03需求工程的推薦方法教案

1、軟件需求（第2版），教案 3需求工程的推薦方法13.1知識(shí)技能23.2需求獲取33.3需求分析53.4規(guī)格說(shuō)明63.5需求驗(yàn)證73.6需求管理83.7項(xiàng)目管理93.8開(kāi)始新實(shí)踐103.9需求開(kāi)發(fā)過(guò)程113 需求工程的推薦方法十多年前，我曾是一個(gè)軟件開(kāi)發(fā)方法集的愛(ài)好者。軟件開(kāi)發(fā)方法集（methodology）指包裝好的整套模型和技術(shù)方法，用于為項(xiàng)目提供整體解決方案。但現(xiàn)在我更愿意尋找和應(yīng)用行業(yè)的最佳方法（best practice）。最佳方法的做法是：在你的軟件工具包中儲(chǔ)存各種技術(shù)方法，用于解決不同的問(wèn)題，而不是試圖設(shè)計(jì)或購(gòu)買(mǎi)整體解決方案。即便采用商業(yè)開(kāi)發(fā)方法集，也可以對(duì)其進(jìn)行改造，使它最大程度

2、地滿足你的需求。還可以從工具包中選出其他有效方法補(bǔ)充該方法集。最佳方法是一個(gè)有爭(zhēng)議的說(shuō)法：誰(shuí)能決定什么是“最佳”，他有什么依據(jù)？一種決定方法是召集一群行業(yè)專家或研究員來(lái)分析來(lái)自不同組織的項(xiàng)目。這些專家在其中尋找一些方法，它們的有效性能是和成功的項(xiàng)目聯(lián)系在一起，而失敗的項(xiàng)目則往往沒(méi)有很好地實(shí)施這些方法，或者根本就沒(méi)有實(shí)施。通過(guò)這些手段，專家們就那些一直產(chǎn)生良好結(jié)果的活動(dòng)達(dá)成了一致。這些活動(dòng)就被稱為最佳方法。對(duì)于專業(yè)軟件人員來(lái)說(shuō)，這些活動(dòng)代表了十分高效的方法，能夠提高特定類型或特定條件下項(xiàng)目的成功幾率。表3-1列出了近50種方法，分別屬于7個(gè)類型，它們可以幫助大部分項(xiàng)目開(kāi)發(fā)團(tuán)隊(duì)更好地完成他們的需求

3、工作。有幾項(xiàng)方法屬于多種類型，但是表3-1中每個(gè)方法只出現(xiàn)一次。這些方法并不能適用于所有情況，因此要運(yùn)用合適的判斷標(biāo)準(zhǔn)常識(shí)和經(jīng)驗(yàn)而不是照本宣科地應(yīng)用它們。注意并非所有這些方法都己經(jīng)被認(rèn)定為行業(yè)最佳方法，這就是為什么我將這一章的標(biāo)題定為“需求正程的推薦方法”，而不是“最佳方法”的原因。我懷疑是否所有這些方法都曾為了這個(gè)目的而被系統(tǒng)地評(píng)估過(guò)。盡管如此，很多業(yè)內(nèi)人士已經(jīng)發(fā)現(xiàn)這些技術(shù)是有效的（Sommervillc和Sawyer 1997；Hofmann和Lehner 2001）。本章中將簡(jiǎn)單介紹每一個(gè)方法，并給出了可以獲得關(guān)于該技術(shù)的更多內(nèi)容的章節(jié)或其他來(lái)源。本章的最后一節(jié)介紹了一個(gè)適合絕大部分軟件

4、項(xiàng)目的需求開(kāi)發(fā)過(guò)程（一系列活動(dòng)）。表3-1需求工程推薦方法知識(shí)需求管理項(xiàng)目管理 培訓(xùn)需求分析員 對(duì)用戶代表和管理者進(jìn)行需求培訓(xùn) 對(duì)開(kāi)發(fā)者進(jìn)行應(yīng)用領(lǐng)域相關(guān)的培訓(xùn) 創(chuàng)建術(shù)語(yǔ)表 定義需求變更控制進(jìn)程 成立變更控制委員會(huì) 分析需求變更的影響 控制需求版本并為其建立基線 維護(hù)需求變更的歷史記錄 跟蹤每項(xiàng)需求的狀態(tài) 衡量需求穩(wěn)定性 使用需求管理工具 創(chuàng)建需求跟蹤矩陣 選擇合適的開(kāi)發(fā)周期 根據(jù)需求制訂項(xiàng)目計(jì)劃 重新協(xié)商權(quán)利或義務(wù) 管理需求風(fēng)險(xiǎn) 跟蹤需求耗費(fèi)的人力物力 回顧以往的教訓(xùn)需求獲取需求分析編寫(xiě)規(guī)格說(shuō)明需求驗(yàn)證 定義需求開(kāi)發(fā)過(guò)程 定義項(xiàng)目前景和范圍 確定用戶群 選擇用戶代言人 建立核心隊(duì)伍 確定用例

