軟件過程管理-課件5

承上啟下項(xiàng)目合同管理生存期模型0chapter__４承上啟下項(xiàng)目合同管理0chapter__４RoadMap合同管理

生存期需求管理任務(wù)分解項(xiàng)目進(jìn)度規(guī)模估算質(zhì)量計(jì)劃配置計(jì)劃風(fēng)險(xiǎn)計(jì)劃團(tuán)隊(duì)管理項(xiàng)目度量集成項(xiàng)目跟蹤控制

項(xiàng)目結(jié)束1chapter__４RoadMap合同管理需求管理任務(wù)分解軟件開發(fā)項(xiàng)目管理第四章軟件項(xiàng)目需求管理2chapter__４軟件開發(fā)項(xiàng)目管理第四章2chapter__４需求管理中的問題舉例需求的隱含錯(cuò)誤需求不明確、含糊用戶不斷增加需求、變更需求用戶刁難開發(fā)人員的鍍金3chapter__４需求管理中的問題舉例需求的隱含錯(cuò)誤3chapter__４鍍金（goldplating）的定義

給予用戶的東西要多于他們所要求的。事實(shí)上，額外的特性、擴(kuò)展的功能、更好的組件以及其他等等，通常都不會為項(xiàng)目增加什么價(jià)值。實(shí)際上，鍍金常常會增加項(xiàng)目的開支，因?yàn)檫@需要更多的資源、更長的開發(fā)周期，還會增加重新設(shè)計(jì)的風(fēng)險(xiǎn)、耽誤項(xiàng)目的交付使用。4chapter__４鍍金（goldplating）的定義

給予用戶的東西要多鍍金案例在檢視項(xiàng)目要求的時(shí)候，你發(fā)現(xiàn)了一個(gè)需要?jiǎng)?chuàng)建軟件模塊的要求。這個(gè)模塊允許用戶在瀏覽應(yīng)用程序的時(shí)候，在屏幕上維持其所喜好的顏色和字體樣式。在更進(jìn)一步檢視的時(shí)候，你意識到這個(gè)模塊的加入雖然很好，但是不會為整個(gè)項(xiàng)目增添什么價(jià)值。5chapter__４鍍金案例在檢視項(xiàng)目要求的時(shí)候，你發(fā)現(xiàn)了一個(gè)需要?jiǎng)?chuàng)建軟件模塊的如何確定項(xiàng)目里是否包含有鍍金的內(nèi)容要驗(yàn)證開發(fā)要求或者任務(wù)里是否包含有鍍金內(nèi)容的一種方法是：思考一下如果項(xiàng)目沒有包含這個(gè)模塊的話，其影響會是什么。問問你自己：如果這個(gè)項(xiàng)目沒有包含這個(gè)模塊，這個(gè)應(yīng)用程序的可靠性、效率是否會更低，或者根本就不會有任何降低。6chapter__４如何確定項(xiàng)目里是否包含有鍍金的內(nèi)容要驗(yàn)證開發(fā)要求或者任務(wù)里是本章要點(diǎn)一、軟件需求定義二、軟件需求管理過程三、需求建模的基本方法四、案例分析7chapter__４本章要點(diǎn)一、軟件需求定義7chapter__４軟件需求定義軟件需求定義軟件需求需求是指用戶對軟件的功能和性能的要求，就是用戶希望軟件能做什么事情，完成什么樣的功能，達(dá)到什么性能。9chapter__４軟件需求需求是指用戶對軟件的功能和性能的要求，就是用戶希望軟軟件需求的層次業(yè)務(wù)需求用戶需求功能需求軟件需求規(guī)格非功能性需求質(zhì)量特性約束和假設(shè)系統(tǒng)需求10chapter__４軟件需求的層次業(yè)務(wù)需求用戶需求功能需求軟件需求規(guī)格非功能性需1．業(yè)務(wù)需求（businessrequirement）反映了組織機(jī)構(gòu)或客戶對系統(tǒng)、產(chǎn)品高層次的目標(biāo)要求，它們在項(xiàng)目視圖與范圍文檔中予以說明2．用戶需求(userrequirement)文檔描述了用戶使用產(chǎn)品必須要完成的任務(wù)，這在使用實(shí)例（usecase）文檔或方案腳本說明中予以說明。3．功能需求(functionalrequirement)定義了開發(fā)人員必須實(shí)現(xiàn)的軟件功能，使得用戶能完成他們的任務(wù)，從而滿足了業(yè)務(wù)需求。在軟件需求規(guī)格說明書（SRS）中說明的功能需求充分描述了軟件系統(tǒng)所應(yīng)具有的外部行為。軟件需求規(guī)格說明在開發(fā)、測試、質(zhì)量保證、項(xiàng)目管理以及相關(guān)項(xiàng)目功能中都起了重要的作用。對一個(gè)大型系統(tǒng)來說，軟件功能需求也許只是系統(tǒng)需求的一個(gè)子集，因?yàn)榱硗庖恍┛赡軐儆谧酉到y(tǒng)（或軟件部件）。11chapter__４1．業(yè)務(wù)需求（businessrequirement）反映作為功能需求的補(bǔ)充，軟件需求規(guī)格說明還應(yīng)包括非功能需求，它描述了系統(tǒng)展現(xiàn)給用戶的行為和執(zhí)行的操作等。它包括產(chǎn)品必須遵從的標(biāo)準(zhǔn)、規(guī)范和合約；外部界面的具體細(xì)節(jié)；性能要求；設(shè)計(jì)或?qū)崿F(xiàn)的約束條件及質(zhì)量屬性。所謂約束是指對開發(fā)人員在軟件產(chǎn)品設(shè)計(jì)和構(gòu)造上的限制。質(zhì)量屬性是通過多種角度對產(chǎn)品的特點(diǎn)進(jìn)行描述，從而反映產(chǎn)品功能。多角度描述產(chǎn)品對用戶和開發(fā)人員都極為重要。12chapter__４作為功能需求的補(bǔ)充，軟件需求規(guī)格說明還應(yīng)包括非功能需求，它描以一個(gè)字處理程序?yàn)槔齺碚f明需求的不同種類。

業(yè)務(wù)需求可能是：“用戶能有效地糾正文檔中的拼寫錯(cuò)誤”，該產(chǎn)品的包裝盒封面上可能會標(biāo)明這是個(gè)滿足業(yè)務(wù)需求的拼寫檢查器。用戶需求可能是“找出文檔中的拼寫錯(cuò)誤并通過一個(gè)提供的替換項(xiàng)列表來供選擇替換拼錯(cuò)的詞”。同時(shí)，該拼寫檢查器還有許多功能需求，如找到并高亮度提示錯(cuò)詞的操作；顯示提供替換詞的對話框以及實(shí)現(xiàn)整個(gè)文檔范圍的替換。13chapter__４以一個(gè)字處理程序?yàn)槔齺碚f明需求的不同種類。13功能需求功能需求：列舉出被開發(fā)軟件在職能上應(yīng)做什么。這是最主要的需求，規(guī)定開發(fā)人員必須在產(chǎn)品中實(shí)現(xiàn)的軟件功能，用戶利用這些功能來完成任務(wù)，滿足業(yè)務(wù)需求。通常功能性需求是：產(chǎn)品功能的規(guī)格說明；產(chǎn)品必須執(zhí)行的動作；源自于產(chǎn)品的基本目標(biāo)例如：銀行ATM系統(tǒng)功能性需求：取、存、查、密碼檢驗(yàn)

14chapter__４功能需求功能需求：列舉出被開發(fā)軟件在職能上應(yīng)做什么。這是最主非功能需求許多非功能需求關(guān)心的是系統(tǒng)整體特性，而不是個(gè)別的系統(tǒng)特性。因此非功能需求比功能需求對系統(tǒng)更關(guān)鍵。一個(gè)功能需求沒有滿足可能降低系統(tǒng)的能力，而一個(gè)非功能系統(tǒng)需求沒有滿足則可能使整個(gè)系統(tǒng)無法使用。例如：一個(gè)飛機(jī)系統(tǒng)不符合可靠性需求，它將不會被批準(zhǔn)飛行。若一個(gè)實(shí)時(shí)控制系統(tǒng)無法滿足其性能需求，控制功能可能根本無法使用。例如：銀行ATM系統(tǒng)非功能需求：響應(yīng)時(shí)間，安全保密等

15chapter__４非功能需求許多非功能需求關(guān)心的是系統(tǒng)整體特性，而不是個(gè)別的系需求管理的重要性16chapter__４需求管理的重要性16chapter__４項(xiàng)目失敗的原因分析No.

Top10Factors

平均值

1

Inadequaterequirementsspecification

不充分的需求規(guī)范

4.5

2

Changesinrequirements

需求的改變

4.3

3

Shortageofsystemsengineers

缺乏系統(tǒng)工程師

4.2

4

Shortageofsoftwaremanagers缺乏了解軟件特性的經(jīng)理人

4.1

5

Shortageofqualifiedprojectmanagers缺乏合格的項(xiàng)目經(jīng)理

4.1

6

Shortageofsoftwareengineers缺乏軟件工程師

3.9

7

Fixed-pricecontract固定價(jià)合同

3.8

8

Inadequatecommunicationsforsystemintegration系統(tǒng)集成階段,交流與溝通不充分

3.8

9

Insufficientexperienceasteam團(tuán)隊(duì)缺乏經(jīng)驗(yàn)

3.6

10

Shortageofapplicationdomainexperts缺乏應(yīng)用領(lǐng)域?qū)＜?/p>

3.6

Scale:5=VerySerious3=Serious1=NoSerious

