It boils down to requirements traceability in the end.
I'd note as well (going back to waterfall land particularly), some requirements *will not be met*. Just because a need is expressed and requirements are identified doesn't mean it's in scope for delivery.
It is really important to be able to say - if this requirement is not met, then it traces back to this capabilty & need - and we get agreement on the impact of not meeting the requirement. If it's anchored, it's easy to figure it out. If it's floating ... who knows?
And in Agile development, from what I've seend, sometimes requirements can be very lightly anchored (by which I mean, traceable in a very specific functional context only) and the wider consequences of change / omission unclear.
I'm a big fan of Sutherland's "Enabling Specifications", even if they didn't make it into the Scrum Guide. I've written about them here: https://bettersoftware.uk/2024/08/26/improve-your-offshore-software-development-with-enabling-specifications/ and I wondered @Maarten, if you had an opinion on their use, good/bad/indifferent, particularly since the prescriptive nature of them seem to fly in the face of the current agile movement.
I read the article, but to me it's still not clear enough what an enabling specification is to comment.
I follow a very simple and straightforward rule:
A valid requirement must be translated into understandable and measurable acceptance criteria.
This approach reduces clutter, ambiguity and misunderstandings.
What's a valid requirement?
According to my approach, which I establish with all the stakeholders, a requirement is valid if it can be stated in the form of acceptance criteria.
Otherwise, it is invalid and will be ignored / discarded.
For instance:
For critical authorizations, the confirmation code must be quickly dispatched to the user.
Is not a valid requirement, because "quickly" is subjective.
Instead.
For critical authorizations, the confirmation code must be dispatched to the user within 5 seconds.
A valid requirement must be measurable.
Okay, so valid means technically valid, but it could still be useless depending on the perspective you take, is that a fair interpretation? :)
Indeed. The value and the purpose of a requirement fall beyond the responsibility of the developers.
Issuing the "right" requirements is a Product Management call.
In the example, 5 seconds is the threshold to be respected.
Then the dev team can be very creative and propositive within the boundaries given.
It boils down to requirements traceability in the end.
I'd note as well (going back to waterfall land particularly), some requirements *will not be met*. Just because a need is expressed and requirements are identified doesn't mean it's in scope for delivery.
It is really important to be able to say - if this requirement is not met, then it traces back to this capabilty & need - and we get agreement on the impact of not meeting the requirement. If it's anchored, it's easy to figure it out. If it's floating ... who knows?
And in Agile development, from what I've seend, sometimes requirements can be very lightly anchored (by which I mean, traceable in a very specific functional context only) and the wider consequences of change / omission unclear.