需求管理

需求管理（Requirement management）是完整管理模式中的一環，同其他特性諸如完整性、一致性等不可分割，彼此相關而成一體。一套需求管理應當是已知系統需求的完整體現，每部分解決方案都是對總體需求一定比例的滿足（甚至是充分滿足），僅僅解決部分需求是沒有意義的。對關鍵需求的疏忽很可能是災難性的，試想一架飛機的安全設計不過關將會帶來什麼樣的後果。不同的需求組合起來，構成了一套完整的需求模型。用戶需求決定了系統設計所要解決的問題，所要帶來的結果。可以說，需求管理指明了系統開發所要做和必須做的每一件事，指明了所有設計應該提供的功能和必然受到的制約。需求管理的過程，從需求獲取開始貫於整個項目生命周期，力圖實現最 終產品同需求的最佳結合。通過對需求管理在項目進程中實施的不同任務進行分析，我們可以看出需求管理所起的作用。

需求管理本就是一個動態的過程，離開了能動的、變化的系統進程而空談需求管理，無異於紙上談兵。

需求管理恰如裁縫的量體裁衣，它直接關係到最終產品的成型。僅從字面出發，如果一個產品滿足了客戶需求，那它無疑就是成功的。需求管理的過程，從需求分析開始貫穿整個項目始終，力圖實現最終產品同需求性的最佳結合（參見Figure1）。

需求管理能夠確證：

●我們確知客戶的需求是什麼（質量）；

●滿足客戶需求的最佳解決辦法（統一性）；

著名學者Crosby對於質量的定義是"同需求保持統一"。從這個意義上說，需求管理正是從質量出發以確定需求。每個人都應當始終明白他們所做的具體任務其意義何在。然而，在一個產品的生命周期里，其需求性是能動的，是處於變化之中的。

對於系統工程沒有嚴格統一的定義，因此很難找到足夠的數據以說明系統工程所起的作用。有些致力於研究需求分析的組織認為，一項開發計劃應當至少將8-15%的資源投入到系統工程方面。如果低於這一標準，將很可能導致無法對客戶群做出準確把握。如果該項開發計劃含有許多創新或實驗的成分，那麼這一百分比還應當適度提高。

（Define Requirement）在項目進展過程中，如何區分用戶需求與需求分析中需求定義呢？

當完成用戶需求調查后，首先對《用戶需求說明書》進行細化，對比較複雜的用戶需求進行建模分析，以幫助軟體開發人員更好地理解需求。例如採用Rational的Rose工具進行需求的建模分析。如果使用工具進行建模分析，對需求分析人員的要求比較高。需求定義過程中通常會出現的問題有內容失實、遺漏、含糊不清和前後描述不一致。

當完成需求的定義及分析后，需要將此過程書面化，要遵循既定的規範將需求形成書面的文檔，我們通常稱之為《需求分析說明書》。

邀請同行專家和用戶（包括客戶和最終用戶）一起評審《需求規格說明書》，盡最大努力使《需求規格說明書》能夠正確無誤地反映用戶的真實意願。需求評審之後，開發方和客戶方的責任人對《需求規格說明書》作書面承諾。具體的同行評審詳見需求評審章節。

(Requirement Validate) 需求確認是需求管理過程中的一種常用手段，也是需求控制的五一節之一；確認有兩個層面的意思，第一是進行系統需求調查與分析的人員與客戶間的一種溝通，通過溝通從而對需求不一致的進行剔除；另外一個層面的意思是指，對於雙方達成共同理解或獲得用戶認可的部分，雙方需要進行承諾。

(Establish Requirement State) 何謂需求狀態；顧名思義，狀態也就是一種事物或實體在某一個時刻或點所處的情況，此處要講的需求狀態是指用戶需求的一種狀態變換過程。

為什麼要建立需求狀態？在整個生命周期中，存在著幾種不同的情況，在需求調查人員或系統分析人員進行需求調查時，客戶存在的需求可能有多種，一類是客戶可以明確且清楚的提出的需求；一類是客戶知道需要做些什麼，但又不能確定的需求；另一類是客戶本身可以得出這類需求，但需求的業務不明確，還需要等待外部信息。還有是客戶本身也說不清楚的。

對於這些需求，在開發進展的過程中，存在著以下幾種情況:

有可能要取消的

有的因為不明確而可以後延的，同時可能轉化為被取消的需求

與客戶經過溝通或確認的，此處有兩種情況，一類是確認雙方達成共識，另一種情況是還需要再進一步溝通的。

下面是一個簡單的狀態例子：

CLOSED：經過確認，雙方認可並達成共識；

OPEN:雙方確認，但沒有達成共識的需求；

待定：客戶提出需求，但雙方沒有經過溝通或確認；

