Joint Quality Management in the Supply Chain

Product and Production Process Development

Maturity Level Assurance

Automotive VDA Component

Requirements Specification Standard
Structure
Recommendation for the specification of systems, software, modules,
components and individual parts

2nd revised edition, October 2023

Online download document

1
Joint Quality Management in the Supply Chain

Product and Production Process Development

Maturity Level Assurance

Automotive VDA Component

Requirements Specification Standard
Structure
Recommendation for specification of systems, software, modules,
components and individual parts

2nd revised edition, October 2023

Verband der Automobilindustrie e.V. (VDA)

2
Non-binding VDA recommendation
The Association of the German Automotive Industry (VDA) recommends its
members to apply the following VDA Volume for the implementation and
maintenance of quality management systems.

Exclusion of Liability
VDA volumes are recommendations available for general use. Anyone who
implements them is responsible for ensuring that they are used correctly in
each case.
This VDA volume takes into account state-of-the-art technical procedures,
current at the time of issue. Implementation of VDA recommendations re-
lieves no one of responsibility for their own actions. In this respect, every-
one acts at their own risk.
The VDA and those involved in VDA recommendations shall bear no liabil-
ity.
If during the use of VDA recommendations, errors or the possibility of mis-
interpretation are found, it is requested that the VDA be notified immedi-
ately so that any possible faults can be corrected.

Copyright
This publication is protected by copyright. Any use outside of the strict lim-
its of copyright law is not permissible without the consent of the VDA and is
liable to prosecution. This applies in particular to copying, translation, mi-
crofilming and the storing or processing in electronic systems.

Translations
This publication will also be issued in other languages. The current status
must be requested from VDA QMC.

Note on gender
For reasons of readability, the masculine form is used throughout this text.
However, all information applies to both genders.

1
Foreword
Companies and manufacturers in the automotive industry are faced with a
dynamic environment characterized by increasingly complex products, new
technologies, and challenges with regard to product quality as well as con-
formity. Cutting-edge technologies have to be implemented more and more
quickly in the individual projects. In order to allow for successful collabora-
tion when working on new projects, it is necessary to ensure clear and pre-
cise communication regarding the requirements and objectives for the
products to be developed. The present VDA volume is a completely revised
edition and is the result of major revisions and updates in terms of content.
In addition to experiences from the past several years, new aspects such
as agile working methods have been taken into account (among other
things). New requirements regarding electronics, software applications,
product compliance, functional safety, cybersecurity and other aspects
have been incorporated and/or updated according to the current state of
technology. Furthermore, the present volume was aligned with other VDA
volumes and the regulatory requirements set out in ISO 9001 and IATF
16949.

This volume describes a new, standardized structure for a Component Re-

quirements Specification agreed upon between a customer (the recipient of
a scope of supply, irrespective of the position in the supply chain) and their
resource provider (supplier). Scopes of supply and services are the con-
tractually agreed new parts/products (all categories, e.g. hardware, ser-
vices, software, and materials to be processed), including their associated
development and production processes (see VDA Maturity Level Assur-
ance for New Parts). A standardized process for the development of re-
quirement specifications by the OEM and/or supplier is not part of the pre-
sent VDA volume.

The objective of the procedure and structure described in this volume is to

obtain an unambiguous and comprehensive profile of requirements for the
product, and thus also for its production process. This is to be achieved by
systematically considering all requirements in relation to the product.

The structure of the Component Requirements Specification can be applied

along the entire supply chain between the customer and the supplier. In ad-
dition, the structure is modular. In the newly designed module I, the generic
requirements for project implementation as well as the process and organi-
zation originated requirements to be met by the supplier, are described.
These requirements from module I are meant to allow for structured project
work, and to standardize the interfaces for collaboration. The relevant

2
project and product-specific requirements regarding the project to be devel-
oped are described within the new module II.

As part of the product specification, the Component Requirements Specifi-

cation provides important “input” for the further product development pro-
cess. Within the Component Requirements specification, the quality of the
requirements descriptions in relation to a product provides a fundamental
basis for the effective development of safe products and processes. Apply-
ing this VDA volume is meant to encourage those involved to specify defini-
tions, engage in communication, reach agreements and meet the relevant
requirements early on, thus ensuring conformity of the development and
implementation processes as well as conformity of the relevant product
within the scope of the objectives agreed upon.

3
Contents
Foreword 2
Contents 4
List of Illustrations 6
1 Introduction 7
2 Objective and purpose 10
2.1 Significance of the Component Requirements Specification 10
2.2 Objective and purpose of the VDA Component Requirements
Specification standard structure 10
2.2.1 Added value for the customer 11
2.2.2 Added value for suppliers 12
3 General description and definition 13
3.1 General description 13
3.2 Definitions – Component Requirements Specification and
functional specification 13
4 Application 15
4.1 General information 15
4.2 Overview of the modules 15
4.2.1 Module I – Process and organization originated requirements
15
4.2.2 Module II – Project and product-specific requirements 16
5 Formulating precise requirements 18
5.1 Objective and purpose 18
5.2 Quality criteria 18
6 The Component Requirements Specification process in the
supply chain 21
7 Requirements management with IT support 23
8 VDA Component Requirements Specification standard
structure 24
8.1 Module I – Process and organization originated requirements 24
8.1.1 Project management 24
8.1.2 Risk management 26
8.1.3 Environment and sustainability 26
8.1.4 Functional safety 28
8.1.5 Cybersecurity management 28
8.1.6 Software update management 28
8.1.7 Data protection 28
8.1.8 Supply chain management 29
8.1.9 Releases 31
8.1.10 Quality management system 31
8.1.11 Quality assurance 32
8.1.12 Requalification 32
8.1.13 Reporting and documentation 32