5、確定系統(tǒng)事件和響應(yīng) 舉行進(jìn)一步需求獲取的討論 觀察用戶如何工作 檢查問(wèn)題報(bào)告 重用需求 繪制關(guān)聯(lián)圖 創(chuàng)建原型 分析可行性 確定需求優(yōu)先級(jí) 為需求建模 創(chuàng)建數(shù)據(jù)字典 將需求分配至各子系統(tǒng) 應(yīng)用質(zhì)量功能調(diào)度 采用SRS模板 確定需求來(lái)源 惟一標(biāo)識(shí)每項(xiàng)需求 記錄業(yè)務(wù)規(guī)范 定義質(zhì)量屬性 審查需求文檔 測(cè)試需求 確定合格標(biāo)準(zhǔn)3.1 知識(shí)技能軟件開(kāi)發(fā)人員大都未曾接受過(guò)需求工程的正規(guī)培訓(xùn)。然而，許多開(kāi)發(fā)人員在他們職業(yè)生涯的某些時(shí)刻都會(huì)擔(dān)任需求分析員的角色，與用戶打交道，獲取、分析需求，并將它們編寫(xiě)成文檔。期望所有開(kāi)發(fā)人員天生就都勝任需求工程中需要進(jìn)行大量溝通的工作是不合理的。培訓(xùn)可以提高分析員的熟練程度，使

6、他們工作起來(lái)更得心應(yīng)手，卻無(wú)法彌補(bǔ)人際關(guān)系能力的不足或興趣的缺乏。由于需求過(guò)程是必不可少的，因此項(xiàng)目的所有涉眾都應(yīng)該理解需求工程的概念和方法。將各方涉眾召集起來(lái)利用一天的時(shí)間進(jìn)行軟件需求培訓(xùn)，這是打造團(tuán)隊(duì)的一種有效方法。各方可以更好地理解合作伙伴所面臨的挑戰(zhàn)，明白為了整個(gè)團(tuán)隊(duì)的成功參與者們需要對(duì)方做些什么。同樣，開(kāi)發(fā)者也應(yīng)該了解產(chǎn)品應(yīng)用領(lǐng)域中的基本概念和術(shù)語(yǔ)。關(guān)于這些主題可以在以下章節(jié)中找到更詳細(xì)的內(nèi)容：· 第4章 第10章培訓(xùn)需求分析員所有將要成為分析員的團(tuán)隊(duì)成員都應(yīng)該接受需求工程方面的基本培訓(xùn)。需求分析專家需要幾天時(shí)間來(lái)進(jìn)行這樣的培訓(xùn)。熟練的需求分析員應(yīng)具備以下特點(diǎn)：耐心，思維條

7、理性強(qiáng)，有良好的交際和溝通能力，理解產(chǎn)品應(yīng)用領(lǐng)域，并且掌握豐富的需求工程技術(shù)。對(duì)用戶代表和管理者進(jìn)行軟件需求培訓(xùn)參與軟件開(kāi)發(fā)的用戶應(yīng)該接受一到兩天的需求工程方面的培訓(xùn)。開(kāi)發(fā)經(jīng)理和客戶經(jīng)躉也會(huì)發(fā)現(xiàn)這些內(nèi)容很有用。培訓(xùn)可使用他們明白重視需求的意義；需求工作包括哪些活動(dòng)，要提交什么樣的結(jié)果；忽略需求過(guò)程會(huì)導(dǎo)致什么風(fēng)險(xiǎn)。一些參加過(guò)我的需求研討課程的用戶說(shuō)他們從此更加體諒軟件開(kāi)發(fā)人員。對(duì)開(kāi)發(fā)人員進(jìn)行應(yīng)用領(lǐng)域的相關(guān)培訓(xùn)為了幫助開(kāi)發(fā)人員對(duì)應(yīng)用領(lǐng)域有一個(gè)基本的理解，可以安排一個(gè)研討課程，內(nèi)容是客戶的業(yè)務(wù)活動(dòng)、術(shù)語(yǔ)和產(chǎn)品的目標(biāo)。這樣可以減少開(kāi)發(fā)過(guò)程中的混淆、誤解、和返工。還可以在項(xiàng)目開(kāi)發(fā)過(guò)程中為每位開(kāi)發(fā)人員配備

8、一位“用戶伙伴”，負(fù)責(zé)向他解釋行話和業(yè)務(wù)概念。用戶代言人可以擔(dān)當(dāng)這個(gè)角色。創(chuàng)建項(xiàng)目術(shù)語(yǔ)表定義應(yīng)用領(lǐng)域?qū)I(yè)名稱的術(shù)語(yǔ)表可以堿少誤解。術(shù)語(yǔ)表中包括同義詞、有多種含義的術(shù)語(yǔ)、以及既有特定領(lǐng)域的含義又有日常含義的術(shù)語(yǔ)。既可以是名詞又可以是動(dòng)詞的單詞，如“process”和“order”，尤其容易產(chǎn)生混淆。3.2 需求獲取第1章討論了3個(gè)不同層次的需求：業(yè)務(wù)需求、用戶需求和功能需求。這些需求在項(xiàng)目不同階段的來(lái)源不同，有著不同的受眾和目的，需要用不同的方式寫(xiě)入文檔。項(xiàng)目范圍內(nèi)的業(yè)務(wù)需求不能排斥任何必要的用戶需求，而且每項(xiàng)功能需求都應(yīng)該可以追溯到對(duì)應(yīng)的用戶需求。您還需要收集非功能需求，如對(duì)質(zhì)量和性能的要求。

