SIST ISO 9000-3:1996

SLOVENSKI STANDARD
SIST ISO 9000-3:1996
01-maj-1996
Standardi za vodenje in zagotavljanje kakovosti - 3. del: Smernice za uporabo
standarda ISO 9001 pri razvoju, nabavi in vzdrževanju programske opreme
Quality management and quality assurance standards -- Part 3: Guidelines for the
application of ISO 9001 to the development, supply and maintenance of software
Normes pour la gestion de la qualité et l'assurance de la qualité -- Partie 3: Lignes
directrices pour l'application de l'ISO 9001 au développement, à la mise à disposition et
à la maintenance du logiciel
Ta slovenski standard je istoveten z: ISO 9000-3:1991
ICS:
03.120.10 Vodenje in zagotavljanje Quality management and
kakovosti quality assurance
35.080 Dokumentiranje razvoja Software development and
programske opreme in system documentation
sistemov (sistemska
dokumentacija)
SIST ISO 9000-3:1996 en
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

---------------------- Page: 1 ----------------------

SIST ISO 9000-3:1996

---------------------- Page: 2 ----------------------

SIST ISO 9000-3:1996
I N T ER NAT I O NA L IS0
STANDARD
9000-3
First edition
1991 46-01
Corrected and reprinted
1993-05-01
Quality management and quality assurance
standards -
Part 3:
Guidelines for the application of IS0 9001 to
the development, supply and maintenance of
software
Normes pour la gestion de la qualité et l'assurance de la qualité -
Partie 3: Lignes directrices pour l'application de I'ISO 9001 au
développement, à la mise à disposition et à la maintenance du logiciel
Reference number
IS0 9000-3:1991 (E)

---------------------- Page: 3 ----------------------