4
8.1.14 Spare part and service requirements 32
8.1.15 Configuration and variant management 33
8.1.16 Non-conformity management 33
8.1.17 Change management 33
8.1.18 Data management 33
8.1.19 Test management 33
8.1.20 Standard and carry-over parts 34
8.1.21 Logistics 34
8.1.22 Labeling and traceability of parts, components and data 34
8.1.23 Requirements regarding test and prototype tools and
production 34
8.1.24 Applicable documents 34
8.2 Module II – Project and product-specific requirements 35
8.2.1 Objective and scope of the project 35
8.2.2 Traceability 35
8.2.3 Description of the product and function 36
8.2.4 Product-specific requirements 36
8.2.5 Technical and functional requirements 36
8.2.6 Product compliance 40
8.2.7 Specific test requirements 40
8.2.8 Non-functional requirements 41
9 Definitions, terms, abbreviations 44
9.1 Weak word list 45

5
List of Illustrations
Figure 1: Challenges in the product development process ................ 8
Figure 2: Added value of a standardized Component Requirements
Specification ...................................................................... 11
Figure 3: The Component Requirements Specification within the
product development process ........................................... 13
Figure 4: Overview of the contents of module I ................................ 16
Figure 5: Structure of module II in the VDA Component
Requirements Specification .............................................. 17
Figure 6: Standard process in requirements engineering ................ 18
Figure 7: Proposed sentence structure ............................................ 20
Figure 8: The Component Requirements Specification process in the
supply chain ...................................................................... 22

6
1 Introduction

Within the automotive industry, vehicle projects and the required parts,
components, software, services as well as assemblies are implemented in
collaboration with external providers of required resources (external suppli-
ers). The vehicles do not only present challenges in relation to the relevant
markets, they also feature the latest technologies. In addition to the expec-
tations of the end users, the relevant statutory requirements or require-
ments imposed by regulatory bodies/approval authorities must be met and
taken into account. Even during the product development process, im-
portant proofs of conformity regarding the product and its implementation
processes must be available. Given these current challenges in the auto-
motive industry, car manufacturers (OEM) as well as the suppliers they
work with have to meet various objectives in terms of requirements man-
agement (see Figure 1):
• Management, definition, description, agreements on require-
ments at the various levels of abstraction (vehicle, system,
module, component, part, software),
• Keeping records of proofs and managing information regarding
the requirements
• Ensuring that requirements are met along the upstream value
and supply chains.

A requirement specification bundles the customer’s requirements regarding

a product, based upon which the customer orders the actual (series) devel-
opment. The quality of the requirement specifications thus has a significant
impact on the quality of the components to be developed and delivered, as
well as the required cost and effort for release and system integration. The
time and expenses necessary for rectifying errors or retroactively specifying
requirements increase exponentially as the development progresses and
are relevant in terms of achieving project targets (SOP and time to market)
with shorter and shorter development times.

7
Figure 1: Challenges in the product development process

The customer is responsible for specifying the product from the perspective
of the vehicle manufacturer and the end customer. This specification must
be unambiguous and comprehensible, such that it is clear what the supplier
has to do in order to meet the customer’s requirements regarding the prod-
uct.

When it comes to the development of new technologies in the automotive

industry, there are usually more and more changes the further the develop-
ment of the project progresses. The customer and the supplier can there-
fore agree upon and fine-tune the requirements iteratively over time. The
objective is to fully describe and agree upon the product and the required
implementation processes.

8
The maturity of the delivered product and its production process can be
evaluated within the scope of project implementation according to VDA Ma-
turity Level Assurance for New Parts (MLA) and VDA Volume 2.

The quality of the Component Requirements Specification does not depend

on the length of the requirement description. Rather, it is necessary to un-
ambiguously specify the product ideas and functions, such that they can be
clearly understood and implemented. Data management for controlling,
providing, and archiving data, information as well as proofs is absolutely
necessary and must be agreed upon between the customer and the sup-
plier.

9
2 Objective and purpose

2.1 Significance of the Component Requirements Specification

The Component Requirements Specification results from the specification

process and becomes the central document for agreements between the
customer and the supplier. Thus, the Component Requirements Specifica-
tion is the basis for starting contract award negations or awarding a con-
tract to a supplier in relation to a particular scope of development.
It is necessary to keep the documentation of the requirements in a Compo-
nent Requirements Specification up to date, not only at the time the con-
tract is awarded, and to introduce adjustments by means of a change man-
agement process.

2.2 Objective and purpose of the VDA Component Requirements

Specification standard structure

The objective is to obtain a standardized structural template regarding the

contents that are required as a minimum in requirement specifications. The
structure of the templates for the modules of the Component Requirements
Specification should be understood as a checklist which is meant to ensure
that the requirements from all areas involved are taken into account. In ad-
dition, the added value of the VDA Component Requirements Specification
standard structure can be considered from two angles, namely from both
the customer’s and the supplier’s perspectives (see Figure 2).

10
Figure 2: Added value of a standardized Component Requirements
Specification

The VDA Component Requirements Specification standard structure pro-

vides the basis for a uniform interface for communication between the cus-
tomer and the supplier.

2.2.1 Added value for the customer

For the customer, the Component Requirements Specification is a stand-

ardized template for new projects. It helps the customer when describing
requirements and information. Risks can thus be avoided, the use of re-
sources can be optimized, and communication with the suppliers and the
supply chain can be made more transparent.

The template already includes various aspects that are important and have
to be taken into account when it comes to describing to the supplier the re-
quirements regarding a specific component. The user can focus on the
component-specific parts of the technical specification.

All users are advised to check every project-specific aspect and to fully pre-
sent it in the description of requirements.

11
2.2.2 Added value for suppliers

The added value of a Component Requirements Specification for the sup-

plier is that they obtain information and defined requirements regarding
technical, logistical, as well as quality and production-related aspects etc. in
a standardized form for the planned project.
The Component Requirements Specification provides the basis for further
planning and implementation regarding the project work on the supplier’s
side and along the supply chain.

12
3 General description and definition

3.1 General description

Requirement specifications are created in an early phase of the product de-

