Why Trace Requirements?

[article]
Overcoming resistance to requirements tracing
Member Submitted
Summary:

Requirements traceability isn't difficult to understand or implement. As with many process improvements, the hard part is to convince the development team that the practice will benefit them and their project in some meaningful, practical way. This brief article looks at some of the benefits of requirements tracing and offers advice for overcoming resistance to implementation.

A colleague, who is responsible for helping his organization improve their software development process, recently reported that he's having a terrible time convincing his organization to trace their requirements. His managers and developers understand what requirements traceability is and how to implement it, but don't believe that they or their projects have anything to gain by doing so. In fact, the level of resistance is so high that he's beginning to wonder if maybe they're right. He asks: "Would an automated requirements management tool make the practice easier, and therefore more acceptable? Is the practice only useful for larger projects? Should we wait until we've reached a higher level of process maturity before trying to implement this practice?"

I can't think of any project, regardless of size or level of process maturity, that wouldn't benefit from requirements tracing. The only exception would be a project whose customers are so easy to please that they'll gladly take anything the project team gives them. (Not likely!)

Requirements tracing is the process of documenting the links between the user requirements for the system you're building and the work products developed to implement and verify those requirements. These work products include software requirements, design specifications, software code, test plans and other artifacts of the systems development process. Requirements tracing helps the project team to understand which parts of the design and code implement the user's requirements, and which tests are necessary to verify that the user's requirements have been implemented correctly.

If you don't do requirements traceability, how do you make sure that:

  • The system you build has the necessary functionality to meet your customers' and users' needs and expectations "Surprising" your customer with a system that doesn't do what they wanted isn't a pleasant experience for anyone.
  • The completed system contains only the functionality needed and wanted? "Extra" functionality may not seem like a problem until you consider that it costs time, money, and effort to develop. It's also a source of defects, which may cause problems for your customer after installation.
  • Developers work first on implementing the requirements, which are most important to the customer? If you know which code components implement the customer’s high-priority requirements, you can work on those first, improving your chances of shipping a useful product on schedule.
  • Testers work first on verifying the most important functionality? This will help you determine when and if the first versions of the system are ready to release.
  • Appropriate test plans and test cases are written and executed to verify that all of the system requirements were implemented? Mapping test cases to the requirements helps make sure that you don't miss a major defect in the system.
  • All system components affected by a change request are modified and nothing is overlooked? This also helps you evaluate the impact of a change request. A seemingly simple request might involve changes to several parts of the system, and it's better to understand how much work will be needed before agreeing to make the change.

I've done software process improvement work since 1993, and I can attest to how challenging it can be to get an organization to change its processes. In my experience, very few people will willingly embrace change if they don't understand how the new process will benefit them, if the process is burdensome or takes extra time (especially if they’re already working overtime to get their existing tasks done), or if their managers don't demonstrate that they care whether the new process is followed or not. If, like my colleague, you’d like your organization to get started with requirements tracing, here are some ideas which should build acceptance and encourage people to give the practice a try:

  • Keep it simple. You can easily set up a traceability matrix by creating a table with a word processor. (See Figure 1 for an example.) List the user’s requirements in the left column. List the work products, which are derived from the user requirements across the top row. (At a minimum, you should include Requirements, Design, Code, and Test work products.) Then, as software requirements, design elements, objects or code modules, and test cases needed to implement and test each user requirement are developed, their designators should be entered into the cells of the matrix.

Figure 1. Segment of a simple traceability matrix from an image processing program

User Requirement Functional Requirement Design Code Test Code
13 Display image thumbnails 127 Class Thumbnail thumbnail display 12.4
14 Allow user to select desired thumbnail 128 Class Thumbnail thumbnail select 12.5
15 Allow user to resize image 142 Class Image image resize 15.6
  • Get your process in place and develop the discipline to follow it before investing in an automated tool. Decide which work products you will trace. Decide who will responsible for requirements traceability. Decide how you maintain traceability as change requests come in. Finally, make sure that time is scheduled for people to do the work needed to set up and maintain the traceability records. An automated requirements management tool will make the job easier, but is no substitute for a good process.
  • Don't try to make the developers do it. In my experience, saying that a task is everyone’s responsibility rarely results in that task being done consistently or well. Instead, assign responsibility for gathering information and maintaining the requirements traceability matrix to a specific team member such as the project librarian (the team member who organizes and maintains the project’s documentation). I've also seen this task done by the project’s systems engineer, SQA practitioner, quality leader, or configuration manager. In any case, the task should be done by someone with visibility into requirements, design, coding, and testing if these functions are performed by different groups of people.
  • Try the practice as a pilot. If you can't convince your whole organization that this is the best practice since structured programming, then try to get at least one project team to take a leap of faith and just try it as a pilot. Choose the project carefully to ensure that they will make a good effort. Make it as painless as possible, and look for ways to show that the practice helps in some way to make the project more successful.
  • Educate everyone. Work hard to help everyone (including technical leaders and managers) understand why they should support the new practice. Use examples of problems that have occurred in your organization that might have been prevented by requirements traceability. Make sure you tell the managers what you want them to do to support the practice. When you're getting started with requirements traceability, managers should communicate their support to their people. Managers should check periodically to be sure the practice is still being followed, and reward people who do so. Above all, technical leaders and managers whose work products appear on the traceability matrix should "walk the talk" by making sure their traceability information is kept up to date.

Requirements tracing is simple to understand, but it can be hard to put into practice in a busy development project team. Helping everyone understand why the practice is important, and making its' adoption as easy for the project team as you can will improve your chances of implementing this practice successfully.

About the author

StickyMinds is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.