需求文档是个麻烦问题。虽然我们可能真的需要那么多文档才能准确地制定出规格。而且，大量的需求文档里面还有重复内容及不一样的语言。此外，虽然团队中有人善于编写规格，但也有人不擅长或者需要压力才能做好。大家都想知道，有简化这方面工作的方法或工具吗？

确认症结所在

要确定需求集符合目标、恰好能够满足完成工作的需求，必须先确定你需要的是什么。至少，这些需求要能够回答以下问题：

要取得成功，就必须选择能够回答这些问题的方法。先来看一些常见而且各位可能正在经历的情况。您是否对以下情况深有同感呢？

确定一套方法

现在，让我们先确定一套方法。 当然，我们有许多方法可以选择。但重要的是,我们选择出来的方法应该是互补性的.这样它们才能让你对构建目标有一个完整的了解。

因为我们需要的是“恰到好处”，所以我们得问自己表中所述是否有非必需的内容。

不管如何认真地选择需要的方法，都有可能遇到特殊情况。于是有人会说没有什么标准方法。但是如果你明智地选择了一套方法，那么完全可以在大部分项目中使用这些方法。当然，如果项目在比如数据或规则方面做得过多，那么就需要修正一下方法。

修正方法

笔者曾经参加过一个项目。这个项目非常重视数据，相对来说用户任务和规则则比较少。公司有使用指定技术的需求开发流程，但是却没有用于以数据为中心的开发项目的方法。当时，逻辑数据模型是分析的重要工具。我们确定了用户任务，但这些用户任务却没有包含在用例中。信息的状态会促使用户采取相应的行为——不管是“确认”、“审查”、“通过”或是其它状态。 所以，我们开发了一个阶段-步骤表，在表中把变化转换为状态，然后相应的用户就会采取与状态对应的行动。

这个方法实施得不错，但是需求管理小组还是找我们谈话了。于是我们集合到一起——业务赞助人、项目经理和需求分析师、架构设计师、开发人员等。我们解释说，我们用上面描述的方法进行标准的需求开发，但是很快却发现这个方法无法让我们对这个以数据为中心的项目的需要有一个准确、清晰的了解。

然后我们重新整理记录需求的方法。需求管理小组的人听完我们的说明，问了两个问题，第一个是问业务赞助人：“这些需求是否代表了你的需要？”答案是：“当然，我还亲自写了一些。”第二个是问开发人员：“你知道该构建什么东西吗？” 答案是：“当然，我们动作很快。通常只需要改动很少的地方。”如果需求管理小组的人是“警察”，那么我们可能已经“被捕”了。不过，这两个问题却恰到好处地反映了修正过的方法是否行得通。

总结

回到主题，要构建正确的系统，开发人员必须知道一些东西。

如果没有这些信息或信息不明确，那么初始开发可能并没有向着目标发展，而在测试过程中则可能发现新需求。在项目最后阶段、需求完成之前，一定要检查可能出现的问题。

除了一些比较正规的需求记录方法，还可以采取一些基本措施来保证开发人员对系统开发需求有一致而清晰的认识：

需求类型/方法

·了解需求的各种类型以及互相之间几乎确定的关系

·确定统一的方法

·提供针对需求类型及所用描述方法的培训

·简单地描述需求完整性、合规性和一致性的预期目标

·检查每一项工作成果，保证预期目标的达成。

系统开发的职能

·为每个系统开发职能编写能够清晰地描述任务和预期目标的职能说明（并非职位说明）

·找出那些天生具有符合职能的技能的人

·为每种职能提供可以提高技能的培训