SIST ISO 9000-3:1996
IS0 9000-3:1991(E)
.
Contents
Page
1 Scope . 1
2 Normative references . 1
3 Definitions . 1
4 Quality system - Framework . 2
4.1 Management responsibility . 2
4.2 Quality system . 3
4.3 Internal quality system audits . 3
4.4 Corrective action . 3
5 Quality system - Life-cycle activities . 3
5.1 General . 3
5.2 Contract review . 4
5.3 Purchaser's requirements specification . 4
5.4 Development planning . 4
Quality planning . 6
5.5
5.6 Design and implementation . 6
5.7 Testing and validation . 7
5.8 Acceptance . 7
5.9 Replication. delivery and installation . 8
5.10 Maintenance . 8
6 Quality system - Supporting activities (not phase dependent) 9
6.1 Configuration management . 9
6.2 Document control . 10
6.3 Quality records . 11
6.4 Measurement . 11
6.5 Rules. practices and conventions . 12
(O IS0 1991
All rights reserved . No part of this publication may be reproduced or utilized in any form or
by any means. electronic or mechanical. including photocopying and microfilm. without per-
mission in writing from the publisher .
International Organization for Standardization
Case Postale 56 CH-1211 Genève 20 Switzerland
Printed in Switzerland
ii

---------------------- Page: 4 ----------------------

SIST ISO 9000-3:1996
IS0 9000-3:1991(E)
6.6 Tools and techniques . 12
6.7 Purchasing . 12
6.8 Included software product . 12
6.9 Training . 12
Annexes
A Cross-reference between IS0 9000-3 and IS0 9001 . 14
B Cross-reference between IS0 9001 and IS0 9000-3 ., 15
...
111

---------------------- Page: 5 ----------------------

SIST ISO 9000-3:1996
IS0 9000-3:1991(E)
Foreword
IS0 (the International Organization for Standardization) is a worldwide
federation of national standards bodies (IS0 member bodies). The work
of preparing International Standards is normally carried out through IS0
technical committees. Each member body interested in a subject for
which a technical committee has been established has the right to be
represented on that committee. International organizations, governmental
and non-governmental, in liaison with ISO, also take part in the work. IS0
collaborates closely with the International Electrotechnical Commission
(IEC) on all matters of electrotechnical standardization.
Draft International Standards adopted by the technical committees are
circulated to the member bodies for voting. Publication as an International
Standard requires approval by at least 75 % of the member bodies casting
a vote.
International Standard IS0 9000-3 was prepared by Technical Committee
ISO/TC 176, Quality management and quality assurance.
IS0 9000 consists of the following parts, under the general title Quality
management and quality assurance standards:
- Part 1: Guidelines for selection and use
- Part 2: Generic guidelines for the application of IS0 9001, IS0 9002
and IS0 9003
- Part3: Guidelines for the application of IS0 9001 to the develop-
ment, supply and maintenance of software
Part 1 will be a revision of IS0 9000:1987. Part 2 is to be published.
Annexes A and B of this part of IS0 9000 are for information only.
IV

---------------------- Page: 6 ----------------------

SIST ISO 9000-3:1996
IS0 9000-3:1991 (E)
Introduction
With the progress of information technology, the amount of software
products has been increasing and the quality management of software
products is essential. One of the means of establishing a quality manage-
ment system is to provide guidance for software quality assurance.
The requirements for a generic quality system for two-party contractual
situations have already been published: IS0 9001 :I 987, Quality systems
- Model for quality assurance in design/development, production, instal-
lation and servicing.
However, the process of development and maintenance of software is
different from that of most other types of industrial products. In such a
rapidly evolving technology field it is therefore necessary to provide ad-
ditional guidance for quality systems where software products are in-
volved, taking into account the present status of this technology.
The nature of software development is such that some activities are re-
lated to particular phases of the development process, while others may
apply throughout the process. These guidelines have therefore been
structured to reflect these differences. This document thus does not cor-
respond directly in format with IS0 9001 and cross-reference indexes
(annex A and annex B) are provided to give assistance when referring to
that standard.
Contracts between two parties for software product development may
occur in many variations. In certain cases of two-party contracts, these
guidelines might not be applicable even if "tailored". It is therefore im-
portant to determine the adequacy of the application of this part of
IS0 9000 to the contract.
This part of IS0 9000 deals primarily with situations where specific soft-
ware is developed as part of a contract according to purchaser's specifi-
cations. However, the concepts described may be equally of value in other
situations.
NOTES
1 In English, use of the masculine gender in this part of IS0 9000 is not meant
to exclude the feminine gender where applied to persons. Similarly, use of the
singular does not exclude the plural (and vice versa) when the sense allows.
2 Throughout this part of IS0 9000 where there is no further guidance, the text
of the relevant IS0 9001 clause is given and printed in italics.
3 In this part of IS0 9000 there are a number of lists; none of these is presumed
to be exhaustive -they are intended as examples.

---------------------- Page: 7 ----------------------

SIST ISO 9000-3:1996

---------------------- Page: 8 ----------------------

SIST ISO 9000-3:1996
INTERNATIONAL STANDARD IS0 9000-3:1991(E)
Quality management and quality assurance
standards -
Part 3:
Guidelines for the application of IS0 9001 to the
deve lop m en t , s U pp I y a n d ma i n t e na n ce of sof twa re
part of IS0 9000 are encouraged to investigate the
1 Scope
possibility of applying the most recent editions of the
standards indicated below. Members of IEC and IS0
This part of IS0 9000 sets out guidelines to facilitate
maintain registers of currently valid International
the application of IS0 9001 to organizations develop-
Standards.
ing, supplying and maintaining software.
is intended to provide guidance where a contract IS0 2382-1 : 1984, Data processing - Vocabulary -
It
between two parties requires the demonstration of a Part 01: Fundamental terms.
supplier's capability to develop, supply and maintain
software products. IS0 8402: 1 986, Quality - Vocabulary.
The guidelines in this part of IS0 9000 are intended
IS0 9001 :I 987, Quality systems - Model for quality
to describe the suggested controls and methods for
assurance in design/development, production, instal-
producing software which meet a purchaser's re-
lation and servicing.
quirements. This is done primarily by preventing non-
conformity at all stages from development through to
IS0 1 O01 1-1 : 1 990, Guidelines for auditing quality
maintenance.
systems - Part 1: Auditing.
The guidelines in this part of IS0 9000 are applicable
in contractual situations for software products when
3 Definitions
a) the contract specifically requires design effort and
the product requirements are stated principally in For the purposes of this part of IS0 9000, the defi-
performance terms, or they need to be estab- nitions given in IS0 2382-1 and IS0 8402 apply, to-
lished; gether with the following definitions.
b) confidence in the product can be attained by the
3.1 software: Intellectual creation comprising the
adequate demonstration of a certain supplier's ca-
programs, procedures, rules and any associated
pabilities in development, supply and mainten- a data
documentation pertaining to the operation of
ance.
processing system.
[IS0 2382-1 :I 984, 01.04.041
2 Normative references
NOTE 4 Software is independent of the medium on
which it is recorded.
The following standards contain provisions which,
through reference in this text, constitute provisions
of this part of IS0 9000. At the time of publication, the 3.2 software product: Complete set of computer
editions indicated were valid. All standards are subject programs, procedures and associated documentation
to revision, and parties to agreements based on this and data designated for delivery to a user.
1

---------------------- Page: 9 ----------------------

SIST ISO 9000-3:1996
IS0 9000-3:1991 (E)
3.3 software item: Any identifiable part of a soft-
e) control further processing, delivery or installation
of nonconforming product until the deficiency or
ware product at an intermediate step or at the final
unsatisfactory condition has been corrected.
step of development.
[IS0 9001 :I 987, 4.1 -2.11
3.4 development All activities to be carried out to
create a software product.
4.1.1.2.2 Verification resources and personnel
3.5 phase: Defined segment of work.
The supplier shall identify in-house verification re-
NOTE 5 A phase does not imply the use of any specific quirements, provide adequate resources and assign
a period of time in the
life-cycle model, nor does it imply trained personnel for verification activities.
development of a software product.
Verification activities shall include inspection, test and
monitoring of the design, production, installation and
3.6 verification (for software): The process of
servicing processes and/or product; design reviews
evaluating the products of a given phase to ensure
and audits of the quality system, processes and/or
correctness and consistency with respect to the
product shall be carried out by personnel independent
products and standards provided as input to that
of those having direct responsibility for the work being
phase.
performed.
3.7 validation (for software): The process of evalu-
[IS0 9001:1987, 4.1.2.21 C'
ating software to ensure compliance with specified
requirements.
4.1.1.2.3 Management representative
The supplier shall appoint a management represen-
tative who, irrespective of other responsibilities, shall
4 Quality system - Framework
have defined authority and responsibility for ensuring
that the requirements of [IS0 90011 are implemented
and maintained.
4.1 Management responsibility
[IS0 9001 :I 987, 4.1.2.31
4.1.1 Supplier's management responsibility
4.1.1.3 Management review
4.1.1.1 Quality policy
The quality system adopted to satisfy the require-
ments of [IS0 90011 shall be reviewed at appropriate
The supplier's management shall define and docu-
intervals by the supplier's management to ensure its
ment its policy and objectives for, and commitment
continuing suitability and effectiveness. Records of
to, quality. The supplier shall ensure that this policy is
such reviews shall be maintained.
understood, implemented and maintained at all levels
in the organization.
- Management reviews normally include as-
NOTE
sessment of the results of internal quality system au-t
[IS0 9001:1987, 4.1.13
dits, but are carried out by, or on behalf of, the
supplier's management viz management personnel
4.1.1.2 Organization
having direct responsibility for the system.
[IS0 9001 :I 987, 4.1.33
4.1.1.2.1 Responsibility and authority
The responsibility, authority and the interrelation of all
4.1.2 Purchaser's management responsibility
personnel who manage, perform and verify work af-
fecting quality shall be defined; particularly for per-
The purchaser should cooperate with the supplier to
sonnel who need the organizational freedom and
provide all necessary information in a timely manner
authority to
and resolve pending items.
The purchaser should assign a representative with the
a) initiate action to prevent the occurrence of product
responsibility for dealing with the supplier on con-
nonconformity;
tractual matters. This representative should have the
b) identify and record any product quality problems; authority commensurate with the need to deal with
contractual matters which include, but are not limited
c) initiate, recommend or provide solutions through to, the following:
designated channels;
a) defining the purchaser's requirements to the sup-
plier;
d) verify the implementation of solutions;
2

---------------------- Page: 10 ----------------------

SIST ISO 9000-3:1996
IS0 9000-3:1991 (E)
b) answering questions from the supplier;
4.3 Internal quality system audits
c) approving the supplier's proposals;
Internal quality audits
The supplier shall carry out a comprehensive system
d) concluding agreements with the supplier;
of planned and documented internal quality [system]
audits to verify whether quality activities comply with
e) ensuring the purchaser's organization observes
planned arrangements and to determine the effec-
the agreements made with the supplier;
tiveness of the quality system.
f) defining acceptance criteria and procedures;
Audits shall be scheduled on the basis of the status
and importance of the activity.
g) dealing with the purchaser-supplied software
items that are found unsuitable for use.
The audits and follow-up actions shall be carried out
in accordance with documented procedures.
4.1.3 Joint reviews
The results of the audits shall be documented and
brought to the attention of the personnel having re-
Regular joint reviews involving the supplier and pur-
sponsibility in the area audited. The management
chaser should be scheduled to cover the following
personnel responsible for the area shall take timely
aspects, as appropriate:
corrective action on the deficiencies found by the au-
dit.
a) conformance of the software to the purchaser's
agreed requirements specification;
[IS0 9001:1987, 4.171
b) verification results; See IS0 1 O01 1-1.
c) acceptance test results;
4.4 Corrective action
The results of such reviews should be agreed and
documented.
The supplier shall establish, document and maintain
procedures for
4.2 Quality system a) investigating the cause of nonconforming product
and the corrective action needed to prevent re-
currence;
4.2.1 General
b) analysing all processes, work operations, conces-
The supplier should establish and maintain a docu-
sions, quality records, service reports and cus-
mented quality system. The quality system should be
tomer complaints to detect and eliminate potential
an integrated process throughout the entire life cycle,
causes of nonconforming product;
thus ensuring that quality is being built in as develop-
(
ment progresses, rather than being discovered at the
c) initiating preventive actions to deal with problems
end of the process. Problem prevention should be
to a level corresponding to the risks encountered;
emphasized rather than depending on correction after
occurrence.
d) applying controls to ensure that corrective actions
are taken and that they are effective;
The supplier should ensure the effective implemen-
tation of the documented quality system.
e) implementing and recording changes in pro-
cedures resulting from corrective action.
4.2.2 Quality system documentation
[IS0 9001:1987, 4.141
All the quality system elements, requirements and
provisions should be clearly documented in a sys-
tematic and orderly manner.
5 Quality system - Life-cycle activities
4.2.3 Quality plan
5.1 General
The supplier should prepare and document a quality
A software development project should be organized
plan to implement quality activities for each software
development on the basis of the quality system, and according to a life-cycle model. Quality-related activ-
ensure that it is understood and observed by the or- ities should be planned and implemented with respect
ganizations concerned. to the nature of the life-cycle model used.
3

---------------------- Page: 11 ----------------------

SIST ISO 9000-3:1996
IS0 9000-3:1991 (E)
This part of IS0 9000 is intended for application ir-
f) standards and procedures to be used:
respective of the life-cycle model used. Should any
description, guidance, requirement or structure be g) replication requirements (see 5.9).
read differently, this is unintended and should not be
read as indicating that the requirement or guidance is
restricted to a specific life-cycle model only.
5.3 Purchaser's requirements specification
5.2 Contract review
5.3.1 General
In order to proceed with software development, the
5.2.1 General
a complete, unambiguous set of
supplier should have
functional requirements. In addition, these require-
The supplier should establish and maintain procedures
ments should include all aspects necessary to satisfy
for contract review and for the coordination of these
the purchaser's need. These may include, but are not
activities.
limited to, the following: performance, safety, reliabil-
Each contract should be reviewed by the supplier to ity, security and privacy. These requirements should
so as to allow validation
ensure that be stated precisely enough
during product acceptance.
a) the scope of the contract and requirements are
The purchaser's requirements specification records I
defined and documented;
these requirements. In some cases, this document is
provided by the purchaser. If not, the supplier should
b) possible contingencies or risks are identified;
develop these requirements in close cooperation with
the purchaser, and the supplier should obtain the
c) proprietary information is adequately protected;
purchaser's approval before entering the development
stage. The purchaser's requirements specification
d) any requirements differing from those in the
should be subject to documentation control and con-
tender are resolved;
figuration management as part of the development
documentation.
e) the supplier has the capability to meet contractual
requirements;
All interfaces between the software product and other
software or hardware products should be fully speci-
f) the supplier's responsibility with regard to sub-
fied, either directly or by reference, in the purchaser's
contracted work is defined;
requirements specification.
g) the terminology is agreed by both parties;
5.3.2 Mutual cooperation
h) the purchaser has the capability to meet contrac-
tual obligations.
During the development of the purchaser's require-
ments specification, attention to the following issues
Records of such contract reviews should be main-
is recommended:
tained.
('
a) assignment of persons (on both sides) responsible
5.2.2 Contract items on quality
for establishing the purchaser's requirements
specification;
Among others, the following items are frequently
found to be relevant in the contract:
b) methods for agreeing on requirements and ap-
proving changes;
a) acceptance criteria;
c) efforts to prevent misunderstandings such as
b) handling of the changes in purchaser's require-
definition of terms, explanations of background of
ments during the development;
requirements:
c) handling of problems detected after acceptance,
d) recording and reviewing discussion results on both
including quality-related claims and purchaser
sides.
complaints;
d) activities carried out by the purchaser, especially
5.4 Development planning
the purchaser's role in requirements specification,
installation and acceptance;
5.4.1 General
e) facilities, tools and software items to be provided
The development plan should cover the following:
by the purchaser;
4

