Hi Jon,

It is interesting that your last paragraph highlights exactly the problem that the traceability matrix is designed to overcome.

In your example the QA team is relying on the developers to tell them that Reqt B may be affected by the changes in Reqt X. This is fine if the original developers are still around. What happens though when it is six months after the project was completed and you are responsible for maintenance work?

The original developers have moved on or even left the company, so you are on your own. Unless you have a traceability matrix to explain the relationships between requirements you are back to square one and may be forced to read a lot of code to figure it out for yourself.

yes bruce, a TM would help in this case. however, unless it is guaranteed up-to-date, the TM might be less useful. i remember someone wiser than i quipping "a good code maintainer worth their salt, never relies on documentation, but rather looks only at the actual code for what is truly going on." i paraphrase .

you just have to weigh the cost of creating and maintaining a TM with the value it provides.

i submit a well-architected and commented app gets you 90% of the way to knowing where to look to find a requirement's implementation bits. and for the next 8%, you can add docs to the project wiki that describe various design quirks, or the really odd things you may have had to do.

should someone decide to proceed with a TM, i would suggest writing requirements for it and test cases. do a little implementation, then see if you can actually use it as hoped. compare the cost of developing it and using it, with the cost of alternate ways to achieve the same test case results (i.e., find the code "manually").

Hi Jon,

When you get to a project with 100K+ lines of code it becomes a very long task for a developer new to the project to "read the code" to understand how the application fits together, even if the code is well documented.

At this point it becomes critical to have sufficient documentation in place or your developer will be spending the next few months becoming familiar with the code :)

agreed, bruce. i try to have a blend of wiki docs that cover major design aspects -- including things we chose not to do. and for specific "harder" bits of the app, be sure the developer not only has good code comments, but has documented other -- less obvious -- aspects on the wiki.

having a good issue tracker system that also maintains corporate memory for a specific component's life story can be useful.

then after that is digested, the developer can jump into the pool of 100K SLOC.

but a manually-maintained traceability matrix implies a lot of work to me... maybe i tried to do them wrong all those years ago, and have a permanent "bad taste" in my mouth...