Source:Carnegie-MellonUniversity,SoftwareEngineeringInstitute17chapter__４項(xiàng)目失敗的原因分析No.Top10Factors平均本章要點(diǎn)一、軟件需求定義二、軟件需求管理過程三、需求建模的基本方法四、案例分析18chapter__４本章要點(diǎn)一、軟件需求定義18chapter__４軟件需求管理過程軟件需求管理過程軟件需求管理的過程需求分析編寫需求規(guī)格需求驗(yàn)證需求獲取需求變更需求確認(rèn)需求變更20chapter__４軟件需求管理的過程需求分析編寫需求規(guī)格需求驗(yàn)證需求獲取需求變需求開發(fā)(確認(rèn))和管理基本任務(wù)需求工程需求管理需求開發(fā)需求獲取需求分析需求規(guī)格說明需求驗(yàn)證變更管理版本控制風(fēng)險(xiǎn)分析21chapter__４需求開發(fā)(確認(rèn))和管理基本任務(wù)需求工程需求管理需求開發(fā)需求獲本章要點(diǎn)一、軟件需求定義二、軟件需求管理過程需求的獲取需求分析編寫需求規(guī)格需求驗(yàn)證需求變更三、需求建模的基本方法四、案例分析22chapter__４本章要點(diǎn)一、軟件需求定義22chapter__４需求獲取圖示23chapter__４需求獲取圖示23chapter__４需求獲取用戶要求

擴(kuò)展需求基線需求軟件需求24chapter__４需求獲取用戶要求軟件需求24chapter__４程、硬件環(huán)境、軟件環(huán)境、現(xiàn)有的運(yùn)行系統(tǒng)等具體情況和客觀的信息，建立起良好的溝通渠道和方式25chapter__４程、硬件環(huán)境、軟件環(huán)境、現(xiàn)有的運(yùn)行系統(tǒng)等具體情況和客觀的信息26chapter__４26chapter__４進(jìn)行需求獲取應(yīng)注意的問題識別真正的客戶正確理解客戶的需求具備較強(qiáng)的忍耐力和清晰的思維說明和教育客戶27chapter__４進(jìn)行需求獲取應(yīng)注意的問題識別真正的客戶27chapter_本章要點(diǎn)一、軟件需求定義二、軟件需求管理過程需求的獲取需求分析編寫需求規(guī)格需求驗(yàn)證需求變更三、需求建模的基本方法四、案例分析28chapter__４本章要點(diǎn)一、軟件需求定義28chapter__４需求分析定義需求分析是為最終用戶所看到的系統(tǒng)建立一個(gè)概念模型，是對需求的抽象描述。29chapter__４需求分析定義需求分析是為最終用戶所看到的系統(tǒng)建立一個(gè)概念模型需求分析模型30chapter__４需求分析模型30chapter__４本章要點(diǎn)一、軟件需求定義二、軟件需求管理過程需求的獲取需求分析編寫需求規(guī)格需求驗(yàn)證需求變更三、需求建模的基本方法四、案例分析31chapter__４本章要點(diǎn)一、軟件需求定義31chapter__４需求規(guī)格需求分析工作完成的一個(gè)基本標(biāo)志是形成了一份完整的、規(guī)范的需求規(guī)格說明書需求規(guī)格說明書的編制是為了使用戶和軟件開發(fā)者雙方對該軟件的初始規(guī)定有一個(gè)共同的理解，使之成為整個(gè)開發(fā)工作的基礎(chǔ)。32chapter__４需求規(guī)格需求分析工作完成的一個(gè)基本標(biāo)志是形成了一份完整的、規(guī)軟件需求規(guī)格說明的原則從現(xiàn)實(shí)中分離功能，即描述要“做什么”而不是“怎樣實(shí)現(xiàn)”要求使用面向處理的規(guī)格說明語言（或稱系統(tǒng)定義語言）如果被開發(fā)軟件只是一個(gè)大系統(tǒng)中的一個(gè)元素，那么整個(gè)大系統(tǒng)也包括在規(guī)格說明的描述之中33chapter__４軟件需求規(guī)格說明的原則從現(xiàn)實(shí)中分離功能，即描述要“做什么”而規(guī)格說明應(yīng)該包括系統(tǒng)運(yùn)行環(huán)境規(guī)格說明應(yīng)該是一個(gè)認(rèn)識模型規(guī)格說明應(yīng)該容許不完備性并允許擴(kuò)充34chapter__４規(guī)格說明應(yīng)該包括系統(tǒng)運(yùn)行環(huán)境34chapter__４3、規(guī)格文檔參考引言系統(tǒng)定義應(yīng)用環(huán)境功能規(guī)格性能需求產(chǎn)品提交實(shí)現(xiàn)約束質(zhì)量描述其它簽字認(rèn)證35chapter__４3、規(guī)格文檔參考引言35chapter__４本章要點(diǎn)一、軟件需求定義二、軟件需求管理過程需求的獲取需求分析編寫需求規(guī)格需求驗(yàn)證需求變更三、需求建模的基本方法四、案例分析36chapter__４本章要點(diǎn)一、軟件需求定義36chapter__４需求驗(yàn)證需求是正確的嗎？需求是一致的嗎？需求是完全的嗎？需求是實(shí)際可行的嗎？需求是必要的嗎？需求是可檢驗(yàn)的嗎？需求是可跟蹤的嗎？最后的簽字37chapter__４需求驗(yàn)證需求是正確的嗎？37chapter__４本章要點(diǎn)一、軟件需求定義二、軟件需求管理過程需求的獲取需求分析編寫需求規(guī)格需求驗(yàn)證需求變更三、需求建模的基本方法四、案例分析38chapter__４本章要點(diǎn)一、軟件需求定義38chapter__４需求總在變化39chapter__４需求總在變化39chapter__４40chapter__４40chapter__４需求變更管理確定需求變更控制過程建立變更控制委員會(SCCB)進(jìn)行需求變更影響分析跟蹤所有受需求變更影響的工作產(chǎn)品建立需求基準(zhǔn)版本和需求控制版本文檔維護(hù)需求變更的歷史記錄跟蹤每項(xiàng)需求的狀態(tài)衡量需求穩(wěn)定性41chapter__４需求變更管理確定需求變更控制過程41chapter__４需求變更管理管理和控制需求基線的過程需求變更控制系統(tǒng)一個(gè)正式的文檔，說明如何控制需求變更建立變更審批系統(tǒng)42chapter__４需求變更管理管理和控制需求基線的過程42chapter__控制需求漸變的策略需求一定要與投入有顯然的聯(lián)系，在項(xiàng)目的開始雙方都要明確：需求變化，成本也要變化。需求的變化要經(jīng)過出資者的認(rèn)可。小的需求變更也要經(jīng)過正規(guī)的需求管理過程，否則積少成多。精確的需求和范圍的定義并不會阻止需求的變更。這是兩個(gè)層面的問題。43chapter__４控制需求漸變的策略需求一定要與投入有顯然的聯(lián)系，在項(xiàng)目的開始變更控制過程44chapter__４變更控制過程44chapter__４需求變更處理流程提出變更變更評估實(shí)施變更45chapter__４需求變更處理流程提出變更45chapter__４變更申請需求方開發(fā)方忽略選擇變更方式SCCB評估項(xiàng)目經(jīng)理自行決定根據(jù)評估結(jié)果拒絕接受本次修改下個(gè)版本再修改修改合同相關(guān)信息修改相關(guān)需求修改相應(yīng)的項(xiàng)目計(jì)劃46chapter__４變更申請需求方開發(fā)方忽略選擇變更方式SCCB評估項(xiàng)目經(jīng)理自行表4-3需求變更提交單軟件基線產(chǎn)品修改提交單申請人韓萬江申請日期2002。10．11項(xiàng)目名稱項(xiàng)目管理系統(tǒng)階段名稱系統(tǒng)設(shè)計(jì)文件名稱RCR-PM-01.doc,RCR-PM-02.doc,變更簡述如下修改內(nèi)容1）修改測試流程控制：將2個(gè)角色，3個(gè)渠道流，改為3個(gè)角色，4個(gè)渠道流，詳見RCR-PM-01.doc2）增加開發(fā)人員技能信息庫管理，詳見RCR-PM-02.doc

驗(yàn)證意見同意RCR-PM-01.doc變更。RCR-PM-02.doc的變更可以推遲到下一個(gè)版本實(shí)施驗(yàn)證人楊炎泰驗(yàn)證日期2002．10．11SCCB韓萬江，姜岳尊，孫泉

