Search

How To Generate Requirements From Use Cases

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. Why? 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”. Why?  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? 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. 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!  

How To Generate Requirements From Use Cases

1K
How To Generate Requirements From Use Cases

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.

Why?
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”.

Why? 
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?

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.

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!
 

Abhinav

Abhinav Gupta

Blog Author

PMP, has 12+ years of experience working in Information technology sector and has worked with companies like Infosys and Microsoft in various capacities. He started his career as a manual tester for a world renowned software product and grew on to become automation champion in both functional as well as UI. He has worked with Healthcare units providing various software solutions to companies in North America and has worked with search engine based groups to enhance their experience and provide more bang for buck to their customers.

Join the Discussion

Your email address will not be published. Required fields are marked *

Suggested Blogs

6 Tips To Write Compelling Business Cases

It’s not that easy to earn the trust of your prospective customers. However, coming up with a compelling business case is how you can earn this kind of trust and faith from your clients. To achieve this, the business case should be captivating to the reader to make them interested and thus, it should involve a lot of creativity and professionalism. Do you want to make your business case compelling to your prospective and existing customers? Can a business case writing really helps you?. Here’re some tips to writing compelling business case 1. Use a Concise and Clear Format First and foremost, it’s important to write a brief and self-explanatory business case. This is because you want your target audience to easily understand the kind of business you want to start. Therefore, you should summarize information about the product or services you want to offer so that it’s clear to your audience. The clients will get interested and may want to seek more information about the business. Secondly, being organized is also very crucial when writing a business case. This is because the clients usually look out for structured businesses. In any case, who would want to peruse an unstructured business case? I wouldn’t either. Furthermore, as long as it’s not well organized, it makes the customers lose interest as they find it very complex to understand. 2. The Writer Should Be Realistic and on Point This means that you should be factual and real. Your content should be genuine and not exaggerated. It’s advisable to use accurate information when writing a business case. This is because a business case can either build your work or destroy it. The business case is meant to make the customers want to invest in the business or to buy a product, so genuineness is a key attribute in any business. The fact that the business case should be compelling does not mean that the writer should use information that’s not reliable. This calls for transparency and accountability. The customers need to believe in the services or products that you’re offering. Being precise in your business case is very important. The customers do not need to go through the whole business case. Making it clear and straightforward makes them want more information. The business case should be captivating in that it should not bore the reader. Hence, it is imperative to make sure the clients can understand what it is that you have to offer in a few words.                                                                                                              3. The Writer Should Write with a Sense of Urgency Creating a sense of urgency is vital when writing a business case. This is because you need to make your prospective clients want to get involved in your business. Urgency is created by making clients realize that they have no option but to use your idea or product. In most cases, urgency makes the customers take action. At some point, it triggers them to invest in the business. For instance, in financial institutions, when urgency is created, it mainly focuses on greater returns. I could give an example of insurance companies. The business cases of such companies are self-explanatory and they work within a certain time frame. A custom writing service can be of good help here. This business case writing course really helps you to attract your customers to get in the business. 4. In Case You Use Figures and Graphs, Ensure that They Are Easy to Understand Most financial business cases use graphs and diagrams to illustrate their idea. It’s very clear that when one sees the graphs and diagrams, they get a clear and good explanation of the business. In my opinion, using graphs and charts also shows how serious the business is. For instance, in online trading, to show the market trend, whether bear or bull, graphs are often used. Other similar figures known as candlesticks are also used to depict the stronger of the two at a particular time. It’s very important to ensure that your charts and figures are self-explanatory and easily understood by your target audience. This could be done by labelling your charts and graphs appropriately in such a way that they do not confuse the reader. Coming up with well-defined graphs for the business case shows an element of organization. The customers are more compelled to deal with an organization that is well coordinated. 5. As a Good Writer, Use Statistics and Verified Data to Convince the Clients Using verified data and statistics is important as it makes the business case appear more credible to the clients. The use of statistics makes the case look more accurate as the figures distinctly show how much is needed or how much is used for an investment. A good business case consists of reliable statistics and data. Everyone wants to invest in a thriving business that’s sustainable. It is, therefore, very important that the business has accurate data and information about the feasibility study. How viable is the business? Are there any chances of survival within the current market? These are some of the questions that the business case should answer. Statistics in the business case should also show the history of the business and how profitable it became with time. This generally creates trust between the investors and the sponsors who are the brains behind its existence.  6. Include Different Types of Information and Other People if They Support Your Case The different types of information could be competitors who are offering a similar kind of service or product. This could make the business case more compelling as there is a comparison of prices, quality, and durability of the products being sold. As a matter of fact, other case studies could also be included in the business case as well as scenarios that could relate to the business. Activities like benchmarking with other companies are also allowed as they bring an element of comparison thus giving a client an opportunity to weigh all the options before they make a decision. It should be noted that the business case is the key driver of the decisions made in your business. Therefore, engaging with other stakeholders is very crucial when writing a compelling business case. Talking to other or potential stakeholders opens up your mind. You are able to understand the interests of the customers and come up with a plan to satisfy their needs. You are also able to understand chances of survival in the market as well as how profitable the business may become. Conclusion The aim of a business case is to answer some of the questions that the customers could have concerning the business. The business case at some point also acts as a perfect marketing strategy. Therefore, coming up with a compelling business case is very important as it brings the customers on board. It also gives you an edge over other businesses who choose not to have one or don’t know about its importance. What is your experience with writing a business case? And how having one has helped you connect more with your customers?
6 Tips To Write Compelling Business Cases

