“Who needs requirements anyway?” This is a direct quote from a stakeholder in a project that I was part of. It was said after a group session where the project team was trying to herd cats and get a reasonable list of requirements for a new framework that was to be implemented.
After the project team finished drowning our sorrows at the local pub, we realised that we needed to do a bit of education on why having a concise list of clearly defined requirements was a key component of successful project delivery.
Requirements gathering ensures everyone understands what the project is supposed to achieve.
Requirements are one of the foundation stones of a project and give us something to refer back to when the project is finished to make sure we have met all of the objectives. You also want to make sure to record where requirements came from and how requirements relate to each other (traceability). This in 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.
Gathering requirements can throw up issues or potential solutions that had not been considered before.
On software projects, a solid list of requirements makes testing easier as test cases can be linked to requirements to cross check that all requirements have been covered (test coverage).
Gathering formal requirements before the project starts removes any nasty surprises as the project progresses. In fact, history has shown that the more time you spend up front on defining requirements, the less time you spend on development and rework.
On an agile project you may only define the high-level requirements up front. During each iteration you would then prioritise those requirements and then only refine to top three or four selected for that sprint.
We’ll be exploring the different kinds of project requirements in a follow up blog.
Psoda has a complete requirements management module to make this task easier. To try it for yourself sign up for a free trial.