需求規格說明文件是需求規格說明活動的乙個核心元素。（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）在跟蹤階段，仲裁者要確認所有發現的問題都得到了解決，所有的錯誤都得到了修正。
需求獲取活動收集了需求資訊，需求分析活動深入地理解了需求資訊並建立了能夠滿足使用者需要的軟體解決方案。而需求規格說明活動就是將需求及其軟體解決方案進行定義和文件化，並傳遞給開發人員的需求工程活動。
閱讀筆記四
軟體需求模式的第四章 使用和編寫需求模式閱讀筆記 在學習了需求模式的機制之後，開始教我們學習如何來編寫需求模式。首先我們要知道，什麼時候要用到需求模式。在定義系統期間，6種情況下需要用到需求模式，分別是當定義需求時，看是否存在可以指導如何定義這種需求 當考慮需求是否完全時，瀏覽主題覆蓋的整套模式，是...
《人件》閱讀筆記四
無論做出何種努力，最終結果更多在於是誰來做而不是怎麼做。你的成功與否完全取決於你在何時何地部署你的好無差異的資源。成功還是失敗在組建團隊並形成最初方向時就已經設定了。領導力通常指的是如何巧妙利用權力在組織中達到乙個目標。作為工作壓榨機制的領導力 領導的速度決定團隊的效率 這種領導力就是工作榨取的機制...
《設計原本》閱讀筆記（四）
本次閱讀筆記主要談一談設計原本的第八章 設計中的理性主義與經驗主義。理性主義與經驗主義一直存在分歧，面對設計也是如此，主要是對 依靠思考能否正確完成設計 這一問題。理性主義者認為人類天生就是健全的，雖然會犯錯誤，但可以通過後天的學習不斷完善自己，因此隨著不斷的教育，經過仔細的思考後是可以完成設計任務...