As project teams grapple with the challenge of capturing and communicating functional requirements in a manner that is accessible and clear to both business and technical audiences, a number of requirements modelling techniques have emerged to assist in overcoming this common project hurdle. Techniques such as use cases, user stories and, lately, gherkin acceptance criteria are examples.
Since the emergence of gherkin, one of the key themes I have observed in discussions about the different approaches has been the question – is the use of gherkin and other requirements modelling techniques mutually exclusive, or can certain concepts be applied to tailor an approach that best suits the project need?
It is commonly accepted that a quality requirement is characterised as being precise, unambiguous, and testable.
The approach adopted by requirements modelling techniques to satisfy this definition are varied, and there are a number of perceived limitations to these approaches – quality measures are sometimes ambiguous, or the focus on requirements testability is sometimes at a too high or abstract level are just a few examples.
Gherkin is the latest approach to address these limitations by introducing a requirements model that attempts to closely adhere to the quality requirement definition.
The goal of this post is to critically assess gherkin against traditional requirements modelling approaches.
While some in the industry would argue that the user of gherkin is limited to the Agile sphere, and its application to traditional project methodologies impractical or cumbersome to derive benefit, the focus of this post is to is to critically assess gherkin against traditional requirements modelling approaches and explore whether gherkin can be used to compliment an existing requirements model, or if it is indeed limited and mutually exclusive.
To quickly recap, the core objective at the heart of gherkin is to communicate functional requirements in a way that business audiences will be able to understand the functionality being delivered at a level they can relate to. At the same time, gherkin looks to provide enough detail for technical resources to devise a solution that meets the business need.
Gherkin, in my view, does this very well by using common business terminology and descriptions to describe how the system is supposed to work. For example, lets consider a scenario where the developers are working on a requirement to show a message and apply a 10% discount if a user purchases an item whose price is greater than $20:
GIVEN a user has added an [item] to their shopping cart
AND the [item price] is greater than $20
WHEN the user navigates to the “Checkout” page
AND clicks on the “Purchase’ button
THEN the following message will be displayed: “Your purchase is greater than $20. You are entitled to a 10% discount!”
AND a discount rate of 10% will be applied to the [item price]As you can see, not only does this communicate the business requirement clearly using business terminology (apply a 10% discount if a purchased item’s price is greater than $20), it’s also structured in a way that closely resembles how the code would be implemented to satisfy the particular requirement (if a purchased items price is greater than $20, then apply 10% discount to the item price and display a message informing the user of the discount).
Another strength of gherkin is the ease in which requirements can be tested.
This also leads to another strength of gherkin, which is the ease in which requirements can be tested. Gherkin allows for immediate feedback between all interested parties regarding the quality of a requirement – if a set of gherkin acceptance criteria cannot easily express how a system is supposed to work through logical processing steps, or if the process outcome is ambiguous, it is a sign that further analysis and/or refinement is required. The gherkin structure allows for easy integration with automated test suites, which are a powerful tool in ensuring that both application quality and business needs are met.
Using the previous example, it is easy to determine whether a piece of developed functionality has met the business need. In this scenario, if the item price is greater than $20, and no discount is applied, or no discount message is displayed, then the acceptance criteria has failed. With gherkin acceptance criteria representing the minimum set of criteria the business will accept to release the piece of functionality, this can also assist in moving project discussion away from determining whether it is a problem that needs to be fixed to a discussion about the importance of fixing the issue and when it should be fixed.
In comparison, use cases seek to define a model explaining the interactions between actors and the system. Like gherkin, use cases seeks to explain functional requirements in a manner that is both understandable and relevant to the business, while at the same time provide developers with enough context to devise a solution. By understanding the business goals/objectives of the actors through modelling the business process(es), this can be translated by the Business Analyst into a set of use cases. Take the following example:
From this diagram, you can see that there are a number of activities a customer and a sales person can perform. For example, a customer can purchase an item, cancel a purchase or search for an item. On the other hand, a sales person can add, delete as well as ship an item on top of being able to search for an item within the system. Once the system activities have been defined and modelled, use case scenarios can be written, which defines the interactions between the system and the various actors.
The advantage of using use cases is that the system objective and boundary is defined and illustrated from the onset, providing a holistic view of the business requirements. Another key advantage of use cases is that it seeks to identify all possible positive and negative user scenarios, which is documented to avoid ambiguity and ensure that all parties are aware of processing implications in a language that both business and technical staff can understand.
Up to this point, we have covered the strengths of both gherkin and use cases as a means of communicating functional requirements. Each take slightly different approaches to achieve the same goal, while at the same time sharing common characteristics, like encouraging reuse and using business language to explain processes just to name a few. However, each approach has its set of limitations.
With respect to use cases, a limitation with taking this approach is that while use cases describe process flows in a plain language format, they can’t be easily incorporated into automated tests without some translation by developers and/or testers. Another limitation of use cases is the learning curve required to correctly interpret use case documentation from an end user and technical resource perspective, especially for those who are unfamillar with use case notation. While this can be mitigated by adopting a standardised notation for the project, there is still some translation required, with the quality of understanding dependent on the clarity of the use case scenario. Finally, some Agile purists (especially those who practice Extreme Programming), argue that it is too document-centric, which is contradictory to the “just in time” documentation paradigm (focus on delivering working software over documentation).
As for gherkin acceptance criteria, one of the main limitations is that it is often difficult to see the big picture on how the business requirements tie into the developed functionality described in the acceptance criteria. Gherkin is quite good at breaking down and describing requirements at a granular level, however at times, it can be difficult to put all the puzzle pieces together to create the bigger picture. Also, gherkin has a tendency to be more useful when specifying user interactions with a system through a user interfaces – it is easier to describe and verify how something is supposed to work as opposed to something that isn’t readily visible or tangible (eg. batch processing).
So, is gherkin mutually exclusive to other forms of requirements communication? My answer would be no. The strengths of gherkin can be applied to compliment other methods of communicating functional requirements, while the same can also be applied when talking about other approaches and gherkin. The method for communicating requirements between stakeholders and the project team can be and should be tailored to best suit the needs of the project, the stakeholders and the environment.
In a nutshell, gherkin, like other requirements approaches, has its own inherent set of strengths and weaknesses. The key to project success does not lie in selecting one approach over another. Rather, it is about understanding the needs of all parties involved, and selecting the approach or technique that best meet the project and stakeholder needs. Gherkin is one tool that a Business Analyst can utilise to help ensure that stakeholders have a clear understanding of the system requirements. It is one of various requirements modelling techniques available that can be used to help achieve the project goal of delivering a quality system that meets the needs of its stakeholders.
