There is no product without requirements.

Sure, you can work based on intuition, believing that you are heading in the right direction. I don’t want to work like that.

Requirements for a product are like its description. Decision-makers need to know what they want, so that engineers know what to do.

Requirements levels

My experience shows that what decision-makers have in mind is not always immediately suitable for implementation by engineers. After all, we are dealing with different domains and have different roles.

To bridge this gap, I believe it is necessary to establish agreement on the levels of requirements and the responsible individuals. In the simplest scenario, I propose two levels:

• Business requirements: specifying what the product should do and how it should operate.

• Technical requirements: determining the programming language, platform, and other technical aspects.

The process should begin by defining the business requirements and then writing corresponding technical requirements. This ensures that engineers understand what needs to be done and, most importantly, have a reliable source of truth for the product.

Shifting left

I previously mentioned that defining requirements should come before implementation. I understand that it may resemble the infamous waterfall approach.

From my experience, however, I believe that defining technical requirements is a task that involves numerous questions and problems that may also arise during implementation. Solving these problems and finding answers before writing any code can save a significant amount of effort and even prevent the need for code deletion.

Requirements and User Stories

In the Agile world, teams commonly organise their work around user stories. I understand that. This approach prioritizes the user and focuses on delivering maximum value.

However, it’s important to note that a user story is not a requirement itself. Requirements emerge from a user story. In the previously mentioned breakdown, the user story lies in the realm of business requirements. Therefore, completing a user story involves both defining and implementing the requirements.

Tracking requirements

The user story is considered complete when the user is able to successfully perform the given task. At that point, we close the user story, but the requirements and implementation still exist and will continue to change many times.

As mentioned earlier, requirements, like code, are the output of someone’s work. Therefore, they should be treated in a similar manner to code. It is essential to establish processes that ensure complete synchronization of tasks, requirements, code, and all other components. We should also keep in mind the tests that directly arise from the requirements.

What it means to me

Requirements are the starting point for almost everything. Without them, we do should not start implementation, and testers should not start testing. A comprehensive set of requirements shows that project is understood and that we all know what we are working with.

Requirements are also a way of communication. I like to think of them as a contract between teams – we do not need to discuss every single detail, because requirements define what we should deliver. It saves time and communication issues.