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

　　（注：Rational Unified Process：是IBM Rational的軟件開發(fā)方法論，作為面向?qū)ο箝_發(fā)方法論而聞名）

　　為什么要進(jìn)行需求管理？

　　為什么要進(jìn)行需求管理？用一句話來概述就是因?yàn)楣芾硇枨罂梢院艽蟪潭鹊貋碜笥翼?xiàng)目的成功。首先，來考慮一般的項(xiàng)目目標(biāo)吧。請(qǐng)看下面的定義。

　　項(xiàng)目目標(biāo)

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

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

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

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

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

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

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

　　需求（Requirement）

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

　　需求管理（Requirement Management）

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

　　關(guān)于能夠產(chǎn)生變更的需求、形成客戶和開發(fā)團(tuán)隊(duì)之間的協(xié)議，為了維護(hù)系統(tǒng)研究

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

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

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

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

　　需求管理不簡(jiǎn)單

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

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

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

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

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

　　◎ “難以將需求文檔化”

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

　　◎ “難以追加需求變更”

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

　　如上、發(fā)現(xiàn)了很多問題，但是為了妥當(dāng)?shù)靥幚磉@些問題，要求對(duì)需求管理進(jìn)行體系化的程序。下回、在開始需求管理具體的程序之前，先要了解一下要求的各個(gè)種類和級(jí)別。