淺談需求分析在軟件開(kāi)發(fā)中的重要性

1、-PAGE . z學(xué)生畢業(yè)設(shè)計(jì)論文報(bào)告系 別專(zhuān) 業(yè)班 級(jí)姓 名學(xué) 號(hào)設(shè)計(jì)論文題目淺談需求分析在軟件開(kāi)發(fā)過(guò)程中的重要性指導(dǎo)教師起迄日期畢業(yè)設(shè)計(jì)誠(chéng)信承諾書(shū)本人慎重承諾和聲明：我承諾在畢業(yè)設(shè)計(jì)過(guò)程中嚴(yán)格遵守學(xué)校有關(guān)規(guī)定，在指導(dǎo)教師的安排與指導(dǎo)下完成所規(guī)定的畢業(yè)設(shè)計(jì)工作，絕不弄虛作假，不請(qǐng)別人代做畢業(yè)設(shè)計(jì)或抄襲別人的成果。所撰寫(xiě)的畢業(yè)論文或畢業(yè)設(shè)計(jì)是在指導(dǎo)教師的指導(dǎo)下自主完成，文中所有引文或引用數(shù)據(jù)、圖表均注明來(lái)源，本人愿意為由此引起的后果承當(dāng)責(zé)任。學(xué)生簽名：日期：年月日畢業(yè)設(shè)計(jì)知識(shí)產(chǎn)權(quán)權(quán)屬聲明本人在教師指導(dǎo)下所完成的論文及設(shè)計(jì)成果、知識(shí)產(chǎn)權(quán)歸屬學(xué)校。學(xué)校享有以任何方式發(fā)表、復(fù)制、公開(kāi)閱覽、借閱以及申

2、請(qǐng)專(zhuān)利等權(quán)利。學(xué)生簽名：日期：年月日指導(dǎo)教師簽名： 日期：年月日淺談需求分析在軟件開(kāi)發(fā)過(guò)程中的重要性摘 要軟件需求分析是軟件工程過(guò)程中方案階段的一個(gè)決定性步驟，在這一步將把模糊的軟件概念轉(zhuǎn)變成具體的規(guī)格說(shuō)明，從而奠定了軟件開(kāi)發(fā)的根底。本文通過(guò)對(duì)需求的定義、需求的類(lèi)型、需求分析的任務(wù)、需求分析的方法、需求的變更以及應(yīng)用實(shí)例等幾個(gè)方面的介紹，對(duì)于在軟件開(kāi)發(fā)中做好需求分析有一定的借鑒作用。 關(guān) 鍵 字:軟件，開(kāi)發(fā)，需求分析 目錄 TOC o 1-3 h z u HYPERLINK l _Toc219261284第1章 緒論4HYPERLINK l _Toc2192612851.1引言4HYPERLI

3、NK l _Toc2192612861.2需求的定義4HYPERLINK l _Toc219261289第2章軟件需求分析的特點(diǎn)5HYPERLINK l _Toc2192612902.1用戶與開(kāi)發(fā)人員很難進(jìn)展交流5HYPERLINK l _Toc219261291HYPERLINK l _Toc2192612932.2用戶的需動(dòng)態(tài)變化的52.3 系統(tǒng)變更的代價(jià)呈非線性增長(zhǎng).5 HYPERLINK l _Toc219261296第3章 軟件需求分析過(guò)程6HYPERLINK l _Toc2192612973.1什么是軟件需求6HYPERLINK l _Toc2192612993.2需求過(guò)程中的角色

4、6HYPERLINK l _Toc2192613003.3 需求過(guò)程的迭代7HYPERLINK l _Toc2192613003.4 需求來(lái)源8HYPERLINK l _Toc2192613003.5 需求獲取方法.9HYPERLINK l _Toc2192613003.6 軟件需求表達(dá).9HYPERLINK l _Toc2192613003.7 需求評(píng)審.10HYPERLINK l _Toc2192613003.7.1 需求評(píng)審概述.10HYPERLINK l _Toc2192613003.7.2 需求評(píng)審過(guò)程.10HYPERLINK l _Toc219261296第4章 合格需求的標(biāo)準(zhǔn)13

