我正在尝试了解SBE的补充或取代传统要求文档。需求级别显示了三个级别的传统软件要求。
以下哪个项目（从图中）进行了替换，哪些项目补充了：
- 视觉和范围文件
- 业务需求
- 用例文档
- 用户要求
- 业务规则
- 软件需求规范
- 系统要求
- 功能要求
- 质量属性
- 外部接口
- 约束
我对SBE的天真理解会说SBE只是软件需求规范的另一种形式。这是正确的吗？
bdd和sbe通常由敏捷团队使用，他们的专注于传统软件开发团队的文档。
bdd是在对话中使用示例来说明行为的艺术。然后，SBE将示例用作指定您决定解决的行为的一种方式（我总是将其视为BDD的一个子集，因为通过示例进行交谈通常最终会消除范围，发现不确定性或发现不同的选项，没有哪一个最终作为规格）。
BDD很难做几件事。其中之一是本质上不是离散的任何东西，或者需要在系统的整个生命中始终始终是正确的 - 非功能，质量属性，约束等。这些例子。需求的这些连续方面更适合监视，这是离散的，因此BDD甚至可以用来帮助管理这些。
通常会创建最初的愿景，以帮助公司赚钱，省钱或保护现有收入（例如，停止客户去其他地方），您甚至可以提出有关该项目将如何做到这一点的示例。实际上，如果您不能，那么该项目可能会失败。因此，BDD/SBE也可以用来帮助补充初始视觉和范围。
因此，bdd/sbe可以补充所有这些文件，在敏捷的团队中，文档本身通常会被有关要求和规则的对话所取代（示例说明），故事卡以代表这些对话的占位符，甚至可能在Wiki上对这些对话的轻量级捕获。
任何敏捷团队不太可能捕获其所有示例，因为这会导致对需求的过度投资，并且倾向于将其转变为传统的瀑布/SDLC项目。
我写的关于BDD的博客文章也可能很感兴趣。