When you work as a dev for a small company, or if you've had the enviable bravery to start your own software business, it's likely that, as well as doing the codey code bits, you'll have to take control of the whole software lifecycle, including the requirements gathering. When I got my first job as a software engineer, I was just an introvert trying to recover from a noisy career in teaching, by retreating into a quiet, peaceful coding groove when I got thrown into the world of requirements gathering. It's taken many projects to figure out how to fit all the pieces together and I think it's something that a lot of devs find daunting, so here are 5 tips!

1 - Get intimately familiar with your context.

Visit the people you're building for and get them to show you the entire process that you'll be automating. Better yet, get them to walk you through as much of what they do as possible, including the processes before and after yours and the physical location your application will be used in. Ask them what they're doing and why they're doing it. The more context you understand about the tasks and the environment, the better placed you are to help them figure out what they actually need (which is often not what they're asking for). While you're there, ask them what works well about their processes, what doesn't work and what they'd like to change. Just really poke around. If you think you're being too nosy, you're probably on the right track.

2 - Talk to all the stakeholders.

This is one thing I've made mistakes with, and I've still got software out there not being used partly because of it. Usually the person requesting the software is management level and they don't interact with the process you'll be automating. While they can give you an overview of what they need and why, you need to talk to the people who actually do the work. Actual processes will likely differ from process policy and there will be workarounds, little annoyances and environmental nuances that you need to take into account. Essentially, they know best what they need, so you need to find out what they need, what the requesting person wants, and find a balance between the two. It's also important that people have trust in your application. If you develop without involving the users, they have zero visibility of what you're doing and therefore zero trust in your application.

3 - Ask all the 'what-if' questions

Have you ever delivered at the end of an iteration and one of your users has gone 'well what about when this happens?'? Yeah, me too. It's usually a random situation that you've not thought of while coding, and which hasn't come up when requirements gathering, but which causes a considerable road block to users. A lot of guidance will suggest that you ask these 'what-if' questions while you're interviewing your stakeholders, but this doesn't always work when you're an introvert like me. We work better processing alone, so I do my 'what-iffing' alone. I draw my flow charts of the processes and, for each step, figure out the 'what-ifs'. What if the information wasn't there, or was corrupted? What if the information is in the wrong format? What if a step in a process before mine was missed? What if the database is unavailable? And so on... Then I'll go back to the customer and have a chat about them.

Just to be clear, despite how many 'what-ifs' you uncover, there will always be at least one more sneaky one that you'll have to account for after go-live.

4 - When you assume, it makes an...

This is similar to what-iffing, but, instead of looking at what could happen to the information or the application, you're looking at what conclusions you've already come to about the information or the process. These are super hard to figure out. You've made the assumption without thinking about it, so how can you think about something you've not thought about? 🤯 I've not come across a decent way of unearthing these, but running through the flow chart can be handy.

You're looking for assumptions you've made about the data/information you're dealing with. Have you assumed that a user ID is always an int, but not realised that there was an issue with the HR system one year and people got assigned strings?

You're also looking for assumptions about the user. Have you assumed that they will always upload a Word document in your file upload section, so you've not thought about validation? I guarantee that someone will upload a spreadsheet or an exe, or some random file type that died off with Windows 95. BTW, I'm also upset at your insecure code if you've got no validation on your file upload, but that's a subject for another post.

You should also consider assumptions about the environment and infrastructure. Have you assumed that the users will always have a consistent network connection? What will happen if they lose this connection? You need to think about offline caching.

5 - Think about constraints

This usually boils down to things like what data can you get access to, what regulations you're working within, how long you have to deliver and how many requirements you can fit in before that time runs out. For things like this, you have to look at workload, company policies and peripheral systems. Things like this will impact the amount you can deliver and what features you can actually implement.

The constraint that upsets me the most is usually whether I have the skill to deliver what I want within the time frame. I might have a really cool idea about using web sockets to ping realtime notifications between users, but the constraint is whether I have time to learn that technology and implement it without impacting the essential requirements. You do sometimes have to sacrifice learning the new, cool stuff in order to deliver the necessary stuff. Personally, I try not to see the as a constraint, just a slight pothole that I need to find a way around, because what's the point in writing a project if you don't get to learn something new? I think this is why so many of us learn stuff on our own time.

I think, to sum up my advice, the crux is to be annoyingly chatty and think of everything. Simple, right?

In all seriousness though, this is a skill that takes time, and you will make mistakes. I made a habit of reviewing my requirements gathering process each time I ran a new project in order to figure out what I was doing well and what needed improving. I also watched other people go through the process to figure out other people's approaches. Comments on your process are always appreciated, so leave them below!