---------------------- Page: 12 ----------------------

SIST ISO 9000-3:1996
IS0 9000-3:1991(E)
a) the definition of the project, including a statement c) organizational responsibilities, resources and work
assignment;
of its objectives and with reference to related
purchaser or supplier projects;
d) organizational and technical interfaces between
different groups.
b) the organization of the project resources, including
the team structure, responsibilities, use of sub-
contractors and material resources to be used;
5.4.2.3 Development methods and tools
c) development phases (as defined in 5.4.2.1);
The development plan should identify methods for
ensuring that all activities are carried out correctly.
d) the project schedule identifying the tasks to be
This may include
performed, the resources and time required for
each and any interrelationships between tasks;
a) rules, practices and conventions for development;
e) identification of related plans, such as
b) tools and techniques for development;
- quality plan,
c) configuration management.
- configuration management plan,
5.4.3 Progress control
I - integration plan,
Progress reviews should be planned, held and docu-
- test plan. mented to ensure that outstanding resource issues
are resolved and to ensure effective execution of de-
velopment plans.
The development plan should be updated as devel-
opment progresses and each phase should be defined
as in 5.4.2.1 before activities in that phase are started.
5.4.4 Input to development phases
It should be reviewed and approved before execution.
The required input to each development phase should
be defined and documented. Each requirement
5.4.2 Development plan
should be defined so that its achievement can be
verified. Incomplete, ambiguous or conflicting re-
5.4.2.1 Phases
quirements should be resolved with those responsible
for drawing up the requirements.
The development plan should define a disciplined
process or methodology for transforming the pur-
5.4.5 Output from development phases
chaser's requirements specification into a software
product. This may involve dividing the work into
The required output from each development phase
phases, and the identification of
should be defined and documented. The output from
each development phase should be verified and
l a) development phases to be carried out;
should
b) required inputs for each phase;
a) meet the relevant requirements;
c) required outputs from each phase;
b) contain or reference acceptance criteria for for-
warding to subsequent phases;
d) verification procedures to be carried out at each
phase;
c) conform to appropriate development practices and
conventions, whether or not these have been
e) analysis of the potential problems associated with
stated in the input information;
the development phases and with the achievment
of the specified requirements.
d) identify those characteristics of the product that
are crucial to its safe and proper functioning;
5.4.2.2 Management
e) conform to applicable regulatory requirements.
The development plan should define how the project
is to be managed, including the identification of
5.4.6 Verification of each phase
a) schedule of development, implementation and as-
The supplier should draw up a plan for verification of
sociated deliveries;
all development phase outputs at the end of each
b) progress control; phase.

