ISO 16175-1:2020

INTERNATIONAL ISO
STANDARD 16175-1
Second edition
2020-07
Information and documentation —
Processes and functional
requirements for software for
managing records —
Part 1:
Functional requirements and
associated guidance for any
applications that manage digital
records
Information et documentation — Processus et exigences
fonctionnelles applicables aux logiciels de gestion des documents
d'activité —
Partie 1: Exigences fonctionnelles et recommandations associées pour
toute application de gestion de documents d’activité numériques
Reference number
©
ISO 2020
© ISO 2020
All rights reserved. Unless otherwise specified, or required in the context of its implementation, 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
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: +41 22 749 01 11
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii © ISO 2020 – All rights reserved

Contents Page
Foreword .v
Introduction .vi
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Key outcome areas and configuration options . 2
4.1 Key outcome areas . 2
4.2 Key outcome areas in detail . 2
4.2.1 Records capture and classification . 2
4.2.2 Records retention and disposition . 3
4.2.3 Records integrity and maintenance . 3
4.2.4 Records discovery, use and sharing . 3
4.3 Possible configuration options for managing records created in business applications . 3
5 High-level requirements for software managing digital records .4
5.1 General . 4
5.2 Assumptions . 5
5.3 General overview of requirements . 5
6 Model functional requirements for applications that manage digital records .6
6.1 Requirements groupings . 6
6.2 Obligation levels and extensibility of requirements . 7
6.3 Requirements in detail . 7
7 Understanding the model functional requirements .12
7.1 General .12
7.2 Addressing records requirements in business applications .13
7.2.1 General.13
7.2.2 Importance of records metadata .14
7.2.3 Archiving .14
7.3 Records characteristics that should be enabled by business applications .14
7.3.1 General.14
7.3.2 Authenticity .15
7.3.3 Reliability .15
7.3.4 Integrity .15
7.3.5 Usability .15
7.4 Characteristics of business applications that manage records .15
7.4.1 General.15
7.4.2 Secure .15
7.4.3 Compliant .15
7.4.4 Comprehensive .15
7.4.5 Systematic .15
7.5 Records entities and relationships .16
7.5.1 Entity relationship models .16
7.5.2 Business classification scheme .16
7.5.3 Aggregations of digital records .17
7.5.4 Digital records .17
7.5.5 Extracts .17
7.5.6 Components .18
8 Using the model functional requirements .18
8.1 General .18
8.2 Determining needs for evidence of events, transactions and decisions in business
applications (identifying the needs for records) .18
8.2.1 General.18
8.2.2 Step 1: Identifying requirements for evidence of the business using
functional analysis .19
8.2.3 Step 2: Analysing the work process .20
8.2.4 Step 3: Identify the information that records the required evidence .20
8.2.5 Step 4: Identify linkages and dependencies .23
8.2.6 Step 5: Reflect requirements for evidence of business in functional
requirements for software and determine implementation options .24
8.3 Functional requirements conformity assessment .24
8.3.1 General.24
8.3.2 Undertaking the conformity assessment process .24
8.4 Risk assessment .25
8.5 Determining functional requirements for managing records in an application
design specification .26
8.5.1 General.26
8.5.2 Step 1 — Assess the functional requirements . .26
8.5.3 Step 2 — Check appropriateness of the requirements .27
8.5.4 Step 3 — Check appropriateness of the obligation levels .27
8.5.5 Step 4 — Identify gaps in the functional requirements .27
8.6 Assessing options for deploying functionality in one or more software applications .27
Annex A (informative) Example template for functional requirements.32
Annex B (informative) Mapping of records principles to model functional requirements .36
Bibliography .37
iv © ISO 2020 – All rights reserved

Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards
bodies (ISO member bodies). The work of preparing International Standards is normally carried out
through ISO technical committees. Each member body interested in a subject for which a technical
committee has been established has the right to be represented on that committee. International
organizations, governmental and non-governmental, in liaison with ISO, also take part in the work.
ISO collaborates closely with the International Electrotechnical Commission (IEC) on all matters of
electrotechnical standardization.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular the different approval criteria needed for the
different types of ISO documents should be noted. This document was drafted in accordance with the
editorial rules of the ISO/IEC Directives, Part 2 (see www .iso .org/ directives).
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. ISO shall not be held responsible for identifying any or all such patent rights. Details of
any patent rights identified during the development of the document will be in the Introduction and/or
on the ISO list of patent declarations received (see www .iso .org/ patents).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation on the voluntary nature of standards, the meaning of ISO specific terms and
expressions related to conformity assessment, as well as information about ISO's adherence to the
World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT) see the following
URL: www .iso .org/ iso/ foreword .html.
This document was prepared by Technical Committee ISO/TC 46, Information and documentation
Subcommittee SC 11, Archives/records management.
This second edition cancels and replaces the first edition (ISO 16175-1:2010), which has been technically
revised. The main changes compared to the previous edition are as follows.
— The distinction between dedicated records management applications and business applications has
been dispensed with. As a result, a single set of functional requirements and associated guidance is
provided in a single document that addresses both kinds of software applications.
— The number of functional requirements has been greatly reduced and simplified in order to help
users focus on the most important areas of software functionality.
— Text has been updated, clarified and simplified, with the use of records jargon eliminated where
possible and explained when necessary in acknowledgement of the primary audience for the
standard being IT professionals. More diagrams have been added.
A list of all parts in the ISO 16175 series can be found on the ISO website.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www .iso .org/ members .html.
Introduction
0.1  Case for management of records
Good management of records and information is fundamental to a well-functioning organization. It
supports business functions and processes and provides a basis for efficient service delivery. It also
provides the mechanism for organizations to retain evidence of their decisions and actions for future
reference and to support business continuity. Good records practice is simply good business practice.
Managing records facilitates:
a) efficiency, by making information readily available when needed for decision-making and
operational purposes and to support information reuse and innovation;
b) sound use of financial resources, by allowing timely disposition of non-current records;
c) accountability, by enabling the creation of complete and authoritative records of business functions
and processes;
d) compliance, by demonstrating that legal requirements have been met; and
e) risk mitigation, by managing the risks associated with unlawful loss or destruction of records and
with over-retention of records, and risks resulting from inappropriate or unauthorized access to
records.
In most organizations today, business is transacted and enabled by a variety of software applications.
If organizations are to capture and manage reliable records of their business functions and processes,
it is vital that their line-of-business applications incorporate good records functionality as part of their
design. Making, keeping and disposing of records should be an organic and natural part of business
processes.
0.2  Purpose of this document
This document provides model, high-level functional requirements, with associated explanatory
information and usage guidance, for any software applications that are intended to manage digital
1)
records. ISO/TS 16175-2:— provides guidance on how to select/design, implement and maintain
software for managing records within organizations.
For the purpose of presenting model functional requirements, this document makes no distinction
between software applications that are used for any business purpose and those applications
specifically intended and designed to manage records. Examples of the former include Enterprise
Content Management Systems and applications which create records as one part of their functionality
such as Contracts Management Systems, Case Management Systems or transactional systems. The
term used throughout is therefore “Business application”, which is intended to encapsulate the totality
of applications that manage records as part of their usual functioning. It is assumed that almost all
business applications will generate data that is needed to serve as evidence of business functions
and processes for future reference and as such will, among other things, need to create, store and
manage records. The purpose of this document is to assist the developers and implementers of those
applications to identify and deploy functional requirements that helps ensure that the data generated
and held in such applications can serve as adequate records of business functions and processes.
In addition to providing model high-level functional records requirements in business applications, this
document provides guidance on identifying and addressing the needs for records. It aims to:
a) help organizations understand requirements for managing digital records as they relate to
software applications used by organizations;
b) assist IT and business specialists to include records considerations in applications design and/or
procurement; and
1) Under development. Stage at the time of publication: ISO/DTS 16175-2:2020.
vi © ISO 2020 – All rights reserved