(Requirement Review) 對工作產品的評審有兩類方式，一類是正式技術評審，也稱同行評審，另一類是非正式技術評審。對於任何重要的工作產品，都應該至少執行一次正式技術評審。在進行正式評審前，需要有人員對其要進行評審的工作產品進行把關，確認其是否具備進入評審的初步條件。

需求評審的規程與其它重要工作產品（如系統設計文檔、源代碼）的評審規程非常相似，主要區別在於評審人員的組成不同。前者由開發方和客戶方的代表共同組成，而後者通常來源於開發方內部。

有人問：需求評審究竟評審什麼？要細到什麼程度？怎麼樣進行？

嚴格地講，應當檢查需求文檔中的每一個需求，每一行文字，每一張圖表。評判需求優劣的主要指標有：正確性、清晰性、無二義性、一致性、必要性、完整性、可實現性、可驗證性、可測性。如果有可能，最好可以制定評審的檢查表。

需求評審面臨的困難及對策如下：

需求評審的一個通病是“虎頭蛇尾”。需求評審的確乏味，也比較費腦子。剛開始評審時，大家都比較認真，越到後頭越馬虎。當需求文檔很長時，幾乎沒人能夠堅持到最後。會議主持人事先要強調需求評審的重要性：認真評審一小時可能會避免將來數十天的“返工”，讓大家足夠重視。評審組長還要設法避免大家在昏昏沉沉中評審。如果評審時間比較長，建議每隔兩小時休息一次。另外，如果系統比較大，也可以細分成不同的部分分別進行，嚴格控制每一次評審的文檔規模及持續時間。

需求評審涉及的人員可能比較多，有些時候讓這麼多人聚在一起花費比較長的時間開會並不容易（例如有些人可能出差在外，有些人可能事務纏身）。沒有必要把所有事情擠在一塊做，需求開發是循序漸進的過程，需求評審也可以分段進行。這樣每次評審的時間比較短，參加評審的人員也少一些，組織會議就比較容易。對於需求的工作產品《需求規格說明書》，我們可以標明幾種文檔狀態，如草稿狀態，評審狀態，初始狀態等。只有進入評審狀態時，我們可以用不同的方式來對文檔進行評審。但當其評審狀態轉化為初始狀態時，需要進行嚴格的正式的同行評審。

開評審會議時經常會“跑題”，導致評審效率很低。有時話匣子一打開后關不上，大家越扯越遠，結果評審會議變成了聊天會議。主持人應當控制話題，避免大家討論與主題無關的東西。對於自主研發的產品，由於需求評審人員大部分是開發人員，大家會不知不覺地談論軟體“如何做”。由於需求是否“可實現、可驗證、可測試”本來就屬於需求評審的範疇，所以強制大家“只談做什麼，不談怎麼做”幾乎是不可能的。那麼，在需求的評審會上，需要允許開發人員談如何做，但不需太細，適而可止。同時，評審會必須明確一位評審組長，對時間與問題進行控制。

開評審會議時經常會發生爭議。適當的爭議有利於澄清問題，比什麼東西都一致贊成要好。然而當爭議變為爭吵時就壞事了。爭吵不僅對評審工作沒有好處，而且會無意中傷害同事們的感情。同時也解決不了問題。所以，在評審會的過程中，我們要儘可能的是在闡述事實與證據，而並不是從你心底要如何地說服別人。

人們在很多時候分不清楚自己究竟是“堅持真理”還是“固執己見”。毫不妥協或者輕易妥協都不是好辦法。我們應當養成良好的習慣：不要一棍子打死異己的觀點，嘗試著讓自己站在他人的立場思考問題，這樣你會找到比較滿意的答案。試著從不同的角度去看同樣的問題。

{項目名稱}評審報告_需求

基本信息

工作產品。版本號

名稱，標識符，版本，作者，時間

工作產品標識號

評審方式

第幾次評審

工作產品存放路徑

評審地點

評審時間

參與人員

評審人員名字

工作單位或部門

職務職稱

簽字

問題記錄及處理意見

問題編號

位置

問題描述

問題類型

嚴重程度

Problem A

Problem B

評審結論

評審結論

【 】工作產品合格，“無需修改”或者“需要輕微修改但不必再審核”。

【√】工作產品基本合格，需要作少量的修改，之後通評審組長檢查即可。

【 】工作產品不合格，需要作比較大的修改，之後必須重新對其評審。

簽字

（Requirement Consent）什麼是需求承諾，是指開發方和客戶方的責任人對通過了同行評審的需求階段的工作產品，作出承諾，同時該承諾具有商業合同的同等效果。需求承諾如下：

需求承諾

XXX項目需求文檔_《XXX需求說明書》，版本號：X.X.X,是建立在XXX與XXX雙方共同對需求理解的基礎之上，同意後續的開發工作根據該工作產品開展。如果需求發生變化，雙方將共同遵循項目定義的“變更控制規程”執行。需求的變更將導致雙方重新協商成本、資源和進度等。