velopment process and are an integral part of the inquiry documents.
Figure 3 shows where the Component Requirements Specification is situ-
ated within the product development process as a basis for invitations to
tender, tenders, and agreements/contracts.

Figure 3: The Component Requirements Specification within the

product development process

3.2 Definitions – Component Requirements Specification and func-

tional specification
The Component Requirements Specification defines WHAT solution or
product is needed and FOR WHAT PURPOSE. It serves as a basis for invi-
tations to tender, tenders, as well as agreements/contracts, and can be a
system requirement specification, a module requirement specification as
well as a requirement specification for a component or individual part. The
customer’s requirements, including all framework conditions, must be de-
scribed in it. In addition, the requirements must be met in a quantifiable and
verifiable way.

13
The Component Requirements Specification provides the basis for the cus-
tomer to send an inquiry to the supplier as well as for the supplier to pre-
pare quotes and functional specifications.

The functional specification specifies the plans as to how all valid require-
ments in the Component Requirements Specification will be met1.
The functional specification describes HOW and WITH WHAT the require-
ments will be met. The functional specification does not constitute develop-
ment documentation, in which the solution is precisely described. Instead, it
only contains as much information as the customer needs in order to be
able to assess and evaluate the solution proposed by the supplier.

______________________________
1 see DIN 69905 “Procedure of Projects; Concepts“, VDI 2519 Blatt 1 “Procedures for the
compilation of tender and performance specifications”.

14
4 Application

4.1 General information

The VDA Component Requirements Specification standard structure pro-

vides an overview of the necessary contents for specifying requirements re-
garding developments/products within the automotive industry. It consists
of two modules. Module I describes the process and organization origi-
nated requirements with regard to project organization, whereas module II
comprises the project and product-specific requirements.

The descriptions of the chapters in modules I+II provide the authors of the
Component Requirements Specification with important indications regard-
ing the requirements and system-levels which can be taken into account. In
the finished Component Requirements Specification, these descriptions
must be deleted.

No downloadable documents are provided, given that this VDA volume

serves as a guideline for structuring requirement specifications.
The customer and the supplier are advised to exchange requirements in a
tool-based manner using an agreed-upon process.

4.2 Overview of the modules

4.2.1 Module I – Process and organization originated requirements

Module I “Process and organization originated requirements” de-

scribes the overall requirements regarding the organization and the imple-
mentation of the project (see Figure 4). These requirements can be used
for various projects. Modules I and II are provided to the supplier within the
scope of the inquiry process.

15
Figure 4: Overview of the contents of module I

4.2.2 Module II – Project and product-specific requirements

Module II “Project and product-specific requirements” is a template for

product implementation (see Figure 5) and includes functional as well as
non-functional requirements with regard to product/module development.
The structure of the module is oriented towards the Automotive SPICE®
reference model. It also includes aspects such as safety and security within
the scope of product compliance.
Customer-specific project requirements are described in the respective
chapters. If necessary, chapters and sub-chapters can be added.

16
Figure 5: Structure of module II in the VDA Component Require-
ments Specification

17
5 Formulating precise requirements

5.1 Objective and purpose

Requirements must be formulated precisely, so that everyone involved can

understand them and so that correct implementation is ensured.
When formulating requirements, the following steps are typically followed
(see Figure 6).

Figure 6: Standard process in requirements engineering

5.2 Quality criteria

The following quality criteria provide a guideline for formulating precise re-
quirements in order to ensure that they are of adequate quality in terms of
content.

18
 Comprehensibility A requirement is comprehensible if it is de-
scribed in simple terms and can be understood
using the available information.
Clarity: Clarity means that there is only one possible in-
terpretation for each requirement.
Terms such as the ones in chapter 9.1 should
be avoided.

Identifiability: A requirement can be recognized as such and is

identifiable by means of a unique number or
identifier (ID) within a project.

Testability: It is possible to prove that a requirement has

been met if the requirement is described in such
a way that it is quantifiable and verifiable.

Granularity Clarity and the level of detail of a requirement;

cannot be further deconstructed at the level of
the system.

Validity The scope of validity of a requirement must be

checked (e.g. variant, area of application, ex-
porting country, importing country, and country
of destination) and must be described for the re-
quirement.

Freedom from redun- A requirement is free from redundancies if state-

dancies: ments within the requirement are not repeated in
other requirements.

Completeness: Requirements are complete if the characteristics

and functions necessary for the intended use
have been described (internal completeness)
and the requirements at the next higher level of
abstraction (system, module, vehicle) have been
taken into account (external completeness).

Freedom from contra- A requirement is free from contradictions if it

dictions: contradicts neither itself nor any other require-
ment in the product project.

Further definitions are for instance included in ISO/IEC/IEEE 29148.

19
Requirements can result from an iterative process. However, they should
meet the above-mentioned quality criteria at the time of the first handover
to the supplier (“baseline”).

In order to formulate requirements optimally, the proposed sentence struc-

ture can be used (see Figure 7).

Figure 7: Proposed sentence structure

20
6 The Component Requirements Specification process in the supply
chain

Even in the early phases of the product development process, require-

ments engineering is used in order to capture the valid requirements re-
garding a system/product. To start with, the desired characteristics and
functions of a (sub)system are described, taking the stakeholders’ needs
into account. Afterwards, the (sub)system requirements are defined and
are assigned to the functions.

A version that is consistent and approved from the customer's perspective

is handed over to the supplier (baseline).

The supplier checks the requirement specification in terms of feasibility

(e.g. technology, deadlines) and enters into talks/communication with the
customer to reach agreements. The agreed-upon version of the require-
ment specification provides the supplier with a basis for implementation
and for the functional specification.

The supplier (tier n) uses the customer’s requirements and their own re-
quirements to derive a requirement specification for their own supplier (tier
n+1).

Changes to the requirements or iterative coordination processes must be

taken into account, agreed upon and documented in the supply chain.

21
Figure 8: The Component Requirements Specification process in the
supply chain

22
7 Requirements management with IT support

