Software engineering - Systems and software Quality Requirements and Evaluation (SQuaRE) - Requirements for quality of Ready to Use Software Product (RUSP) and instructions for testing

ISO/IEC 25051:2014 establishes: quality requirements for Ready to Use Software Product (RUSP); requirements for test documentation for the testing of RUSP, including test plan, test description, and test results; instructions for conformity evaluation of RUSP. It includes also recommendations for safety or business critical RUSP. ISO/IEC 25051:2014 deals only with providing the user with confidence that the RUSP will perform as offered and delivered. It does not deal with the production realization (including activities and intermediate products, e.g. specifications). The quality system of a supplier is outside the scope of ISO/IEC 25051:2014.

Ingénierie du logiciel — Exigences de qualité pour le logiciel et son évaluation (SQuaRE) — Exigences de qualité pour les progiciels et instructions d'essai

L'ISO/IEC 25051:2014 définit: des exigences qualité relatives aux progiciels; des exigences relatives à la documentation de test des progiciels, incluant le plan des tests, leur description et leurs résultats; des instructions pour l'évaluation de la conformité des progiciels. Elle comporte également des recommandations à propos des progiciels critiques pour les entreprises et la sécurité. L'ISO/IEC 25051:2014 a pour unique objet de donner à l'utilisateur l'assurance que la mise en ?uvre du progiciel répondra à ce qui été proposé et fourni. Elle ne traite pas de la réalisation de son développement (ni des activités ou des produits intermédiaires, tels que les spécifications). Le système qualité d'un fournisseur ne relève pas du domaine de l'ISO/IEC 25051:2014.

General Information

Status
Published
Publication Date
04-Feb-2014
Current Stage
9060 - Close of review
Completion Date
02-Dec-2030

Relations

Effective Date
23-Feb-2012

Overview - ISO/IEC 25051:2014 (SQuaRE) for RUSP

ISO/IEC 25051:2014 specifies quality requirements and testing instructions for Ready to Use Software Product (RUSP) as part of the SQuaRE family (Systems and software Quality Requirements and Evaluation). The standard defines what information suppliers should provide (product description and user documentation), sets quality requirements for the delivered software, and prescribes the test documentation needed to demonstrate conformity. It focuses on giving users confidence that a packaged software product will perform as advertised; it does not address supplier quality systems or internal production processes.

Key topics and technical requirements

  • Product description requirements: information on product identification, capabilities and environmental/configuration needs so acquirers can assess suitability before purchase.
  • User documentation requirements: installation, configuration, operation and maintenance instructions required to use the RUSP.
  • Quality requirements for software: properties aligned with the SQuaRE/ISO 25010 model (functional suitability, reliability, usability, performance, security, maintainability, etc.).
  • Test documentation requirements: mandatory test plan, test descriptions and test results that together prove the product meets its advertised properties.
  • Conformity evaluation instructions: guidance on preparing, conducting and reporting conformity evaluation activities (including prerequisites and follow‑up).
  • Handling of anomalies: anomalies found during testing must be documented and resolved prior to release, or advertised claims must be removed; known negligible anomalies may be recorded for later improvement.
  • Guidance for critical use: Annex A offers recommendations for business‑ or safety‑critical applications (informative, not prescriptive).

Practical applications and intended users

ISO/IEC 25051 is practical for organizations that:

  • Suppliers - to specify, document and validate RUSP quality and to prepare declarations of conformity or certification submissions.
  • Testing laboratories and certification bodies - to design and execute test plans and produce compliance reports.
  • Accreditation bodies and regulators - to adopt consistent evaluation criteria for packaged software in critical contexts.
  • Acquirers and end users - to compare product descriptions and certified claims when selecting packaged or commercial off‑the‑shelf software (COTS).
  • Organizations - building management and procurement processes around software quality requirements.

Related standards

  • ISO/IEC 25000 (Guide to SQuaRE)
  • ISO/IEC 25010 (System and software quality models)
    ISO/IEC 25051 is part of the broader SQuaRE series and is intended to be used alongside these standards for consistent software quality evaluation.

Keywords: ISO/IEC 25051, RUSP, SQuaRE, Ready to Use Software Product, software quality, conformity evaluation, test documentation, product description, user documentation.

Standard

ISO/IEC 25051:2014 - Software engineering -- Systems and software Quality Requirements and Evaluation (SQuaRE) -- Requirements for quality of Ready to Use Software Product (RUSP) and instructions for testing

English language
33 pages
sale 15% off
Preview
sale 15% off
Preview
Standard

ISO/IEC 25051:2014 - Ingénierie du logiciel -- Exigences de qualité pour le logiciel et son évaluation (SQuaRE) -- Exigences de qualité pour les progiciels et instructions d'essai

French language
34 pages
sale 15% off
Preview
sale 15% off
Preview

Frequently Asked Questions

ISO/IEC 25051:2014 is a standard published by the International Organization for Standardization (ISO). Its full title is "Software engineering - Systems and software Quality Requirements and Evaluation (SQuaRE) - Requirements for quality of Ready to Use Software Product (RUSP) and instructions for testing". This standard covers: ISO/IEC 25051:2014 establishes: quality requirements for Ready to Use Software Product (RUSP); requirements for test documentation for the testing of RUSP, including test plan, test description, and test results; instructions for conformity evaluation of RUSP. It includes also recommendations for safety or business critical RUSP. ISO/IEC 25051:2014 deals only with providing the user with confidence that the RUSP will perform as offered and delivered. It does not deal with the production realization (including activities and intermediate products, e.g. specifications). The quality system of a supplier is outside the scope of ISO/IEC 25051:2014.

ISO/IEC 25051:2014 establishes: quality requirements for Ready to Use Software Product (RUSP); requirements for test documentation for the testing of RUSP, including test plan, test description, and test results; instructions for conformity evaluation of RUSP. It includes also recommendations for safety or business critical RUSP. ISO/IEC 25051:2014 deals only with providing the user with confidence that the RUSP will perform as offered and delivered. It does not deal with the production realization (including activities and intermediate products, e.g. specifications). The quality system of a supplier is outside the scope of ISO/IEC 25051:2014.

ISO/IEC 25051:2014 is classified under the following ICS (International Classification for Standards) categories: 35.080 - Software. The ICS classification helps identify the subject area and facilitates finding related standards.

ISO/IEC 25051:2014 has the following relationships with other standards: It is inter standard links to ISO/IEC 25051:2006. Understanding these relationships helps ensure you are using the most current and applicable version of the standard.

You can purchase ISO/IEC 25051:2014 directly from iTeh Standards. The document is available in PDF format and is delivered instantly after payment. Add the standard to your cart and complete the secure checkout process. iTeh Standards is an authorized distributor of ISO standards.

Standards Content (Sample)


INTERNATIONAL ISO/IEC
STANDARD 25051
Second edition
2014-02-15
Software engineering — Systems and
software Quality Requirements and
Evaluation (SQuaRE) — Requirements
for quality of Ready to Use Software
Product (RUSP) and instructions for
testing
Ingénierie du logiciel — Exigences de qualité et évaluation des
systèmes et du logiciel (SQuaRE) — Exigences de qualité pour les
progiciels et instructions d’essai
Reference number
©
ISO/IEC 2014
© ISO/IEC 2014
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized otherwise in any form
or by any means, electronic or mechanical, including photocopying, or posting on the internet or an intranet, without prior
written permission. Permission can be requested from either ISO at the address below or ISO’s member body in the country of
the requester.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.org
Web www.iso.org
Published in Switzerland
ii © ISO/IEC 2014 – All rights reserved

Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Conformance . 2
3 Normative references . 2
4 Terms, definitions and abbreviated terms . 3
4.1 Terms and definitions . 3
4.2 Abbreviated termss . 6
5 Requirements for Ready to Use Software Product (RUSP) . 6
5.1 Requirements for product description. 6
5.2 Requirements for user documentation .11
5.3 Quality requirements for software .15
6 Requirements for test documentation .19
6.1 General Requirements .19
6.2 Requirements for the test plan .21
6.3 Requirements for the testing description .22
6.4 Requirements for the test results .23
7 Instructions for conformity evaluation .24
7.1 General Principles .24
7.2 Conformity evaluation pre-requisites .24
7.3 Conformity evaluation activities .25
7.4 Conformity evaluation process .25
7.5 Conformity evaluation report .25
7.6 Follow up conformity evaluation .26
Annex A (informative) Guidance for Ready to Use Software Product (RUSP) evaluation in business
or safety critical applications .27
Annex B (informative) How to use ISO/IEC 25051 .31
Bibliography .32
© ISO/IEC 2014 – All rights reserved iii

Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are
members of ISO or IEC participate in the development of International Standards through technical
committees established by the respective organization to deal with particular fields of technical
activity. ISO and IEC technical committees collaborate in fields of mutual interest. Other international
organizations, governmental and non-governmental, in liaison with ISO and IEC, also take part in the
work. In the field of information technology, ISO and IEC have established a joint technical committee,
ISO/IEC JTC 1.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of the joint technical committee is to prepare International Standards. Draft International
Standards adopted by the joint technical committee are circulated to national bodies for voting.
Publication as an International Standard requires approval by at least 75 % of the national bodies
casting a vote.
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. ISO and IEC shall not be held responsible for identifying any or all such patent rights.
ISO/IEC 25051 was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology,
Subcommittee SC 7, Software and systems engineering. This second edition cancels and replaces the first
edition (ISO/IEC 25051:2006), which has been technically revised. It also incorporates the Technical
Corrigendum ISO/IEC 25051:2006/Cor.1:2007.
The main changes are as follows:
— English and French titles corrected;
— modification of RUSP definition, scope and examples;
— harmonization with the current SQuaRE series.
ISO/IEC 25051 is a part of the SQuaRE series of International Standards, which consists of the following
divisions:
— Quality Management Division (ISO/IEC 2500n);
— Quality Model Division (ISO/IEC 2501n);
— Quality Measurement Division (ISO/IEC 2502n);
— Quality Requirements Division (ISO/IEC 2503n);
— Quality Evaluation Division (ISO/IEC 2504n);
— Extension Division (ISO/IEC 25050: – ISO/IEC 25099).
iv © ISO/IEC 2014 – All rights reserved

