The Software Development Lifecycle (SDLC) is sort of like a pipeline where you put stuff in one end and get stuff out of the other.
At one end you have a rabble of customers / clients / stakeholders / HiPPOs needing and wanting different things and at the other is a lump of delivered software that (ideally!) addresses some of those needs and wants.
The image below shows ‘pipeline’ as I imagine it:
But to make sure the rabble are actually delivered what they needed, there has to be some significant work done to ensure we truly understand what they’re actually asking for.
There are two main difficulties we face here, firstly, our ability to articulate and describe something that doesn’t exist yet, to convey an idea to another mind, is prone to difficulties. Secondly, what a customer thinks they want can be very, very different from what they actually need.
Tell me what do you think it is, I dare you
I like the analogy of describing a fruit bowl as if you and I were sitting opposite each other with the fruit bowl in between us – you see pears and apples; I see grapes and oranges. Neither of us is wrong when we describe our view to each other. We’re seeing the same bowl of fruit, but our views of the same thing are different. But we often only discover that we have very different ideas when we put it into words or pictures – only then do we find we’re misaligned.
Similarly, when we’re talking about an idea, something that doesn’t exist yet, we struggle even more.
You want me to supply a bowl of fruit for you and you have a picture in your head of what that looks like, but when I give you something that isn’t glass, ornate and with apples and pears in, you’ll be disappointed, possibly even annoyed that I didn’t understand you.
We may be violently agreeing that we understand what a bowl of fruit is and yet be completely unaware that our internal images of what that delivered fruit bowl will look and behave like are quite different.
Now imagine that request is for a digital product – a simple webpage, for instance – the complexity increases exponentially of how that will appear in each of our minds.
Scaling further and considering a very large organisation or enterprise, there are different levels of requirements – for instance the Team, Program and Portfolio levels in the Scaled Agile Framework (SAFe) methodology – each level having their own type of requirement.
No matter the scale of the requirements need, we’re going to need listening skills, good engagement and strong discovery or elicitation techniques to get the best chance of understanding our customers.
You really do have a problem
No matter how well we can articulate and understand one another in describing what we want, the other stumbling block can be discovering the underlying need behind each want.
And it is remarkably difficult! There is a real art to getting this information through various discovery or elicitation techniques, and often repurposing Root Cause Analysis (RCA) techniques themselves e.g. 5 Whys.
Customers (and us engineers!) often rush too quickly to the solution, sometimes asking for the solution directly (I need a fruit bowl!) without giving a thought to the problem (why?) (the word ‘solutioning’ is often used in my work as something that is done too soon in the process, but is it a real word? Not everyone agrees!). Customers can tell you exactly what they want your system to do for them – some very intelligent and/or ‘important’ people can be very convincing that they know best how your system should solve their problem. But they often don’t know your system as well as you or your technical team do and are very unlikely to have really thought about what problem it is they’re trying to solve.
When that happens, it’s also easy to go too far down the line and get distracted by potentially irrelevant details (I need it to be a blue ceramic fruit bowl with white detailing that matches the kitchen décor). Whoa there Lesley! - we don’t yet understand the problem you’re trying to solve! Knowing the problem can widen the possibilities for solutions, and sometimes even remove a requirement completely.
“Why do you need a bowl of fruit? What is the problem you’re trying to solve by having one?”
“Well, thinking about it, I actually want to provide healthy snacks for the family in easy reach...”
So, we might still end up with a bowl of fruit as a solution, but we can consider other options and we’ll be less likely to get distracted by parts of the requirement that do nothing to solve the problem - the colour and material of the bowl - certainly not something we need for a Minimum Viable Product (MVP)*!
Stepping away from the tired bowl of fruit, a more relevant example might be:
“If a customer asks you to put a save button, you don’t just go and implement it. You rather ask them the need for the button, understand if a better solution can help and you might end up using an Autosave functionality making the flow more efficient with enhanced customer experience.”
From ‘Define the Problem before the Solution’ by Nitesh Rathi
Problems are sneaky – get good at spotting them
Understanding the problem you’re trying to solve can be done many ways, for instance by finding out the Pain Points for the customer, using an outcome-driven method such as the Jobs-to-be-Done Needs Theory, running Discovery sessions with users, or hiring a Problem Analyst.
“Rather than accepting customer inputs such as “needs,”, “benefits,” “specifications,” and “solutions,” Ulwick argues that researchers should silence the literal “voice of the customer” and focus on the jobs customers need to get done and aggressively uncover the measurable outcomes customers hope to achieve.”
Anthony Ulwick, What Customers Want: Using Outcome-driven Innovation to Create Breakthrough Products and Services, 2005
Summary
Requirements gathering and analysis are often rushed as we assume we understand one another, and what is being asked for.
Taking the time at the beginning to really ensure you’re understanding your customer’s asks and to do your best to understand their needs so as to minimise any ‘regret work’ will pay dividends further along the line.
Fixing things while they’re still in the requirements phase is a billion times easier (and cheaper!) than when you’re doing User Acceptance Testing (UAT) or have gone live!
It might not always be possible to hire a specialist or utilise SAFe, so for some teams, the developers themselves can be expected to be the requirements engineer. If this is the case, using simpler/easier techniques will be more applicable.
There are many ways to do this and teams will often have to use the best tools to hand to give them the best chance of delivering the right product.
* Talking of MVP, I read an interesting article on Medium the other day about MVPs vs EVAs (Essential Value Achieved) and the takeaway was that by aiming for delivering the Essential Value as your first version, rather than an MVP that may well be viable, but may not be delivering any actual value, you’re much more likely to ‘minimize the risk of not achieving the essential solution for success’.