Requirements engineering tools help with versioning and linking extensive

requirements.

These tools provide the following options:

• Versioning of requirements (“history”)
• Creating and comparing baselines
• Linking requirements
• Assigning attributes (e.g. responsibilities, releases, evaluations,
criticality, functional safety, comments)
• Unique reference (e.g. ID number)
• Evaluation (e.g. reports)
• Structuring and grouping requirements
• Exchanging requirements in a controlled and traceable manner (in-
cluding attributes) via a previously agreed-upon exchange format

Thanks to the agreed-upon exchange format, the customer and the sup-
plier can update and coordinate requirements on a continuous basis.

23
8 VDA Component Requirements Specification standard structure

8.1 Module I – Process and organization originated requirements

8.1.1 Project management

In this chapter, general project management requirements are specified.

These requirements include the initiation, planning, management and com-
pletion of projects.

8.1.1.1 Project organization

In this chapter, the requirements regarding project organization and the col-
laboration model between the customer and supplier must be defined.

Contents that are needed in order to outline the organization of the project
include, for example:
• Contact persons, interface matrix, responsibility assignment matrix
(e.g. RASCI chart)
• Collaboration model (e.g. VDA Maturity Level Assurance)
• Management of information for project communication and the use
of tools. Information security requirements, such as TISAX certifica-
tion, must be taken into account
• Organizational framework conditions such as panels, control pro-
cesses, project management plans
• Agile methods and project management actions
• Standards for documenting project work throughout the project
(e.g. meeting notes, status and progress reports, reviews, mile-
stone evaluations and project completion)
• Agreed-upon number of samples for the defined sample levels

In this chapter, responsibilities and escalation paths are specified for the
project. The component-specific requirements define the collaboration at
various levels of aggregation (construction, system integration, diagnosis,
construction of test vehicles, test drives - further details are possible, but
there should be no redundancies in relation to other requirements and
specifications (e.g. with regard to tests)). A list of contact persons on the
customer’s side (and on the supplier’s side, if known) can be added to the
information for the sake of completeness.

24
8.1.1.2 Feasibility

In this chapter, the requirements that the supplier must meet in order to
prove the feasibility of the project and the product are described. This re-
lates to the methods or criteria to be applied, e.g. technologies, deadlines,
capacities, skills, resources.

8.1.1.3 Scheduling & checking project progress

In this chapter, the most important information for project work, including
milestones, deadlines, communication and reporting are described (see
Maturity Level Assurance and project-specific planning on the part of the
customer).

Aspects that need to be specified include, for example:

• Milestones
Information and possible escalation paths regarding specific mile-
stones throughout the project should be specified here. In addition,
component-specific milestones and assurance levels (e.g. by
means of component-specific deadlines, component descriptions)
are also defined in this chapter.

• Schedule
Individual specification of a component-specific development and
testing schedule which is different from the master schedule due to
certain deviations (e.g. regarding long lead time components). Ref-
erence should also be made to a schedule that is valid for the en-
tire project (if available) in order to avoid redundancies in the indi-
vidual modules of the Component Requirements Specification.

• Sample
Definition of samples with regard to the condition at milestones,
deadlines and number of individual parts. When defining sample
levels, available standards must be referred to if required (see Ma-
turity Level Assurance for New Parts).

• Project completion
The project is completed after a successful PPA process and a
positive evaluation regarding the last milestone (see Maturity Level
Assurance for New Parts).

25
8.1.1.4 Specifications regarding the development method, the devel-
opment process, and collaboration

In this chapter, requirements regarding (joint) development processes are

described, e.g. the specification of a jointly used agile framework or pro-
cess model. It is important that the collaboration model, processes, roles
and responsibilities are defined.

8.1.1.5 Confidentiality

This chapter describes additional requirements, if not already agreed in

principle, with regard to the customer’s and the supplier’s rights and re-
sponsibilities in relation to confidentiality as well as the further use, pro-
cessing and management of the data provided in the Component Require-
ments Specification are described.

Moreover, information security requirements must be met in this regard,

e.g. TISAX regulations (Trusted Information Security Assessment Ex-
change) and the provisions according to ISO 27001.

8.1.2 Risk management

In this chapter, the requirements regarding risk management are specified.

These requirements include, for example:
• Systematic and comprehensive documentation of potential risks
• Analysis and evaluation of risks
• Initiation of preventive actions
• Continuous monitoring of actions

Furthermore, general actions and methods for concept, product and pro-
cess assurance should be requested (e.g. FMEA, Maturity Level Assur-
ance, reviews).

8.1.3 Environment and sustainability

In this chapter, environmental and sustainability requirements are specified.

26
8.1.3.1 Sustainability requirements

In this chapter, requirements regarding the environmental footprint across

the entire product development cycle are described.
This includes, e.g.
• greenhouse gas emissions due to upstream (raw) material extrac-
tion
• preprocessing
• the direct emissions of the supplier’s production equipment,
• the procurement and processing of pre-materials,
• energy consumption
• the type of energy used,
• logistics
according to ISO 14040:2006 and DIN EN ISO 14044:2021.

8.1.3.2 Recycling concept

In this chapter, the requirements regarding the recycling concept for the
component are described. It is necessary to refer to existing legislation and
standards (e.g. VDA Volume 31, VDA 260 (Marking of Materials), ISO
22628 (Recyclability and recoverability), directives 2000/53 EG (End-of life
vehicles), and 761/2001/EG(EMAS)) in this chapter.

8.1.3.3 Environmental characteristics of the product

In this chapter, the requirements in relation to permissible and prohibited

materials and production processes are described, e.g.
• harmful substances,
• permissible and prohibited processing states,
• permissible and prohibited material combinations,
• flammability of materials,
• emission behavior,
• compatibility of materials,
• requirements regarding the reduction of the range of materials.

Statutory and regulatory requirements must be observed in this regard, e.g.

RoHS,REACH, conflict minerals, VDA 232-101.

27
8.1.3.4 Disassembly concept

