軟件需求與分析需掌握的內容
1.準備相應文檔
開發商方的系統分析人員同用戶的需求提供人員正式接觸前，完成一個問詢表及需求分析計劃。
一般情況下只需要完成一個整體細節問詢表，問詢用戶為明確需求已經完成的文檔情況（如果可以在進行正式接觸前可以得到並了解完成最好）、業務目的、當前目標、長遠目標、當前準備情況、完成的業務功能列表、將來系統操作人員的業務及電腦技術了解情況、最終操作用戶、當前及將來的硬件、軟件及網絡環境等問題。
由開發商系統分析人員根據對業務的了解程度，適當編寫各業務功能細節問詢表。不過業務功能細節問詢表的使用，是在業務需求調研過程中用戶表明其需求後，再根據問題還沒有明確的情況下再進行問詢的。
其他業務相關政策法規、技術文檔、技術支持人員的通信錄等也要進行相應的準備。
2. 調研過程
調研的過程推薦開發商系統開發人員有專人進行會議記錄，並在每日會議結束後，當場宣布本次會議的結果，並由參加會議人員進行簽字。第二日復印或發送電子文件給參加會議人員及相關人員。以便做到有據可查，明確過程。
開發商系統開發人員每周對用戶提供開發周報，告訴用戶當前開發的進展、是否有問題、是否用戶協助等，這是一個好的加強雙方溝通的方法。
註意：在調研過程的中系統開發人員的變更會對計劃產生重大的影響，不要簡單認為是人員更換的問題。因為在調研過程中對業務的理解，不是通過看看文檔就可以達到。3天通過討論達到對需求理解的程序，9天對文檔的學習也不一定能達到。
3 一般情況下需明確的問題
當前整體業務需求的目的
要求提供的需求功能列表
將來發展的設想
明確服務器、客戶機的軟、硬件及性能要求（容量、速度、可操作性等）
用戶目前相關的技術人員和業務人員情況
將來最終系統操作人員的技術及業務人員情況
用戶需求的系統及用戶本身或其它系統的接口要求
用戶的其它要求
4 需求分析的方法
- 繪制系統關聯圖，這種關聯圖是用於定義系統與系統外部實體間的界限和接口的簡單模型。同時它也明確了通過接口的信息流和物質流。
- 創建用戶界面原型，當開發人員或用戶不能確定需求時，開發一個用戶界面原型——一個可能的局部實現，這樣使得許多概念和可能發生的事更為直觀明了。用戶通過評價原型將使項目參與者能更好地相互理解所要解決的問題。
- 分析需求可行性，在允許的成本、性能要求下，分析每項需求實施的可行性，明確與每項需求實現相聯系的風險，包括與其它需求的沖突，對外界因素的依賴和技術障礙。
- 確定需求的優先級別，應用分析方法來確定使用實例、產品特性或單項需求實現的優先級別。以優先級為基礎確定產品版本將包括哪些特性或哪類需求。當允許需求變更時，在特定的版本中加入每一項變更，並在那個版本計劃中作出需要的變更。
- 為需求建立模型，需求的圖形分析模型是軟件需求規格說明極好的補充說明。它們能提供不同的信息與關系以有助於找到不正確的、不一致的、遺漏的和冗余的需求。這樣的模型包括數據流圖、實體關系圖、狀態變換圖、對話框圖、對象類及交互作用圖。
- 依據分析階段確定合適的客戶方配合人員。
5 完成需求確認
對於需求最終的確認需求先由系統開發人員對編寫的文檔進行內部審核及修訂，然後交由用戶業務人員進行確認，明確系統開發人員已經了解業務需求，並進行簽字確認。
1. 整體需求不變，具體細節變化。
2. 界面風格與操作易用性是最容易發生變更的。
3. 增加其它功能。軟件是對現實的模擬，而現實也是復雜多變的。
軟件需求
軟件需求與分析需掌握的內容