第1章軟件需求的本質(zhì)　　“喂，Phil嗎？我是人事部的Maria。我們?cè)谑褂媚汩_(kāi)發(fā)的人事系統(tǒng)時(shí)遇到一個(gè)問(wèn)題。有位職員剛剛把她的名字改成Sparkle Starlight，但我們無(wú)法在系統(tǒng)中改。你能幫個(gè)忙嗎？”　　“那么她是結(jié)婚了，隨老公姓Starlight？”　　“沒(méi)有，她沒(méi)結(jié)婚，只是改名字了，”Maria回答道，“問(wèn)題就出在這里。好像我們只能在某人婚姻狀況發(fā)生變化時(shí)才能在系統(tǒng)中改名。”　　“好吧，是，我從來(lái)沒(méi)想過(guò)有人可能會(huì)改自己的名字。當(dāng)初我們?cè)谟懻撓到y(tǒng)的時(shí)候，你可沒(méi)告訴過(guò)我有這種可能性。” Phil答道�！　�“我以為你知道任何人隨時(shí)都可以合法更改名字呢，”Maria回應(yīng)道，“我們得在星期五之前解決這個(gè)問(wèn)題，否則Sparkle就領(lǐng)不到工資了。你可以在此之前修復(fù)這個(gè)bug嗎？”　　“這不是什么bug，好嗎？！” Phil反駁道，“我從沒(méi)想過(guò)你們需要這項(xiàng)功能。我現(xiàn)在正忙著做一個(gè)新的績(jī)效評(píng)估系統(tǒng)。你所說(shuō)的問(wèn)題我只能在月底修復(fù)，但周五之前肯定不行，抱歉。下次如果再有類似情況，請(qǐng)?jiān)琰c(diǎn)告訴我，并請(qǐng)?zhí)峁��?shū)面材料。”　　“那我怎么和Sparkle說(shuō)呢？”Maria追問(wèn)道，“如果她領(lǐng)不到工資，會(huì)很難過(guò)的。”　　“嗨，Maria，這不是我的錯(cuò)，”Phil抗議道，“如果當(dāng)初你早提醒我你需要能夠隨時(shí)更改某人的姓名，這種事情就不會(huì)發(fā)生。你不能因?yàn)槲覜](méi)猜透你的想法就怪我。”　　Maria怒了，但又無(wú)可奈何，只好厲聲說(shuō)：“是，你說(shuō)的都對(duì)！好吧，這種破事兒讓我對(duì)電腦簡(jiǎn)直是恨之入骨。問(wèn)題解決好了，就馬上打電話告訴我，可以嗎？”　　　　如果你是以上對(duì)話中的客戶一方，就會(huì)明白無(wú)法使用軟件系統(tǒng)來(lái)完成一項(xiàng)基本任務(wù)多么令人沮喪。你會(huì)痛恨自己得求著開(kāi)發(fā)人員，因?yàn)殛P(guān)鍵變更請(qǐng)求最終掌握在他們手中。另一方面，開(kāi)發(fā)人員也很沮喪，因?yàn)樗麄冎挥性谙到y(tǒng)開(kāi)發(fā)完成之后才會(huì)明白用戶期待有哪些基本功能。對(duì)于開(kāi)發(fā)人員來(lái)說(shuō)，更惱火的是，得中斷手頭的項(xiàng)目去修正以前已經(jīng)完成的系統(tǒng)（因事先未被明確告知而疏忽的需求）。　　軟件中的很多問(wèn)題大多數(shù)來(lái)源于人們了解、記錄、協(xié)商和修改產(chǎn)品需求的方法不當(dāng)。就Phil和Maria這個(gè)例子而言，問(wèn)題就包括：信息收集不正規(guī)；功能隱晦；對(duì)假設(shè)功能有理解上的分歧；需求指定不明確以及變更過(guò)程不正規(guī)。很多研究表明，軟件產(chǎn)品中發(fā)現(xiàn)的缺陷有40%～50%是在需求階段埋下的“禍根”（Davis 2005）。在具體說(shuō)明客戶需求和管理客戶需求過(guò)程中用戶輸入不足和有誤，是造成項(xiàng)目失敗的罪魁禍?zhǔn)�。盡管證據(jù)確鑿，但很多組織仍然在實(shí)行這些沒(méi)有什么成效的需求方法�！　≡谲浖�項(xiàng)目中，所有干系人的利益交接點(diǎn)主要集中在需求方面。（更多干系人方面的內(nèi)容，參見(jiàn)第2章）這些干系人包括客戶、用戶、業(yè)務(wù)分析人員和開(kāi)發(fā)人員等。如果處理得當(dāng)，這種交接既可以讓客戶滿意，又能鼓舞開(kāi)發(fā)人員。若處理不當(dāng)，則會(huì)引發(fā)誤解和摩擦，最終降低產(chǎn)品質(zhì)量和業(yè)務(wù)價(jià)值。正是由于需求是軟件開(kāi)發(fā)和項(xiàng)目管理活動(dòng)的基礎(chǔ)，因此所有干系人都應(yīng)該致力于需求實(shí)踐活動(dòng)，這是打造一流產(chǎn)品的前提�！　〉�開(kāi)發(fā)和管理需求確實(shí)很難！既沒(méi)什么捷徑，也沒(méi)有任何靈丹妙藥。另外，很多組織都在朝著一個(gè)目標(biāo)努力，要找到一種能適應(yīng)不同情景但又有共性的技術(shù)。本書(shū)后面將講到很多這樣的實(shí)踐。這些實(shí)踐假定你正在開(kāi)發(fā)一種全新的系統(tǒng)。但是，它們中的多數(shù)也可用于改進(jìn)、替換以及重構(gòu)項(xiàng)目（詳見(jiàn)第21章），還可以用于融合商業(yè)現(xiàn)成品的（COTS）打包解決方案項(xiàng)目（詳見(jiàn)第22章）。即使項(xiàng)目團(tuán)隊(duì)遵循敏捷開(kāi)發(fā)過(guò)程漸進(jìn)式構(gòu)建產(chǎn)品增量，團(tuán)隊(duì)也要理解每一個(gè)增量所涉及的需求（詳見(jiàn)第20章）。
　　本章將幫助你：* 理解軟件需求領(lǐng)域所用的一些關(guān)鍵術(shù)語(yǔ)；* 區(qū)分產(chǎn)品需求和項(xiàng)目需求；* 區(qū)分需求開(kāi)發(fā)和需求管理；* 警惕可能出現(xiàn)的與需求相關(guān)的一些問(wèn)題。給自己的需求把把脈　　要想對(duì)組織中現(xiàn)有的需求實(shí)踐做一次快速體檢，就對(duì)比下列問(wèn)題，看看有多少條出現(xiàn)于你最近的項(xiàng)目中。如果其中有三四條以上與你的經(jīng)歷相符，那么本書(shū)就是為你量身定做的。* 從來(lái)沒(méi)有清晰制定過(guò)項(xiàng)目的業(yè)務(wù)目標(biāo)、愿景和范圍。* 客戶太忙，沒(méi)有時(shí)間與分析師或開(kāi)發(fā)人員共同處理需求。* 團(tuán)隊(duì)無(wú)法與用戶代表直接互動(dòng)，不理解他們的具體需要。* 客戶認(rèn)為所有的需求都很關(guān)鍵，因此沒(méi)有對(duì)需求排定優(yōu)先級(jí)。* 開(kāi)發(fā)人員在寫(xiě)代碼時(shí)遇到了模棱兩可或者遺漏的信息，所以只能靠猜。* 開(kāi)發(fā)人員與干系人溝通的重點(diǎn)集中于用戶界面展示或者特性，并沒(méi)有關(guān)注用戶要使用軟件完成的具體任務(wù)。* 需求從來(lái)沒(méi)得到過(guò)客戶的認(rèn)可。* 客戶認(rèn)可了某個(gè)發(fā)布或者迭代的需求，但事后又不斷更改。* 不斷接受客戶的需求變更請(qǐng)求，項(xiàng)目范圍隨之?dāng)U大，由于沒(méi)有增加資源或者刪減功能，進(jìn)度最后完全被打亂。* 有人提出了變更請(qǐng)求，但被忽略，沒(méi)人知道特定變更請(qǐng)求的具體狀態(tài)。* 客戶提出特定的功能要求，而且開(kāi)發(fā)人員也建好了，但就是沒(méi)有人用過(guò)。* 在項(xiàng)目接近尾聲時(shí)，雖然滿足規(guī)范說(shuō)明，卻不滿足客戶或業(yè)務(wù)的目標(biāo)。軟件需求的定義　　人們?cè)谟懻撔枨髸r(shí)，開(kāi)始經(jīng)常會(huì)遇到專業(yè)術(shù)語(yǔ)問(wèn)題。人們從不同的角度闡述同一樣?xùn)|西，例如：用戶需求、軟件需求、業(yè)務(wù)需求、功能需求、系統(tǒng)需求、產(chǎn)品需求、項(xiàng)目需求、用戶故事、特性或者約束條件。人們又賦予了不同的需求交付物多種稱謂。對(duì)于開(kāi)發(fā)人員來(lái)說(shuō)，客戶所定義的需求聽(tīng)起來(lái)更像是一種高級(jí)產(chǎn)品概念。對(duì)于用戶來(lái)說(shuō)，開(kāi)發(fā)人員所說(shuō)的需求理念可能聽(tīng)起來(lái)更像一種具體的用戶界面設(shè)計(jì)。這種理解上的偏差讓人困惑，令人沮喪。關(guān)于“需求”的一些解釋　　即使計(jì)算機(jī)編程技術(shù)已經(jīng)有很多年頭，軟件從業(yè)者仍然在激辯“需求”的準(zhǔn)確定義。我們不想在本書(shū)中繼續(xù)這種爭(zhēng)論，只想從實(shí)用定義的角度簡(jiǎn)單表述一下�！　☆檰�(wèn)布萊恩·勞倫斯（Brian Lawrence）認(rèn)為，需求是“任何能夠驅(qū)動(dòng)設(shè)計(jì)做出選擇的東西。”這種口語(yǔ)化定義不錯(cuò)，因?yàn)楹芏嘈畔⒍加∽C了他的說(shuō)法。畢竟，開(kāi)發(fā)需求的目的就是要做出合適的設(shè)計(jì)選項(xiàng)，最終滿足客戶需要。另外一種定義認(rèn)為需求是產(chǎn)品所必備之屬性，目的是向干系人提供價(jià)值。這也沒(méi)錯(cuò)，但不太準(zhǔn)確。我們比較傾向于Ian Sommerville and Pete Sawyer （1997）所提出的觀點(diǎn)：　　　　需求是對(duì)我們應(yīng)當(dāng)執(zhí)行的任務(wù)的規(guī)范說(shuō)明。它描述系統(tǒng)的行為特性或?qū)傩�，可以是一種對(duì)系統(tǒng)開(kāi)發(fā)進(jìn)程的約束�！　　　∵@個(gè)定義認(rèn)為“需求”是多種不同類型的信息的統(tǒng)稱。需求涵蓋來(lái)自客戶視角的外部系統(tǒng)行為以及來(lái)自開(kāi)發(fā)人員視角的一些內(nèi)部特征。它們包含系統(tǒng)在特定條件下的行為和屬性，使目標(biāo)用戶覺(jué)得系統(tǒng)易于甚至樂(lè)于上手。
字典中的“需求”　　字典對(duì)“需求”的解釋為：“被命令或者強(qiáng)制性的東西；需要或者必要。”這與軟件界所使用的“需求”不是一個(gè)含義。人們有時(shí)會(huì)懷疑是否有必要對(duì)需求進(jìn)行優(yōu)先級(jí)排序，因?yàn)橛械牡蛢?yōu)先級(jí)需求可能永遠(yuǎn)不會(huì)被實(shí)現(xiàn)。人們認(rèn)為如果對(duì)某些東西的需求不是太強(qiáng)烈，就說(shuō)明它們不是需求�？赡苁沁@樣，但我們管這類信息叫什么？如果將當(dāng)前項(xiàng)目中的需求推遲到未來(lái)某個(gè)不確定的發(fā)布之中，它還是需求嗎？當(dāng)然是。　　軟件需求包含一個(gè)時(shí)間維度。它們可能是描述目前系統(tǒng)性能的現(xiàn)在時(shí)�；蛘咚鼈兛赡苁墙�期（高優(yōu)先級(jí)）、中期（中等優(yōu)先級(jí)）或者想象中（低優(yōu)先級(jí)）的未來(lái)。甚至可能是過(guò)去時(shí)，也就是那些曾經(jīng)被人指定但后來(lái)又被舍棄的需要。我們沒(méi)必要浪費(fèi)時(shí)間爭(zhēng)論某個(gè)東西是否是需求，即使知道自己會(huì)為了某個(gè)合理的業(yè)務(wù)原因而永遠(yuǎn)不執(zhí)行它。需求就是需求。需求的層次和種類　　由于有很多不同類型的需求信息，所以我們現(xiàn)在需要用一組形容詞來(lái)修飾一下被人們賦予太多意義的“需求”。表1-1列出了需求領(lǐng)域的一些常用術(shù)語(yǔ)�！　”�1-1  一些類型的需求信息術(shù)語(yǔ) 定義業(yè)務(wù)需求開(kāi)發(fā)產(chǎn)品的組織或者獲取產(chǎn)品的客戶所需的高層次業(yè)務(wù)目標(biāo)業(yè)務(wù)規(guī)則策略、綱領(lǐng)、標(biāo)準(zhǔn)或者制度，能夠定義或者約束某些方面的業(yè)務(wù)。雖然本身并不是軟件需求，但它卻是一些類型的軟件需求的鼻祖約束對(duì)開(kāi)發(fā)人員在產(chǎn)品設(shè)計(jì)和構(gòu)建上的限制條件外部界面需求對(duì)軟件系統(tǒng)和用戶、其他軟件系統(tǒng)或硬件設(shè)備間的關(guān)聯(lián)進(jìn)行說(shuō)明特性單個(gè)或者多個(gè)為用戶提供價(jià)值的、有邏輯關(guān)系的系統(tǒng)性能，可以通過(guò)一個(gè)功能需求集合進(jìn)行描述功能需求描述系統(tǒng)在特定條件下展現(xiàn)的行為?   續(xù)表術(shù)語(yǔ) 定義非功能需求描述系統(tǒng)必須展現(xiàn)的屬性或者特性，或者必須遵守的約束質(zhì)量屬性一種非功能需求，描述的是服務(wù)或者一個(gè)產(chǎn)品的性能特征系統(tǒng)需求包含多個(gè)子系統(tǒng)的產(chǎn)品的頂層需求，子系統(tǒng)可以是軟件，也可以是軟硬件用戶需求特定用戶群必須能夠用系統(tǒng)所完成的目標(biāo)或任務(wù)，或者是用戶期望有的產(chǎn)品屬性　　　　軟件需求有三種不同的層次：業(yè)務(wù)需求、用戶需求和功能需求。此外，每個(gè)系統(tǒng)都包含某種類別的非功能需求。不同種類的需求如圖1-1中的模型所示。正如統(tǒng)計(jì)學(xué)家喬治E.?P.?巴克斯（George E. P. Box）的一句名言所述：“從本質(zhì)上講，雖然一切模型都是錯(cuò)誤的，但有些還是有作用的。”（Box and Draper 1987）。這句話用來(lái)形容圖1-1真是恰如其分。這個(gè)模型也許并不全面，但提供的方案非常實(shí)用，可以幫助組織需求方面的知識(shí)。　　圖1-1所示橢圓中的內(nèi)容代表需求信息的種類，長(zhǎng)方形表示儲(chǔ)存信息的文件。實(shí)線箭頭表示具體類型的信息通常儲(chǔ)存于所示文件之中。（業(yè)務(wù)規(guī)則、系統(tǒng)需求應(yīng)與軟件需求獨(dú)立存儲(chǔ)，例如存儲(chǔ)在業(yè)務(wù)規(guī)則目錄或者系統(tǒng)需求規(guī)范說(shuō)明之中。）虛線箭頭代表一種信息起源于或者受另外一種信息的影響。此圖沒(méi)有具體展示數(shù)據(jù)需求。數(shù)據(jù)受控于功能，因此數(shù)據(jù)需求貫穿于這三個(gè)層次的需求之中。第7章有很多這些不同種類的需求信息的示例。
 圖1-1  各類需求之間的關(guān)系。實(shí)線代表“被存儲(chǔ)于”；虛線代表“起源”?或“影響”