5、HYPERLINK l _Toc219261322結(jié)論13HYPERLINK l _Toc219261324參考文獻(xiàn)14緒論引言軟件工程的開(kāi)發(fā)主要分為五個(gè)階段：需求分析階段、設(shè)計(jì)階段、編碼階段、測(cè)試階段和維護(hù)階段，需求調(diào)研和分析是軟件開(kāi)發(fā)的第一個(gè)階段。完善的軟件需求說(shuō)明是軟件開(kāi)發(fā)工程得以成功的根底。不管設(shè)計(jì)如何精心或者編碼如何巧妙，如果對(duì)軟件需求不加以明確規(guī)定，將使用戶感到失望，并給軟件開(kāi)發(fā)者帶來(lái)嚴(yán)重后果。據(jù)權(quán)威部門(mén)統(tǒng)計(jì)，目前軟件的成功率約為25%，75%的軟件是失敗的。在這75%的失敗中，約有50%以上的軟件是由于需求的原因造成的。另有資料說(shuō)明，軟件開(kāi)發(fā)工程中返工開(kāi)銷(xiāo)幾乎占開(kāi)發(fā)總費(fèi)用的一半，

6、而導(dǎo)致返工的主要原因是需求分析錯(cuò)誤或不明確，從而引發(fā)工程開(kāi)發(fā)中的一系列更改。成功的軟件需求分析不僅能提高軟件的成功率，而且能節(jié)省大量的資源，因此需求分析是軟件開(kāi)發(fā)的關(guān)鍵階段。需求的定義軟件產(chǎn)業(yè)存在的一個(gè)普遍問(wèn)題就是缺乏統(tǒng)一定義的名詞術(shù)語(yǔ)來(lái)描述我們的工作。客戶所定義的需求對(duì)開(kāi)發(fā)者似乎是一個(gè)較高層次的產(chǎn)品概念，而開(kāi)發(fā)人員所說(shuō)的需求對(duì)用戶來(lái)說(shuō)又像是詳細(xì)設(shè)計(jì)了。實(shí)際上，軟件需求包含著多個(gè)層次，不同層次的需求從不同角度與不同程度反映著細(xì)節(jié)問(wèn)題。 IEEE軟件工程標(biāo)準(zhǔn)詞匯表1997年將需求定義為： 1) 用戶解決問(wèn)題或到達(dá)目標(biāo)所需的條件或能力。 2) 系統(tǒng)或系統(tǒng)部件要滿足合同、標(biāo)準(zhǔn)、規(guī)或其它正式規(guī)定文檔所

7、需具有的條件或能力。 3) 一種反映上面1)或2)所描述的條件或能力的文檔說(shuō)明。 IEEE的定義包括從用戶角度系統(tǒng)的外部行為，以及從開(kāi)發(fā)者角度一些部特性來(lái)闡述需求，其關(guān)鍵的問(wèn)題是一定要編寫(xiě)需求文檔。 另外，還有其他幾種關(guān)于需求的定義： 需用戶所需要的并能觸發(fā)一個(gè)程序或系統(tǒng)開(kāi)發(fā)工作的說(shuō)明； 需從系統(tǒng)外部能發(fā)現(xiàn)系統(tǒng)所具有的滿足于用戶的特點(diǎn)、功能及屬性等； 需指明必須實(shí)現(xiàn)什么的規(guī)格說(shuō)明。它描述了系統(tǒng)的行為、特性或?qū)傩?，是在開(kāi)發(fā)過(guò)程中對(duì)系統(tǒng)的約束。 從以上的定義中，我們依然無(wú)法得到有關(guān)需求的清晰概念，真正的需求實(shí)際上存在人們的腦海中，任何文檔形式的需求例如：需求規(guī)格說(shuō)明僅是一個(gè)模型或一種表達(dá)，但是編寫(xiě)

