需 求 分 析
管 理 控 制 程 序
版 本：0．1版
制定人：CMM组
需求分析程序
1. 目的
对软件产品需求分析活动进行控制，明确《用户需求说明书》的要求
2. 适用范围
适用于公司自主开发产品和合同项目软件部分的用户需求分析活动。
3. 岗位与职责
责任人 | 职责 | 说明 |
项目核心组 | 与用户沟通，进行初期的用户需求调研，形成文档，决定需求是否有必要继续进行； 对需求分析过程中的需求分析人员与用户的关系进行协调； 对需求分析过程中遇到的不明确性进行判断和决策； 形成《需求备忘录》和《用户需求说明书》，向部门负责人提出评审申请。 需求调研和需求评审由产品经理或项目经理或所在的产品部门负责。 建立《需求跟踪记录》。 | |
事业部/开发部负责人 | 对需求分析过程中出现的问题进行指导；按程序文件要求组织对 《用户需求说明书》进行评审。 为项目组指定SQA、配置管理员、测试经理等相关资源 | |
配置管理员 | 《用户需求说明书》评审后，纳入配置管理 | |
SQA | 开始制定《软件质量保证工作计划》，并监督项目核心组的需求分析工作是否符合程序文件的要求，完成《软件需求分析质量报告》 | |
测试经理 | 参与评审 | |
| | |
4. 程序
4.1. 流程图
4.2. 总则
需求活动大致分三个阶段：需求调研、需求分析和需求管理
4.2.1. 需求调研阶段
a. 对自主产品而言，在用户意向明确后，开发部负责人根据产品经理的申请，指定需求分析人员组成用户需求分析小组，由产品经理负责组织开展用户需求调研活动。
b. 对合同类项目而言，在用户意向明确后，开发部负责人根据项目经理的申请，指定需求分析人员组成用户需求分析小组，由项目经理负责组织开展用户需求调研。
c. 此阶段以调查用户需求为主，生成《需求备忘录》。
4.2.2. 需求分析阶段
立项后，项目核心组对需求进行分析研究，细化，由产品经理或者项目经理负责对需求分析过程中的问题进行判断和解决，关键问题或认为有必要时可向公司事业部或开发部负责人汇报和请示。此阶段以分析为主，如遇不确切的需求，仍需进一步调查补充，生成《用户需求说明书》。
4.2.3. 需求管理阶段
评审后的需求文档纳入基线，按配置管理计划进行变更管理（见《配置管理程序》)。
4.3. 用户需求调研应了解的主要内容：
1. 用户的工作流程、相关部门及职责；
2. 用户原有系统的情况；
3. 用户对产品的期望（包括功能，性能，使用方式，平台，交付时间等）;
4. 用户对产品的具体要求（包括各功能的具体含义);
5. 用户业务中与待开发的产品有关的部分；
6. 用户对产品与其生产流程的配合要求；
7. 产品与用户原有系统的接口；
8. 用户对软、硬件平台的限制和要求；
9. 产品的使用人员的技术水平
4.4. 需求调研的要求
在进行前期用户需求调研时，应进行必要的记录并整理保存，形成正式的《需求备忘录》，并经内部审核和评定。产品立项或合同评审时，必须提供正式的《需求备忘录》文档。
4.5. 用户需求说明书
在《需求备忘录》的基础上，用户需求分析小组进行详细的用户需求分析，编写出《用户需求规格说明书》（内容和要求参见模板）。编写时可根据具体的产品情况进行调整。必要时，可在有关章节中引述其它资料作为附件。
4.6. 评审
1. 《用户需求说明书》形成后，需要由需求分析小组向事业部/开发部负责人申请评审，评审过程要求参见《评审控制程序》，最终形成《用户需求说明书评审报告》。
2. 评审结论分为通过、有条件通过和不通过（即取消项目），对于有条件通过，由SQA进行跟踪解决。
3. 评审主要内容：
a. 确定不完整和遗漏的需求
b. 评审需求以确定它们是否：
o 可行、适用于软件实现
o 需求表达清楚、适当
o 彼此一致
o 可测试
c. 需求分析小组成员对有问题的需求给出解释，并进行必要的修改。
d. 开发经理与测试、配置管理、协作部门等方就需求达成一致意见，或协商作出约定。
4.7. 纳入配置管理
《用户需求说明书》评审后应纳入配置管理，按《配置管理程序》进行管理，进入需求管理阶段。
4.8. 需求变更管理
无论是用户原因还是公司自身原因，在需求评审通过后的设计、开发等活动中需要对《用户需求说明书》进行修改时， 应执行《变更管理控制程序》。