　　　　業(yè)務(wù)需求描述組織為什么要執(zhí)行系統(tǒng)（組織希望獲得的業(yè)務(wù)收益）。其關(guān)注點(diǎn)在于組織或者提出系統(tǒng)要求的客戶有哪些業(yè)務(wù)目標(biāo)。我們假設(shè)有家航空公司打算把機(jī)場(chǎng)的柜臺(tái)工作人員成本降低25%。為此，人們通常想到的是建一個(gè)自助服務(wù)終端，供乘客在機(jī)場(chǎng)自行檢票。項(xiàng)目的出資方、目標(biāo)客戶、實(shí)際用戶的管理層、市場(chǎng)部門或者產(chǎn)品規(guī)劃部門一般都會(huì)有業(yè)務(wù)需求。我們喜歡將業(yè)務(wù)需求記錄在愿景或者范圍文件之中。還有一些戰(zhàn)略性指導(dǎo)文件有時(shí)也會(huì)用于此目標(biāo)，包括項(xiàng)目圖表、業(yè)務(wù)實(shí)例以及市場(chǎng)（或者營(yíng)銷）需求文件。第5章的主要內(nèi)容是對(duì)業(yè)務(wù)需求進(jìn)行詳細(xì)說(shuō)明�？紤]到本書(shū)的主旨，我們假定已經(jīng)確定了業(yè)務(wù)需求或市場(chǎng)機(jī)遇。　　用戶需求描述了用戶使用產(chǎn)品必須完成的目標(biāo)或者任務(wù)，并且這個(gè)產(chǎn)品要能夠?yàn)槿颂峁﹥r(jià)值。用戶需求主要還包括對(duì)用戶滿意度最為關(guān)鍵的產(chǎn)品特性或特征的描述。用例（Kulak and Guiney 2004）、用戶故事（Cohn 2004）以及事件響應(yīng)表都是用戶需求的表示方式。理想狀態(tài)下，這種信息由實(shí)際用戶代表提供。用戶需求表達(dá)的是用戶通過(guò)系統(tǒng)來(lái)完成哪些具體工作。通過(guò)航空公司網(wǎng)站或者機(jī)場(chǎng)自助檢票機(jī)“辦理登機(jī)手續(xù)”是“用例”的典型例子。如果將其寫(xiě)為“用戶故事”，同樣的用戶需求可能是這樣的：“作為一名乘客，我想辦理登機(jī)手續(xù)，以便能夠登機(jī)。”還有一點(diǎn)我們不能忘記，即大多數(shù)項(xiàng)目都有若干個(gè)用戶類別和其他干系人，我們還必須獲取它們的需求。第8章將對(duì)這種層次的模型進(jìn)行解釋。有些人喜歡用“干系人的需求”這個(gè)更廣義的術(shù)語(yǔ)來(lái)說(shuō)明各類干系人比直接客戶更能提供需求。這當(dāng)然沒(méi)有問(wèn)題，但是我們要在這個(gè)層級(jí)集中注意力，理解實(shí)際用戶要用這個(gè)產(chǎn)品完成哪些具體目標(biāo)�！　」δ苄枨笳f(shuō)的是產(chǎn)品在特定條件下所展示出來(lái)的行為，主要描述開(kāi)發(fā)人員需要實(shí)現(xiàn)的功能以便用戶能夠完成自己的任務(wù)（用戶需求），進(jìn)而滿足業(yè)務(wù)需求。這三種需求環(huán)環(huán)相扣，對(duì)項(xiàng)目的成功至關(guān)重要。人們經(jīng)常將功能需求記錄為傳統(tǒng)意義上的“應(yīng)當(dāng)”句式：“乘客應(yīng)當(dāng)能夠隨時(shí)打印自己已經(jīng)辦好登機(jī)手續(xù)的所有航段的登機(jī)牌”或者“如果乘客信息沒(méi)有指定座位偏好，航班預(yù)訂系統(tǒng)就應(yīng)當(dāng)為它分配。”　　業(yè)務(wù)分析師（BA）①將功能需求記錄在軟件需求規(guī)范說(shuō)明（software requirements specification，SRS）之中，盡可能詳盡地描述人們對(duì)軟件系統(tǒng)的預(yù)期行為。SRS用于開(kāi)發(fā)、測(cè)試、質(zhì)量保障、項(xiàng)目管理和相關(guān)項(xiàng)目功能。它的稱謂很多，包括業(yè)務(wù)需求文件、功能規(guī)范說(shuō)明、需求文件等。SRS可以是一個(gè)報(bào)告，由存儲(chǔ)在需求管理工具中的信息所生成。由于它已成為一種行業(yè)標(biāo)準(zhǔn)術(shù)語(yǔ)，所以我們?cè)诒緯?shū)中將其統(tǒng)稱為“SRS”（ISO/IEC/IEEE 2011）。要想進(jìn)一步了解SRS，請(qǐng)參見(jiàn)第10章�！　∠到y(tǒng)需求描述了人們對(duì)某個(gè)產(chǎn)品的需求，而這個(gè)產(chǎn)品由多個(gè)組件或者系統(tǒng)子集組成（ISO/IEC/IEEE 2011）。“系統(tǒng)”在此不單單是信息名義上的系統(tǒng)。所有軟件或軟件、硬件系統(tǒng)子集都可以算是系統(tǒng)。甚至人和過(guò)程也是系統(tǒng)的一部分，因此某些特定的系統(tǒng)功能可以分配給人。有些人使用“系統(tǒng)需求”這個(gè)詞來(lái)表達(dá)對(duì)軟件系統(tǒng)的具體需求，但我們?cè)诒緯?shū)中并不這樣使用該術(shù)語(yǔ)�！　〕�市收銀員的工作臺(tái)算是“系統(tǒng)”的一個(gè)典型例子。超市里有與稱重設(shè)施相連的條形碼掃描儀和手持式條形碼掃描儀。收銀員有鍵盤、顯示器和現(xiàn)金抽屜。我們?cè)诔�市里面還可以發(fā)現(xiàn)用于刷積分卡、信用卡或者借記卡的讀卡器和PIN盒，甚至還有自動(dòng)找零機(jī)。甚至還可以看到三臺(tái)打印機(jī)分別打印購(gòu)物小票、信用卡簽單和優(yōu)惠券，只不過(guò)這些對(duì)你來(lái)說(shuō)無(wú)關(guān)緊要。這些硬件設(shè)備都在軟件控制下互相關(guān)聯(lián)。隨后，業(yè)務(wù)分析師根據(jù)系統(tǒng)或者產(chǎn)品的整體需求提取具體功能，將其分配給這些組件系統(tǒng)子集中的某一個(gè)，同時(shí)了解它們之間的接口。　　業(yè)務(wù)規(guī)則包括公司政策、政府法規(guī)、工業(yè)標(biāo)準(zhǔn)以及計(jì)算算法。在第9章中，將說(shuō)明業(yè)務(wù)規(guī)則本身并不是軟件需求，因?yàn)樗�的存在已�?jīng)超出了任何特定軟件應(yīng)用的范圍。然而，它們又經(jīng)常決定著系統(tǒng)為了切合相關(guān)規(guī)則而必須包含哪些功能。正如公司安全策略一樣，業(yè)務(wù)規(guī)則有時(shí)又引申出具體的質(zhì)量特性，這些特性又以功能的方式由開(kāi)發(fā)人員實(shí)現(xiàn)。因此，特定的功能需求可以追溯到具體的業(yè)務(wù)規(guī)則�！　〕�了功能需求，SRS還包含某些類別的非功能需求。質(zhì)量屬性也被人們稱為質(zhì)量因子、服務(wù)需求質(zhì)量、約束以及“***性”。它們從不同角度描述產(chǎn)品特征，例如性能、安全性、易用性和可移植性，這些對(duì)于用戶、開(kāi)發(fā)人員和維護(hù)人員來(lái)說(shuō)都非常重要。還有一些非功能需求描述系統(tǒng)與外部世界的接口，包括與其他軟件系統(tǒng)、硬件組件、用戶以及溝通界面的關(guān)聯(lián)。在創(chuàng)建產(chǎn)品的過(guò)程中，開(kāi)發(fā)人員的選擇受限于設(shè)計(jì)和實(shí)現(xiàn)約束。
非功能需求到底是什么？　　要想對(duì)組織中的現(xiàn)有需求實(shí)踐做一次快速體檢，就需要對(duì)比下列問(wèn)題，看看有多少條出現(xiàn)于你最近的項(xiàng)目。如果其中有三四條以上與你的經(jīng)歷相符，那么本書(shū)就是為你量身定做的。　　在項(xiàng)目接近尾聲時(shí)，雖然滿足了規(guī)范說(shuō)明，卻不滿足客戶或業(yè)務(wù)的目標(biāo)。　　多年以來(lái)，人們從廣義上將軟件產(chǎn)品需求分為功能需求或者非功能需求。功能需求理解起來(lái)很容易，它們描述的是系統(tǒng)在不同條件下能夠被用戶觀察到的行為。然而，大多數(shù)人都不喜歡“非功能”這個(gè)術(shù)語(yǔ)。因?yàn)檫@個(gè)形容詞強(qiáng)調(diào)的是需求不是什么，并沒(méi)有說(shuō)明需求是什么。很遺憾，對(duì)于這個(gè)問(wèn)題，至今沒(méi)有一個(gè)令人滿意的答案。　　功能之外的需求強(qiáng)調(diào)的并不是系統(tǒng)要做什么，其重點(diǎn)在于系統(tǒng)做得有多棒。它們對(duì)系統(tǒng)最重要的特征或?qū)傩赃M(jìn)行描述，包括系統(tǒng)的易用性、易用性、安全性和性能等很多特征，這些都在第14章中有所體現(xiàn)。有些人將非功能需求等同于質(zhì)量屬性，但這過(guò)于狹隘。例如，設(shè)計(jì)和實(shí)現(xiàn)約束也是非功能需求，外部接口需求也是�！　∵�有其他一些非功能需求，它們描述的是系統(tǒng)運(yùn)行環(huán)境，例如平臺(tái)、可移植性、兼容性和約束。很多產(chǎn)品還受兼容性、監(jiān)管和發(fā)行許可的影響。我們甚至還要考慮到產(chǎn)品的地域性需求，例如用戶的文化、語(yǔ)言、法律、貨幣、專有名詞、拼寫(xiě)和其他特征。雖然此類需求被歸入功能需求，但業(yè)務(wù)分析師仍然可以從中獲得大量的功能，確保系統(tǒng)的所有行為和屬性符合用戶的預(yù)期�！　”M管有其局限性，但由于沒(méi)有一種合適的替代選項(xiàng)，所以我們?cè)诒緯?shū)中仍使用“非功能需求”這一術(shù)語(yǔ)。這類信息的名稱是否準(zhǔn)確并不重要，但要保證將它們納入需求獲取和分析活動(dòng)。交付的產(chǎn)品雖然囊括所有預(yù)想的功能，但用戶還是不喜歡，因?yàn)樗�不符合人們�?duì)其產(chǎn)品質(zhì)量（通常未明確表達(dá)）的預(yù)期。　　　　　　一個(gè)特性包含一個(gè)或者多個(gè)邏輯上有關(guān)聯(lián)的系統(tǒng)功能，能夠?yàn)橛脩籼峁﹥r(jià)值，這些由一組功能性需求來(lái)共同描述�？蛻纛A(yù)想的產(chǎn)品特性清單與描述客戶的任務(wù)相關(guān)的需求不能畫(huà)等號(hào)。網(wǎng)頁(yè)瀏覽器的書(shū)簽、拼寫(xiě)檢查、為運(yùn)動(dòng)器械設(shè)定定制鍛煉程序、殺毒軟件中病毒庫(kù)的自動(dòng)升級(jí)，這些都是典型的特性。特性包含多種用戶需求，每種需求都表示特定的功能需求必須實(shí)現(xiàn)，以便用戶能完成用戶需求中所描述的任務(wù)。圖1-2就是一個(gè)特性樹(shù)，也可以說(shuō)是一個(gè)分析模型，展示的是特性如何層層分解為更小的特性組，這些小特性與具體的用戶需求關(guān)聯(lián)，最終引出功能需求（Beatty and Chen 2012）。

