Advertisement
Articles
Advertisement

Trace Early, Trace Often to Improve Your Development Process

Fri, 02/07/2014 - 2:45pm
Matt Harp, Product Marketing Director, Seapine Software

Figure 1: Trace early and often. Images: Seapine SoftwareMany companies have recognized an untapped opportunity for improving their development process: the requirements traceability matrix. Rather than wait until the end of the development cycle, the team builds the trace matrix when requirements first go under design control, and maintains it all the way through the submission process.

The traceability matrix is a cornerstone to getting through a PMA or 510(k) submission successfully. Historically, the trace matrix is built as one of the last project deliverables. Once a medical device is designed and tested, the team goes back and connects the dots to create a trace matrix for regulatory submission. It’s treated as a necessary evil, with the team feeling forced to focus on what they consider “busy work” at the end of an otherwise finished project.

When a “trace early, trace often” policy is in place, the traceability matrix feeds valuable information into the development process. By creating the matrix early and updating it as the work progresses, team members gain an improved ability to estimate testing needs, as well as better visibility into risk and hazard mitigation work. They can also assess the impact of proposed changes quickly, and conduct transfers between groups more easily.

A single source of truth
The key to realizing these benefits is to build out the initial trace matrix early in the design process, as user needs are being defined. At that point in the development cycle, the trace matrix is a relatively simple document to build and maintain because there isn’t much information to populate it. So why not wait until there is more information? Because building it now gets team members in the habit of maintaining it throughout the project.

As user needs are further defined and broken down into use cases, product requirements and system specifications, the trace matrix grows more complex and serves as the source of truth for planning the testing effort. By building the trace matrix early, and iterating on it as the design progresses, the entire team has one shared asset that gives them a high-level view of all the project assets.

Estimate testing needs with accuracy
Planning the testing and verification effort for a development cycle is never simple. By giving teams real-time visibility into user needs, use cases, product requirements and the like, companies help make a challenging process more manageable.

With an accurate and up-to-date trace matrix, the team has a head start in preparing to test the product. It also allows them to help the design team improve their requirements and specifications to make testing easier and more effective.

Gain more visibility into risk and hazard mitigation
Throughout the design process, ongoing risk analysis and mitigation work ensures potential hazards are identified and their severity reduced in the final product. Integrating risk and hazard mitigation artifacts into an up-to-date trace matrix that is already part of the team’s working process is much simpler than building and maintaining a standalone risk document. And again, the team continues to work from one shared source of truth regarding design, test and risk assets.

Figure 2: Handle change requests logically.Assess change impact quickly
When a single trace matrix links requirements, system specifications, hazards and testing assets, the team can handle change requests logically—not accept and reject them based on guesswork. The trace matrix allows team members to conduct real-time forward and backward impact analysis to better understand the level of effort and risk involved in accepting a change. How many test cases will need to be re-written? How does the change impact hazard mitigation work that’s already been done? Does the change eliminate a hazard the team identified, and therefore actually save project time? These are questions that can’t be answered quickly, if at all, when design, test and risk artifacts are managed in separate documents. By building the trace matrix early, and making it part of the team’s working process, handling change requests becomes a more straightforward process.

Simplify transfers between groups
In addition to helping teams work more effectively, the trace matrix can also play a role in transferring work between groups. The requirements trace matrix serves as the single source of truth for the entire team, give everyone visibility into all project assets. This reduces the risk that some assets will sit forgotten in a person’s inbox, or be lost when a computer crashes or an employee leaves the company.

Trace early, often
More and more companies are finding that building their trace matrix early, and maintaining that information throughout the development cycle, can greatly improve their development process. Early in the process, the trace matrix improves the collaboration between design and verification resulting in more efficient and effective testing. By incorporating risk and hazard artifacts into the matrix, it also helps the team to better mitigate hazards and prove their risk-based approach to the FDA.

When inevitable change requests emerge, the trace matrix is an invaluable source of information for understanding the impact of those change requests. And throughout the entire development process, the trace matrix serves as the single source of truth, simplifying transfers between groups and giving everyone visibility into project progress.

Advertisement

Share This Story

X
You may login with either your assigned username or your e-mail address.
The password field is case sensitive.
Loading