关键处理领域同样建议通过版本控制和变更控制来管理需求文档。版本控制确保随时能知道在开发和计划中正在使用的需求的版本情况。变更控制提供了支配下的规范的方式来统一需求变更，并且基于业务和技术的因素来同意或反对建议的变更。当在开发中修改、增加、减少需求时，软件开发计划应该随时更新以与新的需求保持一致。不反映现实的计划于事无补。 必需要强调的一点是，CMM只是推荐方法，并没有说你一定要采用这种方法。仔细的分析自身的特点，总结适合自身的方法。但是CMM提到的两个目标却是任何需求活动都应该追寻的目标。事实上，不但各个企业采用的方法不同，即便是企业内部，对于不同的项目，也不存在一个标准的模式。每个项目都有自身的特点，不能强制性的要求他们采用同样的模板。所以在项目开始的时候，一般在项目可行性论证的时候，管理小组就会根据本个项目的特性制定项目计划和需求计划。 需求管理步骤
开发组织应该定义项目组执行管理他们需求的步骤。文档化编写这些步骤能使组织成员持续有效地进行必要的项目活动。请考虑选择以下主题：
1、用于控制各种需求文档和单个需求版本的工具、技术和习惯做法。
2、建议、处理、协商、通告新的需求和变更给有关的功能域的方法。
3、如何制定需求基线。
4、将使用的需求状态，并且是谁允许作出的变更。
5、需求状态跟踪和报告过程。
6、分析已建议变动的影响应遵循的步骤。
7、在何种情况下需求变更将会怎样影响项目计划和约定。
你可以在一个文档中包含上面所有的信息。或者，你可能喜欢专题分述，例如分成变更控制过程，影响分析过程，状态跟踪过程。这些过程可能在多个项目中都有用，因为他们反映每个项目所应遵循的公共功能。
需求控制的工具有很多，你可以使用专业的Rational公司的RequisistPro，也可以使用一些可视化的数据库管理工具，甚至你可以只是使用目录结构。用什么样的工具并不是特别重要，关键还是在于人。上面已经说过，需求的管理最重要的（关键过程域）就是版本控制和变更管理。这两个方面是密切相关的。需要版本控制的一个重要因素就是需求在不断的变化。
文档的海洋
虽然到现在还没有提到任何的具体文档，但是需求过程的产品中大都是文档。文档的产生目的是为了项目能够被控制。如果为了实现控制项目的目的，而文档却陷入了不可控制的境地，那就是一条歧途了。想象起来是很可笑，但是这个错误是确实存在的。往往有一些狂热的技术分子，为了追求完美的实施项目管理，实施了过多的文档，可是这个项目本身并没有想象的那么庞大。到了最后，是由于文档的失控导致了项目的失控。即便是以完善著称的RUP（Rational Unifined Process）也并不提倡制作过多的文档。控制好你的计划，使之适合你的项目。需求分析人员应该专注于需求的获取和分析，而不是写出漂亮的文档。当然，如果用户有这方面的要求的话，你是应当重视的。
需求管理活动的积累材料
变更控制过程变更控制过程能够减少因无休止、失控的需求变更引起的混乱。它明确了一种方法来提出、协商、评估一个新的需求或在已有需求上的一项变更。变更控制通常需要问题跟踪工具的支持，但请铭记工具并不能替代过程。
变更控制委员会过程变更控制委员会(CCB)是由风险承担者的主要成员组成的，对提出的需求变更决定执行哪一项，拒绝哪一项，以及在各产品发行版本中包括哪些变更。CCB过程描述了变更控制委员会的组成及操作过程。CCB的主要活动是对提出的变更进行影响分析，为每项变更作出决定，并且告知那些将受到影响的人。 需求变更影响分析清单和模板估计提出的需求变更的成本费用和影响是决定是否执行变更的重要步骤。影响分析能帮助CCB作出正确的决定。影响分析清单包括许多自问自答型的问题，如：要考虑到可能的任务、边界影响、实施所确定的变更引起的相关的潜在风险。一张参与人员工作表可以作为估计任务工作量的简单方法，从这里就能明白确认变更的复杂性。
需求状态跟踪过程需求管理包括监控和报告每项功能需求的状态和状态改变的条件。你需要一个数据库或一种商业需求管理工具来跟踪一个复杂系统中大量的需求状态。此过程也描述了当你随时查看收集到的需求状态时输出的报告格式。
需求跟踪能力矩阵模板需求跟踪能力矩阵列出了SRS中的所有功能需求及相应的设计模块，源文件和实施需求的过程，还有验证需求实施正确性的测试用例。跟踪能力矩阵应该也可以指出对应的上一层用户需求或系统需求。
需求分析
需求分析可分为：问题获取（elicitation）、分析(analysis)、编写规格说明（specification）和验证（verification）四个阶段（Thayer and Dorfman 1997）。这些子项包括软件类产品中需求收集、评价、编写文档等所有活动。需求开发活动包括以下几个方面：
1、确定产品所期望的用户类。
2、获取每个用户类的需求。
3、了解实际用户任务和目标以及这些任务所支持的业务需求。
4、分析源于用户的信息以区别用户任务需求、功能需求、业务规则、质量属性、建议解决方法和附加信息。
5、将系统级的需求分为几个子系统，并将需求中的一部份分配给软件组件。
6、了解相关质量属性的重要性。
7、商讨实施优先级的划分。
8、将所收集的用户需求编写成规格说明和模型。
9、评审需求规格说明，确保对用户需求达到共同的理解与认识，并在整个开发小组接受说明之前将问题都弄清楚。 需求开发过程的积累材料
1) 项目视图与范围模板项目的视图与范围文档明确了项目的概念性功能，并提供了确定需求优先级和变更的参考。需求视图与范围文档是简明扼要的、高度概括的新项目业务需求说明。用统一的方式编写项目视图与范围文档能确保在项目进行过程中作决定时能考虑到所有应考虑的情况。
2) 需求开发过程该过程介绍了怎样确定客户及从客户那里获取需求的技术。也描述了项目。需要创建的各种需求文档和分析模型。这个过程还指明了每项需求包含的信息种类，比如：优先级、预计的稳定性或计划发行版本号。同时还应指明需求分析及需求文档检验需要执行的步骤以及确认软件需求规格说明和建立需求基线的步骤。 3) 需求分配过程把高层的产品需求分成若干特定子系统是非常重要的，尤其是当开发的系统既含有软件又含有硬件或是包括多个子系统的软件产品时尤为重要（Nelsen 1990）。需求分配是在系统级需求完成和系统体系结构确定后才进行的，这个过程包含的信息是怎样执行分配以确保功能分配到合适的系统组件中，同时也说明分配的需求怎样才能追溯回它们的上两级系统需求以及在其它子系统中的相关需求。
4) 使用实例模板使用实例模板提供了一种把每项用户希望使用软件系统完成的任务编写成文档的标准方法。使用实例定义包括一个简要的任务介绍，必须处理的异常情况的说明和描述用户任务特点的附加信息。使用实例可作为软件需求规格说明中一条独立的功能需求。另外，你也可将使用实例与SRS模板合并为一个文档，既包括产品的使用实例，又包括软件功能需求。
5) 软件需求规格说明模板软件需求规格说明模板提供了一种组织功能需求和非功能需求的结构化方法。采用标准的SRS模板将有助于创建统一且高质量的需求文档。可能要采用多个模板以适应组织承担的不同类型和规模的项目。这样可减少因一种“万能”模板并不适合你的项目所带来的障碍。 6) 需求优先级确定过程，此时为满足进度时限要求，计划的功能不得不放弃掉。我们需要知道哪些性能、使用实例或功能需求的优先级最低，以便在任何阶段，我们都可适当缩减范围。
7) SRS和使用实例审查清单对需求文档的正式审查是保证软件质量的一项重要措施。审查清单指出在需求文档中发现的一些错误。在审查会议的准备中运用清单将使你的注意力集中到通常存在问题的地方。
文章来源于领测软件测试网 https://www.ltesting.net/
