AgileAttitudes Article
 
 
 

Vol 02 Issue 06- What About Traceability

  
 
Back to the list of articles 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@agilerules.com. O><O><O><O><O><O Your feedback is welcome! Send feedback to info@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@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.</plaintext> </td id="bodytable_r1_c3_body"> </tr id="bodytable_r1"> </table id="bodytable">