【IT168 专稿】 需求文档是个麻烦问题。虽然我们可能真的需要那么多文档才能准确地制定出规格。而且，大量的需求文档里面还有重复内容及不一样的语言。此外，虽然团队中有人善于编写规格，但也有人不擅长或者需要压力才能做好。大家都想知道，有简化这方面工作的方法或工具吗？
确认症结所在
要确定需求集符合目标、恰好能够满足完成工作的需求，必须先确定你需要的是什么。至少，这些需求要能够回答以下问题：
| 问题 | 关键字 |
| 业务目标是什么？ | 业务目标goals |
| 用户需要怎么做才能完成业务目标？ | 用户任务 |
| 系统要能为用户提供哪些支持？ | 系统功能 |
·系统必须符合哪些质量要求？ ·这些质量属性可用于哪些方面？ | 质量属性 |
·系统必须符合哪些规则？ ·这些规则可用于哪些方面？ | 政策…条例 |
要取得成功，就必须选择能够回答这些问题的方法。先来看一些常见而且各位可能正在经历的情况。您是否对以下情况深有同感呢？
| 情况 | 分歧 | 可以采取的行动 |
| 每个项目都会有需求文档，却极少有描述预期目标的指南性文档。 | ·虽然有需求文档，但是每个文档都有不同的需求记录方式。 ·如果项目团队需要合作，这些不同的文档整理方法就会极大地妨碍交流和整合。 | ·确定一种统一的方法来定义需求（版本说明、用例、数据模型等）。 ·为每种方法提供培训并简单地对需求完整性、合规性和一致性的预期目标进行说明。 ·检查每一项工作成果，保证预期目标的达成。 |
| “以文档为中心”的思想成为主宰的时候 | ·当“以文档为中心”的思想成为主宰的时候，大家就会觉得“越多越好”，重量（或页数）也会成为衡量需求质量的标准。 ·当“以需求为中心”的思想盛行的时候，需求就会被作为简单的描述（通常只是一句话），描述必须完成的目标。这些简单的描述是局部相关的。需求的性质是互不相同的——从包含附加信息的文档，到一系列互相关联的、对必须完成目标的描述。 ·“以文档为中心”的思想会产生不一致性和冗余。 | ·了解需求的各种类型以及之间几乎确定的关系 ·确定一种统一的方法来定义不同类型的需求（版本说明、用例、数据模型等） ·提供相关需求类型的培训，使需求：完整、合规、一致 |
| 未对职能进行清晰的定义 | ·“职能”和“职位”之间的关系通常并不清晰——项目经理编写需求，业务分析师设计内容、测试应用，这会导致质量参差不齐，而且有多少人来做，就会产生多少不同的编写方式。 ·许多人不明白编写优秀的需求需要很高的技巧。他们认为谁有空谁就可以写。写是写出来了，但是这些确实是所需要的吗？我很怀疑。 | ·为每个系统开发职位编写能够清晰地描述任务和预期目标的职能说明（并非职位说明） ·找出那些具有符合其职能所需技能的人 ·为每种职能提供可以提高技能的培训 |
