至今所不為熟悉的需求管理的基礎(chǔ)
這則報(bào)道是以年輕IT工程師為對(duì)象（參加工作2-4年左右），以能夠使其理解軟件需求管理的基礎(chǔ)為目標(biāo)。為了描述更具體的內(nèi)容，在本報(bào)道中提出了關(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à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è)員業(yè)務(wù)處理效率的應(yīng)用程序。在該項(xiàng)目中擁有高超技能的開發(fā)者進(jìn)行了極優(yōu)秀的設(shè)計(jì)，也充分考慮了其擴(kuò)展性。但是，由于應(yīng)用程序?qū)τ谟脩簦I業(yè)員）來說非常難以使用，所以很多營業(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)目的成功挖掘。
另一方面、從數(shù)據(jù)中也能說明需求管理對(duì)項(xiàng)目的成功有很大的貢獻(xiàn)。作為軟件開發(fā)現(xiàn)場的調(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中將需求和需求管理如下定義。
“需求”的定義非常簡單。所謂定義需求就是定義“應(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é)議也是非常重要的。
需求管理不簡單
如果是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ì)的全體成員中共享也不是簡單的事情。
如上、發(fā)現(xiàn)了很多問題，但是為了妥當(dāng)?shù)靥幚磉@些問題，要求對(duì)需求管理進(jìn)行體系化的程序。下回、在開始需求管理具體的程序之前，先要了解一下要求的各個(gè)種類和級(jí)別。
第2回：軟件需求的詳細(xì)分類
在上回的 “至今所不為熟悉的需求管理的基礎(chǔ)”中只接觸了關(guān)于需求的非常模糊的定義。在這回我們來了解一下更詳細(xì)的需求吧。首先看一看如何描述才能把系統(tǒng)需求完整記錄，然后再逐步深入。
需求可以描述系統(tǒng)的什么內(nèi)容？
定義系統(tǒng)的詳細(xì)需求在RUP中稱為“軟件需求（Software Requirements）”。也就是說，如果完整的描述了軟件需求的話，系統(tǒng)需求也就完整描述了。
軟件需求定義是從把系統(tǒng)作為黑匣子的觀點(diǎn)出發(fā)，描述系統(tǒng)為用戶、設(shè)備或者其他系統(tǒng)提供的執(zhí)行能力/狀態(tài)的內(nèi)容。也就是說，要描述軟件需求的話，需要考慮從系統(tǒng)外部來了解的狀態(tài)下（不知道系統(tǒng)中會(huì)變成什么什么狀態(tài)），完整地描述其要執(zhí)行什么。為了完整地描述系統(tǒng)，需要著眼于圖1的5個(gè)范疇。根據(jù)定義圖中的項(xiàng)目能夠決定軟件的全套需求。
不屬于軟件需求的事項(xiàng)
至此所說的軟件需求就是將“從外部觀點(diǎn)來看系統(tǒng)必須要做什么”傳達(dá)給開發(fā)者的事項(xiàng)。說明了從系統(tǒng)的輸入、輸出、功能、非功能特性以及設(shè)計(jì)方面限制等的側(cè)面來定義的事項(xiàng)。決定“系統(tǒng)會(huì)執(zhí)行什么（What）”，但是重要的是不能決定“系統(tǒng)怎樣將其實(shí)現(xiàn)（How）”。
另外，必須注意軟件需求中不應(yīng)該包含的信息。在軟件需求中不包含關(guān)于設(shè)計(jì)和實(shí)現(xiàn)的信息、系統(tǒng)測(cè)試方法的信息以及與項(xiàng)目管理相關(guān)的信息等（圖2）。
特別是關(guān)于設(shè)計(jì)和實(shí)現(xiàn)的信息，稍不注意就會(huì)介入，所以需要特別注意。如果需求中包含關(guān)于設(shè)計(jì)和體系結(jié)構(gòu)的信息，則會(huì)被其信息所限制，對(duì)于應(yīng)用程序來說就不能選擇最合適的設(shè)計(jì)方法。但是，有時(shí)系統(tǒng)內(nèi)部已經(jīng)確定的場合也有。例如，因?yàn)榻M織許可方面的因素，明確了數(shù)據(jù)庫必須使用DB2，這種情況下作為“設(shè)計(jì)限制（Design Constraints）”進(jìn)行描述。
重要的是盡量減少設(shè)計(jì)上的限制。那樣，開發(fā)者只在最小限度的限制下能夠?qū)崿F(xiàn)必要的功能、設(shè)計(jì)出滿足性能和可靠性的系統(tǒng)。
需求的詳細(xì)分類
關(guān)于軟件需求之前了解的情況，使用一句話來概括也會(huì)有多種。特別是可以按如下所示分為3種。
1)功能需求
2)非功能需求
3)設(shè)計(jì)限制
另外，如圖3所示通常取出Functionality（功能性）、Usability（易用性）、Reliability（可靠性）、Performance（性能）、Supportability（易支持性）的開頭字母以FURPS+形式來分類。FURPS+中最后的+表示不包含在FURPS中的設(shè)計(jì)方面的限制。該FURPS+用上述3種分類來說的話，各自相當(dāng)于F是功能需求、URPS是非功能需求、+是設(shè)計(jì)限制。
根據(jù)上述形式進(jìn)行分類，形成識(shí)別需求時(shí)和評(píng)價(jià)對(duì)需求的理解時(shí)的檢驗(yàn)一覽表，可以防止遺漏和不完整性。
軟件非功能需求
到前一節(jié)為止我們了解了所說的“軟件需求”就是把系統(tǒng)在詳細(xì)基準(zhǔn)下定義的需求，從黑匣子的觀點(diǎn)來描述系統(tǒng)能力的需求。另外軟件需求可以用FURPS+方式分類。但是對(duì)于開發(fā)能夠讓客戶滿意的系統(tǒng)不僅僅是軟件需求，掌握利害關(guān)系者的需求也是非常重要的。（利害關(guān)系者：擁有與項(xiàng)目有相關(guān)利害關(guān)系的人、特別是系統(tǒng)的用戶被列舉為重要的利害關(guān)系者）
眾所周知，為了有效地執(zhí)行需求管理，作為詳細(xì)標(biāo)準(zhǔn)需求的“軟件需求”以外也作為需求來掌握，這一事項(xiàng)在經(jīng)驗(yàn)上是很有效的。也就是說，把需求的語言對(duì)象不僅僅是系統(tǒng)詳細(xì)定義的“軟件需求”，也擴(kuò)大到了利害關(guān)系者的“原始需求(Needs)”。并且另外一點(diǎn)，作為比軟件需求抽象標(biāo)準(zhǔn)更高的需求，把“功能特性(Features)”也作為需求來掌握。有點(diǎn)麻煩但是倒入“需求類型”這一概念，其類型之一包括“原始需求”、“功能特性”，“軟件需求”。由于功能特性比軟件需求的抽象度要高，所以如果利用功能特性的話，就能很容易地把握系統(tǒng)整體，也就能輕松地管理開發(fā)范圍。
軟件非功能需求
到前一節(jié)為止我們了解了所說的“軟件需求”就是把系統(tǒng)在詳細(xì)基準(zhǔn)下定義的需求，從黑匣子的觀點(diǎn)來描述系統(tǒng)能力的需求。另外軟件需求可以用FURPS+方式分類。但是對(duì)于開發(fā)能夠讓客戶滿意的系統(tǒng)不僅僅是軟件需求，掌握利害關(guān)系者的需求也是非常重要的。（利害關(guān)系者：擁有與項(xiàng)目有相關(guān)利害關(guān)系的人、特別是系統(tǒng)的用戶被列舉為重要的利害關(guān)系者）
眾所周知，為了有效地執(zhí)行需求管理，作為詳細(xì)標(biāo)準(zhǔn)需求的“軟件需求”以外也作為需求來掌握，這一事項(xiàng)在經(jīng)驗(yàn)上是很有效的。也就是說，把需求的語言對(duì)象不僅僅是系統(tǒng)詳細(xì)定義的“軟件需求”，也擴(kuò)大到了利害關(guān)系者的“原始需求(Needs)”。并且另外一點(diǎn)，作為比軟件需求抽象標(biāo)準(zhǔn)更高的需求，把“功能特性(Features)”也作為需求來掌握。有點(diǎn)麻煩但是倒入“需求類型”這一概念，其類型之一包括“原始需求”、“功能特性”，“軟件需求”。由于功能特性比軟件需求的抽象度要高，所以如果利用功能特性的話，就能很容易地把握系統(tǒng)整體，也就能輕松地管理開發(fā)范圍。
那樣的話，如圖4所示可以把原始需求、功能特性和軟件需求在3段的金字塔狀中按照每個(gè)需求類型進(jìn)行體系化描述。以訂單管理業(yè)務(wù)的應(yīng)用程序?yàn)槔鐖D5所示按照各自的需求類型分別描述需求樣本。
重新簡單地總結(jié)一下“需求類型”吧。首先，為了能夠準(zhǔn)確地解決客戶的問題，把在系統(tǒng)背后的“原始需求”以不依賴系統(tǒng)的形式來掌握。并且，以掌握系統(tǒng)大功能總括的“功能特性”為基礎(chǔ)，來理解系統(tǒng)整體，也就容易進(jìn)行開發(fā)范圍的管理。更進(jìn)一步說，以定義作為系統(tǒng)詳細(xì)的“軟件需求”為基礎(chǔ)，開發(fā)者應(yīng)該可以對(duì)系統(tǒng)進(jìn)行設(shè)計(jì)、實(shí)現(xiàn)以及測(cè)試。特別是根據(jù)“原始需求”記錄的事項(xiàng)、該“功能特性”最初是從哪里來的？“軟件需求”是為了什么而存在的？具有這樣的觀點(diǎn)是非常重要的。比如，讓開發(fā)者變更依賴內(nèi)容時(shí)，從“原始需求”的視點(diǎn)來看，可以討論實(shí)現(xiàn)方法和不用討論實(shí)現(xiàn)方法，這兩者存在很大差異。
那么，這回關(guān)于需求的分類進(jìn)行了了解。下回對(duì)于需求管理程序的流程以及對(duì)作業(yè)流程圖進(jìn)行整理。
