2022年需求开发和管理流程范例 .pdf

《2022年需求开发和管理流程范例 .pdf》由会员分享，可在线阅读，更多相关《2022年需求开发和管理流程范例 .pdf（17页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、第 1 页 共 17 页需求开发和管理流程范例目录1.目的 . 32.适用范围 . 33.名词和缩略语 . 34.角色和职责 . 35.过程综述 . 55.1. 流程图 . 5 5.2. 过程说明 . 5 6.过程活动 . 66.1. 活动一：获取用户需求 . 6 6.2. 活动二：建立系统需求 . 7 6.3. 活动三 . 需求分析与建模 . 9 6.4. 活动四 . 形成需求规格说明 . 10 6.5. 活动五 .需求验证 . 11 6.6. 活动六：需求变更 . 12 6.7. 活动七：需求跟踪 . 12 7.过程度量与改进 . 158.过程裁剪指南 . 159.相关文件 . 15名师资

2、料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 1 页，共 17 页 - - - - - - - - - 第 2 页 共 17 页10. 质量记录 . 1611. 附录 . 1711.1. 附录 1：需求优先级说明 . 17 11.2. 附录 2：需求状态说明 . 17 名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 2 页，共 17 页 - - - - - - - - - 第

3、3 页 共 17 页1.目的本程序文件定义了本组织的需求与管理的过程，目的是实现有计划地收集、分析顾客的需求，并保证所有共利益者在项目进展过程中始终保持对需求一致的理解和承诺。2.适用范围本过程适用于公司所有合同项目和自主研发项目。3.名词和缩略语缩写和术语解释用户需要用户对项目所提出的要求功能需求特性列表为满足用户需要，项目 /产品需要提供的功能点的组合列表产品部件作为产品的一部分提交给用户使用或用于集成的产品组件，也称模块。系统需求组织对用户需求建议请求Request for Proposal 的响应，一般为项目的技术建议书或产品系统需求，包括功能、性能、环境、验收的要求等需求规格说明对系

4、统需求进行分析、细化，形成的对需求的技术描述需求跟踪矩阵 RTM 用于表示需求和对其进行开发后形成的各种系统元素之间联系链。4.角色和职责角色职责用户代表指客户和最终用户， 是产品调研的对象； 售前和销售人员也可以作为用户代表参加项目或产品的一些评审活动。当自主产品研发时，产品经理可代表用户。售前人员直接与用户接触，并了解项目最终目标的人， 一定程度上可以代表用户。共利益者可以代表客户以外所有对项目需求或最终目标有影响的人员。产品经理负责开发和管理来自用户的需要。名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 -

5、- - - - - - 第 3 页，共 17 页 - - - - - - - - - 第 4 页 共 17 页项目经理在项目中管理分配给项目的用户需求。测试经理负责项目开发过程中的功能测试和测试计划的安排。高级经理负责审查和评审需求开发过程中的活动、 状态和结果，并给出解决方案。产品小组产品经理领导的实施需求的开发和管理的团队。可以是一个人， 也可能是包括产品工程师在内的一个小组。测试小组按测试经理制定的测试计划进行测试，编写测试用例和测试模拟程序。评审小组对需求进行审核的小组， 可以是一个人，也可能是包括资深软件工程师、系统设计师、产品经理、售前人员、高级经理等在内的一个小组，项目经理是其领

6、导者，资深软件工程师是其核心。名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 4 页，共 17 页 - - - - - - - - - 第 5 页 共 17 页5.过程综述5.1.流程图5.2.过程说明需求开发与管理过程包括首先获取用户需求，然后对用户需求进行分类和整理， 形成系统需求。通过对系统需求进行分析和建模，形成需求规格说明书， 并将分析后的需求以模型或原型方法与用户进行确认，以此建立设计开发基础。最后采用原型、测试验证、评审等方式验证需求。同时，在开发活动中有序的管理需求变

7、更，并通过需求跟踪确保需求的可追溯性和一致性。名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 5 页，共 17 页 - - - - - - - - - 第 6 页 共 17 页6.过程活动6.1.活动一：获取用户需求通过与用户交流、对现有系统的了解以及对项目任务的分析，开发、捕获和修订用户的需要。6.1.1.进入准则经过市场扫描活动、售前支持、客户反馈等活动，产品经理经过基本分析，确定要进行某产品的开发和较大升级；6.1.2.输入市场分析报告、售前和售后服务相关记录6.1.3.任务任

8、务 1：产品市场扫描。 市场服务部会同产品经理针对特定产品进行市场扫描工作，主要包括与该产品相关的其他产品的名称、主要功能、市场情况；产品的领域，相关标准情况；产品主要涉及的技术领域和技术发展概况。产品经理根据市场扫描的结果确认是否需要进行产品开发和升级。任务 2：需求调研。 产品经理根据需求调研规程组织相关人员实施需求调研活动，形成相关调研记录和需求特性列表。评审小组对调研结果实施结构化审查。任务 3：产品路线图设计 。产品经理根据产品的需求特性列表和市场情况初步确定产品功能特性的优先级，优先级划分参见附录1，并且将优先级的划分与高级经理进行沟通，得到初步的确定后，对需求特性列表按照优先级进

