Posts:
20,296
Registered:
12/6/03
|
|
|
|
Requirements Traceability
Posted:
Sep 27, 2002 11:00 PM
|
|
[Originally posted by diogenes]
Hi, your book is an absolute goldmine of information, especially for students
like myself who have no real knowledge of industry!
I am currently writing my Masters Thesis on the problems presented when trying
to trace requirements to specifications.
What would you say is the biggest problem in actually using traceability and
why don't CASE tools seem to be resolving the problem?
|
|
Posts:
20,296
Registered:
12/6/03
|
|
|
|
Re: Requirements Traceability
Posted:
Oct 6, 2002 11:00 PM
in response to:
import-bot
|
|
[Originally posted by bkovitz]
Hi, Kev. Glad to hear you're enjoying the book!
Here are some thoughts about traceability.
1. This thought might bring tears to your eyes, if you have a lot
invested in the importance of traceability. In my 16 years or so on
the job, I have never once seen anyone look at or request
information about what traced to what. I once heard a second-hand
story that traceability info was used once (a friend of a friend,
you know), but that's it.
This wiki page has some pretty brutal analysis of this topic:
http://www.c2.com/cgi/wiki?RequirementsTracking
The biggest problem, I think, is just that keeping track of
traceability info costs a lot of bandwidth for no perceivable
benefit.
2. Jackson's notion of separating problem domain from interface
(shared) domain seems to me to solve the problem of traceability at
its root. By discovering facts about the problem domain, we often
discover ways to simplify or even eliminate our ideas for
interfaces. By treating the combination of interface design and
descriptive assumptions about the problem domain as propositions
that should deductively prove that requirements are satisfied, we
get satisfaction that the design really addresses what we care
about. And we sidestep the mess that would result if people really
tried to connect every part of the program to all the requirements
that justify its existence.
This message (posted minutes ago!) gives an example of using
problem-domain info to steer clear of designing and implementing an
unnecessary interface (the last full paragraph):
http://www.manning.com/ao/psr/psrao.html?action=get&id=182&mypage=5
3. One argument for maintaining a traceability matrix is to help
deal with requirements changes. The theory is that some changes
"ripple" throughout the design in complex ways, so you need a sort
of dependency graph to follow the implications. Extreme Programming
has a nice solution to this problem, though: storing requirements as
automated tests. Changing the requirements = changing the tests.
The now-failing tests show you what changes you need to make to the
program. When they pass again, you know the program meets the new
requirements.
That doesn't help prune code that no longer serves a purpose, but if
the programmers are continuously refactoring, any code that doesn't
help pass a test will sooner or later get deleted.
Hmm, I'm afraid I've mostly talked about tracing requirements to
code, not to specifications. Most folks in industry think of the
specifications as the requirements. It's usually seen as the
customer's job to say what screens they want, what use cases they
want, etc. Any connection from interface specifications to desired
conditions in the problem domain is left to the inside of the
customer's mind and is often not discussed. I believe this is
because specifications serve much better as contracts. Requirements
in Jackson's sense are not necessarily met perfectly even by the
best software design.
CASE tools don't solve the problem of relating the specification to
the (domain) requirements because computer programs are systematic
and brittle. Probing for relevant aspects of the problem domain and
brainstorming for better interface designs really requires human
intelligence and creativity. I'm told, though, that traceability
for purposes of accountability and status tracking (keeping lists of
requirements, who provided them, and whether they've been
implemented and tested) is handled well by programs such as DOORS.
I've never used such a program myself, though.
BK
|
|
|
Legend
|
|
Gold: 300
+
pts
|
|
Silver: 100
- 299
pts
|
|
Bronze: 25
- 99
pts
|
|
Manning Author
|
|
Manning Staff
|
|
