检查并提出关于需求的问题。反过来，负责任的需求分析人员应该回答工程师提出的问题，并将这些澄清记录在需求文档中。出于项目规划的目的，应该为这种检查分配时间，尤其是让分析人员直接与客户一起检查未知问题以获得更多细节的时间。因此，需求规格说明书检查应该成为常规工作，而不是项目中的例外情况。最后，在开始设计之前应该解决所有的开发人员问题。如果完备的需求规格说明书检查受到影响，那么您的项目团队就面临着工程师在系统设计中引进不希望的假定的风险。
除了检查之外，另一种可用的有效实践是使用用例来表达功能需求。用例通过从用户的观点将系统功能记录为一系列步骤描述了系统与外部世界交互时的行为。该视角为软件团队和他们的客户提供了对待建系统的预期行为的共同理解。通过最小化需求误解的风险，用例还能够提高需求的清晰度。比如，在使用用例的项目中，分析人员通常只注意主要用例（关于如何使用系统的用法场景）并且相信没有大问题。然而，一旦开发人员开始通过识别所有备用流（在出错情况下的备用用法场景）来整理用例的细节，真正的问题就浮出水面。如果开发人员在设计之前没有进行这种细化，那么该设计就需要多次返工，以便包含所有的用户场景。该细化过程中，能否在开发人员和分析人员之间建立起关键的交流关系，通常决定了能否成功交付最终产品。
然而，必须注意到并非所有需求都可以用用例表达。比如，可靠性和性能需求更适合以声明性的形式表达（如，"系统应该……"），但是用例确实提供了一种从各种视角记录系统的用户体验的机制。通过专注于用户观点，用例还避免了在需求规格说明书中引进设计元素的问题，从而将设计者从无根据的设计约束中解脱出来。
问题4：根据过时的需求规格说明书编写代码
在可以开始设计和编写代码之前，需要了解交付目标，并且分析人员负责确认您理解了客户需要。这是需求规格说明文档的任务。它必须保证项目团队中的每个人对要将要开发用来解决客户提出的特定问题的系统有着共同理解。如果需求规格说明文档的角色已经给定，那么开发人员就可以很容易地定位文档，更重要的是定位它的最新版本。这看上去可能没有什么意义，但经过验证它非常灵活。通常，要按照特别的基础来检查规格说明书，并且还要做出决定和假设。不幸的是，在这种情况下，需求并不总能及时得到更新。此外，更新过的需求不能总是重新分发给项目团队。另一种情况可能是更新过的需求被重新分发之后，淹没在每个人邮箱中的邮件堆里，无从寻觅。最后，保证最新的需求并提供对它们的访问应该是项目团队的标准实践。
解决办法：最新的规格说明书随时可用
好的 RM 实践为管理需求规格说明书清楚地确定了一个中央知识库，这样每个人都能总是得到最新的需求版本。作为开发人员不能依赖电子邮件时间标记，您可以保证不以一个过时版本的需求文档开始工作，从而不浪费时间和精力。此外，与项目团队交流（通过电子邮件、电话、会议等）需求已经被更新的消息也是一种良好、健康的实践。
在机构中改善需求管理的六种技巧
本节，我们提供为开发人员提供简单有效的指导，帮助他们避免前面讨论过的软件问题。
技巧1：参与建立变更请求过程
这可能看上去令人畏缩，但实际上却很容易实现。简单地说，任何变更请求在被接受之前都应该经过确认。
建立变更请求过程的第一步是确定您的团队如何收集和管理变更请求。最简单的方法是创建一个标准的纸张形式表格，每个人都可以通过电子邮件或者亲自填写该表格。更健壮的方法是使用某种程度的自动化工具支持。
接着，您需要确定如何存储这些请求。这些纸张形式文档可以存放在一个三环的活页夹中吗？或者您会使用有些种类的