This chapter specifies the requirements in terms of dismantling the compo-

nent in such a way that materials are separated according to type.

8.1.4 Functional safety

In this chapter, product safety requirements, such as those set out in ISO
26262, are described. The safety level for each individual requirement (e.g.
ASIL level) is specified in the technical requirements (module II).

8.1.5 Cybersecurity management

In this chapter, the requirements regarding product cybersecurity are de-

scribed (e.g. ISO SAE 21434) in order to observe specific regulations at the
level of the vehicle (e.g. UNECE R155).
The specific cybersecurity requirements must be defined in the technical
requirements (module II).

8.1.6 Software update management

In this chapter, general requirements in relation to software updates are de-

scribed, including the requirements in the relevant countries, or those im-
posed by regulatory bodies and approval authorities (e.g. UNECE R156
(SUMS)).
The specific requirements must be defined in the technical requirements
(module II).

8.1.7 Data protection

In this chapter, the requirements regarding applicable data protection regu-

lations (e. g. GDPR) are described. It must be taken into account that sepa-
rate data protection agreements may have to be concluded in case per-
sonal data is processed outside of the European Union / the European
Economic Area.

28
8.1.8 Supply chain management

In this chapter, the requirements relating to the supply chain are described.
It should be ensured that the agreed-upon standards and methods are im-
plemented, applied and monitored accordingly by the supplier and in their
upstream supply chain (e.g. A-SPICE®, TISAX, cybersecurity require-
ments).

The relevant requirements must be contractually agreed between the sup-

plier and the suppliers in their upstream supply chain, e.g.:
• Confidentiality agreements imposed on the contractor’s external re-
source providers
• Project handbook, which describes how the collaboration will be
handled
• Interface agreement
• RASIC / responsibility assignment matrix
• Standards regarding the documentation of project work throughout
the project (e.g. meeting notes, status and progress reports, re-
views, milestone evaluations, project completion)
• Information and proofs whose documentation is mandatory, such
as inspections carried out, validations and verifications
• Management of information relating to project communication and
the use of tools. It must be ensured that information security re-
quirements such as TISAX certification are met
• Contractually agreed methods, such as VDA Maturity Level Assur-
ance, VDA PPA process, etc.
• Proofs of capability to be provided by the external resource provid-
ers in the upstream supply chain (e.g. certificates, reports on 1st,
2nd or 3rd party auditing/assessment, approvals granted by author-
ities)
• Specification and contractual agreement regarding the capacities
required from the external resource providers
• Contractual agreement whereby it must be ensured that the cus-
tomer’s requirements are met in the supply chain, where applica-
ble.

29
8.1.8.1 Contract management, including customer and project-spe-
cific requirements along the entire supply chain

Tasks to be completed within the scope of project management, including

development, administration, adjustment of contracts relating to the project,
are described here.

These include among others:

• Stipulations whereby the supplier must disclose which external re-
source providers they use
• Verification on the part of the supplier that the agreed-upon stand-
ards and methods are applied accordingly by the supplier’s exter-
nal resource providers (e.g. A-SPICE®)
• Confidentiality agreements with the supplier’s external resource
providers
• An interface agreement.

8.1.8.2 Qualification of suppliers

In this sub-chapter, qualification requirements imposed on suppliers, sub-

suppliers, as well as their employees are outlined. If available, training pro-
grams offered by the customer should be referred to.

8.1.8.3 Sub-supplier management according to contract (e.g. deliv-

eries, interfaces and requirements)

In this chapter, the customer defines requirements in relation to the sup-

plier’s sub-suppliers.

8.1.8.4 Definition of a requirements management process with the

supplier

In this chapter, requirements in relation to requirements management are

defined. This includes the tools to be used as well as an agreed-upon ex-
change process.

30
 • Tool
Tool to help with requirements management
Definition of interface and/or exchange format
Definition of contents and attributes / responsibilities
• Exchange process
Definition of the set of requirements to be exchanged, taking the
project schedule into account.

8.1.9 Releases

In this chapter, the requirements regarding the releases of the product and
the process are defined.

The customer specifies an overall project schedule (including sample lev-

els, construction stages, market launch).
Further deliverables, necessary releases and associated requirements as
well as documentation (e.g. sample folder) must be agreed upon between
the customer and the supplier, and must be handed over to the customer.

The supplier must provide all necessary proofs (e.g. homologation, testing,
capability) and certificates needed for production process and product ap-
proval (e.g. VDA Volume 2).

All of the necessary and agreed-upon releases must have been granted by
the time the product reaches series maturity.

8.1.10 Quality management system

If not otherwise agreed upon, the requirements regarding the supplier’s

quality management system (including interfaces to the customer and the
sub-suppliers) are defined here. If possible, this should include a reference
to existing quality management agreements and standards (e.g. IATF
16949).

8.1.10.1 Ensuring process conformity

In this chapter, project-specific proofs and requirements for process con-

formity are defined (e.g. A-SPICE®, assessments, audits, joint review for
ensuring process and product quality).

31
8.1.11 Quality assurance

If not otherwise agreed upon, general requirements regarding the supplier’s

quality assurance processes (product, project, production) and standards to
be applied are defined in this chapter.

Note: Specific product requirements are described in module II.

8.1.12 Requalification

In this chapter, requirements relating to layout inspection and functional

testing are defined.

8.1.13 Reporting and documentation

In this chapter, mutual reporting obligations as well as project-wide stand-

ard documentation are defined, e.g. meeting notes, data and information
management (see ISO 9001:2015).
Besides formal requirements, particular attention must be paid to the sup-
plier’s and the customer’s responsibilities and obligations to cooperate
when it comes to reporting throughout the development process.

In addition, all documents for which there are special obligations to main-
tain records, e.g. documents that are relevant to safety or certification, must
be listed (see VDA Volume 1 – Selection of documents with special archiv-
ing).

8.1.14 Spare part and service requirements

In this chapter, requirements regarding the spare parts documentation that

