Copyright ©2008-2020 SoftTeco
Hexagonal architecture or ports and adapters architecture

Hexagonal architecture or ports and adapters architecture

Hexagon architecture is a great option for software applications as it significantly facilitates development and helps avoid a number of issues.

The Biggest Fintech Trends to Expect in 2020

The Biggest Fintech Trends to Expect in 2020

The fintech industry facilitates and optimizes the services provided by banks and financial establishments to their clients by using the latest technologies.

Headless Commerce: Do You Really Need To Adopt It?

Headless Commerce: Do You Really Need To Adopt It?

Headless commerce is a new ecommerce trend that grants entrepreneurs great flexibility and limitless personalization options for their store.

Behind Iowa’s Caucus Disaster: What Was The Big Deal With The Shadow App?

Behind Iowa’s Caucus Disaster: What Was The Big Deal With The Shadow App?

The performance and reliability of a mobile application are critical, especially for governmental projects like the recent app for Iowa caucus.

Telemedicine App Development: Basic Functionality to Implement

Telemedicine App Development: Basic Functionality to Implement

A telemedicine app is a brand-new way to connect patients with medical specialists so it is important to equip it with rich functionality for great performance.

Source Сode Management: An Overview of Tools and Practices

Source Сode Management: An Overview of Tools and Practices

Code management is obligatory for any development process as it helps safely implement any changes to the code and significantly speeds up the workflow.

Software Development Team Structure: Things To Consider

Software Development Team Structure: Things To Consider

Software development team structure is an important subject as it impacts the product’s quality and its adherence to the business goals and requirements.

Infrastructure as Code

Infrastructure as Code

Infrastructure as Code method allows to manage the IT infrastructure in an efficient and swift manner, minimizes errors and automates many manual processes.

AI Image Generation

AI Image Generation

The technology of AI image generation is trending these days so we decided it would be useful to puzzle it out and take a deeper look at the way it works.

Mobile Site vs Mobile App: What's Best for Your Business?

Mobile Site vs Mobile App: What's Best for Your Business?

When choosing between a mobile website and a mobile application, one needs to consider the goals to be achieved and what each option can bring to a business.

Software industry news
Irina Linnik
Turning Project Requirements Into User Stories: Why You Might Need It

Turning Project Requirements Into User Stories: Why You Might Need It

How to turn project requirements into user stories and what to avoid during the process

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:

  1. Write a brief project overview and describe the business goals and the main aim of the project

  2. Write a statement of functionality which describes the general functionality of the project and what it should do

  3. 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.