8、出高質(zhì)量的需求規(guī)格說(shuō)明書(shū)在需求分析階段還是關(guān)鍵。 需求分析奠定了軟件工程和工程管理的根底。我們?cè)诮ㄔ燔浖到y(tǒng)這座大廈的時(shí)候，如果需求分析的根底不夠堅(jiān)實(shí)和結(jié)實(shí)，則往往會(huì)導(dǎo)致軟件系統(tǒng)問(wèn)題百出，甚至被馬上丟棄。在建造軟件系統(tǒng)的過(guò)程中，如果我們經(jīng)常習(xí)慣地沿用一些不規(guī)的方法，其后果便是產(chǎn)生一條鴻溝開(kāi)發(fā)者開(kāi)發(fā)的與用戶所想得到的軟件存在著巨大的期望差異。 因此需求這個(gè)名詞的定義不僅僅是從用戶角度對(duì)系統(tǒng)外部行為的描述，以及從開(kāi)發(fā)人員角度對(duì)系統(tǒng)部特性的描述，其關(guān)鍵的一點(diǎn)是需求必須文檔化。第二章 軟件需求分析的特點(diǎn)2.1用戶與開(kāi)發(fā)人員很難進(jìn)展交流在軟件生命周期中，其他4個(gè)階段都是面向軟件技術(shù)方面的，只有本階段是面

9、向用戶的。需求分析是對(duì)用戶的業(yè)務(wù)活動(dòng)進(jìn)展分析，以便明確在用戶的業(yè)務(wù)環(huán)境中軟件系統(tǒng)應(yīng)該做什么。但是在開(kāi)場(chǎng)時(shí)，開(kāi)發(fā)人員和用戶雙方都不能準(zhǔn)確地提出系統(tǒng)要做什么，因?yàn)檐浖_(kāi)發(fā)人員不是用戶問(wèn)題領(lǐng)域的專(zhuān)家，不熟悉用戶的業(yè)務(wù)活動(dòng)和業(yè)務(wù)環(huán)境，又不可能在短期搞清楚；而用戶不熟悉計(jì)算機(jī)應(yīng)用的有關(guān)問(wèn)題。由于雙方互相不了解對(duì)方的工作，又缺乏共同語(yǔ)言，所以在交流時(shí)存在著隔膜。2.2用戶的需動(dòng)態(tài)變化的對(duì)于一個(gè)大型而復(fù)雜的軟件系統(tǒng)，用戶很難準(zhǔn)確、完整地提出它的功能和性能要求。一開(kāi)場(chǎng)只能提出一個(gè)大概、模糊的功能，只有經(jīng)過(guò)長(zhǎng)時(shí)間的反復(fù)認(rèn)識(shí)才逐步明確。有時(shí)進(jìn)入到設(shè)計(jì)、編程階段才能明確，更有甚者，到開(kāi)發(fā)后期還在提新的要求。這無(wú)疑給

10、軟件開(kāi)發(fā)帶來(lái)困難。2.3系統(tǒng)變更的代價(jià)呈非線性增長(zhǎng)需求分析是軟件開(kāi)發(fā)的根底。假定在該階段發(fā)現(xiàn)一個(gè)錯(cuò)誤，解決它需要用一個(gè)小時(shí)的時(shí)間，到設(shè)計(jì)、編程、測(cè)試和維護(hù)階段解決，則要花費(fèi)2.5、5、25甚至100倍的時(shí)間。第三章 軟件需求分析過(guò)程3.1 什么是軟件需求從根本上講，軟件需求就是為了解決現(xiàn)實(shí)世界中的特定問(wèn)題，軟件必須展現(xiàn)的屬性。軟件需求包括兩局部：功能性需求和非功能性需求。雖然功能性需對(duì)軟件系統(tǒng)的一項(xiàng)根本需求，但卻并不是唯一的需求。除功能性需求外，軟件質(zhì)量屬性的特性，稱為系統(tǒng)的非功能性需求。這些特性包括：系統(tǒng)的易用性、執(zhí)行速度、可靠性，處理異常情況的能力與方式等。在決定系統(tǒng)的成功或失敗的因素中，

