1、金宇恒軟件過程標準需求管理過程V1.0修訂記錄版本號日 期作者授權人授權日期描述0.92002/07/19萬志鵬蘇光2002/07/18第一次編制, 蘇光指導0.992002/07/29萬志鵬蘇光2002/08/01根據評審意見修改過程，并轉換為公司文檔格式。1.02002/08/12萬志鵬彭柏林2002/08/12通過批準目錄1目的和范圍12術語簡稱與解釋13進入準則14退出準則15階段交付產品26文件使用者27過程流圖37.1過程3需求收集與獲取3需求評審5需求變更管理過程67.2過程描述8需求收集與獲取過程細則8需求評審細則8需求變更管理過程細則97.3驗證機制107.4度量108活動職

2、責矩陣119參考資料1110附件111 目的和范圍本過程的目的在于為公司實施與需求相關的方針提供指南。該過程對所有公司負責需求采集的項目適用，也適用于那些客戶在自行采集需求時需要幫助的項目。2 術語簡稱與解釋總經理：簡稱GM，指公司總經理，具備法人代表資格。副總：簡稱VGM，公司的一種職務，指公司副總。項目經理：簡稱PM，公司的一種職務，一般由具備項目管理經驗和行業經驗人員承擔，負責項目的管理活動。項目負責人：簡稱PL，項目組組長，臨時性職務，負責項目的開發活動，如無變更，生存周期與項目生存周期相同。需求分析人員：簡稱RA，通常由項目組中成員承擔此角色，可以是項目負責人也可以項目組中其他人員。

3、軟件設計人員：簡稱SD。在公司一般指系統分析員和程序員（包括高級程序員）；在項目中指項目組中的設計人員。軟件質量保證：SQA，一種軟件質量保證活動，在公司通常也用SQA代表質量保證活動者，目前由公司品管部執行此活動。配置管理員：簡稱CC，在公司中負責所有項目的配置管理活動。3 進入準則進入準則如下： 來自客戶的關于需求的文檔經過公司審批； 來自客戶的標識有意進行某個項目的信函，并且經過公司審批； 總經理對內部項目的授權，有相關文件（文檔）表明是經過審批的； 公司與客戶簽訂的合同。附注：滿足其中任何一種條件均可。4 退出準則退出準則如下： SRS的文檔已準備好，經過評審和批準。5 階段交付產品本

4、階段交付有： 經過評審并得到批準的SRS文檔； SRS評審報告； 變更請求； 變更請求單日志； 影響分析報告。6 使用者本文件的使用者如下：VGM、RA、SD、PM、PL、QA。7 過程流圖7.1 過程7.1.1 需求收集與獲取7.1.2 需求評審7.1.3 需求變更管理過程7.2 過程描述需求管理過程被分為3部分，包括：需求獲取和采集過程、需求評審過程、需求變更管理過程。7.2.1 需求收集與獲取規程 需求可能來自以下任何一種渠道n 客戶的需求文檔n 工作范圍描述文檔n 電子郵件n 合同 隨后，進行需求文檔格式的評審：n 當需求不是以公司格式提交時，項目經理/項目負責人可選擇如下處理辦法：將

5、需求轉換成金恒宇公司的格式，或采用用戶的需求文檔格式。n 當客戶特別要求用他們自己的格式時，應滿足他們的要求。 就以下方面對評審需求n 正確性。正確性取決于技術人員n 完整性。完整性取決于技術人員以及SQA人員n 可行性。可行性研究由PM/PL在評審時進行，在進行估計時進一步完善對可行性的研究n 一旦在需求文件中發現缺陷/問題，將編制評審報告，并從客戶那里征求進一步的闡述或建議或更多輸入n 如果評審報告表明需求清晰、完整而且正確無誤，需求文檔得到基線化；n 需求文檔命名應遵守命名規則，并檢入配置管理（CM）工具/庫；n SRS的評審報告也要置于配置管理之下7.2.2 需求評審規程在SRS被用于

