需求獲取活動收集了需求資訊，需求分析活動深入地理解了需求資訊並建立了能夠滿足使用者需要的軟體解決方案。而需求規格說明活動就是將需求及其軟體解決方案進行定義和文件化，並傳遞給開發人員的需求工程活動。
需求規格說明文件是需求規格說明活動的乙個核心元素。（1）需求規格說明文件可以成為各方人員之間有關軟體系統的協議基準。（2）需求規格說明文件可以成為專案開發活動的乙個重要依據。（3）在需求規格說明文件的編寫過程中，可以盡早的發現和減少可能的需求錯誤，從而減少專案的返工，降低專案的工作量。（4）需求規格說明文件可以成為有效的智力資產。
需求規格說明文件的幾個常見讀者群體：專案管理者、設計人員和程式設計師、測試人員、文件編寫人員、維護人員、培訓人員、律師。為了讓文件的編寫工作更加順利，同時也讓編寫出的文件具有更高的質量，人們傾向於總結、借鑑和復用已有的經驗。因此，在編寫需求規格說明時，首先要選擇乙份適合的文件模板。
軟體需求規格說明模板：（1）引言（是對整個軟體需求規格說明的概覽）：a.文件的意圖（目的）b.主要內容（範圍）c.閱讀時的注意事項（定義、首字母縮寫和縮略語）、參考文獻、組織方式（文件組織）（2）總體描述（從總體上描述影響蟾皮和需求的因素）：a.產品前景 b.產品功能 c.使用者特徵 d.約束 e.假設和依賴 （3）詳細需求描述（最多和最重要的部分）：a.功能需求 b.效能需求 c.約束 d.質量屬性 e.對外介面
優秀的需求規格說明文件應該具備下面的特性：正確性、無歧義、完備性、一致性、根據重要性和穩定性分級、可驗證、可修改、可跟蹤。
在需求驗證中，驗證有兩層含義：驗證與確認。要深入的了解驗證與確認的實質意義，就有必要在整個軟體工程的框架下來理解系統驗證的意義。軟體開發過程中的完全正確性是可望而不可即的，總還有一些小的偏差和錯誤發生。所以有在開發過程中發現的偏差和錯誤都應該在最終的軟體產品中得到修正。軟體測試時人們最為熟悉和常用的軟體質量保證措施。
和驗證活動貫穿於軟體開發活動一樣，驗證活動同樣也普遍存在於需求開發活動中。需求驗證並不是乙個可以一次結束的活動，它可能需要多次、反覆地執行驗證。執行驗證的常見方法有：需求評審、原型與模擬、測試用例開發、使用者手冊編制、利用跟蹤關係和自動化分析。
常見的評審過程可以分為6個階段：（1）在和規劃階段，作者和仲裁者共同制定審查計畫，決定審查會議的次數，安排每次審查會議的時間、地點、參與人員、審查內容。（2）在總體部署階段，作者和仲裁者向所有參與審查會議的人員描述待審查材料的內容、審查的目標以及一些假設，並分發文件。（3）在準備階段，審查人員各自獨立執行檢查任務。（4）審查會議階段，通過會議討論，識別、確認和分類發現的錯誤。（5）返工階段，作者修改發現的缺陷。（6）在跟蹤階段，仲裁者要確認所有發現的問題都得到了解決，所有的錯誤都得到了修正。
軟體需求分析 閱讀筆記
筆記要求 發表一篇閱讀筆記，說明本學期 軟體需求分析 需要掌握哪些必要的內容？針對每個內容點說出自己的理解，並繪圖標意相互之間的關聯關係。讀 需求工程 軟體建模與分析 有感 今天大致的看了一下這本書，對軟體需求分析有了初步的了解，我認為學習軟體需求分析需要掌握的內容主要包括五個方面 需求基礎與過程 ...
軟體需求分析閱讀筆記
今天讀了關於如何做需求分析的博文，學習了軟體需求與分析需要掌握的一些內容，下面就做一些總結。首先要認識到深入地去理解客戶的業務，進而想到客戶的心坎兒上去，最後做出來的東西必然是客戶滿意的。第乙個舉出來東軟的例子，東軟在做這個專案的時候，整個過程經歷了10多次結構性的大變更，區域性性的調整更是不計其數...
《軟體需求分析》閱讀筆記
很多需求分析的工作都是從需求調研開始，需求調研是需求分析最重要的一環，決定之後的工作能否順利地展開，與客戶的交流決定了能否明確的交換雙方的想法，讓客戶與我們都可以達到滿意。面對客戶群體的不同層次決定了如何交流，不同的群體對程式設計的了解是不同的，對不同的人要有不同的交流方法，而需求調研不是一朝一夕所...