What is a requirement? A probably agile answer

Requirements focus on value. This at least is the name of a category for this Blog. But what are requirements anyway? If you know the answer, fine. But for all those that are as confused as I am, this article gives the ultimate answer, or hopefully one as helpful as 42 was for Loonquawl and Phouchg.


If really requirements are that important, and my experience strongly suggests that this is so, then one would think it is important to understand – and agree – what actually is meant with the term requirements.

The starting point: different opinions

Have you asked around in your company? I tried that lately and received completely different opinions about what a requirement is and especially strict statements about things that are definitely not a requirement. My observation: if two people talk about requirements, both use a different definition of the term requirement.

So lets look at what a couple of “official” sources have to say:

The wikipedia article makes it obvious: The term requirement is not as unambiguous as one would wish. Here are keywords I picked to contemplate the matter a bit more:

  • A capability to offer
  • A condition to satisfy
  • A factor judged necessary
  • By the circumstances
  • By the nature of things
  • Needed by a stakeholder
  • Needed to fulfill a contract, standard
  • explicitly requested or implicitly required
  • what a product should achieve
  • how to interact with a product
  • detailed statements of the system’s behavior, content, qualities, and operational constraints

There seem to be intertwined threads that need separating. Here is one way of doing this:

  1. Context knowledge: There is knowledge about the context of a system, e.g. about users and customers, how they do and experience their work and life, about limitations rooted in the nature of the things, about circumstances of specific situation, about relevant regulations and laws, and more.
  2. Demands: There are explicit statements from stakeholders about what they want the system to be, do and how the system should do it. And also statements about what stakeholders want the project team to do and how.
  3. External and internal view: When describing a software system, it is often described by the externally visible behavior, content and qualities. Such an external view will have several levels of details (see RAM on the ourspeak page) and describes WHAT the software system offers. This description is then matched with an internal view that shows HOW the system is built. This internal view will also be on several level of details, the most detailed being code and tests. All of that information is linked to the context knowledge and the demands gathered as well as the decision made. This then explains WHY the system is doing just what it does.

Some people I talked to in my company, had the model of the externally visible behavior in mind. Software developers and requirements people are generally in this group. Others talked about the demands and the context knowledge. This body of requirements is sometimes named user or business requirements by software teams to distinguish it from the other set of requirements.

The turning point: an irrelevant quesiton

Deep Thought by the way not only gave 42 as the answer. The electronic brain also hinted very strongly that the question might need refinement. So lets think about the question of what a requirement is. Is this a good question at all?

There are two common approaches to address Glass’ Law.

The first approach strives to create the perfect requirements specification. In this thinking, requirements are a part of the external model derived by analysts. The specification is the best compromise given the knowledge about the context, the stakeholder demands and the available technology. Developers implement the specification and everything is fine. In this thinking the question is relevant. The answer is: The requirements that are really worth being called requirements are those that describe the external view of the system.

The second approach is to create the perfect conversation about requirements: Given the current understanding of the context, the stakeholder demands and the current state, what is the best possible product we can provide?

In some cases, creating the best possible external view at just the right level of details can be crucial. Especially if there is no way around one of those contracts where resources (time and money), scope and quality are tightly fixed.

In most cases, the question of how to conduct the perfect conversation is much more important.

Given such thoughts I decided that I do not care anymore, what a requirement is. I however take great care on how I can influence and improve the conversation within the team and with stakeholders about what the best possible product is.

This thinking gave some freedom to my work.

For example to talk with stakeholders. Instead of creating a detailed requirements specification and drafting use cases to talk about how the system should work, I can now focus my attention on how the users will work given the cool new functionality the system will offer. For that I make use of the power of mock-ups, story-telling and experience maps to make the new system come to live. Stakeholders just have a great time.

Tools that proved great towards developers were e.g. wireframes of the UI; excel sheets of the business logic (yes, these are executable acceptance tests a domain expert can create and the team can integrate into test automation); and mocks of external systems together with a life data stream. Such items form a much richer specification than the abstract body of requirements.

The conclusion: It should not matter, what a requirement is

So my conclusion: As a person responsible to get the requirements right, bother on how to make people work together to develop the best possible product.