c) assess the capabilities of existing business applications to manage records, including helping to
identify gaps or areas of risk in the current functionality of those applications.
This document is part of a suite of records system implementation guidance that supports the core
international records management standard, ISO 15489-1, where utility and characteristics of records
systems are explained.
0.3  Audience
The primary audience for this document are professionals responsible for designing, developing,
procuring, reviewing and/or implementing software applications, such as business analysts,
applications developers, solution architects and IT procurement decision-makers. The audience also
includes records professionals who are involved in advising or assisting in such processes.
Role Purpose
Solution architects/ Ensure IT applications infrastructure supports the records requirements.
designers
Records professionals Advising and assisting the business in defining records requirements.
IT procurement deci- Ensure procurement processes meet these requirements.
sion-makers
Applications developers Build applications and support information systems testers during functional
specification development and test phase. Includes software vendors and devel-
opers who wish to incorporate records functionality within their products, both
commercial or open source.
Business analysts Develop technical specifications; initiate/collate feedback and walkthrough. Submit
specification for sign-off and pass over to developer. Update any changes to specifi-
cation after sign-off (e.g. changes that are agreed during test phase), if required.
Applications testers Develop test plans, test conditions/cases and execute tests. Analyse test results,
log any failures and retest once immutability has been applied and built to test
environment.
Business owners For solution-specific requirements. Review and confirm application requirements
that meet business objectives. Provide the business rules/processes/requirements to
the business analyst during the software specification development and test phases.
Given the target audience for this document, the use of terminology that is specific to records
professionals has been minimised as far as possible. Where the use of such terminology is unavoidable,
it is explained and/or defined (in Clause 3).
INTERNATIONAL STANDARD ISO 16175-1:2020(E)
Information and documentation — Processes and
functional requirements for software for managing
records —
Part 1:
Functional requirements and associated guidance for any
applications that manage digital records
1 Scope
This document provides model, high-level functional requirements and associated guidance for
software applications that are intended to manage digital records (including digital copies of analogue
source records), either as the main purpose of the application or as a part of an application that is
primarily intended to enable other business functions and processes.
It does not include:
— functional requirements for applications that manage analogue records;
— generic design requirements such as reporting, application administration and performance;
— requirements for the long-term preservation of digital records in a dedicated preservation
environment;
NOTE The model requirements are intended to encourage the deployment of applications that do not
hinder long-term preservation of records. As such, some of the requirements support long-term digital
preservation outcomes.
— implementation guidance for applications that manages analogue and/or digital records. Such
2)
guidance can be found in ISO/TS 16175-2:— .
2 Normative references
The following document is referred to in the text in such a way that some or all of its content constitutes
requirements of this document. For undated references, the latest edition of the referenced document
(including any amendments) applies.
ISO 30300, Information and documentation — Records management — Core concepts and vocabulary
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO 30300 apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https:// www .iso .org/ obp
— IEC Electropedia: available at http:// www .electropedia .org
2) Under development. Stage at the time of publication: ISO/DTS 16175-2:2020.
4 Key outcome areas and configuration options
4.1 Key outcome areas
The functional requirements in this document focus on the outcomes required to ensure records are
managed appropriately. How to achieve the outcomes will depend on the type of application being used.
See Figure 1.
Figure 1 — Key outcome areas
4.2 Key outcome areas in detail
4.2.1 Records capture and classification
Software applications that enable business activities or transactions should be able to capture and/or
import/ingest evidence of those activities. This involves identifying sets of digital information to serve
as records. Records shall be linked to their business context using metadata.
2 © ISO 2020 – All rights reserved

4.2.2 Records retention and disposition
Records shall be kept and remain accessible to authorized agents for as long as required for legislative,
community and business needs. In conformance with authorized disposition authorities, records
should be retained and disposed of in a managed, systematic and auditable way.
4.2.3 Records integrity and maintenance
Business applications should be able to register any interactions with or changes to the records.
Metadata recording these interactions and changes should include the name of the responsible agent, a
timestamp and details of any changes. The metadata should be persistently linked to the records for as
long as they exist.
4.2.4 Records discovery, use and sharing
Business applications should enable searching, retrieval, rendering, use, sharing and redaction of
records for authorized agents. They should also support interoperability across platforms and domains
and over time.
NOTE See 7.5.5 for a discussion on redaction of records.
4.3 Possible configuration options for managing records created in business
applications
It is not necessary for all the functional requirements presented in this document to be met by a single
software application. It may be more cost effective for the requirements to be satisfied by multiple
software applications that collectively work together within an organization, or across multiple
organizations, to enable the conduct of business. Guidance on these issues can be found in Figure 2 and
in 7.5. In addition, some requirements could be satisfied outside applications through processes and
procedures.
Before using the functional requirements, organizations should consider how to meet these
requirements: through internal mechanisms within a business application itself, or by interacting
with external software applications that are capable of providing the necessary records management
functionality.
The mandatory functional requirements in this document outline the core records processes that shall
be addressed. Options to implement these requirements may include:
a) designing the business application to internally perform the records processes, or to do so in
combination with associated work processes;
b) integrating with a dedicated records management application, such as an electronic records
management system (ERMS); or
c) designing export functionality into the business application to directly export records and their
associated metadata to an identified records management application.
Figure 2 — Possible configuration options for managing records created in business
applications
For more detail, see 8.6.
5 High-level requirements for software managing digital records
5.1 General
Organizations make decisions on what type of software for managing records should support
particular business processes, business units or the organization as a whole and consider the risks
that are linked to business processes when making such decisions. The scope of software for managing
records will be affected by the social and regulatory framework within which an organization operates,
by the organizational readiness or maturity around records reflected in its policies and allocation of
responsibilities, and by the technologies that are appropriate for organizational use.
Organizations that already rely on digital records to conduct and document business, or that are
interested in eliminating paper records from their operations, are seeking solutions to the issues arising
from management of digital records. The decisions that organizations make today about the capability
of the software, and the arrangement and structure of information within the software will have a
significant impact on the long-term sustainability of digital records. The capacity to sustain digital
records beyond the lifespan of a single instance of software is closely linked to the design, selection and
4 © ISO 2020 – All rights reserved