甲方簽字

乙方簽字

不少人會草率地??面簽字嗎，反正已經評審過了，我就簽吧。但他將來變更需求時可能會表示不瞞：“不錯，我是簽字了，但是我並沒有閱讀文檔。是你們要我在文檔上簽字的，我是相信你們才這麼做的。”為了避免發生此類糾紛，人們在作出承諾之前務必要認真閱讀文檔，一定要明白簽字意味著什麼。

(Requirement Track) 為什麼要進行需求跟蹤？在整個開發過程中，進行需求跟蹤的目的是為了建立和維護從用戶需求開始到測試之間的一致性與完整性。確保所有的實現是以用戶需求為基礎。對於需求實現是否全部的覆蓋。同時確保所有的輸出與用戶需求的符合性。

需求跟蹤有兩種方式，正向跟蹤與逆向跟蹤：

正向跟蹤：以用戶需求為切入點，檢查《用戶需求說明書》或《需求規格說明書》中的每個需求是否都能在後繼工作產品中找到對應點。

逆向跟蹤：檢查設計文檔、代碼、測試用例等工作產品是否都能在《需求規格說明書》中找到出處。

正向跟蹤和逆向跟蹤合稱為“雙向跟蹤”。不論採用何種跟蹤方式，都要建立與維護《需求跟蹤矩陣》。需求跟蹤矩陣保存了需求與後續開發過程輸出的對應關係。矩陣單元之間可能存在“一對一”、“一對多”或“多對多”的關係。見下表：簡單的需求跟蹤矩陣示例。

簡單的需求跟蹤矩陣示例1

使用需求跟蹤矩陣的優點是很容易發現需求與後續工作產品之間的不一致，有助於開發人員及時糾正偏差，避免干冤枉活。

很多人有這樣的誤解：如果依照“需求開發－系統設計－編碼－測試”這樣的順序開發產品，由於每一步的輸出就是下一步的輸入，所以不必擔心設計、編程、測試會與需求不一致，因此可以省略需求跟蹤。那麼，需要指正的是，按照軟體生命周期嚴格線性順序的開發模型並不能保證各個開發階段的工作產品與需求保持一致。需求開發包括獲取分析需求，需求定義，從所有方面核查和驗證需求。因為開發者是人而不是機器。而且，大多數開發人員也都深有體會。

生活中“以訛傳訛”的例子，想必大家都很熟悉。學生甲在精工實習時被機器弄破了手指，於是到醫院包紮。同學乙路過醫院時看到甲的手血跡斑斑，以為甲的手指被機器割斷，於是將這個壞消息告訴同學丙。丙急忙轉告同學丁，說甲的手被機器割斷，正躺在醫院裡。丁十萬火急地告訴全班同學，大家陷入悲痛之中，都以為“甲的胳膊被機器割斷了，正躺在醫院裡，人快不行 了。”

由於人們的表達能力、理解能力不可能完全相同，人與人之間的協作很難達到天衣無縫的境界。而使用需求追溯的本身也是一種傳遞的過程。

需求追溯本身並不是一件複雜的事，而是我們的本身一種理念在支配著我們。也許就有人認為這本身就是在浪費時間，主要麻煩是，當需求或工作產品發生變更時，開發人員要及時更新需求跟蹤矩陣。然而沒想到的事，如果後來再花時間來做同樣的事的時候，將會付出更多。也時也就丟去了本身做這件事的意義。

(Requirement Change Control) 需求變更通常會對項目的進度、人力資源產生很大的影響，這是開發商非常畏懼的問題。也是必須面臨與需要處理的問題。作為軟體項目，特別在外地實施的工程軟體項目而言，需求發生若干次變更似乎是不可避免的。需求發生變更的起因主要有：

隨著項目生命周期的不斷往前推進，人們（包括開發方和客戶方）對需求的了解越來越深入。原先的提出的需求可能存在著一定的缺陷，因此要變更需求。

市場業務需求發生了變化，原先的需求可能跟不上當前的市場業務發展，因此要變更需求。由於市場變化而導致需求發生變更，開發商大可不必為此煩惱，應當高興才對。倘若市場靜如死水，那麼開發商吃了“上一頓”就沒有“下一頓”。正因為市場在變化，才會產生更多商機，聰明的開發商才會有活干，有錢賺。

如果在項目開發的初始階段，開發人員和用戶沒有搞清楚需求或者搞錯了需求，到了項目開發後期才將需求糾正過來，導致產品的部分內容需要重新開發。毫無疑問，這種需求??方工作失誤造成的，雙方應當好好反省，認真學習需求開發和管理的方法，避免再犯相似的錯誤。

總的而言，人們提出需求變更，本就是出於能夠使產品更加符合市場或客戶需求，出發點本身是好的。但對於開發小組而言，需求的變更則意味著要需要重新進行估計，調整資源、重新分配任務、修改前期工作產品等，而作為開發商，需要增預算與投資，開發組要為此付出較重的代價。假定每次需求變更請求都被接受的話，那麼這個項目將會成為一個連環式的工程。