填表人韓萬江47chapter__４表4-3需求變更提交單軟件基線產(chǎn)品修改提交單申請人韓萬江申需求變更管理原則（1）建立需求基線。需求基線是需求變更的依據(jù)。在開發(fā)過程中，需求確定并經(jīng)過評審后(用戶參與評審)，可以建立第一個(gè)需求基線。此后每次變更并經(jīng)過評審后，都要重新確定新的需求基線。（2）制訂簡單、有效的變更控制流程，并形成文檔。在建立了需求基線后提出的所有變更都必須遵循這個(gè)控制流程進(jìn)行控制。同時(shí)，這個(gè)流程具有一定的普遍性，對以后的項(xiàng)目開發(fā)和其他項(xiàng)目都有借鑒作用。（3）成立項(xiàng)目變更控制委員會(CCB)或相關(guān)職能的類似組織，負(fù)責(zé)裁定接受哪些變更。CCB由項(xiàng)目所涉及的多方人員共同組成，應(yīng)該包括用戶方和開發(fā)方的決策人員在內(nèi)。（4）需求變更一定要先申請然后再評估，最后經(jīng)過與變更大小相當(dāng)級別的評審確認(rèn)。（5）需求變更后，受影響的軟件計(jì)劃、產(chǎn)品、活動都要進(jìn)行相應(yīng)的變更，以保持和更新的需求一致。（6）妥善保存變更產(chǎn)生的相關(guān)文檔。48chapter__４需求變更管理原則（1）建立需求基線。需求基線是需求變更需求變更應(yīng)對之道?相互協(xié)作——很難想像遭到用戶抵制的項(xiàng)目能夠成功。在討論需求時(shí)，開發(fā)人員與用戶應(yīng)該盡量采取相互理解、相互協(xié)作的態(tài)度，對能解決的問題盡量解決。即使用戶提出了在開發(fā)人員看來"過分"的要求，也應(yīng)該仔細(xì)分析原因，積極提出可行的替代方案。?充分交流——需求變更管理的過程很大程度上就是用戶與開發(fā)人員的交流過程。軟件開發(fā)人員必須學(xué)會認(rèn)真聽取用戶的要求、考慮和設(shè)想，并加以分析和整理。同時(shí)，軟件開發(fā)人員應(yīng)該向用戶說明，進(jìn)入設(shè)計(jì)階段以后，再提出需求變更會給整個(gè)開發(fā)工作帶來什么樣的沖擊和不良后果。?安排專職人員負(fù)責(zé)需求變更管理——有時(shí)開發(fā)任務(wù)較重，開發(fā)人員容易陷入開發(fā)工作中而忽略了與用戶的隨時(shí)溝通，因此需要一名專職的需求變更管理人員負(fù)責(zé)與用戶及時(shí)交流。?合同約束——需求變更給軟件開發(fā)帶來的影響有目共睹，所以在與用戶簽訂合同時(shí)，可以增加一些相關(guān)條款，如限定用戶提出需求變更的時(shí)間，規(guī)定何種情況的變更可以接受、拒絕接受或部分接受，還可以規(guī)定發(fā)生需求變更時(shí)必須執(zhí)行變更控制流程。?區(qū)別對待——隨著開發(fā)進(jìn)展，有些用戶會不斷提出一些在項(xiàng)目組看來確實(shí)無法實(shí)現(xiàn)或工作量比較大、49chapter__４需求變更應(yīng)對之道?相互協(xié)作——很難想像遭到用戶抵制的項(xiàng)目能需求變更應(yīng)對之道?對項(xiàng)目進(jìn)度有重大影響的需求。遇到這種情況，開發(fā)人員可以向用戶說明，項(xiàng)目的啟動是以最初的基本需求作為開發(fā)前提的，如果大量增加新的需求(雖然用戶認(rèn)為是細(xì)化需求，但實(shí)際上是增加了工作量的新需求)，會使項(xiàng)目不能按時(shí)完成。如果用戶堅(jiān)持實(shí)施新需求，可以建議用戶將新需求按重要和緊迫程度劃分檔次，作為需求變更評估的一項(xiàng)依據(jù)。同時(shí)，還要注意控制新需求提出的頻率。?選用適當(dāng)?shù)拈_發(fā)模型——采用建立原型的開發(fā)模型比較適合需求不明確的開發(fā)項(xiàng)目。開發(fā)人員先根據(jù)用戶對需求的說明建立一個(gè)系統(tǒng)原型，再與用戶溝通。一般用戶看到一些實(shí)際的東西后，對需求會有更為詳細(xì)的解釋，開發(fā)人員可根據(jù)用戶的說明進(jìn)一步完善系統(tǒng)原型。這個(gè)過程重復(fù)幾次后，系統(tǒng)原型逐漸向最終的用戶需求靠攏，從根本上減少需求變更的出現(xiàn)。目前業(yè)界較為流行的疊代式開發(fā)方法對工期緊迫的項(xiàng)目的需求變更控制很有成效。?用戶參與需求評審——作為需求的提出者，用戶理所當(dāng)然是最具權(quán)威的發(fā)言人之一。實(shí)際上，在需求評審過程中，用戶往往能提出許多有價(jià)值的意見。同時(shí)，這也是由用戶對需求進(jìn)行最后確認(rèn)的機(jī)會，可以有效減少需求變更的發(fā)生。50chapter__４需求變更應(yīng)對之道?對項(xiàng)目進(jìn)度有重大影響的需求。遇到這種情況，本章要點(diǎn)一、軟件需求定義二、軟件需求管理過程三、需求建模的基本方法四、案例分析51chapter__４本章要點(diǎn)一、軟件需求定義51chapter__４需求建模的基本方法原型方法結(jié)構(gòu)化分析法面向?qū)ο蟮挠美治龇üδ芰斜矸ㄆ渌?2chapter__４需求建模的基本方法原型方法52chapter__４本章要點(diǎn)一、軟件需求定義二、軟件需求管理過程三、需求建模的基本方法原型方法結(jié)構(gòu)化分析法面向?qū)ο蟮挠美治龇üδ芰斜矸ㄆ渌?、案例分?3chapter__４本章要點(diǎn)一、軟件需求定義53chapter__４原型方法按照用戶的需要，快速形成一個(gè)操作流程界面可能只是一個(gè)框架，具體的功能沒有實(shí)現(xiàn)，只是結(jié)果靜態(tài)的操作流程，以便與用戶快速就需求達(dá)成一致主要考慮系統(tǒng)的功能需求，很少考慮非功能需求54chapter__４原型方法按照用戶的需要，快速形成一個(gè)操作流程界面54cha原型方法需求分析原型開發(fā)原型評價(jià)55chapter__４原型方法需求分析原型開發(fā)原型評價(jià)55chapter__４原型方法的類型進(jìn)化型開發(fā)出來用于了解問題，并形成被交付軟件的部分或全部的基礎(chǔ)拋棄型開發(fā)出來獲以便更多地了解問題或探究可能的方案的靈活性或者合理性，是嘗試性軟件，不用于被交付軟件的實(shí)際部分56chapter__４原型方法的類型進(jìn)化型56chapter__４原型實(shí)例原型系統(tǒng)57chapter__４原型實(shí)例原型系統(tǒng)57chapter__４本章要點(diǎn)一、軟件需求定義二、軟件需求管理過程三、需求建模的基本方法原型方法結(jié)構(gòu)化分析法面向?qū)ο蟮挠美治龇üδ芰斜矸ㄆ渌摹咐治?8chapter__４本章要點(diǎn)一、軟件需求定義58chapter__４結(jié)構(gòu)化分析方法（SA,StructuredAnalysis）

20世紀(jì)70年發(fā)展起來的面向數(shù)據(jù)流的方法是一種自頂向下逐步求精的分析方法根據(jù)軟件內(nèi)部數(shù)據(jù)傳遞、變換的關(guān)系進(jìn)行分析的59chapter__４結(jié)構(gòu)化分析方法（SA,StructuredAnalysis結(jié)構(gòu)化分析方法-技術(shù)數(shù)據(jù)流圖(DFD)數(shù)據(jù)字典(DD)系統(tǒng)流程圖60chapter__４結(jié)構(gòu)化分析方法-技術(shù)數(shù)據(jù)流圖(DFD)60chapter_描述銀行取款過程的數(shù)據(jù)流圖61chapter__４描述銀行取款過程的數(shù)據(jù)流圖61chapter__４數(shù)據(jù)流圖的層次結(jié)構(gòu)為了表達(dá)數(shù)據(jù)處理過程的數(shù)據(jù)加工情況，需要采用層次結(jié)構(gòu)的數(shù)據(jù)流圖。按照系統(tǒng)的層次結(jié)構(gòu)進(jìn)行逐步分解，并以分層的數(shù)據(jù)流圖反映這種結(jié)構(gòu)關(guān)系，能清楚地表達(dá)和容易理解整個(gè)系統(tǒng)62chapter__４數(shù)據(jù)流圖的層次結(jié)構(gòu)為了表達(dá)數(shù)據(jù)處理過程的數(shù)據(jù)加工情況，需要采分層數(shù)據(jù)流圖63chapter__４分層數(shù)據(jù)流圖63chapter__４數(shù)據(jù)字典描述系統(tǒng)中涉及的每個(gè)數(shù)據(jù),是數(shù)據(jù)描述的集合,通常配合數(shù)據(jù)流圖使用,用來描述數(shù)據(jù)流圖中出現(xiàn)的各種數(shù)據(jù)和加工.64chapter__４數(shù)據(jù)字典描述系統(tǒng)中涉及的每個(gè)數(shù)據(jù),是數(shù)據(jù)描述的集合,通常配合數(shù)據(jù)字典-組成數(shù)據(jù)項(xiàng):數(shù)據(jù)元素?cái)?shù)據(jù)流:由數(shù)據(jù)項(xiàng)組成的數(shù)據(jù)流數(shù)據(jù)文件:表示對數(shù)據(jù)文件的存儲65chapter__４數(shù)據(jù)字典-組成數(shù)據(jù)項(xiàng):數(shù)據(jù)元素65chapter__４數(shù)據(jù)流圖需求分析實(shí)例建立學(xué)生管理系統(tǒng)學(xué)管科體檢科學(xué)籍科學(xué)生處66chapter__４數(shù)據(jù)流圖需求分析實(shí)例建立學(xué)生管理系統(tǒng)66chapter__數(shù)據(jù)流圖-頂層學(xué)管科體檢科學(xué)籍科學(xué)生管理信息系統(tǒng)學(xué)生處領(lǐng)導(dǎo)學(xué)生基本信息學(xué)生健康信息學(xué)生成績學(xué)生健康情況表學(xué)生成績單查詢要求不及格人數(shù)人數(shù)統(tǒng)計(jì)表67chapter__４數(shù)據(jù)流圖-頂層學(xué)管科體檢科學(xué)籍科學(xué)生管理學(xué)生處領(lǐng)導(dǎo)學(xué)生基本信數(shù)據(jù)流圖-0層68chapter__４數(shù)據(jù)流圖-0層68chapter__４數(shù)據(jù)流圖-1層69chapter__４數(shù)據(jù)流圖-1層69chapter__４數(shù)據(jù)流圖-1層70chapter__４數(shù)據(jù)流圖-1層70chapter__４數(shù)據(jù)字典-數(shù)據(jù)流

