需求工程系列：
軟件需求工程習題1（1~4章）
軟件需求工程習題2（5~7章）
需求工程中的面談和原型（8、9章）
需求獲取方法之觀察與文檔審查（10章）
需求工程規格說明、需求驗證、需求管理（11~13章）
第十一章 需求規格說明
需求獲取：目標是得到用戶需求——收集需求信息
需求分析：目標是更深刻的理解用戶需求——界定能夠讓用戶滿意的解決方案准則
需求規格說明：目標是定義用戶需求——準確描述需求及其解決方案
需求規格說明文檔類型：
需求規格說明文檔的描述手段：
非形式化：自然語言、限制性文本
半形式化：結構化文本（僞碼/結構化英語）、模型語言（圖、表…）
形式化：形式化語言（數學語言：BNF，Z…）
優秀需求規格說明文檔的特性：
完備性、一致性、根據重要性和穩定性分級、可修改、可跟蹤
習題：
1.系統需求開發的結果最終會寫入（ 系統需求規格說明）。
2.項目的前景和範圍文檔、用戶需求文檔都被視爲屬於（ 用戶文檔），重點都是用戶的現實世界。
3.系統需求規格說明文檔、軟件需求規格說明文檔、硬件需求規格說明文檔、接口需求規格說明文檔和人機交互文檔一起被用於系統開發的目的，都被認爲是（開發文檔）。
4.下列（ C）不是需求規格說明文檔的讀者。
A、項目管理者
B、編程人員
C、銷售商
D、律師
5.編寫需求規格說明文檔的意義（ABCD）
A、需求規格說明文檔可以成爲各方人員之間有關軟件系統的協議基準。
B、需求規格說明文檔可以成爲項目開發活動的一個重要依據。
C、在需求規格說明文檔的編寫過程 中，可以儘早的發現和減少可能的需求錯誤，從而減少項目的返工，降低項目的工作量。
D、需求規格說明文檔可以成爲有效的智力資產。
6.編寫需求規格說明文檔所使用的語言類型有（非形式化語言、半形式化語言、形式化語言）。
7.【判斷題】軟件需求規格說明文檔是對部分系統功能分配給軟件部分的詳細描述。（×）
8.【判斷題】人機交互文檔是對整個系統功能中需要進行人機交互部分的詳細描述。（√）
9.【判斷題】需求規格文檔化的目標是交流。（√）
第十二章 需求驗證
驗證（Validation）與確認（Verification）
一方面，它要確保正確地得到需求（需求驗證）得到足以作爲軟件創建基礎的需求；
另一方面，它要確保得到正確的需求（需求確認），得到能夠準確反映用戶意圖的需求。
需求驗證活動的四個步驟：
需求驗證普遍存在於需求開發活動中
1、在需求獲取中：獲得的用戶需求是否正確和充分的支持業務需求？
2、在需求分析中：建立的分析模型是否正確的反映了問題域特性和需求？細化的系統需求是否充分和正確的支持用戶需求？
3、需求規格說明：需求規格說明文檔是否組織良好、書寫正確？需求規格說明文檔內的需求是否充分和正確的反映了涉衆的意圖？需求規格說明文檔是否可以作爲後續開發工作（設計、實現、測試等等）的基礎？
4、需求驗證：是指在需求規格說明完成之後，對需求規格說明文檔進行的驗證活動。
需求驗證常見的方法；
需求評審、原型與模擬、開發測試用例、用戶手冊編制、利用跟蹤關係和自動化分析。
評審過程的6個階段：
1.規劃階段
2.總體部署階段
3.準備階段
4.評審會議階段
5.返工階段
6.跟蹤階段
評審的類型：
審查（最爲嚴格）、小組評審（輕型審查）、走查、輪查、臨時評審（最不正式）
習題：
1.在大多數情況下，需求都是在靜態的方式下被加以驗證。那麼對複雜的動態行爲就需要使用模擬或原型方法來加以驗證。
2.評審的檢查方法有自由方法、檢查清單、缺陷、功能點、視角、場景和逐步提升。
3.【判斷題】 需求驗證活動同樣普遍存在於需求分析過程中。（ ×）
4.【判斷題】需求驗證是需求工程中最後一個活動。（ ×）
5.需求驗證並不是一個可以一次結束的活動，它可能需要多次、反覆地執行驗證。（ √）
6.在大多數情況下，需求都是在靜態的方式下被加以驗證。那麼對複雜的動態行爲就需要使用原型或模擬方法來加以驗證。 ( √)
7.審查類型中最正式評審類型是輪查。（×）
8.驗證是貫穿於整個軟件生命週期的。（ √）
9.基於場景方法也是需求評審當中常用的一種檢查方法。（√）
10.需求驗證和需求確認一樣，都能確保得到正確的需求。（ ×）
第十三章 需求管理
在需求開發活動之後，需求基線應該成爲後續軟件系統開發的工作基礎和黏合劑：
- 項目管理者根據需求安排、監控和管理項目計劃；
- 開發者依據需求開發相應的產品功能和特性；
- 測試人員按照需求執行系統測試和驗收測試；
- 客戶和顧客依照需求驗收最終產品；
- 維護人員參考需求執行產品的演化。
也就是說，需求的影響力貫穿於整個後續的產品生命週期，而不是單純地存在於需求開發階段。軟件需求規格說明文檔要在產品生命週期的各個階段都扮演重要角色，發揮重要作用。軟件需求說明文檔的內容是開發各階段的標準和目標來進行。
需求管理的3個活動：
維護需求基線、實現需求跟蹤和控制變更。
需求基線的內容：
軟件需求是需求基線的關鍵內容，還包括很多和軟件需求相關的描述信息，它們將爲軟件需求在項目中的作用的有效發揮提供信息支持。
需求基線的維護：
1.配置管理
2.狀態維護
需求跟蹤：
以軟件需求規格說明文檔爲基線，在向前和向後兩個方向上，描述需求以及跟蹤需求變化的能力。
1.前向跟蹤
前向跟蹤是指需求被定義到軟件需求規格說明文檔之前的演化過程
（1）向前跟蹤到需求：說明涉衆的需要和目標產生了哪些軟件需求
（2）從需求向後回溯：說明軟件需求來源於哪些涉衆的需要和目標
2.後向跟蹤
後向跟蹤是指需求被定義到軟件需求規格說明文檔之後的演化過程
（1）從需求向前跟蹤：說明軟件需求是如何被後續的開發物件支持和實現的
（2）回溯到需求的跟蹤：說明各種系統開發的物件是因爲什麼原因（軟件需求）而被開發出來的
需求跟蹤的實現方法：
主要有矩陣、實體關係模型和交叉引用3種。
習題：
1.需求工程是所有需求處理活動的總和，它包括需求開發和需求管理兩個部分。
2需求基線的維護主要包括配置管理和狀態維護。
3.從需求向後回溯（前向跟蹤的兩種聯繫之一）說明軟件需求來源於哪些涉衆的需要和目標。
4.後向跟蹤是指 需求被定義到軟件需求規格說明文檔之後的演化過程。
5.【判斷題】前向跟蹤是指需求在被 獲取 到軟件需求規格說明文檔之前的演化過程。（×）
6.【判斷題】後向跟蹤包括兩種聯繫：從需求向前跟蹤和 回溯到需求的跟蹤 。（√）
7.【判斷題】需求基線其實不是被明確和固定的需求集合，是項目團隊需要在某一特定產品版本中實現的特徵和需求集合。（×）
8.【判斷題】需求跟蹤是一種有效的控制手段，能夠在涉衆的需求變化中協調系統的演化，保持各項開發工作對需求的一致性。（√）
9.【判斷題】需求跟蹤是以前景與範圍文檔爲基線，在向前和向後兩個方向上，描述需求以及跟蹤需求變化的能力，分爲前向跟蹤和後向跟蹤兩種。（×）應該是以軟件需求規格說明文檔爲基線