Re: [AM] Why Traceability?

(responding to all)

Between you, most of the 'reasons' for traceability
that arose on the other forums have been touched on.

Most popular - tracing from requirements to code to
ensure the requirement has been coded.

Other interesting reasons - Aid to Impact Assessment
(I'll get back to that - it's a very murky reason...)

Tracing low level (detailed) requirements back to high
level requirements to ensure the 'vision' is being
followed and 'extras' are not creeping in.
(Dubious, maybe this needs re-visiting?)

Justification.  For each fragment of code, there should be
a corresponding requirement.  This is, among other things,
meant to eliminate 'back doors' etc.

Empire Building.  Tina's point - it makes work, we can get
more people on the team, keep them busy.  This thinking
would need to hide behind some other 'reason'.

Keeping documentation in sync - I think this should be
distinct from Impact Assessment, but there's definitely 
some overlap.

Big 2000 lb Gorilla - some standards body or other
immovable force says you must do it, without reason
or explanation.

IMHO, agile approaches can deal with all of these,
except possibly the 'Justification'.

<rant mode>
Of all the people that quoted Impact Assessment as the
reason, I have yet to find a credible explanation unless
we assume a level of incompetence in the developers of
the existing code that would surely render any traceability
information worthless.  

The argument that the trace for a known requirement gives
an idea of what needs to change when the requirement 
changes does not hold up to inspection.  The change
may be a very small change in a large amount of code.
OTOH, the change may require writing of a heap of new 
code, or interaction with new areas of existing code, and no 
traceability information will tell us much about this.

The alternative explanation, that when we touch each
part of the code, the traceability tells us what else may
be affected, is more credible.  However, this only makes
sense if there has been no work to counteract the 'ripple 
effect', and a change to one area of code *could* give 
problems to a remote area of code.  One wonders if there
was ever a time in history when we could expect developers
to collect reliable traceability information, but not to 
counteract the ripple effect.
</rant mode>

Get rid of the ripple effect, and Impact Assessment is
akin to any other estimation problem.

As for tracing low-level requirements to high-level
requirements, this does rather smack of a lack of trust
in the provider of requirements.  If the requirements
provider is being careful to rank the requirements by
the value they provide, at what point should the 
'overall' customer become worried that the vision
is being exceeded?  I guess this will depend on the
customer who holds the purse strings.


Paul Oldfield

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
www.aptprocess.com

any opinions expressed herein are not necessarily those of
Mentors of Cally or the Appropriate Process Movement
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: [email protected]

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: [email protected]

For Topica's complete suite of email marketing solutions visit:
http://www.topica.com/?p=TEXFOOTER
--^----------------------------------------------------------------