學(xué)生基本信息：學(xué)號十姓名學(xué)生健康信息：學(xué)號十健康情況學(xué)生成績：學(xué)號十{課程名+成績}查詢要求：[健康查詢單|平均成績查詢單l不及格人數(shù)查詢]學(xué)生健康情況表：優(yōu)％十良％十一般％十差％學(xué)生成績單：學(xué)號十姓名十{課程名+成績}+總成績不及格人數(shù)統(tǒng)計(jì)表：學(xué)號十成績十不及格總?cè)藬?shù)71chapter__４數(shù)據(jù)字典-數(shù)據(jù)流學(xué)生基本信息：學(xué)號十姓名71cha數(shù)據(jù)字典-數(shù)據(jù)文件文件名：基本信息組成：｛學(xué)號十姓名十入學(xué)成績十生源｝組織：按學(xué)號遞增順序排列文件名：健康文件組成：{學(xué)號+姓名+健康情況}組織：按照健康情況為優(yōu)、良、一般、差順序排列文件名：成績文件組成：{學(xué)號+姓名+平均成績}組織：按照評劇成績遞增順序排列72chapter__４數(shù)據(jù)字典-數(shù)據(jù)文件文件名：基本信息72chapter__４系統(tǒng)流程圖系統(tǒng)包含的部分以及各個(gè)部分之間的關(guān)系是描述物理系統(tǒng)的工具用圖形符號表示系統(tǒng)中的元素表達(dá)了系統(tǒng)中各個(gè)元素之間的信息流動情況73chapter__４系統(tǒng)流程圖系統(tǒng)包含的部分以及各個(gè)部分之間的關(guān)系73chap系統(tǒng)流程圖符號74chapter__４系統(tǒng)流程圖符號74chapter__４75chapter__４75chapter__４本章要點(diǎn)一、軟件需求定義二、軟件需求管理過程三、需求建模的基本方法原型方法結(jié)構(gòu)化分析法面向?qū)ο蟮挠美治龇üδ芰斜矸ㄆ渌摹咐治?6chapter__４本章要點(diǎn)一、軟件需求定義76chapter__４面向?qū)ο蟮男枨蠓治鯫OSEOOAOODOOPOOT…….77chapter__４面向?qū)ο蟮男枨蠓治鯫OSE77chapter__４OOA是OO軟件工程的第一項(xiàng)技術(shù)活動將現(xiàn)實(shí)世界的“視圖”轉(zhuǎn)化為用對象來描述的模型描述對象之間的各種關(guān)系，以滿足軟件系統(tǒng)的要求。78chapter__４OOA是OO軟件工程的第一項(xiàng)技術(shù)活動78chapter__用例需求（Usecase）分析用例需求分析方法采用一種面向?qū)ο蟮那榫胺治龇椒ㄓ美窍到y(tǒng)向用戶提供一個(gè)有價(jià)值的結(jié)果的某項(xiàng)功能從用戶角度出發(fā)考慮的功能需求所有的用例結(jié)合起來就構(gòu)成了用例模型79chapter__４用例需求（Usecase）分析用例需求分析方法采用一種面向UML需求視圖用例視圖（UsecaseDiagram）順序圖（SequenceDiagram）狀態(tài)圖（StateDiagram）活動圖（ActivityDiagram）80chapter__４UML需求視圖用例視圖（UsecaseDiagram）881chapter__４81chapter__４82chapter__４82chapter__４83chapter__４83chapter__４84chapter__４84chapter__４用例視圖用例視圖主要是展示了外部行為者所觀察到的系統(tǒng)將提交的功能.即:各類外部行為者與系統(tǒng)所提供的用例的連接85chapter__４用例視圖用例視圖主要是展示了外部行為者所觀察到的系統(tǒng)將提交的用例視圖用例（Usecase）：系統(tǒng)所提供的功能描述角色（Actor）：可能使用用例的人或者外部系統(tǒng)86chapter__４用例視圖用例（Usecase）：系統(tǒng)所提供的功能描述86UML圖符87chapter__４UML圖符87chapter__４通信關(guān)系：執(zhí)行者與用例之間的連線來表示泛化關(guān)系：用例間的泛化關(guān)系意味著一個(gè)用例是另一個(gè)用例的特殊版本，特殊用例可在一般用例的執(zhí)行序列的任意位置插入額外的動作序列，也可修改某些繼承來的操作和順序。在UML中用帶連線的三角形表示。包含關(guān)系：描述用例間的共同行為，當(dāng)兩個(gè)或多個(gè)用例有共同的執(zhí)行序列片斷時(shí)，可將這些序列片斷抽取，形成被包含用例。UML中用標(biāo)有《include》的虛箭頭線來表示。有點(diǎn)類似于程序間的調(diào)用關(guān)系。擴(kuò)展關(guān)系：當(dāng)對一個(gè)已存在的用例增加新的功能時(shí)，可使用擴(kuò)展關(guān)系，擴(kuò)展關(guān)系一般用于有條件地?cái)U(kuò)展已有用例的行為，是一種不改變原始用例的情況下增加用例行為的一種方法。88chapter__４通信關(guān)系：執(zhí)行者與用例之間的連線來表示88chapter存款驗(yàn)證密碼支取管理取款維護(hù)通知透支轉(zhuǎn)帳《include》《include》《extend》顧客銀行系統(tǒng)管理員89chapter__４存款驗(yàn)證密碼支取管理取款維護(hù)通知透支轉(zhuǎn)帳《include》《用例實(shí)例90chapter__４用例實(shí)例90chapter__４用例實(shí)例91chapter__４用例實(shí)例91chapter__４順序圖示順序圖展示了幾個(gè)對象之間的動態(tài)協(xié)作關(guān)系，主要用來顯示對象之間發(fā)送消息的順序，還顯示對象之間的交互，即系統(tǒng)執(zhí)行某一特定時(shí)間點(diǎn)所發(fā)生的事。

92chapter__４順序圖示順序圖展示了幾個(gè)對象之間的動態(tài)協(xié)作關(guān)系，主要用來顯示順序圖示93chapter__４順序圖示93chapter__４狀態(tài)視圖狀態(tài)圖是對類描述的補(bǔ)充，它說明該類的對象所有可能的狀態(tài)以及那些事件將導(dǎo)致狀態(tài)的改變。它是一個(gè)類對象所可能經(jīng)歷的所有歷程的模型圖94chapter__４狀態(tài)視圖狀態(tài)圖是對類描述的補(bǔ)充，它說明該類的對象所有可能的狀活動視圖活動圖用來描述執(zhí)行工作流程中涉及的活動，展示了連續(xù)的活動流95chapter__４活動視圖活動圖用來描述執(zhí)行工作流程中涉及的活動，展示了連續(xù)的活動圖例96chapter__４活動圖例96chapter__４UseCase需求分析方法綜述識別出系統(tǒng)的Actor描述主要的Usecase實(shí)現(xiàn)用例視圖實(shí)現(xiàn)順序視圖，活動視圖,狀態(tài)視圖等97chapter__４UseCase需求分析方法綜述識別出系統(tǒng)的Actor97實(shí)例用Rationalrose工具實(shí)現(xiàn)的需求規(guī)格文檔貿(mào)易鏈需求的需求實(shí)例98chapter__４實(shí)例用Rationalrose工具實(shí)現(xiàn)的需求規(guī)格文檔9899chapter__４99chapter__４100chapter__４100chapter__４101chapter__４101chapter__４102chapter__４102chapter__４103chapter__４103chapter__４104chapter__４104chapter__４105chapter__４105chapter__４106chapter__４106chapter__４107chapter__４107chapter__４108chapter__４108chapter__４本章要點(diǎn)一、軟件需求定義二、軟件需求管理過程三、需求建模的基本方法原型方法結(jié)構(gòu)化分析法面向?qū)ο蟮挠美治龇üδ芰斜矸ㄆ渌?、案例分?09chapter__４本章要點(diǎn)一、軟件需求定義109chapter__４功能列表需求類別（功能/性能）名稱/標(biāo)識描述

特性（Feature）AA.1

……

A.n

特性FeatureBB.1

……

B.n

特性FeatureCC.1

……

C.n

110chapter__４功能列表需求類別（功能/性能）名稱/標(biāo)識描述

A.1

……

功能列表實(shí)例（某網(wǎng)站功能列表)111chapter__４功能列表實(shí)例（某網(wǎng)站功能列表)111chapter__４本章要點(diǎn)一、軟件需求定義二、軟件需求管理過程三、需求建模的基本方法四、案例分析112chapter__４本章要點(diǎn)一、軟件需求定義112chapter__４案例分析“School”項(xiàng)目的需求管理過程：需求確認(rèn)：原型法需求變更：變更控制系統(tǒng)變更過程113chapter__４案例分析“School”項(xiàng)目的需求管理過程：113chapInfosys公司常用的變更管理過程（1）記錄變更。（2）分析變更對工作產(chǎn)品的影響。（3）估計(jì)變更申請所需的工作量。（4）重新估計(jì)交付時(shí)間表。（5）執(zhí)行累積的成本影響分析。（6）如果影響超出一定限度，則與高級主管一起評審影響。（7）客戶不再提出變更申請。（8）修改工作產(chǎn)品。114chapter__４Infosys公司常用的變更管理過程（1）記錄變更。114變更申請日記護(hù)一個(gè)變更申請日記，以跟蹤變更申請。日志中的每條記錄包含一個(gè)變更申請?zhí)?、關(guān)于變更的簡單描述、變更的影響、變更申請的狀態(tài)以及關(guān)鍵日期。在評估變更申請的影響時(shí)，必須執(zhí)行影響分析。影響分析涉及標(biāo)識出需要進(jìn)行變更的工作產(chǎn)品，并估算對每種產(chǎn)品的變更量；通過重新查看風(fēng)險(xiǎn)管理計(jì)劃，重新評估項(xiàng)目風(fēng)險(xiǎn)；評估需求變更蘊(yùn)涵的總的工作量和進(jìn)度估計(jì)的變化。客戶對分析結(jié)果進(jìn)行評審，并做出答復(fù)。變更申請一般作為需求規(guī)格說明文檔的附件。有時(shí)還要修改文檔的有關(guān)部分以反映所做的變更。監(jiān)督已認(rèn)可的變更申請并保證它們正確實(shí)現(xiàn)，這部分由配置管理過程處理。115chapter__４變更申請日記護(hù)一個(gè)變更申請日記，以跟蹤變更申請。115ch變更的累積影響需求變更的一種危險(xiǎn)是：盡管每種變更本身并不大，但是生命期中所有變更的累積影響卻是很大的。因此，除了研究每個(gè)變更的影響并對它們進(jìn)行跟蹤外，還必須監(jiān)督變更的累積影響。116chapter__４變更的累積影響需求變更的一種危險(xiǎn)是：盡管每種變更本身并不大Infosys公司的項(xiàng)目經(jīng)理有時(shí)為處理變更申請預(yù)留一定的余地。–只要所有變更累積的工作量不超過這一預(yù)留的工作量，就不需要做任何特殊的處理。–然而，如果所有變更的累積工作量超過了這一預(yù)留的工作量，則再進(jìn)行變更可能會對總成本和進(jìn)度安排產(chǎn)生負(fù)面影響。在這種情況中，項(xiàng)目經(jīng)理必須修改估計(jì)并使它們得到承認(rèn)。117chapter__４Infosys公司的項(xiàng)目經(jīng)理有時(shí)為處理變更申請預(yù)留一定的余地課堂討論

