需求工程规范

1、需求工程规范 0.1版 目录1.概要11.1.目的11.2.范围11.3.术语与缩略语11.4.角色与职责12.过程描述22.1.过程介绍22.2.立项22.2.1. 准入条件22.2.2. 输入22.2.3. 具体步骤32.2.4. 输出42.2.5. 准出条件42.2.6. 裁剪42.3.需求分析42.3.1. 准入条件42.3.2. 输入42.3.3. 具体步骤52.3.4. 输出62.3.5. 准出条件62.3.6. 裁剪62.4.需求跟踪与管理62.4.1. 准入条件62.4.2. 输入62.4.3. 具体步骤62.4.4. 输出72.4.5. 准出条件72.4.6. 裁剪73.实施

2、建议74.其它74.1.需求调研的六边形法则71. 概要1.1. 目的本文档用以规范本公司的需求工程活动。1.2. 范围本文档适用本公司的所有项目的需求活动。1.3. 术语与缩略语术语/缩略语解释客户需求客户按照自己的理解提出的需求。产品需求根据客户需求进行分析得到的需求，面向技术人员使用。质量属性满足质量要求的一系列要求。1.4. 角色与职责角色职责2. 过程描述2.1. 过程介绍立项需求分析需求跟踪与管理获取客户需求估算可行性分析项目建立项目组成立建立需求跟踪矩阵计划整理现有流程设计新系统评审设计整体架构设计性能开发界面原型考虑约束复用/采购组件编制规格书评审客户书面确认项目计划编制形成需

3、求基线设计接口维护需求跟踪矩阵二次估算2.2. 立项2.2.1. 准入条件无。2.2.2. 输入客户初始意向。2.2.3. 具体步骤2.2.3.1. 获取客户需求根据客户初始意向需求，按照以下流程处理：研讨需求（业务部、研发部）预习提问（研发部）交流达成一致计划（PM）调研内部评审达成一致结束需求详尽需求不详尽需求详尽的标准：可以使用目前的需求进行估算。研发部经理确定PM人选，由PM负责需求调研工作，PM成立需求调研小组，确定组长和组员。（一） 需求详尽1） 预习提问由于客户提供的需求比较详尽，PM组织研发部内的技术骨干等相关人员预习需求，并对不理解的需求点提出疑问。2） 交流对于不理解的需求

4、点，PM通过业务部与客户方接口人直接交流，解决疑问。3） 达成一致最终双方对于需求的理解达成一致，并进行书面确认。（二） 需求不详尽1） 计划：PM编制调研计划，准备需求调研报告模板、调查表，计划、模板、调查表需要经过研发部、业务部和测试部评审。2） 调研PM安排需求调研小组与客户方接口人建立联系，使用访谈、参观、调查表等不同方式综合运用对客户进行调研。需求调研小组获取相关的资料和数据后，组长按照模板编制需求调研报告。3） 内部评审PM组织评审会议评审需求调研报告，参加人员：需求调研小组、研发部经理、业务部经理、测试人员、QA。4） 达成一致PM将评审通过后的需求调研报告发给客户，并与客户书面

5、上达成一致。2.2.3.2. 估算参考项目估算指南。本活动工作产品为估算表。2.2.3.3. 可行性分析报告研发部根据估算表进行可行性分析，出具一份可行性分析报告提交给业务部。2.2.3.4. 项目建立业务部参考可行性分析报告安排后续商务活动，并通知研发部是否立项。2.2.3.5. 项目组成立业务部确定要立项，需要通知研发部。业务部在与客户签订合同前要将影响项目的相关事项告知研发部。研发部经理安排PM成立项目组。PM配置项目所需资源，编写项目计划日程表。2.2.4. 输出客户需求调研报告需求调查表估算表可行性分析报告项目计划日程表2.2.5. 准出条件业务部与客户签订商务合同。2.2.6. 裁

6、剪编号活动标题裁剪结果裁剪条件备注2.3. 需求分析2.3.1. 准入条件项目已经立项。2.3.2. 输入客户需求调研报告客户提供资料客户提供数据决策分析指南2.3.3. 具体步骤2.3.3.1. 计划PM开始编写项目计划书，分析各阶段详细日程及资源安排，初期完成（3天内）。同时PM确定各个角色人员（如CM），分配人员任务安排。如果原先的需求调研小组没有人员变动，则转变为需求分析小组；如有人员变动，PM需要重新确定组长和组员。2.3.3.2. 整理现有业务流程需求分析小组首先整理客户现有的业务流程，必要时使用活动图进行描述。2.3.3.3. 设计新系统需求分析小组根据需求调研结果设计新系统功能

