軟件項(xiàng)目管理第第4章軟件需求

1、承上啟下0情景引入：計(jì)劃1How long?How much?How good?項(xiàng)目計(jì)劃2沒有計(jì)劃的情況3時(shí)間資源投入開發(fā)工作計(jì)劃性工作協(xié)調(diào)性工作有計(jì)劃的情況4時(shí)間資源投入開發(fā)工作計(jì)劃性工作協(xié)調(diào)性工作明確做什么？ chapter_45范圍計(jì)劃6軟件項(xiàng)目管理 第二篇7第第 4 4 章章軟件項(xiàng)目需求管理軟件項(xiàng)目需求管理需求管理中的問題舉例8需求的隱含錯(cuò)誤需求管理中的問題舉例chapter_49用戶不斷增加需求、變更需求項(xiàng)目失敗的原因分析10No. Top 10 Factors 平均值平均值 1 Inadequate requirements specification 不充分的需求規(guī)范不充分的需求

2、規(guī)范 4.5 2 Changes in requirements 需求的改變需求的改變 4.3 3 Shortage of systems engineers 缺乏系統(tǒng)工程師缺乏系統(tǒng)工程師 4.2 4 Shortage of software managers 缺乏了解軟件特性的經(jīng)理人缺乏了解軟件特性的經(jīng)理人 4.1 5 Shortage of qualified project managers 缺乏合格的缺乏合格的項(xiàng)目經(jīng)理項(xiàng)目經(jīng)理 4.1 6 Shortage of software engineers 缺乏軟件工程師缺乏軟件工程師 3.9 7 Fixed - price contract

3、 固定價(jià)合同固定價(jià)合同 3.8 8 Inadequate communications for system integration 系統(tǒng)集成階段系統(tǒng)集成階段, 交流與溝通不充分交流與溝通不充分 3.8 9 Insufficient experience as team團(tuán)隊(duì)缺乏經(jīng)團(tuán)隊(duì)缺乏經(jīng)驗(yàn)驗(yàn) 3.6 10 Shortage of application domain experts 缺乏應(yīng)用領(lǐng)域?qū)＜胰狈?yīng)用領(lǐng)域?qū)＜?3.6 Scale: 5 = Very Serious 3 = Serious 1 = No Serious Source: Carnegie-Mellon University

4、, Software Engineering Institute本章要點(diǎn)11軟件需求定義軟件需求管理過(guò)程需求建模的基本方法案例分析 課程實(shí)踐軟件需求定義 chapter_212需求是指用戶對(duì)軟件的功能和性能的要求。本章要點(diǎn)13軟件需求定義軟件需求管理過(guò)程需求建模的基本方法案例分析 課程實(shí)踐軟件需求管理的過(guò)程 chapter_414需求分析需求分析需求規(guī)格編寫需求規(guī)格編寫需求驗(yàn)證需求驗(yàn)證需求獲取需求獲取需求變更需求變更需求確認(rèn)需求變更1、需求獲取 chapter_215需求獲取的方法 chapter_416用戶要求軟件需求獲取需求n 訪談和調(diào)研訪談和調(diào)研l(wèi)和用戶進(jìn)行訪談和調(diào)研通常是適用于任何環(huán)境

5、下的最重要和用戶進(jìn)行訪談和調(diào)研通常是適用于任何環(huán)境下的最重要最直接的方法之一。最直接的方法之一。l訪談的一個(gè)主要目標(biāo)是確保訪談?wù)叩钠娀蛑饔^意識(shí)不會(huì)訪談的一個(gè)主要目標(biāo)是確保訪談?wù)叩钠娀蛑饔^意識(shí)不會(huì)干擾自由的交流。干擾自由的交流。通過(guò)幾次這樣的訪談，開發(fā)人員和系統(tǒng)分析員能獲得一些問通過(guò)幾次這樣的訪談，開發(fā)人員和系統(tǒng)分析員能獲得一些問題域中的知識(shí)，對(duì)要解決的問題有進(jìn)一步的理解。題域中的知識(shí)，對(duì)要解決的問題有進(jìn)一步的理解。需求獲取方法n 專題討論會(huì)專題討論會(huì)l專題討論會(huì)是一種可用于任何情況下的軟件需求調(diào)研方法。專題討論會(huì)是一種可用于任何情況下的軟件需求調(diào)研方法。l專題討論會(huì)的目的是鼓勵(lì)軟件需求調(diào)研