Introduction
Ready to Use Software Product (RUSP) are used in an increasingly wide variety of application areas and
their correct operation is often vital for business, safety and personal applications.
Ready to Use Software Product (RUSP) are packages sold to the acquirer who had no influence on
its features and other qualities. Typically the software is sold pre-wrapped or downloaded via web
store with its user documentation. A software product, which a user can use anytime thorough Cloud
Computing may be considered as RUSP. The information provided on the cover of the package or the
supplier website is often the only means whereby the manufacturer or marketing organization can
communicate with the acquirer and user. It is therefore important that essential information is given to
enable acquirers to evaluate the quality of the Ready to Use Software Product (RUSP) for their needs.
Selecting high quality Ready to Use Software Product (RUSP) is of prime importance, because Ready to
Use Software Product (RUSP) may have to be operational in various environments and selected without
the opportunity to compare performance among similar products. Suppliers need a way to ensure
confidence in services given by the Ready to Use Software Product (RUSP) to the users. Some suppliers
may choose a conformity evaluation group for evaluation or certification to assist them in providing this
confidence.
In addition, when users require assurances that business or safety critical risks are involved, those
assurances may need to be addressed by the user using techniques chosen by the user after the purchase.
It is not the intent of this International Standard to specify minimum safety or business critical quality
requirements for RUSP; however, informative guidance is given. (See Annex A.)
ISO/IEC 25051:2006 was developed based on ISO/IEC 9126-1:2001 and replaced ISO/IEC 12119:1994.
This second edition of ISO/IEC 25051 is a revision of ISO/IEC 25051:2006, in order to conform to
ISO/IEC 25010:2011, which replaced ISO/IEC 9126-1:2001 quality model.
These items are the major points for revising this International Standard, which provides a set of
requirements for Ready to Use Software Product (RUSP) and requirements for testing a Ready to Use
Software Product (RUSP) against its requirements.
© ISO/IEC 2014 – All rights reserved v

INTERNATIONAL STANDARD ISO/IEC 25051:2014(E)
Software engineering — Systems and software Quality
Requirements and Evaluation (SQuaRE) — Requirements
for quality of Ready to Use Software Product (RUSP) and
instructions for testing
1 Scope
This International Standard is applicable to Ready to Use Software Product (RUSP).
In this International Standard, the term “RUSP” is used as an adjective and stands for “Ready to Use
Software Product”.
NOTE 1 Examples of Ready to Use Software Product (RUSP) include but are not limited to text processors,
spreadsheets, database control software, graphics packages, software for technical, scientific or real-time
embedded functions, human resources management software, sales management, smartphone application,
freeware and web software such as generators of websites/pages.
NOTE 2 Open source software is not part of Ready to Use Software Product (RUSP).
This International Standard establishes:
a) Quality requirements for Ready to Use Software Product (RUSP);
b) Requirements for test documentation for the testing of Ready to Use Software Product (RUSP),
including test plan, test description, and test results;
NOTE The collection of documents for test is called “test documentation”.
c) Instructions for conformity evaluation of Ready to Use Software Product (RUSP).
It includes also recommendations for safety or business critical Ready to Use Software Product (RUSP).
This International Standard deals only with providing the user with confidence that the Ready to Use
Software Product (RUSP) will perform as offered and delivered. It does not deal with the production
realization (including activities and intermediate products, e.g. specifications). The quality system of a
supplier is outside the scope of this International Standard.
The intended users of this International Standard include:
a) suppliers when:
1) specifying requirements for a Ready to Use Software Product (RUSP);
2) assessing their own software products against the claimed performance;
3) issuing declarations of conformity (ISO/IEC 17050);
4) applying for certificates or marks of conformity (ISO/IEC Guide 23);
b) certification bodies that may wish to establish a certification scheme (international, regional or
national) (ISO/IEC Guide 28);
c) testing laboratories which will have to follow the instructions for testing when testing for a
certificate or a mark of conformity (ISO/IEC 17025);
d) accreditation bodies for accrediting registration or certification bodies and testing laboratories;
© ISO/IEC 2014 – All rights reserved 1

e) potential acquirers who may:
1) compare the requirements for the intended work task with the information in product
descriptions of existing software products;
2) look for certified Ready to Use Software Product (RUSP);
3) check if the requirements are otherwise met;
f) end users who may profit from better software products;
g) organizations:
1) establishing management and engineering environments based on the quality requirements
and methods of this International Standard; and
2) managing and improving their quality processes “and personnel”.
h) regulatory authorities who may require or recommend the requirements of this International
Standard for Ready to Use Software Product (RUSP) used in safety or business-critical applications.
2 Conformance
A Ready to Use Software Product (RUSP) conforms to this International Standard if:
a) it has the properties specified in Clause 5;
b) it has been tested by producing test documentation that meets the requirements of Clause 6;
c) anomalies found during testing are documented and resolved prior to product release. Anomalies
against advertised performance claims must be fixed or the performance claim must be removed.
Known anomalies may be considered acceptable if:
1) the anomaly is not a violation of a performance claim; and
2) the supplier has duly considered the nature and the impact of the anomaly on the potential
acquirer and deemed it negligible, and has preserved the documentation of the anomalies for
future improvement.
Clause 7 and Annex A are optional.
NOTE To facilitate the conformity evaluation, requirements of the present standard are drafted in a way
that they are level 3 subclauses (numbered X.X.X.X). Informative notes complete these clauses and can serve as a
guide.
3 Normative references
The following documents, in whole or in part, are normatively referenced in this document and are
indispensable for its application. For dated references, only the edition cited applies. For undated
references, the latest edition of the referenced document (including any amendments) applies.
ISO/IEC 25000, Systems and software engineering — Systems and software Quality Requirements and
Evaluation (SQuaRE) — Guide to SQuaRE
ISO/IEC 25010, Systems and software engineering — Systems and software Quality Requirements and
Evaluation (SQuaRE) — System and software quality models
2 © ISO/IEC 2014 – All rights reserved

4 Terms, definitions and abbreviated terms
4.1 Terms and definitions
For the purposes of this document, the following terms and definitions apply:
4.1.1
acquirer
stakeholder that acquires or procures a product or service from a supplier
Note 1 to entry: The acquirer could be one of the following: buyer, customer, owner, purchaser.
[SOURCE: ISO/IEC 12207:2008]
4.1.2
anomaly
any condition that deviates from expectations based on requirements specifications, design documents,
standards, etc. or from someone’s perceptions or experiences
[SOURCE: IEEE Std 1044-2009]
4.1.3
application administration function
functions performed by users which include installation, configuration, application backup, maintenance
(patching and upgrading) and uninstallation
4.1.4
conformity evaluation
systematic examination of the extent to which a product, process or service fulfils specified requirements
[SOURCE: ISO/IEC Guide 2:2004]
4.1.5
conformity evaluation report
document that describes the conduct and results of the evaluation carried out for a Ready to Use Software
Product (RUSP)
Note 1 to entry: This was adapted from IEEE Std 610.12–1990.
4.1.6
Ready to Use Software Product
RUSP
software product available for any user, at cost or not, and use without the need to conduct development
activities
Note 1 to entry: Ready to Use Software Product (RUSP) includes:
— the product description (including all cover information, data sheet, website information, etc.),
— the user documentation (necessary to install and use the software), including any configurations of the
operating system/s or target computer required to operate the product,
— the software contained on a computer sensible media (disk, CD-ROM, internet downloadable, etc.).
Note 2 to entry: Software is mainly composed of programs and data.
Note 3 to entry: This definition applies also to product description, user documentation and software which are
produced and supported as separate manufactured goods, but for which typical commercial fees and licensing
considerations may not apply.
© ISO/IEC 2014 – All rights reserved 3

4.1.7
end user
individual person who ultimately benefits from the Ready to Use Software Product functionalities
Note 1 to entry: The end user may be a regular operator of the software product or a casual user such as a member
of the public.
[SOURCE: ISO/IEC 25000:2005]
4.1.8
fault
incorrect step, process, or data definition in a computer program
[SOURCE: IEEE Std 610.12-1990]
4.1.9
maintenance
process of modifying a software system or component after delivery to correct faults, improve
performance or others attributes, or adapt to a changed environment
[SOURCE: IEEE Std 610.12-1990]
4.1.10
pass/fail criteria
decision rules used to determine whether a software item or a software feature passes or fails a test
[SOURCE: IEEE Std 829.12-1998]
4.1.11
product description
document stating properties of software, with the main purpose of helping potential acquirers in the
evaluation of the suitability for themselves of the software before purchasing it
4.1.12
product identification
software product name, version, variant, and date information
4.1.13
requirements document
document containing any combination of requirements or regulations to be met by a Ready to Use
Software Product (RUSP)
Note 1 to entry: These documents may be technical reports, standards, requirements list (or model requirements
specification) for a kind of user, or a statute or regulation imposed by a governing or regulatory body.
4.1.14
software function
implementation of an algorithm in the software with which the end user or the software can perform
part or all of a work task
Note 1 to entry: A function does not need to be callable by the end user (e.g. automatic backup or saving of data).
4.1.15
software test environment
facilities, hardware, software, firmware, procedures, and documentation needed to perform qualification
or other testing of software
[SOURCE: ISO/IEC/IEEE 24765:2010]
4 © ISO/IEC 2014 – All rights reserved

4.1.16
supplier
organization or individual that enters into an agreement with the acquirer for the supply of a product
or service
Note 1 to entry: The “supplier” could be a contractor, producer, seller, or vendor.
Note 2 to entry: Sometimes the acquirer and the supplier are part of the same organization.
[SOURCE: ISO/IEC 12207:2008]
4.1.17
test
activity in which a system or component is executed under specified conditions, the results are observed
or recorded, and an evaluation is made of some aspect of the system or component
[SOURCE: IEEE Std 610.12-1990]
4.1.18
test case
set of inputs, execution conditions, and expected results developed for a particular objective, such as
exercise a particular program path or to verify compliance with a specific requirement
[SOURCE: IEEE Std 610.12-1990]
4.1.19
test documentation
collection of the documentation inherent to the testing activities
4.1.20
test objective
identified set of software characteristics to be measured under specified conditions by comparing
actual behaviour with the required behaviour
Note 1 to entry: This was adapted from IEEE Std 610.12–1990.
4.1.21
test plan
document describing the scope, approach, resources, and schedule of intended testing activities
Note 1 to entry: This was adapted from IEEE Std 610.12–1990.
4.1.22
test procedure
detailed instructions for the set-up, execution, and evaluation of results for a given test case
[SOURCE: IEEE Std 610.12-1990]
4.1.23
testing
process of operating a system or component under specified conditions, observing or recording the
results, and making an evaluation of some aspect of the system or component
[SOURCE: IEEE Std 610.12-1990]
4.1.24
testing description
description of the test execution conditions (i.e. test procedure)
© ISO/IEC 2014 – All rights reserved 5

