1. Home
2. Blog
3. Behavior Driven Development with JUnit 5. Part 2

From requirements analysis to acceptance criteria

For the company using the flight-management application, one business goal that we can formulate is “Increase sales by providing higher quality overall flight services.” This is a very general goal, and it can be detailed through requirements:

 

• Provide an interactive application to choose flights.
• Provide an interactive application to change flights.
• Provide an interactive application to calculate the shortest route between source and destination.

 

To make the customer happy, the features generated by the requirements analysis need to achieve the customer business goals or deliver business value. The initial ideas need to be described in more detail. One way to describe the previous requirements would be

 

As a passenger

I want to know the flights for a given destination within a given period of time

So that I can choose the flight(s) that suit(s) my needs

or

As a passenger

I want to be able to change my initial flight(s) to a different one(s)

So that I can follow the changes in my schedule

A feature like “I can choose the flights that suit my needs” might be too large to be implemented at once—so, it must be divided. You may also want to get some feedback while passing through the milestones of the implementation of a feature.

The previous feature may be broken into smaller stories, such as the following:

Find the direct flights that suit my needs (if any).

Find the alternatives of flights with stopovers that suit my needs.

Find the one-way flights that suit my needs.

Find the there and back flights that suit my needs.

 

Generally, particular examples are used as acceptance criteria. Acceptance criteria express what will make the stakeholder agree that the application is working as expected. In BDD, acceptance criteria are defined using the Given/When/Then keywords: 

 

Given <a context>

When <an action occurs>

Then <expect a result>

Here’s a concrete example:

Given the flights operated by the company

When I want to travel from Bucharest to London next Wednesday

Then I should be provided 2 possible flights: 10:35 and 16:20

 

 

BDD benefits and challenges

Here are some benefits of the BDD approach:

 

• Addresses user needs—Users care less about the implementation and are mainly interested in application functionality. Working BDD style, we get closer to addressing these needs.
  
• Provides clarity—Scenarios clarify what software should do. They are described in simple language that is easy for technical and non-technical people to understand. Ambiguities can be clarified by analyzing the scenario or by adding another scenario.
  
• Supports change—Scenarios represent part of the software documentation: it’s living documentation, as it evolves simultaneously with the application. It also helps locate incoming changes. Automated acceptance tests hinder the introduction of regressions when new changes are introduced.
  
• Supports automation—Scenarios can be transformed into automated tests, as the steps of the scenario are already defined.
  
• Focuses on adding business value—BDD prevents the introduction of features that are not useful to the project. We can also prioritize functionalities.
  
• Reduces costs—Prioritizing the importance of functionalities and avoiding unnecessary ones will prevent wasting resources and concentrate these resources to do exactly what is needed
  

 

The challenges of BDD are that it requires engagement, strong collaboration, interaction, direct communication, and constant feedback. This may be a challenge for some people and, in the context of present-day globalization and distributed teams, may require language skills and managing time zones.

Tudose, Florin-Catalin Tudose

Java Champion; Java Chapter Lead; Author at Pluralsight and Manning