6、并且在很短的時(shí)間內(nèi)專題討論會(huì)的目的是鼓勵(lì)軟件需求調(diào)研并且在很短的時(shí)間內(nèi) 對(duì)討論的問題達(dá)成一致。對(duì)討論的問題達(dá)成一致。l專題討論會(huì)一般由開發(fā)團(tuán)隊(duì)的成員主持，主要討論系統(tǒng)應(yīng)具專題討論會(huì)一般由開發(fā)團(tuán)隊(duì)的成員主持，主要討論系統(tǒng)應(yīng)具備的特征或者評(píng)審系統(tǒng)特性。備的特征或者評(píng)審系統(tǒng)特性。l專題討論會(huì)前的準(zhǔn)備工作是能否成功的舉行會(huì)議的關(guān)鍵。專題討論會(huì)前的準(zhǔn)備工作是能否成功的舉行會(huì)議的關(guān)鍵。需求獲取方法n 腦力風(fēng)暴腦力風(fēng)暴l 腦力風(fēng)暴是一種對(duì)于獲取新觀點(diǎn)或創(chuàng)造性的解決方案而言非腦力風(fēng)暴是一種對(duì)于獲取新觀點(diǎn)或創(chuàng)造性的解決方案而言非常有用的方法。常有用的方法。l 通常，專題討論會(huì)的一部分時(shí)間是用于進(jìn)行腦力風(fēng)暴，找出

7、通常，專題討論會(huì)的一部分時(shí)間是用于進(jìn)行腦力風(fēng)暴，找出關(guān)于軟件系統(tǒng)的新想法和新特征。關(guān)于軟件系統(tǒng)的新想法和新特征。l 腦力風(fēng)暴包括兩個(gè)階段：想法產(chǎn)生階段和想法精化階段。腦力風(fēng)暴包括兩個(gè)階段：想法產(chǎn)生階段和想法精化階段。應(yīng)用程序腦力風(fēng)暴中確定的特征系統(tǒng)特征定義家用自動(dòng)照明系統(tǒng)自動(dòng)照明設(shè)置用戶可以制定每天自動(dòng)照明的時(shí)間計(jì)劃，系統(tǒng)將按時(shí)間計(jì)劃觸發(fā)照明事件任務(wù)管理系統(tǒng)代理任務(wù)通知當(dāng)用戶將自己的任務(wù)代理給其他人時(shí)，系統(tǒng)自動(dòng)發(fā)送Email通知將接手該任務(wù)的人腦力風(fēng)暴中為確定的問題定義系統(tǒng)特征腦力風(fēng)暴中為確定的問題定義系統(tǒng)特征需求獲取方法n 場(chǎng)景串聯(lián)場(chǎng)景串聯(lián)l 場(chǎng)景串聯(lián)的目的是為了盡早的從用戶那里得到用戶對(duì)建

8、議的場(chǎng)景串聯(lián)的目的是為了盡早的從用戶那里得到用戶對(duì)建議的系統(tǒng)功能的意見。系統(tǒng)功能的意見。l 場(chǎng)景串聯(lián)提供了用戶界面以說(shuō)明系統(tǒng)操作流程，它容易創(chuàng)建場(chǎng)景串聯(lián)提供了用戶界面以說(shuō)明系統(tǒng)操作流程，它容易創(chuàng)建和修改，能讓用戶知道系統(tǒng)的操作方式和流程。和修改，能讓用戶知道系統(tǒng)的操作方式和流程。l 根據(jù)與用戶交互的方式，場(chǎng)景串聯(lián)被分成三種模式：靜態(tài)的根據(jù)與用戶交互的方式，場(chǎng)景串聯(lián)被分成三種模式：靜態(tài)的場(chǎng)景串聯(lián)、動(dòng)態(tài)的場(chǎng)景串聯(lián)以及交互的場(chǎng)景串聯(lián)。場(chǎng)景串聯(lián)、動(dòng)態(tài)的場(chǎng)景串聯(lián)以及交互的場(chǎng)景串聯(lián)。l 選擇提供哪種場(chǎng)景串聯(lián)是根據(jù)系統(tǒng)的復(fù)雜性和需求缺陷的風(fēng)選擇提供哪種場(chǎng)景串聯(lián)是根據(jù)系統(tǒng)的復(fù)雜性和需求缺陷的風(fēng)險(xiǎn)來(lái)確定的。險(xiǎn)來(lái)