面對客戶的需求變更，接受還是拒絕？在某公司的項(xiàng)目管理課堂上，小李，小王等人正在七嘴八舌地議論紛紛。原來，大家正在討論小王的公司最近遇到的兩個(gè)頗為有趣的項(xiàng)目。據(jù)小王介紹，這兩個(gè)項(xiàng)目分別由兩個(gè)項(xiàng)目經(jīng)理來擔(dān)任。其中，項(xiàng)目經(jīng)理A屬于“謙虛”型，對于客戶提出的問題，無論大小都給與解決，客戶對此非常滿意，然而，項(xiàng)目進(jìn)度卻拖得比較長，而且，客戶總想把所有的問題都改完再說，項(xiàng)目已經(jīng)一再延期。相比之下，項(xiàng)目經(jīng)理B顯得稍有些“盛氣凌人”，對于客戶提出的問題，大多都不予理睬，客戶對此不是很滿意，不過，該項(xiàng)目的進(jìn)度控制得比較好，基本能夠按期完成項(xiàng)目。118chapter__４課堂討論

面對客戶的需求變更，接受還是拒絕？在某公司的項(xiàng)目話剛一說完，小李就搶著說：“A比較像我，一般在和我的一些戰(zhàn)略客戶打交道的時(shí)候，我基本是有求必應(yīng)，與客戶的關(guān)系處得如魚得水，這樣做肯定不會錯(cuò)。就像前天我連合同都寫錯(cuò)了，找到客戶，人家二話沒說就同意改了。你說如果是B的話可能嗎？”小王對此不以為然，“對項(xiàng)目經(jīng)理來說，成本、質(zhì)量和時(shí)間是最為重要的三要素。與客戶的關(guān)系當(dāng)然很重要，但也要全盤考慮項(xiàng)目的各要素。對于用戶的要求，應(yīng)該在有限的范圍內(nèi)給與解決，但不可以做出太大的犧牲。一味的遷就用戶將會使整個(gè)項(xiàng)目失敗?！毙×纸又⊥醯脑捳f：“當(dāng)前，國內(nèi)的項(xiàng)目一般情況下是由銷售處面簽單，再由項(xiàng)目經(jīng)理接手后續(xù)的工作，因此客戶關(guān)系多在事前已經(jīng)搞定。發(fā)生新的情況后，可以由公司的公關(guān)部出面與客戶進(jìn)行協(xié)調(diào)，項(xiàng)目經(jīng)理可以在此過程中堅(jiān)持一下原則，與公司的公關(guān)部一個(gè)紅臉，一個(gè)白臉，唱出一出好戲?！?19chapter__４話剛一說完，小李就搶著說：“A比較像我，一般在和我的一些戰(zhàn)略小趙反駁道：“不管怎樣，客戶才是第一位的。客戶可以給你帶來收入，也可以給你帶來更多的客戶和工作，有什么道理不多配合一下他們呢？說實(shí)話我對B的做法蠻欣賞的，可惜行不通。因?yàn)榭蛻羰巧系?，如果照B的做法，后果會造成做一次項(xiàng)目丟掉一個(gè)客戶，太不劃算了?！眴栴}：1、如果你的項(xiàng)目遇到需求變更問題，你會采用哪種方式去應(yīng)對？2、分析這兩種應(yīng)對需求變更方式的優(yōu)缺點(diǎn)。分析結(jié)果120chapter__４小趙反駁道：“不管怎樣，客戶才是第一位的?？蛻艨梢越o你帶來收121chapter__４121chapter__４小結(jié)軟件需求開發(fā)過程需求的獲取需求分析編寫需求規(guī)格需求驗(yàn)證需求變更需求建模的基本方法原型方法結(jié)構(gòu)化分析法面向?qū)ο蟮挠美治龇P(guān)鍵功能列表法122chapter__４小結(jié)軟件需求開發(fā)過程122chapter__４承上啟下項(xiàng)目合同管理生存期模型123chapter__４承上啟下項(xiàng)目合同管理0chapter__４RoadMap合同管理

生存期需求管理任務(wù)分解項(xiàng)目進(jìn)度規(guī)模估算質(zhì)量計(jì)劃配置計(jì)劃風(fēng)險(xiǎn)計(jì)劃團(tuán)隊(duì)管理項(xiàng)目度量集成項(xiàng)目跟蹤控制

項(xiàng)目結(jié)束124chapter__４RoadMap合同管理需求管理任務(wù)分解軟件開發(fā)項(xiàng)目管理第四章軟件項(xiàng)目需求管理125chapter__４軟件開發(fā)項(xiàng)目管理第四章2chapter__４需求管理中的問題舉例需求的隱含錯(cuò)誤需求不明確、含糊用戶不斷增加需求、變更需求用戶刁難開發(fā)人員的鍍金126chapter__４需求管理中的問題舉例需求的隱含錯(cuò)誤3chapter__４鍍金（goldplating）的定義

給予用戶的東西要多于他們所要求的。事實(shí)上，額外的特性、擴(kuò)展的功能、更好的組件以及其他等等，通常都不會為項(xiàng)目增加什么價(jià)值。實(shí)際上，鍍金常常會增加項(xiàng)目的開支，因?yàn)檫@需要更多的資源、更長的開發(fā)周期，還會增加重新設(shè)計(jì)的風(fēng)險(xiǎn)、耽誤項(xiàng)目的交付使用。127chapter__４鍍金（goldplating）的定義

給予用戶的東西要多鍍金案例在檢視項(xiàng)目要求的時(shí)候，你發(fā)現(xiàn)了一個(gè)需要?jiǎng)?chuàng)建軟件模塊的要求。這個(gè)模塊允許用戶在瀏覽應(yīng)用程序的時(shí)候，在屏幕上維持其所喜好的顏色和字體樣式。在更進(jìn)一步檢視的時(shí)候，你意識到這個(gè)模塊的加入雖然很好，但是不會為整個(gè)項(xiàng)目增添什么價(jià)值。128chapter__４鍍金案例在檢視項(xiàng)目要求的時(shí)候，你發(fā)現(xiàn)了一個(gè)需要?jiǎng)?chuàng)建軟件模塊的如何確定項(xiàng)目里是否包含有鍍金的內(nèi)容要驗(yàn)證開發(fā)要求或者任務(wù)里是否包含有鍍金內(nèi)容的一種方法是：思考一下如果項(xiàng)目沒有包含這個(gè)模塊的話，其影響會是什么。問問你自己：如果這個(gè)項(xiàng)目沒有包含這個(gè)模塊，這個(gè)應(yīng)用程序的可靠性、效率是否會更低，或者根本就不會有任何降低。129chapter__４如何確定項(xiàng)目里是否包含有鍍金的內(nèi)容要驗(yàn)證開發(fā)要求或者任務(wù)里是本章要點(diǎn)一、軟件需求定義二、軟件需求管理過程三、需求建模的基本方法四、案例分析130chapter__４本章要點(diǎn)一、軟件需求定義7chapter__４軟件需求定義軟件需求定義軟件需求需求是指用戶對軟件的功能和性能的要求，就是用戶希望軟件能做什么事情，完成什么樣的功能，達(dá)到什么性能。132chapter__４軟件需求需求是指用戶對軟件的功能和性能的要求，就是用戶希望軟軟件需求的層次業(yè)務(wù)需求用戶需求功能需求軟件需求規(guī)格非功能性需求質(zhì)量特性約束和假設(shè)系統(tǒng)需求133chapter__４軟件需求的層次業(yè)務(wù)需求用戶需求功能需求軟件需求規(guī)格非功能性需1．業(yè)務(wù)需求（businessrequirement）反映了組織機(jī)構(gòu)或客戶對系統(tǒng)、產(chǎn)品高層次的目標(biāo)要求，它們在項(xiàng)目視圖與范圍文檔中予以說明2．用戶需求(userrequirement)文檔描述了用戶使用產(chǎn)品必須要完成的任務(wù)，這在使用實(shí)例（usecase）文檔或方案腳本說明中予以說明。3．功能需求(functionalrequirement)定義了開發(fā)人員必須實(shí)現(xiàn)的軟件功能，使得用戶能完成他們的任務(wù)，從而滿足了業(yè)務(wù)需求。在軟件需求規(guī)格說明書（SRS）中說明的功能需求充分描述了軟件系統(tǒng)所應(yīng)具有的外部行為。軟件需求規(guī)格說明在開發(fā)、測試、質(zhì)量保證、項(xiàng)目管理以及相關(guān)項(xiàng)目功能中都起了重要的作用。對一個(gè)大型系統(tǒng)來說，軟件功能需求也許只是系統(tǒng)需求的一個(gè)子集，因?yàn)榱硗庖恍┛赡軐儆谧酉到y(tǒng)（或軟件部件）。134chapter__４1．業(yè)務(wù)需求（businessrequirement）反映作為功能需求的補(bǔ)充，軟件需求規(guī)格說明還應(yīng)包括非功能需求，它描述了系統(tǒng)展現(xiàn)給用戶的行為和執(zhí)行的操作等。它包括產(chǎn)品必須遵從的標(biāo)準(zhǔn)、規(guī)范和合約；外部界面的具體細(xì)節(jié)；性能要求；設(shè)計(jì)或?qū)崿F(xiàn)的約束條件及質(zhì)量屬性。所謂約束是指對開發(fā)人員在軟件產(chǎn)品設(shè)計(jì)和構(gòu)造上的限制。質(zhì)量屬性是通過多種角度對產(chǎn)品的特點(diǎn)進(jìn)行描述，從而反映產(chǎn)品功能。多角度描述產(chǎn)品對用戶和開發(fā)人員都極為重要。135chapter__４作為功能需求的補(bǔ)充，軟件需求規(guī)格說明還應(yīng)包括非功能需求，它描以一個(gè)字處理程序?yàn)槔齺碚f明需求的不同種類。