需求變更控制的動機是：

如果需求變更帶來的好處大於壞處，那麼允許變更，但必須按照已定義的變更規程執行，以免變更失去控制。

如果需求變更帶來的壞處大於好處，那麼拒絕變更。

當然，好處與壞處並不是主觀的，而是通過客觀的分析與評價而得出的。

對於需求的變更，在某一個程度上來說，也就是項目的範圍進行了變化。而需求同時又是項目進行的基礎。是非常得要的基石。通常對於需求的變更需要客戶與開發方共同參與，包括負責人及市場人員。當然，我們需要根據變更的內容來靈活運用。

需求變更控制過程中最難辦的事情是莫過於“拒絕客戶提出的需求變更請求”。客戶會想當然地以為變更需求是他的權利，因為他付錢給開發方。通常情況下開發方是不敢得罪客戶的，但是無原則地退讓將使開發小組陷入困境。怎麼解決這個問題呢，通常情況下，每一類“遊戲”都有一定的遊戲規則，那麼我們事先也需要建立“遊戲規則”。

如果事先沒有“遊戲規則”的話，開發方的負責人需要一些社交技巧來減緩矛盾。例如首先承認客戶提出的需求變更請求是合理的，再闡述己方的難處，最後建議在開發該產品新版本時修改需求。這種方式比直接拒絕有效得多，既不得罪客戶，又為自己爭取了餘地。

另外還有一種方法，可以將變更需求先進行記錄，並通知給客戶，當其需求變化在開發組不能接受的範圍時，可以通過市場進行相關的協調。

需求變更本是正常的，並不可怕，可怕的是需求的變更得不到控制。

避免失敗就是一個很充分的理由。提高項目的成功率和需求管理所帶來的其他好處同樣也是理由.Standish Group 的 CHAOS 報告進一步證實了與成功項目關係最大的因素是良好的需求管理.

理解需求管理的第一步就是對什麼是需求管理達成共識.Rational 把需求定義為"(正在構建的)系統必須符合的條件或具備的功能".電氣和電子工程師學會使用的定義與此類似. 著名的需求工程設計師 Merlin Dorfman 和 Richard H. Thayer 提出了一個包容且更為精練的定義，它特指軟體方面 - 但不僅僅限於軟體:

"軟體需求可定義為: 用戶解決某一問題或達到某一目標所需的軟體功能. 系統或系統構件為了滿足合同，規約，標準或其他正式實行的文檔而必須滿足或具備的軟體功能.

由於需求是正在構建的系統必須符合的事務，而且符合某些需求決定了項目的成功或失敗，因此找出需求是什麼，將它們記下來，進行組織，並在發生變化時對它們進行追蹤，這些活動都是有意義的. 換句話說，需求管理就是：一種獲取，組織並記錄系統需求的系統化方案，以及一個使客 戶與項目團隊對不斷變更的系統需求達成並保持一致的過程.

這個定義與 Dorfman 與 Thayer 以及IEEE的"軟體需求工程"的定義相似。需求工程包括獲取，分析，規定，驗證和管理軟體需求，而"軟體需求管理"則是對所有相關活動的規劃和控制。這裡介紹的以及 IBM Rational提出的需求管理定義包括了所有這些活動。它們的區別主要在於這裡選用了"管理"這個詞，而不是"工程".管理這個詞更合適用來描述所有涉及到的活動，並且它準確地強調了追蹤變更以保持涉眾與項目團隊之間共識的重要性.

對那些不熟悉"引出"這個詞的人來說，它可定義為團隊用來獲取或發現涉眾請求，確定請求后隱藏的真正需要，以及為滿足這些需要對系統提出的一組適當需求.

需求管理問題 一個目的在於確保系統符合人們對其期望的流程面臨著哪些困難呢 當它真正在實際項目實施時，困難就暴露出來了。圖 1 顯示了年對開發人員，經理和質量保證人員所做的一次調查結果。該圖顯示了經歷過最常提到的需求相關難題的受訪者比例.

簡單地說，系統開發團隊之所以管理需求，是因為他們想讓項目獲得成功。滿足項目需求即為成功打下了基礎。若無法管理需求，達到目標的幾率就會降低. 以下最近收集的證據很有說服力: Standish Group 從 1994 年到 2001 年的 CHAOS Reports 證實，導致項目失敗的最重要的原因與需求有關. 2001年,Standish Group 的CHAOS Reports報導了該公司的一項研究，該公司對多個項目作調查后發現，百分之七十四的項目是失敗的，既這些項目不能按時按預算完成。其中提到最多的導致項目失敗的原因就是"變更用戶需求".

