軟件過(guò)程管理(5)課件

1、承上啟下項(xiàng)目合同管理生存期模型0 chapter_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é)束1 chapter_軟件開發(fā)項(xiàng)目管理第四章軟件項(xiàng)目需求管理2 chapter_需求管理中的問(wèn)題舉例需求的隱含錯(cuò)誤需求不明確、含糊用戶不斷增加需求、變更需求用戶刁難開發(fā)人員的鍍金3 chapter_鍍金（gold plating）的定義 給予用戶的東西要多于他們所要求的。 事實(shí)上，額外的特性、擴(kuò)展的功能、更好的組件以及其他等等，通常都不會(huì)為項(xiàng)目增加什么價(jià)值。實(shí)際上，鍍金常常會(huì)增加項(xiàng)目的開支，因?yàn)檫@需要更多的資源、更長(zhǎng)的開

2、發(fā)周期，還會(huì)增加重新設(shè)計(jì)的風(fēng)險(xiǎn)、耽誤項(xiàng)目的交付使用。4 chapter_鍍金案例在檢視項(xiàng)目要求的時(shí)候，你發(fā)現(xiàn)了一個(gè)需要?jiǎng)?chuàng)建軟件模塊的要求。這個(gè)模塊允許用戶在瀏覽應(yīng)用程序的時(shí)候，在屏幕上維持其所喜好的顏色和字體樣式。在更進(jìn)一步檢視的時(shí)候，你意識(shí)到這個(gè)模塊的加入雖然很好，但是不會(huì)為整個(gè)項(xiàng)目增添什么價(jià)值。 5 chapter_如何確定項(xiàng)目里是否包含有鍍金的內(nèi)容要驗(yàn)證開發(fā)要求或者任務(wù)里是否包含有鍍金內(nèi)容的一種方法是：思考一下如果項(xiàng)目沒(méi)有包含這個(gè)模塊的話，其影響會(huì)是什么。問(wèn)問(wèn)你自己：如果這個(gè)項(xiàng)目沒(méi)有包含這個(gè)模塊，這個(gè)應(yīng)用程序的可靠性、效率是否會(huì)更低，或者根本就不會(huì)有任何降低。6 chapter_本章要點(diǎn)

3、一、軟件需求定義二、軟件需求管理過(guò)程三、需求建模的基本方法四、案例分析7 chapter_軟件需求定義軟件需求需求是指用戶對(duì)軟件的功能和性能的要求，就是用戶希望軟件能做什么事情，完成什么樣的功能，達(dá)到什么性能。9 chapter_軟件需求的層次業(yè)務(wù)需求用戶需求功能需求軟件需求規(guī)格非功能性需求質(zhì)量特性約束和假設(shè)系統(tǒng)需求10 chapter_1業(yè)務(wù)需求（business requirement）反映了組織機(jī)構(gòu)或客戶對(duì)系統(tǒng)、產(chǎn)品高層次的目標(biāo)要求，它們?cè)陧?xiàng)目視圖與范圍文檔中予以說(shuō)明 2用戶需求(user requirement) 文檔描述了用戶使用產(chǎn)品必須要完成的任務(wù)，這在使用實(shí)例（use case）

4、文檔或方案腳本說(shuō)明中予以說(shuō)明。3功能需求(functional requirement)定義了開發(fā)人員必須實(shí)現(xiàn)的軟件功能，使得用戶能完成他們的任務(wù)，從而滿足了業(yè)務(wù)需求。 在軟件需求規(guī)格說(shuō)明書 （SRS）中說(shuō)明的功能需求充分描述了軟件系統(tǒng)所應(yīng)具有的外部行為。軟件需求規(guī)格說(shuō)明在開發(fā)、測(cè)試、質(zhì)量保證、項(xiàng)目管理以及相關(guān)項(xiàng)目功能中都起了重要的作用。對(duì)一個(gè)大型系統(tǒng)來(lái)說(shuō)，軟件功能需求也許只是系統(tǒng)需求的一個(gè)子集，因?yàn)榱硗庖恍┛赡軐儆谧酉到y(tǒng)（或軟件部件）。11 chapter_作為功能需求的補(bǔ)充，軟件需求規(guī)格說(shuō)明還應(yīng)包括非功能需求，它描述了系統(tǒng)展現(xiàn)給用戶的行為和執(zhí)行的操作等。它包括產(chǎn)品必須遵從的標(biāo)準(zhǔn)、規(guī)范和合約

