就是对项目中描述的用户需求的普遍理解，一旦理解了需求，分析者、开发者和用户就能探索出描述这些需求的多种解决方案。
这一阶段的工作一旦做错，将最终会给系统带来极大损害的部分，由于需求获取事物造成的对需求定义的任何改动，都将导致设计、实现和测试上的大量返工，而这时花费的资源和时间将大大超过仔细精确获取需求的时间和资源。
首先，软件需求不能如实反映用户的真正需要。比较常见的一种误解是需求的简单和复杂程度决定了用户是否能够真正理解相应的内容：误认为客户只能看懂简单的需求，但是对开发没有直接帮助；只有复杂的需求才有用，但是大多用户又不可能看得懂。事实上，造成这类问题的主要原因是捕获的需求不能反映用户的视角，因而，用户站在自己的立场上很难判断需求是否完备和正确，特别是在开发活动的早期。
其次，软件需求不能被开发团队的不同工种直接共用。理论上，开发团队所有成员的工作内容都受软件需求制约；现实中，如果不采用理想的需求捕获方式，只有分析人员的工作看起来和软件需求的内容直接关联，其它人的工作内容和软件需求的关联并不直观，形式上的差异或转述往往不易察觉地造成了诸多歧义、冗余或者缺失。
本文并不会就此开始探讨需求开发的问题，只是强调需求开发过程的重要，以及需求开发过程对需求变更的影响。就拿笔者亲身参与的一个项目来说：我们遵循一般的软件开发过程，通过前期一段时间的调研，做需求分析，客户基本确认之后，开发人员就投入到紧张的开发工作中，由于项目时间要求紧迫，在经过测试人员的简单确认之后，进入到试运行阶段。
结果是，在客户的试运行报告中，提出了很多问题，其中就有一条，关于一个数据查询条件的设置，客户要求的是模糊匹配查询，而实现的却是精确匹配查询。在相关的需求文档中，却找不到任何相关的需求说明。
需求开发完成之后，进入系统构建阶段，下面我们来谈构建过程中如何做好需求跟踪，以便于后期需求变更的管理。