需求不總是顯而易見的，而且它可來自各個方面. 需求並不總是容易用文字明白無誤地表達. 存在不同種類的需求，其詳細程度各不相同. 如果不加以控制，需求的數量將難以管理. 需求相互之間以及與流程的其他可交付工件之間以多種方式相關聯. 需求有唯一的特徵或特徵值。例如，它們既非同等重要，處理的難度也不同. 需求涉及眾多相關利益責任方，這意味著需求要由跨職能的各組人員來管理. 需求發生變更. 需求可能對時間敏感. 當這些問題與需求管理和處理技能不足以及缺乏易用工具等情況一同出現時，許多團隊都對管理好需求不抱希望了.IBM Rational 已經開發出指導團隊提高需求管理技能和流程的專業技術，並使用相應的工具使得上述的流程和專業技術得以實現.

從上述的分析可以看出，需求的捕獲是需求管理的基礎和前提。在這裡，將介紹一種為業界所廣泛採用並經驗證的需%E4%BE%8B%E6%A8%A1%E5%9E%8B target="_new" class=innerlink>用例模型. 用例模型是系統既定功能及系統環境的模型，並作為客戶和開發人員之間的契約.

用例模型用作分析，設計和測試活動的基本輸入。用例是貫穿整個系統開發的一條主線。同一個用例模型即為需求工作流程的結果，可當作分析設計工作流程以及測試工作流程的輸入使用。參與者(Actor)和用例(UseCase)是用例模型中的主要元素. 下圖顯示了自動取款機系統用例模型的一部分:

客戶

查詢

提款

轉帳

客戶身份驗證系統時鐘

資料庫伺服器

(from )系統維護

信函印表機

列印對帳單

用例圖用於顯示包含參與者和用例的用例模型示例。系統建模有許多種方法，每種建模方法可以滿足不同的目的。然而，用例模型最重要的作用是將系統行為傳達給客戶或最終用戶。可能與該系統交互的用戶和任何其他系統都是參與者。由於參與者代表了系統用戶,它們協助界定系統並提供十分明確的系統用途說明。編寫用例依據參與者的需求來進行。這樣就確保該系統成為用戶期望得到的系統.

參與者和用例都是通過將客戶需求及潛在用戶當作重要的信息查找到的。找到這些用例和參與者后，應對它們作簡要說明。在詳細說明這些用例之前，客戶應複審該用例模型以核實所有的用例和參與者都已經找到，並且它們可以提供客戶所需要的東西. 在迭代開發環境中，您可以選擇用例的子集以便在每個迭代中詳細描述。參與者和用例找到后，需要詳細說明每個用例的事件流。這些說明指出系統與參與者交互的方式以及在各個獨立用例中系統執行的有關操作.

最後，對已完成的用例模型(包括用例說明)進行複審，開發人員和客戶使用該模型對系統應執行的操作達成一致意見.

在需求管理的流程中，需求的捕獲手段固然重要，但在需求的捕獲和需求最終成型的過程中，我們會面臨各種和需求相關的信息和資料(也可以把這些信息籠統地稱做"需求"),如何發現這些信息之間的關係並有效組織，更為關鍵. 需求類型 在RUP中，我們採用一種金字塔方式的管理辦法，來組織和管理我們獲取的信息乃至最終的需求.

徠為了建立一個真正滿足客戶需求的系統，項目團隊首先必須確定系統要解決的問題。然後，團隊必須確定涉眾，從中獲得業務和用戶需要，對其進行描述，並區分它們的優先順序。從這一組高層期望或需求出發，對產品或系統特性集達成一致意見。而後，由產品特性來抽取軟體需求，在我們的模型中，軟體需求是以用例模型的方式來描述。從測試的角度來看，測試項一定來自於軟體需求，即軟體需求中確定了哪些需求項，測試就要根據這些需求項來制定和實現.

系統越大越複雜，出現的需求類型就越多。一個需求類型不過是指需求的一個類。通過確定需求類型，團隊可以把大量需求組織成意義明確且更容易管理的組。在一個項目中建立不同類型的需求有助於團隊成員對變更請求進行分類，並使相互之間的溝通更為清楚明確。從上述的分析中我們可以看到，通常，一類需求可以細分即分解成其他類型的需求。這裡，我們就把需求分解為幾種類型，並在他們 之間建立相應的關聯。業務規則和前景聲明包括高層次的需求，團隊可以從中導出用戶需要，特性和產品需求類型。用例和其他建模形式驅動設計需求，該需求可分解為軟體需求，並可以用分析設計模型來說明。測試需求源於軟體需求，它被分解為具體的測試過程。如果既定項目中有成百上千個，甚至上萬個需求實例時，對需求進行分類可以使項目更容易管理。上述的這些需求類型同時保存在對應的RUP文檔和資料庫中

需求預測模型

1.主觀判斷預測。主觀判斷預測涉及利用主觀判斷和直覺，適用於數據有限或無歷史數據的情況，例如引入新產品。主觀判讀預測技術包括調研和類比技術等。

