畢業(yè)論文-淺談需求分析在軟件開(kāi)發(fā)中的重要性

畢業(yè)設(shè)計(jì)說(shuō)明書(shū)PAGEPAGE1-學(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ān)責(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)閱覽、借閱以及申請(qǐng)專(zhuān)利等權(quán)利。學(xué)生簽名：日期：年月日指導(dǎo)教師簽名：日期：年月日淺談需求分析在軟件開(kāi)發(fā)過(guò)程中的重要性從以上的定義中，我們依然無(wú)法得到有關(guān)“需求”的清晰概念，真正的“需求”實(shí)際上存在人們的腦海中，任何文檔形式的需求（例如：需求規(guī)格說(shuō)明）僅是一個(gè)模型或一種敘述，但是編寫(xiě)出高質(zhì)量的需求規(guī)格說(shuō)明書(shū)在需求分析階段還是關(guān)鍵。需求分析奠定了軟件工程和項(xiàng)目管理的基礎(chǔ)。我們?cè)诮ㄔ燔浖到y(tǒng)這座大廈的時(shí)候，如果需求分析的基礎(chǔ)不夠堅(jiān)實(shí)和牢固，那么往往會(huì)導(dǎo)致軟件系統(tǒng)問(wèn)題百出，甚至被馬上丟棄。在建造軟件系統(tǒng)的過(guò)程中，如果我們經(jīng)常習(xí)慣地沿用一些不規(guī)范的方法，其后果便是產(chǎn)生一條鴻溝──開(kāi)發(fā)者開(kāi)發(fā)的與用戶(hù)所想得到的軟件存在著巨大的“期望差異”。因此“需求”這個(gè)名詞的定義不僅僅是從用戶(hù)角度對(duì)系統(tǒng)外部行為的描述，以及從開(kāi)發(fā)人員角度對(duì)系統(tǒng)內(nèi)部特性的描述，其關(guān)鍵的一點(diǎn)是“需求”必須文檔化。第二章軟件需求分析的特點(diǎn)2.1用戶(hù)與開(kāi)發(fā)人員很難進(jìn)行交流在軟件生命周期中，其他4個(gè)階段都是面向軟件技術(shù)方面的，只有本階段是面向用戶(hù)的。需求分析是對(duì)用戶(hù)的業(yè)務(wù)活動(dòng)進(jìn)行分析，以便明確在用戶(hù)的業(yè)務(wù)環(huán)境中軟件系統(tǒng)應(yīng)該“做什么”。但是在開(kāi)始時(shí)，開(kāi)發(fā)人員和用戶(hù)雙方都不能準(zhǔn)確地提出系統(tǒng)要“做什么”，因?yàn)檐浖_(kāi)發(fā)人員不是用戶(hù)問(wèn)題領(lǐng)域的專(zhuān)家，不熟悉用戶(hù)的業(yè)務(wù)活動(dòng)和業(yè)務(wù)環(huán)境，又不可能在短期內(nèi)搞清楚；而用戶(hù)不熟悉計(jì)算機(jī)應(yīng)用的有關(guān)問(wèn)題。由于雙方互相不了解對(duì)方的工作，又缺乏共同語(yǔ)言，所以在交流時(shí)存在著隔閡。2.2用戶(hù)的需求是動(dòng)態(tài)變化的對(duì)于一個(gè)大型而復(fù)雜的軟件系統(tǒng)，用戶(hù)很難精確、完整地提出它的功能和性能要求。一開(kāi)始只能提出一個(gè)大概、模糊的功能，只有經(jīng)過(guò)長(zhǎng)時(shí)間的反復(fù)認(rèn)識(shí)才逐步明確。有時(shí)進(jìn)入到設(shè)計(jì)、編程階段才能明確，更有甚者，到開(kāi)發(fā)后期還在提新的要求。這無(wú)疑給軟件開(kāi)發(fā)帶來(lái)困難。2.3系統(tǒng)變更的代價(jià)呈非線(xiàn)性增長(zhǎng)需求分析是軟件開(kāi)發(fā)的基礎(chǔ)。假定在該階段發(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ì)量屬性的特性，稱(chēng)為系統(tǒng)的非功能性需求。這些特性包括：系統(tǒng)的易用性、執(zhí)行速度、可靠性，處理異常情況的能力與方式等。在決定系統(tǒng)的成功或失敗的因素中，滿(mǎn)足非功能性需求往往比滿(mǎn)足功能性需求更為重要。軟件需求的屬性包括可驗(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ì)量的可靠性和用戶(hù)界面的友好性等非功能性需求的量化尤為重要。例如，系統(tǒng)應(yīng)支持2000個(gè)并發(fā)用戶(hù)，系統(tǒng)回應(yīng)時(shí)間應(yīng)低于10秒，這就是需求的量化。3.2需求過(guò)程中的角色需求過(guò)程涉及各種角色的人員。需求人員應(yīng)協(xié)調(diào)軟件開(kāi)發(fā)人員和各領(lǐng)域內(nèi)的專(zhuān)家共同完成需求過(guò)程。軟件的涉眾（牽涉到的角色）隨項(xiàng)目的不同而不同，但至少包括用戶(hù)（操作人員）和客戶(hù)。典型的需求過(guò)程中的角色如表3-2所示。表3-2

