The Art of Requirements Gathering

It was when I first started working near software development (many, many years ago) that I began hearing the word ‘requirements’ a lot. Then I trained to become a business analyst, which, if you trust the theory, equates to gathering requirements for most of your life, and then you draw some process maps in the end. One could wonder, is it really that big a deal, to commit nearly a full time job to it? Having done it for a while, I can assure you: it is. To get a new something created, or to improve something that exists, with value and efficiency in mind, it’s important to know what exactly it is, who needs it and why. That something is called a product. This is a story about the foundation of making good products.

Setting up the scene

In my practice, I commonly find out that there is a need by hearing statements like: ‘we need to get Salesforce’, ‘we need a new dashboard’ or, because why not, ‘I need a pony’. What is symptomatic, is that people - stakeholders, as we should refer to them from now on - love to define their needs by naming what they think would solve their problem  (pony, Salesforce, dashboard), not: by naming their problem. In such situations, I tend to ask: who needs it (that would be business or product owner), why exactly (problem statement) and who’s going to use it (user)?

The business owner and user may, or may not, be the same person. Commonly, a senior stakeholder defines a business need but using the solution will fall on someone else’s shoulders. As an analyst, you will need to work with both the business owner and the end user, to make sure that whatever gets delivered a. is fit for purpose and b. is not a nightmare to use. And it really is on you to figure it out.

Problem statement

Let’s look at the most ridiculous example from the list above: I need a pony. 

Define the need, and pony may just be the best solution for it, but you may also find that there are better, cheaper, faster, more efficient solutions doing the same - or, in fact, better - thing. That’s why we shouldn’t define our needs by arbitrarily stating what is going to fulfill them. We define the problem and then try to find the best fit for it. Requirements gathering builds a bridge between the problem and the solution.

If a 3 year old toddler states ‘I need a pony’, there is really no arguing with them. However, if a business manager announces that ‘we need a pony’, unless we’re in the equestrian industry, some questions should be raised. Why does the business need it? What need will the pony fulfill? What is the problem that we’re trying to solve here? The pony will come at a cost, so there must be a value it will generate, for its purchase to make sense. What value will it unlock?

Sit down with the manager and try to find your answers, find your problem. There are many different, less or more formalised investigation techniques out there. 5 why-s may come in handy (although I discourage making it 5 at all costs, sometimes 3 or even 2 will get you there - read my post on root cause analysis to find out more). In discussing the manager’s needs, you may find out that the pony is supposed to make the office environment more friendly and, ultimately, improve the employees’ morale. We’re getting somewhere! The problem could just be low morale. In digging deeper (but why is morale low?) you uncover that people are frustrated because they are being asked to come to the office 5 times a week while the commute has become increasingly painful (traffic) and there’s commonly more people in the office than available desks. We can now make the problem statement: we have unhappy staff. 

How did a single pony get us all the way here?

Teasing out requirements

Enough of this nonsense now! Let’s look at some real life examples.

Once upon a time, I worked with a really frustrated stakeholder who, as part of their BAU, had to compose and circulate a weekly email for senior leadership, summarising the trading outcomes of the past 7 days. The email would take hours to put together and involve copying and pasting screen shots of tables from Excel, then painstaking proofreading, because once you’ve sent it, you can’t take it back. There was one other person in the business who had the skill and knowledge to fulfill the task, so these two were not allowed to be on leave at the same time. Inevitably, once the email was sent, our stakeholder would get bombarded with questions, the likes of: ‘what about this’ and ‘what if that’. Their problem statement was: this is not sustainable, and the objective: let the senior leadership self-serve so I can focus on things that add value.

We sat together for a number of sessions. We started off detailing the ‘as is’, mapping out exactly how things were done, why they were required, how long it took to complete the existing process, what sort of questions tended to follow. We analysed the structure and content of the email, rating how important each component part of it was and why. We listed the recipients of the email, what their levels of interest were and how likely they were to ask for more (and why). We thought about what wasn’t currently there but we knew the leadership would be keen to receive, in an ideal world.

We then proceeded to imagine the glorious, sustainable future, with the main objective to create a self-served functionality, of which senior stakeholders would become users, empowered to model the data however they like, whenever they fancy. We imagined what that functionality should do for them - but also what it shouldn’t do. For your own sake, always remember to define what is in scope and what’s out of scope. In our case, we said that the functionality should summarise past activities but any forecasting was out of scope, at least for the first release. We defined what was critical (solution won’t add value without it) and what was good to have. All that was captured in a mighty product requirements document.

User first

Needs can be expressed on various levels of the business. In the above case, the bulk of the requirements came from a manager, who just wanted some peace and quiet, to be able to do work that matters. The solution that followed was a web-based dashboard, designed to mirror the scope of the infamous weekly email but with a daily granularity, with added date-range customisation, filtering by asset, revenue stream, etc. At the point of its creation, we imagined what would be best for the future user, because there were no present users to ask about their experience. In time, having achieved the main objective, we started listening to end user feedback, to make sure our tool actually got used. What could have happened (and, sadly, what commonly happens) is: we could have patted ourselves on the back, having delivered what we thought was great, only to learn several months later that the end users find it appalling and refuse to incorporate the tool in their BAU. Mission failed, bring back the weekly email! 

If a business wants a product - any product - to be used, it must listen to the end users, keep checking if they are happy, review their needs from time to time, as they may have changed. Don’t guess, don’t design what you would like. Get the end users to complain to you about their BAU pains, then allow them to imagine a perfect world. Capture the ‘what’ (is the need), not the ‘how’ (to fulfill it), then let others find the best-fitting solution for it.

Acceptance criteria

Here’s where it could go horribly wrong again. We could have gathered the requirements, designed, tested and implemented the solution, only to hear ‘That’s not what I meant’ from the user. Back to the drawing board, and why? Because we’ve not agreed with the user what good looks like. Again, that was on us.

The user has a right to be vague. It is the analyst’s job to make sure any uncertainty is addressed, for the sake of good requirements. Work together with the user and the developers on defining the acceptance criteria - and get it all agreed in writing. Think ‘how can we test this’ from the start.

Success measures

And now comes the part that makes lots of analysts squirm. I used to be one of them and still find it incredibly challenging to come up with the right set of success measures for the project or delivery. Pretending we don’t need success measures is easier. Solution delivered, it works, job done. Let others figure out whether it was worth it.

But we’ve done it for a reason, haven’t we? We hoped to achieve business value significant enough for the project to get prioritised, and resources committed to its delivery. Analysts must not shy away from scrutinising the business value upfront, because if there is no or little value, then maybe the business should be focussing efforts elsewhere. Stakeholders may project value off the top of their heads, and it’s better to uncover such painful facts early, rather than allow the disaster that is a delivery that no one really needed.

That’s why it’s important to write down how we’re going to measure the success of the delivery. In tangible, quantifiable metrics best - like money or time saved (and its £ equivalent), increased satisfaction, reduced cost. When you list these metrics, think - and declare - how you’re going to collect the measurements (statistical analysis, revenue reporting, user feedback, you name it). Ask the user what outcome they expect, how their life will get better once the solution is delivered. And then it’s delivered, don’t just assume success. Measure, and report with full honesty. If it’s a success, great. If it isn’t then maybe there’s still time to fix it. Maybe not and you’ve learned the lesson. In any case, knowing is much, much better than not knowing. Having learned, we are able to do things better next time.