Where do a software system's requirements come from?

A software system exists to meet functional needs: capturing customer names and addresses, performing specific tasks like calculating a benefit, or even carrying out artificial-intelligence tasks such as facial recognition. These tasks all stem from a need inherent to an organization, from a desire to create something different, or simply from an idea someone believes to be useful and profitable.

Those needs come from somewhere. For an analyst who must structure them and make them clear to a developer, this means a process of identification — and the needs often come from different sources.

Sometimes they are contradictory and must be cross-checked to find the real need. And that real need won’t necessarily end up in a developer’s hands. A user’s need is not necessarily the manager’s need, and even if the manager is aware of the user’s need, it doesn’t mean they will be willing to pay to address it.

The analyst is sometimes caught in the middle: they must understand everyone’s needs, weigh them against each other, and make a choice for the product, in agreement with the various stakeholders.

Here are a few examples of where requirements come from.

The client

The client brings the analyst needs that are often their own, shaped by what they see or perceive in their company. A good conversation with them is essential: this is the person paying to address the software needs. The client is a good source of information, but the analyst shouldn’t stop there; they must look for needs elsewhere to verify them and uncover others.

The user

The user is a very valuable source: they know the application, they use it every day, and they know what they need. For applications used by occasional users, those users can also provide important information about ease of use.

The architects

Whether functional, software, or business architects, these members of the development teams are a source of requirements not to be overlooked: thanks to their experience, they can offer valuable ideas for developing an application.

The analyst

Although the analyst is often the person tasked with finding requirements, they can also be a contributor: suggesting ideas and having them validated by other members of the organization.

The developer

Don’t forget developers: they can have good ideas, because they know the application — especially when they’re in maintenance mode.

The market

Competitors offer ready-made applications, and many of those ideas can be brought into the application you’re working on. If an idea comes from the market, it may be necessary to offer the same kind of service. That’s something to analyze with the team.

Laws and regulations

One important source: laws and regulations. They govern our lives and absolutely must be considered when gathering requirements.

In short, requirements come from different sources and are sometimes contradictory. For the analyst, it’s essential to sort through them, to weigh them against several members of the organization — and sometimes people outside it. Not all needs are equal: some can be dropped if they’re barely necessary, others prioritized when the need is urgent.