業(yè)務(wù)需求可能是：“用戶能有效地糾正文檔中的拼寫錯(cuò)誤”，該產(chǎn)品的包裝盒封面上可能會標(biāo)明這是個(gè)滿足業(yè)務(wù)需求的拼寫檢查器。用戶需求可能是“找出文檔中的拼寫錯(cuò)誤并通過一個(gè)提供的替換項(xiàng)列表來供選擇替換拼錯(cuò)的詞”。同時(shí)，該拼寫檢查器還有許多功能需求，如找到并高亮度提示錯(cuò)詞的操作；顯示提供替換詞的對話框以及實(shí)現(xiàn)整個(gè)文檔范圍的替換。136chapter__４以一個(gè)字處理程序?yàn)槔齺碚f明需求的不同種類。13功能需求功能需求：列舉出被開發(fā)軟件在職能上應(yīng)做什么。這是最主要的需求，規(guī)定開發(fā)人員必須在產(chǎn)品中實(shí)現(xiàn)的軟件功能，用戶利用這些功能來完成任務(wù)，滿足業(yè)務(wù)需求。通常功能性需求是：產(chǎn)品功能的規(guī)格說明；產(chǎn)品必須執(zhí)行的動作；源自于產(chǎn)品的基本目標(biāo)例如：銀行ATM系統(tǒng)功能性需求：取、存、查、密碼檢驗(yàn)

137chapter__４功能需求功能需求：列舉出被開發(fā)軟件在職能上應(yīng)做什么。這是最主非功能需求許多非功能需求關(guān)心的是系統(tǒng)整體特性，而不是個(gè)別的系統(tǒng)特性。因此非功能需求比功能需求對系統(tǒng)更關(guān)鍵。一個(gè)功能需求沒有滿足可能降低系統(tǒng)的能力，而一個(gè)非功能系統(tǒng)需求沒有滿足則可能使整個(gè)系統(tǒng)無法使用。例如：一個(gè)飛機(jī)系統(tǒng)不符合可靠性需求，它將不會被批準(zhǔn)飛行。若一個(gè)實(shí)時(shí)控制系統(tǒng)無法滿足其性能需求，控制功能可能根本無法使用。例如：銀行ATM系統(tǒng)非功能需求：響應(yīng)時(shí)間，安全保密等

138chapter__４非功能需求許多非功能需求關(guān)心的是系統(tǒng)整體特性，而不是個(gè)別的系需求管理的重要性139chapter__４需求管理的重要性16chapter__４項(xiàng)目失敗的原因分析No.

Top10Factors

平均值

1

Inadequaterequirementsspecification

不充分的需求規(guī)范

4.5

2

Changesinrequirements

需求的改變

4.3

3

Shortageofsystemsengineers

缺乏系統(tǒng)工程師

4.2

4

Shortageofsoftwaremanagers缺乏了解軟件特性的經(jīng)理人

4.1

5

Shortageofqualifiedprojectmanagers缺乏合格的項(xiàng)目經(jīng)理

4.1

6

Shortageofsoftwareengineers缺乏軟件工程師

3.9

7

Fixed-pricecontract固定價(jià)合同

3.8

8

Inadequatecommunicationsforsystemintegration系統(tǒng)集成階段,交流與溝通不充分

3.8

9

Insufficientexperienceasteam團(tuán)隊(duì)缺乏經(jīng)驗(yàn)

3.6

10

Shortageofapplicationdomainexperts缺乏應(yīng)用領(lǐng)域?qū)＜?/p>

3.6

Scale:5=VerySerious3=Serious1=NoSerious

Source:Carnegie-MellonUniversity,SoftwareEngineeringInstitute140chapter__４項(xiàng)目失敗的原因分析No.Top10Factors平均本章要點(diǎn)一、軟件需求定義二、軟件需求管理過程三、需求建模的基本方法四、案例分析141chapter__４本章要點(diǎn)一、軟件需求定義18chapter__４軟件需求管理過程軟件需求管理過程軟件需求管理的過程需求分析編寫需求規(guī)格需求驗(yàn)證需求獲取需求變更需求確認(rèn)需求變更143chapter__４軟件需求管理的過程需求分析編寫需求規(guī)格需求驗(yàn)證需求獲取需求變需求開發(fā)(確認(rèn))和管理基本任務(wù)需求工程需求管理需求開發(fā)需求獲取需求分析需求規(guī)格說明需求驗(yàn)證變更管理版本控制風(fēng)險(xiǎn)分析144chapter__４需求開發(fā)(確認(rèn))和管理基本任務(wù)需求工程需求管理需求開發(fā)需求獲本章要點(diǎn)一、軟件需求定義二、軟件需求管理過程需求的獲取需求分析編寫需求規(guī)格需求驗(yàn)證需求變更三、需求建模的基本方法四、案例分析145chapter__４本章要點(diǎn)一、軟件需求定義22chapter__４需求獲取圖示146chapter__４需求獲取圖示23chapter__４需求獲取用戶要求

擴(kuò)展需求基線需求軟件需求147chapter__４需求獲取用戶要求軟件需求24chapter__４程、硬件環(huán)境、軟件環(huán)境、現(xiàn)有的運(yùn)行系統(tǒng)等具體情況和客觀的信息，建立起良好的溝通渠道和方式148chapter__４程、硬件環(huán)境、軟件環(huán)境、現(xiàn)有的運(yùn)行系統(tǒng)等具體情況和客觀的信息149chapter__４26chapter__４進(jìn)行需求獲取應(yīng)注意的問題識別真正的客戶正確理解客戶的需求具備較強(qiáng)的忍耐力和清晰的思維說明和教育客戶150chapter__４進(jìn)行需求獲取應(yīng)注意的問題識別真正的客戶27chapter_本章要點(diǎn)一、軟件需求定義二、軟件需求管理過程需求的獲取需求分析編寫需求規(guī)格需求驗(yàn)證需求變更三、需求建模的基本方法四、案例分析151chapter__４本章要點(diǎn)一、軟件需求定義28chapter__４需求分析定義需求分析是為最終用戶所看到的系統(tǒng)建立一個(gè)概念模型，是對需求的抽象描述。152chapter__４需求分析定義需求分析是為最終用戶所看到的系統(tǒng)建立一個(gè)概念模型需求分析模型153chapter__４需求分析模型30chapter__４本章要點(diǎn)一、軟件需求定義二、軟件需求管理過程需求的獲取需求分析編寫需求規(guī)格需求驗(yàn)證需求變更三、需求建模的基本方法四、案例分析154chapter__４本章要點(diǎn)一、軟件需求定義31chapter__４需求規(guī)格需求分析工作完成的一個(gè)基本標(biāo)志是形成了一份完整的、規(guī)范的需求規(guī)格說明書需求規(guī)格說明書的編制是為了使用戶和軟件開發(fā)者雙方對該軟件的初始規(guī)定有一個(gè)共同的理解，使之成為整個(gè)開發(fā)工作的基礎(chǔ)。155chapter__４需求規(guī)格需求分析工作完成的一個(gè)基本標(biāo)志是形成了一份完整的、規(guī)軟件需求規(guī)格說明的原則從現(xiàn)實(shí)中分離功能，即描述要“做什么”而不是“怎樣實(shí)現(xiàn)”要求使用面向處理的規(guī)格說明語言（或稱系統(tǒng)定義語言）如果被開發(fā)軟件只是一個(gè)大系統(tǒng)中的一個(gè)元素，那么整個(gè)大系統(tǒng)也包括在規(guī)格說明的描述之中156chapter__４軟件需求規(guī)格說明的原則從現(xiàn)實(shí)中分離功能，即描述要“做什么”而規(guī)格說明應(yīng)該包括系統(tǒng)運(yùn)行環(huán)境規(guī)格說明應(yīng)該是一個(gè)認(rèn)識模型規(guī)格說明應(yīng)該容許不完備性并允許擴(kuò)充157chapter__４規(guī)格說明應(yīng)該包括系統(tǒng)運(yùn)行環(huán)境34chapter__４3、規(guī)格文檔參考引言系統(tǒng)定義應(yīng)用環(huán)境功能規(guī)格性能需求產(chǎn)品提交實(shí)現(xiàn)約束質(zhì)量描述其它簽字認(rèn)證158chapter__４3、規(guī)格文檔參考引言35chapter__４本章要點(diǎn)一、軟件需求定義二、軟件需求管理過程需求的獲取需求分析編寫需求規(guī)格需求驗(yàn)證需求變更三、需求建模的基本方法四、案例分析159chapter__４本章要點(diǎn)一、軟件需求定義36chapter__４需求驗(yàn)證需求是正確的嗎？需求是一致的嗎？需求是完全的嗎？需求是實(shí)際可行的嗎？需求是必要的嗎？需求是可檢驗(yàn)的嗎？需求是可跟蹤的嗎？最后的簽字160chapter__４需求驗(yàn)證需求是正確的嗎？37chapter__４本章要點(diǎn)一、軟件需求定義二、軟件需求管理過程需求的獲取需求分析編寫需求規(guī)格需求驗(yàn)證需求變更三、需求建模的基本方法四、案例分析161chapter__４本章要點(diǎn)一、軟件需求定義38chapter__４需求總在變化162chapter__４需求總在變化39chapter__４163chapter__４40chapter__４需求變更管理確定需求變更控制過程建立變更控制委員會(SCCB)進(jìn)行需求變更影響分析跟蹤所有受需求變更影響的工作產(chǎn)品建立需求基準(zhǔn)版本和需求控制版本文檔維護(hù)需求變更的歷史記錄跟蹤每項(xiàng)需求的狀態(tài)衡量需求穩(wěn)定性164chapter__４需求變更管理確定需求變更控制過程41chapter__４需求變更管理管理和控制需求基線的過程需求變更控制系統(tǒng)一個(gè)正式的文檔，說明如何控制需求變更建立變更審批系統(tǒng)165chapter__４需求變更管理管理和控制需求基線的過程42chapter__控制需求漸變的策略需求一定要與投入有顯然的聯(lián)系，在項(xiàng)目的開始雙方都要明確：需求變化，成本也要變化。需求的變化要經(jīng)過出資者的認(rèn)可。小的需求變更也要經(jīng)過正規(guī)的需求管理過程，否則積少成多。精確的需求和范圍的定義并不會阻止需求的變更。這是兩個(gè)層面的問題。166chapter__４控制需求漸變的策略需求一定要與投入有顯然的聯(lián)系，在項(xiàng)目的開始變更控制過程167chapter__４變更控制過程44chapter__４需求變更處理流程提出變更變更評估實(shí)施變更168chapter__４需求變更處理流程提出變更45chapter__４變更申請需求方開發(fā)方忽略選擇變更方式SCCB評估項(xiàng)目經(jīng)理自行決定根據(jù)評估結(jié)果拒絕接受本次修改下個(gè)版本再修改修改合同相關(guān)信息修改相關(guān)需求修改相應(yīng)的項(xiàng)目計(jì)劃169chapter__４變更申請需求方開發(fā)方忽略選擇變更方式SCCB評估項(xiàng)目經(jīng)理自行表4-3需求變更提交單軟件基線產(chǎn)品修改提交單申請人韓萬江申請日期2002。10．11項(xiàng)目名稱項(xiàng)目管理系統(tǒng)階段名稱系統(tǒng)設(shè)計(jì)文件名稱RCR-PM-01.doc,RCR-PM-02.doc,變更簡述如下修改內(nèi)容1）修改測試流程控制：將2個(gè)角色，3個(gè)渠道流，改為3個(gè)角色，4個(gè)渠道流，詳見RCR-PM-01.doc2）增加開發(fā)人員技能信息庫管理，詳見RCR-PM-02.doc