11、滿足非功能性需求往往比滿足功能性需求更為重要。軟件需求的屬性包括可驗(yàn)證性、優(yōu)先級(jí)、唯一性和定量化。1可驗(yàn)證性可驗(yàn)證性是軟件需求的根本屬性。軟件需求必須是可驗(yàn)證的，否則軟件的評(píng)審和測(cè)試就沒(méi)有相應(yīng)的依據(jù)。2優(yōu)先性軟件需求具有優(yōu)先級(jí)，應(yīng)該能夠在有限的資源資金、人員、技術(shù)情況下進(jìn)展取舍。3唯一性軟件需求應(yīng)唯一地標(biāo)識(shí)出來(lái)，以便在軟件配置管理和整個(gè)軟件生命周期中進(jìn)展管理。4定量化軟件需求應(yīng)盡可能地表述清楚，沒(méi)有二義性，進(jìn)展適當(dāng)?shù)牧炕?，?yīng)防止模糊、無(wú)法測(cè)試、無(wú)法驗(yàn)證的需求出現(xiàn)。軟件質(zhì)量的可靠性和用戶界面的友好性等非功能性需求的量化尤為重要。例如，系統(tǒng)應(yīng)支持2000個(gè)并發(fā)用戶，系統(tǒng)回應(yīng)時(shí)間應(yīng)低于10秒，這就是

12、需求的量化。3.2 需求過(guò)程中的角色需求過(guò)程涉及各種角色的人員。需求人員應(yīng)協(xié)調(diào)軟件開(kāi)發(fā)人員和各領(lǐng)域的專(zhuān)家共同完成需求過(guò)程。軟件的涉眾牽涉到的角色隨工程的不同而不同，但至少包括用戶操作人員和客戶。典型的需求過(guò)程中的角色如表3-2所示。表3-2 需求過(guò)程中的角色角色名稱描 述用戶指直接操作軟件的人員，他們通常具有不同的業(yè)務(wù)角色，具有不同的業(yè)務(wù)需求客戶指軟件開(kāi)發(fā)的委托方或軟件市場(chǎng)的目標(biāo)客戶市場(chǎng)分析人員對(duì)于沒(méi)有具體客戶的通用軟件，市場(chǎng)分析人員將提供市場(chǎng)需要，并對(duì)實(shí)際客戶進(jìn)展模擬系統(tǒng)分析師對(duì)于類(lèi)似的工程，系統(tǒng)分析師將對(duì)以前系統(tǒng)進(jìn)展評(píng)估，判斷是否存在重用的可能對(duì)于涉眾的各種需求通常很難完全滿足，系統(tǒng)分析師

13、應(yīng)根據(jù)預(yù)算、技術(shù)等條件進(jìn)展取舍。3.3 需求過(guò)程的迭代軟件需求分析是一個(gè)不斷認(rèn)識(shí)和逐步細(xì)化的過(guò)程。該過(guò)程將軟件方案階段所確定的軟件圍工作圍逐步細(xì)化到可詳細(xì)定義的程度，并分析出各種不同的軟件元素，然后為這些元素找到可行的解決方法。需求過(guò)程要適應(yīng)客戶和工程的環(huán)境，并作為配置項(xiàng)納入配置管理。關(guān)于配置管理的具體容我們將在后面第8章中詳細(xì)講解。當(dāng)前的軟件業(yè)面臨著巨大競(jìng)爭(zhēng)壓力，要求軟件企業(yè)有更低的構(gòu)建本錢(qián)和更短的開(kāi)發(fā)周期。有些工程受環(huán)境的影響很大，有些工程是對(duì)原有工程的升級(jí)，有些工程客戶要求在指定的架構(gòu)下完成。在工程初期，客戶不能完全確定需要什么，對(duì)計(jì)算機(jī)的能力和限制不甚了解，所以需求過(guò)程很難是一步到位的

