1、軟件需求管理,周 立 新 博士 北京大學(xué)軟件與微電子學(xué)院,業(yè)務(wù)需求,用戶需求,系統(tǒng)需求,功能需求,質(zhì)量屬性,其他非功能需求,約束條件,項(xiàng)目視圖與范圍文檔,使用實(shí)例文檔,軟件需求規(guī)格說(shuō)明,用戶能有效的糾正文檔中的拼寫錯(cuò)誤,找出文檔中的拼寫錯(cuò)誤并通過一個(gè)提供的替換項(xiàng)列表來(lái)供選擇替換拼錯(cuò)的詞。,找到并高亮度提示錯(cuò)詞； 顯示提供替換詞的對(duì)話框以及實(shí)現(xiàn)整個(gè)文檔范圍的替換。,需求工程,需求工程,需求管理,需求開發(fā),編寫規(guī)格說(shuō)明,分析,問題獲取,驗(yàn)證,包括軟件類產(chǎn)品中需求收集、評(píng)價(jià)、編寫文檔等所有活動(dòng),建立并維護(hù)在軟件工程中同客戶達(dá)成的契約,需求開發(fā)活動(dòng),確定產(chǎn)品所期望的用戶類。 獲取每個(gè)用戶類的需求。 了

2、解實(shí)際用戶任務(wù)和目標(biāo)以及這些任務(wù)所支持的業(yè)務(wù)需求。 分析源于用戶的信息以區(qū)別用戶任務(wù)需求、功能需求、業(yè)務(wù)規(guī)則、質(zhì)量屬性、建議解決方法和附加信息。,需求開發(fā)活動(dòng)（續(xù)）,將系統(tǒng)級(jí)的需求分為幾個(gè)子系統(tǒng)，并將需求中的一部份分配給軟件組件。 了解相關(guān)質(zhì)量屬性的重要性。 商討實(shí)施優(yōu)先級(jí)的劃分。 將所收集的用戶需求編寫成規(guī)格說(shuō)明和模型。 評(píng)審需求規(guī)格說(shuō)明，確保對(duì)用戶需求達(dá)到共同的理解與認(rèn)識(shí)，并在整個(gè)開發(fā)小組接受說(shuō)明之前將問題都弄清楚。,需求管理活動(dòng),定義需求基線（迅速制定需求文檔的主體）。 評(píng)審提出的需求變更、評(píng)估每項(xiàng)變更的可能影響從而決定是否實(shí)施它。 以一種可控制的方式將需求變更融入到項(xiàng)目中。 使當(dāng)前的項(xiàng)

3、目計(jì)劃與需求一致。,需求管理活動(dòng)（續(xù)）,估計(jì)變更需求所產(chǎn)生影響并在此基礎(chǔ)上協(xié)商新的承諾（約定）。 讓每項(xiàng)需求都能與其對(duì)應(yīng)的設(shè)計(jì)、源代碼和測(cè)試用例聯(lián)系起來(lái)以實(shí)現(xiàn)跟蹤。 在整個(gè)項(xiàng)目過程中跟蹤需求狀態(tài)及其變更情況。,基準(zhǔn)需求說(shuō)明,分析 編寫文檔 評(píng)審、商議,需求變更過程,市場(chǎng),需求,客戶,管理,市場(chǎng) 客戶 管理,項(xiàng)目環(huán)境,當(dāng)前基線,需求開發(fā),需求管理,修正后基線,需求變更,項(xiàng)目變更,需求開發(fā)與需求管理之間的界限,需求開發(fā)與管理之間的界線,1. 需求管理活動(dòng),CMMI中需求管理的流程圖,1.1 版本控制,需求文檔的每一個(gè)版本必須被統(tǒng)一確定。 組內(nèi)每個(gè)成員必須能夠得到需求的當(dāng)前版本。 必須清楚地將變更寫