9、在以下章節(jié)中介紹了有關(guān)這些主題的內(nèi)容：· 第3章· 第5章 第6章 第7章 第8章 第22章定義需求開(kāi)發(fā)過(guò)程將你的組織如何獲取和分析需求、編寫(xiě)規(guī)格說(shuō)明和驗(yàn)證需求的步驟編寫(xiě)成文檔。提供如何完成主要步驟的指導(dǎo)可以幫助分析員做好工作，還能夠使規(guī)劃項(xiàng)目的需卒尹發(fā)任務(wù)、進(jìn)度和所需的資源變得更為容易。編寫(xiě)前景和范圍文檔前景和范園（vision and scope）文檔包含了產(chǎn)品的業(yè)務(wù)需求。前景說(shuō)明使所有涉眾可以對(duì)產(chǎn)品的目標(biāo)達(dá)成共識(shí)。范圍則定義了需求是否屬于某個(gè)特定版本的界線。前景和范圍一起為如何評(píng)估提出的需求提供了參考。項(xiàng)目前景應(yīng)該在不同版本之間保持相對(duì)穩(wěn)定，但是每個(gè)版本需要有自己的項(xiàng)

10、目范圍聲明。確定用戶群和他們的特點(diǎn)將產(chǎn)品的用戶分成組，以避免出現(xiàn)某一用戶群的需求被忽略的情況。不同的用戶在很多方面存在著差異，例如：使用產(chǎn)品的頻率、所使用的產(chǎn)品功能、他們的優(yōu)先級(jí)以及熟練程度。詳細(xì)描述出他們的工作內(nèi)容、意見(jiàn)、工作地點(diǎn)及其個(gè)性特點(diǎn)將有助于實(shí)現(xiàn)更好的產(chǎn)品設(shè)計(jì)。為每類用戶選擇代言人為每類用戶選擇至少一位能夠準(zhǔn)確反映其需求的代言人。用戶代言人提供某一類用戶的需求，并代表他們作出決策。開(kāi)發(fā)內(nèi)部信息系統(tǒng)時(shí)這很容易做到，因?yàn)橛脩艟褪峭?。而開(kāi)發(fā)商業(yè)產(chǎn)品時(shí)，則要與主要的客戶或測(cè)試者建立起良好的合作關(guān)系，從而確定合適的用戶代言人。用戶代言人必須一直參與項(xiàng)目的開(kāi)發(fā)而且有權(quán)在用戶需求方面作出決策。建

11、立典型用戶的中心小組把產(chǎn)品早期版本或同類產(chǎn)品的用戶代表召集起來(lái)，收集他們對(duì)正在開(kāi)發(fā)的產(chǎn)品的功能和質(zhì)量特性的意見(jiàn)。這樣的中心小組對(duì)于商業(yè)開(kāi)發(fā)尤為有用，因?yàn)槟憧赡軗碛幸粋€(gè)龐大且多樣的客戶群。中心小組與用戶代言人不同，他們通常沒(méi)有決策權(quán)。與用戶代表溝通以確定用例與用戶代表溝通、了解他們需要使用軟件來(lái)完成的任務(wù)用例。討論用戶與可以完成這些任務(wù)的系統(tǒng)之間的交互方式。在編寫(xiě)用例的文檔時(shí)應(yīng)采用標(biāo)準(zhǔn)模板，并根據(jù)這些用例推導(dǎo)出功能需求。一種經(jīng)常用于政府項(xiàng)目的方法是定義一個(gè)業(yè)務(wù)概念（ConOps）文檔，它從用戶的觀點(diǎn)出發(fā)描述了新系統(tǒng)的特性（IEEE 1998a）。確定系統(tǒng)事件和響應(yīng)列出系統(tǒng)可能發(fā)生的外部事件以及對(duì)

12、每個(gè)事件所期待的響應(yīng)事件包括從外部硬件設(shè)備所接收的信號(hào)或數(shù)據(jù)，以及可以觸發(fā)響應(yīng)的臨時(shí)事件，例如你的系統(tǒng)在每晚同一時(shí)刻生成的外部數(shù)據(jù)輸入事件。業(yè)務(wù)事件可觸發(fā)業(yè)務(wù)應(yīng)用中的用例。召開(kāi)專門(mén)的需求獲取討論會(huì)專門(mén)的需求獲取討論會(huì)可以方便分析員和客戶進(jìn)行合作。它是研究用戶需求、編寫(xiě)需求文檔的一種十分有效的途徑（GottesdiCner 2002）。這種會(huì)議的典型例子包括聯(lián)合需求計(jì)劃（Join七Requircments P1anning，簡(jiǎn)稱JRP）會(huì)議和聯(lián)合應(yīng)用程序開(kāi)發(fā)（Joint App1icationDcvclopmcnt，簡(jiǎn)稱JAD）會(huì)議。觀察用戶工作的過(guò)程觀察用戶執(zhí)行業(yè)務(wù)任務(wù)的過(guò)程，能夠確定用戶對(duì)新

