Defining requirements as an agile Team

Defining the requirements is undoubtedly one of the most important steps to take into consideration during the development life cycle of a system. A requirements document meets the needs that give rise to the beginning of a project and is used to define what needs to be done; it is the basis of any software project.

When we talk about writing a requirements document, we instantly think (those of us who knew how it was done in the past), in a super detailed document that is difficult to maintain, but this is not practical or a trend in the development world today.

The objective of this article is to illustrate how the requirements are classified in the world nowadays and how we do the process of lifting requirements in Codegenio, so that our future clients have a better idea of how we function as a company.

When defining requirements, it is easy to get confused when attempting to distinguish between business, user and software requirements. Each and every one of them is different and serves different purposes.

Requirements Classification

In Codegenio we take care of separating the requirements in these three categories so that it is much simpler for our clients and developers to understand the projects we develop.

Business requirements

User requirements

In Codegenio we have business analysts that carefully analyze user requirements and build a set of high quality system requirements and ensure that requirements meet quality standards defined by the company.

System requirements

These requirements are the building blocks developers use to build the system. These are the traditional “shall” statements that describe what the system “shall do.”

The plan for implementing functional requirements is detailed in the system design. The plan for implementing non-functional requirements is detailed in the system architecture. Some examples of non-functional requirements are: Usability, Security, Reliability, Performance, among others.

Managing requirements as an agile team

When developing a product in Codegenio, we always make sure that the stakeholders agree on what needs to be delivered first. Product owners prioritize user stories in order to make them ready at the start of a sprint resulting in higher product quality. Iterations can also be used to clarify a requirement.

A user story is a documented description of a software feature seen from the end-user perspective. The user story describes exactly what the user wants the system to do. In Agile projects such as the ones we develop at Codegenio, user stories are organized in a backlog, which is an ordered list of product functions. Nowadays, user stories are considered to be the best format for backlog items.

A typical user story is written like this: As a <type of user>, I want <some goal> so that <some reason>.

Example: As a service provider, I want to add descriptions to services so that users can later view these descriptions and compare the products.

Every user story must be accompanied by acceptance criteria. These are the conditions that the product must satisfy to be accepted by a user, stakeholders, or a product owner.

Conclusion

Our team is aware of all the new agile methodologies in order to make easier the creation and maintenance of any project’s requirements. We work in sprints, with user stories managed in our backlog guaranteeing all the stakeholders satisfaction. As a company we are perfectly able to develop any project using the best practices to write a requirements document.

This article was originally posted at Codegenio’s blog by our Project Manager Guelmis Lázara Martínez Ramírez.