9、確定的。需求獲取方法進(jìn)行需求獲取應(yīng)注意的問題n識(shí)別真正的客戶識(shí)別真正的客戶n正確理解客戶的需求正確理解客戶的需求n具備較強(qiáng)的忍耐力和清晰的思維具備較強(qiáng)的忍耐力和清晰的思維n說(shuō)明和教育客戶說(shuō)明和教育客戶2、需求分析 chapter_423需求分析是為最終用戶所看到的系統(tǒng)建立一個(gè)概念模型，是對(duì)需求的抽象描述。 chapter_424需求分析模型3、需求規(guī)格編寫 chapter_425需求分析工作完成的一個(gè)基本標(biāo)志是形成了一份完整的、規(guī)范的需求規(guī)格說(shuō)明書需求規(guī)格文檔參考 chapter_226引言系統(tǒng)定義 應(yīng)用環(huán)境功能規(guī)格 性能需求產(chǎn)品提交實(shí)現(xiàn)約束質(zhì)量描述其它簽字認(rèn)證4、需求驗(yàn)證 chapter_4

10、27需求是正確的嗎？需求是一致的嗎？需求是完全的嗎？需求是實(shí)際可行的嗎？需求是必要的嗎？需求是可檢驗(yàn)的嗎？需求是可跟蹤的嗎？最后的簽字5、需求總在變化 chapter_428需求變更管理 chapter_429確定需求變更控制過(guò)程確定需求變更控制過(guò)程建立變更控制委員會(huì)建立變更控制委員會(huì)( (SCCB)SCCB)進(jìn)行需求變更影響分析進(jìn)行需求變更影響分析跟蹤所有受需求變更影響的工作產(chǎn)品跟蹤所有受需求變更影響的工作產(chǎn)品建立需求基準(zhǔn)版本和需求控制版本文檔建立需求基準(zhǔn)版本和需求控制版本文檔維護(hù)需求變更的歷史記錄維護(hù)需求變更的歷史記錄跟蹤每項(xiàng)需求的狀態(tài)跟蹤每項(xiàng)需求的狀態(tài)衡量需求穩(wěn)定性衡量需求穩(wěn)定性表4-3

