Behaviour Driven Development

Behaviour Driven Development

I've been attempting to use some more agile processes at work recently, and today I had an opportunity to put into practice some user story paradigms. Behaviour Driven Development (sometimes also called Business Driven Development, and in both cases shortened frequently to BDD) attempts to clearly define the requirements of a solution without specifying the implementation of a solution. This allows your analyst to focus on understanding the needs of the client in language that is meaningful to everybody in the process (including, critically, non-technical stakeholders) and affords your engineers the freedom to determine the best implementation.

It uses a story card format to define a high-level requirement with the familiar "As an… I would… so that…" format. The practice then deviates by expanding that user story into more granular scenarios. It still keeps a natural language focus; plain English should be used at each stage. These requirements should be above all other concerns easy to understand.

Scenarios follow the format "Given… when… then… and…" — A presumed circumstance, an action, and a number of expected results. You keep adding scenarios until you have covered all the potential situations you can discover, and of course these can be expanded on in later development cycles.

The situation I was given was very simple. We need an automated method to find duplicate indices in an Excel spreadsheet. I am no master of Agile development methodologies and am strictly speaking a developer and not an analyst, however, below is my finalised user story.


As an analyst
I would like to automate the process of finding duplicate entries in a range of columns in a customer provided spreadsheet prior to commencement of development work
So that I can eliminate specific defects earlier in the development cycle.

Scenario 1: The file is in the expected Excel format
Given that the source file is in the anticipated format
When I execute the solution on the source file
Then the tool should be able to detect duplicate entries in the specified range of columns
And output the results to the user

Scenario 2: The file is incompatible
Given that the source file is not in an anticipated format
When I execute the solution on the source file
Then the tool should provide a meaningful error message

Scenario 3: No duplication is detected
Given that no duplication is present in the source file
When I execute the solution on the source file
Then the tool should clearly report that no duplication is present
And provide that output in a format that can be attached to a JIRA ticket

Scenario 4: Duplication is detected
Given that there are duplicate entries in the source file
When I execute the solution on the source file
Then the tool should identify each instance of duplication
And provide a visual report of those duplications
And provide their positions in the file
And provide that output in a format that can be attached to a JIRA ticket
And provide that output in a format that can be presented to the customer


I love this kind of process. The format sometimes feels a little bit clumsy or it asks you to specify things that feel too obvious. Sometimes that's a benefit, more often than not it's just a result of the process catering for a wider set of needs than your immediate concern. I love when requirements for a technical problem are presented in natural language as opposed to jargon; It's actually clearer, and communicates fewer preconceptions and biases that might influence the implementation of the solution and impede imagination. I love that you could put this under the nose of anyone who's even passingly familiar with spreadsheets and they'd understand what you wanted to do.

Writing a requirement in a structured format also influences the way you approach that problem. You are directed to be methodical and to break the task down into it's smallest, meaningful constituent actions — which is of course a core principle of rapid iterative development practices such as Agile methodologies.

Performative Social Media

Performative Social Media

Finding Apple

Finding Apple