六、 需求评审：

　　1. 评审小组负责人拟定检查清单，为成员分派检查任务，制订评审日程表;

　　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.风险承担者 指从项目中直接或间接受益的人员,例如：用户，管理人员，开发人员等