11、 需求變更提交單軟件基線產(chǎn)品修改提交單軟件基線產(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 1）修改測(cè)試流程控制：將）修改測(cè)試流程控制：將2 2個(gè)角色，個(gè)角色，3 3個(gè)渠道流，改為個(gè)渠道流，改為3 3個(gè)角色，個(gè)角色，4 4個(gè)渠道流，詳見個(gè)渠道流，詳見RCR-PM-01.doc2 2）增加開發(fā)人員技能信息庫(kù)管理，詳見）增加開發(fā)人員技能信息庫(kù)管理，詳見RCR-PM-02.doc驗(yàn)證意見同意RCR-PM-01.doc變更。RCR-PM-02.doc的變更可以推遲到下一個(gè)

12、版本實(shí)施驗(yàn)證人楊炎泰驗(yàn)證日期20021011SCCB韓萬(wàn)江，姜岳尊，孫泉 填表人韓萬(wàn)江控制需求漸變的策略需求一定要與投入有顯然的聯(lián)系，在項(xiàng)目的開始雙方都要明確：需求變化，成本也要變化。需求的變化要經(jīng)過(guò)出資者的認(rèn)可。小的需求變更也要經(jīng)過(guò)正規(guī)的需求管理過(guò)程，否則積少成多。精確的需求和范圍的定義并不會(huì)阻止需求的變更。這是兩個(gè)層面的問題。變更控制過(guò)程需求變更處理流程提出變更變更評(píng)估實(shí)施變更 需求變更管理原則 （1） 建立需求基線。需求基線是需求變更的依據(jù)。在開發(fā)過(guò)程中，需求確定并經(jīng)過(guò)評(píng)審后(用戶參與評(píng)審)，可以建立第一個(gè)需求基線。此后每次變更并經(jīng)過(guò)評(píng)審后，都要重新確定新的需求基線。 （2） 制訂簡(jiǎn)單、

13、有效的變更控制流程，并形成文檔。在建立了需求基線后提出的所有變更都必須遵循這個(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í)別的評(píng)審確認(rèn)。 （5） 需求變更后，受影響的軟件計(jì)劃、產(chǎn)品、活動(dòng)都要進(jìn)行相應(yīng)的變更，以保持和更新的需求一致。 （6） 妥善保存變更產(chǎn)生的相關(guān)文檔。 需求變更應(yīng)對(duì)之道 相互協(xié)作相互協(xié)作很難想像遭到用戶抵制的

14、項(xiàng)目能夠成功。在討論需求時(shí)，開發(fā)人員與用戶應(yīng)該盡量采取相互理解、相互協(xié)作的態(tài)度，對(duì)能解決的問題盡量解決。即使用戶提出了在開發(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ì)階段以后，再提出需求變更會(huì)給整個(gè)開發(fā)工作帶來(lái)什么樣的沖擊和不良后果。 安排專職人員負(fù)責(zé)需求變更管理安排專職人員負(fù)責(zé)需求變更管理有時(shí)開發(fā)任務(wù)較重，開發(fā)人員容易陷入開發(fā)工作中而忽略了與用戶的隨時(shí)溝通，因此需要一名專職的需求變更管

15、理人員負(fù)責(zé)與用戶及時(shí)交流。 合同約束合同約束需求變更給軟件開發(fā)帶來(lái)的影響有目共睹，所以在與用戶簽訂合同時(shí)，可以增加一些相關(guān)條款，如限定用戶提出需求變更的時(shí)間，規(guī)定何種情況的變更可以接受、拒絕接受或部分接受，還可以規(guī)定發(fā)生需求變更時(shí)必須執(zhí)行變更控制流程。 需求變更應(yīng)對(duì)之道 需求變更應(yīng)對(duì)之道 區(qū)別對(duì)待區(qū)別對(duì)待隨著開發(fā)進(jìn)展，有些用戶會(huì)不斷提出一些在項(xiàng)目組看來(lái)確實(shí)無(wú)法實(shí)現(xiàn)或工作量比較大，對(duì)項(xiàng)目進(jìn)度有重大影響的需求。遇到這種情況，開發(fā)人員可以向用戶說(shuō)明，項(xiàng)目的啟動(dòng)是以最初的基本需求作為開發(fā)前提的，如果大量增加新的需求(雖然用戶認(rèn)為是細(xì)化需求，但實(shí)際上是增加了工作量的新需求)，會(huì)使項(xiàng)目不能按時(shí)完成。如果用

16、戶堅(jiān)持實(shí)施新需求，可以建議用戶將新需求按重要和緊迫程度劃分檔次，作為需求變更評(píng)估的一項(xiàng)依據(jù)。同時(shí)，還要注意控制新需求提出的頻率。 選用適當(dāng)?shù)拈_發(fā)模型選用適當(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)原型逐漸向最終的用戶需求靠攏，從根本上減少需求變更的出現(xiàn)。目前業(yè)界較為流行的疊代式開發(fā)方法對(duì)工期緊迫的項(xiàng)目的需求變更控制很有成效。 需求變更應(yīng)對(duì)之道用戶參與需求評(píng)審用戶參與需求評(píng)審作為需求的提出者

17、，用戶理所當(dāng)然是最具權(quán)威的發(fā)言人之一。實(shí)際上，在需求評(píng)審過(guò)程中，用戶往往能提出許多有價(jià)值的意見。同時(shí)，這也是由用戶對(duì)需求進(jìn)行最后確認(rèn)的機(jī)會(huì)，可以有效減少需求變更的發(fā)生。 需求變更應(yīng)對(duì)之道案例分析“School”項(xiàng)目的需求管理過(guò)程：q需求確認(rèn)：原型法q需求變更：q變更控制系統(tǒng)q變更過(guò)程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)品。變更申請(qǐng)日記護(hù)一個(gè)變更申請(qǐng)日記，以跟蹤變更

