在哪里通过示例补充/替换传统的需求文档?

时间:2014-01-28 10:10:47

标签: bdd specifications atdd

我试图了解SBE的补充或替代传统的需求文档。图levels of requirements显示了传统软件需求的三个级别。

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

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

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

1 个答案:

答案 0 :(得分:1)

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

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

有很多事情很难用BDD做。其中一个是任何本质上不离散的,或者在系统的整个生命周期中始终都是真的 - 非功能,质量属性,约束等等。这很难说话这些例子。需求的这些连续方面更适合监控,而且这是离散的,因此BDD甚至可以用来帮助管理这些。

由于最初的愿景通常是为了帮助公司赚钱,省钱或保护现有收入(例如阻止客户去其他地方),您甚至可以提出项目如何实现这一目标的示例。事实上,如果你不能,该项目可能无论如何都会失败。因此,BDD / SBE也可用于帮助补充初始愿景和范围。

因此,BDD / SBE可以补充所有这些文档,而在敏捷团队中,文档本身通常由关于需求和规则的对话(由示例说明),代表占位符的故事卡代替,也许在Wiki上轻松捕获这些对话。

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

This blog post I wrote about BDD in the Large也可能是有意义的。