Better software requirements is about the right conversations, happening at the right time, to the right level of detail, and with decision making delegated to the lowest possible level.
The successful translation between ‘business’ and ‘technology’ depends on behaviours not artefacts, and that’s the mindset shift that needs to be made.
‘Congratulations Frank, you’ve just joined the agile party when it’s largely over’, you say. Wrong. I’m not taking about agile development, I’m taking about any kind of development.
Feature factory development that takes four sprints for stories to travel across refinement, development, testing and deployment? That’s cool, you can still level up your ‘software requirements’ by better behaviours within, and between, each sprint.
One small part of my literal, black and white, certainty seeking identity as an engineer would dearly like to define industry wide, super clarified, standardised requirements definitions; however I think this unrealistic and probably unhelpful, at least in the professional services/digital product arena I play in.
Software development is an art, enterprise environments are complicated, the future unknown. Better conversations are needed, the ‘software requirements’ are the notes left behind as an after thought.