14、過(guò)程。隨著工程的深入，需求將隨時(shí)間變化而發(fā)生變化。因此，需求過(guò)程是一個(gè)迭代的過(guò)程，每次迭代都提供更高質(zhì)量和更詳細(xì)的軟件需求。這種迭代會(huì)給工程帶來(lái)一定的風(fēng)險(xiǎn)，上一次迭代的設(shè)計(jì)實(shí)現(xiàn)可能會(huì)因?yàn)樾枨笕狈Χ煌品?。但是，系統(tǒng)分析師應(yīng)根據(jù)工程方案，在給定的資源條件下得到盡可能高質(zhì)量的需求。在很多情況下，對(duì)需求的理解會(huì)隨著設(shè)計(jì)和實(shí)現(xiàn)的過(guò)程而不斷深入，這也會(huì)導(dǎo)致在軟件生命周期的后期重新修訂軟件需求。原因可能來(lái)自于錯(cuò)誤的分析、客戶環(huán)境和業(yè)務(wù)流程的改變、市場(chǎng)趨勢(shì)的變化等。無(wú)論什么原因，系統(tǒng)分析師應(yīng)認(rèn)識(shí)到需求變化的必然性，并采取相應(yīng)的措施減少需求變更對(duì)軟件系統(tǒng)的影響。進(jìn)展變更的需求必須經(jīng)過(guò)仔細(xì)的需求評(píng)審、需求跟蹤和

15、比擬分析后才能實(shí)施。3.4 需求來(lái)源理解問(wèn)題域的第一步是提取需求，即確定需求的來(lái)源，識(shí)別軟件的涉眾，確立開(kāi)發(fā)團(tuán)隊(duì)與客戶間的關(guān)系。提取需求時(shí)，要求用戶與開(kāi)發(fā)人員之間保持良好的溝通。軟件的需求來(lái)源很多，我們要盡可能多地識(shí)別顯式的來(lái)源和潛在的來(lái)源，并評(píng)估這些來(lái)源對(duì)系統(tǒng)的影響。典型的來(lái)源包括以下5種。1系統(tǒng)目的系統(tǒng)目的是指軟件的整體目的或高層的目標(biāo)。這是進(jìn)展軟件開(kāi)發(fā)的動(dòng)機(jī)，但它們通常表達(dá)比擬模糊。系統(tǒng)分析師需要仔細(xì)地評(píng)估這些目標(biāo)的價(jià)值和本錢(qián)，對(duì)系統(tǒng)的整體目標(biāo)進(jìn)展可行性研究。2行業(yè)知識(shí)系統(tǒng)分析師需要獲取業(yè)務(wù)領(lǐng)域的相關(guān)知識(shí)。因?yàn)樯姹妼?duì)于通用的行業(yè)知識(shí)會(huì)一概而過(guò)，一些行業(yè)慣例需要系統(tǒng)分析師根據(jù)環(huán)境進(jìn)展推斷。

16、當(dāng)需求發(fā)生矛盾時(shí)，系統(tǒng)分析師可以利用行業(yè)知識(shí)對(duì)各種需求進(jìn)展權(quán)衡。3軟件涉眾應(yīng)充分考慮不同軟件涉眾的需求，如果只強(qiáng)調(diào)*一角色的需求，忽略其他角色的需求，往往將導(dǎo)致軟件系統(tǒng)的失敗。系統(tǒng)分析師應(yīng)從不同涉眾的角度去識(shí)別、表述他們的需求。用戶的文化差異、客戶的組織構(gòu)造，常常會(huì)是系統(tǒng)難以正常實(shí)施的原因。4運(yùn)行環(huán)境軟件的運(yùn)行環(huán)境包括地域限制、實(shí)時(shí)性要求和網(wǎng)絡(luò)性能等。系統(tǒng)的可行性和軟件架構(gòu)都依賴于這些環(huán)境需求。5組織環(huán)境軟件作為一個(gè)組織的業(yè)務(wù)流程支持工具，受到組織構(gòu)造、企業(yè)文化和部政策的影響。軟件的需求也與組織構(gòu)造、企業(yè)文化和部政策有關(guān)。3.5 需求獲取方法常用的需求獲取方法有：1實(shí)地參加 通過(guò)親身參加業(yè)務(wù)工

