1

我试图了解 SBE 在哪里补充或替换了传统的需求文档。需求层次图显示了传统软件需求的三个层次。

SBE 替换了以下哪些项目(来自图表)以及它补充了哪些项目:

  • 愿景和范围文件
    • 业务需求
  • 用例文档
    • 用户要求
    • 商业规则
  • 软件需求规范
    • 系统要求
    • 功能要求
    • 质量属性
    • 外部接口
    • 约束

我对 SBE 的幼稚理解会说 SBE 只是软件需求规范的另一种形式。这个对吗?

4

1 回答 1

1

BDD 和 SBE 通常由敏捷团队使用,他们不像传统软件开发团队那样关注文档。

BDD 是在对话中使用示例来说明行为的艺术。然后,SBE 使用示例作为指定您决定解决的行为的一种方式(我一直认为它是 BDD 的一个子集,因为通过示例讨论通常最终会消除范围、发现不确定性或找到不同的选项,但没有一个最终作为规格)。

有几件事很难用 BDD 做。其中之一是本质上不是离散的,或者在系统的整个生命周期中需要始终为真的东西——非功能性、质量属性、约束等。很难通过这些例子来讨论。需求的这些连续方面更适合监控,而且是离散的,因此甚至可以使用 BDD 来帮助管理这些方面。

由于最初的愿景通常是为了帮助公司赚钱、省钱或保护现有收入(例如,阻止客户去别处),你甚至可以想出项目将如何做到这一点的例子。事实上,如果你做不到,这个项目无论如何都可能失败。因此,BDD / SBE 也可用于帮助补充初始愿景和范围。

因此,BDD / SBE 可以补充所有这些文档,并且在敏捷团队中,文档本身通常被关于需求和规则的对话(通过示例说明)、代表这些对话的占位符的故事卡,也许还有一些轻量级的捕获维基上的那些对话。

任何敏捷团队都不太可能预先捕获所有示例,因为这会导致对需求的过度投资,并倾向于将其转变为传统的瀑布/SDLC 项目。

我写的这篇关于 BDD in the Large 的博文可能也很有趣。

于 2014-01-28T13:19:19.090 回答