5、；外部界面的具體細(xì)節(jié)；性能要求；設(shè)計(jì)或?qū)崿F(xiàn)的約束條件及質(zhì)量屬性。所謂約束是指對(duì)開發(fā)人員在軟件產(chǎn)品設(shè)計(jì)和構(gòu)造上的限制。質(zhì)量屬性是通過(guò)多種角度對(duì)產(chǎn)品的特點(diǎn)進(jìn)行描述，從而反映產(chǎn)品功能。多角度描述產(chǎn)品對(duì)用戶和開發(fā)人員都極為重要。12 chapter_ 以一個(gè)字處理程序?yàn)槔齺?lái)說(shuō)明需求的不同種類。 業(yè)務(wù)需求可能是：“用戶能有效地糾正文檔中的拼寫錯(cuò)誤”，該產(chǎn)品的包裝盒封面上可能會(huì)標(biāo)明這是個(gè)滿足業(yè)務(wù)需求的拼寫檢查器。用戶需求可能是“找出文檔中的拼寫錯(cuò)誤并通過(guò)一個(gè)提供的替換項(xiàng)列表來(lái)供選擇替換拼錯(cuò)的詞”。同時(shí)，該拼寫檢查器還有許多功能需求，如找到并高亮度提示錯(cuò)詞的操作；顯示提供替換詞的對(duì)話框以及實(shí)現(xiàn)整個(gè)文檔范圍的

6、替換。13 chapter_功能需求功能需求：列舉出被開發(fā)軟件在職能上應(yīng)做什么。這是最主要的需求，規(guī)定開發(fā)人員必須在產(chǎn)品中實(shí)現(xiàn)的軟件功能，用戶利用這些功能來(lái)完成任務(wù)，滿足業(yè)務(wù)需求。通常功能性需求是： 產(chǎn)品功能的規(guī)格說(shuō)明； 產(chǎn)品必須執(zhí)行的動(dòng)作； 源自于產(chǎn)品的基本目標(biāo)例如：銀行ATM系統(tǒng) 功能性需求：取、存、查、密碼檢驗(yàn) 14 chapter_非功能需求許多非功能需求關(guān)心的是系統(tǒng)整體特性，而不是個(gè)別的系統(tǒng)特性。因此非功能需求比功能需求對(duì)系統(tǒng)更關(guān)鍵。一個(gè)功能需求沒(méi)有滿足可能降低系統(tǒng)的能力，而一個(gè)非功能系統(tǒng)需求沒(méi)有滿足則可能使整個(gè)系統(tǒng)無(wú)法使用。例如：一個(gè)飛機(jī)系統(tǒng)不符合可靠性需求，它將不會(huì)被批準(zhǔn)飛行。若

7、一個(gè)實(shí)時(shí)控制系統(tǒng)無(wú)法滿足其性能需求，控制功能可能根本無(wú)法使用。例如：銀行ATM系統(tǒng) 非功能需求：響應(yīng)時(shí)間，安全保密等 15 chapter_需求管理的重要性16 chapter_項(xiàng)目失敗的原因分析No. Top 10 Factors 平均值 1 Inadequate requirements specification 不充分的需求規(guī)范 4.5 2 Changes in requirements 需求的改變 4.3 3 Shortage of systems engineers 缺乏系統(tǒng)工程師 4.2 4 Shortage of software managers 缺乏了解軟件特性的經(jīng)理人 4

8、.1 5 Shortage of qualified project managers 缺乏合格的項(xiàng)目經(jīng)理 4.1 6 Shortage of software engineers 缺乏軟件工程師 3.9 7 Fixed- price contract 固定價(jià)合同 3.8 8 Inadequate communications for system integration 系統(tǒng)集成階段, 交流與溝通不充分 3.8 9 Insufficient experience as team團(tuán)隊(duì)缺乏經(jīng)驗(yàn) 3.6 10 Shortage of application domain experts 缺乏應(yīng)用領(lǐng)

9、域?qū)＜?3.6 Scale: 5 = Very Serious 3 = Serious 1 = No Serious Source: Carnegie-Mellon University, Software Engineering Institute17 chapter_本章要點(diǎn)一、軟件需求定義二、軟件需求管理過(guò)程三、需求建模的基本方法四、案例分析18 chapter_軟件需求管理過(guò)程軟件需求管理的過(guò)程需求分析編寫需求規(guī)格需求驗(yàn)證需求獲取需求變更需求確認(rèn)需求變更20 chapter_需求開發(fā)(確認(rèn))和管理基本任務(wù)需求工程需求管理需求開發(fā)需求獲取需求分析需求規(guī)格說(shuō)明需求驗(yàn)證變更管理版本控制風(fēng)險(xiǎn)分

