bafd2b98317835f4548c7e257eb13550.doc1前言--------------------------------------------------------------2本書有益于讀者之處-------------------------------------------------2誰應(yīng)該讀這本書------------------------------------------------------3本書說明------------------------------------------------------------3-----------------------------------------------------------4第一部分軟件需求：是什么和為什么-------------------------------------5第一章基本的軟件需求-------------------------------------------5----------------------------------------6需求的層次-----------------------------------------------7-----------------------------------------8導(dǎo)致發(fā)生不合格的需求說明-------------------------9高質(zhì)量的需求過程帶來的好處------------------------------11優(yōu)秀需求具有的特性--------------------------------------12求的開發(fā)和管理----------------------------------------13第二章客戶的需求觀--------------------------------------------15誰是客戶------------------------------------------------15客戶與開發(fā)人員之間的合作關(guān)系----------------------------16軟件客戶需求權(quán)利書--------------------------------------17軟件客戶需求義務(wù)書--------------------------------------18--------------------------------------42---------------------------------------44bafd2b98317835f4548c7e257eb13550.doc2前言五十年積累的經(jīng)驗(yàn)，但許多軟件開發(fā)組織仍不得不在收集、編寫和管理產(chǎn)品需求中疲乏用戶參與、不完整的需求及不斷變更需求，是導(dǎo)致信息技術(shù)項(xiàng)目不能按進(jìn)度安排和功能的主要原因(TheCHAOSReport,TheStandishGroupInternational.Inc.,1995)。許多軟件開發(fā)人員不能熟練地收集客戶(customer)需求，很多開發(fā)軟件開發(fā)中，信息溝通(交流)至少應(yīng)與計(jì)算占有同等的比重，然而我們往往強(qiáng)調(diào)了計(jì)算而忽致理解怎樣構(gòu)造一個(gè)軟件才能滿足用戶(user)實(shí)際的需要，同時(shí)也包括了編寫文檔和管理變更的的方法學(xué)。讀者之處Top達(dá)到實(shí)現(xiàn)更高的客戶滿意度。令減少維護(hù)和支持費(fèi)用。令在開發(fā)周期早期提高項(xiàng)目需求分析的質(zhì)量，減少重復(fù)勞動(dòng)，從而提高生產(chǎn)率。幫助你改進(jìn)收集和分析需求、編寫和修改需求規(guī)格說明以及在整個(gè)產(chǎn)品開發(fā)周期中等規(guī)模的信息系統(tǒng)——“化學(xué)制品跟蹤系統(tǒng)”說明了許多實(shí)用技術(shù)(不必?fù)?dān)憂——你勿需知道任何關(guān)于化學(xué)的知識(shí)也能理解該項(xiàng)目)。這個(gè)實(shí)例的項(xiàng)目說明還會(huì)幫助你了解怎樣把不同的策略 (方法)較好地融合到一塊。本書中還穿插著源于該實(shí)例的項(xiàng)目參與者之間的對(duì)話實(shí)例。不論你的誰應(yīng)該讀這本書Top的或升級(jí)的軟件產(chǎn)品的需求定義或說明中的任何人員都能從本書中獲得有用的信義一種符合他們功能和使用需要的產(chǎn)品。希望確認(rèn)產(chǎn)品是否滿足業(yè)務(wù)需要的客戶將能更好地理bafd2b98317835f4548c7e257eb13550.doc3求分析過程的重要性。而負(fù)責(zé)監(jiān)督按期完成產(chǎn)品的項(xiàng)目管理者也將學(xué)會(huì)怎樣管理潛在的威脅——需求變更。自己對(duì)開發(fā)過程的理解和想了解需求在軟件成功中扮演的關(guān)鍵角色的任何人都將從本書本書結(jié)構(gòu)Top三大部分。第一部分先介紹了一些基本的需求工程定義和一些優(yōu)秀的需求分析所具有了許多需求開發(fā)和管理的改進(jìn)熟練程度的好方法(良好的習(xí)慣做法)。第4章有助于計(jì)劃怎一些通常與需求相關(guān)的項(xiàng)目風(fēng)險(xiǎn)。分介紹了許多關(guān)于需求開發(fā)的技術(shù)。首先是定義項(xiàng)目的業(yè)務(wù)需求，項(xiàng)目視圖(wision)及涉及的范圍(scope)。接下來的章節(jié)介紹怎樣為項(xiàng)目尋找合適的客戶代表，獲取(elicit)用戶需法。分的主題是需求管理的原則和策略。這部分還特別介紹了處理需求變更和評(píng)價(jià)每項(xiàng)變更相關(guān)的設(shè)計(jì)、代碼等)聯(lián)系起來。第三部分的內(nèi)容包括一些商業(yè)工具的說明，這些工具能增強(qiáng)你管礙，更改舊的傳統(tǒng)做法，把新的知識(shí)付諸實(shí)踐的確不是一件容易的事情。你也許仍想保持原有熟悉(可能并不很有效)的方法，為了幫助你改進(jìn)需求分析，本書的每一章都包括一個(gè)稱一步”的內(nèi)容，它細(xì)致地教你如何將本章所學(xué)的知識(shí)真正開始應(yīng)用于實(shí)踐。我提供了許多帶om從今天就開始，一點(diǎn)一點(diǎn)地逐漸改進(jìn)你的需求分析。與者在嘗試新需求技術(shù)時(shí)是很勉強(qiáng)的。因?yàn)橛幸恍┤送耆恢v理，而與這些不理解同提高。非要在一個(gè)新項(xiàng)目中開始應(yīng)用這種改進(jìn)的需求工程方法。其實(shí)就地改變控制過程就是始作系統(tǒng)的影響分析，創(chuàng)建跟蹤能力矩陣，從而把新的需求與相應(yīng)的設(shè)計(jì)、代碼、測(cè)試用例都起來了。為現(xiàn)存系統(tǒng)回頭重新編寫整個(gè)系統(tǒng)的需求規(guī)格說明是不現(xiàn)實(shí)的。但你可以寫一個(gè)更加并且也可以為你將新技術(shù)應(yīng)用于下一個(gè)主要項(xiàng)目奠定基礎(chǔ)。bafd2b98317835f4548c7e257eb13550.doc4做出高質(zhì)量而并非完美的需求分析，這使得你能在一個(gè)可接受的風(fēng)險(xiǎn)限度上致謝Top謝那些花費(fèi)時(shí)間、精力審閱我的手稿并提供了許多改進(jìn)建議的人們。特別要感謝凱瑞 rapiddescopingphase紹的一些技術(shù)將它改稱為：“受控的縮小范圍階段” (controlleddescopingphase)。分析所需的實(shí)用方法。如果你認(rèn)為這能有助于工作或不能，請(qǐng)你告訴我：kwiegers@。bafd2b98317835f4548c7e257eb13550.doc5軟件需求：是什么和為什么第一章基本的軟件需求Top能在婚姻狀況改變時(shí)才能更改姓名?！盤hil道。統(tǒng)，并且我還要處理職員系統(tǒng)的一些需求變更請(qǐng)求”(傳來翻閱稿紙的聲音)?！芭叮@兒還有別我只可能在月底前修改好，一周內(nèi)不行，很抱歉。下次若有類似情況，請(qǐng)?jiān)缫恍└嬖V我并把們寫下來?！眗kleMaria時(shí)改變某個(gè)人的名字，那這些都不會(huì)發(fā)生。因此你不能因未猜出你的想法(需求)就責(zé)備我?！毙邪桑俊眰冞帧逼饋?。軟件項(xiàng)目中百分之四十至百分之六十的問題都是在需求分析階段埋下的“禍根” Leffingwell許多組織仍在那些基本的項(xiàng)目功能上采用一些不合規(guī)范的方法，這樣導(dǎo)bafd2b98317835f4548c7e257eb13550.doc6致的后果便是一條鴻溝(期望差異)——開發(fā)者所想開發(fā)的與用戶所想得到的存在著巨大期望差工程中，所有的風(fēng)險(xiǎn)承擔(dān)者(stakeholder)都感興趣的就是需求分析階段。這些風(fēng)險(xiǎn)承擔(dān)者包括客戶、用戶、業(yè)務(wù)或需求分析員(負(fù)責(zé)收集客戶需求并編寫文檔，以及負(fù)責(zé)客戶與開發(fā)之間聯(lián)系溝通的人)、開發(fā)人員、測(cè)試人員、用戶文檔編寫者、項(xiàng)目管理者和客戶管理者。這出很出色的產(chǎn)品，同時(shí)會(huì)使客戶感到滿意，開發(fā)者也倍感滿足、充若處理不好，則會(huì)導(dǎo)致誤解、挫折、障礙以及潛在質(zhì)量和業(yè)務(wù)價(jià)值上的威脅。因?yàn)樾枨蠓治龅炝塑浖こ毯晚?xiàng)目管理的基礎(chǔ)，所以所有風(fēng)險(xiǎn)承擔(dān)者最好是采用下面提供的有效的需求分析過令了解軟件需求開發(fā)中使用的一些關(guān)鍵名詞。令警惕在軟件項(xiàng)目中可能出現(xiàn)的與需求相關(guān)的一些問題。令知道優(yōu)秀的需求規(guī)格說明應(yīng)該具有的特點(diǎn)。令明白需求開發(fā)與需求管理之間的區(qū)別。軟件需求的定義Top在的一個(gè)問題就是缺乏統(tǒng)一定義的名詞術(shù)語來描述我們的工作。客戶所定義的“需者似乎是一個(gè)較高層次的產(chǎn)品概念。而開發(fā)人員所說的“需求”對(duì)用戶來說又像是詳細(xì)IEEEIEEE軟件工程標(biāo)準(zhǔn)詞匯表(1997年)中定義需求為：(1)用戶解決問題或達(dá)到目標(biāo)所需的條件或權(quán)能(Capability)。(2)系統(tǒng)或系統(tǒng)部件要滿足合同、標(biāo)準(zhǔn)、規(guī)范或其它正式規(guī)定文檔所需(3)一種反映上面(1)或(2)所描述的條件或權(quán)能的文檔說明。需求”的解釋IEEE公布的定義包括從用戶角度(系統(tǒng)的外部行為)，以及從開發(fā)者角度(一些內(nèi)部的問題是一定要編寫需求文檔。我曾經(jīng)目睹過一個(gè)項(xiàng)目中途更換了幾乎所有的開發(fā)戶被迫又與新的需求分析者坐到一起。分析人員說：“我們想與你談?wù)勀愕男枨?。”客戶的寫成文檔，因此新的分析人員不得不從頭做起。所以事實(shí)上你只有一堆郵件、貼條、會(huì)談過另外一種定義認(rèn)為需求是“用戶所需要的并能觸發(fā)一個(gè)程序或系統(tǒng)開發(fā)工作的說明”(Jones于用戶的特點(diǎn)、功能、屬性等”。這些定義強(qiáng)調(diào)的都是產(chǎn)品是什么樣的，而并非產(chǎn)品是怎樣設(shè)bafd2b98317835f4548c7e257eb13550.doc7計(jì)、構(gòu)造的。而下面的定義則從用戶需要進(jìn)一步轉(zhuǎn)移到了系統(tǒng)特性(Sommerville和Sawyer性，正的“需求”實(shí)際上在人們的腦海中。任何文檔形式的需求(例如：需求規(guī)格說明)僅是一個(gè)模型，一種敘述(Lawrence1998)。我們需要確保所有項(xiàng)目風(fēng)險(xiǎn)承擔(dān)者在描述需求的那些名詞的理需求的層次Top明。括三個(gè)不同的層次——業(yè)務(wù)需求、用戶需求和功能需求——也包括非功能需求。業(yè)務(wù)需求(businessrequirement)反映了組織機(jī)構(gòu)或客戶對(duì)系統(tǒng)、產(chǎn)品高層次的目標(biāo)要求，它們?cè)谂c范圍文檔中予以說明。用戶需求(userrequirement)文檔描述了用戶使用產(chǎn)品必須要完成的任務(wù)，這在使用實(shí)例(usecase)文檔或方案腳本(scenario)說明中予以說明。功能需求functionalrequirement軟件功能，使得用戶能完成他們的任務(wù)，從。在軟件需求規(guī)格說明(softwarerequirementsspecification簡(jiǎn)稱“SRS”)中說明的功能需了軟件系統(tǒng)所應(yīng)具有的外部行為。軟件需求規(guī)格說明在開發(fā)、測(cè)試、質(zhì)量保證、項(xiàng)目管因?yàn)榱硗庖恍┛赡軐儆谲浖考?。bafd2b98317835f4548c7e257eb13550.doc8求的補(bǔ)充，軟件需求規(guī)格說明還應(yīng)包括非功能需求，它描述了系統(tǒng)展現(xiàn)給用戶的行實(shí)現(xiàn)的約束條件及質(zhì)量屬性。所謂約束是指對(duì)開發(fā)人員在軟件產(chǎn)品設(shè)計(jì)和構(gòu)造上所具有。質(zhì)量屬性是通過多種角度對(duì)產(chǎn)品的特點(diǎn)進(jìn)行描述，從而反映產(chǎn)品功能，多角度描述產(chǎn)發(fā)人員都極為重要。戶需求可能是“找出文檔中的拼寫錯(cuò)誤并通過一個(gè)提供的替換項(xiàng)列表來供選擇替換拼錯(cuò)的詞”。實(shí)現(xiàn)整個(gè)文檔范圍的替換。分析人員會(huì)確定軟件的業(yè)務(wù)需求，這有利于公司操作更加高效(對(duì)信息系統(tǒng)而言)或具有很強(qiáng)的市場(chǎng)競(jìng)爭(zhēng)力(對(duì)商業(yè)軟件產(chǎn)品而言)。所有的用戶需求必須與業(yè)務(wù)需求一致。用許需求分析者能從中得到一些功能需求以滿足用戶使用產(chǎn)品來完成其任務(wù)，而開發(fā)人員則求來設(shè)計(jì)如何實(shí)現(xiàn)必須的功能。以發(fā)現(xiàn)，需求并未包括設(shè)計(jì)細(xì)節(jié)、實(shí)現(xiàn)細(xì)節(jié)、項(xiàng)目計(jì)劃信息或測(cè)試信息。需求與產(chǎn)品及移植到支撐環(huán)境的需求。盡管這些需求對(duì)項(xiàng)目成功也至關(guān)重要，但它們并非本書所每個(gè)項(xiàng)目都有需求TopofSoftwareEngineering中充分說明了需求過程在軟件項(xiàng)目中扮演的重要角色：確說明開發(fā)什么。最為困難的概念性工作便是包括所有面向用戶、面向機(jī)器和其它軟件系統(tǒng)的接口。同時(shí)終給系統(tǒng)帶來極大損害的部分，而且以后再對(duì)它進(jìn)行修改也統(tǒng)的某一部分的產(chǎn)品是顯而易見的。但是對(duì)于我們開發(fā)人員來說，并沒有編寫出客戶認(rèn)返工這種不可避免的后果，而重新編制代碼的代價(jià)遠(yuǎn)遠(yuǎn)超過重寫一份需求文檔的代價(jià)。有這個(gè)功能。結(jié)果這個(gè)小組只好手工抄寫源代碼文檔以供代碼檢查。這說明如果我們沒有編寫bafd2b98317835f4548c7e257eb13550.doc9況，我曾為一個(gè)要集成到“商業(yè)錯(cuò)誤跟蹤系統(tǒng)”中的簡(jiǎn)單電子郵件界面寫了一頁需求清晰地實(shí)現(xiàn)了所有必需功能，而且未發(fā)現(xiàn)任何錯(cuò)誤。什么情況將會(huì)導(dǎo)致好的群體發(fā)生不合格的需求說明Top程的項(xiàng)目隊(duì)伍將自食其果。需求工程中的缺陷將給項(xiàng)目成功帶來極大風(fēng)險(xiǎn)，這里成功”是指推出的產(chǎn)品能以合理的價(jià)格、及時(shí)地完成并在功能、質(zhì)量上完全滿足用戶的期望。令包含的用戶數(shù)不多將導(dǎo)致無法接受的產(chǎn)品。令用戶需求的擴(kuò)展將帶來過度的耗費(fèi)和降低產(chǎn)品的質(zhì)量。令模棱兩可的需求說明可能導(dǎo)致時(shí)間浪費(fèi)和返工。令用戶增加一些不必要的特性和開發(fā)人員“畫蛇添足(gold-plating)”的追求。令過分精簡(jiǎn)的需求說明以致遺漏某些關(guān)鍵需求。令忽略某一部分用戶類的需求將導(dǎo)致眾多客戶的不滿。完善的需求說明使得項(xiàng)目計(jì)劃和跟蹤等無法準(zhǔn)確進(jìn)行。戶參與明白為什么收集需求和確保需求質(zhì)量需花費(fèi)那么多功夫，開發(fā)人員可能也不重視用的不斷擴(kuò)展中若不斷地補(bǔ)充需求，項(xiàng)目就越變?cè)烬嫶笠灾鲁^其計(jì)劃安排及預(yù)算范圍。計(jì)劃并不總規(guī)模與復(fù)雜性的實(shí)際情況、風(fēng)險(xiǎn)、開發(fā)生產(chǎn)率及需求變更情況，這使得問題更難解題根源在于用戶對(duì)需求的改變和開發(fā)者對(duì)新需求所作的修改。更范圍的不斷擴(kuò)展，必須一開始就對(duì)項(xiàng)目視圖、范圍、目標(biāo)、約束限制和成功標(biāo)準(zhǔn)給說明，并將此說明作為評(píng)價(jià)需求變更和新特性的參照框架。說明中包括了對(duì)每種變更進(jìn)行變因素分析的變更控制過程，這也將有助于所有風(fēng)險(xiǎn)承擔(dān)者明白業(yè)務(wù)決策的合理性，為何進(jìn)行發(fā)中不斷延續(xù)的變更會(huì)使其整體結(jié)構(gòu)日漸紊亂，補(bǔ)丁代碼也使得整個(gè)程序難以理解和維可的需求可是需求規(guī)格說明中最為可怕的問題(Lawrence1996)。它的一層含義是指諸多讀者對(duì)讀者能用不止一個(gè)方式來解釋某個(gè)需求說明。bafd2b98317835f4548c7e257eb13550.doc10并且使測(cè)試者與開發(fā)者所期望的也不一致。一位系統(tǒng)測(cè)試人員曾告訴我，她所在的測(cè)試組經(jīng)常測(cè)試用例和重做許多測(cè)試。兩可的需求帶來不可避免的后果便是返工——重做一些你認(rèn)為已做好的事情。返工會(huì)耗費(fèi)四十，而百分之七十至八十五的重做是由于需求方面的錯(cuò)誤所導(dǎo)致的 (leffingwell1997)。想像一下如果你能減少一半的返工會(huì)是怎樣的情況？你能更快地開發(fā)出產(chǎn)求的一種方法是組織好負(fù)責(zé)從不同角度審查需求的隊(duì)伍。僅僅簡(jiǎn)單瀏覽一下需大。其它檢測(cè)模棱兩可的技術(shù)由Gause和Weinberg(1989)給予了介紹，本章的后面也有“畫蛇添足”是指開發(fā)人員力圖增加一些“用戶欣賞”但需求規(guī)格說明中并未涉及的新功能為客戶構(gòu)思方案和出于他們考慮的一些創(chuàng)新思路，具體確定哪些功能是要在客戶所需與開的“來龍去脈”，這樣使得需求分析過程始終是注重那些能使用戶完成他們業(yè)務(wù)任務(wù)的規(guī)格說明之后再完成需求說明。這種方法可能適合于尖端研究性的產(chǎn)品或需求本身就十分靈活的情況 (McConnell1996)。但在大多數(shù)情況下，這會(huì)給開發(fā)人員帶來挫折(使他們?cè)诓徽_的假設(shè)前提下和極其有限的指導(dǎo)下工作)，也會(huì)給客戶帶來煩惱(他們無法得到他們所設(shè)想的產(chǎn)品)。忽略了用戶分類“上述是我對(duì)新產(chǎn)品的看法，好，現(xiàn)在你能告訴我你什么時(shí)候能完成嗎？”許多開發(fā)人員都遇。對(duì)需求分析缺乏理解會(huì)導(dǎo)致過分樂觀的估計(jì)，而當(dāng)不可避免的超支發(fā)生時(shí)，會(huì)帶來頗需求；與用戶交流不夠；質(zhì)量低下的需求規(guī)格說明和不完善的需求分析(Davisbafd2b98317835f4548c7e257eb13550.doc11計(jì)時(shí)間要求提問的正確響應(yīng)是“等我真正明白你的需求時(shí)，我就會(huì)來告訴你”。基于不充 內(nèi)完成)。通常未經(jīng)準(zhǔn)備的估計(jì)是作為一種猜測(cè)而給出的，聽者卻認(rèn)為是一種承諾。因此我們要盡期的期望并堅(jiān)持一貫如此。高質(zhì)量的需求過程帶來的好處Top程管理的組織能獲得多方面的好處。也許最大的好處是在開發(fā)后期和整個(gè)維護(hù)階段的返工重做大大減少了。Boehm(1981)發(fā)現(xiàn)要改正在產(chǎn)品付諸應(yīng)用后所發(fā)現(xiàn)的一個(gè)需求方間就會(huì)導(dǎo)致產(chǎn)品開發(fā)推遲多少時(shí)間。從傳統(tǒng)的質(zhì)量成本角度分析來看，揭示了需求及其它早期質(zhì)量工作的重要性(Wiegers1996a)。。由于收集需求能使開發(fā)小組更好地了解其市場(chǎng)，而市場(chǎng)因素是任何項(xiàng)目成功的一個(gè)關(guān)鍵因產(chǎn)品開發(fā)前了解這些比在遭到客戶批評(píng)后才意識(shí)到要節(jié)約很多成本。讓用戶積極參與需求收一些“華麗”的特性，你能避免在無用功能上白耗精力，并且用戶的參與能彌補(bǔ)用戶期望獲得和開發(fā)者實(shí)際開發(fā)之間的“鴻溝(期望差異)”。選定系統(tǒng)的需求明確地分配到各軟件子系統(tǒng)，強(qiáng)調(diào)采用產(chǎn)品工程的系統(tǒng)方法。這樣能簡(jiǎn)化硬集成，也能確保軟硬件系統(tǒng)功能匹配適當(dāng)。而有效的變更控制和影響分析過程也能降低需求優(yōu)秀需求具有的特性TopDavis1993；IEEE1998)。讓風(fēng)險(xiǎn)承擔(dān)者從不同角度對(duì)SRS需求說明進(jìn)行認(rèn)真評(píng)地確定哪些需求確實(shí)是需要的。只要你在編寫、評(píng)審需求時(shí)把這些特點(diǎn)記在心中，你會(huì)找到一些需求陳述中的問題并改進(jìn)之。需求都必須將所要實(shí)現(xiàn)的功能描述清楚，以使開發(fā)人員獲得設(shè)計(jì)和實(shí)現(xiàn)這些功能所需的需求都必須準(zhǔn)確地陳述其要開發(fā)出的功能性。判斷正確的參考是需求的來源，如客戶或系統(tǒng)需求規(guī)格說明。若軟件需求與對(duì)應(yīng)的系統(tǒng)需求相抵觸則是不正確的。只有用戶代表才能bafd2b98317835f4548c7e257eb13550.doc12項(xiàng)需求都必需是在已知系統(tǒng)和環(huán)境的權(quán)能和限制范圍內(nèi)可以實(shí)施的。為避免不可行的需求，最好在獲取(elicitation)需求(收集需求)過程中始終有一位軟件工程小組的組員與需求分慮市場(chǎng)的人員在一起工作，由他來負(fù)責(zé)技術(shù)可行性上的檢查。需求都應(yīng)把客戶真正所需要的和最終系統(tǒng)所需遵從的標(biāo)準(zhǔn)記錄下來?！氨匾浴币部梢悦宽?xiàng)需求都是用來授權(quán)你編寫文檔的“根源”。要使每項(xiàng)需求都能回溯至某項(xiàng)客戶的輸入，先級(jí)求、特性或使用實(shí)例分配一個(gè)實(shí)施優(yōu)先級(jí)以指明它在特定產(chǎn)品中所占的分量。如果把項(xiàng)需求用簡(jiǎn)潔明了的用戶性的語言表達(dá)出來。避免二義性的有效方法包括對(duì)需求文檔的正規(guī)下每項(xiàng)需求是否能通過設(shè)計(jì)測(cè)試用例或其它的驗(yàn)證方法，如用演示、檢測(cè)等來確定產(chǎn)品求也是不可驗(yàn)證的。必要的需求信息。遺漏需求將很難查出。注重用戶的任務(wù)而不是系統(tǒng)的功能將有TBD。一致性是指與其它軟件需求或高層(系統(tǒng)，業(yè)務(wù))需求不相矛盾。在開發(fā)前必須解決所有需求。另外，使用目錄表、索引和相互參照列表方法將使軟件需求規(guī)格說明更容易修改。每項(xiàng)軟件需求與它的根源和設(shè)計(jì)元素、源代碼、測(cè)試用例之間建立起鏈接鏈，這種可跟項(xiàng)需求以一種結(jié)構(gòu)化的，粒度好(fine-grained)的方式編寫并單獨(dú)標(biāo)明，而不是大段bafd2b98317835f4548c7e257eb13550.doc13需求開發(fā)需求開發(fā)分析編寫規(guī)格說明需求的開發(fā)和管理Top需求中名詞術(shù)語的混淆將導(dǎo)致對(duì)科目(規(guī)范)(discipline)叫法的不一致。一些作者把整個(gè)究領(lǐng)域劃分為需求開發(fā)(本書的第二部分)和需求管理(本書第三部分)兩部分更合適，如圖1-2需求工程需求管理驗(yàn)證圖1-2需求工程域的層次分解示意圖需求開發(fā)可進(jìn)一步分為：?jiǎn)栴}獲取(elicitation)、分析(analysis)、編寫規(guī)格說明 (specification)和驗(yàn)證(verification)四個(gè)階段(Thayer和Dorfman1997)。這些子項(xiàng)包括品中需求收集、評(píng)價(jià)、編寫文檔等所有活動(dòng)。需求開發(fā)活動(dòng)包括以下幾個(gè)方面：令確定產(chǎn)品所期望的用戶類。獲取每個(gè)用戶類的需求。令了解實(shí)際用戶任務(wù)和目標(biāo)以及這些任務(wù)所支持的業(yè)務(wù)需求。令分析源于用戶的信息以區(qū)別用戶任務(wù)需求、功能需求、業(yè)務(wù)規(guī)則、質(zhì)量屬性、建議解決方令將系統(tǒng)級(jí)的需求分為幾個(gè)子系統(tǒng)，并將需求中的一部份分配給軟件組件。了解相關(guān)質(zhì)量屬性的重要性。商討實(shí)施優(yōu)先級(jí)的劃分。令將所收集的用戶需求編寫成規(guī)格說明和模型。。需求管理需要“建立并維護(hù)在軟件工程中同客戶達(dá)成的契約”(CMU/SEI1995)。這種契約都編寫的需求規(guī)格說明與模型中?？蛻舻慕邮軆H是需求成功的一半，開發(fā)人員也必須能夠接受令定義需求基線(迅速制定需求文檔的主體)。令評(píng)審提出的需求變更、評(píng)估每項(xiàng)變更的可能影響從而決定是否實(shí)施它。令以一種可控制的方式將需求變更融入到項(xiàng)目中。前的項(xiàng)目計(jì)劃與需求一致。令基于估計(jì)變更需求所產(chǎn)生影響的基礎(chǔ)上，協(xié)商新的承諾(約定)。bafd2b98317835f4548c7e257eb13550.doc14需需求開發(fā)市場(chǎng)，客戶，管理 項(xiàng)目變更項(xiàng)目環(huán)境需求變更需需求開發(fā)市場(chǎng)，客戶，管理 項(xiàng)目變更項(xiàng)目環(huán)境需求變更應(yīng)的設(shè)計(jì)、源代碼和測(cè)試用例聯(lián)系起來以實(shí)現(xiàn)跟蹤。令在整個(gè)項(xiàng)目過程中跟蹤需求狀態(tài)及其變更情況。市場(chǎng)客戶管理求求析編寫文檔評(píng)審，商議基準(zhǔn)需求說明需求管理修正后基線修正后基線需需求變更過程圖1-3需求開發(fā)與需求管理之間的界限令記錄你在當(dāng)前項(xiàng)目或以前項(xiàng)目中所遇到的與需求相關(guān)的問題。指明每一個(gè)是需求令與你的組員和其他風(fēng)險(xiǎn)承擔(dān)者(客戶，市場(chǎng)調(diào)查人員，項(xiàng)目管理者)一起討論當(dāng)決這些困難，必須正視它，大家是否為此做好準(zhǔn)備了呢？令整理出對(duì)整個(gè)項(xiàng)目人員一天訓(xùn)練用的軟件需求課程，人員要包括重要的客戶，市管理人員。訓(xùn)練是一種有效的團(tuán)隊(duì)學(xué)習(xí)與合作的方法。大家將會(huì)在訓(xùn)練bafd2b98317835f4548c7e257eb13550.doc15第2章客戶的需求觀TopContoso制藥公司的高級(jí)管理長(zhǎng)官Gerhard,會(huì)見Contoso公司的信息系統(tǒng)開發(fā)小組的新管理員Cynthia?！拔覀冃枰⒁惶谆瘜W(xué)制品跟蹤信息系統(tǒng)”，Gerhard說道?！霸撓到y(tǒng)可以記錄在庫(kù)房或某個(gè)實(shí)驗(yàn)室中已有的化學(xué)藥品，這樣，化學(xué)專家可以直接從樓下的某人那里拿到所需的藥品，而不必再買一瓶新的。另外，衛(wèi)生保健部門也得為聯(lián)邦政府寫些關(guān)于化學(xué)藥品的使用報(bào)告。你們小組能在五個(gè)月內(nèi)開發(fā)出該系統(tǒng)來嗎？”“我已經(jīng)明白這個(gè)項(xiàng)目的重要性了，Gerhard”Cynthia說道。“但在我制定計(jì)劃前，我們必須收集一些系統(tǒng)的需求?！盙erhard覺得很奇怪“你的意思是什么？我不是剛告訴你我的需求了嗎？”“實(shí)際上，你只說明了整個(gè)項(xiàng)目的概念與目標(biāo)”，Cynthia解釋道?！斑@些高層次的業(yè)務(wù)需求并不能為我們提供足夠的詳細(xì)信息以確定究竟要開發(fā)什么樣的軟件，以及需要多長(zhǎng)時(shí)間。我需要一些分析人員與一些知道系統(tǒng)使用要求的化學(xué)專家進(jìn)行討論，然后才能真正明白達(dá)到業(yè)務(wù)目標(biāo)所需的各種功能和用戶的要求。我們甚至并不需要開發(fā)一個(gè)新的軟件系統(tǒng)，這樣可節(jié)省許多錢?！盙erhard此前還從未遇到過類似這位系統(tǒng)開發(fā)人員的看法?！澳切┗瘜W(xué)專家都非常忙”他堅(jiān)持道，“他們沒有時(shí)間與你們?cè)敿?xì)討論各種細(xì)節(jié)，你不能讓你的手下的人說明嗎？”Cynthia盡力解釋從使用新系統(tǒng)的用戶處收集需求的合理性。“如果我們只是憑空猜想用戶要求，結(jié)果不會(huì)令人滿意。我們只是軟件開發(fā)人員，而并非化學(xué)專家。我們并不能真正明白化學(xué)專家們需要這個(gè)化學(xué)制品跟蹤系統(tǒng)做些什么。我曾經(jīng)嘗試過，未真正明白這些問題就匆忙開始編碼，結(jié)果沒有人對(duì)產(chǎn)品滿意。”“行了，行了，我們沒有那么多時(shí)間”Gerhard堅(jiān)持道?！拔襾砀嬖V你需求，請(qǐng)馬上開始開發(fā)系統(tǒng)。隨時(shí)將你們的進(jìn)展情況告訴我?！毕襁@樣的對(duì)話經(jīng)常出現(xiàn)在軟件開發(fā)過程中。要求開發(fā)一個(gè)新信息系統(tǒng)的客戶通常并不懂得從系統(tǒng)的實(shí)際用戶處得到信息的重要性。市場(chǎng)人員在有了一個(gè)很不錯(cuò)的新產(chǎn)品想法后，也就自認(rèn)為能充分代表產(chǎn)品用戶的興趣要求。然而，直接從產(chǎn)品的實(shí)際用戶處收集需求有著不可替代的必要性。通過對(duì)8380個(gè)項(xiàng)目的調(diào)查發(fā)現(xiàn)，導(dǎo)致項(xiàng)目失敗的最主要兩個(gè)原因是缺乏用戶參與和不完整的需求以及不完整的規(guī)格說明(Standish1995)。引起需求問題的一部分原因是對(duì)不同層次需求(業(yè)務(wù)、用戶、功能)的混淆所致。Gerhard說明了一些業(yè)務(wù)需求，但他并不能描述用戶需求，因?yàn)樗⒉皇恰盎瘜W(xué)制品跟蹤系統(tǒng)”的實(shí)際使用者。只有實(shí)際用戶才能描述他們要用此系統(tǒng)必須完成的任務(wù)。但他們又不能指出完成這些任務(wù)所有具體的功能需求。本章說明客戶與開發(fā)人員之間的關(guān)系，它對(duì)軟件項(xiàng)目開發(fā)的成功極為關(guān)鍵。我建議寫一份軟件客戶需求權(quán)利書和相應(yīng)的軟件客戶需求義務(wù)書，以強(qiáng)調(diào)客戶(和實(shí)際用戶)參與需求開發(fā)過程的重要性。bafd2b98317835f4548c7e257eb13550.doc16誰是客戶？Top通常意義下，客戶是指直接或間接從產(chǎn)品中獲得利益的個(gè)人或組織。軟件客戶包括提出要求、支付款項(xiàng)、選擇、具體說明或使用軟件產(chǎn)品的項(xiàng)目風(fēng)險(xiǎn)承擔(dān)者(stakeholder)或是獲得產(chǎn)品所產(chǎn)生的結(jié)果的人。Gerhard代表支付、采購(gòu)(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)險(xiǎn)承擔(dān)者或從系統(tǒng)中取得結(jié)果的用戶他們所要求的目標(biāo)。業(yè)務(wù)需求為后繼工作建立了一個(gè)指導(dǎo)性的框架。其它任何的說明都應(yīng)遵從業(yè)務(wù)需求的規(guī)定，然而業(yè)務(wù)需求并不能為開發(fā)人員提供許多開發(fā)所需的細(xì)節(jié)說明。下一層需求——用戶需求——必須從使用產(chǎn)品的用戶處收集。因此這些用戶(通常稱作最終用戶)，構(gòu)成了另一種軟件客戶。他們能說清楚要使用該產(chǎn)品完成什么任務(wù)和一些非功能性的特性，而這些特性會(huì)對(duì)使用戶很好接收具有該特點(diǎn)的產(chǎn)品是重要的。說明業(yè)務(wù)需求的客戶有時(shí)將試圖替代用戶說話，但通常他們根本無法準(zhǔn)確說明用戶需求。因?yàn)閷?duì)信息系統(tǒng)、合同(contract)或是客戶應(yīng)用程序的開發(fā)、業(yè)務(wù)需求應(yīng)來自風(fēng)險(xiǎn)承擔(dān)者，而用戶需求則應(yīng)來自產(chǎn)品的真正使用操作者。不幸的是，這兩種客戶可能都覺得他們沒有時(shí)間與(收集、分析與編寫需求說明)需求分析者討論。有時(shí)客戶還希望分析人員或開發(fā)人員無須討論和編寫文檔就能說出用戶的需求。除非遇到的需求極為簡(jiǎn)單，否則不能這樣做。如果你的組織關(guān)注軟件的成功，那必須要花上數(shù)天時(shí)間來消除需求中模糊不清的地方和一些使程序人員感到困惑的方面。商業(yè)軟件開發(fā)的情況有些不同，因?yàn)橥ǔＦ淇蛻艟褪怯脩?。正如市?chǎng)部這類客戶代理，可能想確定究竟軟件產(chǎn)品的購(gòu)買者會(huì)喜歡什么。但即使是商業(yè)軟件，也應(yīng)該讓實(shí)際用戶參與到收集需求的過程中來 (第7章將談及)。如果你不這樣作，那產(chǎn)品很可能會(huì)因缺乏足夠用戶提供的信息而出現(xiàn)不少隱患?？蛻襞c開發(fā)人員之間的合作關(guān)系Top優(yōu)秀的軟件產(chǎn)品是建立在優(yōu)秀的需求基礎(chǔ)之上的。而高質(zhì)量的需求來源于客戶與開發(fā)人員之間有效的交流與合作。但通常，開發(fā)人員與客戶或客戶代理人，如市場(chǎng)人員間的關(guān)系反而會(huì)成為一種對(duì)立關(guān)系。雙方的管理者都只想自己的利益而擱置用戶提供的需求從而產(chǎn)生摩擦，在這種情況下，不會(huì)給雙方帶來一點(diǎn)益只有當(dāng)雙方參與者都明白要成功自己需要什么，同時(shí)也應(yīng)知道要成功合作方需要什么時(shí)，才能建立起一種合作關(guān)系。由于項(xiàng)目壓力與日漸增，所有風(fēng)險(xiǎn)承擔(dān)者有著一個(gè)共同的目標(biāo)這一點(diǎn)容易被遺忘。其實(shí)大家都想開發(fā)出一個(gè)既能實(shí)現(xiàn)商業(yè)價(jià)值，又能滿足用戶需要，還能使開發(fā)者感到滿足的優(yōu)秀軟件產(chǎn)軟件客戶需求權(quán)利書列出了十條關(guān)于客戶在項(xiàng)目需求工程實(shí)施中與分析人員、開發(fā)人員交流時(shí)的合法要求。每一項(xiàng)權(quán)利都對(duì)應(yīng)著軟件開發(fā)人員、分析人員的義務(wù)。而軟件客戶需求義務(wù)書也列出了十條關(guān)于客戶在需求過程中應(yīng)承擔(dān)的義務(wù)。如果愿意，可以將其作為開發(fā)人員的權(quán)利書。軟件客戶需求權(quán)利書客戶有如下權(quán)利：1.要求分析人員使用符合客戶語言習(xí)慣的表達(dá)。2.要求分析人員了解客戶系統(tǒng)的業(yè)務(wù)及目標(biāo)。3.要求分析人員組織需求獲取期間所介紹的信息，并編寫軟件需求規(guī)格說明。bafd2b98317835f4548c7e257eb13550.doc174.要求開發(fā)人員對(duì)需求過程中所產(chǎn)生的工作結(jié)果進(jìn)行解釋說明。5.要求開發(fā)人員在整個(gè)交流過程中保持和維護(hù)一種合作的職業(yè)態(tài)度。6.要求開發(fā)人員對(duì)產(chǎn)品的實(shí)現(xiàn)及需求都要提供建議，拿出主意。7.描述產(chǎn)品使其具有易用、好用的特性。8.可以調(diào)整需求，允許重用已有的軟件組件。9.當(dāng)需要對(duì)需求進(jìn)行變更時(shí)，對(duì)成本、影響、得失(trade-off)有個(gè)真實(shí)可信的評(píng)估。10.獲得滿足客戶功能和質(zhì)量要求的系統(tǒng)，并且這些要求是得到開發(fā)人員同意的。軟件客戶需求義務(wù)書客戶有下列義務(wù)：1.給分析人員講解業(yè)務(wù)及說明業(yè)務(wù)方面的術(shù)語等專業(yè)問題。2.抽出時(shí)間清楚地說明需求并不斷完善。3.當(dāng)說明系統(tǒng)需求時(shí)，力求準(zhǔn)確詳細(xì)。4.需要時(shí)要及時(shí)對(duì)需求做出決策。5.要尊重開發(fā)人員的成本估算和對(duì)需求的可行性分析。6.對(duì)單項(xiàng)需求、系統(tǒng)特性或使用實(shí)例劃分優(yōu)先級(jí)。7.評(píng)審需求文檔和原型。8.一旦知道要對(duì)項(xiàng)目需求進(jìn)行變更，要馬上與開發(fā)人員聯(lián)系。9.在要求需求變更時(shí)，應(yīng)遵照開發(fā)組織確定的工作過程來處理。10.尊重需求工程中開發(fā)人員采用的流程(過程)。些權(quán)利和義務(wù)可以直接應(yīng)用于客戶。這也適用于那些有合作為項(xiàng)目計(jì)劃的一部分，客戶和開發(fā)人員應(yīng)評(píng)審上述兩張列表并達(dá)成共識(shí)。一些很忙的客戶可能不愿意積極參與需求過程(也即，他們不太接受義務(wù)書#2)，而缺少客戶參與將很可能導(dǎo)致不理想的產(chǎn)品。故一定要確保需求開發(fā)中的主要參與者都了解并接受他們的義務(wù)。如果遇到分歧，通過協(xié)商以達(dá)成對(duì)各自義務(wù)的相互理解，這樣能減少今后的摩擦(如一方要求而另一方不愿意或不能滿足要求)。軟件客戶需求權(quán)利書Top權(quán)利#1：要求分析人員使用符合客戶語言習(xí)慣的表達(dá)需求討論應(yīng)集中于業(yè)務(wù)需要和任務(wù)，故要使用業(yè)務(wù)術(shù)語，你應(yīng)將其教給分析人員，而你不一定要懂得計(jì)算機(jī)的行業(yè)術(shù)語。權(quán)利#2：要求分析人員了解客戶的業(yè)務(wù)及目標(biāo)通過與用戶交流來獲取用戶需求、分析人員才能更好地了解你的業(yè)務(wù)任務(wù)和怎樣才能使產(chǎn)品更好地滿足你的需要。這將有助于開發(fā)人員設(shè)計(jì)出真正滿足你的需要并達(dá)到你期望的優(yōu)秀軟件。為幫助開發(fā)人員和分析人員，可以考慮邀請(qǐng)他們觀察你或你的同事是怎樣工作的。如果新開發(fā)系統(tǒng)是用來替代已有的bafd2b98317835f4548c7e257eb13550.doc18系統(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ī)格說明便在開發(fā)人員和客戶之間針對(duì)要開發(fā)的產(chǎn)品內(nèi)容達(dá)成了協(xié)議。SRS可以用一種你認(rèn)為易于翻閱和理解的方式組織編寫。要評(píng)審編寫出的規(guī)格說明以確保它們準(zhǔn)確而完整地表達(dá)了你的需求。一份高質(zhì)量的軟件需求規(guī)格說明能有助于開發(fā)人員開發(fā)出真正需要的產(chǎn)品。權(quán)利#4：要求得到需求工作結(jié)果的解釋說明分析人員可能采用了多種圖表作為文字性軟件需求規(guī)格說明的補(bǔ)充。因?yàn)槿绻ぷ髁鞒虉D那樣的圖表能很清楚地描述出系統(tǒng)行為的某些方面。所以需求說明中的各種圖表有著極高的價(jià)值。雖然它們不太難于理解，但是你很可能對(duì)此并不熟悉。因此可以要求分析人員解釋說明每張圖表的作用或其它的需求開發(fā)工作結(jié)果和符號(hào)的意義，及怎樣檢查圖表有無錯(cuò)誤及不一致等。權(quán)利#5:要求開發(fā)人員尊重你的意見如果用戶與開發(fā)人員之間不能相互理解，那關(guān)于需求的討論將會(huì)有障礙，共同合作能使大家“兼聽則明”。參與需求開發(fā)過程的客戶有權(quán)要求開發(fā)人員尊重他們并珍惜他們?yōu)轫?xiàng)目成功所付出的時(shí)間。同樣，客戶也應(yīng)對(duì)開發(fā)人員為項(xiàng)目成功這一共同目標(biāo)所作出的努力表示尊重與感激。權(quán)利#6：要求開發(fā)人員對(duì)需求及產(chǎn)品實(shí)施提供建議，拿出主意通常，客戶所說的“需求”已是一種實(shí)際可能的實(shí)施解決方案，分析人員將盡力從這些解決方法中了解真正的業(yè)務(wù)及其需求，同時(shí)還應(yīng)找出已有系統(tǒng)不適合當(dāng)前業(yè)務(wù)之處，以確保產(chǎn)品不會(huì)無效或低效。在徹底弄清業(yè)務(wù)領(lǐng)域內(nèi)的事情后，分析人員有時(shí)就能提出相當(dāng)好的改進(jìn)方法。有經(jīng)驗(yàn)且富有創(chuàng)造力的分析人員還能提出增加一些用戶并未發(fā)現(xiàn)的很有價(jià)值的系統(tǒng)特性。權(quán)利#7：描述產(chǎn)品易使用的特性你可以要求分析人員在實(shí)現(xiàn)功能需求之上還要注重軟件的易用性。因?yàn)檫@些易用特性或質(zhì)量屬性能使你更準(zhǔn)確、高效地完成任務(wù)。例如，客戶有時(shí)要求產(chǎn)品要“用戶友好”或“健壯”或“高效率”，但這對(duì)于開發(fā)人員來說，太主觀了并無實(shí)用價(jià)值。正確的應(yīng)是：分析人員通過詢問和調(diào)查了解客戶所要的友好、健壯、高效所包含的具體特性(第11章將詳細(xì)討論它)。權(quán)利#8調(diào)整需求，允許重用已有的軟件組件需求通常要有一定的靈活性。分析人員可能發(fā)現(xiàn)已有的某個(gè)軟件組件與你描述的需求很相符。在這種情況下，分析人員應(yīng)提供一些修改需求的選擇以便開發(fā)人員能夠在新系統(tǒng)開發(fā)中重用一些已有的軟件。如果有可重用的機(jī)會(huì)出現(xiàn)，同時(shí)你又能調(diào)整你的需求說明，那就能降低成本和節(jié)省時(shí)間，而不必嚴(yán)格按原有的需求說明開發(fā)。所以說，如果想在產(chǎn)品中使用一些已有的商業(yè)常用組件，而它們并不完全適合你所需的特性，這時(shí)一定程度上的需求靈活性就顯得極為重要了。權(quán)利#9：要求對(duì)變更的代價(jià)提供真實(shí)可信的評(píng)估有時(shí)人們面臨更好、也更昂貴的方案時(shí)，會(huì)做出不同的選擇。而這時(shí)，對(duì)需求變更的影響進(jìn)行評(píng)估從而對(duì)業(yè)務(wù)決策提供幫助，這是十分必要的，所以，你有權(quán)利要求開發(fā)人員通過分析給出一個(gè)的確真實(shí)可信的評(píng)估，包括影響、成本和得失等評(píng)估。開發(fā)人員不能由于不想實(shí)施變更而隨意夸大評(píng)估成本。權(quán)利#10：獲得滿足客戶功能和質(zhì)量要求的系統(tǒng)bafd2b98317835f4548c7e257eb13550.doc19每個(gè)人都希望項(xiàng)目獲得成功。但這不僅要求你要清晰地告知開發(fā)人員關(guān)于系統(tǒng)“做什么”所需的所有信息，而且還要求開發(fā)人員能通過交流了解清楚取舍與限制。一定要明確說明你的假設(shè)和潛在的期望。否則，開發(fā)人員開發(fā)出的產(chǎn)品很可能無法讓你滿意。軟件客戶需求義務(wù)書Top義務(wù)#1：給分析人員講解你的業(yè)務(wù)分析人員要依靠你給他們講解的業(yè)務(wù)概念及術(shù)語。但你不能指望分析人員會(huì)成為該領(lǐng)域的專家，而只能讓他們真正明白你的問題和目標(biāo)。不要期望分析人員能把握你們業(yè)務(wù)的細(xì)微與潛在之處，他們很可能并不知道那些對(duì)于你和你的同事來說理所當(dāng)然的“常識(shí)”。義務(wù)#2：抽出時(shí)間清楚地說明并完善需求客戶很忙，經(jīng)常在最忙的時(shí)候還得參與需求開發(fā)。但無論如何，你有義務(wù)抽出時(shí)間參與“頭腦風(fēng)暴”會(huì)議的討論，接受采訪或其它獲取需求的活動(dòng)。有時(shí)分析人員可能先以為明白了你的觀點(diǎn)，而過后發(fā)現(xiàn)還需要你的講解。這時(shí)，請(qǐng)耐心一些對(duì)待需求和需求的精化工作過程中的反復(fù)，因?yàn)樗侨藗兘涣髦械暮茏匀坏默F(xiàn)象，何況這對(duì)軟件產(chǎn)品的成功極為重要。義務(wù)#3：準(zhǔn)確而詳細(xì)地說明需求在需求規(guī)格說明中暫時(shí)加上TBD的標(biāo)志是個(gè)不錯(cuò)的辦法。用該標(biāo)志可指明了哪些需要進(jìn)一步探討、分析或增加信息的地方。不過，有時(shí)也可能因?yàn)槟硞€(gè)特殊需求難以解決或沒有人愿意處理它而注上TBD標(biāo)志。盡量將每項(xiàng)需求的內(nèi)容都闡述清楚，以便分析人員能準(zhǔn)確的將其寫進(jìn)軟件需求規(guī)格說明中。如果你一時(shí)不能準(zhǔn)確表述，那就得允許獲取必要的準(zhǔn)確信息這樣一個(gè)過程。通常使用所謂的原型技術(shù)。通過開發(fā)的原型，你可以同開發(fā)人員一起反復(fù)修改，不斷完善需求定義。義務(wù)#4：及時(shí)地作出決定正如一位建筑師為你修建房屋，分析人員將要求你做出一些選擇和決定。這些決定包括來自多個(gè)用戶提出的處理方法或在質(zhì)量特性沖突和信息準(zhǔn)確度中選擇折衷方案等。有權(quán)做出決定的客戶必須積極地對(duì)待這一切，盡快做處理、做決定。因?yàn)殚_發(fā)人員通常只有等你做出了決定才能行動(dòng)，而這種等待會(huì)延誤項(xiàng)目的進(jìn)展。義務(wù)#S：尊重開發(fā)人員的需求可行性及成本評(píng)估所有的軟件功能都有其成本價(jià)格，開發(fā)人員最適合預(yù)算這些成本(盡管許多開發(fā)人員并不擅長(zhǎng)評(píng)估預(yù)測(cè))。你所希望的某些產(chǎn)品特性可能在技術(shù)上行不通，或者實(shí)現(xiàn)它要付出極為高昂的代價(jià)。而某些需求試圖在操作環(huán)境中要求不可能達(dá)到的性能或試圖得到一些根本得不到的數(shù)據(jù)，開發(fā)人員會(huì)對(duì)此作出負(fù)面的評(píng)價(jià)意見，你應(yīng)該尊重他們的意見。有時(shí)，你可以重新給出一個(gè)在技術(shù)上可行、實(shí)現(xiàn)上便宜的需求，例如，要求某個(gè)行為在“瞬間”發(fā)生是不可行的，但換種更具體的時(shí)間需求說法(“在50毫秒以內(nèi)”)，這就可以實(shí)現(xiàn)了。絕大多數(shù)項(xiàng)目沒有足夠的時(shí)間或資源來實(shí)現(xiàn)功能性的每個(gè)細(xì)節(jié)。決定哪些特性是必要的，哪些是重要的，哪些是好的，是需求開發(fā)的主要部分。只能由你來負(fù)責(zé)設(shè)定需求優(yōu)先級(jí)，因?yàn)殚_發(fā)者并不可能按bafd2b98317835f4548c7e257eb13550.doc20你的觀點(diǎn)決定需求優(yōu)先級(jí)。開發(fā)者將為你確定優(yōu)先級(jí)提供有關(guān)每個(gè)需求的花費(fèi)和風(fēng)險(xiǎn)的有關(guān)信息。當(dāng)你設(shè)定優(yōu)先級(jí)時(shí)，你幫助開發(fā)者確保在適當(dāng)?shù)臅r(shí)間內(nèi)用最小的開支取得最好的效果。在時(shí)間和資源限制下，關(guān)于所需特性能否完成或完成多少應(yīng)該尊重開發(fā)人員的意見。盡管沒有人愿意看到自己所希望的需求在項(xiàng)目中未被實(shí)現(xiàn)，但畢竟是要面對(duì)這種現(xiàn)實(shí)的。業(yè)務(wù)決策有時(shí)不得不依據(jù)優(yōu)先級(jí)來縮小項(xiàng)目范圍或延長(zhǎng)工期，或增加資源，或在質(zhì)量上尋找折衷。義務(wù)#7：評(píng)審需求文檔和原型正如我們將在第14章討論的，無論是正式的還是非正式的方式，對(duì)需求文檔進(jìn)行評(píng)審都會(huì)對(duì)軟件質(zhì)量提高有所幫助。讓客戶參與評(píng)審才能真正鑒別需求文檔是否的確完整、正確說明了期望的必要特性。評(píng)審也給客戶代表提供一個(gè)機(jī)會(huì)，給需求分析人員帶來反饋信息以改進(jìn)他們的工作。如果你認(rèn)為編寫的需求文檔不夠準(zhǔn)確，就有義務(wù)盡早告訴分析人員并為改進(jìn)提供建議。通過閱讀需求規(guī)格說明，很難想象實(shí)際的軟件是什么樣子的。更好的方法是先為產(chǎn)品開發(fā)一個(gè)原型。這樣你就能提供更有價(jià)值的反饋信息給開發(fā)人員，幫助他們更好地理解你的需求。必須認(rèn)識(shí)到：原型并非是一個(gè)實(shí)際產(chǎn)品，但開發(fā)人員能將其轉(zhuǎn)變、擴(kuò)充成功能齊全的系統(tǒng)。義務(wù)#8：需求出現(xiàn)變更要馬上聯(lián)系不斷的需求變更會(huì)給在預(yù)定計(jì)劃內(nèi)完成高質(zhì)量產(chǎn)品帶來嚴(yán)重的負(fù)面影響。變更是不可避免的，但在開發(fā)周期中變更越在晚期出現(xiàn)，其影響越大。變更不僅會(huì)導(dǎo)致代價(jià)極高的返工，而且工期也會(huì)被迫延誤，特別是在大體結(jié)構(gòu)已完成后又需要增加新特性時(shí)。所以一旦你發(fā)現(xiàn)需要，變更需求時(shí)，請(qǐng)一定立即通知分析人員。義務(wù)#9：應(yīng)遵照開發(fā)組織處理需求變更的過程為了將變更帶來的負(fù)面影響減少到最低限度，所有的參與者必須遵照項(xiàng)目的變更控制過程。這要求不放棄所有提出的變更，對(duì)每項(xiàng)要求的變更進(jìn)行分析、綜合考慮，最后作出合適的決策以確定將某些變更引入項(xiàng)目中。義務(wù)#10：尊重開發(fā)人員采用的需求工程過程軟件開發(fā)中最具挑戰(zhàn)性的莫過于收集需求并確定其正確性。分析人員采用的方法有其合理性所在。也許你認(rèn)為需求過程不太劃算，但請(qǐng)相信花在需求開發(fā)上的時(shí)間是“很有價(jià)值”的。如果你理解并支持分析人員為收集、編寫需求文檔和確保其質(zhì)量所采用的技術(shù)，那么整個(gè)過程將會(huì)更為順利。盡管去詢問分析人員為什么他們要收集某些信息，或參與與需求有關(guān)的活動(dòng)?！昂灱s”意味著什么？為所開發(fā)產(chǎn)品的需求簽訂協(xié)議是客戶與開發(fā)人員關(guān)系中的重要部分。許多組織在需求文檔中使用“簽約”這個(gè)概念來作為客戶同意需求的標(biāo)志行為。故要讓所有需求參與者都真正明白“簽約”的意但存在這樣一個(gè)問題：客戶代表經(jīng)常把“簽約”看作是毫無意義的?！八麄円以谝粡埣埖淖詈笠恍形淖窒旅婧炆厦?，于是我就簽了，否則這些開發(fā)人員不開始編碼?！边@種態(tài)度會(huì)給將來帶來麻煩。譬如客戶想更改需求或?qū)Ξa(chǎn)品有不滿時(shí)?！安诲e(cuò)，我是在需求上簽署了名字，但我并沒有時(shí)間去讀完所有的內(nèi)容。我是相信你們的，是你們非要讓我簽字的?！蓖瑯拥膯栴}也會(huì)發(fā)生在僅把簽約看作是完成文檔的管理人員身上。一旦有需求變更出現(xiàn)，他便指著軟件需求規(guī)格說明說道：“但你已經(jīng)在需求上簽約了，所以這些便是我們所要開發(fā)的。如果你想要?jiǎng)e的什么，你應(yīng)早些告訴我們?！眀afd2b98317835f4548c7e257eb13550.doc21這樣的態(tài)度都是不對(duì)的，不可能在項(xiàng)目早期就了解所有需求，而且毫無疑問需求將會(huì)出現(xiàn)變更。在需求上簽約是終止需求開發(fā)過程的正確方法。然而，參與者必須明白他們的簽約意味著什么。更為重要的是簽約名字是建立在一個(gè)需求協(xié)議的基線上，因此在需求規(guī)格說明上的簽約應(yīng)該這樣理解：“我同意這份文檔表述了目前我們對(duì)項(xiàng)目軟件需求的了解。進(jìn)一步的變更可在此基線上通過項(xiàng)目定義的變更過程來進(jìn)行。我知道變更可能會(huì)使我們要重新協(xié)商成本、資源和項(xiàng)目工期任務(wù)等”。關(guān)于基線達(dá)成一定共識(shí)會(huì)易于忍受將來的摩擦，這些摩擦來源于項(xiàng)目的改進(jìn)和需求的誤差或市場(chǎng)和業(yè)務(wù)的新要求等。給初步的需求開發(fā)工作畫上雙方都明確的句號(hào)會(huì)有助你形成一個(gè)持續(xù)良好的客戶與開發(fā)人員的關(guān)系，為項(xiàng)目的成功奠定了基礎(chǔ)。令讓客戶提供項(xiàng)目的業(yè)務(wù)需求和用戶需求。對(duì)權(quán)利書和義務(wù)書的條目，哪些被客戶接受、理解并付諸實(shí)踐了？那些沒有？令與你的重要客戶一起討論權(quán)利書和義務(wù)書，以達(dá)成協(xié)議，并付諸實(shí)踐。這些行為會(huì)有助于客戶和開發(fā)人員更好地互相理解，以形成更融洽的關(guān)系。令如果你是軟件開發(fā)項(xiàng)目中的客戶參與方，你感到你的需求權(quán)利書沒有被充分尊重，就可以與軟件項(xiàng)目的領(lǐng)導(dǎo)人員或業(yè)務(wù)分析人員一起討論權(quán)利書的內(nèi)容。要想建立一種合作的工作關(guān)系，就要盡力使對(duì)方對(duì)你的義務(wù)書感到滿意。bafd2b98317835f4548c7e257eb13550.doc22第3章需求工程的推薦方法Top十年前，我曾熱衷于追求軟件的開發(fā)方法論的研究，將整套整套的模型、技術(shù)等用于解決項(xiàng)目難題。但現(xiàn)在我更注重應(yīng)用“最佳方法”。最佳方法強(qiáng)調(diào)將軟件工具包拆分成多個(gè)子包以分別應(yīng)用于不同的問題，而并不是去設(shè)計(jì)或購(gòu)買一整套的解決方案。即使你采用了一套商業(yè)上的方法，你也應(yīng)當(dāng)從中提取出好的技術(shù)，將它有效地應(yīng)用于實(shí)踐。“最佳方法”這個(gè)詞值得討論一下：誰能確定什么是“最佳”的呢？而且，得到這個(gè)結(jié)論的依據(jù)何在？一種方案是把這方面的專家召集起來分析眾多不同組織中成功和失敗的項(xiàng)目(Browm1996)。專家們將那些成功項(xiàng)目中提供高效的方法和失敗項(xiàng)目中導(dǎo)致低效甚至無效的方法都?xì)w納出來。這樣，專家們就能找到公認(rèn)的能收到實(shí)效的關(guān)鍵方法。這些方法即是“最佳方法”，其本質(zhì)就是有助于項(xiàng)目成功的有效方法。本章的標(biāo)題是“需求工程的推薦方法”而非“最佳方法”。下面分七類介紹了四十余種方法，能有助于開發(fā)小組的需求工作，推薦方法如表3-1所列。表3-1需求工程推薦方法知識(shí)技能需求管理項(xiàng)目管理●培訓(xùn)需求分析人員●確定變更控制過程●建立變更控制委員會(huì)行變更影響分析●選擇合適的生存期●跟蹤影響工作產(chǎn)品的每項(xiàng)變更●管理需求風(fēng)險(xiǎn)●編寫需求文檔的基線和控制版本●跟蹤需求工作需求開發(fā)獲取分析編寫規(guī)格說明書驗(yàn)證●編寫項(xiàng)目視圖與范圍●繪制示意圖●采用軟件需求規(guī)格說明模版●審查需求文檔bafd2b98317835f4548c7e257eb13550.doc23●確定需求開發(fā)過程●創(chuàng)建開發(fā)原型●指明需求來源●分析可行性●為每項(xiàng)需求注上標(biāo)號(hào)●確定需求優(yōu)先級(jí)●記錄業(yè)務(wù)規(guī)范●建立核心隊(duì)伍●為需求建立模型●創(chuàng)建需求跟蹤能力矩陣調(diào)配發(fā)聯(lián)系(JAD)會(huì)議(QFD)并非上面所有的條目都是最佳方法，或許也并非全部經(jīng)過了系統(tǒng)的評(píng)估。但無論如何，我和許多實(shí)踐者都覺得這些技術(shù)是很有效的(Sommerville和Sawyer1997)。其中每一條都在本書中給予了簡(jiǎn)要介紹或在其它資料中給予了更詳細(xì)的討論。表3-2把表3-1中的方法按重要性和實(shí)施難度進(jìn)行了分組。由于所列的方法都是有所裨益的，故最好是循序漸進(jìn)，先從那些相對(duì)容易實(shí)施而對(duì)項(xiàng)目有很大影響的方法開始。表3-2實(shí)施需求工程的推薦方法優(yōu)先級(jí)別難度高中低高?確定使用實(shí)例會(huì)?培訓(xùn)開發(fā)人員了解應(yīng)用領(lǐng)域控制版本?為需求建立模型?建立核心隊(duì)伍?管理需求風(fēng)險(xiǎn)?創(chuàng)建開發(fā)原型中?使用需求管理工具?分析可行性?創(chuàng)建需求跟蹤能力矩陣?確定合格的標(biāo)準(zhǔn)?匯編術(shù)語用例?進(jìn)行變更影響分析?跟蹤需求狀態(tài)每項(xiàng)bafd2b98317835f4548c7e257eb13550.doc24系?分析用戶工作流程?檢查問題報(bào)告低?需求重用?編寫用戶手冊(cè)?維護(hù)變更歷史記錄?跟蹤需求工作不要想著把所有這些方法都用于你的下一個(gè)項(xiàng)目。而應(yīng)該考慮將其中的一些方法推薦到你的需求工具包中，不管你的項(xiàng)目處在開發(fā)的哪個(gè)階段，你都可以馬上開始應(yīng)用某些方法，譬如變更管理的處理。其它如需求獲取等可以在你的下一個(gè)項(xiàng)目開始時(shí)付諸應(yīng)用。當(dāng)然其它一些方法也可能并不適合你目前的項(xiàng)第4章介紹了一些用于評(píng)價(jià)需求工程的方法，并可設(shè)計(jì)一張實(shí)施需求方法改進(jìn)的步驟圖。具體的改進(jìn)方法在此處和第4章中都給予了介紹。絕大部分的軟件開發(fā)人員都沒有接受過高效需求工程所需技能的正規(guī)培訓(xùn)，但許多開發(fā)人員在職業(yè)生活中的某個(gè)階段總會(huì)扮演一個(gè)需求分析員的角色，與客戶一起工作：收集，分析，編寫需求文檔。不能過高期望開發(fā)人員在需求工程的信息溝通中的“天份”。一定的培訓(xùn)將有助于提高需求分析員的能力。因?yàn)樾枨髮?duì)項(xiàng)目成功極為重要，所有的項(xiàng)目風(fēng)險(xiǎn)承擔(dān)者都應(yīng)該對(duì)需求工程的重要性、合理性及其方法有一個(gè)基本的了解。把項(xiàng)目風(fēng)險(xiǎn)承擔(dān)者(例如開發(fā)人員，市場(chǎng)人員，客戶，測(cè)試人員和管理人員)召集起來進(jìn)行為期一天的需求過程概要學(xué)習(xí)，這對(duì)建立一個(gè)合作團(tuán)隊(duì)是很有效的。所有參與者都會(huì)更好的明白各自所面臨的挑戰(zhàn)是什么，以及為了整個(gè)團(tuán)隊(duì)獲得成功大家都需要作些什么。同樣，開發(fā)人員也能對(duì)應(yīng)用領(lǐng)域的術(shù)語和一些基本概念有大致的了解。培訓(xùn)需求分析人員。所有的開發(fā)人員都應(yīng)接受一個(gè)基本的需求工程培訓(xùn)。但那些負(fù)責(zé)收集(capturing)、編寫文檔和分析用戶需求的人員應(yīng)當(dāng)進(jìn)行為期一周或更長(zhǎng)時(shí)間的培訓(xùn)。把高水平的需求人員組織起來，通過良好的信息交流，了解應(yīng)用領(lǐng)域并有效地應(yīng)用需求工程中的成熟技術(shù)。培訓(xùn)軟件需求的用戶代表和管理人員。參與軟件開發(fā)的用戶代表應(yīng)接受為期一天左右關(guān)于需求工程的培訓(xùn)，開發(fā)管理者和客戶管理者也應(yīng)參加。這樣的培訓(xùn)將使他們明白強(qiáng)調(diào)需求的重要性，以及忽略需求將帶來的風(fēng)險(xiǎn)。參加過我組織的需求討論會(huì)的一些用戶表示，他們?cè)诖酥蟾芾斫廛浖_發(fā)人員了。讓開發(fā)人員了解應(yīng)用領(lǐng)域的基本概念。組織一些簡(jiǎn)短的關(guān)于客戶業(yè)務(wù)活動(dòng)、術(shù)語、目標(biāo)等方面的討論會(huì)以幫助開發(fā)人員對(duì)應(yīng)用領(lǐng)域有個(gè)基本了解。這能減少誤解及工程中的返工。你可能要為每位開發(fā)人員安排一個(gè)用戶伙伴以便在項(xiàng)目過程中解釋業(yè)務(wù)術(shù)語和概念。產(chǎn)品代表就應(yīng)該扮演這樣的角色。編寫項(xiàng)目術(shù)語匯編。為減少溝通方面的問題，編一部術(shù)語匯編將項(xiàng)目應(yīng)用領(lǐng)域的專用詞匯給予定義說明，既要包括那些有多種含義與用法的術(shù)語，也要包括那些在專用領(lǐng)域和一般使用中有不同含義的詞。第1章討論了需求的三個(gè)層次：業(yè)務(wù)，用戶和功能。在項(xiàng)目中它們?cè)诓煌臅r(shí)間來自不同的來源，也有著不同的目標(biāo)和對(duì)象，并需以不同的方式編寫成文檔。業(yè)務(wù)需求(或產(chǎn)品視圖和范圍)不應(yīng)包括用戶需求(或使用實(shí)例)，而所有的功能需求都應(yīng)該源于用戶需求。同時(shí)你也需要獲取非功能需求，如質(zhì)量屬性。你可以在下列章節(jié)中找到相關(guān)主題的詳細(xì)內(nèi)容：令第4章—確定需求開發(fā)過程。bafd2b98317835f4548c7e257eb13550.doc25令第6章—編寫項(xiàng)目視圖和范圍文檔。令第7章—將用戶群分類并歸納其特點(diǎn)，為每個(gè)用戶類選擇產(chǎn)品代表(productchampion)。令第8章——讓用戶代表確定使用實(shí)例。令第11章——確定質(zhì)量屬性和其它非功能需求。確定需求開發(fā)過程。確定如何組織需求的收集、分析、細(xì)化并核實(shí)的步驟，并將它編寫成文檔，對(duì)重要的步驟要給予一定指導(dǎo)，這將有助于分析人員的工作，而且也使收集需求活動(dòng)的安排和進(jìn)度計(jì)劃更容易進(jìn)行。編寫項(xiàng)目視圖和范圍文檔。項(xiàng)目視圖和范圍文檔應(yīng)該包括高層的產(chǎn)品業(yè)務(wù)目標(biāo)，所有的使用實(shí)例和功能需求都必須遵從能達(dá)到的業(yè)務(wù)需求。項(xiàng)目視圖說明使所有項(xiàng)目參與者對(duì)項(xiàng)目的目標(biāo)能達(dá)成共識(shí)。而范圍則是作為需求或潛在特性的參考。將用戶群分類并歸納各自特點(diǎn)。為避免出現(xiàn)疏忽某一用戶群需求的情況，要將可能使用產(chǎn)品的客戶分成不同組別。他們可能在使用頻率、使用特性、優(yōu)先等級(jí)或熟練程度等方面都有所差異。詳細(xì)描述出它們的個(gè)性特點(diǎn)及任務(wù)狀況，將有助于產(chǎn)品設(shè)計(jì)。選擇每類用戶的產(chǎn)品代表。為每類用戶至少選擇一位能真正代表他們需求的人作為那一類用戶的代表并能作出決策。這對(duì)于內(nèi)部信息系統(tǒng)的開發(fā)是最易實(shí)現(xiàn)的，因?yàn)榇藭r(shí)，用戶就是身邊的職員。而對(duì)于商業(yè)開發(fā)，就得在主要的客戶或測(cè)試者中建立起良好的合作關(guān)系，并確定合適的產(chǎn)品代表。他們必須一直參與項(xiàng)目的開發(fā)而且有權(quán)作出決策。建立起典型用戶的核心隊(duì)伍。把同類產(chǎn)品或你的產(chǎn)品的先前版本用戶代表召集起來，從他們那里收集目前產(chǎn)品的功能需求和非功能需求。這樣的核心隊(duì)伍對(duì)于商業(yè)開發(fā)尤為有用，因?yàn)槟銚碛幸粋€(gè)龐大且多樣的客戶基礎(chǔ)。與產(chǎn)品代表的區(qū)別在于，核心隊(duì)伍成員通常沒有決定權(quán)。讓用戶代表確定使用實(shí)例。從用戶代表處收集他們使用軟件完成所需任務(wù)的描述——使用實(shí)例，討論用戶與系統(tǒng)間的交互方式和對(duì)話要求。在編寫使用實(shí)例的文檔時(shí)可采用標(biāo)準(zhǔn)模版，在使用實(shí)例基礎(chǔ)上可得到功能需求。召開應(yīng)用程序開發(fā)聯(lián)系會(huì)議。召開應(yīng)用程序開發(fā)聯(lián)系(JAD)會(huì)議是范圍廣的、簡(jiǎn)便的專題討論會(huì) (workshop)，也是分析人員與客戶代表之間一種很好的合作辦法，并能由此擬出需求文檔的底稿。該會(huì)議通過緊密而集中的討論得以將客戶與開發(fā)人員間的合作伙伴關(guān)系付諸于實(shí)踐(Wood和Silver1995)。分析用戶工作流程。觀察用戶執(zhí)行業(yè)務(wù)任務(wù)的過程。畫一張簡(jiǎn)單的示意圖(最好用數(shù)據(jù)流圖)來描繪出用戶什么時(shí)候獲得什么數(shù)據(jù)，并怎樣使用這些數(shù)據(jù)。編制業(yè)務(wù)過程流程文檔將有助于明確產(chǎn)品的使用實(shí)例和功能需求。你甚至可能發(fā)現(xiàn)客戶并不真的需要一個(gè)全新的軟件系統(tǒng)就能達(dá)到他們的業(yè)務(wù)目標(biāo) (McGraw和Harbison1997)。確定質(zhì)量屬性和其它非功能需求。在功能需求之外再考慮一下非功能的質(zhì)量特點(diǎn)，這會(huì)使你的產(chǎn)品達(dá)到并超過客戶的期望。這些特點(diǎn)包括性能、有效性、可靠性、使用性等，而在這些質(zhì)量屬性上客戶提供的信息相對(duì)來說就非常重要了。通過檢查當(dāng)前系統(tǒng)的問題報(bào)告來進(jìn)一步完善需求?？蛻舻膯栴}報(bào)告及補(bǔ)充需求為新產(chǎn)品或新版本提供了大量豐富的改進(jìn)及增加特性的想法，負(fù)責(zé)提供用戶支持及幫助的人能為收集需求過程提供極有價(jià)值的跨項(xiàng)目重用需求。如果客戶要求的功能與已有的產(chǎn)品很相似，則可查看需求是否有足夠的靈活性以允許重用一些已有的軟件組件。bafd2b98317835f4548c7e257eb13550.doc26需求分析(requirementanalysis)需求分析包括提煉、分析和仔細(xì)審查已收集到的需求，以確保所有的風(fēng)險(xiǎn)承擔(dān)者都明白其含義并找出其中的錯(cuò)誤、遺漏或其它不足的地方。分析員通過評(píng)價(jià)來確定是否所有的需求和軟件需求規(guī)格說明都達(dá)到了第1章中優(yōu)秀需求說明的要求。分析的目的在于開發(fā)出高質(zhì)量的需求，這樣你能作出實(shí)用的項(xiàng)目估算并可以進(jìn)行設(shè)計(jì)、構(gòu)造和測(cè)試。通常，把需求中的一部分用多種形式來描述，如同時(shí)用文本和圖形來描述。分析這些不同的視圖將揭示出一些更深的問題，這是單一視圖無法提供的(Davis1995)。分析還包括與客戶的交流以澄清某些混淆，并明確哪些需求是更為重要的。其目的是確保所有風(fēng)險(xiǎn)承擔(dān)者盡早地對(duì)項(xiàng)目達(dá)成共識(shí)并對(duì)將來的產(chǎn)品有個(gè)相同而清晰的認(rèn)識(shí)。下面幾章對(duì)需求分析中的任務(wù)進(jìn)行了詳細(xì)討論：令令令令令第6章——繪制系統(tǒng)上下文示意圖。第9章——建立數(shù)據(jù)字典。第10章——為需求建立模型。第12章——建立用戶接口原型。第13章——確定需求優(yōu)先級(jí)。繪制系統(tǒng)上下文示意圖。這種示意圖是用于定義系統(tǒng)與系統(tǒng)外部實(shí)體間的界限和接口的簡(jiǎn)單模型。同時(shí)它也明確了通過接口的信息流和物質(zhì)流。創(chuàng)建用戶接口原型。當(dāng)開發(fā)人員或用戶不能確定需求時(shí)，開發(fā)一個(gè)用戶接口原型———個(gè)局部的可能實(shí)現(xiàn)——這樣使得許多概念和可能發(fā)生的事更為直觀明了。用戶通過評(píng)價(jià)原型將使項(xiàng)目參與者能更好地相互理解所要解決的問題。注意要找出需求文檔與原型之間的所有沖突之處。分析需求可行性。在允許的成本、性能要求下，分析每項(xiàng)需求實(shí)施的可行性，明確與每項(xiàng)需求實(shí)現(xiàn)相聯(lián)系的風(fēng)險(xiǎn)，包括與其它需求的沖突，對(duì)外界因素的依賴和技術(shù)障礙。確定需求的優(yōu)先級(jí)別。應(yīng)用分析方法來確定使用實(shí)例、產(chǎn)品特性或單項(xiàng)需求實(shí)現(xiàn)的優(yōu)先級(jí)別。以優(yōu)先級(jí)為基礎(chǔ)確定產(chǎn)品版本將包括哪些特性或哪類需求。當(dāng)允許需求變更時(shí)，在特定的版本中加入每一項(xiàng)變更，并在那個(gè)版本計(jì)劃中作出需要的變更。為需求建立模型。需求的圖形分析模型是軟件需求規(guī)格說明極好的補(bǔ)充說明。它們能提供不同的信息與關(guān)系以有助于找到不正確的、不一致的、遺漏的和冗余的需求。這樣的模型包括數(shù)據(jù)流圖、實(shí)體關(guān)系圖、狀態(tài)變換圖、對(duì)話框圖、對(duì)象類及交互作用圖。創(chuàng)建數(shù)據(jù)字典。數(shù)據(jù)字典是對(duì)系統(tǒng)用到的所有數(shù)據(jù)項(xiàng)和結(jié)構(gòu)的定義，以確保開發(fā)人員使用統(tǒng)一的數(shù)據(jù)定義。在需求階段，數(shù)據(jù)字典至少應(yīng)定義客戶數(shù)據(jù)項(xiàng)以確?？蛻襞c開發(fā)小組是使用一致的定義和術(shù)語。分析和設(shè)計(jì)工具通常包括數(shù)據(jù)字典組件。使用質(zhì)量功能調(diào)配。質(zhì)量功能調(diào)配(QFD)是一種高級(jí)系統(tǒng)技術(shù)，它將產(chǎn)品特性、屬性與對(duì)用戶價(jià)值聯(lián)系起來。該技術(shù)提供了一種分析方法以明確那些是客戶最為關(guān)注的特性。QFD將需求分為三類：期望需求，即客戶或許并未提及，但如若缺少會(huì)讓他們感到不滿意；普通需求；和興奮需求，即實(shí)現(xiàn)了會(huì)給客戶帶去驚喜，但若未實(shí)現(xiàn)也不會(huì)受到責(zé)備(Zultner1993;Pardee1996)。需求規(guī)格說明(requirementspecification)無論你的需求從何而來，也不管你是怎樣得到的，你都必須用一種統(tǒng)一的方式來將它們編寫成可視文檔。業(yè)務(wù)需求要寫成項(xiàng)目視圖和范圍文檔，用戶需求要用一種標(biāo)準(zhǔn)使用實(shí)例模板編寫成文檔。而軟件需求規(guī)格說明則包含了軟件的功能需求和非功能需求。你必須為每項(xiàng)需求明確建立標(biāo)準(zhǔn)的風(fēng)格，并在SRS中bafd2b98317835f4548c7e257eb13550.doc27采用，以確保SRS的統(tǒng)一風(fēng)格，同時(shí)讀者也會(huì)明白怎樣解釋它。下列章節(jié)討論了關(guān)于編寫需求文檔的幾個(gè)令令令第8章——記錄業(yè)務(wù)規(guī)范。第9章——采用SRS模板；為每項(xiàng)需求注上標(biāo)號(hào)。第18章——指明需求來源；創(chuàng)建需求跟蹤能力矩陣。采用SRS模板。在你的組織中要為編寫軟件需求文檔定義一種標(biāo)準(zhǔn)模板。該模板為記錄功能需求和各種其它與需求相關(guān)的重要信息提供了統(tǒng)一的結(jié)構(gòu)。注意，其目的并非是創(chuàng)建一種全新的模板，而是采用一種已有的且可滿足項(xiàng)目需要并適合項(xiàng)目特點(diǎn)的模板。許多組織一開始都采用IEEE標(biāo)準(zhǔn)830-1998(IEEE1998)描述的SRS模板。要相信模板是很有用的，但有時(shí)要根據(jù)項(xiàng)目特點(diǎn)進(jìn)行適當(dāng)?shù)母膭?dòng)。指明需求的來源。為了讓所有項(xiàng)目風(fēng)險(xiǎn)承擔(dān)者明白SRS中為何提供這些功能需求，要將每項(xiàng)需求都能追溯其來源，這可能是一種使用實(shí)例(usecase)或其它客戶要求，也可能是某項(xiàng)更高層系統(tǒng)需求、業(yè)務(wù)規(guī)范、政府規(guī)則、標(biāo)準(zhǔn)或別的外部來源。為每項(xiàng)需求注上標(biāo)號(hào)。制定一種風(fēng)格來為SRS中的每項(xiàng)需求提供一個(gè)獨(dú)立的可識(shí)別的標(biāo)號(hào)或記號(hào)。這種風(fēng)格應(yīng)當(dāng)很健全，允許增加、刪除和修改。作了標(biāo)號(hào)的需求使得需求能被跟蹤，記錄需求變更并為需求狀態(tài)和變更活動(dòng)建立度量。記錄業(yè)務(wù)規(guī)范。業(yè)務(wù)規(guī)范是指關(guān)于產(chǎn)品的操作原則，比如誰能在什么情況下采取什么動(dòng)作。將這些編寫成SRS中的一個(gè)獨(dú)立部分，或一獨(dú)立的業(yè)務(wù)規(guī)范文檔。某些業(yè)務(wù)規(guī)范將引出相應(yīng)的功能需求；當(dāng)然這些需求也應(yīng)能追溯相應(yīng)業(yè)務(wù)規(guī)范。創(chuàng)建需求跟蹤能力矩陣。建立一個(gè)矩陣把每項(xiàng)需求與實(shí)現(xiàn)、測(cè)試它的設(shè)計(jì)和代碼部分聯(lián)系起來。這樣的需求跟蹤能力矩陣同時(shí)也把功能需求和高層的需求及其它相關(guān)需求聯(lián)系起來了。在開發(fā)過程中建立這個(gè)矩陣，而不要等到最后才去補(bǔ)建。需求驗(yàn)證(requirementverification)驗(yàn)證是為了確保需求說明準(zhǔn)確、完整地表達(dá)了必要的質(zhì)量特點(diǎn)。當(dāng)你閱讀軟件需求規(guī)格說明 (SRS)時(shí)，可能覺得需求是對(duì)的，但實(shí)現(xiàn)時(shí)，卻很可能會(huì)出現(xiàn)問題。當(dāng)以需求說明為依據(jù)編寫測(cè)試用例時(shí)，你可能會(huì)發(fā)現(xiàn)說明中的二義性。而所有這些都必須改善，因?yàn)樾枨笳f明要作為設(shè)計(jì)和最終系統(tǒng)驗(yàn)證的依據(jù)。客戶的參與在需求驗(yàn)證中占有重要的位置，第14章還將進(jìn)一步討論它。審查需求文檔。對(duì)需求文檔進(jìn)行正式審查是保證軟件質(zhì)量的很有效的方法。組織一個(gè)由不同代表 (如分析人員，客戶，設(shè)計(jì)人員，測(cè)試人員)組成的小組，對(duì)SRS及相關(guān)模型進(jìn)行仔細(xì)的檢查。另外在需求開發(fā)期間所做的非正式評(píng)審也是有所裨益的。以需求為依據(jù)編寫測(cè)試用例。根據(jù)用戶需求所要求的產(chǎn)品特性寫出黑盒功能測(cè)試用例?？蛻敉ㄟ^使用測(cè)試用例以確認(rèn)是否達(dá)到了期望的要求。還要從測(cè)試用例追溯回功能需求以確保沒有需求被疏忽，并且確信所有測(cè)試結(jié)果與測(cè)試用例相一致。同時(shí)，要使用測(cè)試用例來驗(yàn)證需求模型的正確性，如對(duì)話框圖和原編寫用戶手冊(cè)。在需求開發(fā)早期即可起草一份用戶手冊(cè)，用它作為需求規(guī)格說明的參考并輔助需求分析。優(yōu)秀的用戶手冊(cè)要用淺顯易懂的語言描述出所有對(duì)用戶可見的功能。而輔助需求如質(zhì)量屬性、性能需求及對(duì)用戶不可見的功能則在SRS中予以說明。確定合格的標(biāo)準(zhǔn)。讓用戶描述什么樣的產(chǎn)品才算滿足他們的要求和適合他們使用的。將確認(rèn)合格的測(cè)試建立在使用情景描述或使用實(shí)例的基礎(chǔ)之上(Hsia,Kung,和Sell1997)。需求管理(requirementmanagement)bafd2b98317835f4548c7e257eb13550.doc28當(dāng)你完成需求說明之后，你不可避免的還會(huì)遇到項(xiàng)目需求的變更。有效的變更管理需要對(duì)變更帶來的潛在影響及可能的成本費(fèi)用進(jìn)行評(píng)估。變更控制委員會(huì)與關(guān)鍵的項(xiàng)目風(fēng)險(xiǎn)承擔(dān)者要進(jìn)行協(xié)商，以確定哪些需求可以變更。同時(shí)，無論是在開發(fā)階段還是在系統(tǒng)測(cè)試階段，還應(yīng)跟蹤每項(xiàng)需求的狀態(tài)。建立起良好的配置管理方法是進(jìn)行有效需求管理的先決條件。許多開發(fā)組織使用版本控制和其它管理配置技術(shù)來管理代碼，所以你也可以采用這些方法來管理你的需求文檔，需求管理的改進(jìn)也是將全新的管理配置方法引入項(xiàng)目的組織中的一種方法。下列章節(jié)討論了需求管理涉及到的各種技術(shù)：令令令令第16章—建立需求基線和需求控制版本文檔。第17章—確定需求變更控制過程；建立變更控制委員會(huì)。第18章—進(jìn)行需求變更影響分析；跟蹤所有受需求變更影響的工作產(chǎn)品。第19章—使用需求管理工具。確定需求變更控制過程。確定一個(gè)選擇、分析和決策需求變更的過程。所有的需求變更都需遵循此過程，商業(yè)化的問題跟蹤工具都能支持變更控制過程。建立變更控制委員會(huì)。組織一個(gè)由項(xiàng)目風(fēng)險(xiǎn)承擔(dān)者組成的小組作為變更控制委員會(huì)，由他們來確定進(jìn)行哪些需求變更，此變更是否在項(xiàng)目范圍內(nèi)，估價(jià)它們，并對(duì)此評(píng)估作出決策以確定選擇哪些，放棄哪些，并設(shè)置實(shí)現(xiàn)的優(yōu)先順序，制定目標(biāo)版本。進(jìn)行需求變更影響分析。應(yīng)評(píng)估每項(xiàng)選擇的需求變更，以確定它對(duì)項(xiàng)目計(jì)劃安排和其它需求的影響。明確與變更相關(guān)的任務(wù)并評(píng)估完成這些任務(wù)需要的工作量。通過這些分析將有助于變更控制委員會(huì)作出更好的決策。跟蹤所有受需求變更影響的工作產(chǎn)品。當(dāng)進(jìn)行某項(xiàng)需求變更時(shí)，參照需求跟蹤能力矩陣找到相關(guān)的其它需求、設(shè)計(jì)模板、源代碼和測(cè)試用例，這些相關(guān)部分可能也需要修改。這樣能減少疏忽使需求變更帶來的產(chǎn)品變更變得相對(duì)輕松些。建立需求基線和需求控制版本文檔。確定一個(gè)需求基線，之后的需求變更就遵循變更控制過程即可。每個(gè)版本的需求規(guī)格說明都必須是獨(dú)立說明，以避免將底稿和基線或新舊版本相混淆。最好的辦法是使用合適的配置管理工具在版本控制下為需求文檔定位。維護(hù)需求變更的歷史記錄。記錄變更需求文檔版本的日期以及所做的變更、原因，還包括由誰負(fù)責(zé)更新的和更新的新版本號(hào)等。版本控制工具能自動(dòng)完成這些任務(wù)。跟蹤每項(xiàng)需求的狀態(tài)。建立一個(gè)數(shù)據(jù)庫(kù)，其中每一條記錄保存一項(xiàng)功能需求。保存的每項(xiàng)功能需求的重要屬性，它包括狀態(tài)(如已推薦的，已通過的，已實(shí)施的，或已驗(yàn)證的)，這樣在任何時(shí)候都能得到每個(gè)狀態(tài)類的需求數(shù)量。衡量需求穩(wěn)定性。記錄基本需求的數(shù)量和每周或每月的變更數(shù)量(添加、修改、刪除)。過多的需求變更“是一個(gè)報(bào)警信號(hào)”意味著問題并未真正弄清楚，項(xiàng)目范圍并未很好的確定下來或是政策變化較使用需求管理工具。商業(yè)化的需求管理工具能幫助你在數(shù)據(jù)庫(kù)中存儲(chǔ)不同類型的需求，為每項(xiàng)需求確定屬性，可跟蹤其狀態(tài)，并在需求與其它軟件開發(fā)工作產(chǎn)品間建立跟蹤能力聯(lián)系鏈。項(xiàng)目管理(projectmanagement)軟件工程管理方法在本質(zhì)上與項(xiàng)目的需求過程是緊密相關(guān)的。項(xiàng)目計(jì)劃建立在功能基礎(chǔ)之上，而需求變更會(huì)影響這些計(jì)劃。因此，項(xiàng)目計(jì)劃應(yīng)能允許一定程度的需求變更或項(xiàng)目范圍擴(kuò)展。如果剛開始，需求不能確定，你可以選擇一種軟件開發(fā)方法生存期以允許這種不確定性，并在弄清后逐漸實(shí)施。關(guān)于需求工程項(xiàng)目管理方法的