As product design becomes more complex, spanning engineering and including interrelated mechanical, electrical and software requirements, managing those requirements and providing traceability across the design process has become more critical. Designers need a way to ensure their work comports to customer expectations, functional requirements and government regulations. They need visibility into how a change in one component can affect the system. Failing to do so can cause delays, recalls or even complete project failures.
“In the past requirements could be relatively simple because products were relatively simple,” says Doug Akers, vice president of ALM solution management at PTC. “You had a purely physical product. As software becomes more pervasive and as products start interacting with the environment and other products, it’s no longer so simple. Those requirements live on because you have to be able to reiterate on that design, and take derivatives. The requirements now have a genealogy. Traceability becomes essential; you need to know which specification comes from which version of which requirements within which product family.”
In many organizations, engineering and design work was completed in silos, which made this type of traceability difficult or impossible. PLM (product lifecycle management) and ALM (application lifecycle management), for example, were typically managed separately. “So the requirements were kept in one or the other system, or in a stand-alone environment,” says Dennis George, Teamcenter marketing manager at Siemens PLM Software. “It’s difficult to link requirements in a standalone environment. At a high[er] level, you wouldn’t know what the breakdown was for the product or for the software elements.”
Requirements for tracking and traceability tools now provide a way for companies to trace requirements forward and backward within the process, and to provide an audit trail. This type of functionality is critical for validation testing. In markets like medical devices and other highly regulated industries, traceability itself is part of the compliance requirement.
“That helps define the regulatory strategy and types of clinical trials you have to do,” says Arieh Halpern, director of Life Sciences Industry at Dassault Systèmes. “Transitioning down, you then transfer those product requirements to engineering, and they’ll take those and put together an engineering product design spec. Those verification tests can be very simple or can involve thousands of tests if you get into something like a robotic surgical system. Requirements traceability is fundamental to being able to develop the test plan against each of those requirements.”
Traceability failures typically occur because of disconnected design processes, or the use of paper documents or spreadsheets to manage requirements. These approaches make it difficult to ensure traceability or revision control.
“That paper document may go from marketing to engineering and be put into a requirements tracking program, but you don’t have backward traceability to the initial document,” Halpern says. “You [can] lose those initial requirements, and in some cases companies don’t even use software to track those requirements in the first place.”
Testing requirements could then be developed against what may not be the final release version of the engineering product specification, which means testing won’t be 100% accurate or complete. That could warrant a recall.
The volume of the information that has to be tracked also has complicated requirements tracking. Employees can only keep track of so much information or keep so much data on hand. “Up and down the supply chain, traceability becomes essential,” Akers says.
With regulatory requirements, both risk and scrutiny are higher. Having a tool to manage that process and provide an audit trail alleviates some of that project risk. “If you are in a regulatory environment and don’t have a trace on those requirements, you are far from being OK,” Akers says. “You need to have evidence that test results are directly linked to your requirements.”
A System-Wide View
There are a variety of software approaches to requirements traceability, available as stand-alone or modules, or included as features in PLM or ALM tools. These solutions should provide the ability to trace requirements both forward and backward as they change.
Users should also be able to validate the total system, including both hardware and software that are increasingly interlinked. All of those subsets of requirements should be linked to a master product requirement set.
“You need to make sure you are taking a system view of the product before you decide which of the three disciplines (hardware, software or electrical) will tackle a change,” Akers says. “Having that system view that is independent of the implementation is the first key to solving that challenge. It’s not the complete solution to the problem, but it helps.”
Halpern agrees: “You should be able to keep those early requirements in place and strike them as they change so you are working off of one master document. You can see the changes that have been made, and the features or requirements that have been removed for specific reasons.”
Auditing capabilities are also critical for regulatory compliance traceability. “The FDA has been known to close down a product or prevent it from being shipped, or even shut down a whole division until you are in compliance,” Halpern says. “That’s why it’s important to have complete document management.”
Traceability also enables impact analysis, allowing you to see how a change to the design or to the requirements can affect the end product.
Tools can help you create workflows across design groups that are uniform and consistent, so when a change is proposed everyone understands what will happen. “An e-mail will tell them what is associated with the change, or if there is a task that must be completed and who needs to sign off on it,” Siemens’ George says. “All of this needs to be done in tools they are familiar with.”
According to Akers, this process is made much easier if traceability is an automatic, secondary element of the primary design activities associated with meeting the requirements. “You can create those relationships automatically,” Akers says. “The processes create the traces. The network is the foundation of a solution, not the end point. When I’m writing requirements, I’m deriving that from the neighboring requirements, and those traces should be created as I do the derivation. When I write code, the trace should be attached to the design I’m writing code for. Traces are a byproduct of productive work.”
The Human Element is Critical
Cultural and operational changes have to accompany the use of requirements tracking solutions for the systems to work effectively. Processes and workflows have to be mapped, and employees need to understand the importance of accurate traces.
“The software really ensures complete traceability forward and backward,” Halpern says. “That doesn’t mean it’s not open to human error; if you mis-enter information or convert a document incorrectly, you’ll have errors. But the software tools are still a thousand times better than if you are working from paper.”
Companies have to ensure that changes and impact assessments are communicated to the right people, and employees should understand their role in the development process and how they affect requirements compliance. “They have to understand the importance of traceability,” Akers says. “It’s easy to overlook when you are dealing with different tools and processes.”
There also needs to be a clear process to ensure that requirement changes are linked throughout the entire product lifecycle. There can be thousands of changes to a given FDA regulation during the development process, and those changes have to be kept consistent within the development process.
“As you receive requirements, you make sure the appropriate people are responsible for entering the data into the system,” George says. “You have to capture the requirements so that they can be linked to the product development process as well as making sure that the mechanism people use in order to get those requirements into the system is one that is familiar to them.”
The industry continues to put new demands on requirements tracking tools. Halpern says customers are asking for CAD or mechanical drawings to be linked to requirements documents, and for the ability to extend that linkage to the parts supply chain.
“You have high-level requirements, but if you get into electrical design you have to make sure that those components adhere to certain specifications,” Halpern says. “You have to go out to the supply chain and ensure that the parts meets those standards. This goes all the way down to individual components.”
Another emerging need is the ability to propagate change on a massive scale across product families. “If you have to network hundreds of thousands of artifacts and you want to branch all of those traces, how do you do that at scale at the product level?” Akers says. “That spans multiple disciplines.”
The emergence of the Internet of Things will create new demands for traceability, while also providing a real-time data feed from the product in the field. Companies are also looking for ways to better link requirements across different design domains. “How do we make sure software requirements are linked and tightly tied to the electronics that turn them, or the mechanical operations associated with them?” George says. “How do you assess potential changes and the effect they have on other domains? That’s where the biggest focus is.”
These emerging traceability needs should be folded into existing workflows that will make it easier and less disruptive to managing complex requirements. “Customers come to us with a traceability problem, and their misconception is that traceability is hard,” Akers says. “It shouldn’t be. Process is hard, and engineering products is hard. Traceability is easy if it is a byproduct of natural work.”