Developers don’t start with a blank sheet of paper

Developers don’t start with a blank sheet of paper, and writing down software requirements is not waterfall.

Something is needed, and that gets communicated to the development team somehow. Jira, email, service desk ticket, Excel, Word document, UML diagram, napkin, carrier pigeon.

I’m yet to come across a development team who worked 100% verbally. There is nothing waterfall about taking the time to write down the ask.

Clearly documenting what needs to be done, how it should be done, and how to test it is common sense. It’s also particularly important with remote teams and asynchronous working.

Writing up a requirement also helps think through necessary design changes, edge case behaviours, business rules, non-functional requirements, regulatory and compliance issues, deployment approach, related issues, knock-on effects, etc.

The best requirement processes are tailored to the situation. Developing medical devices and nuclear control software is very different to ordering fast food on a mobile app.

The extent to which requirements are documented, when in the lifecycle this is done, and by whom, is entirely up to you. Be as traditional or agile as you like.

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

Better software requirements can help with this.