After posting my blog about project scope creep, Joshua Milane asked if I am a proponent of traceability matrices. I replied YES.
He immediately sent me his preferred approach. It is a good article particularly for practitioners who occasionally prefer the spirit vs. the letter of various methodologies, processes and standards.
As long as the job gets done, is it really necessary to have physical vs. conceptual traceability matrices? In my projects, I have never seen the former per se but I know that we can:
- trace the origins of requirements
- map the design against the requirements
- vet the solution against the design
- pinpoint where a change came from
- identify who signed off on the changes
We use unique IDs for requirements, test cases, defects and change requests to link various artefacts. Do we need more?
Prevent undocumented and/or unapproved changes by strictly adhering to fundamental scope management and change request (CR) processes.
