☆概要
    需求管理恰如裁縫的量體裁衣，它直接關系到最終產品的成型。僅從字面出發(fā)，如果一個產品滿足了客戶需求，那它無疑就是成功的。需求管理的過程，從需求分析開始貫穿整個項目始終，力圖實現(xiàn)最終產品同需求性的結合（參見Figure 1）。通過對需求管理在項目進程中實施的不同任務進行分析，我們可以看出需求管理所起的作用。
    需求管理能夠確證：
    ●我們確知客戶的需求是什么（質量）；
    ●滿足客戶需求的解決辦法（統(tǒng)一性）；
    學者Crosby對于質量的定義是"同需求保持統(tǒng)一"。從這個意義上說，需求管理正是從質量出發(fā)以確定需求。每個人都應當始終明白他們所做的具體任務其意義何在。然而，在一個產品的生命周期里，其需求性是能動的，是處于變化之中的。
    對于系統(tǒng)工程沒有嚴格統(tǒng)一的定義，因此很難找到足夠的數(shù)據(jù)以說明系統(tǒng)工程所起的作用。有些致力于研究需求分析的組織認為，一項開發(fā)計劃應當至少將8-15%的資源投入到系統(tǒng)工程方面。如果低于這一標準，將很可能導致無法對客戶群做出準確把握。如果該項開發(fā)計劃含有許多創(chuàng)新或實驗的成分，那么這一百分比還應當適度提高。
    ☆需求管理所要完成的任務
    可以說需求是一種模型，是產品的早期雛形，通過進行需求分析，我們可以對最終產品做出優(yōu)化。需要始終保持注意的是，需求性是始終處于變化之中的。需求管理需要完成的任務包括：
    ●明確需求并達成共識；
    ●建立關聯(lián)；
    ●根據(jù)不同需求設計相應解決辦法；
    ●進行系統(tǒng)優(yōu)化；
    ●提出設計方案；
    ●監(jiān)控和解決可能出現(xiàn)的問題以及需要做出的改變；
    ●控制不同開發(fā)任務的開展；
    ●對最終產品做出評測；
    ●監(jiān)控可能出現(xiàn)的重復開發(fā)；
    ●提出項目實施時間表；
    ●確定最終用戶界面。
    有時侯我們所進行的需求分析只停留于分析本身，而沒有進一步去思索我們?yōu)槭裁匆M行需求分析。需求性是項目開發(fā)的源頭，只有進行認真的需求分析，我們才能做到對癥下藥、量體裁衣，才能才設計開發(fā)中去偽存真，不斷改進。"需求之需求"正是強調了貫穿始終的需求分析的重要。離開了能動的、變化的系統(tǒng)進程而空談需求管理，無異于紙上談兵。需求管理所產生的效益或許并不明顯，或許要日后才能體現(xiàn)，但是無序的，沒有經過精心策劃的需求管理是不可能產生效益的。
    以下篇幅分別介紹需求管理在系統(tǒng)工程中的不同應用。
    需求共識：
    首先，用戶需求通過非術語的形式進行表述，這種表述應當使每一位開發(fā)者明確自己的職責所在，并且清楚知道不同開發(fā)工作之間的關聯(lián)。這里的"用戶"泛指在實際應用環(huán)境中每一位可能使用最終產品的人。如果一個產品不能滿足客戶所需，那么設計方案再出色也無濟于事，許多方案有很高的技術設計水準卻最終不能獲得成功，其原因正在于此?？梢园旬a品功能說得天花亂墜，但卻無法改變用戶需求決定最終產品基本模式的事實。
    需求管理的首要任務在于使開發(fā)人員和用戶雙方對于需求都有一個明確的認識。因此用來進行需求分析的語言組織應當使所有相關人員，包括用戶，都能夠理解，都能夠進而對整個項目有一個整體把握，并明確每一個人在項目中所起的作用。因而需求管理需要解決的第一位也是最基本的任務就是明確需求，并使所有相關人員達成共識。
    根據(jù)需求設計解決辦法：
    我們在進行系統(tǒng)設計時，應當首先建立一個需求模型，但不能是為了建模而建模，需求模型實際是最終產品的抽象化表現(xiàn)。需求模型的建立使我們在明確需求的基礎上更進一步，使我們知道我們將要生產何種產品，該產品都具有那些功能。同時，創(chuàng)建需求模型的過程也使開發(fā)者明確自己的工作如何同整個項目有機地結合在一起。建立需求模型應當充分研究不同類型、不同架構建模方式的可行性，切忌主觀武斷。
    系統(tǒng)優(yōu)化：
    任何設計都應以考慮用戶需求為優(yōu)先，用戶需求的滿足程度即成為衡量設計優(yōu)劣的標準。在一個項目設計周期中，開發(fā)人員經常會面臨選擇，以提煉需求，決定開發(fā)的優(yōu)先次序，并在不同的實施方案中作出選擇。這些選擇必須考慮到收益與付出地平衡比例，這種選擇的重要性尤其在建立需求模型的后期凸現(xiàn)出來?；拘枨笤谶@時都已明確，而實施方案還未敲定，為了使用戶的基本需求得到落實，一定程度的開銷用于搭建不同構架的需求模式是合理的。假使我們已經有了一套翔實的需求分析，我們甚至不必將每一套方案都付諸實行，就可以成功地對系統(tǒng)設計進行優(yōu)化。
    面對不同的可行性而需要作出選擇時，我們也必須參照收益與付出的比例關系。例如，在被要求提供計劃書時（Request for Proposal），我們應當盡量做到每一份計劃書的提供都物有所值。
    方案設計：
    明確需求后，開發(fā)人員就可以進行方案設計。通過對用戶需求和設計方案之間所存在關聯(lián)性進行分析比較，我們就能夠對設計方案進行評估。
    必要的修改：
    方案的設計不可能是一成不變的，經常會有方案設計同需求相悖的情況。如果我們無法準確把握用戶需求同方案設計之間的關系，我們就無法在需要對方案進行必要修改時正確判斷。優(yōu)秀的需求分析應當非常精確細致地對用戶需求作出描述，同時也應該程度地給予方案設計者充分發(fā)揮的余地。
    任務劃分：
    一個大的開發(fā)項目可能涉及20-30組不同的開發(fā)隊伍，人員包括技術工程師、軟件工程師以及具體項目主管等等，而每一個模塊都有它自己的開發(fā)工具和開發(fā)語言。
    主持一個大項目的開發(fā)并不是件容易的事，總體項目主管的首要任務是對開發(fā)項目進行任務劃分，將整體開發(fā)任務細化為多個子模塊，從而使這些子模塊能夠平行開發(fā)而無需太多的干預?？傮w項目主管可以將細化的不同模塊的需求分析交給不同的開發(fā)隊伍，對于開發(fā)進程的監(jiān)控只需參照需求的解決情況，對于具體的開發(fā)細節(jié)則不問太多。
    不同的開發(fā)隊伍會使用不同的開發(fā)語言和開發(fā)工具，會使用不同的符號和標記。相反，作為總體項目主管所使用的語言、符號和標記等則必須簡單易懂，以使所有的開發(fā)人員都等理解。換言之，總體項目主管應當使用自然語言，或只涉及少量的，簡單的術語和專用詞匯。
    產品測試：
    需求的滿足情況是決定最終產品成敗的判定基礎，對最終產品的測試評估必須以產品所試圖解決的需求為標準。下圖標示了不同的開發(fā)階段所對應的測試需求。
     這里有一個需求、產品和測試系統(tǒng)之間的關系問題，確定需要進行的測試屬于總體開發(fā)主管的工作范疇，雖然具體工作并非都要由開發(fā)主管來親自完成。
    重復開發(fā)：
    對于總體開發(fā)主管而言，針對方案設計的修改是一項經常性的工作（因為修改而造成的影響則應當盡可能減小）。在進行項目開發(fā)時，隨著開發(fā)進程的深入，各種修改的建議和問題的報告是屢見不鮮的，每解決一個問題，就是將產品同其需求性的結合又完善了一步。存在問題正是需求性尚未滿足的表現(xiàn)。
    方案設計的完善和需求性的滿足是同步的，因此真正的用戶對于產品的評價和建議尤其具有重要意義。在那些一步到位的產品設計中，真正用戶無法左右開發(fā)進程；但在一個能夠進行重復設計、重復開發(fā)的產品生命期中，開發(fā)人員應當及時搜集用戶對于產品的反饋信息，并將這些信息結合到下一步的開發(fā)工作中去。如下圖所示，用戶反饋同產品開發(fā)是統(tǒng)一的。
    項目管理的輔助：
    在有些地方，需求管理被作為一個技術問題來處理，需求管理所針對的對象只是產品，而同項目管理所涉及的問題例如進程安排或資源分配等無關。實際上，項目管理涉及三方面問題：進程安排、資源分配和質量管理（同需求的統(tǒng)一）。
    試想以下三種情況：
    ●一場高水準的音樂會，預算合理，演出時間卻晚了兩天。
    ●質量優(yōu)良的小轎車，交貨及時，然而造價是市價的兩倍。
    ●一套系統(tǒng)，完全滿足了用戶需求，但在開發(fā)過程中使用非法勞工。
    這三種情況雖然都滿足了用戶所需，然而缺乏實際意義，因此都以失敗告終。