Use cases vs user stories in application design

24 Jul 2019

Oceń artykuł:
Journal / JPG / Burakowski - avatar
Piotr Burakowski
Business and technology journalist, publishing since 2006.

One of the most important questions we should ask ourselves before implementing software is: "What will users do with our software?" User-oriented solutions can help. Thanks to them, we can implement key functions and protect ourselves from adding features users wouldn’t use.

User requirements lie between the business requirements, which is the purpose of the project, and functional requirements - all that developers should use.

Stairs start at a level of choosing that will determine the intentions of a user. It's best when you use the two most popular techniques - use cases and user stories. Both strategies allow the customer to understand the requirements of many types of projects, and do so in a better way than other solutions.

What is a use case and user story

Let's move on to the definitions themselves. A use case is a description of the sequence of interactions that occur between the system and the persona. The point is for the persona to achieve a set goal, e.g. change the profile data in the online store.

Let's be more specific with our visualization by using a simple record of a use case:

"Online bookstore - update customer profile".

Paper figure of a man against the background of the php code
 

Meanwhile, the user's story is "a short and simple description of functionality, told from the perspective of the person, usually the user or client of the system, whose functionality is needed" (Cohn, 2010). An example user story scheme looks like this:

"As <user type> I want <some purpose>, so <reason>".

The user story allows us to see the user's history (unlike the user's case) and indicates his type, as well as the premise behind the fact he wants to perform a given option.

Therefore, we have a detailed description. For example: "As a customer, I want to update my profile so that I can pay for my future purchases with a new credit card."

Remember that user processes and stories go in different directions. Working on a use case means the business analyst will work with user representatives. They will discover how the user imagines a dialogue with a system whose task is to achieve a specific goal. Thanks to the collected information, it will give a structure that will be consistent with the usage template. Based on the use case, it will determine what functional requirements developers should consider. The tester will check whether the specific case has been correctly implemented.

However, the use case should not specify the details of the design - its task is to focus on the user's perceptions. Use cases show the project participants structure and context that are not in the user story collection.

For user stories, agile teams typically focus on developing acceptance tests. Thanks to them, we learn how to meet the requirements the user set for us. The strength of this method comes from the fact it focuses on testing at an early stage of work - it results in very good outcomes, regardless of the methodology used.

However, what if the user stories are too big to be implemented in one iteration? It’s then necessary to divide them into smaller stories that can be implemented in a single iteration.

Programmer's workstation on two computers

User cases and stories - Common features

Let us now focus on the common features of both methods. First of all, use cases and user stories focus on what users want to achieve - but not what they think the system should do. Our task - in both use cases and user stories - will be to describe the tasks that users will have to perform or to identify user-system interactions.

The business analyst will find out what functions are necessary. There are also verification tests that will assess whether the option has been correctly implemented.

When do both methods work or not work?

User cases and stories will work in:

  • Obtaining requirements for business applications;      
  • Websites;      
  • Self-service kiosks;      
  • Systems that allow users to control devices.      

They won't work in:

  • Embedded systems and in real time;      
  • Applications that use batch processes;      
  • Computationally intensive systems;      
  • Business analysis;      
  • Data warehouses.      

Check out our articles devoted to how to choose a good software house part 1 and part 2

Main photo: Giphy.com

Journal / JPG / Burakowski - avatar
Piotr Burakowski
Business and technology journalist, publishing since 2006.
Oceń artykuł: