A project team is reviewing solution design, tracing it back to the requirements. Business analyst is flashing the original requirement on screen. Everyone in the room is looking at each other, doubts on their faces.
“Was this our requirement? I don’t remember why we would have asked for that. It does not make much sense now”. ‘What would we need that for?”. “Hmm, I can’t think of why”…
The reaction from the business analyst is swift and strict:
“Let’s not reopen that. The requirements have been approved, so it does not matter why you decided it was required. This is a waste of time to discuss it again, let’s move on!”
Dear Business Analyst:
Of course it matters why a requirement is required. If we can’t remember why, and we don’t have it captured, and we can’t explain it anymore, then perhaps it is no longer required (or never was?)
This is exactly why a user story requires that the ”why” is captured right inside it:
“As a user, I want X so that I can do / have / achieve Y”
This is exactly why a business analyst should care about solving a business problem and take accountability to understand why a certain condition or function is needed and what it will allow to achieve.
And the fact that the requirement has been signed off and nobody owns up to it now may also mean that the last requirements review was done in a rush, or the analyst made changes last moment, and nobody actually read that particular sentence carefully until this moment.
Discovering a requirement that does not make sense during a design review is actually a good thing, since we did not waste any developing cycles on coding it yet.
We should never spend time, money and other resources on the requirements that were captured, signed-off, but no longer can be explained or justified. That would indeed be a waste.