[Company Name]

[Company Group, Division, Location]

Document Title: Development of Design Input Requirements

Document Number: [Document Number]
Document Filename: [Document Filename]

CONTROLLED COPY/ MASTER COPY

STAMP HERE

OTHER
STAMP HERE

Revision Revision DCO/ECO Revision

Level Date Number Description of Revision Author
DRAFT DD/MM/Y YY-00000 Draft Author Name
Y
1.00 DD/MM/Y YY-00000 Initial Release Author Name
Y

COMPANY PROPRIETARY AND CONFIDENTIAL

[Company Name] Development of Design Input Requirements
[Company Group, Division, Location] [Document Number]
Rev x.xx DD/MM/YY

Table of Contents

1.0 Purpose..........................................................................................................................................................2

2.0 Scope.............................................................................................................................................................2

3.0 Definitions.....................................................................................................................................................2
3.1 Executive Management Team (EMT)................................................................................................2
3.2 Customer............................................................................................................................................2
3.3 Design Input.......................................................................................................................................2
3.4 Design Output....................................................................................................................................2
3.5 Marketing Requirements Document (MRD).....................................................................................2
3.6 Product...............................................................................................................................................2
3.7 Product Development.........................................................................................................................2
3.8 Product Development Feasibility Study (PDFS)...............................................................................2
3.9 Product Manager................................................................................................................................3
3.10 Quality................................................................................................................................................3
3.11 Product Development Team (PDT)....................................................................................................3
3.12 Validation...........................................................................................................................................3
3.13 Verification.........................................................................................................................................3

4.0 Responsibilities.............................................................................................................................................3
4.1 Executive Management Team (EMT)................................................................................................3
4.2 Product Manager................................................................................................................................3
4.3 Regulatory Affairs/Quality Systems Director....................................................................................3
4.4 Product Development Team (PDT)....................................................................................................3

5.0 References and Applicable Documents........................................................................................................4

6.0 Procedure......................................................................................................................................................4
6.1 Determination of Input Requirements...............................................................................................4
6.2 Sources of Information for Input Requirements................................................................................4
6.2.1 Customer Requirements......................................................................................................4
6.2.2 Intended Use Requirements.................................................................................................5
6.2.3 System and Product Development Requirements...............................................................5
6.3 Development of Input Requirements.................................................................................................5
6.4 Categories of Input Requirements.....................................................................................................6
6.4.1 Functional Requirements.....................................................................................................6
6.4.2 Performance Requirements..................................................................................................6
6.4.3 Interface Requirements........................................................................................................6
6.4.4 System and Product Development Requirements...............................................................6
6.5 Assessment of Input Requirements....................................................................................................6
6.6 Incomplete, Ambiguous, or Conflicting Input Requirements...........................................................7
6.7 Development of Input Requirements.................................................................................................7
6.8 Development of Input Requirements.................................................................................................7
6.9 Change Control..................................................................................................................................7
6.10 Conversion of Input Requirements....................................................................................................7

[Document Filename] COMPANY PROPRIETARY AND CONFIDENTIAL Page 1 of 7

[Company Name] Development of Design Input Requirements
[Company Group, Division, Location] [Document Number]
Rev x.xx DD/MM/YY

1.0 Purpose
This procedure defines the guidelines for establishing and documenting the design input requirements
for the development of a product design.

2.0 Scope
This procedure applies to all product development programs funded and managed by [Company Name].

3.0 Definitions

3.1 Executive Management Team (EMT)

A management team that plans, directs, and manages company activities, including
manufacturing operations and product development. It has the authority and responsibility to
carry out the company’s strategic objectives. The Executive Management Team has the authority
to establish or make changes to the quality policy and quality system.

3.2 Customer
Anyone purchasing, using, operating, or interfacing with a product in any manner.

3.3 Design Input

The physical and performance requirements of a product used as a basis for product design and
development.

3.4 Design Output

The results of a design effort at each design 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 product, its packaging and labeling, and the Device Master Record.

3.5 Marketing Requirements Document (MRD)

The Marketing Requirements Document specifies design input requirements used as the basis for
complete product design. It defines what the design is intended to do and details requirements
for functionality, performance, interfacing, etc. as well as system and program requirements and
goals. Approval of the MRD by the Executive Management Team marks the end of the research
phases (Concept and Feasibility) and the beginning of a development program.