6、開展進一步的策劃和開發活動之前，SRS必須經過評審制定評審計劃，選定SRS評審人員，主要有：VGM、PM、PL、RA、SD、關鍵技術人員。 評審進度安排要通知給評審小組成員，交流的方式可以是E-MAIL亦可是書面通知 分發SRS文檔以及其他客戶提供的資料和參考資料，評審小組成員就SRS進行個人評審，如果發現任何缺陷，將他們列入個人的缺陷清單 評審者參加評審會議，分配評審組角色 讀者朗讀SRS文檔 當任何評審組員發現潛在的缺陷時，讀者停止朗讀，小組討論它是否是SRS的一個缺陷，若確實存在缺陷，由記錄員負責記錄下來 以上過程反復進行直到所有的缺陷均被討論并達成一致意見 記錄員做出最終缺陷列表，評審

7、小組負責人將其通知客戶 需求分析人員就評審中發現的缺陷征求客戶的意見 評審小組就缺陷嚴重程度決定是否進行再評審 一旦再評審是必須的，評審報告應反映這個情況并采用本規程安排及執行再評審 如果在SRS文件中找不到重要缺陷，亦認為再評審無必要，則可批準該SRS文檔，并基線化 基線化的SRS版本應檢入配置管理（CM）工具/庫7.2.3 需求變更管理規程 當需求發生變更，公司要提出變更請求、這個工作可以由公司或客戶來做 變更請求必須有一個唯一的編號 對變更進行影響分析，以評估變更的規模。一旦發現變更影響巨大，以至波及到項目工作量、進度，成本，變更將轉送到公司高層經理和市場/財務部門決策是否變更合同 當變

8、更被認可（小變更由公司控制，大變更要經過客戶許可）變更申請轉變成變更令，并付諸實施 更新SRS文件。如果有要求，更新其他文件 為這些變更的進行提供資源（人，軟件、硬件），如有必要時。 將更新過的文檔置于CM的管理之下（CM工具/庫） 將SRS及其他文件的變更通知所有相關人員 按照項目跟蹤過程與活動，對變更的執行進行跟蹤 一旦變更實施，且實施通過驗收，變更請求單上將標注為閉合 為便于在以后參閱，關于該變更的所有信息將保存在過程數據庫中7.3 驗證機制 驗證機制如下： 配置審計n 對執行期超過六個月的項目應當在每個月、每個版本發布前、任何外部審計前進行。n 對執行期少于六個月的項目應當在每15天、

9、每個版本發布前、任何外部審計前進行。 由SQA/獨立小組進行的內部審計n 對執行周期超過六個月的項目每個月組織內部審計。n 對執行周期少于六個月的項目每15天組織內部審計。 外部審計n ISO監督審計由外審人員安排日程。n CMM相關評估由評估人員安排日程。 給管理高層的關于需求管理相關活動的定期報告n 對執行期少于六個月的項目應當每周進行報告n 對執行期超過六個月的項目應當每15天進行報告7.4 度量對需求相關活動的評估指標如下：編號評估指標頻率責任來源1需求數量每15天PM / PLSRS2需求變更數量每周PM / PL變更日志3已認可的變更數量每周PM / PL變更申請日志4正在執行的變更數量每周PM / PL項目狀態報告5需求相關活動中耗費的工作量每周所有參與需求相關活動人員時間表6預期在需求管理中耗費的工作量每周PM / PL項目計劃7實際在需求管理中耗費的工作量每周所有參與需求活動人員項目狀態報告8 活動職責矩陣編號.活動VGMPMPLRASQA/ SEPG1獲得需求-SSP-2評審需求SPPPS3準備SRS-SPP-4評審SRSSPPPS5認可SRSSPSSS6認可變化SPSPS7影響分析SPPPS8管理SRSSSPSS9