任甲林  

摘要

本文介紹了需求管理的必要性，從實(shí)踐的角度給出了進(jìn)行有效的需求管理的5個基本原則，并介紹了進(jìn)行需求變更控制的一些方法。

關(guān)鍵詞

需求管理，需求漸變，需求復(fù)用，優(yōu)先級，分類管理

在CMM®1.1版本中第一個KPA是需求管理，是CMM®2級的標(biāo)準(zhǔn)文本中論述篇幅最少的一個KPA，這也是在CMM®2級中最容易讓開發(fā)人員與項(xiàng)目經(jīng)理提出疑問的一個KPA：為什么需求需要管理？如何進(jìn)行有效的需求管理？

1為什么需要需求管理？

需求是整個項(xiàng)目的最關(guān)鍵的一個輸入，和傳統(tǒng)的生產(chǎn)企業(yè)相比較，軟件的需求具有模糊性、不確定性、變化性和主觀性的特點(diǎn)，他不像生產(chǎn)汽車、電腦等硬件的需求，是有形的、客觀的、可描述的、可檢測的。軟件需求是軟件項(xiàng)目難把握的問題：

? 需求的描述方式問題

如何使項(xiàng)目組的開發(fā)人員、客戶、最終用戶等各個方面各個層次的人員能夠清楚的讀懂需求文檔？曾經(jīng)有多個項(xiàng)目經(jīng)理向我抱怨，在用戶方進(jìn)行的需求評審會經(jīng)常是走形式，因?yàn)橛脩舾静蝗ヂ犓x那上百頁的需求文檔。這能怪客戶嗎？問題出在需求是如何描述的？需求管理的評審會是如何組織的？不同層次的客戶（用戶）關(guān)心的問題是不一樣的，想要每個客戶都成為需求專家是不現(xiàn)實(shí)的。

? 需求的完備程度問題

需求如何做到?jīng)]有遺漏？如何準(zhǔn)確劃定系統(tǒng)的范圍？這確實(shí)是一個兩難問題，稍微大一點(diǎn)的系統(tǒng)要想窮舉需求幾乎是不可能的，每次開需求評審會時，總會冒出新的需求，以至于系統(tǒng)沒有一個準(zhǔn)確的范圍界定。即使是這樣，系統(tǒng)還是要開發(fā)，沒辦法，系統(tǒng)的范圍還要硬性的劃定一個，而建立一個基線。

? 需求開發(fā)的工期問題

在需求上花費(fèi)了大量的時間（而不是人*工時，因?yàn)樾枨箅A段人多了也沒有作用），客戶、軟件公司是否能夠忍受？為了確保需求的正確性，完備性，項(xiàng)目經(jīng)理往往堅(jiān)持要在需求階段花費(fèi)大量的時間，但是客戶與公司的高層領(lǐng)導(dǎo)卻會為項(xiàng)目遲遲看不到實(shí)際可運(yùn)行的軟件擔(dān)心不已！他們往往會逼迫項(xiàng)目組盡快往前推進(jìn)，而項(xiàng)目組的成員往往也會為系統(tǒng)復(fù)雜的善變的需求折騰的筋疲力盡，他們也希望盡快結(jié)束此階段。

? 需求的細(xì)致程度問題

需求到底描述到多細(xì)，才算可以結(jié)束了？仁者見仁，智者見智，并沒有定論，如果時間允許，要想細(xì)總可以細(xì)下去的。但是，需求的周期越長，可能的變化越多，對設(shè)計(jì)的限制越嚴(yán)格，對需求的共性提取要求越高，所以只要大家（客戶、用戶、需求分析人員、設(shè)計(jì)人員、測試人員）認(rèn)為描述清楚了，就可以進(jìn)入設(shè)計(jì)階段了。

? 需求的變化問題

在軟件開發(fā)過程中如果只有一條真理的話，那一定是：需求的變化是永恒的，需求不可能是完備的。軟件開發(fā)的過程實(shí)際上是同變化做斗爭的過程，需求的變更不一定是壞事，也有可能是好事，是商業(yè)機(jī)會，對市場敏感的人可以從需求的變化中發(fā)現(xiàn)市場機(jī)會。

