How to gather better software requirements

“Have you got the requirements yet?” is a question I’m often asked early in a new engagement, usually a few weeks in. “Have you got the requirements yet?”, asked sincerely, as if the requirements are something lying around the hallways to be simply picked up and gathered together in some kind of wicker basket. Collecting eggs from a chicken coop comes to mind. I used to get pretty mad at this point, being asking for a status update so early on in the engagement, and then wondering why the client offered a 6 month contract if they thought the ‘requirements gathering’ could be done in a couple of weeks. What did they expect for the following 5 months then? Perhaps more requirements would be laid in the hallways.

I came to realise these kinds of experiences almost always came from a misunderstanding of how to build good quality software, and ignorance about what a business analyst does to help. An urgent need to deliver some kind of system, unrealistic deadlines and the need for progress creates anxiety in the stakeholders, producing the well intended, but misguided question “Have you got the requirements yet?”. If only the requirements were complete, then the real work could commence, goes their thinking. Once I saw the ignorance and lack of understanding driving this behaviour (no personal criticism intended), I stopped getting mad and started educating stakeholders about the requirements gathering process. I started educating them in interviews even before I was hired, so they knew what to expect. Their anxiety reduced, more realistic expectations came about, and importantly, I would be more likely afforded the time and means to work in the most effective way I knew how.

I would explain that requirements aren’t necessarily known in advance, they aren’t located in the heads of the stakeholders, and they aren’t solicited in back to back Zoom meetings. Equally, going around saying “Tell me what you want” is a pretty terrible approach and certainly won’t provide the answers they needed or hoped for. You wouldn’t hire a business analyst if it really was this easy. Requirements gathering isn’t a simple linear process, and unfortunately, it often can’t be planned and executed in a deterministic manner. Sure, you can schedule two weeks of stakeholder interviews on a project plan, and you will find out a heap of stuff, but you may not get the answers you need to build the kind of software the business demands, and users want. The cautionary adage, ‘it’s exactly what I asked for, but not what I want’ (or will pay for) is true, and is the reason why relying on stakeholder interviews alone is insufficient.

I like creating truly excellent software that is loved by users and creates competitive advantage, not just shipping features in a no code platform configured by cheap offshore labour (I’m sorry, but that’s where the industry is heading). I’m not that interested in writing noddy tickets in Atlassian Jira or Azure DevOps for appearance sake, but what really does interest me is understanding the underlying needs, wants and desires of the user, many of which are not yet fully known or can be easily articulated. I really want to understand what they need to do, and why, so that I can (hopefully) build preemptive features that properly ‘wow’ them. This is a pretty good goal for any ‘requirements gathering’ activity and the primary output should be acquired knowledge of the user. Software requirements follow, being the best way we know to represent user needs and painpoints in written form. They are often a poor approximation or hypothesis of actual need, yet to be built and validated.

Time with users is probably the single biggest factor in gathering good software requirements. Adequate time to develop a relationship, build trust, listen intently, ask questions and hear feedback. Adequate time to see how they work, to understand the daily pressures they are under, the environment they work in, and other tools they use. Adequate time to understand the competitive landscape, the needs of the business, and the opportunities to do better or differently. With adequate time, and a keen eye and enquiring mind, you start to understand the real needs of the users and stakeholders, and with some luck, be able to make known a provisional roadmap of features to address them. Software requirements are finally written nearer to the developers firing up their keyboard in anger.

Buying yourself adequate time, and the remit, to do all this is where the real challenge lies for the business analyst or requirements analyst, particularly in the face of delivery pressures and tight project deadlines. Some clients ‘get it’ and you’ll be afforded the necessary time and access to individuals, most won’t, even if you explain the importance. Often I agree a formal, up front requirements gathering piece of work, say a month in duration. My goal is to capture enough of a backlog for the first three sprints, to demonstrate progress, align developers and put everyone at ease. I also know there is a high chance of this work being off the mark, given a lack of time and relatively fixed interview schedule, and so I’m managing the risk of rework and ability to pivot all the time when compiling the initial backlog and scheduling the delivery of it.

Once development commences, everyone feels good and I can then start the real, in-depth process of understanding needs by immersing myself in the organisation and through the day to day interactions with users and stakeholders, having secured myself both the time and access required to really unpick what is required. Interestingly, IT system builds often represent a deep, unmet organisational need and there is immense value in accurately clarifying and surfacing it, but that is a post for another day. Anyhow, this is how I spend the following 5 months once ‘requirements gathering’ has been ticked off.

If you are unhappy with your development team, they may need more detailed guidance.

Better software requirements can help with this.