3.6 Product
Unless otherwise specified, the word “product” in this procedure is used in the more global sense
to refer to components, materials, structures, machines, devices, systems, processes, software, or
services.

3.7 Product Development

The systematic development process for optimizing a product’s time to market, cost,
performance, quality, customer satisfaction, and risk management. A product development
simultaneously integrates all product knowledge and expertise from concept, through
manufacturing and customer satisfaction, to the end of the product’s life.

3.8 Product Development Feasibility Study (PDFS)

The Product Development Feasibility Study examines all applicable facets of a proposed
development program to assist in management’s decision to expend time and resources in
undertaking development of the product. This study is the first step in the Feasibility Phase of
the Product Development Cycle and it evolves into the Product Development Plan during the
Planning Phase.

3.9 Product Manager

The Product Manager directs the activities of the Product Development Team and the
development program in accordance with the process detailed in this procedure and bears overall

[Document Filename] COMPANY PROPRIETARY AND CONFIDENTIAL Page 2 of 7

[Company Name] Development of Design Input Requirements
[Company Group, Division, Location] [Document Number]
Rev x.xx DD/MM/YY

responsibility for management of the development program. The Product Manager is the leader
of the Product Development Team and acts as liaison to the Executive Management Team. The
Executive Management Team assigns a Product Manager to a particular product development
program.

3.10 Quality
The totality of features and characteristics that bears on the ability of a product to satisfy fitness-
for-use, including safety and performance.

3.11 Product Development Team (PDT)

A cross-functional team that plans, directs, and manages a development program. It has the
authority and responsibility to carry out the development objectives of the Executive Management
Team and to advise, coordinate, and integrate the activities of the Task Teams. The Executive
Management Team is responsible for forming the Product Development Team.

3.12 Validation
Confirmation by examination and provision of objective evidence that the particular requirements
for a specific intended use can be consistently fulfilled.

3.13 Verification
Confirmation by examination and provision of objective evidence that specified requirements has
been fulfilled.

4.0 Responsibilities
This procedure is intended as a guide. Depending on the complexity of the product and the extent of
the design requirements, the Product Manager and the PDT may not exactly follow this procedure, but
must still apply the essential elements of effective and systematic development of design input
requirements.

4.1 Executive Management Team (EMT)

The Executive Management Team has comprehensive responsibility and authority to plan, direct,
and manage the business and strategic objectives of product development programs. The EMT
approves the Marketing Requirements Document to initiate a product development program.

4.2 Product Manager

The Product Manager bears overall responsibility for successful management of the development
program and is responsible for leading and facilitating the efforts of the Product Development
Team. As the leader of the Product Development Team, the Product Manager is responsible for
coordinating and integrating their activities and acting as liaison with the Executive
Management Team.

4.3 Regulatory Affairs/Quality Systems Director

The Director of Regulatory Affairs/Quality Systems is responsible for assuring the quality of the
product design process, the Manufacturing Process, the product, and all phases of the Product
Development Cycle.

4.4 Product Development Team (PDT)

The Product Development Team has collective responsibility and authority to plan, direct, and
manage the activities and deliverables of a development program and to carry out the objectives
of the Executive Management Team. It is responsible for development of design input and
preparation of the Marketing Requirements Document. As the design evolves, the PDT reviews
and updates the MRD as required.

5.0 References and Applicable Documents

“Design Control Guidance for Medical Device Manufacturers”, FDA Center for Devices and
Radiological Health, March 11, 1997

[Document Filename] COMPANY PROPRIETARY AND CONFIDENTIAL Page 3 of 7

[Company Name] Development of Design Input Requirements
[Company Group, Division, Location] [Document Number]
Rev x.xx DD/MM/YY

The FDA and Worldwide Quality System Requirements Guidebook for Medical Devices, Kimberly
Trautman, ASQ Quality Press
The Product Development Cycle

6.0 Procedure

6.1 Determination of Input Requirements