需求變化的原因很多，如：

? 一開始沒有識別全，需要增加需求；

? 業(yè)務(wù)發(fā)生了變化，需求必須變化；

? 需求錯誤；

? 需求不清楚；

需求的變化問題是每個開發(fā)人員、每個項(xiàng)目經(jīng)理都遇到的問題，也是最頭痛的問題，一旦發(fā)生了需求變化，你不得不來修改你的設(shè)計(jì)、重寫你的代碼、修改你的測試用例、調(diào)整你的項(xiàng)目計(jì)劃等等，需求的變化好比是萬惡之源，為項(xiàng)目的正常的進(jìn)展帶來不盡的麻煩，怎么辦？管理它！使需求在受控的狀態(tài)下發(fā)生變化，而不是隨意變化，需求管理就是要按照標(biāo)準(zhǔn)的流程來控制需求的變化。

難題隨之而來，需求中的變化一般不是突發(fā)的革命性的變化，最常見的是“項(xiàng)目需求的漸變”（Project Scope Creep）問題，這種漸變很可能是客戶與開發(fā)方都沒有意識到的，當(dāng)達(dá)到一定層度時，雙方才驀然回首，發(fā)現(xiàn)已經(jīng)物是人非，換了一番天地。

2 需求管理的目標(biāo)

在CMM®1.1中，需求管理的目標(biāo)定義為：

1) 把軟件需求建立一個基線供軟件工程和管理使用。

2) 軟件計(jì)劃、活動和工作產(chǎn)品同軟件需求保持一致。

軟件需求作為軟件工程的基線是很容易理解的，而作為管理的基線可能有些人無法理解。從需求階段稍微向下一個階段延伸就會發(fā)現(xiàn)，軟件需求是軟件項(xiàng)目策劃的基礎(chǔ)，只有有了明確的項(xiàng)目需求，才能保證計(jì)劃中的任務(wù)識別的比較全面，否則計(jì)劃的可行性就大打折扣了。當(dāng)然，需求改變了，軟件計(jì)劃、軟件的開發(fā)活動、工作產(chǎn)品等就必然要發(fā)生變化，計(jì)劃、活動與工作產(chǎn)品必須與需求保持一致。

其實(shí)需求管理還有一個更高的目標(biāo)：

3) 軟件需求的復(fù)用。

筆者曾經(jīng)遇到過一位領(lǐng)域?qū)＜?，他在?0多年的領(lǐng)域工程經(jīng)驗(yàn)，積累了大量的領(lǐng)域需求，可是在其每進(jìn)行一次產(chǎn)品開發(fā)時，他總是感到他所理解的需求無法為與他配合的分析人員、設(shè)計(jì)人員所接受。當(dāng)我們一起來討論這個問題的時候，共同的一個觀點(diǎn)就是：沒有對需求進(jìn)行有效的管理，已經(jīng)形成的需求文檔沒有很好的復(fù)用。所以需求管理一個很重要的目標(biāo)應(yīng)是提高軟件需求的復(fù)用率。

3 需求管理的基本原則與方法

（1）必須與需求工程的其他活動緊密整合

就象在上面討論的那樣，談需求管理一定不能脫離需求工程，從完整意義上講，需求工程包括了：需求獲取、需求分析、需求描述、需求驗(yàn)證、需求管理，狹義的需求管理指已經(jīng)建立了軟件需求后，需求變更的管理，而廣義的需求管理自需求獲取階段已經(jīng)開始了。需求管理的難易層度、好壞和需求的獲取的質(zhì)量、需求分析的質(zhì)量、需求描述的方式、需求驗(yàn)證的充分性是密不可分。從狹義上來講需求管理關(guān)心的是需求管理過程的建立，在企業(yè)或項(xiàng)目組中需要有一套規(guī)范的需求管理過程，而實(shí)際上從項(xiàng)目經(jīng)理的角度上可能還有50%甚至更多的精力是關(guān)注結(jié)果的，所以對需求內(nèi)容的管理與對需求形式的管理是密不可分的。