---------------------- Page: 13 ----------------------

SIST ISO 9000-3:1996
IS0 9000-3:1991(E)
Development verification should establish that devel-
- reviews and tests,
opment phase outputs meet the corresponding input
requirements by means of development control - configuration management and change control,
measures such as
- defect control and corrective action.
a) holding development reviews at appropriate points
in the development phases;
5.6 Design and implementation
b) comparing a new design with a proven similar de-
5.6.1 General
sign, if available;
The design and implementation activities are those
c) undertaking tests and demonstrations.
which transform the purchaser's requirements speci-
fication into a software product. Because of the com-
The verification results and any further actions re-
plexity of software products, it is imperative that
quired to ensure that the specified requirements are
these activities be carried out in a disciplined manner,
met should be recorded and checked when the ac-
tions are completed. Only verified development out- in order to produce a product according to specifi-
cation rather than depending on the test and validation
puts should be submitted to configuration
activities for assurance of quality.
management and accepted for subsequent use.
NOTE 6 The level of information disclosure to be pro-
5.5 Quality planning vided to the purchaser needs to be mutually agreed to by
the parties, as design and implementation processes are
frequently proprietary to the supplier.
5.5.1 General
5.6.2 Design
As part of the development planning, the supplier
should prepare a quality plan.
In addition to the requirements common to all the
development phases, the following aspects inherent
The quality plan should be updated along with the
to the design activities should be taken into account.
progress of the development and items concerned
with each phase should be completely defined when
a) Identification of design considerations: in addition
starting that phase.
to the input and output specifications, aspects
The quality plan should be formally reviewed and such as design rules and internal interface defi-
agreed by all organizations concerned in its im- nitions should be examined.
plementation.
b) Design methodology: a systematic design meth-
The document that describes the quality plan (see
odology appropriate to the type of software prod-
5.5.2) may be an independent document (entitled
uct being developed should be used.
quality plan) or a part of another document, or com-
posed of several documents including the develop-
c) Use of past design experiences: utilizing lessons
ment plan.
learned from past design experiences, the supplier ( ,
should avoid recurrences of the same or similar
problems.
5.5.2 Quality plan content
d) Subsequent processes: the product should be de-
The, quality plan should specify or reference the fol-
signed to the extent practical to facilitate testing,
lowing items:
maintenance and use.
a) quality objectives, expressed in measurable terms
5.6.3 Implementation
whenever possible;
In addition to the requirements common to all the
b) defined input and output criteria for each develop-
development activities, the following aspects should
ment phase;
be considered in each
...

NORME IS0
I N T ER NAT I O NA LE 9000-3
Première édition
1991-06-01
Corrigée et réimprimée
1993-05-01
Normes pour la gestion de la qualité et
-
l'assurance de la qualité
Partie 3:
Lignes directrices pour l'application de
I'ISO 9001 au développement, à la mise à
disposition et à la maintenance du logiciel
Quality management and quality assurance standards - '
Part 3: Guidelines for the application of IS0 9001 to the development,
supply and maintenance of software
Numéro de référence
IS0 9000-3:1991 (F)

---------------------- Page: 1 ----------------------
IS0 9000-3A991 (F)
Sommaire
Page
1 Domaine d'application . 1
2 Références normatives . 1
3 Définitions . 1
4 Système qualité . Cadre . 2
4.1 Responsabilité de la direction . 2
4.2 Système qualité . 3
4.3 Audits internes du système qualité . 3
4.4 Action corrective . 4
........................... 4
Système qualité . Activités du cycle de vie
5
5.1 Généralités . 4
5.2 Revues de contrat . 4
5.3 Spécifications des besoins de l'acheteur . 5
5.4 Planification du développement . 5
5.5 Plan qualité . 6
5.6 Conception et réalisation . 7
5.7 Tests et validation . 7
5.8 Réception . 8
5.9 Reproduction. livraison et installation . 8
5.10 Maintenance . 9
6 Système qualité . Activités de soutien (indépendantes des
phases) . 10
6.1 Gestion de configuration . 10
6.2 Maîtrise des documents . 11
6.3 Enregistrements relatifs h la qualité . 12
6.4 Mesures . 12
O IS0 1991
Droits de reproduction réservés . Aucune partie de cette publication ne peut être reproduite
ni utilisée sous quelque forme que ce soit et par aucun procédé. électronique ou mécanique.
y compris la photocopie et les microfilms. sans l'accord écrit de l'éditeur .
Organisation internationale de normalisation
Case Postale 56 CH-1211 Genève 20 Suisse
Imprimé en Suisse
ii

---------------------- Page: 2 ----------------------
IS0 9000-3:1991(F)
........... . ...... .. .. .... .... ...... . .... 13
6.5 Règles, pratiques et conventions
6.6 Outils et techniques . . . . . 13
6.7 Achats . 13
6.8 Logiciel inclus . 13
6.9 Formation ~.a . . . . . . . . 74
Ann exes
A Références croisées entre I'ISO 9000-3 et I'ISO 9001 . 15
B Références croisées entre I'ISO 9001 et I'ISO 9000-3 . 16
...

