1

我正在审查一个需求规范,其中一些需求包括“和”这个词,有时甚至是所需功能的列表。

我主要认为这些应该被分解,但这确实有使长文档更长且可读性更低的缺点 - 这实际上可能意味着其目标受众最终会略读它或仅阅读部分而不是吸收整个内容。

但是,有些要求将它们分解似乎有点愚蠢。例如:有很多 get/set 操作,它们总是一起进行 - 总是将它们分解为“用户应该能够获得......”,“用户应该能够设置”似乎有点过分。 ..” 其他示例包括启用/禁用、验证列表、支持的平台/浏览器等。

只是想知道是否有人有类似的想法,以及有时是否可以打破原子性规则?

4

1 回答 1

2

我的观点是,您不必分解需求,只要您唯一标识它们即可。例如“[REQ1] 用户应该能够 [a] set ... 和 [b] get ...” 这样您就可以保持文档的可读性,并保持单独跟踪原子部分的可能性。

于 2013-10-07T07:41:16.727 回答