10、析21 chapter_本章要點(diǎn)一、軟件需求定義二、軟件需求管理過(guò)程需求的獲取需求分析編寫需求規(guī)格需求驗(yàn)證需求變更三、需求建模的基本方法四、案例分析22 chapter_需求獲取圖示23 chapter_需求獲取用戶要求 擴(kuò)展需求基線需求軟件需求24 chapter_程、硬件環(huán)境、軟件環(huán)境、現(xiàn)有的運(yùn)行系統(tǒng)等具體情況和客觀的信息，建立起良好的溝通渠道和方式25 chapter_26 chapter_進(jìn)行需求獲取應(yīng)注意的問(wèn)題識(shí)別真正的客戶正確理解客戶的需求具備較強(qiáng)的忍耐力和清晰的思維說(shuō)明和教育客戶27 chapter_本章要點(diǎn)一、軟件需求定義二、軟件需求管理過(guò)程需求的獲取需求分析編寫需求規(guī)格需求驗(yàn)

11、證需求變更三、需求建模的基本方法四、案例分析28 chapter_需求分析定義需求分析是為最終用戶所看到的系統(tǒng)建立一個(gè)概念模型，是對(duì)需求的抽象描述。 29 chapter_需求分析模型30 chapter_本章要點(diǎn)一、軟件需求定義二、軟件需求管理過(guò)程需求的獲取需求分析編寫需求規(guī)格需求驗(yàn)證需求變更三、需求建模的基本方法四、案例分析31 chapter_需求規(guī)格需求分析工作完成的一個(gè)基本標(biāo)志是形成了一份完整的、規(guī)范的需求規(guī)格說(shuō)明書需求規(guī)格說(shuō)明書的編制是為了使用戶和軟件開發(fā)者雙方對(duì)該軟件的初始規(guī)定有一個(gè)共同的理解，使之成為整個(gè)開發(fā)工作的基礎(chǔ)。32 chapter_軟件需求規(guī)格說(shuō)明的原則從現(xiàn)實(shí)中分離功

12、能，即描述要“做什么”而不是“怎樣實(shí)現(xiàn)”要求使用面向處理的規(guī)格說(shuō)明語(yǔ)言（或稱系統(tǒng)定義語(yǔ)言）如果被開發(fā)軟件只是一個(gè)大系統(tǒng)中的一個(gè)元素，那么整個(gè)大系統(tǒng)也包括在規(guī)格說(shuō)明的描述之中33 chapter_規(guī)格說(shuō)明應(yīng)該包括系統(tǒng)運(yùn)行環(huán)境規(guī)格說(shuō)明應(yīng)該是一個(gè)認(rèn)識(shí)模型規(guī)格說(shuō)明應(yīng)該容許不完備性并允許擴(kuò)充34 chapter_3、規(guī)格文檔參考引言系統(tǒng)定義 應(yīng)用環(huán)境功能規(guī)格 性能需求產(chǎn)品提交實(shí)現(xiàn)約束質(zhì)量描述其它簽字認(rèn)證35 chapter_本章要點(diǎn)一、軟件需求定義二、軟件需求管理過(guò)程需求的獲取需求分析編寫需求規(guī)格需求驗(yàn)證需求變更三、需求建模的基本方法四、案例分析36 chapter_需求驗(yàn)證需求是正確的嗎？需求是一致的

13、嗎？需求是完全的嗎？需求是實(shí)際可行的嗎？需求是必要的嗎？需求是可檢驗(yàn)的嗎？需求是可跟蹤的嗎？最后的簽字37 chapter_本章要點(diǎn)一、軟件需求定義二、軟件需求管理過(guò)程需求的獲取需求分析編寫需求規(guī)格需求驗(yàn)證需求變更三、需求建模的基本方法四、案例分析38 chapter_需求總在變化39 chapter_40 chapter_需求變更管理確定需求變更控制過(guò)程建立變更控制委員會(huì)(SCCB)進(jìn)行需求變更影響分析跟蹤所有受需求變更影響的工作產(chǎn)品建立需求基準(zhǔn)版本和需求控制版本文檔維護(hù)需求變更的歷史記錄跟蹤每項(xiàng)需求的狀態(tài)衡量需求穩(wěn)定性41 chapter_需求變更管理管理和控制需求基線的過(guò)程需求變更控制系