It’s not that easy to earn the trust of your pro... Read More

Business Analysts - Changing How Companies Deal with Change

Working as a business analyst has become one of the most interesting career options for young professionals in recent times. As a business analysis professional, individuals tend to work in organizations helping to work with and manage the changes that take place as well as wade through transitions. They also work to plan for the future in a way that is in line with the corporate goals of the company. This has become a very widely required skillset across industries at every level. The requirements could be for a specific project where you would work as a consultant or even as a permanent feature in the organization as they see the tides of change looming overhead constantly. A thorough understanding of the organization’s current situation is warranted, along with identification of possible future needs and the ability to create nifty solutions that would help meet those very needs. This usually involves the implementation of some kind of information technology or software systems, although this may not always be the case. The high level of specialization and knowledge that this field requires has warranted the need for several PMI-PBA training and PMI PBA certification training programmes which effectively equip professionals with the right tools to work effectively in their capacity as a business analyst. Business analysts are required to demonstrate a highly-detailed knowledge as well as understanding of the way in which the organization is currently working. This includes looking into the sector in which it is currently operating in, as the professional would be helping the organization through developing its functions, products and services in various ways to meet the market demands, internal and external goals in a way that appeases all the stakeholders, no matter which side of the table they may sit on.  This is perhaps why many organizations insist that professionals take up a PBA training programme for a certification so that they know that the business analyst that they have on their side is fully capable of taking on the tasks that they need to be done, and dealing with changes and transitions in processes that they may not be able to predict. The business analyst plays a crucial role in communicating between the external parties and the internal departments of the organization, which means they would act as a ‘translator’ wherever they may be needed and try and reduce the amount of misunderstandings and miscommunications. This ‘translator’ role is one of the most challenging parts of working as a business analyst but is also one of the most required. Now through any PMI-PBA online training, the aspiring business analyst may be exposed to a number of portfolios including product owner, requirements engineer, management consultant, business architect, enterprise analyst, process analyst, systems analyst, business systems analyst and product manager. Although these titles all mostly mean the same thing and involve the same responsibilities, they may differ slightly from role to role, as well as from firm to firm, depending on their individual requirements and the sector in which they operate in. Now while the barrier in terms of PMI-PBA certification cost is generally quite reasonable, many choose not to pursue it, and this leaves them quite behind in the grand scheme of things as they are unable to stay competitive in a world where business analysts appear to be coming out of the woodworks. The best way to differentiate in such an environment is definitely through the right certifications. This is reflected by the vast range of responsibilities that a business analyst must take on including communication, working with stakeholders, using data modelling, opportunity evaluation and the identification of the right processes to name very few. All of these add up and mean that the aspiring business analyst, while in demand, still has some catching up to do.
14324
Business Analysts - Changing How Companies Deal wi...

Working as a business analyst has become one of th... Read More

Defining How Decisions Are Made With Effective Business Cases

Before we even start out to consider writing a business case, there are three important questions that any business case writing course would tell you to ask yourself. What is a business case? Why do I need a business case? Why is business case vital?  And when should I use a business case? Once you are able to find the right answers for these questions, then you are definitely already on the right track and will be writing effecting business cases and getting decision makers to sway your way when you need them to.now one of the first things to know when starting with a new proposal is to first understand what the benefits of that business proposal are for the decision makers, and how to best communicate these benefits to them in a way that they will easily understand. The business case is developed in one of the early stages of a proposal and it outlines the main whys, whats, hows and whos, necessary to properly decide if taking on this proposal is worthwhile for the decision makers. The impact of this is that the person who is doing the business case writing, needs to present the facts and benefits in a way that isn’t disingenuous, but still shows that this is a proposal worth taking up. Now why you might need a business case is largely based on the fact that the process of preparing one requires a lot of assessment. In fact, most business case writing training programmes specify that the case looks into the business problem or opportunity, the benefits, the risks, the costs involved including the appraisal of investment, likely technical solutions, the time period, the impact it would have on operations as well as the capability of the organization to deliver on the outcomes proposed.  All of these are the main issues that are very important to the business case, and exploring them means that there has to be an in-depth analysis done into the proposal. This means that a sort of internal audit is done for the proposal, which would expose any likely weaknesses in it and allow for the project proposer to look into them and sort them out, before presenting the business case to the decision makers. This is just one of the ways in which bcw training can prove useful to the professional and it is always advised that they at least look up bcw online to get a good idea on the best practices for writing effective cases. The question of when to use a business case is one that would become clear over time and practice, especially if the professional in question has done a good business case writing certification as this is a learned skill. Many organizations would require that project management professionals be certified in business cases as they may take their proposals only in the form of cases, as it has come to be a widely-accepted format due to its simplicity and ability to deliver raw facts in a precise manner. The need for a business case is most seen when the resources or expenditure on a particular proposal needs to be justified appropriately to the decision makers. It does a great job of providing grounds for such actions and allows decision makers to look at them from a frontline view. Approval for these proposals in this format is usually sought out from the sponsor of the project or even other parties who may be interested. A good example would be the IT department being authorised funds by the finance function in a company for the undertaking of a new client side project which would require upfront costs, but would bring in heavy returns over time.
16476
Defining How Decisions Are Made With Effective Bus...

Before we even start out to consider writing a bus... Read More

Useful links