You are on page 1of 17

Cookies and privacy

This website uses Cookies. By continuing to use our site, you consent to the use of

cookies.

AcceptPrivacy centre

 HOME
 DOWNLOADS
 ISO TEMPLATES
 GUIDANCE
 CONTACT

Management system guidance


8.3 Design and development of products and
services
ISO Navigator Pro™ is a free tool that provides practical, expert guidance for

businesses wishing to interpret and better implement the requirements of ISO

9001:2015, ISO 14001:2015 and ISO 45001:2018.

Our range of templates cover the requirements of ISO 9001:2015, ISO 14001:2015 and ISO

45001:2018, and offer an easy way to implement your next management system.

8.3.3 Design and development inputs


« Previous | Next »

This requirement expands upon the requirements from ISO 9001:2008 Clause 7.3.2 -

Design and Development Inputs 7.3.1. You should seek and record evidence that your

organization has documented and retained information concerning the need for internal

and external resources and the potential consequences of design or development

failure.
Define which design and development inputs are required to carry out the design and

development process. The inputs should be determined according to the design and

development activities. For example, which employees are required or what information

is required for every step of the development process. When determining design input

requirements, ensure the retention of documented information such as:

1. Statutory and regulatory requirements e.g. legislation, regulation, directives;


2. Standards or codes of practice e.g. policies, standards, specifications, rules and
aids, protocols, guidance, industry codes
3. Functional and performance requirements informed by customer requirements,
operational and performance charateristics, usability, reliability, availability,
maintainability, and safety (e.g. Human factors and RAMS);
4. Knowledge exchange from other, similar proven designs, lessons-learned,
performance data, in-service data, customer feedback, external feeback, best
practice, benchmarking;
5. Design assumptions and associated risks;
6. Methods of validation and verification;
7. Adequacy of inputs e.g. clear, complete, unambiguous, and authorized;
8. Conflicting inputs are resolved by communicating with interested parties/contract
amendments.

The auditor will need to review evidence that the inputs have been addressed based on

the nature of the product being produced, that they have been reviewed for adequacy

and that records are maintained of the activity. An organization may include design

personnel in the contract review stage; these records may suffice the review of design

input requirement.

Conceptual Design Statement (CDS)


The Conceptual Design Statement (CDS) includes a design statement that declares the

inputs to be used in the design and the proposed design solution. A design statement

illustrates the principles concepts and input data relevant to the design and allows

relevant stakeholders to understand the thinking behind any chosen design solution.

The Design Team will normally produce a Conceptual Design Statement that states the

standards and requirements against which the design is to be developed, the processes

to be applied and the level of independent checking to be carried out (if any) that is
proportionate to the level of risk. The design activities are then carried out by the

Design Team using the CDS as the basis.

Design and development inputs are documented and controlled. Design and

development inputs can be in any form, including data sheets, customer drawings and

specifications, photographs, samples, references to standards, etc.

Design standards baseline


All designs are based on a list of approved design standards, referred to as the

Standards Baseline. This list is owned and managed by the Engineering Manager. The

Standards Baseline is made up of a combination of National and International

Standards, National Engineering Specifications, and Approved Codes of Practice.

The Standards Baseline should be reviewed monthly and any changes are controlled by

the Engineering Manager. At the commencement of any given design package, the

Design Team is required to specify the Standards Baseline that will be used in the

design. 

The Engineering Manager should be responsible for checking that the correct design

standards have been specified and for verifying that the design output complies with

these standards and design requirements.

Due to the continuous review and updating of standards, the baseline between different

design instructions may vary so a strict configuration control is maintained and only

agreed changes are used in the assurance process. Once a design package has been

instructed, the baseline for that element of work becomes fixed and will not reflect any

subsequent changes in standards.

Design assumptions
Assumptions will normally be statements to fill uncertainties in available information.

They are generated by the Design Team in order to allow designs to continue in the
early stages. The anticipation is that assumptions are temporary and are closed out

either by obtaining data or updating documents to confirm or change the assumption.

Assumptions have the potential to be incorrect, and are therefore a source of risk, that

require management. Any associated risk is identified and raised through the Risk

Register. The assumption management activity is coordinated by Design Manager, with