---------------------- Page: 3 ----------------------
IS0 9000-3:1991(F)
Avant-propos
L'ISO (Organisation internationale de normalisation) est une fédération
mondiale d'organismes nationaux de normalisation (comités membres de
I'ISO). L'élaboration des Normes internationales est en général confiée aux
comités techniques de I'ISO. Chaque comité membre intéressé par une
étude a le droit de faire partie du comité technique créé à cet effet. Les
organisations internationales, gouvernementales et non gouvernemen-
tales, en liaison avec I'ISO participent également aux travaux. L'ISO colla-
bore étroitement avec la Commission électrotechnique internationale (CEI)
en ce qui concerne la normalisation électrotechnique.
Les projets de Normes internationales adoptés par les comités techniques
sont soumis aux comités membres pour vote. Leur publication comme
Normes internationales requiert l'approbation de 75% au moins des co-
mités membres votants.
La Norme internationale IS0 9000-3 a été élaborée par le comité techni-
Management et assurance de la qualité, sous-comité SC
que ISO/TC 176,
2, Systèmes qualité.
L'ISO 9000 comprend les parties suivantes, présentées sous le titre gé-
néral Normes pour la gestion de la qualité et l'assurance de la qualité:
- Partie 7: Lignes directrices pour la sélection et l'utilisation
- Partie 2: Lignes directrices pour l'application de I'lSO 9001, I'ISO
9002 et I'ISO 9003
- Partie 3: Lignes directrices pour l'application de /'/SO 9001 au dé-
veloppement, à la mise à disposition et à la maintenance du logiciel
La partie 1 sera une révision de I'ISO 9000:1987.
Les annexes A et B de la présente partie de I'ISO 9000 sont données
uniquement à titre d'information.
iv

---------------------- Page: 4 ----------------------
IS0 9000-3:1991 (F)
Introduction
Avec le progrès de la technologie de l'information, la quantité du logiciel
augmente et la gestion de la qualité des logiciels est essentielle. Un des
moyens d'établir un système de gestion de la qualité est de fournir des
conseils pour l'assurance de la qualité du logiciel.
Les exigences d'un système générique de la qualité pour un contrat entre
deux parties sont déjà publiées: IS0 9001:1987, Systèmes qualité - Mo-
dèle pour l'assurance de la qualité en conception/développement, pro-
duction, installation et soutien après la vente.
Cependant, le processus de développement et de maintenance du logiciel
est différent de celui des autres types de produits industriels. Dans un
domaine technologique évoluant aussi rapidement, il est donc nécessaire
de fournir des conseils supplémentaires pour les systèmes qualité impli-
quant des logiciels, en prenant en compte l'état actuel de la technologie.
La nature du développement du logiciel est telle que certaines activités
sont relatives à des phases particulières du processus de développement,
tandis que d'autres peuvent s'appliquer tout au long du processus. En
conséquence, ces lignes directrices ont été structurées pour refléter ces
différences. Aussi l'organisation de ce document ne correspond-elle pas
directement à celle de I'ISO 9001 et un index de référence (annexe A et
annexe 6) est fourni comme aide quand cette norme sert de référence.
Des contrats entre deux parties pour le développement d'un logiciel peu-
vent se présenter dans différentes situations. Dans certains cas de con-
trats entre deux parties, ces lignes directrices pourraient ne pas être
applicables même en les adaptant. II est donc important de s'assurer de
l'adéquation de l'application de la présente partie de I'ISO 9000 au contrat.
La présente partie de I'ISO 9000 traite en premier lieu des situations où
le développement d'un logiciel spécifique fait partie d'un contrat et répond
aux spécifications de l'acheteur. Cependant, les concepts décrits peuvent
également être utilisés avec autant d'efficacité dans d'autres situations.
NOTES
1 L'emploi du genre masculin dans la présente partie de I'ISO 9000 n'exclut pas
le genre féminin lorsqu'il s'applique aux personnes. De même, l'utilisation du sin-
le pluriel (et vice versa) lorsque le sens le permet.
gulier n'exclut pas
2 Tout au long de la présente partie de I'ISO 9000, quand il n'y a pas de conseils
supplémentaires, le texte de I'ISO 9001 est donné et imprimé en italique.
3
Dans la présente partie de I'ISO 9000, certaines énumérations sont données

---------------------- Page: 5 ----------------------
NORME INTERNATIONALE IS0 9000-3:1991(F)
Normes pour la gestion de la qualité et l'assurance de
la qualité -
Partie 3:
Lignes directrices pour l'application de I'ISO 9001 au
développement, à la mise à disposition et à la maintenance
du logiciel
1 Domaine d'application 2 Références normatives
Les normes suivantes contiennent des dispositions
qui, par suite de la référence qui en est faite, consti-
tuent des dispositions valables pour la présente partie
La présente partie de I'ISO 9000 établit des lignes di-
de I'ISO 9000. Au moment de la publication, les édi-
rectrices facilitant l'application de I'ISO 9001 pour les
tions indiquées étaient en vigueur. Toute norme est
organisations de développement, de mise à dispo-
sujette à révision et les parties prenantes des accords
sition et de maintenance du logiciel.
fondés sur la présente partie de I'ISO 9000 sont invi-
tées à rechercher la possibilité d'appliquer les éditions
Elle a pour but de donner des conseils iorsqu'un
les plus récentes des normes indiquées ci-après. Les
contrat entre deux parties requiert la démonstration
membres de la CE1 et de I'ISO possèdent le registre
de l'aptitude du fournisseur à développer, mettre à
des Normes internationales en vigueur à un moment
disposition et maintenir du logiciel.
donné.
'\ Les lignes directrices de la présente partie de
IS0 2382-1:1984, Traitement des données - Voca-
I'ISO 9000 ont pour but de décrire les moyens de
bulaire - Partie 01: Termes fondamentaux.
gestion et les méthodes préconisés pour produire du
logiciel qui satisfasse aux exigences de l'acheteur.
IS0 8402:1986, Qualité - Vocabulaire.
Ceci est obtenu principalement en prévenant toute
non-conformité & toutes les phases, depuis le déve-
IS0 9001:1987, Systèmes qualité - Modèle pour
loppement jusqu'à la maintenance.
l'assurance de la qualité en conception/dévelop-
pement, production, installation et soutien après la
Les lignes directrices de la présente partie de
vente.
I'ISO 9000 sont applicables au logiciel en situations
contractuelles lorsque
IS0 1001 1-1:1990, Lignes directrices pour l'audit des
- Partie 1: Audit.
systèmes qualité
a) le contrat requiert de façon spécifique un travail
de conception et que les exigences relatives au
produit sont formulées principalement en termes
de performances, ou qu'il est nécessaire de les
établir; 3 Définitions
b) la confiance dans le produit peut être obtenue par Pour les besoins de la présente partie de I'ISO 9000,
une démonstration appropriée de certaines aptitu-
les définitions données dans I'ISO 2382-1 et
des du fournisseur en matière de développement, I'ISO 8402 s'appliquent, conjointement avec les défi-
de mise à disposition et de maintenance. nitions suivantes.
1

