軟件需求工程過程

2. 評審員各自評審分派的內容，將發現的問題錄入DRL(缺陷記錄日志)；

    3. 評審小組負責人組織評審會議，各小組成員提交DRL并討論；

    4. 評審小組以IRF形式提交檢查報表；

    5. 軟件需求工程師根據IRF修訂相關文檔；

    6. 計劃經理整理數據，錄入TPT、SPT。

    七、 需求文檔編寫：

    1. 軟件需求工程師綜合考慮功能需求和非功能需求，編寫《軟件需求說明書》

    《軟件需求說明書》的編寫格式與要求，請參見具體的作業指導書。

    2. 利用RDC檢查《軟件需求說明書》是否全面、正確并可執行；

    3. 如果檢查不通過，從1重頭開始過程；

    4. 軟件需求工程師填寫TRL、PIP；

    5. 計劃經理整理數據，錄入TPT、SPT。

    八、 需求確認：

    1. 評審小組，對需求進行確認：

    l 確認每一個需求及相互關系；

    l 需求的總體質量達到標準。

    將結果寫到RVC。

    2. 軟件需求工程師根據RVC，修訂需求文檔，并最終通過；

    3. 軟件工程師為每一個需求設計測試用例，并錄入TRF；

    4. 相關人員填寫TRL、PIP；

    5. 計劃經理整理數據，錄入TPT、SPT。

    九、 配置管理：

    1. RD(需求文檔)成為基線后，即納入到配置管理；

    2. 如果需要對基線RD(需求文檔)進行修改，填寫CCP；

    3. 配置管理人員征求需求開發小組和其他相關人員(風險承擔者)關于CCP的意見；
 
    4. 如果所有人員通過CCP，則將需求文檔的配置管理取出，并填寫CCF；

    如果否決需求，則填寫RRF；

    5. 軟件需求工程師修改RD以適應新的需求 (可能包括REA等)；

    6. 評審小組對修改的RD執行第八步；

    7. 相關人員填寫TRL、DRL。

    十、 事后分析：

    1. 計劃經理將DRL、TRL、需求增長率，整理到PPS；

    2. 小組分析SREP過程，找出需要改進的地方，填寫PIP，并提交質量經理；

    3. 小組建立未來過程的改進目標。

    名詞解釋：

    1．風險承擔者 指從項目中直接或間接受益的人員,例如：用戶，管理人員，開發人員等。

文章來源于領測軟件測試網 http://www.kjueaiud.com/