“Who needs requirements anyway?” This is a direct quote from a project stakeholder on a very large and expensive project I worked on. He said it at the end of a frustrating group session where we were trying to put together a reasonable list of project requirements.
Unfortunately, this is a common sentiment. It can be frustrating trying to gather requirements for something which hasn’t even been designed yet or may not even happen. So it’s tempting to want to get it over with as fast as possible and with minimal effort.
Just as exasperating is spending months gathering requirements from all and sundry. The delay this causes means nothing ever goes anywhere and by the time a decision is made, the whole process needs to start again from scratch.
Many things can make or break a project. In my opinion, few things are as important as gathering requirements right at the start of a project. You might think this is common sense, but often it’s done in a slap dash, half-hearted manner. This leads to all sorts of problems – from products which don’t deliver what the customer wanted, to work taking twice as long as it should because it needed to be reworked.
Getting requirements right up front goes a long way towards setting your project up for success.
Why are project requirements important?
Requirements gathering is all about making sure everyone involved with your project has a clear understanding of what it’s supposed to deliver. It’s also a chance to help you identify any issues or potential solutions which might not have been considered before. History shows that the more time you spend up front on defining requirements, the less time you spend on development and rework.
Benefits of good requirements
They give us something to refer back to when the project is finished to make sure we have met all of the objectives. Make sure you record where requirements came from and how requirements relate to each other to ensure traceability. This record is an essential tool to understand the impact of change on the project or for maintenance after the project has finished and the team members have moved on.
The same document can be used as a reference guide for your test team to make sure all the requirements identified are met by the solution being delivered.
On software projects, a solid list of requirements makes testing easier as test cases can be linked to requirements. This lets you cross check that all requirements have been covered (test coverage).
The consequences neglecting requirements or doing it badly can be devastating for a project.
I’ve seen multi-million dollar projects with requirements so woolly they could be used to knit jumpers! And still people were surprised when the project failed to deliver what they wanted, or complained that it went over time and budget when the scope had to be adjusted half way through.
How to gather good requirements
So how do you go about making sure that you gather meaningful requirements? Here are some of my top tips:
- Assign the task to a dedicated business analyst
- Make sure there is a high level scope statement that frames what the project is supposed to achieve. This will be used to frame the requirements gathering process and make sure it doesn’t include things it shouldn’t
- Involve users, end customers, technical people, sponsors and stakeholders right from the beginning
- When defining the requirements, make sure they are SMART: specific, measurable, agreed upon, realistic and time-based
- Ensure the requirements documentation is clear, concise and includes all of relevant information
- When gathering requirements, always go in with an open mind – don’t assume anything!
- Get the requirements document signed off before starting work on the project
- Understand that any requirements gathering will never be 100%
- Keep the number of stakeholders involved to one representative from each area of the organisation impacted by the project, including the project team – means the project manager, developers, testers and maintenance team. Anymore and it becomes too complicated to manage.
- Spend as much time as possible on gathering and refining the requirements. The more time spent at this stage to get the requirements clearly articulated, the less time will be spent on rework during the design and development stage
- Make the requirements gathering process as collaborative as possible. Ideally, there will be requirements gathering workshops with all of key stakeholders in one room. Where this is impossible or impractical, circulate a master list of requirements often
- Make sure there is only one feature or need per requirement
- If possible, store requirements in a central repository for easy access and management
Plus, make sure you avoid making these common mistakes when gathering your requirements:
- Not prioritising requirements
- Presenting users with a solution before you understand what they want to achieve
- Making assumptions (again!)
- Not involving the right people in the requirements gathering process
Finally, to really streamline your requirements gathering process, consider using a requirements management tool. With Psoda’s requirements management tool, you can organise your project requirements, collaborate with your team, and manage change throughout the life of your programme or project. Try it free with a 30-day trial – click here to sign up.