【正文】 用例 編號 描述 燈的狀態(tài) 預(yù)期結(jié)果 開關(guān) 1 基本流：住戶按下按扭的時間小于 1秒 開 關(guān)并記憶亮度 2 基本流：住戶按下按扭的時間小于 1秒 關(guān) 按記憶亮度開 3 其他流：住戶按下按扭的時間大于 1秒 開 亮度按 10%/秒速度上升達(dá)到最大后下降并循環(huán) 4 其他流：住戶按下按扭的時間大于 1秒 關(guān) 先開，然后再同上循環(huán) 5 其他流：住戶按下按扭的時間大于 1秒后松開了開關(guān) 開 停在當(dāng)時的亮度位置 6 其他流：住戶按下按扭的時間大于 1秒后松開了開關(guān) 關(guān) 停在當(dāng)時的亮度位置 根據(jù)用例的事件流分析，針對用例情景，產(chǎn)生系統(tǒng)測試用例。 需求追蹤鏈（ 4）：從用例到測試用例 需求實(shí)現(xiàn) —— 需求追蹤能力 ?如果項(xiàng)目開發(fā)的文檔化 、 形式化做的不夠 ， 需求追蹤鏈存在于工程師的頭腦中 ， 則需求追蹤是沒有保證的 。 ?同時 ， 需求追蹤強(qiáng)調(diào)的是沿需求實(shí)現(xiàn)路徑的追蹤 ， 而不是僅僅檢查點(diǎn)與點(diǎn)之間的對應(yīng) （ 功能測試 ） ， 因此 ， 建立完善的需求實(shí)現(xiàn)過程的記錄 ，是實(shí)現(xiàn)需求追蹤的關(guān)鍵 。 ?現(xiàn)在 ， 有一些需求管理工具 ， 可以幫助進(jìn)行需求追蹤 。 小結(jié) ： 在需求實(shí)現(xiàn)階段 ， 需求管理的工作要點(diǎn)歸納起來 ， 就是以下幾個方面： （ 1） 需求要盡量形式化 、 數(shù)據(jù)庫化； （ 2） 在需求形式化的基礎(chǔ)上 ， 建立需求追蹤矩陣 ， 對需求實(shí)現(xiàn) ， 進(jìn)行追溯和回溯； （ 3） 需求追蹤能力的好壞 ， 是軟件需求管理水平的標(biāo)志 。 需求變更管理 ? 需求變更管理的重要性 ? 需求變更控制活動 ? 需求變更波及分析 ? 需求穩(wěn)定性評估 需求變更管理的重要性 時間緊迫 壓縮需求過程 產(chǎn)品不滿足需求變更需求維護(hù)工作量增加項(xiàng)目資源惡化需求過程的惡性循環(huán)需求變更的原因多種多樣，但管理變更，應(yīng)確立以下原則： （ 1） 認(rèn)識到變更是不可避免的，為變更指定計(jì)劃； （ 2）確定需求基線； （ 3）建立控制變更的唯一渠道 （ 4）使用變更控制系統(tǒng)來控制變更過程； （ 5）分層次地管理變更。 需求變更控制活動 6大需求變更控制活動 （ 1）確定需求變更控制過程： 確定需求變更的選擇、分析、決策、記錄的過程，所有需求的變更，都要在選擇、分析、決策、記錄環(huán)節(jié)上，受到機(jī)制和責(zé)任的保證。 （ 2）建立需求變更控制委員會： 組織公司、項(xiàng)目組內(nèi)部和用戶利益和風(fēng)險(xiǎn)承擔(dān)人員，成立需求變更控制委員會，由他們來決定要變更哪些需求，是否在項(xiàng)目范圍之內(nèi)（包括：項(xiàng)目范圍和合同范圍。因?yàn)橛袝r，在項(xiàng)目范圍，但不在合同范圍，需要項(xiàng)目進(jìn)行二期合同開發(fā)），評估變更的波及，最后決定變更是可以接受，還是放棄。對變更的需求設(shè)置優(yōu)先級、制定版本規(guī)定等。 需求變更 —— 6大需求變更控制活動 （ 3）進(jìn)行需求變更影響分析： 波及分析有利于對需求變更要求，進(jìn)行更深入、精確的理解，幫助變更控制委員會做出科學(xué)的決策。波及分析還可以幫助項(xiàng)目組對現(xiàn)有系統(tǒng)做出合理的、有前瞻性的調(diào)整，使面對日后新的需求變更，有充足的技術(shù)準(zhǔn)備。 波及分析完全依賴于需求的跟蹤能力。沒有需求形式化記錄、沒有需求跟蹤鏈，就沒有波及分析的可能。如果有，也是主觀的、非定量的。由此對項(xiàng)目計(jì)劃、成本、質(zhì)量控制的影響分析，其可信度是有疑問的。 系統(tǒng)分析師和架構(gòu)師應(yīng)評估變更對系統(tǒng)技術(shù)實(shí)現(xiàn)的影響。 項(xiàng)目經(jīng)理應(yīng)根據(jù)新需求，明確相關(guān)任務(wù)，評估新的工作量和相應(yīng)的要求變化。新需求不但導(dǎo)致分析、編碼、測試的工作量增加，項(xiàng)目管理有關(guān)的各環(huán)節(jié)（需求管理、計(jì)劃管理、成本管理、配置管理、質(zhì)量管理等）都會有所變化。 在需求變更評估分析中，也要做需求穩(wěn)定性評估。頻繁地需求變更，應(yīng)該超出了需求變化的范圍。項(xiàng)目經(jīng)理要考慮項(xiàng)目組織管理方面，是不是發(fā)生了什么問題。 需求變更 —— 6大需求變更控制活動 （ 4）跟蹤所有受需求變更影響的工作產(chǎn)品： 當(dāng)確定某一需求發(fā)生變更時，根據(jù)需求跟蹤矩陣，找到與變更需求有關(guān)的各層、各環(huán)節(jié)需求項(xiàng)。例如：涉及需求項(xiàng)的設(shè)計(jì)模型、代碼模塊、測試用例等。這些部分全部必須做相應(yīng)的修改。依據(jù)需求跟蹤矩陣，可以完整地追蹤到需求變更所影響到的所有地方，可以不會發(fā)生遺漏，而產(chǎn)生系統(tǒng) BUG，或產(chǎn)品缺陷。甚至包括對軟件產(chǎn)品本身以外的影響，如：因需求變更，版本控制沒有相應(yīng)的記錄、產(chǎn)品使用手冊沒有做相應(yīng)修改等。 因?yàn)樾枨笞兏?，需求狀態(tài)記錄應(yīng)相應(yīng)地發(fā)生變化。每一條記錄，反映了需求的現(xiàn)實(shí)情況。 （ 5）調(diào)整需求基線： 需求變化以后，需求變更控制委員會要決定是否調(diào)整需求基線。新需求是反映為基線的調(diào)整，還是版本的變化。 基線是產(chǎn)品的標(biāo)準(zhǔn)，基線變化可以作為產(chǎn)品標(biāo)準(zhǔn)的變化，也可以理解為將發(fā)行一個新版本的產(chǎn)品。 需求變更 —— 6大需求變更控制活動 但是，版本并不一定就是新產(chǎn)品。因?yàn)椋?dāng)產(chǎn)品面對不同地區(qū)、不同用戶群的時候，也可以確定不同的版本。因此，需求變更控制委員會要做的工作，是對新需求，決定是全面升版，還是局部更改。是基線變化，還是個別版本變化。有時，這是一個比較難于做出的決定，他依賴于對新需求的分析，評估它對市場、用戶和產(chǎn)品本身的影響。 （ 6）維護(hù)需求變更記錄和文檔： 決定變更基線或提升版本以后，就要做好記錄，修改相應(yīng)的文檔。變更記錄要記錄變更原因、變更內(nèi)容、變更影響、變更實(shí)現(xiàn)過程、其他相應(yīng)變更等。變更記錄越完整，對于追溯，甚至以后可能發(fā)生的回退，就越有幫助。 有一些版本控制工具，可以幫助項(xiàng)目經(jīng)理來做到記錄相應(yīng)的信息。 需求變更波及分析 變更波及分析的意義 對于項(xiàng)目組來說，一個新的需求提出來以后，這個需求如果接受，可能對系統(tǒng)造成多大的影響？系統(tǒng)結(jié)構(gòu)上的、數(shù)據(jù)結(jié)構(gòu)上的、涉及的模塊、版本上的變更影響有多大？ 需求波動在技術(shù)上有潛伏性，在工程上，也表現(xiàn)為不可預(yù)知性。工作量不可預(yù)知、成本不可預(yù)知。項(xiàng)目經(jīng)理往往受市場人員的壓力，對用戶宣稱“免費(fèi)維護(hù)”，但在項(xiàng)目組內(nèi)部，對于需求變更的成本，甚至可能是“巨大”的。這種不理智的“反差”，正好說明了我們軟件項(xiàng)目管理的水平，是處在原始和粗放的狀態(tài)。 需求波及分析是軟件項(xiàng)目管理的需求管理比較重要的組成部分，在需求變更決策前，通過波及分析，可以達(dá)到精確理解需求、評估系統(tǒng)對需求變更要求的接納程度、變更的代價、變更對系統(tǒng)總體架構(gòu)、甚至產(chǎn)品發(fā)展的影響等。 這樣的分析，對需求變更委員會做出變更批準(zhǔn)還是放棄的決策，具有重要的意義。一旦變更控制委員會批準(zhǔn)需求變更的要求，就能比較清晰地知道相應(yīng)變更的內(nèi)容、工作范圍、需要的時間等。需求變更波及分析也是保證項(xiàng)目組在需求變更以后，可以做到“在計(jì)劃、成本、質(zhì)量（不是降低質(zhì)量標(biāo)準(zhǔn)為代價）范圍的變更”。 需求變更 —— 變更波及的內(nèi)部分析 系統(tǒng)元素波及分析包括： （ 1） 所有涉及到的輸入界面有關(guān)部分； （ 2） 所有涉及到的報(bào)表等輸出界面有關(guān)部分； （ 3） 所有涉及到的外部接口部分； （ 4） 所有涉及到的內(nèi)部接口部分； （ 5） 所有涉及到的數(shù)據(jù)庫表結(jié)構(gòu)； （ 6） 所有涉及到的系統(tǒng)數(shù)據(jù)定義； （ 7） 所有涉及到的公用模塊定義、公用子程序庫、控件庫； （ 8） 所有涉及到的系統(tǒng)常量、宏定義； （ 9） 所有涉及到的已經(jīng)實(shí)現(xiàn)的代碼； （ 10） 所有涉及到的已經(jīng)完成的單元、集成測試； （ 11） 所有涉及到的已經(jīng)編寫完成的用戶文檔（使用手冊、維護(hù)手冊）； （ 12） 所有涉及到的已經(jīng)編寫完成的幫助文件、培訓(xùn)教材； （ 13） 所有涉及到的第三方軟件和工具； （ 14） 所有涉及到的項(xiàng)目管理有關(guān)的需求管理、計(jì)劃管理、成本管理、配 置管理、質(zhì)量管理有關(guān)的數(shù)據(jù)庫、文檔庫； （ 15） 所有涉及到的其他應(yīng)該檢查的部分； （ 16） 所有涉及到的 ……… 。 需求變更 —— 變更波及的外部分析 （ 1）變更是否與基線（已經(jīng)實(shí)現(xiàn)的部分）相沖突（是否是基線內(nèi)的）； （ 2） 變更是否存在與雖未實(shí)現(xiàn)，但已經(jīng)決定的需求相沖突； （ 3）不采納變更是否會有技術(shù)上的風(fēng)險(xiǎn)，或者采納變更會有什么技術(shù)上的風(fēng)險(xiǎn)； （ 4）不采納變更是否會有業(yè)務(wù)上的風(fēng)險(xiǎn)，或者采納變更會有什么業(yè)務(wù)上的風(fēng)險(xiǎn)； （ 5）不采納變更是否會導(dǎo)致質(zhì)量降低，或者采納變更會有多大的質(zhì)量提升； （ 6） 變更在技術(shù)實(shí)現(xiàn)上是可行的嗎？ （ 7） 采納變更是否會導(dǎo)致用戶進(jìn)一步提出更多不合理的要求？ （ 8）采納變更對現(xiàn)有項(xiàng)目組在人力、技術(shù)、工具等方面，是否能夠承受，增加資 源是否可能； （ 9）采納變更的需求變更量的估計(jì)是多少？（以單元為單位、以時間為單位、以 成本為單位） （ 10）采納變更后，雖然進(jìn)行了合理安排，包括采用關(guān)鍵路徑法，調(diào)整進(jìn)度安 排，但最后仍然對進(jìn)度的影響是多少？ （ 11）采納變更以后使多少實(shí)際已經(jīng)開發(fā)完成的單元被廢棄，相關(guān)的工作量是多 少？ （ 12）采納變更以后使多少實(shí)際已經(jīng)開發(fā)所用的單元時間被浪費(fèi)，相關(guān)的比率是 多少？ （ 13） 變更對市場、銷售、培訓(xùn)、維護(hù)的影響有多大？ 需求變更 —— 需求變更波及分析報(bào)告 標(biāo)題： 變更描述： 分析人 日期： 優(yōu)先級評定： 相關(guān)收益： 相關(guān)代價： 相關(guān)成本： 相關(guān)風(fēng)險(xiǎn)： 增加耗時： 增加人力： 對進(jìn)度的影響： 對成本的影響： 對質(zhì)量的影響： 直接影響的其他部分： 間接影響的其他部分： 導(dǎo)致的計(jì)劃變更： 導(dǎo)致的成本變更： 其他影響： 假定前提： 條件與約束： 評審人意見： 需求穩(wěn)定性評估 為了了解需求的穩(wěn)定性情況，可以對需求的穩(wěn)定性，進(jìn)行評估。評估的基本過程是： （ 1）統(tǒng)計(jì)基線需求的數(shù)量：通過需求數(shù)據(jù)庫，可以按最底層的需求項(xiàng)為單位，統(tǒng)計(jì)需求的數(shù)量。因?yàn)槿魏紊蠈有枨蟮淖兓?，最終要反映到最底層需求項(xiàng)的變化。比較差的設(shè)計(jì)，可能使簡單的需求變化，帶來巨大的系統(tǒng)元素的修改。 （ 2）統(tǒng)計(jì)每月 /每周基線需求項(xiàng)的增加、刪除、修改的數(shù)量。如同需求基線一樣，根據(jù)項(xiàng)目的大小和歷史經(jīng)驗(yàn)，項(xiàng)目經(jīng)理也要定一個穩(wěn)定性基線，當(dāng)需求變化量在一定時間內(nèi)超過了穩(wěn)定性基線，項(xiàng)目經(jīng)理就要分析原因，采取措施。 （ 3）需求變化既可能來自組織外部，也可能來自項(xiàng)目組內(nèi)部。對需求不穩(wěn)定的因素和來源進(jìn)行分析，做出的評估，是獲得需求穩(wěn)定的好辦法。這一點(diǎn)，將在以后 《 配置管理 》 和 《 質(zhì)量管理 》 中，再做詳細(xì)討論。 對需求穩(wěn)定性的關(guān)注，是軟件項(xiàng)目經(jīng)理經(jīng)常需要做的工作。需求不穩(wěn)定，是項(xiàng)目組的“危險(xiǎn)警報(bào)”。輕則是項(xiàng)目組工作量的增大，重則可能導(dǎo)致項(xiàng)目的嚴(yán)重延誤，甚至失敗。 現(xiàn)代軟件工程需求管理的關(guān)鍵要點(diǎn) 需求開發(fā)階段 ?業(yè)務(wù)模型 /用例誘導(dǎo) ?分析模型 ?需求形式化 ?需求評審 需求實(shí)現(xiàn)階段 ?需求分解與需求分配 ?需求基線化與狀態(tài)控制 ?需求可追溯與可跟蹤 ?需求波動分析與需求穩(wěn)定性評估 ?需求過程中的質(zhì)量評估與控制 通過軟件需求管理實(shí)現(xiàn)項(xiàng)目的范圍管理 ? 項(xiàng)目的范圍 —— 軟件需求、需求控制過程 ? 項(xiàng)目的范圍管理 —— 需求定義和用戶確認(rèn)、控制 ? 范圍管理的過程 —— 項(xiàng)目啟動、范圍計(jì)劃編制、范圍定義、范圍確認(rèn)、范圍變更控制 ? WBS結(jié)構(gòu) —— 需求樹 ? 范圍確認(rèn) —— 需求獲取階段的用戶確認(rèn)，需求確認(rèn)階段的內(nèi)部需求評審 ? 范圍變更控制系統(tǒng) —— 需求基線、需求追蹤鏈、需求狀態(tài)控制、需求波動分析與穩(wěn)定性評估