2.時間序列預測。其基本假設是未來需求僅由過去需求決定。時間序列預測技術包括但不限於簡單移動平均.

和加權移動平均。

3.因果預測。因果預測假設一個或多個因素與需求相關，而因果關係可用來估計未來的需求。

通過定義需求類型，以及他們之間的關係，我們就建立了一個需求管理模型的框架。當然，我們建立這樣的一個模型，是為了方便我們使用需求，為了達到這一目的，我們還需要在此基礎上添加相應的內容. 需要對各種需求類型添加它們的屬性，以便於對需求進行查詢等管理手段。比如，可以針對用戶需要，確定該需要的必要性，優先順序，確定性等屬性。在實際的項目中，就可以確定這些屬性的值，而後根據這些實際屬性值來安排項目的進度表等。或是在項目進度緊急時，確定哪些需求是可以延期完成，而哪些是必須完成的，等等.

需求的追蹤性 其次，可以根據不同需求的導出情況，在不同的需求之間建立追蹤關係。譬如，用戶需要決定了要構建產品的特性，產品的特性又決定了產品的軟體需求，等.在這些不同類型的需求之間建立關聯，一旦其中的某些需求發生變化，就可以確定它可能帶來的影響，從而制定相應的策略.

工作流明細簡介

問題分析可以通過了解問題及涉眾的最初需要，並提出高層解決方案來實現。它是為找出"隱藏在問題之後的問題"而進行的推理和分析。問題分析期間，將對"什麼是面臨實際問題"和"誰是涉眾"等問題達成一致。而且，您還要從業務角度界定解決方案，以及制約該解決方案的因素。您應該已經對項目進行過商業理由分析，這將便於您更好地預計能從構建中的項目中得到多少投資回報.

需求來自各個方面，比如來自客戶，合作夥伴，最終用戶或是某領域的專家。您需要掌握如何準確判斷需求應來源於哪方面，如何接近這些來源並從中獲取信息。提供這些信息主要出處的個人在本項目中稱為涉眾。如果您正在開發一個在您公司內部使用的信息系統，那麼在開發團隊中應包括具有最終用戶經驗和業務領域專業知識的人員。通常討論將在業務模型這一級上展開，而不是在系統這一級上展開。如果正在開發一個要在市場上出售的產品，那麼您可以充分調動營銷人員，以便更好地了解該市場中用戶的需要. 獲取需要的活動可使用這樣一些技巧：訪談，集體討論，概念原型設計,問卷調查和競爭性分析等。獲取結果可能是一份圖文並茂的請求或需要列表，並按相互之間的優先順序列出.

定義系統指的是解釋涉眾需求，並整理為對要構建系統的意義明確的說明。在系統定義的初期要確定以下內容：需求構成，文檔格式，語言形式，需求的具體程度(需求量及詳細程度),需求的優先順序和預計工作量(不同人在不同的實踐中通常對這兩項內容的看法大不相同),技術和管理風險以及最初規模。系統定義活動還可包括與最關鍵的涉眾請求直接聯繫的初期原型和設計模型。系統定義的P>

為使項目高效運作，應仔細根據所有涉眾的需求確定優先順序，並對項目規模進行管理。有的開發人員僅僅重視所謂的"復活節彩蛋"(即開發人員感興趣或覺得有挑戰性的特性),而不是及早將精力投入降低項目風險或提高應用程序構架穩定性方面，這已使太多的項目蒙受損失。為確保儘早解決或降低項目中的風險，應以遞增的方式開發系統。要慎重選擇需求，以確保每次增加都能緩解項目中的已知風險。要達到目的，您需要和項目的涉眾協商每次迭代的範圍。通常，這要求具備管理項目各個階段的期望結果的良好技能.

除了控制開發過程本身，您還需控制需求的來源，並控制項目可交付工件的外觀. 改進系統定義 系統的詳細定義應能讓涉眾理解，同意並認可。它不僅需要具備所有功能，而且應符合法律或法規上的要求，符合可用性，可靠性，性能，可支持性和可維護性。感覺構建過程複雜的系統就應該有複雜的定義，這是一種常見的錯誤看法。這會給解釋項目和系統的目的造成困難。人們可能印象深刻，但他們會因不甚理解而無法給出建議。應該致力於

了解您製作的系統說明文檔的讀者。您可能常會發現需要為不同的讀者準備不同的說明文檔.

我們認為用例方法是傳達系統目的和定義系統細節的一種行之有效的方法，它常與簡單的可視化原型結合使用。用例有助於為需求提供一個環境，利用它可生動地說明系統使用的方式.

系統詳細定義的另一個構件是說明系統採用的測試方式。測試計劃及要執行測試的定義將會說明要核實哪些系統功能.