14、統(tǒng)一個(gè)正式的文檔，說(shuō)明如何控制需求變更建立變更審批系統(tǒng)42 chapter_控制需求漸變的策略需求一定要與投入有顯然的聯(lián)系，在項(xiàng)目的開始雙方都要明確：需求變化，成本也要變化。需求的變化要經(jīng)過(guò)出資者的認(rèn)可。小的需求變更也要經(jīng)過(guò)正規(guī)的需求管理過(guò)程，否則積少成多。精確的需求和范圍的定義并不會(huì)阻止需求的變更。這是兩個(gè)層面的問(wèn)題。43 chapter_變更控制過(guò)程44 chapter_需求變更處理流程提出變更變更評(píng)估實(shí)施變更45 chapter_變更申請(qǐng)需求方開發(fā)方忽略選擇變更方式SCCB評(píng)估項(xiàng)目經(jīng)理自行決定根據(jù)評(píng)估結(jié)果拒絕接受本次修改下個(gè)版本再修改修改合同相關(guān)信息修改相關(guān)需求修改相應(yīng)的項(xiàng)目計(jì)劃46 c

15、hapter_表4-3 需求變更提交單軟件基線產(chǎn)品修改提交單申請(qǐng)人韓萬(wàn)江申請(qǐng)日期2002。1011項(xiàng)目名稱項(xiàng)目管理系統(tǒng)階段名稱系統(tǒng)設(shè)計(jì)文件名 稱RCR-PM-01.doc, RCR-PM-02.doc,變更簡(jiǎn)述如下修改內(nèi)容1）修改測(cè)試流程控制：將2個(gè)角色，3個(gè)渠道流，改為3個(gè)角色，4個(gè)渠道流，詳見RCR-PM-01.doc2）增加開發(fā)人員技能信息庫(kù)管理，詳見RCR-PM-02.doc驗(yàn)證意見同意RCR-PM-01.doc變更。RCR-PM-02.doc的變更可以推遲到下一個(gè)版本實(shí)施驗(yàn)證人楊炎泰驗(yàn)證日期20021011SCCB韓萬(wàn)江，姜岳尊，孫泉 填表人韓萬(wàn)江47 chapter_ 需求變更管理

16、原則 （1） 建立需求基線。需求基線是需求變更的依據(jù)。在開發(fā)過(guò)程中，需求確定并經(jīng)過(guò)評(píng)審后(用戶參與評(píng)審)，可以建立第一個(gè)需求基線。此后每次變更并經(jīng)過(guò)評(píng)審后，都要重新確定新的需求基線。 （2） 制訂簡(jiǎn)單、有效的變更控制流程，并形成文檔。在建立了需求基線后提出的所有變更都必須遵循這個(gè)控制流程進(jìn)行控制。同時(shí)，這個(gè)流程具有一定的普遍性，對(duì)以后的項(xiàng)目開發(fā)和其他項(xiàng)目都有借鑒作用。 （3） 成立項(xiàng)目變更控制委員會(huì)(CCB)或相關(guān)職能的類似組織，負(fù)責(zé)裁定接受哪些變更。CCB由項(xiàng)目所涉及的多方人員共同組成，應(yīng)該包括用戶方和開發(fā)方的決策人員在內(nèi)。 （4） 需求變更一定要先申請(qǐng)然后再評(píng)估，最后經(jīng)過(guò)與變更大小相當(dāng)級(jí)別

17、的評(píng)審確認(rèn)。 （5） 需求變更后，受影響的軟件計(jì)劃、產(chǎn)品、活動(dòng)都要進(jìn)行相應(yīng)的變更，以保持和更新的需求一致。 （6） 妥善保存變更產(chǎn)生的相關(guān)文檔。 48 chapter_需求變更應(yīng)對(duì)之道 相互協(xié)作很難想像遭到用戶抵制的項(xiàng)目能夠成功。在討論需求時(shí)，開發(fā)人員與用戶應(yīng)該盡量采取相互理解、相互協(xié)作的態(tài)度，對(duì)能解決的問(wèn)題盡量解決。即使用戶提出了在開發(fā)人員看來(lái)過(guò)分的要求，也應(yīng)該仔細(xì)分析原因，積極提出可行的替代方案。 充分交流需求變更管理的過(guò)程很大程度上就是用戶與開發(fā)人員的交流過(guò)程。軟件開發(fā)人員必須學(xué)會(huì)認(rèn)真聽取用戶的要求、考慮和設(shè)想，并加以分析和整理。同時(shí)，軟件開發(fā)人員應(yīng)該向用戶說(shuō)明，進(jìn)入設(shè)計(jì)階段以后，再提出