17、作來(lái)了解業(yè)務(wù)活動(dòng)的情況。這種方法可以比擬準(zhǔn)確地理解用戶的需求，但比擬消耗時(shí)間。2開(kāi)調(diào)查會(huì) 通過(guò)與用戶座談來(lái)了解業(yè)務(wù)活動(dòng)情況及用戶需求。座談時(shí)，參加者之間可以相互啟發(fā)。3請(qǐng)專(zhuān)人介紹4面談對(duì)*些調(diào)查中的問(wèn)題，可以找專(zhuān)人詢問(wèn)。5設(shè)計(jì)調(diào)查表請(qǐng)用戶填寫(xiě) 如果調(diào)查表設(shè)計(jì)得合理，這種方法是很有效的，也很易于被用戶承受。6查閱記錄 查閱與原系統(tǒng)有關(guān)的數(shù)據(jù)記錄，包括原始單據(jù)、賬簿、報(bào)表等。 通過(guò)調(diào)查了解獲取了用戶需求后，還需要進(jìn)一步分析和表達(dá)用戶的需求。3.6 軟件需求表達(dá)如何有效地表達(dá)軟件需求？我們這里建議使用用例建模技術(shù)。用例建模技術(shù)是十多年來(lái)最重要的需求分析技術(shù)，在保障全球各類(lèi)軟件的成功開(kāi)發(fā)中發(fā)揮了極其重

18、要的作用。實(shí)踐證明，用例技術(shù)是迄今為止最為深刻、準(zhǔn)確和有效的系統(tǒng)功能需求描述方法。功能需指系統(tǒng)輸入到輸出的映射，以及它們的不同組合，任何功能必然要通過(guò)外部環(huán)境與系統(tǒng)之間的交互才能完成，因此，我們可以在容和形式上把用例和系統(tǒng)的功能需求等同起來(lái)。用例建模技術(shù)不同于構(gòu)造化功能分解的特點(diǎn)有：1顯式地表達(dá)用戶的任務(wù)目標(biāo)層次，突出系統(tǒng)行為與用戶利益間的關(guān)系。2通過(guò)描述執(zhí)行實(shí)例情節(jié)交互行為序列、正常/非正常事件流，能夠完整地反映軟件系統(tǒng)用以支持特定功能的行為。3以契約前/后置條件等的形式突出了用戶和系統(tǒng)之間常常被忽略的背后關(guān)系。4部署約束等非功能需求與系統(tǒng)行為直接綁定，能夠更準(zhǔn)確地表達(dá)此類(lèi)需求。3.7 需求

19、評(píng)審 需求評(píng)審概述需求評(píng)審是一項(xiàng)精益求精的技術(shù)，它主要由非軟件開(kāi)發(fā)人員來(lái)進(jìn)展。通過(guò)評(píng)審發(fā)現(xiàn)二義性的或不確定的需求，還有那些實(shí)際上是設(shè)計(jì)規(guī)格說(shuō)明的所謂的需求，這些需求是不能作為設(shè)計(jì)根底和依據(jù)的。需求評(píng)審也為風(fēng)險(xiǎn)承當(dāng)者們提供了在特定問(wèn)題上達(dá)成共識(shí)的方法。需求評(píng)審可以分為非正式評(píng)審和正式評(píng)審。 非正式評(píng)審：可以根據(jù)個(gè)人愛(ài)好的方式進(jìn)展評(píng)審，包括在任何場(chǎng)合的交流、征求意見(jiàn)。它是非系統(tǒng)化的、不徹底的，或者在實(shí)施過(guò)程中具有不一致性。非正式評(píng)審不需要記錄備案，沒(méi)有人對(duì)提出的意見(jiàn)負(fù)責(zé)。 正式評(píng)審：正式技術(shù)評(píng)審的最好類(lèi)型叫做審查，它遵循預(yù)先定義好的一系列步驟、過(guò)程及規(guī)定的方法和要求進(jìn)展，評(píng)審容需要記錄在案，正式評(píng)

20、審小組的成員對(duì)評(píng)審的質(zhì)量負(fù)責(zé)。 需求評(píng)審過(guò)程1確定參與者 審查參與者必須代表3個(gè)方面的觀點(diǎn)： 需求提出人員和產(chǎn)品代表者的觀點(diǎn)； 需求分析、開(kāi)發(fā)、管理人員的觀點(diǎn)； 軟件設(shè)計(jì)、開(kāi)發(fā)、測(cè)試、管理人員的觀點(diǎn)。 審查組中的審查人員應(yīng)限制在7個(gè)人左右或者更少。 審查的工作根底是軟件需求規(guī)格說(shuō)明書(shū)。2參與者扮演的角色 創(chuàng)立或維護(hù)正在被審查的產(chǎn)品。作者在審查中卻起著被動(dòng)的作用，作者經(jīng)?？梢园l(fā)現(xiàn)其他審查員沒(méi)有覺(jué)察到的錯(cuò)誤。 協(xié)調(diào)者：與作者一起為審查制訂方案，組織與協(xié)調(diào)各種活動(dòng)，并且推進(jìn)審查會(huì)的進(jìn)展。催促作者對(duì)需求文檔做出建議性的更改，以保證向執(zhí)行者明確說(shuō)明在審查過(guò)程中提出的問(wèn)題和缺陷。 讀者：扮演審查員的角色。

