需求管理研究报

TOC\o"1-3"\h\z第8章需求管理 28.1介绍 28.2需求确认 38.2.1目的 38.2.2角色与职责 38.2.3启动准那么 38.2.4输入 38.2.5主要步骤 4[Step1]非正式需求评审 4[Step2]正式需求评审 4[Step3]获取需求承诺 48.2.6输出 48.2.7结束准那么 48.2.8度量 48.3需求跟踪 58.3.1目的 53.3.2角色与职责 53.3.3启动准那么 53.3.4输入 53.3.5主要步骤 5[Step1]建立与维护需求跟踪矩阵 5[Step2]查找不一致 6[Step3]消除不一致 68.3.6输出 68.3.7结束准那么 68.3.8度量 68.4需求变更控制 78.4.1目的 78.4.2角色与职责 78.4.3启动准那么 78.4.4输入 78.4.5主要步骤 7[Step1]需求变更申请 7[Step2]审批需求变更申请 7[Step3]更改需求文档 7[Step4]重新进行需求确认 88.4.6输出 88.4.7结束准那么 88.4.8度量 88.5实施建议 8第8章需求管理需求管理〔RequirementManagement,RM〕的目的在客户与开发方之间建立对需求的共同理解，维护需求与其他工作成果的一致性，并控制需求的变更。需求管理过程域是SPP模型的重要组成局部。本标准阐述了需求管理过程域的三个主要规程：需求确认[SPP-PROC-RM-VALIDATE]需求跟踪[SPP-PROC-RM-TRACKING]需求变更控制[SPP-PROC-RM-CHANGE]上述每个规程的“目标〞、“角色与职责〞、“启动准那么〞、“输入〞、“主要步骤〞、“输出〞、“完成准那么〞和“度量〞均已定义。本标准适用于国内IT企业的软件研发工程。建议用户根据自身情况〔如商业目标、研发实力等〕适当地修改本标准，然后推广使用。8.1介绍我们把所有与需求相关的活动通称为需求工程。需求工程中的活动可分为两大类，一类属于需求开发，另一类属于需求管理。图8-1为需求工程的结构图〔流程见图9-1〕。需求确认需求管理需求分析需求定义需求调查需求开发需求工程需求变更控制需求跟踪需求确认需求管理需求分析需求定义需求调查需求开发需求工程需求变更控制需求跟踪图8-1需求工程结构图需求管理过程域主要有3个规程：需求确认、需求跟踪与需求变更控制。一、需求确认需求确认是指开发方和客户共同对需求文档进行评审，双方对需求达成共识后作出书面承诺，使需求文档具有商业合同效果。二、需求跟踪需求跟踪是指通过比较需求文档与后续工作成果之间的对应关系，建立与维护“需求跟踪矩阵〞，确保产品依据需求文档进行开发。三、需求变更控制需求变更控制是指依据“变更申请－审批－更改－重新确认〞的流程处理需求的变更，确保需求的变更不会失去控制而导致工程发生混乱。需求管理过程域产生的主要文档有：?需求评审报告?，同技术评审报告的模板[SPP-TEMP-TR-REPORT]。?需求跟踪报告?，模板见[SPP-TEMP-RM-TRACKING]。?需求变更控制报告?，模板见[SPP-TEMP-RM-CHANGE]。8.2需求确认8.2.1目的开发方和客户对需求文档如?用户需求说明书?和?产品需求规格说明书?进行评审，并作书面承诺。补充说明：?用户需求说明书?和?产品需求规格说明书?可以分开也可以放在一起进行需求确认，视工程的具体情况而定。8.2.2角色与职责开发方和客户共同组织人员对需求文档如?用户需求说明书?和?产品需求规格说明书?进行评审。开发方负责人〔工程经理〕和客户对需求文档作书面承诺，使之具有商业合同效果。8.2.3启动准那么需求文档如?用户需求说明书?和?产品需求规格说明书?已经完成。8.2.4输入需求文档如?用户需求说明书?和?产品需求规格说明书?。8.2.5主要步骤[Step1]非正式需求评审工程经理先在工程内部组织人员进行非正式的需求评审，以消除明显的错误和分歧。非正式的需求评审方式请参考技术评审过程域的对应规程[SPP-PROC-TR-ITR]。[Step2]正式需求评审工程经理邀请同行专家和用户〔包括客户和最终用户〕一起评审需求文档，尽最大努力使需求文档能够正确无误地反映用户的真实意愿。正式需求评审方式请参考技术评审过程域的对应规程[SPP-PROC-TR-FTR]。[Step3]获取需求承诺 当需求文档通过正式的评审之后，开发方负责人〔工程经理〕和客户对需求文档作书面承诺，使之具有商业合同效果。例如如下： 本需求文档建立在双方对需求的共同理解根底之上，我同意后续的开发工作根据该需求文档开展。如果需求发生变化，我们将按照“需求变更控制规程〞执行。我明白需求的变更将导致双方重新协商本钱、资源和进度等。 甲方负责人签字乙方负责人签字8.2.6输出?需求评审报告?书面的需求承诺8.2.7结束准那么需求文档通过了正式评审，并且获得开发方和客户的书面承诺。8.2.8度量工程经理统计工作量和上述文档的规模8.3需求跟踪8.3.1目的将系统设计、编程、测试等阶段的工作成果与需求文档进行比较，建立与维护“需求文档－设计文档－代码－测试用例〞之间的一致性，确保产品依据需求文档进行开发。3.3.2角色与职责工程经理跟踪需求。3.3.3启动准那么需求文档已经通过正式评审并获得了承诺。系统设计、编程、测试等阶段的工作成果如设计文档、代码、测试用例已经产生。3.3.4输入需求文档设计文档、代码、测试用例等3.3.5主要步骤[Step1]建立与维护需求跟踪矩阵正向跟踪。检查需求文档中的每个需求是否都能在后续工作成果中找到对应点。逆向跟踪。检查设计文档、代码、测试用例等工作成果是否都能在需求文档中找到出处。正向跟踪和逆向跟踪合称为“双向跟踪〞。不管采用何种跟踪方式，都要建立与维护需求跟踪矩阵〔即表格〕。需求跟踪矩阵保存了需求与后续工作成果的对应关系。矩阵单元之间的可能存在“一对一〞、“一对多〞或“多对多〞的关系。由于对应关系比较复杂，最好在表格中加必要的文字解释。表8-1为简单的需求跟踪矩阵格式。当需求文档或后续工作成果发生变更时，要及时更新需求跟踪矩阵。＃需求文档〔版本，日期〕设计文档〔版本，日期〕代码〔版本，日期〕测试用例〔版本，日期〕1标题或标识符，说明标题或标识符，说明代码名称，说明测试用例名称，说明2…………表8-1简单的需求跟踪矩阵格式[Step2]查找不一致使用需求跟踪矩阵的优点是很容易发现需求文档与后续工作成果之间的不一致之处，例如：后续工作成果没有实现需求文档中的某些需求；后续工作成果实现了需求文档中的不存在的需求；后续工作成果没有正确实现需求文档中的的需求；工程经理将发现的“不一致性〞记录在?需求跟踪报告?之中，并通报给相关责任人〔工作成果的开发者〕。[Step3]消除不一致相关责任人给出消除“不一致〞的措施和方案，工程经理将该措施和方案记录到?需求跟踪报告?之中。相关责任人消除“不一致性〞之后，工程经理更新“需求跟踪矩阵〞。8.3.6输出?需求跟踪报告?8.3.7结束准那么每个开发阶段的“需求跟踪矩阵〞都已经建立。已经消除了需求文档与后续工作成果之间的不一致性。8.3.8度量工程经理统计工作量和上述文档的规模。8.4需求变更控制8.4.1目的修改“原需求文档〞中不正确的内容，产生新的需求文档。控制需求文档的变更，防止发生混乱。补充说明：本规程中的“原需求文档〞是指已经通过了评审并获得书面承诺的需求文档。8.4.2角色与职责开发方负责人〔工程经理〕和客户共同控制需求变更。8.4.3启动准那么某人〔来自开发方或客户方〕提出变更“原需求文档〞的申请。8.4.4输入“原需求文档〞8.4.5主要步骤[Step1]需求变更申请需求变更申请人撰写“需求变更申请书〞，递交给工程经理或客户方负责人。“需求变更申请书〞必须阐述：〔1〕变更原因；〔2〕变更的内容；〔3〕此变更对工程造成的影响。[Step2]审批需求变更申请 开发方负责人〔工程经理〕和客户共同审批“需求变更申请书〞：如果任何一方不同意变更，那么退回变更请求，工程按照“原需求文档〞执行。如果双方都同意变更，转向[Step3]。[Step3]更改需求文档需求分析员根据[Step1]和[Step2]更改“原需求文档〞，产生新的需求文档。[Step4]重新进行需求确认重新进行需求评审，参见需求