18、需求變更會(huì)給整個(gè)開發(fā)工作帶來(lái)什么樣的沖擊和不良后果。 安排專職人員負(fù)責(zé)需求變更管理有時(shí)開發(fā)任務(wù)較重，開發(fā)人員容易陷入開發(fā)工作中而忽略了與用戶的隨時(shí)溝通，因此需要一名專職的需求變更管理人員負(fù)責(zé)與用戶及時(shí)交流。 合同約束需求變更給軟件開發(fā)帶來(lái)的影響有目共睹，所以在與用戶簽訂合同時(shí)，可以增加一些相關(guān)條款，如限定用戶提出需求變更的時(shí)間，規(guī)定何種情況的變更可以接受、拒絕接受或部分接受，還可以規(guī)定發(fā)生需求變更時(shí)必須執(zhí)行變更控制流程。 區(qū)別對(duì)待隨著開發(fā)進(jìn)展，有些用戶會(huì)不斷提出一些在項(xiàng)目組看來(lái)確實(shí)無(wú)法實(shí)現(xiàn)或工作量比較大、49 chapter_需求變更應(yīng)對(duì)之道對(duì)項(xiàng)目進(jìn)度有重大影響的需求。遇到這種情況，開發(fā)人員可

19、以向用戶說(shuō)明，項(xiàng)目的啟動(dòng)是以最初的基本需求作為開發(fā)前提的，如果大量增加新的需求(雖然用戶認(rèn)為是細(xì)化需求，但實(shí)際上是增加了工作量的新需求)，會(huì)使項(xiàng)目不能按時(shí)完成。如果用戶堅(jiān)持實(shí)施新需求，可以建議用戶將新需求按重要和緊迫程度劃分檔次，作為需求變更評(píng)估的一項(xiàng)依據(jù)。同時(shí)，還要注意控制新需求提出的頻率。 選用適當(dāng)?shù)拈_發(fā)模型采用建立原型的開發(fā)模型比較適合需求不明確的開發(fā)項(xiàng)目。開發(fā)人員先根據(jù)用戶對(duì)需求的說(shuō)明建立一個(gè)系統(tǒng)原型，再與用戶溝通。一般用戶看到一些實(shí)際的東西后，對(duì)需求會(huì)有更為詳細(xì)的解釋，開發(fā)人員可根據(jù)用戶的說(shuō)明進(jìn)一步完善系統(tǒng)原型。這個(gè)過(guò)程重復(fù)幾次后，系統(tǒng)原型逐漸向最終的用戶需求靠攏，從根本上減少需求變

20、更的出現(xiàn)。目前業(yè)界較為流行的疊代式開發(fā)方法對(duì)工期緊迫的項(xiàng)目的需求變更控制很有成效。 用戶參與需求評(píng)審作為需求的提出者，用戶理所當(dāng)然是最具權(quán)威的發(fā)言人之一。實(shí)際上，在需求評(píng)審過(guò)程中，用戶往往能提出許多有價(jià)值的意見。同時(shí)，這也是由用戶對(duì)需求進(jìn)行最后確認(rèn)的機(jī)會(huì)，可以有效減少需求變更的發(fā)生。 50 chapter_本章要點(diǎn)一、軟件需求定義二、軟件需求管理過(guò)程三、需求建模的基本方法四、案例分析51 chapter_需求建模的基本方法原型方法結(jié)構(gòu)化分析法面向?qū)ο蟮挠美治龇üδ芰斜矸ㄆ渌?2 chapter_本章要點(diǎn)一、軟件需求定義二、軟件需求管理過(guò)程三、需求建模的基本方法原型方法結(jié)構(gòu)化分析法面向?qū)ο蟮挠?/p>