4.1.25
user
individual or group that benefits from a RUSP during its utilization
Note 1 to entry: The role of user and the role of operator may be vested, simultaneously or sequentially, in the
same individual or organization.
[SOURCE: ISO/IEC 12207:2008]
4.1.26
user documentation
information that is supplied with the software to help the user in their use of that software
4.2 Abbreviated termss
RUSP Ready to Use Software Product
CM Configuration Management
SQA Software Quality Assurance
SQC Software Quality Control
5 Requirements for Ready to Use Software Product (RUSP)
5.1 Requirements for product description
NOTE The paragraph concerning the Cover information of ISO/IEC 9127 Software engineering – User
documentation and cover information for consumer software package can be used as input for creating a product
description.
5.1.1 Availability
5.1.1.1 The product description shall be available for potential acquirers and users of the product.
5.1.2 Contents
5.1.2.1 The product description should declare the quality characteristics during operating the
software.
5.1.2.2 The product description shall contain information needed by potential acquirers to evaluate the
suitability of the software for their needs.
5.1.2.3 The product description shall be free from internal inconsistences.
5.1.2.4 The statements included in the product description shall be testable or verifiable.
5.1.3 Identification and indications
5.1.3.1 The product description shall display a unique identification.
5.1.3.2 The Ready to Use Software Product (RUSP) shall be designated by its product identification.
6 © ISO/IEC 2014 – All rights reserved

5.1.3.3 The product description shall contain the name and address (postal or web) of the supplier and,
if applicable, of the sellers, e-commerce sellers or distributors.
5.1.3.4 The product description shall identify the intended work tasks and services that can be
performed with the software.
5.1.3.5 The product description shall identify the requirements documents when the supplier wants
to claim conformity to documents defined by a law or by a regulatory body that affects the Ready to Use
Software Product (RUSP).
5.1.3.6 The product description shall state whether support for operating the Ready to Use Software
Product (RUSP) is offered or not.
5.1.3.7 The product description shall state whether maintenance is offered or not. If offered, the product
description shall describe the maintenance services offered.
5.1.4 Mapping
5.1.4.1 All functions mentioned in the product description shall be classified according to the quality
requirements for software characteristics (5.3.2 to 5.3.9).
5.1.5 Product quality - Functional suitability
5.1.5.1 The product description shall contain, as applicable, statements on Functional suitability, taking
into account functional completeness, functional correctness and functional appropriateness, written
such that verifiable evidence of compliance can be demonstrated, based on ISO/IEC 25010.
5.1.5.2 The product description shall provide an overview of end user callable functions of the product.
5.1.5.3 The product description shall describe all functions which the user may be encountered critical
defects.
NOTE 1 Critical defects may be:
— data loss;
— deadlock.
NOTE 2 Refer to ISO/IEC 15026 for more information.
5.1.5.4 The product description shall describe all known limitation that the user may encounter.
NOTE These limitations may be:
— minimum or maximum values;
— lengths of keys;
— maximum number of records in a file;
— maximum number of search criteria;
— minimum sample size.
5.1.5.5 If there are options and versions for software components, they shall be indicated without
ambiguity
© ISO/IEC 2014 – All rights reserved 7

5.1.5.6 If prevention of unauthorized access, whether inadvertent or deliberate, to the software is
provided, the product description shall include this information.
5.1.6 Product quality - Performance efficiency
5.1.6.1 The product description shall include statements of Performance efficiency, taking into account
Time behaviour, Resource utilization and Capacity, written such that verifiable evidence of compliance
can be demonstrated, based on ISO/IEC 25010.
5.1.6.2 All known conditions to Performance efficiency shall be described.
NOTE Stated conditions may be:
— system configurations;
— resources needed for efficient working with the Ready to Use Software Product (RUSP), e.g. bandwidth, hard
disk space, RAM, video card, wireless network card, CPU speed, etc.
5.1.6.3 The product description shall describe the capacity of the systems, which is particularly relevant
to computer systems.
5.1.7 Product quality - Compatibility
5.1.7.1 The product description shall contain, as applicable, statements on Compatibility, taking into
account Co-existence and Interoperability, written such that verifiable evidence of compliance can be
demonstrated, based on ISO/IEC 25010.
5.1.7.2 The product description shall indicate where the Ready to Use Software Product (RUSP) relies
on specific software and/or hardware with appropriate references.
NOTE The reference may include:
— name of software and/or hardware (Server, Platform, etc…);
— version;
— specific operating system.
5.1.7.3 The product description shall identify user callable interfaces and the related called software.
5.1.8 Product quality - Usability
5.1.8.1 The product description shall contain, as applicable, statements on Usability, taking into account
Appropriateness recognizability, Learnability, Operability, User error protection, User interface aesthetics
and Accessibility, written such that verifiable evidence of compliance can be demonstrated, based on
ISO/IEC 25010.
5.1.8.2 The product description shall specify the type of user interface.
NOTE These interfaces may be:
— command line;
— menu;
— window;
— function key;
8 © ISO/IEC 2014 – All rights reserved

5.1.8.3 The product description shall specify the specific knowledge required for the use and operation
of the software.
NOTE They can be:
— knowledge of the database calls and protocol used;
— knowledge of a technical area;
— knowledge of an operating system;
— knowledge obtainable by special training;
— knowledge of a language other than that in which the product description is written.
5.1.8.4 The product description shall describe functions to protect user from error operation, if
applicable.
5.1.8.5 The product description shall state technical protection against copyright infringement that can
hamper usability, if applicable.
NOTE These protections may be:
— programmed expiry dates for usage;
— interactive reminders to pay for copies.
5.1.8.6 The product description shall include provision for accessibility, particularly for users with
disabilities and language differences.
5.1.9 Product quality - Reliability
5.1.9.1 The product description shall contain, as applicable, statements on Reliability, taking into
account Maturity, Availability, Fault tolerance and Recoverability, written such that verifiable evidence of
compliance can be demonstrated, based on ISO/IEC 25010.
NOTE No statement claiming reliability should be made unless the developer can substantiate the claim with
in-service data or other verifiable data.
5.1.9.2 The product description shall address the ability of the software to continue operating (i.e. to
be available) in the case of user interface errors, errors in the application’s own logic, or errors due to
availability of system or network resources.
5.1.9.3 The product description shall include information on data saving and restoring procedures.
NOTE An indication affirming that data backup may be executed by functions of the operating system is
acceptable.
5.1.10 Product quality - Security
5.1.10.1 The product description shall contain, as applicable, statements on Security, taking into account
Confidentiality, Integrity, Non-repudiation, Accountability and Authenticity, written such that verifiable
evidence of compliance can be demonstrated, based on ISO/IEC 25010.
© ISO/IEC 2014 – All rights reserved 9

5.1.11 Product quality - Maintainability
5.1.11.1 The product description shall contain, as applicable, statements on Maintainability, taking into
account Modularity, Reusability, Analysability, Modifiability and Testability, written such that verifiable
evidence of compliance can be demonstrated, based on ISO/IEC 25010.
5.1.11.2 The product description shall include information on maintenance for the user.
NOTE Information may be:
— monitoring on-going dynamic performance of the app;
— monitoring unexpected failures and significant conditions;
— monitoring operational indicators such as logs, alert screens;
— monitoring local data which are operated upon by the application.
5.1.11.3 If the user can adapt the software, then the tools or procedures for this adaptation and the
conditions of their use shall be identified.
NOTE Conditions can be:
— changing of parameters;
— changing of algorithms for computation;
— interface customization;
— assignments to function keys.
5.1.12 Product Quality - Portability
5.1.12.1 The product description shall contain, as applicable, statements on Portability, taking into
account Adaptability, Installability and Replaceability, written such that verifiable evidence of compliance
can be demonstrated, based on ISO/IEC 25010.
5.1.12.2 The product description shall specify the different configurations or supported configurations
(hardware, software) for putting the software into use.
NOTE 1 Different configurations may be specified, e.g. for different work tasks, different boundary values or
different efficiency requirements.
NOTE 2 These systems may be:
— operating systems;
— processing unit including co-processors;
— main memory size;
— types and sizes of peripheral storage;
— extension cards;
— input and output equipment;
— network environment;
— system software and other software.
5.1.12.3 The product description shall provide information on the installation procedure.
10 © ISO/IEC 2014 – All rights reserved

5.1.13 Quality in use - Effectiveness
5.1.13.1 The product description shall contain, as applicable, statements on quality in use Effectiveness
written such that verifiable evidence of compliance can be demonstrated, based on ISO/IEC 25010.
5.1.13.2 The product description shall specify any product compliance reference for users to achieve
specific goals.
5.1.14 Quality in use - Efficiency
5.1.14.1 The product description shall contain, as applicable, statements on quality in use Efficiency
written such that verifiable evidence of compliance can be demonstrated, based on ISO/IEC 25010.
5.1.14.2 The product description shall indicate whether the Ready to Use Software Product (RUSP) is
intended for multiple concurrent end users or for a single end user on a single system, and shall state
the maximum number of concurrent end users feasible at a stated level of performance on the required
system.
5.1.14.3 The product description shall contain information on resources needed for user to achieve
specific goals.
5.1.15 Quality in use - Satisfaction
5.1.15.1 The product description shall contain, as applicable, statements on quality in use Satisfaction,
taking into account Usefulness, Trust, Pleasure and Comfort, written such that verifiable evidence of
compliance can be demonstrated, based on ISO/IEC 25010.
5.1.15.2 The product description shall contain a specific supplier contact for satisfaction guaranty on the
use of the product.
5.1.16 Freedom from risk
5.1.16.1 The product description shall contain, as applicable, statements on quality in use Freedom
from risk, taking into account Economic risk mitigation, Health and safety risk mitigation, Environmental
risk mitigation, written such that verifiable evidence of compliance can be demonstrated, based on
ISO/IEC 25010.
5.1.16.2 The product description shall contain the non-disclosure information in case of known risk due
to the use of the software or the need of specifics trainings.
5.1.17 Context coverage
5.1.17.1 The product description shall contain, as applicable, statements on quality in use Context
coverage, taking into account Context completeness and Flexibility, written such that verifiable evidence
of compliance can be demonstrated, based on ISO/IEC 25010.
5.1.17.2 When the product description contains compliance information, the coverage of such compliance
shall be clearly indicated.
5.2 Requirements for user documentation
NOTE The paragraph concerning the Cover information of ISO/IEC 9127 Software engineering – User
documentation and cover information for consumer software package can be used as input for creating user
documentation.
© ISO/IEC 2014 – All rights reserved 11