驗(yàn)證意見同意RCR-PM-01.doc變更。RCR-PM-02.doc的變更可以推遲到下一個(gè)版本實(shí)施驗(yàn)證人楊炎泰驗(yàn)證日期2002．10．11SCCB韓萬江，姜岳尊，孫泉

填表人韓萬江170chapter__４表4-3需求變更提交單軟件基線產(chǎn)品修改提交單申請人韓萬江申需求變更管理原則（1）建立需求基線。需求基線是需求變更的依據(jù)。在開發(fā)過程中，需求確定并經(jīng)過評審后(用戶參與評審)，可以建立第一個(gè)需求基線。此后每次變更并經(jīng)過評審后，都要重新確定新的需求基線。（2）制訂簡單、有效的變更控制流程，并形成文檔。在建立了需求基線后提出的所有變更都必須遵循這個(gè)控制流程進(jìn)行控制。同時(shí)，這個(gè)流程具有一定的普遍性，對以后的項(xiàng)目開發(fā)和其他項(xiàng)目都有借鑒作用。（3）成立項(xiàng)目變更控制委員會(CCB)或相關(guān)職能的類似組織，負(fù)責(zé)裁定接受哪些變更。CCB由項(xiàng)目所涉及的多方人員共同組成，應(yīng)該包括用戶方和開發(fā)方的決策人員在內(nèi)。（4）需求變更一定要先申請然后再評估，最后經(jīng)過與變更大小相當(dāng)級別的評審確認(rèn)。（5）需求變更后，受影響的軟件計(jì)劃、產(chǎn)品、活動都要進(jìn)行相應(yīng)的變更，以保持和更新的需求一致。（6）妥善保存變更產(chǎn)生的相關(guān)文檔。171chapter__４需求變更管理原則（1）建立需求基線。需求基線是需求變更需求變更應(yīng)對之道?相互協(xié)作——很難想像遭到用戶抵制的項(xiàng)目能夠成功。在討論需求時(shí)，開發(fā)人員與用戶應(yīng)該盡量采取相互理解、相互協(xié)作的態(tài)度，對能解決的問題盡量解決。即使用戶提出了在開發(fā)人員看來"過分"的要求，也應(yīng)該仔細(xì)分析原因，積極提出可行的替代方案。?充分交流——需求變更管理的過程很大程度上就是用戶與開發(fā)人員的交流過程。軟件開發(fā)人員必須學(xué)會認(rèn)真聽取用戶的要求、考慮和設(shè)想，并加以分析和整理。同時(shí)，軟件開發(fā)人員應(yīng)該向用戶說明，進(jìn)入設(shè)計(jì)階段以后，再提出需求變更會給整個(gè)開發(fā)工作帶來什么樣的沖擊和不良后果。?安排專職人員負(fù)責(zé)需求變更管理——有時(shí)開發(fā)任務(wù)較重，開發(fā)人員容易陷入開發(fā)工作中而忽略了與用戶的隨時(shí)溝通，因此需要一名專職的需求變更管理人員負(fù)責(zé)與用戶及時(shí)交流。?合同約束——需求變更給軟件開發(fā)帶來的影響有目共睹，所以在與用戶簽訂合同時(shí)，可以增加一些相關(guān)條款，如限定用戶提出需求變更的時(shí)間，規(guī)定何種情況的變更可以接受、拒絕接受或部分接受，還可以規(guī)定發(fā)生需求變更時(shí)必須執(zhí)行變更控制流程。?區(qū)別對待——隨著開發(fā)進(jìn)展，有些用戶會不斷提出一些在項(xiàng)目組看來確實(shí)無法實(shí)現(xiàn)或工作量比較大、172chapter__４需求變更應(yīng)對之道?相互協(xié)作——很難想像遭到用戶抵制的項(xiàng)目能需求變更應(yīng)對之道?對項(xiàng)目進(jìn)度有重大影響的需求。遇到這種情況，開發(fā)人員可以向用戶說明，項(xiàng)目的啟動是以最初的基本需求作為開發(fā)前提的，如果大量增加新的需求(雖然用戶認(rèn)為是細(xì)化需求，但實(shí)際上是增加了工作量的新需求)，會使項(xiàng)目不能按時(shí)完成。如果用戶堅(jiān)持實(shí)施新需求，可以建議用戶將新需求按重要和緊迫程度劃分檔次，作為需求變更評估的一項(xiàng)依據(jù)。同時(shí)，還要注意控制新需求提出的頻率。?選用適當(dāng)?shù)拈_發(fā)模型——采用建立原型的開發(fā)模型比較適合需求不明確的開發(fā)項(xiàng)目。開發(fā)人員先根據(jù)用戶對需求的說明建立一個(gè)系統(tǒng)原型，再與用戶溝通。一般用戶看到一些實(shí)際的東西后，對需求會有更為詳細(xì)的解釋，開發(fā)人員可根據(jù)用戶的說明進(jìn)一步完善系統(tǒng)原型。這個(gè)過程重復(fù)幾次后，系統(tǒng)原型逐漸向最終的用戶需求靠攏，從根本上減少需求變更的出現(xiàn)。目前業(yè)界較為流行的疊代式開發(fā)方法對工期緊迫的項(xiàng)目的需求變更控制很有成效。?用戶參與需求評審——作為需求的提出者，用戶理所當(dāng)然是最具權(quán)威的發(fā)言人之一。實(shí)際上，在需求評審過程中，用戶往往能提出許多有價(jià)值的意見。同時(shí)，這也是由用戶對需求進(jìn)行最后確認(rèn)的機(jī)會，可以有效減少需求變更的發(fā)生。173chapter__４需求變更應(yīng)對之道?對項(xiàng)目進(jìn)度有重大影響的需求。遇到這種情況，本章要點(diǎn)一、軟件需求定義二、軟件需求管理過程三、需求建模的基本方法四、案例分析174chapter__４本章要點(diǎn)一、軟件需求定義51chapter__４需求建模的基本方法原型方法結(jié)構(gòu)化分析法面向?qū)ο蟮挠美治龇üδ芰斜矸ㄆ渌?75chapter__４需求建模的基本方法原型方法52chapter__４本章要點(diǎn)一、軟件需求定義二、軟件需求管理過程三、需求建模的基本方法原型方法結(jié)構(gòu)化分析法面向?qū)ο蟮挠美治龇üδ芰斜矸ㄆ渌?、案例分?76chapter__４本章要點(diǎn)一、軟件需求定義53chapter__４原型方法按照用戶的需要，快速形成一個(gè)操作流程界面可能只是一個(gè)框架，具體的功能沒有實(shí)現(xiàn)，只是結(jié)果靜態(tài)的操作流程，以便與用戶快速就需求達(dá)成一致主要考慮系統(tǒng)的功能需求，很少考慮非功能需求177chapter__４原型方法按照用戶的需要，快速形成一個(gè)操作流程界面54cha原型方法需求分析原型開發(fā)原型評價(jià)178chapter__４原型方法需求分析原型開發(fā)原型評價(jià)55chapter__４原型方法的類型進(jìn)化型開發(fā)出來用于了解問題，并形成被交付軟件的部分或全部的基礎(chǔ)拋棄型開發(fā)出來獲以便更多地了解問題或探究可能的方案的靈活性或者合理性，是嘗試性軟件，不用于被交付軟件的實(shí)際部分179chapter__４原型方法的類型進(jìn)化型56chapter__４原型實(shí)例原型系統(tǒng)180chapter__４原型實(shí)例原型系統(tǒng)57chapter__４本章要點(diǎn)一、軟件需求定義二、軟件需求管理過程三、需求建模的基本方法原型方法結(jié)構(gòu)化分析法面向?qū)ο蟮挠美治龇üδ芰斜矸ㄆ渌?、案例分?81chapter__４本章要點(diǎn)一、軟件需求定義58chapter__４結(jié)構(gòu)化分析方法（SA,StructuredAnalysis）