9、行分类整理，形成产品路线图。对于项目而言，此任务可以演化成考虑项目分阶段实施的需求划分。6.1.4.输出需求特性列表、产品路线图6.1.5.退出准则需求特性列表通过审核，与高级经理沟通后初步明确项目经理名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 6 页，共 17 页 - - - - - - - - - 第 7 页 共 17 页6.2.活动二：建立系统需求产品小组首先获取到用户的原始需求，在此基础上进行针对原始需求的分析和建模，参考需求确认方法描述 采取一些综合性的方法与需求直接提

10、出者进行需求确认，最后形成系统需求， 作为项目开发的首要依据。 系统需求除功能需求外， 还要包括硬件、 系统软件、数据库约束以及性能、可靠性等要求等。6.2.1.进入准则获取到用户原始需求，并准备开始建立系统需求6.2.2.输入需求特性列表6.2.3.任务任务 1：用户需求确认。产品经理向项目经理和共利益者讲解需求特性列表。产品经理安排产品小组对原始需求进行分类，并且分模块对这些需求进行分析确认，可以参考需求确认方法描述，采用用例（ Use Case ）或场景（ Scenario）描述方法模拟系统最终的用户环境，通过原型方法来向用户或共利益者演示系统的一些模拟情况、分析结果和流程， 根据演示的

11、结果与用户进行需求探讨和修订。当得到用户或共利益者对需求的确认后，就可以开始对系统功能进行架构分析。任务 2：建立系统主要功能结构图。项目经理根据需求特性列表中描述的需求特性，初步确定系统解决方案， 包括总体结构、 产品部件（模块）以及相互的关系、 第三方产品的选择和使用、已有软件模块的选择和使用等。任务 3：建立系统功能需求。它主要包括以下子任务：1 产品小组在产品经理指导下，根据需求特性列表细化需求，将每个功能特性细化成若干个相互关联的具体的功能点，并对每个功能点进行描述名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精

12、心整理 - - - - - - - 第 7 页，共 17 页 - - - - - - - - - 第 8 页 共 17 页2 项目经理将细化后的功能点按照功能特性分配给相应的产品部件。对于特殊要求的部件，项目经理要在备注中加以说明比如需要提供特殊的API，使产品提供二次开发能力等。3 确定接口需求。项目经理将功能特性分配到各产品部件后，要通过部件接口明确主要部件间的信息传递和服务关系。同时要考虑与外部部件的接口关系如第三方的邮件服务器、数据库、消息服务器、应用系统的接口关系等等任务 4：产品经理组织产品小组确定产品的非功能性需求，如性能、约束条件（如操作系统、网络、带宽等外部条件）、可靠性。任

13、务 5：决策分析。当存在多个解决方案时，特别是存在多个第三方产品部件解决方案时，由产品经理牵头， 高级经理、共利益者共同参考 决策分析和解决方案控制程序进行决策分析，确定选用的解决方案。任务 6：整合形成系统需求。以上任务完成后，由产品经理整合编写系统需求。任务 7：系统需求评审。产品经理会同高级经理、用户代表、产品小组、共利益者对系统需求按照 正式评审规程 进行评审。评审通过后，系统需求纳入项目受控库，形成功能基线 FBL任务 8：需求跟踪。产品经理根据系统需求，指派产品小组初始化需求跟踪矩阵，包括命名、标识、状态。对应合同项目， 系统需求的对应工作产品可以是技术建议书。产品小组的职能由售前

14、人员代替。相关过程参考售前技术支持控制程序。6.2.4.输出系统需求，经过高级经理确认，并由评审负责人签字后的评审纪录6.2.5.退出准则全部任务完成名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 8 页，共 17 页 - - - - - - - - - 第 9 页 共 17 页6.3.活动三 . 需求分析与建模项目经理根据已经经过评审的系统需求，协同产品小组和资深工程师一起对系统需求进行分析。该过程包括选择相关的分析方法进行分析，并且建立需求模型。6.3.1.进入准则系统需求通过评

15、审6.3.2.输入系统需求6.3.3.任务任务 1：项目经理协同产品小组和资深软件工程师与，参考需求分析方法工具指南选定需求分析方法。任务 2：产品小组按照传统的结构化需求分析作业指导书暂缺或面向对象需求分析作业指导书 实施需求分析活动。结构化需求分析方法：开发过程模型和逻辑数据模型，产生ERD（Entity-Relation Diagram）、DFD（Data Flow Diagram）、状态转换图，形成数据字典。面向对象的需求分析方法：开发详细的用例，抽象类以及类间的关系，创建协作图、时序图、交互图。任务 3：整理分析结果，形成需求分析数据包（即需求模型的集合）。产品小组按照需求缺陷分类标