input from the Design Team.

Assumptions regarding domain knowledge include facts about the application of the end

product or service that allow requirements to be developed in a particular context. The

assumptions are normally traceable to gaps or inconsistencies in the design inputs e.g.

incomplete or conflicting functional requirements, inconsistencies between the

applicable Standards, unclear scope of work, or demarcation issues.

The Responsible Body; which might be another company, organisation, person, or team

against which an assumption has been made or who are responsible for providing a

feature or undertaking an action to resolve an assumption agreed by them. Qualifying

criteria for design assumptions are based on the following:

 Assumptions on scope and allocation;


 Assumption regarding gap or conflict in the stated capabilities, systems or
operational aspects;
 Conflict between standards;
 Assumptions due to missing design data;
 Assumptions regarding a design decision;
 Assumptions relating to interface issues.

Assumptions must not be raised on programme and cost related matters. The

requirements or the design statement will be verifiable against the raised assumption or

the origin of the assumption. Assumptions are accepted by the Resolving Body; they

may be turned into design requirements or project risks. The process for managing

design assumptions is summarised as follows:

 Assumptions are managed using an Assumptions Register;


 The Design Team propose an assumption to fill an uncertainty;
 The Engineering Manager reviews the suitability of the assumption against the
criteria;
 Once agreed with the Resolving Body, the Design Team updates the assumption
register;
 Action owner closes out assumption by agreed date, this could be done either by
establishing additional data or confirming a decision;
 The Engineering Manager monitors that action owners are closing out
assumptions and takes action to expedite if necessary;
 Any assumption remaining at the end of the design phase must be clearly
recorded in the Assumptions Register and transferred to the Risk Register.

Assumptions are considered closed when they are successfully resolved i.e. accepted by

the Resolving Body and the Resolving Body has taken an action that is documented in a

resolving document. This resolving document must be properly reviewed, verified and

issued before the closure of an assumption is accepted.

The respective Gate Review Authority are the final authority to accept or reject the

closure of an assumption. The confirmation of closure is noted in the Assumptions

Register and a reference to the resolving document with the relevant clause is provided

for verification purposes.

Design requirements
The design management process is geared towards meeting customer requirements,

while providing a product cost, which enables organizations to have a satisfactory

return on investment. The physical and performance requirements of a product used as

a basis for product design and development; includes user requirements, regulatory

requirements, and system requirements.

The customer and user requirements are translated into design requirements and may

either be hardware or software (according to intended use) and included in the design

specifications and other design documents.

The requirements are reviewed for adequacy by a cross functional, multidisciplinary

team involving Design, Engineering, Sales, Manufacturing, Procurement, Sales and

Quality to ensure the requirements are complete, unambiguous and not in conflict with
each other. The Design Team notifies Engineering Manager if the requirements are

ambiguous or conflict with each other.

The Design Team produces evidence of the capture of and compliance with the

requirements. This evidence is presented in the Requirements Register. The Design

Team should provide compliance matrices and verification reports to demonstrate how

the designs meet the requirements, supported by the compliance rationale, evidence,

models and analysis as required, whilst ensuring that:

 All requirements are traceable to the identifier, author, rationale, source,


requirement owner, allocation and stakeholder;
 All requirements have been validated and approved by identified personnel;
 All requirements set been reviewed and agreed with the customer;
 Are requirements are recorded into the project applicable database;
 All allocated requirements are understood and accepted by all the recipients.

In order to progress their close-out and acceptance, compliance statements are

prepared and allocated to each requirement, commensurate to the design stage e.g.

Gate 1, 2, or 3. Links and references to supporting drawings and documents are

provided as the design progresses.

Customer supplied user requirements are transferred to the Requirements Review

Checklist and additional requirements are addressed with the customer. The Marketing

Manager and the Sales Manager should identify and document the markets’ need for

new solutions in a requirement statement which serves as the input for design and

development work. The requirement statement includes the following:

 What is required (features/functions, etc.);


 Why it is needed (customer demand);
 When it is needed;
 Assumptions needed to progress the design;
 Risk and opportunity, and hazard analysis;
 Requirements for performance, reliability, safety, statutory and regulatory, etc.;
 Pricing targets and design project milestones.

