On the meaning of "required"

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 here I am … writing about requirements.

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

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.

(Important 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. We BAs 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.

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’m going to 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.

The representation doesn’t matter.

We business analysts are a little obsessed with documentation, are we not?

It is epidemic in our profession, or almost so.

And it is 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 a 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 problematic behaviour as well. 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 … 👇

You may remember (approximately one rant ago) 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 that is not to say that focusing on usability is easy. It is not!

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.

Finding the right balance is the biggest trick of them all.

But we often don’t focus on finding balance.

We BAs might have oversimplified things a bit. Note: I will deny everything if you tell anyone I said that. But in this instance, it might actually be true!

Specifically, we might have decomposed the process too much.

When we decompose the requirements process, it is easy to miss the bigger picture. All those steps. Documentation. Formatting. Representation. Yes, I am painfully aware that I’m guilty of this, too.

And if 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 might 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.

We talk about format when we should be talking 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 business analysis is not in question. Report after report highlights that good business analysis is 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?

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:

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.”

Paul, D. et al, “Business Analysis”  2010, BCS, Swindon

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 to this point (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.