軟體需求調研方案設計
軟體需求作為軟體專案工作的重要依據，對軟體專案的成敗起著至關重要的作用。以下是小編整理的軟體需求調研方案設計，歡迎閱讀。
軟體需求分析是一個專案的開端，也是專案實施最重要的關鍵點。據有關的機構分析結果表明，我們設計的軟體產品存在不完整性、不正確性等問題80％以上是需求分析錯誤所導致的，而且由於需求分析錯誤造成根本性的功能問題尤為突出。因此，一個專案的成功軟體需求分析是關鍵的一步。
A.軟體需求分析人員組織
軟體需求分析其根本性問題是理解使用者功能需求，由此軟體需求分析實際上是與客戶間交流過程完成的目標。要求我們組織適當的參與人員進行交流活動。
需求分析是一個綜合團隊的工作，是在需求分析理論的指導下，對使用者需要進行漸進方式逐步深化；透過不斷變化方式形成具體約束；努力實現需求功能目標形成特色效果的商業化產品。需求分析是一個商業行為，完全是一個商業化操作，要求有商業、技術等結合的團隊共同合作，解決需求和設計的同步，設計符合需求。
專案涉及內容，專案大小都需要我們考慮參加軟體需求分析工作團退的人數，配置合理的參與人員。一般我們必須有商務活動人員，專案管理人員，設計技術人員等參加，而且要求組織人員必須明確負責範圍，以及明確工作目標，保證實施的有效性。
B.具體開展需求分析工作，建議採用以下步驟形成軟體需求：確定專案目標及範圍→獲取使用者需求→分析使用者需求→編寫需求文件→評審需求文件→管理需求。
第一步：明確需要分析的工作目標，同時確定調研物件，最好能指定本次專案的介面人。
明確軟體需求分析的主要實現目標包括如下內容：
1）對實現軟體的功能做全面的描述，幫助使用者判斷實現功能的正確性、一致性和完整性，促使使用者在軟體設計啟動之前周密地、全面地思考軟體需求；
2）瞭解和描述軟體實現所需的全部資訊，為軟體設計、確認和驗證提供一個基準；
3）為軟體管理人員進行軟體成本計價和編制軟體開發計劃書提供依據；
第二步：獲取使用者需求。這是該階段的一個最重要的任務。對使用者進行訪談和調研。交流的方式可以是會議、電話、電子郵件、小組討論、模擬演示等不同形式。具體說來可分為三個階段：
1.“訪談”階段
這一階段是和具體使用者方的領導層、業務層人員的訪談式溝通，主要目的是從宏觀上把握使用者的具體需求方向和趨勢，瞭解現有的組織架構、業務流程、硬體環境、軟體環境、現有的執行系統等等具體情況、客觀的資訊。建立起良好的溝通渠道和方式。針對具體的職能部門以及成員單位。
實現手段：訪談、調查表格
輸出成果：調查報告、業務流程報告
2.“誘導”階段
這一階段是在承建方已經瞭解了具體使用者方的組織架構、業務流程、硬體環境、軟體環境、現有的執行系統等等具體實際、客觀的資訊基礎上，結合現有的硬體、軟體實現方案，做出簡單的使用者流程頁面，同時結合以往的專案經驗對使用者採用誘導式、啟發式的調研方法和手段，和使用者一起探討業務流程設計的合理性、準確性、便易性、習慣性。使用者可以操作簡單演示的DEMO，來感受一下整個業務流程的設計合理性、準確性等等問題，及時地提出改進意見和方法。
實現手段：拜訪（誘導）、原型演示
輸出成果：調研分析報告、原型反饋報告、業務流程報告
3.“確認”階段
這一階段是在上述兩個階段成果的基礎上，進行具體的流程細化、資料項的確認階段，這個階段承建方必須提供原型系統和明確的業務流程報告、資料項表，並能清晰地向用戶描述系統的業務流設計目標。使用者方可以透過審查業務流程報告、資料項表以及操作承建方提供的DEMO系統，來提出反饋意見，並對已經可接受的報告、文件簽字確認。
實現手段：拜訪（回顧、確認），提交業務流程報告、資料項表；原型演示系統
輸出成果：需求分析報告、資料項、業務流程報告、原型系統反饋意見（後三者可以統一歸入需求分析報告中，提交使用者方、監理方進行確認和存檔）
整體來講，需求分析的三個階段是需求調研中不可忽視一個重要的部分，三個階段或者說三步法的實施和採用，對使用者和承建方都同樣提供了專案成功的保證。當然在系統建設的過程中，特別在採用迭代法的開發模式時，需求分析的工作需一直進行下去，而在後期的需求改進中，工作則基本集中在後兩個階段中。
第三步：分析使用者需求。
需求分析人員對收集到的使用者需求做進一步的分析和整理。下面是幾條常見的準則：
1.對於使用者提出的每個需求都要知道“為什麼”，並判斷使用者提出的需求是否有充足的理由;
2.將那種以“如何實現”的表述方式轉換為“實現什麼”的方式，因為需求分析階段關注的目標是“做什麼”，而不是“怎麼做”;
3.分析由使用者需求衍生出的隱含需求，並識別使用者沒有明確提出來的隱含需求(有可能是實現使用者需求的前提條件)，這一點往往容易忽略掉，經常因為對隱含需求考慮得不夠充分而引起需求變更。
需求分析的具體內容可以歸納為六個方面：軟體的功能需求，軟體與硬體或其他外部系統介面，軟體的非功能性需求，軟體的反向需求，軟體設計和實現上的限制，閱讀支援資訊。
軟體需求分析應儘量提供軟體實現功能需求的全部資訊，使得軟體設計人員和軟體測試人員不再需要需求方的接觸。這就要求軟體需求分析內容應正確、完整、一致和可驗證。此外，為保證軟體設計質量，便於軟體功能的休整和驗證，軟體需求表達無岔意性，具有可追蹤性和可修改性。
1.軟體的功能需求。
軟體的功能需求是整個需求分析最主要、最關鍵和最複雜的部分，它描述軟體的各種可能的條件下，對所有可能輸入的資料資訊，應完成那些具體功能，產生什麼樣的輸出。描述軟體功能需求是應注意下面幾點：
1）功能需求的完整性和一致性
對功能的描述應包含與功能相關的資訊，並應具有內在的一致性（即各種描述之間不矛盾、不衝突）。應注意以下幾點：
（1）給出觸發功能的各種條件（如：控制流、執行狀態、執行模式等）；
（2）定義各種可能性條件下的所有可能的輸入（包括合法的輸入空間和非法的輸入空間）；
（3）給出各種功能間可能的相互關係（如各個功能間的控制流、資料流、資訊流，功能執行關係：順序、重複、選擇、併發、同步）；
（4）給出功能性的主要級別（如：基本功能、可由設計者選擇逐步實現的功能、可由設計者改變實現的功能等）；
（5）儘可能不使用“待定”這樣的詞。所有含有待定內容的需求都不是完整的檔案，如果出現待定的部分，必須進行待定部分內容說明，落實負責人員、落實實施日期。
2）功能描述的.無岔意性和可追蹤性
需求功能描述的無岔意性、可追蹤性和規範化：
（1）功能描述必須清晰地描述出怎樣輸入到怎樣輸出，並且輸入、輸出描述應對應有資料流描述、控制流描述圖，這些描述必須與其它地方描述一致；
（2）可以用語言、方程式、決策表、矩陣或圖等對功能的描述。如果選用語言描述必須使用結構化的語言，描述前必須說明該步驟（或子功能）的執行是順序，選擇，重複，還是併發，然後說明步驟邏輯。整個描述必須單入單出。
（3）描述時，每一個功能名稱和參照編號必須唯一，且不要將多個功能混在一起進行描述，這樣便於功能的追蹤和修改。
（4） 功能描述應注意需求說明和程式設計的區別。需求設計僅僅是軟體的功能設計，它給出軟體執行的的外部功能描述，以及為了實現這一外部功能必須做哪些事情（採用和種資料結構，定義多個模組，介面間的介面等）是設計階段的事情，功能描述不應涉及到那些細節問題，以避免給軟體設計帶來不必要的約束。
2.軟體與硬體或其他外部系統介面。
軟體與硬體或其它外部系統介面包括下述內容：
（1）人機介面：說明輸入、輸出的內容、螢幕安排、格式等要求；
（2）硬體介面：說明埠號，指令集，輸入輸出訊號的內容與資料型別，初始化訊號源，傳輸通道號和訊號處理方式。
（3）軟體介面：說明軟體的名稱、助記符、規格說明、版本號和來源；
（4）通訊介面：指定通訊介面和通訊協議等描述。
3.軟體的非功能性要求。
軟體非功能性需求是指軟體效能指標，容限等功能以外的需求。一般指下述內容：
（1）時間需求：輸入、輸出頻率，輸入、輸出響應時間，各種功能恢復時間等；
（2）處理容限、精度、取樣引數的解析度，誤差處理等；
（3）可靠性的MTBF要求，可維護性、安全性要求等。（對可能的不正常的輸入給以正常響應是可靠性的重要內容，這屬於功能性需求。）
4.軟體反向需求
軟體的反向需求描述軟體在那些情況下不能做什麼。這一條是隨軟體實際要求而定。有兩類情形需要採用反向需求的形式。第一種情況：某些使用者需求適宜採用反向形式說明，如資料安全性要求屬於這類形式。第二種情況：對一些可靠性和安全性要求較高的軟體，有些必須描述軟體不能做些什麼。如控制點火時序，我們必須交代清楚在那些情況下不能點火，否則會造成故障。
5.軟體設計和實現上的限制
軟體設計和實現上的限制主要指對軟體設計者的限制。如軟體執行環境的限制（選擇計算機型別，使用配置，作業系統的限制等）、設計工具的限制（使用語言、執行的標準）和保密要求等。
6.閱讀支援資訊
這部分內容是為了更好的幫助我們理解使用者需求，也是為了使需求便於修改和追蹤。其本身並不是對需求的描述，但它影響到需求分析的可讀性，也屬於需求分析的一個重要部分。一般目錄、需求背景資訊、內容索引、交叉引用表、註釋等均屬於這個部分的內容。
再看軟體需求分析常用工具
我們根據使用者需求，透過反覆討論、分析，最終明確一個唯一性的使用者需求，這個結果其實就是我們的軟體需求分析報告。一般我們採用Word、PowerPoint、Visio、ProntPage、Excel等Office工具，同時可能採用一些開發工具，如VC或BC等，同樣也會使用一些圖形工具，如Potoshop、調色盤等畫圖工具。
使用各種工具表達軟體需求分析，其具體表達手段可以分為：
1.效果圖描述。主要是使用者UI介面的描述反映使用者需求功能；
2.邏輯圖描述。根據使用者需求功能，使用抽象化理論，以及需求分析理論，對使用者需求功能進行全面的分析，建立功能性邏輯關係圖，流程邏輯關係圖等；
3.關係圖表描述。主要是對資訊關係、資料庫表格、介面函式等描述；
4.工程數學描述。分析使用者需求，分析使用者需求資訊，運用工程數學進行演算法推導，進行合理化需求分析推導；
5.甘地圖描述。主要是軟體專案工作安排，開發週期預估；
6.其它方法描述。保證完整性合理性的有效描述。
第四步：編寫需求文件。
根據我們多年的經驗總結，針對特定專案我們的需求文件都有固定模板，經過前面的需求調研、需求分析過程所得到的結果，基本上按照使用者組織結構、功能模組分佈情況，經過文件格式、內容的整合與最佳化，即可形成我們需求調研分析的成果檔案“需求規格說明書”，其將做為我們下一步系統開發的主要輸入檔案之一。
第五步：評審需求文件。
軟體需求分析評審是為了檢查我們進行軟體需求分析工作，保證軟體需求分析工作正確性、完整性、有效性、合理性、可確認性、可實施性，完全保證使用者所需求的功能，評審內容的主要載體就是“需求規格說明書”。
1.組織結構與責任管理
我們對組織結構與責任管理的評估主要有：參與人員任務和責任介面的明確；安排計劃按時完成狀況；相互間的協調能力狀況。
2.滿足使用者需求的功能
我們進行需求分析的目的是完整、準確地描述使用者的需求，跟蹤使用者需求的變化，將使用者的需求準確地反映到系統的分析和設計中，並使系統的分析、設計和使用者的需求保持一致。
需求分析的特點是需求的完整性、一致性和可追溯性。完整性：是準確、全面的描述使用者的需求。一致性：是透過分析整理，剔除使用者需求矛盾的方面，規範使用者需求。可追溯性：有兩個方面的含義，整理和規範的需求，其一，需要不斷的和使用者進一步交流，保持和使用者最新的需求一致。其二，和系統分析（設計）保持一致。
因此在需求分析之前我們必須建立需求分析技術層面的基本框架，從技術上保證需求分析的要求，在此基礎上我們進行的需求分析才能滿足專案對需求分析的要求。
3.保證可實施性
我們必須以使用者軟體需求為依據，以求實的態度詳細的、準確的、完整的編寫軟體需求分析，避免空想世界，空中樓閣的想法；避免無邏輯性、無核心的描述；避免無量化思維，無實際空間概念。
4.需求分析評價指標
主要有這麼幾個指標：功能性、完整性、正確性、邏輯性、表現性、合理性，可實施性等。
5.工作週期
評價人員投入，以及費用支出的合理性問題。正確制定工作週期，保證軟體專案的順利完成。
6.需求不確定更改與可確認保證
可確認需求功能是實現使用者需求的基本保證，如果不可確認的、不確定更改存在，將會阻礙軟體實現，或者軟體設計存在著不完整性缺陷，或者存在著不可實施性問題，我們必須區分是功能性障礙問題，還是未來性問題。如果不能夠明確是未來性問題，則必須調整功能需求，化解不確定更改的問題。因此，判斷不確定性更改是一個非常重要的問題
第六步：管理需求-將存在於專案的整個生命週期內。
需求管理就是IT專案中的範圍管理，需求管理是整個IT專案的源頭，IT專案的估算，計劃，後續的跟蹤控制，驗證和確認等各項工作都是跟需求密切相關的。因此為了保證專案的進度，質量和成本的目標的順利實現，保證專案計劃的嚴肅性和可執行性；為了保證軟體系統最終開發的產品正是客戶期望的產品，必須要做好需求管理工作。
需求管理工作應該是需求全生命週期的管理，從使用者原始需求的提出，到最終形成軟體產品後用戶對需求實現情況的驗證以形成閉環流程。因此我們需要跟蹤和了解到需求狀態的演變過程。大型的專案軟體生命週期模型較為複雜，一個需求的實現會經過使用者需求，軟體需求，總體設計，詳細設計，開發和單元測試，整合測試，系統測試和驗收測試多個環節，在這個過程中需要建立需求追蹤以確認需求和中間階段產生的工作產品的一致性。另外變更管理是需求管理的另外一個重點，需求在經過評審確認後需要基線並受到控制，當出現需求變更的時候必須進行相應的需求影響分析以確認對需求變更的處理方式，當變更工作量影響較大的時候還需要調整並重新基線專案計劃。
對於整個需求調研，分析和需求開發，評審確認的過程也需要進行管理。在這個過程中的一個重點就是對需求輸出的文件需要得到使用者，專案組設計開發人員的共同確認和承諾。
【軟體需求調研方案設計】相關文章：