　　圖1-2  特性、用戶需求和功能性需求之間的關(guān)系　　為了解釋這些不同類型的需求，我們假設(shè)在開(kāi)發(fā)某個(gè)文本編輯程序的新版本。“在6個(gè)月內(nèi)將非美國(guó)地區(qū)的銷量增加25%”可以算是一種業(yè)務(wù)需求。市場(chǎng)部發(fā)現(xiàn)參與競(jìng)爭(zhēng)的產(chǎn)品只有英語(yǔ)拼寫(xiě)檢查器，因此他們決定新版本要包括一個(gè)多語(yǔ)種拼寫(xiě)檢查器特性。對(duì)應(yīng)的用戶需求可能包含諸如“為拼寫(xiě)檢查器選擇語(yǔ)言”“發(fā)現(xiàn)拼寫(xiě)錯(cuò)誤”和“將詞添加到字典”這樣的任務(wù)。拼寫(xiě)檢查器有很多獨(dú)立的功能需求，涉及的操作包括高亮拼寫(xiě)錯(cuò)誤的單詞、自動(dòng)糾錯(cuò)、顯示建議替代選項(xiàng)、用正確的單詞整體替代拼寫(xiě)錯(cuò)誤的單詞。易用性需求明確指定如何使用特定語(yǔ)言和字符集來(lái)定位軟件的使用區(qū)域。處理三種層次的需求　　圖1-3向我們展示了不同的干系人如何參與獲取三種層次的需求。不同組織對(duì)參與到這些活動(dòng)中的角色稱呼各異，考慮一下組織內(nèi)部的這些活動(dòng)。根據(jù)開(kāi)發(fā)組織是一個(gè)公司內(nèi)部實(shí)體性質(zhì)還是一個(gè)開(kāi)發(fā)商用軟件的公司，角色的名稱可能有所不同�！　「鶕�(jù)特定的業(yè)務(wù)需求、市場(chǎng)需求或者某個(gè)新奇的產(chǎn)品概念，經(jīng)理或者市場(chǎng)部門確定軟件的業(yè)務(wù)需求，使公司運(yùn)營(yíng)更加高效（對(duì)信息系統(tǒng)而言）或具有很強(qiáng)的市場(chǎng)競(jìng)爭(zhēng)力（對(duì)商業(yè)產(chǎn)品而言）。在企業(yè)環(huán)境中，業(yè)務(wù)分析師通常與用戶代表協(xié)同工作，確定客戶需求。而開(kāi)發(fā)商業(yè)產(chǎn)品的公司通常讓產(chǎn)品經(jīng)理決定新產(chǎn)品應(yīng)當(dāng)包含的具體特性。每個(gè)用戶需求和特性必須向完成業(yè)務(wù)需求看齊。從用戶需求角度出發(fā)，業(yè)務(wù)分析師或者產(chǎn)品經(jīng)理引出能夠使用戶實(shí)現(xiàn)任務(wù)目標(biāo)的功能。開(kāi)發(fā)人員根據(jù)功能和非功能需求來(lái)設(shè)計(jì)解決方案，執(zhí)行必要的功能，但要在約束的限制范圍之內(nèi)。測(cè)試人員決定如何驗(yàn)證需求是否已經(jīng)正確實(shí)現(xiàn)。
　　圖1-3  不同干系人如何參與需求開(kāi)發(fā)　　我們還要認(rèn)識(shí)到以共享方式記錄關(guān)鍵需求信息的重要性，而不應(yīng)只是用傳統(tǒng)的口述形式。我曾經(jīng)參與過(guò)一個(gè)項(xiàng)目，其中的開(kāi)發(fā)團(tuán)隊(duì)互相推諉。首席客戶被折磨得欲哭無(wú)淚，因?yàn)槊總�(gè)新團(tuán)隊(duì)都單獨(dú)找他談話：“我們得談一談貴方的需求。”對(duì)于我們這個(gè)要求，他的第一反應(yīng)就是：“我已經(jīng)將我的需求給了你們的前任�，F(xiàn)在我只要你們給我編個(gè)系統(tǒng)！”不幸的是，沒(méi)人記錄下任何需求，因此每個(gè)新團(tuán)隊(duì)都得從頭開(kāi)始。如果只有一堆郵件和留言信息、便條、會(huì)議記錄和跟客戶在走廊里短暫談話的模糊回憶就宣稱“已經(jīng)有了需求”，簡(jiǎn)直就是自欺欺人。BA必須做到心中有數(shù)，能夠綜合考慮如何為特定的項(xiàng)目確定需求文檔　　本章前面所提到的圖1-1顯示了三種主要的需求交付物：愿景和范圍文檔、用戶需求文檔和軟件需求規(guī)范說(shuō)明。無(wú)需為每個(gè)項(xiàng)目都創(chuàng)建三種獨(dú)立的需求交付物。但將這類需求信息融合在一起（特別是對(duì)于小型項(xiàng)目），還是有必要的。然而，還要注意這三種交付物包含著不同的信息，要在項(xiàng)目的不同點(diǎn)進(jìn)行開(kāi)發(fā)，開(kāi)發(fā)人員也可能不同，目的和目標(biāo)受眾也不相同。　　圖1-1所示的模型為我們展示了一個(gè)簡(jiǎn)單的自上而下的需求信息流。在現(xiàn)實(shí)生活中，我們見(jiàn)到的是以業(yè)務(wù)、用戶和功能需求為中心的循環(huán)和迭代。只要有人提出某個(gè)新特性、用戶需求或者一點(diǎn)點(diǎn)功能，分析師肯定會(huì)問(wèn)：“這在范圍內(nèi)嗎？”如果答案為“是”，就將此需求歸入規(guī)范說(shuō)明。如果答案是“不”，就算了，起碼不會(huì)放到下一個(gè)發(fā)布或者迭代之中。還有一種可能的回答：“不，但它支持業(yè)務(wù)目標(biāo)，所以應(yīng)該算是吧。”在這種情況下，不管是誰(shuí)負(fù)責(zé)項(xiàng)目范圍——項(xiàng)目發(fā)起方、項(xiàng)目經(jīng)理或者是產(chǎn)品負(fù)責(zé)人——都必須當(dāng)機(jī)立斷，決定是否增加當(dāng)前項(xiàng)目或者迭代的范圍以適應(yīng)新的需求。這種業(yè)務(wù)決策對(duì)項(xiàng)目的計(jì)劃和預(yù)算都有著很大的影響，可能要對(duì)其他功能做出妥協(xié)。高效的變更過(guò)程包含“影響分析”以保證合適的人做出可靠的業(yè)務(wù)決策，確定哪些變更可以接受，解決時(shí)間、資源或特性權(quán)衡所關(guān)聯(lián)的成本。產(chǎn)品需求與項(xiàng)目需求　　到目前為止，我們討論的需求主要描述軟件系統(tǒng)的屬性。我們將其稱為產(chǎn)品需求。當(dāng)然，項(xiàng)目還包含有其他的訴求和產(chǎn)出，不在團(tuán)隊(duì)執(zhí)行的軟件范圍之內(nèi)，但對(duì)項(xiàng)目的整體成敗尤為關(guān)鍵。這些都是項(xiàng)目需求而非產(chǎn)品需求。SRS包含產(chǎn)品需求，但不包括設(shè)計(jì)或執(zhí)行細(xì)節(jié)（不同于已知的約束）、項(xiàng)目計(jì)劃、測(cè)試計(jì)劃或者類似信息。要將這類事項(xiàng)獨(dú)立出去，使需求開(kāi)發(fā)活動(dòng)聚焦于理解團(tuán)隊(duì)要開(kāi)發(fā)的內(nèi)容。項(xiàng)目需求包括以下具體內(nèi)容。* 開(kāi)發(fā)團(tuán)隊(duì)的物質(zhì)需求，比如工作站、專用硬件設(shè)備、測(cè)試實(shí)驗(yàn)室、測(cè)試工具和設(shè)備、團(tuán)隊(duì)辦公室和視頻會(huì)議設(shè)備。* 員工培訓(xùn)需求。* 用戶文檔，包括培訓(xùn)材料、教程、參考手冊(cè)和發(fā)行說(shuō)明。* 支持文件，例如幫助資源、硬件的現(xiàn)場(chǎng)維護(hù)和服務(wù)信息。* 操作環(huán)境中所需要的基礎(chǔ)設(shè)施變更。* 需求和流程，用于發(fā)布產(chǎn)品，在實(shí)際操作環(huán)境中安裝產(chǎn)品，對(duì)它進(jìn)行配置和測(cè)試。* 針對(duì)從舊系統(tǒng)遷移到新系統(tǒng)所做的需求和規(guī)則，例如數(shù)據(jù)合并和轉(zhuǎn)換、安全設(shè)置、產(chǎn)品切換以及為彌補(bǔ)技術(shù)空白而做的培訓(xùn)，我們有時(shí)稱之為遷移需求（IIBA 2009）。* 產(chǎn)品認(rèn)證和合規(guī)需求。* 修改的策略、過(guò)程、組織結(jié)構(gòu)和類似文檔。* 第三方軟件和硬件組件的采購(gòu)、收購(gòu)和許可。* Beta測(cè)試、生產(chǎn)、包裝、市場(chǎng)和發(fā)行需求。* 客戶服務(wù)等級(jí)協(xié)議�！　♂槍�(duì)與軟件相關(guān)的知識(shí)產(chǎn)權(quán)，為獲取法律保護(hù)（專利、商標(biāo)或者版權(quán)）所做的需求�！　”緯�(shū)不對(duì)這類項(xiàng)目需求做過(guò)多的論述。但這并不是說(shuō)它們不重要，只是超出了我們的范圍，我們側(cè)重的是軟件產(chǎn)品需求的開(kāi)發(fā)和管理。識(shí)別這些項(xiàng)目需求是業(yè)務(wù)分析師和項(xiàng)目經(jīng)理的共同責(zé)任。他們?cè)讷@取產(chǎn)品需求時(shí)經(jīng)常涉及這方面的內(nèi)容。項(xiàng)目需求信息最好存儲(chǔ)在項(xiàng)目管理計(jì)劃之中，詳細(xì)列出全部預(yù)期項(xiàng)目活動(dòng)和交付物。　　特別是針對(duì)業(yè)務(wù)應(yīng)用，人們有時(shí)認(rèn)為“解決方案”包含產(chǎn)品需求（業(yè)務(wù)分析師的主要責(zé)任）和項(xiàng)目需求（項(xiàng)目經(jīng)理負(fù)主要職責(zé)）。他們使用“解決方案的范圍”這個(gè)術(shù)語(yǔ)來(lái)表達(dá)“為勝利完成項(xiàng)目而必須完成的一切工作。”但在本書(shū)中，我們主要討論產(chǎn)品需求，不管最終的交付物是某個(gè)商業(yè)軟件產(chǎn)品、帶嵌入式軟件的硬件設(shè)備、企業(yè)信息系統(tǒng)、政府定制軟件還是其他任何東西。需求開(kāi)發(fā)和管理　　人們對(duì)需求術(shù)語(yǔ)的困惑甚至延伸到整個(gè)學(xué)科的稱謂上。有些作者將整個(gè)范圍都稱為“需求工程”（我們贊同此觀點(diǎn)）。有些人統(tǒng)稱為“需求管理”。還有些人認(rèn)為這些活動(dòng)屬于廣義上的業(yè)務(wù)分析的一個(gè)分支�！　∥覀儼l(fā)現(xiàn)，最好將需求工程分為需求開(kāi)發(fā)（參見(jiàn)本書(shū)第II部分）和需求管理（參見(jiàn)第IV部分），如圖1-4所示。不管項(xiàng)目遵循什么樣的開(kāi)發(fā)生命周期——純瀑布法、分階段開(kāi)發(fā)方法、迭代開(kāi)發(fā)、增量開(kāi)發(fā)、敏捷方法或者混合各種開(kāi)發(fā)方式——這些需求工作都要完成。根據(jù)項(xiàng)目生命周期，在項(xiàng)目的不同階段實(shí)施這些活動(dòng)，只不過(guò)深度或廣度有所差異。
　　圖1-4  軟件需求工程的細(xì)分
需求開(kāi)發(fā)　　如圖1-4所示，我們將需求開(kāi)發(fā)細(xì)分為：獲取、分析、規(guī)范說(shuō)明和驗(yàn)證（Abran et al. 2004）。這些細(xì)分囊括的活動(dòng)涉及產(chǎn)品需求的開(kāi)發(fā)、評(píng)估、記錄和確認(rèn)。下面介紹每個(gè)細(xì)分中的一些基本活動(dòng)�！　～@取　　需求獲取涵蓋需求發(fā)現(xiàn)的所有活動(dòng)，例如訪談、研討會(huì)、文檔分析、原型等。主要活動(dòng)如下所示。* 識(shí)別產(chǎn)品的預(yù)期客戶群和其他干系人。* 理解客戶任務(wù)、目標(biāo)以及與這些任務(wù)相關(guān)的業(yè)務(wù)目標(biāo)。* 了解新產(chǎn)品的應(yīng)用環(huán)境。* 與每一類客戶群的代表一起工作，理解他們對(duì)功能有哪些需要以及對(duì)質(zhì)量有怎樣的預(yù)期。以用途為核心還是以產(chǎn)品為核心？　　雖然有多種策略可用，但我們?cè)谶M(jìn)行需求獲取活動(dòng)時(shí)，通常采取以用途為核心或者以產(chǎn)品為核心的方法。以用途為核心的策略強(qiáng)調(diào)的是對(duì)用戶目標(biāo)的理解和探求，以便提取必要的系統(tǒng)功能。以產(chǎn)品為核心的方法側(cè)重于特性，目的是領(lǐng)先市場(chǎng)或者業(yè)務(wù)取得成功。以產(chǎn)品為中心的策略，其風(fēng)險(xiǎn)在于開(kāi)發(fā)人員辛辛苦苦實(shí)現(xiàn)的特性并沒(méi)有得到很高的利用，雖然它們當(dāng)時(shí)看似都是奇思妙想。我們建議先理解業(yè)務(wù)目標(biāo)和用戶目標(biāo)，然后根據(jù)自己得出的見(jiàn)解來(lái)確定合適的產(chǎn)品特性和特征�！　》治觥　》治鲂枨笊婕吧钊氩�準(zhǔn)確理解每個(gè)需求，然后將各個(gè)需求以不同的方式表達(dá)出來(lái)。下面是一些基本活動(dòng)。* 分析來(lái)自用戶的信息，將其任務(wù)目標(biāo)與功能需求、質(zhì)量預(yù)期、業(yè)務(wù)規(guī)則、建議解決方案和其他信息區(qū)別開(kāi)。* 將概要需求進(jìn)行適當(dāng)?shù)募?xì)分。* 從其他需求信息中引出功能需求。* 理解質(zhì)量屬性的相對(duì)重要性。* 將需求分配給系統(tǒng)架構(gòu)所定義的軟件組件。* 協(xié)商需求實(shí)現(xiàn)的優(yōu)先級(jí)別�！　≌页鲂枨笾械倪z漏的或多余的、不必要的需求，以便定義范圍�！　∫�(guī)范說(shuō)明　　需求規(guī)范說(shuō)明以一種連貫并結(jié)構(gòu)清晰的方式來(lái)表達(dá)和存儲(chǔ)收集到的需求知識(shí)。主要活動(dòng)如下。* 將收集到的用戶需求轉(zhuǎn)換為書(shū)面形式的需求和圖表，供目標(biāo)讀者理解、檢查和使用�！　◎�(yàn)證　　需求驗(yàn)證是指確認(rèn)需求信息是正確的，能使開(kāi)發(fā)人員制定出能滿足業(yè)務(wù)目標(biāo)的解決方案。其中心活動(dòng)如下所示。* 檢查記錄下來(lái)的需求，在交給開(kāi)發(fā)團(tuán)隊(duì)認(rèn)可之前解決所有問(wèn)題。* 開(kāi)發(fā)驗(yàn)收測(cè)試和標(biāo)準(zhǔn)，保證產(chǎn)品的開(kāi)發(fā)是建立在需求基礎(chǔ)之上的，能夠滿足客戶需要并達(dá)成業(yè)務(wù)目標(biāo)�！　〉�代是成功需求開(kāi)發(fā)的關(guān)鍵。規(guī)劃出多周期的需求探究活動(dòng)，我們要逐步優(yōu)化概要需求，使其進(jìn)一步準(zhǔn)確和細(xì)化，并與用戶共同確認(rèn)得出正確的需求。這可能是費(fèi)力不討好的活兒。但如果想解決新軟件系統(tǒng)的不確定性，這個(gè)工作就是不可避免的。
需求管理　　需求管理活動(dòng)如下所示。* 及時(shí)確定需求基線，提交一個(gè)供當(dāng)前時(shí)間段使用的參考，提出一套大家商定的、經(jīng)過(guò)評(píng)審和批準(zhǔn)的功能需求與非功能需求，通常針對(duì)具體的產(chǎn)品發(fā)布或者開(kāi)發(fā)迭代。* 評(píng)估提議需求變更可能產(chǎn)生的影響，然后以可控方式將獲準(zhǔn)的變更融入項(xiàng)目。* 隨著需求的演化，保持項(xiàng)目計(jì)劃與需求同步。* 根據(jù)預(yù)估的需求變更可能帶來(lái)的影響，商定新的承諾。* 定義各個(gè)需求之間存在的關(guān)系和依賴。* 跟蹤每個(gè)需求到它們各自對(duì)應(yīng)的設(shè)計(jì)、源代碼和測(cè)試。* 在整個(gè)項(xiàng)目過(guò)程中跟蹤需求狀態(tài)和變更活動(dòng)。　　需求管理的目標(biāo)不是抑制變更或加大其難度，而是為了預(yù)測(cè)和協(xié)調(diào)不可避免且實(shí)際存在的變更，最終最小化變更對(duì)項(xiàng)目的破壞性影響�！　�圖1-5從另外一個(gè)視角為我們闡明需求開(kāi)發(fā)與需求管理之間的區(qū)別。本書(shū)有許多需求獲取、分析、規(guī)范說(shuō)明、驗(yàn)證和管理方面的具體實(shí)踐。

