本文章是以年輕IT工程師為對象（參加工作2-4年左右），以能夠使其理解軟件需求管理的基礎為目標。為了描述更具體的內容，在本文章中提出了關于RUP（注）的需求管理成果物和作業(yè)流程，為了盡量使需求管理的基礎更明了易懂，而要對其進行講解。

　　（注：Rational Unified Process：是IBM Rational的軟件開發(fā)方法論，作為面向對象開發(fā)方法論而聞名）

　　為什么要進行需求管理？

　　為什么要進行需求管理？用一句話來概述就是因為管理需求可以很大程度地來左右項目的成功。首先，來考慮一般的項目目標吧。請看下面的定義。

　　項目目標

　　在期限內及預算內，開發(fā)滿足客戶真實需求的高品質的產品（在此所說的產品是指以軟件為中心的產品，包含企業(yè)業(yè)務應用程序、嵌入式軟件以及包裝產品）

　　出現了“滿足顧客真實需求”“高品質”“期限內”“預算內”這4個關鍵字，但是無論哪個都與需求管理息息相關。首先、為了制造“高品質的產品”，在需求管理方面要準確地把握所謂的系統(tǒng)可靠性、可擴展性等非功能需求也是非常重要的。另外、對于在“期限內”“預算內”開發(fā)產品存在問題嗎？項目必須在限定時間、預算以及資源的狀態(tài)下開發(fā)。考慮利用所給予的時間、預算以及資源能夠完成多少作業(yè)，必須把產品要求式樣的范圍控制在作業(yè)可能的范圍內。

　　由于QCD（Quality：質量、Cost：價格、Delivery：繳納期）這一關鍵字經常被使用，所以大家也就對“在期限內及預算內開發(fā)高品質的產品”更加耳熟了。在此想要讓大家關注的是“滿足客戶真實需求”的部分。無論在期限及預算內制造了多少高品質的產品，如果不能滿足顧客真實需求的話，那些產品也是沒有意義的。

　　例如，開發(fā)為提高營業(yè)員業(yè)務處理效率的應用程序。在該項目中擁有高超技能的開發(fā)者進行了極優(yōu)秀的設計，也充分考慮了其擴展性。但是，由于應用程序對于用戶（營業(yè)員）來說非常難以使用，所以很多營業(yè)員都對其敬而遠之。不久，該系統(tǒng)就會自然消失了。該產品沒能反映所謂“提高業(yè)務處理效率”的顧客的真實需求。也就是說、缺少了滿足該需求的部分（例如：使用 GUI的容易度）。遺憾的是這種事例經常發(fā)生。在此，我想在實現“滿足顧客真實需求”之后來強調項目的成功挖掘。 項目經理圈子

　　另一方面、從數據中也能說明需求管理對項目的成功有很大的貢獻。作為軟件開發(fā)現場的調查報告，根據著名的（Standish Group的）CHAOS（2001年）報告，在對項目的成功完成貢獻的原因一覽里“用戶的輸入”“明確商務目標”“將開發(fā)范圍最小化”“穩(wěn)定的需求項目”等與需求管理相關的事項連接在上面。從此也能看出需求管理的重要性。

　　何為需求？何為需求管理？

　　在接觸需求管理的具體內容之前，首先來看一下要求和需求管理的定義。在RUP中將需求和需求管理如下定義。

　　需求（Requirement）

　　應該滿足系統(tǒng)的樣態(tài)和能力

　　需求管理（Requirement Management）

　　挖掘需求、體系以及文檔化的系統(tǒng)研究

　　關于能夠產生變更的需求、形成客戶和開發(fā)團隊之間的協議，為了維護系統(tǒng)研究

　　“需求”的定義非常簡單。所謂定義需求就是定義“應該滿足系統(tǒng)的樣態(tài)和能力”。換句話說，可以說成定義“做什么好呢？”，這也可以說是定義了項目成功的基準。即使用一句話來概述需求、在需求里也存在著各種各樣的種類和水平。但是我想在以后將對需求的詳細定義進行說明。

　　在RUP中“需求管理”的定義中需要注意的是操縱需求管理的范圍的寬度。所謂需求管理，首先包含“挖掘需求”。所謂“挖掘需求”就是從顧客和終端用戶提出對系統(tǒng)的需求。通常、不會輕易提出需求，所以就變?yōu)槭褂酶鞣N手法來竭力發(fā)掘。

　　其次、所謂需求管理包含“整理需求”。如果是復雜的系統(tǒng)，存在幾百件需求也是正常的，所以需要對其進行整理。并且，需求管理也包含“將需求文檔化”。一般人都不能記住那么多的需求，并且也為了在客戶和開發(fā)團隊之間共享需求所以文檔化是必要的。

　　另外，所謂需求管理也包含“形成并維護客戶與開發(fā)團隊之間的協議”。如上所述、如果能夠“發(fā)掘、整理要求，并將其文檔化”，接下來關于其要求，為了在期限內、預算內完成開發(fā)，需要在顧客和開發(fā)團隊之間對項目中涉及的要求范圍進行協定。另外、隨著開發(fā)的進入而發(fā)生需求變更時要分析其影響范圍，對于被采納的以及與之相反的事項與客戶形成協議也是非常重要的。

　　需求管理不簡單

　　如果是2～3人規(guī)模的小項目，不會為需求而煩惱。但是小規(guī)模軟件包開發(fā)中有幾千件需求、大規(guī)模項目中有幾萬件以上的要求，隨著規(guī)模的變大，在需求管理中要面對各種問題。如下所示：列舉了項目中容易引發(fā)的典型問題。

　　◎ “很難發(fā)掘需求”

　　在很多情況下，如果開發(fā)團隊不能充分理解應該解決的問題，就會提供給傾向技術的解決對策，從而制作成沒有滿足顧客需求的系統(tǒng)。為了不出現上述情況，挖掘客戶的需求就顯得尤為重要。但是由于客戶與開發(fā)者之間持有不同的術語、背景、動機以及目的，因而存在著溝通上的分歧。

　　◎ “難以將需求體系化并整理”

　　由于在大規(guī)模項目中單純地需求的數目非常多，所以涉及的事物本身很困難。另外、這些需求的出處也不僅僅是用戶，也復雜地涉及到受系統(tǒng)影響的利害關系者（Stakeholder）。更進一步地說、在需求方面存在著多種種類和級別。關系到各種各樣的成果物，所以體系化非常困難。

　　◎ “難以將需求文檔化”

　　這既有沒有明確需求的情況，也有難以把單純的需求用語言來表達的情況。文檔化是不僅困難、而且對記述高品質的需求文檔缺乏評審，同時在需求變更時更新文檔也需要花費大量的作業(yè)時間。

　　◎ “難以追加需求變更”

　　隨著項目的展開、需求會進化并增加，有時計劃會超出項目的日程安排和預算。最初的原因是客戶頻繁的需求變更，但是在開發(fā)團隊的對應方法上也存在著問題。有時候不能分析需求變更的影響，不能與客戶取得很好的協議。另外、把需求變更在開發(fā)團隊的全體成員中共享也不是簡單的事情。

　　如上、發(fā)現了很多問題，但是為了妥當地處理這些問題，要求對需求管理進行體系化的程序。下回、在開始需求管理具體的程序之前，先要了解一下要求的各個種類和級別。