13、的應(yīng)用程序可能有哪些應(yīng)用。可以畫(huà)一張簡(jiǎn)單的工作流程圖（最好用數(shù)據(jù)流圖解）來(lái)描繪用戶什么時(shí)候擁有什么數(shù)據(jù)，以及怎樣使用這些數(shù)據(jù)。編制業(yè)務(wù)過(guò)程流程文檔將有助于您確定支持該業(yè)務(wù)過(guò)程的系統(tǒng)需求。您甚至可能性發(fā)現(xiàn)客戶并非真的需要一個(gè)全新的軟件系統(tǒng)就能達(dá)到他們的業(yè)務(wù)目標(biāo)。檢查當(dāng)前系統(tǒng)的問(wèn)題報(bào)告來(lái)進(jìn)一步完善需求客戶的問(wèn)題報(bào)告及補(bǔ)充需求提供了很多建議，抬出在新產(chǎn)品或新版本中應(yīng)添加哪些功能。負(fù)責(zé)提供支持及幫助的人能夠?yàn)閷?lái)開(kāi)發(fā)工作中的需求提供很有價(jià)值的信息?？珥?xiàng)目重用需求如果客戶要求的功能與已有產(chǎn)品的某項(xiàng)功能很相似，則可以查看需求（和客戶！）是否具有足夠的靈活性允許重用一些已有的組件。多個(gè)項(xiàng)目可以重用那些符合一

14、個(gè)組織的業(yè)務(wù)規(guī)則的需求。這類需求包括用于控制對(duì)應(yīng)用程序的訪問(wèn)的安全需求，符合政府法規(guī)（如殘疾人法）的需求等。3.3 需求分析需求分析包括對(duì)需求進(jìn)行推敲和潤(rùn)色以保證所有的涉眾人都能夠理解需求，以及仔細(xì)檢查找其中的錯(cuò)誤、疏漏和萁他缺陷。分析包括將高層的需求分解成具體細(xì)節(jié)、創(chuàng)建開(kāi)發(fā)原型，以及評(píng)估可行性和協(xié)商需求優(yōu)先級(jí)。其目的是開(kāi)發(fā)高質(zhì)量、內(nèi)容詳細(xì)的需求，讓管理者能夠?qū)?xiàng)目做出實(shí)際的評(píng)估，使技術(shù)人員能夠繼續(xù)進(jìn)行設(shè)計(jì)、開(kāi)發(fā)和測(cè)試。用多種方式來(lái)表達(dá)某些需求通常是很有幫助的例如，同時(shí)使用文本和圖形形式。這些不同的方法可以揭示出許多單獨(dú)一種方法所不能發(fā)現(xiàn)的問(wèn)題。多種方法將有助于所有涉眾就產(chǎn)品發(fā)布后他們將得到什

15、么達(dá)成共識(shí)（一個(gè)共享的視圖）。關(guān)于需求分析方法的更多討論可以在以下章節(jié)中找到： 第5章· 第10章 第11章 第13章 第14章· 第17章繪制關(guān)聯(lián)圖關(guān)聯(lián)圖是顯示新系統(tǒng)如何適應(yīng)它的環(huán)境的一個(gè)簡(jiǎn)單的分析模型。它定義了正在開(kāi)發(fā)的系統(tǒng)和系統(tǒng)的外部實(shí)體（如用戶，硬件設(shè)備和其他信息系統(tǒng)）之間的界線和接口。創(chuàng)建用戶界面和技術(shù)原型當(dāng)開(kāi)發(fā)人員或用戶對(duì)需求不能確定時(shí)，可構(gòu)建一個(gè)開(kāi)發(fā)原型個(gè)不完全的、可能的、初步的實(shí)現(xiàn)，以便使概念和可能性變得更為直觀明了。讓用戶評(píng)估原型能夠幫助項(xiàng)目涉眾對(duì)要解決的問(wèn)題形成更一致和正確的理解。分析需求的可行性在允許的成本和性能要求下，分析在指定的運(yùn)行環(huán)境下實(shí)現(xiàn)每項(xiàng)需

16、求的可行性。明確與每項(xiàng)需求實(shí)現(xiàn)相關(guān)的風(fēng)險(xiǎn)，包括與其他需求之間的沖突、對(duì)外界因素的依賴以及技術(shù)上的障礙。確定需求優(yōu)先級(jí)可采用分析方法確定產(chǎn)品功能、用例或單項(xiàng)需求的相對(duì)實(shí)現(xiàn)優(yōu)先級(jí)。以優(yōu)先級(jí)為基礎(chǔ)，確定各項(xiàng)功能或各組需求應(yīng)包括在哪個(gè)版本中。接受需求變更后，應(yīng)將每一項(xiàng)變更加入到將來(lái)的某一版本中，并在該版本的計(jì)劃中作出相應(yīng)的變化。在項(xiàng)目的整個(gè)開(kāi)發(fā)過(guò)程中，應(yīng)定期評(píng)估和調(diào)整優(yōu)先級(jí)，以適應(yīng)客戶需求、市場(chǎng)條件和業(yè)務(wù)目標(biāo)的變化，為需求建模較之SRS中的細(xì)節(jié)或原型提供的用戶界面視圖，圖形分析模型對(duì)需求的描述更為抽象。模型能夠揭示不正確的、不一致的、遺漏的或冗余的需求。這類模型包括數(shù)據(jù)流圖、實(shí)體關(guān)系圖、狀態(tài)轉(zhuǎn)換圖或狀

