#CMMI受控文檔某公司文件編號：YKRM0401保密級別：公司機(jī)密需求管理計劃編制：審核：批準(zhǔn)：存放位置：某公司發(fā)布文檔修訂記錄目錄TOC\o"1-5"\h\z第一章簡介41.1目的41.2范圍41.3定義、首字母縮寫詞和縮略語41.4參考資料41.5概述4第二章需求管理4組織機(jī)構(gòu),職責(zé),和接口4工具,環(huán)境,和基礎(chǔ)架構(gòu)5第三章需求管理程序53.1需求標(biāo)識53.2可追蹤性標(biāo)準(zhǔn)53.2.1＜需求類型＞的標(biāo)準(zhǔn)5需求屬性53.3.1＜需求類型＞的屬性53.4報告和評估73.5需求變更管理73.5.1變更請求處理和審核73.5.2變更控制委員會(ChangeControlBoard-CCB.)73.5.3項目基線73.6工作流和活動8第四章里程碑8第五章培訓(xùn)和資源需求8第一章簡介需求管理計劃的簡介應(yīng)提供整個文檔的概述。其中應(yīng)包括此需求管理計劃的目的、范圍、定義、首字母縮寫詞、縮略語、參考資料和概述。1.1目的闡明本需求管理計劃的目的。一rn一rn簡要說明此需求管理計劃的范圍、與它相關(guān)的項目，以及受到此文檔影響的其他任何事物1.3定義、首字母縮寫詞和縮略語本小節(jié)應(yīng)提供正確解釋此需求管理計劃所需的全部術(shù)語的定義、首字母縮寫詞和縮略語。這些信息可以通過引用項目詞匯表來提供。1.4參考資料本小節(jié)應(yīng)完整列出此需求管理計劃中其他部分所引用的任何文檔。每個文檔應(yīng)標(biāo)有標(biāo)題、報告號（如果適用）、日期和出版單位。列出可從中獲取這些參考資料的來源。這些信息可以通過引用附錄或其他文檔來提供。1.5概述此小節(jié)應(yīng)說明需求管理計劃其他部分所包含的內(nèi)容，并解釋該文檔的組織方式。第二章需求管理2.1組織機(jī)構(gòu),職責(zé),和接口對于需求工作流中描述的所有活動，都要說明誰負(fù)責(zé)執(zhí)行某項活動。2.2工具,環(huán)境,和基礎(chǔ)架構(gòu)說明在完成需求管理功能的項目生命周期中的計算機(jī)環(huán)境和使用的軟件工具。說明項目生命周期中產(chǎn)生的用于需求項目的版本控制的工具和過程。第三章需求管理程序3.1需求標(biāo)識對于項目中的每種需求文檔或工作產(chǎn)品，都應(yīng)列出其中包含的需求類型，并簡要解釋其用途。最好也列出承擔(dān)相應(yīng)職責(zé)的角色。工作產(chǎn)品需求類型說明用戶需求規(guī)格說明書用戶需求（BRQ）用戶需求（包括變更請求）軟件需求規(guī)格說明書涉眾需求和軟件特性（SRS）涉眾或用戶需求；此系統(tǒng)發(fā)布版的狀況或功能。3.2可追蹤性標(biāo)準(zhǔn)對于已確定的每一需求類型，應(yīng)列出確定可追蹤性時使用的標(biāo)準(zhǔn)（應(yīng)追蹤至的對象）。3.2.1＜需求類型＞的標(biāo)準(zhǔn)對于已確定的每一需求類型，應(yīng)列出確定可追蹤性時使用的標(biāo)準(zhǔn)（應(yīng)追蹤至的對象）。3.3需求屬性3.3.1＜需求類型＞的屬性對于已確定的每一需求類型，都應(yīng)列出將要使用的屬性，并簡要解釋其含義。例如，對于“特性這一需求類型，可能要列出以下屬性：3.3.1.1狀態(tài)在經(jīng)過項目管理團(tuán)隊的商談和復(fù)審后設(shè)置。用于在確立項目基線的過程中對進(jìn)度進(jìn)行跟蹤。已提出用于說明正在進(jìn)行討論但尚未經(jīng)過“正式渠道"（例如由項目團(tuán)隊、產(chǎn)品管理部門和用戶或客戶群的代表所組成的工作組）復(fù)審和驗收的特性。已批準(zhǔn)被認(rèn)為是有用、可行并已獲得正式渠道批準(zhǔn)，準(zhǔn)備實施的功能。已并入在特定時間點(diǎn)并入產(chǎn)品基線中的特性。3.3.1.2利益由營銷經(jīng)理、產(chǎn)品經(jīng)理或業(yè)務(wù)分析員設(shè)置。并非所有需求都同等重要。通過按照各項需求對最終用戶的相對利益來劃分其等級，可以促使客戶、分析員和開發(fā)團(tuán)隊成員相互交換意見。用于管理規(guī)模并確定開發(fā)的優(yōu)先級。關(guān)鍵［必不可少的特性。不實現(xiàn)這些規(guī)約就無法使系統(tǒng)滿足客戶的需要。所有關(guān)鍵特性都必須在發(fā)布時實現(xiàn)，否則將錯過預(yù)定的發(fā)布時間。］重要［對于系統(tǒng)在大多數(shù)應(yīng)用中的有效性及效率都較為重要的特性。很難通過其他方式來實現(xiàn)這方面的功能。如果遺漏了某項重要特性，可能會影響客戶或用戶滿意度，甚至?xí)绊懯杖?，但發(fā)布并不會因為缺少某一項重要特性而延期。］有用［有些特性在不太典型的應(yīng)用中比較有用，或者可以合理而有效地實現(xiàn)其替代特性，這些特性的使用次數(shù)將會相對較少。即使發(fā)布版中沒有包括某一項這樣的特性，也不會對收入或客戶滿意度造成嚴(yán)重的影響。］3.3.1.3工作量由開發(fā)團(tuán)隊設(shè)置。由于有些特性所需的時間和資源多于其他特性，所以在評測復(fù)雜程度并預(yù)計在給定時間范圍內(nèi)能否完成哪些工作時，最佳的方式就是估計團(tuán)隊工作周數(shù)或個人工作周數(shù)、所需的代碼行數(shù)或功能點(diǎn)數(shù)（舉例來說）。用于管理規(guī)模并確定開發(fā)的優(yōu)先級。3.3.1.4風(fēng)險由開發(fā)團(tuán)隊根據(jù)項目遭遇意外事件的可能性來設(shè)置，這些事件包括超支、工期延誤，甚或是項目取消。雖然可以對風(fēng)險級別進(jìn)行細(xì)分，但大多數(shù)項目經(jīng)理都認(rèn)為將風(fēng)險歸為高、中、低就足夠了。通過評測項目團(tuán)隊估計進(jìn)度的不確定性（范圍），一般都可以間接地對風(fēng)險進(jìn)行評估。3.3.1.5穩(wěn)定性由分析員和開發(fā)團(tuán)隊設(shè)置，設(shè)置的依據(jù)是特性發(fā)生變化的可能性或團(tuán)隊對特性的理解發(fā)生變化的可能性。用于協(xié)助確定開發(fā)優(yōu)先級并確定下一步需要繼續(xù)征集的特性。3.3.1.6目標(biāo)發(fā)布版記錄將首次包括指定特性的產(chǎn)品版本。該字段可用于將前景文檔中的特性分配給特定的基線發(fā)布版。如果將其與狀態(tài)字段結(jié)合，您的團(tuán)隊就可以提出、記錄和討論發(fā)布版的各種特性，而此時還不必前進(jìn)到開發(fā)階段。只有狀態(tài)被設(shè)置為“已并入”且目標(biāo)發(fā)布版已確定的特性才將被實施。管理規(guī)模時，可以增加目標(biāo)發(fā)布版本號，這樣該項特性雖然仍保留在前景文檔中，但將安排在以后發(fā)布。3.3.1.7職責(zé)分配在許多項目中，特性會被分配給各個“特性團(tuán)隊”，它們負(fù)責(zé)進(jìn)一步獲取需求，并編寫軟件需求和實施方案。這一簡單的下拉列表將幫助項目團(tuán)隊中的每位成員更好地理解他們的職責(zé)。3.3.1.8此文本字段用于跟蹤所需特性的來源。需求的提出總會有一定的原因。此字段記錄相應(yīng)的解釋或?qū)ο鄳?yīng)解釋的引用。例如，引用可以是產(chǎn)品需求規(guī)約的頁碼及行號，或是某次重要的客戶訪談錄像的會議記錄標(biāo)號。3.4報告和評估描述需求報告的內(nèi)容、格式和目標(biāo).3.5需求變更管理3.5.1變更請求處理和審核描述問題和變更被提交、評審和審核的處理過程，包括與用戶協(xié)商需求變更和任何約定的過程、活動和約束。3.5.2變更控制委員會(ChangeControlBoard-CCB)說明CCB的成員組成，處理需求變更和批準(zhǔn)的程序。3.5.3項目基線基線提供一個“官方”的標(biāo)準(zhǔn)，其后的工作都是基于這個標(biāo)準(zhǔn)，只有經(jīng)過授權(quán)方可進(jìn)行變更。說明在項目或產(chǎn)品生命周期建立基線的點(diǎn)，許多公共基線的建立通常在軟件生命周期的某個階段結(jié)束時。也可以在迭代結(jié)束時生成基線內(nèi)的各個階段。說明誰創(chuàng)建或授權(quán)創(chuàng)