Development of design input requirements is the starting point for product design and results in a
Marketing Requirements Document that initiates the design control process. Customer
requirements mainly govern design input. However, the Product Development Team must also
consider other issues pertinent to product design such as regulatory requirements, new
technologies requiring development and analysis, or any other factor necessary to describe the
product throughout its life cycle. To obtain a truly comprehensive set of design requirements, the
customer and those developing the product both provide input. Ultimately, the Product
Development Team translates customer needs and development needs into a set of requirements
that can be verified and validated prior to product implementation.

6.2 Sources of Information for Input Requirements

In the Concept and Feasibility Phases of the Product Development Cycle, Research and/or
Engineering perform experiments and gather information to prepare the Product Development
Feasibility Study. This is a concept document containing a conceptual description of the product.
It is one source of design input information. The Product Development Team, with additional
sources of information, elaborates and expands this description into a complete set of design
input requirements written to an engineering level of detail. In many cases, a particular product
development program does not require a Product Development Feasibility Study. The
development may be an enhancement or improvement of an existing product. In either case, the
Product Development Team considers many sources and types of information to develop a
comprehensive and precise set of design input requirements.

Market research is the primary mechanism for acquiring knowledge of customer needs and
requirements. Market research gathers detailed information regarding where and how the
product will be used, who will use it, the use environment, safety concerns, etc. The focus of
such information gathering is external to the company.

Another source of information is the results of contract reviews. Before and during the Design
input Review, the PDT will communicate directly with the manager responsible for contract
review to incorporate any changes or additions to the design input requirements resulting from
contract review activities. If changes to the design input requirements occur after the Design
Input Review, the contract review manager is responsible for notifying and coordinating the
changes with the PDT.

Other information originates from a variety of sources such as documentation of past projects and
studies, existing products, customer complaints and service records, competing products, etc. It
may be necessary to acquire such information first had such as engineers conducting
investigations at selected product use sites to characterize the actual use environment.

The following are examples of the types of information the PDT should acquire:

6.2.1 Customer Requirements

 Diagnostic requirements
 Therapeutic requirements
 Clinical effectiveness requirements
 User expectations
 Labeling requirements including operator guidance
 Human factors
 Safety

[Document Filename] COMPANY PROPRIETARY AND CONFIDENTIAL Page 4 of 7

[Company Name] Development of Design Input Requirements
[Company Group, Division, Location] [Document Number]
Rev x.xx DD/MM/YY

 Training

6.2.2 Intended Use Requirements

 Performance
 Functional
 Interface
 Environmental
 Electro-Magnetic Compliance (EMC)
 Product/System compatibility
 Reliability
 Maintainability
 Serviceability
 Storage and shelf life
 Materials
 Regulatory requirements
 Human factors
 Safety
 Sterilization
 Standards

6.2.3 System and Product Development Requirements

 Cost
 Technological viability
 Manufacturability
 Export requirements
 Packaging and shipping
 Other business considerations
 Delivery and installation
 Statutory requirements
 Contract review results

6.3 Development of Input Requirements

The Product Development Team is responsible for translating the information on customer needs
and development needs into a set of requirements that can be verified and validated prior to
implementation of the product. This is a broad based, cross-functional activity. Though the
Product Development Team is cross functional in membership, the Product Manager may need to
secure additional representatives from other functional areas.

Write the requirements to an engineering level of detail. Use quantitative terms that can be both
verified and validated. Give a measurement of tolerance when applicable. Carefully avoid
specifying design solutions and instead, concentrate on specifying what the design is intended to
do. When it is impractical to establish a functional or performance characteristic, state the
requirement with a to-be-determined (TBD) numerical value or a range of possible values.

Group the design input into requirement classifications and categories. These classifications are
beneficial when later preparing the Product Development Plan.

6.4 Categories of Input Requirements

Design input requirements must be comprehensive. Product complexity and the risk associated
with its use dictate the amount of detail. Design input requirements basically fall into four (4)
categories.

6.4.1 Functional Requirements

These specify what the product does, focusing on its operational capabilities and
the processing of inputs and resultant outputs.

[Document Filename] COMPANY PROPRIETARY AND CONFIDENTIAL Page 5 of 7

[Company Name] Development of Design Input Requirements
[Company Group, Division, Location] [Document Number]
Rev x.xx DD/MM/YY

6.4.2 Performance Requirements

