The Deceptive Nature of Requirements
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.
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.