21、例分析法功能列表法其他四、案例分析53 chapter_原型方法按照用戶的需要，快速形成一個(gè)操作流程界面可能只是一個(gè)框架，具體的功能沒(méi)有實(shí)現(xiàn)，只是結(jié)果靜態(tài)的操作流程，以便與用戶快速就需求達(dá)成一致主要考慮系統(tǒng)的功能需求，很少考慮非功能需求54 chapter_原型方法需求分析原型開發(fā)原型評(píng)價(jià)55 chapter_原型方法的類型進(jìn)化型開發(fā)出來(lái)用于了解問(wèn)題，并形成被交付軟件的部分或全部的基礎(chǔ)拋棄型開發(fā)出來(lái)獲以便更多地了解問(wèn)題或探究可能的方案的靈活性或者合理性，是嘗試性軟件，不用于被交付軟件的實(shí)際部分56 chapter_原型實(shí)例原型系統(tǒng)57 chapter_本章要點(diǎn)一、軟件需求定義二、軟件需求管理過(guò)

22、程三、需求建模的基本方法原型方法結(jié)構(gòu)化分析法面向?qū)ο蟮挠美治龇üδ芰斜矸ㄆ渌摹咐治?8 chapter_結(jié)構(gòu)化分析方法（SA,Structured Analysis）20世紀(jì)70年發(fā)展起來(lái)的面向數(shù)據(jù)流的方法是一種自頂向下逐步求精的分析方法根據(jù)軟件內(nèi)部數(shù)據(jù)傳遞、變換的關(guān)系進(jìn)行分析的59 chapter_結(jié)構(gòu)化分析方法-技術(shù)數(shù)據(jù)流圖(DFD)數(shù)據(jù)字典(DD)系統(tǒng)流程圖60 chapter_描述銀行取款過(guò)程的數(shù)據(jù)流圖61 chapter_數(shù)據(jù)流圖的層次結(jié)構(gòu)為了表達(dá)數(shù)據(jù)處理過(guò)程的數(shù)據(jù)加工情況，需要采用層次結(jié)構(gòu)的數(shù)據(jù)流圖。按照系統(tǒng)的層次結(jié)構(gòu)進(jìn)行逐步分解，并以分層的數(shù)據(jù)流圖反映這種結(jié)構(gòu)關(guān)系，能清楚

23、地表達(dá)和容易理解整個(gè)系統(tǒng)62 chapter_分層數(shù)據(jù)流圖63 chapter_數(shù)據(jù)字典描述系統(tǒng)中涉及的每個(gè)數(shù)據(jù),是數(shù)據(jù)描述的集合,通常配合數(shù)據(jù)流圖使用,用來(lái)描述數(shù)據(jù)流圖中出現(xiàn)的各種數(shù)據(jù)和加工.64 chapter_數(shù)據(jù)字典-組成數(shù)據(jù)項(xiàng):數(shù)據(jù)元素?cái)?shù)據(jù)流:由數(shù)據(jù)項(xiàng)組成的數(shù)據(jù)流數(shù)據(jù)文件:表示對(duì)數(shù)據(jù)文件的存儲(chǔ)65 chapter_數(shù)據(jù)流圖需求分析實(shí)例建立學(xué)生管理系統(tǒng)學(xué)管科體檢科學(xué)籍科學(xué)生處66 chapter_數(shù)據(jù)流圖-頂層學(xué)管科體檢科學(xué)籍科學(xué)生管理信息系統(tǒng)學(xué)生處領(lǐng)導(dǎo)學(xué)生基本信息學(xué)生健康信息學(xué)生成績(jī)學(xué)生健康情況表學(xué)生成績(jī)單查詢要求不及格人數(shù)人數(shù)統(tǒng)計(jì)表67 chapter_數(shù)據(jù)流圖-0層68 chap

24、ter_數(shù)據(jù)流圖-1層69 chapter_數(shù)據(jù)流圖-1層70 chapter_數(shù)據(jù)字典-數(shù)據(jù)流 學(xué)生基本信息：學(xué)號(hào)十姓名 學(xué)生健康信息：學(xué)號(hào)十健康情況 學(xué)生成績(jī)：學(xué)號(hào)十課程名+成績(jī) 查詢要求：健康查詢單 |平均成績(jī)查詢單 l不及格人數(shù)查詢 學(xué)生健康情況表：優(yōu)十良十一般十差 學(xué)生成績(jī)單：學(xué)號(hào)十姓名十課程名+成績(jī)+總成績(jī) 不及格人數(shù)統(tǒng)計(jì)表：學(xué)號(hào)十成績(jī)十不及格總?cè)藬?shù)71 chapter_數(shù)據(jù)字典-數(shù)據(jù)文件文件名：基本信息組成：學(xué)號(hào)十姓名十入學(xué)成績(jī)十生源組織：按學(xué)號(hào)遞增順序排列文件名：健康文件組成：學(xué)號(hào)+姓名+健康情況組織：按照健康情況為優(yōu)、良、一般、差順序排列文件名：成績(jī)文件組成：學(xué)號(hào)+姓名+平均

