继续肝，还记得软件需求分为需求开发和需求管理，两个模块么？其中需求开发还差一个需求定义，跟需求验证，本章一块更新了，剩下就是需求管理的内容了，需求变更，需求跟踪，希望大伙可以画画脑图，能更好的帮助记忆，我有时间也会整理出脑图，帮助大家记忆！

1.需求定义

需求定义（软件需求规格说明书SRS)：是需求开发活动的产物，编制该文档的目的是使项目干系人与开发团队对系统的初始规定有一个共同的理解，使之成为整个开发工作的基础。SRS是软件开发过程中最重要的文档之一，对于任何规模和性质的软件项目都不应该缺少。

需求定义方法

（1)严格定义也称为预先定义，需求的严格定义建立在以下的基本假设之上：所有需求都能够被预先定义。开发人员与用户之间能够准确而清晰地交流。采用图形（或文字）可以充分体现最终系统。

（2)原型方法，迭代的循环型开发方式，需要注意的问题：并非所有的需求都能在系统开发前被准确地说明。项目干系人之间通常都存在交流上的困难，原型提供了克该服困难的一个手段。特点：需要实际的、可供用户参与的系统模型。有合适的系统开发环境。反复是完全需要和值得提倡的，需求一旦确定，就应遵从严格的方法。

2.需求验证

需求验证：也称为需求确认，目的是与用户一起确认需求无误，对需求规格说明书SAS进行评审和测试，包括两个步骤：

需求评审：正式评审和非正式评审。

需求测试：设计概念测试用例。

需求验证通过后，要请用户签字确认，作为验收标准之一，此时，这个需求规格说明书就是需求基线，不可以再随意更新，如果需要更改必须走需求变更流程。

3.需求管理

定义需求基线：通过了评审的需求说明书就是需求基线，下次如果需要变更需求，就需要按照流程来一步步进行。需求的流程及状态如下图所示：

4.需求变更

需求变更和风险

主要关心需求变更过程中的需求风险管理，带有风险的做法有：无足够用户参与、忽略了用户分类、用户需求的不断增加、模棱两可的需求、不必要的特性、过于精简的SRS、不准确的估算。

变更产生的原因：外部环境的变化、需求和设计做的不够完整、新技术的出现、公司机构重组造成业务流程的变化。

变更控制委员会CCB：也称为配置控制委员会，其任务时对建议的配置项变更做出评价、审批，以及监督已经批准变更的实施。

注意：需求变更，不用拘泥于流程里，会考步骤，顺序不能变，流程少了没关系。

5.需求跟踪

双向跟踪，两个层次，如图所示：

正向跟踪表示用户原始需求是否都实现了，反向跟踪表示软件实现的是否都是用户要求的，不多不少，可以用原始需求和用例表格（需求跟踪矩阵）来表示：

若原始需求和用例有对应，则在对应栏打对号，若某行都没有对号，表明原始需求未实现，正向跟踪发现问题；若某列都没有对号，表明有多余功能用例，软件实现了多余功能，反向跟踪发现问题。

真题来喽：

1.（）是关于需求管理正确的说法。

A.为达到过程能力成熟度模型第二级，组织机构必须具有3个关键过程域

B.需求的稳定性不属于需求属性

C.需求变更的管理过程遵循变更分析和成本计算、问题分析和变更描述、变更实现的顺序

D.变更控制委员会对项目中任何基线工作产品的变更都可以做出决定

解析：C需求变更的顺序不对！正确答案选D

感谢大伙点赞+关注的支持，是我持续学习更新的动力，关注公众号：Coding-9527，跟大伙一起学习，成长，进步！