通知吗？通常开发人员都依据过时的需求工作，因为有些人忘了将影响他们工作的变更通知给他们。
即使在实际中，QE/QA 和文档化通常比开发人员更处于盲区之中，经常出现这种情况：没有及时将间接影响开发人员工作的变更通知开发人员。团队中的分析人员可能与另一位开发人员讨论，衡量变更的影响，但是却没有意识到它可能对开发人员工作的影响。
解决办法：需求变更通知
好的 RM 实践确保在影响您工作的变更发生时，您能够得到通知。同时通知您应该与哪些人取得联系，以保证您使用的是最新的需求。
如何知道需求变更何时会影响您的工作？除非您团队中的某个人对需求与实现这些需求的设计要素之间的关系进行跟踪，否则很难快速评估需求变更对设计的影响。好的RM都对需求和设计工件之间的依赖关系做了跟踪，以便在需求发生变更时您能查明设计的哪一部分受到影响。
由于需求是不断变化的目标，所以RM的一个主要利益是能跟踪需求是否被实现。这就是所谓的可跟踪性。存在各种级别的可跟踪性，但不幸的是，同时也有许多方法在滥用可跟踪性。可跟踪性的任务是保证您为客户许诺的功能能够真正实现（由开发人员来完成），并且按照指定的要求工作（由测试人员确认）。为了保证能够实现需求，并评估需求变更对设计的影响，需求应该被跟踪到设计元素。为了保证需求发生变更时能够得到验证同时测试验证也得到更新，需求应该被跟踪到测试工件（通常为测试用例）。
从需求跟踪到源代码会如何呢？虽然乍一看很有吸引力（比如，如果我变更一个需求，我知道哪些代码必须更新），但实际上代码在本质上比需求更具动态性。您可以从一个设计开始，然后优化该设计。新设计可能会导致代码变更，但是它仍与需求一致。维护可跟踪性链接需要花费时间，但是软件团队永远也没有足够的时间。所以您应该明智地使用可跟踪性。可跟踪性的真正价值在于将需求跟踪到设计和测试。编写代码实施规格说明书的方法有很多种，但是最终用户不会关心您编写的代码是什么，只要它满足需要就可以了（需求是清楚无误地向整个软件团队表达这些需要的媒介）。这种情况的一个例外是如果您工作的系统经过了标准实体（如 FDA）的审计，该标准实体托管了从需求到代码（有时甚至几行代码）的可跟踪性。即使这种情况，您在构建软件时仍不应该将需求跟踪到代码。您只需要报告最终产品需求跟踪到了代码，并且每段代码都实现了一个需求。管理需求和源代码之间的可跟踪性链接可能是一个没有多少实效的耗时工作。
问题3：根据不完整的需求规格说明书编写代码
需求文档的最初版本中总是存在模糊性，这是您的团队面临的主要RM挑战之一。上一次读需求文档并感觉您确切理解了构建目标是什么时候？大部分需求文档不包含开发人员设计系统所需的足够信息，而是留下了让他们"解释"用户需要的余地。
尽管分析人员通过RM会议、联合应用开发（JAD）会议、会见或者专题组收集和文档化需求下了不少功夫，但是开发人员在第一次读完需求之后还是有很多疑问。不管分析人员多么专业，都会出现这种情况。通常，开发人员只提供了一个可能被分析人员忽略的不同的视角。比如，开发人员通常会提出系统用户可能遇到而分析人员却没有意识到的异常情况。因此，开发人员和分析人员必须紧密合作，在开始设计之前精化原始的需求规格说明书。开发人员应该无拘束地向分析人员提出有关需求规格说明书的问题，而分析人员则应该提供答案，必要时甚至可以直接与客户联系。
解决办法：详细且无歧义的需求规格说明书
好的RM实践认识到需求规格说明书的初版需要项目团队的检查，并且还需要开发人员关于该规格说明书的提问。因此，必须给予开发人员足够的时间来