---------------------- Page: 6 ----------------------
IS0 9000-3~1991 (F)
3.1 logiciel (traduction des termes anglais 4.1 .I .2 Organisation
usoftware)) et ((software product))): Création intellec-
tuelle comprenant les programmes, procédures, rè-
gles et toute documentation relatifs au
4.1 .I .2.1 Responsabilité et autorite
fonctionnement d'un ensemble de traitement des
données.
Les responsabilités, l'autorité et les relations de tou-
tes les personnes qui dirigent, effectuent et vérifient
[IS0 2382-1 :I 984, 01.04.041
des tâches qui ont une incidence sur la qualité, doi-
vent être définies; cela concerne, en particulier, les
NOTE 4 Un logiciel est indépendant du support sur lequel
personnes qui ont besoin de la liberté et de l'autorité
il est enregistré.
organisationnelle pour
3.2 produit logiciel: En français, le terme ((logiciel))
a) déclencher des actions permettant de prévenir
suffit, il n'est pas nécessaire d'introduire le terme
l'apparition de non-conformités relatives au pro-
((produit logiciel)).
duit;
3.3 constituant du logiciel: Toute partie de logiciel
b) identifier et enregistrer tout problème de qualité
identifiable à une étape intermédiaire ou à une étape
relatif au produit;
finale du développement.
c) susciter, recommander ou fournir des solutions
3.4 développement: Toutes les activités devant
par des circuits préétablis;
f
être effectuées pour créer un logiciel.
d) vérifier la mise en œuvre des solutions;
3.5 phase: Séquence définie d'activités.
e) maîtriser le traitement, la livraison ou l'installation
d'un produit non conforme jusqu'à ce que la défi-
5 Une phase n'implique ni l'emploi d'un modèle
NOTE
spécifique de cycle de vie, ni une période de temps durant cience ou la situation non satisfaisante ait été cor-
le développement d'un logiciel.
rigée.
[IS0 9001 :1987, 4.1.2.11
3.6 vérification (du logiciel): Processus d'évaluation
des produits d'une phase donnée pour s'assurer de
leur exactitude et leur cohérence vis-à-vis des pro-
4.1.1.2.2 Moyens et personnel pour les
duits et normes fournis en entrée de cette phase.
vérifications
3.7 validation (du logiciel): Processus d'évaluation
Le fournisseur doit identifier les besoins internes en
du logiciel pour s'assurer de la conformité aux exi-
matière de vérification, prévoir les moyens nécessai-
gences prescrites.
res et désigner des personnes formées pour les acti-
vités de vérification.
Les activités de Vérification doivent comprendre le (
contrdle, les essais et le pilotage des procédés eVou
du produit aux stades de la conception, de la produc-
4 Système qualité - Cadre
tion, de l'installation, et du soutien après la vente; les
revues de conception et les audits du système qua-
lité, des procédés ethou du produit doivent être ef-
fectués par des personnes indépendantes de celles
4.1 Responsabilité de la direction
qui ont une responsabilité directe vis-à-vis des tâches
effectuées.
4.1.1 Responsabilité de la direction du
[IS0 9001 :1987, 4.1 2.21
fournisseur
4.1.1.2.3 Représentant de la direction
4.1.1.1 Politique qualité
La direction du fournisseur doit, en matière de qualité, Le fournisseur doit désigner un représentant de la di-
définir et mettre par écrit sa politique, ses objectifs rection qui, nonobstant d'autres responsabilités, doit
et son engagement. Le fournisseur doit assurer que avoir une autorité et des responsabilités définies de
cette politique est comprise, mise en œuvre et façon à assurer que les exigences de I'ISO 9001 sont
entretenue à tous les niveaux de l'organisation. mises en œuvre de manière permanente.
[IS0 9001:1987, 4.1.11 [IS0 9001:1987, 4.1.2.33
2

---------------------- Page: 7 ----------------------
IS0 9000-3:1991 (F)
4.1.1.3 Revue de direction c) résultats des tests de réception.
II convient que les résultats de ces revues soient
Le système qualité adopté pour satisfaire aux exi-
agréés et documentés.
gences de I'ISO 9001 doit être examiné à intervalles
convenables par la direction du fournisseur afin d'as-
surer qu'il demeure constamment approprié et effi-
cace. Des enregistrements de telles revues doivent
4.2 Système qualité
être tenus en permanence.
4.2.1 Généralités
NOTE - Les revues de direction incluent nor-
malement une évaluation des résultats des audits
II est recommandé que le fournisseur établisse et
qualité internes, mais elles sont effectuées par ou
entretienne un système qualité documenté. II
pour le compte de la direction du fournisseur, c'est-
convient que le système quaiité soit un processus in-
à-dire des personnes de la direction qui sont direc-
tégré pendant tout le cycle de vie donnant ainsi I'as-
tement responsables du système.
surance que la qualité est construite au fur et à
[IS0 9001:1987, 4.1.31
mesure du développement, et pas seulement vérifiée
à la fin du processus, II est bon de mettre l'accent sur
la prévention plutôt que sur la résolution des difficul-
tés quand elles apparaissent.
4.1.2 Responsabilité de la direction de l'acheteur
(,
II est souhaitable que le fournisseur assure la mise en
II est recommandé que l'acheteur coopère avec le
œuvre réelle du système qualité tel qu'il a été docu-
fournisseur pour lui fournir toutes les informations
menté.
nécessaires en temps utile et résoudre les questions
en suspens.
II est souhaitable que l'acheteur nomme un repré-
4.2.2 Documentation du système qualité
sentant qui a la responsabilité de traiter avec le four-
nisseur des questions contractuelles. II est bon que
II est recommandé que tous les éléments, toutes les
ce représentant ait une délégation de pouvoir suffi-
exigences et dispositions contenus dans le système
sante pour prendre les engagements contractuels ce
qualité soient documentés de manière claire, ordon-
qui inclut, mais n'est pas limité, à
née et systématique.
a) définir les exigences de l'acheteur pour le fournis-
seur;
4.2.3 Plan qualit6
b) répondre aux questions du fournisseur;
II convient que le fournisseur prépare et établisse un
plan qualité pour prendre en compte les activités
c) approuver les propositions du fournisseur;
qualité pour chaque développement de logiciel selon
les fondements du système qualité et qu'il fasse en
d) conclure des accords avec le fournisseur;
sorte que ce plan soit compris et respecté par les or-
i
ganisations concernées.
e) s'assurer que l'organisation de l'acheteur respecte
les accords convenus avec le fournisseur;
f) définir les critères de réception et leurs procédu-
4.3 Audits internes du système qualité
res;
Audits qualité internes
g) reconnaître les constituants de logiciel dont
Le fournisseur doit mettre en œuvre un système
l'usage ne peut pas convenir.
complet d'audits internes programmés et documen-
tés pour contrôler que les activités relatives à la qua-
lité satisfont aux dispositions prévues et pour évaluer
4.1.3 Revues conjointes
l'efficacité du système qualité.
II est recommandé que les revues conjointes régu-
Les audits doivent être programmés en fonction de la
lières entre le fournisseur et l'acheteur soient pro-
nature et de l'importance de l'activité.
grammées afin de prendre en compte les aspects
suivants, si cela est approprié:
Les audits et leurs suivis doivent être effectués
conformément à des procédures documentées.
a) conformité du logiciel aux spécifications agréées
par l'acheteur; Les résultats des audits doivent être documentés et
portés à la connaissance des personnes qui ont la
responsabilité du domaine soumis à l'audit. Les res-
b) vérification des résultats;
3