18、申請(qǐng)。日志中的每條記錄包含一個(gè)變更申請(qǐng)?zhí)?、關(guān)于變更的簡(jiǎn)單描述、變更的影響、變更申請(qǐng)的狀態(tài)以及關(guān)鍵日期。在評(píng)估變更申請(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)審評(píng)審，并做出答復(fù)答復(fù)。變更申請(qǐng)一般作為需求規(guī)格說(shuō)明文檔的附件變更申請(qǐng)一般作為需求規(guī)格說(shuō)明文檔的附件。有時(shí)還要修改文檔的有關(guān)部分以反映所做的變更。監(jiān)督已認(rèn)可的變更申請(qǐng)并保證它們正確實(shí)現(xiàn)，這部分由配置管理過(guò)程處理。變更的累積影響 需求變更的一種危險(xiǎn)是：盡管每種變需求變更的一種危

19、險(xiǎn)是：盡管每種變更本身并不大，但是生命期中所有變更本身并不大，但是生命期中所有變更的累積影響卻是很大的。因此，除更的累積影響卻是很大的。因此，除了研究每個(gè)變更的影響并對(duì)它們進(jìn)行了研究每個(gè)變更的影響并對(duì)它們進(jìn)行跟蹤外，還必須監(jiān)督變更的累積影響。跟蹤外，還必須監(jiān)督變更的累積影響。Infosys公司的項(xiàng)目經(jīng)理有時(shí)為處理變更申請(qǐng)預(yù)留一定的余地。 只要所有變更累積的工作量不超過(guò)這一預(yù)留的工作量，就不需要做任何特殊的處理。 然而，如果所有變更的累積工作量超過(guò)了這一預(yù)留的工作量，則再進(jìn)行變更可能會(huì)對(duì)總成本和進(jìn)度安排產(chǎn)生負(fù)面影響。在這種情況中，項(xiàng)目經(jīng)理必須修改估計(jì)并使它們得到承認(rèn)。課堂討論面對(duì)客戶的需求變更，

20、接受還是拒絕？ 在某公司的項(xiàng)目管理課堂上，小李，小王等人正在七嘴八舌地議論紛紛。原來(lái)，大家正在討論小王的公司最近遇到的兩個(gè)頗為有趣的項(xiàng)目。據(jù)小王介紹，這兩個(gè)項(xiàng)目分別由兩個(gè)項(xiàng)目經(jīng)理來(lái)?yè)?dān)任。其中，項(xiàng)目經(jīng)理A屬于“謙虛”型，對(duì)于客戶提出的問題，無(wú)論大小都給與解決，客戶對(duì)此非常滿意，然而，項(xiàng)目進(jìn)度卻拖得比較長(zhǎng)，而且，客戶總想把所有的問題都改完再說(shuō)，項(xiàng)目已經(jīng)一再延期。相比之下，項(xiàng)目經(jīng)理B顯得稍有些“盛氣凌人”，對(duì)于客戶提出的問題，大多都不予理睬，客戶對(duì)此不是很滿意，不過(guò)，該項(xiàng)目的進(jìn)度控制得比較好，基本能夠按期完成項(xiàng)目。話剛一說(shuō)完，小李就搶著說(shuō)：“A比較像我，一般在和我的一些戰(zhàn)略客戶打交道的時(shí)候，我基本是

21、有求必應(yīng)，與客戶的關(guān)系處得如魚得水，這樣做肯定不會(huì)錯(cuò)。就像前天我連合同都寫錯(cuò)了，找到客戶，人家二話沒說(shuō)就同意改了。你說(shuō)如果是B的話可能嗎？”小王對(duì)此不以為然，“對(duì)項(xiàng)目經(jīng)理來(lái)說(shuō)，成本、質(zhì)量和時(shí)間是最為重要的三要素。與客戶的關(guān)系當(dāng)然很重要，但也要全盤考慮項(xiàng)目的各要素。對(duì)于用戶的要求，應(yīng)該在有限的范圍內(nèi)給與解決，但不可以做出太大的犧牲。一味的遷就用戶將會(huì)使整個(gè)項(xiàng)目失敗?！毙×纸又⊥醯脑捳f(shuō)：“當(dāng)前，國(guó)內(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)理可以在此過(guò)程中堅(jiān)持一下原則，與公司的公關(guān)部一個(gè)

