Defending against poor requirements

What is your first line of defence against poor requirements and vague ideas? Do these ever slip through the net and make it into development? Hopefully not.

The real cost of implementing a badly formed requirement is a whole lot more than just developer time. Ongoing liability is a better way to see it.

Are developers your first line of defence against poor requirements and vague ideas? Perhaps so, if your team lacks an analyst and the developers speak directly to the users or take instruction from the product owner.

Can your developers identify a well-formed requirement? Only some developers know the difference between a well-formed requirement, and a vague idea disguised as one. Understanding what a good requirement looks like can really help the team consider incoming requests and changes, etc. The same understanding can be shared outside the team with the originators of the requests, too.

Should developers ask to see the user research that underpins a new feature request, if they suspect some dodgy behaviour or shaky ground? Is this even within their remit?

I would argue ‘Yes’, it’s entirely appropriate for the developer to ask if no one else is first looking at the requirements. Because if they don’t ask, then who is going to prevent poor requirements and vague ideas from slipping through the net?

Do your developers know when to push back on a request and ask for clarification, and do they feel empowered enough to recommend not to proceed when something is a bad idea? It can be a pretty terrifying position to find yourself in, requiring courage and brave action to safeguard the product’s integrity.

Small cross-functional teams where the technical staff interact directly with end users are the gold standard for many teams, particularly those seeking more agile ways of working.

Some developers thrive when given responsibility for ensuring well-formed requirements, using analytical thinking and good communication skills. Once upon a time, an ‘analyst/developer’ did just this, a role some of us still practice today.

However, it’s a mistake to assume each developer, at every point of their career, should interact with users and proactively guard against poor requirements and vague ideas. Some developers will be able to, some can with a bit of help, and some won’t want to. Having the right developers doing the right things is what matters.

If you are unhappy with your development team, they may need more detailed guidance.

Better software requirements can help with this.