Abstract. This introductory tutorial goes beyond explaining Design Controls within
the Quality System Regulation (QSR) by outlining low cost, integrated product/process
team (IPPT) methods to attain and maintain auditable compliance with its ten provisions
while producing quality products to minimized schedules for new projects. (The general IPPT
approach is described in the second ODDSCO tutorial in this set.) When the tutorial text is set
off with double quote marks, it is a direct quotation from the Design Controls subpart of the
QSR. When text is placed in brackets [like this], it is this Author's synopsis of the much
lengthier QSR text.
Ongoing projects to design and manufacture complex embedded systems medical devices involve
many employees. Obviously, Project Management and project team members from Engineering must
be familiar with QSR design controls. Manufacturing, Purchasing, Field Service, Quality
Assurance, Regulatory Affairs, Document Control, and Human Relations employees also perform tasks that must be
compliant with the QSR provisions for Design Controls. Accordingly, understanding of Design
Controls also must be relatively widespread throughout a medical device development
organization.
At the end of this tutorial is your opportunity to pose question(s) on this subject to the
Author.
Return to Home Page [Use a Return Link after any of
the listed subsections to quickly reach this option.]
(a) General (1) states, “Each manufacturer of any ... class III or class II device
... shall establish and maintain procedures to control the design of the device ... to
ensure that specified design requirements are met.”
Typically, each medical device manufacturer provides Procedures and Instructions (P&Is)
intended to ensure that work performed to develop their products is auditably compliant with
the associated provisions of the QSR. Further, the P&Is must be maintained for continued
correspondence to evolving and improving work processes. An IPPT approach is recommended for
planning and controlling P&Is maintenance as well as for accomplishing new product
development projects as described in the remainder of this training segment.
Nearly all of the remaining subsections (b) through (i) open with the requirement “Each
manufacturer shall establish and maintain [plans or procedures to or for] ... [accomplishing
provisions of that subsection].” The last subsection (j) requires a Design History File
(DHF) as the formal record of accomplishing subsections (b) through (i).]
Scope and scale of design and implementation tasks can range from extremely simple to
relatively complex. Accordingly, the PMP document design must support planning for conceptual
worst case new or upgrade projects while avoiding inappropriate documentation burdens for
intermediate to small projects. An IPPT solution is based on two powerful methods for managing
project documentation:
1. Provide standardized, integrated templates for every project document type. That is,
develop an outline for each document that can encompass the perceived worst case project need
for its content while minimizing the information overlap with the other project documents.
Further, provide instructions for general and specific content in the predefined sections and
subsections of the outline.
2. Provide for tailoring the documents to evaluated scope and scale of the project, beginning
with provision for a tailoring plan in the PMP document template. When tailoring is approved,
the PMP contains instructions that enable it and the associated project documents to have
their planned content reduced to match the need.
The PMP instructions for tailoring of each template enables the authors and document reviewers
to ‘know’ the minimum information required for completing each project document and where
therein to put it. This early knowledge of required deliverables content assists developing
initial budget and schedule estimates that correlate well with intent of the approved project
plan. Tailoring instructions must be specified with unambiguous clarity such that project plan
fulfillment remains auditable.
Medical Device Manufacturers that understand and apply classical Systems Engineering have
someone from that specialty develop most of the PMP and specific tailoring for the Project
Manager. However, many (if not most) medical device manufacturers understnd that specialty
function label as equivalent to engineering systems (which is what all good engineers in the
‘core competencies’ of electrical, mechanical, and software engineering automatically do as
part of their jobs). Accordingly, see the also free seventh tutorial mentioned with the
Tutorial Two link on the Home Page to learn the important differences.
Design input is defined in QSR 820.30 as “physical and performance requirements of a
device that are used as the basis for a device design.” Design input therefore ranges
from elicited customer inputs to requirements for addressing “the intended use of the
device, including needs of the user and patient” to at least the top level software and
hardware requirements specifications that drive detailed design. Further, “procedures
shall include a mechanism for addressing incomplete, ambiguous, or conflicting
requirements.” [‘Intended use’ also is the statement of purpose and function, target
patient population, intended environment of use, and medical safety and effectiveness claims
for a device, as it is provided in the 510(k) premarket notifications to the FDA.]
Marketing surveys, Medical department clarification and User studies, predicate or competitor
device features, Quality Function Deployment (with ‘House of Quality’) and other sources, if
any, may be used to determine a set of economically prioritized customer needs and wants as
inputs. These customer inputs to the medical device requirements are recorded for reference
during project decision-making. A convenient label in this tutorial for this record of the
customer inputs is Customer Requirements Document (CRD).
A highest level system specification sets forth selected customer inputs as development project
functional, performance, and design qualification requirements in general engineering terms.
The label used in this tutorial for that system specification is Product Requirements Document
(PRD). To fulfill the QSR provisions for design controls, the CRD inputs to the PRD must be
addressed formally. This does not mean that each CRD input becomes a system requirement for
immediate project development. Addressing the specific customer inputs can be by notation of
deferral or partial or optional implementation. The PRD requirements are derived into system
level Hardware Requirements Specification(s) (HRS) as mechanical and electrical devices functional,
performance, and design qualification requirements. Similarly, the PRD provides design inputs
to the system level Software Requirements Specification(s) (SRS). The PRD and each HRS and SRS
“shall be reviewed and approved by a designated individual(s). ... [and]
documented.”
‘Requirements rule’ could be a suitable slogan for medical device development projects. The
Requirements Management methods are a means to produce the auditable design inputs/outputs
records that show compliance with the QSR provisions for Design Controls. Requirements are
the formal means to describe a device or its software such that any competent entity could be
contracted to design and develop it. A requirement in a specification is a natural language
statement that sets forth a mandatory characteristic or functional behavior to be provided by
the developed product or process. In fact, unambiguous and verifiable requirements become the
single recipe that development teams are to follow for design, manufacture, and ‘testing’ of a
specified item.
A requirement statement is correct and complete when it fully responds to its design input
and is verifiable by one or more of the following methods: instrumented test, demonstration,
inspection, and/or analysis. One method for writing such requirements text is consistently
using a predefined standard sentence structure along with applying some simple rules for
their wording.
PRD requirements translate customer input functions/performance into engineering terms as
design input for development of the project deliverables by the hardware and software design
teams. Requirements for functions and performance to be provided by the project output state
what is needed and how well it must work. That is, except in limited situations, requirements
do not specify how to fulfill the function. The PRD also lists various company and external
(domestic and international) medical device safety standards and other design qualification
criteria to which the design output often must be in accord. (Even when the standards are not
mandatory for enabling foreign sales of the medical devices, it is often prudent to use them
for design guidance.) Other features (the ‘...ilities’) may be required for qualification of
the device design. Some common examples are Availability (Reliability and Maintainability),
Feasibility (technological, economic, socio-political), Adaptability (future use),
Producibility, Supportability, Usability (ergonomic suitability), Disposability, and
Vulnerability/Survivability (harsh use).
In the simplest projects of small scope and scale, as defined by the PMP tailoring, the PRD
can be combined with the CRD.
Most PRD requirements are allocated/derived into subsidiary system level hardware and software
requirements specifications (HRS and SRS) based on functional subsystems of the conceptual
system architectures. When a system is relatively complex, each major subsystem may have its
separate HRS and SRS. Each system level hardware and software requirement results from deriving
one or more portions of source PRD functional and performance requirement into their separate
electrical, mechanical, and/or software requirements. Emphasizing the general rule, HRS and
SRS requirements state what the system hardware and software must do but almost never how to
do it. (The exception is that implementation can be specified in a system level requirement
when interface with a preexisting or predefined separate system (that may be a specific user)
is necessary.)
Unambiguous and verifiable requirements are the single recipe that development team members
follow for design, manufacture, and ‘testing’ of the specified item, so they should be accurate
as well as comprehensive. Finally, each requirement should specify a single function (or be the
parent requirement to only closely affiliated functions). When well written, the requirements
can describe a product such that its design and manufacture could be outsourced. Here, text
stating a function to be fulfilled (and/or how well it must be done) is necessary but may not
be sufficient to form a valid system requirement. Until fulfillment of a requirement statement
may be unambiguously confirmed for a developed product or process (via one or more of test,
demonstration, inspection, or analysis), it is not valid for use and must be rewritten.
Auditable evidence of compliance with the FDA Quality System Regulation provisions for design
controls must be produced during every medical device development project. Requirements
Management is a name for the set of activities that result in such evidence by providing
trace from the PRD requirements (as selected customer inputs) to their validation. That
traceability is provided by a project Requirements Verification/Validation Trace Matrix/Report
(RVTM). Each PRD requirement related to some selected design qualification items (such as
accelerated life testing, extreme environmental conditions, or electromagnetic compatibility)
may be traced directly to a general validation procedure. Each PRD requirement that is to be
implemented by hardware and/or software is traced to its derived requirement(s).
Because it displays the complete text as well as an identifier for each requirement, an RVTM
enables inspecting each subsidiary hardware and software requirement for correct and complete
response to its driving PRD requirement (and thereby is a “mechanism for addressing
incomplete, ambiguous, or conflicting requirements”).
Each derived requirement also is traced to its formal verification procedure/test case, thus
indicating where its driving PRD requirement is indirectly validated. Listing requirements
being verified or validated in each cited procedure ultimately completes the tracing. Summary
reports of verification and validation procedures performance cite their results as objective
evidence of the requirements fulfillment.
Thus, a comprehensive RVTM provides each medical device development project with its ‘roadmap’
to the auditable evidence for proving design controls compliance.
Below that system requirement level, the design engineers provide implementation, design, test,
and manufacturing ‘requirements’ that describe how the HRS or SRS requirements are to be
fulfilled. In simple, small scope and scale projects, design or implementation detail may be
included in an HRS or SRS using a lower paragraph header level than the driving system level
requirements (for automatic tracing) or in a separate document section. Separate documents for
this application are the Hardware or Software Design Descriptions (HDD or SDD). The design
engineers determine what is needed for subsystems and components functions and performance and
begin to develop the detailed drawings, schematics, and software modules for the described
solutions. Where a complex or complicated firmware or software algorithm must be elaborated, a
detailed design description (DDD) may be developed as a separate document referenced by the HDD
or SDD. Verification of these lower level ‘requirements’ is informal (regardless of rigor) and
is performed by the assigned design specialists (or their peers, when independence is desired).
As the PRD is developed, the project team develops a preliminary system concept architecture
diagram with major subsystem blocks that show internal and external interconnections. This
concept architecture is revised during derivation of system level requirements into the
various system and/or subsystem specifications (HRS and SRS). With the system functions
becoming well known, a Preliminary Hazard Analysis (PHA) is begun as the required first
element in the project Risk Analysis portion of the design validation. Previous hazard analyses
are a source of potentially applicable hazards for the new projects. The Hazard Analysis can be
made partially compliant with ISO 14971, Medical Devices – Application of Risk Management to
Medical Devices, by matching its hazard catalog organization. Further, with a minor change to
the traditional project Hazard Analysis, the RVTM also can trace to the evidence of actual risk
reduction for an initially unacceptable assessed hazard risk level. Simply append a citation of
the PRD requirement that will be allocated into the HRS or SRS requirement that drives
implementation of the proposed hazard risk level abatement action. Include a citation in the
RVTM that identifies the hazard being abated (by the allocated HRD or SRS requirement for that
PRD requirement. Because the RVTM shows trace to the test step(s) in the verification procedure
for that HRS or SRS requirement, the evidence for each such hazard risk level reduction will be
provided in the report of the procedure results.
However, for each identified hazard with residual risk (unacceptable risk level still existing
after all reasonably practicable abatements have been required and implemented), ISO 14971 also
requires the responsible executive management to affirm that benefit of device use for patient
treatment exceeds the assessed risk (to take reaponsibility for such residual risk). Citation
of this affirmation should be an annotation to each such hazard in the PHA to enable its
release by document control.
Another top-down document, that may be developed in parallel with the PHA, is a Fault Tree
Analysis (FTA) that begins with an Event of Serious Injury or Death for a patient or user
and defines the categories of equipment or process (or human action) faults that could result
in that top Event as logical OR gate inputs. The use described here is not traditional, with
lack of fault probability estimates, but is very useful for evaluating and refining a concept
architecture, as follows:
Each category is subdivided into the multiple faults that could lead to an event in that
category. The subdivision of faults continues until one of two conditions is met.
1. Each subsystem or component fault is input to a logical AND gate along with an associated
crosschecking process or component (that also must fail, to enable passage of the fault
event to the point of causing the defined harm).
2. The fault is a single point failure item that must have adequate reliability for
supporting intended use of the device over its projected lifetime (plus some prudent
margin).
With subsystems implementation well defined, each is subjected to the bottom-up Failure
Mode and Effects Analysis (FMEA) evaluation as the last element of the project Risk
Analysis portion of its design validation. Each FTA identified single point failure must
be included in an FMEA. Because FMEA is based upon a nearly completed design, likelihood
of including the corrective actions stated for abating an unacceptable assessed risk
level is high. Requiring citation of the drawing or software component (and engineering
change notice for any retrofit) implementing that design correction within the FMEA helps
to enforce its occurence.
As a design is further refined for the hardware, design specialists translate subsystem
concepts into mechanical drawings and electrical schematics. When design and fabrication
require specialty firms, procurement specifications are developed. Because commercial
off-the-shelf (COTS) components with second sources are preferred, selection of these
items is made. The electrical documents include interconnect diagrams, electrical crate
and/or rack diagrams indicating individual chassis locations, cables drawings, and the
Interface Control Document (ICD), as well as new design schematics. The implementation
requirements in the HRS are updated to describe the developing design, so they can become
theory of operation descriptions to accompany the drawings and schematics in the system
service manual.
The definition for Design output in QSR 820.30 is “the results of a design effort at each
phase and at the end of the total design effort. The finished design output is the basis for
the device master record. The total finished design output consists of the device, its
packaging and labeling, and the device master record.” Despite the association with the
early development and the design review(s) implied by “each phase” in the first
sentence of the definition, this subsection emphasizes a finished device: “Design output
procedures shall contain or make reference to acceptance criteria and shall ensure that those
design outputs that are essential for the proper functioning of the device are
identified.”
In keeping with the definition for design output in QSR 820.30, many design inputs are outputs
from previous stages in the “total design effort” and their use is further
described in (e) Design review. Along with the device, total finished design output includes
the device master record (DMR) that is associated closely with this subsection. Briefly, the
DMR contains all the information that would be necessary to duplicate the device in its
delivered configuration. QSR 820.181 states: “The DMR for each type of device shall
include, or refer to the location of, the following information:
(a) Device specifications including appropriate drawings ... component specifications, and
software specifications;
(b) Production process specifications including the appropriate equipment specifications,
production methods, production procedures, and production environment specifications;
(c) Quality assurance procedures and specifications including acceptance criteria and the
quality assurance equipment to be used;
(d) Packaging and labeling specifications, including methods and processes used; and
(e) Installation, maintenance, and servicing procedures and methods.”
As described in QSR 820.130, “packaging and shipping containers are ... to protect the
device from alteration or damage ...” Labeling extends beyond the ordinary meaning for
identifiers and warnings affixed to equipment and packaging to include Service Manuals and
User/Operating Manuals because they are the means to ensure that the device will be “safe
and effective” each time it is used.
Successful progression through each stage of device development requires applying the
complementary process described next:
The output of each phase of the device development is subject to extensive design review
procedures as defined in an associated instruction. A System Requirements Review (SRR) ensures
that the PRD responds to the CRD outputs for the customer inputs to requirements that were
accepted for implementing. The initial concept architectures, Preliminary Hazard Analysis and
Preliminary Fault Tree Analysis may be included in the SRR.
The Preliminary Design Review (PDR) ensures that each HRS and SRS responds to the PRD outputs
as its inputs. The Preliminary Hazard Analysis identifies the PRD requirements that ultimately
are to drive implementation of means to abate previously unacceptable risk levels. Further, the
Requirements Verification/Validation Trace Matrix/Report (RVTM) cites the risk analysis items
being addressed. Systems Engineering or Quality Assurance teams can make initial assignment of
the planned verification method(s) for the permutations for each requirement as instrumented
test (T), demonstration (D), inspection (I), or analysis (A). (This method enables inclusion of
the verification plan in the Project Management Plan and precludes development of a detailed
verification specification that is named as the verificayion plan and duplicates work to
develop the verification procedure. (Keep plans simple!)
Following the PDR, the hardware and software engineers begin developing designs intended to
fulfill the HRS and SRS requirements for subsystems. Often, hardware and software design
‘requirements’ in separate subsidiary design descriptions (HDD or SDD) detail how the design
is to be implemented. If care is taken to retain their subordinate status to the formal
requirements, which prevents their mandated inclusion in the formal verification procedures,
implementation descriptions may be included in the HRS and SRS instead of in separate HDD or
SRS documents. Detailed drawings, schematics, and software module definitions then are
developed by the mechanical, electrical and software design specialists. Systems Engineering or
Quality Assurance teams begin development of the formal requirements verification procedures as
initially defined by the verification plan assignments in the RVTM.
A Critical Design Review (CDR) ensures that proposed physical incarnation of the hardware
design(s) along with the installed software will fulfill the HRS and SRS functional and
performance requirements. Components are defined in preparation for their procurement.
A Production Readiness Review (PRR) ensures that the designs are suited for manufacture or
purchase or issuance of a contract to an approved developer or supplier. User and Service
Manuals are developed from the design information as part of the labeling.
Each document that is produced as part of the design output is reviewed by project team
members and corrected until designated signatories approve its inclusion in the Document
Control System as a formally released item.
The RVTM, developed throughout the stages of the device development, maps HRS and SRS
requirements allocation/derivation from the PRD requirements and on to steps in their
verification procedures. The easily accessed trace assists design engineers in ensuring correct
design output results from the design input; that the implemented device will fulfill its
functional and performance requirements (and hazard risk level abatements) when installed,
reducing quantity and scope of the PDR and CDR Action Items.
Along with the mapping from each HRS and SRS requirement to its subsequent verification
procedure step(s), the RVTM identified the verification means to be employed in that procedure
as one or more of: instrumented test, demonstration, inspection, or analysis. The thorough RVTM
trace mapping assists System Engineering (or QA) and design engineers in developing formal
verification and informal test cases to confirm (or deny) that an implemented subsystem will
fulfill its functional and performance requirements as set forth in the HRS(s) and SRS(s). When the
identified Verification Procedures are near release, the RVTM is updated to indicate the
location therein (step) of each test case for verifying each requirement (and accompanying
hazard risk level resuction).
Each Verification Procedure identified in the RVTM references its Verification Report as a
sibling document. Each Verification Report has one-to-one section header correspondence with
the test cases in its sibling Verification Procedure. Thus, the hazard requiring assessed risk
level abatement in the Hazard Analysis can be traced to confirmation of its implementation via
the RVTM. This approach to documenting verification provides trace to the auditable proof of
compliance with Risk Analysis as well as with the Requirements Management aspects of QSR
provisions for design controls.
Functional and performance requirements in the PRD are derived from customer inputs to
requirements (the CRD). Because most are further derived into system level requirements in the
HRS and SRS documents and then into implementation and design requirements, their verification
is the vast majority of the validation process. The remainder of validation involves confirming
fulfillment of system design qualification requirements that cannot be measured with simple,
one-time checks because cumulative assessments must be developed. Examples are deliberate use
of erroneous inputs to user interfaces, accelerated life or use tests, electromagnetic
compatibility testing, environmental stress screening, conformance to boyh domestic and
international standards, and other such means to determine system suitability for its intended
use(s). For lengthy predicted device use periods and other areas where test, demonstration, and
inspection are less than directly applicable, analysis becomes the only practical validation
method.
Along with mapping from each PRD requirement not derived into any subsidiary hardware or
software requirement to its assigned validation procedure, the RVTM identifies validation means
to be employed in that procedure. As for verification, the means is one or more of instrumented
test, demonstration, inspection, or analysis assigned to each requirement. The RVTM trace
assists Systems (or QA) Engineers in developing formal validation test cases that confirm (or
deny) that the implemented and installed system fulfills its system design qualification
requirements. The RVTM indicates location in Validation Procedures of each test case for
validating each permutation of the associated top level requirement. Each project unique
Validation Procedure references its Report as a sibling document. Because Validation Procedures
often are broadly conceived standards common to all projects, the references to their project
unique Validation Reports may accompany identification of such procedures in the RVTM. A hazard
or fault requiring risk level abatement in the Hazard Analysis or FMEA may be traced in the
RVTM to confirmation of its implementation via a directly validated design qualification
requirement. This approach to validation documentation provides more trace to the auditable
proof of compliance with the applicable QSR provisions for design controls.
Here, emphasis is on ensuring “that the device design is correctly translated into
production specifications.” Depth and breadth of each translation depends entirely
on which permutation of a make or buy decision applies to the system, subsystem, or
component to be produced. Some of the device design may be contracted to an external
entity that will do or arrange for the item fabrication and supply the design drawings
and schematics in accordance with company standards for inclusion in a Device Master
Record (DMR).
QSR 820.30 definition for the DMR is “a compilation of records containing the
procedures and specifications for a finished device.” The DMR contents detail is
provided in QSR 820.181 and listed above in (d) Design output. Repeating earlier mention,
the DMR is a collection of all that it would take to precisely duplicate the product.
A recommended approach for the design transfer process is to go beyond ensuring auditable
compliance by including Manufacturing Engineering early in the design process such that
ease of fabrication and assembly join maintainability to become a concern of embedded
systems hardware design specialists. Benefits may also apply to external producers and be
realized as cost bid reductions.
Whenever a requirement above implementation level is known to be (or might be) affected,
the described RVTM becomes invaluable. Locating that requirement enables determining if
one or more driving or responding requirement(s) also must be revised. Further, need for
evaluation of effect upon implementation necessary to reduce the assessed risk level for
an FMEA fault or Hazard Analysis item is plainly indicated. The Requirements Management
and attention to Risk are maintained, as is auditable proof of compliance with the QSR
provisions for design controls.
The definition for Design History File in QSR 820.30 is “a compilation of records
which describes the design history of a finished device.” This subsection of QSR
provisions for design controls states that “The DHF shall contain or reference the
records necessary to demonstrate that the design was developed in accordance with the
approved design plan and the requirements of this part.”
Because “this part” means the entire QSR, work requested of and decisions
made (by virtually anyone) that impact development and production of a medical device
throughout the project are pertinent for such capture and retention in the DHF. This can
affect any employee, as well as members of a project team and management representatives.
Regardless, this provision highlights the value of clear minutes of meetings, especially
regarding decisions and action items in wording that can be understood by those persons
not in attendance or not extremely familiar with the topics.
Registered laboratory notebooks are basically an extension of the DHF. FDA Design Control
Guidance (March 1997) states, “Design and development contracts should explicitly
specify the manufacturer’s right to design information and establish standards for form
and content of the design documentation.”
With pervasive use of email for company communications, maximizing automatic capture of
project decisions and action items is enabled by establishing one company network email
DHF alias with controlled team member access for each development project and instruction
in the appropriate use by persons accomplishing any work on that project. The traditional
Memo to File is simplified in its execution and vastly improved for project-wide team members
notification.
When a company-wide electronic document management system exists, each project document can be
put through a formal revision (check, review, and release) procedure and the latest version
made available to all with access priveleges. Each project/product DHF then can be a spreadsheet
with hyperlinked list of files for the documents produced during each phase of the development
project. Listing the project produced risk analysis related documentation (including the formal
requirements verification procedures and reports that together confirm implementation of hazard
risk level abatement actions) constitutes much of the ISO 14971 required Risk Management File.
(The missing part is the QA/RA maintained file for the post-production device records as well
as hyperlinked list pointers to the project DHF spreadsheet files.)
The IPPT related toolset providing the greatest increase in effectiveness and efficiency
of device development project teams is comprehensive, integrated document templates that
standardize their content and interrelationships. The earlier named project documents may
be built from a document template base. Because the document templates are more than
predefined outline formats of the named document types, authors are assisted in the rapid
creation of new documents that are automatically compliant with Design Controls provisions
of the QSR:
The Project Management Plan template provides detailed instructions for tailoring the
project work to a reduced scope and scale as well as for providing the worst case of
full-scale project plan content. A multi-use document template related to Requirements
Management (Requirements Specifications) contains the detailed instructions, in early
(sub)sections, which guide providing project information at an appropriate breadth and
depth for the PRD and HRS/SRS (with inclusion of the HDD/SDD implementation/design
‘requirements’ when desired). The instructions show the formal specification
language sentence structure along with requirements writing rules. Templates for
ancillary documents also instruct providing the records necessary for fulfillment of
internal, customer, and regulatory objectives beyond required QSR compliance, such as
showing adherence to specified documentation standards. Thus, even initial draft versions
of the work products provide auditable Design Controls compliance support for the project.
Predefined content descriptions help ensure that everything will be in its expected
location, so project team members can learn quickly where information of interest should
be placed. This standardization is especially helpful when upgrading poorly documented
legacy systems that require extensive reverse engineering and capture of widely
distributed and untraced requirements information.
Assisting Quality Assurance, detailed guidance in document templates describing what
information belongs therein enables all reviewers to evaluate likely adequacy of provided
content — even when it is outside their domains of expertise.
The integrated set of document templates relatively automate the 510(k) submittal package
preparation and greatly helps estimating how much time will be required for development
and review of each project document for project planning. Because documents preparation
from instructions will be much closer to right the first time, the design information is
available sooner and (when based on experience with developing similar documents) fewer
of the project schedule estimates will be greatly exceeded.
Traditional status tracking, when using an earned value method for project management,
is to assign a percent complete value for association with the hours expended relative to
the hours bid for the task. For documents, an arbitrary percent complete is assigned to
developing each of the initial outline format, the first draft completion proportion, the
first submittal for general team review, and to the final release review. Estimates of
percent complete for each document development task are improved with templates guidance
for content. Alone, the stated benefits of document templates argue well for their
adaptation and adoption wherever they can be applied.
But what is percent complete status of an overall project, with respect to Requirements
Management (or end to end development phases) as represented by documents development? A
previously unmentioned benefit of a spreadsheet based RVTM is accurate percent complete status
metrics that can be based on actual task accomplishments for each requirement in the documents.
Commercial requirements management tools import requirements from specification documents into
a database program and assign a project unique identifier (PUI) to each requirement. Attachment
to the specifications is maintained by some of the tools, such that revision to requirements
may be made in database program or the specification. Requirements in one document are assigned
PUI to PUI linkages to requirements in other documents to establish source driver and responder
relationships. For example, information necessary to output an RVTM can be imported or
installed in the requirements management tool database. The steps are: Prepare appropriate
documents for their importing, using rules that apply specific level(s) of paragraph header
hierarchy to be part of the PUI, assign needed attribute/types, and assign the PUI code for
each document (not document type).
A major feature of requirements management tools is that revision to a requirement produces
automatic notification of which other requirement(s) possibly are affected (based on their PUIs
linking).
Support for custom reports, such as an RVTM, is provided by most requirements management tools.
The provided support ranges from fairly intuitive format layout and selection of sorting and
inclusion/exclusion rules for populating the report to the next level up from pure programming
of another utility to access the database.
This tutorial is presented by:
E-mail:
Tutorial Author: jonesjh@optants.com
Other subjects: consult@optants.com