BDD: Executable Requirements


The problem

It doesn’t matter if your background is Agile, Iterative, Waterfall or Traditional. One thing is certain and we all agree: Excellent requirements combined with perfectly executed architecture is a great formula for success. At a first glance, the formula is simple… and it is! The problem is in the execution. How do we know we are being too heavy handed on requirements and design? In order words: how deep (or shallow) must the requirements be in order to be enough and how much design is needed for a perfect fit between business and technology?

The right amount of each ingredient of this formula has been haunting the development community since COBOL times and is still relevant in our Internet/Cloud/.Net/Java/Ruby/Python/PHP days… the mystery must be solved!

A solution

One solution to this dilemma can be found in agile methodologies. If you ask an agile methodologist the ingredient question, the answer will be, in most cases: avoid BDUF (Big Design Up Front). And it makes sense. One of the characteristics of requirements is that they tend to change. So if you take too much time in defining your requirements and architecture, as soon as you are ready to start implementing… guess what? Those pesky requirements decided to change!

So that’s a good start! Avoid BDUF! But that’s not a prescriptive approach, it’s restrictive. It’s great to know what we should NOT do. But what SHOULD we do? Well… again, agilists will say: TDD is the way, my brother … go forth and test first! Again… another great directive… and that’s very prescriptive… but is it complete? Hmmm… I’ll have to answer: no. Unfortunately, knowing that tests should be written before the actual implementation is part of the “path to perfection”. TDD is fantastic, I agree wholeheartedly. It practically forces the developer to write code using decoupled components. If the architecture follows industry-proven best practices, design patterns and good old common sense, it’s even better.  But one last question remains: WHAT should we test?

Do I see some hands raised in the audience? Oh, you, sir, please go ahead:

- Well, Daniel, of course. The answer is in the requirements. The developer should look up the requirements, understand the business need and design the tests accordingly.

Very well! That’s an excellent suggestion. But there’s a catch. It lies in the following word combination: “understand the business need”. Developers are, generally, a homogeneously Cartesian group of individuals. We live in a world of “0s” and “1s”, “Trues” and “Falses”, “ifs” and “elses”. Business level requirements may clearly identify a client need, but if they are not very carefully worded, ambiguity proliferates and the result may be like the age old, but too true “tire swing” cartoon.

Oh… and another catch: what about traceability? Which sentence of a classic requirement specification (set of) paragraphs traces to the code that needs to be reviewed whenever something changes? Tough, eh?

The solution

Well, several approaches to define unambiguous, verifiable, attainable and specific requirements have been subject of numerous papers, methodologies and frameworks. From now on, I’ll focus on a framework/methodology that has been working amazingly well in my experience: Behavior Driven Development (or BDD). BDD tries to bridge the gap between requirements analysts and developers by specifying a well defined “language”. This “language” is, at the same time, natural and specific. It is clearly understood by both business and technical-type stakeholders and describes system behavior. Here’s an example:

Feature: Order Placement	
  In order to purchase an item
  As a customer
  I want to be able to place orders

: Add item to cart
I have selected an item
I have provided its quantity
I press the "add to cart" button
the item should be added to the cart
And the cart's total amount should be incremented by the selected item quantity multiplied by its price

It surely looks unambiguous, verifiable, attainable and specific enough, doesn’t it?

What if each one of those scenario lines became a specific step in a test case, from which architecture and code would be derived, a-la TDD? Wouldn’t it be fantastic? That’s exactly what BDD is about.

Next steps

I think this is just enough information to justify a couple of (near) future entries that will further clarify and exemplify BDD. Those entries will be a bit biased, though. Since my background is basically .Net, I will provide examples in C# using a beautifully implemented .Net-specific Cucumber-based BDD implementation: Specflow, an open source project sponsored by TechTalk.

See you in a bit!

0 comentários: