《需求开发与管理过程》.docx

1、需求开发与管理过程需求开发与管理过程编号文件状态 草稿 正式发布 正在修改当前版本V1.0修 订日期2007-11-21审 核日期批 准日期发布日期生效日期 修订历史记录 A - 增加 M - 修订 D - 删除变更版本号日期变更类型（A*M*D）修改人摘 要备注1目的2定义需求开发与管理过程，为需求开发及跟踪提供有效的流程和方法。3适用范围44.1机构4.2技术部门、CCB及质量部门。4.3业务4.4提供需求工程的过程标准。5名词术语6RDM（Request Development and Management）：需求开发与管理； SRS(Software Requirement Speci

2、fication)：软件需求规格说明书； URS（User Requirement Specification）：用户需求说明书； 客户(Customer)：开发产品订单的付费方； 最终用户(End User)：最终真正操作软件的用户； 用户需求：指直接来自于客户或者用户的原始需求； 软件需求：指对用户需求进行需求分析和开发之后生成的对于软件产品开发的需求； 项目的级别分为三类， A类、B类、C类；A类项目：一般开发周期长（超过6个月）、人员多（超过6个人）、费用高、或对公司利益影响大的项目属于A类项目；B类项目：开发周期为26个月、人员36个、对公司利益影响比较大的项目属于B类项目；C类项目

3、：对于开发周期短（少于2个月）、投入人员少（少于3人），或对公司利益影响较小的项目大多数的情况下可确定为C类项目，C类项目的风险通常比较小，容易控制。 CCB(Change Control Board)：变更控制委员会。CCB的组长一般为适用机构的领导，成员一般为质量部门经理及适用机构领导制定的某些特定人员，对于B类项目，CCB可直接由部门的经理担任组长，由质量部门经理、专家、开发人员担任组员； 高层经理：项目经理的直接主管，如各事业部的部门经理、技术总监等。7概述8项目在工程活动的开始，首先要进行需求开发。后续所有的工程活动，包括设计、实现、测试均是根据需求展开的，所以需求开发的重要程度是最

4、高的，而由于需求的抽象性，需求开发人员（系统分析员）不仅需要有过硬的专业知识，而且要具备较强的交流、沟通能力，所以需求开发也是最难的。任何项目，需求在整个工程开发过程中必定会发生变化，因此对需求变更的控制，即需求管理必不可少。9过程定义1010.1需求开发与管理流程图10.210.35.1.1角色与职责 角色职责需求分析员1、进行需求调查及需求分析；2、3、撰写用户需求说明书，软件需求规格说明书。项目经理1、需求跟踪；2、3、提交需求变更申请；4、5、组织需求评审。高层经理1、评审及确认需求。CCB1、审批需求变更申请。客户1、需求确认；2、提交需求变更申请；3、配合软件需求开发。5.1.2入

5、口准则 项目已经启动；5.1.3输入 项目计划5.1.4过程活动 1)、用户需求调查获取用户（客户和最终用户）的需求信息。调查需求的方式包括：与用户交谈，向用户提问题参观用户的工作流程，观察用户的操作向用户群体发调查问卷需求讨论会与同行专家交谈，听取他们的意见利用原型法分析已经存在的同类软件产品，提取需求从行业标准、规则中提取需求从Internet上搜查相关资料在需求调查过程中形成用户需求调查报告，最后整理形成用户需求说明书，用户需求说明书要尽最大努力使搜集到的需求正确无误的反映用户的真实意愿。2）、评审用户需求说明书 项目经理组织对用户需求说明书进行正式评审。3）、确认用户需求说明书 项目经

6、理将评审通过的用户需求说明书提交给客户（或客户代表）进行确认。4）、对用户需求分析及定义需求分析员对搜集到的用户需求进行分析细化，以便产生详细的软件需求。需求分析的主要方法有：问答分析法。常见的问题包括： 需求是否存在二义性 需求文档上下文是否有矛盾 需求是否完备 需求是必要的吗 需求可实现吗 需求可验证吗 需求的优先级确定了吗结构化分析方法。结构化分析方法的主要特点是“自顶向下、逐层分解”，它把系统看作一个过程的集合体，利用图形等半形式化的描述方式表达需求，对问题进行分析。基于用例的分析方法。用例是由一组用例实例组成的，用例实例也称为“使用场景”，是用户使用系统的一个实际的、特定场景。用例是

7、应用程序开发中的一个关键技术，主要用来捕获系统的高层次（High Level）用户功能性需求。用例分析技术是一种需求合成技术，它利用现有的需求获取技术从客户、原有系统、文档中找到需求，记录下来，然后从这些零散的需求、特性中进行整理、提炼，从而建立用例模型。同时需求分析人员应确定每个需求的优先级，级别分别为：高、中、低。优先级的定义有利于帮助项目组在项目的范围、进度、资源、预算等相关制约因素之间产生冲突时，能够正确地对需求实现的范围或实现的优先程度做出取舍。一个实现这种权衡的方法是：当接受一个新的高优先级的需求或者其它项目环境变化时，删除低优先级的需求，或者把它们推迟到下一版本中去实现。（具体优

