XXX公司-需求开发和管理规程

XXX公司软件过程体系需求开发和管理规程编制人：***

审核人：***

批准人：***CMMI部1/12

文档修改/批准记录版本修改/批准日期内容修订人批准人目录TOC\o"1-5"\h\z需求开发和管理规程 1\o"CurrentDocument"1概述 3\o"CurrentDocument"编制目的 4\o"CurrentDocument"适用范围 4\o"CurrentDocument"介绍 4\o"CurrentDocument"需求开发 4\o"CurrentDocument"需求跟踪 4\o"CurrentDocument"需求变更 52/12TOC\o"1-5"\h\z\o"CurrentDocument"2术语及定义 5\o"CurrentDocument"3方针 5\o"CurrentDocument"4角色与职责 5\o"CurrentDocument"5工作流程 6\o"CurrentDocument"启动准则 6\o"CurrentDocument"输入 6\o"CurrentDocument"流程图 6\o"CurrentDocument"主要步骤 9\o"CurrentDocument"步骤1编制、同行审批《需求规格说明书》（SRS） 9\o"CurrentDocument"步骤2需求变更申请、评审和确认 10\o"CurrentDocument"步骤3《需求跟踪表》的维护和踉踪 11\o"CurrentDocument"输出 11\o"CurrentDocument"结束准则 11\o"CurrentDocument"6度量 11\o"CurrentDocument"7附加说明 11\o"CurrentDocument"8裁剪说明 12\o"CurrentDocument"9相关文件 121概述对项目的需求进行管理，要从项目开始时客户最初的想法和陈述，一直到最终的系统实现满足客户的要求为止，在项目整个生命周期内对项目的需求进行管理和跟踪，使客户和项目团队就系统不断变化的需求进行确认并保持一致意见；根据CMMI标准和要求，公司目前的需求相关活动分为以下三个方面：•需求开发•需求跟踪3/12需求变更编制目的本规程给出需求开发阶段活动的目标、方针、流程以及一些常用方法，以及在产品生命周期中需求管理活动的目标、方针、流程及一些常用方法。最终生成需求规格说明书，作为项目开发计划以及后续项目工程和管理活动的基础。适用范围本文档适用于公司的所有项目。1-3介绍需求开发客户需求是软件产品必须完成的工作以及必须具备的品质。需求开发的目的在于通过科学的方法和规范的过程去收集、识别和整理出有价值的需求，并且保证这些需求能够满足用户对于产品的期望；需求的开发过程，是从最初的客户的一个想法或陈述，逐渐演变成一个非常具体、明确的需求定义，是一个渐进细化的过程，可分为三个层次：1、项目初步需求，作为项目附件和开发任务书，一般来源于合同的功能需求。主要是描述客户最初的想法和要求，可作为项目进行售前技术交流的基础或项目可行性分析报告。此文档可由客户、售前技术支持人员、方案预研人员完成。《客户访谈记录》2、客户需求，是项目人员对客户提出的需求进行收集整理的结果，对于不明确的需求，还需要通过需求提问单进行专门的需求调研，与客户的业务人员进行交流，最后整理形成的结果，一般采用业务语言描述，是进行需求分析的基础。可以作为项目商务报价的基础。《需求收集汇总表》3、需求规格说明书（以下简称SRS），是经过需求分析工程师对客户需求进行分析理解，并文档化的结果，这是需求最终分解和细化的文档，需要经过客户确认的，作为项目进行设计和开发的基础，也是项目最终测试验收的依据。 《需求规格说明书》需求跟踪4/12需求跟踪的目的是检查遗漏的需求；检查出不必要的设计/程序模块/测试项目；快速、准确地判断出需求变更所影响的范围。需求跟踪主要关注两个方面：•需求实现状态的跟踪；•跟踪需求在后续工程阶段的实现对照。一般由项目经理制定专人对《需求跟踪表》进行维护。1.3.3需求变更需求变更控制指在需求定义完成后，管理和控制对成为基线的需求项的变更，使需求项的变更是受控的、可追溯的。2术语及定义客户需求：通过引导、分析、验证，以及沟通客户的需要、期望、限制和接口界面，以获取客户的需求，并对这些需求达成共识，形成客户需求；客户需求一般以业务术语描述。不同的项目中，客户需求除软件需求外，还会包括硬件需求等，本规程需求主要指软件需求即指描述客户在软件方面需求的工作产品。产品需求：采用能够用于设计决策的技术语言描述客户需求；产品需求可以进一步细化为产品组件需求。3方针.每个开发类项目均应通过需求的收集、识别和整理，以文档化的形式给出需求规格说明书。.每项需求的描述，都应确保正确、必要、完备、无歧义、可验证和可追踪。.需求规格说明书，经同行评审并审批后，作为项目开发计划以及后续项目工程和管理活动的基础。.项目组必须跟踪需求的实现状态，定期向客户和项目上级领导汇报。4角色与职责.项目经理：负责组织需求工程师进行需求开发；在项目的整个生命周期内，自始至终负责需求管理。负责组织确认及评审《需求收集汇总表》、《需求规格说明书》、《需求跟踪表》，并对评审结果的后续处理及需求开发过程中的不确定项进行跟踪管理。5/12.需求工程师：在项目经理的领导下，收集和分析客户需求、编制《客户需求》、《需求规格说明书》，并确保上述工作产品与客户理解一致；.测试工程师：理解客户的客户需求及需求规格说明书，并且参加需求同行评审，确认需求的可测性。.项目组成员：理解客户需求及需求规格说明书，并且参加需求同行评审。.CM工程师：负责需求开发阶段的配置管理工作。.QA工程师：验证客户需求的收集、识别、整理、变更以及其评审活动与规程的符合性。.项目上级主管：负责批准《需求规格说明书》。.客户代表：确认《需求收集汇总表》、《需求规格说明书》。5工作流程启动准则需求工程师和相关人员到位，职责分工明确。相关人员接受过必要的培训。已有必要的输入。输入《客户访谈记录》，《需求收集汇总表》模板，《需求规格说明书》模板，《需求跟踪表》模板，《需求变更申请》模板，《变更控制表》模板。流程图输入流程图输出6/12

