Following your track from the stakeholder needs analysis phase to the solution
An internationally renowned expert in the field of requirements engineering was recently asked the following at an event: “In your opinion how should one deal with user stories – client requirements in agile projects – once they have been realized?”
His answer: “Once they are completed throw them out.”
Everyone shifted around in their seats, then another question came from the audience: “When will traceability finally become a reality?”
Counter question by the speaker: “What do you want traceability for?”
Indignant heckling from the audience: “Without it we’ll never achieve a higher CMMI or SPICE level.”
“Then we can forget about ISO certification.”
The speaker remained calm. “How much traceability have you achieved in your projects?” he asked.
Silence fell on the room like a blanket. Obviously there is a massive gap between what people theoretically want, indeed, what they consider absolutely necessary and what actually gets practiced in projects.
Why are theory and practice so far apart when it comes to traceability? Why do people have strong reservations, especially in agile projects, regarding the usefulness and costs of traceability? And how much traceability do we actually need? We seek to answer these questions by presenting a simple requirements traceability approach that makes even agile projects “enjoyable”.