5.2.1 Availability
5.2.1.1 The user documentation shall be available for users of the product.
5.2.2 Contents
5.2.2.1 The functions included in the user documentation shall be testable or verifiable.
5.2.3 Identification and indications
5.2.3.1 The user documentation shall display a unique identification.
5.2.3.2 The Ready to Use Software Product (RUSP) shall be designated by product identification.
5.2.3.3 The user documentation shall contain the name and address (postal or web) of the supplier.
5.2.3.4 The user documentation shall identify the intended work tasks and services that can be
performed with the software.
5.2.4 Completeness
5.2.4.1 The user documentation shall contain the information necessary for the use of the software.
5.2.4.2 The user documentation shall describe all the functions stated in the product description and
all the functions that can be called by the end user.
5.2.4.3 The user documentation shall list the errors and defects that are handled and cause application
failure or termination, particularly, those conditions ending in application termination which end in loss
of data.
5.2.4.4 The user documentation shall give guidance to backup and restoration of the necessary data.
5.2.4.5 The user documentation shall provide complete instructional and reference information for all
critical software functions (software whose failure could have an impact on safety, or could cause large
financial or social loss).
NOTE See Annex A for more information.
5.2.4.6 The user documentation shall state the minimum required disk space for installation.
5.2.4.7 The user documentation shall include all information necessary for user performed application
administration functions.
NOTE example of information:
— Information allowing the user to verify the successful completion of application administration functions.
5.2.4.8 If the user documentation is provided in several parts, at least one item in the set shall identify
all the parts.
5.2.5 Correctness
5.2.5.1 All information in the user documentation shall be adequate for the main targeted users.
12 © ISO/IEC 2014 – All rights reserved

NOTE All information in the user documentation should be traceable to an authoritative source for
correctness.
5.2.5.2 The user documentation shall present the information free from ambiguities.
5.2.6 Consistency
5.2.6.1 The documents of the user documentation shall be free from contradiction within themselves,
with each other, and with the product description.
5.2.7 Understandability
5.2.7.1 The user documentation shall be understandable by the end user population for which the Ready
to Use Software Product (RUSP) is primarily targeted by using terminology and style understandable by
its specialized audience.
5.2.7.2 Understanding of the user documentation shall be facilitated by an organized document list.
5.2.8 Product quality – Functional suitability
5.2.8.1 The user documentation shall state all limitations given in the product description.
5.2.9 Product quality – Compatibility
5.2.9.1 The user documentation shall provide the necessary information to identify the compatibility
to use the software.
5.2.9.2 The user documentation shall indicate where the Ready to Use Software Product (RUSP) relies
on specific software and/or hardware with appropriate references.
NOTE The reference may include:
— name of software and/or hardware;
— version;
— specific operating system.
5.2.9.3 If the user documentation makes reference to known user callable interfaces to other software,
these interfaces or software shall be identified.
5.2.10 Product quality – Usability/Learnability
5.2.10.1 The user documentation shall provide the information necessary to learn how to use the
software.
NOTE the user documentation may reference additional information contained within the Ready to Use
Software Product (RUSP) itself, or within auxiliary materials such as training.
5.2.11 Product quality – Usability/Operability
5.2.11.1 If user documentation is not provided in printed form, the documentation shall indicate whether
it can be printed, and if so, how to obtain a printed copy.
© ISO/IEC 2014 – All rights reserved 13

5.2.11.2 User documentation other than cards and quick reference guides shall have a table of contents,
or list of topics, and an index.
5.2.11.3 The user documentation shall define terms and acronyms giving definitions necessary for the
understanding of certain terms used in the document.
5.2.12 Product quality – Reliability
5.2.12.1 The user documentation shall describe the reliability characteristics and their operations.
5.2.13 Product quality – Security
5.2.13.1 The user documentation shall provide the information necessary to identify the level of security
managed by the software for each data managed by the user.
5.2.14 Product quality – Maintainability
5.2.14.1 The user documentation shall state whether maintenance is offered or not. If offered, the
user documentation shall describe the maintenance services in accordance with the release plan of the
software.
5.2.15 Quality in use – Effectiveness
5.2.15.1 The user documentation shall help the user reaching Quality in use Effectiveness as stated in
the product description.
5.2.16 Quality in use – Efficiency
5.2.16.1 The user documentation shall help the user reaching Quality in use Efficiency as stated in the
product description.
5.2.17 Quality in use – Satisfaction
5.2.17.1 The user documentation shall help the user reaching Quality in use Satisfaction as stated in the
product description.
5.2.17.2 The user documentation shall contain a specific supplier contact for satisfaction feedback on
the use of the product.
5.2.18 Quality in use – Freedom from risk
5.2.18.1 The user documentation shall help the user reaching Quality in use Freedom from risk as stated
in the product description.
5.2.19 Quality in use – Context coverage
5.2.19.1 The user documentation shall help the user reaching Quality in use Context coverage as stated
in the product description.
14 © ISO/IEC 2014 – All rights reserved

5.3 Quality requirements for software
5.3.1 Product quality – Functional suitability
5.3.1.1 Following installation, it shall be recognizable whether or not the software can perform a
function.
NOTE The verification of good functioning can be done by using supplied test cases or by self-testing with
corresponding messages, or by other tests conducted by the user.
5.3.1.2 All functions mentioned in the user documentation shall be executable with the corresponding
facilities, properties, and data, and within the given limitations, according to all the statements in the user
documentation.
5.3.1.3 The software shall comply with all the requirements in any requirements document referenced
by the product description.
5.3.1.4 The software shall be free from contradictions within itself and with the product description
and user documentation.
NOTE Example: two identical actions shall return the same result.
5.3.1.5 The control of the software operation by the end user following user documentation and the
software behaviour shall be consistent.
5.3.2 Product quality – Performance efficiency
5.3.2.1 The software shall conform to the Performance efficiency stated in the product description.
NOTE Message to end user when time to wait for a response is unreasonable.
5.3.3 Product quality – Compatibility
5.3.3.1 If the user can carry out the installation, the software shall provide a means to control the
compatibility of the installed components.
5.3.3.2 The software shall perform in accordance with the Compatibility features defined in the user
documentation and the product description.
5.3.3.3 If the software needs parameters or pre-requisite environments to perform compatibility as
defined, it shall be stated clearly in the user documentation.
5.3.3.4 The type of compatibility, function, data or flow shall be clearly specified in the user
documentation.
5.3.3.5 The software shall identify which components of the software are taking in charge the
compatibility.
5.3.3.6 If the user can carry out the installation and the software has any co-existence constraint to any
component installed, it shall be stated before installation occurs.
© ISO/IEC 2014 – All rights reserved 15

5.3.4 Product quality – Usability
5.3.4.1 The user shall recognize whether the product or system is appropriate for its needs based on
the product description or after first manipulation.
5.3.4.2 The messages (questions, instruction, etc…) and results of the software execution shall be
understandable.
NOTE 1 The understandability can be ac
...


NORME ISO/IEC
INTERNATIONALE 25051
Deuxième édition
2014-02-15
Ingénierie du logiciel — Exigences
de qualité pour le logiciel et son
évaluation (SQuaRE) — Exigences
de qualité pour les progiciels et
instructions d’essai
Software engineering — Systems and software Quality Requirements
and Evaluation (SQuaRE) — Requirements for quality of Ready to Use
Software Product (RUSP) and instructions for testing
Numéro de référence
©
ISO/IEC 2014
DOCUMENT PROTÉGÉ PAR COPYRIGHT
© ISO/IEC 2014
Droits de reproduction réservés. Sauf indication contraire, 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, l’affichage sur
l’internet ou sur un Intranet, sans autorisation écrite préalable. Les demandes d’autorisation peuvent être adressées à l’ISO à
l’adresse ci-après ou au comité membre de l’ISO dans le pays du demandeur.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.org
Web www.iso.org
Publié en Suisse
ii © ISO/IEC 2014 – Tous droits réservés

Sommaire Page
Avant-propos .iv
Introduction .v
1 Domaine d’application . 1
2 Conformité . 2
3 Références normatives . 2
4 Termes, définitions et abréviations . 3
4.1 Termes et définitions . 3
4.2 Abréviations . 6
5 Exigences relatives aux progiciels . 6
5.1 Exigences relatives au descriptif produit . 6
5.2 Exigences relatives à la documentation utilisateur .12
5.3 Exigences de qualité relatives au logiciel .15
6 Exigences relatives à la documentation de test .20
6.1 Exigences générales .20
6.2 Exigences liées au plan de test .22
6.3 Exigences liées à la description des tests .23
6.4 Exigences liées aux résultats des tests .23
7 Instructions pour l’évaluation de conformité .25
7.1 Principes généraux .25
7.2 Préalables à l’évaluation de conformité .25
7.3 Activités d’évaluation de conformité .25
7.4 Processus d’évaluation de conformité .26
7.5 Rapport d’évaluation de conformité.26
7.6 Renouvellement de l’évaluation de la conformité .27
Annexe A (informative) Guide d’évaluation des progiciels dans des applications critiques pour la
sécurité ou les entreprises .28
Annexe B (informative) Comment utiliser l’ISO/IEC 25051 .32
Bibliographie .33
© ISO/IEC 2014 – Tous droits réservés iii

Avant-propos
L’ISO (Organisation internationale de normalisation) et l’IEC (Commission électrotechnique
internationale) forment le système spécialisé de la normalisation mondiale. Les organismes nationaux
membres de l’ISO ou de l’IEC participent au développement de Normes internationales par l’intermédiaire
des comités techniques créés par l’organisation concernée afin de s’occuper des domaines particuliers de
l’activité technique. Les comités techniques de l’ISO et de l’IEC collaborent dans des domaines d’intérêt
commun. D’autres organisations internationales, gouvernementales et non gouvernementales, en liaison
avec l’ISO et l’IEC participent également aux travaux. Dans le domaine des technologies de l’information,
l’ISO et l’IEC ont créé un comité technique mixte, l’ISO/IEC JTC 1.
Les Normes internationales sont rédigées conformément aux règles données dans les Directives ISO/IEC,
Partie 2.
La tâche principale du comité technique mixte est d’élaborer les Normes internationales. Les projets de
Normes internationales adoptés par le comité technique mixte sont soumis aux organismes nationaux
pour vote. Leur publication comme Normes internationales requiert l’approbation de 75 % au moins des
organismes nationaux votants.
L’attention est appelée sur le fait que certains des éléments du présent document peuvent faire l’objet
de droits de propriété intellectuelle ou de droits analogues. L’ISO et l’IEC ne sauraient être tenues pour
responsables de ne pas avoir identifié de tels droits de propriété et averti de leur existence.
L’ISO/IEC 25051 a été élaborée par le comité technique mixte ISO/IEC JTC 1, Technologies de l’information,
sous-comité SC 7, Ingénierie du logiciel et des systèmes. Cette deuxième édition annule et remplace la
première édition (ISO/IEC 25051:2006), qui a fait l’objet d’une révision technique. Elle intègre également
le corrigendum technique ISO/IEC 25051:2006/Cor.1:2007.
Les principaux changements sont les suivants:
— Correction des titres anglais et français,
— Modification de la définition de Progiciel, du domaine d’application et des exemples,
— Harmonisation avec la série de normes SQuaRE en cours.
L’ISO/IEC 25051 fait partie de la série de Normes internationales SQuaRE, qui comporte les divisions
suivantes:
— Division Gestion de la qualité (ISO/IEC 2500n);
— Division Modèle de qualité (ISO/IEC 2501n);
— Division Mesure de la qualité (ISO/IEC 2502n);
— Division Exigences de qualité (ISO/IEC 2503n);
— Division Évaluation de la qualité (ISO/IEC 2504n);
— Division réservée au développement (ISO/IEC 25050:— ISO/IEC 25099).
iv © ISO/IEC 2014 – Tous droits réservés