需求過(guò)程中的角色角色名稱(chēng)描

述用戶(hù)指直接操作軟件的人員，他們通常具有不同的業(yè)務(wù)角色，具有不同的業(yè)務(wù)需求客戶(hù)指軟件開(kāi)發(fā)的委托方或軟件市場(chǎng)的目標(biāo)客戶(hù)市場(chǎng)分析人員對(duì)于沒(méi)有具體客戶(hù)的通用軟件，市場(chǎng)分析人員將提供市場(chǎng)需要，并對(duì)實(shí)際客戶(hù)進(jìn)行模擬系統(tǒng)分析師對(duì)于類(lèi)似的項(xiàng)目，系統(tǒng)分析師將對(duì)以前系統(tǒng)進(jìn)行評(píng)估，判斷是否存在重用的可能對(duì)于涉眾的各種需求通常很難完全滿(mǎn)足，系統(tǒng)分析師應(yīng)根據(jù)預(yù)算、技術(shù)等條件進(jìn)行取舍。3.3需求過(guò)程的迭代軟件需求分析是一個(gè)不斷認(rèn)識(shí)和逐步細(xì)化的過(guò)程。該過(guò)程將軟件計(jì)劃階段所確定的軟件范圍（工作范圍）逐步細(xì)化到可詳細(xì)定義的程度，并分析出各種不同的軟件元素，然后為這些元素找到可行的解決辦法。需求過(guò)程要適應(yīng)客戶(hù)和項(xiàng)目的環(huán)境，并作為配置項(xiàng)納入配置管理。關(guān)于配置管理的具體內(nèi)容我們將在后面第8章中詳細(xì)講解。當(dāng)前的軟件業(yè)面臨著巨大競(jìng)爭(zhēng)壓力，要求軟件企業(yè)有更低的構(gòu)建成本和更短的開(kāi)發(fā)周期。有些項(xiàng)目受環(huán)境的影響很大，有些項(xiàng)目是對(duì)原有項(xiàng)目的升級(jí)，有些項(xiàng)目客戶(hù)要求在指定的架構(gòu)下完成。在項(xiàng)目初期，客戶(hù)不能完全確定需要什么，對(duì)計(jì)算機(jī)的能力和限制不甚了解，所以需求過(guò)程很難是一步到位的過(guò)程。隨著項(xiàng)目的深入，需求將隨時(shí)間變化而發(fā)生變化。因此，需求過(guò)程是一個(gè)迭代的過(guò)程，每次迭代都提供更高質(zhì)量和更詳細(xì)的軟件需求。這種迭代會(huì)給項(xiàng)目帶來(lái)一定的風(fēng)險(xiǎn)，上一次迭代的設(shè)計(jì)實(shí)現(xiàn)可能會(huì)因?yàn)樾枨蟛蛔愣煌品?。但是，系統(tǒng)分析師應(yīng)根據(jù)項(xiàng)目計(jì)劃，在給定的資源條件下得到盡可能高質(zhì)量的需求。在很多情況下，對(duì)需求的理解會(huì)隨著設(shè)計(jì)和實(shí)現(xiàn)的過(guò)程而不斷深入，這也會(huì)導(dǎo)致在軟件生命周期的后期重新修訂軟件需求。原因可能來(lái)自于錯(cuò)誤的分析、客戶(hù)環(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)審、需求跟蹤和比較分析后才能實(shí)施。3.4需求來(lái)源理解問(wèn)題域的第一步是提取需求，即確定需求的來(lái)源，識(shí)別軟件的涉眾，確立開(kāi)發(fā)團(tuán)隊(duì)與客戶(hù)間的關(guān)系。提取需求時(shí)，要求用戶(hù)與開(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à)值和成本，對(duì)系統(tǒng)的整體目標(biāo)進(jìn)行可行性研究。（2）行業(yè)知識(shí)系統(tǒng)分析師需要獲取業(yè)務(wù)領(lǐng)域內(nèi)的相關(guān)知識(shí)。因?yàn)樯姹妼?duì)于通用的行業(yè)知識(shí)會(huì)一概而過(guò)，一些行業(yè)慣例需要系統(tǒng)分析師根據(jù)環(huán)境進(jìn)行推斷。當(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í)別、表述他們的需求。用戶(hù)的文化差異、客戶(hù)的組織結(jié)構(gòu)，常常會(huì)是系統(tǒng)難以正常實(shí)施的原因。（4）運(yùn)行環(huán)境軟件的運(yùn)行環(huán)境包括地域限制、實(shí)時(shí)性要求和網(wǎng)絡(luò)性能等。系統(tǒng)的可行性和軟件架構(gòu)都依賴(lài)于這些環(huán)境需求。（5）組織環(huán)境軟件作為一個(gè)組織的業(yè)務(wù)流程支持工具，受到組織結(jié)構(gòu)、企業(yè)文化和內(nèi)部政策的影響。軟件的需求也與組織結(jié)構(gòu)、企業(yè)文化和內(nèi)部政策有關(guān)。3.5需求獲取方法常用的需求獲取方法有：（1）實(shí)地參加通過(guò)親身參加業(yè)務(wù)工作來(lái)了解業(yè)務(wù)活動(dòng)的情況。這種方法可以比較準(zhǔn)確地理解用戶(hù)的需求，但比較耗費(fèi)時(shí)間。（2）開(kāi)調(diào)查會(huì)通過(guò)與用戶(hù)座談來(lái)了解業(yè)務(wù)活動(dòng)情況及用戶(hù)需求。座談時(shí)，參加者之間可以相互啟發(fā)。（3）請(qǐng)專(zhuān)人介紹（4）面談對(duì)某些調(diào)查中的問(wèn)題，可以找專(zhuān)人詢(xún)問(wèn)。（5）設(shè)計(jì)調(diào)查表請(qǐng)用戶(hù)填寫(xiě)如果調(diào)查表設(shè)計(jì)得合理，這種方法是很有效的，也很易于被用戶(hù)接受。（6）查閱記錄查閱與原系統(tǒng)有關(guān)的數(shù)據(jù)記錄，包括原始單據(jù)、賬簿、報(bào)表等。通過(guò)調(diào)查了解獲取了用戶(hù)需求后，還需要進(jìn)一步分析和表達(dá)用戶(hù)的需求。3.6軟件需求表達(dá)如何有效地表達(dá)軟件需求？我們這里建議使用用例建模技術(shù)。用例建模技術(shù)是十多年來(lái)最重要的需求分析技術(shù)，在保障全球各類(lèi)軟件的成功開(kāi)發(fā)中發(fā)揮了極其重要的作用。實(shí)踐證明，用例技術(shù)是迄今為止最為深刻、準(zhǔn)確和有效的系統(tǒng)功能需求描述方法。功能需求是指系統(tǒng)輸入到輸出的映射，以及它們的不同組合，任何功能必然要通過(guò)外部環(huán)境與系統(tǒng)之間的交互才能完成，因此，我們可以在內(nèi)容和形式上把用例和系統(tǒng)的功能需求等同起來(lái)。用例建模技術(shù)不同于結(jié)構(gòu)化功能分解的特點(diǎn)有：（1）顯式地表達(dá)用戶(hù)的任務(wù)目標(biāo)層次，突出系統(tǒng)行為與用戶(hù)利益間的關(guān)系。（2）通過(guò)描述執(zhí)行實(shí)例情節(jié)（交互行為序列、正常/非正常事件流），能夠完整地反映軟件系統(tǒng)用以支持特定功能的行為。（3）以契約（前/后置條件等）的形式突出了用戶(hù)和系統(tǒng)之間常常被忽略的背后關(guān)系。（4）部署約束等非功能需求與系統(tǒng)行為直接綁定，能夠更準(zhǔn)確地表達(dá)此類(lèi)需求。3.7需求評(píng)審3.7.1需求評(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ì)基礎(chǔ)和依據(jù)的。需求評(píng)審也為風(fēng)險(xiǎn)承擔(dān)者們提供了在特定問(wèn)題上達(dá)成共識(shí)的方法。需求評(píng)審可以分為非正式評(píng)審和正式評(píng)審?！?/p>

