The life of a business analyst appears to revolve around requirements. Every working day we go about eliciting, analysing, prioritizing and communicating requirements.
So it might come as a bit of a shock to discover something:
There’s no such thing as a requirement.
At least, not in my view. Let me explain why.
Contexts and Ideas
Business analysts work on projects to deliver business change. Often, but not always, these projects involve changes to IT systems, but in the general case we are delivering business change.
All business change occurs within a context. This is what we call the “as-is”. The business is currently operating in a certain way. BABOK refers to this as the domain in which the change is to occur.
Then, somebody who is exposed to that context has an idea. The idea they have is an idea about how the business could be improved. They have observed something about the context (the “as-is”) and they have imagined a future in which the business operates differently – hopefully better (the “to-be”).
Sometimes the idea is labelled as an opportunity. Sometimes, the context is labelled as a problem and the idea is labelled as a solution to that problem. But these are merely labels. In the general case, what we have is an idea for business change – to move from the “as-is” to the “to-be”.
Sometimes, there is initially no clear view on what the “to-be” would actually be. This occurs when the context contains something that is perceived as a problem, but as yet we don’t have an idea as to what the solution might be. So there is a desire to move away from the “as-is” to a better, as-yet undefined, place. Note that labelling the context as a problem is just that – a label; a subjective view; a perception. A (perceived) problem does not necessarily need to be solved.
Cost and Value
The purpose of business change is to make the business better in some way. In other words, the change adds value, or delivers a benefit. Value is sometimes subjective, but let’s ignore that for now. Let’s imagine that value is objective enough that I can put a dollar figure on it.
Business change also has a cost. The cost includes the cost of making changes to an IT system, maintaining that system, altering defined business processes, re-training, hiring, firing and so on. The cost also includes any downsides to the idea. Sometimes, making an improvement to one aspect of the business has an adverse impact elsewhere.
Not all Ideas are Good
Business people (and business analysts) have ideas all the time. They are not all good ideas. For an idea to be a good one, the value it delivers has to outweigh the cost. In other words, the business case needs to stack up.
Most bad ideas are rejected before they even get to the point of cost/benefit analysis. They get discussed informally at the water cooler and it’s soon realised that it just wouldn’t work, or it would cost too much, or that the downside is too great.
Some ideas are on the cusp. Or more likely, the value is over-estimated and/or the costs are under-estimated, so the business case appears to stack up when the project starts. In this case, a project to deliver a bad idea might actually go ahead. We’ve all seen this – it’s called a doomed project.
It’s very important to note that nobody can be absolutely sure whether an idea for business change is a good one until it has been fully implemented and the total costs and benefits have been measured.
There Are Always Options
When someone has an idea to change the business, they are usually focussed on delivering a specific outcome. An outcome is not a solution. An outcome delivers specific benefits and has an associated value. In general, a given outcome can be achieved in many different ways (there is always more than one way to skin a cat).
Sometimes, the options are considered. If a well-trained business analyst is involved early enough in the process, they can perform enterprise business analysis (as per BABOK v2, Chapter 5). Sometimes, however, the idea is for a specific solution approach, and other options to deliver the same outcome (possibly at a lower cost) are not considered.
And there is always the option to not proceed. This is an especially good option if the idea is a bad idea, because it avoids launching a doomed project.
There are always options, and all business change is optional. Sometimes, the consequence of no change is total business collapse or, in the case of illegality, imprisonment of directors. But these are edge cases. In general, all business change is optional.
Once a project has been launched to implement the (good or bad) idea, the idea starts being referred to as a business need. This is an interesting term to use for an idea that is (a) possibly a bad idea, (b) possibly not the best way to achieve a specific outcome and (c) almost certainly optional.
Remember, even if a well-trained business has been involved from the outset, and all options have been considered, and a well-reasoned business case has been produced, it might still be a bad idea – we don’t know for sure until the business change has actually been implemented and the costs and benefits have been measured.
In my view, there’s no such thing as a business need. There are ideas for business change, but they are not needed, they are optional.
As soon as we label an idea as a business need, it effectively becomes set in concrete. We cannot challenge it. We cannot point out that there might be better alternatives, or that it might be better not to implement the idea at all.
At the start of a project we probably don’t want to challenge the business need. But as we go through the process of elicitation and analysis, and we discover that actually it’s a whole load more complicated than we thought, or that actually the benefit might be smaller than expected, we are unable to challenge the need, because, apparently, it’s needed.
So, on to requirements. According to BABOK v2, a requirement is
A condition or capability needed by a stakeholder to solve a problem or achieve an objective.
First of all, as previously discussed, calling something a problem is just giving it a label. So we are left with a requirement being
A condition or capability needed by a stakeholder to achieve an objective.
Notice that this definition of a requirement is implicitly conditional. If the objective is to be achieved then I need a certain condition or a capability. That’s good news – it sort of recognises that the objective is optional.
But according to the above definition, the requirement itself is, apparently, needed. It must be delivered. I don’t agree with this because, again, there are usually options. For a given objective, there are usually many ways to achieve it, if you think hard enough. And, as mentioned above, there is always the option not to achieve the objective, which is a good option if the cost of the requirement turns out to be greater than the benefit.
Specific conditions and capabilities are never needed. There are always options. Hence:
There’s no such thing as a requirement.
The things we call requirements are actually all just aspects of the proposed business change. I prefer to label them as aspects of the design of the business change, because I believe that the process of generating options and selecting a preferred option is a process of design. Labeling these things as requirements discourages the considering of alternatives.
Requirements are Designs
At this point, many business analysts will shout: “Ah, you’ve misunderstood. Requirements and designs are not the same. Requirements state what the stakeholder wants. Designs state how that will be delivered.” This is the classic requirements-versus-design debate, or the what-versus-how debate (see the references below for examples of the debate taking place). In my view, it’s a red herring. The terms “requirement” and “design” are both labels for aspects of a proposed business change. Which one you use depends on your viewpoint – one man’s how is another man’s what.
Some business analysts point out that the difference between requirements and design is that business analysts do requirements and designers do design. This implies that business analysts don’t, or shouldn’t, consider options and make recommendations. And I have met many business analysts who work this way. In my view this is badly wrong. Business analysts should work with stakeholders and technical people to consider options and select a preferred approach. One of the problems with BABOK v2 is that it doesn’t make this clear.
I prefer to avoid the debate entirely by labeling everything as a design. So for example, I refer to:
- Business process design – a representation of the “to-be” business process
- System functional design – a representation of the “to-be” IT system, as it is visible to its users
- System technical design – a representation of the “to-be” IT system, the internal bits that the users don’t care about (somebody else’s job, not mine)
When I label these things as designs, I am sending out a clear message: we have chosen to do it this way. None of it is needed, it’s a conscious decision – the result of considering the options and selecting the preferred approach – every step of the way.
To put it another way, it’s all design.
More importantly, business analysts are designers. We need to work collaboratively with business stakeholders and technical teams to consider all the possible options and deliver business change that gives the most value for the least cost.
Acknowledgements and References
I’ve had a number of discussions on this topic with various business analysts. The debates have been both stimulating and thought-provoking. It’s a contentious topic and not everybody agrees. Sometimes people agree but appear to disagree because of differences in terminology. Anyway, here’s a list of some of the people and articles that have influenced my thinking:
- Julian Sammy and his articles Some Thoughts on Requirements States and Needs and Solutions, Requirements and Designs
- Adriana Beal and her articles Requirement is what we have to do to achieve an objective and Requirements vs Design
- Scott Selhorst and his article Requirements vs Design – Which is Which and Why?
- Steve Blais and his article Stop Gathering Requirements
- The BABOK Guide (version 2)
- Everyone who commented on my previous article on this topic, Requirements Versus Design: It’s All Design