When I was a software developer I once had the embarrassing experience of reaching the end of a project and realizing I had left something out. I simply forgot to implement a particular agreed-upon requirement. It’s more than embarrassing if the overlooked requirement was to let the pilot lower the airplane’s landing gear, or the one that turned on the respirator in the emergency room. My development process was clearly inadequate because it allowed me to make this mistake. The least consequence of such an error is unexpected rework and delay. More severe outcomes could include delayed product certification or even potential catastrophe.
Embedded systems pose particular design and development challenges. The convergent synthesis of software and hardware engineering faces the reality of hardware being more expensive and time-consuming to modify than software. An overlooked software or system requirement could lead to painful hardware redesign late in the process. Beyond functionality, your team must specify, design, and build the product to protect against serious safety, security, reliability, and performance risks. Yet the imperative to deliver the right product quickly still looms.
“The ability to automatically trace requirements through the system development life cycle is not a nice to have but paramount to our continued success and keeping our regulatory status”Wendy Kennedy, CTO at UltraLinq Healthcare Solutions
Generations of customers, managers, and engineers have lamented how long it takes to build systems that contain software. A busy development team is tempted to skip process steps that don’t appear to add value either to the customer or to the individuals who perform those activities. However, when streamlining your processes you need to think about whether activities that might appear optional do add value to the overall development effort. Such activities might prevent defects, wasted effort, and delays farther downstream, thereby supporting your goal of delivering quality quickly.
Overlooked requirements lead to painful hardware redesigns.
After experiencing my embarrassing requirement oversight, I decided to add a step to my personal software development process. I needed a map that showed where each requirement was implemented in the solution so I wouldn’t make this kind of mistake again. That process step is called requirements tracing, or traceability.
Traceability to the Rescue
Requirements tracing is one of those activities that might appear time-consuming and superfluous but which can totally save your bacon. This is why certifying bodies require requirements traceability information before approving safety- or life-critical products. Requirements traceability involves building a set of threads that link each high-level requirement to its detailed requirements, then to the software and hardware architectural and design components that address those requirements. These requirements ultimately link to the code that implements each one, the tests that verify them in the product, and other related information. Full two-way traceability involves knowing where each customer need turned into requirements and then into downstream deliverables, as well as tracing backwards from any work product to its corresponding requirements and thence to a customer or compliance need.
Requirements tracing provides significant benefits when customized for workplace culture and project objectives.
Properly performed, accumulating requirements traceability information is neither wasted effort nor excessively burdensome. It provides numerous benefits, including the following.
It’s hard to overlook a requirement because you can see when it has not been traced into downstream deliverables.
Business or user requirements that don’t trace to any functionality might indicate that some requirements are missing.
Conversely, functionality that doesn’t trace back to a higher level requirement, business rule, or other origin might be unnecessary.
Nonfunctional requirements in categories like safety, security, reliability, and robustness can be traced to specific functional requirements and design elements to ensure all have been properly addressed.
Trace data facilitates change management. It provides pointers to software and hardware components that you might need to modify when a requirement changes.
This knowledge also aids with impact analysis to estimate the cost or time associated with a change.
When a test fails, the links between tests, requirements, and code point toward likely hiding places for the defect.
Trace information facilitates reusing product components by identifying packages of related requirements, design, code, and tests.
These kinds of benefits help your team move faster with less rework and wasted effort. The price tag is the time needed to collect the traceability data and the investments needed for team education and supporting tools.
Accumulating requirements traceability data is simple when teams build tracing into their processes as they work.
Requirements tracing adds particular value to embedded systems projects. A single system requirement could lead to deriving multiple hardware and software requirements. Each of those requirements must be allocated to specific architectural components, as well as to lower-level elements of the design. Design packages can map to specific hardware components and firmware routines that, in the aggregate, will satisfy the top-level system requirement. It’s easy to overlook one of these vital bits without comprehensive forward tracing. Traceability data also helps you avoid the risks of requirements that lack corresponding tests and tests that cannot be executed because of missing requirements.
Figure 1 illustrates some of the many possible requirements trace links an embedded systems project should consider collecting. Most projects won’t need to manage all of these link types. But the larger, more complex, and riskier the project is, the more value you will reap from the investment you make in requirements traceability.
Making Requirements Tracing Happen
Requirements traceability data doesn’t create itself. You need to build tracing into your process as a task team members perform as they do their work. It’s virtually impossible to reconstruct traceability data from a completed project of any size. However, if you collect traceability information as team members complete chunks of work it becomes a habit that takes just a little time, not a burden. Gathering and managing requirements trace data must be an explicit responsibility of certain individuals or won’t get done.
Table 1 indicates likely sources of various types of trace link information. Think about whom on your team would possess each of these types of link knowledge. Make sure the team members know a development task is not done until they’ve recorded these bits of information.
It’s impossible to manage complex requirements traceability without tool support. Indeed, traceability is a central feature of most commercial requirements management tools. These tools allow individuals to enter the link information as they do the work. You can then view the link information in the form of a requirements traceability matrix. The tools can facilitate change impact analysis by showing which other system elements are linked to a specific requirement so you can make all the necessary modifications.
The Process Works for You
During my 25 years in software process improvement I’ve heard more than one manager protest, “That process stuff will just slow us down!” Poorly selected, implemented, and performed processes absolutely can slow the team down. But a team that thoughtfully chooses and applies appropriate value-added practices will find they succeed because of their processes, not in spite of them. Requirements tracing is one activity that can provide significant benefits when customized for the culture and the project objectives, performed consistently, and accepted by committed management and team members.
The more complex and risky the project, the more value you reap from requirements traceability
I once taught a class on software requirements to an audience that included the CEO of a major car rental company. When I got to the section on traceability he looked up and asked, “Why wouldn’t you want to do this for all of your mission-critical business applications?” That’s an insightful question. This CEO grasped the value of adding thoughtfully selected activities to your development process that can increase your chance of success and reduce the risk of serious and time-consuming errors. Requirements tracing can pay off for you, provided you enable it with trained team members who understand and accept their responsibilities and with adequate tool support to make sure the process works for you.