configuration of software, and should be considered carefully within an organization-wide information
governance context.
Organizations deploy software applications to automate business activities and transactions. The
digital information generated by an application may serve as the only evidence or record of the activity
or transaction, despite the application not being designed specifically for the purpose of managing
records. Without evidence of these activities, organizations are exposed to risk and may be unable to
meet legislative, accountability, business and community expectations. Because of the dynamic and
manipulable nature of business applications, the capture of records and the ongoing management of
their fixity, authenticity, reliability, usability and integrity can be challenging.
Many business applications generate and store data that can be subject to constant updating (dynamic),
able to be transformed (manipulable) and only contain current data (non-redundant). While business
requirements for dynamic, manipulable and non-redundant data can be entirely legitimate, if records
are to serve as reliable evidence of business functions and processes, they need to be fixed and
inviolable. That is, systems and processes need to be able to guarantee the reliability, integrity and
authenticity of the records as evidence of past business activities and as business assets.
For the purposes of this document, the characteristics of authoritative records (as defined in
ISO 15489-1:2016, 5.2.2) may be applied to any and all data, documents or information. A records
approach enables the traceability of actions documenting business to be maintained for as long as
needed to support assertions of authenticity, reliability and integrity.
5.2 Assumptions
This document assumes
— that records controls (particularly those identified in Clause 8) are already developed within the
organization;
— that projects to implement records requirements in software will be continuous; and
— that all new software implementation projects require implementation of defined records
requirements.
Designing, implementing and maintaining software for managing records is an ongoing and continual
part of managing records within organizations, to reflect constantly changing technological
environments, new business software, and changes to business processes.
5.3 General overview of requirements
Selecting software that creates or manages digital records should be done in line with defined
functional requirements. The high-level requirements included here are consistent with the principles
for managing records outlined in ISO 15489-1:2016, Clause 4. Clause 6 provides more detailed functional
requirements for software that creates or manages digital records.
a) Software should support the management of digital records as a core component of the business
process.
When automating a business process, records requirements should be met by software.
b) Software managing digital records should maintain persistent links to the business context.
An understanding of the business context of records is required to enable accurate interpretation
of their content. Software should persistently link to the specific business context in which records
are created and maintain that linkage over time.
c) Software managing digital records should be able to capture metadata, automatically generated to
the greatest extent possible.
Software should be designed and implemented in a manner that allows maximum automatic
assignment of point of capture records metadata, enabling end-user editing capability prior to
capture, where needed. Records process metadata should be automatically generated and captured
as the system is used.
d) Software should be user-friendly and allow easy records creation and capture.
Software that automates management of records should be designed in a way that makes such
activity largely "invisible" to the end-users. Techniques for this may include automatic logging of
events occurring on records at all levels of aggregation and minimizing end-user requirements to
interact with complex functionality specific to requirements of records professionals.
e) Software should support interoperability over time and across platforms and domains.
Digital records often have operational or legal requirements for retention over periods of time
that may exceed the lifespan of the hardware or software that created it. Software should be able
to present records in a manner that maintains their metadata, usability and enables them to be
converted to new formats and/or migrated to other technology platforms.
f) Software should have the capacity for bulk import and export.
Records often need to last longer than the system in which they are initially created, captured and
managed. Records software should incorporate capabilities for bulk re-formatting as part of import
(ingest) or export capability or, at a minimum, via non-proprietary encoding of record metadata.
g) Software should maintain records in a secure environment.
Software should not allow unauthorized access or modifications to any records or to records
metadata. Where authorized modifications are performed, they should be fully documented.
Information which is confidential or which contains personal information should be identified and
mechanisms deployed to ensure appropriate access and use protections.
h) Software should support the disposition of records in a managed, systematic and auditable way.
Software needs to be able to dispose of records in a systematic and auditable way in line with
business or legal requirements and societal and community expectations.
i) Software should rely as much as possible on open, robust and technology neutral standards.
Many software products that create or manage records are developed using proprietary code.
Hardware or software dependencies can have adverse effects on access and preservation of records
in the long term. Open, robust and technology neutral standards should be used.
6 Model functional requirements for applications that manage digital records
6.1 Requirements groupings
NOTE See 6.3.
R1. Capture and classification
R1.1. Records creation, capture and import
R1.2. Records metadata capture
R1.3. Records classification
R1.4. Managing business classification schemes
6 © ISO 2020 – All rights reserved

R2. Retention and disposition
R2.1. Records retention, review, transfer and destruction
R2.2. Records migration and export
R3. Integrity and maintenance
R3.1. Records authentication and security
R3.2. Storage, reporting and metadata management
R4. Discovery, use and sharing
R4.1. Search, retrieval, presentation, use and interoperability
R4.2. Access restrictions and permissions
R4.3. Duplication, extraction and redaction
6.2 Obligation levels and extensibility of requirements
The obligation levels provided for each requirement indicate the relative importance of the requirement
in question. The words “shall”, “should” and “may” are to be interpreted as follows:
Shall Requirement that use “shall” are mandatory for applications intended to conform with this
document.
Should Requirements that use “should” are highly desirable but not mandatory. They may be ig-
nored if a valid reason exists, but the full implications of ignoring the requirement should
be understood and carefully considered before choosing a different course.
May Requirements that use “may” are optional.
The model requirements presented in 6.3 may be added to or extended in particular implementation
settings depending on the circumstances and records requirements that apply in those settings. Such
additions and extensions shall not, however, contradict any of the model requirements presented in 6.3.
6.3 Requirements in detail
These requirements can be met by more than one configuration option, see Figure 2. As far as possible,
this subclause aims to avoid the use of records jargon. Definitions for records terminology that is used
can be found in ISO 30300. Discussion of the utility of many of these concepts can be found in Clause 7.
R1. Capture and classification Obligation
R1.1  Records creation, capture and import
The business application shall, either alone or in conjunction with other applications: Shall
R1.1.1  enable the capture of records and any associated records metadata;
R1.1.2  where an individual business application cannot provide the capability to ingest
records and associated metadata, other components shall provide the capability to ingest
records and/or associated metadata from other business applications or related external
repositories, see options 2 and 3 in Figure 2;
R1.1.3  where the application creates or receives records generated by electronic messag-
ing systems (such as email, text messaging and instant messaging), capture attachments
and embedded objects together with the digital messages as either linked records or as a
single compound record;
R1.1.4  enable the business application to import digital records and associated metadata
directly from an external business application, either in bulk or individually, ensuring
the integrity of the content and structure of the records. When the records that are to be
captured have additional integrity verification criteria (electronic signatures, checksum,
etc.), the system that captures them shall be able to verify the validity according to these
criteria, at least at the time of capture.
The business application should, either alone or in conjunction with other applications: Should
R1.1.5  support capture of records in commonly used file formats and/or in their native
formats.
R1.2  Records metadata capture
The business application shall, either alone or in conjunction with other applications: Shall
R1.2.1  enable the capture and maintenance of metadata for records at any time during
the record’s existence, in accordance with one or more pre-determined metadata schemas;
R1.2.2  be able to assign and persistently link unique identifiers to each record and records
aggregation;
R1.2.3  support the ability to automatically detect and capture pre-existing metadata for
records from business processes and associated information systems;
R1.2.4  be able to capture metadata entered manually by an agent.
The business application should, either alone or in conjunction with other applications: Should
R1.2.5  be able to validate metadata values against pre-determined schemes and/or syn-
tactical standards;
R1.2.6  support common business formats (e.g. XML) or combinations of formats for meta-
data elements/properties;
R1.2.7  be able to capture and persistently link workflow processes associated with re-
cords, including approvals.
The business application may, either alone or in conjunction with other applications: May
R1.2.8  allow authorized agents to add annotations or notes to records as linked metadata
in accordance with business rules and policies (e.g. authorized agents may include persons
who are the subject of records).
R1.3 Records classification
The business application shall, either alone or in conjunction with other applications: Shall
R1.3.1  be able to associate records at individual object and/or aggregation level to their
business context;
R1.3.2  support documentation of changes to business context over time, retaining the
ability to link business context accurately over time.
R1.4 Managing business classification schemes
The business application may, either alone or in conjunction with other applications: May
R1.4.1  manage and maintain an approved business classification scheme.
8 © ISO 2020 – All rights reserved

