How to meet launch dates and deliver an application that does what it's supposed to do
by Marco Leon
You are about to deploy your initial build to the production environment. The quality assurance team is hard at work addressing the last few areas that they put off while concentrating on an inventory problem. Suddenly, they notify you of a defect in the administration module: The administrator does not have the ability to override and change the prices in the catalog. The project manager verifies that, according to the requirements, the administrator should indeed be able to change prices. Now, you need to change database tables, add new logic to the code, create new screens, and most important, inform the client that the launch date is in jeopardy.
This scenario is a classic case of a requirements management problem. As a project becomes more complex, the risk of missing certain details along the way increases. Missed details often result in an application that doesn’t do everything it is supposed to do. And that means costly recoding and launch delays. One of the best ways to minimize such errors is to conduct a traceability analysis. It is a very valuable but seldom used technique in today’s development processes. Traceability analysis is rarer still in the Internet-development industry, where it is even more essential.
Traceability is an analysis of the work products, such as the requirements and specifications documents, in a development project and involves relating virtually every artifact back to the requirement from which it originated. Every requirement agreed upon before and during the development of an application should have something designed to satisfy that requirement. Although beyond the scope of this column, I believe that proper requirements gathering and articulation is quite difficult and should not be taken lightly.
Traceability offers considerable benefits for your project:
•Coverage analysis: The main benefit of traceability is verifying that all requirements have been satisfied. Lower-profile requirements usually get overlooked, which often delays code-freeze dates. You can’t expect to remember everything the client or end-user needs.
•Fulfilled contracts: Contracts, statements of work, and letters of intent frequently have requirements outlined as a set of obligations to your client. Conducting a traceability analysis can be essential in avoiding a breach of contract.
•Better design: Best-of-breed designs are only possible when the architect has complete information from which to design. By finding many of the holes in the requirements and specifications, good system architects obtain the information they need to develop the best design and deliver a quality solution.
•Fewer code reworks: A simple traceability analysis can often save a project by catching potential problems early and minimizing time and money spent on code reworks.
•Improved change management: By knowing what is being designed to satisfy each requirement, you can immediately determine what has to be revisited as a result of a change up the traceability tree. Many requirements management tools have features that make this very easy to visualize.
•Stronger configuration management: Because you can visualize relationships and their impact when they are changed, your configuration management becomes much more robust and easier to maintain.
•Shorter development cycles: All these benefits ultimately result in shorter development cycles and more on-time launches.
Traceability analysis is especially important on Web development projects, for precisely the same reason that it is often ignored — tight schedules. Internet-site launches usually have compressed schedules with set launch dates tied to multimillion-dollar marketing campaigns. Partnership agreements may also have the launch date as a critical milestone. In such cases, traceability analysis is invaluable for shortening development cycles and increasing the likelihood of meeting target launch dates.
Performing a Traceability Analysis
Traceability analysis begins with gathering artifacts to trace. Artifacts are anything developed or configured specially for the application. These artifacts may include proposals, statements of work, requirements, functional specifications, technical specifications, copy decks, test plans, test cases, code, configuration files, and network schemas. The most important items to trace, because they yield the greatest benefits, are the requirements and the specifications. You may know the specifications document as the design or architecture document, but this document details the application being built, as opposed to the rules and functions it must comply with.
To be useful for tracing, those documents should attempt to describe the subject in full. If the authors aren’t diligent and only enter the items they don’t want to forget, then you will be unable to account for a number of requirements and left with no standard for compliance. Under those circumstances, tracing is a very frustrating exercise. If you can easily attribute every hole in the specification and requirements document to “the author just didn’t write it down,” then the traceability exercise loses its key benefit — coverage analysis. You achieve the most benefit from tracing when you fully commit to designing, testing, and building to a set of requirements.
Let’s consider a simple and common example relevant to e-commerce Web sites. A typical requirement is that the site needs to be able to give the status of an order placed through the Web site. I’ll label this requirement “Req1.1.” At first, it may seem like a simple, straightforward requirement; however, Req1.1 immediately implies several other requirements. In order to give the order status, the system must acquire data to track orders through to the fulfillment entity. The system may also need to capture the UPS or FedEx tracking number. These requirements in turn generate further requirements. In any case, you can see that simply preparing the requirements for a traceability analysis can uncover other related requirements, which may save time later on.
So how do these requirements map to the specifications? You trace a link on the main navigation bar that says “Order Status” to Req1.1. The entire section of the specifications detailing the elements in the order-status page maps to Req1.1. Depending on how the architect organizes the functions, the user may need to go through multiple pages — all tracing back to Req1.1 — before seeing the actual order status. The technical specification that details how you will capture and store the tracking number is also traced to Req1.1. And don’t forget the artwork, the order status results page, and the links to the UPS or FedEx sites. Quite a number of relationships from just one requirement.
How do you know what should be traced to what? Any design element that resulted from a statement in the requirements should be traced back to that requirement. Any design element that would change as the result of that requirement changing should also be traced back to the original requirement. This is obviously much easier said than done. These correlations are not necessarily obvious and do not have the benefit of one-to-one relationships. One requirement can have multiple design elements traced to it, and you can have one design element satisfying multiple requirements. As you can see from the example, traceability exercises require a thorough knowledge and follow-on analysis of the system’s requirements and specifications.
Now what if Req1.1 changed? What if the new requirement is not that the user be redirected to another site, such as ups.com, to retrieve the shipping status, but instead, that the user sees all the shipping information displayed on a page within the site? What has to change? All the specifications related to Req1.1 now become suspect and need to be reviewed to see if they still satisfy Req1.1. In addition, the changed requirement means engineering new specifications, including new database tables, artwork, and page layouts. If you articulate all the relationships, you can manage changes efficiently — and we all know that change is the only constant in our business!
Planning for the Process
For a thorough, accurate analysis, the person doing the traceability exercise has to have a very good understanding of the entire system, a good knowledge of technical system design, a good knowledge of the project’s goals and objectives, and an ability to extract and articulate implied requirements. A team could do traceability, but realistically, one person is typically responsible for the analysis — usually a quality assurance analyst or a business analyst. If it’s a quality assurance analyst, then an added benefit is that this person will know the system inside and out and can thoroughly verify the system during the testing phase.
The tool that my team at MarchFirst uses for traceability analyses is Rational Software Corp.’s RequisitePro. It has a good interface, and it integrates seamlessly with Microsoft Word. It also has some nice reporting tools and features, such as automatically highlighting related specifications as suspect when something on a higher branch is changed. Another useful tool is Quality Systems & Software (QSS) Inc.’s Doors. You can evaluate a list of available requirements management tools at www.incose.org/tools/tooltax/ reqtrace_tools.html.
Pressed for Time
You may be convinced of the value of traceability analysis, but you probably also face immovable deadlines and unforgiving budgets. A full traceability analysis takes time, and the more complex the project, the longer it takes. If you have been diligent about managing the project and are still pressed for time, then it may not be prudent to conduct a full traceability analysis. You certainly don’t want the tracing process to be the cause of a delayed launch! Sometimes it’s just not possible to conduct a traceability analysis on every one of your application development projects, to the ideal level of detail. In such cases, you can take shortcuts to at least reap some of the benefits of traceability.
First, simply revisiting the proposal, statement of work, and even the original management presentation before you launch or deliver an application is a valuable traceability exercise. Even reviewing requirements at that level could save the project from failure.
If you have a bit more time but still not enough to do a complete traceability analysis, concentrate your efforts on the most critical documents: the requirements and the specifications (design). If some element of tracing has to be cut, the test plan and test cases are less critical and can be eliminated from the trace. The impact of missing a key design element is much greater than the impact of missing a test element.
If you don’t have enough time to trace every line item, then you can do a cursory traceability on the groups of requirements to the components in the specifications. For example, by checking that you have a search section in the specifications, you know that it will satisfy the search requirement. You may not be able to verify the specific types of searches it must handle, but you at least know you won’t miss it entirely. Although not ideal, this solution may uncover blatant oversights. Use what time and resources you have to at least conduct high-level checks of your application.
The slickest application is really only useful if it does what your client needs it to do. Because of the complexity, hurried pace, and constant changes that are inherent in application development, traceability analysis is essential to ensure that all system requirements are met. E-business applications have all these types of special demands that make traceability analysis even more important. Although full traceability may not be feasible for all projects, get in the habit of conducting at least a basic review of the system requirements and specifications. It can make the difference between costly delays and the successful launch of an application that really works.
Marco Leon (marco.leon@marchFIRST.com) is associate partner for quality assurance in MarchFirst’s New York office and has managed the quality assurance on more than 70 Web engagements.
