My challenge to the trace matrix is, what about requirements that are implied or assumed? Or what about testing ideas that don't map back to a requirement? Many great testing ideas come to mind while we're testing. If the trace matrix prevents test ideas from being executed because there is no stated requirement to trace back to, then I would challenge the practice of the trace matrix. In fact, by focusing on filling out a trace matrix, testing ideas can be stymied. This is the core reason why I don't believe a trace matrix is necessarily the best indication that a system is well tested.
However, if you're working in a regulated environment where you are governed that the trace matrix shall be used to demonstrate complete test coverage, then the trace matrix must be updated. As long as the requirements and trace matrix can be updated all the way until the end of a project, then a trace matrix can be the indicator of test coverage. If the requirements are frozen and the trace matrix is not updated up until the project is complete, then the trace matrix is not necessarily the best indicator of test coverage.
This was first published in February 2007