至今所不為熟悉的需求管理的基礎
這則報道是以年輕IT工程師為對象（參加工作2-4年左右），以能夠使其理解軟件需求管理的基礎為目標。為了描述更具體的內容，在本報道中提出了關于RUP（注）的需求管理成果物和作業流程，為了盡量使需求管理的基礎更明了易懂，而要對其進行講解。
（注：Rational Unified Process：是 IBM Rational的軟件開發方法論，作為面向對象開發方法論而聞名）
為什么要進行需求管理？
為什么要進行需求管理？用一句話來概述就是因為管理需求可以很大程度地來左右項目的成功。首先，來考慮一般的項目目標吧。請看下面的定義。
出現了“滿足顧客真實需求”“高品質”“期限內”“預算內”這4個關鍵字，但是無論哪個都與需求管理息息相關。首先、為了制造“高品質的產品”，在需求管理方面要準確地把握所謂的系統可靠性、可擴展性等非功能需求也是非常重要的。另外、對于在“期限內”“預算內”開發產品存在問題嗎？項目必須在限定時間、預算以及資源的狀態下開發。考慮利用所給予的時間、預算以及資源能夠完成多少作業，必須把產品要求式樣的范圍控制在作業可能的范圍內。
由于QCD（Quality：質量、Cost：價格、Delivery：繳納期）這一關鍵字經常被使用，所以大家也就對“在期限內及預算內開發高品質的產品”更加耳熟了。在此想要讓大家關注的是“滿足客戶真實需求”的部分。無論在期限及預算內制造了多少高品質的產品，如果不能滿足顧客真實需求的話，那些產品也是沒有意義的。
例如，開發為提高營業員業務處理效率的應用程序。在該項目中擁有高超技能的開發者進行了極優秀的設計，也充分考慮了其擴展性。但是，由于應用程序對于用戶（營業員）來說非常難以使用，所以很多營業員都對其敬而遠之。不久，該系統就會自然消失了。該產品沒能反映所謂“提高業務處理效率”的顧客的真實需求。也就是說、缺少了滿足該需求的部分（例如：使用 GUI的容易度）。遺憾的是這種事例經常發生。在此，我想在實現“滿足顧客真實需求”之后來強調項目的成功挖掘。
另一方面、從數據中也能說明需求管理對項目的成功有很大的貢獻。作為軟件開發現場的調查報告，根據著名的（Standish Group的）CHAOS（2001年）報告，在對項目的成功完成貢獻的原因一覽里“用戶的輸入”“明確商務目標”“將開發范圍最小化”“穩定的需求項目”等與需求管理相關的事項連接在上面。從此也能看出需求管理的重要性。
何為需求？何為需求管理？
在接觸需求管理的具體內容之前，首先來看一下要求和需求管理的定義。在RUP中將需求和需求管理如下定義。
“需求”的定義非常簡單。所謂定義需求就是定義“應該滿足系統的樣態和能力”。換句話說，可以說成定義“做什么好呢？”，這也可以說是定義了項目成功的基準。即使用一句話來概述需求、在需求里也存在著各種各樣的種類和水平。但是我想在以后將對需求的詳細定義進行說明。
在RUP中“需求管理”的定義中需要注意的是操縱需求管理的范圍的寬度。所謂需求管理，首先包含“挖掘需求”。所謂“挖掘需求”就是從顧客和終端用戶提出對系統的需求。通常、不會輕易提出需求，所以就變為使用各種手法來竭力發掘。
其次、所謂需求管理包含“整理需求”。如果是復雜的系統，存在幾百件需求也是正常的，所以需要對其進行整理。并且，需求管理也包含“將需求文檔化”。一般人都不能記住那么多的需求，并且也為了在客戶和開發團隊之間共享需求所以文檔化是必要的。
另外，所謂需求管理也包含“形成并維護客戶與開發團隊之間的協議”。如上所述、如果能夠“發掘、整理要求，并將其文檔化”，接下來關于其要求，為了在期限內、預算內完成開發，需要在顧客和開發團隊之間對項目中涉及的要求范圍進行協定。另外、隨著開發的進入而發生需求變更時要分析其影響范圍，對于被采納的以及與之相反的事項與客戶形成協議也是非常重要的。
需求管理不簡單
如果是2～3人規模的小項目，不會為需求而煩惱。但是小規模軟件包開發中有幾千件需求、大規模項目中有幾萬件以上的要求，隨著規模的變大，在需求管理中要面對各種問題。如下所示：列舉了項目中容易引發的典型問題。
---“很難發掘需求”
在很多情況下，如果開發團隊不能充分理解應該解決的問題，就會提供給傾向技術的解決對策，從而制作成沒有滿足顧客需求的系統。為了不出現上述情況，挖掘客戶的需求就顯得尤為重要。但是由于客戶與開發者之間持有不同的術語、背景、動機以及目的，因而存在著溝通上的分歧。
---“難以將需求體系化并整理”
由于在大規模項目中單純地需求的數目非常多，所以涉及的事物本身很困難。另外、這些需求的出處也不僅僅是用戶，也復雜地涉及到受系統影響的利害關系者（Stakeholder）。更進一步地說、在需求方面存在著多種種類和級別。關系到各種各樣的成果物，所以體系化非常困難。
---“難以將需求文檔化”
這既有沒有明確需求的情況，也有難以把單純的需求用語言來表達的情況。文檔化是不僅困難、而且對記述高品質的需求文檔缺乏評審，同時在需求變更時更新文檔也需要花費大量的作業時間。
---“難以追加需求變更”
隨著項目的展開、需求會進化并增加，有時計劃會超出項目的日程安排和預算。最初的原因是客戶頻繁的需求變更，但是在開發團隊的對應方法上也存在著問題。有時候不能分析需求變更的影響，不能與客戶取得很好的協議。另外、把需求變更在開發團隊的全體成員中共享也不是簡單的事情。
如上、發現了很多問題，但是為了妥當地處理這些問題，要求對需求管理進行體系化的程序。下回、在開始需求管理具體的程序之前，先要了解一下要求的各個種類和級別。
第2回：軟件需求的詳細分類
在上回的 “至今所不為熟悉的需求管理的基礎”中只接觸了關于需求的非常模糊的定義。在這回我們來了解一下更詳細的需求吧。首先看一看如何描述才能把系統需求完整記錄，然后再逐步深入。
需求可以描述系統的什么內容？
定義系統的詳細需求在RUP中稱為“軟件需求（Software Requirements）”。也就是說，如果完整的描述了軟件需求的話，系統需求也就完整描述了。
軟件需求定義是從把系統作為黑匣子的觀點出發，描述系統為用戶、設備或者其他系統提供的執行能力/狀態的內容。也就是說，要描述軟件需求的話，需要考慮從系統外部來了解的狀態下（不知道系統中會變成什么什么狀態），完整地描述其要執行什么。為了完整地描述系統，需要著眼于圖1的5個范疇。根據定義圖中的項目能夠決定軟件的全套需求。
不屬于軟件需求的事項
至此所說的軟件需求就是將“從外部觀點來看系統必須要做什么”傳達給開發者的事項。說明了從系統的輸入、輸出、功能、非功能特性以及設計方面限制等的側面來定義的事項。決定“系統會執行什么（What）”，但是重要的是不能決定“系統怎樣將其實現（How）”。
另外，必須注意軟件需求中不應該包含的信息。在軟件需求中不包含關于設計和實現的信息、系統測試方法的信息以及與項目管理相關的信息等（圖2）。
特別是關于設計和實現的信息，稍不注意就會介入，所以需要特別注意。如果需求中包含關于設計和體系結構的信息，則會被其信息所限制，對于應用程序來說就不能選擇最合適的設計方法。但是，有時系統內部已經確定的場合也有。例如，因為組織許可方面的因素，明確了數據庫必須使用DB2，這種情況下作為“設計限制（Design Constraints）”進行描述。
重要的是盡量減少設計上的限制。那樣，開發者只在最小限度的限制下能夠實現必要的功能、設計出滿足性能和可靠性的系統。
需求的詳細分類
關于軟件需求之前了解的情況，使用一句話來概括也會有多種。特別是可以按如下所示分為3種。
1)功能需求
2)非功能需求
3)設計限制
另外，如圖3所示通常取出Functionality（功能性）、Usability（易用性）、Reliability（可靠性）、Performance（性能）、Supportability（易支持性）的開頭字母以FURPS+形式來分類。FURPS+中最后的+表示不包含在FURPS中的設計方面的限制。該FURPS+用上述3種分類來說的話，各自相當于F是功能需求、URPS是非功能需求、+是設計限制。
根據上述形式進行分類，形成識別需求時和評價對需求的理解時的檢驗一覽表，可以防止遺漏和不完整性。
軟件非功能需求
到前一節為止我們了解了所說的“軟件需求”就是把系統在詳細基準下定義的需求，從黑匣子的觀點來描述系統能力的需求。另外軟件需求可以用FURPS+方式分類。但是對于開發能夠讓客戶滿意的系統不僅僅是軟件需求，掌握利害關系者的需求也是非常重要的。（利害關系者：擁有與項目有相關利害關系的人、特別是系統的用戶被列舉為重要的利害關系者）
眾所周知，為了有效地執行需求管理，作為詳細標準需求的“軟件需求”以外也作為需求來掌握，這一事項在經驗上是很有效的。也就是說，把需求的語言對象不僅僅是系統詳細定義的“軟件需求”，也擴大到了利害關系者的“原始需求(Needs)”。并且另外一點，作為比軟件需求抽象標準更高的需求，把“功能特性(Features)”也作為需求來掌握。有點麻煩但是倒入“需求類型”這一概念，其類型之一包括“原始需求”、“功能特性”，“軟件需求”。由于功能特性比軟件需求的抽象度要高，所以如果利用功能特性的話，就能很容易地把握系統整體，也就能輕松地管理開發范圍。
軟件非功能需求
到前一節為止我們了解了所說的“軟件需求”就是把系統在詳細基準下定義的需求，從黑匣子的觀點來描述系統能力的需求。另外軟件需求可以用FURPS+方式分類。但是對于開發能夠讓客戶滿意的系統不僅僅是軟件需求，掌握利害關系者的需求也是非常重要的。（利害關系者：擁有與項目有相關利害關系的人、特別是系統的用戶被列舉為重要的利害關系者）
眾所周知，為了有效地執行需求管理，作為詳細標準需求的“軟件需求”以外也作為需求來掌握，這一事項在經驗上是很有效的。也就是說，把需求的語言對象不僅僅是系統詳細定義的“軟件需求”，也擴大到了利害關系者的“原始需求(Needs)”。并且另外一點，作為比軟件需求抽象標準更高的需求，把“功能特性(Features)”也作為需求來掌握。有點麻煩但是倒入“需求類型”這一概念，其類型之一包括“原始需求”、“功能特性”，“軟件需求”。由于功能特性比軟件需求的抽象度要高，所以如果利用功能特性的話，就能很容易地把握系統整體，也就能輕松地管理開發范圍。
那樣的話，如圖4所示可以把原始需求、功能特性和軟件需求在3段的金字塔狀中按照每個需求類型進行體系化描述。以訂單管理業務的應用程序為例，如圖5所示按照各自的需求類型分別描述需求樣本。
重新簡單地總結一下“需求類型”吧。首先，為了能夠準確地解決客戶的問題，把在系統背后的“原始需求”以不依賴系統的形式來掌握。并且，以掌握系統大功能總括的“功能特性”為基礎，來理解系統整體，也就容易進行開發范圍的管理。更進一步說，以定義作為系統詳細的“軟件需求”為基礎，開發者應該可以對系統進行設計、實現以及測試。特別是根據“原始需求”記錄的事項、該“功能特性”最初是從哪里來的？“軟件需求”是為了什么而存在的？具有這樣的觀點是非常重要的。比如，讓開發者變更依賴內容時，從“原始需求”的視點來看，可以討論實現方法和不用討論實現方法，這兩者存在很大差異。
那么，這回關于需求的分類進行了了解。下回對于需求管理程序的流程以及對作業流程圖進行整理。
