What is requirement management

04 Apr 2022


In this article, I will try to go through the importance of requirements management in software engineering projects.

During my career as a software engineer, there were often situations when product roadmap was very unclear on project management level, and when discussing with customers, the medium term vision was pretty blurry.

At some point, I was reading about product management, and found a very important step in product management process: requirements management. The topic itself may seem quite simple and obvious, however there are a lot of ways to do it wrong, but it can help to formalize customer needs, and therefore to define a ground for feature definition.

Let’s take a look on what requirements management really is, and have a clear understanding what is requirement management process.

Understanding customer needs

The success of a product in a market is defined by how efficiently it responds to customer needs. Ideally the customer needs should reflect pain points that people with specific activity does have issues on performing specific activity. Usually the pain is defined by consumption of bigger than expected amount of resources; for software products that is usually time and/or money.

Defining customer needs means to have an understanding on customer issues, and how it affects their activities. This should be the centric idea when building products or adding a new feature to an existing product. Because, customers won’t pay you money, unless your service (even automated) won’t help them to relief a pain related to time (and/or money) that they currently face.

Articulate clear requirement

When there will a clear undestanding of customer needs, it quite easy to translate it into a requirement. Basically I would say that requirements are a formal way to describe the customer needs. In order to formalize it should have a specific syntax, that basically will define:

This might look as a random list of terms, but a good requirements should contain all of the elements from above.

The priority is pretty straightforward, and usually is defined by specific keywords, like shall, or should. The rationale is a set of reasons, and/or arguments that describes the customer need, that is listed in data sources (either qualitative or quantitative feedback). The constraints is usually a list of constraint for specific needs.

All of these elements should be formulated into a simple, accurate and with just one semantic interpretation, in order to result into a clear requirement definition.

Define product feature

Product managers usually gather the most information possible about customer needs and turn them into requirements; therefore the list of requirements should evolve continuously, by collecting data about customer needs.

Usually, these requirements will be related to specific aspect of the problem. Let’s say it can be defined as a part of the process, that helps to automate a service. In this case, if we group requirements by the criteria of belonging to specific aspect of the problem, a feature could be defined.

During the product lifetime, feature is always changing, according to the customer needs. This means that feature has new requirement that has to satisfy customer need, based on the priorities that should be elaborated during information gathering. At that point, it is the job of different stakeholders on how to add changes to the already existing solution, in order to meet the new customer needs; and this is called an agile process


Requirements management process could be vital when defining product roadmap for software engineering team. By formalizing customer needs, it then could improve feature definition or feature change, as well as prioritization of specific features that could satisfy customer needs.

I am looking forward for your thoughts on requirements management process, that you can share in the comments, and also please share this article so that the discussion around this thoughts will be much larger.