22、紅臉，一個(gè)白臉，唱出一出好戲?！毙≮w反駁道：“不管怎樣，客戶才是第一位的?？蛻艨梢越o你帶來(lái)收入，也可以給你帶來(lái)更多的客戶和工作，有什么道理不多配合一下他們呢？說(shuō)實(shí)話我對(duì)B的做法蠻欣賞的，可惜行不通。因?yàn)榭蛻羰巧系?，如果照B的做法，后果會(huì)造成做一次項(xiàng)目丟掉一個(gè)客戶，太不劃算了?！?問題：1、如果你的項(xiàng)目遇到需求變更問題，你會(huì)采用哪種方式去應(yīng)對(duì)？ 2、分析這兩種應(yīng)對(duì)需求變更方式的優(yōu)缺點(diǎn)。分析結(jié)果需求變更控制流程48變更申請(qǐng)忽略選擇變更方式SCCB評(píng)估項(xiàng)目經(jīng)理自行決定根據(jù)評(píng)估結(jié)果拒絕接受本次修改下個(gè)版本再修改修改合同相關(guān)信息修改相關(guān)需求修改相應(yīng)的項(xiàng)目計(jì)劃本章要點(diǎn)49軟件需求定義軟件需求管理過(guò)程需求建

23、模的基本方法案例分析 課程實(shí)踐需求建模的基本方法介紹 chapter_450原型方法結(jié)構(gòu)化分析法面向?qū)ο蟮挠美治龇üδ芰斜矸?chapter_251需求建模的基本方法介紹 chapter_452原型方法結(jié)構(gòu)化分析法面向?qū)ο蟮挠美治龇üδ芰斜矸?、原型方法chapter_453需求分析原型開發(fā)原型評(píng)價(jià)原型實(shí)例54需求建模的基本方法介紹 chapter_455原型方法結(jié)構(gòu)化分析法面向?qū)ο蟮挠美治龇üδ芰斜矸?、結(jié)構(gòu)化分析方法5620世紀(jì)70年發(fā)展起來(lái)的面向數(shù)據(jù)流的方法是一種自頂向下逐步求精的分析方法根據(jù)軟件內(nèi)部數(shù)據(jù)傳遞、變換的關(guān)系進(jìn)行分析的 chapter_4結(jié)構(gòu)化分析方法-技術(shù) chapt

24、er_457數(shù)據(jù)流圖(DFD)數(shù)據(jù)字典(DD)系統(tǒng)流程圖 chapter_458學(xué)生管理系統(tǒng)-數(shù)據(jù)流圖-頂層 chapter_459學(xué)管科學(xué)管科體檢科體檢科學(xué)籍科學(xué)籍科學(xué)生管理信息系統(tǒng)學(xué)生處領(lǐng)導(dǎo)學(xué)生基本信息學(xué)生健康信息學(xué)生成績(jī)學(xué)生健康情況表學(xué)生成績(jī)單查詢要求不及格人數(shù)人數(shù)統(tǒng)計(jì)表學(xué)生管理系統(tǒng)-數(shù)據(jù)流圖-0層 chapter_260學(xué)生管理系統(tǒng)-數(shù)據(jù)流圖-1層 chapter_261學(xué)生管理系統(tǒng)-數(shù)據(jù)流圖-1層 chapter_262學(xué)生管理系統(tǒng)-數(shù)據(jù)字典-數(shù)據(jù)流 chapter_463 學(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ù)需求建模的基本方法介紹 chapter_464原型方法結(jié)構(gòu)化分析法面向?qū)ο蟮挠美治龇üδ芰斜矸?、面向?qū)ο蟮挠美治?chapter_465基于面向?qū)ο蟮那榫胺治龇椒◤挠脩艚嵌瘸霭l(fā)考慮的功能需求用例是系統(tǒng)向用戶提供一個(gè)有價(jià)值的結(jié)果的某項(xiàng)功能UML需求視圖chapter_466用例視圖（Use case Diagram）順序圖（Sequence Diagram）狀態(tài)圖（State Diagram）活動(dòng)圖（Activity Diagr