需求管理

ref: https://www.cnblogs.com/bayuezhiguang/p/6118501.html
（REQM,Requirements Management）属于成熟度2级（受管理级）的过程域，是其他许多过程域实施的前提。对于暂未实施CMMI的企业，同样也可以借鉴CMMI的原则，实施和优化需求管理。

许多IT企业都有过需求失控的痛苦经历，我们不难体会，没有好的需求管理会给我们带来什么：

☹ 需求以失控的状态进入软件过程，从源头上失去了项目的质量保证；

☹ 需求范围界定不清，使项目缺乏计划性，导致成本、研制周期失控；

☹ 需求变更失控，使组织处于被动反应式的环境中，项目组成为救火队；

☹ 需求管理不当，导致项目延期、士气低落，增加了项目的失败风险；

☹ ……

为了避免上述情况的出现，CMMI对需求管理提出了明确的目的：
一、是管理项目的产品和产ugi品构件的需求；
二、是标识哪些需求与项目计划及工作产品之间不一致。通过适当的步骤，确保需求在项目的各个层面上动态地保持一致，一旦出现不一致，则启动相关的处理过程域，使其调整到一致。

2. 需求工程＝需求开发＋需求管理

ref: http://www.zhoujingen.cn/blog/2933.html
在这里插入图片描述

2.1 需求开发

需求开发活动包括以下几个方面：

确定产品所期望的用户分类。
获取每类用户的需求。
了解实际用户任务和目标以及这些任务所支持的业务需求。
分析源于用户的信息以区别用户任务需求、功能需求、业务规则、质量属性、建议解决方法和附加信息。
将系统级的需求分为几个子系统，并将需求中的一部份分配给软件组件。
了解相关质量属性的重要性。
商讨实施优先级的划分。
将所收集的用户需求编写成规格说明和模型。
评审需求规格说明，确保对用户需求达到共同的理解与认识，并在整个开发小组接受说明之前将问题都弄清楚。
实际工作中很难一次性得到完全正确的需求，所以以上步骤并不是严格顺序执行到底的，它是一个不断反复的过程。这些步骤也不是完全顺序的，很可能需要迭代的进行。

下面就需求开发每个活动进行简单介绍：

2.2 需求获取

在《软件需求的三个层次》中介绍了三个层次的需求，在需求获取中，这些需求都是我们需要获取的，我们需要收集问题域的描述，要求解决的问题列表，以及了解系统的行为或约束。

信息来源

客户（实际的和潜在的）
用户（实际的和潜在的）
已有系统及其文档
领域专家
相关技术标准和法规

获取方式：

阅读背景资料
用户访谈、调研
需求讨论会
现场观摩

要求：

需求对需求地属性严格记录，并记录可追溯的反馈人员。
采集的需求必须符合运营要求；
可实现性、拓展性、可开发和合理性；
项目组成员确认，对人员限制，不能有过多相关人员加入；
满足用户需求和业务需求的一致性；
对研发周期进行安排，计算人力成本，分析工期合理性；

采集流程：
在这里插入图片描述

2.2.1 需求分析

需求分析是指通过对需求获取中获得的问题域的研究，获得对该领域特性及存在其中的问题特性的透彻理解并用文档说明。

不需要等到需求完全捕获后开始，在“业务需求”充分理解下，并且收集了本质的“用户需求”之后就可以开始进行需求分析
交替进行，先把握“用户需求”主要部分，然后在分析的基础上引入系统级的需求（系统的涉及与实现角度），并且分析模型，成为开发人员之间、开发人员与客户之间达成共识的一个平台
分析的基础上，就会发现更多的不明确项，更多待捕获的信息，这时就可以生成第二次的需求调研计划、问题和素材

分析要求：

需求分析文档；
使用大众习惯性的语言表达；
分析人员要了解业务需求；
需求文档中不能有模棱两可的文字，如可能一般等；
分析工期不能超过预期时间；
需求分析应该具备合理性；

分析流程：
在这里插入图片描述

