软件需求工程过程(SREP)，本文简要地列举并说明了在整个软件需求工程的过程中的工作职责要点。

一、 开始

1. 项目经理根据项目特点，指定对过程表格的具体要求；

2. 项目经理制订项目的标准，包括：DTS(缺陷类型)、TRA(风险类型)、TRS(需求类型)等，在过程表格中按标准引用.

二、 计划

1. 计划经理估算需求开发时间；

2. 计划经理完成：SPT(进度计划)、TPT(任务计划)，将计划数据录入PDS(项目计划摘要).

三、 需求获取

1. 软件需求工程师搜集系统概要信息，填写REQ(需求获取概貌)；

2. 软件需求工程师搜集用户需求，分类并清晰地把需求写入REA(需求获取/分析)、RES(需求获取情节)、UIR(用户交互需求)；

3. 检查需求获取过程，并填写REC(需求获取检查)；

4. 如果检查不通过，从1.重头开始过程；

5. 软件需求工程师填写TRL(时间记录日志)、PIP(过程改进建议)；

6. 计划经理整理本阶段数据，录入SPT、TPT.

四、 需求分析

1. 软件需求工程师进行需求分析，建立分析模型，数据字典及项目词汇表，完成REA（分析模型的具体要求，请分别参见结构化分析和面向对象分析的具体作业指导书）；

2. 软件需求工程师将发现的需求的冲突、交迭、冗余或矛盾，记入NCR；

3. 检查需求分析，完成RAC(需求分析检查)；

4. 如果检查不通过，从1重头开始过程；

5. 软件需求工程师填写TRL、PIP；

6. 计划经理整理数据，录入TPT、SPT.

五、 协商

1. 软件需求工程师利用NCR，与风险承担者协商解决需求分析中发现的问题，将决议录入NCR；

2. 软件需求工程师根据决议，修改REA等相关文档；

3. 如果有新的需求引入，需要重新进行需求分析阶段；

4. 软件需求工程师填写TRL、PIP；

5. 计划经理整理数据，录入TPT、SPT.

六、 需求评审

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

2. 评审员各自评审分派的内容，将发现的问题录入DRL(缺陷记录日志)；

3. 评审小组负责人组织评审会议，各小组成员提交DRL并讨论；

4. 评审小组以IRF形式提交检查报表；

5. 软件需求工程师根据IRF修订相关文档；

6. 计划经理整理数据，录入TPT、SPT。

七、 需求文档编写

1. 软件需求工程师综合考虑功能需求和非功能需求，编写《软件需求说明书》
《软件需求说明书》的编写格式与要求，请参见具体的作业指导书。

2. 利用RDC检查《软件需求说明书》是否全面、正确并可执行；

3. 如果检查不通过，从1重头开始过程；

4. 软件需求工程师填写TRL、PIP；

5. 计划经理整理数据，录入TPT、SPT。

八、 需求确认

1. 评审小组，对需求进行确认：

• 确认每一个需求及相互关系；
• 需求的总体质量达到标准。

将结果写到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. 小组建立未来过程的改进目标.

名词解释

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

组织简介 | 联系我们 |   Copyright 2002 ®  UML软件工程组织 京ICP备10020922号

京公海网安备110108001071号