作者和來源：不詳
1 概述
需求是從系統外部能發現系統所具有的滿足於用戶的特點、功能及屬性等。需求是指明必須實現什麼的規格說明。它描述了系統的行爲、特性或屬性，是在開發過程中對系統的約束。
軟件需求工程劃分爲需求開發和需求管理，其中需求開發可進一步分爲問題獲取(elicitation)、分析(analysis)、編寫規格說明(specification)和驗證(verification)四個階段,
需求開發活動包括以下幾個方面：
(1) 確定產品所期望的用戶類
(2) 獲取每個用戶類的需求
(3) 瞭解實際用戶任務和目標以及這些任務所支持的業務需求
(4) 分析源於用戶的信息以區別用戶任務需求、功能需求、業務規則、質量屬性、建議解決方法和附加信息
(5) 將系統級的需求分爲幾個子系統，並將需求中的一部分分配給軟件組件
(6) 瞭解相關質量屬性的重要性
(7) 商討實施優先級的劃分
(8) 將所發現的用戶需求編寫成規格說明和用例模型
(9) 評審用例和需求規格說明，確保對用戶需求達到共同的理解與認識，並在整個開發小組接受說明之前將問題都弄清楚。
需求管理活動包括以下幾個方面：
(1) 定義需求基線(迅速制定需求文檔的主體)
(2) 評審提出的需求變更、評估每項變更的可能影響從而決定是否實施它
(3) 以一種可控制的方式將需求變更融入到項目中
(4) 使當前的項目計劃與需求一致
(5) 估計變更需求所產生的影響並在此基礎上協商新的承諾。
(6) 讓每項需求都能與其對應的設計、源代碼和測試用例聯繫起來以實現跟蹤
(7) 在整個項目過程中跟蹤需求狀態及其變更情況。
2 需求工程的推薦方法
需求工程推薦方法
|
需求管理
|
項目管理
|
|
l 確定變更控制過程
l 建立變更控制委員會
l 進行變更影響分析
l 跟蹤影響工作產品的每項變更
l 編寫需求文檔的基準版本和控制版本
l 維護變更歷史記錄
l 跟蹤需求狀態
l 衡量需求穩定性
l 使用需求管理工具
|
l 選擇合適的生存週期
l 確定需求基本計劃
l 協商約定
l 管理需求風險
|
需求開發
|
獲取
|
分析
|
編寫規格說明書
|
驗證
|
|
Ø 編寫前景
Ø 確定需求開發過程
Ø 用戶羣分類
Ø 選擇產品代表
Ø 確定用例
Ø 聯繫會議
Ø 分析用戶工作流程
Ø 確定質量屬性
Ø 檢查問題報告
Ø 需求重用
|
Ø 繪製關聯圖
Ø 創建開發原型
Ø 分析可行性
Ø 確定需求優先級
Ø 爲需求建立模型
Ø 編寫數據字典
Ø 應用質量功能調配
|
Ø 採用軟件需求規格說明模版
Ø 指明需求來源
Ø 爲每項需求註上標號
Ø 記錄業務範圍
Ø 創建需求跟蹤能力矩陣
|
Ø 審查需求文檔
Ø 依據需求編寫測試用例
Ø 確定合格標準
|
2.1 需求獲取
（1） 編寫前景文檔：前景文檔應該包括高層的產品業務目標，所有的用例和功能需求都必須遵從能達到的業務需求。項目前景文檔中的說明使所有項目參與者對項目的目標能達成共識。
（2） 確定用戶類：爲避免出現疏忽某一用戶羣需求的情況，要將可能使用產品的客戶分成不同組別。他們可能在使用頻率、使用特性、優先等級或熟練程度等方面都有所差異。詳細描述出它們的個性特點及任務狀況，將有助於產品設計
（3） 在每個用戶類中確定適當的代表：爲每類用戶至少選擇一位能真正代表他們需求的人作爲那一類用戶的代表並能作出決策。
（4） 運用需求獲取方法對系統的重要部分進行用例開發並設置優先級
（5） 確定用例：從用戶代表處收集他們使用軟件完成所需任務的描述，編寫用例，描述用戶與系統間的交互方式和對話要求。
（6） 召開應用程序開發聯繫會議：應用程序開發聯繫會議是範圍廣的、簡便的專題討論會，也是分析人員與客戶代表之間一種很好的合作辦法，可以在會上就已完成的工作或未完成的工作與客戶展開討論，並能由此擬出需求文檔的底稿。
（7） 分析用戶工作流程：觀察用戶執行業務任務的過程。畫一張簡單的示意圖（最好是數據流圖）來描繪用戶什麼時候獲得什麼數據，並怎樣使用這些數據。並與客戶討論此內容。
（8） 確定質量屬性和其它非功能需求：在功能需求之外再考慮一下非功能的質量特點。這些特點包括性能、有效性、可靠性、可用性等，而這些質量屬性上客戶提供的信息相對來說就非常重要了。
（9） 通過檢查當前系統的問題報告來進一步完善需求：客戶的問題報告及補充需求爲新產品或新版本提供了大量豐富的改進及增加特性的想法，負責提供用戶支持及幫助的人能爲需求過程提供極有價值的信息。
（10） 跨項目重用需求：如果客戶要求的功能與已有產品很相近，則可查看需求是否有足夠的靈活性以允許重用一些已有的軟件組件。
2.2 需求分析
需求分析（ requirement analysis）包括提煉、分析和仔細審查已收集到的需求，以確保所有的stakeholder 都明白其含義並找出其中的錯誤、遺漏或其它不足的地方。分析員通過評價來確定是否所有的用例和軟件需求規格說明都達到了優秀需求說明的要求。分析的目的在於開發出高質量和具體的需求，這樣你就能作出實用的項目估算並可以進行設計、構造和測試。
通常，把需求中的一部分用多種形式來描述，如同時用文本和圖形來描述。分析這些不
同的視圖將揭示出一些更深的問題，這是單一視圖無法提供的。分析還包括與客戶的交流以澄清某些易混淆的問題，並明確哪些需求更爲重要。其目的是確保所有stakeholder 儘早地對項目達成共識並對將來的產品有個相同而清晰的認識。
1)繪製系統關聯圖:這種關聯圖是用於定義系統與系統外部實體間的界限和接口的簡單
模型。同時它也明確了通過接口的信息流和物質流。
2) 創建用戶接口原型:當開發人員或用戶不能確定需求時，開發一個用戶接口原型—一
個可能的局部實現—這樣使得許多概念和可能發生的事更爲直觀明瞭。用戶通過評價原型
將使項目參與者能更好地相互理解所要解決的問題。注意要找出需求文檔與原型之間所有的
衝突之處。
3) 分析需求可行性:在允許的成本、性能要求下，分析每項需求實施的可行性，明確與
每項需求實現相聯繫的風險，包括與其它需求的衝突，對外界因素的依賴和技術障礙。
4) 確定需求的優先級別:應用分析方法來確定用例、產品特性或單項需求實現的優先級別。以優先級爲基礎確定產品版本將包括哪些特性或哪類需求。當允許需求變更時，在特定的版本中加入每一項變更，並在那個版本計劃中作出需要的變更。給每個需求建立優先級有助於解決衝突，安排階段交付，並且做出必要的取捨。需求的優先級可以設爲三類，①基本的－只有在這些需求上達成一致意見，軟件纔會被接收；②條件的－實現這些需求將增強產品的性能，但如果忽略這些需求，產品也是可以被接受的；③可選的－一個功能類，實現或不實現均可
5) 爲需求建立模型：需求的圖形分析模型是軟件需求規格說明極好的補充說明。它們能提供不同的信息與關係以有助於找到不正確的、不一致的、遺漏的和冗餘的需求。這樣的模型包括數據流圖、實體關係圖、狀態變換圖、對象類及交互作用圖。
6) 創建數據字典：數據字典是對系統用到的所有數據項和結構的定義，以確保開發人員
使用統一的數據定義。在需求階段，數據字典至少應定義客戶數據項以確保客戶與開發小組
是使用一致的定義和術語。數據字典可以用術語表代替。
2.3 需求規格說明
無論你的需求從何而來，也不管你是怎樣得到的，得到的形式是什麼，你都必須用一種統一的方式來將它們編寫成可視文檔。業務需求要寫成前景文檔。用戶需求要編成用例及用例規約和補充規約。而軟件需求規格說明（requirement specification）則包含了軟件的功能需求和非功能需求。
1) 採用S R S模板：在組織中要爲編寫軟件需求文檔定義一種標準模板。該模板爲記錄
功能需求和各種其它與需求相關的重要信息提供了統一的結構。模板是很有用的，但有時
要根據項目特點進行適當的改動。
2) 指明需求的來源：爲了讓所有stakeholder明白S R S中爲何提供這些功能需求，要都能追溯每項需求的來源，這可能是一種使用實例或其它客戶要求，也可能是某項更高層系統需求、業務規範、政府法規、標準或別的外部來源。
3) 爲每項需求註上標號:制定一種慣例來爲S R S中的每項需求提供一個獨立的可識別的標
號或記號。這種慣例應當很健全，允許增加、刪除和修改。作了標號的需求使得需求能被跟
蹤，記錄需求變更併爲需求狀態和變更活動建立度量。
4) 記錄業務規範:業務規範是指關於產品的操作原則，比如誰能在什麼情況下采取什麼動作。將這些編寫成S R S中的一個獨立部分，或一獨立的業務規範文檔。某些業務規範將引
出相應的功能需求；當然這些需求也應能追溯相應業務規範。
5) 創建需求跟蹤能力矩陣:建立一個矩陣把每項需求與實現、測試它的設計和代碼部分
聯繫起來。這樣的需求跟蹤能力矩陣同時也把功能需求和高層的需求及其它相關需求聯繫起
來了。
2.4 需求驗證
驗證是爲了確保需求說明準確、完整地表達必要的質量特點。當你閱讀軟件需求規格說
明（S R S）時，可能覺得需求是對的，但實現時，卻很可能會出現問題。當以需求說明爲依據編寫測試用例時，你可能會發現說明中的二義性。而所有這些都必須改善，因爲需求說明要作爲設計和最終系統驗證的依據。客戶的參與在需求驗證（ requirement verification）中佔有重要的位置。
1) 審查需求文檔:對需求文檔進行正式審查是保證軟件質量的很有效的方法。組織一個
由不同代表（如分析人員，客戶，設計人員，測試人員）組成的小組，對S R S及相關模型進行仔細的檢查。另外在需求開發期間所做的非正式評審也是有所裨益的。
2) 以需求爲依據編寫測試用例:根據用戶需求所要求的產品特性寫出黑盒功能測試用例。
客戶通過使用測試用例以確認是否達到了期望的要求。還要從測試用例追溯回功能需求以確
保沒有需求被疏忽，並且確保所有測試結果與測試用例相一致。同時，要使用測試用例來驗
證需求模型的正確性，如對話框圖和原型等。
3) 確定合格的標準:讓用戶描述什麼樣的產品纔算滿足他們的要求和適合他們使用的。
將合格的測試建立在使用情景描述或使用用例的基礎之上
2.5 需求管理
當你完成需求說明之後，不可避免地還會遇到項目需求的變更。有效的變更管理需要對
變更帶來的潛在影響及可能的成本費用進行評估。變更控制委員會與關鍵的項目風險承擔者
要進行協商，以確定哪些需求可以變更。同時，無論是在開發階段還是在系統測試階段，還
應跟蹤每項需求的狀態。建立起良好的配置管理方法是進行有效需求管理（ requirement management）的先決條件。
可以使用版本控制和其它管理配置技術來管理代碼和文檔，
1) 確定需求變更控制過程：確定一個選擇、分析和決策需求變更的過程。所有的需求變
更都需遵循此過程，商業化的問題跟蹤工具都能支持變更控制過程。
2) 建立變更控制委員會：組織一個由項目風險承擔者組成的小組作爲變更控制委員會，
由他們來確定進行哪些需求變更，此變更是否在項目範圍內，估價它們，並對此評估作出決
策以確定選擇哪些，放棄哪些，並設置實現的優先順序，制定目標版本。
3) 進行需求變更影響分析：應評估每項選擇的需求變更，以確定它對項目計劃安排和其
它需求的影響。明確與變更相關的任務並評估完成這些任務需要的工作量。通過這些分析將
有助於變更控制委員會作出更好的決策。
4) 跟蹤所有受需求變更影響的工作產品：當進行某項需求變更時，參照需求跟蹤能力矩陣
找到相關的其它需求、設計模板、源代碼和測試用例，這些相關部分可能也需要修改。這樣能減少因疏忽而不得不變更產品的機會，這種變更在變更需求的情況下是必須進行的。
5) 建立需求基準版本和需求控制版本文檔：確定一個需求基準，這是一致性需求在特定
時刻的快照。之後的需求變更就遵循變更控制過程即可。每個版本的需求規格說明都必須是
獨立說明，以避免將底稿和基準或新舊版本相混淆。最好的辦法是使用合適的配置管理工具
在版本控制下爲需求文檔定位。
6) 維護需求變更的歷史記錄：記錄變更需求文檔版本的日期以及所做的變更、原因，還
包括由誰負責更新和更新的新版本號等。
7) 跟蹤每項需求的狀態：建立一個數據庫，其中每一條記錄保存一項功能需求。保存每
項功能需求的重要屬性，它包括狀態（如已推薦的，已通過的，已實施的，或已驗證的），這樣在任何時候都能得到每個狀態類的需求數量。
8) 衡量需求穩定性：記錄基準需求的數量和每週或每月的變更（添加、修改、刪除）數
量。過多的需求變更“是一個報警信號”，意味着問題並未真正弄清楚，項目範圍並未很好地確定下來或是政策變化較大。
9) 使用需求管理工具：商業化的需求管理工具能幫助在數據庫中存儲不同類型的需求，爲每項需求確定屬性，可跟蹤其狀態，並在需求與其它軟件開發工作產品間建立跟蹤能力聯繫鏈。
2.6 項目管理
軟件工程管理方法在本質上與項目的需求過程是緊密相關的。項目計劃建立在功能基礎之上，而需求變更會影響這些計劃。因此，項目計劃應能允許一定程度的需求變更或項目範
圍的擴展。如果剛開始，需求不能確定，可以選擇一種軟件開發方法生存週期以允許這種
不確定性，並在弄清後逐漸實施。
1) 選擇一種合適的軟件開發方法生存週期：如果需求說明在項目早期無法全部確定，則從
最爲清晰易懂的需求開始，建立一個健壯的可修改的結構，再逐漸增加補充。實現了部分特
性的產品可作爲早期版本發佈。
2) 基於需求的項目計劃：隨着需求細節不斷變得清晰、完善，項目開發計劃的進度安排
將會不斷改變。一開始可以根據前景對開發功能需求所需的工作量作一個估算，建立在不甚完善的需求基礎之上的成本、進度安排的估計很不可靠，但隨着需求說明的完善，估計也會得到不斷改善。
3) 發生需求變更時協商項目約定：當在項目中添加新的需求時，估計一下你是否能在目
前安排下，利用現有資源保質保量完成。如果不能，將項目的實現與管理聯繫起來，協商一
下新的、切實可行的約定。如果協商不成功則將可能的後果和更新項目風險管理計劃聯繫起來，以反映出對項目成功的新的不利因素。
4) 編寫文檔和管理與需求相關的風險：採用自由討論的方法並將與需求相關的項目風險
編寫成文檔。利用各種方法來減輕或阻止這些風險，實施這些方法並跟蹤其發展及效果。
3 與需求有關的風險
下面介紹的風險因素是按需求工程中獲取、分析、編寫規格說明、驗證和管理彙總起來
的，並推薦了一些方法用於降低風險發生的可能性或減輕風險發生給項目帶來的影響。
3.1 需求獲取
1) 前景：如果團隊成員沒有對他們要做的產品功能達成一個清晰的共識，則很可能導致項目範圍的逐漸擴大。因此最好在項目早期寫一份項目前景文檔將業務需求涵蓋在內，並將其作爲新的需求及修改需求的指導。
2) 需求開發所需時間：緊張的工程進度安排給管理者造成很大的壓力，使他們覺得不趕緊開始編碼將無法按時完成項目，因而對需求一帶而過。項目因其規模和應用種類不同（如
信息系統，系統軟件，商業的或軍事的應用）而有着很大的不同。粗略的統計表明：需求開
發工作應占全部工作量的1 5 %。記錄你參與的每個項目中實際需求開發的工作量，這樣就能知道所花的時間是否合適並改進將來項目的工作計劃。
3) 需求規格說明的完整性和正確性：爲確保需求是客戶真正需要的，要以用戶的任務爲中心，應用用例獲取需求。根據不同的使用情景編寫需求用例，建立原型，使需求對用戶來說更加直觀，同時獲取用戶的反饋信息。讓客戶代表對需求規格說明和分析模型進行正式的評審。
4) 對革新產品的需求：有時容易忽略市場對產品的反饋信息。故要強調市場調查研究，建立原型，並運用客戶核心小組來獲得革新產品任務的反饋信息。
5) 明確非功能需求：由於一般強調產品的功能性要求，非常容易忽略產品的非功能性的需求。詢問客戶關於產品性能、使用性、完整性、可靠性等質量特性，編寫非功能需求文檔
和驗收標準，（像在S R S中一樣）作爲可接受的標準。
6) 客戶贊同產品需求：如果不同的客戶對產品有不同的意見，那最後必將有些客戶會不
滿意。確定出主要的客戶，並採用產品代表的方法來確保客戶代表的積極參與，確保在需求
決定權上有正確的人選。
7) 未加說明的需求：客戶可能會有一些隱含的期望要求，但並未說明。要儘量識別並記
錄這些假設。提出大量的問題來提示客戶以充分表達他們的想法、主意和應關注的一切。
8) 把已有的產品作爲需求基線：在升級或重做的項目中需求開發可能顯得不很重要。開
發人員有時被迫把已有的產品作爲需求說明的來源。“只是修改一些錯誤和增加一些新特性”，這時的開發人員不得不通過現有產品的逆向工程(reverse engineering)來獲取需求。可是，逆向工程對收集需求是一種既不充分也不完整的方法。因此新系統很可能會有一些與現有系統同樣的缺陷。將在逆向工程中收集的需求編寫成文檔，並讓客戶評審以確保其正確性。
9) 給出期望的解決辦法：用戶推薦的解決方法往往掩蓋了用戶的實際需求，導致業務處
理的低效，或者給開發人員帶來壓力以至做出很差的設計方案。因此分析人員應盡力從客戶
敘說的解決方法中提煉出其本質核心。
3.2 需求分析
1) 劃分需求優先級：劃分出每項需求、特性或使用實例的優先級並安排在特定的產品版
本或實現步驟中。評估每項新需求的優先級並與已有的工作主體相對比以做出相應的決策。
2) 帶來技術困難的特性：分析每項需求的可行性以確定是否能按計劃實現。成功好象總是懸於一線的，應該運用項目狀態跟蹤的辦法管理那些落後於計劃安排的需求，並儘早採取
措施糾正。
3) 不熟悉的技術、方法、語言、工具或硬件平臺：不要低估了學習曲線中表明的滿足某項需求所需要的新技術的速度跟進情況。明確那些高風險的需求並留出一段充裕時間從錯誤
中學習、實驗及測試原型。
3.3 需求規格說明
1) 需求理解開發人員和客戶對需求的不同理解會帶來彼此間的期望差異，將導致最終產品無法滿足客戶的要求。對需求文檔進行正式評審的團隊應包括開發人員，測試人員和客戶。訓練有素且頗有經驗的需求分析人員能通過詢問客戶一些合適的問題，從而寫出更好的規格說明。模型和原型能從不同角度說明需求，這樣可使一些模糊的需求變得清晰。
2) 時間壓力對T B D的影響：將S R S中需要將來進一步解決的需求註上T B D記號，但如果這些T B D並未解決，則將給結構設計與項目的繼續進行帶來很大風險。因此應記錄解決每項T B D的負責人的名字，如何解決的以及解決的截止日期。
3) 具有二義性的術語：建立一本術語和數據字典，用於定義所有的業務和技術詞彙，以
防止它被不同的讀者理解爲不同的意思。特別是要說明清楚那些既有普通含義又有專用領域
含義的詞語。對S R S的評審能夠幫助參與者對關鍵術語、概念等達成一致的共識。
4) 需求說明中包括了設計：包含在S R S中的設計方法將對開發人員造成不必要的限制並妨
礙他們發揮創造性設計出最佳的方案。仔細評審需求說明以確保它是在強調解決業務問題需
要做什麼，而不是在說怎麼做。
3.4 需求驗證
1) 未經驗證的需求：審查相當篇幅的S R S是有些令人沮喪，正如要在開發過程早期編寫測
試用例一樣。但如果在構造設計開始之前通過驗證基於需求的測試計劃和原型測試來驗證需
求的正確性及其質量，就能大大減少項目後期的返工現象。在項目計劃中應爲這些保證質量
的活動預留時間並提供資源。從客戶代表方獲得參與需求評審的贊同（承諾），並儘早且以儘可能低的成本通過非正式的評審逐漸到正式評審來找出其存在的問題。
2) 審查的有效性：如果評審人員不懂得怎樣正確地評審需求文檔和怎樣做到有效評審，那麼很可能會遺留一些嚴重的問題。故要對參與需求文檔評審的所有團隊成員進行培訓，請
組織內部有經驗的評審專家或外界的諮詢顧問來講課、授教以使評審工作更加有效。
3.5 需求管理
1) 變更需求：將前景文檔作爲變更的參照可以減少項目範圍的延伸。用戶積
極參與的具有良好合作精神的需求獲取過程可把需求變更減少近一半。能在早期發現需求錯誤的質量控制方法可以減少以後發生變更的可能。而爲了減少需求變更的影響，將那些易於變更的需求用多種方案實現，並在設計時更要注重其可修改性。
2) 需求變更過程：需求變更的風險來源於未曾明確的變更過程或採用的變動機制無效或不按計劃的過程來做出變更。應當在開發的各階層都建立變更管理的紀律和氛圍，當然這需
要時間。需求變更過程包括對變更的影響評估，提供決策的變更控制委員會，以及支持確定
重要起點步驟的工具。
3) 未實現的需求：需求跟蹤能力矩陣有助於避免在設計、結構建立及測試期間遺漏的任
何需求。也有助於確保不會因爲交流不充分而導致多個開發人員都未實現某項需求。
4) 擴充項目範圍：如果開始未很好定義需求，那麼很可能隔段時間就要擴充項目的範圍。
產品中未說明白的地方將耗費比預料中更多的工作量，而且按最初需求所分配好的項目資源
也可能不按實際更改後用戶的需求而調整。爲減少這些風險，要對階段遞增式的生存期制定
計劃，在早期版本中實現核心功能，並在以後的階段中逐步增加實現需求。
3.6 風險管理是你的好助手
項目管理人員可以運用風險管理來提高對造成項目損失的條件的警惕，在需求獲取階段
要有用戶的積極參與。精明的管理者不僅要能認識到它能帶來風險的條件，而且將它編入風險清單，並依據以往項目的經驗估計其可能性和影響。如果用戶一直沒有參與，風險危害值將會擴大以至危害項目的成功。週期性的風險跟蹤能使管理人員保持對風險危害變化的瞭解，對那些並未得到完全控制的風險能得到高層管理人員的注意。他們要麼開始採取一些修正措施，要麼不管風險，依舊按原業務決策思路進行。即使不能控制項目可能遇到的所有風險，風險管理也能使你看清形勢，做出的決策是有所依據。
