Why your requirements will always be wrong

Angela Prentner-Smith

Managing Consultant, This is Milk

A pretty bold statement, coming from a business analyst, right?  But, I believe this 100%. I better back up my statement then.  Let’s look at how we can improve the perception of business requirements.

What is the problem with business requirements?

I have heard countless times, and probably even said myself, things like:

“These requirements are crap.”

“That isn’t even a requirement.”

“If you put sh*t in, you get sh*t out.”

This needs to be addressed. Why are they so open to criticism?

Let’s take a quick look at what I mean by requirements.  I’m talking about business requirements - in a broad sense covering user stories, high level requirements, use cases and anything else used to define a business need.  That’s all a requirement is – the capture of a business need.  My statement is equally true however of system requirements – the capture of what a system needs to do.

My background is working on large programmes and projects of change – and it’s with this background I make my assertion.  However, I believe the same statement is true of any change.  My belief is that, even if your business isn’t “engineering requirements”, you still have business needs, and are most likely eliciting and capturing them in some way.  Within small companies, you probably deal with changes in these needs quite pragmatically.  The issue comes about when change methodology, corporate culture and stringent gateways, with a lack of a fluid change control method turn the business requirements into a gospel.  A gospel to be tarnished with blame, dispute and to become a fighting ground for stakeholders and delivery teams.

Now, I’m not saying that requirements aren’t necessary – I believe quite the opposite.  Any business should and would benefit from understanding their needs before embarking upon change.  Indeed, how else would we tell suppliers what we need them to do, how else would we estimate scale and cost, how else would we assess impacts?  Business needs should be captured and managed, enough said.

So when I say they will always be wrong, let’s look at how we get to business requirements.  Business requirements, user stories, or however else you are documenting your needs, generally come after the vision, strategy, scope etc. of a project.  Stakeholders are pulled together, or a product owner is defined, and whether you are using agile or waterfall methodology, or something else you’ve come up with, requirements are elicited by the business analyst. 

Why are they always wrong?

There are 3 things with this process that lead to requirements always being wrong:

1.       They are written at a point in time.  They were gathered based on the knowledge of those involved at the time.  Everything moves on.  So why on earth would you expect a document of needs captured at one point in time to be the truth? As projects progress, knowledge gathers, needs change.

2.       They are only as good as their input.  You have a room of stakeholders and subject matter experts, and sponsors and delivery partners, all with diverse backgrounds and differing viewpoints.  They all have their view of the world, and are unlikely to all be on the same page, of the same level of knowledge, and in complete agreement.  Therefore your requirements are only as good as the input they give you, which will be variable in quality.  Additionally your requirements are a compromise from the very start.

3.       They are produced by humans.  The one thing all of your requirements have in common – they were produced by a human.  Therefore open to human error.  End of story.  They’ll be wrong.  You can’t possibly expect every line of what can be hundreds of business requirements not to contain any errors.

So what do we do about it?

Stop – and I mean everybody - stop doing these things:

Expecting the requirements to do everything
Requirements are just one project artefact.  They document business need.  Do not expect them to define the design, the test strategy or anything else.

Expecting the requirements to be immutable
They were captured at a point in time – of course they are going to change, as knowledge develops and change matures.

Expecting the requirements to contain solution
They should never.  I repeat, requirements should never contain solution.  And by solution, I don’t just mean technical.  They should not contain the wording of a question, the heading of a web page etc, etc.  There’s a good reason for this!  If you put solution into your requirements, you do 3 things that you want to avoid.

1. You constrain your design.  I’ll give an example.  You know a question in an online app is difficult to understand and needs to change.  So you write the new wording into a requirement i.e. the solution.  Seems simple enough?  No harm right? Wrong!  What if the new wording is wrong, and through some customer engagement you validate that yes, the question needs to change, but your wording was wrong and customers don’t understand it?  You’ve constrained yourself with no need.  Suddenly you have a requirement being pushed through build and test, but it’s wrong – so you need to change it – which can create a new change process.  Just don’t constrain yourself in the first place.  
2. You muddy what requirements do.  Requirements are business needs, if you start putting some solution in, you set the expectation that the solution or anything else will be contained within the business requirements.  All those other things you need, are someone else’s job, or are a different document.  Keep them clean people, and please stop doing everyone else’s jobs!  
3. You stop focussing on the real need.  When you stop focussing on the need, and start to look elsewhere, you aren’t doing the job right.  You stop questioning properly, and this is bad.  So when a stakeholder says to you we need System X to do ABC – that isn’t a business requirement.  You need to ask why they need that, and what benefit that would bring.  Then you will get the real business need.  That may be that they need a process to be completed quicker, or a method of recording an element of data.

Methodology:  Define what needs to be done and who is doing it.

First of all – define your project roles and responsibilities, and the associated deliverables.  You let everyone know what their job is, what their role in the production of deliverables is, and what the purpose of the deliverable is.  Make sure you communicate this clearly, and get everyone’s buy in.

This will:

1. Create clarity of the purpose of deliverables, therefore avoiding the problem of the requirements being expected to define anything other than a business need.
2.  Ensure stakeholders and recipients of the requirements are engaged and understand their role in the production of the requirements and the project.  Create a sense of shared ownership.
3. Clarify the role of the business analyst – and stop them doing everyone else’s job.

Create a method to change the requirements.

The next step is to create and communicate a method to change the requirements.  Regardless of your overall methodology, you need a change control mechanism to track and communicate changes to requirements.  The best change control processes are nimble and quick, but still provide traceability.  I won’t go into this too much here – I think that’s maybe another article.  Like everything else, make sure everyone knows the process and has bought into it.

Foster a good project culture

Part of the issue in projects where statements like those I first quoted – is culture.  A culture with a lack of empowerment and decision making, and one where people are not working towards the same objectives, only produces blame and finger pointing.  A culture where everyone is working towards a common goal, feels shared ownership of success and failure and is empowered to make things better, make decisions and move on will help your requirements do a better job.  Not because your requirements are better but because the people using them are all on the same page.

Learn and improve

And back to my initial point - stop expecting the requirements to be right in the first place.  They can’t possibly be.  So stop blaming the requirements for your project’s foibles.  Yes, there are bad requirements out there – but you know what – there’s bad everything.  Expect some duffs in there, and move on.  Don’t waste time and effort with criticism, and if there are genuinely things that can be done better, debrief, record your lessons learned and build the learnings into your future projects!

---

Find out how we can help your business learn and improve!​

What We Do

​(Blog Post - First Published on 20/09/2015)