軟件項目管理第第4章軟件需求

1、承上啟下0情景引入：計劃1How long?How much?How good?項目計劃2沒有計劃的情況3時間資源投入開發(fā)工作計劃性工作協(xié)調(diào)性工作有計劃的情況4時間資源投入開發(fā)工作計劃性工作協(xié)調(diào)性工作明確做什么？ chapter_45范圍計劃6軟件項目管理 第二篇7第第 4 4 章章軟件項目需求管理軟件項目需求管理需求管理中的問題舉例8需求的隱含錯誤需求管理中的問題舉例chapter_49用戶不斷增加需求、變更需求項目失敗的原因分析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 缺乏合格的缺乏合格的項目經(jīng)理項目經(jīng)理 4.1 6 Shortage of software engineers 缺乏軟件工程師缺乏軟件工程師 3.9 7 Fixed - price contract

3、 固定價合同固定價合同 3.8 8 Inadequate communications for system integration 系統(tǒng)集成階段系統(tǒng)集成階段, 交流與溝通不充分交流與溝通不充分 3.8 9 Insufficient experience as team團隊缺乏經(jīng)團隊缺乏經(jīng)驗驗 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本章要點11軟件需求定義軟件需求管理過程需求建模的基本方法案例分析 課程實踐軟件需求定義 chapter_212需求是指用戶對軟件的功能和性能的要求。本章要點13軟件需求定義軟件需求管理過程需求建模的基本方法案例分析 課程實踐軟件需求管理的過程 chapter_414需求分析需求分析需求規(guī)格編寫需求規(guī)格編寫需求驗證需求驗證需求獲取需求獲取需求變更需求變更需求確認需求變更1、需求獲取 chapter_215需求獲取的方法 chapter_416用戶要求軟件需求獲取需求n 訪談和調(diào)研訪談和調(diào)研l(wèi)和用戶進行訪談和調(diào)研通常是適用于任何環(huán)境

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

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

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

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

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

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

11、 需求變更提交單軟件基線產(chǎn)品修改提交單軟件基線產(chǎn)品修改提交單申請人韓萬江申請日期2002。1011項目名稱項目管理系統(tǒng)階段名稱系統(tǒng)設(shè)計文件名稱RCR-PM-01.doc, RCR-PM-02.doc,變更簡述如下修改內(nèi)容1 1）修改測試流程控制：將）修改測試流程控制：將2 2個角色，個角色，3 3個渠道流，改為個渠道流，改為3 3個角色，個角色，4 4個渠道流，詳見個渠道流，詳見RCR-PM-01.doc2 2）增加開發(fā)人員技能信息庫管理，詳見）增加開發(fā)人員技能信息庫管理，詳見RCR-PM-02.doc驗證意見同意RCR-PM-01.doc變更。RCR-PM-02.doc的變更可以推遲到下一個

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

13、有效的變更控制流程，并形成文檔。在建立了需求基線后提出的所有變更都必須遵循這個控制流程進行控制。同時，這個流程具有一定的普遍性，對以后的項目開發(fā)和其他項目都有借鑒作用。 （3） 成立項目變更控制委員會(CCB)或相關(guān)職能的類似組織，負責(zé)裁定接受哪些變更。CCB由項目所涉及的多方人員共同組成，應(yīng)該包括用戶方和開發(fā)方的決策人員在內(nèi)。 （4） 需求變更一定要先申請然后再評估，最后經(jīng)過與變更大小相當(dāng)級別的評審確認。 （5） 需求變更后，受影響的軟件計劃、產(chǎn)品、活動都要進行相應(yīng)的變更，以保持和更新的需求一致。 （6） 妥善保存變更產(chǎn)生的相關(guān)文檔。 需求變更應(yīng)對之道 相互協(xié)作相互協(xié)作很難想像遭到用戶抵制的

14、項目能夠成功。在討論需求時，開發(fā)人員與用戶應(yīng)該盡量采取相互理解、相互協(xié)作的態(tài)度，對能解決的問題盡量解決。即使用戶提出了在開發(fā)人員看來過分的要求，也應(yīng)該仔細分析原因，積極提出可行的替代方案。 充分交流充分交流需求變更管理的過程很大程度上就是用戶與開發(fā)人員的交流過程。軟件開發(fā)人員必須學(xué)會認真聽取用戶的要求、考慮和設(shè)想，并加以分析和整理。同時，軟件開發(fā)人員應(yīng)該向用戶說明，進入設(shè)計階段以后，再提出需求變更會給整個開發(fā)工作帶來什么樣的沖擊和不良后果。 安排專職人員負責(zé)需求變更管理安排專職人員負責(zé)需求變更管理有時開發(fā)任務(wù)較重，開發(fā)人員容易陷入開發(fā)工作中而忽略了與用戶的隨時溝通，因此需要一名專職的需求變更管

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

16、戶堅持實施新需求，可以建議用戶將新需求按重要和緊迫程度劃分檔次，作為需求變更評估的一項依據(jù)。同時，還要注意控制新需求提出的頻率。 選用適當(dāng)?shù)拈_發(fā)模型選用適當(dāng)?shù)拈_發(fā)模型采用建立原型的開發(fā)模型比較適合需求不明確的開發(fā)項目。開發(fā)人員先根據(jù)用戶對需求的說明建立一個系統(tǒng)原型，再與用戶溝通。一般用戶看到一些實際的東西后，對需求會有更為詳細的解釋，開發(fā)人員可根據(jù)用戶的說明進一步完善系統(tǒng)原型。這個過程重復(fù)幾次后，系統(tǒng)原型逐漸向最終的用戶需求靠攏，從根本上減少需求變更的出現(xiàn)。目前業(yè)界較為流行的疊代式開發(fā)方法對工期緊迫的項目的需求變更控制很有成效。 需求變更應(yīng)對之道用戶參與需求評審用戶參與需求評審作為需求的提出者