16、准 利用需求问题跟踪记录表 ，记录存在问题。6.3.4.输出需求分析数据包（即需求模型的集合）6.3.5.退出准则需求分析数据包开发完成名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 9 页，共 17 页 - - - - - - - - - 第 10 页 共 17 页6.4.活动四 . 形成需求规格说明生成需求模型部件的精确的、形式化的表述，作为设计和开发的基础文件，形成分配基线（ABL ）。6.4.1.进入准则需求分析数据包开发完成6.4.2.输入需求分析数据包6.4.3.任务任务

17、 1：产品小组处理需求分析中发现的问题，确实是系统需求缺陷的，由产品经理代表SCCB 批准配置变更申请（系统需求）实施变更。需求跟踪矩阵相应的变更。任务 2：产品小组依据需求分析数据包，采用描述性语言，针对每个部件细化精确的描述该部件完成的主要活动以及部件间的相互协作关系，形成需求规格说明书。 在需求描述中发现的问题，需求分析小组需要采用需求问题跟踪表对问题进行跟踪和确认，任务 3：按照正式评审规程对需求规格说明书进行评审，评审中的问题参考需求缺陷分类标准 进行分类。通过评审的 需求规格说明书 要纳入配置管理， 形成分配基线 ABL 。作为软件开发的主要里程碑之一，需求规格说明书评审通过后，要

18、组织一个里程碑评审会议，参见项目监督与控制过程执行。任务 4：需求跟踪。项目经理根据需求规格说明书，更新需求跟踪矩阵，包括命名、标识、状态。产品经理负责对需求跟踪矩阵进行审核。对应合同项目，需求规格说明书可以映射为合同技术附件或者是工程技术实施方案中有关定制开发的详细需求说明。 对于合同中完全新开发的部分， 应该有单独的 需求规格说明书 。6.4.4.输出需求规格说明书，分配基线，相关评审纪录，更新的需求跟踪矩阵名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 10 页，共 17 页

19、- - - - - - - - - 第 11 页 共 17 页6.4.5.退出准则需求规格说明书通过评审并纳入配置管理形成分配基线6.5.活动五 .需求验证根据需求规格说明书，通过原型、模拟、测试用例的编写和执行，分析需求规格的正确性和可行性。6.5.1.进入准则需求规格说明书通过评审并形成基线6.5.2.输入需求规格说明书6.5.3.任务任务 1：根据选定的生命周期模型，项目经理确定是否开发系统，如果开发原型系统，项目经理必须确定原型系统中需要开发的功能点，原则上，原型系统的功能点低于总体功能的20%且必须为基本功能。 对于难以实现的功能， 项目经理应该说明存在的难点问题。原型实现后，产品小

20、组、用户代表一起针对原型产品，评审需求规格说明书的正确性和可行性，原型开发小组采用需求问题跟踪表 跟踪和确认问题。 确实是缺陷的， SCCB 会议批准对 需求规格说明书 进行变更。任务 2：测试小组根据需求规格说明书，概要设计说明书编写系统测试方案和用例，通过编写系统测试用例检验需求规格说明书的明确性、可测试性。对于不能测试的需求，测试小组采用需求问题跟踪表跟踪和确认问题。确实是缺陷的，由项目经理、产品经理同时代表SCCB 批准对需求规格说明书实施变更。任务 3：产品小组变更相应的需求跟踪矩阵。6.5.4.输出需求问题跟踪表，更新的需求规格说明书名师资料总结 - - -精品资料欢迎下载 - -

21、 - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 11 页，共 17 页 - - - - - - - - - 第 12 页 共 17 页6.5.5.退出准则需求规格说明书得到验证。6.6.活动六：需求变更6.6.1.进入准则分配基线形成后产生来自项目内外部的需求变更请求6.6.2.输入配置变更申请表6.6.3.任务任务 1：来自项目内需求变更，项目经理是唯一的接口，由项目经理向SCCB 提出配置变更申请表 ，来自项目外部的变更，产品经理是唯一的接口，由产品经理向SCCB提出配置变更申请表 。任务 2：需求变更提出后，相关人员按照配置

22、变更子过程执行变更流程，按照需求变更影响分析规程 执行需求变更影响分析。任务 3：需求变更关闭后，配置管理员代表SCCB要对需求变更的涉及元素进行一致性审核，有问题的提交需求不一致项列表 ，并跟踪至关闭，不能按期关闭的不一致项，CC 负责提请 QA提交不符合报告。任务 4：现场的需求变更参考 现场需求变更作业指导书执行。6.6.4.输出关闭的配置变更申请表、影响分析相关文档。6.6.5.退出准则变更关闭6.7.活动七：需求跟踪通过跟踪需求的演进，确保需求的一致性、完整性。名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整