---------------------- Page: 8 ----------------------
IS0 9000-3:1991 (F)
ponsables de ce domaine doivent engager des actions
5.2 Revues de contrat
correctives en temps utile pour remédier aux défi-
ciences trouvées lors de l'audit
5.2.1 Généralités
[IS0 9001:1987, 4.171
II est recommandé que le fournisseur établisse et
IS0 1001 1-1.
Voir tienne à jour des procédures de revue de contrat et
de coordination de ces activités.
II est bon que chaque contrat soit étudié par le four-
nisseur afin de s'assurer que
4.4 Action corrective
a) l'objet du contrat et ses exigences sont définis et
Le fournisseur doit établir, documenter et tenir à jour
documentés;
des procédures pour:
b) tous les facteurs aléatoires ou les risques sont
a) rechercher la cause de non-conformité du produit identifiés;
et l'action corrective nécessaire pour empêcher sa
réapparition; c) le secret industriel est protégé de façon adéquate;
d) toutes les exigences qui diffèrent de celles conte-
b) analyser tous les processus, les travaux, les déro-
gations, les comptes rendus qualité, les rapporfç
nues dans l'offre sont résolues;
internes et les réclamations du client pour détecter
et éliminer les causes potentielles de non-
e) le fournisseur a la capacité de satisfaire aux exi-
conformité d'un produit; gences contractuelles;
c) déclencher des actions préventives pour prendre f) la responsabilité du fournisseur est définie vis-à-vis
en compte les problèmes selon les risques en- des travaux sous-traités;
courus;
g) la terminologie est agréée par les deux parties;
d) contrôler que les actions correctives sont prises
et qu'elles sont efficaces; h) l'acheteur a la capacité de satisfaire aux obligations
contractuelles.
e) réaliser et enregistrer les modifications des procé-
II convient de tenir en permanence les enregis-
dures issues d'actions correctives.
trements de ces revues.
[IS0 9001:1987, 4.141
5.2.2 Éléments du contrat relatifs à la qualité
Les éléments suivants sont, entre autres, fréquem-
ment à prendre en compte dans le contrat:
5 Système qualité - Activités du cycle
a) critères de réception;
de vie
b) traitement des modifications apportées aux exi-
gences de l'acheteur au cours du développement;
.
5.1 Généralités
c) traitement des problèmes détectés après la ré-
ception, notamment les réclamations en matière
II est recommandé qu'un projet de développement de
de qualité et les plaintes des acheteurs;
logiciel soit organisé selon un modèle de cycle de vie.
II convient que les activités concernant la qualité
d) activités exécutées par l'acheteur et, plus spé-
soient planifiées et mises en œuvre selon la nature
cialement, rôle de l'acheteur en matière de défini-
du modèle de cycle de vie utilisé.
tion des spécifications des besoins, d'installation
La présente partie de I'ISO 9000 a pour but d'être et de réception;
appliquée indépendamment du modèle de cycle de
vie utilisé. Au cas où certaines descriptions, conseils,
e) moyens, outils et constituants de logiciel à fournir
exigences ou structures tendraient à faire croire le par l'acheteur;
contraire, cela serait involontaire et ne devrait pas être
interprété comme indiquant que les exigences ou les
f) normes et procédures à utiliser;
conseils sont limités à un modèle de cycle de vie en
particulier.
g) exigences de reproduction (voir 5.9).
4

