Below is a typical scenario at software companies with poor QA system
“This is the new business requirement, go get started…”
⬇️
“The design, engineering teams come back with questions as they implement”
⬇️
“This to & fro journey between requirement clarification and dev/ test teams goes on in an (almost) endless cycle till the feature reaches the end customers”
⬇️
“All this hurry to get the feature implemented without breaking down the requirements was to get the feature delivered fast!”
⬇️
“Ironically you invest/waste (depends on the way you want to look at it) more time in this to & fro journey, leave alone the higher number of bugs you encounter during the SDLC phase or even by your customers!”
Here are the steps that we follow as a team and save a lot of time and $$ by investing a few extra hours in the requirement analysis phase. Try this and I can guarantee you that you can enjoy the same benefits!
Breaking down a requirement is like logically dividing it into saying stories wherein each story constitutes a group of statements. These stories tell you what value it provides and how will it be delivered to the end customer.
The stories should satisfy below:
They are a set of rules. Eg these rules should help us to design the process to achieve the expected business outcome
Should not be ambiguous
Should be solution agnostic
Should help you to measure success when the stories are fulfilled
They have to be predictable (should be able to answer questions like when, how, and how much)
You should have control over the stories
For one of the products, we are following the “Given-When-Then” style of breaking down the requirements. We also have a custom “Continous Improvement” mechanism that complements this process to make it more mature and robust with each passing sprint/cycle
In this way, you can assure your product quality from the requirement phase.
I am sure this will help you. You are welcome to write me if any questions/ suggestions at prashant@pristineprotech.com