When a product is designed or modified to meet specific customer requirements, the

Engineering Manager receives from Marketing Manager and the Sales Manager an

outline design order with customer requirements and specifications. The Design Team
translates the needs and expectations from the requirements and design statements to

technical specifications for materials, products, services and processes.

Design interfaces
Where necessary, the Design Team should form working groups to develop interface

control documents and record agreements for interfacing stakeholders in order to elicit

their requirements and to provide feedback that may be important to your designs.

Their emphasis should be on the identification and co-ordination of the important

characteristics, parameters and configurations that need to be developed to deliver

effective interface designs. The level of detail documented must be proportionate with

the level of detail being developed in the design outputs.

1. Identify, specify and manage interfaces;


2. Assist in the resolution of interface issues relating to commercial or contractual
issues;
3. Assist in the production of and agree interface documents with interfacing
parties;
4. Ensure that the process of interface management is fully supported during the
development of detailed designs;
5. Review and monitor the development of interface identification.
Design documentation
The established document numbering system must be used by the Design Team. All

documents produced to support the design and the design assurance process should be

listed in the Master Design Document List, which is a list of all plans, processes and

procedures to be used to control the safety, quality and efficiency of the design output.

All design documents must follow the ‘Prepare’, ‘Check’, and ‘Approve’ process,

evidenced by the signatures of competent individuals. All design documents should be

signed off in the three categories:


1. Prepared – by a competent person who produces the design document,
checking their own work complies with codes and standards governing that work.
2. Checked – by a competent person able to undertake a formal detailed
check/review of design methods, codes and standards used, deliverables,
calculations, drawings and specifications produced by another member of the
Design Team. This role is undertaken by a competent person of the same
discipline, not the Preparer, but can be a member of the same team.
3. Approved – by a competent person of the same discipline, but not a member of
the same team, able to undertake a review of the design output after detail
checking has taken place to validate that the design is consistent with
requirements, is fully integrated and satisfies interface requirements.

Design and development reference materials (e.g. standards, catalogues, etc.) should

be available and maintained by the Engineering Manager. Only current issues and

revisions of reference material must be used. All documents produced to support the

design and the design assurance process must be listed in the Master Design

Documents List.

« Previous | Next »
More information on PDCA
Planning
ISO ISO ISO
9001:2015 14001:2015 45001:2018

4.1 4.1 4.1


Organization Organization Organization
al Context al Context al Context

4.2 Relevant 4.2 Relevant 4.2 Relevant


Interested Interested Interested
Parties Parties Parties

4.3 4.3 4.3


Management Management Management
System Scope System Scope System Scope

4.4 OH&S
4.4 QMS 4.4 EMS
Management
Processes Processes
System
 

ISO ISO ISO


9001:2015 14001:2015 45001:2018

5.1 5.1 5.1


Leadership & Leadership & Leadership &
Commitment Commitment Commitment

5.2 Quality 5.2 5.2 OH&S


Policy Environment Policy
al Policy

5.3 Roles, 5.3 Roles, 5.3 Roles,


Responsibiliti Responsibiliti Responsibiliti
es/Authorities es/Authorities es/Authorities

5.4
Consultation
   
&
Participation
 

ISO ISO ISO


9001:2015 14001:2015 45001:2018

6.1.1
Address 6.1.1 Address 6.1.1 Address
Risks & Risks & Risks &
Opportunitie Opportunities Opportunities
s

6.1.2
6.2.1 Quality 6.1.2 Hazard
Environmenta
Objectives Identifcation
l Aspects

6.2.2 6.1.3 Legal


6.1.3
Planning to & Other
Compliance
Achieve Requirement
Obligations
Objectives s

6.1.4
6.3 Planning 6.1.4 Planning
Planning
for Change Action
Action

6.2.1
6.2.1 OH&S
  Environmenta
Objectives
l Objectives

6.2.2
6.2.2 Planning
Planning to
  to Achieve
Achieve
Objectives
Objectives
 
Doing
ISO ISO ISO
9001:2015 14001:2015 45001:2018
7.1.1
Resources - 7.1 Resources 7.1 Resources
General