非正式評(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>

正式評(píng)審：正式技術(shù)評(píng)審的最好類(lèi)型叫做審查，它遵循預(yù)先定義好的一系列步驟、過(guò)程及規(guī)定的方法和要求進(jìn)行，評(píng)審內(nèi)容需要記錄在案，正式評(píng)審小組的成員對(duì)評(píng)審的質(zhì)量負(fù)責(zé)。3.7.2需求評(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è)人左右或者更少。③審查的工作基礎(chǔ)是軟件需求規(guī)格說(shuō)明書(shū)。（2）參與者扮演的角色①作者：創(chuàng)建或維護(hù)正在被審查的產(chǎn)品。作者在審查中卻起著被動(dòng)的作用，作者經(jīng)?？梢园l(fā)現(xiàn)其他審查員沒(méi)有覺(jué)察到的錯(cuò)誤。②協(xié)調(diào)者：與作者一起為審查制訂計(jì)劃，組織與協(xié)調(diào)各種活動(dòng)，并且推進(jìn)審查會(huì)的進(jìn)行。督促作者對(duì)需求文檔做出建議性的更改，以保證向執(zhí)行者明確說(shuō)明在審查過(guò)程中提出的問(wèn)題和缺陷。③讀者：扮演審查員的角色。在審查會(huì)進(jìn)行期間，讀者一次審查規(guī)格說(shuō)明中的一塊內(nèi)容，并做出解釋?zhuān)以试S其他審查員在審查時(shí)提出問(wèn)題。對(duì)于一份需求規(guī)格說(shuō)明，審查員每次必須對(duì)需求給出注解或一個(gè)簡(jiǎn)短評(píng)論。通過(guò)用自己的話(huà)來(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)記；—