分析阶段文档：
输入文档：需求清单表
输出文档：

需求商业价值文档；
需求分析说明文档；
需求清单表；
市场需求文档；

2.2.2 编写规约

规格说明书是对需求分析结果的文档化过程
需求规约必须与实际开发紧密结合，否则很容易造成与开发脱离
为需求规约定义统一的格式是一个很重要的工作
规约内容必须严谨、正确、无歧义

2.2.3 需求验证

不重视需求验证工作会在系统交付时，客户发现不是这样的，导致不期望的需求变更
提高需求质量的重要手段有：需求评审、需求确认和原型验证

需求评审：

评审流程：
在这里插入图片描述
输入文档：

需求清单表
需求说明书
输出文档：
需求评估记录表
评估报告
需求清单表
需求说明书
项目计划书
项目时间进度表

2.2.4 需求处理

需求处理说明：

产品定义和功能和需求保持一致；
原型设计应该满足要求；

需求处理要求：
在这里插入图片描述

2.3 需求管理

需求管理活动包括：

定义需求基线（迅速制定需求文档的主体）。
评审提出的需求变更、评估每项变更的可能影响从而决定是否实施它。
以一种可控制的方式将需求变更融入到项目中。
使当前的项目计划与需求一致。
估计变更需求所产生影响并在此基础上协商新的承诺（约定）。
让每项需求都能与其对应的设计、源代码和测试用例联系起来以实现跟踪。
在整个项目过程中跟踪需求状态及其变更情况。

2.3.1 需求管理的特定实践

在这里插入图片描述

2.3.2 需求跟踪

跟踪说明：

产品是否满足需求；
将项目可预见的问题最低化，对产品质量负责；
跟踪的目的：建立和维护从用户需求到测试一致性和完整性；

跟踪要求：

从开始到结束的整个流程；
团队协作，互相可以看到需求的进度和进展；
需求描述正确、清晰易懂；
是否实现所有需求；
确保所有的输出符合用户的需求；

2.3.3 需求验证

验证说明：

测试负责人编写测试标准，相关人员按照测试标准进行验证；
验证过程中对于需求不明确的bug，找相关负责人确认，确认结果通知所有相关人员；
审核测试细心、严谨，减少项目问题；

验证要求：

按照验证标准进行验证；
考虑兼容性问题；
细心，问题最小化；
bug提交规范化，语言清晰易懂，不能含有模棱两可的词语；

验证流程：
在这里插入图片描述

2.3.4 需求变更

变更说明：

变更控制的目的：变更的好处大于坏处，则允许且按照规则执行变更，避免失去控制；否则拒绝变更；
重大需求：指对整个产品定义有改变的需求；
建立和维护从需求到测试之间的一致性和完整性；
确保以用户为基础；

变更要求：

需求必须合理；
可实现性，可扩展性，可验证性，考虑到后续实现需求和产品迭代时的人力成本开发成本、技术实现难易程度；
满足用户需求和业务需求的一致性；
开发周期、人力成本、工期合理；
评审未通过的需求一定要保留；
需求变更后素所有因需求形成的文档需要更新，防止需求遗漏，防止开发错误需求；

2.3.5 需求管理trick

来源：自市场、用户调研、运营、测试、开发、用户反馈、产品经理
明确收集需求周期：
可以是半个月或者一个月进行一次汇总的需求收集，避免业务方经常提需求打断现有工作。
有的业务方不主动提需求，这时需要主动跟业务方去聊，了解业务方的规划，对整个大产品有更高的认知；

拿到业务方的建议：
初步梳理，提出无效需求，将有效需求记录到需求池。
需求方只会告诉你一个解决方案，需要向需求方不断去问为什么，了解背后真正的需求，发现本质需求后看是否现有方案已经解决或者存在更优途径，如果可以就不用放到需求池里面。

需求记录：
需求需求描述目的与价值需求来源需求分类需求标签。
待开发需求
待讨论需求

需求管理 -- 笔记