R2.  Retention and disposition Obligation
R2.1  Records retention, review, transfer and destruction
The business application shall, either alone or in conjunction with other applications: Shall
R2.1.1  be able to allocate an appropriate retention and disposition period in the application
for every record and record aggregation and also allow the updating of these retention
and disposition periods if necessary, because of changing legal or business requirements;
R2.1.2  retain key metadata (as stipulated by relevant local/jurisdictional standards),
including metadata documenting disposition authorization, for the record and/or aggre-
gation following disposition of the record and/or aggregation;
R2.1.3  store the status of the record (and/or records aggregation) as ‘Deleted’ or ‘Trans-
ferred to X’ from the date of record disposition;
R2.1.4  have the ability to pause disposition, preventing records from being disposed of;
R2.1.5  report on disposition status and activity when records disposition is carried out
within the application;
R2.1.6  if required by a disposition authority, ensure that the destruction of records results
in the complete obliteration or inaccessibility of the contents of all records (including all
components of each record and any backup copies) as authorized, and that they cannot be
restored through operating system features or specialist data recovery techniques;
R2.1.7  support the capability to transfer records of continuing value together with their
metadata to an in-house organization’s archive or to an authorized third-party archiving
service.
The business application should, either alone or in conjunction with other applications: Should
R2.1.8  automatically flag records as eligible for disposition and dispose of them once their
retention periods have expired and, if required by a disposition authority, the records have
been reviewed by an authorized agent/user;
R2.1.9  restrict the operation of disposition to a business application administrator;
support a range of disposition triggers. For example:
— date of record creation;
— date of last retrieval of a record;
— opening or closing date of an aggregation of records (where applicable);
— date of demolition of a building, where records relating to the building
...

NORME ISO
INTERNATIONALE 16175-1
Deuxième édition
2020-07
Information et documentation —
Processus et exigences fonctionnelles
applicables aux logiciels de gestion
des documents d'activité —
Partie 1:
Exigences fonctionnelles et
recommandations associées pour
toute application de gestion de
documents d’activité numériques
Information and documentation — Processes and functional
requirements for software for managing records —
Part 1: Functional requirements and associated guidance for any
applications that manage digital records
Numéro de référence
©
ISO 2020
DOCUMENT PROTÉGÉ PAR COPYRIGHT
© ISO 2020
Tous droits réservés. Sauf prescription différente ou nécessité dans le contexte de sa mise en œuvre, 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, ou la diffusion sur l’internet ou sur un intranet, sans autorisation écrite préalable. Une autorisation peut
être demandée à l’ISO à l’adresse ci-après ou au comité membre de l’ISO dans le pays du demandeur.
ISO copyright office
Case postale 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Genève
Tél.: +41 22 749 01 11
E-mail: copyright@iso.org
Web: www.iso.org
Publié en Suisse
ii © ISO 2020 – Tous droits réservés

