需求开发与管理过程

1、版本：V1.3文 档DCFS-REQ-P-01等 级作者EPG 小组最后修改日期2006-01-18审 核人最后日期2007-1-18批 准人最后批准日期2007-1-18修订日期版本修订说明修订人2006-6-10V1.0创建领2006-8-5V1.14.2 增加了架构设计内容；4.5 增加了需求矩阵的状态。领2006-11-3V1.22 角色职责增加了 质量经理4.1 需求获取增加了文档的说明针对不同类型项目，需求获取管理方式调整2007-1-18V1.3需求阶段需要输出部分系统测试用例 强调了需求开发和技术架构选择的交互过程EPG 小组目 录1导言11.1目的1范围1术语定义11.21.

2、32主要角色及职责13准则24过程描述24.1需求获取和识别24.2分析并确定系统架构和需求34.3评审需求和架构设计44.4需求变更管理44.5需求. 44.5.14.5.24.5.34.5.44.5.54.5.64.5.7需求分析阶段的需求设计阶段的需求编码阶段的需求集成测试阶段的需求系统测试阶段的需求发布阶段的需求.5.5.5.5.5.6需求的验证6出口准则656输出6工具与方法678剪裁指南6相关文档69第I 页1导言1.1 目的定义需求管理过程的目的是为项目组控制和需求提供依据，从而保证项目范围变化是可控的。1.2 范围本过程适用与西安研发中心所有项目。1.3 术语定义客户：由于研发

3、项目类型不同，对客户的定义和理解如下：对于客户化子项目，客户是指客户项目组和项目总监。对于产品研发项目，客户是指公司解决方案部的产品经理。CCB：变更控制，负责变更的控制管理，评审和批准变更申请。2主要角色及职责第 1 页角色名称职责描述项目经理参与对工作说明书、客户业务需求或产品需求定义书的评审；负责将需求获取、识别和分析的工作分配给项目组；负责对项目组需求变更的控制和批准；负责或指定相关负责项目的需求。架构师参与需求获取、识别和分析的活动；负责组织需求组完成需求分析工作；协助项目经理进行需求变更的技术评审并把关技术影响；参与 CCB 的工作。需求分析组参与工作说明书的评审确定用户的业务需求

4、并搜集掌握相关的进行需求分析（含功能需求和性能需求） 编写需求规格说明书并参与有关的评审执行需求变更并参与相关的评审在得到 CCB的情况下，修改需求规格说明书设计组参与需求规格说明书的评审，从设计角度提出意见；负责需求矩阵中设计部分的项。测试组参与需求规格说明书的评审，从需求的可验证性提出评审意见；3准则项目立项完成，工作说明书和项目文档评审通过。根据不同的项目类型设置不同的进入条件：4过程描述4.1 需求获取和识别需求获取是为了明确用户业务系统或产品的目标和边界。对于不同的项目类型，需求获取的方式也不同：需求获取和识别的具体子活动有：收集并了解项目售前的文档，了解项目背景；准备需求调研计划、

5、调研提纲、原型等；与用户交流和访谈，采用调研提纲和原型的方式来获取用户的需求，收集用户的与项目相关的业务需求、技术要求、数据、报表等资料；整理调研和访谈，并将反馈客户确认和签署；根据调研结果整理用户的业务需求说明书并通过评审，获得客户的确认；对于产品研发项目，从产品经理获得产品需求说明书或产品。需求获取和识别过程主要文档模板使用说明：用户需求说明书：用于 客户化项目，最原始的用户需求。第 2 页项目类型需求获取途径需求获取方法选择客户化项目从客户项目组持续地取得用户需求。面谈法，问卷法，业务文档研究法，生产现场观察法产品研发项目由解决方案部组织公司架构组进行并整理，评审通过后交与项目组需求专题

6、会，法预研项目可以从潜在客户那里挖掘产品需求法项目类型进入条件客户化子项目研发中心与客户项目组初步达成分包意向产品研发项目解决方案部提出产品的完整需求预研项目立项完成负责需求矩阵中测试部分的项。质量经理组织对需求规格说明书的评审，并对评审出的缺陷进行；负责对需求的一致性和完整性进行验证QA负责对需求开发、需求管理、架构设计活动的审计产品定义说明书：用于 产品研发项目，解决方案部确定的产品需求定义。4.2分析并确定系统架构和需求把用户业务需求或者产品需求转化成系统需求，并与项目开发技术方案选择紧密结合，多次反馈、交叉实施，重点要解决架构设计和构件获取类型选择问题。具体包括的过程如下：1)通过对用