23、理 - - - - - - - 第 12 页，共 17 页 - - - - - - - - - 第 13 页 共 17 页6.7.1.进入准则相关软件工程过程文档通过评审6.7.2.输入相关软件产品。6.7.3.任务任务 1：在软件生命周期的特定点，更新需求跟踪矩阵，包括：责任人输 入前提内容产品经理系统需求文档通过评审需求命名、标识、状态项目组需求规格说明书文档通过评审功能点的简述、标识、状态项目组概要设计说明书文档通过评审相关章节标识、状态项目组详细设计说明书部件详细设计完成后相关的文档标识、章节、状态项目组代码部件单元测试完成相关的类 /、单元名、用例名、状态测试组系统测试用例一轮测试完

24、成后相关的测试用例名称、标识、状态测试组验收测试用例系统的验收用例完成后相关的测试用例名称、状态任务 2：审核需求跟踪矩阵。审核人时机内容产品经理需求分析评审前完整性产品经概要设计评审前追溯性名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 13 页，共 17 页 - - - - - - - - - 第 14 页 共 17 页理项目经理部件详细设计完成后追溯性项目经理部件单元测试通过后追溯性测试经理一轮测试完成后追溯性产品经理系统的验收用例完成后追溯性审核人将发现的“不一致项”记录在

25、需求不一致项列表 中，并通报给项目经理和高级经理 （工作成果的开发者），限期消除“不一致项”，若未发吸纳不一致项，在需求跟踪矩阵中标注审核通过与日期。任务 3：消除需求跟踪矩阵中的不一致项。对开发相关的问题，由项目经理负责针对“不一致项”协商并制定纠正措施； 对测试相关的问题，由测试经理负责针对“不一致项”协商并制定纠正措施；对 “不一致项” 的处理意见要通知产品经理。相关责任人执行纠正措施， 消除“不一致项”并更新 需求跟踪矩阵 ，并通知审核人及时验证，并将验证结果记录在需求不一致项列表中的确认栏。任务 4：在需求变更时，由SCCB 会议责成相关人员更新需求跟踪矩阵。6.7.4.输出需求跟踪

26、矩阵6.7.5.退出准则需求跟踪工作全部完成名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 14 页，共 17 页 - - - - - - - - - 第 15 页 共 17 页7.过程度量与改进1、 产品经理在初始化需求跟踪矩阵时，同时形成需求状态统计表。在项目进行中，相关人员在更新需求跟踪矩阵时，同时按需求状态测量的要求更新需求状态统计表。2、 需求状态、需求缺陷等数据统计和使用活动参见产品度量规格说明的相关部分。3、 在需求变更过程中，要充分考虑到由于需求的变更或新需求的开发，

27、给项目带来的成本、进度、工作量等各方面的数据。8.过程裁剪指南根据软件生命周期模型的不同，可不执行相应的活动对于合同类项目，可以根据情况，修订和裁剪部分活动。对于产品项目中的小版本之间迭代只需要部分活动。活动二的任务五在不存在多种方案时可以裁剪。9.相关文件决策分析和解决方案控制程序阶段评审控制程序需求调研作业指导书需求变更影响分析规程配置变更子过程测量与分析控制程序面向对象的需求分析作业指导书需求缺陷标准正式评审规程文档审查规程名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 15

28、页，共 17 页 - - - - - - - - - 第 16 页 共 17 页10.质量记录编号名称当 前 版本最后更改时间主责任人存储位置需求特性列表产品经理产品路线图产品经理RD3101系统需求1.2 产品经理需求规格说明书评审纪录RD3021 需求问题跟踪表1.3 2004.8.26 需求分析小组配置变更申请表RM3005 需求跟踪矩阵1.5 2004.8.26 产品小组RM3004需求不一致项列表1.3 2004.8.26 配置管理员名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - -

29、- 第 16 页，共 17 页 - - - - - - - - - 第 17 页 共 17 页11.附录11.1. 附录 1：需求优先级说明需求的优先级基本的(*): 只有在这些需求上达成一致意见，产品才会被接受条件的(*): 实现这些需求将增强产品的性能，但如果忽略这些需求， 产品也是可以被接受的可选的(*): 一个功能类，实现或不实现均可11.2. 附录 2：需求状态说明状态名称状态描述待确定需求已经被用户、客户或其他共利益者提出。已定义该需求经过分析确定将在产品中实现，并纳入产品的功能特性。已确定：该需求已经经过分析、总结并分配到产品的版本中实现，即形成了产品系统需求。已批准：并作为产品构件的需求分配到系统需求中，并通过评审名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 17 页，共 17 页 - - - - - - - - -