Sommaire Page
Avant-propos .v
Introduction .vi
1 Domaine d'application . 1
2 Références normatives . 1
3 Termes et définitions . 1
4 Principaux domaines de résultat et options de configuration . 2
4.1 Principaux domaines de résultat. 2
4.2 Principaux domaines de résultat en détail . 3
4.2.1 Capture et classement des documents d'activité . 3
4.2.2 Conservation et sort final des documents. 3
4.2.3 Intégrité et tenue à jour des documents d'activité . 3
4.2.4 Recherche, utilisation et partage des documents d'activité . 3
4.3 Options de configuration possibles pour gérer des documents d'activité créés dans
des applications métier . 3
5 Exigences générales applicables aux logiciels gérant des documents d'activité
numériques . 4
5.1 Généralités . 4
5.2 Hypothèses . 5
5.3 Présentation générale des exigences . 5
6 Exigences fonctionnelles modélisées pour les applications gérant des documents
d'activité numériques . 7
6.1 Regroupement des exigences . 7
6.2 Niveaux d'obligation et extensibilité des exigences . 8
6.3 Présentation des exigences en détail . 8
7 Compréhension des exigences fonctionnelles modélisées .14
7.1 Généralités .14
7.2 Réponse aux besoins relatifs aux documents d'activité dans les applications métier .14
7.2.1 Généralités .14
7.2.2 Importance des métadonnées de documents d'activité .16
7.2.3 Archivage .16
7.3 Caractéristiques de documents qu'il convient d'intégrer dans les applications métier.16
7.3.1 Généralités .16
7.3.2 Authenticité .16
7.3.3 Fiabilité .16
7.3.4 Intégrité .16
7.3.5 Aptitude à l'utilisation.17
7.4 Caractéristiques des applications métier qui gèrent des documents d'activité .17
7.4.1 Généralités .17
7.4.2 Sécurité .17
7.4.3 Conformité.17
7.4.4 Exhaustivité .17
7.4.5 Caractère systématique .17
7.5 Entités et relations en matière de gestion des documents d'activité.17
7.5.1 Modèles de relation entre entités . .17
7.5.2 Plan de classement fonctionnel.18
7.5.3 Regroupements de documents d'activité numériques .19
7.5.4 Documents d'activité numériques .19
7.5.5 Extraits .19
7.5.6 Composantes .20
8 Utilisation des exigences fonctionnelles modélisées .20
8.1 Généralités .20
8.2 Détermination des besoins d'éléments de preuve pour les événements,
les transactions et les décisions dans les applications métier (identification
des besoins de documents d'activité) .20
8.2.1 Généralités .20
8.2.2 Étape 1: identifier les exigences relatives à la justification probante de
l'activité à l'aide d'une analyse fonctionnelle .21
8.2.3 Étape 2: analyser le processus de travail .22
8.2.4 Étape 3: identifier les informations qui consignent l'élément de preuve
demandé . .22
8.2.5 Étape 4: identifier les liaisons et les dépendances .25
8.2.6 Étape 5: refléter les exigences de preuve de l'activité dans les exigences
fonctionnelles applicables aux logiciels et déterminer les options de mise
en œuvre .26
8.3 Évaluation de la conformité aux exigences fonctionnelles .26
8.3.1 Généralités .26
8.3.2 Conduite du processus d'évaluation de la conformité .26
8.4 Évaluation des risques.28
8.5 Détermination des exigences fonctionnelles applicables pour gérer des documents
d'activité dans une spécification de conception d'application .29
8.5.1 Généralités .29
8.5.2 Étape 1 — Évaluer les exigences fonctionnelles .29
8.5.3 Étape 2 — Vérifier le caractère adéquat des exigences .29
8.5.4 Étape 3 — Vérifier le caractère adéquat des niveaux d'obligation .29
8.5.5 Étape 4 — Identifier les écarts au niveau des exigences fonctionnelles .30
8.6 Évaluation des options de déploiement de fonctionnalités dans une ou plusieurs
applications logicielles .30
Annexe A (informative) Exemple de modèle d'exigences fonctionnelles .35
Annexe B (informative) Mise en correspondance des principes documentaires avec
les exigences fonctionnelles modélisées .39
Bibliographie .40
iv © ISO 2020 – Tous droits réservés

Avant-propos
L'ISO (Organisation internationale de normalisation) est une fédération mondiale d'organismes
nationaux de normalisation (comités membres de l'ISO). L'élaboration des Normes internationales est
en général confiée aux comités techniques de l'ISO. Chaque comité membre intéressé par une étude
a le droit de faire partie du comité technique créé à cet effet. Les organisations internationales,
gouvernementales et non gouvernementales, en liaison avec l'ISO participent également aux travaux.
L'ISO collabore étroitement avec la Commission électrotechnique internationale (IEC) en ce qui
concerne la normalisation électrotechnique.
Les procédures utilisées pour élaborer le présent document et celles destinées à sa mise à jour sont
décrites dans les Directives ISO/IEC, Partie 1. Il convient, en particulier de prendre note des différents
critères d'approbation requis pour les différents types de documents ISO. Le présent document a été
rédigé conformément aux règles de rédaction données dans les Directives ISO/IEC, Partie 2 (voir www
.iso .org/ directives).
L'attention est attiré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 ne saurait être tenue pour responsable
de ne pas avoir identifié de tels droits de propriété et averti de leur existence. Les détails concernant
les références aux droits de propriété intellectuelle ou autres droits analogues identifiés lors de
l'élaboration du document sont indiqués dans l'Introduction et/ou dans la liste des déclarations de
brevets reçues par l'ISO (voir www .iso .org/ brevets).
Les appellations commerciales éventuellement mentionnées dans le présent document sont données
pour information, par souci de commodité à l'intention des utilisateurs et ne sauraient constituer un
engagement.
Pour une explication de la nature volontaire des normes, la signification des termes et expressions
spécifiques de l'ISO liés à l'évaluation de la conformité, ou pour toute information au sujet de l'adhésion
de l'ISO aux principes de l’Organisation mondiale du commerce (OMC) concernant les obstacles
techniques au commerce (OTC), voir www .iso .org/ avant -propos.
Le présent document a été élaboré par le comité technique ISO/TC 46, Information et documentation,
sous-comité SC 11, Archives/Gestion des documents d'activité.
Cette deuxième édition annule et remplace la première édition (ISO 16175-1:2010), qui a fait l'objet d'une
révision technique. Les principales modifications par rapport à l'édition précédente sont les suivantes:
— la distinction entre applications dédiées à la gestion des documents d'activité et applications métier
a été supprimée. Par conséquent, l'ensemble des exigences fonctionnelles et des recommandations
associées sont regroupées dans un même document qui couvre les deux types d'applications
logicielles;
— le nombre d'exigences fonctionnelles a été considérablement réduit et simplifié afin de permettre
aux utilisateurs de se concentrer sur les aspects les plus importants des fonctionnalités logicielles;
— le texte a été mis à jour, clarifié et simplifié, et l'utilisation du jargon propre aux documents d'activité
a été supprimée autant que possible et explicitée, étant entendu que la présente norme s'adresse
principalement à des professionnels des technologies de l'information. Des schémas supplémentaires
ont été ajoutés.
Une liste de toutes les parties de la série ISO 16175 se trouve sur le site web de l'ISO.
Il convient que l'utilisateur adresse tout retour d'information ou toute question concernant le présent
document à l'organisme national de normalisation de son pays. Une liste exhaustive desdits organismes
se trouve à l'adresse www .iso .org/ fr/ members .html.
Introduction
0.1 Justification d'une gestion des documents d'activité
Une bonne gestion des documents d'activité et de l'information est essentielle au bon fonctionnement d'un
organisme. Elle soutient les fonctions et processus métier et établit la base d'une fourniture de services
efficace. Elle fournit également un mécanisme permettant aux organismes de conserver la preuve de
leurs décisions et de leurs actions afin de s'y référer ultérieurement, et de soutenir la continuité de leurs
activités. Une bonne pratique documentaire relève simplement d'une bonne pratique métier.
La gestion des documents d'activité facilite:
a) l'efficacité, en favorisant une mise à disposition rapide des informations lorsqu'elles sont
nécessaires à la prise de décision et à des fins opérationnelles, en vue de permettre une réutilisation
des informations et d'encourager l'innovation;
b) une utilisation appropriée des ressources financières, en permettant l'élimination des documents
d'activité obsolètes au moment opportun;
c) le sens des responsabilités, en permettant la création de documents d'activité complets et faisant
autorité en ce qui concerne les fonctions et processus métier;
d) la mise en conformité, en apportant la preuve que les exigences légales ont été respectées; et
e) la réduction des risques, en gérant les risques associés à une perte ou une destruction illicite des
documents d'activité, et avec une rétention excessive des dossiers, et les risques résultant qu'à un
accès inapproprié ou non autorisé à des documents d'activité.
Dans la plupart des organismes aujourd'hui, les transactions entre activités impliquent le recours à
une grande diversité d'applications logicielles. Pour que les organismes soient en mesure de compiler
et gérer des documents fiables retraçant leurs fonctions et processus métier, il est essentiel que leurs
applications métier intègrent, par conception, de solides fonctionnalités de gestion documentaire.
Il convient que la création, la conservation et d'établissement du sort final des documents d'activité
fassent partie intégrante des processus métier.
0.2  Objet du présent document
Le présent document établit des exigences fonctionnelles modélisées d'ordre général, accompagnées
des informations explicatives et des recommandations d'usage associées, concernant toute application
1)
logicielle conçue pour la gestion de documents d'activité numériques. L'ISO/TS 16175-2:— fournit des
recommandations concernant le choix/la conception, la mise en œuvre et la maintenance des logiciels
gérant des documents d'activité au sein des organismes.
Afin de présenter les exigences fonctionnelles modélisées, le présent document n'établit aucune
distinction entre les applications logicielles utilisées pour répondre à tout objectif organisationnel
et les applications qui sont spécifiquement destinées et conçues pour gérer des documents d'activité.
Les premières englobent, par exemple, les systèmes et applications de gestion de contenu d'entreprise
qui, entre autres fonctionnalités, permettent la création de documents d'activité, tels que les systèmes
de gestion de contrats, les systèmes de gestion de dossiers ou les systèmes transactionnels. Le terme
«application métier» est donc ici employé, afin de couvrir la totalité des applications qui gèrent des
documents d'activité dans le cadre de leur fonctionnement usuel. L'hypothèse retenue est que toutes
les applications métier génèreront des données servant à tracer des fonctions et processus métier à des
fins de référence ultérieure et qui, entre autres, devront créer, stocker et gérer des documents d'activité.
Le présent document vise à aider les personnes qui développent et mettent en œuvre ces applications
à identifier et déployer les exigences fonctionnelles qui contribuent à faire en sorte que les données
gérées et contenues dans de telles applications puissent servir de documents d'activité adéquats en lien
avec les fonctions et processus métier.
1) En cours d'elaboration. (Stade au moment de la publication ISO/DTR 16175-2:2020).
vi © ISO 2020 – Tous droits réservés

