讀《需求工程——軟件建模與分析》 第四部分 需求的文檔化和驗證 有感

　　需求規格說明文檔是需求規格說明活動的一個核心元素。（1）需求規格說明文檔可以成為各方人員之間有關軟件系統的協議基準。（2）需求規格說明文檔可以成為項目開發活動的一個重要依據。（3）在需求規格說明文檔的編寫過程中，可以盡早的發現和減少可能的需求錯誤，從而減少項目的返工，降低項目的工作量。（4）需求規格說明文檔可以成為有效的智力資產。

　　需求規格說明文檔的幾個常見讀者群體：項目管理者、設計人員和程序員、測試人員、文檔編寫人員、維護人員、培訓人員、律師。為了讓文檔的編寫工作更加順利，同時也讓編寫出的文檔具有更高的質量，人們傾向於總結、借鑒和復用已有的經驗。因此，在編寫需求規格說明時，首先要選擇一份適合的文檔模板。

　　軟件需求規格說明模板：（1）引言（是對整個軟件需求規格說明的概覽）：a.文檔的意圖（目的）b.主要內容（範圍）c.閱讀時的註意事項（定義、首字母縮寫和縮略語）、參考文獻、組織方式（文檔組織）（2）總體描述（從總體上描述影響蟾皮和需求的因素）：a.產品前景 b.產品功能 c.用戶特征 d.約束 e.假設和依賴 （3）詳細需求描述（最多和最重要的部分）：a.功能需求 b.性能需求 c.約束 d.質量屬性 e.對外接口

　　優秀的需求規格說明文檔應該具備下面的特性：正確性、無歧義、完備性、一致性、根據重要性和穩定性分級、可驗證、可修改、可跟蹤。

　　在需求驗證中，驗證有兩層含義：驗證與確認。要深入的了解驗證與確認的實質意義，就有必要在整個軟件工程的框架下來理解系統驗證的意義。軟件開發過程中的完全正確性是可望而不可即的，總還有一些小的偏差和錯誤發生。所以有在開發過程中發現的偏差和錯誤都應該在最終的軟件產品中得到修正。軟件測試時人們最為熟悉和常用的軟件質量保證措施。

　　和驗證活動貫穿於軟件開發活動一樣，驗證活動同樣也普遍存在於需求開發活動中。需求驗證並不是一個可以一次結束的活動，它可能需要多次、反復地執行驗證。執行驗證的常見方法有：需求評審、原型與模擬、測試用例開發、用戶手冊編制、利用跟蹤關系和自動化分析。

　　評審又被稱為統計評審，是指由作者之外的其他人來檢查產品問題的方法。在系統驗證中，評審時主要的靜態分析手段，所以評審也是需求評審的一種主要方法。審查過程中的所有參與者，包括作者，他們的任務都是查找缺陷和對其進行改進的機會。審查組中的成員在審查期間可能扮演下面的角色：（1）組織者，負責整個項目當中審查活動的組織和規劃。（2）仲裁者，負責確保整個審查過程的正確進行，協調審查活動。（3）作者，創建或者維護軟件需求規格說明文檔的人，在評審中作為聽眾聽取評論，並在需要時解答審查人員的問題。（4）閱讀人員。（5）記錄人員。（6）收集人員。（7）審查人員。

　　常見的評審過程可以分為6個階段：（1）在和規劃階段，作者和仲裁者共同制定審查計劃，決定審查會議的次數，安排每次審查會議的時間、地點、參與人員、審查內容。（2）在總體部署階段，作者和仲裁者向所有參與審查會議的人員描述待審查材料的內容、審查的目標以及一些假設，並分發文檔。（3）在準備階段，審查人員各自獨立執行檢查任務。（4）審查會議階段，通過會議討論，識別、確認和分類發現的錯誤。（5）返工階段，作者修改發現的缺陷。（6）在跟蹤階段，仲裁者要確認所有發現的問題都得到了解決，所有的錯誤都得到了修正。

　　需求獲取活動收集了需求信息，需求分析活動深入地理解了需求信息並建立了能夠滿足用戶需要的軟件解決方案。而需求規格說明活動就是將需求及其軟件解決方案進行定義和文檔化，並傳遞給開發人員的需求工程活動。

閱讀筆記四