the customer needs from the supplier, such as spare parts catalogs, spare
and wear parts lists, drawings, isometric images/illustrations of spare parts
in electronic format, etc. are specified. It must be specified that these will
be provided before the start of series production.

32
8.1.15 Configuration and variant management

In this chapter, general requirements regarding variant management are

defined.
In addition, requirements for ensuring the integrity, versioning and availabil-
ity of work products and processes are described.

8.1.16 Non-conformity management

In this chapter, requirements relating to the supplier’s and the customer’s

error management are described. (error documentation and analysis, ac-
tions to eliminate errors, checking for effectiveness, etc.).

8.1.17 Change management

In this chapter, requirements regarding the supplier’s and the customer’s

change management are described (effort, costs, feasibility, deadlines,
documentation, and procedures).

8.1.18 Data management

Project-wide retention and archiving periods have to be specified in accord-

ance with existing standards (e.g. VDA Volume 1). Criteria and processes
for creating and archiving data (drawings, inspection protocols, etc.) must
be defined and must conform with the latest technical standards as well as
statutory requirements. Media and formats for data exchanges between the
customer and the supplier must be defined.

8.1.19 Test management

In this chapter, general requirements and specifications regarding test

management and component testing are described (test planning, imple-
mentation, monitoring and documentation, see ISO 9001:2015, sections
8.2.3 and 8.3.4).

Note: Specific test requirements in relation to the product are de-

scribed in module II.

33
8.1.20 Standard and carry-over parts

In this chapter, customer-specific requirements relating to the use of stand-

ard and carry over parts are defined. All relevant information in relation to
the standard and carry over parts must be given to the supplier. These re-
quirements apply to software, components that include software, and hard-
ware.

8.1.21 Logistics

If not otherwise agreed upon, requirements regarding the logistics concept

which apply to all components of a project are described here. These in-
clude general requirements regarding delivery to individual production loca-
tions or standards, e.g. relating to packaging, load carriers.

8.1.22 Labeling and traceability of parts, components and data

In this chapter, the customer’s requirements regarding the types of labeling

(e.g. for series and original parts, test and prototype parts) and require-
ments in relation to the traceability of components are specified.

8.1.23 Requirements regarding test and prototype tools and pro-

duction

In this chapter, the general requirements regarding the handling of test and
prototype tools are defined (ordering, development, and production of test
parts using prototype tools, costs, disposal, etc.).

8.1.24 Applicable documents

This chapter specifies additional requirements that are not documented in

the requirement specification but must be taken into account and are man-
datory (applicable documents, edition/version).

The applicable documents (legislation, standards, industry-specific stand-

ards and guidelines, customer-specific requirements, etc.) that are referred
to in the requirement specification must be listed here and sorted according
to document type.

34
8.2 Module II – Project and product-specific requirements

This module contains the customer’s project and product-specific require-

ments which are not included in module I of the Component Requirements
Specification.

8.2.1 Objective and scope of the project

In this chapter, the overarching goals and the scope of the project are de-
fined (development, production, etc.). Moreover, the customer should de-
scribe what is not the goal of the project.

Scenarios which could have an impact on the development or production of

the component are described. These developments must be pointed out in
terms of functional upgrades, (setup/assembly) variants, design options, al-
ternative production processes, environmental aspects and further plan-
ning.

8.2.2 Traceability

In this chapter, requirements regarding traceability from the supplier to the

customer are described. This includes, for example:
• Samples
• Series parts
• Work products in the development process (bidirectional traceabil-
ity2)

Note (traceability of parts – samples, series parts):

The traceability of series parts and samples can be ensured
by various means (e.g. Identification and allocation by
means of labeling, readability of information through diagno-
sis services, MES – Manufacturing Execution Systems, allo-
cation of development stages to samples)

Note (work products in the development process):

This bidirectional traceability should already be ensured
when the customer imposes requirements on the supplier at

______________________________
2 see Automotive SPICE® Guidelines 1st edition, September 2017, p. 34.

35
 various levels. It should be clear which level/customer re-
quirement detailed customer requirements were derived
from.
It is advisable to agree on a traceability concept before the
start of the project and to include this concept in the collabo-
ration model.
In complex projects, traceability can only be ensured by us-
ing suitable tools.

8.2.3 Description of the product and function

In this chapter, the component and scope of services to be developed are

defined and described.
Component-specific information must be provided in relation to series, tar-
get markets, as well as the intended applications and purpose of use for
which the component will be delivered/developed.
Specifications regarding the supplier’s variant management must be in-
cluded.
The planned target markets must be contractually agreed.

8.2.4 Product-specific requirements

Component-specific requirements regarding installability, handling in the

production sequence, permissible adjustment work, clamping and fixing
concepts etc. must be defined. If possible, specifications or requirements to
be observed by the supplier regarding the planned component-specific
start-up monitoring must be described.

8.2.5 Technical and functional requirements

In this chapter, the scope of development and delivery is described, mean-

ing all services in relation to the delivery of the component (including proto-
types).

All functions of the component are described in detail in the following chap-
ter.

Note: Depending on the component, not all chapters are neces-

sary and can therefore be regarded as optional.

36
 Given that the scope of delivery may include multiple com-
ponents, the term “system” is used in the following sub-
chapters.

8.2.5.1 Mechanical and environmental requirements

In this chapter, aspects such as geometry, dimensions, weight targets,

space requirements, packaging (installation location) are described.

This information must be provided for all variants, e.g. countries, motors,
design.

If the system is exposed to particular media, environmental stresses or

other influences, these must be specified (e.g. spray water, direct exposure
to sunlight, exhaust, heat from the motor, vibrations, humidity).

In addition, the system’s acoustic, haptic and thermal requirements are de-
scribed (e.g. heat resistance, operating temperatures, storage tempera-
ture).

8.2.5.2 Functional requirements

In this chapter, the system’s functional requirements are specified. The lat-
ter can also be grouped, e.g. according to functionality.
If the functionalities are described in separate requirement specifications
(e.g. diagnosis, network management), the latter must be referenced here.