25、成績(jī)組織：按照評(píng)劇成績(jī)遞增順序排列72 chapter_系統(tǒng)流程圖系統(tǒng)包含的部分以及各個(gè)部分之間的關(guān)系是描述物理系統(tǒng)的工具用圖形符號(hào)表示系統(tǒng)中的元素表達(dá)了系統(tǒng)中各個(gè)元素之間的信息流動(dòng)情況73 chapter_系統(tǒng)流程圖符號(hào)74 chapter_75 chapter_本章要點(diǎn)一、軟件需求定義二、軟件需求管理過(guò)程三、需求建模的基本方法原型方法結(jié)構(gòu)化分析法面向?qū)ο蟮挠美治龇üδ芰斜矸ㄆ渌?、案例分?6 chapter_面向?qū)ο蟮男枨蠓治鯫OSEOOAOODOOPOOT.77 chapter_OOA是OO軟件工程的第一項(xiàng)技術(shù)活動(dòng)將現(xiàn)實(shí)世界的“視圖”轉(zhuǎn)化為用對(duì)象來(lái)描述的模型描述對(duì)象之間的各種關(guān)系，以

26、滿足軟件系統(tǒng)的要求。78 chapter_用例需求（Use case）分析用例需求分析方法采用一種面向?qū)ο蟮那榫胺治龇椒ㄓ美窍到y(tǒng)向用戶提供一個(gè)有價(jià)值的結(jié)果的某項(xiàng)功能從用戶角度出發(fā)考慮的功能需求所有的用例結(jié)合起來(lái)就構(gòu)成了用例模型79 chapter_UML需求視圖用例視圖（Use case Diagram）順序圖（Sequence Diagram）狀態(tài)圖（State Diagram）活動(dòng)圖（Activity Diagram）80 chapter_81 chapter_82 chapter_83 chapter_84 chapter_用例視圖用例視圖主要是展示了外部行為者所觀察到的系統(tǒng)將提交的功

27、能.即:各類外部行為者與系統(tǒng)所提供的用例的連接85 chapter_用例視圖用例（Use case）：系統(tǒng)所提供的功能描述角色（Actor）：可能使用用例的人或者外部系統(tǒng)86 chapter_UML圖符87 chapter_通信關(guān)系：執(zhí)行者 與用例之間的連線來(lái)表示泛化關(guān)系：用例間的泛化關(guān)系意味著一個(gè)用例是另一個(gè)用例的特殊版本，特殊用例可在一般用例的執(zhí)行序列的任意位置插入額外的動(dòng)作序列，也可修改某些繼承來(lái)的操作和順序。在UML中用帶連線的三角形表示。包含關(guān)系：描述用例間的共同行為，當(dāng)兩個(gè)或多個(gè)用例有共同的執(zhí)行序列片斷時(shí)，可將這些序列片斷抽取，形成被包含用例。UML中用標(biāo)有 include的虛箭頭

28、線來(lái)表示。有點(diǎn)類似于程序間的調(diào)用關(guān)系。擴(kuò)展關(guān)系：當(dāng)對(duì)一個(gè)已存在的用例增加新的功能時(shí)，可使用擴(kuò)展關(guān)系，擴(kuò)展關(guān)系一般用于有條件地?cái)U(kuò)展已有用例的行為，是一種不改變?cè)加美那闆r下增加用例行為的一種方法。88 chapter_存款驗(yàn)證密碼支取管理取款維護(hù)通知透支轉(zhuǎn)帳includeincludeextend顧客銀行系統(tǒng)管理員89 chapter_用例實(shí)例90 chapter_用例實(shí)例91 chapter_順序圖示順序圖展示了幾個(gè)對(duì)象之間的動(dòng)態(tài)協(xié)作關(guān)系，主要用來(lái)顯示對(duì)象之間發(fā)送消息的順序，還顯示對(duì)象之間的交互，即系統(tǒng)執(zhí)行某一特定時(shí)間點(diǎn)所發(fā)生的事。 92 chapter_順序圖示93 chapter_狀態(tài)視

