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

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

2、請專利等權(quán)利。學(xué)生簽名：日期：年月日指導(dǎo)教師簽名： 日期：年月日淺談需求分析在軟件開發(fā)過程中的重要性摘 要軟件需求分析是軟件工程過程中方案階段的一個決定性步驟，在這一步將把模糊的軟件概念轉(zhuǎn)變成具體的規(guī)格說明，從而奠定了軟件開發(fā)的根底。本文通過對需求的定義、需求的類型、需求分析的任務(wù)、需求分析的方法、需求的變更以及應(yīng)用實(shí)例等幾個方面的介紹，對于在軟件開發(fā)中做好需求分析有一定的借鑒作用。 關(guān) 鍵 字:軟件，開發(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用戶與開發(fā)人員很難進(jìn)展交流5HYPERLINK l _Toc219261291HYPERLINK l _Toc2192612932.2用戶的需動態(tài)變化的52.3 系統(tǒng)變更的代價呈非線性增長.5 HYPERLINK l _Toc219261296第3章 軟件需求分析過程6HYPERLINK l _Toc2192612973.1什么是軟件需求6HYPERLINK l _Toc2192612993.2需求過程中的角色

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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