目录

编写需求文档时的8个注意事项

编写需求时,每一个词汇的选用都至关重要。简单地添加一个副词或将“必须”改为“应该”都可能产生模糊含义,这可能使工程师感到困惑并导致项目延误。

更好的需求能使各方利益相关者之间的交流更为清晰有效。这将整个组织推向更大的透明度,减少重新工作的需要,同时加快开发速度,且不会牺牲质量。虽然编写需求是一项结合艺术和科学的工作,会根据上下文环境而变化,但仍有一些最佳实践需要考虑。

遵循以下关于编写需求的主要注意事项,你将会发现在整个产品开发周期中,需求既清晰又可以追溯。

1.应该:使用需求模板

模板能为需求提供一致的结构。可以使用用户故事或系统工程格式,两者都能为更容易的测试提供统一的结构。

2.不应该:使用副词

“快速”、“轻松”等副词无法为测试人员提供清晰的指导。你应专注于可测试和可衡量的验收准则。

3.应该:标准化你的语言

中文、英语中包含许多在日常用法中含义相似的词汇。你需要确定一些词汇来表示被大家接受的含义,例如用“shall”表示具有约束性的高优先级需求。

4.不应该:模糊不清

需求常常因为过于泛泛而引起歧义,例如,“设备应易于使用”。应当更具体,无论是设定一个明确的标准,还是指定一个特定的颜色。

5.应该:使用主动语态和特定的形容词

使用主动语态的动词。例如,“汽车应该承受…”比“汽车应该被加强以承受…”更清晰。也要选择具体的形容词,而不是常用的像“用户友好”和“兼容”等词汇。

6.不应该:在需求中混入设计规格

尽可能从需求中去除设计,因为需求描述的是需求,而设计则是对需求的响应。不含设计的需求可以给工程师更多的自由度。

7.应该:定期与利益相关者审查需求

与其他人审查你的需求是确保大家对需求有共同理解的可靠方法。在实时平台上协作可以让团队交换反馈,保证可测试性,并且最小化返工。

8.不应该:依赖于负面的需求声明

负面声明可能引入歧义,因为在实现其积极需求的过程中,任何系统都有几乎无穷无尽的“不做”的事情。你需要审查负面声明。

以上就是编写需求时的一些重要原则。遵循这些原则,能帮助你编写出更清晰、更易于理解和执行的需求,从而使项目更有效地推进。

本文是否对你有用?

内容导航

目录