Requirements Tracing

In larger projects with many requirements, tracing of requirement keys is a necessity to ensure the completion of all deliverables. But even for smaller projects, the number of requirement keys increases throughout the life cycle, and it becomes too complex to bear everything in mind.

Requirements tracing ensures that all defined keys have been considered in the core workflows of the Unified Process. For readability, the book does not show the requirements everywhere they have been analyzed or the design is discussed, but we can trace all keys to code, unit, and integration tests.

First, we create XSL formatting files to extract the requirement keys from the following XML document types:

• The requirement specification
• Code documentation (implementation and unit tests)
• The integration test specification

To ease the comparison of the extracted keys, it is best to output them as plain text lines. Listing 13.3 shows the XSL file to extract all keys from the requirement specification.

Listing 13.3 KeysInRS.xsl: Formatting File to Extract Keys from RS Documents

To extract the requirement keys from the implementation, we use the code documentation file generated with Visual Studio. The requirement tag is listed under a member (either class or method). Because the unit tests are also added to the same solution, we check whether the member name includes Test. If it does not include Test in its name, the key belongs to the actual implementation of functionality; otherwise, it is a method that implements a unit test.

Listing 13.4 shows the XSL formatting file to extract keys that belong to the actual implementation. To extract keys belonging to test code, we remove the not() keyword from the test attribute.

Listing 13.4 KeysInCode.xsl: Formatting File to Extract Keys from Implementation

[View full width]

So far, we have hard-coded links to the formatting stylesheet in the XML file itself. This is rather inconvenient because we need to apply different stylesheets to the same document. Also, it would be nice to extract the keys from a command line program so that we can put all necessary steps into a command batch file instead of executing them manually.

For this purpose, we create a small tool that takes two arguments: an XML document file and an XSL formatting file. The formatted result of applying the stylesheet to the XML document is output to the standard console. Listing 13.5 shows the code for a command line tool that can be used to apply a stylesheet to an XML document.

Listing 13.5 FormatXML.cs: Tool for Formatting an XML Document

using System; using System.IO; using System.Xml; using System.Xml.XPath; using System.Xml.Xsl; namespace FormatXML { ///

/// Tool that formats an XML document using an XSL stylesheet. ///

class Class1 { ///

/// The main entry point for the application. ///

[STAThread] static void Main(string[] args) { if (args.Length != 2) { Console.Error.WriteLine("Missing or invalid arguments!"); return; } try { XslTransform xslt = new XslTransform(); xslt.Load(args[1]); XPathDocument xpathdocument = new XPathDocument(args[0]); XmlTextWriter writer = new XmlTextWriter(Console.Out); writer.Formatting=Formatting.Indented; xslt.Transform(xpathdocument, null, writer, null); } catch { Console.Error.WriteLine("Error reading input file!"); } } } }

After compiling this tool, we copy it to a location listed in the system's Path environment variable. Next, remove the hard links to the formatting stylesheets from the RS.XML and ITS.XML documents. To format the requirement specification to an HTML document named RS.htm, type this command:

FormatXML RS.XML RS.XSL > RS.HTM

The following command will list all requirement keys defined in the requirement specification:

FormatXML RS.XML KeysInRs.XSL

Using XSL stylesheets and the formatting tool, we can now easily trace requirements in the various core workflows. Table 13.2 lists the tracing results.

For each key, all core workflows should be traceable. We must analyze missing workflows to determine whether they were skipped to implement certain functionality or to test for them. In most cases it will turn out that the functionality was implemented, but it was skipped to add the key at the proper location. Other keys, such as architectural requirements, are not really traceable to an implementation and should be evaluated during code reviews.

We have traced almost all the requirement keys of the project throughout the different workflows of the photo editor application as well as Online Photo Shop. There are only a few keys missing, and they refer to general constraints or limitations of the software and do not address functionality that needs to be implemented. Such keys (for example, the coding conventions document) are therefore not traceable to code or test but should be considered during the architectural design or process definitions.