17、態(tài)圖、對(duì)話圖、類圖、序列圖、交互作用圖、決策表和決策樹(shù)等。創(chuàng)建數(shù)據(jù)字典數(shù)據(jù)字典中包括系統(tǒng)用到的所有數(shù)據(jù)項(xiàng)和結(jié)構(gòu)的定義。數(shù)據(jù)字典可使參與項(xiàng)目開(kāi)發(fā)的每個(gè)人都使用統(tǒng)一的數(shù)據(jù)定義。在需求階段，數(shù)據(jù)字典應(yīng)該定義問(wèn)題領(lǐng)域中的數(shù)據(jù)項(xiàng)以方便客戶和開(kāi)發(fā)團(tuán)隊(duì)之間的交流。將需求分解到子系統(tǒng)必須將包括多個(gè)子系統(tǒng)的復(fù)雜產(chǎn)品的需求分配到各個(gè)軟件、硬件以及人員子系統(tǒng)和部件中去（NclsCn 1990）。這種分配工作通常由系統(tǒng)工程師或架構(gòu)設(shè)計(jì)師來(lái)完成。應(yīng)用質(zhì)量功能調(diào)配質(zhì)量功能調(diào)配（QFD）是一種高級(jí)系統(tǒng)技術(shù)，它將產(chǎn)品功能、屬性與客戶的重要性聯(lián)系起來(lái)（ZultnCr L993；Pardcc 1996）。該技術(shù)提供了一種分析方法

18、以明確哪些功能最能滿足客戶的需要。QFD將需求分為3類：期望需求客戶或許并未提及，但若缺少卻會(huì)讓他們感到不滿意的需求；普通需求：額外需求實(shí)現(xiàn)了會(huì)給客戶帶來(lái)較高利益，未實(shí)現(xiàn)也不會(huì)受到責(zé)罰。3.4 規(guī)格說(shuō)明不管你如何獲得需求，都應(yīng)該將它們編成一致的、可訪問(wèn)、可檢查的文檔。可以用項(xiàng)目前景和范園文檔記錄業(yè)務(wù)需求。用戶需求通常使用用例或事件響應(yīng)表來(lái)表達(dá)。SRS中包含詳細(xì)的軟件的功能需求和非功能需求。編寫(xiě)需求說(shuō)明的方法在以下幾章中討論！ 第9章 第10章· 第12章采用SRS模板為組織定義一種標(biāo)準(zhǔn)模板用于編寫(xiě)軟件需求規(guī)約。該模板為記錄功能說(shuō)明和其他與需求相關(guān)的信息提供了統(tǒng)一的結(jié)構(gòu)。不必創(chuàng)建一種全

19、新的模板，只需改造一個(gè)已有的模板讓它可適合你的項(xiàng)目特點(diǎn)即可。許多組織都采用IEEE Standard 8301998（IEEE 1988b）中規(guī)定的SRS模板作為基礎(chǔ)；第10章中給出的模板就改造自該模板。如果你的組織開(kāi)展了多個(gè)不同種類和規(guī)模的項(xiàng)目，例如大型的新項(xiàng)目和小規(guī)模的版本改進(jìn)，應(yīng)該為每個(gè)項(xiàng)目定義一個(gè)合適的模板。模板和過(guò)程的規(guī)模都應(yīng)是可縮放的。確定需求來(lái)源為保證所有涉眾都明自SRS中為何包括這些需求，以及便于進(jìn)一步閽明需求，應(yīng)追溯每項(xiàng)需求的來(lái)源。結(jié)果可能是某項(xiàng)用例或其他客戶要求，也可能是更高層的系統(tǒng)需求、業(yè)務(wù)規(guī)則或其他外部來(lái)源。為每項(xiàng)需求記錄受其影響最大的涉眾，這樣，當(dāng)變更請(qǐng)求提上議程時(shí)，

20、你就可以知道該和誰(shuí)聯(lián)系?？梢酝ㄟ^(guò)使用跟蹤鏈或者定義需求屬性來(lái)確定需求來(lái)源。關(guān)于需求屬性的更多內(nèi)容可參見(jiàn)第18章。為需求分配惟一標(biāo)號(hào)可定義一種約定，用于為SRS中的每項(xiàng)需求提供一個(gè)惟一的識(shí)別標(biāo)號(hào)。這種約定應(yīng)該很健全，經(jīng)得起隨時(shí)間推移發(fā)生的對(duì)需求的增加、刪除和修改。為需求標(biāo)號(hào)使得需求可以被跟蹤，其變更可以被記錄。記錄業(yè)務(wù)規(guī)則業(yè)務(wù)規(guī)則包括公司章程、政府法規(guī)和計(jì)算機(jī)算法。之所以應(yīng)將業(yè)務(wù)規(guī)則從SRs中分離出來(lái)單獨(dú)形成文檔，是因?yàn)樗鼈兊拇嬖谕ǔ３隽颂囟?xiàng)目的范圍。某些業(yè)務(wù)規(guī)則將引出實(shí)施它們的功能需求，因而需要在這些需求和對(duì)應(yīng)的規(guī)則之間定義跟蹤鏈。定義質(zhì)量屬性在功能需求之外還應(yīng)考慮非功能的質(zhì)量屬性，運(yùn)會(huì)使