8.2.5.3 Safety requirements

In this chapter, the system’s technical safety requirements are described.

This includes, e.g. ASIL levels, reactions to errors, time response, and –
where applicable – safety targets.

8.2.5.4 Interfaces and restrictions

In this chapter, interfaces between the system and the operating environ-
ment (e.g. value ranges for sensors, diagnosis, bus system) as well as

37
influences on the system are specified. When defining interfaces, efforts
should be made to specify precise limit values or tolerance ranges.
Among other things, electrical requirements regarding fluctuations in supply
voltage, overvoltage, system compatibility and operational stability are de-
scribed.

In case of a pure software solution, interfaces to other systems are de-

scribed.

8.2.5.5 System architecture

In this chapter, requirements relating to the system architecture are de-

scribed, if there are requirements at this level. Such requirements can re-
late to interfaces or elements of the architecture, such as HW/SW inter-
faces, plugs, power supply.

Note: This chapter is optional. In general, the architecture is de-

signed by the supplier on the basis of requirements and re-
strictions.
If there are requirements at this level, bidirectional traceabil-
ity must be ensured (see 8.2.2).

8.2.5.6 Software architecture

In this chapter, requirements regarding software architecture and the “de-

tailed design” are described, if such requirements exist. They can, for ex-
ample, include algorithms or calculation formulas.

Note: This chapter is optional. In general, the architecture is de-

signed by the supplier on the basis of requirements and re-
strictions.
If there are requirements at this level, bidirectional traceabil-
ity must be ensured (see 8.2.2).

8.2.5.7 Mechanics

In this chapter, the requirements regarding the mechanics (including the ar-
chitecture and design) of a component are specified, e.g. with regard to:

38
 • Feel and surface finish
• Geometry and packaging
• Design (fit, gap dimensions, radii, etc.)
• Construction and joining process, including specification of toler-
ances and measuring instructions (reference point system)
• Load requirements (maximum forces, pressure, alternating load,
predetermined breaking points, acceleration)
• Crash behavior
• Torsional stiffness and deformation
• Vibration behavior (resonance ranges in driving operation or vari-
ous driving conditions, natural frequencies of the component)
• Tightness

8.2.5.8 Electronics

In this chapter, E/E requirements (including architecture and design) are

described:
• Physical specifications (e.g. of the pins) and circuit diagrams for the
system
• Signal characteristics (input and output signals, bus signals with
signal information and load behavior)
• Interface documentation (e.g. signal type, modulation, signal ampli-
tude, frequency range, protocol, bus)
• Electromagnetic compatibility and ESD protection (limit values,
control plan, storage, among other things)

8.2.5.9 New technologies

In this chapter, product requirements that have to be met by means of new

technologies (e.g. AI, CAR2X communication) are specified.

8.2.5.10 Production process

In this chapter, requirements regarding the production process, for example

relating to specific production parameters, cleanliness requirements, pro-
cess assurance, tools, production processes or specific methods for prod-
uct implementation are described.

39
8.2.5.11 Integration

This chapter specifies requirements regarding the integration of a supplier

sub-system into an overall customer system, e.g. integration cycles and ac-
ceptance criteria of the iteration results (DoD – Definition of Done).

8.2.5.12 Cybersecurity and software updates

In this chapter, security goals or security requirements are described. Fur-

ther specifications are described in a development interface agreement
(DIA) or statement of work (SOW).

In this chapter, requirements relating to the implementation of an integrity

test characteristic (e.g. IVD - Integrity Validation Data, UNECE R156) are
described.

Note: When using various diagnosis tools for updating software in

the field, it must be ensured that changes are mapped in the
manufacturer’s software update management system (and
thus configuration management).

8.2.6 Product compliance

In this chapter, the requirements relating to the component’s product com-

pliance (conformity and product safety) are defined (see VDA Product
Compliance).

8.2.7 Specific test requirements

In this chapter, requirements with regard to the type and scope of testing
and simulation are defined.

Among other things, this includes:

• Test planning and documentation
• Inspection equipment to be used
• Provision of prototypes/test samples, data, and models by the cus-
tomer
• Operating states

40
 • Environmental factors
• Reliability and service life requirements
• Specific requirements regarding the target markets
• Testing in the vehicle

8.2.8 Non-functional requirements

In this chapter, non-functional product requirements are described. Among

other things, these can include procedural, regulatory, quality, safety, and
data protection requirements, but also the behavior of the product (how is
the product supposed to work).

8.2.8.1 Compatibility and transferability

In this chapter, requirements regarding the compatibility and transferability

of the product are described. This includes hardware and software, e.g. re-
using software, reusing the whole product in other systems (model series)
or downward compatibility of various software versions.

8.2.8.2 Scalability

In this chapter, requirements regarding the extensibility of the product are

described. This can for example include updates or functional upgrades in
case of software.

8.2.8.3 Robustness

The requirements regarding the product’s robustness are described here.

This can entail the behavior of a system or a component under specific
conditions for a specific period of time under internal and external influ-
ences (e.g. environmental conditions or power supply, failure protection).
The robustness requirements can also be described by means of test
cases (e.g. LV 124 or ISO 16750).

41
8.2.8.4 Reliability

The customer-specific service life requirements (e.g. service life of the vehi-
cle, mileage, software reliability requirements) regarding the component
should be described here.

8.2.8.5 Usability

This chapter outlines the product requirements which are meant to ensure
that the end user can operate the product. These requirements can include
effective, efficient, and intuitive operation as well as satisfaction with a par-
ticular context of use, e.g. infotainment or instrument clusters.

8.2.8.6 Customer support and service requirements

In this chapter, the service requirements that must be taken into account
during the development of the component are described, e.g.
• Operating and maintenance concept
• Repair concept (assembly/disassembly)
• Software updates
• Data protection

8.2.8.7 Resources and stress test

In this chapter, requirements relating to the timing and resources of the

