There will inevitably be changes to a product’s requirements during the course of a project. Some requirements churn is natural in the beginning, as the developers refine their understanding of the product and the technologies being used to develop it.
In most cases, requirements stabilize after they become part of a baseline and the relevant stakeholders have signed off. If the amount of churn is still high after this point, it can drive up costs, impact quality, or force you to sacrifice key features or functionality in order to get the product out the door on time.
In our new guide, 5 Practices for Reducing Requirements Churn, we discuss how to keep requirements churn from becoming excessive. From using shorter release cycles and reducing review fatigue to improving visibility and exposing the impact of change, this free guide can help your project go as smoothly as possible.
Looking to monitor requirements and design on your TestTrack Home Page? Here are 3 widgets that can help. For these examples, I’m going to assume you’re using a simple requirements workflow as shown below.
TestTrack’s impact analysis tools take the guesswork out of understanding and approving requirement changes. You can quickly understand the scope of changes in the context of the entire project and make better choices about which changes to approve.
To perform impact analysis on a specific requirement, open the requirement and click the Traceability tab. Click Impact Analysis and then select the option for Forward Impact, Backward Impact, or both. Continue reading…
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?
If you work for a company that has explicitly defined standards for writing product requirements, consider yourself lucky. Most organizations don’t have the benefit of documented standards, often resulting in confusion and miscommunication due to poorly written requirements.
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.