　　圖1-5  需求開(kāi)發(fā)和需求管理的界限每個(gè)項(xiàng)目都有需求　　布魯克斯（Frederick Brooks）在他1987年發(fā)表的經(jīng)典論文“沒(méi)有銀彈：軟件工程的根本問(wèn)題和次要問(wèn)題”中對(duì)需求在軟件項(xiàng)目中扮演的角色做出以下精彩的論述：　　　　開(kāi)發(fā)軟件系統(tǒng)最困難的部分是準(zhǔn)確判斷開(kāi)發(fā)什么。最難的概念性工作便是確定詳細(xì)的技術(shù)需求，包括所有面向用戶、機(jī)器和其他軟件系統(tǒng)的接口。這項(xiàng)工作一旦做錯(cuò)，就會(huì)削弱系統(tǒng)性能。后期的修改工作也會(huì)更困難�！　　　≤浖�涉及的相關(guān)系統(tǒng)都有對(duì)其依賴的干系人�；ㄒ恍�時(shí)間理解他們的需要，這對(duì)項(xiàng)目的成功是一種高杠桿投資。如果項(xiàng)目團(tuán)隊(duì)寫(xiě)的需求得不到干系人的認(rèn)可，開(kāi)發(fā)人員如何確定自己的工作可以使干系人滿意呢？　　我們通常不太可能也沒(méi)有必要在開(kāi)始設(shè)計(jì)和執(zhí)行之前就指定全部功能需求。在這種情況下，可以采用迭代或者漸進(jìn)式方法，一次只執(zhí)行一部分需求，然后獲取客戶的反饋，然后再進(jìn)入下一個(gè)循環(huán)。敏捷開(kāi)發(fā)的精髓就在于此：充分理解需求，制定周全的優(yōu)先級(jí)排序和發(fā)布計(jì)劃，使團(tuán)隊(duì)盡快開(kāi)始交付有價(jià)值的軟件。但這并不意味著下一個(gè)增量的需求還未被深思熟慮之前就有借口寫(xiě)代碼。相較于對(duì)概念進(jìn)行迭代，對(duì)代碼進(jìn)行迭代所付出的代價(jià)更高�！　∪藗冇袝r(shí)不愿花時(shí)間寫(xiě)軟件需求。但核心問(wèn)題并不在于寫(xiě)需求，而在于判斷需求。寫(xiě)需求只是在對(duì)自己所了解的內(nèi)容進(jìn)行分類、闡述和記錄。只有對(duì)產(chǎn)品需求有充分的認(rèn)識(shí)，團(tuán)隊(duì)才能正確處理問(wèn)題，并針對(duì)問(wèn)題設(shè)計(jì)出最佳的解決方案。如果不了解需求，就不知道項(xiàng)目何時(shí)完工，也不知道是否滿足目標(biāo)，在必須修改范圍時(shí)，也無(wú)法做出權(quán)衡。與其擔(dān)心在需求方面浪費(fèi)時(shí)間，還不如想一想如果項(xiàng)目對(duì)需求的關(guān)注度不夠會(huì)浪費(fèi)掉多少銀子。人對(duì)了，得出的需求卻很糟糕　　如果需求出了問(wèn)題，最大的惡果就是返工——重復(fù)以為已經(jīng)完成的工作——尤其是在開(kāi)發(fā)末期或者發(fā)布之后。返工通常會(huì)占到開(kāi)發(fā)總成本的30%～50%（Shull, et al. 2002; GAO 2004），而需求錯(cuò)誤占返工成本的70%～85%（Leffingwell 1997）。有些返工確實(shí)能增加價(jià)值和改進(jìn)產(chǎn)品，但大量的返工不僅是一種浪費(fèi)，還會(huì)挫傷士氣。設(shè)想一下如果能將返工量砍掉一半，人們的生活會(huì)變成什么樣子？團(tuán)隊(duì)成員可以更快開(kāi)發(fā)出更好的產(chǎn)品，甚至可能按點(diǎn)下班了。確定更精準(zhǔn)的需求是一種投資，并不只是成本。　　相較于在缺陷剛開(kāi)始“顯山露水”的時(shí)候就修復(fù)，在項(xiàng)目末期糾正缺陷成本顯然更高。假設(shè)在處理需求時(shí)發(fā)現(xiàn)和修復(fù)一個(gè)需求問(wèn)題要耗費(fèi)1美元。如果在設(shè)計(jì)時(shí)發(fā)現(xiàn)問(wèn)題，則要花1美元去修復(fù)需求問(wèn)題，還要花2美元或3美元重構(gòu)基于錯(cuò)誤需求的設(shè)計(jì)。但我們假設(shè)沒(méi)人發(fā)現(xiàn)錯(cuò)誤，一直到某位用戶提出問(wèn)題。根據(jù)系統(tǒng)類型，糾正運(yùn)行中所發(fā)現(xiàn)的需求缺陷可能要100美元甚至更多（981; Grady 1999; Haskins 2004）。我的一位咨詢客戶發(fā)現(xiàn)：如果使用一種優(yōu)秀的軟件檢查技巧——同行審查，發(fā)現(xiàn)并修復(fù)其信息系統(tǒng)中的缺陷需要花200美元的人工費(fèi)用（Wiegers 2002）。相反，如果由客戶來(lái)反饋，單單一個(gè)缺陷的修復(fù)，其平均成本就要4200美元，放大了21倍。預(yù)防需求錯(cuò)誤并在早期將其準(zhǔn)確捕獲對(duì)降低返工量有著巨大的杠桿效果�！　⌒枨髮�(shí)踐的不足會(huì)對(duì)項(xiàng)目的成功造成很多風(fēng)險(xiǎn)，這里的成功指的是在規(guī)定的成本和時(shí)間內(nèi)交付符合預(yù)期功能和質(zhì)量的產(chǎn)品。第32章將描述如何管理這一類風(fēng)險(xiǎn)以免搞砸項(xiàng)目。下面要介紹一些最常見(jiàn)的需求風(fēng)險(xiǎn)。用戶參與度不夠　　用戶通常不明白為什么獲取需求和確保質(zhì)量要花費(fèi)那么多功夫。開(kāi)發(fā)人員也可能不重視用戶的參與，也許是因?yàn)樗麄冇X(jué)得已經(jīng)明白用戶的具體需要了。在某些情況下，與實(shí)際使用產(chǎn)品的用戶直接接觸很難，而用戶代表并不總能理解用戶的真實(shí)需要。用戶參與度不足會(huì)引發(fā)新的需求，造成返工并延誤工期�！　∮脩魠⑴c度不足的另一個(gè)風(fēng)險(xiǎn)是業(yè)務(wù)分析師無(wú)法理解并準(zhǔn)確記錄實(shí)際業(yè)務(wù)或者客戶需要，特別是在檢查和驗(yàn)證需求時(shí)。有時(shí)，業(yè)務(wù)分析師制定的需求似乎“完美無(wú)缺”，開(kāi)發(fā)人員也開(kāi)發(fā)了這些需求，但由于業(yè)務(wù)問(wèn)題被誤解，所以解決方案仍然無(wú)人問(wèn)津。如果想消除風(fēng)險(xiǎn)，就得與客戶保持溝通，但如果客戶檢查需求時(shí)不夠仔細(xì)，問(wèn)題仍然在所難免。規(guī)劃不當(dāng)　　“我對(duì)新產(chǎn)品的想法就這些。你什么時(shí)候能完成？”除非對(duì)討論內(nèi)容有更充分的了解，否則這個(gè)問(wèn)題沒(méi)人能夠答得上來(lái)。如果不能徹底理解需求，就會(huì)得出過(guò)于樂(lè)觀的估算，而真出現(xiàn)超支后你又該撓頭了。做估算的人算得快聽(tīng)起來(lái)更像是對(duì)聽(tīng)者的一種承諾。軟件成本估算不當(dāng)?shù)闹饕�原因有：頻繁的需求變更、需求遺漏、與用戶溝通不足、低質(zhì)量的需求規(guī)范和不完善的需求分析（Davis 1995）。如果圍繞需求來(lái)估算項(xiàng)目工作量和時(shí)間，就需要了解需求的規(guī)模和開(kāi)發(fā)團(tuán)隊(duì)的生產(chǎn)效率。要想進(jìn)一步了解如何對(duì)需求進(jìn)行估算，可以參見(jiàn)第5章（Wiegers 2006）。用戶需求蔓延　　隨著需求在開(kāi)發(fā)過(guò)程中的不斷演化，項(xiàng)目經(jīng)常會(huì)超出計(jì)劃的時(shí)間和預(yù)算（計(jì)劃幾乎總是過(guò)于樂(lè)觀）。為了管理范圍蔓延，必須一開(kāi)始就對(duì)項(xiàng)目的業(yè)務(wù)目標(biāo)、戰(zhàn)略愿景、范圍、邊界和成功標(biāo)準(zhǔn)給予明確說(shuō)明。以此為參照，對(duì)所有的新特性或者需求變更進(jìn)行評(píng)估。需求會(huì)變，會(huì)發(fā)展。項(xiàng)目經(jīng)理應(yīng)當(dāng)在時(shí)間表中設(shè)置應(yīng)急緩沖區(qū)，以免打亂時(shí)間表（Wiegers 2007）。敏捷項(xiàng)目采用的方法就是對(duì)特定的迭代范圍進(jìn)行調(diào)整，使其符合迭代中規(guī)定的預(yù)算和時(shí)間。隨著新需求的涌現(xiàn)，我們可以將其植入到未完工的條目之中，然后根據(jù)優(yōu)先級(jí)別分配到未來(lái)的迭代之中。變更也許決定著項(xiàng)目成敗，但它總是有代價(jià)的。需求模棱兩可　　需求模棱兩可的一大特征就是讀的人可以用許多種方式來(lái)解讀需求說(shuō)明（Lawrence 1996）。另外一個(gè)信號(hào)是讀的人不同，對(duì)需求的理解也各不相同。第11章將列舉諸多會(huì)造成歧義的單詞和短語(yǔ)，它們模棱兩可，讓人很難準(zhǔn)確理解�！　∧＠鈨煽傻男枨髸�(huì)使不同干系人產(chǎn)生不同的期望。有些人會(huì)對(duì)交付物感到驚訝。當(dāng)開(kāi)發(fā)人員為錯(cuò)誤問(wèn)題而實(shí)施解決方案時(shí)，模棱兩可的需求就會(huì)造成時(shí)間上的浪費(fèi)。測(cè)試人員對(duì)產(chǎn)品的預(yù)期表現(xiàn)與開(kāi)發(fā)人員開(kāi)發(fā)出來(lái)的東西完全是兩回事，解決這種差異肯定是浪費(fèi)時(shí)間的�！　∫�想找出模棱兩可的需求，一個(gè)辦法是讓那些具有不同視角的人來(lái)檢查需求（Wiegers 2002）。正如第17章所提到的那樣，非正式的同行檢查只是從自己的角度來(lái)閱讀，一般看不出模棱兩可的需求。如果不同的檢查者只按照自己的理解從不同角度理解需求，也看不出歧義性需求。因此，干系人應(yīng)作為小組以工作坊的形式來(lái)討論和解讀需求，共同獲取和驗(yàn)證需求。為需求寫(xiě)測(cè)試或者建原型也可以幫助我們找出歧義性需求。鍍金　　所謂鍍金，是指開(kāi)發(fā)人員增加的功能并不在需求規(guī)范說(shuō)明之中（或者超出范圍），但開(kāi)發(fā)人員卻自認(rèn)為“用戶肯定喜歡。”如果客戶對(duì)這個(gè)功能并不在意，那么實(shí)現(xiàn)這個(gè)功能就是在浪費(fèi)時(shí)間。開(kāi)發(fā)人員和業(yè)務(wù)分析師不應(yīng)只是簡(jiǎn)單插入新的特性，而應(yīng)向干系人展示創(chuàng)意，供他們參考。開(kāi)發(fā)人員應(yīng)當(dāng)盡可能簡(jiǎn)而精，不要未經(jīng)干系人同意就自作主張�！　】蛻粲袝r(shí)提出一些看似合理的特性或者用戶界面要求，但這些實(shí)際對(duì)產(chǎn)品增加不了什么價(jià)值。開(kāi)發(fā)的每一個(gè)東西都有時(shí)間成本和金錢成本，因此需要將交付的價(jià)值最大化。為了降低鍍金的風(fēng)險(xiǎn)，就要對(duì)每一個(gè)功能單元跟蹤溯源，讓大家了解為什么要有這些功能。確保規(guī)范和開(kāi)發(fā)的東西都包含在項(xiàng)目范圍之內(nèi)。忽視干系人　　大多數(shù)產(chǎn)品都有若干個(gè)不同的用戶群，他們使用不同的特性，使用頻率也有所差異，經(jīng)驗(yàn)水平也不盡相同。如果無(wú)法在早期為產(chǎn)品確定主要的用戶分類，某些用戶的需要可能就無(wú)法滿足。確定所有的用戶分類之后，還要保證傾聽(tīng)用戶的聲音，相關(guān)論述可以參見(jiàn)第6章。除了顯而易見(jiàn)的用戶，還要考慮維護(hù)人員和現(xiàn)場(chǎng)支持人員，他們也有自身的需求，包括功能需求和非功能需求。必須將數(shù)據(jù)從遺留系統(tǒng)中轉(zhuǎn)換出來(lái)的人會(huì)有轉(zhuǎn)換需求，雖然這對(duì)最終產(chǎn)品軟件沒(méi)有影響，但肯定會(huì)影響解決方案的成敗。有些干系人甚至不知道項(xiàng)目的存在，例如制定標(biāo)準(zhǔn)并影響系統(tǒng)的政府機(jī)構(gòu)，但你需要了解他們及其對(duì)項(xiàng)目的影響。高質(zhì)量需求過(guò)程帶來(lái)的好處　　有些人錯(cuò)誤地認(rèn)為花時(shí)間討論需求純粹是耽誤按時(shí)交付。這種論點(diǎn)認(rèn)為，花在需求活動(dòng)上的投資不會(huì)有回報(bào)。實(shí)際上，在優(yōu)秀需求上的投資真的總會(huì)讓你事半功倍。　　有效的需求過(guò)程強(qiáng)調(diào)的是協(xié)同開(kāi)發(fā)產(chǎn)品，并在整個(gè)項(xiàng)目過(guò)程中將干系人視為合作伙伴。通過(guò)需求獲取活動(dòng)，開(kāi)發(fā)團(tuán)隊(duì)可以更好地了解用戶或市場(chǎng)，這是成功的一個(gè)關(guān)鍵要素。如果團(tuán)隊(duì)強(qiáng)調(diào)的是用戶任務(wù)，而不是局限于一些“浮華”的特性，就不會(huì)出現(xiàn)代碼寫(xiě)出來(lái)卻沒(méi)人用的情況。用戶的參與能夠彌補(bǔ)其實(shí)際需要與開(kāi)發(fā)人員交付物之間的“鴻溝”。最終你會(huì)了解客戶的想法，相對(duì)于在開(kāi)發(fā)產(chǎn)品之前而不是交付之后再意識(shí)到問(wèn)題，付出的代價(jià)要小得多。第2章將討論客戶-開(kāi)發(fā)合作關(guān)系的本質(zhì)。　　準(zhǔn)確將系統(tǒng)需求分配給不同的軟件、硬件和人工子系統(tǒng)是一種構(gòu)建產(chǎn)品的系統(tǒng)方法。有效的變更控制過(guò)程可以最小化需求變更可能帶來(lái)的負(fù)面影響。將需求清晰記錄下來(lái)對(duì)系統(tǒng)測(cè)試有著極大的幫助。上述所有這些好處會(huì)大大增加交付高質(zhì)量產(chǎn)品的幾率，滿足各方干系人。誰(shuí)也無(wú)法保證使用有效的需求實(shí)踐就能獲得具體的投資收益。但是，可以進(jìn)行分析思考，想象一下優(yōu)秀的需求對(duì)團(tuán)隊(duì)有哪些幫助（Wiegers 2006）。要得到更優(yōu)準(zhǔn)的需求，需要的成本包括開(kāi)發(fā)新程序和文檔模板、培訓(xùn)團(tuán)隊(duì)和購(gòu)買工具。最大的投資是項(xiàng)目團(tuán)隊(duì)花在需求工程任務(wù)上的實(shí)際時(shí)間。潛在收益如下。* 需求中的缺陷和交付產(chǎn)品中的缺陷更少。* 開(kāi)發(fā)的返工減少了。* 開(kāi)發(fā)和交付更快。* 不必要和無(wú)用的特性更少。* 減少成本追加。* 信息錯(cuò)誤傳達(dá)的現(xiàn)象減少了。* 范圍蔓延減少了。* 項(xiàng)目的混亂現(xiàn)象減少了。* 客戶和團(tuán)隊(duì)成員的滿意度更高了。* 產(chǎn)品按照人們當(dāng)初的設(shè)想順利運(yùn)行。　　即使無(wú)法對(duì)上述好處進(jìn)行量化，但也能看出它們的效果。
　　　　　　　　第2章從客戶角度審視需求　　Contoso制藥公司的高級(jí)經(jīng)理Gerhard正在和公司的IT部門經(jīng)理Cynthia開(kāi)會(huì)。“我們需要構(gòu)建一個(gè)可以跟蹤化學(xué)制劑的信息系統(tǒng)，” Gerhard首先說(shuō)，“這個(gè)系統(tǒng)應(yīng)該能夠跟蹤我們倉(cāng)庫(kù)和實(shí)驗(yàn)室里所有的化學(xué)制劑。這樣一來(lái)，藥劑師就能夠使用其他人剩余的化學(xué)制劑而不是總?cè)ベ?gòu)買新的。這會(huì)為我們節(jié)省大量經(jīng)費(fèi)。與此同時(shí)，健康與安全部門希望這個(gè)系統(tǒng)能夠幫助他們大大減少向政府提供化學(xué)品使用和處理報(bào)告的工作量。你們能在五個(gè)月內(nèi)及時(shí)開(kāi)發(fā)出符合這些要求的系統(tǒng)嗎？”　　“我明白這個(gè)項(xiàng)目有多重要了，Gerhard，” Cynthia說(shuō)，“但在我提上日程之前，我們還要進(jìn)一步了解這個(gè)所謂的化學(xué)品跟蹤系統(tǒng)。”　　Gerhard很困惑，問(wèn)：“什么意思？剛才我不是已經(jīng)把需求告訴你了嗎？　　“實(shí)際上，你只是大致介紹了一下項(xiàng)目的業(yè)務(wù)目標(biāo)，” Cynthia解釋說(shuō)，“這并沒(méi)有給我足夠的信息確定軟件究竟要實(shí)現(xiàn)哪些具體功能，更無(wú)法得知需要多久才能夠完成。我想派一個(gè)我們這邊的業(yè)務(wù)分析師實(shí)際參與用戶的日常工作，了解一下究竟他們需要哪些功能。”　　“藥劑師都很忙，”Gerhard反對(duì)說(shuō)，“他們沒(méi)時(shí)間在你們開(kāi)發(fā)之前確定所有的細(xì)節(jié)。你們的人難道就不能自己想想究竟該做什么嗎？”　　Cynthia回答說(shuō)：“如果我們僅靠猜測(cè)來(lái)確定用戶需要哪些功能，不可能把系統(tǒng)做好。因?yàn)槲覀兪擒浖�開(kāi)發(fā)人員，不是藥劑師。我所知道的是，如果我們不花一些時(shí)間理解問(wèn)題，不會(huì)有人對(duì)結(jié)果表示滿意的。”　　“我們沒(méi)有時(shí)間做那些事，”Gerhard堅(jiān)持自己的看法，“我已經(jīng)告訴你需求了。現(xiàn)在就請(qǐng)開(kāi)工吧。把你們的進(jìn)度通報(bào)給我。”　　　　這樣的對(duì)話在軟件世界里經(jīng)常發(fā)生。需要新系統(tǒng)的客戶常常不理解從實(shí)際用戶以及其他干系人那里獲取信息的重要性。有偉大產(chǎn)品概念的營(yíng)銷人員堅(jiān)信他們可以充分代表未來(lái)買家的利益。但是，從產(chǎn)品的實(shí)際使用者那里直接挖掘需求依然是無(wú)可替代的。一些敏捷開(kāi)發(fā)方法就建議有一個(gè)駐廠的客戶代表（有時(shí)也叫產(chǎn)品負(fù)責(zé)人）與開(kāi)發(fā)團(tuán)隊(duì)一起緊密工作。一本有關(guān)敏捷開(kāi)發(fā)的書(shū)中曾經(jīng)如此描述：“項(xiàng)目的成功離不開(kāi)客戶和開(kāi)發(fā)人員的緊密合作。”（Jeffries, Anderson, and Hendrickson 2001）　　部分需求問(wèn)題源于混淆了不同的需求層面，就是第1章提到的業(yè)務(wù)、用戶和功能層面。Gerhard描述了Contoso在使用新的化學(xué)品跟蹤系統(tǒng)后可以達(dá)成的業(yè)務(wù)目標(biāo)和收益。雖然業(yè)務(wù)目標(biāo)是業(yè)務(wù)需求的一個(gè)核心要素，但是由于Gerhard不是這個(gè)系統(tǒng)的目標(biāo)用戶，所以它無(wú)法完整描述用戶需求。同理，用戶雖然能夠描述他們要通過(guò)系統(tǒng)完成哪些任務(wù)，但無(wú)法完整描述為完成這些任務(wù)而需要開(kāi)發(fā)人員實(shí)現(xiàn)的所有功能需求。業(yè)務(wù)分析師需要與用戶緊密合作以獲得對(duì)需求更深入的理解。　　本章所闡述的客戶-開(kāi)發(fā)人員關(guān)系是軟件項(xiàng)目成功的關(guān)鍵要素。我們提出了軟件客戶所擁有的權(quán)利清單以及與之對(duì)應(yīng)的義務(wù)清單。這些清單重點(diǎn)強(qiáng)調(diào)客戶（特別是終端用戶）參與需求開(kāi)發(fā)的重要性。本章同時(shí)還討論了在一次具體的發(fā)布或是開(kāi)發(fā)迭代中如何對(duì)需求集合達(dá)成一致的關(guān)鍵性問(wèn)題。第6章將詳細(xì)描寫(xiě)各種類型的客戶和用戶以及各種讓合適的用戶代表參加需求挖掘的方法。交付物被拒收　　有一次在訪問(wèn)一家公司IT部門的時(shí)候，我聽(tīng)到了一個(gè)慘痛的故事。開(kāi)發(fā)人員最近剛剛完成了一個(gè)供企業(yè)內(nèi)部使用的新的信息系統(tǒng)。從始至終，他們獲得的用戶需求少得可憐。當(dāng)他們最終驕傲地發(fā)布新系統(tǒng)時(shí)，用戶卻拒收系統(tǒng)，并認(rèn)為它完全不可接受。開(kāi)發(fā)人員覺(jué)得非常震驚，為了實(shí)現(xiàn)他們所認(rèn)為的那些用戶需求，他們付出了巨大的努力。隨后怎么辦？只能修改這個(gè)系統(tǒng)。在發(fā)現(xiàn)搞錯(cuò)需求之后，公司總是得修復(fù)，但是相比一開(kāi)始就讓用戶代表加入進(jìn)來(lái)，成本無(wú)疑高出很多�！　￠_(kāi)發(fā)人員原本沒(méi)有預(yù)見(jiàn)到需要花時(shí)間修復(fù)有缺陷的信息系統(tǒng)，因此團(tuán)隊(duì)需求隊(duì)列中的下一個(gè)項(xiàng)目就只好先放一放了。這是一個(gè)“三輸”的境地：開(kāi)發(fā)人員感到苦惱；用戶也很失望，因?yàn)樵谛枰�的時(shí)候新系統(tǒng)不可用；高管也很失望，項(xiàng)目花了很多錢，同時(shí)其他項(xiàng)目被推遲也造成大量機(jī)會(huì)成本被浪費(fèi)。如果一開(kāi)始就有廣泛而持續(xù)的用戶參與，就會(huì)避免這種不幸而常見(jiàn)的項(xiàng)目結(jié)果。期望落差　　如果沒(méi)有足夠的客戶參與，當(dāng)項(xiàng)目結(jié)束時(shí)一個(gè)無(wú)法避免的結(jié)果就是期望落差，用戶的真實(shí)需求和開(kāi)發(fā)人員根據(jù)項(xiàng)目之初所聽(tīng)到的需求開(kāi)發(fā)出的產(chǎn)品之間的巨大鴻溝 （Wiegers 1996）。圖2-1中虛線標(biāo)示出了這個(gè)鴻溝。正如之前故事中描述的那樣，期望落差對(duì)所有干系人來(lái)說(shuō)都是一個(gè)殘酷的“驚喜”。根據(jù)我們的經(jīng)驗(yàn)，軟件中的出現(xiàn)“驚喜”從來(lái)都不是什么好消息。與此同時(shí)，需求也很容易由于業(yè)務(wù)變化而過(guò)時(shí)，所以與客戶持續(xù)溝通至關(guān)重要。　　縮小期望落差的最好方法是與合適的客戶代表頻繁溝通。這些溝通可以是正式訪談，對(duì)話，需求評(píng)審，用戶界面設(shè)計(jì)走查，原型評(píng)估以及敏捷開(kāi)發(fā)中在可執(zhí)行軟件每個(gè)小的增量功能上收集的用戶反饋。每次溝通都是一個(gè)縮小預(yù)期差距的機(jī)會(huì)，讓開(kāi)發(fā)人員所開(kāi)發(fā)的軟件能夠更貼近用戶所需�！　‘�(dāng)然，每次接觸之后，隨著開(kāi)發(fā)的推進(jìn)這個(gè)缺口又將會(huì)擴(kuò)大。越頻繁溝通，越容易讓開(kāi)發(fā)工作保持在正確的軌道上。就像圖2-1中所示的逐步收縮的漸變灰色三角形，一系列的溝通將在項(xiàng)目最后帶來(lái)小得多的預(yù)期差距，同時(shí)也能夠讓我們得到一個(gè)更接近用戶實(shí)際需求的解決方案。這就是為什么敏捷方法的一個(gè)指導(dǎo)性原則是開(kāi)發(fā)人員要與客戶保持持續(xù)溝通。對(duì)于任何項(xiàng)目，這都是一個(gè)非常棒的原則。
　　圖2-1  頻繁的用戶參與能減少期望落差誰(shuí)是客戶　　在討論客戶之前，我們首先討論干系人這個(gè)角色。干系人是指積極參與項(xiàng)目的某個(gè)人、群體或組織，它們可能會(huì)受項(xiàng)目過(guò)程和結(jié)果的影響或影響項(xiàng)目的過(guò)程和結(jié)果。干系人可以在項(xiàng)目團(tuán)隊(duì)和開(kāi)發(fā)組織的內(nèi)部或者外部。圖2-2標(biāo)示了許多類型的潛在干系人。當(dāng)然，并不都適用于所有的項(xiàng)目和場(chǎng)景�！　「上等朔治鍪切枨箝_(kāi)發(fā)的一個(gè)重要部分（Smith 2000; Wiegers 2007; IIBA 2009）。為一個(gè)項(xiàng)目尋找潛在干系人的時(shí)候，應(yīng)該廣撒網(wǎng)以免忽略一些重要的群體。然后將候選干系人列表縮小為核心人選，這些人能夠帶給你所需的信息，確保你理解所有項(xiàng)目的需求和約束，使團(tuán)隊(duì)能夠交付正確的解決方案�！　】蛻羰歉上等说囊粋�(gè)子集�？蛻羰悄軌蛑苯踊蜷g接從產(chǎn)品中獲益的個(gè)人或組織。軟件客戶可能提出需求，出錢，選擇，說(shuō)明，使用或者接收軟件產(chǎn)品的輸出。圖2-2中包含直接用戶、間接用戶、上級(jí)主管、采購(gòu)人員和收單機(jī)構(gòu)等客戶。一些干系人不是客戶，比如法務(wù)人員，設(shè)計(jì)人員，供應(yīng)商，承包商和風(fēng)投。Gerhard，我們先前提到的那個(gè)經(jīng)理，代表為這個(gè)項(xiàng)目付錢的上級(jí)主管。像Gerhard這樣的客戶提供業(yè)務(wù)需求，建立項(xiàng)目的指導(dǎo)框架以及啟動(dòng)項(xiàng)目的業(yè)務(wù)理念。我們將在第5章中探討業(yè)務(wù)需求描述的是客戶、公司或是其他干系人想要達(dá)成的業(yè)務(wù)目標(biāo)。其他所有的產(chǎn)品需求都必須有助于達(dá)成這個(gè)預(yù)期的業(yè)務(wù)目標(biāo)。
　　圖2-2  項(xiàng)目團(tuán)隊(duì)、開(kāi)發(fā)組織和外部組織里的潛在干系人缺失干系人的一個(gè)案例　　用戶需求應(yīng)該來(lái)自于直接或者間接使用產(chǎn)品的人，這些用戶（通常稱為“終端用戶”）是客戶的子集。直接用戶會(huì)動(dòng)手使用產(chǎn)品。間接用戶雖然不動(dòng)手使用，但也會(huì)收到系統(tǒng)的輸出，例如倉(cāng)庫(kù)主管會(huì)收到自動(dòng)發(fā)送的每日庫(kù)存活動(dòng)報(bào)告郵件。用戶通常能夠描述他們需要用產(chǎn)品執(zhí)行的具體任務(wù)、他們需要的輸出以及他們希望產(chǎn)品達(dá)到的質(zhì)量標(biāo)準(zhǔn)�！　∥抑�道有一個(gè)項(xiàng)目，當(dāng)時(shí)需求引導(dǎo)馬上就要結(jié)束了，在評(píng)審一個(gè)工作流時(shí)，業(yè)務(wù)分析師詢問(wèn)干系人：“你確定工作流程中的稅務(wù)計(jì)算步驟是正確的么？”干系人回答：“哦，我不知道，稅務(wù)不歸我管。那是稅務(wù)部門的事。”在隨后項(xiàng)目推進(jìn)的幾個(gè)月中，研發(fā)團(tuán)隊(duì)沒(méi)有跟稅務(wù)部門的任何人進(jìn)行過(guò)交流。他們甚至都不知道還有一個(gè)稅務(wù)部門。在最終接觸稅務(wù)部門后，業(yè)務(wù)分析師發(fā)現(xiàn)已實(shí)現(xiàn)的稅務(wù)相關(guān)功能在法律含義方面遺漏了一連串的需求。結(jié)果，項(xiàng)目延期交付好幾個(gè)月。用一個(gè)組織關(guān)系圖來(lái)找出所有可能受系統(tǒng)影響的干系人，以免產(chǎn)生類似的不愉快經(jīng)歷�！　√峁�業(yè)務(wù)需求的客戶有時(shí)會(huì)試圖替實(shí)際用戶說(shuō)話。然而這些內(nèi)容常常和真實(shí)用戶的需求相去甚遠(yuǎn)。對(duì)于企業(yè)信息系統(tǒng)，合同制定或者定制應(yīng)用開(kāi)發(fā)，業(yè)務(wù)需求應(yīng)該來(lái)自于最終的產(chǎn)品業(yè)務(wù)價(jià)值負(fù)責(zé)人。用戶需求則應(yīng)該來(lái)自于按下按鍵、點(diǎn)擊屏幕或是接收輸出的人。如果為項(xiàng)目買單的人和最終用戶之間有嚴(yán)重的脫節(jié)，肯定會(huì)出大問(wèn)題�！　∩虡I(yè)軟件開(kāi)發(fā)與此不同，客戶和用戶通常是同一個(gè)人�？蛻舸�理（例如營(yíng)銷人員或是產(chǎn)品經(jīng)理）常常試圖決定客戶想要什么。但即使是開(kāi)發(fā)商業(yè)軟件，也應(yīng)該盡力讓終端用戶加入用戶需求開(kāi)發(fā)過(guò)程，就像第7章里描述的。如果不這么做，那些原本可以通過(guò)充分用戶參與避免的缺陷就會(huì)出現(xiàn)在評(píng)審報(bào)告里�！　№�(xiàng)目干系人之間可能會(huì)出現(xiàn)矛盾。業(yè)務(wù)需求有時(shí)會(huì)反映用戶不可見(jiàn)的組織戰(zhàn)略或預(yù)算約束。通過(guò)管理手段強(qiáng)迫他們使用新的信息系統(tǒng)會(huì)使用戶感到痛苦，因而他們不愿意和開(kāi)發(fā)人員進(jìn)行合作并把他們當(dāng)作悲慘未來(lái)的先驅(qū)。這樣的人常常被稱作“失敗者”（Gause and Weinberg 1989）。為了管理這樣的潛在沖突，可以嘗試基于項(xiàng)目目標(biāo)和約束的溝通策略，創(chuàng)造更多的接納，消除爭(zhēng)論與埋怨�？蛻�-開(kāi)發(fā)的合作關(guān)系　　卓越的軟件產(chǎn)品來(lái)自基于卓越需求的卓越設(shè)計(jì)。卓越的需求則根植于開(kāi)發(fā)人員與客戶（特別是終端用戶）高效協(xié)作的土壤中。協(xié)同合作要想取得成果，需要所有干系人都清楚自己的需要并且理解并尊重其他合作者的需求。當(dāng)項(xiàng)目壓力上升時(shí)，很容易忘記所有干系人共享的同一個(gè)目標(biāo)：構(gòu)建一個(gè)既實(shí)現(xiàn)業(yè)務(wù)價(jià)值又可以使所有干系人受益的產(chǎn)品。通常需要業(yè)務(wù)分析師建立這種合作伙伴關(guān)系�！　”�2-1所示的軟件客戶權(quán)利清單列出了十項(xiàng)用戶權(quán)利。在項(xiàng)目的需求工程階段，用戶可以在與業(yè)務(wù)分析師和開(kāi)發(fā)人員的互動(dòng)中享有這些權(quán)利。其中每項(xiàng)權(quán)利都隱含著一項(xiàng)與之對(duì)應(yīng)的業(yè)務(wù)分析師和軟件開(kāi)發(fā)人員義務(wù)。其中，權(quán)利和義務(wù)清單中的“你”指的是一個(gè)軟件開(kāi)發(fā)項(xiàng)目中的客戶。　　因?yàn)闄?quán)利的另一面代表著責(zé)任，因此，表2-2也列出了需求階段中客戶對(duì)業(yè)務(wù)分析師和開(kāi)發(fā)人員應(yīng)盡的十項(xiàng)義務(wù)。也可以認(rèn)為這是開(kāi)發(fā)人員的權(quán)利清單。如果這個(gè)列表并不完全適用于你的組織，可以在此基礎(chǔ)上進(jìn)行修改，使其適合具體情況�！　”�2-1  軟件客戶的需求權(quán)利權(quán)利1. 期望業(yè)務(wù)分析師用自己的語(yǔ)言進(jìn)行交流2. 期望業(yè)務(wù)分析師了解自己的業(yè)務(wù)和目標(biāo)3. 希望業(yè)務(wù)分析師用了解合適的形式記錄需求4. 收到需求實(shí)踐和交付物的相關(guān)解釋5. 變更需求6. 期望一個(gè)相互尊重的環(huán)境7. 聆聽(tīng)關(guān)于需求以及解決方案的建議和替代方案8. 描述能夠提高產(chǎn)品易用性的特性9. 了解調(diào)整哪些需求可以實(shí)現(xiàn)復(fù)用，加速產(chǎn)品開(kāi)發(fā)10. 收到滿足自己功能需求和質(zhì)量預(yù)期的系統(tǒng)　　表2-2  軟件客戶的需求責(zé)任責(zé)任1. 給業(yè)務(wù)分析師和開(kāi)發(fā)人員傳授你的業(yè)務(wù)知識(shí)2. 準(zhǔn)備足夠的時(shí)間用來(lái)澄清需求3. 提供具體而準(zhǔn)確的需求4. 及時(shí)對(duì)需求的進(jìn)行確認(rèn)5. 尊重開(kāi)發(fā)人員針對(duì)需求可行性和成本的估算6. 和開(kāi)發(fā)人員協(xié)作設(shè)置符合實(shí)際的需求優(yōu)先級(jí)7. 評(píng)審需求和評(píng)估原型8. 設(shè)定驗(yàn)收條件9. 及時(shí)溝通需求變更10. 尊重需求開(kāi)發(fā)流程　　　　在開(kāi)發(fā)公司內(nèi)部系統(tǒng)、合同型項(xiàng)目或是為已知的重要客戶定制系統(tǒng)時(shí)，上述權(quán)利和義務(wù)比較適用于實(shí)際客戶。對(duì)于大眾市場(chǎng)的產(chǎn)品開(kāi)發(fā)，這個(gè)權(quán)利和義務(wù)更適用于產(chǎn)品經(jīng)理這樣的客戶代表�！　∽鳛轫�(xiàng)目計(jì)劃的一部分。關(guān)鍵用戶和開(kāi)發(fā)干系人應(yīng)該討論這兩個(gè)列表并且達(dá)成一致意見(jiàn)。確保需求開(kāi)發(fā)過(guò)程中的參與者理解并且接受他們的責(zé)任。這種理解能夠在后來(lái)減少?zèng)_突和摩擦，特別是當(dāng)某個(gè)角色希望從其他角色處得到一些東西而對(duì)方卻不愿或無(wú)法提供的時(shí)候。 