定義需求時無論怎樣謹慎小心，也總會有可變因素。變更的需求之所以變得難以管理，不僅是因為一個變更了的需求意味著要花費或多或少的時間來實現某一個新特性，而且也因為對某個需求的變更很可能影響到其他需求。應確保賦予需求一個有彈性的結構，使它能適應變更，並且確保使用可追蹤性鏈接可以表達需求與開發生命周期的其他工件之間的依賴關係。管理變更包括建立基線，確定需要追蹤的重要依賴關係，建立相關項之間的可追蹤性，以及變更控制等活動.

可以說需求是一種模型，是產品的早期雛形，通過進行需求分析，我們可以對最終產品做出優化。需要始終保持注意的是，需求性是始終處於變化之中的。需求管理需要完成的任務包括：

●明確需求並達成共識；

●建立關聯；

●根據不同需求設計相應解決辦法；

●進行系統優化；

●提出設計方案；

●監控和解決可能出現的問題以及需要做出的改變；

●控制不同開發任務的開展；

●對最終產品做出評測；

●監控可能出現的重複開發；

●提出項目實施時間表；

●確定最終用戶界面。

有時候我們所進行的需求分析只停留於分析本身，而沒有進一步去思索我們為什麼要進行需求分析。需求性是項目開發的源頭，只有進行認真的需求分析，我們才能做到對症下藥、量體裁衣，才能才設計開發中去偽存真，不斷改進。"需求之需求"正是強調了貫穿始終的需求分析的重要。離開了能動的、變化的系統進程而空談需求管理，無異於紙上談兵。需求管理所產生的效益或許並不明顯，或許要日後才能體現，但是無序的，沒有經過精心策劃的需求管理是不可能產生效益的。

以下篇幅分別介紹需求管理在系統工程中的不同應用。

首先，用戶需求通過非術語的形式進行表述，這種表述應當使每一位開發者明確自己的職責所在，並且清楚知道不同開發工作之間的關聯。這裡的"用戶"泛指在實際應用環境中每一位可能使用最終產品的人。如果一個產品不能滿足客戶所需，那麼設計方案再出色也無濟於事，許多方案有很高的技術設計水準卻最終不能獲得成功，其原因正在於此。可以把產品功能說得天花亂墜，但卻無法改變用戶需求決定最終產品基本模式的事實。

需求管理的首要任務在於使開發人員和用戶雙方對於需求都有一個明確的認識。因此用來進行需求分析的語言組織應當使所有相關人員，包括用戶，都能夠理解，都能夠進而對整個項目有一個整體把握，並明確每一個人在項目中所起的作用。因而需求管理需要解決的第一位也是最基本的任務就是明確需求，並使所有相關人員達成共識。

根據需求設計解決辦法

我們在進行系統設計時，應當首先建立一個需求模型，但不能是為了建模而建模，需求模型實際是最終產品的抽象化表現。需求模型的建立使我們在明確需求的基礎上更進一步，使我們知道我們將要生產何種產品，該產品都具有那些功能。同時，創建需求模型的過程也使開發者明確自己的工作如何同整個項目有機地結合在一起。建立需求模型應當充分研究不同類型、不同架構建模方式的可行性，切忌主觀武斷。

任何設計都應以考慮用戶需求為優先，用戶需求的滿足程度即成為衡量設計優劣的標準。在一個項目設計周期中，開發人員經常會面臨選擇，以提煉需求，決定開發的優先次序，並在不同的實施方案中作出選擇。這些選擇必須考慮到收益與付出地平衡比例，這種選擇的重要性尤其在建立需求模型的後期凸現出來。基本需求在這時都已明確，而實施方案還未敲定，為了使用戶的基本需求得到落實，一定程度的開銷用於搭建不同構架的需求模式是合理的。假使我們已經有了一套翔實的需求分析，我們甚至不必將每一套方案都付諸實行，就可以成功地對系統設計進行優化。

面對不同的可行性而需要作出選擇時，我們也必須參照收益與付出的比例關係。例如，在被要求提供計劃書時（Request for Proposal），我們應當盡量做到每一份計劃書的提供都物有所值。

明確需求后，開發人員就可以進行方案設計。通過對用戶需求和設計方案之間所存在關聯性進行分析比較，我們就能夠對設計方案進行評估。

方案的設計不可能是一成不變的，經常會有方案設計同需求相悖的情況。如果我們無法準確把握用戶需求同方案設計之間的關係，我們就無法在需要對方案進行必要修改時正確判斷。優秀的需求分析應當非常精確細緻地對用戶需求作出描述，同時也應該最大程度地給予方案設計者充分發揮的餘地。

一個大的開發項目可能涉及20-30組不同的開發隊伍，人員包括技術工程師、軟體工程師以及具體項目主管等等，而每一個模塊都有它自己的開發工具和開發語言。