En plus de décrire des exigences fonctionnelles modélisées d'ordre général pour les documents d'activité
dans les applications métier, le présent document fournit des recommandations sur l'identification et la
réponse aux besoins de documents d'activité. Il vise à:
a) aider les organismes à comprendre les exigences applicables pour gérer des documents d'activité
numériques en lien avec les applications logicielles utilisées par les organismes;
b) aider les spécialistes informatiques et métier à intégrer des aspects en lien avec les documents
d'activité dans la conception et/ou l'approvisionnement d'applications; et
c) évaluer les aptitudes des applications métier existantes à gérer des documents d'activité, y compris
en facilitant l'identification des écarts ou des domaines de risque dans les fonctionnalités actuelles
desdites applications.
Le présent document fait partie d'un ensemble de recommandations de mise en œuvre d'un système
documentaire, qui vient en appui à l'ISO 15489-1, Norme internationale essentielle en matière de gestion
des documents d'activité, qui explicite l'utilité et les caractéristiques des systèmes documentaires.
0.3  Public
Le présent document s'adresse essentiellement aux professionnels responsables de la conception, du
développement, de l'approvisionnement, de l'étude et/ou de la mise en œuvre d'applications logicielles,
tels que des analystes métier, des développeurs d'applications, des architectes de solutions et des
décideurs responsables des achats de technologies de l'information. Le public inclut également les
professionnels des documents d'activité chargés de dispenser des conseils ou d'apporter une assistance
dans le cadre de ces processus.
Rôle Objectif
Architectes/concepteurs S'assurer que l'infrastructure d'applications informatiques satisfait aux exigences
de solutions en matière de documents d'activité.
Professionnels des Conseiller et accompagner l'entreprise dans la définition des exigences en matière
documents d'activité de documents d'activité.
Décideurs responsables S'assurer que les processus d'approvisionnement satisfont à ces exigences.
des achats de technologies
de l'information
Développeurs Développer des applications et assister les testeurs de systèmes d'information
d'applications au cours des phases d'élaboration de spécifications fonctionnelles et de test. Inclut
les fournisseurs et développeurs de logiciels qui souhaitent intégrer des fonction-
nalités documentaires dans leurs produits, aussi bien commerciaux que libres
(«open source»).
Analystes métier Élaborer des spécifications techniques; initier/recueillir des commentaires et
organiser des visites. Soumettre la spécification à approbation et la transmettre au
développeur. Introduire toute modification éventuelle dans la spécification après
approbation (par exemple, modifications convenues au cours de la phase de test),
si nécessaire.
Testeurs d'applications Élaborer des plans de test, des conditions/cas de test et exécuter les tests. Analyser
les résultats des tests, consigner tout échec éventuel et effectuer de nouveau des
tests une fois l'immuabilité appliquée et intégrée à l'environnement de test.
Propriétaires de processus Pour les exigences spécifiques à une solution. Vérifier et confirmer les exigences de
métier l'application qui satisfont aux objectifs métier. Communiquer les règles/processus/
exigences métier à l'analyste métier pendant les phases d'élaboration des spécifi-
cations et de test du logiciel.
Étant donné le public auquel s'adresse le présent document, l'utilisation de la terminologie
spécifiquement utilisée par les professionnels de la gestion documentaire a été réduite autant que
possible. Lorsque l'utilisation d'une telle terminologie est inévitable, elle est expliquée et/ou définie
(dans l'Article 3).
NORME INTERNATIONALE ISO 16175-1:2020(F)
Information et documentation — Processus et exigences
fonctionnelles applicables aux logiciels de gestion des
documents d'activité —
Partie 1:
Exigences fonctionnelles et recommandations associées
pour toute application de gestion de documents d’activité
numériques
1 Domaine d'application
Le présent document fournit des exigences fonctionnelles modélisées d'ordre général ainsi que des
recommandations concernant des applications logicielles conçues pour gérer des documents d'activité
numériques (y compris des copies numériques de documents sources analogiques), soit pour des
applications remplissant essentiellement cette fonction, soit pour des applications conçues pour
soutenir d'autres fonctions et processus métier et qui intègrent cette fonctionnalité.
Il ne couvre pas:
— les exigences fonctionnelles des applications de gestion de documents analogiques;
— les exigences de conception génériques, telles que la génération de rapports, l'administration des
applications et les performances;
— les exigences relatives à la conservation à long terme des documents d'activité numériques dans un
environnement de conservation dédié;
NOTE Les exigences du modèle visent à encourager le déploiement d'applications qui ne font en aucun
cas obstacle à une conservation à long terme des documents. À cet effet, certaines exigences produisent des
résultats qui viennent à l'appui d'une conservation numérique à long terme;
— des recommandations de mise en œuvre d'applications qui gèrent des enregistrements analogiques
2)
et/ou numériques. Ces conseils peuvent être trouvés dans l'ISO/TS 16175-2:— .
2 Références normatives
Les documents suivants cités dans le texte constituent, pour tout ou partie de leur contenu, des
exigences du présent document. 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 30300, Information et documentation — Systèmes de gestion des documents d'activité — Principes
essentiels et vocabulaire
3 Termes et définitions
Pour les besoins du présent document, les termes et définitions donnés dans l'ISO 30300 s'appliquent.
2) En cours d'elaboration. (Stade au moment de la publication ISO/DTR 16175-2:2020).
L'ISO et l'IEC tiennent à jour des bases de données terminologiques destinées à être utilisées en
normalisation, consultables aux adresses suivantes:
— ISO Online browsing platform: disponible à l'adresse https:// www .iso .org/ obp
— IEC Electropedia: disponible à l'adresse http:// www .electropedia .org
4 Principaux domaines de résultat et options de configuration
4.1 Principaux domaines de résultat
Les exigences fonctionnelles du présent document se concentrent sur les résultats attendus pour
garantir une gestion adéquate des documents d'activité. La manière dont ces résultats sont obtenus
dépend du type d'application utilisé. Voir Figure 1.
Figure 1 — Principaux domaines de résultat
2 © ISO 2020 – Tous droits réservés