需求开发：《需求收集汇总表》模板需求开发：《需求收集汇总表》模板《需求规格说明书》模板需求管理：《需求跟踪表》模板《需求变更申请表》模板《需求收集汇总表》《需求规格说明书》需求管理：《需求跟踪表》《需求变更申请表》《变更控制表》1、收集客户需求需求工程师对客户提出的需要、期望、限制及界面进行收集整理，形成与客户理解一致的文档化的《需求收集汇总表》。项目经理根据需要组织对《需求收7/12集汇总表》的同行评审。对于合同项目《需求收集汇总表》必须经过客户确定；对于产品项目《需求收集汇总表》可裁剪。2、需求分析、需求确认、编写《需求规格说明书》（SRS）需求工程师结合技术解决方案，对客户需求进行分析，确保需求的充分性与必要性，明确项目产品的边界，确定接口界面需求。需求工程师编写《需求规格说明书》，将客户全部需求定义下来。3、需求规格说明书同行评审项目经理组织对SRS在项目组内部进行内部评审，对于评审中出现的问题反复的修正，如果需要和客户进行确认，需要和客户进行不断的沟通，提问，直至问题全部解决，内部评审确认通过，然后准备召集正式的需求评审。4、需求规格说明书确认对于合同项目，项目经理在评审通过后，需要将SRS提交客户代表，并取得客户的确认；对于产品项目，由项目经理确认；5、批准需求规格说明书经确认后的需求规格说明书，需要提交项目上级领导批准进行后续项目策划与开发。6、建立需求基线SRS通过批准后，提交至配置管理人员，建立需求基线。对已经基线化的需求进行变更，必须通地需求变更相关流程。7、建立需求跟踪矩阵在需求基线化后，项目经理根据SRS建立需求跟踪矩阵。项目经理指派专人对《需求跟踪表》进行维护和跟踪。8、分配需求跟踪任务项目经理根据项目组成员情况，分配需求跟踪任务，以便在项目后续工程阶段能及时跟踪了解需求状态。9、定期更新需求状态，并进行分析统计承担需求跟踪任务的项目组成员，应每周跟踪并更新所负责的需求状态。当分配给产品或产品组件的需求进行变动时，项目经理需要维护需求跟踪矩阵结构，重新明确跟踪任务。8/12项目经理定期统计分析需求项的状态和趋势，向客户及项目上级领导报告。10、在建立了需求基线后提出的所有需求变更都必须提出书面申请。11、编写完成需求变更申请，需要将申请提交客户代表，取得客户的确认；对于产品项目，由项目经理确认。12、项目经理组织对变更申请在项目组内部进行内部评审，对于评审中出现的问题反复的修正，如果需要和客户进行确认，需要和客户进行不断的沟通，提问，直至问题全部解决，内部评审确认通过，如果大变更则再组织进行正式的变更申请。13、根据变更，分配需求变更人员及任务。14、变更经过评审后，进入基线配置管理流程、修改基线，重新确定新的需求基线。主要步骤步骤1编制、同行审批《需求规格说明书》（SRS）1、编制《需求规格说明书》1）需求工程师结合技术解决方案，对客户需求进行分析，确保需求的充分性与必要性，明确项目产品的边界，确定接口界面需求。2）对于不明确的需求，还需要进行专门的需求调研，需求工程师要与客户的业务人员进行沟通交流，通过和客户的不断沟通，将客户的隐含需求和定义不明确的需求确定下来；对于客户不同业务人员之间有冲突的需求进行协调平衡；3）需求工程师编写《需求规格说明书》，将客户全部需求定义下来。《需求规格说明书》应准确描述产品必须提供的所有功能、性能以及其他应满足的约束条件；结合解决方案对功能进行逻辑分组，标识需求之间相互关系；识别项目中的关键需求，标识需求优先级。一般情况下，对于高版本的产品开发，必须兼容低版本的需求，对于不再支持的需求，应该给出明确的理由并形成文档。在需求分析时，还要注意本项目是否可以复用已有系统，以及本项目产品是否存在被其他系统复用的可能性。S不仅是集成测试、系统测试和验收测试以及编写用户文档的基础，也是项目策划、9/12设计和编码的基础；除了设计和实现时的约束及初步的产品与产品组件划分之外，《需求规格说明书》不包括设计、编码、测试和工程管理的细节。2、审批《需求规格说明书》1）项目经理组织对《需求规格说明书》在项目组内部进行内部评审，对于评审中出现的问题反复的修正，如果需要和客户进行确认，需要和客户进行不断的沟通，提问，直至问题全部解决，内部评审确认通过，然后准备召集正式的需求评审。2）项目经理根据需求开发阶段计划，分次组织内部同行评审。并在需求分析结束后组织对SRS的正式同行评审，正式评审应按照公司的同行评审过程执行，需求评审的参加人员至少应包括：项目管理人员、系统工程组、系统测试组、QA、CM，以及客户代表，完成后要填写评审报告，通知相关人员。步骤2需求变更申请、评审和确认需求变更控制要经过变更申请、变更评估、决策、回复这四大步骤。如果变更被接受，还要增加实施变更和验证两个步骤，有时还会有取消变更的步骤。针对变更控制流程，有以下几点：.建立需求基线后,每次变更并经过评审后，都要重新确定新的需求基线。.在建立了需求基线后提出的所有变更都必须遵循以上流程图的变更部分进行控制。.项目成立时应同时成立项目变更控制委员会或相关职能的类似组织，负责裁定接受哪些变更。组织中的成员由项目所涉及的多方人员共同组成，包括用户方和开发方的决策人员在内。.需求变更一定要先申请然后再评估，最后经过与变更大小相当级别的评审确认。.需求变更后，受影响的软件计划、产品、活动都要进行相应的变更，以保持和更新的需求一致。.妥善保存变更产生的相关文档。7、通过《变更控制表》跟踪整个变更过程，直至变更关闭。10/12步骤3《需求跟踪表》的维护和跟踪《需求跟踪表》主要是对客