Collecting requirements for a project is a complicated process. If you don’t do it right, you can waste both money and time. Customers who start working with software development company often have problems with specifying their needs. To avoid communication failure when getting on a project – no matter if you are a customer or a contractor – learn how to use Gherkin to collect the requirements!

Requirements Engineering Analysis

Defining the business problem – this is the first step of the Requirements Engineering Analysis. In this task, we should not focus on the details but rather think about the problem globally. Here is an example of a well-posed problem:

“It is becoming increasingly difficult to find qualified specialists for the ICT sector”

The second step is to create a solution to this problem. It can be a service, a product or even a process. Following on, the example of a solution to the problem posed earlier could be:

“Creating SkillHunt.io application – a recruitment platform allowing its users to get a high reward for referring a job to his or her friend”

At this stage, the details are needless. If we evaluate the idea, conduct market research and it turns out that our solution has a business justification, we can start collecting the requirements. To make sure they fulfill their function, we should check if they meet the 3 main criteria. They need to be:

Explicit and unambiguous
Understandable for all the stakeholders,
Up-to-date and documented.

To make the process of collecting requirements easier and to meet all the presented criteria, we can use the Gherkin language. It is a natural language which can be useful both to business analysts collecting the requirements and to developers creating the scenarios for functional tests.

Speak Gherkin fluently

The record of requirements in Gherkin is unambiguous, explicit, and – what’s most important – easy to understand for all the parties involved. Because of that, the discussion about the requirements is actually possible.

Just like every other language, Gherkin has its syntax. It has some specific structure, some keywords have to appear. Here is how it looks:

Feature: Logout from application
Scenario: 
   Given I am logged in
   When I click “log out” button
   Then I am informed about successful logout
   And I am redirected to login page

The requirements collected in Gherkin are saved to a .feature file. Thanks to that, the developers can easily use these files for writing automated tests in BDD (Behavior-driven development) using Cucumber.

When we want to create a new requirements description, we need to define the Feature which gives us the name of a new functionality. Then, we go ahead with writing the Scenario. It’s worth to mention that one file can contain more than one scenario. Each scenario consists of three main steps: Given, When, and Then. The description following the word Given sets the preconditions, When defines the actions that take place at the particular functionality and Then describes the expected outcome of the action. In the example presented above, there is one more keyword: And which continues the method that it follows. Therefore, when listed after When, it would continue this section and define another action. Gherkin knows one more keyword: But – but, to be honest, in my whole career as a Project Manager, I have never found a situation when it could be applied.

Becoming fluent

Take a look at the example in which the user is logged in in each of the scenarios:

Feature: Select profile
Background: 
   Given I am logged in 

Scenario: First profile select 
   Given I go to application after logging
   When I am asked which profile I would like to choose from my list
   And I select profile from list 
   Then I see dashboard for this profile

Scenario: Next profile select
   Given I am on dashboard
   And I have selected profile
   When I select  from dropdown with list
   Then I see dashboard for this

Moreover, if we want to discuss the requirements and, in the future, test more than one scenario, it is worth to use some examples – using the Example function. Collecting data in this form is often the most unambiguous. To use Example, we need to put the variable inside angle brackets <> and put the tables below the scenario. We need to remember that if we use examples, our scenarios should be named Scenario Outline. The following example should make it clear:

Feature: Login to application
Background:
   Given I am a registered user
   And my account is activated

Scenario Outline: Successful login
   Given I am on login page
   When I fill "login" with 
   And I fill "password" with       
   And I click "Login" button
   Then I am redirected to page with profile select

Examples: 
   | login  | correct-password |
   | Lukasz | Gh3rk1n          |
   | Arek   | Cucumb3r         |

Scenario Outline: Unsuccessful login
   Given I am on login page
   When I fill "login" with 
   And I fill "password" with       
   And click "Login" button
   Then I am informed about unsuccessful login

Examples: 
   | login    | incorrect-password |
   | Lukasz   | Gherkin            |
   | Arek     | Cucumber           |

Scenario: Unauthorized entry
   Given I am not logged in
   When I try to go Dashboard page
   Then I am redirected to login page

Of course, in agile projects, the requirements are changing. It is necessary to apply changes in the .feature files and therefore – the on-going changes in application tests. This way we can keep our documentation up-to-date. Completing the tasks in compliance with the scenarios results in delivering up and running elements that perfectly fit with the principles of the Agile management.

Articles by Łukasz Nowacki

Price Estimate for Web and Mobile Applications

Speak Gherkin And Learn How To Collect Requirements For Your Project