21、在審查會(huì)進(jìn)展期間，讀者一次審查規(guī)格說(shuō)明中的一塊容，并做出解釋?zhuān)以试S其他審查員在審查時(shí)提出問(wèn)題。對(duì)于一份需求規(guī)格說(shuō)明，審查員每次必須對(duì)需求給出注解或一個(gè)簡(jiǎn)短評(píng)論。通過(guò)用自己的話來(lái)述，讀者可能做出與其他審查員不同的解釋?zhuān)@將有利于發(fā)現(xiàn)二義性或可能的錯(cuò)誤。 記錄員：用標(biāo)準(zhǔn)化的形式記錄在審查會(huì)中提出的問(wèn)題和缺陷。3進(jìn)入和退出審查的標(biāo)準(zhǔn) 文檔進(jìn)入審查的標(biāo)準(zhǔn)： 文檔符合標(biāo)準(zhǔn)模板； 文檔已經(jīng)做過(guò)拼寫(xiě)檢查和語(yǔ)法檢查； 作者已經(jīng)檢查了文檔在版面上所存在的錯(cuò)誤； 已經(jīng)獲得了審查員所需要的先前系統(tǒng)的運(yùn)行資料或確認(rèn)所需要的參考文檔，例如系統(tǒng)需求規(guī)格說(shuō)明； 在文檔中打印了行序號(hào)以方便對(duì)特定位置的查閱和標(biāo)記； 所有未

22、解決的問(wèn)題都被標(biāo)記為T(mén)BD待確定； 文檔中使用到的術(shù)語(yǔ)詞匯表已全部進(jìn)展了說(shuō)明。 文檔退出審查的標(biāo)準(zhǔn)： 已經(jīng)明確闡述了審查員提出的所有問(wèn)題； 已經(jīng)正確修改了文檔； 修訂過(guò)的文檔已經(jīng)進(jìn)展了拼寫(xiě)檢查和語(yǔ)法檢查； 所有TBD的問(wèn)題已經(jīng)全部解決，或者已經(jīng)記錄下每個(gè)待確定問(wèn)題的解決過(guò)程、目標(biāo)日期和提出問(wèn)題的人； 文檔已經(jīng)錄入工程的配置管理系統(tǒng)； 已將審查過(guò)的資料送到有關(guān)歸檔部門(mén)。4需求審查清單 軟件需求規(guī)格說(shuō)明書(shū)審查清單： 組織和完整性； 正確性； 質(zhì)量屬性； 可跟蹤性； 特殊的問(wèn)題。 使用實(shí)例審查清單： Use Case是否是獨(dú)立的分散任務(wù)； Use Case的目標(biāo)或價(jià)值度量是否明確； Use Case給操作者帶來(lái)的益處是否明確； Use Case是否處于抽象級(jí)別上，而不具有詳細(xì)的情節(jié)； Use Case中是否不包含設(shè)計(jì)和實(shí)現(xiàn)的細(xì)節(jié)； 是否記錄了所有可能的可選過(guò)程； 是否記錄了所有可能的例外條件； 是否存在一些普通的動(dòng)作序列可以分解成獨(dú)立的Use Case； 是否簡(jiǎn)明書(shū)寫(xiě)、無(wú)二義性和完整地記錄了每個(gè)過(guò)程的對(duì)話； Use Case中的每個(gè)操作和步驟是否都與所執(zhí)行的任務(wù)相關(guān)； Use Case中定義的每個(gè)過(guò)程是否都可行；