7.2 7.2
7.1.2 People
Competence Competence

7.1.3 7.3 7.3


Infrastructure Awareness Awareness

7.1.4 7.4.1 7.4.1


Operational Communcati Communcati
Environment on - General on - General

7.1.5 7.4.2 Internal 7.4.2 Internal


Monitoring & Communcati Communcati
Measuring on on

7.1.6 7.4.3 External 7.4.3 External


Organization Communcati Communcati
al Knowledge on on

7.5 7.5
7.2
Documented Documented
Competence
Information Information

7.3
   
Awareness

7.4
Communcati    
on

7.5
Documented    
Information

ISO ISO
ISO 9001:2015
14001:2015 45001:2018

8.1 Operational 8.1 8.1.1


Planning & Operational General
Control Planning &
Control

8.2.1 Customer 8.2 8.1.2


Communicatio Emergency Eliminating
n Preparedness Hazards

8.2.2 8.1.3
Determining   Management
Requirements of Change

8.2.3
8.1.4
Reviewing  
Outsourcing
Requirements

8.2
8.2.4 Changes
Emergency
in  
Preparednes
Requirements
s

8.3.1 Design
Development -    
General

8.3.2 Design
Development -    
Planning

8.3.3 Design
Development -    
Inputs

8.3.4 Design
Development -    
Controls

8.3.5 Design
Development -    
Outputs

8.3.6 Design
Development -    
Changes

8.4.1 External
Processes -    
General
8.4.2
Purchasing    
Controls

8.4.3
Purchasing    
Information

8.5.1
Production &
   
Service
Provision

8.5.2
Identification &    
Traceability

8.5.3 3rd Party


   
Property

8.5.4
   
Preservation

8.5.5 Post-
delivery    
Activities

8.5.6 Control of
   
Changes

8.6 Release of
Products &    
Services

8.7
Nonconforming    
Outputs
 
Checking
ISO ISO ISO
9001:2015 14001:2015 45001:2018

9.1.1 9.1.1 9.1.1


Performance Performance Performance
Evaluation Evaluation Evaluation
9.1.2 9.1.2 9.1.2
Customer Evaluation of Evaluation of
Satisfaction Compliance Compliance

9.1.3
9.2 Internal 9.2 Internal
Analysis &
Audit Audit
Evaluation

9.3 9.3
9.2 Internal
Management Management
Audit
Review Review

9.3
Management    
Review
 
Acting
ISO ISO ISO
9001:2015 14001:2015 45001:2018

10.1 10.1 10.1


Improvement Improvement Improvement
- General - General - General

10.2 10.2 10.2 Incident,


Nonconformi Nonconformi Nonconformi
ty & ty & ty &
Corrective Corrective Corrective
Action Action Action

10.3 10.3 10.3


Continual Continual Continual
Improvement Improvement Improvement
 

Free internal audit checklists


Check out our free internal audit checklists. The audit checklist template is just one of

the many tools which are available from the auditor’s toolbox that help ensure your

audits address the necessary requirements.


Client list
Over 8,000 companies and globally recognized brands have relied on our templates to

provide a path to improve, collaborate, and to enhance their operations to achieve

certification, please see our client list for more information.

 Navigate
o HOME
o DOWNLOADS
o ISO TEMPLATES
o GUIDANCE
o CONTACT

 ISO Templates
o QUALITY MANUALS
o ENVIRONMENTAL MANUALS
o ISO 9001 AUDIT CHECKLISTS
o HEALTH & SAFETY MANUALS
o PROCEDURES & FORMS
o OTHER AUDIT CHECKLISTS
o INTEGRATED EQMS
o INTEGRATED EHQMS

 ISO 9001 Guidance