（2）需求必須是文檔化的、正確的、新的、可管理的、可理解的

筆者曾經(jīng)被緊急委派主管一個已經(jīng)進(jìn)入了編碼后期階段的項(xiàng)目，該項(xiàng)目已經(jīng)換過2次項(xiàng)目經(jīng)理了，這是第3次更換項(xiàng)目經(jīng)理了，用戶方的IT部經(jīng)理馬上來找我抱怨：“我已經(jīng)是第3次來給你們講補(bǔ)貨申請的處理規(guī)則了！”。我只能表示抱歉，因?yàn)槲覠o法找到原來的需求描述，這是一個變更的需求，前任的項(xiàng)目經(jīng)理講他只是將當(dāng)時與用戶交流的需求記到2頁草稿紙上，不幸的是，那2頁珍貴的手稿現(xiàn)在已經(jīng)找不到了！更不幸的是，該IT部經(jīng)理是在轉(zhuǎn)述業(yè)務(wù)部門的需求，當(dāng)軟件開發(fā)完畢后，業(yè)務(wù)部門講“這不是我們最初給IT部反映的需求，我們說的不是這樣的！”。

所以需求必須有文檔來記錄，該文檔必須是正確的，是經(jīng)過驗(yàn)證的，是在受控的狀態(tài)下變更的。而很多開發(fā)人員會提這樣一個問題：簡單的系統(tǒng)就不用寫需求了吧？這是很多開發(fā)人員不寫需求的借口“這么簡單，說說就行了！”。其實(shí)簡單的系統(tǒng)未必簡單，想清楚、寫清楚、說清楚才說明真正把需求整理清楚了。有一次，我安排2名開發(fā)人員編寫一個單據(jù)錄入的模塊，僅給出了數(shù)據(jù)庫的設(shè)計(jì)，簡單說了一下模塊的需求，這兩名開發(fā)人員以前均做過類似的系統(tǒng)，在大家看來這是一個很簡單的系統(tǒng)，不需要太多的溝通，然后，當(dāng)系統(tǒng)交付時，才發(fā)現(xiàn)想象中的系統(tǒng)與現(xiàn)實(shí)的系統(tǒng)差距是如此之大，在需求提出者看來是想當(dāng)然的問題，開發(fā)人員卻全都忽略了！

（3）只要需求變化了，需求變更的影響就必須被評估

在上面我們談到需求漸變的問題，無論需求變化的多少，只要需求變化了就必須進(jìn)行評估，這是基本的原則?？刂菩枨鬂u變需要注意以下幾點(diǎn)：

? 需求一定要與投入有顯示的聯(lián)系，否則如果需求變更的成本由開發(fā)方來承擔(dān)，則項(xiàng)目需求的變更就成為必然了。人們常說世上沒有免費(fèi)的午餐，同樣也不應(yīng)該有免費(fèi)的需求變更。但是，接受需求變更目前卻是軟件開發(fā)商不得不咽下的苦果。所以，在項(xiàng)目的開始無論是開發(fā)方還是出資方都要明確這一條：需求變，軟件開發(fā)的投入也要變。

? 需求的變更要經(jīng)過出資者的認(rèn)可，需求的變更引起投入的變化，所以要通過出資者的認(rèn)可，這樣才會對需求的變更有成本的概念，能夠慎重地對待需求的變更。筆者曾經(jīng)經(jīng)歷過一個項(xiàng)目，為了避免項(xiàng)目的風(fēng)險，我們請了用戶代表全程參與了開發(fā)過程，結(jié)果此用戶代表在開發(fā)過程提出了大量的“小”的需求變更，當(dāng)開發(fā)人員按此需求變更修改了軟件時，在項(xiàng)目進(jìn)入現(xiàn)場實(shí)施階段時，卻有大量的這些變更需要改回去，問題就是出在我們的項(xiàng)目組成員視該用戶代表的需求為圣旨，卻忽略了需求是否經(jīng)過了客戶方真正有決策權(quán)的人員的認(rèn)可。

