Back in January I listened to a .NET Rocks episode that discussed a method of building software that I had not heard of before.  It’s called Behaviour Driven Development or BDD.  As I listened to the episode I was intrigued by the approach and decided I had to learn more about the subject.  The more I read and the better my understanding of the concepts, the more I was convinced that I need to try this method out on a project.

I have done just that and have come to the realization that Behaviour Driven Development provides a simple and effective way to capture software requirements.  So, what does a behaviour look like.  A behaviour can be defined in the following manor.

Given [some initial context],
When [an event occurs],
Then [ensure some outcome(s)].

The beauty of this format is that it describes software the way it actually functions.  When I click some button, navigate to some page, submit some form then I should see, or I should be able to … whatever, you get the point.  The template describes software the way we use it and more importantly, the way we code it.  Because of this, behaviours are highly testable.  So, if you prescribe to Test Driven Development, when sitting down to knock off your first test you don’t have to figure out where to start or how to convert whatever requirement you have into something that is actually testable.

One problem I found while attempting to describe software as a set of behaviours was that they seems to be too detailed and did not facilitate discussion that easily.  One suggestion that I came across during my research discussed using User Stories as the actual feature narrative and behaviours to describe all the relevant scenarios of that feature.  This has turned out to be a brilliant combination.

So, let’s review the format for a User Story quickly so we can see how they work in concert.  A User Story can be defined in the following manor.

As a [role],
I want [to perform some action],
So that [I can get some desired result].

Describing features using this template is a very natural way to start a conversation.  Who are you, what do you want to do and why do you want to do it.  I have found that User Stories are great for getting the high level feature set for an application.  What they are not good at though are the details or the how.  Behaviours, on the other hand, are perfectly suited to answer how software will actually accomplish the goals outlined by a user story.

So, user stories accompanied by a series of behaviour scenarios can allow you to describe and build the system in a natural and intuitive way.

If you are interested in learning more about BDD here are a few articles that I found helpful.

• Introducing BDD
• What’s in a Story?
• CODE Magazine – Article: Behavior-Driven Development
• User Story is Worthless, Behavior is What We Need

Also, I will be writing another post in the near future where I will show some examples and start into some tooling options that can make you experience with BDD even better.