需求分析
（版权所有，翻版必究）
文件修改控制
目录1. 目的
2. 适用范围
3. 职责
3.1 开发部门
3.2 开发体系决策层SMG
4. 术语和缩略语
5. 工作程序
5.1《需求分析报告》的编制
5.2《需求分析报告》的评审
5.3《需求分析报告》的更改
6.引用文件
6.1 NP601100《配置管理》
6.2 NW503101《需求分析报告编写规范》
7.质量记录
7.1 NR503100A“需求分析报告评审记录”
1.目的
保证本公司开发的软件产品和软件项目的需求分析活动在受控状态下进行。

在进行软件开发前，明确其应达到的目标，对系统目标做出完整、准确、清晰、具体的要求。

2.适用范围
适用于所有软件项目和/或软件产品。

3.职责
3.1 开发部门：负责编制《需求分析报告》，并参加评审。

3.2开发体系决策层SMG：负责参加评审重大项目的《需求分析报告》，并批准相应
的评审结果。

4.术语和缩略语
本程序采用NQ402100《质量手册》中的术语和缩略语及其定义。

5.工作程序
5.1 《需求分析报告》的编制
5.1.1 需求分析文档可由开发人员编制。

项目软件经理PSM或其指定人员根据调研结
果，编制该项目的需求分析文档即《需求分析报告》和/或《软件功能规格说明书》，
必要时可邀请客户派人员参加编制工作。

5.1.2 《需求分析报告》的内容以满足客户要求或系统所要实现的功能和性能要求为
准，同时还要满足本公司NW503101《需求分析报告编写规范》或《开发计划》
中明确的标准与规程的要求，如有明确的法律、法规、行业标准等规定时，《需
求分析报告》必须遵守相应规定。

5.1.3 若客户已提供《需求分析报告》或具有同等作用的文档，则本公司无须进行《需
求分析报告》的编制。

但在使用前必须进行评审，以确保准确理解客户的需求，
并取得客户的确认。

5.2 《需求分析报告》的评审
5.2.1 《需求分析报告》在提交之前必须进行评审。

根据《开发计划》确定《需求分析
报告》的评审类型。

5.2.2 部门级评审，参加人员可包括项目软件经理PSM、开发部门负责人、相应的开发
人员，由事业部/开发部负责人审批；公司级评审，由开发体系决策层SMG审批。

必要时，可邀请客户参加评审工作。

评审记录由软件配置管理负责人SCML填写
并归档。

5.2.3 评审要求包括以下几方面
1）无歧义性──对每个需求只有一种解释；
2）完整性──包括全部有意义的需求（性能、安全性、可靠性、保密性和专用性等）；
──完整地规定该软件产品和其他软件或硬件产品之间的所有接口
──定义对所有可能出现（合法的和非法的）的数据输入的响应
3）可验证性──描述的每一个需求均可验证；
4）一致性──对各个需求的描述不矛盾；
5）可使用性——满足运行和维护阶段的需要；
6）符合NW503101《需求分析报告编写规范》或《开发计划》中的标准与规程；
7）需求分析中风险的识别及评估。

5.2.4没有通过评审的《需求分析报告》由开发人员负责按照评审意见进行修改，修改
后重新评审。

5.2.5通过评审的《需求分析报告》由开发体系决策层SMG或开发部负责人批准执行，
并由软件配置管理负责人SCML按NP601100《配置管理》程序进行配置管理。

5.2.6通过评审的合同项目《需求分析报告》须经客户确认，确认方式为：客户签字、
e-mail、传真、电话记录等。

5.3 《需求分析报告》的更改
根据客户提出的意见或软件开发过程中需要进行对《需求分析报告》修订时，须
填写NR601100A“更改单”申请更改，经审核批准后方可修改。

6. 引用文件
6.1 NP601100《配置管理》
6.2 NW503101《需求分析报告编写规范》
7. 质量记录
7.1 NR503100A“需求分析报告评审记录”
需求分析报告评审记录
第页/共页
风险评估与控制（需求分析报告评审附页）
1.评估中风险不限于表中已列出的，应依据评审的具体情况增加风险项。

并将各项填写完整。

2.风险描述：描述当前过程中可能发生的风险。

风险发生可能性：风险发生的概率，以百分数表示，为0到1，增量为0.05。

风险级别：风险发生造成损失的严重程度，以0~10级表示，其中10级 为最高级。

风险现值：风险发生可能性与风险级别的乘积。

风险控制措施：预防风险发生的措施。

第 页/共 页。