软件需求管理
目錄
- 前言
- 1.需求工程導論
- 1.1軟件工程導論部分知識
- 1.1.1軟件開發的五種常用模型
- 1.1.1.1瀑布模型
- 1.1.1.2快速原型模型
- 1.1.1.3增量模型
- 1.1.1.4螺旋模型
- 1.1.1.5面向對象的模型（噴泉模型）
- 1.1.2結構化和面向對象
- 1.1.3統一軟件開發過程
- 1.2軟件需求概述
- 2.需求工程
- 2.1需求工程的基本活動
- 2.2需求基線
- 2.3需求工程的兩個時期
- 2.4需求工程的特性
- 2.4.1必要性
- 2.4.2復雜性
- 3.需求理論基礎
- 3.1需求的類型
- 3.1.1需求的層次性（需求的三個層次）
- 3.1.1.1業務需求
- 3.1.1.2用戶需求
- 3.1.1.2系統需求
- 3.1.2嚴格意義上的軟件需求分類
- 3.1.2.1功能需求
- 3.1.2.2非功能需求
- 3.2需求工程的路線（了解）
- 3.3優秀需求的特性
- 3.3.1完整性
- 3.3.2正確性（真實性）
- 3.3.3可行性
- 3.3.4必要性（精確性）
- 3.3.5無歧義
- 3.3.6可驗證
- 4.需求工程過程
- 4.1需求工程過程
- 4.2需求工程的活動
- 4.2.1需求獲取
- 4.2.2需求分析
- 4.2.3需求規格說明
- 4.2.4需求驗證
- 4.2.5需求管理
- 4.3需求工程的并發和迭代性
- 5.需求獲取概述
- 5.1需求的非平凡性
- 5.1.1.用戶和開發人員的背景不同，立場不同
- 5.1.2.普通用戶缺乏概括性、綜合性的表述能力
- 5.1.3.用戶存在認知困境
- 5.1.4.缺乏用戶參與
- 5.2需求獲取的過程（了解）
- 5.3需求獲取活動的要點
- 5.3.1獲取內容
- 5.3.2獲取來源
- 5.3.2.1涉眾（主要講解涉眾分析的步驟）
- 涉眾識別（發現所有關鍵類別，識別方法）
- 涉眾描述
- 涉眾評估
- 優先級評估（重要性）——兩種方法 User/Task矩陣 和 power/interest分布圖
- 風險評估 power/attribute分布圖
- 共贏分析 Stakeholder/Issue關系圖
- 涉眾代表選擇
- 代表采樣（涉眾明確時，對于每種涉眾選擇合適的代表）
- 用戶替代源（涉眾不明確時，選擇與用戶聯系密切且有經驗的人作為涉眾代表）
- 涉眾參與需求開發（軟件系統）的參與策略
- 5.3.2.2硬數據
- 定量硬數據
- 定性硬數據
- 硬數據的采樣方法
- 5.3.2.3相關產品
- 5.3.2.4重要文檔
- 5.3.2.5相關技術標準和法規
- 5.3.3獲取方法
- 傳統方法
- 集體獲取方法
- 原型
- 模型驅動方法
- 認知方法
- 基于上下文的方法
- 5.3.4獲取過程（了解）
- 5.3.4.1防止遺漏
- 5.3.4.2結束獲取活動的判斷條件
- 5.3.5獲取結果
- 獲取筆錄、錄音錄像（Elicitation Notes）
- 正式文檔（項目前景和范圍文檔、用例文檔）
- 6.確定項目的前景和范圍
- 6.1確定項目前景和范圍的活動
- 6.2問題分析
- 6.2.1明確問題
- 描述問題
- 判斷問題的明確性
- 發現問題背后的問題
- 6.2.2發現業務需求
- 6.2.3定義解決方案及系統特性
- 確定高層次的解決方案
- 確定系統特性和解決方案的邊界
- 確定解決方案的約束
- 6.3建立系統邊界
- 6.3.1面向對象——用例圖
- 6.3.2結構化——上下文圖
- 6.4項目前景和范圍文檔
- 7.面談
- 7.1面談中的問題
- 7.1.1問題的類型
- 開放式問題
- 封閉式問題
- 其他類型的問題
- 7.1.2問題的組織
- 金字塔型
- 漏斗型
- 菱型
- 7.2面談的過程
- 7.2.1準備面談
- 7.2.2主持面談
- 7.2.3處理面談結果
- 7.3面談的類型
- 7.3.1結構化面談
- 7.3.2半結構化面談
- 7.3.3非結構化面談
- 7.4面談的優點和局限
- 優點
- 局限
- 8.原型
- 8.1應用原型的必要性
- 8.2原型的類別
- 8.2.1按照使用方式分類
- 8.2.2按照開發方式分類
- 8.2.3按照構建技術分類
- 8.2.4按照介質分類
- 8.2.5按照表現分類
- 8.3原型方法過程
- 8.4原型方法的風險
- 9.觀察和文檔審查
- 9.1觀察的情境適用性
- 常見的觀察方法
- 觀察的情境性（了解）
- 9.2觀察方法的應用
- 9.2.1采樣觀察
- 9.2.2民族志
- 9.3文檔審查方法的應用
- 10.需求分析概述
- 10.1需求分析的根本任務
- 10.1.1建立分析模型
- 10.1.1.1模型
- 建立模型的方法
- 建立模型的好處
- 10.1.1.2兩個世界與三種模型
- 計算模型（不是個需求建模）
- 業務模型（不適合需求建模）
- 分析模型（適合做需求建模）
- 10.1.1.3模型的表述
- 三要素
- 分析模型
- 需求建模
- 需求分析和目標
- 10.1.2建立解決方案
- 10.2需求分析技術
- 結構化技術
- 面向對象技術
- 綜合運行需求分析技術
- 10.3需求分析方法
- 傳統分析(1950’s)
- 結構化分析(late 1980’s)
- 面向對象分析(1990‘s)
- 10.4前期需求階段的建模與分析
- 面向目標的分析（Goal Oriented Analysis）
- 面向問題域的分析（Problem Domain Oriented Analysis）
- 領域分析（Domain Analysis）
- 企業建模（Enterprise Modeling）
- 10.5需求分析的活動
- 10.5.1前期需求分析的活動
- 10.5.2后期需求分析的活動
- 過程描述（了解）
- 需求細化
- 確定需求的優先級
- 需求協商
- 11.需求規格說明
- 11.1需求規格說明概述
- 11.2需求規格說明文檔
- 11.3模版的選擇與裁剪
- 11.4文檔寫作技巧
- 11.5優秀需求規格說明文檔的特性
- 完備性
- 一致性
- 根據重要性和穩定性分級
- 可修改
- 可跟蹤
- 11.6需求規格說明的實踐調查
- 12.需求驗證
- 12.1驗證與確認
- 12.2需求驗證
- 12.3需求驗證方法
- 12.3.1評審
- 12.3.2原型與模擬
- 12.3.3開發測試用例
- 12.3.4用戶手冊編制
- 12.3.5利用跟蹤關系※
- 12.3.6自動化分析
- 12.4問題修正※
- 12.5需求驗證的實踐調查
- 13.需求管理
- 13.1需求管理
- 13.1.1需求管理意圖
- 13.1.2需求管理作用
- 13.1.3需求管理任務
- 13.1.4需求管理活動
- 13.2需求基線
- 13.3需求跟蹤
- 13.3.1用途
- 13.4需求變更控制
- 13.5需求管理的實踐調查
- 13.5.1需求變更
- 13.5.2需求管理工具
前言
首先想現在這里寫下一點自己關于這門課的理解吧，先對這門課有一個整體的認識
一個軟件從開始到消亡一共會經歷以下三個步驟
由圖我們不難看出，軟件需求是在軟件開發之前的一個步驟，主要用于解決系統究竟要做什么的問題
但是用戶由于種種原因，往往對于需求的描述無法做到非常清淅
因此就需要一種科學的工程化方法來獲取需求，這就是軟件需求管理存在的意義
接下來我們將系統的看一看這門課的知識
第一節、第二節思維導圖：
1.需求工程導論
這一章我們將介紹需求工程的一些前置知識，主要包括軟件工程導論中的部分知識和軟件需求概述
1.1軟件工程導論部分知識
1.1.1軟件開發的五種常用模型
1.1.1.1瀑布模型
傳統瀑布模型的開發流程如下圖所示
但是在實際的開發過程中，往往前一階段的任務會存在誤差，需要調整
因此就有接下來這種實際的瀑布模型
由于以上開發模式，不嫩總結出瀑布模型的優缺點
優點：
瀑布模型適合于用戶需求明確、完整、無重大變化的軟件項目開發。一種文檔驅動的模型
嚴格規定必須提交的文檔，交出的所有產品必須是經過驗證（審查）
缺點：
實際項目很少按照該模型給出的順序進行，用戶常常難以清楚地給出所有需求，需等到系統開發完成
幾乎完全依賴書面的規格說明，可能導致無法滿足用戶需要，只適用于項目開始時需求已確定的情況
1.1.1.2快速原型模型
在用戶不能完整、明確的給出需求說明的時候，開發者往往會先建立一個原型與用戶討論，從而精確得到用戶需求的一種方法
可以理解為是一種應用與瀑布模型中需求分析中的一種方法
建造某些原型僅是為了定義需求，之后就被拋棄（或被部分拋棄），實際的軟件在充分考慮了質量和可維護性之后才被開發。
優點：
不帶反饋環
本質是快速
基本是線性順序進行
用途是獲知用戶真實需求
減少較大的返工
減少后續犯錯的可能性
缺點：
為了使原型盡快的工作，沒有考慮軟件的總體質量和長期的可維護性。
為了演示，可能采用不合適的操作系統、編程語言、效率低的算法，這些不理想的選擇成了系統的組成部分。
開發過程不便于管理。
1.1.1.3增量模型
是一種漸進地開發逐步完善的軟件版本的模型。早期實現用戶的基本需求，并提供給用戶評估的平臺
優點：
在較短時間內向用戶提交可完成部分工作的產品，并分批、逐步地向用戶提交產品。從第一個構件交付之日起，用戶就能做一些有用的工作。
整個軟件產品被分解成許多個增量構件，開發人員可以一個構件一個構件地逐步開發。
逐步增加產品功能可以使用戶有較充裕的時間學習和適應新產品，從而減少一個全新的軟件可能給客戶組織帶來的沖擊。
采用增量模型比采用瀑布模型和快速原型模型需要更精心的設計，但在設計階段多付出的勞動將在維護階段獲得回報。
優先級最高的服務首先交付，項目失敗的風險較低。
缺點：
在把每個新的增量構件集成到現有軟件體系結構中時，必須不破壞原來已經開發出的產品。
必須把軟件的體系結構設計得便于按這種方式進行擴充，向現有產品中加入新構件的過程必須簡單、方便，也就是說，軟件體系結構必須是開放的。
開發人員既要把軟件系統看作整體。又要看成可獨立的構件，相互矛盾。
多個構件并行開發，具有無法集成的風險。
考慮使用增量模型需要注意一下問題：
慎重考慮使用漸增模型的情況：
不能充分理解客戶需求或客戶需求有可能迅速發生變化；
事先擬采用的技術迅速發生變化；
客戶突然提出一些新的功能需求；
長時期內僅有有限的資源保證（開發人員和資金）。
考慮使用漸增模型的情況：
需要在盡短的時間內得到系統基本功能的演示或使用；
各版本都有中間階段產品可提供使用；
系統可以被自然地分割成漸增的模式；
開發人員與資金可以逐步增加。
1.1.1.4螺旋模型
螺旋模型=瀑布模型+快速原型+風險分析
優點：
對可選方案和約束條件的強調有利于已有軟件的重用，也有助于把軟件質量作為軟件開發的一個重要目標。
減少了過多測試或測試不足帶來的風險。
維護和開發之間并沒有本質區別。
缺點：
風險驅動，需要相當豐富的風險評估經驗和專門知識，否則風險更大。
主要適用于內部開發的大規模軟件項目，隨著過程的進展演化，開發者和用戶能夠更好的識別和對待每一個演化級別上的風險。
隨著迭代次數的增加，工作量加大，軟件開發成本增加。
1.1.1.5面向對象的模型（噴泉模型）
典型的面向對象生命周期模型。主要用于支持面向對象開發過程。
體現了軟件創建所固有的迭代和無間隙的特征。
活動之間存在重疊和無縫過渡。
1.1.2結構化和面向對象
結構化: 先調查，再徹底分析、了解問題并規劃，最后實現整個系統。（從功能和流程的角度考慮）
面向對象: 先調查，并將問題細化（根據不同的類和對象以及他們之間的聯系），最后根據這些內在聯系實現整個系統。（從對象的角度考慮）
1.1.3統一軟件開發過程
特點： 軟件開發是迭代過程，是由Use Case（用例）驅動的，以架構設計為中心的增量迭代模型。
統一開發過程四個階段：初始、細化、構建、移交
統一開發過程六個核心工作流：業務建模、需求、分析與設計、測試、實現、部署
1.2軟件需求概述
需求的定義： （正在構建的）系統必須符合的條件或具備的功能或能力
軟件需求的定義：
1、用戶需解決某一問題或達到某一目標所需的軟件功能。
2、系統或系統構件為了滿足合同、規約、標準或其他正式實行的文檔而必須滿足或具備的軟件功能。
2.需求工程
2.1需求工程的基本活動
紅字部分是要點（記住）
2.2需求基線
需求工程主要分成了需求開發和需求管理兩部分
需求開發和需求管理之間的界限就是所謂的需求基線
需求基線定義：已經通過正式評審和批準的需求規格說明活產品
需求基線意義：是軟件需求開發和軟件需求管理的界限
2.3需求工程的兩個時期
需求工程主要分為系統需求開發和軟件需求開發兩部分
由圖不難看出
系統需求開發之前需要進行需求獲取和需求分析
在軟件工程階段，需求工程需要在設計編碼測試之前完成
2.4需求工程的特性
需求工程的特性主要體現在兩個方面，一個是必要性一個是復雜性
2.4.1必要性
軟件開發是這樣一個工程問題
==利用通用的計算機結構，構建一個有用的軟件系統，來滿足人們的某些目的 ==
計算機應用于現實世界的廣泛性
新的問題和新的解決方案
定義問題就是需求工程的任務
2.4.2復雜性
處理范圍廣泛
現實世界和計算機世界
涉及諸多參與方
客戶、用戶、領域專家、需求工程師、軟件開發者、系統維護者等
處理內容多樣
功能需求、非功能需求 、環境及其約束
處理活動互相交織
需求開發的各項活動雖然在理論上具有順序處理的特性，但在實際執行過程中往往是迭代和互相交織的
處理結果要求苛刻
正確性、完整性和一致性
3.需求理論基礎
基于上一章節，我們已經對需求的概念等知識有了基本的認識，本節內容將更為詳細的講解需求到底是個什么東西
3.1需求的類型
3.1.1需求的層次性（需求的三個層次）
按照層次來分類，需求主要分為業務需求、用戶需求、系統需求三個部分
3.1.1.1業務需求
業務需求主要來源于決策者
是系統的目標和效益
主要表現為系統的解決方案和系統特性
論述為什么開發軟件或者系統（why）
形成的文檔為 前景和范圍文檔 （非常重要）
3.1.1.2用戶需求
用戶需求的主要來源是用戶
是系統需要提供的具體任務
主要表現為問題域的知識
描述用戶使用系統都能做到些什么事（what）
形成的文檔為用例說明文檔 （非常重要）
3.1.1.2系統需求
系統需求主要來源于軟件開發者
是軟件系統的行為
主要表現為系統分析模型
描述開發人員如何設計具體的解決方案來實現用戶需求
形成需求規格說明文檔 （非常重要）
3.1.2嚴格意義上的軟件需求分類
嚴格意義上的軟件需求可以分為功能需求和非功能需求兩類
3.1.2.1功能需求
和系統主要工作相關的需求，即在不考慮物理約束的情況下，用戶希望系統所能夠執行的活動，這些活動可以幫助用戶完成任務
功能需求主要表現為系統和環境之間的行為交互
3.1.2.2非功能需求
1.性能需求
系統整體或系統組成部分應該擁有的性能特征
例如：速度、容量、吞吐量、載負、實時性、CPU使用率、內存使用率等。
2.質量屬性
系統完成工作的質量，即系統需要在一個“好的程度”上實現功能需求
例如：功能性、可靠性、可用性、可維護性、課移植性、效率等。
3.對外接口
系統和環境中其他系統之間需要建立的接口
包括硬件接口、軟件接口、數據庫接口等等。
4.約束
進行系統構造時需要遵守的約束、
例如：運行環境、相關標準、社會因素、編程語言、硬件設施、將來可能提出的要求等
3.2需求工程的路線（了解）
3.3優秀需求的特性
3.3.1完整性
不需要做更多的擴展就可以充分的說明用戶所需要的系統功能
每一個需求的描述都應該包含開發人員設計和實現這項功能需要的所有信息
系統應該允許被擴展
系統的調度算法應該允許被擴展。
3.3.2正確性（真實性）
真實的反映用戶的意圖
必須請需求的提出者予以==確認 ==
3.3.3可行性
由開發人員進行檢查
需要進行一定的分析和研究，而不是單純的憑借經驗和直覺
必要的時候要通過開發原型來加以驗證
不可行的需求被稱為不切實際的期望。
3.3.4必要性（精確性）
簡潔、清晰
確認每一項需求都是滿足用戶的業務需求所必需的。——不遺漏也不畫蛇添足，剛剛好。
3.3.5無歧義
每一項需求都應該有而且只能有一種解釋
定義一個可以共同理解的詞匯表（Glossary）
3.3.6可驗證
通過分析、檢查、模擬或者測試等方法能夠判斷需求是否被滿足
不可驗證的需求往往是因為描述模糊或者過于抽象，所以在進行需求的描述時要
4.需求工程過程
了解了需求的基本概念之后，接下來講講需求工程的主要過程
4.1需求工程過程
需求工程過程是系統開發當中需求開發活動的集成，它的模版是產生一個能夠在用戶環境下解決用戶業務問題的系統方案
需求工程的具體流程在需求工程的基本活動中已經講到過了
這里主要的流程上的區別就是加上了反饋的過程
在整個軟件工程體系中需求主要工程的過程描述如下圖所示
4.2需求工程的活動
將上一節講過的需求工程過程細化到每一步，逐步講解每一步都需要作什么
4.2.1需求獲取
需求獲取是從人、文檔或者環境當中獲取需求的過程
需求工程師必須要利用各種方法和技術來“發現”需求
需求獲取和需求分析是交織在一起的
在需求獲取的過程中由如下子活動：
收集背景資料
定義項目前景和范圍
選擇信息的來源
選擇獲取方法，執行獲取
記錄獲取結果
4.2.2需求分析
為問題定義出一個需求集合，這個集合能夠為問題界定一個有效的解決方案
需求分析主要由如下子活動
背景分析
確定系統邊界（用例圖，上下文圖）
需求建模（DFD數據流圖、ERD實體關系圖、STD狀態轉換圖，類圖等）
需求細化（用戶需求->系統需求）
確定優先級 （功能取舍；評估和調整適應需求，滿足市場和業務目標的變化）
需求協商（需求工程師發現需求沖突，組織用戶協商解決）
4.2.3需求規格說明
業務需求被寫入項目前景和范圍文檔
用戶需求被寫入用戶需求文檔（或者用例文檔）
系統需求被寫入需求規格說明
4.2.4需求驗證
執行驗證（同級評審、原型或模擬）
問題修正 （伴隨問題跟蹤）
4.2.5需求管理
建立和維護需求基線集 （版本控制，變更記錄）
建立需求跟蹤信息 （雙向：前向和后向）
進行變更控制（建立過程、策略，評估和落實）
4.3需求工程的并發和迭代性
理論上需求分析模型的復雜度應隨著獲取內容的逐漸積累而線性上升，事實上是總體上升趨勢中伴隨著間歇性的下降。下降的過程可以理解為知識重構過程。
即實際的需求開發過程是獲取-分析-重構的不斷交織和迭代的過程。
5.需求獲取概述
需求獲取是確定和理解不用用戶類的需要和限制的過程，是軟件工程的主題
需求獲取階段主要產生的文檔：
1.前景和范圍文檔
2.用例說明文檔（假設需求分析時采用面向對象方法）
軟件需求或許是往往是非常困難且易出錯的，因此我們需要科學的分析方法來確定需求，這就是本節要描述的東西
5.1需求的非平凡性
5.1.1.用戶和開發人員的背景不同，立場不同
首先是知識理解的困難。
盡力去研究應用的背景，理解組織的狀況，形成一個能夠和用戶進行有效溝通的粗略的知識框架
默認（Tacit）知識現象
默認知識：表達著看來簡單認為不值得專門進行解釋或提及的知識。
**利用有效的獲取方法與技巧（角色扮演、觀察等）**來發現并獲取默認知識
5.1.2.普通用戶缺乏概括性、綜合性的表述能力
普通用戶的知識結構就相對局限于一些具體的業務細節
善于表達具體業務的細節問題
專家用戶的知識結構因其淵博性而具有概括性和廣泛性
能夠回答概括性和綜合性的問題
開發人員在與用戶接觸之前就先行確定獲取的內容主題，然后設計具體的應用環境和場景條件，由用戶根據細節業務的執行來描述問題、表達期望。
5.1.3.用戶存在認知困境
潛在（Latency）知識
發覺潛在知識，主動創造需求。
用戶越俎代庖
用戶提出的不是需求，而是解決方案
注意保持業務領域和解決方案的區分界限
用戶固執的堅持某些特征和功能
分析用戶的深層目的，找到隱藏在背后的需求
5.1.4.缺乏用戶參與
對系統的用戶以及用戶的替代源等相關涉眾進行分析
5.2需求獲取的過程（了解）
研究背景，創建初始框架
獲取問題，建立前景和范圍文檔
分析涉眾，選擇信息來源
確定獲取內容和主題，建立系統邊界，設置場景
采用適合的方法和技術進行獲取，分析用戶更高層次的目標，理解用戶意圖
記錄結果，寫出項目前景和范圍文檔
5.3需求獲取活動的要點
5.3.1獲取內容
1.需求
系統期望達到的目標，來源于用戶的觀點、看法、目標或者問題
2.問題域描述
現實世界的業務運行狀況
3.環境與約束
限制解系統部署的環境和條件
5.3.2獲取來源
5.3.2.1涉眾（主要講解涉眾分析的步驟）
涉眾的定義：所有能夠影響軟件系統的實現，或者會被實現后的軟件系統所影響的個人和團體。
常見的涉眾有：用戶、客戶、開發者、管理者、領域專家、政府力量、市場力量、維護人員
涉眾分析的概念：為系統找尋并理解關鍵涉眾的過程
在涉眾分析中，主要講解涉眾分析的步驟和每個步驟的需要注意的東西
涉眾識別（發現所有關鍵類別，識別方法）
涉眾類別的認為與外界交互活動屬于項目范圍，服務與系統目標（業務需求）
進行涉眾識別的過程中需要對涉眾類別進行細分，并且需要在涉眾群體中發現比較關鍵的涉眾，最后涉眾的群體不是一成不變的，應該在任務完成后保證適當的關注
涉眾的識別方法有一下三步：
1、先膨脹在收縮
2、檢查列表
3、涉眾網絡
涉眾描述
主要描述一下幾方面內容
涉眾、主要目標、態度、主要關注點、約束條件
涉眾評估
進行涉眾評估主要需要一下三個方面
優先級評估（重要性）
風險評估
共贏分析
優先級評估（重要性）——兩種方法 User/Task矩陣 和 power/interest分布圖
顧名思義，進行涉眾優先級評估的目的就是確定涉眾的優先級
具體有一下兩種操作的方法
User/Task矩陣
給出一個例子如下
用戶群體的數量級越大，目標涉眾的優先級越高
power/interest分布圖
由圖可以直觀的看出的看出參與者的優先級是最高的
風險評估 power/attribute分布圖
進行風險評估的目標是分析涉眾的態度，化解涉眾的風險
主要應用的評估方法是建立power/attribute分布圖
通過對不同風險涉眾的分析達到
化解涉眾風險策略 （合適的項目策略）
提高環境設定者提高關注度，向參與者轉化
消除強反對者的反對原因，將他們變為強支持者
共贏分析 Stakeholder/Issue關系圖
建立涉眾類別與所關注問題的關聯，進行沖突發現
如果涉眾所關注的問題與項目整體存在沖突，則需要調整折中，甚至重新進行可行性分析
進行共贏分析的主要方法是Stakeholder/Issue關系圖
如果某個Stakeholder-Issue關系上所寄予的期望與項目的業務需求無法保持一致，那么它關聯的涉眾就在該Issue的問題上和項目整體目標存在沖突
如果Stakeholder/Issue關系圖中某個Issue所關聯的不同關系標識有互相沖突的期望，那么就意味著它所關聯的涉眾在該Issue上存在需求沖突
涉眾代表選擇
對于涉眾的選擇我們應當盡量保證科學，減少采樣帶來的誤差
這里講解兩種常用的涉眾選擇方法
代表采樣（涉眾明確時，對于每種涉眾選擇合適的代表）
完整采樣: 每種涉眾類別都有自己的代表
態度積極: 愿意提供幫助
數量適中
太少 : 個人看法傾軋群體共同看法
太多: 達成一致困難
代表數量的準確數字要視項目的上下文環境來確定, 一般6-10
比例恰當（代表的個人特征保持恰當的比例分布）
計算機技能
業務技能
用戶替代源（涉眾不明確時，選擇與用戶聯系密切且有經驗的人作為涉眾代表）
因為業務關系而和用戶頻繁接觸的人 ，能夠代替他們發表看法
涉眾參與需求開發（軟件系統）的參與策略
事先安排好代表們的參與時間、強度和內容，讓代表們在合適的時間參與合適的工作
如果采用的是敏捷開發與極限編程，就需要用戶參與需求開發和軟件系統開發的整個過程
5.3.2.2硬數據
硬數據的定義：在研究現有系統時，需求工程師獲取事實，理解問題域所依賴的文檔資料。
定量硬數據
經過仔細設計、具有嚴格要求的格式化文檔。
例如：數據收集表格、統計報表
定性硬數據
定性的硬數據大都采用自然語言進行文本描述，利用起來代價較大
例如：整個組織的描述文檔、業務指導文檔、業務備忘
硬數據的采樣方法
1.隨機抽樣
隨機地采樣數據
2.分層抽樣
考慮系統的分層，從每一層中隨機抽取一個樣本
5.3.2.3相關產品
5.3.2.4重要文檔
5.3.2.5相關技術標準和法規
5.3.3獲取方法
傳統方法
問卷調查、面談、硬數據分析、文檔檢查、需求剝離等
集體獲取方法
頭腦風暴（Brainstorming）、專題討論會（Workshop）、聯合應用開發JAD、聯合需求計劃JRP等
原型
適用于需求模糊和不確定性較大的情況
模型驅動方法
定義明確的模型，確定所收集的信息類型，模型建立和完善的過程就是進行需求獲取的過程
面向目標的方法、基于場景的方法、基于用例的方法
認知方法
以認知的方式獲取用戶無法表達的潛在知識
任務分析（Task Analysis）、協議分析（Protocol Analysis）等
基于上下文的方法
通過分析用戶的行為得到信息
觀察、民族志（Ethnography）和話語分析（Conversation Analysis）
5.3.4獲取過程（了解）
5.3.4.1防止遺漏
務必讓所有的涉眾都表達出自己的意見。
不要以抽象和模糊的需求作為結束。對抽象和模糊的需求，要進行細化，讓真正的需求顯露出來。
使用多種方法表達需求信息。利用不同的分析技術為相同的需求進行建模，通過分析不同的關注點，考察需求是否完整。
注意檢查邊界值和布爾邏輯。
5.3.4.2結束獲取活動的判斷條件
用戶想不出更多的用例；
用戶想出的新用例都是導出用例（通過其他用例的結合可以推導出該用例）；
用戶只是在重復已經討論過的問題；
新提出的特性、需求等都在項目范圍之外；
新提出的需求優先級都很低；
用戶提出的新功能都屬于后繼版本，而非當前版本
5.3.5獲取結果
獲取筆錄、錄音錄像（Elicitation Notes）
用戶需求、問題域知識和約束
可能具有組織差、冗余、遺漏、自相矛盾等諸多問題
可以包括文字記錄、錄音、攝像等各種形式
正式文檔（項目前景和范圍文檔、用例文檔）
項目前景和范圍文檔
用例文檔
6.確定項目的前景和范圍
6.1確定項目前景和范圍的活動
1.定義項目前景文檔
描述產品是用來描述產品的作用，最終的功能。它使所有的涉眾都從共同認同的項目前景出發，理解和描述問題域及需求
2.定義項目范圍文檔
指出當前項目是要解決的產品是長遠規劃中的哪一部分。它為項目劃定了需求的界限
6.2問題分析
6.2.1明確問題
明確問題就是在不同涉眾之間對問題達成共識
要想明確一個問題首先必不可少的就是描述問題，只有將一個問題能夠描述的清楚才可以進行以下的步驟，明確完問題之后需要對問題的明確性進行分析，然后發現問題背后的問題
描述問題
描述問題是在涉眾之間獲取認同
主要使用如下表格的形式進行問題的描述
判斷問題的明確性
對于問題描述是否明確主要有一下兩種判斷因素
1、易于理解
2、能指明解決的方向
發現問題背后的問題
對于不明確的問題，我們直接咨詢涉眾是第一選擇，利用收集的資料和業務數據是第二選擇，必要時需要使用一些簡單的問題分析技巧
發現問題背后的問題當然還包括發現問題更深層次的問題
我們可以使用魚骨圖列出所有可能的原因，然后請用戶確認
如果用戶無法確定則搜集數據構建帕累托圖進行分析
6.2.2發現業務需求
每一個明確、一致的問題都意味著涉眾存在一些相應的期望目標，即業務需求。
我們需要用一個標準化格式來定義業務需求
6.2.3定義解決方案及系統特性
確定高層次的解決方案
確定高層次的解決方案的思想是發現各種可行的高層次解決方案，分析不同方案的業務優勢和代價，然后通過和涉眾的協商，選定其中一個
描述方式為
確定系統特性和解決方案的邊界
系統特性的定義：解決方案需要具備的功能特征，即系統特性，即滿足解決方案的系統應當具備哪些功能。
特性：
對一系列內聚的相互關聯的需求、領域特征和規格的總稱。
通常，一個特性內聚于一個目標與任務，反映了系統與外界一次有價值的完整互動過程。
確定解決方案的約束
解決方案的約束影響設計師、程序員等后續開發者的工作決策，需要重視又被忽視的因素
約束主要有一下幾種
6.3建立系統邊界
系統邊界的定義是系統與環境交互的界限
定義系統邊界的意義是可以明確系統需要滿足的與外界的交互行為，從而從宏觀上界定了系統的功能概要。
得到系統邊界的方法是將所有問題的解決方案進行綜合，就可以得到整個解系統的功能和邊界
6.3.1面向對象——用例圖
6.3.2結構化——上下文圖
6.4項目前景和范圍文檔
內容：業務需求、高層次解決方案和系統特性
撰寫人：需求工程師
文檔負責人：投資負責人、執行主管或其他類似角色
結構：
7.面談
顧名思義，面談就是面對面交談，是獲取需求的重要方法之一
7.1面談中的問題
7.1.1問題的類型
開放式問題
被會見者對答復的選擇可以是開放和不受限制的
適用于面談的前期
優點：
讓被會見者感到自在；
會見者可以收集被會見者使用的詞匯，這能反應他的教育、價值標準、態度和信念；
提供豐富的細節；
對沒采用的進一步的提問有啟迪作用；
讓被會見者更感興趣；
容許更多的自發性；
會見者可以在沒有太多準備的情況下進行面談。
缺點：
提此類問題可能會產生太多不相干的細節；
面談可能失控；
開放式的回答會花費大量的時間才能獲得有用的信息量；
可能會使會見者看上去沒有準備。
封閉式問題
答案有基本的形式，被會見者的回答是受到限制的
適用于面談的后期
優點：
節省時間；
切中要點；
保持對面談的控制；
快速探討大范圍問題；
得到貼切的數據
缺點：
使得被會見者厭煩；
得不到豐富的細節；
出于上述原因，失去主要思想；
不能建立和面談者的友好關系。
其他類型的問題
（1）探究式問題：目的是深究答復
為什么？
你能舉個例子嗎？
你能詳細描述一下嗎？
（2）誘導性問題：引導被會見者按會見者所想來回答，答復有偏向性
“你和其他經理一樣，都同意把財產管理計算機化，是嗎”
（3）雙筒問題：一個問題包含兩個獨立的內容，效果差
“每天你通常會做什么決策，你是怎樣做的？”
（4）元問題：關于面談本身的問題，對實施需求有很大幫助
我的問題看起來相關嗎？
你的回答正式嗎？
你是回答這些問題的最佳人選嗎？
我問了太多的問題嗎？
我還應該見什么人？
7.1.2問題的組織
金字塔型
漏斗型
菱型
7.2面談的過程
7.2.1準備面談
閱讀背景資料
確定面談主題和目標
選擇被會見者
準備被會見者
確定問題和類型
7.2.2主持面談
記錄的內容：
（1）事實和問題（主要）
（2）被會見人的觀點
（3）被會見者的感受
（4）組織和個人目標
記錄的方式
（1）筆錄
（2）錄音和攝像
7.2.3處理面談結果
復查面談記錄
整理出內容要點，進行分類
總結面談信息
評估面談中所得到的信息
完成面談報告
7.3面談的類型
7.3.1結構化面談
安全按照事先的問題和結構來控制面談
7.3.2半結構化面談
事先需要根據面談內容準備面談的問題和面談結構，但在面談過程當中，會見者可以根據實際情況采取一些靈活的策略
7.3.3非結構化面談
沒有事先預定的情況下就開展某個主題的面談
甚至會在沒有太多事前準備的情況下就直接到訪被會見者的工作地，就某個主題開展會談
會見者和被會見者談話的主題可能非常廣泛，而且每個主題都不會非常深入
也可能在非結構面談中僅就某個特殊的主題進行深入的討論
7.4面談的優點和局限
優點
開展條件較為簡單，經濟成本低
獲取信息廣泛，能獲得包括事實、問題、被會見者觀點、被會見者態度和被會見者信仰等
容易建立好友關系，需求工程師可以和涉眾（尤其是用戶）建立相互之間的友好關系
提高涉眾的項目參與熱情。通過參與面談，被會見者會產生一種主動為項目做出貢獻的感覺
局限
面談比較耗時，時間成本較高
地理位置分散難以實現
需求工程師壓力比較大，面談的成功較高的依賴于需求工程師的人際交流能力
在會見者不了解的情況下難以開展
8.原型
幫助需求工程師及早解決需求的不確定性：
創新性產品，它們的基本需求是潛在的，有著很大的不確定性；
產品的用戶對相關類別的產品沒有經驗，產品的細節需求存在著不確定性；
用戶在完成工作的方式上仍然存在障礙，產品在整體方案的可行性上存在著不確定性；
用戶在清晰說明他們的需求方面存在困難，這些相關的需求是有著不確定性的需求；
需求工程師在理解用戶的需求上存在困難，在澄清和理解之前，這些需求存在著不確定性；
需求的可行性值得懷疑，即具體需求的可滿足性存在著不確定性。
8.1應用原型的必要性
概念：原型是一個系統，它內化了（capture）一個更遲系統（later system）的本質特征
描述原型的方式包括書面描繪、場景敘述、情節串聯圖板、幻燈演示、動畫模擬、屏幕快照和程序代碼等
原型的優點：
及時、有力的響應用戶需求的變化；
減少返工；
幫助控制不完整需求所帶來的風險；
可以將一個大的難以處理的開發過程細分成一些更小更容易處理的步驟；
減少開發成本，提高經濟效益；
增加開發者之間的交流，幫助確定技術解決方案的可行性；
有效的識別風險和解決風險，幫助進行風險管理；
提高用戶在軟件開發中的參與程度。
8.2原型的類別
8.2.1按照使用方式分類
(1)演示原型（presentation prototype），如Demo
主要被用在啟動項目階段
目的是讓用戶相信應用系統的開發是可行的
(2)嚴格意義上的原型（prototype proper）
主要被用在需求分析階段
用來闡明用戶界面或者系統功能的某些特定方面
(3)試驗原型（breadboard prototype）
主要被用在構建系統階段
幫助開發者澄清他們所面對的一些和系統構建相關的技術問題
(4)引示系統原型（pilot system prototype）
會被用在系統開發的各個階段
用作最終系統的構建核心，在后續的開發中被不斷增強
8.2.2按照開發方式分類
1.探索式（exploratory） 開發的原型為廢棄式原型
以缺陷需求開始繼而不斷調整和修正需求的原型開發方式
需求不確定程度高，且不確定方面來自于需求方面
2.實驗式（experimental） 開發的原型為拋棄式原型
以清晰的用戶需求和模糊的實現方法、實現效果、可行性開始，明確需求的可行性和技術實現方案
需求不確定程度高，且不確定方面來自于技術細節方面
3.演化式（evolutionary） 開發的原型為演化式式原型
以清晰的原型化需求和項目積累下來的原型資產為開始被不斷傳遞和不斷增強的原型資產將成為最終的軟件系統
需求不確定程度低
8.2.3按照構建技術分類
水平原型方法（horizontal prototyping）
它僅僅實現選定功能所有層次中的某些特定層次
要把注意力集中在概括性需求和工作流問題上，處理范圍較大，但并未實現所涵蓋的功能
需求獲取水平原型關注的常見層次：人機交互、功能與任務和實現。
1.人機交互關注用戶使用時的感覺體驗。重點在于原型的界面外觀。
2.功能與任務原型關注用戶的任務。原型能帶來哪些工作與任務。
3.實現原型關注特定功能實現的技術細節。原型開發的功能實現方法，驗證方法技術的可行性和觀察用戶對原型的反應。
垂直原型方法（vertical prototyping）
它會觸及到選定功能實現的所有層次
要保證真實實現它的各種功能，考慮所有技術細節
8.2.4按照介質分類
8.2.5按照表現分類
故事版是交互性介于靜態畫面和動態程序之間的一種原型表現形式，它能夠表現場景式的互動。
8.3原型方法過程
（1）確定原型需求
為什么開發原型，擁有的起點是什么？期望的結束標準是什么？
（2）原型開發
依據原型的需求特點和開發目的，以最低的成本建立初始原型
（3）原型評估
對上一階段原型進行評估，根據評估者的反饋判斷原型是否滿足結束標準。評估者一般是用戶和開發者
（4）原型修正
如果已經建立的原型達到了目的，就結束原型方法的過程；否則根據評估者反饋的不足進行原型調整，調整完成后準備再次進行原型評估。
8.4原型方法的風險
缺點：復雜性使它在減少風險的同時也引入了新的風險
1.最大的風險是成本失控。原型開發工作投入太多的工作，使得開發團隊消耗了過多的時間和過大的成本 。
2.第二個風險是給客戶造成錯誤印象。涉眾看到了一個正在運行的原型，得出產品幾乎已經完成的結論，從而提出快速交付產品的不當要求。
3.用戶過多關注原型的非功能需求，容易忽略功能特性
4.可能會掩蓋一些用戶假設，這些將會無從發現。
9.觀察和文檔審查
9.1觀察的情境適用性
常見的觀察方法
（1）采樣觀察：傳統、簡單的方法，它根據明確的目的選取特定的時間段或特定的事件進行觀察。
（2）民族志：長期、浸入式的觀察方法。
（3）話語分析：對用戶之間的交談行為的觀察。觀察和分析交談中的交互方式或特定話語形式的內部結構來發現和獲取信息
（4）協議分析：對用戶任務的觀察。要求觀察對象一邊執行任務，一邊大聲解釋執行任務時產生的各種想法。
（5）任務分析：專門針對人機交互行為進行的觀察。
觀察的情境性（了解）
情景性：某些事件與具體環境聯系起來才能被理解。
情景性的重要性質：
1.突現——事件是集體成員集體促成的，所以需要將所有的成員互動聯系起來才能理解這些事件。
2.局部——事件及其解釋只有在特定的上下文環境下才能得以成立。
3.暫時——對事件的解釋會受到活動演進過程的影響，用戶的解釋可能僅僅是對以前類似事件的解釋。
4.涉身——特定的參與者對周圍環境的感知方式會從根本上影響事件的解釋。
5.開放——僅僅依據現有信息無法在總體上對事件的原理給出一個最終和完整的解釋。用戶無法對事件形成全面和準確的解釋，對事件的解釋保持開放，從而可以進一步進行完善。
6.模糊——對事件的解釋往往不能至及其精確的程度，而是基于一些潛在的知識進行展開。
9.2觀察方法的應用
9.2.1采樣觀察
9.2.2民族志
優點
能夠得到信息的深度理解
能夠讓真實世界的社會性因素可見化
打破人們已有的一些錯誤假設和錯誤觀念
缺點
耗時
調研結果很難傳遞到開發過程，抽取知識困難
注意事項
應該定期的記錄發現
盡快的記錄可能會在觀察過程中發生的面談
定期的復查和更新自己的想法
海量數據的應對策略 （總結，索引，分類）
9.3文檔審查方法的應用
文檔審查是傳統的專門針對文檔進行的需求獲取活動。
它的主要獲取對象包括相關產品（原有產品或競爭產品）的需求規格說明、硬數據和客戶的需求文檔（委托開發的規格說明、招標書）
10.需求分析概述
10.1需求分析的根本任務
10.1.1建立分析模型
建立分析模型的目標：達成開發者和用戶對需求信息的共同理解
建立分析模型包括：
分解系統，抽象出本質
達成信息的共同理解
分析的活動主要包括識別、定義和結構化
10.1.1.1模型
模型的概念：模型是對事物的抽象，是對系統進行思考和推理的一種方式
建模的目標：建立系統的一個表示，這個表示以精確一致的方式描述系統，使得系統的使用更加容易
建立模型的方法
抽象：找到本質特征
分解：簡化降低復雜性
投影：模型描述（多視點方法）
視點：將系統中既交織共存又相對獨立的不同內容拆解成不同的組成部分。每一個視點都是獨立的模型存在，用獨立的模型語言和表述方法來進行描述
多視點：所有視點的模型描述集成起來，就是對原有復雜系統的模型描述
建立模型的好處
降低應用的復雜性；
更深刻的理解信息；
更好的記憶細節；
更好的與其他開發人員進行交流；
更好的與用戶以及其他涉眾進行交流；
為維護和升級提供文檔
10.1.1.2兩個世界與三種模型
兩個世界：現實世界和計算世界
計算模型（不是個需求建模）
特征：基于計算科學建立的，具有形式化的特征，信息的描述具有明確化、準確化和確定化的特征
不適合需求建模的原因：
缺乏和軟件實現相關的技術細節
用戶無法理解
業務模型（不適合需求建模）
特征：使用了業務描述的方式，具有非形式化特征
不適合需求建模的原因：
業務模型元素的選取和定義上具有不準確、不確定和模糊化的特征
分析模型（適合做需求建模）
特征：
介于計算模型和業務模型二者之間的模型形式
使用了計算模型的組元形式
在組元的表現上采用了業務模型的表現方式
適合原因：
不像計算模型那么嚴謹
比業務模型更嚴格
10.1.1.3模型的表述
三要素
語法：使用規則——怎樣使用模型的元素，并且以什么方式組織、連接或關聯這些元素；
語義：特定模型元素所具有的含義；
語用：模型元素的上下文，以及影響該模型元素意義的約束和假定
分析模型
語用復雜
語義豐富
語法嚴格同時又不太復雜
需求建模
先依據獲取的問題域信息建立初步的模型。
然后分析用戶需求，對模型進行調整，得到一個中間形式的模型形式。
對調整后的模型進行邏輯推理和驗證，如果符合預期的期望，那么它就是最終的解決方案模型。
需求分析和目標
10.1.2建立解決方案
集中關注問題的計算特性（數據、功能、規則）
10.2需求分析技術
結構化技術
數據建模
實體關系圖(ERD)Entity Relationship Diagram
過程建模
數據流圖(DFD)Data Flow Diagram
上下文圖Context Diagram
微規格說明Mini-Specification
數據字典Data Dictionary
行為建模
狀態(轉換)圖/矩陣State (Transition) Diagram/Matrix
過程/數據關系建模
功能實體矩陣Function/Entity Matrix
信息工程方法
功能分解圖Function Decomposition Diagram
過程依賴圖Process Dependency Diagram
面向對象技術
用例圖Use-Case Diagram
活動圖Activity Diagram
類圖Class Diagram
狀態圖State Chart Diagram
交互圖（順序圖/通信圖）Interaction（Sequence / Communication）Diagram
對象約束語言Object Constraint Language
綜合運行需求分析技術
如何為各個視角選擇需求分析技術？
每一種需求分析技術都有自己的特點，具有在應用上的獨特性
如何實現它們之間的配合？
只有通過多種需求分析技術的有機結合與集成才能充分的描述復雜應用
10.3需求分析方法
傳統分析(1950’s)
沒有固定方法
缺乏結構、不可重復、不可測量,冗長、混亂、偏頗、無結構
結構化分析(late 1980’s)
傳統結構化分析 (late 1960’s),現代結構化分析 (late 1970’s)
以數據流動為中心，以DFD為核心技術，輔助ERD…
信息工程 (late 1980’s)
以數據知識結構為基礎，ERD為核心技術，輔助DFD，STD, FDD,…
面向對象分析(1990‘s)
以對象為中心，以UML（類圖）為核心技術
10.4前期需求階段的建模與分析
針對問題世界的分析和針對計算世界的分析
前期需求階段和后期需求階段
面向目標的分析（Goal Oriented Analysis）
通過關注前期需求階段—項目的前景與范圍定義活動進行目標分析
面向問題域的分析（Problem Domain Oriented Analysis）
面向問題域，關注問題的理解和建模
領域分析（Domain Analysis）
代價很高！！！！
領域分析的職責是發現、分析并定義可復用的需求。
領域：應用的集合
產品族：來自于同一應用領域并具有共性特征的產品。對產品的開發應當盡可能的實現復用。
產品線：以軟件復用為核心建立產品族的方法。
產品線的開發方法分為兩個部分：
領域工程與應用工程
領域工程負責分析、設計和建立可復用的軟件物件
應用工程以此為基礎，建立最終產品。
企業建模（Enterprise Modeling）
主要用來理解組織的結構、行為規則、目標、重要成員的任務與職責、操縱的數據等等。
企業建模利用企業的目標、任務、策略、資源等來刻畫組織的行為，并依此來發現組織開發系統的目的，建立系統的業務需求
10.5需求分析的活動
10.5.1前期需求分析的活動
以問題域為關注點的分析
包括的活動：背景分析；問題分析；目標分析；業務分析；確定系統邊界
10.5.2后期需求分析的活動
后期需求階段分析活動：發生在獲得需求信息之后的分析活動
包括的活動：需求建模；需求細化；確定需求優先級和需求協商
過程描述（了解）
需求細化
需求細化的根本：是將從問題域和業務任務角度描述的用戶需求轉換為從軟件和技術角度描述的系統級需求
細化內容：
（1）需要將用戶需求細化
用戶需求以任務為單位的，但一個任務完成可能需要多次交互。
（2）需要補充隱含因素
將從問題域信息補充到系統需求中，這些需要補充的信息就是隱含因素。
（3）非功能需求也需要隨著功能需求的細化而細化
（4）會發現新的細節需求
這些細節往往是用于約束和限定解決方案的手段。
（5） 在足夠具體時停止。
足夠具體意味著需求已經得到了充分的理解，并且開發者已經可以著手為其進行方案設計了。
需求的記錄：
標識符（ID），每一條需求都應該能夠通過ID唯一的標識自己。
源頭（Source），要能夠回溯到需求的源頭，例如特定的涉眾。
理由（Rational），需求被提出的目的。
優先級（Priority），詳細情況見下一節。
成本（Cost），預估的實現成本。
風險（Risk），實現該需求的過程中可能帶來的風險。
可變性（Volatility），將來發生變化的可能性。
確定需求的優先級
1.需要確定優先級的情況：
（1）一個項目的資源有限
（2）項目采用分階段的開發方式，第一階段應交付最重要和最緊急的需求
（3）項目的開始階段，無法明確和保證最終滿足所有用戶需求
2.確定優先級的常用方法
（1）累計投票：按需求得到的總分值確定優先級
（2）區域劃分：評價優先級的常見特征：
重要性。需求的不可或缺程度。
緊急性。需求的時間緊迫程度。
懲罰性。忽略需求會導致的懲罰程度。
成本。實現需求的代價。
風險。需求實現中可能產生的風險程度。
Top-N
每次迭代開始之前，由評價人選擇他們認為最重要的N個需求。N的取值是不受明確限制的，真正受限制的是Top-N個需求的實現代價總和。
需求協商
需求協商活動包括：對目標沖突的處理、對需求細節沖突的處理
關鍵：
涉眾之間的人際互動
需求協商三原則：
（1）明確沖突的因素，避免情緒上的沖突
（2）明確沖突的解決空間
（3）確定最佳解決方案
11.需求規格說明
11.1需求規格說明概述
需求獲取的目標是得到用戶的需求——收集需求信息
需求分析的目標是更深刻的理解用戶的需求——界定能夠讓用戶滿意的解決方案和準則
需求規格說明的目標是定義用戶的需求——準確描述其需求和解決方案
需求規格說明文檔的撰寫流程如下圖：
11.2需求規格說明文檔
編寫需求規格說明的必要性：
1.更好的傳遞軟件系統的需求信息和解決方案給所有的開發者
2.拓展人們的知識記憶能力
除必要性以外，編寫需求規格說明可以帶來的其他好處：
1.作為合同協議的重要部分
2.作為項目開發活動的一個重要依據
3.發現和減少可能的需求錯誤，減少項目的返工，降低項目的工作量
4.作為有效的智力資產
常見的需求說明文檔主要有以下幾種：
以上不同類型的文檔主要有一下區別：
需求文檔的名稱不同
需求文檔的內容不同
需求文檔內容的組織方式不同
需求文檔內容的表達方式不同
需求文檔的用途和作用不同
在聯系需求時使用的輔助性文檔不同
項目的前景和范圍文檔被視為屬于用戶的文檔，主要包括的內容有問題域信息、解決方案、需求，內容較為抽象，具有概括性的特點
招標活動是基于用戶需求文檔進行的
大多數系統開發項目都是以系統需求規格說明文檔為基礎簽約的
軟件需求規格說明文檔是對整個系統功能分配給軟件部分的詳細描述。
對系統規格說明的細化和詳細說明會產生軟件需求規格說明文檔、硬件需求規格說明文檔、接口需求規格說明文檔和人機交互文檔，都是開發文檔。
需求規格文檔的作者和讀者有：項目管理者、設計人員和程序員、測試人員、文檔編寫人員、維護人員、培訓人員、律師
典型開發活動片段：
信息描述語言的3種類別：
非形式化（文本為主）
半形式化（圖形為主）
形式化（數學公式為主）
11.3模版的選擇與裁剪
11.4文檔寫作技巧
指導原則：
寫作是一門藝術
文檔化的目標是交流
內容組織：
所有內容位置得當
引用或強化，但不重復
表達方式：
形式依賴于內容
使用系統的表達方式
細節描述：
定義術語表或數據字典時應避免的問題有
術語不一致
“方言”問題
錯誤術語和冗余術語
避免干擾文本
避免歧義詞匯
11.5優秀需求規格說明文檔的特性
完備性
標準（當且僅當）
描述了用戶的所有有意義的需求，包括功能、性能、約束、質量屬性和對外接口。
每一條需求都是完備的。
定義了軟件對所有情況的所有實際輸入（無論有效輸入還是無效輸入）的響應。
為文檔中的所有插圖、圖、表和術語、度量單位的定義提供了完整的引用和標記。
正確的前景和范圍
一致性
細節的需求不能同高層次的需求相沖突，例如系統需求不能和業務需求、用戶需求互相矛盾
同一層次的不同需求之間也不能互相沖突
根據重要性和穩定性分級
建立需求的優先級
可修改
標準
它的結構和風格使得人們可以對其中任一需求進行容易地、完整地、一致地修改，同時還不會影響文檔現有的結構和風格
文檔的可修改性要求：
有著條理分明并且易于使用的組織方式，包括目錄、索引和顯式的交叉引用。
沒有重復冗余。
獨立表達每個需求，而不是和其他需求混在一起。
可跟蹤
標準
它包含的每個需求的來源是清晰的，并且存在一種機制使在未來的開發工作中引用該需求是可行的。
分為：
1.后向跟蹤（Backward traceability）
能找到需求的來源，例如和更早期文檔的顯式關聯。
2.前向跟蹤（Forward traceability）
能找到需求所對應的設計單元、實現源代碼和測試用例等，它要求每個需求都要有唯一的標識或者可供引用的名稱
11.6需求規格說明的實踐調查
不編寫正式的需求規格說明文檔的原因：
1.時間壓力，用非正式文檔替代
2.迭代式開發，每次迭代是完成本次需求的正式需求規格說明，最后在整合成完整版本
12.需求驗證
12.1驗證與確認
需求驗證主要有兩層含義：
1.驗證：正確得到需求
2.確認：得到正確的需求
1. 需求驗證：以正確的方式建立需求
需求集是正確的、完備的和一致的；
技術上是可解決的；
它們在現實世界中的滿足是可行的和可驗證的。
2.需求確認：建立的需求是正確的
每一條需求都是符合用戶原意的
系統驗證：正確的建立系統
系統能夠在預期的環境中正確的執行設定的功能。
系統確認：建立的系統是正確的
建立的系統是符合系統需求和系統設計的
驗證貫穿于整個軟件生命周期，靜態分析和測試的兩個主要手段
12.2需求驗證
需求驗證是專指在需求規格說明完成之后，對需求規格說明文檔進行的驗證活動
12.3需求驗證方法
12.3.1評審
由作者之外的其他人來檢查產品問題的方法
是主要的靜態分析手段
原則上，每一條需求都應該進行評審
12.3.2原型與模擬
用于靜態方法力所不及的復雜需求
涉及到復雜的動態行為時
成本較高
12.3.3開發測試用例
用于功能測試，測試用例可以盡早開發
為需求類開發測試用例也可以被看成一個有效的需求驗證方法
無法測試的需求并非絕對有問題
排斥性需求和全局非功能性需求通常無法定義測試用例
12.3.4用戶手冊編制
用戶手冊主要包含以下內容：
1.驗證功能需求：對軟件系統功能和實現的描述
2.驗證項目范圍：對系統沒有實現的功能的描述
3.驗證異常流程需求：問題和故障的解決
4.驗證環境與約束需求：系統的安裝和啟動
12.3.5利用跟蹤關系※
業務需求（系統特性）=>用戶需求（業務、任務）=>系統需求（分析模型）
逐步細化的關系
如果業務需求和用戶需求沒有得到后項需求（用戶需求和系統需求）的充分支持，那么軟件需求規格說明文檔就存在不完備的缺陷。軟件需求規格說明文檔描述的是系統級需求，被用來進行需求驗證
系統需求=>用戶需求=>業務需求
如果不能依據跟蹤關系找到一條系統需求的前項用戶需求和前項業務需求，那么該需求就屬于非必要的需求。
12.3.6自動化分析
在一致性、正確性方面，自動化的工具檢查一直是研究者的關注目標
強的限制前提：用形式化方法書寫軟件需求規格說明文檔
12.4問題修正※
1.需求澄清
（1）理解偏差：重新進行分析工作
（2）分析遺漏：重新分析和文檔化這部分信息
（3）表達不當：重新以合適的方式表達
2.發現缺失需求
重新執行需求獲取等一系列工作
3.解決需求沖突
協商解決
4.修正不切實際的期望
項目調整與需求協商
12.5需求驗證的實踐調查
需求驗證是重要的
需求驗證是容易被忽視的
需求驗證的方法是多樣的
評審和原型最為廣泛
13.需求管理
13.1需求管理
13.1.1需求管理意圖
需求的影響力
整個后續的產品生命周期 VS 需求開發階段
需求規格說明文檔
后續的開發工作都應該以軟件需求規格說明文檔的內容為標準和目標來進行
需求管理能夠做到
在需求開發之后的產品生命周期當中保證需求作用的有效發揮
保證軟件質量
13.1.2需求管理作用
（1）增強了項目涉眾對復雜產品特征在細節和相互依賴關系上的理解，將需求基線納入項目的知識管理
增強了項目涉眾對需求（尤其是復雜需求）的掌握。
（2）增進了項目涉眾之間的交流
減少了可能的誤解和交流偏差。
（3）減少了工作量的浪費，提高了生產力
需求管理能夠更加有效的處理需求的變更
（4）準確反映項目的狀態，幫助進行更好的項目決策
需求跟蹤信息能夠更加準確的反映項目的進展情況
（5）改變項目文化，使得需求的作用得到重視和有效發揮
使得項目涉眾認識到需求在項目工作中的重要性
13.1.3需求管理任務
交流涉眾需要什么；
將需求應用、實施到解決方案；
驅動設計和實現工作；
控制變更；
將需求分配到子系統；
測試和驗證最終產品；
控制迭代式開發中的變化；
輔助項目管理
13.1.4需求管理活動
13.2需求基線
是被明確和固定下來的需求集合，是項目團隊需要在某一特定產品版本中實現的特征和需求集合
需求基線的主要描述內容有軟件需求（需求基線的關鍵內容）+和軟件需求相關的描述信息，如：
標識符（ID），為后續的項目工作提供一個共同的交流參照。
當前版本號（Version），保證項目的各項工作都建立在最新的一致需求基礎之上。
源頭（Source），在需要進一步深入理解或者改變需求時，可以回溯到需求的源頭。
理由（Rational），提供需求產生的背景知識。
優先級（Priority），后續的項目工作可以參照優先級進行安排和調度。
狀態（Status），交流和具體需求相關的項目工作狀況。
成本、工作量、風險、可變性（Cost、Effort、Risk、Volatility），為需求的設計和實現提供參考信息，驅動設計和實現工作。
13.3需求跟蹤
主要目的是：避免在開發過程或者演化過程中與需求基線不一致或者偏離的風險
需求跟蹤是以軟件需求規格說明文檔為基線，在向前和向后兩個方向上，描述需求以及跟蹤需求變化的能力。
1.前向跟蹤是指被定義到軟件需求規格說明文檔之前的需求演化過程
向需求的跟蹤：說明涉眾的需要和目標產生了哪些軟件需求
從需求向后回溯：說明軟件需求來源于哪些涉眾的需要和目標
2.后向跟蹤是指被定義到軟件需求規格說明文檔之后的需求演化過程
從需求向后跟蹤：說明軟件需求是如何被后續的開發物件支持和實現的
向需求的回溯：說明各種系統開發的物件是因為什么原因（軟件需求）而被開發出來的
13.3.1用途
需求的后向跟蹤可以幫助項目管理者：
評估需求變更的影響；
盡早發現需求之間的沖突，避免未預料的產品延期；
可以收集沒有被實現的需求，并估算這些需求需要的工作量；
發現可以復用的已有組件，從而降低新系統開發的時間和精力；
明確需求的實現進度，跟蹤項目的狀態。
需求的后向跟蹤可以幫助客戶和用戶：
評價針對用戶需求的產品的質量；
可以確認成本上沒有（昂貴的）鍍金浪費；
確認驗收測試的有效性；
確信開發者的關注點始終保持在需求的實現上。
需求跟蹤中針對具體需求的設計方案選擇、設計假設條件以及設計結果等信息可以幫助設計人員：
驗證設計方案正確的滿足了需求；
評估需求變更對設計的影響；
在設計完成很久之后仍然可以理解設計的原始思路；
評估技術變化帶來的影響；
實現系統組件的復用；
需求跟蹤信息還可以幫助維護人員：
評估某一個需求變化時對其他需求的影響；
評估需求變化時對實現的影響；
評估未變化需求對實現變更的允許度。
13.4需求變更控制
需求的變化是正當和不可避免的，包括：
問題發生了改變
環境發生了改變
需求基線存在缺陷
13.5需求管理的實踐調查
13.5.1需求變更
變更發生的事件越遲，影響越大
新增（Added）需求影響最大——影響最大的變更類型
缺陷修復是最為頻繁的變更類型
范圍蔓延是常見的風險因素
13.5.2需求管理工具
通用的文本處理器（Word Processor）和電子表格（Spreadsheet）使用最為廣泛
總結
- 上一篇： setjmp与logjmp用法总结
- 下一篇： Node.js server使用