所有未解決的問(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)錄入項(xiàng)目的配置管理系統(tǒng)；—

已將審查過(guò)的資料送到有關(guān)歸檔部門(mén)。（4）需求審查清單①軟件需求規(guī)格說(shuō)明書(shū)審查清單：—

組織和完整性；—

正確性；—

質(zhì)量屬性；—

可跟蹤性；—

特殊的問(wèn)題。②使用實(shí)例審查清單：—

UseCase是否是獨(dú)立的分散任務(wù)；—

UseCase的目標(biāo)或價(jià)值度量是否明確；—

UseCase給操作者帶來(lái)的益處是否明確；—

UseCase是否處于抽象級(jí)別上，而不具有詳細(xì)的情節(jié)；—

UseCase中是否不包含設(shè)計(jì)和實(shí)現(xiàn)的細(xì)節(jié)；—

是否記錄了所有可能的可選過(guò)程；—

是否記錄了所有可能的例外條件；—

是否存在一些普通的動(dòng)作序列可以分解成獨(dú)立的UseCase；—

是否簡(jiǎn)明書(shū)寫(xiě)、無(wú)二義性和完整地記錄了每個(gè)過(guò)程的對(duì)話(huà)；—

UseCase中的每個(gè)操作和步驟是否都與所執(zhí)行的任務(wù)相關(guān)；—

UseCase中定義的每個(gè)過(guò)程是否都可行；—

UseCase中定義的每個(gè)過(guò)程是否都可確認(rèn)。第四章合格需求的標(biāo)準(zhǔn)合格需求的標(biāo)準(zhǔn)概括如下：1.必要性：如果沒(méi)有這項(xiàng)需求，系統(tǒng)仍然能夠滿(mǎn)足經(jīng)優(yōu)化的實(shí)際需要，則該項(xiàng)需求是不必要的；2.可行性：在可用的費(fèi)用和時(shí)間約束下，該項(xiàng)需求是可以實(shí)現(xiàn)和運(yùn)行的；3.正確性：與