29、圖狀態(tài)圖是對(duì)類描述的補(bǔ)充，它說(shuō)明該類的對(duì)象所有可能的狀態(tài)以及那些事件將導(dǎo)致狀態(tài)的改變。它是一個(gè)類對(duì)象所可能經(jīng)歷的所有歷程的模型圖94 chapter_活動(dòng)視圖活動(dòng)圖用來(lái)描述執(zhí)行工作流程中涉及的活動(dòng)，展示了連續(xù)的活動(dòng)流95 chapter_活動(dòng)圖例96 chapter_Use Case需求分析方法綜述識(shí)別出系統(tǒng)的Actor描述主要的Use case實(shí)現(xiàn)用例視圖實(shí)現(xiàn)順序視圖，活動(dòng)視圖,狀態(tài)視圖等97 chapter_實(shí)例用Rational rose工具實(shí)現(xiàn)的需求規(guī)格文檔貿(mào)易鏈需求的需求實(shí)例98 chapter_99 chapter_100 chapter_101 chapter_102 chapt

30、er_103 chapter_104 chapter_105 chapter_106 chapter_107 chapter_108 chapter_本章要點(diǎn)一、軟件需求定義二、軟件需求管理過(guò)程三、需求建模的基本方法原型方法結(jié)構(gòu)化分析法面向?qū)ο蟮挠美治龇üδ芰斜矸ㄆ渌?、案例分?09 chapter_功能列表需求類別（功能/性能）名稱/標(biāo)識(shí)描述特性（Feature） AA.1A.n特性Feature BB.1B.n特性Feature CC.1C.n110 chapter_功能列表實(shí)例（某網(wǎng)站功能列表)111 chapter_本章要點(diǎn)一、軟件需求定義二、軟件需求管理過(guò)程三、需求建模的基本方法

31、四、案例分析112 chapter_案例分析“School”項(xiàng)目的需求管理過(guò)程：需求確認(rèn)：原型法需求變更：變更控制系統(tǒng)變更過(guò)程113 chapter_Infosys公司常用的變更管理過(guò)程（1）記錄變更。（2）分析變更對(duì)工作產(chǎn)品的影響。（3）估計(jì)變更申請(qǐng)所需的工作量。（4）重新估計(jì)交付時(shí)間表。（5）執(zhí)行累積的成本影響分析。（6）如果影響超出一定限度，則與高級(jí)主管一起評(píng)審影響。（7）客戶不再提出變更申請(qǐng)。（8）修改工作產(chǎn)品。114 chapter_變更申請(qǐng)日記護(hù)一個(gè)變更申請(qǐng)日記，以跟蹤變更申請(qǐng)。日志中的每條記錄包含一個(gè)變更申請(qǐng)?zhí)?、關(guān)于變更的簡(jiǎn)單描述、變更的影響、變更申請(qǐng)的狀態(tài)以及關(guān)鍵日期。在評(píng)估變

32、更申請(qǐng)的影響時(shí)，必須執(zhí)行影響分析。影響分析涉及標(biāo)識(shí)出需要進(jìn)行變更的工作產(chǎn)品，并估算對(duì)每種產(chǎn)品的變更量；通過(guò)重新查看風(fēng)險(xiǎn)管理計(jì)劃，重新評(píng)估項(xiàng)目風(fēng)險(xiǎn)；評(píng)估需求變更蘊(yùn)涵的總的工作量和進(jìn)度估計(jì)的變化。 客戶對(duì)分析結(jié)果進(jìn)行評(píng)審，并做出答復(fù)。變更申請(qǐng)一般作為需求規(guī)格說(shuō)明文檔的附件。有時(shí)還要修改文檔的有關(guān)部分以反映所做的變更。監(jiān)督已認(rèn)可的變更申請(qǐng)并保證它們正確實(shí)現(xiàn)，這部分由配置管理過(guò)程處理。115 chapter_變更的累積影響 需求變更的一種危險(xiǎn)是：盡管每種變更本身并不大，但是生命期中所有變更的累積影響卻是很大的。因此，除了研究每個(gè)變更的影響并對(duì)它們進(jìn)行跟蹤外，還必須監(jiān)督變更的累積影響。116 chapter_Infosys公司的項(xiàng)目經(jīng)理有時(shí)為處理變更申請(qǐng)預(yù)留一定的余地