軟件客戶的需求權(quán)利法案　　下面詳細(xì)介紹出現(xiàn)需求問(wèn)題時(shí)客戶可以享有的十項(xiàng)權(quán)利�！　�權(quán)利1. 期望業(yè)務(wù)分析師使用自己的語(yǔ)言　　需求討論應(yīng)該以你的業(yè)務(wù)需要和任務(wù)為中心，使用業(yè)務(wù)術(shù)語(yǔ)。可以使用術(shù)語(yǔ)表的方式把業(yè)務(wù)術(shù)語(yǔ)介紹給業(yè)務(wù)分析師。在和業(yè)務(wù)分析師進(jìn)行交流的時(shí)候，不要聽(tīng)到晦澀難懂的技術(shù)術(shù)語(yǔ)�！　�權(quán)利2. 期望業(yè)務(wù)分析師了解自己的業(yè)務(wù)和目標(biāo)　　通過(guò)與你互動(dòng)獲取需求，業(yè)務(wù)分析師能夠更好地理解你的業(yè)務(wù)工作以及系統(tǒng)如何融入使用場(chǎng)景。這也能幫助開(kāi)發(fā)人員建立真正符合需求的解決方案。邀請(qǐng)業(yè)務(wù)分析師和開(kāi)發(fā)人員來(lái)觀察你和你的同事的做事方式。如果是基于老的系統(tǒng)進(jìn)行開(kāi)發(fā)，業(yè)務(wù)分析師應(yīng)該像你一樣使用當(dāng)前的系統(tǒng)。這么做可以使其知道系統(tǒng)如何融入工作流以及哪里可以做得更好。不要假設(shè)業(yè)務(wù)分析師已經(jīng)了解你們所有的業(yè)務(wù)操作方式和業(yè)務(wù)術(shù)語(yǔ)（參見(jiàn)權(quán)利1）。　　權(quán)利3. 希望業(yè)務(wù)分析師用適合的形式記錄需求　　業(yè)務(wù)分析師會(huì)整理所有干系人提供的信息，之后通過(guò)各種問(wèn)題來(lái)區(qū)分用戶需求、業(yè)務(wù)規(guī)則、功能需求、質(zhì)量目標(biāo)和其他需要。分析階段的交付物是以合適形式存儲(chǔ)的優(yōu)化需求集合，比如一個(gè)軟件需求規(guī)范文檔或者是記錄在一個(gè)需求管理工具中。這個(gè)需求集合構(gòu)成了干系人對(duì)功能、質(zhì)量和產(chǎn)品約束的一致意見(jiàn)。需求應(yīng)該用易于理解的方式寫(xiě)和組織。你對(duì)這些規(guī)范說(shuō)明或其他需求呈現(xiàn)方式（例如可視化分析模型）的評(píng)審意見(jiàn)，能夠幫助業(yè)務(wù)分析師確認(rèn)他們是否準(zhǔn)確記錄你的需求�！　�權(quán)利4. 收到需求實(shí)踐和交付物的相關(guān)解釋　　很多實(shí)踐都能夠讓需求開(kāi)發(fā)和管理變得高效，需求相關(guān)的知識(shí)也能夠用多種形式呈現(xiàn)。業(yè)務(wù)分析師應(yīng)該解釋他所推薦的實(shí)踐以及每個(gè)交付物都包含哪些信息。例如，業(yè)務(wù)分析師會(huì)用一些圖表來(lái)補(bǔ)充文本描述的需求。你也許對(duì)這些圖表不太熟悉，它們也許看起來(lái)比較復(fù)雜，但標(biāo)記并不難以理解。業(yè)務(wù)分析師需要解釋每個(gè)圖表的目的、每個(gè)符號(hào)代表的意義以及如何通過(guò)圖表發(fā)現(xiàn)錯(cuò)誤。如果業(yè)務(wù)分析師不提供這種解釋，請(qǐng)直接詢問(wèn)他們�！　�權(quán)利5. 變更需求　　業(yè)務(wù)分析師或開(kāi)發(fā)人員期望你一開(kāi)始就考慮清楚需求或指望這些需求在整個(gè)開(kāi)發(fā)周期中保持不變，顯然并不現(xiàn)實(shí)。隨著業(yè)務(wù)的不斷發(fā)展，團(tuán)隊(duì)接收到干系人提供的信息不斷增多，或自身更深入地考慮了自己的需要，就有權(quán)變更之前提出的需求。但變更總是有代價(jià)的。有時(shí)增加一個(gè)新功能就必須在其他功能或項(xiàng)目整體計(jì)劃和預(yù)算之間進(jìn)行艱難的取舍。業(yè)務(wù)分析師的一個(gè)重要責(zé)任是評(píng)估、管理和溝通變更所帶來(lái)的影響�？梢栽陧�(xiàng)目中和業(yè)務(wù)分析師一起摸索，確定一個(gè)簡(jiǎn)單有效的需求變更處理流程�！　�權(quán)利6. 期望有一個(gè)彼此尊重的環(huán)境　　客戶和開(kāi)發(fā)人員之間的關(guān)系有時(shí)會(huì)變得很對(duì)立。如果參與者不理解對(duì)方，需求討論就會(huì)令人沮喪。一起工作可以讓每個(gè)參與者看到其他人所面對(duì)的問(wèn)題。參與需求開(kāi)發(fā)的客戶有權(quán)讓業(yè)務(wù)分析師和開(kāi)發(fā)人員尊重自己并且感謝自己為項(xiàng)目成功所投入的時(shí)間。類似，客戶也應(yīng)該尊重開(kāi)發(fā)團(tuán)隊(duì)成員，彼此同舟共濟(jì)才能達(dá)成項(xiàng)目成功這一共同目標(biāo)。大家是在同一戰(zhàn)線上的。　　權(quán)利7. 聆聽(tīng)關(guān)于需求以及解決方案的建議和替代方案　　讓業(yè)務(wù)分析師了解現(xiàn)有系統(tǒng)不適合當(dāng)前業(yè)務(wù)流程的地方，確保新的系統(tǒng)不自動(dòng)化那些低效或廢棄的工作流程。也就是說(shuō)，應(yīng)該避免“一錯(cuò)再錯(cuò)”。業(yè)務(wù)分析師常常會(huì)對(duì)業(yè)務(wù)流程提出不少改進(jìn)建議。有創(chuàng)造力的業(yè)務(wù)分析師甚至?xí)�提出客戶未曾想到的可能性�！　��?quán)利8. 描述能提高產(chǎn)品易用性的特性　　業(yè)務(wù)分析師應(yīng)該詢問(wèn)軟件功能需求之外的特性。這些特性或質(zhì)量屬性能夠確保軟件更易用或更好用，使得用戶能夠更高效地完成其本職工作。用戶有時(shí)要求產(chǎn)品更友好或者更健壯，但這樣的描述太主觀，對(duì)開(kāi)發(fā)沒(méi)有什么幫助。所以，分析人員應(yīng)該詢問(wèn)哪些具體特性是對(duì)“用戶友好”或者“健壯”的。還可以告訴業(yè)務(wù)分析師現(xiàn)在的應(yīng)用在哪些方面對(duì)用戶友好（哪些方面不好）。如果不和業(yè)務(wù)分析師討論這些特性，將來(lái)的產(chǎn)品可能很難達(dá)到你的期望�！　�權(quán)利9. 了解調(diào)整哪些需求可以實(shí)現(xiàn)復(fù)用，加速產(chǎn)品開(kāi)發(fā)　　需求通常較為靈活。業(yè)務(wù)分析師也許知道當(dāng)前軟件組件或需求里哪些與你描述的需求接近。在這種情況下，業(yè)務(wù)分析師應(yīng)該提出需求的修改方案以減少不必要的定制，讓開(kāi)發(fā)人員就能夠復(fù)用這些組件。存在合適的重用機(jī)會(huì)時(shí)調(diào)整需求可以有效節(jié)省時(shí)間和成本。如果想集成一些現(xiàn)成的商業(yè)軟件包，需求就得靈活，因?yàn)樗鼈兒苌倌軌蚓�確提供你想要的特性�！　�權(quán)利10. 收到滿足自己功能需求和質(zhì)量期望的系統(tǒng)　　這是最根本的用戶權(quán)利，但要實(shí)現(xiàn)這一點(diǎn)，需要清晰地表達(dá)開(kāi)發(fā)正確產(chǎn)品所需要的所有信息，需要開(kāi)發(fā)人員不斷和你溝通備選方案與約束，還需要當(dāng)事各方能夠達(dá)成一致。確保你陳述了所有假設(shè)和期望，否則開(kāi)發(fā)人員很難掌握這些信息�？蛻粲袝r(shí)候并不會(huì)清楚說(shuō)出他們認(rèn)為是常識(shí)的信息。因而在項(xiàng)目團(tuán)隊(duì)里，驗(yàn)證共識(shí)與提出新的想法同樣重要。
軟件客戶的需求責(zé)任法案　　權(quán)力對(duì)應(yīng)的是責(zé)任，以下十項(xiàng)責(zé)任是客戶代表在為項(xiàng)目定義和管理需求時(shí)需要履行的�！　∝�(zé)任1：向業(yè)務(wù)分析師和開(kāi)發(fā)人員傳授自己的業(yè)務(wù)知識(shí)　　開(kāi)發(fā)團(tuán)隊(duì)需要你向他們傳授業(yè)務(wù)概念和業(yè)務(wù)術(shù)語(yǔ)。這么做的目的并不是讓業(yè)務(wù)分析師變成業(yè)務(wù)專家，而是幫助他們理解你的問(wèn)題和目標(biāo)。業(yè)務(wù)分析師通常并不掌握你和你的同事認(rèn)為理所當(dāng)然的知識(shí)�！　∝�(zé)任2：準(zhǔn)備足夠的時(shí)間用來(lái)澄清需求　　客戶都是大忙人，參與需求梳理工作中的人往往也是最忙的人。盡管如此，你有責(zé)任為需求討論會(huì)、訪談或者其他的需求引導(dǎo)和驗(yàn)證等活動(dòng)留出時(shí)間。有時(shí)業(yè)務(wù)分析師可能認(rèn)為自己已經(jīng)了解你的想法，但后來(lái)卻發(fā)現(xiàn)需要進(jìn)一步澄清需求。請(qǐng)耐住性子接受這種迭代式開(kāi)發(fā)和精煉需求的方式，因?yàn)檫@是復(fù)雜的人類溝通的特性，也是軟件成功的關(guān)鍵。相比一次討論一點(diǎn)且歷時(shí)數(shù)周的討論，集中幾個(gè)小時(shí)的討論更有效。　　責(zé)任3：提供具體而準(zhǔn)確的需求描述　　讓需求模糊不清很有誘惑力，因?yàn)榇_定細(xì)節(jié)通常都很瑣碎，相當(dāng)花時(shí)間（或者因?yàn)橛行┤讼胩颖茇?zé)任而不愿意確認(rèn)）。即便如此，必須有人解決這些模糊不清的問(wèn)題。你是做這個(gè)決定的最佳人選。否則，你只能依賴業(yè)務(wù)分析師或開(kāi)發(fā)人員的猜測(cè)是正確的。為需要進(jìn)一步探討的需求臨時(shí)打上“待確定”標(biāo)簽是合理的。有時(shí)，“待確定”被用在一些難以確認(rèn)的或沒(méi)人愿意解決的需求上。嘗試描述每個(gè)需求的潛在目的，使業(yè)務(wù)分析師能夠把它準(zhǔn)確呈現(xiàn)出來(lái)。這是確保產(chǎn)品能夠滿足真正需要的最好方式�！　∝�(zé)任4：被問(wèn)到有關(guān)需求的問(wèn)題時(shí)及時(shí)做出決策　　就像為你建造房子的承包商一樣，業(yè)務(wù)分析師會(huì)讓你做出很多決定。包括解決多個(gè)客戶之間需求的沖突，在不兼容的質(zhì)量屬性間進(jìn)行選擇，評(píng)估信息的準(zhǔn)確性。有權(quán)做出決策的客戶必須及時(shí)回復(fù)。通常，開(kāi)發(fā)人員在你做決定之前無(wú)法前進(jìn)，所以遲遲未決會(huì)造成項(xiàng)目進(jìn)度的延遲。如果覺(jué)得不厭其煩，請(qǐng)牢記系統(tǒng)是為你開(kāi)發(fā)的。業(yè)務(wù)分析師通常都很善于引導(dǎo)客戶做決定，所以當(dāng)你難以抉擇的時(shí)候可以向他們尋求幫助�！　∝�(zé)任5：尊重開(kāi)發(fā)人員對(duì)需求可行性和成本的估算　　開(kāi)發(fā)所有功能都要付出成本。開(kāi)發(fā)人員是對(duì)成本進(jìn)行預(yù)估的最佳人選。一些特性可能無(wú)法實(shí)現(xiàn)或?qū)崿F(xiàn)成本很高。某些需求可能希望系統(tǒng)在運(yùn)行環(huán)境中達(dá)到無(wú)法達(dá)到的性能或要求訪問(wèn)系統(tǒng)無(wú)法獲得的數(shù)據(jù)。開(kāi)發(fā)人員會(huì)帶來(lái)這些可行性或者有關(guān)成本的壞消息。你應(yīng)該尊重這些評(píng)估，即使這意味著你可能無(wú)法獲得完全符合你期望的功能。有時(shí)，你可以重寫(xiě)需求使其變得可行或成本可接受。例如，讓系統(tǒng)實(shí)時(shí)響應(yīng)可能無(wú)法實(shí)現(xiàn)，但是換成精確的時(shí)間需求（50?ms內(nèi)）也許可以實(shí)現(xiàn)�！　∝�(zé)任6：和開(kāi)發(fā)人員協(xié)作設(shè)置符合實(shí)際的需求優(yōu)先級(jí)　　很少有項(xiàng)目能夠有足夠的時(shí)間和充足的資源實(shí)現(xiàn)用戶想要的一切。所以，決定哪些功能是核心，哪些有用，哪些需求對(duì)用戶不是最重要的，這是需求分析中最重要的幾點(diǎn)。你需要成為主角，為需求設(shè)置優(yōu)先級(jí)。開(kāi)發(fā)人員能夠提供每個(gè)需求或是用戶故事的成本和風(fēng)險(xiǎn)來(lái)幫助確定最終的優(yōu)先級(jí)。設(shè)置務(wù)實(shí)的優(yōu)先級(jí)，就是幫助開(kāi)發(fā)人員用最低的成本在最合適的時(shí)間交付最大化的價(jià)值。協(xié)作確定優(yōu)先級(jí)是敏捷項(xiàng)目的核心，使開(kāi)發(fā)人員能以最快的速度交付最有價(jià)值的軟件產(chǎn)品�！　�對(duì)于團(tuán)隊(duì)在可用的時(shí)間和資源約束下能完成多少所需的功能，應(yīng)該充分尊重開(kāi)發(fā)團(tuán)隊(duì)的判斷。如果你所需的功能無(wú)法完全放入項(xiàng)目，決策者就會(huì)根據(jù)優(yōu)先級(jí)縮小項(xiàng)目范圍、延長(zhǎng)時(shí)間或者提供額外的資金或者人力。簡(jiǎn)單粗暴地把所有需求都設(shè)置為高優(yōu)先級(jí)，這樣做既不符合現(xiàn)實(shí)，也不是一種合作的態(tài)度�！　∝�(zé)任7：評(píng)審需求和評(píng)估原型　　正如在第17章中將看到的，同行評(píng)審是保障軟件質(zhì)量最有效的方法之一。讓客戶參與評(píng)審是評(píng)估軟件在需求方面是否滿足完整性、正確性和必要性的關(guān)鍵方法。評(píng)審也是客戶代表評(píng)估業(yè)務(wù)分析師工作是否滿足項(xiàng)目需要的一個(gè)重要時(shí)機(jī)。忙碌的客戶通常不愿意花時(shí)間參與需求評(píng)審，但其實(shí)這樣做是值得的。業(yè)務(wù)分析師應(yīng)該在需求引導(dǎo)的過(guò)程中經(jīng)常向你提供適量需求進(jìn)行評(píng)審，不要在需求“完成”以后才將一大本需求手冊(cè)放到你的桌子上。　　僅僅依靠寫(xiě)好的需求，很難“腦補(bǔ)”出軟件如何工作的畫(huà)面。為了更好地理解你的想法并探索最佳的實(shí)現(xiàn)方式，業(yè)務(wù)分析師或開(kāi)發(fā)人員有時(shí)會(huì)構(gòu)建一個(gè)目標(biāo)產(chǎn)品的原型。針對(duì)這個(gè)初級(jí)的、不完備的或是探索性原型給出的反饋，可以為開(kāi)發(fā)人員提供非常有價(jià)值的信息。　　責(zé)任8：設(shè)定驗(yàn)收條件　　開(kāi)發(fā)人員如何知道開(kāi)發(fā)完成了呢？他們?nèi)绾沃�道開(kāi)發(fā)的軟件符合客戶期望呢？作為客戶，你有設(shè)定驗(yàn)收條件的責(zé)任，預(yù)先定義好未來(lái)如何評(píng)估產(chǎn)品的條件。這些條件包括驗(yàn)收測(cè)試，可以用它們來(lái)評(píng)估用戶執(zhí)行業(yè)務(wù)操作時(shí)產(chǎn)品是否能夠正確執(zhí)行。其他的驗(yàn)收條件還可以針對(duì)可能存在的缺陷、特定操作下的表現(xiàn)或是能夠滿足外部系統(tǒng)的驗(yàn)證需求等。敏捷項(xiàng)目使用驗(yàn)收條件來(lái)充實(shí)用戶故事細(xì)節(jié)，而不使用書(shū)面記錄的需求。測(cè)試人員雖然能夠判斷某個(gè)需求是否正確實(shí)現(xiàn)，但是他們并不見(jiàn)得總是了解你能夠接受什么樣的產(chǎn)出。　　責(zé)任9：及時(shí)溝通需求變更　　不斷改變需求會(huì)給開(kāi)發(fā)團(tuán)隊(duì)按時(shí)交付高質(zhì)量產(chǎn)品帶來(lái)嚴(yán)重的風(fēng)險(xiǎn)。雖然改變難以避免，而且通常也有望增加價(jià)值，但是越晚引入變更，造成的沖擊越大。應(yīng)該在發(fā)現(xiàn)需求需要改變的時(shí)候盡早通知業(yè)務(wù)分析師。為了能把影響降到最低，要遵從項(xiàng)目定義的需求變更流程，以確保所有提出的變更不會(huì)丟失，每個(gè)變更影響都要考慮到，并且所有變更都要用相同的方式考慮。最后，由業(yè)務(wù)干系人判斷在哪個(gè)階段將哪些需求變更添加到項(xiàng)目中。　　責(zé)任10：尊重需求開(kāi)發(fā)流程　　引導(dǎo)和制定需求是軟件開(kāi)發(fā)中最有挑戰(zhàn)的活動(dòng)之一。業(yè)務(wù)分析師進(jìn)行需求開(kāi)發(fā)時(shí)有一個(gè)基本原理。雖然可能使人沮喪，但是花在理解需求上的時(shí)間依然是一種很好的投資。如果你能夠尊重業(yè)務(wù)分析師所使用的技巧，整個(gè)過(guò)程就會(huì)輕松許多。可以詢問(wèn)業(yè)務(wù)分析師他們?yōu)槭裁匆�獲取某些信息，為什么要你加入某些需求開(kāi)發(fā)實(shí)踐�；ハ嗬斫獠⒆鹬仄渌�人的做事方法和需要，有利于建立一個(gè)有效而愉快的合作關(guān)系。建立尊重需求的企業(yè)文化有家公司需求部門的領(lǐng)導(dǎo)曾經(jīng)提出一個(gè)問(wèn)題：“我遇到了如何讓我們開(kāi)發(fā)人員同意加入需求開(kāi)發(fā)過(guò)程的問(wèn)題，”她說(shuō)，“我怎樣才能讓他們理解參與這一過(guò)程的價(jià)值呢？”在另一個(gè)部門，一名業(yè)務(wù)分析師經(jīng)歷過(guò)這么一次沖突：開(kāi)發(fā)人員想要為一個(gè)會(huì)計(jì)系統(tǒng)梳理需求細(xì)節(jié)，但是IT經(jīng)理只想做一個(gè)簡(jiǎn)單的頭腦風(fēng)暴，不希望使用其他方法。“你的讀者會(huì)面臨文化沖突嗎？”這個(gè)業(yè)務(wù)分析師問(wèn)我。　　這些問(wèn)題都是讓業(yè)務(wù)分析師、開(kāi)發(fā)人員以及客戶協(xié)作進(jìn)行需求開(kāi)發(fā)時(shí)所面臨的挑戰(zhàn)。你會(huì)覺(jué)得用戶應(yīng)該很清楚這一點(diǎn)：“提供需求信息有利于使其得到他自己想要的”。開(kāi)發(fā)人員會(huì)發(fā)現(xiàn)，相比收到一堆不知從哪里來(lái)的需求文檔，加入這個(gè)過(guò)程會(huì)使其工作更輕松。顯然，并不是讓每個(gè)人都像你一樣對(duì)需求如此感興趣，如果是這樣，他們可能都已經(jīng)是業(yè)務(wù)分析師了�！　�團(tuán)隊(duì)一起從事需求開(kāi)發(fā)時(shí)文化沖突會(huì)頻繁出現(xiàn)。有些人認(rèn)為基于太少或是靠心靈感應(yīng)式溝通所獲取的需求來(lái)開(kāi)發(fā)軟件存在大量風(fēng)險(xiǎn)。也有一些人認(rèn)為需求并不是非做不可的。像替換遺留系統(tǒng)這樣的項(xiàng)目，如果用戶覺(jué)得這與自己工作沒(méi)有太大關(guān)系，不值得浪費(fèi)時(shí)間，那么爭(zhēng)取業(yè)務(wù)人員的合作會(huì)非常困難。理解人們抵觸參與需求開(kāi)發(fā)的原因，是解決問(wèn)題的第一步�！　∫恍┓磳�(duì)者可能并沒(méi)有具體接觸過(guò)需求實(shí)踐�；蛘咚麄兘�(jīng)歷過(guò)令人失望的需求引導(dǎo)過(guò)程，參與的項(xiàng)目產(chǎn)出了規(guī)模龐大、不完整、被忽視的需求說(shuō)明。這一定會(huì)讓每個(gè)人都留下糟糕的印象。即使工作很有效，反對(duì)者也理解不到這些實(shí)踐的價(jià)值。他們也許沒(méi)有意識(shí)到在隨意的、缺乏條理的環(huán)境中工作所付出的代價(jià)。這種代價(jià)通常體現(xiàn)在出現(xiàn)意料之外的返工、延期或軟件品質(zhì)低劣。這樣的返工隱藏在項(xiàng)目參與者的日常工作中，所以他們意識(shí)不到它竟然如此低效�！　∪绻�想把開(kāi)發(fā)人員、經(jīng)理和客戶拉在一起，就必須讓每個(gè)人都了解公司和客戶之間曾經(jīng)因?yàn)樾枨髥?wèn)題而經(jīng)歷的痛苦。如果他們感受不到這樣的痛苦，可以找一些具體的案例。量化它們對(duì)組織造成的浪費(fèi)，可以用錢、時(shí)間、客戶投訴或者失去的商機(jī)來(lái)衡量。開(kāi)發(fā)經(jīng)理并不總是能夠意識(shí)到糟糕需求對(duì)團(tuán)隊(duì)生產(chǎn)力所產(chǎn)生的影響。可以向他們展示糟糕的需求如何減慢設(shè)計(jì)并在修正產(chǎn)品方向時(shí)花費(fèi)巨大的成本。　　開(kāi)發(fā)人員也是項(xiàng)目干系人，但他們的需求有時(shí)并沒(méi)有得到過(guò)任何考慮，使其成為被強(qiáng)加需求的受害者。開(kāi)發(fā)人員應(yīng)該提供關(guān)鍵信息以確保需求文檔能夠真正發(fā)揮作用。我喜歡讓開(kāi)發(fā)人員參與需求評(píng)審，讓他們知道接下來(lái)會(huì)發(fā)生什么并且指出哪些地方需要進(jìn)一步澄清。用戶看不到的內(nèi)部質(zhì)量屬性通常需要由開(kāi)發(fā)人員提供。開(kāi)發(fā)人員經(jīng)常能夠提供其他人想不到的信息，比如如何用更簡(jiǎn)單的方式完成任務(wù)；什么功能實(shí)現(xiàn)起來(lái)非常耗時(shí)；哪些是不必要的設(shè)計(jì)約束；是否有遺漏的需求，比如異常處理；如何利用技術(shù)創(chuàng)造機(jī)遇，等等�！　≠|(zhì)量保障人員和測(cè)試人員也是優(yōu)秀需求的貢獻(xiàn)者。不要等到項(xiàng)目后期再讓他們加入，讓這些“眼尖”的人盡早加入迭代的需求評(píng)審。他們善于發(fā)現(xiàn)歧義與沖突，非常關(guān)心如何基于需求來(lái)開(kāi)發(fā)測(cè)試用例和場(chǎng)景。測(cè)試人員也能夠提出可驗(yàn)證的質(zhì)量屬性方面的需求。　　對(duì)流程或文化改變的抵觸大多來(lái)自于恐懼、不確定性或知識(shí)的缺乏。如果能識(shí)別出這種抵觸，你就能通過(guò)保障、澄清和教育的方式應(yīng)對(duì)。讓人們了解他們的參與不僅對(duì)他們個(gè)人有益，同時(shí)也會(huì)在整體上產(chǎn)生更好的效果�！　☆I(lǐng)導(dǎo)必須理解這一點(diǎn)：組織需要把高效業(yè)務(wù)分析和需求工程能力作為自己的戰(zhàn)略性核心競(jìng)爭(zhēng)力。雖然項(xiàng)目范圍內(nèi)基層人員的努力非常重要，但如果沒(méi)有高層的投入，這些改進(jìn)和收益在項(xiàng)目結(jié)束或團(tuán)隊(duì)重組后將很難保持。識(shí)別決策者在軟件項(xiàng)目中，需要做很多決定，而且往往都是在向前發(fā)展的關(guān)鍵路徑上。必須解決一些沖突，接受（或拒絕）某個(gè)需求變更或者批準(zhǔn)一組即將發(fā)布的需求。在項(xiàng)目早期，就要確定由誰(shuí)來(lái)做決定以及如何做決定。我的朋友Chris（一個(gè)經(jīng)驗(yàn)豐富的項(xiàng)目經(jīng)理）指出:“我發(fā)現(xiàn)項(xiàng)目中通常有一個(gè)主要的決策人，通常是組織的出資人。我必須找出這個(gè)人，然后讓他關(guān)注整個(gè)項(xiàng)目的進(jìn)度。究竟誰(shuí)負(fù)責(zé)做決定，有時(shí)沒(méi)有唯一的答案。讓一個(gè)代表各個(gè)關(guān)鍵領(lǐng)域（比如管理、客戶、商業(yè)分析、開(kāi)發(fā)和市場(chǎng)部門）的小組來(lái)做決定通常更有效。第28章將描述如何讓變更控制委員會(huì)作為決策者來(lái)處理需求變更�！　�決策小組需要指明決策領(lǐng)導(dǎo)并選擇一個(gè)決策規(guī)則，該規(guī)則描述了他們?nèi)绾巫鰶Q定。有很多決策規(guī)則可以選擇，下面是一些（Gottesdiener 2001）：* 決策領(lǐng)導(dǎo)做決定，不管是否已經(jīng)和其他人討論過(guò)* 小組投票，少數(shù)服從多數(shù)* 小組投票，但是結(jié)果必須獲得一致通過(guò)* 小組討論和協(xié)商達(dá)成共識(shí)。每個(gè)人都擁護(hù)這個(gè)決定并承諾支持它* 決策領(lǐng)導(dǎo)授權(quán)一個(gè)決策人* 小組達(dá)成一個(gè)決策，但是一些人有權(quán)否決小組決定　　沒(méi)有普適的決策規(guī)則。單一的決策規(guī)則通常也不普遍適合于每個(gè)場(chǎng)景，所以小組必須建立一套指導(dǎo)原則，讓他們知道什么時(shí)候該投票，什么時(shí)候該達(dá)成一致，什么時(shí)候該授權(quán)代理人等。在每個(gè)項(xiàng)目的第一個(gè)重大決策點(diǎn)出現(xiàn)之前，需要做需求決策的人都必須事先確定好一個(gè)決策規(guī)則。對(duì)需求達(dá)成一致　　對(duì)在建產(chǎn)品的需求達(dá)成一致或是在某部分達(dá)成一致是客戶-開(kāi)發(fā)人員關(guān)系的核心。涉及的多個(gè)角色應(yīng)形成如下共識(shí)：* 客戶承認(rèn)需求描述了他們的需要* 開(kāi)發(fā)人員承認(rèn)理解需求并且認(rèn)為它們是可實(shí)現(xiàn)的* 測(cè)試人員承認(rèn)需求是可驗(yàn)證的* 管理層承認(rèn)需求可以達(dá)成他們的業(yè)務(wù)目標(biāo)　　許多組織用簽字的方式來(lái)代表干系人認(rèn)可需求。所有需求確認(rèn)流程的參與者都清楚簽字的含義及其結(jié)果。一個(gè)常見(jiàn)問(wèn)題是客戶代表或是經(jīng)理認(rèn)為自己在需求上簽字是毫無(wú)意義的例行公事“我拿到了需要我簽字的紙，我簽了，因?yàn)槿绻�不這樣，開(kāi)發(fā)人員就不會(huì)開(kāi)始編碼。”將來(lái)當(dāng)某個(gè)角色希望改變需求或者交付物不符合預(yù)期時(shí)，他們就會(huì)說(shuō)：“雖然我在文檔上簽字了，但是我并沒(méi)有足夠的時(shí)間仔細(xì)閱讀這些文檔，我非常信任你們，可是你們卻讓我大失所望！”　　另一個(gè)問(wèn)題是開(kāi)發(fā)經(jīng)理把簽字視作需求凍結(jié)的一種手段。每次提出需求變更，他都會(huì)表示抗議：“你已經(jīng)在文檔上簽字了，我們也是按照這個(gè)開(kāi)發(fā)的，如果希望我們開(kāi)發(fā)其他內(nèi)容，你應(yīng)該早點(diǎn)說(shuō)。”　　這些態(tài)度都忽略了一個(gè)事實(shí)，即我們不可能在項(xiàng)目早期就知道所有的需求，而且毫無(wú)疑問(wèn)，需求會(huì)隨著時(shí)間的變化而變化。雖然批準(zhǔn)一組需求是結(jié)束某個(gè)需求開(kāi)發(fā)階段的常用方法，但是每個(gè)參與需求開(kāi)發(fā)過(guò)程的角色都應(yīng)該明白簽字的真正含義。
需求基線　　比簽字儀式更重要的是確立一條需求基線，一個(gè)特定時(shí)間點(diǎn)的需求快照（Wiegers 2006）。需求基線是一組需求，在評(píng)審和確認(rèn)后作為后續(xù)開(kāi)發(fā)的基礎(chǔ)。不論團(tuán)隊(duì)使用正式的簽字流程或其他方式對(duì)需求達(dá)成一致，潛在的含義都應(yīng)該如下所述：　　　　“我同意當(dāng)前這組需求代表我們對(duì)項(xiàng)目下一階段需求最深入的理解，并且基于目前我們對(duì)問(wèn)題的理解，這個(gè)解決方案能夠滿足我們的需求。我同意在未來(lái)使用項(xiàng)目定義好的變更流程基于這個(gè)基線對(duì)需求進(jìn)行修改。我清楚變更可能導(dǎo)致我們重新討論項(xiàng)目的成本、涉及的資源以及對(duì)時(shí)間表的承諾。”　　　　一些組織與這段話類似的內(nèi)容放在簽名頁(yè)上，讓需求審批人在簽字的時(shí)候清楚簽字的真正含義�！　‰S著項(xiàng)目的進(jìn)行，發(fā)現(xiàn)需求有遺漏或者市場(chǎng)和業(yè)務(wù)需求有變化時(shí)可能會(huì)出現(xiàn)沖突，對(duì)以上內(nèi)容達(dá)成共識(shí)將有助于減少這種沖突。一個(gè)有意義的基線確定流程可以在以下幾個(gè)方面為主要干系人帶來(lái)信心。* 客戶管理層或者市場(chǎng)營(yíng)銷人員相信項(xiàng)目不會(huì)超出可控范圍，因?yàn)榭蛻魰?huì)為范圍變化的決定負(fù)責(zé)。* 用戶代表相信開(kāi)發(fā)團(tuán)隊(duì)會(huì)和他們一起工作，交付正確的解決方案，即使他們?cè)陂_(kāi)發(fā)開(kāi)始之前沒(méi)有考慮清楚所有的需求。* 開(kāi)發(fā)部門的信心建立在開(kāi)發(fā)團(tuán)隊(duì)有業(yè)務(wù)伙伴保證項(xiàng)目始終聚焦于其目標(biāo)上，同時(shí)業(yè)務(wù)伙伴也和開(kāi)發(fā)團(tuán)隊(duì)一起平衡項(xiàng)目計(jì)劃、成本、功能和質(zhì)量。* 業(yè)務(wù)分析師和項(xiàng)目經(jīng)理有信心有效控制項(xiàng)目變更帶來(lái)的風(fēng)險(xiǎn)，并使風(fēng)險(xiǎn)最小化。* 質(zhì)量保證和測(cè)試團(tuán)隊(duì)有信心開(kāi)發(fā)測(cè)試腳本并且為自己在項(xiàng)目中的各種活動(dòng)做好準(zhǔn)備。　　在決策者定義基線以后，業(yè)務(wù)分析師需要在需求變更上施加控制。團(tuán)隊(duì)可以在分析每個(gè)變化對(duì)項(xiàng)目計(jì)劃和其他的關(guān)鍵因素的影響之后重新調(diào)整項(xiàng)目的范圍。在達(dá)成一致之后結(jié)束初始的需求開(kāi)發(fā)活動(dòng)，可以有效推進(jìn)協(xié)作式客戶-開(kāi)發(fā)人員關(guān)系，使產(chǎn)品走上成功之路。
達(dá)不成共識(shí)怎么辦　　讓所有干系人達(dá)成一致并簽字是很困難的。障礙包括后勤、忙碌的日程以及某人不愿意承諾（害怕在日后承擔(dān)責(zé)任）等。如果干系人擔(dān)心批準(zhǔn)需求以后不可以再改，就會(huì)拖延審批時(shí)間。這無(wú)疑會(huì)導(dǎo)致需求分析工作陷入癱瘓。許多團(tuán)隊(duì)嘗試發(fā)郵件說(shuō)：“如果不在下周五前回復(fù)修改意見(jiàn)或是簽字確認(rèn)，我們將會(huì)假定你已經(jīng)同意了這些需求。”這也是一種選擇，不過(guò)這等同于沒(méi)有達(dá)成一致。同時(shí)，這么做還會(huì)讓你和那個(gè)“被同意”的干系人關(guān)系緊張。試著了解一下他們不愿意簽字的原因并當(dāng)面提出來(lái)。　　在這種場(chǎng)景下，最好先小心地推進(jìn)項(xiàng)目，不過(guò)要假定你沒(méi)有得到這些有抵觸情緒的干系人的同意。在風(fēng)險(xiǎn)列表中做記錄，說(shuō)明有些干系人沒(méi)有在需求文檔上簽字（把它和遺漏或錯(cuò)誤的需求可能帶來(lái)的影響同等對(duì)待）。作為風(fēng)險(xiǎn)管理的一部分，持續(xù)跟進(jìn)這些人。用一種積極的態(tài)度讓他們了解，雖然他們沒(méi)有批準(zhǔn)需求，但是為了保證進(jìn)度，項(xiàng)目仍然使用這些需求作為基線。讓他們知道，如果他們想改變需求，可以通過(guò)有一個(gè)現(xiàn)成的流程�；�本上是在假定干系人同意需求的狀態(tài)下工作，但是需要與他們保持密切的溝通。對(duì)敏捷項(xiàng)目的需求達(dá)成共識(shí)　　敏捷項(xiàng)目沒(méi)有正式的簽字環(huán)節(jié)。通常，敏捷項(xiàng)目使用產(chǎn)品Backlog（待辦事項(xiàng)）中放入用戶故事的形式來(lái)管理需求。產(chǎn)品負(fù)責(zé)人和團(tuán)隊(duì)一起在計(jì)劃會(huì)議上針對(duì)下一個(gè)迭代團(tuán)隊(duì)要做的用戶故事達(dá)成一致。選擇實(shí)現(xiàn)哪些用戶故事主要取決于故事的優(yōu)先級(jí)和團(tuán)隊(duì)速率（生產(chǎn)力）。在需求集合達(dá)成一致后，迭代中包含的用戶故事將被凍結(jié)。新出現(xiàn)的需求變更留在未來(lái)的迭代中再考慮。敏捷項(xiàng)目不會(huì)一開(kāi)始就試圖讓干系人就項(xiàng)目所有需求達(dá)成一致。雖然產(chǎn)品愿景和其他業(yè)務(wù)需求仍然需要一開(kāi)始就明確，但是在敏捷項(xiàng)目中，功能全集是逐漸得以明確的。第20章將具體討論敏捷項(xiàng)目如何進(jìn)行需求管理�！　∥以�經(jīng)遇到過(guò)一個(gè)客戶，他雖然在使用敏捷生命周期卻要求對(duì)需求進(jìn)行簽字確認(rèn)。團(tuán)隊(duì)需要在這種不需要簽字的非傳統(tǒng)流程中以創(chuàng)造性的方式解決這個(gè)問(wèn)題。業(yè)務(wù)分析團(tuán)隊(duì)和用戶一起挖掘和評(píng)審需求，使用用戶故事或工作流程、狀態(tài)表等其他形式來(lái)記錄需求。我們讓用戶對(duì)這些產(chǎn)出簽字。其時(shí)，他們會(huì)知道沒(méi)有遺漏大的需求，同時(shí)由于用戶親身參與了需求相關(guān)的實(shí)踐，因而也知道我們寫(xiě)下來(lái)的內(nèi)容不會(huì)出大問(wèn)題，隨后的開(kāi)發(fā)工作自然不會(huì)有大的偏差。但是使用簽字方式仍然保證用戶有權(quán)在未來(lái)增加新功能或修復(fù)發(fā)現(xiàn)的問(wèn)題。　　不同于過(guò)去簽字意味著“需求通過(guò)審批并同時(shí)被凍結(jié)”，這種新的方式不會(huì)讓任何人覺(jué)得簽字就是讓自己對(duì)大量看不懂的需求文檔負(fù)全責(zé)。同時(shí)也不會(huì)強(qiáng)迫客戶同意需求已經(jīng)近乎完美，所有的事情在一開(kāi)始就已經(jīng)完全定義清楚。這種簽字符合敏捷的思想。就像前面介紹的簽字過(guò)程那樣，簽字的本質(zhì)是就需求的特定部分達(dá)成一致，它為下個(gè)開(kāi)發(fā)周期中要實(shí)現(xiàn)的需求定義了一個(gè)基線，同時(shí)所有人都明白這種達(dá)成一致意味著什么�！　⊥ǔ�，在敏捷項(xiàng)目中，產(chǎn)品負(fù)責(zé)人為迭代選擇或拒絕需求，需求包括一系列用戶故事以及相應(yīng)的驗(yàn)收條件和驗(yàn)收測(cè)試。最終的簽字就是接收迭代所產(chǎn)出的經(jīng)過(guò)測(cè)試的可工作的軟件�！　【拖耦檰�(wèn)布朗（Nanette Brown）所說(shuō)：“即使在一個(gè)敏捷環(huán)境中，簽字的理念也可以填補(bǔ)一個(gè)空白，敏捷告訴我們要‘擁抱變化’，但變化總是基于某個(gè)參照點(diǎn)而存在的，即使是一個(gè)溝通緊密的團(tuán)隊(duì)，人們對(duì)當(dāng)前的計(jì)劃和狀態(tài)也會(huì)有不同的認(rèn)識(shí)。一個(gè)人對(duì)需求的變更可能會(huì)被別人認(rèn)為是先前已經(jīng)確定好的東西。但是，如果用簽字作為一個(gè)輕量級(jí)的確認(rèn)方式來(lái)標(biāo)示‘我們?cè)谶@里’，我認(rèn)為是一件好事情，今天‘我們到這里’不代表了我們明天不能去其他地方，而是代表我們找到了一個(gè)參照點(diǎn)。”　　
　�、�  “業(yè)務(wù)分析師”（簡(jiǎn)稱BA）在項(xiàng)目中主要負(fù)責(zé)領(lǐng)導(dǎo)項(xiàng)目中與需求相關(guān)的活動(dòng)。BA還有很多其他稱呼。在第4章中，將進(jìn)一步介紹業(yè)務(wù)分析師這個(gè)角色。---------------　　　　------------------------------------------------------------　　　　---------------　　　　------------------------------------------------------------