dsrkkk wrote:
> Whatever process we use, we need to track requirements, user stories
> to design and test cases. The traceability provides obviously many
> benefits. Why don't we automate traceabiliy? How can humanly track
> these complex relationships? If we do manually, we may miss something.

The less you work in a waterfa;lish-way, and the more you work in an
agile fashion with very short feedback loops, the less necessary it
becomes to make additional efforts to track/trace requirements.

If I first do lots of requirements, then lots of design, then lots of
code, etc., I have to "put the pieces together". The task I performed to
write requirements was different from the one that did the design which
was different from the one that did code, tests, etc.

If I work in very short cycles (particularly using test-driven
development), then an individual development task looks something like:
- write a single test
- write the code to pass the test and no more
- refactor the code
- commit my changes (Note I might commit my changes before refactoring too).

If, when I commit my changes to the repository, a associate my "commit"
with the name or id of the story the test was for, then I have a single,
fine-grained change-task that went thru the complete cycle of
specification, implementation/design, verification all in a matter of
minutes for a single "commit" and user-story.

Working in such fine-grained full-lifecycled tasks automatically
associates all the elements that were created & updated as part of the
task, which in turn is associated with a user-story. Ta da!!!!
Traceability comes along for the ride almost automatically.

From "Extreme Locality", in the Feb 2004 "Agile Times", pp.37-40
(http://www.agilealliance.com/resources/agiletimes/agile_times_4.pdf)

. . . . . . . . . . . . . . . . . . . .

In Agile methods, we often hear a lot about the importance of
simplicity: simple design; do the simplest thing that could possibly
work; simple tools; minimal documentation ... Much of the documentation
and artifacts created in larger software development methods is for the
sake of capturing historical knowledge: the rhyme and reasons behind why
something is there, or is designed a certain way.

The desire for such information is often used to justify the need for
formal traceability and additional documentation for the sake of
maintainability and comprehension. Some very powerful and sophisticated
tools exist to do this sort of thing. And yet, there are basic
fundamental principles and simple tactics to apply that can eliminate
much of this burden.

WHENCE FORMAL TRACEABILITY?
The mandate for formal traceability originated from the days of
Department of Defense (DoD) development with very large systems that
included both hardware and software, and encompassed many geographically
dispersed teams collaborating together on different pieces of the whole
system. The systems were often mission critical in that a typical “bug”
might very likely result in catastrophic loss of some kind (loss of
life, limb, livelihood, national security, or obscenely large sums of
money/funding).

At a high level, the purpose of formal traceability was three-fold:

1. Aid project management by improving change *Impact* *Analysis* (to
help estimate effort/cost, and assess risk)

2. Help ensure *Product* *Conformance* to requirements specs (i.e.
ensure the design covers every requirement, the implementation realizes
every design element and every requirement)

3. Help ensure *Process* *Compliance* (only the authorized individuals
worked on the things [requirements, tasks, etc.] they were supposed to do)

On a typical Agile project, there is a single team of typically less
than two-dozen. And that team is likely to be working with less than 10
million lines of code (probably less than 1 million). In such
situations, many of the aforementioned needs for formal traceability can
be satisfactorily ensured without the additional rigor and overhead of
full-fledged formal requirements tracing.

Rigorous traceability isn’t always necessary for the typical Agile
project, except for the conformance auditing, which some Agile methods
accomplish via test-driven design (TDD). A “coach” would be responsible
for process conformance via good practices and good “teaming,” but
likely would not need to have any kind of formal audit (unless obligated
to do so by contract or by market demand or industry standards).

Agile methodologies turn the knob up to 10 on product conformance by
being close to the customer, by working on micro-sized
changes/increments to ensure that minimal artifacts are produced (and
hence with minimal reconciliation) and that communication feedback loops
are small and tight. Fewer artifacts, better communication, pebble-sized
change-tasks with frequent iterations tame the tiger of complexity!

. . . . . . . . . . . . . . . . . . . .

For more then you ever wanted to know about the why&wherefore behind
traceability, see "The Trouble with Tracing: Traceability Dissected" at
(http://www.cmcrossroads.com/article/44526)
--
Brad Appleton <brad {AT} bradapp.net>
Agile CM Environments (http://blog.bradapp.net/)
& Software CM Patterns (www.scmpatterns.com)
"And miles to go before I sleep" -- Robert Frost