When a requirement changes, dependent items may be impacted. Without a full understanding of a requirement’s dependencies, there is an increased risk of making uninformed decisions about implementing changes. An overlooked dependency can quickly cause a ripple effect of missed changes, ultimately resulting in schedule overruns and scope creep.
TestTrack’s impact analysis capabilities can take the guesswork out of understanding and approving requirement changes by helping you quickly understand the scope of changes in the context of the entire project.
We’ve made breaking down requirements much easier with TestTrack 2014.1. Now you have the ability to create requirements and tasks from another requirement with a single click. Let’s take a simple example, where you’re creating system specs from product requirements and then breaking down each system spec into a set of tasks for the team. Using Item Mapping Rules, you can quickly create the logic necessary to enable single-click creation of a task from a system specification.
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.
How early in the process do you create your traceability matrix? At the beginning of a project, so you can take advantage of it throughout the development process? Or do you wait until the end, and generate it as an item on your compliance checklist?
In our recently completed 2013 State of Medical Device Development Survey we asked medical device professionals, “What are the top three pieces of information or insights you wish you had better visibility into during the design control phase?” The most common response? Risk controls!
If you look at the responses to another question we asked about how teams are managing their risk artifacts, you won’t be surprised that folks are struggling with visibility into those artifacts. Almost 90% of teams are using documents to manage risk identification, analysis, and mitigation.
Seapine’s recently completed 2013 State of Medical Device Development Survey gathered insight and feedback from more than 400 individuals working in the medical device industry, covering all organizational levels and roles within the medical device field. In addition to general questions about the way folks are developing medical devices, we drilled down into their practices and challenges in three key areas; risk control, design control, and quality control. If you’re interested in how your processes compare to our industry benchmarks, download the full report.
Specific to design control processes, we asked a few questions that are highlighted below along with response data. The first question centered around visibility into project assets. Sadly, survey results indicate most teams don’t have real-time visibility into their data, and must track down and dig through multiple documents to get that information. Not only is this time-consuming, but it often results in incomplete or outdated information being used to make decisions.
Thanks for everyone that participated in the “Beyond FDA Compliance Webinar: 5 Hidden Benefits of Your Traceability Matrix” webinar. The webinar recording is now available if you weren’t able to attend or if you would like to watch it again. Transcript from the webinar Q & A follows.
When you’re contemplating new features for a device or dealing with the need to change existing requirements, the impact on hazards and risk mitigation can often get lost in the shuffle. If adequate traceability is not maintained throughout the design control process, it can be challenging to identify what risks will be impacted if a specific requirement is added or modified.
It seems like a straightforward proposition. We have a business problem, and we start a project to address that problem. Business analysts look at the problem domain, interview users, and come up with a set of project requirements that drive a subsequent application development effort.
But what happens in larger organizations where there are multiple projects going on at the same time? Especially if the various applications work with one another in some way? It’s possible that some requirements in different projects can conflict with one another, even to the extent of one project reversing a feature required by another.
In organizations where rushing software out the door is the standard operating procedure, test managers must develop inventive ways to recruit and retain staff, find time to perform the essentials of testing, and ensure that important defects are addressed.