之前在文章测试工程师的修炼：识别需求中提到，再传统的软件开发生命周期中，关于需求的定义原则部分，我们说过软件需求定义的四条原则：
正确性Correct
完整性Complete
一致性（内部、外部）Consistent
可测试性Testable
相对于传统软件开发，敏捷软件开发中关于用户故事的划分，Bill Wake也曾经提出过INVEST原则：
Independent独立的：用户故事相对于其他用户故事来说，应该是独立的。用户故事的依赖性可能导致任务估算的困难，进而影响计划的制定。通常情况下，可以使用组合或拆分用户故事的方式减少其相互之间的依赖性。
Negotiable可协商的/便于沟通的：一个用户故事的卡片应该包含故事详情的简短描述，详情通过讨论阶段完成。一张包含足够详情的用户故事卡片实际上是减少了和客户的沟通。
Valuable有价值的：每个用户故事都应该对客户有价值。一个让用户故事有价值的方法就是让客户写下来。一旦一个客户意识到一个用户故事并不是一个契约而是可协商的，用户将非常乐意写下他们。
Estimate-able可估算的：开发者应该可以估算用户故事，以确定优先级或进行故事规划。一些阻止开发人员估算的障碍包括：缺乏领域知识（这时应进行更多的沟通）、故事太大了（这时应对用户故事进行拆分）。
Small粒度合适的：一个用户故事应该在工作量上短小，且不超过2–3人周的工作量。超过这个范围，将会在范围划分和估算上出现问题。
Testable可测试的：用户故事只有可测试才可以确认何时完成。如，“软件应易于使用”，这个用户故事是不可测试的，因而开发和测试时也缺少明确的完成标准。
这五条特性中，独立性、价值性、可估算性、可测试性，都是对于传统软件需求划分也适用的。这样结合起来，软件需求也应该满足如下原则：
正确性
完备性
独立性
价值性
可估算性
粒度合适
可测试性
将这七点直接凑在一起，也有些不合逻辑，貌似是在从不同的层面上讨论需求的定义原则。使用下图可以对其分类整理，可以从内容、粒度、价值属性、可测试性四个维度对其进行约束。
图1 软件需求定义原则
内容维度：正确、完整且相互独立无依赖；
粒度维度：粒度合适，可估算（不存在无法估算或估算可能极其不准确的需求）；
价值属性：对用户有价值的需求，才值得实现；
可测试性：可测试性定义了需求实现的判定准则和工作范围，如果无法判断是否实现，即缺少明确的工作范围定义，后期可能导致项目的范围蔓延。
网友评论