What I like about BDD is the simple, but powerful concept of Given-When-Then for specifying scenarios. It is a concept you can also use without doing BDD to specify the requirements of your application.

It simply defines the structure of how you write down the requirements in the form of scenarios (as a sidenote: in BDD, a scenario belongs to a feature. For example, a “Login” feature might consist of the scenarios “Login with username/password” and “Login with OpenID”):

Given some initial context (the givens),
When an event occurs,
Then ensure some outcomes.

(from http://dannorth.net/introducing-bdd)

“Given” defines the preconditions, “When” defines what happens, and “Then” defines the result of the scenario. Or in other words: “Given” describes the start state, and “When” the steps necessary to reach the accepting state (= “Then”).

A simple example of a “Publish new article” scenario might look like:

Given I am logged in
When I write an article with the title "My article"
And I publish the article
Then I should see the message "Article published"
And the article "My article" should appear on the homepage

The simplicity of this format makes it easy to discuss the requirements of your application. And thanks to tools like Cucumber you can even make such specifications executable, but that’s something for another post…

[...] to build an application which allows [...] to notify the users of [...] code snippets about updates.

Now it is time to become more concrete and to define what our application is supposed to do. For this purpose I will write some stories/use cases. So here we go:

Creating a project: The user choses to create a new project, enters the project information, and the system creates the project.

Posting a message: The user selects a project and enters the message, which is then published by the system.

Subscribing to a project: The user selects a project and subscribes to it, so that he gets all future messages of the selected project.

Importing an external feed: The user enters the url of an external feed, so that he will get all messages provided by that feed.

There are more use cases like Unsubscribing from a project, but they are not that important at the moment.

So we can move on to identify the conceptual classes and draw the domain model. But that’s a task for tomorrow…