培訓(xùn)資料：需求工程

“喂，是Phil嗎？我是人力資源部的Maria，我們在使用你編寫的職員系統(tǒng)時遇到一“她嫁給了一個姓Starlight的人嗎？”Phil問道。“Maria“當(dāng)然是這樣，我從沒想過誰會莫名其妙地更改自己的姓名。我不記得你曾告訴我系統(tǒng)需要處理這樣的事情，這就是為什么你們只能在改變婚姻狀況對話框中才能Phil說。Maria（她）們的姓名。但不管怎樣，我們希望在下周五之前解決這個問題，否則，Sparkle將不能支付她的賬單。你能在此前修改好這個錯誤嗎？““這并不是我的錯！我從來不知道你需要處理這種情況。我現(xiàn)在正忙著做一個新的性能檢測系統(tǒng)，并且還要處理職員系統(tǒng)的一些需求變更請求”（傳來翻閱稿紙的聲音“那我怎么跟SparkleMaria“Maria，你要明白，這不是我的過錯?！盤hil你要能隨時改變某個人的名字，那這些都不會發(fā)生。因此你不能因我未猜出你的想法（需求）Maria等你修改好了，馬上打電話告訴我，行吧？”如果作為客戶有過類似的經(jīng)驗，你一定知道：一個不能進(jìn)行一項基本操作的軟件產(chǎn)品是多么令人煩惱。盡管開發(fā)者最終會滿足你的要求，你也不會感謝他。但從開發(fā)者角度來看，在整個系統(tǒng)已經(jīng)完成后，用戶再提出對功能的進(jìn)一步要求是多么煩人的事。同時，修改系統(tǒng)的請求迫使你放下當(dāng)前的項目，而且往往修改請求還要求你優(yōu)先處理，也是令人很不愉快的。其實，在軟件開發(fā)中遇到的許多問題，都是由于收集、編寫、協(xié)商、修改產(chǎn)品需求過程中的手續(xù)和作法（方法）失誤帶來的。例如上面的Phil和Maria，出現(xiàn)的問題涉及到非正式信息的收集，未確定的或不明確的功能，未發(fā)現(xiàn)或未經(jīng)交流的假設(shè)，不完善的需求文檔，以及突發(fā)的需求變更過程。對大多數(shù)人來說，若要建一幢20萬美元的房子，他一定會與建房者詳細(xì)討論各種細(xì)節(jié)，他們都明白完工以后的修改會造成損失，以及變更細(xì)節(jié)的危害性。然而，涉及到軟件開發(fā)，人們卻變得“大大咧咧”起來。軟件項目中百分之四十至百分之六十的問題都是在需求分析（Lefingwell1997?？稍S多組織仍在那些基本的項目功能上采用一些不合規(guī)范的方法，這樣導(dǎo)致的后果便是一條鴻溝（期望差異）—開發(fā)者開發(fā)的與用戶所想得到的軟件存在著巨大期望差異。在軟件工程中，所有的風(fēng)險承擔(dān)者（stakeholder）都感興趣的就是需求分析階段。這些風(fēng)險承擔(dān)者包括客戶、用戶、業(yè)務(wù)或需求分析員（負(fù)責(zé)收集客戶需求并編寫文檔，以及負(fù)責(zé)客戶與開發(fā)機構(gòu)之間聯(lián)系溝通的人、開發(fā)人員、測試人員、用戶文檔編寫者、項目管理者和客戶管理者。這部分工作若處理好了，能開發(fā)出很出色的產(chǎn)品，同時會使客戶感到滿意，開發(fā)者也倍感滿足、充實。若處理不好，則會導(dǎo)致誤解、挫折、障礙以及潛在質(zhì)量和業(yè)務(wù)價值上的威脅。因為需求分析奠定了軟件工程和項目管理的基礎(chǔ)，所以所有風(fēng)險承擔(dān)者最好是采用本書提供的有效的需求分析過程。本章將幫助你：了解軟件需求開發(fā)中使用的一些關(guān)鍵名詞。警惕在軟件項目中可能出現(xiàn)的與需求相關(guān)的一些問題。知道優(yōu)秀的需求規(guī)格說明應(yīng)該具有的特點。明白需求開發(fā)與需求管理之間的區(qū)別。IEEE軟件工程標(biāo)準(zhǔn)詞匯表（1997年）中定義需求為：用戶解決問題或達(dá)到目標(biāo)所需的條件或權(quán)能（IEEE軟件工程標(biāo)準(zhǔn)詞匯表（1997年）中定義需求為：用戶解決問題或達(dá)到目標(biāo)所需的條件或權(quán)能（Capability。系統(tǒng)或系統(tǒng)部件要滿足合同、標(biāo)準(zhǔn)、規(guī)范或其它正式規(guī)定文檔所需具有的條件或權(quán)能。一種反映上面（1）或（2）所描述的條件或權(quán)能的文檔說明。IEE公布的定義包括從用戶角度（系統(tǒng)的外部行為，以及從開發(fā)者角度（一些內(nèi)部特性）來闡述需求。關(guān)鍵的問題是一定要編寫需求文檔。我曾經(jīng)目睹過一個項目中途更換了所有的開發(fā)者，客戶被迫與新的需求分析者坐到一起。分析人員說：“我們想與你談?wù)勀愕男枨??！笨蛻舻牡趯嶋H上，需求并未編寫成文檔，因此新的分析人員不得不從頭做起。所以如果只有一堆郵件、貼條、會談過幾次或一些零碎的對話，你就確信你已明白用戶的需求，那完全是自欺欺人。另外一種定義認(rèn)為需求是“用戶所需要的并能觸發(fā)一個程序或系統(tǒng)開發(fā)工作的說明”（Jones1994。需求分析專家AlanDavis（1993）品是怎樣設(shè)計、構(gòu)造的。而下面的定義則從用戶需要進(jìn)一步轉(zhuǎn)移到了系統(tǒng)特性（SommervilleandSawyer1997：需求是??指明必須實現(xiàn)什么的規(guī)格說明。它描述了系統(tǒng)的行為、特性或?qū)傩?，是在開發(fā)過程中對系統(tǒng)的約束。從上面這些不同形式的定義不難發(fā)現(xiàn)：并沒有一個清晰、毫無二義性的“需求”術(shù)語存在，真正的“需求”實際上在人們的腦海中。任何文檔形式的需求（例如：需求規(guī)格說明）僅是一個模型，一種敘述（Lawrence1998。我們需要確保所有項目風(fēng)險承擔(dān)者在描述需求的那些名詞的理解上務(wù)必達(dá)成共識。下面這些定義是需求工程領(lǐng)域中常見術(shù)語的定義說明。軟件需求包括三個不同的層次—業(yè)務(wù)需求、用戶需求和功能需求—也包括非功能需求。業(yè)務(wù)需求（businessrequirement）反映了組織機構(gòu)或客戶對系統(tǒng)、產(chǎn)品高層次的目標(biāo)要求，它們在項目視圖與范圍文檔中予以說明。用戶需求(userrequirement)文檔描述了用戶使用產(chǎn)品必須要完成的任務(wù)，這在使用實例（usecase）文檔或方案腳本（scenario）說明中予以說明。功能需求(functionalrequirement)定義了開發(fā)人員必須實現(xiàn)的軟件功能，使得用戶能完成他們的任務(wù)，從而滿足了業(yè)務(wù)需求。所謂特性(feature)是指邏輯上相關(guān)的功能需求的集合，給用戶提供處理1-1所示。業(yè)務(wù)需求業(yè)務(wù)需求項目視圖與范圍文檔用戶需求質(zhì)量屬性使用實例文檔其它非功能需求系統(tǒng)需求功能需求約束條件軟件需求規(guī)格說明在軟件需求規(guī)格說明（softwarerequirementsspecification，SRS）中說明的功能需求充分描述了軟件系統(tǒng)所應(yīng)具有的外部行為。軟件需求規(guī)格說明在開發(fā)、測試、質(zhì)量保證、項目管理以及相關(guān)項目功能中都起了重要的作用。對一個復(fù)雜產(chǎn)品來說，軟件功能需求也許只是系統(tǒng)需求的一個子集，因為另外一些可能屬于軟件部件。作為功能需求的補充，軟件需求規(guī)格說明還應(yīng)包括非功能需求，它描述了系統(tǒng)展現(xiàn)給用戶的行為和執(zhí)行的操作等。它包括產(chǎn)品必須遵從的標(biāo)準(zhǔn)、規(guī)范和合約；外部界面的具體細(xì)節(jié)；性能要求；設(shè)計或?qū)崿F(xiàn)的約束條件及質(zhì)量屬性。所謂約束是指對開發(fā)人員在軟件產(chǎn)品設(shè)計和構(gòu)造上的限制。質(zhì)量屬性是通過多種角度對產(chǎn)品的特點進(jìn)行描述，從而反映產(chǎn)品功能。多角度描述產(chǎn)品對用戶和開發(fā)人員都極為重要。下面以一個字處理程序為例來說明需求的不同種類。業(yè)務(wù)需求可能是：“用戶能有效地糾而對應(yīng)的用戶需求可能是“找出文檔中的拼寫錯誤并通過一個提供的替換項列表來供選擇替示提供替換詞的對話框以及實現(xiàn)整個文檔范圍的替換。管理人員或市場分析人員會確定軟件的業(yè)務(wù)需求，這使公司運作更加高效（對信息系統(tǒng)而言）或具有很強的市場競爭力（對商業(yè)軟件產(chǎn)品而言。所有的用戶需求必須與業(yè)務(wù)需求一致。用戶需求使需求分析者能從中總結(jié)出功能需求以滿足用戶對產(chǎn)品的要求從而完成其任務(wù)，而開發(fā)人員則根據(jù)功能需求來設(shè)計軟件以實現(xiàn)必須的功能。從以上定義可以發(fā)現(xiàn)，需求并未包括設(shè)計細(xì)節(jié)、實現(xiàn)細(xì)節(jié)、項目計劃信息或測試信息。需求與這些沒有關(guān)系，它關(guān)注的是充分說明你究竟想開發(fā)什么。項目也有其它方面的需求，如開發(fā)環(huán)境需求或發(fā)布產(chǎn)品及移植到支撐環(huán)境的需求。盡管這些需求對項目成功也至關(guān)重要，但它們并非本書所要討論的。FrederickBrooks在他1987NoSilverBullet：EssenceandAccidentsofSoftwareEngineering”中充分說明了需求過程在軟件項目中扮演的重要角色：開發(fā)軟件系統(tǒng)最為困難的部分就是準(zhǔn)確說明開發(fā)什么。最為困難的概念性工作便是編寫出詳細(xì)技術(shù)需求，這包括所有面向用戶、面向機器和其它軟件系統(tǒng)的接口。同時這也是一旦做錯，將最終會給系統(tǒng)帶來極大損害的部分，并且以后再對它進(jìn)行修改也極為困難。每個軟件產(chǎn)品都是為了使其用戶能以某種方式改善他們的生活，于是，花在了解他們需要上的時間便是使項目成功的一種高層次的投資。這對于商業(yè)最終用戶應(yīng)用程序，企業(yè)信息系統(tǒng)和軟件作為一個大系統(tǒng)的一部分的產(chǎn)品是顯而易見的。但是對于我們開發(fā)人員來說，并沒有編寫出客戶認(rèn)可的需求文檔，我們?nèi)绾沃理椖坑诤螘r結(jié)束？而如果我們不知道什么對客戶來說是重要的，那我們又如何能使客戶感到滿意呢？然而，即便并非出于商業(yè)目的的軟件需求也是必須的。例如軟件庫、組件和工具這些供開發(fā)小組內(nèi)部使用的軟件。當(dāng)然你可能偶爾勿需文檔說明就能與其他人意見較為一致，但更常見的是出現(xiàn)重復(fù)返工這種不可避免的后果，而重新編制代碼的代價遠(yuǎn)遠(yuǎn)超過重寫一份需求文檔的代價。近來，我遇到一個開發(fā)小組開發(fā)包括流程圖工具和源代碼編輯器在內(nèi)的一套計算機輔助軟件工程工具。不幸的是，在他們開發(fā)完這個工具后，發(fā)現(xiàn)這個工具不能打印出源代碼文件，而用戶當(dāng)然希望有這個功能。結(jié)果這個小組只好手工抄寫源代碼文檔以供代碼檢查。這說明那怕相反的情況，我曾為一個要集成到“商業(yè)錯誤跟蹤系統(tǒng)”中的簡單電子郵件界面寫了一頁需求說明。而Unix系統(tǒng)管理員在為處理電子郵件寫腳本時發(fā)現(xiàn)簡單的一張需求清單竟是如此有用。我依據(jù)需求對系統(tǒng)進(jìn)行測試時，此系統(tǒng)不僅非常清晰地實現(xiàn)了所有必需功能，而且未發(fā)現(xiàn)任何錯誤。不重視需求過程的項目隊伍將自食其果。需求工程中的缺陷將給項目成功帶來極大風(fēng)險，這里的“成功”是指推出的產(chǎn)品能以合理的價格、及時限在功能、質(zhì)量上完全滿足用戶的期望。下面將討論一些需求風(fēng)險。第5章將介紹怎樣應(yīng)用軟件風(fēng)險管理防止與需求有關(guān)的風(fēng)險的出現(xiàn)。不適當(dāng)?shù)男枨筮^程所引起的一些風(fēng)險用戶不多導(dǎo)致產(chǎn)品無法被接受。用戶需求的增加帶來過度的耗費和降低產(chǎn)品的質(zhì)量。模棱兩可的需求說明可能導(dǎo)致時間的浪費和返工。用戶增加一些不必要的特性和開發(fā)人員畫蛇添足(gold-plating)。過分簡略的需求說明以致遺漏某些關(guān)鍵需求。忽略某類用戶的需求將導(dǎo)致眾多客戶的不滿。不完善的需求說明使得項目計劃和跟蹤無法準(zhǔn)確進(jìn)行。無足夠用戶參與客戶經(jīng)常不明白為什么收集需求和確保需求質(zhì)量需花費那么多功夫，開發(fā)人員可能也不重視用戶的參與。究其原因：一是因為與用戶合作不如編寫代碼有意思；二是因為開發(fā)人員覺得已經(jīng)明白用戶的需求了。在某些情況下，與實際使用產(chǎn)品的用戶直接接觸很困難，而客戶也不太明白自己的真正需求。但還是應(yīng)讓具有代表性的用戶在項目早期直接參與到開發(fā)隊伍中，并一同經(jīng)歷整個開發(fā)過程。用戶需求的不斷增加在開發(fā)中若不斷地補充需求，項目就越變越龐大以致超過其計劃及預(yù)算范圍。計劃并不總是與項目需求規(guī)模與復(fù)雜性、風(fēng)險、開發(fā)生產(chǎn)率及需求變更實際情況相一致，這使得問題更難解決。實際上，問題根源在于用戶需求的改變和開發(fā)者對新需求所作的修改。要想把需求變更范圍控制到最小，必須一開始就對項目視圖、范圍、目標(biāo)、約束限制和成功標(biāo)準(zhǔn)給予明確說明，并將此說明作為評價需求變更和新特性的參照框架。說明中包括了對每種變更進(jìn)行變更影響因素分析的變更控制過程，有助于所有風(fēng)險承擔(dān)者明白業(yè)務(wù)決策的合理性，即為何進(jìn)行某些變更，相應(yīng)消耗的時間、資源或特性上的折中。產(chǎn)品開發(fā)中不斷延續(xù)的變更會使其整體結(jié)構(gòu)日漸紊亂，補丁代碼也使得整個程序難以理解和維護(hù)。插入補丁代碼使模塊違背強內(nèi)聚、松耦合的設(shè)計原則，特別是如果項目配置管理工作不完善的話，收回變更和刪除特性會帶來問題。如果你盡早地區(qū)別這些可能帶來變更的特性，你就能開發(fā)一個更為健壯的結(jié)構(gòu)，并能更好地適應(yīng)它。這樣設(shè)計階段需求變更不會直接導(dǎo)致補丁代碼，同時也有利于減少因變更導(dǎo)致質(zhì)量的下降。模棱兩可的需求模棱兩可是需求規(guī)格說明中最為可怕的問題(Lawrence1996)。它的一層含義是指諸多讀者對需求說明產(chǎn)生了不同的理解；另一層含義是指單個讀者能用不止一個方式來解釋某個需求說明。模棱兩可的需求會使不同的風(fēng)險承擔(dān)者產(chǎn)生不同的期望，它會使開發(fā)人員為錯誤問題而浪費時間，并且使測試者與開發(fā)者所期望的不一致。一位系統(tǒng)測試人員曾告訴我，她所在的測試組經(jīng)常對需求理解有誤，以致不得不重寫許多測試用例并重做許多測試。模棱兩可的需求帶來不可避免的后果便是返工—重做一些你認(rèn)為已做好的事情。返工會耗費開發(fā)總費用的40%，而70%～85%的重做是由于需求方面的錯誤所導(dǎo)致的（leffingwell1997。想像一下如果你能減少一半的返工會是怎樣的情況？你能更快地開發(fā)出產(chǎn)品，在同樣的時間內(nèi)開發(fā)更多、更好的產(chǎn)品，甚至能偶爾回家休息休息。處理模棱兩可需求的一種方法是組織好負(fù)責(zé)從不同角度審查需求的隊伍。僅僅簡單瀏覽一下需求文檔是不能解決模棱兩可問題的。如果不同的評審者從不同的角度對需求說明給予解釋，但每個評審人員都真正了解需求文檔，這樣二義性就不會直到項目后期才被發(fā)現(xiàn)，那時再發(fā)現(xiàn)的話會使得更正代價很大。其它檢測模棱兩可需求的技術(shù)由Gause和Weinberg（1989）給予介紹，本章的后面也有所涉及。不必要的特性“畫蛇添足”是指開發(fā)人員力圖增加一些“用戶欣賞”但需求規(guī)格說明中并未涉及的新功能。經(jīng)常發(fā)生的情況是用戶并不認(rèn)為這些功能性很有用，以致在其上耗費的努力“白搭”了。開發(fā)人員應(yīng)當(dāng)為客戶構(gòu)思方案并為他們提供一些具有創(chuàng)新意識的思路，具體提供哪些功能要在客戶所需與開發(fā)人員在允許時限內(nèi)的技術(shù)可行性之間求得平衡，開發(fā)人員應(yīng)努力使功能簡單易用，而不要未經(jīng)客戶同意，擅自脫離客戶要求，自作主張。同樣，客戶有時也可能要求一些看上去很“酷”，但缺乏實用價值的功能，而實現(xiàn)這些功能只能徒耗時間和成本。為了將“畫蛇添足”的危害盡量減小，應(yīng)確信：你明白為什么要包括這些功能，以及這些功能的“來龍去脈”，這樣使得需求分析過程始終是注重那些能使用戶完成他們業(yè)務(wù)任務(wù)的核心功能。過于精簡的規(guī)格說明有時，客戶并不明白需求分析有如此重要，于是只作一份簡略之至的規(guī)格說明，僅涉及了產(chǎn)品概念上的內(nèi)容，然后讓開發(fā)人員在項目進(jìn)展中去完善，結(jié)果很可能出現(xiàn)的是開發(fā)人員先建立產(chǎn)品的結(jié)構(gòu)之后再完成需求說明。這種方法可能適合于尖端研究性的產(chǎn)品或需求本身就十分靈活的情況（McConnell1996。但在大多數(shù)情況下，這會給開發(fā)人員帶來挫折（使他們在不正確的假設(shè)前提和極其有限的指導(dǎo)下工作，也會給客戶帶來煩惱（他們無法得到他們所設(shè)想的產(chǎn)品。忽略了用戶分類大多數(shù)產(chǎn)品是由不同的人使用其不同的特性，使用頻繁程度也有所差異，使用者受教育程度和經(jīng)驗水平也不盡相同。如果你不能在項目早期就針對所有這些主要用戶進(jìn)行分類的話，必然導(dǎo)致有的用戶對產(chǎn)品感到失望。例如，菜單驅(qū)動操作對高級用戶太低效了，但含義不清的命令和快捷鍵又會使不熟練的用戶感到困難。不準(zhǔn)確的計劃“上述是我對新產(chǎn)品的看法，好，現(xiàn)在你能告訴我你什么時候能完成嗎？”許多開發(fā)人員都遇到這種難題。對需求分析缺乏理解會導(dǎo)致過分樂觀的估計，而當(dāng)不可避免的超支發(fā)生時，會帶來頗多麻煩。據(jù)報道，導(dǎo)致需求過程中軟件成本估計極不準(zhǔn)確的原因主要有以下五點：頻繁的需求變更、遺漏的需求、與用戶交流不夠、質(zhì)量低下的需求規(guī)格說明和不完善的需求分析（Davis1995?；诓怀浞中畔⒑臀唇?jīng)深思的對需求不成熟的估計很容易為一些因素左右。要作出估計時，最好還是給出一個范圍（如最好的情況下，很可能的，最壞情況下）或一個可信賴的程度（我有90%的把握，我能在8周內(nèi)完成。未經(jīng)準(zhǔn)備的估計通常是作為一種猜測給出的，聽者卻認(rèn)為是一種承諾。因此我們要盡力給出可達(dá)到的目標(biāo)并堅持完成它。實行有效的需求工程管理的組織能獲得多方面的好處。最大的好處是在開發(fā)后期和整個維護(hù)階段的重做的工作大大減少了。Boehm（1981）發(fā)現(xiàn)要改正在產(chǎn)品付諸應(yīng)用后所發(fā)現(xiàn)的一個需求方面的缺陷比在需求階段改正這個錯誤要多付出68倍的成本。近來很多研究表明這種錯誤導(dǎo)致成本放大因子可以高達(dá)200倍。強調(diào)需求質(zhì)量并不能引起某些人的重視，他們錯誤地認(rèn)為在需求上消耗多少時間就會導(dǎo)致產(chǎn)品開發(fā)推遲多少時間。傳統(tǒng)的質(zhì)量成本角度分析揭示了需求及其它早期質(zhì)量工作的重要性（Wiegers1996a。正確的需求過程強調(diào)產(chǎn)品開發(fā)中的通力合作，包括在整個項目過程中多方風(fēng)險承擔(dān)者的積極努力。收集需求能使開發(fā)小組更好地了解市場，而市場因素是任何項目成功的一個關(guān)鍵因素。在產(chǎn)品開發(fā)前了解這些比在遭到客戶批評后才意識到要節(jié)約很多成本。讓用戶積極參與需求收集過程能使產(chǎn)品更富有吸引力，而且能擁有忠實的客戶關(guān)系。通過了解用戶的任務(wù)需求而不僅僅局限于一些“華麗”的特性，你能避免在無用功能上白耗精力，并且用戶的參與能彌補用戶期望和開發(fā)者實際開發(fā)之間的“鴻溝（期望差異將選定系統(tǒng)的需求明確地分配到各軟件子系統(tǒng)，強調(diào)采用產(chǎn)品工程的系統(tǒng)方法。這樣能簡化硬軟件的集成，也能確保軟硬件系統(tǒng)功能匹配適當(dāng)。有效的變更控制和影響分析過程也能降低需求變更帶來的負(fù)面影響。最后，將需求編寫成清晰、無二義性的文檔將會極大地有利于系統(tǒng)測試，確保產(chǎn)品質(zhì)量，以使所有風(fēng)險承擔(dān)者感到滿意。怎樣才能把好的需求規(guī)格說明和有問題的需求規(guī)格說明區(qū)別開來？下面討論單個需求陳述說明的幾個特點（Davis1993；IEEE1998SRS需求說明進(jìn)行認(rèn)真評審，能很好地確定哪些需求確實是需要的。只要你在編寫、評審需求時把這些特點記在心中，就會寫出更好的（盡管并不十分完美）需求文檔，同時也會開發(fā)出更好的產(chǎn)品。在第9章中，我們將使用這些特點找到一些需求陳述中的問題并改進(jìn)之。完整性每一項需求都必須將所要實現(xiàn)的功能描述清楚，以使開發(fā)人員獲得設(shè)計和實現(xiàn)這些功能所需的所有必要信息。正確性每一項需求都必須準(zhǔn)確地陳述其要開發(fā)的功能。做出正確判斷的參考是需求的來源，如用戶或高層的系統(tǒng)需求規(guī)格說明。若軟件需求與對應(yīng)的系統(tǒng)需求相抵觸則是不正確的。只有用戶代表才能確定用戶需求的正確性，這就是一定要有用戶的積極參與的原因。沒有用戶參全是評審者憑空猜測?？尚行悦恳豁椥枨蠖急仨毷窃谝阎到y(tǒng)和環(huán)境的權(quán)能和限制范圍內(nèi)可以實施的。為避免不可行的需求，最好在獲取（elicitation）需求(收集需求)過程中始終有一位軟件工程小組的組員與需求分析人員或考慮市場的人員在一起工作，由他負(fù)責(zé)檢查技術(shù)可行性。必要性的輸入，如使用實例或別的來源。劃分優(yōu)先級給每項需求、特性或使用實例分配一個實施優(yōu)先級以指明它在特定產(chǎn)品中所占的分量。如果把所有的需求都看作同樣重要，那么項目管理者在開發(fā)或節(jié)省預(yù)算或調(diào)度中就喪失控制自由度。第13章將更詳細(xì)地討論如何劃分優(yōu)先級。無二義性對所有需求說明的讀者都只能有一個明確統(tǒng)一的解釋，由于自然語言極易導(dǎo)致二義性，所以盡量把每項需求用簡潔明了的用戶性的語言表達(dá)出來。避免二義性的有效方法包括對需求文檔的正規(guī)審查，編寫測試用例，開發(fā)原型以及設(shè)計特定的方案腳本。可驗證性檢查一下每項需求是否能通過設(shè)計測試用例或其它的驗證方法，如用演示、檢測等來確定產(chǎn)品是否確實按需求實現(xiàn)了。如果需求不可驗證，則確定其實施是否正確就成為主觀臆斷，而非客觀分析了。一份前后矛盾，不可行或有二義性的需求也是不可驗證的。完整性不能遺漏任何必要的需求信息。遺漏需求將很難查出。注重用戶的任務(wù)而不是系統(tǒng)的功能將有助于你避免不完整性。如果知道缺少某項信息，用TBD(“待確定”)作為標(biāo)準(zhǔn)標(biāo)識來標(biāo)TBD項。一致性一致性是指與其它軟件需求或高層（系統(tǒng)，業(yè)務(wù)）需求不相矛盾。在開發(fā)前必須解決所有需求間的不一致部分。只有進(jìn)行一番調(diào)查研究，才能知道某一項需求是否確實正確。可修改性在必要時或為維護(hù)每一需求變更歷史記錄時，應(yīng)該修訂SRS。這就要求每項需求要獨立標(biāo)出，并與別的需求區(qū)別開來，從而無二義性。每項需求只應(yīng)在SRS中出現(xiàn)一次。這樣更改時易于保持一致性。另外，使用目錄表、索引和相互參照列表方法將使軟件需求規(guī)格說明更容易修改?？筛櫺詰?yīng)能在每項軟件需求與它的根源和設(shè)計元素、源代碼、測試用例之間建立起鏈接鏈，這種可跟蹤性要求每項需求以一種結(jié)構(gòu)化的，粒度好（fine-grained）的方式編寫并單獨標(biāo)明，而不是大段大段的敘述。第18章將詳細(xì)說明需求的可跟蹤性。需求中名詞術(shù)語的混淆將導(dǎo)致對科目（規(guī)范，discipline）叫法的不一致。一些作者把整個研究領(lǐng)域劃分為需求開發(fā)（本書的第二部分）和需求管理（本書第三部分）兩部分更合適，如圖1-2所示：需求工程需求工程需求開發(fā)需求管理問題獲取分析編寫規(guī)格說明驗證需求開發(fā)可進(jìn)一步分為：問題獲?。╡licitationanalysis、編寫規(guī)格說明（specification）和驗證（verification）四個階段（ThayerandDorfman1997。這些子項包括軟件類產(chǎn)品中需求收集、評價、編寫文檔等所有活動。需求開發(fā)活動包括以下幾個方面：確定產(chǎn)品所期望的用戶類。獲取每個用戶類的需求。了解實際用戶任務(wù)和目標(biāo)以及這些任務(wù)所支持的業(yè)務(wù)需求。分析源于用戶的信息以區(qū)別用戶任務(wù)需求、功能需求、業(yè)務(wù)規(guī)則、質(zhì)量屬性、建議解決方法和附加信息。將系統(tǒng)級的需求分為幾個子系統(tǒng)，并將需求中的一部份分配給軟件組件。了解相關(guān)質(zhì)量屬性的重要性。商討實施優(yōu)先級的劃分。將所收集的用戶需求編寫成規(guī)格說明和模型。評審需求規(guī)格說明，確保對用戶需求達(dá)到共同的理解與認(rèn)識，并在整個開發(fā)小組接受說明之前將問題都弄清楚。需求管理需要“建立并維護(hù)在軟件工程中同客戶達(dá)成的契約”（CMU/SEI1995。這種契約都包含在編寫的需求規(guī)格說明與模型中?？蛻舻慕邮軆H是需求成功的一半，開發(fā)人員也必須能夠接受他們，并真正把需求應(yīng)用到產(chǎn)品中。通常的需求管理活動包括：定義需求基線（迅速制定需求文檔的主體。評審提出的需求變更、評估每項變更的可能影響從而決定是否實施它。以一種可控制的方式將需求變更融入到項目中。使當(dāng)前的項目計劃與需求一致。估計變更需求所產(chǎn)生影響并在此基礎(chǔ)上協(xié)商新的承諾（約定。讓每項需求都能與其對應(yīng)的設(shè)計、源代碼和測試用例聯(lián)系起來以實現(xiàn)跟蹤。在整個項目過程中跟蹤需求狀態(tài)及其變更情況。由圖1-3中可以從另一個角度來看需求開發(fā)和需求管理之間的區(qū)別：市場市場客戶管理需求分析編寫文檔需求開發(fā)基準(zhǔn)需求說明需求管理當(dāng)前基線修正后基線市場，管理需求變更過程項目環(huán)境需求變更項目變更下一步：下一步：記錄你在當(dāng)前項目或以前項目中所遇到的與需求相關(guān)的問題。指明每一個問題是需求開發(fā)問題還是需求管理問題，以及這些問題帶來的影響及其產(chǎn)生的根本原因。與你的組員和其他風(fēng)險承擔(dān)者（客戶，市場調(diào)查人員，項目管理者）一起討論當(dāng)前或以前項目中的需求問題，及其產(chǎn)生的根源和帶來的影響。向所有參與者指明，如果想解決這些困難，必須正視它，大家是否為此做好準(zhǔn)備了呢？整理出對整個項目人員一天訓(xùn)練用的軟件需求課程，人員要包括重要的客戶，市場人員和管理人員。訓(xùn)練是一種有效的團(tuán)隊學(xué)習(xí)與合作的方法。大家將會在訓(xùn)練中達(dá)成術(shù)語與技術(shù)上的共識，有利于相互交流溝通與協(xié)作。Contoso制藥公司的高級管理長官Gerhard,會見Contoso公司的信息系統(tǒng)開發(fā)小組的新管理員CynthiaGerhard說道?！霸撓到y(tǒng)可以記錄庫房或某個實驗室中已有的化學(xué)藥品，這樣，化學(xué)專家可以直接從樓下的某人那里拿到所需的藥品，而不必再買一瓶新的。另外，衛(wèi)生保健部門也得為聯(lián)邦政府寫些關(guān)于化學(xué)藥品的使用報告。你們小組能在五個月內(nèi)開發(fā)出該系統(tǒng)嗎？”“我已經(jīng)明白這個項目的重要性了，Gerhard”CynthiaGerhard覺得很奇怪“你的意思是什么？我不是剛告訴你我的需求了嗎？”“實際上，你只說明了整個項目的概念與目標(biāo)，”Cynthi業(yè)務(wù)需求并不能為我們提供足夠的詳細(xì)信息以確定究竟要開發(fā)什么樣的軟件，以及需要多長時間。我需要一些分析人員與一些知道系統(tǒng)使用要求的化學(xué)專家進(jìn)行討論，然后才能真正明白達(dá)到業(yè)務(wù)目標(biāo)所需的各種功能和用戶的要求。我們甚至并不需要Gerhard說明要做的系統(tǒng)嗎？”Cynthia猜想用戶要求，結(jié)果不會令人滿意。我們只是軟件開發(fā)人員，而并非化學(xué)專家。我們并不能真正明白化學(xué)專家們需要這個化學(xué)制品跟蹤系統(tǒng)做些什么。我曾經(jīng)嘗試過，“行了，行了，我們沒有那么多時間”Gerhard像這樣的對話經(jīng)常出現(xiàn)在軟件開發(fā)過程中。要求開發(fā)一個新信息系統(tǒng)的客戶通常并不懂得從系統(tǒng)的實際用戶處得到信息的重要性。市場人員在有了一個很不錯的新產(chǎn)品想法后，也就自認(rèn)為能充分代表產(chǎn)品用戶的興趣要求。然而，直接從產(chǎn)品的實際用戶處收集需求有著不可替代的必要性。通過對8380個項目的調(diào)查發(fā)現(xiàn)，導(dǎo)致項目失敗的最主要的兩個原因是缺乏(Standish1995)。引起需求問題的一部分原因是對不同層次需求（業(yè)務(wù)、用戶、功能）的混淆所致。Gerhard說明了一些業(yè)務(wù)需求，但他并不能描述用戶需求，因為他并不是“化學(xué)制品跟蹤系統(tǒng)”的實際使用者。只有實際用戶才能描述他們要用此系統(tǒng)必須完成的任務(wù)。但他們又不能指出完成這些任務(wù)所有具體的功能需求。本章說明客戶與開發(fā)人員之間的關(guān)系，它對軟件項目開發(fā)的成功極為關(guān)鍵。我建議寫一份軟件客戶需求權(quán)利書和相應(yīng)的軟件客戶需求義務(wù)書，以強調(diào)客戶（和實際用戶）參與需求開發(fā)過程的重要性。通常意義下，客戶是指直接或間接從產(chǎn)品中獲得利益的個人或組織。軟件客戶包括提出要求、支付款項、選擇、具體說明或使用軟件產(chǎn)品的項目風(fēng)險承擔(dān)者(stakeholder)或是獲得產(chǎn)品所產(chǎn)生的結(jié)果的人。Gerhard代表支付、采購(procure)或投資軟件產(chǎn)品的這類客戶，處于Gerhard層次上的客戶有義務(wù)說明業(yè)務(wù)需求。他們應(yīng)闡明產(chǎn)品的高層次概念和將發(fā)布產(chǎn)品的主要業(yè)務(wù)內(nèi)容。在第6章中討論到業(yè)務(wù)需求應(yīng)說明客戶、公司和想從該系統(tǒng)獲利的風(fēng)險承擔(dān)者或從系統(tǒng)中取得結(jié)果的用戶所要求的目標(biāo)。業(yè)務(wù)需求為后繼工作建立了一個指導(dǎo)性的框架。其它任何說明都應(yīng)遵從業(yè)務(wù)需求的規(guī)定，然而業(yè)務(wù)需求并不能為開發(fā)人員提供許多開發(fā)所需的細(xì)節(jié)說明。下一層需求—用戶需求—必須從使用產(chǎn)品的用戶處收集。因此這些用戶（通常稱作最終用戶，構(gòu)成了另一種軟件客戶。他們能說清楚要使用該產(chǎn)品完成什么任務(wù)和一些非功能性的特性，而這些特性會對使用戶很好接收具有該特點的產(chǎn)品是重要的。說明業(yè)務(wù)需求的客戶有時將試圖替代用戶說話，但通常他們根本無法準(zhǔn)確說明用戶需求。因為對信息系統(tǒng)、合同(contract)或是客戶應(yīng)用程序的開發(fā)、業(yè)務(wù)需求應(yīng)來自風(fēng)險承擔(dān)者，而用戶需求則應(yīng)來自產(chǎn)品的真正使用、操作者。不幸的是，這兩種客戶可能都覺得他們沒有時間與(收集、分析與編寫需求說明)需求分析者討論。有時客戶還希望分析人員或開發(fā)人員無須討論和編寫文檔就能說出用戶的需求。除非遇到的需求極為簡單，否則不能這樣做。如果你的組織希望軟件成功，那必須要花上數(shù)天時間來消除需求中模糊不清的地方和一些使程序人員感到困惑的方面。商業(yè)軟件開發(fā)的情況有些不同，因為通常其客戶就是用戶。正如市場部這類客戶代理，可能想確定究竟軟件產(chǎn)品的購買者會喜歡什么。但即使是商業(yè)軟件，也應(yīng)該讓實際用戶參與到收集需求的過程中來（第7章將談及。如果你不這樣做，那產(chǎn)品很可能會因缺乏足夠用戶提供的信息而出現(xiàn)不少隱患。優(yōu)秀的軟件產(chǎn)品是建立在優(yōu)秀的需求基礎(chǔ)之上的。而高質(zhì)量的需求來源于客戶與開發(fā)人員之間有效的交流與合作。通常，開發(fā)人員與客戶或客戶代理人，如市場人員間的關(guān)系反而會成為一種對立關(guān)系。雙方的管理者都只想自己的利益而擱置用戶提供的需求從而產(chǎn)生摩擦，在這種情況下，不會給雙方帶來一點益處。只有當(dāng)雙方參與者都明白要成功自己需要什么，同時也應(yīng)知道要成功合作方需要什么時，才能建立起一種合作關(guān)系。由于項目壓力與日漸增，所有風(fēng)險承擔(dān)者有著一個共同的目標(biāo)這一點容易被遺忘。其實大家都想開發(fā)出一個既能實現(xiàn)商業(yè)價值，又能滿足用戶需要，還能使開發(fā)者感到滿足的優(yōu)秀軟件產(chǎn)品。軟件客戶需求權(quán)利書列出了十條關(guān)于客戶在項目需求工程實施中與分析人員、開發(fā)人員交流時的合法要求。每一項權(quán)利都對應(yīng)著軟件開發(fā)人員、分析人員的義務(wù)。而軟件客戶需求義務(wù)書也列出了十條關(guān)于客戶在需求過程中應(yīng)承擔(dān)的義務(wù)。如果愿意，可以將其作為開發(fā)人員的權(quán)利書。軟件客戶需求權(quán)利書客戶有如下權(quán)利：要求分析人員使用符合客戶語言習(xí)慣的表達(dá)。要求分析人員了解客戶系統(tǒng)的業(yè)務(wù)及目標(biāo)。要求分析人員組織需求獲取期間所介紹的信息，并編寫軟件需求規(guī)格說明。要求開發(fā)人員對需求過程中所產(chǎn)生的工作結(jié)果進(jìn)行解釋說明。要求開發(fā)人員在整個交流過程中保持和維護(hù)一種合作的職業(yè)態(tài)度。要求開發(fā)人員對產(chǎn)品的實現(xiàn)及需求都要提供建議，拿出主意。描述產(chǎn)品使其具有易用、好用的特性。可以調(diào)整需求，允許重用已有的軟件組件。當(dāng)需要對需求進(jìn)行變更時，對成本、影響、得失（trade-off）有個真實可信的評估。獲得滿足客戶功能和質(zhì)量要求的系統(tǒng)，并且這些要求是開發(fā)人員同意的。軟件客戶需求義務(wù)書客戶有下列義務(wù)：給分析人員講解業(yè)務(wù)及說明業(yè)務(wù)方面的術(shù)語等專業(yè)問題。抽出時間清楚地說明需求并不斷完善。當(dāng)說明系統(tǒng)需求時，力求準(zhǔn)確詳細(xì)。需要時要及時對需求做出決策。要尊重開發(fā)人員的成本估算和對需求的可行性分析。對單項需求、系統(tǒng)特性或使用實例劃分優(yōu)先級。評審需求文檔和原型。一旦知道要對項目需求進(jìn)行變更，要馬上與開發(fā)人員聯(lián)系。在要求需求變更時，應(yīng)遵照開發(fā)組織確定的工作過程來處理。尊重需求工程中開發(fā)人員采用的流程（過程。當(dāng)為內(nèi)部集團(tuán)使用而開發(fā)軟件時，這些權(quán)利和義務(wù)可以直接應(yīng)用于客戶。這也適用于那些有合同關(guān)系或者有明確的主要客戶集的情況。對普遍市場產(chǎn)品的開發(fā)，這些權(quán)利和義務(wù)更適于像市場部這樣的客戶代理者。作為項目計劃的一部分，客戶和開發(fā)人員應(yīng)評審上述兩張列表并達(dá)成共識。一些很忙的客戶可能不愿意積極參與需求過程（也即，他們不太接受軟件客戶需求義務(wù)書，而缺少客戶參與將很可能導(dǎo)致不理想的產(chǎn)品。故一定要確保需求開發(fā)中的主要參與者都了解并接受他們的義務(wù)。如果遇到分歧，通過協(xié)商以達(dá)成對各自義務(wù)的相互理解，這樣能減少今后的摩擦（如一方要求而另一方不愿意或不能滿足要求。權(quán)利#1：要求分析人員使用符合客戶語言習(xí)慣的表達(dá)需求討論應(yīng)集中于業(yè)務(wù)需要和任務(wù)，故要使用業(yè)務(wù)術(shù)語，你應(yīng)將其教給分析人員，而你不一定要懂得計算機的行業(yè)術(shù)語。權(quán)利#2：要求分析人員了解客戶的業(yè)務(wù)及目標(biāo)通過與用戶交流來獲取用戶需求、分析人員才能更好地了解你的業(yè)務(wù)任務(wù)和怎樣才能使產(chǎn)品更好地滿足你的需要。這將有助于開發(fā)人員設(shè)計出真正滿足你的需要并達(dá)到你期望的優(yōu)秀軟件。為幫助開發(fā)人員和分析人員，可以考慮邀請他們觀察你或你的同事是怎樣工作的。如果新開發(fā)系統(tǒng)是用來替代已有的系統(tǒng)，那么開發(fā)人員應(yīng)使用一下目前的系統(tǒng)，這將有利于他們明白目前系統(tǒng)是怎樣工作的，其工作流程的情況，以及可供改進(jìn)之處。權(quán)利#3：要求分析人員編寫軟件需求規(guī)格說明分析人員要把從你和其他客戶那里獲得的所有信息進(jìn)行整理，以區(qū)分開業(yè)務(wù)需求及規(guī)范、功能需求、質(zhì)量目標(biāo)、解決方法和其它信息。通過這些分析就能得到一份軟件需求規(guī)格說明。而這份軟件需求規(guī)格說明（softwarerequirementsspecification,SRS）便在開發(fā)人員和客戶之間針對要開發(fā)的產(chǎn)品內(nèi)容達(dá)成了協(xié)議。SRS可以用一種你認(rèn)為易于翻閱和理解的方式組織編寫。要評審編寫出的規(guī)格說明以確保它們準(zhǔn)確而完整地表達(dá)了你的需求。一份高質(zhì)量的軟件需求規(guī)格說明能有助于開發(fā)人員開發(fā)出真正需要的產(chǎn)品。權(quán)利#4：要求得到需求工作結(jié)果的解釋說明分析人員可能采用了多種圖表作為文字性軟件需求規(guī)格說明的補充。因為如工作流程圖那樣的圖表能很清楚地描述出系統(tǒng)行為的某些方面。所以需求說明中的各種圖表有著極高的價值。雖然它們不太難于理解，但是你很可能對此并不熟悉。因此可以要求分析人員解釋說明每張圖表的作用或其它的需求開發(fā)工作結(jié)果和符號的意義，及怎樣檢查圖表有無錯誤及不一致等。權(quán)利#5：要求開發(fā)人員尊重你的意見如果用戶與開發(fā)人員之間不能相互理解，那關(guān)于需求的討論將會有障礙，共同合作能使功所付出的時間。同樣，客戶也應(yīng)對開發(fā)人員為項目成功這一共同目標(biāo)所作出的努力表示尊重與感激。權(quán)利#6：要求開發(fā)人員對需求及產(chǎn)品實施提供建議，拿出主意通常，客戶所說的“需求”已是一種實際可能的實施解決方案，分析人員將盡力從這些解決方法中了解真正的業(yè)務(wù)及其需求，同時還應(yīng)找出已有系統(tǒng)不適合當(dāng)前業(yè)務(wù)之處，以確保產(chǎn)品不會無效或低效。在徹底弄清業(yè)務(wù)領(lǐng)域內(nèi)的事情后，分析人員有時就能提出相當(dāng)好的改進(jìn)方法。有經(jīng)驗且富有創(chuàng)造力的分析人員還能提出增加一些用戶并未發(fā)現(xiàn)的很有價值的系統(tǒng)特性。權(quán)利#7：描述產(chǎn)品易使用的特性你可以要求分析人員在實現(xiàn)功能需求的同時還要注重軟件的易用性。因為這些易用特性或質(zhì)量屬性能使你更準(zhǔn)確、高效地完成任務(wù)。例如，客戶有時要求產(chǎn)品要“用戶友好”或人員通過詢問和調(diào)查了解客戶所要的友好、健壯、高效所包含的具體特性（第11章將詳細(xì)討論它。權(quán)利#8：調(diào)整需求，允許重用已有的軟件組件需求通常要有一定的靈活性。分析人員可能發(fā)現(xiàn)已有的某個軟件組件與你描述的需求很相符。在這種情況下，分析人員應(yīng)提供一些修改需求的選擇以便開發(fā)人員能夠在新系統(tǒng)開發(fā)中重用一些已有的軟件。如果有可重用的機會出現(xiàn)，同時你又能調(diào)整你的需求說明，那就能降低成本和節(jié)省時間，而不必嚴(yán)格按原有的需求說明開發(fā)。所以說，如果想在產(chǎn)品中使用一些已有的商業(yè)常用組件，而它們并不完全適合你所需的特性，這時一定程度上的需求靈活性就顯得極為重要了。權(quán)利#9：要求對變更的代價提供真實可信的評估有時人們面臨更好、也更昂貴的方案時，會做出不同的選擇。而這時，對需求變更的影響進(jìn)行評估從而對業(yè)務(wù)決策提供幫助，是十分必要的，所以，你有權(quán)利要求開發(fā)人員通過分析給出一個的確真實可信的評估，包括影響、成本和得失等評估。開發(fā)人員不能由于不想實施變更而隨意夸大評估成本。權(quán)利#10：獲得滿足客戶功能和質(zhì)量要求的系統(tǒng)每個人都希望項目獲得成功。但這不僅要求你要清晰地告知開發(fā)人員關(guān)于系統(tǒng)“做什么”所需的所有信息，而且還要求開發(fā)人員能通過交流了解清楚取舍與限制。一定要明確說明你的假設(shè)和潛在的期望。否則，開發(fā)人員開發(fā)出的產(chǎn)品很可能無法讓你滿意。義務(wù)#1：給分析人員講解你的業(yè)務(wù)分析人員要依靠你給他們講解的業(yè)務(wù)概念及術(shù)語。但你不能指望分析人員會成為該領(lǐng)域的專家，而只能讓他們真正明白你的問題和目標(biāo)。不要期望分析人員能把握你們業(yè)務(wù)的細(xì)微義務(wù)#2：抽出時間清楚地說明并完善需求客戶很忙，經(jīng)常在最忙的時候還得參與需求開發(fā)。但無論如何，你有義務(wù)抽出時間參與“頭腦風(fēng)暴”會議的討論，接受采訪或其它獲取需求的活動。有時分析人員可能先以為明白了你的觀點，而過后發(fā)現(xiàn)還需要你的講解。這時，請耐心一些對待需求和需求的精化工作過程中的反復(fù)，因為它是人們交流中的很自然的現(xiàn)象，何況這對軟件產(chǎn)品的成功極為重要。義務(wù)#3：準(zhǔn)確而詳細(xì)地說明需求編寫一份清晰、準(zhǔn)確的需求文檔是很困難的。由于處理細(xì)節(jié)問題不但煩人而且又耗時，故很容易留下模糊不清的需求。但是，在開發(fā)過程中，必須得解決這種模糊性和不準(zhǔn)確性。而你恰是為解決這些問題作出決定的最佳人選。不然的話，你就只好靠開發(fā)人員去正確猜測了。在需求規(guī)格說明中暫時加上待定（tobedetermined,TBD）的標(biāo)志是個不錯的辦法。用該標(biāo)志可指明了哪些需要進(jìn)一步探討、分析或增加信息的地方。不過，有時也可能因為某個特殊需求難以解決或沒有人愿意處理它而注上TBD標(biāo)志。盡量將每項需求的內(nèi)容都闡述清楚，以便分析人員能準(zhǔn)確的將其寫進(jìn)軟件需求規(guī)格說明中。如果你一時不能準(zhǔn)確表述，那就得允許獲取必要的準(zhǔn)確信息這樣一個過程。通常使用所謂的原型技術(shù)。通過開發(fā)的原型，你可以同開發(fā)人員一起反復(fù)修改，不斷完善需求定義。義務(wù)#4：及時地作出決定正如一位建筑師為你修建房屋，分析人員將要求你做出一些選擇和決定。這些決定包括來自多個用戶提出的處理方法或在質(zhì)量特性沖突和信息準(zhǔn)確度中選擇折衷方案等。有權(quán)做出決定的客戶必須積極地對待這一切，盡快做處理、做決定。因為開發(fā)人員通常只有等你做出了決定才能行動，而這種等待會延誤項目的進(jìn)展。義務(wù)#5：尊重開發(fā)人員的需求可行性及成本評估所有的軟件功能都有其成本價格，開發(fā)人員最適合預(yù)算這些成本（盡管許多開發(fā)人員并不擅長評估預(yù)測。你所希望的某些產(chǎn)品特性可能在技術(shù)上行不通，或者實現(xiàn)它要付出極為高昂的代價。而某些需求試圖在操作環(huán)境中要求不可能達(dá)到的性能或試圖得到一些根本得不到的數(shù)據(jù)，開發(fā)人員會對此作出負(fù)面的評價意見，你應(yīng)該尊重他們的意見。有時，你可以重新給出一個在技術(shù)上可行、實現(xiàn)上便宜的需求，例如，要求某個行為在“瞬間”發(fā)生是不可行的，但換種更具體的時間需求說法“在50ms，這就可以實現(xiàn)了。義務(wù)#6絕大多數(shù)項目沒有足夠的時間或資源來實現(xiàn)功能性的每個細(xì)節(jié)。決定哪些特性是必要的，哪些是重要的，哪些是好的，是需求開發(fā)的主要部分。只能由你來負(fù)責(zé)設(shè)定需求優(yōu)先級，因為開發(fā)者并不可能按你的觀點決定需求優(yōu)先級。開發(fā)者將為你確定優(yōu)先級提供有關(guān)每個需求的花費和風(fēng)險的信息。當(dāng)你設(shè)定優(yōu)先級時，你幫助開發(fā)者確保在適當(dāng)?shù)臅r間內(nèi)用最小的開支取得最好的效果。在時間和資源限制下，關(guān)于所需特性能否完成或完成多少應(yīng)該尊重開發(fā)人員的意見。盡管沒有人愿意看到自己所希望的需求在項目中未被實現(xiàn)，但畢竟是要面對這種現(xiàn)實的。業(yè)務(wù)決策有時不得不依據(jù)優(yōu)先級來縮小項目范圍或延長工期，或增加資源，或在質(zhì)量上尋找折衷。義務(wù)#7：評審需求文檔和原型正如我們將在第14章討論的，無論是正式的還是非正式的方式，對需求文檔進(jìn)行評審都會對軟件質(zhì)量提高有所幫助。讓客戶參與評審才能真正鑒別需求文檔是否的確完整、正確說明了期望的必要特性。評審也給客戶代表提供一個機會，給需求分析人員帶來反饋信息以改進(jìn)他們的工作。如果你認(rèn)為編寫的需求文檔不夠準(zhǔn)確，就有義務(wù)盡早告訴分析人員并為改進(jìn)提供建議。通過閱讀需求規(guī)格說明，很難想象實際的軟件是什么樣子的。更好的方法是先為產(chǎn)品開發(fā)一個原型。這樣你就能提供更有價值的反饋信息給開發(fā)人員，幫助他們更好地理解你的需求。必須認(rèn)識到：原型并非是一個實際產(chǎn)品，但開發(fā)人員能將其轉(zhuǎn)變、擴充成功能齊全的系統(tǒng)。義務(wù)#8：需求出現(xiàn)變更要馬上聯(lián)系不斷的需求變更會給在預(yù)定計劃內(nèi)完成高質(zhì)量產(chǎn)品帶來嚴(yán)重的負(fù)面影響。變更是不可避免的，但在開發(fā)周期中變更越在晚期出現(xiàn)，其影響越大。變更不僅會導(dǎo)致代價極高的返工，而且工期也會被迫延誤，特別是在大體結(jié)構(gòu)已完成后又需要增加新特性時。所以一旦你發(fā)現(xiàn)需要變更需求時，請一定立即通知分析人員。義務(wù)#9：應(yīng)遵照開發(fā)組織處理需求變更的過程為了將變更帶來的負(fù)面影響減少到最低限度，所有的參與者必須遵照項目的變更控制過程。這要求不放棄所有提出的變更，對每項要求的變更進(jìn)行分析、綜合考慮，最后作出合適的決策以確定將某些變更引入項目中。義務(wù)#10：尊重開發(fā)人員采用的需求工程過程軟件開發(fā)中最具挑戰(zhàn)性的莫過于收集需求并確定其正確性。分析人員采用的方法有其合理性。也許你認(rèn)為需求過程不太劃算，但請相信花在需求開發(fā)上的時間是“很有價值”的。如果你理解并支持分析人員為收集、編寫需求文檔和確保其質(zhì)量所采用的技術(shù)，那么整個過程將會更為順利。盡管去詢問分析人員為什么他們要收集某些信息，或參與與需求有關(guān)的活動。為所開發(fā)產(chǎn)品的需求簽訂協(xié)議是客戶與開發(fā)人員關(guān)系中的重要部分。許多組織在需求文檔中使用“簽約”這個概念來作為客戶同意需求的標(biāo)志行為。故要讓所有需求參與者都真正明白“簽約”的意思。同樣的問題也會發(fā)生在僅把簽約看作是完成文檔的管理人員身上。一旦有需求變更出現(xiàn)，他便指著軟件需求規(guī)格說明說道這樣的態(tài)度都是不對的，不可能在項目早期就了解所有需求，而且毫無疑問需求將會出現(xiàn)變更。在需求上簽約是終止需求開發(fā)過程的正確方法。然而，參與者必須明白他們的簽約意味著什么。更為重要的是簽名是建立在一個需求協(xié)議的基線上，因此在需求規(guī)格說明上的簽約應(yīng)該線上通過項目定義的變更過程來進(jìn)行。我知道變更可能會使我們要重新協(xié)商成本、資源和項關(guān)于基線達(dá)成一定共識會易于忍受將來的摩擦，這些摩擦來源于項目的改進(jìn)和需求的誤差或市場和業(yè)務(wù)的新要求等。給初步的需求開發(fā)工作畫上雙方都明確的句號會有助你形成一個持續(xù)良好的客戶與開發(fā)人員的關(guān)系，為項目的成功奠定了基礎(chǔ)。下一步：下一步：讓客戶提供項目的業(yè)務(wù)需求和用戶需求。對權(quán)利書和義務(wù)書的條目，哪些被客戶接受、理解并付諸實踐了？哪些沒有？與你的重要客戶一起討論權(quán)利書和義務(wù)書，以達(dá)成協(xié)議，并付諸實踐。這些行為會有助于客戶和開發(fā)人員更好地互相理解，以形成更融洽的關(guān)系。如果你是軟件開發(fā)項目中的客戶參與方，你感到你的需求權(quán)利書沒有被充分尊重，就可以與軟件項目的領(lǐng)導(dǎo)人員或業(yè)務(wù)分析人員一起討論權(quán)利書的內(nèi)容。要想建立一種合作的工作關(guān)系，就要盡力使對方對你的義務(wù)書感到滿意。10年前，我曾熱衷于追求軟件的開發(fā)方法論的研究，將整套整套的模型、技術(shù)等用于解以分別應(yīng)用于不同的問題，而并不是去設(shè)計或購買一整套的解決方案。即使你采用了一套商業(yè)上的方法，你也應(yīng)當(dāng)在其中增加那些在業(yè)界被認(rèn)為行之有效的推薦技術(shù)?！白罴逊椒ā边@個詞值得討論一下：誰能確定什么是“最佳”的呢？而且，得到這個結(jié)論的依據(jù)何在？一種方案是把這方面的專家召集起來分析眾多不同組織中成功和失敗的項目（Browm1996。專家們將那些成功項目中提供高效的方法和失敗項目中導(dǎo)致低效甚至無效的方法都?xì)w納出來。這樣，專家們就能找到公認(rèn)的能收到實效的關(guān)鍵方法。這些方法即是“最3-1所列。表3-1需求工程推薦方法知識技能 需求管理 項目管理培訓(xùn)需求分析人員 ?確定變更控制過程 ?選擇合適的生存周期培訓(xùn)用戶代表和管理人員 ?建立變更控制委員會 ?確定需求的基本計劃培訓(xùn)應(yīng)用領(lǐng)域的開發(fā)人員 ?進(jìn)行變更影響分析 ?協(xié)商約定匯編術(shù)語 ?跟蹤影響工作產(chǎn)品的每項變更 ?管理需求風(fēng)險編寫需求文檔的基準(zhǔn)版本和控制版本 ?跟蹤需求工作維護(hù)變更歷史記錄跟蹤需求狀態(tài)衡量需求穩(wěn)定性使用需求管理工具需求開發(fā)獲 取 分 析 編寫規(guī)格說明書 驗 證編寫項目視圖與范圍 ?繪制關(guān)聯(lián)圖 ?采用軟件需求規(guī)格說明模版 ?審查需求文檔確定需求開發(fā)過程 ?創(chuàng)建開發(fā)原型 ?指明需求來源 ?依據(jù)需求編寫測試用例用戶群分類 ?分析可行性 ?為每項需求注上標(biāo)號 ?編寫用戶手冊選擇產(chǎn)品代表 ?確定需求優(yōu)先級 ?記錄業(yè)務(wù)規(guī)范 ?確定合格的標(biāo)準(zhǔn)建立核心隊伍 ?為需求建立模型 ?創(chuàng)建需求跟蹤能力矩陣確定使用實例 ?編寫數(shù)據(jù)字典召開應(yīng)用程序開發(fā) ?應(yīng)用質(zhì)量功能調(diào)配聯(lián)系（JAD）會議 （QFD）分析用戶工作流程確定質(zhì)量屬性檢查問題報告需求重用并非上面所有的條目都是最佳方法，或許也并非全部經(jīng)過了系統(tǒng)地評估。但無論如何，(SommervilleandSawyer1997)。其中每一條都在本章給予了簡要介紹，并在其他章節(jié)或其他更詳細(xì)地討論技術(shù)來源的地方給出了參考文獻(xiàn)。表3-2把表3-1中的方法按實施的優(yōu)先順序和實施難度進(jìn)行了分組。由于所列的方法都是有所裨益的，故最好是循序漸進(jìn)，先從那些相對容易實施而對項目有很大影響的方法開始。表3-2實施需求工程的推薦方法優(yōu)先級別 難 度高 中 低確定需求開發(fā)過程 ?確定使用實例 ?培訓(xùn)應(yīng)用領(lǐng)域的開發(fā)人員確定需求的基本計劃 ?確定質(zhì)量屬性 ?編寫項目視圖與范圍高 ?協(xié)商約定 ?確定需求優(yōu)先級 ?用戶群分類采用軟件規(guī)格說明模板 ?繪制關(guān)聯(lián)圖確定變更控制過程 ?指明需求來源建立變更控制委員會 ?為每項需求注上標(biāo)號審查需求文檔 ?編寫需求文檔的基準(zhǔn)版本和控制版本培訓(xùn)用戶代表和管理人員 ?培訓(xùn)需求分析人員 ?匯編術(shù)語為需求建立模型 ?建立核心隊伍 ?選擇產(chǎn)品代表管理需求風(fēng)險 ?創(chuàng)建開發(fā)原型 ?編寫數(shù)據(jù)字典中 ?使用需求管理工具 ?分析可行性 ?記錄業(yè)務(wù)規(guī)范創(chuàng)建需求跟蹤能力矩陣 ?確定合格的標(biāo)準(zhǔn) ?依據(jù)需求編寫測試用例進(jìn)行變更影響分析 ?跟蹤需求狀態(tài)跟蹤影響工作產(chǎn)品的每項變更選擇合適的生存周期召開應(yīng)用程序開發(fā)聯(lián)系 ?分析用戶工作流程低 （JAD）會議 ?檢查問題報告需求重用 ?編寫用戶手冊應(yīng)用質(zhì)量功能調(diào)配（QFD） ?維護(hù)變更歷史記錄衡量需求穩(wěn)定性 ?跟蹤需求工作不要想著把所有這些方法都用于你的下一個項目。而應(yīng)該考慮將其中的一些方法推薦到你的需求工具箱中。不管你的項目處在開發(fā)的哪個階段，你都可以馬上開始應(yīng)用某些方法，譬如變更管理的處理。其它如需求獲取等可以在你的下一個項目開始時付諸應(yīng)用。當(dāng)然其它一些方法也可能并不適合你目前的項目。第4章介紹一些用于評價需求工程的方法，并可設(shè)計一張實施需求方法改進(jìn)的步驟圖。具體的改進(jìn)方法在此處和第4章中都給予介紹。絕大部分的軟件開發(fā)人員都沒有接受過高效需求工程所需技能的正規(guī)培訓(xùn)。但許多開發(fā)人員在職業(yè)生活中的某個階段總會扮演一個需求分析員的角色，與客戶一起工作：收集，分將有助于提高需求分析員的能力和水平。因為需求對項目成功極為重要，所有的項目風(fēng)險承擔(dān)者都應(yīng)該對需求工程的重要性、合理性及其方法有一個基本的了解。把項目風(fēng)險承擔(dān)者（例如開發(fā)人員，市場人員，客戶，測試人員和管理人員）召集起來進(jìn)行為期一天的需求過程概要學(xué)習(xí)，這對建立一個合作團(tuán)隊是很有效的。所有參與者都會更好地明白各自所面臨的挑戰(zhàn)是什么，以及為了整個團(tuán)隊獲得成功大家都需要作些什么。同樣，開發(fā)人員也能對應(yīng)用領(lǐng)域的術(shù)語和一些基本概念有大致的了解。培訓(xùn)需求分析人員所有的開發(fā)人員都應(yīng)接受一個基本的需求工程培訓(xùn)。但那些負(fù)責(zé)收集(capturing)、編寫文檔和分析用戶需求的人員應(yīng)當(dāng)進(jìn)行為期一周或更長時間的培訓(xùn)。把高水平的需求人員組織起來，通過良好的信息交流，了解應(yīng)用領(lǐng)域并有效地應(yīng)用需求工程中的成熟技術(shù)。培訓(xùn)軟件需求的用戶代表和管理人員參與軟件開發(fā)的用戶代表應(yīng)接受為期一天左右關(guān)于需求工程的培訓(xùn)，開發(fā)管理者和客戶管理者也應(yīng)參加。這樣的培訓(xùn)將使他們明白強調(diào)需求的重要性，以及忽略需求帶來的風(fēng)險。參加過我組織的需求討論會的一些用戶表示，他們在此之后更能理解軟件開發(fā)人員了。讓開發(fā)人員了解應(yīng)用領(lǐng)域的基本概念 組織一些簡短的關(guān)于客戶業(yè)務(wù)活動、術(shù)語、目標(biāo)等方面的討論會以幫助開發(fā)人員對應(yīng)用領(lǐng)域有個基本了解。這能減少誤解及工程中的返工。你可能要為每位開發(fā)人員安排一個用戶伙伴以便在項目過程中解釋業(yè)務(wù)術(shù)語和概念。產(chǎn)品代表就應(yīng)該扮演這樣的角色。編寫項目術(shù)語匯編為減少溝通方面的問題，編一部術(shù)語匯編將項目應(yīng)用領(lǐng)域的專用詞匯給予定義說明，既要包括那些有多種含義與用法的術(shù)語，也要包括那些在專用領(lǐng)域和一般使用中有不同含義的詞。第1章討論了需求的三個層次：業(yè)務(wù)，用戶和功能。在項目中它們在不同的時間來自不同的來源，也有著不同的目標(biāo)和對象，并需以不同的方式編寫成文檔。業(yè)務(wù)需求（或產(chǎn)品視圖和范圍）不應(yīng)包括用戶需求（或使用實例，而所有的功能需求都應(yīng)該源于用戶需求。同時你也需要獲取非功能需求，如質(zhì)量屬性。你可以在下列章節(jié)中找到相關(guān)主題的詳細(xì)內(nèi)容：第4章—確定需求開發(fā)過程。第6章—編寫項目視圖和范圍文檔。第7章—將用戶群分類并歸納其特點，為每個用戶類選擇產(chǎn)品代表（productchampion。第8章—讓用戶代表確定使用實例。第11章—確定質(zhì)量屬性和其它非功能需求。確定需求開發(fā)過程確定如何組織需求的收集、分析、細(xì)化并核實的步驟，并將它編寫成文檔。對重要的步驟要給予一定指導(dǎo)，這將有助于分析人員的工作，而且也使收集需求活動的安排和進(jìn)度計劃更容易進(jìn)行。編寫項目視圖和范圍文檔項目視圖和范圍文檔應(yīng)該包括高層的產(chǎn)品業(yè)務(wù)目標(biāo)，所有的使用實例和功能需求都必須遵從能達(dá)到的業(yè)務(wù)需求。項目視圖說明使所有項目參與者對項目的目標(biāo)能達(dá)成共識。而范圍則是作為評估需求或潛在特性的參考。將用戶群分類并歸納各自特點為避免出現(xiàn)疏忽某一用戶群需求的情況，要將可能使用產(chǎn)品的客戶分成不同組別。他們可能在使用頻率、使用特性、優(yōu)先等級或熟練程度等方面都有所差異。詳細(xì)描述出它們的個性特點及任務(wù)狀況，將有助于產(chǎn)品設(shè)計。選擇每類用戶的產(chǎn)品代表 為每類用戶至少選擇一位能真正代表他們需求的人作為那一類用戶的代表并能作出決策。這對于內(nèi)部信息系統(tǒng)的開發(fā)是最易實現(xiàn)的，因為此時，用戶就是身邊的職員。而對于商業(yè)開發(fā)，就得在主要的客戶或測試者中建立起良好的合作關(guān)系，并確定合適的產(chǎn)品代表。他們必須一直參與項目的開發(fā)而且有權(quán)作出決策。建立起典型用戶的核心隊伍 把同類產(chǎn)品或你的產(chǎn)品的先前版本用戶代表召集起來，從他們那里收集目前產(chǎn)品的功能需求和非功能需求。這樣的核心隊伍對于商業(yè)開發(fā)尤為有用，因為你擁有一個龐大且多樣的客戶基礎(chǔ)。與產(chǎn)品代表的區(qū)別在于，核心隊伍成員通常沒有決定權(quán)。讓用戶代表確定使用實例從用戶代表處收集他們使用軟件完成所需任務(wù)的描述—使用實例，討論用戶與系統(tǒng)間的交互方式和對話要求。在編寫使用實例的文檔時可采用標(biāo)準(zhǔn)模版，在使用實例基礎(chǔ)上可得到功能需求。召開應(yīng)用程序開發(fā)聯(lián)系會議應(yīng)用程序開發(fā)聯(lián)系（JAD）會議是范圍廣的、簡便的專題討論會（workshop，也是分析人員與客戶代表之間一種很好的合作辦法，并能由此擬出需求文檔的底稿。該會議通過緊密而集中的討論得以將客戶與開發(fā)人員間的合作伙伴關(guān)系付諸于實踐（WoodandSilver1995。分析用戶工作流程觀察用戶執(zhí)行業(yè)務(wù)任務(wù)的過程。畫一張簡單的示意圖（最好用數(shù)據(jù)流圖）來描繪出用戶什么時候獲得什么數(shù)據(jù)，并怎樣使用這些數(shù)據(jù)。編制業(yè)務(wù)過程流程文檔將有助于明確產(chǎn)品的使用實例和功能需求。你甚至可能發(fā)現(xiàn)客戶并不真地需要一個全新的軟件系統(tǒng)就能達(dá)到他們的業(yè)務(wù)目標(biāo)（McGrawandHarbison1997。確定質(zhì)量屬性和其它非功能需求在功能需求之外再考慮一下非功能的質(zhì)量特點，這會使你的產(chǎn)品達(dá)到并超過客戶的期望。這些特點包括性能、有效性、可靠性、可用性等，而在這些質(zhì)量屬性上客戶提供的信息相對來說就非常重要了。通過檢查當(dāng)前系統(tǒng)的問題報告來進(jìn)一步完善需求客戶的問題報告及補充需求為新產(chǎn)品或新版本提供了大量豐富的改進(jìn)及增加特性的想法，負(fù)責(zé)提供用戶支持及幫助的人能為收集需求過程提供極有價值的信息?？珥椖恐赜眯枨笕绻蛻粢蟮墓δ芘c已有的產(chǎn)品很相似，則可查看需求是否有足夠的靈活性以允許重用一些已有的軟件組件。需求分析（requirementanalysis）包括提煉、分析和仔細(xì)審查已收集到的需求，以確保所有的風(fēng)險承擔(dān)者都明白其含義并找出其中的錯誤、遺漏或其它不足的地方。分析員通過評價來確定是否所有的需求和軟件需求規(guī)格說明都達(dá)到了第1章中優(yōu)秀需求說明的要求。分析的目的在于開發(fā)出高質(zhì)量和具體的需求，這樣你就能作出實用的項目估算并可以進(jìn)行設(shè)計、構(gòu)造和測試。通常，把需求中的一部分用多種形式來描述，如同時用文本和圖形來描述。分析這些不同的視圖將揭示出一些更深的問題，這是單一視圖無法提供的（Davis1995。分析還包括與客戶的交流以澄清某些易混淆的問題，并明確哪些需求更為重要。其目的是確保所有風(fēng)險承擔(dān)者盡早地對項目達(dá)成共識并對將來的產(chǎn)品有個相同而清晰的認(rèn)識。下面幾章對需求分析中的任務(wù)進(jìn)行了詳細(xì)討論：第6章—繪制系統(tǒng)關(guān)聯(lián)圖。第9章—建立數(shù)據(jù)字典。第10章—為需求建立模型。第12章—建立用戶接口原型。第13章—確定需求優(yōu)先級。繪制系統(tǒng)關(guān)聯(lián)圖這種關(guān)聯(lián)圖是用于定義系統(tǒng)與系統(tǒng)外部實體間的界限和接口的簡單模型。同時它也明確了通過接口的信息流和物質(zhì)流。創(chuàng)建用戶接口原型當(dāng)開發(fā)人員或用戶不能確定需求時，開發(fā)一個用戶接口原型—一個可能的局部實現(xiàn)—這樣使得許多概念和可能發(fā)生的事更為直觀明了。用戶通過評價原型將使項目參與者能更好地相互理解所要解決的問題。注意要找出需求文檔與原型之間所有的沖突之處。分析需求可行性在允許的成本、性能要求下，分析每項需求實施的可行性，明確與每項需求實現(xiàn)相聯(lián)系的風(fēng)險，包括與其它需求的沖突，對外界因素的依賴和技術(shù)障礙。確定需求的優(yōu)先級別應(yīng)用分析方法來確定使用實例、產(chǎn)品特性或單項需求實現(xiàn)的優(yōu)先級別。以優(yōu)先級為基礎(chǔ)確定產(chǎn)品版本將包括哪些特性或哪類需求。當(dāng)允許需求變更時，在特定的版本中加入每一項變更，并在那個版本計劃中作出需要的變更。為需求建立模型需求的圖形分析模型是軟件需求規(guī)格說明極好的補充說明。它們能提供不同的信息與關(guān)系以有助于找到不正確的、不一致的、遺漏的和冗余的需求。這樣的模型包括數(shù)據(jù)流圖、實體關(guān)系圖、狀態(tài)變換圖、對話框圖、對象類及交互作用圖。創(chuàng)建數(shù)據(jù)字典數(shù)據(jù)字典是對系統(tǒng)用到的所有數(shù)據(jù)項和結(jié)構(gòu)的定義，以確保開發(fā)人員使用統(tǒng)一的數(shù)據(jù)定義。在需求階段，數(shù)據(jù)字典至少應(yīng)定義客戶數(shù)據(jù)項以確?？蛻襞c開發(fā)小組是使用一致的定義和術(shù)語。分析和設(shè)計工具通常包括數(shù)據(jù)字典組件。使用質(zhì)量功能調(diào)配質(zhì)量功能調(diào)配(QFD）是一種高級系統(tǒng)技術(shù)，它將產(chǎn)品特性、屬性與對客戶的重要性聯(lián)系起來。該技術(shù)提供了一種分析方法以明確那些是客戶最為關(guān)注的特性。QFD將需求分為三類：期望需求，即客戶或許并未提及，但如若缺少會讓他們感到不滿意；普通需求；興奮需求，即實現(xiàn)了會給客戶帶去驚喜，但若未實現(xiàn)也不會受到責(zé)備（Zultner1993;Pardee1996。無論你的需求從何而來，也不管你是怎樣得到的，你都必須用一種統(tǒng)一的方式來將它們編寫成可視文檔。業(yè)務(wù)需求要寫成項目視圖和范圍文檔。用戶需求要用一種標(biāo)準(zhǔn)使用實例模板編寫成文檔。而軟件需求規(guī)格說明（requirementspecification）則包含了軟件的功能需求和非功能需求。你必須為每項需求明確建立標(biāo)準(zhǔn)的慣例，并確定在SRS中采用任何慣例，以確保SRS的統(tǒng)一風(fēng)格，同時讀者也會明白怎樣解釋它。下列章節(jié)討論了關(guān)于編寫需求文檔的幾個方面：第8章—記錄業(yè)務(wù)規(guī)范。第9章—采用SRS模板；為每項需求注上標(biāo)號。第18章—指明需求來源；創(chuàng)建需求跟蹤能力矩陣。采用SRS模板在你的組織中要為編寫軟件需求文檔定義一種標(biāo)準(zhǔn)模板。該模板為記錄功能需求和各種其它與需求相關(guān)的重要信息提供了統(tǒng)一的結(jié)構(gòu)。注意，其目的并非是創(chuàng)建一種全新的模板，而是采用一種已有的且可滿足項目需要并適合項目特點的模板。許多組織一開始都采用IEEE標(biāo)準(zhǔn)830-1998(IEEE1998)描述的SRS模板。要相信模板是很有用的，但有時要根據(jù)項目特點進(jìn)行適當(dāng)?shù)母膭印Ｖ该餍枨蟮膩碓礊榱俗屗许椖匡L(fēng)險承擔(dān)者明白SRS中為何提供這些功能需求，要都能追溯每項需求的來源，這可能是一種使用實例或其它客戶要求，也可能是某項更高層系統(tǒng)需求、業(yè)務(wù)規(guī)范、政府法規(guī)、標(biāo)準(zhǔn)或別的外部來源。為每項需求注上標(biāo)號制定一種慣例來為SRS中的每項需求提供一個獨立的可識別的標(biāo)號或記號。這種慣例應(yīng)當(dāng)很健全，允許增加、刪除和修改。作了標(biāo)號的需求使得需求能被跟蹤，記錄需求變更并為需求狀態(tài)和變更活動建立度量。記錄業(yè)務(wù)規(guī)范業(yè)務(wù)規(guī)范是指關(guān)于產(chǎn)品的操作原則，比如誰能在什么情況下采取什么動作。將這些編寫成SRS中的一個獨立部分，或一獨立的業(yè)務(wù)規(guī)范文檔。某些業(yè)務(wù)規(guī)范將引出相應(yīng)的功能需求；當(dāng)然這些需求也應(yīng)能追溯相應(yīng)業(yè)務(wù)規(guī)范。創(chuàng)建需求跟蹤能力矩陣建立一個矩陣把每項需求與實現(xiàn)、測試它的設(shè)計和代碼部分聯(lián)系起來。這樣的需求跟蹤能力矩陣同時也把功能需求和高層的需求及其它相關(guān)需求聯(lián)系起來了。在開發(fā)過程中建立這個矩陣，而不要等到最后才去補建。驗證是為了確保需求說明準(zhǔn)確、完整地表達(dá)必要的質(zhì)量特點。當(dāng)你閱讀軟件需求規(guī)格說明（SRS）時，可能覺得需求是對的，但實現(xiàn)時，卻很可能會出現(xiàn)問題。當(dāng)以需求說明為依據(jù)編寫測試用例時，你可能會發(fā)現(xiàn)說明中的二義性。而所有這些都必須改善，因為需求說明要作為設(shè)計和最終系統(tǒng)驗證的依據(jù)。客戶的參與在需求驗證（requirementverification）中占有重要的位置，第14章還將進(jìn)一步討論它。審查需求文檔對需求文檔進(jìn)行正式審查是保證軟件質(zhì)量的很有效的方法。組織一個由不同代表（如分析人員，客戶，設(shè)計人員，測試人員）組成的小組，對SRS及相關(guān)模型進(jìn)行仔細(xì)的檢查。另外在需求開發(fā)期間所做的非正式評審也是有所裨益的。以需求為依據(jù)編寫測試用例根據(jù)用戶需求所要求的產(chǎn)品特性寫出黑盒功能測試用例?？蛻敉ㄟ^使用測試用例以確認(rèn)是否達(dá)到了期望的要求。還要從測試用例追溯回功能需求以確保沒有需求被疏忽，并且確保所有測試結(jié)果與測試用例相一致。同時，要使用測試用例來驗證需求模型的正確性，如對話框圖和原型等。編寫用戶手冊在需求開發(fā)早期即可起草一份用戶手冊，用它作為需求規(guī)格說明的參考并輔助需求分析。優(yōu)秀的用戶手冊要用淺顯易懂的語言描述出所有對用戶可見的功能。而SRS中予以說明。確定合格的標(biāo)準(zhǔn)讓用戶描述什么樣的產(chǎn)品才算滿足他們的要求和適合他們使用的。將合格的測試建立在使用情景描述或使用實例的基礎(chǔ)之上（Hsia,Kung,andSell1997。當(dāng)你完成需求說明之后，不可避免地還會遇到項目需求的變更。有效的變更管理需要對變更帶來的潛在影響及可能的成本費用進(jìn)行評估。變更控制委員會與關(guān)鍵的項目風(fēng)險承擔(dān)者要進(jìn)行協(xié)商，以確定哪些需求可以變更。同時，無論是在開發(fā)階段還是在系統(tǒng)測試階段，還應(yīng)跟蹤每項需求的狀態(tài)。建立起良好的配置管理方法是進(jìn)行有效需求管理（requirementmanagement）的先決條件。許多開發(fā)組織使用版本控制和其它管理配置技術(shù)來管理代碼，所以你也可以采用這些方法來管理你的需求文檔，需求管理的改進(jìn)也是將全新的管理配置方法引入項目的組織中的一種方法。下列章節(jié)討論了需求管理涉及到的各種技術(shù)：第16章—建立需求基準(zhǔn)版本和需求控制版本文檔。第17章—確定需求變更控制過程；建立變更控制委員會。第18章—進(jìn)行需求變更影響分析；跟蹤所有受需求變更影響的工作產(chǎn)品。第19章—使用需求管理工具。確定需求變更控制過程 確定一個選擇、分析和決策需求變更的過程。所有的需求變更都需遵循此過程，商業(yè)化的問題跟蹤工具都能支持變更控制過程。建立變更控制委員會 組織一個由項目風(fēng)險承擔(dān)者組成的小組作為變更控制委員會，由他們來確定進(jìn)行哪些需求變更，此變更是否在項目范圍內(nèi)，估價它們，并對此評估作出決策以確定選擇哪些，放棄哪些，并設(shè)置實現(xiàn)的優(yōu)先順序，制定目標(biāo)版本。進(jìn)行需求變更影響分析應(yīng)評估每項選擇的需求變更，以確定它對項目計劃安排和其它需求的影響。明確與變更相關(guān)的任務(wù)并評估完成這些任務(wù)需要的工作量。通過這些分析將有助于變更控制委員會作出更好的決策。跟蹤所有受需求變更影響的工作產(chǎn)品當(dāng)進(jìn)行某項需求變更時，參照需求跟蹤能力矩陣找到相關(guān)的其它需求、設(shè)計模板、源代碼和測試用例，這些相關(guān)部分可能也需要修改。這樣能減少因疏忽而不得不變更產(chǎn)品的機會，這種變更在變更需求的情況下是必須進(jìn)行的。建立需求基準(zhǔn)版本和需求控制版本文檔確定一個需求基準(zhǔn)，這是一致性需求在特定時刻的快照。之后的需求變更就遵循變更控制過程即可。每個版本的需求規(guī)格說明都必須是獨立說明，以避免將底稿和基準(zhǔn)或新舊版本相混淆。最好的辦法是使用合適的配置管理工具在版本控制下為需求文檔定位。維護(hù)需求變更的歷史記錄記錄變更需求文檔版本的日期以及所做的變更、原因，還包括由誰負(fù)責(zé)更新和更新的新版本號等。版本控制工具能自動完成這些任務(wù)。跟蹤每項需求的狀態(tài)建立一個數(shù)據(jù)庫，其中每一條記錄保存一項功能需求。保存每項功能需求的重要屬性，它包括狀態(tài)（如已推薦的，已通過的，已實施的，或已驗證的，這樣在任何時候都能得到每個狀態(tài)類的需求數(shù)量。衡量需求穩(wěn)定性記錄基準(zhǔn)需求的數(shù)量和每周或每月的變更（添加、修改、刪除）數(shù)量。過多的需求變更“是一個報警信號”，意味著問題并未真正弄清楚，項目范圍并未很好地確定下來或是政策變化較大。使用需求管理工具商業(yè)化的需求管理工具能幫助你在數(shù)據(jù)庫中存儲不同類型的需求，為軟件工程管理方法在本質(zhì)上與項目的需求過程是緊密相關(guān)的。項目計劃建立在功能基礎(chǔ)之上，而需求變更會影響這些計劃。因此，項目計劃應(yīng)能允許一定程度的需求變更或項目范圍的擴展。如果剛開始，需求不能確定，你可以選擇一種軟件開發(fā)方法生存周期以允許這種不確定性，并在弄清后逐漸實施。關(guān)于需求工程項目管理（projectmanagement）方法的更詳細(xì)內(nèi)容將在以下章節(jié)討論：第5章—編寫文檔和管理與需求相關(guān)的風(fēng)險。第15章—基于需求的項目計劃。第16章—記錄需求開發(fā)和管理中的工作。選擇一種合適的軟件開發(fā)方法生存周期經(jīng)典的瀑布法軟件開發(fā)生存周期只適用于需求說明在項目早期即可全部完成的情況。你的組織應(yīng)根據(jù)不同類型的項目和需求說明的不同程度選擇幾種不同的方法（McConnell1996。如果需求說明在項目早期無法全部確定，則從最為清晰易懂的需求開始，建立一個健壯的可修改的結(jié)構(gòu)，再逐漸增加補充。實現(xiàn)了部分特性的產(chǎn)品可作為早期版本發(fā)布（Gilb1998?；谛枨蟮捻椖坑媱?隨著需求細(xì)節(jié)不斷變得清晰、完善，項目開發(fā)計劃的進(jìn)度安排將會不斷改變。一開始可以根據(jù)項目視圖和范圍對開發(fā)功能需求所需的工作量作一估算，建立在不甚完善的需求基礎(chǔ)之上的成本、進(jìn)度安排的估計很不可靠，但隨著需求說明的完善，估計也會得到不斷改善。發(fā)生需求變更時協(xié)商項目約定當(dāng)在項目中添加新的需求時，估計一下你是否能在目前安排下，利用現(xiàn)有資源保質(zhì)保量完成。如果不能，將項目的實現(xiàn)與管理聯(lián)系起來，協(xié)商一下新的、切實可行的約定（Humphrey1997。如果協(xié)商不成功，則將可能的后果和更新項目風(fēng)險管理計劃聯(lián)系起來，以反映出對項目成功的新的不利因素。編寫文檔和管理與需求相關(guān)的風(fēng)險采用自由討論的方法并將與需求相關(guān)的項目風(fēng)險編寫成文檔。利用各種方法來減輕或阻止這些風(fēng)險，實施這些方法并跟蹤其發(fā)展及效果。跟蹤需求工程所耗的工作量記錄需求開發(fā)和管理活動所花費的工作量。利用這些數(shù)據(jù)可以評估計劃的需求活動是否已達(dá)到所期望的要求，并可以為將來項目的需求工程提供更好的所需資源的計劃。下一步：下一步：回到第1章的下一步中你已明確了與需求有關(guān)的一些問題。從本章中學(xué)到的推薦的實踐方法，可能會有助于解決這些問題。針對建議的每一種方法，要在你組織中發(fā)現(xiàn)那些可能給其實現(xiàn)帶來困難的障礙。將在先前步驟中被確認(rèn)是好的需求方法整理成一張表。針對每個方法，指明你的項目的能力水平：專家，熟練者，生手或新手。如果你的隊伍中無一人熟練的話，就得要求項目的某個參與者學(xué)習(xí)更多的知識，并將他所學(xué)的教給隊伍中的其他人。第3章介紹了幾十種需求工程中的好方法，你應(yīng)當(dāng)考慮在實踐中應(yīng)用它們。把理論方法付諸實踐是改進(jìn)軟件過程（process）的核心所在。從根本上說，改進(jìn)過程包括使用更多有效的方法避免使用過去使用過的令人頭痛的方法。然而，改進(jìn)之路卻是從失敗、錯誤開始，還要歷經(jīng)諸如受人為抵制的影響及因任務(wù)的時間緊迫導(dǎo)致改進(jìn)被擱置這樣的挫折。軟件開發(fā)過程的改進(jìn)有以下兩個主要目標(biāo)：解決在以前項目或目前項目中遇到的問題。防止和避免你可能在將來的項目中要遇到的問題。如果目前采用的方法好像也挺有效的，你可能覺得沒有必要改變你的方法。但是，即便是很成功的軟件組織在面臨大項目、不同的客戶群、緊迫的進(jìn)度安排或全新的應(yīng)用領(lǐng)域時也會感到力不從心。因此，至少你應(yīng)該知道其它一些很有價值也頗有效的需求工程方法，并把它們加入到你的軟件工程中。本章介紹了需求與其它主要的項目過程和風(fēng)險承擔(dān)者之間的聯(lián)系、關(guān)于軟件開發(fā)過程改進(jìn)的一些基本概念并推薦了一種經(jīng)改進(jìn)的生存期。我把一些重要的需求“過程精華”羅列出來以供參考使用。本章還介紹了實施改進(jìn)需求工程實踐的一個流程藍(lán)圖。需求是軟件項目成功的核心所在，它為其他許多技術(shù)、管理活動奠定了基礎(chǔ)。變更你的需求開發(fā)和管理方法將對其他項目過程產(chǎn)生影響，反之亦然。需求與其他過程的聯(lián)系見圖4-1。下面簡要介紹各過程間的接口。過程構(gòu)造過程制過程軟件需求縮減過程驗證實現(xiàn)作為的正確性參考變更控制過程系統(tǒng)測試過程制定項目計劃需求是制定項目計劃的基礎(chǔ)。因為開發(fā)資源和進(jìn)度安排的估計都要建立在對最終產(chǎn)品的真正理解之上。通常，項目計劃指出所有希望的特性不可能在允許的資源和時間內(nèi)完成，因此，需要縮小項目范圍或采用版本計劃對功能特性進(jìn)行選擇。項目跟蹤和控制監(jiān)控每項需求的狀態(tài)，以便項目管理者能發(fā)現(xiàn)設(shè)計和驗證是否達(dá)到預(yù)期的要求。如果沒有達(dá)到，管理者通常請求變更控制過程來進(jìn)行范圍的縮減。變更控制在需求編寫成文檔并制定基線以后，所有接下來的變更都應(yīng)通過確定的變更控制過程來進(jìn)行。變更控制過程能確保：變更的影響是可以接受的。受到變更影響的所有人都接到通知并明白這一點。由合適的人選來作出接受變更的正式?jīng)Q定。資源按需進(jìn)行調(diào)整。保持需求文檔是最新版本并是準(zhǔn)確的更新文檔。系統(tǒng)測試用戶需求和功能需求是系統(tǒng)測試的重要參考。如果未說明清楚產(chǎn)品在多種多樣條件下的期望行為，系統(tǒng)測試者將很難明確正確的測試內(nèi)容。反過來說，系統(tǒng)測試是一種方法，可以驗證計劃中