? 小的需求變更也要經(jīng)過正規(guī)的需求管理流程，否則會積少成多。在實(shí)踐中，人們往往不愿意為小的需求變更去執(zhí)行正規(guī)的需求管理過程，認(rèn)為降低了開發(fā)效率，浪費(fèi)了時間。正式由于這種觀念才使需求的漸變不可控，才導(dǎo)致項(xiàng)目的失敗。

? 明確的需求與范圍定義并不會阻止需求的變更。并非對需求定義的越細(xì)，越能避免需求的漸變，這是2個層面的問題。太細(xì)的需求定義對需求漸變沒有任何效果。因?yàn)樾枨蟮淖兓怯篮愕?，并非由于需求寫?xì)了，它就不會變化了。

? 注意溝通的技巧。實(shí)際情況是用戶、開發(fā)者都認(rèn)識了到了上面的幾點(diǎn)問題，但是由于需求的變更可能來自客戶方、也可能來自開發(fā)方，作為客戶他們可能不愿意為需求的變更付出更多的投資，開發(fā)方有可能是主動的變更了需求，他們的目的可能是使軟件做的更“精致”，于是作為需求管理者、項(xiàng)目經(jīng)理需要采用各種溝通技巧來使項(xiàng)目的各方各得其所。

在一個項(xiàng)目組中必須明確定義需求管理員，由他負(fù)責(zé)整個項(xiàng)目的需求管理工作，確保在發(fā)生需求變更時，受影響的工作產(chǎn)品必須修改并與需求的變更保持一致，受影響的其他組和客戶必須協(xié)商一致。

（4）需求必須分優(yōu)先級

需求的優(yōu)先級可能比需求本身更加重要。在我進(jìn)行的每一次產(chǎn)品開發(fā)過程中，都遇到過這個問題：負(fù)責(zé)產(chǎn)品需求的領(lǐng)域?qū)＜伊_列了長長的功能列表，每個功能都是需求的，都是不可或缺的，當(dāng)排出進(jìn)度表后，發(fā)現(xiàn)工期是公司不能接受的，沒辦法，必須裁剪需求。因此，沒有需求就不會有產(chǎn)品，沒有產(chǎn)品就沒有利潤，需求過多，反而可能是陷阱，只有投入，沒有產(chǎn)出。一個好的項(xiàng)目需求，必須有需求的優(yōu)先級，便于進(jìn)行項(xiàng)目的整體平衡。

（5）需求一定要分類管理

在做工程項(xiàng)目的時候一定要給需求分出層次，不同層次的需求側(cè)重點(diǎn)是不一樣的、描述的方式是不同的、管理的方式也是不同的。比如說在企業(yè)里高層領(lǐng)導(dǎo)提出來的是目標(biāo)性需求，中層管理人員的管理人員提出來的是具體的業(yè)務(wù)流程的需求，而作業(yè)人員提出來的更側(cè)重于操作性的需求。對于目標(biāo)性的需求可能采用簡短的幾句話就可以描述清楚，但這是項(xiàng)目的決策性需求，需要很穩(wěn)定，不能輕易更改，在確定的時候需要慎之又慎。目標(biāo)性需求對于雙方所有的人都是約束，而且它不僅僅含有軟件需求，更重要的是對整個系統(tǒng)的需求。對于業(yè)務(wù)需求而言也是基本穩(wěn)定的，它一般覆蓋系統(tǒng)的局部，可以比較詳細(xì)的用文字描述出來，需求之間的關(guān)系錯綜復(fù)雜，這類需求一般也變化比較多，需要分析人員、需求管理者花費(fèi)較大的精力來描述、來管理。操作性需求適合采用原型的方法來描述，可以比較直觀的刻畫出來，盡管變化多，但是很少有結(jié)構(gòu)性的變化。對于需求還可以從其他方面來分類，如：功能性需求與非功能性需求、技術(shù)性需求與非技術(shù)需求等，對需求的分類管理有助于我們把握需求的本質(zhì)，分析不同類需求的特點(diǎn)，根據(jù)不同類的需求的特點(diǎn)采用不同的管理方法。