Introduction
Les progiciels sont utilisés dans une variété toujours plus large de domaines et leur bon fonctionnement
est souvent vital pour les applications professionnelles, la sécurité ou les applications personnelles.
Les progiciels sont des produits prêts à l’emploi vendus à des acquéreurs qui n’ont eu aucune influence
sur leurs caractéristiques et autres qualités. Un progiciel est typiquement vendu emballé ou en
téléchargement via une boutique en ligne, accompagné d’une documentation utilisateur. Un progiciel
fournis sous forme de services qu’un utilisateur peut utiliser à tout moment à travers le CLOUD peut
être considéré comme un RUSP. Les informations fournies sur l’emballage ou sur le site internet du
fournisseur sont souvent le seul moyen utilisé par le fournisseur ou le diffuseur pour communiquer
avec l’acquéreur ou l’utilisateur. Il est par conséquent important que les informations essentielles soient
données pour permettre aux acquéreurs d’évaluer les progiciels selon leurs besoins.
La sélection de progiciels de grande qualité est d’une importance primordiale, car des progiciels peuvent
devoir servir dans des environnements variés et être sélectionnés sans possibilité pour l’acquéreur
d’effectuer des comparaisons de caractéristiques avec des produits similaires. Les fournisseurs ont
besoin d’un moyen pour donner confiance aux utilisateurs dans les services fournis par le progiciel.
Certains fournisseurs peuvent choisir un organisme chargé de l’évaluation de la conformité ou de la
certification pour les aider à apporter cette confiance.
En outre, lorsque les utilisateurs veulent obtenir des garanties quant aux risques critiques pour les
entreprises ou pour la sécurité, ces garanties peuvent devoir être prises en charge par l’utilisateur en
recourant à des techniques choisies par ses soins après l’achat. La présente Norme internationale n’a pas
pour intention de spécifier des exigences minimales de qualité d’un progiciel en matière de risques pour
les entreprises ou la sécurité; cependant, un guide informatif a été prévu. (Voir Annexe A.)
L’ISO/IEC 25051:2006 a été élaborée sur les bases de l’ISO/IEC 9126-1:2001, en remplacement de
l’ISO/IEC 12119:1994. Cette deuxième édition de l’ISO/IEC 25051 est une révision de l’ISO/IEC 25051:2006,
et a pour objet de confirmer le modèle de qualité de l’ISO/IEC 25010:2011, remplaçant celui de
l’ISO/IEC 9126:2001.
Ces éléments constituent les raisons essentielles ayant motivé la révision de la présente Norme
internationale qui fournit un ensemble de prescriptions en matière de progiciels, ainsi que des exigences
pour tester la conformité des progiciels à cet ensemble de prescriptions.
Ingénierie du logiciel — Exigences de qualité pour le logiciel et son évaluation (SQuaRE) —
Exigences de qualité pour les progiciels et instructions d’essai
© ISO/IEC 2014 – Tous droits réservés v

NORME INTERNATIONALE ISO/IEC 25051:2014(F)
Ingénierie du logiciel — Exigences de qualité pour le
logiciel et son évaluation (SQuaRE) — Exigences de qualité
pour les progiciels et instructions d’essai
1 Domaine d’application
La présente Norme internationale est applicable aux progiciels (en anglais RUSP pour «Ready to Use
Software Product»).
Dans la présente Norme internationale, le terme «progiciel» est utilisé comme nom et comme adjectif.
Exemple de progiciels, cette liste n’étant pas exhaustive: traitements de texte, tableurs, gestionnaires
de bases de données, outils graphiques, logiciels avec des fonctions embarquées techniques, avec des
fonctions intégrées scientifiques ou en temps réel, logiciels de gestion de ressources humaines, outils
de gestion commerciale, applications de smartphones, logiciels gratuits et logiciels internet tels que les
générateurs de pages ou de sites internet.
NOTE 2 Les logiciels libres ne font pas partie des progiciels.
La présente Norme internationale définit:
a) des exigences qualité relatives aux progiciels;
b) des exigences relatives à la documentation de test des progiciels, incluant le plan des tests, leur
description et leurs résultats;
NOTE L’ensemble des documents relatifs aux tests est appelé «documentation de test».
c) des instructions pour l’évaluation de la conformité des progiciels.
Elle comporte également des recommandations à propos des progiciels critiques pour les entreprises et
la sécurité.
La présente Norme internationale a pour unique objet de donner à l’utilisateur l’assurance que la mise
en œuvre du progiciel répondra à ce qui été proposé et fourni. Elle ne traite pas de la réalisation de son
développement (ni des activités ou des produits intermédiaires, tels que les spécifications). Le système
qualité d’un fournisseur ne relève pas du domaine de la présente Norme internationale.
La présente Norme internationale s’adresse entre autres aux parties suivantes:
a) aux fournisseurs de progiciels:
1) lorsqu’ils spécifient des exigences qualité relatives aux progiciels;
2) lorsqu’ils évaluent leurs progiciels par rapport aux caractéristiques de performance annoncées;
3) lorsqu’ils émettent des déclarations de conformité (ISO/IEC 17050);
4) lorsqu’ils souhaitent obtenir des certificats ou des marques de conformité (Guide ISO/IEC 23);
b) aux organismes de certification qui souhaitent élaborer un système de certification (international,
régional ou national) (Guide ISO/IEC 28);
c) aux laboratoires d’essais qui devront suivre les instructions de test pour tester un progiciel en vue
de l’attribution d’une certification ou d’une marque de conformité (ISO/IEC 17025);
© ISO/IEC 2014 – Tous droits réservés 1

d) aux organismes d’accréditation pour accréditer des organismes de certification ou des laboratoires
d’essais;
e) aux acquéreurs potentiels qui ont la possibilité:
1) de comparer les exigences de l’activité envisagée avec les informations figurant dans les
descriptifs des produits logiciels existants;
2) de rechercher des progiciels certifiés;
3) de vérifier si les exigences sont par ailleurs satisfaites;
f) aux utilisateurs finaux qui peuvent bénéficier de meilleurs produits;
g) aux organisations:
1) qui définissent des environnements de management et d’ingénierie basés sur les exigences de
qualité et les méthodes figurant dans la présente Norme internationale; et
2) qui gèrent et améliorent les performances de leurs processus de qualité et de leur «personnel»;
h) aux autorités réglementaires qui peuvent exiger ou recommander l’application des prescriptions de
la présente Norme internationale pour des progiciels utilisés dans des applications critiques pour
les entreprises et la sécurité.
2 Conformité
Un progiciel est conforme à la présente Norme internationale dans les conditions suivantes:
a) s’il possède les propriétés spécifiées à l’Article 5;
b) s’il a été testé en produisant une documentation de test satisfaisant aux exigences de l’Article 6;
c) si les anomalies décelées pendant les tests sont documentées et résolues avant la mise à disposition
du produit. Les anomalies portant sur des caractéristiques de performance annoncées doivent être
corrigées. Sinon, l’annonce de la caractéristique de performance doit être supprimée. Des anomalies
connues peuvent être acceptées dans les conditions suivantes:
1) si l’anomalie n’est pas en contradiction avec l’annonce de la caractéristique de performance; et
2) si le fournisseur a dûment examiné la nature et l’impact de l’anomalie pour un acheteur potentiel,
l’a estimé négligeable et a conservé la documentation des anomalies en vue d’améliorations
futures.
L’Article 7 et l’Annexe A sont facultatifs.
NOTE Pour faciliter l’évaluation de la conformité, les exigences de la présente norme sont rédigées sous forme
de paragraphes de niveau 3 (numérotés X.X.X.X). Des notes informatives complètent ces paragraphes et peuvent
servir de guide.
3 Références normatives
Les documents ci-après, dans leur intégralité ou non, sont des références normatives indispensables à
l’application du présent document. Pour les références datées, seule l’édition citée s’applique. Pour les
références non datées, la dernière édition du document de référence s’applique (y compris les éventuels
amendements).
ISO/IEC 25000, Ingénierie des systèmes et du logiciel — Exigences de qualité des systèmes et du logiciel et
évaluation (SQuaRE) — Guide de SQuaRE
2 © ISO/IEC 2014 – Tous droits réservés

ISO/IEC 25010, Ingénierie des systèmes et du logiciel — Exigences de qualité et évaluation des systèmes et
du logiciel (SQuaRE) — Modèles de qualité du système et du logiciel
4 Termes, définitions et abréviations
4.1 Termes et définitions
Pour les besoins du présent document, les termes et définitions suivants s’appliquent:
4.1.1
acquéreur
partie intéressée qui acquiert ou se procure un produit ou un service auprès d’un fournisseur
Note 1 à l’article: L’acquéreur peut être acheteur, client, propriétaire, consommateur.
[SOURCE: ISO/IEC 12207:2008]
4.1.2
anomalie
toute situation qui diffère des attentes basées sur des spécifications d’exigences, des documents de
conception, des normes, etc., ou qui diffère des perceptions ou expériences d’une personne
[SOURCE: IEEE Std 1044-2009]
4.1.3
fonction d’administration de l’application
fonction réalisée par l’utilisateur incluant l’installation, la configuration, la sauvegarde de l’application,
la maintenance (correction et mise à niveau) et la désinstallation
4.1.4
évaluation de conformité
examen systématique de la mesure dans laquelle un produit, un processus ou un service répond à des
exigences spécifiées
[SOURCE: Guide ISO/IEC 2:2004]
4.1.5
rapport d’évaluation de conformité
document décrivant la conduite et les résultats d’une évaluation d’un progiciel
Note 1 à l’article: Note à l’article: Adaptée de IEEE Std 610.12-1990.
4.1.6
progiciel
produit logiciel, payant ou non, à la disposition de tout utilisateur et dont l’utilisation ne nécessite pas de
procéder à des développements
Note 1 à l’article: Le progiciel comprend:
— le descriptif produit (incluant toutes les informations figurant sur l’emballage, la fiche technique, les
informations délivrées par des sites internet, etc.),
— la documentation utilisateur, nécessaire pour permettre l’installation et l’utilisation du logiciel, comportant
toutes les configurations du système d’exploitation ou de l’ordinateur cible nécessaires au bon fonctionnement
du produit,
— le logiciel sur un support informatique (disque, CD-ROM, téléchargement Internet, etc.).
Note 2 à l’article: Le logiciel est principalement composé de programmes et de données.
© ISO/IEC 2014 – Tous droits réservés 3

