As a freelance software developer, I help define requirements for custom solutions. Think of SaaS platforms, websites, and custom web applications that must meet specific requirements. Between the client's wishes and the code I write as a developer, there are user stories, requirements, and use cases. These are essential to satisfy the client.
User Stories
A user story is a short description of what a system user should be able to do. Such an (end) user, also called an actor, has a specific role. From that role, the actor wants to achieve a goal with an action. A user story is described in the form:
"As [role], I want [action] so that [goal]"
Example:
"As a user, I want to reset my password so that I can log in again if I forget my password."
Why user stories? Drafting user stories offers the following benefits:
- Identifying the needs and wishes of actors
- Assisting in creating requirements and (sub-)tasks for better time estimation
- Providing end goals: once the system is developed, it can be verified whether all user stories are fulfilled ( acceptance). This allows you to go through the system per user story to check if the desired action can be performed by a person in a specific role.
- Help building automated tests
Use Cases
Use cases describe how users interact with the system. These can be the steps a user takes to achieve a goal within the system. However, use cases don't always have to be interactions between a user and a system—a system can also respond to other types of requests, like a trigger from another system.
There are different ways to describe a use case. Here's an example of a use case:
Use case 1: Edit blog post
Primary actors: Admin user
Short description: The admin user edits part of an existing blog post.
Preconditions: The admin user is logged in and has permission to edit blog posts.
Post conditions: Changes to the blog post are online
Steps:
1. Actor requests to edit blog post
2. System shows input field with all fields of a post that can be edited
3. Actor edits post where necessary
4. Actor indicates to save post
5. System implements changes and updates the last-edited date
Alternatives:
4.[Field is empty]
4.1 Actor receives a message that a certain mandatory field is empty
4.2 Actor can still enter field
4.3 Back to step 3
Failure scenario:
5.[Implementing changes failed]
5.1 System cannot implement changes due to a malfunction
5.2 Actor receives a message that saving has failed.
5.3 End of use caseThis is just a simple example. In practice, there are more properties and details you can add.
From a use case, you should be able to deduce what the system can do. And that's handy for identifying requirements.
Software Requirements
In software engineering, requirements are essential components that describe what the system must achieve or what criteria it must meet to be considered a successful solution.
We distinguish between functional and non-functional requirements.
Functional Requirements
Functional requirements specify the behaviors and functionalities the software system must perform to meet users' needs.
They are typically expressed in terms of user interactions or system responses and are often documented using use cases, user stories, or feature lists. You can see this in the previous use case example. From it, we can derive the requirement that the system must update the last-edited date after a user edits a blog post.
Non-Functional Requirements
Non-functional requirements describe the quality attributes of the system. These can relate to the user interface, speed, performance, security, user-friendliness, and so on.
An example of a non-functional requirement is that the system must save a blog post within 2 seconds for a fast user experience.
Combining User Stories, Use Cases & Requirements
By combining user stories, use cases, and requirements, I can, as a freelance software developer and requirements engineer, transform my clients' wishes into structured, concrete features.
User stories help understand client needs, use cases provide detailed scenarios of system usage, and requirements offer guidelines for design and development. With this approach, I can work efficiently as a software developer and deliver tailored solutions that perfectly align with the client's wishes.
This approach is typically applied in agile environments (Scrum), where iterative development and close collaboration with the client are central. Through regular feedback moments, changing client needs can be addressed quickly.