software are defined. This also includes the average and maximum re-
sponse time of the system for typical user actions, and the speed of the
system in case of complex, minimum or average system throughput.

Note: If necessary, buffers for functional upgrades or updates

must be specified.

8.2.8.8 Quality assurance

In this chapter, requirements regarding the assurance of quality and relia-

bility by means of product and process monitoring during product develop-
ment, releases and production are described.

42
Furthermore, requirements regarding the maintenance of software quality
in case of software-based products or software as a product are described.

Requirements regarding the maintainability of the software must be speci-

fied. This can for instance include documentation, scalable software archi-
tecture, clear design and coding guidelines (e.g. MISRA).

8.2.8.9 Type inspection and certification

This chapter specifies the customer requirements regarding the provision of

samples and certificates for type testing and certification, which are neces-
sary in order to meet statutory requirements and to put the product on the
market. A distinction must be made between markets with type testing and
markets with self-certification.

8.2.8.10 Logistics

In this chapter, component-specific requirements in relation to the logistics

concept are described (series and spare parts). In addition to a description
of the required delivery concept (just-in-time, etc.), they should include all
data that the supplier must take into account when it comes to the develop-
ment of the component:
• Delivery and storage times
• Transportability
• Batch sizes
• Packaging
• Load carriers
• Transport protection.

In addition, localization requirements to be met by the supplier, as well as

potential sub-suppliers, are defined:
• Selection and release of raw materials
• Customer’s or supplier’s localization of individual parts
• Technical release(s) in the production and assembly process.

43
9 Definitions, terms, abbreviations

The list of abbreviations is supplemented with a standardized glossary in

which the must important terms used in the requirement specification are
uniformly defined. The glossary shall include the same terms that have
been used in other VDA volumes for the same concepts.

Component Re-
Component Requirements Specification Module I -
quirements Speci-
Process and organization originated requirements
fication - Module I
Component Re-
Component Requirements Specification Module II
quirements Speci-
- Project and product-specific requirements
fication - Module II
Conformity of the produced vehicle with the ap-
Conformity proved vehicle type within the scope of homologa-
tion
Electrically Erasable Programmable Read Only
EEprom
Memory
EMAS Environmental Management and Auditing Scheme
FMEA Failure Mode and Effects Analysis
GDPR General Data Protection Regulation
HW Hardware
ISO International Standards Organization
MISRA Motor Industry Software Reliability Association
OEM Original Equipment Manufacturer
QM Quality management
SW Software

44
9.1 Weak word list3

The following list contains a selection of words or expressions that should

not be used in Component Requirements Specifications or when defining
requirements. They are too undefined (literally too “weak”) and thus not
suitable when it comes to accurately describing a product requirement.

A a bit, a few, a little, a while, actually, against, ago, and, and when,
at, at all, at one time, about (like approx.), absolutely, any, any-
thing, anyone, anywhere, abundant, almost, advanced, among
other things, accomplished, accordingly, amazingly, absolutely, at
best, at first, at most, at times, at the time, at the same time, as if,
as of, as well, apparently, already, apparently, approximately, ap-
prox.
B bad, barely, because, but, by way of exception, better, best, best
possible,
C carefully, certain, certainly, currently, classic, clearly, close,
closely, conditionally, colossal, common, conceivably, contempo-
rary, countless, customary, customarily,
D depending on, differently, difficult, definitely,
E enough, especially, essentially, estimated, erstwhile, elementary,
every once in a while, extensively, extraordinarily, enormously,
entirely, even, exactly, exceedingly, extremely, etc.
F fantastic, far, fast, fabulous, fairly, few, for the most part, for the
time being, formerly, frequently, from anywhere, from time to time,
further,
G generally accepted, great, good
H hard, hastily, however, huge, hopefully
I if necessary, if need be, if possible, in case, in no case, in part, in
principle, in the near future, imperceptibly, incidentally, inconsider-
able, individually, innumerable, intuitively, incredibly, isolated,
J just,
L lately, less, likely, little, long, long ago, loud, light,
______________________________
3 see Dreher, Marion: „Konstruktive und analytische Methoden zur Qualitätssicherung von
Anforderungen in der Softwareentwicklung“. [Constructive and analytical methods for qual-
ity assurance in relation to software development requirements] Degree dissertation, Janu-
ary 2004)

45
 M many times, mainly, maybe, meanwhile, moderately, more, more
or less, more often than not, moreover, multiple, most, mostly,
most likely, modern, much,
N nearly, next to, novel, now and then, not long ago, not quite, nu-
merous, never,
O one (someone), one day, overly, other, otherwise, operable, opti-
mal, only, only just, once, obviously, often, occasionally, or so,
P particular, persistently, perhaps, perfect, periodically, perplexing,
partly, partially, plausible, potentially, practically, pretty, presuma-
bly, possible, possibly, preferably, probably, promptly,
Q quiet, quite, quite a few,
R rather, rarely, really, recently, regular, remaining, roughly,
S several, several times, soon, sweeping, similarly, simply, seem-
ingly, simultaneously, slow, small, such as, some, sometimes,
something, somehow, someone, somewhere, self-explanatory,
surely, so, such, short, so to speak, specially, strongly
T temporarily, then, thus, tiny, to some extent, terrible, the other
day, to some extent, thoroughly, total, tremendous, tremendously,
U understandable, usual, usually,
V very, various,
W wide, well, wonders how, whole,
Y yes, yet,

46
Quality Management in the Automotive Industry

The current versions of the VDA publications covering quality management

in the automotive industry (QAI) can be found on the Internet under
http://www.vda-qmc.de.

You may also order via this homepage.

Reference:
Verband der Automobilindustrie e.V. (VDA)
Qualitäts Management Center (QMC)
Behrenstraße 35, 10117 Berlin
Phone +49 (0) 30 8978 42-235, Fax +49 (0) 30 8978 42-605
Email: info@vda-qmc.de, Website: www.vda-qmc.de