Have you ever been in a situation where you are looking at your Jira backlog and think that you have no idea what the title of the ticket means or what is supposed to be implemented in the scope of the ticket? Read on to learn about key requirements engineering tools: user stories and use cases.

Requirements engineering is a tricky business. Software requirements should be written in a concise manner but overly detailed requirements can also be a hindrance and an undue burden for the development process if applied every time. User stories and use cases are essential tools that, when applied correctly, can produce the most favorable outcome.

User story

A user story describes a software feature from the perspective of the end user. Let’s look at an example: “As an Author, I want to be able to edit a post, so that I can make necessary changes.”

The user story follows a structure: As a [persona], I [want to], [so that]. The structure can also be summarized as “Who, What, Why”. A properly defined user story can convey a lot of information for the reader in a very tight package.

Use Case

A use case describes an interaction of a user with a system. It captures the details of a user, their goals, and the required steps to accomplish those goals. Use case is best described as a table. There is no one correct way to define a use case table, but let’s take a look at an example below.

If we compare this use case description to the user story in the chapter before, we can see that it contains a lot more details for all stakeholders interested in the requirements. It also forces us to think about the actual implementation of the feature and the systems that are required to complete it.

Different Usages for User Stories and Use Cases

So what is the difference between user stories and use cases?

• User story: a short and simple description of a feature of a system from a user point of view answering the questions: Who, What, and Why.
• Use case: detailed description of a user interaction with a system.

User stories can be utilized in many ways. Below I will list two examples.

Firstly, user stories are great as Jira story ticket titles. The short “Who, What, Why” approach is very good for summarizing the intent of the ticket. Let’s first take a traditional ticket title that can often be seen on a backlog: “Add user to a register”. Can you guess who is adding a user to a register and why? Let’s fix this by using a user story: “As a Customer Admin, I want to be able to add a user to a register, so that I can comply with regulations”. The who and the why immediately become clearer. It is best to keep the user stories short, so they can be easily digested by the user. More detailed descriptions and acceptance criteria can be defined in the ticket description.

Secondly, user stories are a good way to outline and plan the upcoming work. Even if it is not completely clear how the user stories are going to be implemented, there is a lot of value in describing the work in the short “Who, What, Why” format. It is not always necessary, or even beneficial, to try to go into all the details of the implementation of each user story. Sometimes it is necessary to just see the scope of the upcoming work in multiple user stories that are still to be prioritized, planned and implemented.

Let’s move on to use cases. Use cases are a great way for the development team members trying to understand, verify, document, and implement business requirements. If you look at the use case table in the previous chapter, you can rarely see product owners providing such detailed explanation of the requirements. With such a use case table, the team can verify from a product owner that they have understood the business requirements correctly and provide an implementable solution suggestion.

Sometimes there can be UI sketches already done by a designer before the detailed use case is written. However, many times, the design does not take into account different situations and UI states that can arise in using the software. For example, the exceptions row in the use case table in the previous chapter defines an UI state that few designers or even product owners might think of. Thus, a detailed use case table can provide additional value in most situations for getting the implementation right the first time.

Conclusions

User stories and use cases have their own place in requirements engineering. User stories are fast and simple for general descriptions of a system functionality from the user point of view, even when there are no detailed specifications available. When detailed specifications are required, use cases are invaluable tools to describe the user flow and interaction with a system.

• Blog
|
• Software development
|
• Software testing