How To Generate Requirements From Use Cases

In earlier posts, I wrote about user stories that can help capture users’ 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 and use cases into requirements; then our engineering team is doomed for failure.

Why Generating Requirements are Important?

Because requirements that were being tracked to completion before shipping was not completely and correctly comprehended, in spite of having good user stories and use cases.

Hence, it is a very simple but important step where you should get the final requirements correct down to the last detail. I could have used the term “write” or “create” requirements from use cases; as I did for my post on 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 the 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 understanding use case requirements and how to generate one.

What Are the Use Case Requirements?

Please take 30 seconds and try to put it in words; what is meant by the term “requirements”?

Time yourself! I am waiting.

Tough! Isn’t it?

Exactly!

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.

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 the same page and mutual mental understanding remains.

There we developed a user story for John, our user, who wanted to feel fresh and energized even after 12-14 Hrs. of the work day. And based on that, we developed some use cases; remember?

See the post here.

Listing some use cases again here for ease.

Use case 1: The user wants to have a premium quality feel when he/she takes the toothpaste tube in hand before brushing.
Use case 2: The user gently squeezes the tube and he is pleased with the smoothness of the paste flow out of this tube.
Use case 3: The 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, the 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 a 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 depict the 1, 2, and 3 requirements for use case 1.

2) Requirement description as we know is a clear concise sentence of fewer than 10 words depicting a single unit of demand

3) Use case generated allows the product manager and engineering team to know which use case generated this particular requirement and suppose, down the line if the 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 it 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: The 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: The 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!

Enhance your skills with our unique business intelligence training courses. Boost your knowledge gaining the skills to drive successful projects.