● 避免具有二义性的术语。

　　建立一本术语和数据字典，用于定义所有的业务和技术词汇，以防止它被不同的读者理解为不同的意思。特别是要清楚说明那些既有普通含义又有专用领域含义的词语。

　　● 不要在需求说明中包括设计。

　　包含在需求说明中的设计方法将对开发人员造成多余的限制，并妨碍他们进行最佳设计的创造性。仔细评审需求说明以确保它是在强调解决业务问题需要做什么，而不是在说怎么做。

　　需求验证阶段

　　● 未经验证的需求。

　　审查相当篇幅的需求文档是件烦琐的事，这就像要在开发过程早期编写测试用例一样。但如果在构造设计开始之前通过验证基于需求的测试计划和原型测试来验证需求的正确性及其质量，就能大大减少项目后期的返工现象。在项目计划中应为这些保证质量的活动预留时间并提供资源。

　　● 审查的有效性。

　　如果评审人员不懂得怎样正确地评审需求文档和怎样做到有效评审，那么很可能会遗留一些严重的不足之处。所以要对参与需求文档评审的所有团队成员进行培训，组织内部有经验的评审专家或外界的咨询顾问来做讲座，以便使评审工作更加有效。

　　需求管理阶段

　　● 减轻需求变更带来的影响。

　　设计者将项目视图与范围文档作为变更的参照基础，可以减少项目范围的延伸。使用者如果本着友好合作的态度，可把需求变更减少近一半。能在早期发现需求错误的质量控制方法可以减少以后发生变更的可能。而为了减少需求变更的影响，设计者要将那些易于变更的需求用多种方案实现，并在设计时注重其可修改性。

　　● 管理需求变更。

　　需求变更的风险来源于未曾明确的变更过程，或采用的变动机制无效，亦或是不按计划的过程来做出变更。设计者应当在开发的各阶层都建立变更管理的纪律和氛围，当然这需要时间。需求变更过程包括对变更的影响评估，提供决策的变更控制委员会，以及支持确定重要起点步骤的工具。

　　● 减少未实现的需求。

　　需求跟踪能力矩阵有助于避免在设计、结构建立及测试期间遗漏任何需求，也有助于避免因为交流不充分而导致多个开发人员都未实现某项需求。

　　● 扩充项目范围。

　　如果开始时就没有很好也定义需求，那么很可能隔一段时间就要扩充一次项目的范围。产品中未说明白的地方将耗费比预期更多的工作量，而且按最初需求所分配好的项目资源也可能要按用户的实际需求而调整。为减少这些风险，要对阶段递增式的生存期制定计划，在早期版本中实现核心功能，并在以后的阶段中逐步增加功能以实现需求。