21、你的產(chǎn)品達(dá)到并超過(guò)客戶的要求。這些屬性包括性能、效率、可靠性、可用性等。應(yīng)該將質(zhì)量需求寫(xiě)入SRS文檔?？蛻魧?duì)這些質(zhì)量屬性的相對(duì)重要性的意見(jiàn)可以讓開(kāi)發(fā)者做出適當(dāng)?shù)脑O(shè)計(jì)決策。3.5 需求驗(yàn)證需求驗(yàn)證可確保需求聲明是正確的、具備了所需的質(zhì)量屬性，而且能夠滿足客戶的需要。SRS中有些需求讀起來(lái)感覺(jué)很好，可是當(dāng)開(kāi)發(fā)人員在實(shí)際工作中使用它們時(shí)就會(huì)出現(xiàn)問(wèn)題。根據(jù)需求編寫(xiě)測(cè)試用例時(shí)經(jīng)常會(huì)發(fā)現(xiàn)需求中的歧義和含糊不清的地方。只有糾正這些問(wèn)題，才能使需求成為設(shè)計(jì)和最終系統(tǒng)驗(yàn)收（通過(guò)系統(tǒng)測(cè)試或用戶接受度測(cè)試）的可靠基礎(chǔ)。第15章將對(duì)需求驗(yàn)證作進(jìn)一步的討論。審查需求文檔對(duì)需求文檔進(jìn)行正式審查是保證軟件質(zhì)量的有效手段之一

22、。應(yīng)由代表不同群體（如分析員、客戶、開(kāi)發(fā)人員和測(cè)試人員）的審查員組成審查小組，對(duì)SRS、分析模型和相關(guān)信息進(jìn)行仔細(xì)檢查，找出其中的缺陷和漏洞。在需求開(kāi)發(fā)的過(guò)程中進(jìn)行初步的評(píng)審也是大有裨益的。雖然需求審查并不是最容易實(shí)現(xiàn)的新實(shí)踐之一，但卻是最有價(jià)值的，因此立刻開(kāi)始進(jìn)行需求審查吧。測(cè)試需求應(yīng)根據(jù)用戶需求攤導(dǎo)出功能測(cè)試用例，以便記錄產(chǎn)品在特定條件下應(yīng)有的行為。與客戶一起對(duì)用例進(jìn)行走查，以確保他們反映了所期望的系統(tǒng)行為。從測(cè)試用例追溯到功能需求，以確保沒(méi)有忽略任何需求，而且每項(xiàng)需求都有其對(duì)應(yīng)的測(cè)試用例?？捎脺y(cè)試用例來(lái)驗(yàn)證分析模型和原型的正確性。定義合格標(biāo)準(zhǔn)讓用戶描述決定產(chǎn)品是否滿足他們的需求并適合使用

23、的標(biāo)準(zhǔn)。以使用情況為基礎(chǔ)進(jìn)行合格性測(cè)試（Hsia、Kung和Scll 1997）。3.6 需求管理一旦有了項(xiàng)目的初步需求，就必須處理好開(kāi)發(fā)過(guò)程中不可避免的來(lái)自客戶、管理層、營(yíng)銷部門(mén)、開(kāi)發(fā)團(tuán)隊(duì)以及其他群體的變更請(qǐng)求。要進(jìn)行有效的變更管理，必須建立一個(gè)過(guò)程，用于提請(qǐng)變更、評(píng)估變更的可能成本和對(duì)項(xiàng)目的影響。變更控制委員會(huì)（ChangeControl Board，簡(jiǎn)稱CCB）由主要涉眾組成，負(fù)責(zé)決定接受哪些需求變更。通過(guò)跟蹤每項(xiàng)需求在開(kāi)發(fā)和系統(tǒng)測(cè)試過(guò)程中的狀態(tài)就能洞察整個(gè)項(xiàng)目的狀態(tài)。建立良好的配置管理方法是進(jìn)行有效需求管理的前提。用來(lái)控制基本代碼的控制工具也可以管理需求文檔。需求管理所涉及的技術(shù)將在第

24、18章第21章中詳細(xì)介紹。定義需求變更控制過(guò)程建立一個(gè)用于提議、分析和解決需求變更的過(guò)程。通過(guò)這個(gè)過(guò)程管理所有提議的變更。商業(yè)化的問(wèn)題跟蹤工具可支持變更控制過(guò)程。成立變更控制委員會(huì)可授權(quán)由涉眾組成的小組作為變更控制委員會(huì)（CCB）來(lái)接收需求變更的請(qǐng)求，對(duì)它們進(jìn)行評(píng)估，決定接受或拒絕，并設(shè)置實(shí)現(xiàn)的優(yōu)先順序或者在哪個(gè)版本中實(shí)現(xiàn)。分析需求變更的影響對(duì)影響進(jìn)行分析有助于CCB做出明智的業(yè)務(wù)決策。應(yīng)該評(píng)估被提出的每項(xiàng)需求變更，從而確定它對(duì)項(xiàng)目的影響?？蓞⒄招枨蟾櫨仃囌页銎渌赡苄枰薷牡男枨?、設(shè)計(jì)元素、源代碼和測(cè)試用例。應(yīng)確定實(shí)現(xiàn)變更需要完成的任務(wù)，并評(píng)估完成這些任務(wù)所需要的工作量。建立基線和控制需求

25、文檔的版本基線是由已經(jīng)被提交到一個(gè)指定版本中的實(shí)現(xiàn)（implementation）的需求組成的。在需求被定為基線后，只能通過(guò)定義的變更控制過(guò)程來(lái)實(shí)現(xiàn)變更。應(yīng)該給每個(gè)版本的需求規(guī)恪說(shuō)明指定一個(gè)惟一的標(biāo)識(shí)，以避免需求草案與基線之間以及新舊版本之間的混淆。一種更好的方法是使用合適的配置管理工具，將需求文檔置于版本控制之下。維護(hù)需求變更的歷史記錄記錄需求規(guī)格說(shuō)明變更的日期、變更的內(nèi)容、變更的實(shí)施者和原因。版本控制工具或商業(yè)需求管理工具可以自動(dòng)完成這些任務(wù)。跟蹤每項(xiàng)需求的狀態(tài)建立一個(gè)數(shù)據(jù)庫(kù)，為每一項(xiàng)功能需求倮存一條記錄。保存每項(xiàng)需求的重要屬性，包括需求的狀態(tài)（例如已提議、已批準(zhǔn)、已實(shí)現(xiàn)或已驗(yàn)證），這樣在

