Medical Device Link.

Originally Published MDDI January 2004

Systems Development

The translation of compliance requirements into procedures is a complicated process. There usually isn’t a one-to-one relationship between a specific item in a compliance requirement and a paragraph in a procedure. In order to make a procedure usable, it needs to be presented in terms of an overall process the reader can understand. The compliance requirements provide a backbone, but subject-matter experts (SMEs) are needed to provide best practices and appropriate process steps for each procedure that extends beyond the required activities and deliverables.

Figure A shows two specific GP1268 compliance requirements, and Figure B shows how those two requirements can be translated into a procedure. The procedure example shows the hidden text tracing to the compliance requirements. Whenever the binding term shall is used, the procedure includes hidden text to directly reference the supporting compliance requirement. This helps maintain traceability and ensures all requirements are covered. The terms should and may are used to indicate recommended best practices that aren’t tied to compliance requirements.

The technical writer uses this information to create the first draft of the procedure, which is revised after working sessions with the SMEs. The draft document is submitted to designated general reviewers, who provide additional input for a final version. This review and revision process can be time-consuming, particularly for more-complicated procedures.

Once all of the procedures have gone through a complete review cycle, it is critical to conduct a final review of the entire document to ensure consistency and accuracy across all procedures. Once any revisions have been incorporated, the procedures can then be submitted for final approval and publication.

5.3.12 The project shall ensure that each software requirement be evalua-
ted for accuracy, completeness, consistency, testability, correctness, and clarity.

5.3.13 The project shall ensure that each software requirement be analyzed to confirm that:

• All of the performance requirements for the
system have been identified.
• Fault-tolerance and security requirements are
complete and correct. 
• Allocations of software functions from system
requirements are accurate and complete.
• Software requirements are appropriate for the
system hazards.
• All requirements are expressed in the terms
that are measurable.

3.2.2 Evaluate State Requirements

The project team shall (GP 1268, 5.3.12) assess the requirements for problems such as ambiguity, incompleteness, and 
inconsistencies. This activity is iterative and some tasks may 
be performed several times throughout a project.

For projects rated high, if the requirements are approved and released 
incrementally, the project team shall (GP1268, 5.3.12) ensure that
interactions and interfaces among requirements have been properly reviewed, analyzed, and controlled.

The following is a list of areas that shall (GP1268, 5.3.12) be addressed when evaluating requirements.

•Unambigious—requirements shall (GP1268, 5.3.12) be clear and have only one possible interpretation.

•Complete—although it may be impossible to know all future requirements
for a system, the requirements shall (GP1268, 5.3.12) specify all known requirements.

•Testable—there shall (GP1268, 5.3.12 and 5.3.13, bullet 5) exist some means by which it can be measured or checked that the final system meets this requirement.

•Consistent—a requirement shall (G1268, 5.3.12) not conflict with other requirements. Many people have an interest in the system, and their 
requirements may vary; therefore, the project team should actively 
identify and resolve conflicts to derive a conflict-free specification.

•Traceable—each requirement shall (GP1268, 5.3.12, and 5.3.13, bullet 3) be traced back to the higher-level requirement.

•Correct—requirements shall (GP1268, 5.3.12) accurately describe something the stakeholders have requested.

Copyright ©2004 Medical Device & Diagnostic Industry