spk-logo-white-text-short
0%
1-888-310-4540 (main) / 1-888-707-6150 (support) info@spkaa.com
Select Page

Requirements Management in the PTC Medical Device Solution

Written by SPK Blog Post
Published on October 6, 2015

One of the major points of pain in any development process is how do you prove that the product you’ve built for the marketplace actually does everything you want it to do. The simple answer of course is “Why you test it to make sure.” But the simple answer isn’t always necessarily the right or whole answer. Sure you can test the design, but what if the design is wrong to begin with? What if part of the design misses some vital piece of functionality? What if the need behind some piece of the design changes and the designer never finds out and never alters the design? These questions are why you need something to manage your requirements.

PTC Integrity Lifecycle Manager offers several different solutions to assist customers in managing their requirements. Many customers will use one of these solutions as a starting point, and have organizations like SPK and Associates to configure the solution to suit their specific business needs. Today we are going to talk about how we can manage requirements in the PTC Integrity Lifecycle Manager Medical Device Solution. In an earlier blog article I gave an Overview of the Medical Device Solution for PTC Integrity Lifecycle Manager, where I touched on Requirements Management. Today I will build on that to show you what PTC Integrity Lifecycle Manager has to offer.

Requirements are managed through 3 containers that are referred to as document domains that are linked together through named trace relationships. These documents are the Input Document, the Requirement Specification, and the Design Specification. I will explain each of these in turn below:

SPK Documents and Traces

  1. The Input Document exists to track the rough ideas that will go into your product. This input can be anything from the exterior color of your product, feedback from your customers, the set of safety regulations that you need to follow or even the broad description of the features and functions you want your product to have. It’s these rough ideas that will later be decomposed into specific requirements that your designers will use to develop your product.  The strength of the PTC Integrity Lifecycle Manager comes from the ability to link specific pieces of input directly to the requirements that they are created from via a named trace relationship. The Input Document is linked the Requirements Specification Document via the Decomposes to/Decomposed from trace relationship. Through the trace relationship you can look at a specific item within your Input document and immediately see which requirements were inspired by the current Input item.
  2. The Requirement Specification contains the specific requirements that were decomposed from the Input Document. Where the input document is the generalized information about what you want in your product, the Requirement Specification is where things get specific. These are the items that your system designers will pick-up and use to build your product.  This is where another feature of the named relationship becomes important, the Suspect Flag. Say part way through your development cycle, part of your input document had to be updated. Your customer called up and clarified their feedback, and you updated that feedback into your Input Document. This is a relatively common practice, where most manual or paper based Requirements Management systems can fall apart. Any change to your input, can have a potential impact on the requirements downstream.  In the manual system, there is nothing to inform the author downstream that something has changed other than the good will of the person making the change. Often times the changes are overlooked or forgotten about in the downstream processes.  The Suspect Flag changes this. If, in this case, a change is made in an upstream document, like the Input document, every item that maintains a trace relationship to that upstream item is now flagged as Suspect. That means that the author of a given requirement can, if the suspect flat is set on the trace relationship to a given upstream item, go and review that upstream item and make any required changes to their item before clearing the Suspect Flag. (Also if the author does end up making a change to their Requirement item, all of the related downstream design items and Test items related would then be marked Suspect as well.)SPK TracesSPK UpstreamNote: The question mark in the Relationship Flags field indicates that the trace relationship is now suspect.
  3. The Design Specification contains the design of your product that answers the requirements upstream. This document domain is connected to the Requirements Specification via the Satisfies/Satisfied By trace relationship. Like Requirement Specification, accuracy in the design is maintained via the Suspect Flag. If a requirement is changed upstream, then the related Design item is marked with a Suspect flag.

Another important document that I feel I should mention here is the Test Protocol document. While technically it isn’t used for managing requirements or design, it still plays an important role in the process. The Test Protocol document can be traced from all of the documents above from either of two sets of trace relationships. These trace relationships are Validated By/Validates and Verified By/Verifies. Likewise of any of the items in the documents upstream are updated, the suspect flag will appear on the downstream Tests. In a future article, I will discuss how Test Management works in the Medical Device solution.

As you can see, through the use of Medical Device Solution in PTC Integrity Lifecycle Manager you have an efficient, and effective way developing and maintaining your requirements management process. In a way that not only ensures that you’ve answered every piece of input, requirement and design all the way down the line, but also ensures through the Suspect Flag that you can keep everything up to date as you drive to deliver your product.

Next Steps:

Latest White Papers

The Hybrid-Remote Playbook

The Hybrid-Remote Playbook

Post-pandemic, many companies have shifted to a hybrid or fully remote work environment. Despite many companies having fully remote workers, many still rely on synchronous communication. Loom offers a way for employees to work on their own time, without as many...

Related Resources

OKR and Agile: Harmonizing Strategic Goals with Agile Methodologies

OKR and Agile: Harmonizing Strategic Goals with Agile Methodologies

Objectives and Key Results (OKRs) and Agile methodologies like Scrum, Kanban, and SAFe are powerful frameworks designed to boost productivity and keep teams aligned. OKRs drive strategic goal-setting and measurable outcomes, while Agile approaches like Scrum focus on...

How Model-Based Definition (MBD) Cuts ECOs by 41% and Scrap by 47%

How Model-Based Definition (MBD) Cuts ECOs by 41% and Scrap by 47%

Organizations are increasingly turning to Model-Based Definition (MBD) to revolutionize their engineering and manufacturing processes. By embedding rich, digital annotations directly into 3D models, MBD provides a single source of truth for product definitions. This...