4.2 Principaux domaines de résultat en détail
4.2.1 Capture et classement des documents d'activité
Il convient que les applications logicielles utilisées à l'appui d'activités opérationnelles ou de
transactions soient capables de capturer et/ou importer/ingérer des preuves de ces activités. Cela
suppose d'identifier des ensembles d'informations numériques tenant lieu de documents d'activité. Les
documents doivent être reliés à leur contexte métier au moyen de métadonnées.
4.2.2 Conservation et sort final des documents
Les documents d'activité doivent être conservés et demeurer accessibles aux agents habilités pendant
toute la durée nécessaire pour répondre aux besoins législatifs, communautaires et pour leur activité.
Conformément aux règles de conservation en vigueur, il convient que les documents d'activité soient
conservés d'une manière contrôlée et systématique, et de façon à pouvoir réaliser un audit, et que leur
sort final soit établi en procédant de même.
4.2.3 Intégrité et tenue à jour des documents d'activité
Il convient que les applications métier soient capables d'enregistrer toute interaction ou modification
sur les documents. Il convient que les métadonnées qui enregistrent ces interactions et ces modifications
incluent le nom de l'agent responsable, les date et heure de modification ainsi que les détails relatifs à
ces modifications. Il convient que les métadonnées soient corrélées de façon permanente aux documents
d'activité tout au long de leur existence.
4.2.4 Recherche, utilisation et partage des documents d'activité
Il convient que les applications métier facilitent la recherche, l'extraction, la restitution, le partage et la
rédaction de documents d'activité pour les agents habilités. Il convient également qu'elles prennent en
charge durablement l'interopérabilité entre divers domaines et plates-formes.
NOTE Voir le 7.5.5 pour une discussion relative à la rédaction des documents d'activité.
4.3 Options de configuration possibles pour gérer des documents d'activité créés dans
des applications métier
Il n'est pas nécessaire qu'une même application logicielle satisfasse à l'ensemble des exigences
fonctionnelles décrites dans le présent document. Il peut s'avérer plus intéressant au plan économique
de satisfaire à ces exigences en utilisant plusieurs applications logicielles qui interagissent au sein d'un
ou plusieurs organisme(s) pour en faciliter la conduite d'activité. Des recommandations relatives à ces
questions sont consultables à la Figure 2 et en 7.5. En outre, certaines exigences peuvent être satisfaites
en dehors des applications, par le biais de processus et procédures.
Avant d'utiliser les exigences fonctionnelles, il convient que les organismes évaluent la manière de
satisfaire à ces exigences: soit par le biais de mécanismes internes à l'application métier elle-même, soit
par des interactions avec des applications logicielles externes capables de fournir les fonctionnalités
nécessaires pour la gestion des documents d'activité.
Les exigences fonctionnelles obligatoires établies dans le présent document mettent en lumière les
processus documentaires essentiels qui doivent être couverts. Ces exigences peuvent être appliquées
dans le cadre d'utilisations facultatives, notamment:
a) la conception de l'application métier en vue d'exécuter les processus documentaires en interne, ou
de le faire conjointement avec les processus de travail associés;
b) l'intégration à une application dédiée à la gestion des documents d'activité, telle qu'un système de
gestion électronique de documents d'activité; ou
c) la conception d'une fonctionnalité d'exportation vers l'application métier, afin d'exporter
directement des documents et les métadonnées associées dans une application de gestion des
documents d'activité identifiée.
Figure 2 — Options de configuration possibles pour gérer des documents d'activité créés
dans des applications métier
Pour plus de détails, voir 8.6.
5 Exigences générales applicables aux logiciels gérant des documents d'activité
numériques
5.1 Généralités
Les organismes décident du type de logiciel de gestion des documents d'activité qu'il convient d'utiliser
pour soutenir des processus métier particuliers, des unités opérationnelles données ou l'organisme
dans son ensemble, et évaluent les risques liés aux processus métier lorsqu'ils prennent ce type de
décision. Le périmètre du logiciel de gestion des documents d'activité est affecté par le cadre social et
réglementaire dans lequel évolue l'organisme, par l'aptitude ou la maturité de l'organisme vis-à-vis des
documents d'activité reflétés dans ses politiques et dans la répartition des responsabilités, ainsi que
par les technologies adaptées à une utilisation organisationnelle.
4 © ISO 2020 – Tous droits réservés

