|
编写优秀的需求文档没有现成固定的方法，最好是根据经验进行。从过去所遇到的问题中可使你受益匪浅。许多需求文档可以通过使用有效的技术编写风格和使用用户术语而不是计算机专业术语的方式得以改进（ Kovitz 1999）。你在编写软件需求文档时，应牢记以下几点建议：blog.mypm.net
项目管理者联盟
• 保持语句和段落的简短。项目管理者联盟
• 采用主动语态的表达方式。项目经理圈子
• 编写具有正确的语法、拼写和标点的完整句子。
• 使用的术语与词汇表中所定义的应该一致。项目管理者联盟
• 需求陈述应该具有一致的样式，例如“系统必须⋯⋯”或者“用户必须⋯⋯”，并紧跟一个行为动作和可观察的结果。例如，“仓库管理子系统必须显示一张所请求的仓库中有存货的化学药品容器清单。”项目经理博客
• 为了减少不确定性，必须避免模糊的、主观的术语，例如，用户友好、容易、简单、迅速、有效、支持、许多、最新技术、优越的、可接受的和健壮的。当用客说“用户友好”或者“快”或者“健壮”时，你应该明确它们的真正含义并且在需求中阐明用户的意图。项目管理者联盟文章
• 避免使用比较性的词汇，例如：提高、最大化、最小化和最佳化。定量地说明所需要提高的程度或者说清一些参数可接受的最大值和最小值。当客户说明系统应该“处理”、“支持”或“管理”某些事情时，你应该能理解客户的意图。含糊的语句表达将引起需求的不可验证。由于需求的编写是层次化的，因此，可以把顶层不明确的需求向低层详细分解，直到消除不明确性为止。编写详细的需求文档，所带来的益处是如果需求得到满足，那么客户的目的也就达到了，但是不要让过于详细的需求影响了设计。如果你能用不同的方法来满足需求且这种方法都是可接受的，那么需求的详细程度也就足够了。然而，如果评审软件需求规格说明的设计人员对客户的意图还不甚了解，那么就需要增加额外的说明，以减少由于误解而产生返工的风险。项目管理者联盟
项目管理者联盟
需求文档的编写人员总是力求寻找到恰如其分的需求详细程度。一个有益的原则就是编写单个的可测试需求文档。如果你想出一些相关的测试用例可以验证这个需求能够正确地实现，那么就达到了合理的详细程度。如果你预想的测试很多并且很分散，那么可能就要将一些集合在一起的需求分离开。已经建议将可测试的需求作为衡量软件产品规模大小的尺度（Wilson 1995）。项目管理者联盟
club.mypm.net
文档的编写人员必须以相同的详细程度编写每个需求文档。我曾见过在同一份软件需求规格说明中，对需求的说明五花八门。例如，“组合键C o n t r o l - S代表保存文件”和“组合键C o n t r o l - P代表打印文件”被当成两个独立的需求。然而，“产品必须响应以语音方式输入的编辑指令”则被作为一个子系统，而并不作为一个简单的功能需求。文档的编写人员不应该把多个需求集中在一个冗长的叙述段落中。在需求中诸如“和”，“或”之类的连词就表明了该部分集中了多个需求。务必记住，不要在需求说明中使用“和/或”，“等等”之类的连词。文档的编写人员在编写软件需求规格说明时不应该出现需求冗余。虽然在不同的地方出现相同的需求可能会使文档更易读，但这也造成了维护上的困难。需求的多个实例都需要同时更新，以免造成需求各实例之间的不一致。在软件需求规格说明中交叉引用相关的各项，在进行更改时有助于保持它们之间的同步。让独立性强的需求在需求管理工具或数据库中只出现一次，这样可以缓和冗余问题。
适合某种模式的需求编号列表的表格化示例
文档的编写人员应考虑用最有效的方法表达每个需求。考虑符合如下句型的一系列需求：“文本编辑器应该能分析定义有<管区>法律的<格式>文档。”对于1 2种相似的需求中， <格式>所取的可能值有3种，<管区>所取的可能值有4种。当你评审与此类似的需求时，很难发现遗漏了一个需求，例如“文本编辑器应该能分析定义了国际法的无标记文档。”可以用表中的这种格式表示需求，以确保你没有遗漏掉任何一个需求。 项目管理者联盟
|