Note 3 à l’article: Cette définition s’applique également à un descriptif produit, une documentation utilisateur et
un logiciel qui sont produits et pris en charge comme des produits manufacturés distincts, mais pour lesquels
les frais de commercialisation et les redevances liées aux droits de licence classiques peuvent ne pas s’appliquer.
4.1.7
utilisateur final
individu qui utilise et bénéficie des fonctionnalités du progiciel
Note 1 à l’article: L’utilisateur final peut être l’utilisateur régulier du progiciel ou un utilisateur occasionnel tel
qu’une personne anonyme.
[SOURCE: ISO/IEC 25000:2005]
4.1.8
défaut
étape, processus ou définition de données incorrect dans un programme informatique
[SOURCE: IEEE Std 610.12-1990]
4.1.9
maintenance
après la livraison, processus de modification d’un système logiciel ou d’un composant pour corriger des
défauts, pour améliorer l’exécution ou d’autres attributs, ou pour l’adapter à un environnement modifié
[SOURCE: IEEE Std 610.12-1990]
4.1.10
critères de réussite ou d’échec
règles de décision utilisées pour déterminer si le résultat du test d’un composant logiciel ou d’une
fonction du logiciel est positif ou négatif
[SOURCE: IEEE Std 829.12-1998]
4.1.11
descriptif produit
document exposant les propriétés du logiciel, dont le principal objet est d’aider des acquéreurs potentiels
à apprécier si le produit leur convient avant de procéder à son achat
4.1.12
identification du produit
nom du produit logiciel, version, variante et informations de date
4.1.13
document d’exigences
document contenant toute combinaison d’exigences ou de réglementations applicables à un progiciel
Note 1 à l’article: Ces documents peuvent être des rapports techniques, des normes, une liste d’exigences (ou
une spécification de référence type) pour un type d’utilisateur, ou bien un décret ou un règlement imposé par un
gouvernement ou un organisme réglementaire.
4.1.14
fonction logicielle
implémentation d’un algorithme dans le logiciel permettant à l’utilisateur final ou au logiciel d’effectuer
tout ou partie d’une tâche
Note 1 à l’article: Une fonction n’est pas nécessairement accessible à l’utilisateur final (par exemple, sauvegarde
automatique ou préservation des données).
4 © ISO/IEC 2014 – Tous droits réservés

4.1.15
environnement de test informatique
installations, matériels, logiciels, micrologiciels, procédures et documentation nécessaires pour
procéder à des tests de qualification ou autres en matière de logiciels
[SOURCE: ISO/IEC/IEEE 24765:2010]
4.1.16
fournisseur
organisation ou personne concluant un accord avec l’acquéreur en vue de lui fournir un produit ou un
service
Note 1 à l’article: Le «fournisseur» peut être un sous-traitant, un fabricant, un vendeur ou un prestataire.
Note 2 à l’article: Il se peut que l’acquéreur et le fournisseur fassent partie de la même organisation.
[SOURCE: ISO/IEC 12207:2008]
4.1.17
test
activité dans laquelle un système ou un composant est exécuté dans des conditions spécifiées, les
résultats sont observés ou enregistrés, et une évaluation est faite pour certains aspects du système ou
du composant
[SOURCE: IEEE Std 610.12-1990]
4.1.18
cas de test
ensemble d’entrées, de conditions d’exécution et de résultats attendus, développé pour un objectif
particulier, tel que le cheminement particulier d’un programme, ou la vérification de la conformité à une
exigence spécifique
[SOURCE: IEEE Std 610.12-1990]
4.1.19
documentation de test
ensemble de la documentation inhérente aux activités de test
4.1.20
objectif de test
ensemble identifié de caractéristiques du logiciel à déterminer dans des conditions spécifiées en
comparant le comportement obtenu avec le comportement attendu
Note 1 à l’article: Adaptée de IEEE Std 610.12-1990.
4.1.21
plan de test
document décrivant le domaine d’application, l’approche, les ressources et le calendrier des activités de
test prévues
Note 1 à l’article: Adaptée de IEEE Std 610.12-1990.
4.1.22
procédure de test
instructions détaillées pour la mise en place, l’exécution et l’évaluation des résultats d’un cas de test
donné
[SOURCE: IEEE Std 610.12-1990]
© ISO/IEC 2014 – Tous droits réservés 5

4.1.23
processus de test
processus d’exécution d’un système ou d’un composant dans des conditions spécifiées, d’observation ou
d’enregistrement des résultats et d’évaluation de certains aspects du système ou du composant
[SOURCE: IEEE Std 610.12-1990]
4.1.24
description des tests
description des conditions d’exécution des tests (à savoir la procédure des tests)
4.1.25
utilisateur
personne ou groupe de personnes qui retire un avantage d’un progiciel lors de son utilisation
Note 1 à l’article: Le rôle de l’utilisateur et celui de l’opérateur peuvent être conférés, simultanément ou
successivement, à la même personne ou à la même organisation
[SOURCE: ISO/IEC 12207:2008]
4.1.26
documentation utilisateur
information qui est fournie avec le logiciel pour aider l’utilisateur dans l’utilisation de ce logiciel
4.2 Abréviations
- progiciel
GC Gestion des configurations
AQL Assurance qualité logiciel
CQL Contrôle qualité logiciel
5 Exigences relatives aux progiciels
5.1 Exigences relatives au descriptif produit
NOTE Le paragraphe de l’ISO/IEC 9127, Ingénierie du logiciel — Documentation pour l’utilisateur et
renseignements sur l’emballage des progiciels grand public, concernant les informations présentes sur l’emballage
peut être utilisé comme élément d’entrée pour le descriptif produit.
5.1.1 Disponibilité
5.1.1.1 Le descriptif produit doit être mis à disposition des acheteurs potentiels et des utilisateurs du
produit.
5.1.2 Contenu
5.1.2.1 Il convient que le descriptif produit mentionne les caractéristiques qualitatives liées à l’utilisation
du logiciel
5.1.2.2 Le descriptif produit doit contenir les informations nécessaires permettant à un acquéreur
potentiel d’apprécier si le produit répond à ses besoins.
5.1.2.3 Le descriptif produit doit être exempt d’incohérences internes.
6 © ISO/IEC 2014 – Tous droits réservés

5.1.2.4 Les déclarations figurant dans le descriptif produit doivent pouvoir être testées ou vérifiées.
5.1.3 Identifications et indications
5.1.3.1 Le descriptif produit doit présenter une identification unique.
5.1.3.2 Le progiciel doit être désigné par son identification produit.
5.1.3.3 Le descriptif produit doit comporter le nom et l’adresse (postale ou internet) du fournisseur et,
le cas échéant, des vendeurs, ou des distributeurs et vendeurs en ligne.
5.1.3.4 Le descriptif produit doit indiquer les tâches et services pour lesquels le progiciel est prévu et
qu’il peut exécuter.
5.1.3.5 Lorsque le fournisseur veut revendiquer la conformité de son produit à des documents définis
par une loi ou par un organisme réglementaire et qui s’appliquent au progiciel, le descriptif produit doit
mentionner les références des documents prouvant la conformité aux exigences.
5.1.3.6 Le descriptif produit doit indiquer s’il est proposé ou non un service d’assistance à l’utilisation
du progiciel.
5.1.3.7 Le descriptif produit doit indiquer s’il est proposé ou non une prestation de maintenance. Dans
l’affirmative, le descriptif produit doit décrire les services de maintenance proposés.
5.1.4 Correspondance
5.1.4.1 Toutes les fonctions mentionnées dans le descriptif produit doivent être classées en fonction
des caractéristiques qualité qui s’y rapportent (5.3.2 à 5.3.9).
5.1.5 Qualité du produit - Adéquation fonctionnelle
5.1.5.1 Le descriptif produit doit comporter, selon le cas, des déclarations concernant l’adéquation
fonctionnelle, tenant compte de la complétude, de l’exactitude et de la précision fonctionnelles, ainsi
que de la pertinence fonctionnelle. Ces précisions, basées sur l’ISO/IEC 25010, doivent être rédigées de
manière à ce que des éléments de preuve vérifiables puissent démontrer la conformité du produit.
5.1.5.2 Le descriptif produit doit comporter une vue d’ensemble des fonctions du produit accessibles à
l’utilisateur final.
5.1.5.3 Le descriptif produit doit décrire toutes les fonctions pour lesquelles l’utilisateur peut être
confronté à des défauts critiques.
NOTE 1 Les défauts critiques peuvent être:
— une perte de données;
— un blocage irrémédiable.
NOTE 2 Pour plus d’informations, se reporter à l’ISO/IEC 15026.
5.1.5.4 Le descriptif produit doit décrire toutes les limites connues que l’utilisateur peut rencontrer.
NOTE Ces limites peuvent être:
— des valeurs minimales ou maximales;
© ISO/IEC 2014 – Tous droits réservés 7

— des longueurs de clés;
— un nombre maximal d’enregistrements dans un fichier;
— un nombre maximal de critères de recherche;
— un échantillonnage minimal.
5.1.5.5 S’il existe diverses options et versions de composants du logiciel, celles-ci doivent être indiquées
de manière non équivoque.
5.1.5.6 Si des moyens permettant d’empêcher les accès non autorisés au logiciel, qu’ils soient accidentels
ou délibérés, sont prévus, ils doivent être mentionnés dans le descriptif produit.
5.1.6 Qualité du produit – Efficience des performances
5.1.6.1 Le descriptif produit doit comporter des déclarations d’efficience des performances, prenant
en compte le comportement dans la durée, l’utilisation des ressources et la capacité. Ces déclarations,
basées sur l’ISO/IEC 25010, doivent être rédigées de manière à ce que les éléments de preuve vérifiables
puissent démontrer la conformité du produit.
5.1.6.2 Toutes les conditions connues concourant à l’efficience des performances du progiciel doivent
être décrites.
NOTE Les conditions déclarées peuvent être:
— les configurations système;
— les ressources nécessaires pour une utilisation efficiente du progiciel, par exemple bande passante, espace
disque, mémoire RAM, carte vidéo, carte pour réseau sans fil, vitesse du processeur, etc.
5.1.6.3 Le descriptif produit doit décrire la capacité des systèmes, ce qui est particulièrement important
pour les systèmes informatiques.
5.1.7 Qualité du produit - Compatibilité
5.1.7.1 Le descriptif produit doit comporter, le cas échéant, des déclarations concernant la compatibilité
prenant en compte la coexistence et l’interopérabilité. Ces déclarations, basées sur l’ISO/IEC 25010,
doivent être rédigées de manière à ce que les éléments de preuve vérifiables puissent démontrer la
conformité du produit.
5.1.7.2 Le descriptif produit doit indiquer les dépendances du progiciel avec des logiciels et (ou) des
matériels spécifiques, et mentionner les références appropriées.
NOTE La référence peut inclure ce qui suit:
— le nom d’un logiciel et/ou d’un matériel (serveur, plateforme, etc.);
— une version;
— un système d’exploitation spécifique.
5.1.7.3 Le descriptif produit doit indiquer les interfaces et les logiciels correspondants accessibles à
l’utilisateur.
8 © ISO/IEC 2014 – Tous droits réservés

