OVERVIEW: ARE REQUIREMENT DOCUMENTS DEAD?
Let me put it this way “Do users actually read the requirement documents to use it in the manner it is intended for?” In this generation of Agile, SCRUM and other faster than ever technologies, do you still have the burden of creating a functional specification document detailing each and every screen element? Does your Subject Matter Expert have the time to read the entire document and provide the feedback within the stipulated timelines? With Twitter like mindset can requirements be communicated completed and approved in 140 characters or less? How do you write less and still get approval on requirements?
The answer: Yes, can be done and like any other change this one also requires a paradigm shift.
Atomic use cases and Gherkin are some of the concepts which will help in this requirements maze.
WHAT ARE ATOMIC USE CASES?
A concept introduced in 2003 by Kinh Nguyen, Tharam Dillon from La Trobe University University of Technology Sydney, Australia, as the name suggests it is the basic, core and single action/ step carried out by an actor. It has three main and important characteristics:
- Is very unique building block and cannot be further broken down
- Effects a change in the system/ application
- Has a binary outcome
The advantages of having details at such level are:
- Clear relationship between business layer and User interface layer
- Simplified Traceability
- Highly granular
- Easily Verifiable
- Easy to understand by all stakeholders especially developers
Now a question may arise, that if such detail has to be provided how can one expect a smaller requirements document? How can this simplify things, won’t it be even more tedious?
For this reason, we take help of two things:
- Evergreen rules: By creating the use case / business rules catalogue which will never change unless there is a change in regulation. For e.g. for withdrawing money from an ATM, the user will always have provide identification that the user is the rightful owner and can withdraw the money. This forms the core functionality. Experienced Business Analysts can create such evergreen rulebook as a reference document which can be reused recycled across multiple clients.
- Visual aids: As the saying goes and advocated by Industry practitioners “A picture is worth a 1k words”. There are many tools available in the market for visually representing the use cases and the UI itself. Screens/ wireframes/ mock-ups all these are now created more and more by Business analysts. There is a very thin and diminishing line between an Information architect and business analyst. Barring the aesthetic sense of the UI elements, BAs are expected to know how the “look feel” of the application should be.
While working on BPM projects, I have come across two such tools promoted by two leading BPM product companies which highly promote both the concepts mentioned.
One of the product companies, has been championing the idea of DCO or Direct capture of objectives which is the based on atomic use cases. Within DCO, it gives the ability to create a set of predefined use cases and also empowers the Business process analyst to create a visual by providing UI tools. This indirectly cuts down the development effort as all the screens created are used directly by the development team with some minor changes of course.
While the other product company provides the business users with a “touch” based modelling table so that users themselves can create the process flow with a little bit of training. With the concept of Subject oriented BPM, this product company uses only 5 symbols to define every process. Strategy is to keep business stakeholders interested and is based a little on the concept of gamification.
What is Gherkin?
Gherkin is a business readable and testable language for capturing requirements. It is a behavior driven development methodology which allows developers and business analysts to collaborate in the application development. Introduced in 2007 by Dan North and team, the business analysts are expected to write the story in English from which application development team can map to the steps in the actual code. For writing the story it uses four keywords: “Given, When, Then And” syntax for every business scenario.
As an illustration: If I want to withdraw money from an ATM machine.
Title: Withdraw money from ATM machine
As a person who needs cash
I want: withdraw money
Scenario: Withdraw cash from ATM machine
Given: I have inserted the Debit card into the ATM machine
And: I have entered the ATM PIN into the ATM machine
And: I have entered the amount to be withdrawn into the ATM machine
When: I press the Confirmation button
Then: the amount should be deducted from my balance
And: ATM machine should give me the cash withdrawn
Once such scenario based user stories are created it also helps the testing/ QA team to create required test cases. One thing to note here is the term “Gherkin” itself is specific to the software tools Cucumber and JBehave.
The advantages of creating such user stories are:
- Helps in deriving the complexity based on the data, features required and also the scenario
- Very intuitive
- Easy to understand as it is more like a story narrative
- Excellent tool while during brainstorming sessions with business stakeholders
- Will help in scoping exercises and iterations based on the feedback from team
The fusion process:
Atomic design: The marriage of atomic uses along with Gherkin language creates the “Atomic design”. It is a very useful tool for creating requirements for portals, websites, Apps and other user interactive heavy applications.
Atomic design builds on 5 layers from atoms, molecules, organisms, templates to pages.
The atomic design:
- Is more granular
- Is more collaborative as it is more conversation based
- Helps in identifying the complexity to arrive at accurate estimation
- Allows reuse of atomic use cases for creating various organisms pages
- Creates bottom up approach
- Shows the business users the final context being developed
- They are limited to web design/ portals
- Needs high level of dedication and time from the business stakeholders
- Various methodologies available in the market. Business buy-in required for following the methodology
Based on the application being developed, the requirements methodology can change. For e.g. In case of creating a front end mobile application for banking which is more customer focused has to do more with the User experience. In such cases, the Gherkin or atomic use cases methodology would be highly successful. In contrast, while building a back end application with heavy business rules and numerous calculations would rather be more suited for the traditional way of requirements gathering. Requirements documentation is meant for two main consumers business and developers, and both should understand what is written.
Shyam Nandan has more than 10 years of professional experience in Financial Services domain including 8 years in Business analysis. He has worked in various Business Analysis methodologies like RUP, UML and in BPM. He has played multiple roles during his tenure as a Process analyst, requirements owner, account level Business analyst, functional consultant and as a Requirements manager. For BAs “Change is the only constant in life”.
Powered by Facebook Comments