These specify how much or how well the product must perform, addressing such issues
as speed, strength, response times, accuracy, limits of operation, etc. This includes a
quantitative characterization of the use environment, including temperature, humidity,
shock, vibrati9on, electromagnetic compatibil9ity, etc. Product reliability and safety
requirements also fit in this category.

6.4.3 Interface Requirements

These specify characteristics of the product, which are critical to compatibility with
external systems. More specifically, these are characteristics mandat4ed by external
systems and outside the control of the developers. One interface to always address is the
user and/or customer interface.

6.4.4 System and Product Development Requirements

These specify goals and requirements of the product development and other
development issues that are not necessarily just a characteristic of the product itself.
Typically, these are a consequence of development, manufacturing, and support of the
product.

6.5 Assessment of Input Requirements

After completion of the design input requirements, the Product Manager conducts a design input
Review. The purpose of the review is to ensure the product design requirements are adequate,
appropriate, and address the intended use of the product, including the needs of the user and
customer. The Product manager may have to conduct multiple reviews before the reviewers
satisfactorily resolve every issue.

Any assessment of design input requirements is essentially a matter of judgment. However, the
reviews should employ a number of criteria.

 Precisely state the requirements in unambiguous terms. Each requirement should be

verifiable by an objective method of analysis, inspection, or testing.
 Express quantitative limits with a measurement of tolerance. Provide a basis for determining
accuracy requirements and suitability for intended use.
 Make the set of design input requirements for a product self-consistent. Resolve conflicts
between requirements or with referenced industry standards.
 Properly characterize the product’s use environment. Fully specify the environmental
conditions representative of the intended use.
 When reference, review industry standards for completeness and relevance.
 State each requirement’s means of measurement and validation, including the conformance
assessment procedure, methods, and equipment, if necessary.
 Identify incomplete or “to be determined” (TBD) conditions. Specify the cause of the TBD
condition as well as what to do to eliminate the cause.

6.6 Incomplete, Ambiguous, or Conflicting Input Requirements

The PDT and the reviewers must be diligent in finding and resolving incomplete, ambiguous, or
conflicting requirements. If such a problem is known or discovered prior to the EMT’s approval
of the Marketing Requirements Document, the PDT will resolve the issue and the Product
Manager will make the change to the proposed MRD. If discovered after approval, the PDT will
resolve the issue and the Product Manager will make the change and increment the MRD’s
revision level.

6.7 Development of Input Requirements

The Product Development Team documents the product design input requirements in a
Marketing Requirements Document. After preparation, the Product Manager conducts a Design
Input Review to ensure the product design requirements are adequate, appropriate, and address
the intended use of the product, including the needs of the use and customer. Following an audit

[Document Filename] COMPANY PROPRIETARY AND CONFIDENTIAL Page 6 of 7

[Company Name] Development of Design Input Requirements
[Company Group, Division, Location] [Document Number]
Rev x.xx DD/MM/YY

of the review, the EMT approves the MRD if acceptable, marking the end of the research phases
(Concept/Feasibility) and the start of the development program. The MRD is a design history
document maintained in the Design History File.

6.8 Development of Input Requirements

The MRD is continuously updated as the design evolves and more information becomes
available. As development proceeds, the output from earlier design stages forms the basis for
subsequent stages. Therefore, the information available is inherently more extensive and detailed
as design progresses. The Product Manager, teams, and other developers conduct formal and
informal design reviews throughout the development process. When appropriate, the Product
Manager and PDT use information from reviews and other sources to update the design input
requirements in the MRD.

6.9 Change Control

As discussed above, reviews, verification, and other development activities often uncover
discrepancies, errors, or new information that requires changes to the design input requirements.
The Product Development Team must carefully manage the change control process to prevent a
change that corrects one problem but creates another. To minimize such an occurrence, the PDT
ensures that all potential changes are communicated to developers who can determine the full
impact of the change. The Product Manager of a specific development program is responsible for
controlling and documenting changes to the design input requirements in the MRD. The EMT
approves all updates and changes to the MRD.

6.10 Conversion of Input Requirements

The first step in design development (Development Phase) is converting the product design input
requirements of the Marketing Requirements Document into a set of system (upper level)
specifications. These specifications are a design output.

[Document Filename] COMPANY PROPRIETARY AND CONFIDENTIAL Page 7 of 7