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, back of a napkin, smoke signals, carrier pigeon.

I’m yet to come across a development team who chose to work 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 just common sense. It’s also particularly important with the increasing move toward remote, 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 life-critical medical devices and nuclear control software is very different to ordering fast food on JustEat.

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.