新產(chǎn)品開(kāi)發(fā)的需求管理
作者: 來(lái)源: 文字大小:[大][中][小]
需求管理（Requirement management）是完整管理模式中的一環(huán)，同其他特性諸如完整性、一致性等不可分割，彼此相關(guān)而成一體。一套需求管理應(yīng)當(dāng)是已知系統(tǒng)需求的完整體現(xiàn)，每部分解決方案都是對(duì)總體需求一定比例的滿足（甚至是充分滿足），僅僅解決部分需求是沒(méi)有意義的。對(duì)關(guān)鍵需求的疏忽很可能是災(zāi)難性的，試想一架飛機(jī)的安全設(shè)計(jì)不過(guò)關(guān)將會(huì)帶來(lái)什么樣的后果。不同的需求組合起來(lái)，構(gòu)成了一套完整的需求模型。用戶需求決定了系統(tǒng)設(shè)計(jì)所要解決的問(wèn)題，所要帶來(lái)的結(jié)果?？梢哉f(shuō)，需求管理指明了系統(tǒng)開(kāi)發(fā)所要做和必須做的每一件事，指明了所有設(shè)計(jì)應(yīng)該提供的功能和必然受到的制約。
需求管理的過(guò)程，從需求獲取開(kāi)始貫于整個(gè)項(xiàng)目生命周期，力圖實(shí)現(xiàn)最終產(chǎn)品同需求的最佳結(jié)合。通過(guò)對(duì)需求管理在項(xiàng)目進(jìn)程中實(shí)施的不同任務(wù)進(jìn)行分析，我們可以看出需求管理所起的作用。
需求管理本就是一個(gè)動(dòng)態(tài)的過(guò)程，離開(kāi)了能動(dòng)的、變化的系統(tǒng)進(jìn)程而空談需求管理，無(wú)異于紙上談兵。
需求管理恰如裁縫的量體裁衣，它直接關(guān)系到最終產(chǎn)品的成型。僅從字面出發(fā)，如果一個(gè)產(chǎn)品滿足了客戶需求，那它無(wú)疑就是成功的。需求管理的過(guò)程，從需求分析開(kāi)始貫穿整個(gè)項(xiàng)目始終，力圖實(shí)現(xiàn)最終產(chǎn)品同需求性的最佳結(jié)合（參見(jiàn)Figure 1）。通過(guò)對(duì)需求管理在項(xiàng)目進(jìn)程中實(shí)施的不同任務(wù)進(jìn)行分析，我們可以看出需求管理所起的作用。
需求管理能夠確證：
●我們確知客戶的需求是什么（質(zhì)量）；
●滿足客戶需求的最佳解決辦法（統(tǒng)一性）；
著名學(xué)者Crosby對(duì)于質(zhì)量的定義是"同需求保持統(tǒng)一"。從這個(gè)意義上說(shuō)，需求管理正是從質(zhì)量出發(fā)以確定需求。每個(gè)人都應(yīng)當(dāng)始終明白他們所做的具體任務(wù)其意義何在。然而，在一個(gè)產(chǎn)品的生命周期里，其需求性是能動(dòng)的，是處于變化之中的。
對(duì)于系統(tǒng)工程沒(méi)有嚴(yán)格統(tǒng)一的定義，因此很難找到足夠的數(shù)據(jù)以說(shuō)明系統(tǒng)工程所起的作用。有些致力于研究需求分析的組織認(rèn)為，一項(xiàng)開(kāi)發(fā)計(jì)劃應(yīng)當(dāng)至少將8-15%的資源投入到系統(tǒng)工程方面。如果低于這一標(biāo)準(zhǔn)，將很可能導(dǎo)致無(wú)法對(duì)客戶群做出準(zhǔn)確把握。如果該項(xiàng)開(kāi)發(fā)計(jì)劃含有許多創(chuàng)新或?qū)嶒?yàn)的成分，那么這一百分比還應(yīng)當(dāng)適度提高。
一、概述
定義需求（Define Requirement）
在項(xiàng)目進(jìn)展過(guò)程中，如何區(qū)分用戶需求與需求分析中需求定義呢？
當(dāng)完成用戶需求調(diào)查后，首先對(duì)《用戶需求說(shuō)明書》進(jìn)行細(xì)化，對(duì)比較復(fù)雜的用戶需求進(jìn)行建模分析，以幫助軟件開(kāi)發(fā)人員更好地理解需。例如采用Rational 的Rose工具進(jìn)行需求的建模分析。如果使用工具進(jìn)行建模分析，對(duì)需求分析人員的要求比較高。
當(dāng)完成需求的定義及分析后，需要將此過(guò)程書面化，要遵循既定的規(guī)范將需求形成書面的文檔，我們通常稱之為《需求分析說(shuō)明書》。
邀請(qǐng)同行專家和用戶（包括客戶和最終用戶）一起評(píng)審《需求規(guī)格說(shuō)明書》，盡最大努力使《需求規(guī)格說(shuō)明書》能夠正確無(wú)誤地反映用戶的真實(shí)意愿。需求評(píng)審之后，開(kāi)發(fā)方和客戶方的責(zé)任人對(duì)《需求規(guī)格說(shuō)明書》作書面承諾。具體的同行評(píng)審詳見(jiàn)需求評(píng)審章節(jié)。
需求確認(rèn)(Requirement Validate)
需求確認(rèn)是需求管理過(guò)程中的一種常用手段，也是需求控制的五一節(jié)之一；確認(rèn)有兩個(gè)層面的意思，第一是進(jìn)行系統(tǒng)需求調(diào)查與分析的人員與客戶間的一種溝通，通過(guò)溝通從而對(duì)需求不一致的進(jìn)行剔除；另外一個(gè)層面的意思是指，對(duì)于雙方達(dá)成共同理解或獲得用戶認(rèn)可的部分，雙方需要進(jìn)行承諾。
建立需求狀態(tài)(Establish Requirement State)
何謂需求狀態(tài)；顧名思義，狀態(tài)也就是一種事物或?qū)嶓w在某一個(gè)時(shí)刻或點(diǎn)所處的情況，此處要講的需求狀態(tài)是指用戶需求的一種狀態(tài)變換過(guò)程。
為什么要建立需求狀態(tài)？在整個(gè)生命周期中，存在著有幾種不同的情況，在需求調(diào)查人員或系統(tǒng)分析人員進(jìn)行需求調(diào)查時(shí)，客戶存在的需求可能有多種，一類是客戶可以明確且清楚的提出的需求；一類是客戶知道需要做些什么，但又不能確定的需求；另一類是客戶本身可以得出這類需求，但需求的業(yè)務(wù)不明確，還需要等待外部信息。還有是客戶本身也說(shuō)不清楚的。
對(duì)于這些需求，在開(kāi)發(fā)進(jìn)展的過(guò)程中，存在著以下幾種情況:
有可能要取消的
有的因?yàn)椴幻鞔_而可以后延的，同時(shí)可能轉(zhuǎn)化為被取消的需求與客戶經(jīng)過(guò)溝通或確認(rèn)的，此處有兩種情況，一類是確認(rèn)雙方達(dá)成共識(shí)，另一種情況是還需要再進(jìn)一步溝通的。
下面是一個(gè)簡(jiǎn)單的狀態(tài)例子：
CLOSED：經(jīng)過(guò)確認(rèn)，雙方認(rèn)可并達(dá)成共識(shí)；
OPEN:雙方確認(rèn)，但沒(méi)有達(dá)成共識(shí)的需求；
待定：客戶提出需求，但雙方?jīng)]有經(jīng)過(guò)溝通或確認(rèn)；
需求評(píng)審(Requirement Review)
對(duì)工作產(chǎn)品的評(píng)審有兩類方式，一類是正式技術(shù)評(píng)審，也稱同行評(píng)審，另一類是非正式技術(shù)評(píng)審。對(duì)于任何重要的工作產(chǎn)品，都應(yīng)該至少執(zhí)行一次正式技術(shù)評(píng)審。在進(jìn)行正式評(píng)審前，需要有人員對(duì)其要進(jìn)行評(píng)審的工作產(chǎn)品進(jìn)行把關(guān)，確認(rèn)其是否具備進(jìn)入評(píng)審的初步條件。
需求評(píng)審的規(guī)程與其它重要工作產(chǎn)品（如系統(tǒng)設(shè)計(jì)文檔、源代碼）的評(píng)審規(guī)程非常相似，主要區(qū)別在于評(píng)審人員的組成不同。前者由開(kāi)發(fā)方和客戶方的代表共同組成，而后者通常來(lái)源于開(kāi)發(fā)方內(nèi)部。
有人問(wèn)：需求評(píng)審究竟評(píng)審什么？要細(xì)到什么程度？怎么樣進(jìn)行？
嚴(yán)格地講，應(yīng)當(dāng)檢查需求文檔中的每一個(gè)需求，每一行文字，每一張圖表。評(píng)判需求優(yōu)劣的主要指標(biāo)有：正確性、清晰性、無(wú)二義性、一致性、必要性、完整性、可實(shí)現(xiàn)性、可驗(yàn)證性、可測(cè)性。如果有可能，最好可以制定評(píng)審的檢查表。
需求評(píng)審面臨的困難及對(duì)策如下：
需求評(píng)審的一個(gè)通病是“虎頭蛇尾”。需求評(píng)審的確乏味，也比較費(fèi)腦子。剛開(kāi)始評(píng)審時(shí)，大家都比較認(rèn)真，越到后頭越馬虎。當(dāng)需求文檔很長(zhǎng)時(shí)，幾乎沒(méi)人能夠堅(jiān)持到最后。會(huì)議主持人事先要強(qiáng)調(diào)需求評(píng)審的重要性：認(rèn)真評(píng)審一小時(shí)可能會(huì)避免將來(lái)數(shù)十天的“返工”，讓大家足夠重視。評(píng)審組長(zhǎng)還要設(shè)法避免大家在昏昏沉沉中評(píng)審。如果評(píng)審時(shí)間比較長(zhǎng)，建議每隔兩小時(shí)休息一次。另外，如果系統(tǒng)比較大，也可以細(xì)分成不同的部分分別進(jìn)行，嚴(yán)格控制每一次評(píng)審的文檔規(guī)模及持續(xù)時(shí)間。
需求評(píng)審涉及的人員可能比較多，有些時(shí)候讓這么多人聚在一起花費(fèi)比較長(zhǎng)的時(shí)間開(kāi)會(huì)并不容易（例如有些人可能出差在外，有些人可能事務(wù)纏身）。沒(méi)有必要把所有事情擠在一塊做，需求開(kāi)發(fā)是循序漸進(jìn)的過(guò)程，需求評(píng)審也可以分段進(jìn)行。這樣每次評(píng)審的時(shí)間比較短，參加評(píng)審的人員也少一些，組織會(huì)議就比較容易。對(duì)于需求的工作產(chǎn)品《需求規(guī)格說(shuō)明書》，我們可以標(biāo)明幾種文檔狀態(tài)，如草稿狀態(tài)。評(píng)審狀態(tài)，初始狀態(tài)等。只有進(jìn)入評(píng)審狀態(tài)時(shí)，我們可以用不同的方式來(lái)對(duì)文檔進(jìn)行評(píng)審。但當(dāng)其評(píng)審狀態(tài)轉(zhuǎn)化為初始狀態(tài)時(shí)，需要進(jìn)行嚴(yán)格的正式的同行評(píng)審。
開(kāi)評(píng)審會(huì)議時(shí)經(jīng)常會(huì)“跑題”，導(dǎo)致評(píng)審效率很低。有時(shí)話匣子一打開(kāi)后關(guān)不上，大家越扯越遠(yuǎn)，結(jié)果評(píng)審會(huì)議變成了聊天會(huì)議。主持人應(yīng)當(dāng)控制話題，避免大家討論與主題無(wú)關(guān)的東西。對(duì)于自主研發(fā)的產(chǎn)品，由于需求評(píng)審人員大部分是開(kāi)發(fā)人員，大家會(huì)不知不覺(jué)地談?wù)撥浖?ldquo;如何做”。由于需求是否“可實(shí)現(xiàn)、可驗(yàn)證、可測(cè)試”本來(lái)就屬于需求評(píng)審的范疇，所以強(qiáng)制大家“只談做什么，不談怎么做”幾乎是不可能的。那么，在需求的評(píng)審會(huì)上，需要允許開(kāi)發(fā)人員談如何做，但不需太細(xì)，適而可止。同時(shí)，評(píng)審會(huì)必須明確一位評(píng)審組長(zhǎng)，對(duì)時(shí)間與問(wèn)題進(jìn)行控制。
開(kāi)評(píng)審會(huì)議時(shí)經(jīng)常會(huì)發(fā)生爭(zhēng)議。適當(dāng)?shù)臓?zhēng)議有利于澄清問(wèn)題，比什么東西都一致贊成要好。然而當(dāng)爭(zhēng)議變?yōu)闋?zhēng)吵時(shí)就壞事了。爭(zhēng)吵不僅對(duì)評(píng)審工作沒(méi)有好處，而且會(huì)無(wú)意中傷害同事們的感情。同時(shí)也解決不了問(wèn)題。所以，在評(píng)審會(huì)的過(guò)程中，我們要盡可能的是在闡述事實(shí)與證據(jù)，而并不是從你心底要如何地說(shuō)服別人。
人們?cè)诤芏鄷r(shí)候分不清楚自己究竟是“堅(jiān)持真理”還是“固執(zhí)己見(jiàn)”。毫不妥協(xié)或者輕易妥協(xié)都不是好辦法。我們應(yīng)當(dāng)養(yǎng)成良好的習(xí)慣：不要一棍子打死異己的觀點(diǎn)，嘗試著讓自己站在他人的立場(chǎng)思考問(wèn)題，這樣你會(huì)找到比較滿意的答案。試著從不同的角度去看同樣的問(wèn)題。
需求承諾（Requirement Consent）
什么是需求承諾，是指開(kāi)發(fā)方和客戶方的責(zé)任人對(duì)通過(guò)了同行評(píng)審的需求階段的工作產(chǎn)品，作出承諾，同時(shí)該承諾具有商業(yè)合同的同等效果。 需求承諾如下：
不少人會(huì)草率地對(duì)待需求承諾：不就是在一張紙的最后一行文字下面簽字嗎，反正已經(jīng)評(píng)審過(guò)了，我就簽吧。但他將來(lái)變更需求時(shí)可能會(huì)表示不瞞：“不錯(cuò)，我是簽字了，但是我并沒(méi)有閱讀文檔。是你們要我在文檔上簽字的，我是相信你們才這么做的。”為了避免發(fā)生此類糾紛，人們?cè)谧鞒龀兄Z之前務(wù)必要認(rèn)真閱讀文檔，一定要明白簽字意味著什么。
需求跟蹤(Requirement Track)
為什么要進(jìn)行需求跟蹤？在整個(gè)開(kāi)發(fā)過(guò)程中，進(jìn)行需求跟蹤的目的是為了建立和維護(hù)從用戶需求開(kāi)始到測(cè)試之間的一致性與完整性。確保所有的實(shí)現(xiàn)是以用戶需求為基礎(chǔ)。對(duì)于需求實(shí)現(xiàn)是否全部的覆蓋。同時(shí)確保所有的輸出與用戶需求的符合性。
需求跟蹤有兩種方式，正向跟蹤與逆向跟蹤：
正向跟蹤：以用戶需求為切入點(diǎn)，檢查《用戶需求說(shuō)明書》或《需求規(guī)格說(shuō)明書》中的每個(gè)需求是否都能在后繼工作產(chǎn)品中找到對(duì)應(yīng)點(diǎn)。
逆向跟蹤：檢查設(shè)計(jì)文檔、代碼、測(cè)試用例等工作產(chǎn)品是否都能在《需求規(guī)格說(shuō)明書》中找到出處。
正向跟蹤和逆向跟蹤合稱為“雙向跟蹤”。不論采用何種跟蹤方式，都要建立與維護(hù)《需求跟蹤矩陣》。需求跟蹤矩陣保存了需求與后續(xù)開(kāi)發(fā)過(guò)程輸出的對(duì)應(yīng)關(guān)系。矩陣單元之間可能存在“一對(duì)一”、“一對(duì)多”或“多對(duì)多”的關(guān)系。
使用需求跟蹤矩陣的優(yōu)點(diǎn)是很容易發(fā)現(xiàn)需求與后續(xù)工作產(chǎn)品之間的不一致，有助于開(kāi)發(fā)人員及時(shí)糾正偏差，避免干冤枉活。
很多人有這樣的誤解：如果依照“需求開(kāi)發(fā)－系統(tǒng)設(shè)計(jì)－編碼－測(cè)試”這樣的順序開(kāi)發(fā)產(chǎn)品，由于每一步的輸出就是下一步的輸入，所以不必?fù)?dān)心設(shè)計(jì)、編程、測(cè)試會(huì)與需求不一致，因此可以省略需求跟蹤。那么，需要指正的是，按照軟件生命周期嚴(yán)格線性順序的開(kāi)發(fā)模型并不能保證各個(gè)開(kāi)發(fā)階段的工作產(chǎn)品與需求保持一致。因?yàn)殚_(kāi)發(fā)者是人而不是機(jī)器。而且，大多數(shù)開(kāi)發(fā)人員也都深有體會(huì)。
生活中“以訛傳訛”的例子，想必大家都很熟悉。學(xué)生甲在精工實(shí)習(xí)時(shí)被機(jī)器弄破了手指，于是到醫(yī)院包扎。同學(xué)乙路過(guò)醫(yī)院時(shí)看到甲的手血跡斑斑，以為甲的手指被機(jī)器割斷，于是將這個(gè)壞消息告訴同學(xué)丙。丙急忙轉(zhuǎn)告同學(xué)丁，說(shuō)甲的手被機(jī)器割斷，正躺在醫(yī)院里。丁十萬(wàn)火急地告訴全班同學(xué)，大家陷入悲痛之中，都以為“甲的胳膊被機(jī)器割斷了，正躺在醫(yī)院里，人快不行了。”
由于人們的表達(dá)能力、理解能力不可能完全相同，人與人之間的協(xié)作很難達(dá)到天衣無(wú)縫的境界。而使用需求追溯的本身也是一種傳遞的過(guò)程。
需求追溯本身并不是一件復(fù)雜的事，而是我們的本身一種理念在支配著我們。也許就有人認(rèn)為這本身就是在浪費(fèi)時(shí)間，主要麻煩是，當(dāng)需求或工作產(chǎn)品發(fā)生變更時(shí)，開(kāi)發(fā)人員要及時(shí)更新需求跟蹤矩陣。然而沒(méi)想到的事，如果后來(lái)再花時(shí)間來(lái)做同樣的事的時(shí)候，將會(huì)付出更多。也時(shí)也就丟去了本身做這件事的意義。
需求變更控制(Requirement Change Control)
需求變更通常會(huì)對(duì)項(xiàng)目的進(jìn)度、人力資源產(chǎn)生很大的影響，這是開(kāi)發(fā)商非常畏懼的問(wèn)題。也是必須面臨與需要處理的問(wèn)題。作為軟件項(xiàng)目，特別在外地實(shí)施的工程軟件項(xiàng)目而言，需求發(fā)生若干次變更似乎是不可避免的。需求發(fā)生變更的起因主要有：
隨著項(xiàng)目生命周期的不斷往前推進(jìn)，人們（包括開(kāi)發(fā)方和客戶方）對(duì)需求的了解越來(lái)越深入。原先的提出的需求可能存在著一定的缺陷，因此要變更需求。
市場(chǎng)業(yè)務(wù)需求發(fā)生了變化，原先的需求可能跟不上當(dāng)前的市場(chǎng)業(yè)務(wù)發(fā)展，因此要變更需求。由于市場(chǎng)變化而導(dǎo)致需求發(fā)生變更，開(kāi)發(fā)商大可不必為此煩惱，應(yīng)當(dāng)高興才對(duì)。倘若市場(chǎng)靜如死水，那么開(kāi)發(fā)商吃了“上一頓”就沒(méi)有“下一頓”。正因?yàn)槭袌?chǎng)在變化，才會(huì)產(chǎn)生更多商機(jī)，聰明的開(kāi)發(fā)商才會(huì)有活干，有錢賺。
如果在項(xiàng)目開(kāi)發(fā)的初始階段，開(kāi)發(fā)人員和用戶沒(méi)有搞清楚需求或者搞錯(cuò)了需求，到了項(xiàng)目開(kāi)發(fā)后期才將需求糾正過(guò)來(lái)，導(dǎo)致產(chǎn)品的部分內(nèi)容需要重新開(kāi)發(fā)。毫無(wú)疑問(wèn)，這種需求變更將使項(xiàng)目付出額外的代價(jià)。這種損失是由于雙方工作失誤造成的，雙方應(yīng)當(dāng)好好反省，認(rèn)真學(xué)習(xí)需求開(kāi)發(fā)和管理的方法，避免再犯相似的錯(cuò)誤。
總的而言，人們提出需求變更，本就是出于能夠是產(chǎn)品更加符合市場(chǎng)或客戶需求，出發(fā)點(diǎn)本身是好的。但對(duì)于開(kāi)發(fā)小組而言，需求的變更則意味著要需要重新進(jìn)行估計(jì)，調(diào)整資源、重新分配任務(wù)、修改前期工作產(chǎn)品等，而作為開(kāi)發(fā)商，需要增預(yù)算與投資，開(kāi)發(fā)組要為此付出較重的代價(jià)。假定每次需求變更請(qǐng)求都被接受的話，那么這個(gè)項(xiàng)目將會(huì)成為一個(gè)連環(huán)式的工程。
需求變更控制的動(dòng)機(jī)是：
如果需求變更帶來(lái)的好處大于壞處，那么允許變更，但必須按照已定義的變更規(guī)程執(zhí)行，以免變更失去控制。
如果需求變更帶來(lái)的壞處大于好處，那么拒絕變更。
當(dāng)然，好處與壞處并不是主觀的，而是通過(guò)客觀的分析與評(píng)價(jià)而得出的。
對(duì)于需求的變更，在某一個(gè)程度上來(lái)說(shuō)，也就是項(xiàng)目的范圍進(jìn)行了變化。而需求同時(shí)又是項(xiàng)目進(jìn)行的基礎(chǔ)。是非常得要的基石。通常對(duì)于需求的變更需要客戶與開(kāi)發(fā)方共同參與，包括負(fù)責(zé)人及市場(chǎng)人員。當(dāng)然，我們需要根據(jù)變更的內(nèi)容來(lái)靈活運(yùn)用。
需求變更控制過(guò)程中最難辦的事情是莫過(guò)于“拒絕客戶提出的需求變更請(qǐng)求”?？蛻魰?huì)想當(dāng)然地以為變更需求是他的權(quán)利，因?yàn)樗跺X給開(kāi)發(fā)方。通常情況下開(kāi)發(fā)方是不敢得罪客戶的，但是無(wú)原則地退讓將使開(kāi)發(fā)小組陷入困境。怎么解決這個(gè)問(wèn)題呢，通常情況下，每一類“游戲”都有一定的游戲規(guī)則，那么我們事先也需要建立“游戲規(guī)則”。
如果事先沒(méi)有“游戲規(guī)則”的話，開(kāi)發(fā)方的負(fù)責(zé)人需要一些社交技巧來(lái)減緩矛盾。例如首先承認(rèn)客戶提出的需求變更請(qǐng)求是合理的，再闡述己方的難處，最后建議在開(kāi)發(fā)該產(chǎn)品新版本時(shí)修改需求。這種方式比直接拒絕有效得多，既不得罪客戶，又為自己爭(zhēng)取了余地。
另外還有一種方法，可以將變更需求先進(jìn)行記錄，并通知給客戶，當(dāng)其需求變化在開(kāi)發(fā)組不能接受的范圍時(shí)，可以通過(guò)市場(chǎng)進(jìn)行相關(guān)的協(xié)調(diào)。
需求變更本是正常的，并不可怕，可怕的是需求的變更得不到控制。
二、為什么需要管理需求？
簡(jiǎn)單地說(shuō),系統(tǒng)開(kāi)發(fā)團(tuán)隊(duì)之所以管理需求,是因?yàn)樗麄兿胱岉?xiàng)目獲得成功.滿足項(xiàng)目需求即為成功打下了基礎(chǔ).若無(wú)法管理需求,達(dá)到目標(biāo)的幾率就會(huì)降低. 以下最近收集的證據(jù)很有說(shuō)服力: Standish Group 從 1994 年到 2001 年的 CHAOS Reports 證實(shí),導(dǎo)致項(xiàng)目失敗的最重要的原因與需求有關(guān). 2001年,Standish Group 的CHAOS Reports報(bào)導(dǎo)了該公司的一項(xiàng)研究,該公司對(duì)多個(gè)項(xiàng)目作調(diào)查后發(fā)現(xiàn),百分之七十四的項(xiàng)目是失敗的,既這些項(xiàng)目不能按時(shí)按預(yù)算完成.其中提到最多的導(dǎo)致項(xiàng)目失敗的原因就是"變更用戶需求".
三、為什么要管理需求？
避免失敗就是一個(gè)很充分的理由.提高項(xiàng)目的成功率和需求管理所帶來(lái)的其他好處同樣也是理由.Standish Group 的 CHAOS 報(bào)告進(jìn)一步證實(shí)了與成功項(xiàng)目關(guān)系最大的因素是良好的需求管理.
什么是需求？
理解需求管理的第一步就是對(duì)什么是需求管理達(dá)成共識(shí).Rational 把需求定義為"(正在構(gòu)建的)系統(tǒng)必須符合的條件或具備的功能".電氣和電子工程師學(xué)會(huì)使用的定義與此類似. 著名的需求工程設(shè)計(jì)師 Merlin Dorfman 和 Richard H. Thayer 提出了一個(gè)包容且更為精練的定義,它特指軟件方面 - 但不僅僅限于軟件:
"軟件需求可定義為: 用戶解決某一問(wèn)題或達(dá)到某一目標(biāo)所需的軟件功能. 系統(tǒng)或系統(tǒng)構(gòu)件為了滿足合同,規(guī)約,標(biāo)準(zhǔn)或其他正式實(shí)行的文檔而必須滿足或具備的軟件功能."
什么是需求管理
由于需求是正在構(gòu)建的系統(tǒng)必須符合的事務(wù),而且符合某些需求決定了項(xiàng)目的成功或失敗,因此找出需求是什么,將它們記下來(lái),進(jìn)行組織,并在發(fā)生變化時(shí)對(duì)它們進(jìn)行追蹤,這些活動(dòng)都是有意義的. 換句話說(shuō),需求管理就是：一種獲取,組織并記錄系統(tǒng)需求的系統(tǒng)化方案,以及一個(gè)使客戶與項(xiàng)目團(tuán)隊(duì)對(duì)不斷變更的系統(tǒng)需求達(dá)成并保持一致的過(guò)程.
這個(gè)定義與 Dorfman 與 Thayer 以及 IEEE 的"軟件需求工程"的定義相似.需求工程包括獲取,分析,規(guī)定,驗(yàn)證和管理軟件需求,而"軟件需求管理"則是對(duì)所有相關(guān)活動(dòng)的規(guī)劃和控制.這里介紹的以及 IBM Rational提出的需求管理定義包括了所有這些活動(dòng).它們的區(qū)別主要在于這里選用了"管理"這個(gè)詞,而不是"工程".管理這個(gè)詞更合適用來(lái)描述所有涉及到的活動(dòng),并且它準(zhǔn)確地強(qiáng)調(diào)了追蹤變更以保持涉眾與項(xiàng)目團(tuán)隊(duì)之間共識(shí)的重要性.
對(duì)那些不熟悉"引出"這個(gè)詞的人來(lái)說(shuō),它可定義為團(tuán)隊(duì)用來(lái)獲取或發(fā)現(xiàn)涉眾請(qǐng)求,確定請(qǐng)求后隱藏的真正需要,以及為滿足這些需要對(duì)系統(tǒng)提出的一組適當(dāng)需求.
需求管理問(wèn)題 一個(gè)目的在于確保系統(tǒng)符合人們對(duì)其期望的流程面臨著哪些困難呢 當(dāng)它真正在實(shí)際項(xiàng)目實(shí)施時(shí),困難就暴露出來(lái)了.圖 1 顯示了年對(duì)開(kāi)發(fā)人員,經(jīng)理和質(zhì)量保證人員所做的一次調(diào)查結(jié)果.該圖顯示了經(jīng)歷過(guò)最常提到的需求相關(guān)難題的受訪者比例.
下面列出了更多與需求有關(guān)的問(wèn)題:
需求不總是顯而易見(jiàn)的,而且它可來(lái)自各個(gè)方面. 需求并不總是容易用文字明白無(wú)誤地表達(dá). 存在不同種類的需求,其詳細(xì)程度各不相同. 如果不加以控制,需求的數(shù)量將難以管理. 需求相互之間以及與流程的其他可交付工件之間以多種方式相關(guān)聯(lián). 需求有唯一的特征或特征值.例如,它們既非同等重要,處理的難度也不同. 需求涉及眾多相關(guān)利益責(zé)任方,這意味著需求要由跨職能的各組人員來(lái)管理. 需求發(fā)生變更. 需求可能對(duì)時(shí)間敏感. 當(dāng)這些問(wèn)題與需求管理和處理技能不足以及缺乏易用工具等情況一同出現(xiàn)時(shí),許多團(tuán)隊(duì)都對(duì)管理好需求不抱希望了.IBM Rational 已經(jīng)開(kāi)發(fā)出指導(dǎo)團(tuán)隊(duì)提高需求管理技能和流程的專業(yè)技術(shù),并使用相應(yīng)的工具使得上述的流程和專業(yè)技術(shù)得以實(shí)現(xiàn).
需求捕獲
從上述的分析可以看出,需求的捕獲是需求管理的基礎(chǔ)和前提.在這里,將介紹一種為業(yè)界所廣泛采用并經(jīng)驗(yàn)證的需求捕獲方法,即用例模型. 用例模型是系統(tǒng)既定功能及系統(tǒng)環(huán)境的模型,并作為客戶和開(kāi)發(fā)人員之間的契約.
用例模型用作分析,設(shè)計(jì)和測(cè)試活動(dòng)的基本輸入.用例是貫穿整個(gè)系統(tǒng)開(kāi)發(fā)的一條主線.同一個(gè)用例模型即為需求工作流程的結(jié)果,可當(dāng)作分析設(shè)計(jì)工作流程以及測(cè)試工作流程的輸入使用.參與者(Actor)和用例(UseCase)是用例模型中的主要元素. 下圖顯示了自動(dòng)取款機(jī)系統(tǒng)用例模型的一部分:
客戶
查詢
提款
轉(zhuǎn)帳
客戶身份驗(yàn)證系統(tǒng)時(shí)鐘
數(shù)據(jù)庫(kù)服務(wù)器
(from )系統(tǒng)維護(hù)
信函打印機(jī)
打印對(duì)帳單
用例圖用于顯示包含參與者和用例的用例模型示例.系統(tǒng)建模有許多種方法,每種建模方法可以滿足不同的目的.然而,用例模型最重要的作用是將系統(tǒng)行為傳達(dá)給客戶或最終用戶.可能與該系統(tǒng)交互的用戶和任何其他系統(tǒng)都是參與者.由于參與者代表了系統(tǒng)用戶,它們協(xié)助界定系統(tǒng)并提供十分明確的系統(tǒng)用途說(shuō)明.編寫用例依據(jù)參與者的需求來(lái)進(jìn)行.這樣就確保該系統(tǒng)成為用戶期望得到的系統(tǒng).
參與者和用例都是通過(guò)將客戶需求及潛在用戶當(dāng)作重要的信息查找到的.找到這些用例和參與者后,應(yīng)對(duì)它們作簡(jiǎn)要說(shuō)明.在詳細(xì)說(shuō)明這些用例之前,客戶應(yīng)復(fù)審該用例模型以核實(shí)所有的用例和參與者都已經(jīng)找到,并且它們可以提供客戶所需要的東西. 在迭代開(kāi)發(fā)環(huán)境中,您可以選擇用例的子集以便在每個(gè)迭代中詳細(xì)描述.參與者和用例找到后,需要詳細(xì)說(shuō)明每個(gè)用例的事件流.這些說(shuō)明指出系統(tǒng)與參與者交互的方式以及在各個(gè)獨(dú)立用例中系統(tǒng)執(zhí)行的有關(guān)操作.
最后,對(duì)已完成的用例模型(包括用例說(shuō)明)進(jìn)行復(fù)審,開(kāi)發(fā)人員和客戶使用該模型對(duì)系統(tǒng)應(yīng)執(zhí)行的操作達(dá)成一致意見(jiàn).
四、需求管理模型
在需求管理的流程中,需求的捕獲手段固然重要,但在需求的捕獲和需求最終成型的過(guò)程中,我們會(huì)面臨各種和需求相關(guān)的信息和資料(也可以把這些信息籠統(tǒng)地稱做"需求"),如何發(fā)現(xiàn)這些信息之間的關(guān)系并有效組織,更為關(guān)鍵. 需求類型 在RUP中,我們采用一種金字塔方式的管理辦法,來(lái)組織和管理我們獲取的信息乃至最終的需求.
為了建立一個(gè)真正滿足客戶需求的系統(tǒng),項(xiàng)目團(tuán)隊(duì)首先必須確定系統(tǒng)要解決的問(wèn)題.然后,團(tuán)隊(duì)必須確定涉眾,從中獲得業(yè)務(wù)和用戶需要,對(duì)其進(jìn)行描述,并區(qū)分它們的優(yōu)先級(jí).從這一組高層期望或需求出發(fā),對(duì)產(chǎn)品或系統(tǒng)特性集達(dá)成一致意見(jiàn).而后,由產(chǎn)品特性來(lái)抽取軟件需求,在我們的模型中,軟件需求是以用例模型的方式來(lái)描述.從測(cè)試的角度來(lái)看,測(cè)試項(xiàng)一定來(lái)自于軟件需求,即軟件需求中確定了哪些需求項(xiàng),測(cè)試就要根據(jù)這些需求項(xiàng)來(lái)制定和實(shí)現(xiàn).
系統(tǒng)越大越復(fù)雜,出現(xiàn)的需求類型就越多.一個(gè)需求類型不過(guò)是指需求的一個(gè)類.通過(guò)確定需求類型,團(tuán)隊(duì)可以把大量需求組織成意義明確且更容易管理的組.在一個(gè)項(xiàng)目中建立不同類型的需求有助于團(tuán)隊(duì)成員對(duì)變更請(qǐng)求進(jìn)行分類,并使相互之間的溝通更為清楚明確.從上述的分析中我們可以看到,通常,一類需求可以細(xì)分即分解成其他類型的需求.這里,我們就把需求分解為幾種類型,并在他們之間建立相應(yīng)的關(guān)聯(lián).業(yè)務(wù)規(guī)則和前景聲明包括高層次的需求,團(tuán)隊(duì)可以從中導(dǎo)出用戶需要,特性和產(chǎn)品需求類型.用例和其他建模形式驅(qū)動(dòng)設(shè)計(jì)需求,該需求可分解為軟件需求,并可以用分析設(shè)計(jì)模型來(lái)說(shuō)明.測(cè)試需求源于軟件需求,它被分解為具體的測(cè)試過(guò)程.如果既定項(xiàng)目中有成百上千個(gè),甚至上萬(wàn)個(gè)需求實(shí)例時(shí),對(duì)需求進(jìn)行分類可以使項(xiàng)目更容易管理.上述的這些需求類型同時(shí)保存在對(duì)應(yīng)的RUP文檔和數(shù)據(jù)庫(kù)中.
五、應(yīng)用需求類型
通過(guò)定義需求類型,以及他們之間的關(guān)系,我們就建立了一個(gè)需求管理模型的框架.當(dāng)然,我們建立這樣的一個(gè)模型,是為了方便我們使用需求,為了達(dá)到這一目的,我們還需要在此基礎(chǔ)上添加相應(yīng)的內(nèi)容. 需要對(duì)各種需求類型添加它們的屬性,以便于對(duì)需求進(jìn)行查詢等管理手段.比如,可以針對(duì)用戶需要,確定該需要的必要性,優(yōu)先級(jí),確定性等屬性.在實(shí)際的項(xiàng)目中,就可以確定這些屬性的值,而后根據(jù)這些實(shí)際屬性值來(lái)安排項(xiàng)目的進(jìn)度表等.或是在項(xiàng)目進(jìn)度緊急時(shí),確定哪些需求是可以延期完成,而哪些是必須完成的,等等.
需求的追蹤性 其次,可以根據(jù)不同需求的導(dǎo)出情況,在不同的需求之間建立追蹤關(guān)系.譬如,用戶需要決定了要構(gòu)建產(chǎn)品的特性,產(chǎn)品的特性又決定了產(chǎn)品的軟件需求,等.在這些不同類型的需求之間建立關(guān)聯(lián),一旦其中的某些需求發(fā)生變化,就可以確定它可能帶來(lái)的影響,從而制定相應(yīng)的策略.
六、需求管理的工作流程
工作流明細(xì)簡(jiǎn)介
問(wèn)題分析
問(wèn)題分析可以通過(guò)了解問(wèn)題及涉眾的最初需要,并提出高層解決方案來(lái)實(shí)現(xiàn).它是為找出"隱藏在問(wèn)題之后的問(wèn)題"而進(jìn)行的推理和分析.問(wèn)題分析期間,將對(duì)"什么是面臨實(shí)際問(wèn)題"和"誰(shuí)是涉眾"等問(wèn)題達(dá)成一致.而且,您還要從業(yè)務(wù)角度界定解決方案,以及制約該解決方案的因素.您應(yīng)該已經(jīng)對(duì)項(xiàng)目進(jìn)行過(guò)商業(yè)理由分析,這將便于您更好地預(yù)計(jì)能從構(gòu)建中的項(xiàng)目中得到多少投資回報(bào).
理解涉眾需要
需求來(lái)自各個(gè)方面,比如來(lái)自客戶,合作伙伴,最終用戶或是某領(lǐng)域的專家.您需要掌握如何準(zhǔn)確判斷需求應(yīng)來(lái)源于哪方面,如何接近這些來(lái)源并從中獲取信息.提供這些信息主要出處的個(gè)人在本項(xiàng)目中稱為涉眾.如果您正在開(kāi)發(fā)一個(gè)在您公司內(nèi)部使用的信息系統(tǒng),那么在開(kāi)發(fā)團(tuán)隊(duì)中應(yīng)包括具有最終用戶經(jīng)驗(yàn)和業(yè)務(wù)領(lǐng)域?qū)I(yè)知識(shí)的人員.通常討論將在業(yè)務(wù)模型這一級(jí)上展開(kāi),而不是在系統(tǒng)這一級(jí)上展開(kāi).如果正在開(kāi)發(fā)一個(gè)要在市場(chǎng)上出售的產(chǎn)品,那么您可以充分調(diào)動(dòng)營(yíng)銷人員,以便更好地了解該市場(chǎng)中用戶的需要. 獲取需要的活動(dòng)可使用這樣一些技巧:訪談,集體討論,概念原型設(shè)計(jì),問(wèn)卷調(diào)查和競(jìng)爭(zhēng)性分析等.獲取結(jié)果可能是一份圖文并茂的請(qǐng)求或需要列表,并按相互之間的優(yōu)先級(jí)列出.
定義系統(tǒng)
定義系統(tǒng)指的是解釋涉眾需求,并整理為對(duì)要構(gòu)建系統(tǒng)的意義明確的說(shuō)明.在系統(tǒng)定義的初期要確定以下內(nèi)容:需求構(gòu)成,文檔格式,語(yǔ)言形式,需求的具體程度(需求量及詳細(xì)程度),需求的優(yōu)先級(jí)和預(yù)計(jì)工作量(不同人在不同的實(shí)踐中通常對(duì)這兩項(xiàng)內(nèi)容的看法大不相同),技術(shù)和管理風(fēng)險(xiǎn)以及最初規(guī)模.系統(tǒng)定義活動(dòng)還可包括與最關(guān)鍵的涉眾請(qǐng)求直接聯(lián)系的初期原型和設(shè)計(jì)模型.系統(tǒng)定義的結(jié)果是用自然語(yǔ)言和圖解方式表達(dá)的系統(tǒng)說(shuō)明.
管理項(xiàng)目規(guī)模
為使項(xiàng)目高效運(yùn)作,應(yīng)仔細(xì)根據(jù)所有涉眾的需求確定優(yōu)先級(jí),并對(duì)項(xiàng)目規(guī)模進(jìn)行管理.有的開(kāi)發(fā)人員僅僅重視所謂的"復(fù)活節(jié)彩蛋"(即開(kāi)發(fā)人員感興趣或覺(jué)得有挑戰(zhàn)性的特性),而不是及早將精力投入降低項(xiàng)目風(fēng)險(xiǎn)或提高應(yīng)用程序構(gòu)架穩(wěn)定性方面,這已使太多的項(xiàng)目蒙受損失.為確保盡早解決或降低項(xiàng)目中的風(fēng)險(xiǎn),應(yīng)以遞增的方式開(kāi)發(fā)系統(tǒng).要慎重選擇需求,以確保每次增加都能緩解項(xiàng)目中的已知風(fēng)險(xiǎn).要達(dá)到目的,您需要和項(xiàng)目的涉眾協(xié)商每次迭代的范圍.通常,這要求具備管理項(xiàng)目各個(gè)階段的期望結(jié)果的良好技能.
除了控制開(kāi)發(fā)過(guò)程本身,您還需控制需求的來(lái)源,并控制項(xiàng)目可交付工件的外觀. 改進(jìn)系統(tǒng)定義 系統(tǒng)的詳細(xì)定義應(yīng)能讓涉眾理解,同意并認(rèn)可.它不僅需要具備所有功能,而且應(yīng)符合法律或法規(guī)上的要求,符合可用性,可靠性,性能,可支持性和可維護(hù)性.感覺(jué)構(gòu)建過(guò)程復(fù)雜的系統(tǒng)就應(yīng)該有復(fù)雜的定義,這是一種常見(jiàn)的錯(cuò)誤看法.這會(huì)給解釋項(xiàng)目和系統(tǒng)的目的造成困難.人們可能印象深刻,但他們會(huì)因不甚理解而無(wú)法給出建議.應(yīng)該致力于了解您制作的系統(tǒng)說(shuō)明文檔的讀者.您可能常會(huì)發(fā)現(xiàn)需要為不同的讀者準(zhǔn)備不同的說(shuō)明文檔.
我們認(rèn)為用例方法是傳達(dá)系統(tǒng)目的和定義系統(tǒng)細(xì)節(jié)的一種行之有效的方法,它常與簡(jiǎn)單的可視化原型結(jié)合使用.用例有助于為需求提供一個(gè)環(huán)境,利用它可生動(dòng)地說(shuō)明系統(tǒng)使用的方式.
系統(tǒng)詳細(xì)定義的另一個(gè)構(gòu)件是說(shuō)明系統(tǒng)采用的測(cè)試方式.測(cè)試計(jì)劃及要執(zhí)行測(cè)試的定義將會(huì)說(shuō)明要核實(shí)哪些系統(tǒng)功能.
管理需求變更
定義需求時(shí)無(wú)論怎樣謹(jǐn)慎小心,也總會(huì)有可變因素.變更的需求之所以變得難以管理,不僅是因?yàn)橐粋€(gè)變更了的需求意味著要花費(fèi)或多或少的時(shí)間來(lái)實(shí)現(xiàn)某一個(gè)新特性,而且也因?yàn)閷?duì)某個(gè)需求的變更很可能影響到其他需求.應(yīng)確保賦予需求一個(gè)有彈性的結(jié)構(gòu),使它能適應(yīng)變更,并且確保使用可追蹤性鏈接可以表達(dá)需求與開(kāi)發(fā)生命周期的其他工件之間的依賴關(guān)系.管理變更包括建立基線,確定需要追蹤的重要依賴關(guān)系,建立相關(guān)項(xiàng)之間的可追蹤性,以及變更控制等活動(dòng).
七、需求管理所要完成的任務(wù)
可以說(shuō)需求是一種模型，是產(chǎn)品的早期雛形，通過(guò)進(jìn)行需求分析，我們可以對(duì)最終產(chǎn)品做出優(yōu)化。需要始終保持注意的是，需求性是始終處于變化之中的。需求管理需要完成的任務(wù)包括：
●明確需求并達(dá)成共識(shí)；
●建立關(guān)聯(lián)；
●根據(jù)不同需求設(shè)計(jì)相應(yīng)解決辦法；
●進(jìn)行系統(tǒng)優(yōu)化；
●提出設(shè)計(jì)方案；
●監(jiān)控和解決可能出現(xiàn)的問(wèn)題以及需要做出的改變；
●控制不同開(kāi)發(fā)任務(wù)的開(kāi)展；
●對(duì)最終產(chǎn)品做出評(píng)測(cè)；
●監(jiān)控可能出現(xiàn)的重復(fù)開(kāi)發(fā)；
●提出項(xiàng)目實(shí)施時(shí)間表；
●確定最終用戶界面。
有時(shí)侯我們所進(jìn)行的需求分析只停留于分析本身，而沒(méi)有進(jìn)一步去思索我們?yōu)槭裁匆M(jìn)行需求分析。需求性是項(xiàng)目開(kāi)發(fā)的源頭，只有進(jìn)行認(rèn)真的需求分析，我們才能做到對(duì)癥下藥、量體裁衣，才能才設(shè)計(jì)開(kāi)發(fā)中去偽存真，不斷改進(jìn)。"需求之需求"正是強(qiáng)調(diào)了貫穿始終的需求分析的重要。離開(kāi)了能動(dòng)的、變化的系統(tǒng)進(jìn)程而空談需求管理，無(wú)異于紙上談兵。需求管理所產(chǎn)生的效益或許并不明顯，或許要日后才能體現(xiàn)，但是無(wú)序的，沒(méi)有經(jīng)過(guò)精心策劃的需求管理是不可能產(chǎn)生效益的。
以下篇幅分別介紹需求管理在系統(tǒng)工程中的不同應(yīng)用。
需求共識(shí)：
首先，用戶需求通過(guò)非術(shù)語(yǔ)的形式進(jìn)行表述，這種表述應(yīng)當(dāng)使每一位開(kāi)發(fā)者明確自己的職責(zé)所在，并且清楚知道不同開(kāi)發(fā)工作之間的關(guān)聯(lián)。這里的"用戶"泛指在實(shí)際應(yīng)用環(huán)境中每一位可能使用最終產(chǎn)品的人。如果一個(gè)產(chǎn)品不能滿足客戶所需，那么設(shè)計(jì)方案再出色也無(wú)濟(jì)于事，許多方案有很高的技術(shù)設(shè)計(jì)水準(zhǔn)卻最終不能獲得成功，其原因正在于此。可以把產(chǎn)品功能說(shuō)得天花亂墜，但卻無(wú)法改變用戶需求決定最終產(chǎn)品基本模式的事實(shí)。
需求管理的首要任務(wù)在于使開(kāi)發(fā)人員和用戶雙方對(duì)于需求都有一個(gè)明確的認(rèn)識(shí)。因此用來(lái)進(jìn)行需求分析的語(yǔ)言組織應(yīng)當(dāng)使所有相關(guān)人員，包括用戶，都能夠理解，都能夠進(jìn)而對(duì)整個(gè)項(xiàng)目有一個(gè)整體把握，并明確每一個(gè)人在項(xiàng)目中所起的作用。因而需求管理需要解決的第一位也是最基本的任務(wù)就是明確需求，并使所有相關(guān)人員達(dá)成共識(shí)。
根據(jù)需求設(shè)計(jì)解決辦法：
我們?cè)谶M(jìn)行系統(tǒng)設(shè)計(jì)時(shí)，應(yīng)當(dāng)首先建立一個(gè)需求模型，但不能是為了建模而建模，需求模型實(shí)際是最終產(chǎn)品的抽象化表現(xiàn)。需求模型的建立使我們?cè)诿鞔_需求的基礎(chǔ)上更進(jìn)一步，使我們知道我們將要生產(chǎn)何種產(chǎn)品，該產(chǎn)品都具有那些功能。同時(shí)，創(chuàng)建需求模型的過(guò)程也使開(kāi)發(fā)者明確自己的工作如何同整個(gè)項(xiàng)目有機(jī)地結(jié)合在一起。建立需求模型應(yīng)當(dāng)充分研究不同類型、不同架構(gòu)建模方式的可行性，切忌主觀武斷。
系統(tǒng)優(yōu)化：
任何設(shè)計(jì)都應(yīng)以考慮用戶需求為優(yōu)先，用戶需求的滿足程度即成為衡量設(shè)計(jì)優(yōu)劣的標(biāo)準(zhǔn)。在一個(gè)項(xiàng)目設(shè)計(jì)周期中，開(kāi)發(fā)人員經(jīng)常會(huì)面臨選擇，以提煉需求，決定開(kāi)發(fā)的優(yōu)先次序，并在不同的實(shí)施方案中作出選擇。這些選擇必須考慮到收益與付出地平衡比例，這種選擇的重要性尤其在建立需求模型的后期凸現(xiàn)出來(lái)?；拘枨笤谶@時(shí)都已明確，而實(shí)施方案還未敲定，為了使用戶的基本需求得到落實(shí)，一定程度的開(kāi)銷用于搭建不同構(gòu)架的需求模式是合理的。假使我們已經(jīng)有了一套翔實(shí)的需求分析，我們甚至不必將每一套方案都付諸實(shí)行，就可以成功地對(duì)系統(tǒng)設(shè)計(jì)進(jìn)行優(yōu)化。
面對(duì)不同的可行性而需要作出選擇時(shí)，我們也必須參照收益與付出的比例關(guān)系。例如，在被要求提供計(jì)劃書時(shí)（Request for Proposal），我們應(yīng)當(dāng)盡量做到每一份計(jì)劃書的提供都物有所值。
方案設(shè)計(jì)：
明確需求后，開(kāi)發(fā)人員就可以進(jìn)行方案設(shè)計(jì)。通過(guò)對(duì)用戶需求和設(shè)計(jì)方案之間所存在關(guān)聯(lián)性進(jìn)行分析比較，我們就能夠?qū)υO(shè)計(jì)方案進(jìn)行評(píng)估。
必要的修改：
方案的設(shè)計(jì)不可能是一成不變的，經(jīng)常會(huì)有方案設(shè)計(jì)同需求相悖的情況。如果我們無(wú)法準(zhǔn)確把握用戶需求同方案設(shè)計(jì)之間的關(guān)系，我們就無(wú)法在需要對(duì)方案進(jìn)行必要修改時(shí)正確判斷。優(yōu)秀的需求分析應(yīng)當(dāng)非常精確細(xì)致地對(duì)用戶需求作出描述，同時(shí)也應(yīng)該最大程度地給予方案設(shè)計(jì)者充分發(fā)揮的余地。
任務(wù)劃分：
一個(gè)大的開(kāi)發(fā)項(xiàng)目可能涉及20-30組不同的開(kāi)發(fā)隊(duì)伍，人員包括技術(shù)工程師、軟件工程師以及具體項(xiàng)目主管等等，而每一個(gè)模塊都有它自己的開(kāi)發(fā)工具和開(kāi)發(fā)語(yǔ)言。
主持一個(gè)大項(xiàng)目的開(kāi)發(fā)并不是件容易的事，總體項(xiàng)目主管的首要任務(wù)是對(duì)開(kāi)發(fā)項(xiàng)目進(jìn)行任務(wù)劃分，將整體開(kāi)發(fā)任務(wù)細(xì)化為多個(gè)子模塊，從而使這些子模塊能夠平行開(kāi)發(fā)而無(wú)需太多的干預(yù)?？傮w項(xiàng)目主管可以將細(xì)化的不同模塊的需求分析交給不同的開(kāi)發(fā)隊(duì)伍，對(duì)于開(kāi)發(fā)進(jìn)程的監(jiān)控只需參照需求的解決情況，對(duì)于具體的開(kāi)發(fā)細(xì)節(jié)則不必過(guò)問(wèn)太多。
不同的開(kāi)發(fā)隊(duì)伍會(huì)使用不同的開(kāi)發(fā)語(yǔ)言和開(kāi)發(fā)工具，會(huì)使用不同的符號(hào)和標(biāo)記。相反，作為總體項(xiàng)目主管所使用的語(yǔ)言、符號(hào)和標(biāo)記等則必須簡(jiǎn)單易懂，以使所有的開(kāi)發(fā)人員都等理解。換言之，總體項(xiàng)目主管應(yīng)當(dāng)使用自然語(yǔ)言，或只涉及少量的，簡(jiǎn)單的術(shù)語(yǔ)和專用詞匯。
產(chǎn)品測(cè)試：
需求的滿足情況是決定最終產(chǎn)品成敗的判定基礎(chǔ)，對(duì)最終產(chǎn)品的測(cè)試評(píng)估必須以產(chǎn)品所試圖解決的需求為標(biāo)準(zhǔn)。下圖標(biāo)示了不同的開(kāi)發(fā)階段所對(duì)應(yīng)的測(cè)試需求。
這里有一個(gè)需求、產(chǎn)品和測(cè)試系統(tǒng)之間的關(guān)系問(wèn)題，確定需要進(jìn)行的測(cè)試屬于總體開(kāi)發(fā)主管的工作范疇，雖然具體工作并非都要由開(kāi)發(fā)主管來(lái)親自完成。
重復(fù)開(kāi)發(fā)：
對(duì)于總體開(kāi)發(fā)主管而言，針對(duì)方案設(shè)計(jì)的修改是一項(xiàng)經(jīng)常性的工作（因?yàn)樾薷亩斐傻挠绊憚t應(yīng)當(dāng)盡可能減小）。在進(jìn)行項(xiàng)目開(kāi)發(fā)時(shí)，隨著開(kāi)發(fā)進(jìn)程的深入，各種修改的建議和問(wèn)題的報(bào)告是屢見(jiàn)不鮮的，每解決一個(gè)問(wèn)題，就是將產(chǎn)品同其需求性的結(jié)合又完善了一步。存在問(wèn)題正是需求性尚未滿足的表現(xiàn)。
方案設(shè)計(jì)的完善和需求性的滿足是同步的，因此真正的用戶對(duì)于產(chǎn)品的評(píng)價(jià)和建議尤其具有重要意義。在那些一步到位的產(chǎn)品設(shè)計(jì)中，真正用戶無(wú)法左右開(kāi)發(fā)進(jìn)程；但在一個(gè)能夠進(jìn)行重復(fù)設(shè)計(jì)、重復(fù)開(kāi)發(fā)的產(chǎn)品生命期中，開(kāi)發(fā)人員應(yīng)當(dāng)及時(shí)搜集用戶對(duì)于產(chǎn)品的反饋信息，并將這些信息結(jié)合到下一步的開(kāi)發(fā)工作中去。如下圖所示，用戶反饋同產(chǎn)品開(kāi)發(fā)是統(tǒng)一的。
項(xiàng)目管理的輔助：
在有些地方，需求管理被作為一個(gè)技術(shù)問(wèn)題來(lái)處理，需求管理所針對(duì)的對(duì)象只是產(chǎn)品，而同項(xiàng)目管理所涉及的問(wèn)題例如進(jìn)程安排或資源分配等無(wú)關(guān)。實(shí)際上，項(xiàng)目管理涉及三方面問(wèn)題：進(jìn)程安排、資源分配和質(zhì)量管理（同需求的統(tǒng)一）。
試想以下三種情況：
●一場(chǎng)高水準(zhǔn)的音樂(lè)會(huì)，預(yù)算合理，演出時(shí)間卻晚了兩天。
●質(zhì)量?jī)?yōu)良的小轎車，交貨及時(shí)，然而造價(jià)是市價(jià)的兩倍。
●一套系統(tǒng)，完全滿足了用戶需求，但在開(kāi)發(fā)過(guò)程中使用非法勞工。
這三種情況雖然都滿足了用戶所需，然而缺乏實(shí)際意義，因此都以失敗告終。
"我付了錢，但這不是我想要的"，沒(méi)有用戶愿意這么說(shuō)。要避免出現(xiàn)這種情況，在進(jìn)行項(xiàng)目管理和財(cái)務(wù)預(yù)算時(shí)，也必須以需求管理為基礎(chǔ)。僅僅完成了一件設(shè)計(jì)并不意味著工作的結(jié)束，只有這件設(shè)計(jì)充分解決了需求，它才具有里程碑般的意義。同樣的，一件產(chǎn)品只有在測(cè)試和實(shí)際操作中完全滿足了需求，已經(jīng)完全準(zhǔn)備好了投入到下一階段的運(yùn)營(yíng)，才意味著這件產(chǎn)品在本階段工作的結(jié)束。
開(kāi)發(fā)進(jìn)程中的每一塊里程碑都意味著需求的解決又前進(jìn)了一步，這樣的每一塊里程碑也都是委托商付款的重要參照，產(chǎn)品開(kāi)發(fā)的整個(gè)進(jìn)程都可以通過(guò)需求管理進(jìn)行監(jiān)控。
里程碑構(gòu)造機(jī)制的基本方法之一就是進(jìn)程管理，一項(xiàng)需求的滿足就意味著一塊里程碑的確立。我們應(yīng)當(dāng)對(duì)用戶需求、針對(duì)需求而進(jìn)行的模塊設(shè)計(jì)以及每個(gè)子模塊的開(kāi)發(fā)進(jìn)程之間的關(guān)聯(lián)做到心中有數(shù)。
通過(guò)我們對(duì)需求管理實(shí)際應(yīng)用的分析，幾個(gè)關(guān)鍵因素凸現(xiàn)出來(lái)。首先，需求管理在開(kāi)發(fā)周期中是自始至終存在的。注意：不要把它簡(jiǎn)單理解為"需求周期"，需求管理必須始終保持更新，它構(gòu)成了技術(shù)管理的基礎(chǔ)。
其次，需求管理同項(xiàng)目管理是密不可分的。如果我們把每一個(gè)需求的解決看作一個(gè)里程碑，并以此出發(fā)對(duì)整個(gè)開(kāi)發(fā)進(jìn)程進(jìn)行監(jiān)控，我們就應(yīng)該對(duì)整體開(kāi)發(fā)工作進(jìn)行精密細(xì)致的劃分，從而將需求分析具體化。
八、需求管理的工具
需求管理所用到的工具必須能夠處理和應(yīng)用于本文所提到的各種需求，應(yīng)當(dāng)有助于我們分析需求，確定相應(yīng)開(kāi)發(fā)和支持工具以處理相關(guān)信息，進(jìn)而處理系統(tǒng)相應(yīng)模塊。系統(tǒng)工程師始終致力于用簡(jiǎn)單的工具將需求形象化的展現(xiàn)出來(lái)，常用的工具比如附有標(biāo)注說(shuō)明的系統(tǒng)發(fā)布工具以及相關(guān)數(shù)據(jù)庫(kù)等。
需求管理涉及到一系列復(fù)雜的對(duì)象，其任務(wù)面向很廣，關(guān)系到整個(gè)設(shè)計(jì)開(kāi)發(fā)的方方面面。其使用的工具應(yīng)當(dāng)提供如圖列舉的一些功能：
九、總結(jié)：需求管理
本文論述圍繞于需求管理工程。需求管理是開(kāi)發(fā)工作有效進(jìn)行的確證。很明顯需求管理是一種很高層次的系統(tǒng)行為，涉及整個(gè)開(kāi)發(fā)過(guò)程和產(chǎn)品本身。
需求管理首先要針對(duì)需求做出分析，隨后應(yīng)用于產(chǎn)品并提出方案。需求分析的模型正是產(chǎn)品的原型樣本，優(yōu)秀的需求管理提高了這樣的可能性：它使最終產(chǎn)品更接近于解決需求，提高了用戶對(duì)產(chǎn)品的滿意度，從而使產(chǎn)品成為真正優(yōu)質(zhì)合格的產(chǎn)品。從這層意義上說(shuō)，需求管理是產(chǎn)品質(zhì)量的基礎(chǔ)。