26、任何時(shí)候都能掌握每個(gè)狀態(tài)類的需求數(shù)量。衡量需求的穩(wěn)定性記錄已設(shè)為基線的需求數(shù)，以及每周提議和批準(zhǔn)的需求的變更（增加，修改，刪除）數(shù)。過(guò)多的需求變更是一個(gè)“報(bào)警信號(hào)”，意味著問(wèn)題并未真正弄清楚，項(xiàng)目范圍沒(méi)有明確定義，業(yè)務(wù)規(guī)則變化過(guò)快，需求獲取過(guò)程中漏掉了很多需求，或政策變化太快。使用需求管理工具商業(yè)需求管理工具可用于在數(shù)據(jù)庫(kù)中存儲(chǔ)各種類型的需求?？梢詾槊宽?xiàng)需求定義屬性，跟蹤每項(xiàng)需求的狀態(tài)，并在需求和其他軟件開(kāi)發(fā)產(chǎn)品間建立跟蹤鏈。這項(xiàng)方法能夠幫助你實(shí)現(xiàn)本節(jié)中介紹的其他需求管理任務(wù)的自動(dòng)化。創(chuàng)建需求跟蹤矩陣建立一個(gè)表，把每項(xiàng)功能需求和實(shí)現(xiàn)它的設(shè)計(jì)和代碼部分、驗(yàn)證它的測(cè)試部分聯(lián)系起來(lái)。需求跟蹤矩陣還能

27、把功能需求和產(chǎn)生它的高層需求以及其他相關(guān)的需求聯(lián)系起來(lái)。應(yīng)該在開(kāi)發(fā)過(guò)程中就建立這個(gè)矩陣，而不要等到工程結(jié)束。3.7 項(xiàng)目管理軟件項(xiàng)目管理方法和項(xiàng)目的需求過(guò)程密切相關(guān)。應(yīng)根據(jù)需要實(shí)現(xiàn)的需求來(lái)規(guī)劃項(xiàng)目資源、進(jìn)度和承諾。需求變更會(huì)影響到這些項(xiàng)目計(jì)劃，因此項(xiàng)目計(jì)劃應(yīng)該預(yù)先為需求變更和范圍擴(kuò)大作一些準(zhǔn)備（WiegCrs 2o02d）。關(guān)于需求工程的項(xiàng)目管理方法，更多內(nèi)容可參考以下章節(jié)：· 第17章· 第18章· 第23章選擇合適的軟件開(kāi)發(fā)生命周期組織應(yīng)該定義多種開(kāi)發(fā)生命周期，以適應(yīng)不同的項(xiàng)目類型和不同程度的需求不確定性（McConncl1 1996）°項(xiàng)目經(jīng)理應(yīng)該

28、選擇和采用最適合他的項(xiàng)目的開(kāi)發(fā)周期。生命周期的定義中應(yīng)包括需求工程的活動(dòng)。如果在項(xiàng)目的早期幾乎沒(méi)有充分定義需求或范圍，應(yīng)計(jì)劃以小規(guī)模增量方式開(kāi)發(fā)產(chǎn)品，并且要在充分理解需求，具有強(qiáng)健、可修改的體系結(jié)構(gòu)基礎(chǔ)上進(jìn)行開(kāi)發(fā)?？赡艿脑?，可以實(shí)現(xiàn)一些特性集，這樣你可以周期性發(fā)行產(chǎn)品的一部分，并可盡早將它交付給客戶（Gilb 1998：Cockburn 2002）。根據(jù)需求制訂項(xiàng)目計(jì)劃當(dāng)范園和詳細(xì)的需求變得清楚時(shí)，應(yīng)反復(fù)斟酌項(xiàng)日的計(jì)劃和進(jìn)度表。通過(guò)評(píng)估所需的投入，根據(jù)最初產(chǎn)品前景和項(xiàng)目范圍開(kāi)始開(kāi)發(fā)功能需求。過(guò)早地以尚不明確的需求為基礎(chǔ)進(jìn)行開(kāi)銷和進(jìn)度評(píng)估是非常不可靠的，但是當(dāng)您對(duì)需求的理解加深時(shí)可以再來(lái)改進(jìn)你的