17、，用戶理所當(dāng)然是最具權(quán)威的發(fā)言人之一。實際上，在需求評審過程中，用戶往往能提出許多有價值的意見。同時，這也是由用戶對需求進行最后確認的機會，可以有效減少需求變更的發(fā)生。 需求變更應(yīng)對之道案例分析“School”項目的需求管理過程：q需求確認：原型法q需求變更：q變更控制系統(tǒng)q變更過程Infosys公司常用的變更管理過程（1）記錄變更。（2）分析變更對工作產(chǎn)品的影響。（3）估計變更申請所需的工作量。（4）重新估計交付時間表。（5）執(zhí)行累積的成本影響分析。（6）如果影響超出一定限度，則與高級主管一起評審影響。（7）客戶不再提出變更申請。（8）修改工作產(chǎn)品。變更申請日記護一個變更申請日記，以跟蹤變更

18、申請。日志中的每條記錄包含一個變更申請?zhí)?、關(guān)于變更的簡單描述、變更的影響、變更申請的狀態(tài)以及關(guān)鍵日期。在評估變更申請的影響時，必須執(zhí)行影響分析。影響分析涉及標(biāo)識出需要進行變更的工作產(chǎn)品，并估算對每種產(chǎn)品的變更量；通過重新查看風(fēng)險管理計劃，重新評估項目風(fēng)險；評估需求變更蘊涵的總的工作量和進度估計的變化。 客戶對分析結(jié)果進行評審評審，并做出答復(fù)答復(fù)。變更申請一般作為需求規(guī)格說明文檔的附件變更申請一般作為需求規(guī)格說明文檔的附件。有時還要修改文檔的有關(guān)部分以反映所做的變更。監(jiān)督已認可的變更申請并保證它們正確實現(xiàn)，這部分由配置管理過程處理。變更的累積影響 需求變更的一種危險是：盡管每種變需求變更的一種危

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

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

21、有求必應(yīng)，與客戶的關(guān)系處得如魚得水，這樣做肯定不會錯。就像前天我連合同都寫錯了，找到客戶，人家二話沒說就同意改了。你說如果是B的話可能嗎？”小王對此不以為然，“對項目經(jīng)理來說，成本、質(zhì)量和時間是最為重要的三要素。與客戶的關(guān)系當(dāng)然很重要，但也要全盤考慮項目的各要素。對于用戶的要求，應(yīng)該在有限的范圍內(nèi)給與解決，但不可以做出太大的犧牲。一味的遷就用戶將會使整個項目失敗?！毙×纸又⊥醯脑捳f：“當(dāng)前，國內(nèi)的項目一般情況下是由銷售處面簽單，再由項目經(jīng)理接手后續(xù)的工作，因此客戶關(guān)系多在事前已經(jīng)搞定。發(fā)生新的情況后，可以由公司的公關(guān)部出面與客戶進行協(xié)調(diào)，項目經(jīng)理可以在此過程中堅持一下原則，與公司的公關(guān)部一個

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

23、模的基本方法案例分析 課程實踐需求建模的基本方法介紹 chapter_450原型方法結(jié)構(gòu)化分析法面向?qū)ο蟮挠美治龇üδ芰斜矸?chapter_251需求建模的基本方法介紹 chapter_452原型方法結(jié)構(gòu)化分析法面向?qū)ο蟮挠美治龇üδ芰斜矸?、原型方法chapter_453需求分析原型開發(fā)原型評價原型實例54需求建模的基本方法介紹 chapter_455原型方法結(jié)構(gòu)化分析法面向?qū)ο蟮挠美治龇üδ芰斜矸?、結(jié)構(gòu)化分析方法5620世紀(jì)70年發(fā)展起來的面向數(shù)據(jù)流的方法是一種自頂向下逐步求精的分析方法根據(jù)軟件內(nèi)部數(shù)據(jù)傳遞、變換的關(guā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é)生成績學(xué)生健康情況表學(xué)生成績單查詢要求不及格人數(shù)人數(shù)統(tǒng)計表學(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é)號十姓名 學(xué)生健康信息：學(xué)號十健康情況 學(xué)生成績：學(xué)號十課程名+成績 查詢要求：健康查詢單 |平均成績查詢單 l不及格人數(shù)查詢 學(xué)生健康情況表：優(yōu)十良十一般十差 學(xué)生成績單：學(xué)號十姓名十課程名+成績+總成績 不及格人數(shù)統(tǒng)計表：學(xué)號十成績十不及格總?cè)藬?shù)需求建模的基本方法介紹 chapter_464原型方法結(jié)構(gòu)化分析法面向?qū)ο蟮挠美治龇üδ芰斜矸?、面向?qū)ο蟮挠美治?chapter_465基于面向?qū)ο蟮那榫胺治龇椒◤挠脩艚嵌瘸霭l(fā)考慮的功能需求用例是系統(tǒng)向用戶提供一個有價值的結(jié)果的某項功能UML需求視圖chapter_466用例視圖（Use case Diagram）順序圖（Sequence Diagram）狀態(tài)圖（State Diagram）活動圖（Activity Diagr