Les organismes qui utilisent déjà des documents d'activité numériques pour mener et documenter
leurs activités, ou qui envisagent une dématérialisation de leurs documents d'activité, recherchent des
solutions aux problèmes associés à la gestion des documents d'activité numériques. Les décisions prises
aujourd'hui par les organismes concernant les fonctionnalités du logiciel, de même que la disposition et
la structure des informations contenues dans le logiciel, auront un impact significatif sur la préservation
à long terme des documents d'activité numériques. L'aptitude à conserver des documents d'activité
numériques au-delà de la durée de vie d'une instance unique d'un logiciel dépend étroitement de la
conception, du choix et de la configuration du logiciel, et il convient d'en tenir compte dans un contexte
de gouvernance de l'information à l'échelle de l'organisme.
Les organismes déploient des applications logicielles pour automatiser leurs activités opérationnelles et
leurs transactions. Les informations numériques générées par une application peuvent servir de seule
preuve ou de seul enregistrement de l'activité ou de la transaction, même si l'application n'a pas été
spécifiquement conçue pour gérer des documents d'activité. Sans preuve de ces activités, les organismes
s'exposent à un risque et peuvent ne pas être en mesure de répondre aux attentes de la législation ou de
la communauté, ainsi qu'aux attentes en matière de responsabilité et d'activité commerciale. En raison
de la nature dynamique et manipulable des applications métier, il peut s'avérer difficile de capturer les
documents d'activité et de gérer en continu leur fixité, authenticité, fiabilité, usage et intégrité.
Bon nombre d'applications métier génèrent et stockent des données qui peuvent faire l'objet d'une
actualisation constante (dynamiques), qui sont transformables (manipulables) et qui ne contiennent
que des données à jour (non redondantes). Bien qu'une entreprise puisse tout à fait légitimement exiger
des données dynamiques, manipulables et non redondantes, il est indispensable que ses documents
d'activité, s'ils ont vocation à servir de preuve irréfutable pour ses fonctions et processus métier, soient
fixes et inviolables. Autrement dit, il est nécessaire que les systèmes et processus soient capables de
garantir la fiabilité, l'intégrité et l'authenticité des documents d'activité afin de servir de preuve pour
des activités métier passés et comme actifs commerciaux.
Aux fins du présent document, les caractéristiques des documents faisant autorité d'activité (au sens
défini dans l'ISO 15489-1:2016, 5.2.2) peuvent s'appliquer à l'ensemble des données, documents ou
informations, quels qu'ils soient. Une approche qui repose sur les documents d'activité permet de
maintenir la traçabilité des actions documentant l'activité aussi longtemps que cela est nécessaire pour
étayer des assertions d'authenticité, de fiabilité et d'intégrité.
5.2 Hypothèses
Le présent document prend pour hypothèse:
— que des contrôles des documents d'activité (en particulier ceux identifiés dans l'Article 8) sont déjà
développés au sein de l'organisme;
— que les projets de mise en œuvre des exigences liées aux documents d'activité dans les logiciels ne
seront pas interrompus; et
— que tous les nouveaux projets de mise en œuvre de logiciels imposent l'application des exigences
définies en matière de documents d'activité.
La conception, la mise en œuvre et la maintenance des logiciels gérant des documents d'activité font
partie intégrante en continu de l'effort de gestion des documents d'activité au sein des organismes, afin
de refléter l'évolution constante des environnements technologiques, les nouveaux logiciels métier et
les modifications apportées aux processus métier.
5.3 Présentation générale des exigences
Il convient que le choix d'un logiciel de création ou de gestion de documents d'activité numériques soit
effectué en accord avec les exigences fonctionnelles établies. Les exigences générales ici incluses sont
conformes aux principes de gestion des documents d'activité énoncés à l'Article 4 de l'ISO 15489-1:2016.
L'Article 6 fournit des exigences fonctionnelles plus détaillées concernant les logiciels de création ou de
gestion de documents d'activité numériques.
a) Il convient que le logiciel prenne en charge la gestion des documents d'activité numériques comme
composante essentielle du processus métier.
Lors de l'automatisation d'un processus métier, il convient que le logiciel satisfasse aux exigences
relatives aux documents d'activité.
b) Il convient que le logiciel gérant des documents d'activité numériques maintienne des liens
permanents avec le contexte opérationnel.
Il est nécessaire de comprendre le contexte opérationnel des documents d'activité pour permettre
une interprétation précise de leur contenu. Il convient que le logiciel établisse en permanence un
lien avec le contexte opérationnel spécifique dans lequel sont créés les documents d'activité, et qu'il
maintienne ce lien dans le temps.
c) Il convient que le logiciel gérant des documents d'activité numériques soit capable de capturer des
métadonnées qui, dans la mesure du possible, sont générées automatiquement.
Il convient de concevoir et mettre en œuvre le logiciel de manière à permettre autant que possible
une affectation automatique des métadonnées de documents d'activité à leur point de capture, pour
offrir à l'utilisateur final une fonction de modification avant la capture, si nécessaire. Il convient
que les métadonnées de traitement des documents d'activité soient automatiquement générées et
capturées au fil de l'utilisation du système.
d) Il convient de privilégier un logiciel convivial qui simplifie la création et la capture de documents
d'activité.
Il convient de concevoir un logiciel qui automatise la gestion des documents d'activité de sorte que
cette activité soit essentiellement invisible pour les utilisateurs finaux. Les techniques employées
à cette fin peuvent inclure la consignation automatique dans des fichiers de journalisation des
événements survenus sur les documents d'activité à tous les niveaux d'agrégation, ou encore
la réduction à un niveau minimal des exigences de l'utilisateur final afin d'interagir avec des
fonctionnalités complexes spécifiques aux exigences des professionnels de la gestion des documents
d'activité.
e) Il convient que le logiciel prenne en charge une interopérabilité dans le temps entre divers domaines
et plates-formes.
Les documents d'activité numériques sont souvent soumis à des exigences opérationnelles ou
juridiques qui imposent des durées de conservation pouvant dépasser la durée de vie du matériel
ou du logiciel qui les a créés. Il convient que le logiciel soit en mesure de présenter des documents
d'activité d'une manière qui en préserve les métadonnées et l'usage, tout en facilitant leur conversion
dans de nouveaux formats et/ou leur migration vers d'autres plates-formes technologiques.
f) Il convient que le logiciel intègre une fonction d'importation et d'exportation en masse.
Il est souvent nécessaire que les documents d'activité aient une durée de vie plus longue que celle
du système dans lequel ils ont été initialement créés, capturés et gérés. Il convient que le logiciel de
gestion des documents d'activité incorpore des fonctions de reformatage en masse dans le cadre
d'une fonctionnalité d'importation (ingestion) ou d'exportation ou, au moins, par le biais d'un
mécanisme non propriétaire de codage des métadonnées de documents d'activité.
g) Il convient que le logiciel conserve les documents d'activité dans un environnement sécurisé.
Il convient que le logiciel ne permette aucun accès ou modification non autorisé aux documents
d'activité ou aux métadonnées des documents d'activité. Lorsque des modifications autorisées
sont effectuées, il convient que celles-ci soient entièrement documentées. Il convient d'identifier
les informations à caractère confidentiel ou qui contiennent des informations personnelles et de
déployer des mécanismes pour garantir des protections d'accès et d'utilisation appropriées.
6 © ISO 2020 – Tous droits réservés

h) Il convient que le logiciel prenne en charge le sort final des documents d'activité de manière gérée
et systématique, et de façon à pouvoir réaliser un audit.
Il est nécessaire que le logiciel soit capable d'établir le sort final des documents d'activité d'une
manière systématique et de façon à pouvoir réaliser un audit, conformément aux exigences
opérationnelles ou juridiques et aux attentes sociétales et communautaires.
i) Il convient que le logiciel repose autant que possible sur des normes ouvertes, robustes et neutres
sur le plan technologique.
De nombreux produits logiciels qui créent ou gèrent des documents d'activité sont développés au
moyen d'un code propriétaire. Les dépendances matérielles ou logicielles peuvent avoir des effets
indésirables sur l'accès aux documents d'activité et sur leur conservation à long terme. Il convient
donc d'utiliser des normes ouvertes, robustes et neutres sur le plan technologique.
6 Exigences fonctionnelles modélisées pour les applications gérant
des documents d'activité numériques
6.1 Regroupement des exigences
NOTE Voir 6.3.
E1. Capture et classement
E1.1. Création, capture et import des documents
E1.2. Capture des métadonnées de documents
E1.3. Classement des documents
E1.4. Gestion des plans de classement fonctionnel
E2. Conservation et sort final
E2.1. Conservation, examen, transfert et destruction des documents
E2.2. Migration et exportation des documents
E3. Intégrité et tenue à jour
E3.1. Authentification et sécurité des documents
E3.2. Stockage, création de rapports et gestion des métadonnées
E4. Recherche, utilisation et partage
E4.1. Recherche, extraction, présentation, utilisation et interopérabilité
E4.2. Restrictions et autorisations d'accès
E4.3. Reproduction, extraction et rédaction
...