7、户业务需求或产品功能需求的分析，根据工作说明书中定义的项目的范围以及项目的前提条件和约束条件（硬件和环境、系统的非功能性需求），确定系统的总体架构，总体架构的内容包括：a)系统的体系结构；b)系统的部署视图、用例视图、逻辑视图、实施视图；c)设计机制；d)系统的集成架构；e)架构质量；f)对系统采用的体系结构、的方案或新的技术需要设计两以上的方案。g)新技术的原型开发及验证，并根据结果反馈架构设计。2)分配并确定的功能性需求；3)细化分配的需求，具体内容包括：a)根据用户使用的场景和业务流程，描述系统的功能需求；b)根据获取的原始需求分析和挖掘系统的潜在需求和隐含需求；c)根据系统分解结构确定

8、的子系统、模块之间的接口；d)根据业务系统边界或者产品系统边界，确定与外部系统的接口；e)如果需要，确定的用户界面。4)根据业务的性能要求或产品的性能要求，以及其他操作、安全、法律等方面的要求，确定的非功能性需求；5)在分析需求的同时，需要识别系统需要的构件，构件的来源主要有五种方式：自行开发构件；委托开发构件；第 3 页复用已有的构件；采购的构件；采用开源免费的构件。项目经理要组织架构师和技术分析项目构件的需求，并针对项目的情况决策系统构件的策略（参照决策分析过程）。项目组在需求文档或架构设计文档标识出构件的开发策略。对于构件采购参照采购管理过程。6)建立系统完整的、一致的术语和词汇表；7)

9、确保需求正确、完整、一致、无歧义、可验证、可。根据对用户业务和系统架构的分析，完成需求规格说明书和系统架构设计说明书，并根据系统功能，编写部分系统测试用例。4.3 评审需求和架构设计需求规格说明书、架构设计说明书完成后须经过评审，项目经理或架构师负责组织评审，评审要求需求提出者（客户、方案经理、用户代表等）、项目总监、设计、测试经理、测试工程师、质量经理等参加。对于客户项目，需求需要客户签字确认；对于产品研发项目需要方案经理签字。对于化开发子项目, 需要由事业部填写化开发子项目需求确认单，并进行确认。4.4 需求变更管理需求变更管理参见变更管理过程。4.5 需求保证需求被正确地和完整地实现，保

10、证需求、设计、代码和测试用例之间一致性，当产出物中发生变更时，需要针对需求矩阵分析变更的影响和应该变更的其他的配置项。需求的内容：1)基线化的用户需求或产品需求必须到它的需求，设计，源代码，测试用例。2)采用用例驱动的方法开发时，用例必须被到活动图，类图，交互图以及类的代码实现和测试用例。第 4 页需求矩阵状态说明：UR：未完成需求规格化；R：已完成需求规格化；UD：未完成设计；D：已完成设计；ST：系统测试已完成；UC：未完成编码；C：已完成编码；IT：已完成集成测试。4.5.1 需求分析阶段的需求需求分析组在需求矩阵中建立客户需求和需求的对应关系，将已经完成需求分析的业务需求状态标识为“R

11、”， 未完成需求分析的业务需求状态标识为“UR”。4.5.2 设计阶段的需求工程组在需求矩阵中建立需求和设计项的对应关系，将已经完成设计的需求状态标识为“D”，未完成设计的需求状态标识为“UD”。4.5.3 编码阶段的需求工程组在需求矩阵中建立设计项和代码项的对应关系，将已经完成编码（通过自测）设计状态标识为“C”， 未完成编码（通过自测）的设计状态标识为“UC”。4.5.4 集成测试阶段的需求测试组在需求矩阵中建立设计项和集成测试用例的对应关系，将通过集成测试的设计项状态标识为“IT”。4.5.5 系统测试阶段的需求测试组在需求矩阵中建立需求项和系统测试用例的对应关系，将通过系统测试的需求项状态标识为“ST”。第 5 页4.5.6 发布阶段的需求工程组对需求和验证项的对应关系进行。4.5.7 需求的验证需求矩阵要经过评审，保证被内容之间的一致性和完整性。质量经理负责对需求的一致性和完整性进行