Agile Attitudes- What About Traceability?
agileattitudes at agilerules.com
agileattitudes at agilerules.com
Tue Apr 5 15:17:22 EDT 2005
Agile Attitudes
Volume 2, Issue 06 Apr. 5, 2005
A free bi-weekly email newsletter
Brought to you by
Agile Rules consulting
www.agilerules.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Welcome to Agile Attitudes, a newsletter of ideas, insights and
technical tips that help people find better ways to develop
software. Feel free to share this with anyone - just be sure you
send or print the whole thing, including the copyright notice.
Directions for managing your subscription are below.
O><O><O><O><O><O
Agile related meetings and other events in the Boston area are
discussed on the Agile Bazaar email list. For info see:
http://groups.yahoo.com/group/AgileBazaar/
O><O><O><O><O><O
If you would like to receive an email as soon as we know of
an event in the Boston area of interest to the agile software
community, you can sign up for the announcements list at
http://www.agilerules.com/mailman/listinfo/agileannounce
O><O><O><O><O><O
What About Traceability?
by Ron Morsicato and Nancy Van Schooenderwoert
In agile software development we manage requirements by reviewing
them for importance very often, and commit to implementing them a
few at a time during an iteration. This is akin to manufacturing
practice of companies like Toyoto or Dell who don't build a product
until there is an order for it. There is no time lag between
receiving an order and filling it - no inventory to maintain - one
less activity draining the resources of an organization. One of
these inventory maintenance activities is to keep tabs on what's in
the inventory, so that when an order comes in the product matching
the specification in the order can be retrieved - a kind of tracing,
if you will.
Is requirements traceability one of those activities that really
doesn't add value?
Why do we do a traceability analysis? Because it helps us to be
sure we're covering all the requirements when building the system.
So it's natural to then ask whether a traceability matrix is the
best way to do this. Since we have a set of requirements and a set
of acceptance tests, they have to map into each other. The fallout
of this is that efforts must be made to create and maintain that
mapping.
Agile software development marries the creation of the requirements
and testing artifacts into a single activity. Poof! A seemingly
necessary activity gone! This is some trick if you can do it, and
agile practitioners believe you can do it if you try.
In traditional staged development, tests are created sometime after
requirements. But effort must be made to fully understand the
requirements so that the tests will properly cover them. This same
effort happens in agile development but right at the start. The
same group of people at the same time collaborate to create the
requirements and the tests that will verify them. The same document
that lists requirement specifies their tests as executable tables.
This avoids:
* requirements that are not testable
* misunderstanding of requirements by test designers
* requirements getting out of synch with the test set
What's this about executable tables? If you use Fit or FitNesse to
create your specifications, you end up with a single document that
is both requirements spec and acceptance test plan. You can execute
this, and the inputs and outputs specified in the tables will be
checked by code that runs your actual production software. Related
tests can be organized into "test suites". By definition, this
shows that your code does meet all the requirements. Instant
traceability!
This method does more than just avoid the pitfalls mentioned above.
It creates a collaborative atmosphere that links customers with
project sponsers, business analyists, testers and developers. Every
one of them can contribute to FitNesse's Wiki, to Fit's
spreadsheet. The requirements/test specification document becomes
an instrument that helps everyone see the whole, that binds an
entire community of people focusing on a common understanding.
For more information on the open source tools mentioned above, see
http://www.fitnesse.org and http://fit.c2.com.
O><O><O><O><O><O
More articles on Agile software topics at http://www.agilerules.com
Within our company we have a sub-specialty in embedded systems.
Our site has articles on embedded XP and we support a discussion
list focused on the use of agile methods for building embedded
software. The list signup info is at
http://www.agilerules.com/mailinglists.phtml
O><O><O><O><O><O
To help you get started with in-depth research into Agile Attitudes
topics, we have added a Library section to our web site at
http://www.agilerules.com/library.phtml
Order using our links and receive discounts up to 30%!
O><O><O><O><O><O
If you enjoyed this issue or found it useful, forward it to a
friend! Help spread the word about better ways to build software.
Invite your friends and colleagues to join our growing reader
community at http://www.agilerules.com/mailinglists.phtml
O><O><O><O><O><O
Looking for a speaker for your next corporate or society meeting?
We present dynamic, informative programs on topics of interest
to managers and technical staff in their transition to more
flexible, robust ways to create software.
O><O><O><O><O><O
Want to reprint this issue in your company or society newsletter?
For permission to reprint any of the articles, contact us at
info at agilerules.com.
O><O><O><O><O><O
Your feedback is welcome! Send feedback to info at agilerules.com
To manage your subscription:
http://www.agilerules.com/mailman/listinfo/agileattitudes
O><O><O><O><O><O
Brought to you by Agile Rules consulting
162 Marrett Road, Lexington MA 02421
Copyright (c) 2004, 2005 Agile Rules
info at agilerules.com
O><O><O><O><O><O
Privacy notice: We will not release a subscriber's address to any
third party for any reason. This is a strictly opt-in newsletter.
No one is ever subscribed without their explicit request.
More information about the AgileAttitudes
mailing list