5.1.8 Qualité du produit – Facilité d’utilisation
5.1.8.1 Le descriptif produit doit comporter, le cas échéant, des déclarations concernant la facilité
d’utilisation prenant en compte l’identification de la pertinence, la facilité d’apprentissage, la facilité
d’exploitation, la protection contre les erreurs de l’utilisateur, l’esthétique de l’interface et l’accessibilité.
Ces déclarations, basées sur l’ISO/IEC 25010, doivent être rédigées de manière à ce que les éléments de
preuve vérifiables puissent démontrer la conformité du produit.
5.1.8.2 Le descriptif produit doit indiquer la nature de l’interface utilisateur.
NOTE Ces interfaces peuvent être:
— une ligne de commande;
— un menu;
— une fenêtre;
— une touche de fonction.
5.1.8.3 Le descriptif produit doit indiquer les connaissances spécifiques requises pour l’utilisation et la
mise en œuvre du logiciel.
NOTE Ces connaissances peuvent:
— porter sur les accès à la base de données et le protocole utilisé;
— porter sur un domaine technique;
— porter sur un système d’exploitation;
— être le résultat d’une formation spécifique;
— porter sur un langage autre que celui utilisé dans le descriptif produit.
5.1.8.4 Le descriptif produit doit décrire les fonctions destinées à protéger l’utilisateur de toute erreur
d’utilisation, le cas échéant.
5.1.8.5 Le descriptif produit doit mentionner tout procédé technique de protection des droits d’auteur,
susceptible de limiter la facilité d’utilisation.
NOTE Ces protections peuvent concerner:
— des dates de fin d’utilisation programmées;
— des rappels interactifs pour le paiement de la copie.
5.1.8.6 Le descriptif produit doit comporter des indications sur les dispositions prévues en matière
d’accessibilité, en particulier pour des utilisateurs en situation de handicap ou confrontés à des différences
linguistiques.
5.1.9 Qualité du produit - Fiabilité
5.1.9.1 Le descriptif produit doit comporter, le cas échéant, des déclarations concernant la fiabilité
prenant en compte la maturité, la disponibilité, la tolérance aux défauts et la capacité de récupération.
Ces déclarations, basées sur l’ISO/IEC 25010, doivent être rédigées de manière à ce que les éléments de
preuve vérifiables puissent démontrer la conformité du produit.
NOTE Il convient de ne faire aucune déclaration de fiabilité à moins que le développeur n’établisse le bien-
fondé de sa déclaration au moyen de données disponibles ou autres données vérifiables.
© ISO/IEC 2014 – Tous droits réservés 9

5.1.9.2 Le descriptif produit doit décrire la capacité du logiciel à continuer de fonctionner (à savoir, être
disponible) dans le cas d’erreurs de l’interface utilisateur, d’erreurs dans la logique propre à l’application,
ou d’erreurs dues à la disponibilité des ressources système ou réseau.
5.1.9.3 Le descriptif produit doit comporter des informations sur les procédures de sauvegarde et de
restitution des données.
NOTE Une indication affirmant que la sauvegarde des données peut être réalisée par les fonctions du système
d’exploitation est acceptable.
5.1.10 Qualité du produit - Sécurité
5.1.10.1 Le descriptif produit doit comporter, le cas échéant, des déclarations concernant la sécurité,
prenant en compte la confidentialité, l’intégrité, la non-répudiation, l’imputabilité et l’authenticité. Ces
déclarations, basées sur l’ISO/IEC 25010, doivent être rédigées de manière à ce que les éléments de
preuve vérifiables puissent démontrer la conformité du produit.
5.1.11 Qualité du produit - Maintenabilité
5.1.11.1 Le descriptif produit doit comporter, le cas échéant, des déclarations concernant la maintenabilité
prenant en compte la modularité, la capacité de réutilisation, la capacité d’analyse, la facilité de modification
et la testabilité. Ces déclarations, basées sur l’ISO/IEC 25010, doivent être rédigées de manière à ce que
les éléments de preuve vérifiables puissent démontrer la conformité du produit.
5.1.11.2 Le descriptif produit doit comporter des informations pour l’utilisateur concernant la
maintenance.
NOTE Ces informations peuvent concerner:
— la surveillance continue de l’exécution dynamique de l’application;
— la surveillance des défaillances inattendues et des conditions significatives;
— la surveillance des indicateurs opérationnels tels que journaux, écrans d’alertes;
— la surveillance des données locales qui sont activées par l’application.
5.1.11.3 Si le produit est adaptable par l’utilisateur, les outils ou procédés requis pour cette adaptation
et leurs conditions d’utilisation doivent être précisés.
NOTE Ces conditions peuvent être:
— un changement de paramètres;
— un changement d’algorithmes de calcul;
— une personnalisation de l’interface;
— une assignation de touches de fonction.
5.1.12 Qualité du produit - Portabilité
5.1.12.1 Le descriptif produit doit comporter, le cas échéant, des déclarations concernant la portabilité
prenant en compte la facilité d’adaptation, la facilité d’installation et de remplacement. Ces déclarations,
basées sur l’ISO/IEC 25010, doivent être rédigées de manière à ce que les éléments de preuve vérifiables
puissent démontrer la conformité du produit.
5.1.12.2 Le descriptif produit doit indiquer les différentes configurations ou configurations supportées
(matériel, logiciel) pour la mise en œuvre du progiciel.
10 © ISO/IEC 2014 – Tous droits réservés

NOTE 1 Différentes configurations peuvent être indiquées, par exemple pour différentes tâches, différentes
valeurs limites ou différentes exigences d’efficacité.
NOTE 2 Les systèmes peuvent être:
— des systèmes d’exploitation;
— des unités de processeurs incluant des coprocesseurs;
— la taille de la mémoire centrale;
— le type et la taille des périphériques de stockage;
— des cartes d’extensions;
— des équipements d’entrée sortie;
— l’environnement réseau;
— le logiciel système et les autres logiciels.
5.1.12.3 Le descriptif produit doit comporter des informations sur la procédure d’installation.
5.1.13 Qualité de fonctionnement - Efficacité
5.1.13.1 Le descriptif produit doit comporter, le cas échéant, des déclarations concernant l’efficacité.
Ces déclarations, basées sur l’ISO/IEC 25010, doivent être rédigées de manière à ce que les éléments de
preuve vérifiables puissent démontrer la conformité du produit.
5.1.13.2 Le descriptif produit doit spécifier toute référence de conformité du produit pour permettre
aux utilisateurs d’atteindre des objectifs spécifiques.
5.1.14 Qualité de fonctionnement - Efficience
5.1.14.1 Le descriptif produit doit comporter, le cas échéant, des déclarations concernant l’efficience.
Ces déclarations, basées sur l’ISO/IEC 25010, doivent être rédigées de manière à ce que les éléments de
preuve vérifiables puissent démontrer la conformité du produit.
5.1.14.2 Le descriptif produit doit indiquer si le progiciel est destiné à être utilisé simultanément par
plusieurs utilisateurs ou par un seul utilisateur sur un système unique, ainsi que le nombre maximal
d’utilisateurs simultanés pour un niveau de performance donné sur le système requis.
5.1.14.3 Le descriptif produit doit comporter des informations sur les ressources nécessaires pour
permettre à l’utilisateur d’atteindre des objectifs spécifiques.
5.1.15 Qualité de fonctionnement - Satisfaction
5.1.15.1 Le descriptif produit doit comporter, le cas échéant, des déclarations concernant le niveau de
satisfaction relative à la qualité de fonctionnement, prenant en compte les notions d’utilité, de confiance,
de plaisir et de confort. Ces déclarations, basées sur l’ISO/IEC 25010, doivent être rédigées de manière à
ce que les éléments de preuve vérifiables puissent démontrer la conformité du produit.
5.1.15.2 Le descriptif produit doit comporter les coordonnées spécifiques d’un contact fournisseur
assurant la satisfaction du bon fonctionnement du produit.
© ISO/IEC 2014 – Tous droits réservés 11

5.1.16 Absence de risque
5.1.16.1 Le descriptif produit doit comporter, le cas échéant, des déclarations concernant l’absence de
risque liée à la qualité de fonctionnement, prenant en compte l’atténuation des risques économiques,
des risques liés à la santé et à la sécurité, et des risques environnementaux. Ces déclarations, basées sur
l’ISO/IEC 25010, doivent être rédigées de manière à ce que les éléments de preuve vérifiables puissent
démontrer la conformité du produit.
5.1.16.2 Le descriptif produit doit comporter des informations sur la préservation de la confidentialité
en cas de risques connus liés à l’utilisation du logiciel ou doit comporter des informations sur la nécessité
de procéder à des formations spécifiques des utilisateurs.
5.1.17 Couverture contextuelle
5.1.17.1 Le descriptif produit doit comporter, le cas échéant, des déclarations concernant la couverture
contextuelle liée à la qualité de fonctionnement, prenant en compte la complétude contextuelle et la
flexibilité. Ces déclarations, basées sur l’ISO/IEC 25010, doivent être rédigées de manière à ce que les
éléments de preuve vérifiables puissent démontrer la conformité du produit.
5.1.17.2 Lorsque le descriptif produit comporte des informations de conformité, le champ d’application
de cette conformité doit être indiqué clairement.
5.2 Exigences relatives à la documentation utilisateur
NOTE Le paragraphe concernant les informations présentes sur l’emballage de l’ISO/IEC 9127, Ingénierie du
logiciel — Documentation pour l’utilisateur et renseignements sur l’emballage des progiciels grand public, peut
être utilisé comme élément d’entrée pour l’élaboration de la documentation utilisateur.
5.2.1 Disponibilité
5.2.1.1 La documentation utilisateur doit être mise à la disposition des utilisateurs du produit.
5.2.2 Contenu
5.2.2.1 Les fonctions figurant dans la documentation utilisateur doivent pouvoir être soumises à des
tests ou doivent pouvoir être vérifiées.
5.2.3 Identifications et indications
5.2.3.1 La documentation utilisateur doit posséder une identification unique.
5.2.3.2 Le progiciel doit être désigné par son identification produit.
5.2.3.3 La documentation utilisateur doit comporter le nom et l’adresse (postale ou internet) du
fournisseur.
5.2.3.4 La documentation utilisateur doit indiquer les tâches et services que le progiciel peut exécuter.
5.2.4 Exhaustivité
5.2.4.1 La documentation utilisateur doit comporter les informations nécessaires à l’utilisation du
logiciel.
12 © ISO/IEC 2014 – Tous droits réservés

