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 answer this question. 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 are the purpose of the project, and functional requirements, which are everything that developers should use.
Things get complicated at the level of choosing a method that will identify the intentions of a user. It would be best for you to use the two most popular techniques — use cases and user stories. Both strategies allow you to understand the requirements of a recipient in many types of projects and do so much better than other solutions.
What are use cases and user stories?
Let's move on to the definitions. 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., changing the profile data in an online store.
Let's be more specific with our visualization by using a simply written use case:
"Online bookstore — update customer profile."
A user story is "a short and simple description of functionality, told from the perspective of the person, usually the user or client of the system, who needs a given functionality" (Cohn, 2010).
An example user story scheme looks like this:
"As <user type> I want <a goal>, so <a reason>."
The user story allows us to see the user's history (unlike the use case) and indicates their type, as well as their motivation behind wanting to use 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 the processes of use cases and user stories are going in different directions. Working on a use case means that the business analyst will work with representatives of users. 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, they will give a structure that will be consistent with the usage template. Based on the use case, they will determine what functional requirements developers should consider. And a 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 the structure and context that are not in the collection of user stories.
For user stories, agile teams typically focus on developing acceptance tests. Thanks to them, we learn how to meet the requirements the user sets for us. The strength of this method comes from the fact that 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? Then it's necessary to divide them into smaller stories that can be implemented in a single iteration.
Use 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. Additionally, verification tests will assess whether a given option has been correctly implemented.
Where will both methods work, or where will they not?
Use cases and stories will work for:
- Obtaining requirements for business applications
- Websites
- Self-service kiosks
- Systems that allow users to control devices.
They won't work for:
- Embedded systems and real-time systems
- Applications that use batch processing
- Computer-intensive systems
- Business analysis
- Data warehouses.
Check out our articles devoted to how to choose a good web development company part 1 and part 2.
Hero shot: Giphy.com
Do you want to know how much it costs to develop an app?