4、成文檔，并及時(shí)通知到項(xiàng)目開發(fā)所涉及的人員。 為了盡量減少困惑、沖突、誤傳，應(yīng)僅允許指定的人來(lái)更新需求。,需求的屬性,創(chuàng)建需求的時(shí)間 需求的版本號(hào) 創(chuàng)建需求的作者 負(fù)責(zé)認(rèn)可該需求的人員 需求狀態(tài) 需求的原因或根據(jù)（或信息的出處） 需求涉及的子系統(tǒng) 需求涉及的產(chǎn)品版本號(hào) 使用的驗(yàn)證方法或接受的測(cè)試標(biāo)準(zhǔn) 產(chǎn)品的優(yōu)先級(jí)或重要程度（例如高、中、低或） 需求的穩(wěn)定性（在將來(lái)需求可能變更的指示器，不穩(wěn)定的需求意味你應(yīng)給予較多的關(guān)注，因?yàn)槟銓⒚媾R不定的、混沌的、或不能重復(fù)的業(yè)務(wù)過程。）,建議的需求狀態(tài)表,狀態(tài)跟蹤示例,1.2 需求變更管理,應(yīng)仔細(xì)評(píng)估已建議的變更。 挑選合適的人選對(duì)變更做出決定。 變更應(yīng)及時(shí)通

5、知所有涉及的人員。 項(xiàng)目要按一定的程序來(lái)采納需求變更。,控制項(xiàng)目范圍的擴(kuò)展,擴(kuò)展需求是指在軟件需求基線已經(jīng)確定后又要增添新的功能或進(jìn)行較大改動(dòng)。 問題不僅僅是需求變更本身，而是遲到的需求變更會(huì)對(duì)已進(jìn)行的工作有較大的影響。 要是每個(gè)建議的需求都被采納，對(duì)于項(xiàng)目出資者（sponsor）、參與者與客戶來(lái)說(shuō)項(xiàng)目將永遠(yuǎn)也不會(huì)完成事實(shí)上，這是不可能的。,控制項(xiàng)目范圍的擴(kuò)展,對(duì)許多項(xiàng)目來(lái)說(shuō)，一些需求的改進(jìn)是合理的且不可避免。 業(yè)務(wù)過程、市場(chǎng)機(jī)會(huì)、競(jìng)爭(zhēng)性的產(chǎn)品和軟件技術(shù)在開發(fā)系統(tǒng)期間是可以變更的，管理部門也會(huì)決定對(duì)項(xiàng)目做出一些調(diào)整。 在你的項(xiàng)目進(jìn)度表中應(yīng)該對(duì)必要的需求改動(dòng)留有余地。 若不控制范圍的擴(kuò)展將使我們

6、持續(xù)不斷地采納新的功能，而且要不斷地調(diào)整資源、進(jìn)度、或質(zhì)量目標(biāo)，這樣做極其有害。,管理范圍擴(kuò)展,管理范圍擴(kuò)展的第一步就是把新系統(tǒng)的視圖、范圍、限制文檔化并作為業(yè)務(wù)需求的一部分。 評(píng)估每一項(xiàng)建議的需求和特性，將它與項(xiàng)目的視圖和范圍相比較決定是否應(yīng)該采納它。 強(qiáng)調(diào)客戶參與的有效的需求獲取方法能夠減少遺漏需求的數(shù)量，只在做出提交承諾和分配資源后才采納該需求。 控制需求擴(kuò)展的另一個(gè)有效的技術(shù)是原型法，這個(gè)方法能夠給用戶提供預(yù)覽所有可能的實(shí)現(xiàn)，以幫助用戶與開發(fā)者溝通從而準(zhǔn)確把握用戶的真實(shí)需求。 要敢于說(shuō)“不”。,變更控制策略,所有需求變更必須遵循的過程，按照此過程，如果一個(gè)變更需求未被采納，則其后過程不

7、再予以考慮。 對(duì)于未獲批準(zhǔn)的變更，除可行性論證之外，不應(yīng)再做其它設(shè)計(jì)和實(shí)現(xiàn)工作。 簡(jiǎn)單請(qǐng)求一個(gè)變更不能保證能實(shí)現(xiàn)變更，要由項(xiàng)目變更控制委員會(huì)（ C C B）決定實(shí)現(xiàn)哪些變更。 項(xiàng)目風(fēng)險(xiǎn)承擔(dān)者應(yīng)該能夠了解變更數(shù)據(jù)庫(kù)的內(nèi)容。 絕不能從數(shù)據(jù)庫(kù)中刪除或修改變更請(qǐng)求的原始文檔。 每一個(gè)集成的需求變更必須能跟蹤到一個(gè)經(jīng)核準(zhǔn)的變更請(qǐng)求。,簡(jiǎn)單變更控制步驟模板,緒論 目的 范圍 定義 角色和責(zé)任 變更請(qǐng)求狀態(tài) 開始條件,任務(wù) 產(chǎn)生變更請(qǐng)求 評(píng)估變更請(qǐng)求 作出決策 通知變更人員 驗(yàn)證 結(jié)束條件,變更管理活動(dòng)中可能的項(xiàng)目角色,變更控制委員會(huì)的組成,產(chǎn)品或計(jì)劃管理部門。 項(xiàng)目管理部門。 開發(fā)部門。 測(cè)試或質(zhì)量保證部

8、門。 市場(chǎng)部或客戶代表。 制作用戶文檔的部門。 技術(shù)支持部門。 幫助桌面或用戶支持熱線部門。 配置管理部門。,常見變更請(qǐng)求數(shù)據(jù)項(xiàng),變更需求狀態(tài)轉(zhuǎn)換圖,測(cè)量變更活動(dòng),接收、未作決定、結(jié)束處理的變更請(qǐng)求的數(shù)量。 已實(shí)現(xiàn)需求變更（包括增、刪、改）的合計(jì)數(shù)量（也可以用在基線上占需求總數(shù)的百分比來(lái)表示）。 每個(gè)方面發(fā)出的變更請(qǐng)求的數(shù)量。 每一個(gè)已應(yīng)用的需求（是指已劃過基線）建議變更和實(shí)現(xiàn)變更的數(shù)量。 投入處理變更的人力、物力。,工作量 （勞動(dòng)時(shí)數(shù)） 任務(wù) _ 更新軟件需求規(guī)格說(shuō)明書或需求數(shù)據(jù)庫(kù) _ 開發(fā)并評(píng)估原型 _ 創(chuàng)建新的設(shè)計(jì)部件 _ 修改已有的設(shè)計(jì)部件 _ 開發(fā)新的用戶界面部件 _ 修改已有的用戶

9、界面部件 _ 開發(fā)新的用戶文檔和幫助文件 _ 修改已有的用戶文檔和幫助文件 _ 開發(fā)新的源代碼 _ 修改已有的源代碼 _ 購(gòu)買和集成第三方軟件 _ 修改構(gòu)造文件 _ 開發(fā)新單元測(cè)試和綜合測(cè)試 _ 進(jìn)行單元測(cè)試和綜合測(cè)試 _ 寫新的系統(tǒng)測(cè)試實(shí)例 _ 修改已有的系統(tǒng)測(cè)試實(shí)例 _ 修改自動(dòng)測(cè)試驅(qū)動(dòng)程序 _ 進(jìn)行回歸測(cè)試 _ 開發(fā)新報(bào)告 _ 修改已有的報(bào)告 _ 開發(fā)新的數(shù)據(jù)庫(kù)元素 _ 修改已有的數(shù)據(jù)庫(kù)元素 _ 開發(fā)新的數(shù)據(jù)文件 _ 修改已有的數(shù)據(jù)文件 _ 修改各種項(xiàng)目計(jì)劃 _ 更新別的文檔 _ 更新需求跟蹤能力矩陣 _ 檢查工作產(chǎn)品 _ 根據(jù)測(cè)試和檢查情況返工 _ 總計(jì)勞動(dòng)時(shí)數(shù),影響分析報(bào)告模板,變更

10、請(qǐng)求I D_ 標(biāo)題_ 描述_ 分析者_(dá) 日期_ 優(yōu)先權(quán)評(píng)估： 相關(guān)收益_（1 - 9） 相關(guān)代價(jià)_（1 - 9） 相關(guān)成本_（1 - 9） 相關(guān)風(fēng)險(xiǎn)_（1 - 9） 最終優(yōu)先級(jí)_ 預(yù)計(jì)總耗時(shí)_勞動(dòng)時(shí)數(shù) 預(yù)計(jì)損時(shí)_勞動(dòng)時(shí)數(shù) 預(yù)計(jì)對(duì)進(jìn)度的影響_天數(shù) 額外的成本影響_金額 質(zhì)量影響_ 被影響的其他需求_ 被影響的其他任務(wù)_ 要更新的計(jì)劃_ 綜合的事項(xiàng)_ 生存期成本事項(xiàng)_ 可能的變更所需檢查的其他部件_,1.3 需求跟蹤,一些可能的需求跟蹤能力聯(lián)系鏈,RequisitePro Project Organization,Toolbar,Project icon,Package,Document,View

11、s,Requirements,Working in a View,Existing Artifacts for RU e-st Project,RM Plan, Included on Exercise CD,RU e-st Project,Exist in the project,Create in the project,Import into the project,Create a Requirement in the Explorer or in a View,User Documentation Specifications,Design Specifications,Use-Case Model,Suppl