需求应该是原子性的规则是否有例外？

Question

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

我主要认为应该将这些文件拆散，但这确实有使长文档更长甚至可读性更差的缺点-在实践中，这可能意味着其目标读者最终会在其上略读或仅阅读部分而不是吸收整个内容。

但是，在某些要求下，将它们分解似乎有些愚蠢。 例如：有很多get / set操作，这些操作总是一起使用-总是将它们分解为“用户应该可以得到...”，“用户应该可以进行设置”似乎有点过头了。 ..“其他示例包括启用/禁用，验证列表，受支持的平台/浏览器等。

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

Answer 1

我的意见是，只要您唯一地识别需求，就不必分解需求。 例如，“ [REQ1]用户应该能够[a]设置...和[b]获取...”，这样您可以保持文档的可读性，并且还可以分别跟踪原子部分。