5.2.4.2 La documentation utilisateur doit décrire toutes les fonctions indiquées dans le descriptif
produit et toutes les fonctions auxquelles peut accéder l’utilisateur final.
5.2.4.3 La documentation utilisateur doit lister les erreurs et les défauts qui sont traités et qui
entraînent la défaillance ou l’arrêt de l’application, en particulier les conditions se terminant par l’arrêt
de l’application et provoquant la perte de données.
5.2.4.4 La documentation utilisateur doit fournir un guide pour la sauvegarde et la restauration des
données critiques.
5.2.4.5 La documentation utilisateur doit fournir des instructions complètes et des informations de
référence pour toutes les fonctions critiques du logiciel (logiciel dont les défaillances peuvent avoir un
impact sur la sécurité ou peuvent causer de lourdes pertes financières ou sociales).
NOTE Voir l’Annexe A pour plus d’informations.
5.2.4.6 La documentation utilisateur doit indiquer l’espace disque minimal requis pour l’installation.
5.2.4.7 La documentation utilisateur doit comporter toutes les informations nécessaires concernant
les fonctions d’administration de l’application exécutables par l’utilisateur.
NOTE exemple d’information:
— Information permettant à l’utilisateur de vérifier la bonne exécution des fonctions d’administration de
l’application.
5.2.4.8 Si la documentation utilisateur est fournie en plusieurs parties, au moins un élément de
l’ensemble doit identifier toutes les parties.
5.2.5 Exactitude
5.2.5.1 Toutes les informations de la documentation utilisateur doivent être adaptées aux principaux
utilisateurs cibles.
NOTE Il convient de pouvoir relier toutes les informations figurant dans la documentation utilisateur à une
source de référence fiable quant à son exactitude.
5.2.5.2 La documentation utilisateur doit présenter des informations non équivoques.
5.2.6 Cohérence
5.2.6.1 Les documents de la documentation utilisateur ne doivent pas présenter d’incohérence interne,
d’incohérence entre eux et d’incohérence avec le descriptif produit.
5.2.7 Facilité de compréhension
5.2.7.1 La documentation utilisateur doit être compréhensible par les utilisateurs finaux auxquels le
progiciel est principalement destiné, en utilisant une terminologie et un style compréhensibles par son
public spécialisé.
5.2.7.2 La compréhension de la documentation utilisateur doit être facilitée par une liste structurée des
documents.
© ISO/IEC 2014 – Tous droits réservés 13

5.2.8 Qualité du produit - Adéquation fonctionnelle
5.2.8.1 La documentation utilisateur doit indiquer toutes les limites d’utilisation du progiciel signalées
dans le descriptif pr
...

Questions, Comments and Discussion

Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.

Loading comments...

La norme ISO/IEC 25051:2014 se concentre sur les exigences de qualité pour les produits logiciels prêts à l'emploi (RUSP) et constitue un document fondamental dans le domaine de l'ingénierie logicielle. Son champ d'application est précis et s'articule autour des exigences de qualité qui garantissent aux utilisateurs que les produits logiciels fonctionneront comme prévu. Parmi les points forts de cette norme, on trouve sa capacité à établir des exigences claires pour la documentation de test, englobant des éléments essentiels tels que le plan de test, la description des tests et les résultats des tests. Cela permet aux développeurs et aux clients d'assurer une compréhension mutuelle des critères de qualité avant le déploiement d'un RUSP. De plus, la norme fournit des instructions détaillées sur l'évaluation de la conformité des RUSP, ce qui renforce la confiance dans la capacité des produits à répondre aux attentes. L'importance de l'ISO/IEC 25051:2014 réside également dans ses recommandations concernant les RUSP critiques pour la sécurité ou les affaires, soulignant ainsi la prise en compte des enjeux majeurs lors de l'évaluation de la qualité des produits déployés. En se concentrant exclusivement sur la performance et les exigences de qualité à l'usage, la norme crée un cadre robuste pour les utilisateurs, tout en laissant de côté les aspects de réalisation de production, ce qui permet une spécialisation vers des domaines plus techniques. En somme, l'ISO/IEC 25051:2014 se révèle être un outil crucial pour garantir la qualité et la fiabilité des produits logiciels prêts à l'emploi, tout en fournissant une approche équilibrée entre exigences de test et évaluation de la conformité. Cette norme est, sans aucun doute, pertinente pour les organisations cherchant à assurer la satisfaction des utilisateurs et la maîtrise des risques associés aux logiciels.

Die Norm ISO/IEC 25051:2014 bietet einen umfassenden Rahmen für die Qualitätssicherung von „Ready to Use Software Products“ (RUSP) und definiert spezifische Anforderungen, die für solche Softwareprodukte gelten. Die Reichweite dieser Norm ist klar umrissen, da sie sich auf die Qualität der RUSP konzentriert und nicht auf die Produktions- oder Realisierungsprozesse der Software. Dies ermöglicht es den Benutzern, sicherzustellen, dass die RUSP gemäß den versprochenen Spezifikationen funktionieren, was ein zentrales Anliegen in der heutigen softwaregetriebenen Welt ist. Ein wesentlicher Stärke der ISO/IEC 25051:2014 liegt in der genauen Definition der Anforderungen für die Testdokumentation. Die Norm legt fest, dass Testpläne, Testbeschreibungen und Testergebnisse klar dokumentiert werden müssen. Diese strukturierte Herangehensweise an die Testdokumentation stellt sicher, dass alle Aspekte des Testprozesses transparent und nachvollziehbar sind, was entscheidend für die trust-building der Nutzer ist. Darüber hinaus umfasst die Norm auch Anleitungen zur Konformitätsbewertung von RUSP, was eine wertvolle Ressource für Unternehmen darstellt, die sicherstellen möchten, dass ihre Softwareprodukte den definierten Qualitätsstandards entsprechen. Die Empfehlungen für sicherheits- oder geschäftskritische RUSP unterstreichen die Relevanz dieser Norm in kritischen Anwendungsbereichen, in denen die Softwareverfügbarkeit und -zuverlässigkeit von größter Bedeutung sind. Insgesamt ist die ISO/IEC 25051:2014 von zentraler Bedeutung für Entwickler und Anbieter von Softwareprodukten, da sie nicht nur die Erwartungen an die Qualität von Softwareprodukten definiert, sondern auch die erforderlichen Schritte zur Evaluation und Sicherstellung dieser Qualität systematisch festlegt. Die Norm trägt somit wesentlich dazu bei, das Vertrauen der Benutzer in RUSP zu stärken und deren Erfolg auf dem Markt zu fördern.

ISO/IEC 25051:2014は、Ready to Use Software Product (RUSP)に関する品質要件を明確に定義する重要な標準です。この標準は、RUSPの信頼性を確保するためのテストドキュメントに関する要求事項を定めており、テスト計画、テスト記述、テスト結果を含む実用的な指針を提供します。特に、ユーザーが提供された通りにRUSPが期待通りに機能するという信頼を得るために必要な要件を重視しています。 ISO/IEC 25051:2014の強みは、その包含範囲の明確さにあります。この標準は、テストのコンプライアンス評価に関する具体的な指導も含んでおり、特に安全性やビジネスクリティカルなRUSPに関する推奨事項が含まれている点が評価されます。また、テストドキュメントの標準化により、RUSPの品質保証プロセスが明確に整理され、開発者やテスターが効率よく作業を進める手助けを提供します。 さらに、この標準はユーザーに対する信頼性の提供に焦点を当てており、製品実現やサプライヤーの品質システムの範囲には立ち入らないため、RUSPに特化した品質評価を行うことができます。このため、ISO/IEC 25051:2014は、ソフトウェアエンジニアリングの領域において、ユーザーが選択する際の重要な基準としての役割を果たします。

ISO/IEC 25051:2014 표준은 Ready to Use Software Product (RUSP)의 품질 요구 사항을 다루고 있으며, 이 표준의 핵심은 RUSP의 신뢰성을 보장하기 위한에 있습니다. 이 표준은 RUSP의 품질 요구 사항을 명확하게 규정하고 있어, 사용자에게 제공되는 소프트웨어 제품이 약속된 성능을 충족할 것이라는 확신을 줍니다. 이 표준의 강점 중 하나는 RUSP 테스트 documentation에 대한 명확한 요구 사항을 포함하고 있다는 점입니다. 시험 계획, 시험 설명 및 시험 결과를 포함한 문서 작성 요구 사항은 소프트웨어 품질 평가에 있어 필수적이며, 사용자와 공급자 간의 신뢰를 구축하는 데 중요한 역할을 합니다. ISO/IEC 25051:2014는 안전 또는 비즈니스 중요성이 높은 RUSP에 대한 권장 사항도 제공하여, 특정 산업 분야에서의 응용 가능성을 확대합니다. 또한, 이 표준은 RUSP의 일관된 평가를 위한 지침을 제공함으로써, 개발 및 테스트 프로세스에서의 품질 향상에 기여합니다. 이 표준의 범위는 RUSP의 성능과 신뢰성을 중점적으로 다루고 있으며, 공급자의 품질 시스템이나 생산 실현에 대한 내용은 포함되지 않아, 소프트웨어 제공에 집중할 수 있는 장점이 있습니다. ISO/IEC 25051:2014는 최종 사용자에게 완성된 소프트웨어의 품질을 보장하고, 이를 통해 기업의 신뢰성을 높이는 데 필수적인 기준으로 작용합니다.

The ISO/IEC 25051:2014 standard offers a comprehensive framework for establishing quality requirements specifically for Ready to Use Software Products (RUSP). It intricately details the essential quality criteria that should be met, ensuring that users receive products that perform as promised. One of the key strengths of ISO/IEC 25051:2014 lies in its systematic approach to test documentation for RUSP. The standard mandates the inclusion of crucial components such as a test plan, test descriptions, and clear results, which are vital for validating the functionality and reliability of the software. By providing structured instructions for testing, the standard enhances consistency in evaluation methodologies and instills confidence in users regarding the capabilities of the software products they employ. Furthermore, the inclusion of recommendations for safety or business-critical RUSP highlights the standard's relevance in contexts where software failures could have significant repercussions. By addressing these critical areas, ISO/IEC 25051:2014 supports organizations in selecting and deploying software that meets rigorous safety and operational expectations. While the standard does not cover production realization or the quality systems of suppliers, its focused criteria and evaluation instructions empower users to assess the conformity of RUSP effectively. This distinction underscores the importance of user confidence in the products, setting clear boundaries around the standard's objectives and ensuring clarity in its application. In summary, ISO/IEC 25051:2014 stands out as a pivotal resource for organizations seeking to establish and evaluate the quality of Ready to Use Software Products. Its emphasis on clear documentation and testing instructions greatly enhances the reliability and trustworthiness of software, solidifying its place as an essential standard in the software engineering domain.