Requirements Gathering is a fundamental part of any software development project. These are things like “User wants to do X. How is this achieved?” In effect, Requirements Gathering is the process of generating a list of requirements (functional, system, technical, etc.) from all the stakeholders (customers, users, vendors, IT staff) that will be used as the basis for the formal definition of what the project is.
Because the requirements define the project, poorly written requirements can cause problems during development and, more seriously, cause projects to fail if the goals have been misunderstood. As the adage goes, “fail to prepare, and you prepare to fail” …
The importance of Requirements Gathering
Business customers tend to expect software teams to deliver a solution based on unspoken, incomplete or unknown requirements, while software teams tend to assume that business customers will communicate exactly what they want as succinctly as possible. Both expectations are obviously unrealistic. Therefore, the requirements need to be formally captured in one document that can be used as a reference during software development.
In the case where potential vendors are still being shortlisted, an essential starting point is to at least gather all the key requirements to allow for ball-park quotes.
Good gathering, processing and management of requirements is important as it sets clear targets for everyone to aim for. It can be a lot of hard work, but it need not be a daunting task if you can keep some key points in mind.
The User comes first
Firstly, remember it’s all about the user. Find out how actual users complete their tasks and exactly how they get things done – and how they want to get things done. What do they need to do? How efficiently can we make that happen? And what sorts of flexibility might be required?
The requirements should detail how a user would accomplish what they want using the software being developed. Awareness of any technological preferences and existing system integration is also fundamental, as it can have a huge impact on the development path and subsequently impact on performance and user task efficiency.
Useful tools for Requirements Gathering
There are many tools that can be used to aid requirements gathering. For example, when you’re in a requirements gathering session, try mind mapping to help organise the conversation by aligning comments, requirements and ideas with the major thought branches in a conversation.
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 optimised solution.
It’s worth spending the time documenting the ‘As-Is’ for major or complex processes so the entire team can develop a common understanding of the business process.
The ‘To-Be’ model shows how the business process becomes adjusted with the new system in place (sometimes it’s helpful to overlay the As-Is with the To-Be to understand the changes).
Put yourself in the role of the user and think about how they go from one step to another to achieve their goals using the software and what dependencies might be involved (such as querying the database for a unique identifier). Note that it’s also important to know what users should not be doing with the software, or abilities that should be invisible to them!
Another useful tool is to collect user stories on how they do things. If a user story is too complicated, it can be broken down into smaller stories and supported with diagrams.
Often scoping the project might require a context diagram to define the system’s boundary, its surrounding environment and all the interacting entities.
Being complete also means being thorough: know the system and how it works in the context necessary. How will it integrate with other systems? How will the databases communicate? What APIs will be needed and how are they already being used? By constructing a visual model of the software solution, you’ll get a better idea of the major interactions and players in your system.
A different sort of diagram that can be used is the top-down illustration, called a functional decomposition diagram, which is useful to break down the system into major chunks.
Remember not to make assumptions or take anything for granted. Be as detailed as possible and document every step needed to accomplish a task. Reiterate the key objectives during the requirements gathering process to ensure everyone is happy. One way to do this is to use SMART goals: Specific, Measurable, Agreed-upon, Realistic and Time-based.
Ask your stakeholders what they need and how your team can make their lives easier. Have they encountered pitfalls on other projects and can it be worked into the current spec as potential hazards? This is part diplomacy and part functional requirement gathering.
Finally, if you hit problems, then it’s better to have encountered them early on, during the requirements gathering stage, rather than at some time further down the road, when it could cost additional time and money to put right!
About Blueberry
Since its formation in 1997, Blueberry has been fortunate enough to work on many interesting projects, with clients both large and small. If you need a requirements analysis to move ahead with your project, we can help. Our Technical Consultancy Service includes:
Creation of specifications and requirements documents.
Development review to establish whether a development project is on the right track.
Design and Technology review to confirm that a project has the correct architecture and design, perhaps prior to investment.
We also have case study examples we can provide.
If you’d like more information on how we work with our clients, the following link should be useful.