---------------------- Page: 9 ----------------------
IS0 9000-3:1991(F)
5.3 Spécifications des besoins de l'acheteur b) l'organisation des ressources du projet, compre-
nant la structure de l'équipe de développement,
les responsabilités, les sous-traitants et
5.3.1 Généralités
l'infrastructure nécessaire;
Pour entreprendre le développement du logiciel, il est
c) les phases du développement (voir 5.4.2.1 1;
souhaitable que le fournisseur dispose d'un ensemble
complet et non ambigu d'exigences fonctionnelles.
d) le calendrier du projet identifiant les tâches à réa-
En outre, il convient que ces exigences incluent tous
liser, les ressources et le temps requis pour cha-
les aspects nécessaires pour satisfaire les besoins du
cune d'elles et leurs relations mutuelles;
client. Elles peuvent inclure, entre autres, les points
suivants: performance, sûreté, fiabilité, sécurité et
e) l'identification des plans associés tels que
confidentialité. II est recommandé d'exprimer ces
exigences de manière suffisamment précise pour
- plan qualité,
permettre la validation lors de la réception du produit.
- plan de gestion de configuration,
La spécification des besoins de l'acheteur est le do-
cument qui regroupe ces exigences. Dans certains
- plan d'intégration,
cas, ce document est fourni par l'acheteur. Sinon, il
est souhaitable que le fournisseur l'établisse en colla-
- plan de tests.
boration étroite avec l'acheteur, et que le fournisseur
obtienne l'accord de l'acheteur avant que ne soit
il est bon que le plan de développement soit tenu à
entrepris le développement. Faisant partie de la do-
jour durant le développement et que chaque phase
cumentation de développement, il convient d'assujet-
soit définie, comme indiqué en 5.4.2.1, avant que les
tir la spécification des besoins à la maîtrise de la
activités de cette phase ne soient lancées. II est sou-
documentation et à la gestion de configuration.
haitable de revoir et approuver le plan de dévelop-
II est recommandé que toutes les interfaces entre le
pement avant sa mise en œuvre.
logiciel et d'autres logiciels ou matériels soient en-
tièrement spécifiées, soit directement, soit par réfé-
5.4.2 Plan de développement
rence, dans la spécification des besoins de l'acheteur.
5.3.2 Coopération
5.4.2.1 Phases
Pendant le développement des spécifications des
II est recommandé que le plan de développement
exigences de l'acheteur, il est recommandé de porter
définisse un processus ou une méthodologie rigou-
une attention particulière aux points suivants:
reux pour la transformation des spécifications des
besoins du client en un logiciel. Cela peut nécessiter
a) désignation des personnes (des deux parties)
le partage du travail en phases et l'identification
ayant la responsabilité d'établir la spécification des
besoins de l'acheteur;
a) des phases de développement à effectuer;
b) méthodes pour obtenir l'accord sur les exigences
b) des éléments d'entrée de chaque phase;
et approuver des modifications;
c) des éléments de sortie de chaque phase;
c) actions visant à prévenir tout malentendu, telles
que définition des termes et explication du
d) des procédures de vérification à effectuer à la fin
contexte conduisant aux spécifications;
de chaque phase;
d) enregistrement et revues des résultats des
e) de l'analyse des problèmes potentiels liés aux
dicussions par les deux parties.
phases de développement et à la réalisation des
exigences spécifiées.
5.4 Planification du développement
5.4.2.2 Gestion
5.4.1 Généralités II est souhaitable que le plan de développement défi-
nisse comment le projet doit être géré, en identifiant
II est recommandé que le plan de développement entre autres
couvre les points suivants:
a) la planification du développement, la mise en
a) la définition du projet avec rappel des objectifs et œuvre et les livraisons associées;
les références aux projets correspondants du
client ou du fournisseur; b) la maîtrise de l'avancement des travaux;
5

---------------------- Page: 10 ----------------------
IS0 9000-3:1991(F)
c) les responsabilités organisationnelles et I'attribu- 5.4.6 Vérification de chaque phase
tion des tâches et des ressources;
II est bon que fournisseur établisse un plan de véri-
d) les interfaces organisationnelles et techniques en- fication de tous les éléments de sortie de chaque
tre les différents groupes.
phase de développement.
La vérification du développement devrait établir que
5.4.2.3 Méthodes et outils de développement
les éléments de sortie d'une phase de dévelop-
pement correspondent aux exigences d'entrée, par
II convient que le plan de développement précise les
des mesures de maîtrise du développement telles
méthodes permettant de s'assurer que toutes les ac-
que
tivités sont menées à bien. Ceci peut inclure entre
autres
a) mener des études de développement en des
points appropriés des phases de développement;
a) des règles, pratiques et conventions de dévelop-
pement;
b) comparer une nouvelle conception avec une con-
ception similaire éprouvée, s'il en existe;
b) des outils et techniques de développement;
c) entreprendre des tests et démonstrations.
c) la gestion de configuration.
II convient d'enregistrer les résultats de la vérification
5.4.3 Maîtrise de l'avancement
et toute autre action exigée pour s'assurer que les
exigences spécifiées sont satisfaites et de vérifier dès
II est recommandé que les revues d'avancement
que ces actions sont achevées. II est recommandé
soient planifiées, menées et documentées de façon
de soumettre à la gestion de configuration et d'ac-
à s'assurer que les problèmes de ressources restant
cepter pour une utilisation ultérieure seuls les élé-
en suspens sont résolus, et que les plans de déve-
ments de sortie vérifiés.
loppement sont correctement suivis.
5.4.4 Éléments d'entrée des phases de
développement
5.5 Plan qualité
II est souhaitable de définir et documenter les élé-
5.5.1 Généralités
ments d'entrée requis pour chaque phase de déve-
loppement. II est bon que chaque exigence soit
définie de façon permettant de vérifier sa satisfaction. Faisant partie de son plan de développement, il est
II est recommandé de résoudre les exigences incom- souhaitable que le fournisseur prépare un plan qualité.
plètes, ambiguës ou contradictoires avec les respon-
II est bon que le plan qualité soit mis à jour au fur et
sables qui les ont établies.
à mesure de l'avancement du développement et que
ce qui concerne une phase soit entièrement défini
5.4.5 Éléments de sortie des phases de
avant que celle-ci ne commence.
(
développement
II est recommandé que le plan qualité soit for-
II est recommandé de définir et documenter les élé-
mellement revu et accepté par toutes les organi-
ments de sortie requis pour chaque phase de déve-
sations concernées par sa mise en œuvre.
loppement. II convient que les éléments de sortie de
chaque phase de développement soient vérifiés et
5.5.2) peut
Le document qui décrit le plan qualité (voir
qu'ils
être un document indépendant (intitulé plan qualité)
ou une partie d'un autre document, ou composé de
a) satisfassent aux exigences spécifiées applicables;
plusieurs documents, y compris le plan de dévelop-
pement.
b) contiennent ou référencent les critères de récep-
tion permettant de passer aux phases ultérieures;
5.5.2 Contenu du plan qualité
c) soient conformes aux pratiques et conventions de
II est souhaitable que les points suivants soient spé-
développement, rappelées ou non dans les élé-
cifiés ou référencés dans le plan qualité:
ments d'entrée;
a) les objectifs qualité, exprimés en termes mesu-
d) identifient les caractéristiques qui
...