“This feature is not correct. The process should be done biweekly – twice a week,” - The analyst said, “This is totally different from the feature I requested.”

This was the second demo meeting held with the business analyst to show this new feature and it was the second rejection.


“We thought ‘biweekly’ meant every two weeks,” The programmer said, “We tried to follow verbatim every requirement in the user story, but it seems it has ambiguities in some parts.”

“Fair enough, I’ll revisit it and try to correct any ambiguity” - The analyst agreed.

What’s the cost of this kind of misinterpretations? What can we do to avoid them?

The reason why we don’t use plain english to write code is because it can cause ambiguities that makes it difficult to read.

Software specifications are written mostly in english – so when interpreters (or programmers) try to process them, we sometimes end up with a software misbehavior.

Behavior-Driven Development is a process that intends to solve this kind of problems by providing a common language that a business analyst and a computer can read and process.

There are several tools, like Cucumber, that can be used to implement BDD. Cucumber is a framework that provides a common language used to write software specifications.

Cucumber allows users to create feature files that analysts can use to write specifications and define the behaviour of new features as well as the entire system.

Likewise, these files can be read by a computer and can be used to execute functional tests in order to find out if a particular behaviour is being executed correctly.

The main purpose of BDD is to solve communication problems inside a software development team.

Moreover, we can use this tool in an interesting way when the specifications are defined prior the development of a new feature.

By having all the specifications defined previously, we can test anytime if our current development is meeting these requirements.

We can also test if we are breaking existing functionality.

BDD allows software development teams keep one source of truth that enables the team agreed on the real intention and purpose of any old and new feature.

Teams can finally stop having misinterpretations and communication problems when delivering new functionality.