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

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

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

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


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