I was reading a book review of "Practical Software Engineering"
at www.therationaledge.com and it said something about the
"importance of traceability":

[begin excerpt]

Emphasizes the importance of traceability
-----------------------------------------
Throughout the book, Manassis discusses the importance of
requirements traceability. The last chapter, “Traceability at
Work,” demonstrates how traceability helps to keep projects
on track and on schedule. The greatest practical function
of traceability, he claims, is that it facilitates impact
analysis. It allows you to predict and identify what will
change if you modify the system at any level.

For example, with traceability you can:

* Identify the source of inputs for each artifact.
* Include traceability information as part of an artifact
where appropriate (e.g., in many UML model diagrams).
* Use techniques that help you link two artifacts to each other.
For example, you can see how to link the .NET role-based
security attributes in code with the UML use-case model,
actor diagram, and sequence diagrams, through the role-based
security matrix.
* Whenever you make a code change, identify all artifacts you
need to change, and understand how to make those changes.

[end of excerpt]

In the past, I've mention the three main uses/needs for traceability:
1. Assist change impact analysis (and hence estimation accuracy)
2. Ensure conformance to specs
3. Mandated (by legal/contractual obligation or market industry)

Most of the time it comes up on this list, people use or assume
the 2nd item above and claim its not needed in XP/Agile when I
can show that all my tests pass and all my tests are easily
traceable to the corresponding story (I think part of this is
also not calling a development task "done" until it passes
the tests). I also think that is largely true!

As I look at the impact-analysis use of traceability as described
above, one of the first things that strikes me is that its very
"up front" thinking instead of adaptive. It tries to predict what
will/might happen instead of using feedback upon executable results
to see what does happen.

I think a more adaptive approach would say: create or simulate
the change in an isolated environment, observe see what happens,
then respond to it. If I could do such a "simulation" - would
traceability for the purpose of impact analysis be obsolete?
(do I really need to know which artifacts/entities are touched
if I know what the effects are? Is it still useful for estimation?)

What might be a TDD-way of doing such an executable impact
analysis that didn't take significantly more time to do than to
simply "mock up" all or part of the requested change? (or to
help me find out all the areas of code that would be touched?)

How could I answer the question "what physical [files/classes] and
functional [stories] characteristics are impacted if I add/change
this story or part of a story?" and how can I answer that in an
agile fashion with small and tight rapid-feedback loops that gave
me back an answer without adding too much additional time to my
estimation activity? [I can see how a really nice MDD environment
could be helpful here]

The second question (which really should be the first question)
is, do I really need to answer the "impact" question in the
first place? How much does it help me and my customer to be
able to do that? How much would it improve my estimates, my
team's velocity, our ability to collaborate, and give rapid
executable feedback to our customer if I could do this thing?
[I don't have any ready answers for this - am interested in
opinions from those who actually have or had had this ability
in previous projects (agile or otherwise) and how much their
agile project's would truly benefit from it (or not).

Functionally speaking - why is impact an issue at all? I think
its because it presumably reveals key insights as to the cost
of making the change. But what if my code is maximally well
factored AT ALL TIMES? What if my functional architecture
(e.g., classes, interfaces, packages) my physical architecture
(e.g., files, directories, headers) could:
- maximize encapsulation and localization
- easily correlate my abstractions (e.g., domain objects)
with their corresponding stories/use-cases (as opposed
to trying to trace at the finer-grained level of
line-item requirements and routines/lines of code)
and hence to their corresponding tests

If I aggressively manage and minimize dependencies thru
refactoring and encapsulation, and if I worry about tracing
only at a more coarse-grained level of stories (features)
to abstractions (classes/interfaces), might that not be
enough? Might that be "barely sufficient" to meet most
mandatory/obligatory requirements for formal traceability?

And in the cases where it didn't, how might I take a
simulation/TDD-based approach to impact analysis and
effort estimation for a requested change?

I gave a presentation on "Agile SCM" last week, and several
in the audience asked be about "traceability", and how
to meet mandated traceability in an "agile" fashion (especially
now that things like Sarbanes-Oxley are prompting increasingly
more shops to mandate - a phenomenon which several in the
audience seemed to agree has already started and is growing).

I suggested that agile projects address concerns of traceability
by doing things like:
- Having tests directly traceable to stories (sometimes even
on the same card)
- Minimizing the number of artifacts produce (fewer items means
fewer items and fewer inter-relationships to track and manage)
- Knowing which stories (features) each "commit" is for, and being
able to associate them in the version-control tool if necessary
in order to automate code-level traceability (e.g., a checkin comment)
- Aggressively managing dependencies with (encapsulation/refactoring)
- Using concepts of domain-driven design to ensure the easy correlation
between stories and objects.
- Managing traceability at the level of stories (feature or use-case)
and objects instead of individual line-item requirements and
lines of code (something which good encapsulation makes possible
because low-coupling and high-cohesion increase the odds that
few other objects will be impacted, but the few that are might
impacted throughout)

At the time I said that, I hadn't yet pondered the simulation/TDD-based
approach for traceability hinted at above (nor of the applicability of
Mock-Objects and even AOP to ease t he ability to do so comprehensively).
I would be very interested in hearing if others have done it, or of
how it might be done.

--
Brad Appleton <brad@...> www.bradapp.net
Software CM Patterns (www.scmpatterns.com)
Effective Teamwork, Practical Integration
"And miles to go before I sleep." -- Robert Frost