In earlier posts, I wrote about user stories that can help capture user’s requirements holistically and encompass the needs of your customers; I also wrote that user stories should then lead to use cases enabling your engineering team to get something concrete on paper for building.
This is the third and final post in this series: How to generate requirements from use cases.
The simplicity of this task can be misleading.
If we, as project managers or product managers, fail to accurately translate our refined and well understood user stories, use cases into requirements; then our engineering team is doomed for failure.
Because requirements that were being tracked to completion before shipping were not completely and correctly comprehended, in spite of having good user stories and use cases.
Hence, it is very simple but an important step where you should get final requirements correct down to the last detail.
I could have used the term “write” or “create” requirements from use cases; like I did for my post of Use cases but I chose to use the term “generate”.
Because your product or feature requirements should organically arise out of use cases and you only need to start the documentation process to have them recorded; assuming you have done your job correctly.
Before proceeding, I humbly request you to please read and understand earlier two posts on “how to work with user stories” and “Use Cases - How they are different from user stories and how to create them”. And feel free to raise questions to me by replying to the comments or emailing me directly.
Now, assuming that you have read those two articles; let us begin on the last stretch of this journey.
What are requirements?
Please take 30 seconds and try to put in words; what is meant by the term “requirements”?
Time yourself! I am waiting.
Tough! Isn’t it?
Because while we all intrinsically know what requirements mean, we are not able to put them into words and whatever can’t be put into words, can’t be explained to the audience.
Unless we have a way to put our requirements into words exactly the way we understand them intrinsically, we will not succeed in our goals.
To begin with, I define requirements as a clear concise sentence of not more than 10 words specifying the most singular unit of demand.
A simple example of generating requirements from use cases:
Let’s continue with the same toothpaste development example from my use cases post so that we all are on same page and mutual mental understanding remains.
There we had developed a user story for John, our user, who wanted to feel fresh and energized even after 12-14 Hrs. of work day. And based on that, we had developed some use cases; remember?
See the post here.
Listing some use cases again here for ease.
Use case 1: User wants to have a premium quality feel when he/she takes the toothpaste tube in hand before brushing.
Use case 2: User gently squeezes the tube and he is pleased with the smoothness of the paste flow out of this tube.
Use case 3: User is able to notice the right amount of paste coming out of the tube every time, he/she brushes. It is never too much nor too little. One gentle squeeze always gives out the right amount of paste required for brushing.
Now let us generate requirements out of those.
Always remember, following things while generating requirements:
- Requirements should be concise and should contain only one demand in them.
- A single use case should not be giving rise to more than 2, at max 3, requirements.
- If a use case is able to generate more than 3 requirements then it is a clear sign that this use case is in fact a half-baked user story and needs to be broken down further.
- If a requirement cannot be expressed in less than 10 words then it is a use case in disguise and you need to relook at your user stories once again
- All requirements should have priority.
We will be using tabular format so that we can maintain requirement traceability.
1) Requirement number has to be unique and will be used to track the requirement in various forums, discussions and work breakdown structures. Recommended format for requirement number is X.Y where X refers to the use case number and Y refers to the unique requirement within that use case. For example: 1.1, 1.2, 1.3 and so on to depict 1, 2, 3 requirements for use case 1.
2) Requirement description as we know is a clear concise sentence of less than 10 words depicting a single unit of demand
3) Use case generated from allows the product manager and engineering team to know which use case generated this particular requirement and suppose, down the line if use case or user story undergoes modification then we will clearly know which requirements are impacted and require a review. So it helps in that sense.
4) Business priority is not to be confused with task priority. Every task that is a child of a requirement will have its’ priority depicting the order in which they should be done.
So, let us generate requirements for Use Case 1: “User wants to have a premium quality feel when he/she takes the toothpaste tube in their hand before brushing.”
Now, let us generate requirements for Use Case 2: User gently squeezes the tube and he is pleased with the smoothness of the paste flow out of this tube.
Now, let us generate requirements for Use case 3: User is able to notice the right amount of paste coming out of the tube every time, he/she brushes. It is never too much nor too little. One gentle squeeze always gives out the right amount of paste required for brushing.
And so on you can develop your requirements. I hope you enjoyed this post as much as I did! ☺
All the best!