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