主持一個大項目的開發並不是件容易的事，總體項目主管的首要任務是對開發項目進行任務劃分，將整體開發任務細化為多個子模塊，從而使這些子模塊能夠平行開發而無需太多的干預。總體項目主管可以將細化的不同模塊的需求分析交給不同的開發隊伍，對於開發進程的監控只需參照需求的解決情況，對於具體的開發細節則不必過問太多。

不同的開發隊伍會使用不同的開發語言和開發工具，會使用不同的符號和標記。相反，作為總體項目主管所使用的語言、符號和標記等則必須簡單易懂，以使所有的開發人員都等理解。換言之，總體項目主管應當使用自然語言，或只涉及少量的，簡單的術語和專用辭彙。

需求的滿足情況是決定最終產品成敗的判定基礎，對最終產品的測試評估必須以產品所試圖解決的需求為標準。下圖標示了不同的開發階段所對應的測試需求。

這裡有一個需求、產品和測試系統之間的關係問題，確定需要進行的測試屬於總體開發主管的工作範疇，雖然具體工作並非都要由開發主管來親自完成。

對於總體開發主管而言，針對方案設計的修改是一項經常性的工作（因為修改而造成的影響則應當儘可能減小）。在進行項目開發時，隨著開發進程的深入，各種修改的建議和問題的報告是屢見不鮮的，每解決一個問題，就是將產品同其需求性的結合又完善了一步。存在問題正是需求性尚未滿足的表現。

方案設計的完善和需求性的滿足是同步的，因此真正的用戶對於產品的評價和建議尤其具有重要意義。在那些一步到位的產品設計中，真正用戶無法左右開發進程；但在一個能夠進行重複設計、重複開發的產品生命期中，開發人員應當及時搜集用戶對於產品的反饋信息，並將這些信息結合到下一步的開發工作中去。如下圖所示，用戶反饋同產品開發是統一的。

在有些地方，需求管理被作為一個技術問題來處理，需求管理所針對的對象只是產品，而同項目管理所涉及的問題例如進程安排或資源分配等無關。實際上，項目管理涉及三方面問題：進程安排、資源分配和質量管理（同需求的統一）。

試想以下三種情況：

●一場高水準的音樂會，預算合理，演出時間卻晚了兩天。

●質量優良的小轎車，交貨及時，然而造價是市價的兩倍。

●一套系統，完全滿足了用戶需求，但在開發過程中使用非法勞工。

這三種情況雖然都滿足了用戶所需，然而缺乏實際意義，因此都以失敗告終。

"我付了錢，但這不是我想要的"，沒有用戶願意這麼說。要避免出現這種情況，在進行項目管理和財務預算時，也必須以需求管理為基礎。僅僅完成了一件設計並不意味著工作的結束，只有這件設計充分解決了需求，它才具有里程碑般的意義。同樣的，一件產品只有在測試和實際操作中完全滿足了需求，已經完全準備好了投入到下一階段的運營，才意味著這件產品在本階段工作的結束。

開發進程中的每一塊里程碑都意味著需求的解決又前進了一步，這樣的每一塊里程碑也都是委託商付款的重要參照，產品開發的整個進程都可以通過需求管理進行監控。

里程碑構造機制的基本方法之一就是進程管理，一項需求的滿足就意味著一塊里程碑的確立。我們應當對用戶需求、針對需求而進行的模塊設計以及每個子模塊的開發進程之間的關聯做到心中有數。

通過我們對需求管理實際應用的分析，幾個關鍵因素凸現出來。首先，需求管理在開發周期中是自始至終存在的。注意：不要把它簡單理解為"需求周期"，需求管理必須始終保持更新，它構成了技術管理的基礎。

其次，需求管理同項目管理是密不可分的。如果我們把每一個需求的解決看作一個里程碑，並以此出發對整個開發進程進行監控，我們就應該對整體開發工作進行精密細緻的劃分，從而將需求分析具體化。

需求管理所用到的工具必須能夠處理和應用於本文所提到的各種需求，應當有助於我們分析需求，確定相應開發和支持工具以處理相關信息，進而處理系統相應模塊。系統工程師始終致力於用簡單的工具將需求形象化的展現出來，常用的工具比如附有標註說明的系統發布工具以及相關資料庫等。

需求管理涉及到一系列複雜的對象，其任務面向很廣，關係到整個設計開發的方方面面。其使用的工具應當提供如圖列舉的一些功能：

本文論述圍繞於需求管理工程。需求管理是開發工作有效進行的確證。很明顯需求管理是一種很高層次的系統行為，涉及整個開發過程和產品本身。

需求管理首先要針對需求做出分析，隨後應用於產品並提出方案。需求分析的模型正是產品的原型樣本，優秀的需求管理提高了這樣的可能性：它使最終產品更接近於解決需求，提高了用戶對產品的滿意度，從而使產品成為真正優質合格的產品。從這層意義上說，需求管理是產品質量的基礎。