20世紀(jì)70年發(fā)展起來的面向數(shù)據(jù)流的方法是一種自頂向下逐步求精的分析方法根據(jù)軟件內(nèi)部數(shù)據(jù)傳遞、變換的關(guān)系進(jìn)行分析的182chapter__４結(jié)構(gòu)化分析方法（SA,StructuredAnalysis結(jié)構(gòu)化分析方法-技術(shù)數(shù)據(jù)流圖(DFD)數(shù)據(jù)字典(DD)系統(tǒng)流程圖183chapter__４結(jié)構(gòu)化分析方法-技術(shù)數(shù)據(jù)流圖(DFD)60chapter_描述銀行取款過程的數(shù)據(jù)流圖184chapter__４描述銀行取款過程的數(shù)據(jù)流圖61chapter__４數(shù)據(jù)流圖的層次結(jié)構(gòu)為了表達(dá)數(shù)據(jù)處理過程的數(shù)據(jù)加工情況，需要采用層次結(jié)構(gòu)的數(shù)據(jù)流圖。按照系統(tǒng)的層次結(jié)構(gòu)進(jìn)行逐步分解，并以分層的數(shù)據(jù)流圖反映這種結(jié)構(gòu)關(guān)系，能清楚地表達(dá)和容易理解整個(gè)系統(tǒng)185chapter__４數(shù)據(jù)流圖的層次結(jié)構(gòu)為了表達(dá)數(shù)據(jù)處理過程的數(shù)據(jù)加工情況，需要采分層數(shù)據(jù)流圖186chapter__４分層數(shù)據(jù)流圖63chapter__４數(shù)據(jù)字典描述系統(tǒng)中涉及的每個(gè)數(shù)據(jù),是數(shù)據(jù)描述的集合,通常配合數(shù)據(jù)流圖使用,用來描述數(shù)據(jù)流圖中出現(xiàn)的各種數(shù)據(jù)和加工.187chapter__４數(shù)據(jù)字典描述系統(tǒng)中涉及的每個(gè)數(shù)據(jù),是數(shù)據(jù)描述的集合,通常配合數(shù)據(jù)字典-組成數(shù)據(jù)項(xiàng):數(shù)據(jù)元素?cái)?shù)據(jù)流:由數(shù)據(jù)項(xiàng)組成的數(shù)據(jù)流數(shù)據(jù)文件:表示對數(shù)據(jù)文件的存儲188chapter__４數(shù)據(jù)字典-組成數(shù)據(jù)項(xiàng):數(shù)據(jù)元素65chapter__４數(shù)據(jù)流圖需求分析實(shí)例建立學(xué)生管理系統(tǒng)學(xué)管科體檢科學(xué)籍科學(xué)生處189chapter__４數(shù)據(jù)流圖需求分析實(shí)例建立學(xué)生管理系統(tǒng)66chapter__數(shù)據(jù)流圖-頂層學(xué)管科體檢科學(xué)籍科學(xué)生管理信息系統(tǒng)學(xué)生處領(lǐng)導(dǎo)學(xué)生基本信息學(xué)生健康信息學(xué)生成績學(xué)生健康情況表學(xué)生成績單查詢要求不及格人數(shù)人數(shù)統(tǒng)計(jì)表190chapter__４數(shù)據(jù)流圖-頂層學(xué)管科體檢科學(xué)籍科學(xué)生管理學(xué)生處領(lǐng)導(dǎo)學(xué)生基本信數(shù)據(jù)流圖-0層191chapter__４數(shù)據(jù)流圖-0層68chapter__４數(shù)據(jù)流圖-1層192chapter__４數(shù)據(jù)流圖-1層69chapter__４數(shù)據(jù)流圖-1層193chapter__４數(shù)據(jù)流圖-1層70chapter__４數(shù)據(jù)字典-數(shù)據(jù)流

學(xué)生基本信息：學(xué)號十姓名學(xué)生健康信息：學(xué)號十健康情況學(xué)生成績：學(xué)號十{課程名+成績}查詢要求：[健康查詢單|平均成績查詢單l不及格人數(shù)查詢]學(xué)生健康情況表：優(yōu)％十良％十一般％十差％學(xué)生成績單：學(xué)號十姓名十{課程名+成績}+總成績不及格人數(shù)統(tǒng)計(jì)表：學(xué)號十成績十不及格總?cè)藬?shù)194chapter__４數(shù)據(jù)字典-數(shù)據(jù)流學(xué)生基本信息：學(xué)號十姓名71cha數(shù)據(jù)字典-數(shù)據(jù)文件文件名：基本信息組成：｛學(xué)號十姓名十入學(xué)成績十生源｝組織：按學(xué)號遞增順序排列文件名：健康文件組成：{學(xué)號+姓名+健康情況}組織：按照健康情況為優(yōu)、良、一般、差順序排列文件名：成績文件組成：{學(xué)號+姓名+平均成績}組織：按照評劇成績遞增順序排列195chapter__４數(shù)據(jù)字典-數(shù)據(jù)文件文件名：基本信息72chapter__４系統(tǒng)流程圖系統(tǒng)包含的部分以及各個(gè)部分之間的關(guān)系是描述物理系統(tǒng)的工具用圖形符號表示系統(tǒng)中的元素表達(dá)了系統(tǒng)中各個(gè)元素之間的信息流動情況196chapter__４系統(tǒng)流程圖系統(tǒng)包含的部分以及各個(gè)部分之間的關(guān)系73chap系統(tǒng)流程圖符號197chapter__４系統(tǒng)流程圖符號74chapter__４198chapter__４75chapter__４本章要點(diǎn)一、軟件需求定義二、軟件需求管理過程三、需求建模的基本方法原型方法結(jié)構(gòu)化分析法面向?qū)ο蟮挠美治龇üδ芰斜矸ㄆ渌?、案例分?99chapter__４本章要點(diǎn)一、軟件需求定義76chapter__４面向?qū)ο蟮男枨蠓治鯫OSEOOAOODOOPOOT…….200chapter__４面向?qū)ο蟮男枨蠓治鯫OSE77chapter__４OOA是OO軟件工程的第一項(xiàng)技術(shù)活動將現(xiàn)實(shí)世界的“視圖”轉(zhuǎn)化為用對象來描述的模型描述對象之間的各種關(guān)系，以滿足軟件系統(tǒng)的要求。201chapter__４OOA是OO軟件工程的第一項(xiàng)技術(shù)活動78chapter__用例需求（Usecase）分析用例需求分析方法采用一種面向?qū)ο蟮那榫胺治龇椒ㄓ美窍到y(tǒng)向用戶提供一個(gè)有價(jià)值的結(jié)果的某項(xiàng)功能從用戶角度出發(fā)考慮的功能需求所有的用例結(jié)合起來就構(gòu)成了用例模型202chapter__４用例需求（Usecase）分析用例需求分析方法采用一種面向UML需求視圖用例視圖（UsecaseDiagram）順序圖（SequenceDiagram）狀態(tài)圖（StateDiagram）活動圖（ActivityDiagram）203chapter__４UML需求視圖用例視圖（UsecaseDiagram）8204chapter__４81chapter__４205chapter__４82chapter__４206chapter__４83chapter__４207chapter__４84chapter__４用例視圖用例視圖主要是展示了外部行為者所觀察到的系統(tǒng)將提交的功能.即:各類外部行為者與系統(tǒng)所提供的用例的連接208chapter__４用例視圖用例視圖主要是展示了外部行為者所觀察到的系統(tǒng)將提交的用例視圖用例（Usecase）：系統(tǒng)所提供的功能描述角色（Actor）：可能使用用例的人或者外部系統(tǒng)209chapter__４用例視圖用例（Usecase）：系統(tǒng)所提供的功能描述86UML圖符210chapter__４UML圖符87chapter__４通信關(guān)系：執(zhí)行者與用例之間的連線來表示泛化關(guān)系：用例間的泛化關(guān)系意味著一個(gè)用例是另一個(gè)用例的特殊版本，特殊用例可在一般用例的執(zhí)行序列的任意位置插入額外的動作序列，也可修改某些繼承來的操作和順序。在UML中用帶連線的三角形表示。包含關(guān)系：描述用例間的共同行為，當(dāng)兩個(gè)或多個(gè)用例有共同的執(zhí)行序列片斷時(shí)，可將這些序列片斷抽取，形成被包含用例。UML中用標(biāo)有《include》的虛箭頭線來表示。有點(diǎn)類似于程序間的調(diào)用關(guān)系。擴(kuò)展關(guān)系：當(dāng)對一個(gè)已存在的用例增加新的功能時(shí)，可使用擴(kuò)展關(guān)系，擴(kuò)展關(guān)系一般用于有條件地?cái)U(kuò)展已有用例的行為，是一種不改變原始用例的情況下增加用例行為的一種方法。211ch