+64 4 499 1701
Mon - Fri: 07:00 am - 05:00 pm
Follow
BRAND NEW AGILE TECH!
Psoda is bridging the gap between physical and electronic kanban boards
Learn More
>
BRAND NEW AGILE TECH!
Psoda is bridging the gap between physical and electronic kanban boardsLearn More
>
Title Image

Who needs requirements anyway?

Cartoon of a robot showing different interpretations of requirements

“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. They 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. This lets you 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. After that you would refine further to the top three or four selected for that sprint.

We’ll be exploring the different kinds of project requirements in a follow up blog.

If you’re looking for an easier way to gather requirements, look no further than Psoda. It has a complete requirements management module to make this task easier. To try it for yourself sign up for a free 30 day trial.

Post a comment