7、定义与业务流程，使用用例图描述。需求分析小组组长负责编制需求规格书初稿，主要内容为现有业务流程和新系统业务流程。2.3.3.4. 评审PM组织评审会议评审需求规格书初稿，参加人员：需求分析小组、开发人员、测试人员、客户、研发部经理、QA。2.3.3.5. 设计整体架构评审通过后，PM组织几个技术专家负责设计整体架构，每个技术专家独立设计一套方案。主要包括系统部署、子系统划分、基础平台、关键技术、开发语言、DB选型等内容。多个方案完成后，PM组织决策会议，研发部经理、测试部经理、业务部经理及技术骨干等参加决策会议，评价多个方案，最终确定一个方案为采纳方案，同时保留一个方案为备用方案。设计采纳方案

8、的技术专家由研发部任命为该项目技术经理，负责后续技术架构、设计等工作。PM负责编写决策分析计划、报告，使用决策评价表对待决策事项进行评价，具体流程参加决策分析指南。2.3.3.6. 设计性能需求分析小组和技术经理考虑系统的质量属性，设计系统的性能。2.3.3.7. 设计接口需求分析小组和技术经理设计接口。2.3.3.8. 考虑约束需求分析小组和技术经理在设计时需要考虑约束。2.3.3.9. 开发界面原型美工协助需求分析小组设计开发界面原型，并与客户确认。2.3.3.10. 确定复用/采购组件PM和技术经理确定是否复用代码、采购组件或使用开源软件，在必要时举行决策会议决策采购组件或使用开源组件。

9、如需决策会议，PM负责编写决策分析计划、报告，使用决策评价表对待决策事项进行评价，具体流程参加决策分析指南。2.3.3.11. 编制规格书技术经理根据模板编制需求规格书，必要时增加活动图附件。2.3.3.12. 评审PM组织评审会议评审需求规格书，参加人员：需求分析小组、技术经理、研发部经理、业务部经理、测试部经理、技术骨干、QA（、总经理）。2.3.3.13. 客户书面确认PM将评审后的需求规格书发送给业务部经理，业务部经理根据商务合同安排，将需求规格书发送给客户，并书面上达成一致。2.3.3.14. 二次估算参考项目估算指南。本活动工作产品为估算表。重新进行估算，以便于PM制定项目计划书。

10、2.3.3.15. 项目计划编制PM在需求规格书评审通过后要完成项目计划书。PM组织里程碑会议，同时评审项目计划书，参加人员：项目组全体、研发部经理、测试部经理、业务部经理、QA（、总经理）。PM提交里程碑报告发送与会全体，抄送总经理。2.3.3.16. 形成需求基线项目CM参考配置管理规范，建立需求基线。2.3.4. 输出需求规格书估算表项目计划书活动图里程碑报告决策分析计划、报告决策评价表2.3.5. 准出条件已经形成需求基线。2.3.6. 裁剪编号活动标题裁剪结果裁剪条件备注.2整理现有业务流程不做客户对自身现有业务流程不清晰，或无法获取现有业务流程。.10确定复用/采购组件不做本次项目

11、属于新业务领域拓展或对于新组件不熟悉。2.4. 需求跟踪与管理2.4.1. 准入条件需求基线已经形成。2.4.2. 输入需求基线文档。2.4.3. 具体步骤2.4.3.1. 建立需求跟踪矩阵PM需要指定一人负责需求跟踪和管理（以下简称RTM人员）。需求基线形成后，RTM人员开始建立跟踪矩阵之需求跟踪矩阵表。整个生命周期中，建立跟踪矩阵的时机，产品需求依赖客户需求，系统测试用例依赖产品需求，概要设计依赖产品需求，详细设计依赖概要设计。2.4.3.2. 维护需求跟踪矩阵当需求需要变更时，PM要先做变更影响分析，分析本次变更的影响范围。然后使用决策方法决定是否进行变更。如需决策会议，PM负责编写决策分析计划、报告，使用决策评价表对待决策事项进行评价，具体流程参加决策分析指南。进行变更后，PM要安排人员对受到影响的文档进行修改，并经过评审后重新入基线。RTM人员根据修改情况，修改跟踪矩阵之需求跟踪矩阵表。2.4.4. 输出跟踪矩阵之需求跟踪矩阵表决策分析计划、报告决策评价表2.4.5. 准出条件整个项目运行中持续跟踪。2.4.6. 裁剪编号活动标题裁剪结果裁剪条件备注3. 实施建议建议需求跟踪矩阵在形成需求基线后再进行制作，因为工作量较大，需求不稳定时调整较多。4. 其它4.1