都需遵循此过程。
2）进行需求变更影响分析。评估每项需求变更，以确定他对项目计划安排和其他需求的影响，明确和变更相关的任务并评估完成这些任务需要的工作量。通过这些分析将有助于需求变更控制部门做出更好的决策。
3）建立需求基准版本和需求控制版本文件。确定需求基准，这是项目各方对需求达成一致认识时刻的一个快照，之后的需求变更遵循变更控制过程即可。每个版本的需求规格说明都必须是独立说明，以避免将底稿和基准或新旧版本相混淆。
4）维护需求变更的历史记录。将需求变更情况写成文件，记录变更日期、原因、负责人、版本号等内容，及时通知到项目研发所涉及的人员。为了尽量减少困惑、冲突、误传，应指定专人来负责更新需求。
5）跟踪每项需求的状态。能把每一项需求的状态属性（如已推荐的，已通过的，已实施的，或已验证的）保存在数据库中，这样能在所有时候得到每个状态类的需求数量。
6）衡量需求稳定性。能定期把需求数量和需求变更（添加、修改、删除）数量进行比较。过多的需求变更"是个报警信号"，意味着问题并未真正弄清晰。
4 需求分析评价标准
怎么判断需求规格说明的好坏，不同的软件工程规范都有自己的一套标准，这里向大家介绍一个比较常见的NASA SEL推荐方法，他是由美国国家航空和航天局软件工程实验室研发的五大常用国际软件工程规范之一，他对软件需求过程的评价标准是：清晰、完整、一致、可测试。
（1）清晰：目前大多数的需求分析采用的仍然是自然语言，自然语言对需求分析最大的弊病就是他的二义性，所以研发人员需要对需求分析中采用的语言做某些限制。例如尽量采用主语＋动作的简单表达方式。需求分析中的描述一定要简单，千万不要采用疑问句、修饰这些复杂的表达方式。 除了语言的二义性之外，注意不要使用行话，就是计算机术语。需求分析最重要的是和用户沟通，可是用户多半不是计算机的专业人士，如果在需求分析中使用了行话，就会造成用户理解上的困难。
（2）完整：需求的完整性是非常重要的，如果有遗漏需求，则不得不返工，在软件研发过程中，最糟糕的事情莫过于在软件研发接近完成时发现遗漏了一项需求。但实际情况是，需求的遗漏是常发生的事情，这不仅仅是研发人员的问题，更多发生在用户那里。要做到需求的完整性是非常艰难的一件事情，他涉及到需求分析过程的各个方面，贯穿整个过程，从最初的需求计划制定到最后的需求评审。
（3）一致：一致性是指用户需求必须和业务需求一致，功能需求必须和用户需求一致。在需求过程中，研发人员需要把一致性关系进行细化，比如用户需求不能超出预前指定的范围。严格的遵守不同层次间的一致性关系，就能确保最后研发出来的软件系统不会偏离最初的实现目标。
（4）可测试：一个项目的测试从什么时候开始呢？有人说是从编码完成后开始，有人说是编码的时候同时进行单元测试，编码完成后进行系统测试，这些结论都不完全正确。实际上，测试是从需求分析过程就开始了，因为需求是测试计划的输入和参照。这就需求需求分析是可测试的，只有系统的所有需求都是能被测试的，才能够确保软件始终围绕着用户的需要，确保软件系统是成功的。