些过程可能在多个项目中都有用，因为他们反映每个项目所应遵循的公共功能。
需求控制的工具有很多，你可以使用专业的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、将所收集的