Monday, February 22, 2010

Use Casing with Your Clients - BDD or Given, When, Then...

Sitting at home, feeling sorry for myself as I am off work sick, I thought I might write a short blog post on using Behavioural Driven Development (BDD) for Requirements work with clients - a technique which I am starting to use with some (note the qualification) success.

I'm a big fan of use casing "As is" models and "To be" models to get a really nice sense of the contexts in which a system is supposed to work (and by system, I mean people, process and technologies), but this can be hugely tough unless you are working with clients who are formal, systematic, logic-driven thinkers.

And this is how I stumbled upon Dan North's BDD - as a way of reducing the formal use case methodologies (pre- and post-conditions et al.) into a very simple story formulation.
Feature: As a stakeholder, I need a something, in order to meet my goal (High level business requirement - main system "features")
Scenario: Given a starting context, when something happens to change this context, then this should be the result. (Lower-level scenario and low-level "feature" descriptions).
Note: I write "feature" as feature is a controlled word in BDD.

The greater joy of this technique is that it effectively shrinks the distance between what the client says he wants, and what your technical team is capable of delivering back to satisfy these requirements. Why? Well, as this fine blog post points out, it is because this is a business language way of describing states, event triggers and test conditions. Even more importantly, through the use of JBehave or Cucumber with Automated Testing tools like Selenium, your developers can start by writing failing tests for your requirements (requirements-driven, test-driven development), and then - if it is worth the overhead - write automated functional and acceptance tests.

I'm desperate to get this rolling from Business Contact through Business Analyst to Developers and Testers within the company I work at - but I wondered if anyone else has gone ahead and implemented this fully as an end-to-end requirements and development methodology. In the meantime, I'll get my act together and make a couple of posts (when I'm feeling better) as to a few workshop techniques which work nicely for the client-end of BDD.