o 4.1 UNDERSTANDING CONTEXT
o 4.2 INTERESTED PARTIES
o 4.3 DETERMINING SCOPE
o 4.4 MANAGEMENT SYSTEM
o 5.1 LEADERSHIP AND COMMITMENT
o 5.2 QUALITY POLICY
o 5.3 ROLES, RESPONSIBILITY AND AUTHORITY
o 6.1.1 ADDRESS RISK AND OPPORTUNITY
o 6.2.1 QUALITY OBJECTIVES
o 6.2.2 PLANNING TO ACHIEVE OBJECTIVES
o 6.3 PLANNING FOR CHANGE
o 7.1.1 RESOURCES - GENERAL
o 7.1.2 PEOPLE
o 7.1.3 INFRASTRUCTURE
o 7.1.4 PROCESS ENVIRONMENT
o 7.1.5 MONITORING AND MEASURING RESOURCES
o 7.1.6 ORGANIZATIONAL KNOWLEDGE
o 7.2 COMPETENCE
o 7.3 AWARENESS
o 7.4 COMMUNICATION
o 7.5 DOCUMENTED INFORMATION
o 8.1 OPERATIONAL PLANNING AND CONTROL
o 8.2.1 CUSTOMER COMMUNICATION
o 8.2.2 DETERMINING REQUIREMENTS FOR PRODUCTS & SERVICES
o 8.2.3 REVIEW OF REQUIREMENTS FOR PRODUCTS & SERVICES
o 8.2.4 CHANGES TO REQUIREMENTS FOR PRODUCTS & SERVICES
o 8.3.1 DESIGN & DEVELOPMENT GENERAL
o 8.3.2 DESIGN & DEVELOPMENT PLANNING
o 8.3.3 DESIGN & DEVELOPMENT INPUTS
o 8.3.4 DESIGN & DEVELOPMENT CONTROLS
o 8.3.5 DESIGN & DEVELOPMENT OUTPUTS
o 8.3.6 DESIGN & DEVELOPMENT CHANGES
o 8.4.1 EXTERNALLY PROVIDED PRODUCTS AND SERVICES
o 8.4.2 TYPE & EXTENT OF CONTROL
o 8.4.3 INFORMATION FOR EXTERNAL PROVIDERS
o 8.5.1 CONTROL OF PRODUCT & SERVICE PROVISION
o 8.5.2 IDENTIFICATION & TRACEABILITY
o 8.5.3 CUSTOMER PROPERTY
o 8.5.4 PRESERVATION
o 8.5.5 POST-DELIVERY ACTIVITIES
o 8.5.6 CONTROL OF CHANGES
o 8.6 RELEASE OF PRODUCTS AND SERVICES
o 8.7 NONCONFORMING OUTPUTS
o 9.1.1 PERFORMANCE EVALUATION
o 9.1.2 CUSTOMER SATISFACTION
o 9.1.3 ANALYSIS & EVALUATION
o 9.2 INTERNAL AUDIT
o 9.3 MANAGEMENT REVIEW
o 10.1 IMPROVEMENT - GENERAL
o 10.2 NON-CONFORMITY AND CORRECTIVE ACTION
o 10.3 CONTINUAL IMPROVEMENT

 Quality principles
o CUSTOMER FOCUS
o LEADERSHIP
o ENGAGEMENT OF PEOPLE
o PROCESS APPROACH
o IMPROVEMENT
o EVIDENCE‐BASED DECISION MAKING
o RELATIONSHIP MANAGEMENT

 About
o We've grown from a project started in 2002 by a group of Auditors and

Consultants to freely share our knowledge and experience with the ISO 9001

community. We offer many useful documents that you can download and use for free.

 Search
o
Search
     Site   Web

 Useful links
o SPC - This site is run by a team of volunteers with over 24 years experience working
in manufacturing, quality and product development.
o ISO 27001 Security - The ISO27k Toolkit is a collection of generic ISMS-related
materials contributed by members of the ISO27k Forum.
o Elsmar Cove Quality Forum - An excellent discussion forum and information
archive focusing on quality assurance, standards and management systems.
 
 Contact us
 UK local rate: 0333 222 8958
 International: +44 (0) 333 222 8958
 Email: support@iso9001help.co.uk
 Company No 09921115
 UK
 Guidance
 Free templates
 ISO 9001:2015 guidance
 ISO 9001:2008 guidance
 Quality management principles
 Introduction to SPC

 About us
 Terms and conditions
 Privacy policy
 Client list
 Site map
 Links

© Vanguard Management Systems Ltd 2019 | Company Number 09921115 | Design by Free CSS

Templates by ZyPOP

You might also like