我试图了解 SBE 在哪里补充或替代了传统的需求文档。图levels of requirements 显示了三个级别的传统软件需求。
SBE 替换了以下哪些项目（来自图表）以及哪些项目是补充：
我对 SBE 的幼稚理解会说 SBE 只是软件需求规范的另一种形式。这是正确的吗？
【问题讨论】：
标签： bdd specifications atdd
敏捷团队通常使用 BDD 和 SBE，他们不像传统软件开发团队那样关注文档。
BDD 是在对话中使用示例来说明行为的艺术。然后，SBE 使用示例作为指定您决定解决的行为的一种方式（我一直认为它是 BDD 的一个子集，因为通过示例讨论通常最终会消除范围、发现不确定性或找到不同的选项，其中没有一个最终成为规范）。
有几件事很难用 BDD 完成。其中之一是本质上不是离散的，或者需要在系统的整个生命周期中始终为真的任何东西 - 非功能性、质量属性、约束等。很难说清楚这些例子。需求的这些连续方面更适合监控，这是离散的，因此甚至可以使用 BDD 来帮助管理这些方面。
由于创建初始愿景通常是为了帮助公司赚钱、省钱或保护现有收入（例如，阻止客户去别处），您甚至可以想出项目将如何做到这一点的示例。事实上，如果你做不到，这个项目无论如何都可能失败。因此，BDD / SBE 也可用于帮助补充初始愿景和范围。
因此，BDD / SBE 可以补充所有这些文档，并且在敏捷团队中，文档本身通常被关于需求和规则的对话（以示例说明）、代表这些对话的占位符的故事卡取代，也许对 Wiki 上这些对话的一些轻量级捕获。
任何敏捷团队都不太可能预先捕获所有示例，因为这会导致对需求的过度投资，并倾向于将其转变为传统的瀑布/SDLC 项目。
【讨论】：