Table of Contents
When developing a software product, it is vital to accurately outline and define the project requirements in order to make the product user-friendly and help the development team better understand the end goal.
Project requirements are a must-have in waterfall projects and user stories are an integral part of the Agile development methodology. However, it may happen that you will need to turn the project requirements into user stories – in this case, you need to clearly understand the definition and purpose of both.
Are project requirements and user stories the same?
Not exactly.
Project requirements are all about the system and its specific (and highly technical) features. A typical project requirement would look something like this:
1.2.5 System shall display, “the password should contain the minimum of 8 digits and a capital letter” in the case of the incorrect input.
As you can see, this requirement states how a system should function upon a certain user action. But it does not explain what kind of value this action brings to the user, who the user is and why he or she performs this action.
While project requirements serve as clear guidelines for developers and navigate them through project development, user stories take a slightly different approach. They put the user first and explain why the user would perform an action and what value the user expects to get from it. This is how a user story may look:
As a user, I want to have a strong login password in order to secure my account and data.
These two examples describe the same action but in completely different ways. A user story explains to the development team (and all the parties involved) why it is important for the user to have a strong password – and the team can come up with the most efficient solution (which may not necessarily be the 8-digit password with a capital letter. Let’s see both the project requirements and the user stories in more detail below.
Project requirements: an overview
Project requirements are used in waterfall development and serve as a guide for the development team. Project requirements are basically the conditions that need to be honored so the project meets the set business goals.
There are three types of project requirements:
- Business: they address the business goals, i.e. “a mobile app should help the users quickly find a nearby restaurant”
- Solution: these requirements describe the actual product features, i.e. “an app should provide a guest checkout option”
- Stakeholder: states the interests of the stakeholders.
In the software development process, it’s the responsibility of a product owner to gather and process the requirements and manage them in the backlog. However, this may depend on the team’s composition and involved parties.
Writing a project requirement document
The process of writing project requirements is rather complex so we shall have a look at the basic steps:
- Write a brief project overview and describe the business goals and the main aim of the project
- Write a statement of functionality which describes the general functionality of the project and what it should do
- List down the project requirements and the desired deadline for the delivery of each
Project requirements will be broken down by categories (i.e. main screen, user admin, etc.) and will then be managed by the product owner. The requirements may change throughout the project and need to be prioritized correspondingly.
User stories: an overview
A user story is a component of the Agile development methodology. It describes the action that the user takes and the value that this action brings. A standard canvas for a user story is “As a (user), I want to (action) in order to (value)”.
Unlike a project requirement, a user story concentrates on persona and explains the value of the action. And it may happen that the action stated in project requirements does not actually bring any value or can be replaced with something more efficient and valuable for a user.
A user story is not complex and is usually written in plain language so it can be easily understood by anyone on a team.
Writing user stories
Before writing the user stories, it is first important to have a clear portrait of a user in mind in order to come up with an accurate customer journey. As well, the process of creating user stories usually involves many parties, i.e. a product owner, developers, product manager, even a stakeholder.
There is also such a thing in Agile as epic. An epic consists of several small user stories and can be scheduled for delivery on a certain date in order to comply with the deadline. With epics, it becomes easier to manage the user stories delivery and their prioritization.
The main differences between the project requirements and the user stories
After looking at both the project requirements and user stories, it is also important to understand the main differences between the two. They are:
- Focus: user stories focus on a user’s person and project requirements focus on a system,
- Complexity: project requirements are often written in a technical language while user stories need to be understandable and clear,
- Authors: user stories can be written by basically anyone involved while project requirements demand more technical knowledge and often call for the tech leads’ assistance.
At the same time, user stories and project requirements share one key similarity: they guide the development team and form the vision of the end product.
How to turn project requirements into user stories
You don’t need to turn your project requirements into user stories unless you are switching to Agile. Otherwise, the project can do perfectly fine with project requirements.
But if you decide that Agile methodology is more suitable for your future work, here is how to do it with minimal complexity.
First, you will need to change the mindset of a whole team from “listing down every tiny detail” to “understanding who will be performing an action and why”. This is important – or you will end up with a slightly modified list of the same project requirements.
Second, get the development team, QAs, authors of product specifications and other people involved sit together and spend time on going through the requirements and actually analyzing them. When you start using the “user story” approach based on the user value, you might find out that not all project requirements are needed (or that some of them need to be done in a different manner). This process will surely take quite a lot of time but it is obligatory if you want the system to function as intended.
It is important, though, to clearly understand what is your end goal and business objective. It may happen that waterfall methodology is perfect for one project and Agile will work great for another. So before starting the process of collecting and listing down the project requirements or user stories, identify what kind of development methodology will be the best for the intended budget and timeframe.
Comments