How do you know if you have coded all the requirements or have created test cases to verify all the requirements? How confident are you that you have tested all requirements? Unless there is an effective way for you to show management or the customer that you can measure these numbers, you will be simply guessing.

What is Requirements Traceability

Industry data suggests that approximately 50 percent of product defects originate in the requirements. Perhaps 80 percent of the rework effort on a development project can be traced to requirements defects. Anything you can do to prevent requirements errors from propagating downstream will save you time and money. [Inspecting Requirements, Karl Wiegers, 2001]

Requirements traceability allows the ability to trace code modules and individual test cases back to specific requirements. It also defines the linkages between various artifacts of the development process, such as business requirements, use cases, functional requirements, design specification, and defects.

Why is Requirements Traceability Important

Requirements traceability is a necessity in the software development lifecycle. This is the way to tell whether the requirements have been fulfilled in each of the deliverables, and to ensure that the product is functioning correctly.

Other than tracking existing relationships among artifacts, requirements traceability can also help to report broken linkages. For instance, if a feature in the application or test case is not traced back to the origin, the question should be asked whether the specific implementation is necessary or whether the test case is not testing what it should.

Requirements traceability is also beneficial for risk analysis when a requirement needs to be changed. Sometimes developers or project managers agree to make suggested changes without carefully thinking through the implications. [Karl Wiegers Describes Ten Requirements Traps to Avoid, Karl Wieger, 2000] Based on the linkages created between the documents, it should be a simple matter for risk analysts and Change Control Board (CCB) to determine the extent of the impact of the change on documentation artifacts, coding and testing. Careful consideration can then be made about whether making the change or not is reasonable given expected quantifiable impact/risk to the product, its resources, and schedule at that point in time.

When to do Requirements Traceability

Requirements traceability is something that needs to be done throughout the software development lifecycle. And, it is important to start requirements traceability as early as possible in the process, and to verify the linkage at the end of each phase. This helps to ensure any faults in the documentation are caught before creating subsequent documents.

Initially, the customer usually provides the business requirements, which show what the system needs to accomplish from the business point of view. These high-level requirements generally do not give enough details for developers to code, or for QA to write test cases. Therefore, documents such as user requirements (in the form of use cases) and functional requirements are needed, to provide the detail of the flow of the application, and the detail of each component respectively.

In order to make sure none of the original business requirements were missed in the process of creating these new documents, each requirement in these new documents must be traceable back to the business requirements. At this point, it is only the beginning of the extent of requirements traceability. As the lifecycle progress, more and more documents will be included - the design specification and the test cases need to link to the functional requirements and user requirements, and ultimately, to the business requirements by following up the chain.

Beware that before putting requirements traceability into the project process, each requirement should be well described and uniquely identified. If they are not, requirements traceability may become ineffective as documents become incorrectly linked.

Although it is easy to recognize that requirements traceability is a vital process in the development lifecycle, it is often neglected. This is because of the perception that it significantly slows down the project. In general, development projects are on a very tight schedule, and therefore, requirements traceability seems to be an extra burden or a luxury.

Manual Requirements Traceability

Requirements traceability is usually maintained through a traceability matrix. If you do not want or are unable to invest in expensive tools at this time, simple spreadsheet software can be used. The following example illustrates a sample traceability matrix.

If an item in one level has changed, any subsequent levels will be affected. For instance, if functional requirement "123" has changed, the corresponding design specification, code, and test cases must be updated as well.

If this task can be assigned to one person on the team who would be responsible for creating the traceability matrix, time would not be taken away from other team members. However, the person responsible must have easy access to all documents that are in progress.

At first, it appears to be reasonable to use a spreadsheet to capture the relationships. This is true if there are only a handful of requirements for the product. If there are many requirements that need to be tracked, the job to maintain the traceability matrix manually using a spreadsheet will become tedious and unmanageable. Not to mention that there may be constant requirements changes that cause the traceability matrix to often become out-dated during the course of the project. A solution to this is to automate requirements traceability.

Automate Requirements Traceability

Anyone with experience in any type of software automation likely realizes that before the automation process can even begin, time needs to be spent on defining the requirements of the automation and then researching for the right tool. Finding a tool that can be used for requirements traceability is not an exception. These tools are typically referred to as requirements management (RM) applications.

As suggested by Bill Councill and Carol Councill [Automating Requirements Traceability, Bill Councill/Carol Councill, 2000], RM applications should support the following features:

1. The tool's capability to accept import of / or conduct queries on, relationships among the following lifecycle work products:
   1. Business rules
   2. Business models
   3. Requirements
   4. Use cases
   5. Other object-oriented or component-based design diagrams
   6. Test Cases
2. Seamless integration with the following tools:
   1. Object-Oriented Analysis & Design or component-based analysis and design application
   2. Defect and test case management application
3. The ability to establish and compare baseline requirements for selected builds or versions
4. The ability to add, modify, and delete attributes by requirement type

You may not require all the above features for your project and so you will want to find a tool that is suitable for your project's specific needs. However, it is important to keep in mind that having the majority of features in one tool will minimize the issues of integration with different tools in the future.

Entering all the artifacts in the RM application, and creating the links as the items are created can generate reports such as the requirement matrices easily at anytime. Automating requirements traceability not only saves time from doing everything manually, but most importantly, the reports being generated are always up to date to reflect the current status of the project. This is something that management and the customers would like to see in order to monitor the progress.

Summary

Requirements traceability is vital to a project, whether it is big or small. It is the common thread that ensures that the verification and validation of the project is complete. [Automating Traceability of Requirements to Test Cases & Defect Logs - a case study, Krishna Rajan, T.A. Indira]

Although requirements traceability may slow down the day-to-day of the project, it should not be neglected. It will help you keep the project on track, avoid any unnecessary rework efforts, and unless requirements can be tracked accurately through the artifacts created during the project lifecycle, it is impossible to ensure that the software is built for the intended purposes and tested adequately.

For more information...

QA Labs' test experts construct effective test strategies and realistic estimates tailored to your timeframe and resource realities. Our standards and best practices have been honed with experience on hundreds of projects. QA Labs paves the way for immediate and on-going quality improvements by establishing critical test artifacts, practical automation - all while getting those bugs logged.

Our clients hire us knowing they have hired a company, not an individual or group of individuals. We bring our comprehensive experience to the table and can provide the exact resource skill sets needed at exactly the right time. QA Labs offers a clear, cost-effective, alternative to hiring individual contractors, and even to hiring new permanent full-time employees.

Contact us at services@qalabs.com or visit our website for more information on our QA and Testing services.