8、先级评价标准参考：iASPEC-SP-RDM-G01 需求开发与管理指南）在对需求进行分析和定义时，需求分析员同时撰写软件需求规格说明书。其内容主要包括：产品介绍描述用户群体的特征定义软件的范围需求的优先级别阐述软件应当遵循的标准和规范定义软件中的角色定义软件的功能性需求定义软件的非功能性需求，如用户需求、软硬件环境、质量等需求5）、评审软件需求规格说明书项目经理组织对软件需求规格说明书进行正式评审。如果是需求说明书变更后的评审，变更范围包括用户需求说明书和软件需求规格说明书，那么此次评审需要对两个文档进行评审。6）、需求跟踪当用户需求说明书、软件需求规格说明书通过评审并且用户需求说明书客户确

9、认之后，需求开发人员要依据其编制需求跟踪矩阵。随着软件设计、编码、以及测试开发的不断推进，各个阶段的负责人员在各个阶段产品形成时，将相关的信息填入需求跟踪矩阵，建立与维护“需求文档设计文档代码测试用例”之间的一致性，使阶段工作产品与需求形成对应关系。对于已纳入需求跟踪矩阵的相关工作产品产生的变更，则由需求跟踪矩阵的维护人员（项目配置管理员）在每次变更完成后根据变更修改需求跟踪矩阵的对应关系，在每个里程碑时由项目经理指定人员负责对跟踪矩阵的完整、正确、一致性进行确认。7）、需求变更申请项目组外的需求变更由变更申请人向项目组提出，如由客户经理提交需求变更申请单给项目经理；项目组内部的需求变更，由项

10、目经理提交需求变更申请单。具体的变更流程请参考“变更控制与管理”过程域。8）、审批需求变更申请 CCB进行需求变更申请的审批。9）、变更需求文档 需求分析员根据CCB确认的变更方案对用户需求说明书和软件需求规格说明书进行变更处理；项目经理要进行评审及确认变更需求。模板参见“变更控制与管理”过程域的变更单模板。5.1.5输出 用户需求说明书；软件需求规格说明书；需求跟踪矩阵；需求变更申请单；5.1.6出口准则 项目已结项；5.1.7过程度量 1）度量人员对以下数据进行度量工作量；进度；需求变更的次数；用户需求说明书、软件需求规格说明书的规模；5.1.8确认与验证 QA对需求开发与管理过程及其产生

11、的产品的规范性进行检查；项目经理对需求开发与管理过程进行监督，组织对产生的产品进行审查；高层经理及客户对用户需求说明书进行确认；CCB对需求变更申请进行审批；11规程12无13指南14IASPEC-SP-RDM-G01 需求开发与管理指南15标准与规范16IASPEC-SP-RDM-C01需求开发与管理检查单17裁剪指南18 9.1用户以规范形式提供了用户需求说明书的情况下可裁剪用户需求调查活动；9.2当需求比较简单或需求调研工期比较短的情况下可裁剪用户需求调查报告；。9.3对于非合同项目用户需求说明书可以裁减，直接书写软件需求规格说明书19模板与表格2010.1 IASPEC-SP- RDM

12、 -T01 用户需求调查报告模板10.2 IASPEC-SP- RDM -T02 用户需求说明书模板10.3 IASPEC-SP- RDM -T03 软件需求规格说明书模板10.4 IASPEC-SP- RDM -T04 软件需求跟踪矩阵表单模板21实施指导22“需求开发与管理”是CMMI中的工程类过程。以下是对“需求开发与管理”过程实施时的进一步指导说明：1）、管理配置项对“需求开发与管理”过程产生的所有有价值的文档应纳入配置管理的适当层次。主要文档示例如下：用户需求调查报告用户需求说明书软件需求规格说明书需求跟踪矩阵需求变更申请单2）、培训人员组织应该对所有或部分参与“需求开发与管理”过程的相关人员进行培训。主要培训专题示例如下：需求分析方法3）、使项目干系人适时介入对于需求调查的用户需求要得到所有项目干系人的共同理解和承诺。4）、QA根据计划和控制“需求开发与管理”过程，并且采取适当的纠正措施。5）、项目经理在执行“需求开发与管理”过程中，应注意收集对过程的改进建议，并提交给组织EPG。 6)、评审及确认需求时，如客户及最终用户纳入存在困难，可以在征求高层经理的同意下，由高层经理代表客户需求，其他指定人员代表最终用户需求进行评审。