On the Meaning of Required: Are We Focusing on the Wrong Things?

6 min read
  • analysis

A grid of images.

I’m a Business Analyst who often posts thoughts online. I am also a Business Analyst who fears that no one will think me serious if I don’t write about requirements. 😳

So I'm sitting here … writing about requirements.

And I’m drawing a blank. 😶‍🌫️

Requirements are required?

Requirements are almost the only constant in business analysis. And yet, they are not easy to talk about! For example, I tried to explain a few concepts to my partner recently. We talked specifications. We talked requirements. We talked business requirements.

We got into a fight about it (for context: my partner is a developer.)

His argument was as follows: Business Analysts (and Product Managers, and Product Owners, and designers, and consultants, and basically everyone who doesn’t code) start with what the client wants. But then we fancy it all up. We play games with semantics. Then we pretend that these semantics have meaning. It adds a lot of pointless process, he says.

He went on to cruelly claim that we (yes, all of us, you included!) are complicating things in an effort to justify our jobs.

Here’s an emoji to describe how I felt about that claim: 🤬

Naturally, I argued that it is self-evident that requirements are a real thing. I pointed out that they are very different from specs. And that there are many different kinds of requirements. And that it’s all OBVIOUS and anyone who thinks otherwise is an ignoramus.

But here’s the problem. Honestly, I struggle to pin down a precise and clear definition of any of these apparently established concepts.

Which makes me suspect that my partner is not entirely wrong. Editor: cough, cough. We might have overcomplicated things a tad.

Or are we focusing on the wrong things?

So with that unnecessary (but amusing, I hope) context, let’s get stuck in.

What is a requirement??

There are a bunch of requirement definitions floating around, of which the most often used is IIBA’s. They say that a requirement is a usable representation of a need (I’ll come back to the word usable later). They go on to say that a requirement is:

  1. A condition or capability needed by a stakeholder to solve a problem or achieve an objective.
  2. A condition or capability that must be met or possessed by a solution or solution component to satisfy a contract, standard, specification, or other formally imposed documents.
  3. A documented representation of a condition or capability as in (1) or (2).

According to the IIBA, a requirement is not a requirement until we document it. (See point 3 above.) This is to separate it from the instigating need, which can exist whether it is documented or not.

Is that logic unclear? Their intent is to separate the concept of need from that of a requirement. Hannah needs air to breathe is a need. The system must provide airflow such that Hannah can breathe is a requirement. The latter documents the former. Put another way, if a need falls in a forest and no one was there to write it down, then it’s not a requirement.

Requirements exist only when they’re written down. That’s the stance.

Problem: it’s bullshit.

The representation doesn’t matter. We are a little obsessed with documentation, are we not? It is practically an epidemic in our profession. One with a huge cost. Large companies waste more than twenty percent of analysis funding on ineffective templates and formats. (Source: IAG Consulting).

That’s one full day each week of hours worked and money wasted.

We obsess over requirement formats. We believe that documenting a need creates a requirement. (🪄Poof! A requirement is born!) This shapes all sorts of other problems including behaviours such as:

  1. Formatting a bad idea as a user story. Syntax patterns do not good ideas make!
  2. Being hands off after it’s documented. Your did your part, right?
  3. Getting defensive about the correctness of a requirement. Because, you know, didn’t we already agree on it?
  4. Avoiding change or new information. I have documented it so it is done!

But we’ve lost sight of what matters. There is only thing that does matter.

The process. Let me turn that into a heading to drive home the point … 

The process really matters

Documentation state is not the defining characteristic of a requirement. Analysis is.

I write down needs all the time. The vast majority of the needs I write down don’t become requirements. Needs aren’t automatically awarded required status because I documented them. (Can you even imagine the insanity?)

The state change from a need to a requirement is more than the process of representation. It is analysis and decisions that get you there. Or put another way, it is a process.

And there are far smarter people than I who back up the claim that the process is the part that matters. Cynthia Low, summarizing the research for the BA Times, makes this point better than I ever could:

Effective Business Requirements are a process — not a deliverable. The findings are very clear in this regard — companies that focus on both the process and the deliverables of requirements are far more successful than those that only focus on the documentation quality. Documentation quality can only assure that investment in a project is not wasted by an outright failure. The quality of the process through which documentation is developed is what creates both successes and economic advantage. To make effective change, companies must rethink their process of business requirements discovery.

Do all the documentation you want. It is the needs that the solution requires that become requirements. It’s all in the name!

The core of what we do is to filter those required needs from the mass of needs that we could deliver. So focusing on documentation is worse than just a mistaken focus. It’s missing the entire point.

We need more focus on usable

You may remember from earlier the one-liner definition for a requirement: a usable representation of a need. Here’s my hot take: I don’t think we focus enough on the usable part of that definition.

But getting usability right is not easy!

Not least because usable can mean many different things.

Usable might mean detailed specifications and requirements along with screen designs and process flows. Maybe you’re outsourcing to an offshore development firm. Elsewhere, usable might mean a conversation and some boxes scribbled on a whiteboard. All sorts of combinations are possible between those extremes. It depends on the context.

Here’s an incomplete list of things that impact usability directly:

  • Delivery approach (in-house build vs vendor-led)
  • Complexities in the technical landscape
  • Skills and experiences of the team
  • Organisational risk tolerance
  • Funding constraints
  • And preferences!

These things can and should change what usable looks like in your context. And finding the right balance is the biggest trick of them all.

But balance is something we focus on even less than usability.

More than the sum of its parts

We might have decomposed things a bit too much. When we decompose the requirements process, it is easy to miss the bigger picture — easy to be distracted by all those steps. Distracted by the documentation. Distracted by formatting. Distracted by representation. Distracted by traceability.

When we focus on the steps, too often we lose sight of our purpose.

Why are we bothering? Isn’t it so that people can reason about what to include in the solution? For this, they must have visibility of the parts and understand them as well.

In standardising process and format for repeatability sakes, we have reduced our ability to be value-centric and adaptive. I’m actually a bit worried that standardisation makes predetermined outcomes appear more collaborative and considered than they really are. As a result, we talk about format when we should talk about facilitation. We talk about sign-offs when we should talk about comprehension.

And no point in talking about complex system analysis! Too hard right?

The value of requirements is not in question. Report after report highlights that good business analysis and requirements are fundamental to success. That’s true for any project, programme, or initiative.

But the value is not in the document, it’s in the process. And we should champion it.

The irony is that we often don’t stop to determine the requirements for our requirements before we start writing them.

That might be useful, no?

Postscript

Sometimes I’m looking so close at the Business Analyst role that I get a bit crosseyed and confused. So, I go look up some definitions. Here’s one of my favourites:

A Business Analyst is:

[A Business Analyst] is an internal consultancy role that has the responsibility for investigating business situations, identifying and evaluating options for improving business systems, defining requirements, and ensuring the effective use of information systems in meeting the needs of the business.

And while that definition doesn’t have the word useful in it, doesn’t it just ooze usefulness?

Which is precisely what we usually provide!

So, if you’ve read this far (congrats, BTW), then I don’t want to leave you with the impression that we are not useful. Or that we are all focused on the wrong things. Quite the contrary!

But I do think that sometimes we get distracted.

Last updated .