立一个矩阵把每项需求来源、定义与实现、测试它的设计和代码部分联系起来,这样有利于需求的管理和需求变更影响范围的评估。
四、需求验证
需求的验证是为了确保需求说明准确、完整，表达必要的质量特点,需求将要作为系统设计和最终验证的依据,因此一定要保证它的正确性。需求验证务必确保符合完整性、正确性、灵活性、必要性、无二义性、一致性、可跟踪性及可验证性这些良好特征。这个活动需要完成下面几个任务：
1、审查需求文档，对需求文档进行正式审查是保证软件质量的有效的方法。组织一个由不同代表(如用户，分析人员，设计人员，测试人员)组成的小组，对需求规格说明书及相关模型进行仔细的检查;
2、依据需求编写测试用例，根据用户需求所要求的产品特性写出系统的功能测试用例作为系统测试依据;
3、编写用户手册，在需求开发早期即可起草一份用户手册，用它作为需求规格说明的参考并辅助需求分析;
4、确定合格的标准，需求说明中描述什么样的产品才算满足用户的要求和适合他们使用的，将合格的测试建立在使用情景描述或使用实例的基础之上。
五、需求管理
需求管理是组织、控制和文档化需求的系统方法，也是一种建立和维护用户和开发组织对于改变系统功能的协议。需求开发的结果经验证批准就定义了开发工作的需求基线,这个基线在客户和开发人员之间就构筑了一个需求约定，需求管理包括在项目进展过程中维持需求约定一致性和精确性的活动。现在很多商业化的需求管理工具都能很好的支持需求管理活动。这个活动需要完成下面几个任务：
1、确定变更控制过程,确定一个选择、分析和决策需求变更的过程,所有的需求变更都需遵循此流程;
2、建立软件变更控制委员会(SCCB，Software Change Control Board),组织一个由项目风险承担者组成的小组作为变更控制委员会，由他们来评估和确定需求变更;项目管理
3、进行变更影响分析,评估需求变更对项目进度、资源、工作量和项目范围以及其它需求的影响;
4、跟踪变更影响的产品,当进行某项需求变更时，参照需求跟踪能力矩阵找到相关的其它需求、设计文档、源代码和测试用例，这些相关部分可能也需要修改;
5、建立基准和控制版本,需求文档确定一个基线，这是一致性需求在特定时刻的快照，之后的需求变更就遵循变更控制过程即可;
6、维护变更的历史记录,记录变更需求文档版本的日期以及所做的变更、原因，还包括由谁负责更新和更新的新版本号等情况;
7、跟踪每项需求的状态,这里状态包括"确定"、"已实现"、"暂缓"、"新增"、"变更" 等。建立一个数据库，其中每一条记录记录一项需求;
8、衡量需求稳定性,记录基线需求的数量和每周或每月的变更(添加、修改、删除)数量。
一个项目的目的就是致力于开发正确的系统，要做到这一点就要足够详细地描述需求，也就是系统必须达到的条件或能力，使用户和开发人员在系统应该做什么，不应该做什么方面达成共识。我们都知道开发软件系统最为困难的部分就是准确说明开发什么，最为困难的概念性工作便是编写出详细技术需求，这包括所有面向用户、面向机器和其它软件系统的接口。获取需求就是为了解决这些问题，它必不可少的成果就是是对项目中描述的用户需求的普遍理解，一旦理解了需求，分析者、开发者和用户就能探索出描述这些需求的多种解决方案。
需求获取是在问题及其最终解决方案之间架设桥梁的第一步，是软件需求过程的主体。这一阶段的工作一旦做错，将最终会给系统带来极大损害的部分，由于需求获取事物造成的对需求定义的任何改动，都将导致设计、实现和测试上的大量返工，而这时花费的资源和时间将大大超过仔细精确获取需求的时间和资源。