29、評(píng)估。需求變更時(shí)重新討論項(xiàng)目承諾當(dāng)你將新的需求合并到項(xiàng)目中時(shí)，應(yīng)估計(jì)一下你是否仍然可以利用可用資源兌現(xiàn)當(dāng)前的進(jìn)度和質(zhì)量承諾。如果不能，將項(xiàng)目的實(shí)際情況報(bào)告給管理層，協(xié)商制定新的、可行的承諾（Humphrey 199Fishcr、Ury和Patton 1991；Widgcrs 2002b）。如杲?jīng)]有協(xié)商成功，應(yīng)及時(shí)與管理者和客戶交流可能的結(jié)果，這樣他們就不會(huì)被意想不到的項(xiàng)目結(jié)果搞得暈頭轉(zhuǎn)向了。管理與需求相關(guān)的風(fēng)險(xiǎn)以及編寫(xiě)風(fēng)險(xiǎn)文檔確定與需求相關(guān)的風(fēng)險(xiǎn)并將它們編寫(xiě)成文檔是項(xiàng)目風(fēng)險(xiǎn)管理活動(dòng)的一部分?？山M織自由討論，找到方法來(lái)減輕或避免這些風(fēng)險(xiǎn)、實(shí)施減小風(fēng)險(xiǎn)的活動(dòng)，以及跟蹤它們的過(guò)程和效果。跟蹤需求工程

30、的投入記錄下你的團(tuán)隊(duì)在需求開(kāi)發(fā)和管理活動(dòng)上投入的工作量。使用這些數(shù)據(jù)來(lái)評(píng)定計(jì)劃的需求活動(dòng)是否如期完成，利用這些數(shù)據(jù)還可以為將來(lái)的項(xiàng)目更好地計(jì)劃所需的資源。另外，監(jiān)視需求工程活動(dòng)對(duì)項(xiàng)目的影響，這將有助于評(píng)估對(duì)需求工程的投資的回報(bào)。從其他項(xiàng)目的需求工程中積累經(jīng)驗(yàn)組建一個(gè)學(xué)術(shù)研究組織專門(mén)管理項(xiàng)目回顧（也稱為項(xiàng)目的審鬩）以收集有價(jià)值的信息。研究這些過(guò)去項(xiàng)目的有價(jià)值的需求和方法，可以幫助項(xiàng)目管理層和需求分析人員在以后的工作中更加充滿信心，得心應(yīng)手。3.8 開(kāi)始新實(shí)踐表3-2將本章中描述的需求工程方法，按照它們對(duì)大多數(shù)項(xiàng)目的相對(duì)影響以及實(shí)現(xiàn)的相對(duì)難度進(jìn)行分組。雖然所有的方法都是有益的，但你最好從那些對(duì)項(xiàng)目

31、的成功有很大影響并且相對(duì)容易實(shí)現(xiàn)的方法開(kāi)始。表3-2 實(shí)現(xiàn)需求工程的成功方法影 響難 度高中低高 定義需求開(kāi)發(fā)過(guò)程 以需求為基礎(chǔ)制定計(jì)劃 重新討論項(xiàng)目承諾 確定用例 指定質(zhì)量屬性 確定需求優(yōu)先級(jí) 采用SRS模板 定義變更控制過(guò)程 建立CCB 審查需求文檔 給子系統(tǒng)分配需求 記錄業(yè)務(wù)規(guī)則 在應(yīng)用領(lǐng)域培養(yǎng)開(kāi)發(fā)者 定義項(xiàng)呂前景和范圍 用戶群分類 繪制關(guān)聯(lián)圖 確定需用求來(lái)源 建立需求基線和控制版本低 對(duì)用戶群和管理者進(jìn)行需求培訓(xùn) 為需求建立模型 管理需求風(fēng)險(xiǎn) 使用需求管理工具 創(chuàng)建需求跟蹤能力矩陣 召開(kāi)需求獲取討論會(huì) 培訓(xùn)需求分析員 選擇用戶代言人 建立核心隊(duì)伍 創(chuàng)建原型 定義合格標(biāo)準(zhǔn) 進(jìn)行變更影響分

32、析 選擇適當(dāng)?shù)拈_(kāi)發(fā)周期 分析可行性 創(chuàng)建術(shù)語(yǔ)表 編寫(xiě)數(shù)據(jù)字典 觀察用戶執(zhí)行工作的過(guò)程 確定系統(tǒng)事件及響應(yīng) 為每項(xiàng)需求注上惟一的標(biāo)號(hào) 測(cè)試需求 跟蹤需求狀態(tài) 回顧過(guò)去的經(jīng)驗(yàn)教訓(xùn)低 重用需求 應(yīng)用質(zhì)量功能調(diào)配 衡量需求穩(wěn)定性 維護(hù)需求變更的歷史記錄 跟蹤投入需求工程中的工作量 檢查問(wèn)題報(bào)告不要試圖在下一個(gè)項(xiàng)目中使用所有這些方法，而是考慮將這些推薦方法作為您的需求工具包中新的成員。例如無(wú)論項(xiàng)目處于開(kāi)發(fā)周期中的哪個(gè)階段，都可以利用諸如處理變更管理等成功方法。當(dāng)開(kāi)始下一個(gè)項(xiàng)目或迭代時(shí)，收集方法是非常有用的。其他實(shí)踐仍然可能不適合你當(dāng)前的項(xiàng)目、公司文化或資源可用性。第22章描述了評(píng)估你的當(dāng)前需求工程方法的方法。它還將幫助你以本章描述的方法為基礎(chǔ)設(shè)計(jì)流程圖，以實(shí)現(xiàn)需求過(guò)程中某些需求改進(jìn)。3.9 需求開(kāi)發(fā)過(guò)程不要期望可以線性地、順序地完成獲取、分析、編寫(xiě)規(guī)格說(shuō)明和驗(yàn)證這些需求開(kāi)發(fā)活動(dòng)。實(shí)際上，這些活動(dòng)是交叉的、遞增的和反復(fù)的，如圖