Poorly written requirements cause a lot of problems in software development, and the symptoms can often be traced back to the requirements gathering process. Not system requirements, not technical specs, but things like “User wants to do X, how does this happen?”
Coming up with a thorough list from the requirements gathering process needs not be daunting if you can keep some key points in mind.
The User Is First
When requirements gathering, it’s all about the user. What do they need to do? How efficiently can we make that happen? And what sorts of flexibility might be required?
The user won’t be as concerned with how we address those needs from a purely technical standpoint. They won’t care if something is coded in C++ or Swift, for instance, unless it bogs down performance. Requirements should, however, detail how a user would accomplish something using the software. How well that task is accomplished is where the UX meets the user, meaning efficiency and good design are crucial components.
For discovery purposes, talking to users may be your best tool when requirements gathering, but you can accomplish this in a variety of ways. Surveys, interviews, facilitated sessions, prototypes and even just shadowing users as they complete their tasks can all be helpful when finding out exactly how they get things done. Just be sure to watch out for common pitfalls during this critical stage.
You could also develop a use case diagram, including all the imagined steps in a new process. It could mean using the “As-Is and To-Be” model, where you diagram the current steps required (As-Is) and then add a “swim lane” (To-Be) showing the optimized solution.
Additionally, you could collect stories from users on how they do things or generate a mind map with management to develop the optimal path. Either way, you’ll be putting yourself in the role of the user and thinking about how they go from one step to another to achieve their goals using the software.
Freedom Within Limitations
To avoid feature creep, and generally make your project more manageable, it’s also important to know what users should not be doing with the software, or abilities that should be invisible to them. For instance, creating a client-facing database program is great until you accidentally allow them to edit someone else’s social security number.
Think about the steps the user will take to accomplish their goals and what dependencies might be involved. For example, if a financial query is needed (perhaps they’re applying for a loan), you’ll likely need some way of securely gathering a social security number or other unique identifier.
With luck, this query has already been built and your team will only need to fetch the data, instead of constructing an entire database to store it. Or, it’s possible that is within your specification as the current business has no such database. Either way, for your own sanity during the requirements gathering process, learn exactly how big the project will be.
Often scoping the project involves a context diagram, so you can see how your project fits into existing tools. Setting the boundaries for a project requires a few things:
- Unambiguous language (be precise)
- Consistency (what is the context of use?)
- Completeness (exactly what can or can’t this system do?)
The more specific and accurate your language, the better prepared your team will be to create proper workflows. For instance, writing the system will “process” something isn’t very helpful to a developer who must turn that fuzzy language into real output. Writing, “The credit will be calculated using tables X and Y and their income from field 1,” is the type of specificity needed.
Consistency also comes from integrating with other systems and helps limit the amount of back and forth needed from other teams. How will the databases communicate? What APIs will be needed and how are they already being used?
The more you know about how the larger animal works, the better you’ll be able to plug and play your solution. This will also help when things like a user interface gets built. You don’t want a solution that stands out for all the wrong reasons.
And completion isn’t just finishing the job. If you’re wondering when you’re done creating your list of requirements, be sure to check out this article to learn when you’ve hit a stopping point.
Being complete also means being thorough. So combine your precision with consistency: knowing the system and how it works in the context necessary. And then, be thorough about documenting the steps to get things done.
In this part, you can’t make assumptions. Take nothing for granted and be as detailed as possible when documenting every step needed to accomplish a task. This goes back to focusing on the user, asking them what they need and looking at how they hope to get there.
Stop, Collaborate and Listen
It would be great if requirements gathering simply entailed listening to a user’s dream workflow, writing up a diagram on how they’d accomplish a task and then get to work. But the reality is you’re going to deal with dependencies, either within or outside an organization. To make sure everyone is reasonably happy, it’s important to zoom out and listen.
What are those key objectives again? What is it the group hopes to get done? Make sure these high-level goals are SMART: Specific, Measurable, Agreed-upon, Realistic and Time-based. The larger the organization, the more important each one of those items becomes.
Ask stakeholders in the departments you will interface with what they need and how your team can make their lives easier. This is part diplomacy and part functional requirement gathering.
If the system you built requires a token for a user to interact with another system’s database, for example, make sure you put that in the spec. If that department has a frictionless way of making it happen, don’t reinvent the wheel. For more tips on diplomacy, be sure to read this article on dealing with stakeholder groups.
Lastly, getting potential roadblocks on your map early will save you considerable time down the road. Ask stakeholders across the organization what pitfalls other projects may have found, and work those into your specs as potential hazards to ensure you hit target dates for a smooth release.
For a deep dive into writing better requirements, check out our white paper, “Writing High Quality Requirements.”