【IT168 专稿】 需求文档是个麻烦问题。虽然我们可能真的需要那么多文档才能准确地制定出规格。而且，大量的需求文档里面还有重复内容及不一样的语言。此外，虽然团队中有人善于编写规格，但也有人不擅长或者需要压力才能做好。大家都想知道，有简化这方面工作的方法或工具吗？
确认症结所在
要确定需求集符合目标、恰好能够满足完成工作的需求，必须先确定你需要的是什么。至少，这些需求要能够回答以下问题：
| 问题 | 关键字 |
| 业务目标是什么？ | 业务目标goals |
| 用户需要怎么做才能完成业务目标？ | 用户任务 |
| 系统要能为用户提供哪些支持？ | 系统功能 |
·系统必须符合哪些质量要求？ ·这些质量属性可用于哪些方面？ | 质量属性 |
·系统必须符合哪些规则？ ·这些规则可用于哪些方面？ | 政策…条例 |
要取得成功，就必须选择能够回答这些问题的方法。先来看一些常见而且各位可能正在经历的情况。您是否对以下情况深有同感呢？
| 情况 | 分歧 | 可以采取的行动 |
| 每个项目都会有需求文档，却极少有描述预期目标的指南性文档。 | ·虽然有需求文档，但是每个文档都有不同的需求记录方式。 ·如果项目团队需要合作，这些不同的文档整理方法就会极大地妨碍交流和整合。 | ·确定一种统一的方法来定义需求（版本说明、用例、数据模型等）。 ·为每种方法提供培训并简单地对需求完整性、合规性和一致性的预期目标进行说明。 ·检查每一项工作成果，保证预期目标的达成。 |
| “以文档为中心”的思想成为主宰的时候 | ·当“以文档为中心”的思想成为主宰的时候，大家就会觉得“越多越好”，重量（或页数）也会成为衡量需求质量的标准。 ·当“以需求为中心”的思想盛行的时候，需求就会被作为简单的描述（通常只是一句话），描述必须完成的目标。这些简单的描述是局部相关的。需求的性质是互不相同的——从包含附加信息的文档，到一系列互相关联的、对必须完成目标的描述。 ·“以文档为中心”的思想会产生不一致性和冗余。 | ·了解需求的各种类型以及之间几乎确定的关系 ·确定一种统一的方法来定义不同类型的需求（版本说明、用例、数据模型等） ·提供相关需求类型的培训，使需求：完整、合规、一致 |
| 未对职能进行清晰的定义 | ·“职能”和“职位”之间的关系通常并不清晰——项目经理编写需求，业务分析师设计内容、测试应用，这会导致质量参差不齐，而且有多少人来做，就会产生多少不同的编写方式。 ·许多人不明白编写优秀的需求需要很高的技巧。他们认为谁有空谁就可以写。写是写出来了，但是这些确实是所需要的吗？我很怀疑。 | ·为每个系统开发职位编写能够清晰地描述任务和预期目标的职能说明（并非职位说明） ·找出那些具有符合其职能所需技能的人 ·为每种职能提供可以提高技能的培训 |
确定一套方法
现在，让我们先确定一套方法。 当然，我们有许多方法可以选择。但重要的是,我们选择出来的方法应该是互补性的.这样它们才能让你对构建目标有一个完整的了解。
| 问题 | 关键字 | 可用方法 | 方法的目标 |
| 业务目标是什么？ | 业务目标goals | ·版本说明 ·项目/产品的成功标准 | ·描述目标 ·描述“成功”的含义 |
| 用户需要怎么做才能完成业务目标？ | 用户任务 | ·用例表 ·用例 ·业务流程模型 ·逻辑数据模型 | ·确定所需的用户任务 ·确定每项用户任务的步骤 ·显示用户任务之间的关系 ·定义对业务具有重要意义的数据并确定已有的逻辑关系 |
| 系统要能为用户提供哪些支持？ | 系统功能 | ||
·系统必须符合哪些质量要求？ ·这些质量属性可用于哪些方面？ | 质量属性 | 列出/分类质量属性并标明其应用范围 | ·描述所需的质量 ·把质量与应用范围不重复地联系到一起 |
·系统必须符合哪些规则？ ·这些规则可用于哪些方面？ | 政策…条例 | 列出/分类规则并标明其应用范围 | ·描述所需的规则 ·把规则与应用范围不重复地联系到一起 |
因为我们需要的是“恰到好处”，所以我们得问自己表中所述是否有非必需的内容。
不管如何认真地选择需要的方法，都有可能遇到特殊情况。于是有人会说没有什么标准方法。但是如果你明智地选择了一套方法，那么完全可以在大部分项目中使用这些方法。当然，如果项目在比如数据或规则方面做得过多，那么就需要修正一下方法。
修正方法
笔者曾经参加过一个项目。这个项目非常重视数据，相对来说用户任务和规则则比较少。公司有使用指定技术的需求开发流程，但是却没有用于以数据为中心的开发项目的方法。当时，逻辑数据模型是分析的重要工具。我们确定了用户任务，但这些用户任务却没有包含在用例中。信息的状态会促使用户采取相应的行为——不管是“确认”、“审查”、“通过”或是其它状态。 所以，我们开发了一个阶段-步骤表，在表中把变化转换为状态，然后相应的用户就会采取与状态对应的行动。
这个方法实施得不错，但是需求管理小组还是找我们谈话了。于是我们集合到一起——业务赞助人、项目经理和需求分析师、架构设计师、开发人员等。我们解释说，我们用上面描述的方法进行标准的需求开发，但是很快却发现这个方法无法让我们对这个以数据为中心的项目的需要有一个准确、清晰的了解。
然后我们重新整理记录需求的方法。需求管理小组的人听完我们的说明，问了两个问题，第一个是问业务赞助人：“这些需求是否代表了你的需要？”答案是：“当然，我还亲自写了一些。”第二个是问开发人员：“你知道该构建什么东西吗？” 答案是：“当然，我们动作很快。通常只需要改动很少的地方。”如果需求管理小组的人是“警察”，那么我们可能已经“被捕”了。不过，这两个问题却恰到好处地反映了修正过的方法是否行得通。
总结
回到主题，要构建正确的系统，开发人员必须知道一些东西。
| 开发人员需要知道的… | 对于… |
| 业务目标 | 环境 |
| 用户任务 | |
| 系统功能 | 构建系统功能 |
| 质量属性 | |
| 政策…条例 |
如果没有这些信息或信息不明确，那么初始开发可能并没有向着目标发展，而在测试过程中则可能发现新需求。在项目最后阶段、需求完成之前，一定要检查可能出现的问题。
除了一些比较正规的需求记录方法，还可以采取一些基本措施来保证开发人员对系统开发需求有一致而清晰的认识：
需求类型/方法
·了解需求的各种类型以及互相之间几乎确定的关系
·确定统一的方法
·提供针对需求类型及所用描述方法的培训
·简单地描述需求完整性、合规性和一致性的预期目标
·检查每一项工作成果，保证预期目标的达成。
系统开发的职能
·为每个系统开发职能编写能够清晰地描述任务和预期目标的职能说明（并非职位说明）
·找出那些天生具有符合职能的技能的人
·为每种职能提供可以提高技能的培训
