Writing World Class Standards
Standards-making is a collaborave acvity which benets from
the sharing of knowledge and experse. If you have any comments,
examples or addional content which might improve the usefulness
of this guide, please contact: info@etsi.org.
Contents
Contents 1
Introducon 2
What is a world class standard? 3
What is a standard? 3
What makes a standard ‘world class’? 3
A response to real needs in a mely manner 3
Complete and accurate 3
Easy to understand 4
Clear and unambiguous requirements 4
Validated 4
Maintained 4
Before you get started 5
Who is your standard intended for? 5
The content of a standard 5
Choosing the type of standard 6
Harmonised Standards 7
System Reference Documents 7
Basic steps of standards development 8
Create the Work Item 8
Develop the dra standard 9
Validate the dra 9
Submit the dra for editorial checking 10
Approve and publish the standard 10
Maintain and evolve the standard 10
Dealing with sets of standards 11
Develop a framework 11
Adopt a systemac approach 11
How to dra a good standard 12
Use the ETSI pre-dened deliverable structure 12
Dra the content of the pre-dened elements 12
Follow the style guide 16
The technical content of the standard –
How to write good requirements 17
Some basic principles 17
Use of English 18
Shall, should and may 19
Structuring the requirements 20
Stac and dynamic requirements 21
Pung requirements into context 21
Condions under which a requirement applies 22
Specifying alternaves to condional requirements 22
Combining requirements 23
Ensuring that your requirements are testable 23
Expressing oponal requirements 24
Oponal features 24
Proles 24
Specifying requirements with specialized notaons 25
Specifying interacons and use cases 25
Specifying messages 25
Specifying the behaviour of communicang systems 25
Validaon of standards 26
Peer review 26
Interoperability events 26
Implicit methods of validaon 26
Maintenance and evoluon of standards 27
Maintenance of standards 27
Evoluon of standards 27
Maintaining compability 27
Maintaining numbering in new versions of standards 28
Test specicaons 29
Closing remarks 30
You are not alone! 30
References and useful resources 31
ETSI resources 31
3GPP™ resources 31
oneM2M resources 31
ETSI Guides on standards-wring,
tesng and validaon 31
ITU-T three-stage process 31
Specicaon languages 31
Other resources 31
1
TM
ETSI standards are used the world over and have enabled
technologies which have changed the way people live, work
and do business. Today we produce about 2 500 deliverables
every year and our work impacts almost every area of
modern living. A major element in our producon includes
the standards developed in our global partnership projects
3GPP and oneM2M. Our Industry Specicaon Groups also
contribute with their specicaons and reports.
This success owes much to the high quality of the standards
we produce. We have earned a reputaon for producing
world class standards – a reputaon we work hard to
maintain. Wring good standards is not easy. Wring the
sort of world class standards for which ETSI is well known
is a complex and challenging task. Over the years, we have
developed working methods and detailed draing rules to
ensure the quality and the reliability of our standards.
This document explains how to write ETSI standards. It starts
with the basics for readers who are new to standardizaon
or new to ETSI – what is a standard?
It then goes on with guidance on how to choose the right
type of standard, how to structure a standard and dra
it, how to express the technical requirements so that you
achieve your goals and, nally, how to validate, test and
maintain a standard.
This guide is intended for anyone involved in creang ETSI,
3GPP and oneM2M standards. The target audience includes
Rapporteurs, Editors, members draing standards or
contribuons, commiee ocials and Specialist Task Forces.
Introduction
The guide is also intended for ETSI Secretariat sta supporng
the standardisaon work. There is something for everyone –
even the most experienced among us can benet from being
reminded of the essenals of good standards wring.
By following this guide, you will produce standards that are
accurate and complete, easy to read, clear, unambiguous
and consistent – in short, you too will write world class
standards.
2
What is a standard?
A standard is a collecon of the minimum requirements
necessary for something to:
• Co-exist and interoperate correctly with another
• Meet naonal and internaonal regulaons
• Operate safely without causing harm to people or
equipment.
What makes a standard
‘world class’?
It is not easy to say exactly what makes one standard beer
than another, but the following points are probably the most
important:
• A world class standard should have well-dened
objecves that respond to real needs in a mely
manner.
• Its technical content should be complete and accurate.
• It should be easy to understand (or as easy as the
subject maer allows!) and easy to implement.
• Its requirements should be expressed clearly and
unambiguously.
• It should be validated.
• It should be well-maintained.
A response to real needs in
a timely manner
A standard will be widely used if it has well-dened objecves
that meet real needs in a mely manner. A standard produced
too early may quickly become out of date because of a rapid
evoluon of the technology. On the other hand, a standard
that is published too late risks being ignored in favour of
earlier, compeng standards or proprietary soluons.
Like so much else in standards-making, geng the ming
right needs experience and good judgement – in this case,
awareness of the state of maturity of the technology being
specied. Remember that the type of standard that you
choose to produce may aect its ming, because of the
dierent approval processes involved.
Some formal denitions of
a standard
‘A document established by consensus and approved
by a recognized body that provides for common and
repeated use, rules, guidelines or characteriscs for
acvies or their results, aimed at the achievement
of the opmum degree of order in a given context.’
- ISO/IEC Guide 2:1996
‘A technical specicaon, adopted by a recognized
standardizaon body, for repeated or connuous
applicaon, with which compliance is not
compulsory, and which is one of the following:
• ‘internaonal standard’ means a standard
adopted by an internaonal standardizaon
body
• ‘European standard’ means a standard adopted
by a European standardizaon organizaon
• ‘harmonised standard’ means a European
standard adopted on the basis of a request
made by the Commission for the applicaon of
Union harmonizaon legislaon
• ‘naonal standard’ means a standard adopted
by a naonal standardizaon body.’
- Council Regulaon 1025/2012/EC
What is a world class
standard?
Complete and accurate
To be judged world class, a standard should accurately specify
all the requirements necessary to achieve its objecves and
only include essenal supporng informaon.
3
Easy to understand
A standard should be easy to understand and implement.
This applies both to the way you structure the document
and how you express individual requirements. For example,
a clear structure can help readers follow the document,
while good construcon and expression of the requirements
will make them easier to understand and implement. It also
helps if there is a clear disncon between the normave
parts (those parts which tell the readers exactly what they
must do to comply with the standard) and the informave
parts (the descripve material that is there to improve
general understanding of the concept). Unnecessary detail
or informave text can make it dicult for readers to idenfy
and understand what is really essenal to ensure compliance.
Be careful in your use of English. The contributors and users
of your standard may not all be nave English speakers and
may have varying language skills. To produce a world class
standard, you should aim to create a document that can be
understood by all readers.
Clear and unambiguous
requirements
Requirements specify the individual characteriscs that a
system or product must implement if it is to fully comply
with the standard. Each requirement should be:
• Necessary: it should specify only what is required
to meet its objecves, and not impose a parcular
approach to implementaon.
• Unambiguous: it should be impossible to interpret the
normave parts of the standard in more than one way.
• Complete: the requirement should contain all the
informaon necessary to understand that requirement,
either directly or by reference to other documents.
The reader of a standard should not need to make
assumpons about the implementaon of any
requirement.
• Precise: the requirement should be worded clearly and
exactly, without unnecessary detail that might confuse
the reader.
• Well-structured: the individual elements of the
requirement should all be included in an appropriate
and easy-to-read manner.
• Consistent: there should be no contradicon between
dierent requirements within the standard, nor with
other related standards.
• Testable: there should be clear and obvious means of
demonstrang that an implementaon complies with
the requirement.
Validated
The purpose of validaon is to conrm that the requirements
expressed in a standard do, in fact, achieve their objecves
and are t for purpose. Validaon assures the quality
expected of a world class standard.
Maintained
ETSI standards are ‘living’ documents that develop over
me in order to remain relevant to technological progress
and changing needs and circumstances. To accommodate
this and to maintain the high quality of our standards,
the responsible commiee should plan a programme of
maintenance and evoluon for each of its standards.
Normave = prescripve = how to comply with the
standard
Informave = descripve = help with conceptual
understanding
Requirement = the criteria to be fullled to comply
with the standard
4
Who is your standard intended for?
In most instances, a standard is produced mainly for engineers
who will implement it, and procurement specialists who will
expect suppliers’ products to conform to it. Oen a standard
is used to formalize the technical aspects of a procurement
agreement or contract. Other groups may also use the
standard. For example, regulators may use the standard to
dene market access rules.
The rst thing to do when wring a standard is to idenfy
how it is likely to be used, and by whom. Then you will
be able to idenfy how to meet their needs. In parcular,
bear in mind that the standard must be understandable by
readers who have not been involved in its preparaon, so
you will need to state things clearly and fully.
The content of a standard
Standards consist of a series of requirements to be met when
implemenng a product or service. Typically, requirements
address:
• Equipment behaviour which can be observed at a
dened, accessible interface, such as a protocol or
service.
• Architectures: communicaon and network
architectures usually specify the funconal (or logical)
environment where the standard is expected to be
implemented. Although abstract architectures do not
generally specify testable or measurable requirements,
they do dene requirements (such as those related to
a reference point) that should be complied with by the
writers of protocol standards.
• Physical characteriscs that can be measured, such as
dimensions, voltage, frequency or colour.
• Policy requirements on operaon and management
pracces: for example, related to the process of issuing
qualied cercates by Cercaon Authories.
• Test specicaons: detailed specicaons of the tests
that would demonstrate whether an implementaon
conforms to a standard, or of the tests that could
be used to check that two implementaons are
interoperable.
• Methodologies applicable to ETSI standardizaon
(which may also be used more widely).
Do not try to standardize implementaon details or
constraints. Implementers need to know only what to
implement and you must give them the freedom to achieve
this in the way that suits them best.
Requirements and provisions
Standards specify requirements, recommendaons
and permissible acons of some kind. Collecvely,
these are referred to as provisions.
For clarity, in this document we use the term
requirement in a general sense to mean provision.
Before you get started
5
Choosing the type of standard
ETSI produces several types of standards: each has its own
parcular purpose and each requires a dierent process
of approval. The table below summarizes these dierent
types of standard; the ETSI Direcves and the Rapporteurs’
Guide provide more complete explanaons and will help you
determine which type is appropriate for specic situaons.
You should consider carefully which type of standard to create
since your choice determines maers such as the extent
of approval and the speed of publicaon. The approval of
Technical Specicaons can be quite rapid, typically carried
out in a Technical Commiee meeng or by correspondence.
By contrast, ETSI Standards (ES) and (in parcular) European
Standards (EN) usually take longer to approve.
Other factors that inuence the speed of approval include
the technical complexity of the document and the size of the
approving community. Issues such as the strength of diverging
views will have an impact as well. Misunderstandings and
lack of clarity in the text can also hold things up at the
approval stage and in the nal pre-publicaon eding; by
adopng pracces that build high quality into the dra, you
will help to minimize these delays.
Choosing the right type
of standard
When deciding the appropriate type of a standard
with normave provisions, you should focus on the
stakeholders who will be involved in approving the
document. The approval process is likely to be more
complex and me-consuming if the stakeholder
group is large. You should therefore opt for
deliverables that involve a large stakeholder group
only when really necessary.
Within ETSI and in ETSI partnership projects, the
most commonly used standard type containing
normave provisions is the Technical Specicaon
(TS), which requires approval by just the Technical
Commiee that created it. You should consider
whether this is sucient in your case.
Standard type Approved by Content
ETSI Technical Specicaon (TS) Responsible ETSI Technical Commiee Normave
ETSI Standard (ES) ETSI membership Normave
European Standard (EN)
(which may be designated as a
Harmonised Standard (HS))
Dra adopted by a responsible ETSI
Technical Commiee and approved
by European Naonal Standards
Organizaons
Normave, intended to be transposed
into naonal standards of European
Union (EU) Member States, as well as
states in EFTA and CEPT.
ETSI Technical Report (TR) Responsible ETSI Technical Commiee Informave – the preferred type of
informave deliverable unless other
consideraons demand an EG (or SR)
ETSI Guide (EG) ETSI membership Informave – guidance for the ETSI
Technical Organizaon in general
ETSI Special Report (SR) Responsible ETSI Technical Commiee Informave – informaon made publicly
available for reference purposes
ETSI Group Specicaon (GS) Responsible ETSI Industry Specicaon
Group
Normave
ETSI Group Report (GR) Responsible ETSI Industry Specicaon
Group
Informave
6
Harmonised Standards
Harmonised Standards are European Standards (EN) with
a special status. Produced by one or more of the European
Standards Organizaons in response to a Standardisaon
Request (aka mandate) issued by the European Commission
(EC), their purpose is to provide the technical detail necessary
to achieve the ‘essenal requirements’ of an EU Direcve.
These ‘essenal requirements’ are usually wrien in very
non-specic terms (e.g. “the equipment shall not cause
injury to the user”) so the Harmonised Standards dene, in
detail, how those requirements are to be met.
ETSI supports various EU Direcves through the producon
of Harmonised Standards. A rather large poron are those
concerning radio equipment, Electromagnec Compability
(EMC) and access to emergency services, however there are
others responding to the Accessibility Direcve, EU Single
European Sky direcves as well as the Marine Equipment
Direcve and the Medical Equipment Direcve. Harmonised
Standards enable manufacturers, suppliers, network
operators and others to claim a product’s compliance with
the relevant Direcves. These products may then be placed
on the market and used in all Member States of the European
Union.
ETSI Guide EG 203 336 provides guidance on wring
Harmonised Standards under Direcve 2014/53/EU (Radio
Equipment Direcve (RED)).
System Reference Documents
ETSI produces a specic type of Technical Report called
a ‘System Reference document’ (SRdoc). These provide
technical, legal and economic background to new radio
systems, services or applicaons. They advise on the need
for an allocaon of spectrum, in parcular either when a
change in the current frequency designaon or its usage,
or a change in the regulatory framework for the proposed
band(s) is needed to accommodate a new radio system or
service.
7
Basic steps of standards
development
The development process can be quite complex within a
standardizaon body such as ETSI. Not only do the diverse
interests of our members have to be respected but at
mes other constraints, such as those imposed by EC
Standardisaon Requests (aka Mandates). ETSI’s Standards
Development Process has been created to guide and manage
the draing of standards in a way that keeps the intended
purpose of the standard in focus, whilst addressing the
dierent views and changes of direcon that are inevitable
in any collaborave development task.
The key stages of the standards development process are to:
1. Create the Work Item
2. Develop the dra standard
3. Validate the dra
4. Submit the dra for editorial checking
5. Approve and publish the standard
6. Maintain and evolve the standard
At each stage there is the possibility of feedback into the
draing process. This can provide enormous benets for the
quality of the nal document and helps to maintain its ‘world
class’ status.
Create the Work Item
“If you don’t know where you are going, you may have
diculty geng there!”
One of the most important steps towards producing a ‘good’
standard is the preparaon of the Work Item proposal. If
this is well-wrien it provides a strong and clear plaorm
from which the standard can be developed. On the other
hand, a badly constructed or incomplete Work Item will
make it dicult for the authors and reviewers to know
what the content should be. Technical Ocers can provide
their commiees with considerable assistance, as well as
background knowledge, to simplify the task of developing a
‘good’ Work Item proposal.
Approval and
Publication
Editorial
Check
Validation and
Review
Drafting
Maintenance and evolution resulting in a new Work Item for a
revision of standard
Feedback
Feedback
Feedback
Work Item
Published
Standard
Implementation
and use
8
As you start to develop the Work Item proposal, you should
consider the following:
• Is the document to be normave or informave? What
type of deliverable should it be (EN, ES, TS, etc…)?
• What will the tle of the standard be? It should give
a concise indicaon of the content. If appropriate, it
should make clear to which grouping of standards the
document belongs. It should be simple; any necessary
detail, such as constraints and areas of applicaon, can
be provided in the Scope.
• What is the Scope of the work? The Work Item Scope
should specify the intended contents of the deliverable.
- The Work Item Scope helps to keep the standard
writers focused on what they are creang, whilst the
document’s Scope clause provides the reader with a
short but clear statement of what is actually included
in a standard and the area of applicaon.
- The Work Item Scope and the Scope clause of the
standard may not be the same as they serve dierent
purposes. However, the two Scopes should not
contradict one another!
- For a new standard (i.e. not a revision), it should be
possible to use the Work Item Scope as the basis for
the document’s Scope clause.
- For the revision of an exisng standard, the Work Item
Scope need only specify the addional draing to be
undertaken. So it is unlikely that it will be possible
to transpose the Work Item Scope directly into the
standard. However, if the revision modies the original
Scope of the standard then, of course, the document
Scope clause should be changed as necessary.
• Is the Work Item part of a Hierarchical Work Item? If so,
the Work Item descripon should make it clear where
the proposed document ts in the hierarchy.
• When is the deliverable likely to be completed? The
schedule of milestones should be realisc. It should
take account of the Scope of the document being
draed and the resources that will be available during
development.
Hierarchical Work Items
Commiees may decide to organize or present all
or part of their work programme in a hierarchical
manner. The hierarchy may be organized by any
criteria they decide (e.g. ‘release’, ‘technical area’,
‘project’, ‘stage’, etc.).
ETSI Drafting Rules
In order to encourage consistency, ETSI has
established a basic structure for all its standards,
described in the ETSI Draing Rules (EDR). Other
internaonal standards organizaons have similar
rules. You can download the Draing Rules in a
useful format at hps://portal.etsi.org/Services/
editHelp!.aspx
• Validaon: The quality of a standard is likely to
be improved considerably if you include acvies
to validate its content as it evolves. Will you need
addional acvies such as the creaon of test
specicaons or conformance tests, which may need
to be available by the me the standard has been
implemented as commercial products? Remember to
include these acvies in your schedule. EG 202 107
provides guidance on how to plan for validaon and
tesng in the standards-making process.
• Who is responsible for producing the document?
Have the Technical Commiee, Working Group and
Rapporteur been idened and agreed? Is there a
commitment from members? Is a Specialist Task Force
(STF) needed?
Develop the draft standard
You can help to enhance the quality of your standard by
adopng a structured approach in its draing. Your aim is to
achieve a document that is clear, unambiguous, complete and
accurate. It is vital to write requirements in well-constructed
English and to avoid unnecessary narrave and tutorial text.
Specialized notaons such as ASN.1 and graphical forms of
specicaon such as State Charts and Sequence Diagrams
are also valuable in improving understanding and precision.
As you develop the standard, you should also keep in mind
that every requirement that you include needs to be testable.
Tesng is used to demonstrate that each requirement has
been correctly implemented.
Validate the draft
The development process of any standard should already
include document reviews, even if only as part of the approval
cycle. Any secondary acvity that involves close scruny of the
standard (such as test development, implementaon of the
standard in products and the producon of implementaon
and design guides related to the standard) will provide useful
feedback on deciencies, inconsistencies and ambiguies.
The only opon that you should not consider is not validang
the standard at all!
9
Submit the draft for editorial
checking
The Technical Ocer of your commiee has a good awareness
of the technology to which your standard relates. He or she
also has in-depth knowledge of the various ETSI rules and
procedures that help to ensure high-quality standards. The
Technical Ocer is therefore a valuable partner to you in
your standards-making task and you should not hesitate to
consult him or her regularly as you develop your dra. The
Technical Ocer is there to support and advise you.
In addion, the ETSI Secretariat has centres of experse that
can provide specialist help when needed. Among these is
the editHelp! Service which provides advice and tools for the
writers of ETSI standards, as well as overseeing the approval
and publicaon of the standards.
The editHelp! Service has an essenal role in working with you
to nalize your dra. Once you and your commiee consider
your dra standard to be reasonably complete, you should
send it to the editHelp! Service (normally via your Technical
Ocer, unless other arrangements have been made in your
commiee – your Technical Ocer can tell you). editHelp!
will check many dierent aspects of the eding, including the
use of English, the validity and consistency of the references,
the abbreviaons and the denions of terms.
This acvity oen follows approval by the technical
commiee, but you are also welcome to submit your dra
to editHelp! earlier during its development, for example to
make sure that it is following the correct shape and style.
However, do not treat the editHelp! Service as a substute for
the proper preparaon of a standard! The service will suggest
correcons to structure, presentaon and consistency but
does not evaluate the technical content.
Remember that your Technical Ocer is your key interface to
editHelp! and other Secretariat services.
Approve and publish the standard
The approval process prior to publicaon is dierent for
each type of standard. The Technical Ocer will manage the
passage of the dra through each stage of approval. ETSI’s
web-based vong tools make it easy for our members and
others to record comments and objecons: this feedback
is very valuable for improving the technical quality of the
standard and should be considered as part of the validaon
process.
Maintain and evolve the standard
Standards require on-going maintenance that needs to be
planned for and managed. The Scope of the revision may
include such maers as the correcon of defects found aer
publicaon and alignment with changes in related standards.
10
Develop a framework
If you are involved in the producon of a set of standards,
you may nd it helpful to agree with your fellow writers to
produce a framework document. This will provide guidelines
for the writers of all the standards in the set to achieve a
broad degree of commonality and consistency in their
presentaon. There are no specic requirements for what
should be included in a framework document but you might
want to include the following:
• Document structure
• Requirement numbering format
• Naming convenons
• Recommendaons on the use of specialized languages
• Recommendaons on the use of tools
• Idencaon of supporng material
Dealing with sets
of standards
Adopt a systematic approach
Complex subjects require parcularly careful organizaon.
The general principles of the well-proven three-stage
approach described in ITU Recommendaon I.130 are
parcularly useful in encouraging and facilitang a systemac
method, especially for the development of protocol and
service standards. This approach can also be adapted for
other specicaons. However, some techniques in I.130 may
have been superseded; these will need to be aligned with
current pracces.
The Recommendaon proposes a design process divided into
three stages of acvity, typically resulng in a corresponding
series of specicaons:
Stage 1 Specify objecves from the user’s perspecve
Stage 2 Develop a funconal model to meet those objecves
Stage 3 Develop a specicaon of the detailed
implementaon requirements.
11
Clarity and consistency are essenal characteriscs of a
world class standard. You can achieve them by taking a logical
approach to the document’s structure and content, and by
respecng well-established standards-wring pracces.
Developing standards is similar to the task of engineering a
product. Both are only eecve and ecient if the overall
process is systemac, and both require a top-down approach;
any other approach is unlikely to deliver what was intended.
Use the ETSI pre-dened
deliverable structure
Using a consistent structure for a standard will not only
help you, the writer, to collect essenal informaon and
requirements together in a logical manner, it will also help
the reader to navigate through the document. Consistency
improves the quality of the standard as well as the percepon
of quality. For a set of associated standards, consistency
between the standards makes them easier to read and
implement.
ETSI has also produced skeleton documents for each
deliverable type and these can help you considerably in
your task. You can download them from the editHelp! pages
on the ETSI Portal (hp://portal.etsi.org/edithelp/home.
asp). These skeletons contain all the obligatory deliverable
elements as well as some oponal ones, in the required
order:
• Front cover
• Table of contents
• Intellectual Property Rights
• Foreword
• Introducon (oponal)
• Scope
• References
• Abbreviaons, Symbols and Denions
These pre-dened elements set the context for the standard
and dene the terms the reader will need to understand the
rest of the document. They are followed by the technical
content – the heart of the standard.
You must not write any requirements in these pre-dened
elements.
How to draft a good
standard
Draft the content of
the pre-dened elements
A summary of what goes into each element is described
below; you can nd full details in the ETSI Draing Rules and
the relevant skeleton document.
Foreword
The Foreword starts by menoning the document type and
the commiee that prepared the document. If appropriate
you may also include other informaon that would be helpful
to the reader, such as:
• The relaonship between this standard and other
documents.
• Standards that this standard supersedes or replaces.
• Signicant technical changes from a previous version of
the standard.
• The existence of an electronic aachment.
For European Standards (ENs), the Secretariat will insert a
table containing the transposion dates. The Secretariat will
also add the special text required if the document is to be a
Harmonised Standard.
There are addional rules if the document is part of a mul-
part standard.
12
The example Foreword below contains most of the above elements.
Foreword
This Harmonised European Standard (EN) has been produced by ETSI Technical Commiee Electromagnec compability and
Radio spectrum Maers (ERM).
The present document has been prepared under the Commission’s standardisaon request C(2015) 5376 nal [i.1] to provide
one voluntary means of conforming to the essenal requirements of Direcve 2014/53/EU on the harmonisaon of the laws of
the Member States relang to the making available on the market of radio equipment and repealing Direcve 1999/5/EC [i.2].
Once the present document is cited in the Ocial Journal of the European Union under that Direcve, compliance with the
normave clauses of the present document given in Table A.1 confers, within the limits of the scope of the present document,
a presumpon of conformity with the corresponding essenal requirements of that Direcve, and associated EFTA regulaons.
Naonal transposion dates
Date of adopon of this EN: 28 May 2019
Date of latest announcement of this EN (doa): 31 August 2019
Date of latest publicaon of new Naonal Standard or endorsement of this EN (dop/e): 29 February 2020
Date of withdrawal of any conicng Naonal Standard (dow): 28 February 2021
Introduction
The Introducon is oponal but can help readers to understand the document. The Introducon may give specic informaon
or commentary about the technical content of the deliverable, and the reasons prompng its preparaon.
For example:
Introduction
Electronic commerce has emerged as a frequent way of doing business between companies across local, wide area and global
networks. Trust in this way of doing business is essenal for the success and connued development of electronic commerce.
It is therefore important that companies using this electronic means of doing business have suitable security controls and
mechanisms in place to protect their transacons and to ensure trust and condence with their business partners. In this
respect digital signatures are an important security component that can be used to protect informaon and provide trust in
electronic business.
The present document is intended to cover digital signatures supported by PKI and public key cercates, and aims to meet
the general requirements of the internaonal community to provide trust and condence in electronic transacons, including,
amongst other, applicable requirements from Regulaon (EU) No 910/2014 [i.1].
The present document can be used for any transacon between an individual and a company, between two companies, between
an individual and a governmental body, etc. The present document is independent of any environment. It can be applied to any
environment e.g. smart cards, SIM cards, special programs for electronic signatures, etc.
The present document is part of a raonalized framework of standards (see ETSI TR 119 000 [i.10]). ETSI TR 119 100 [i.11]
provides guidance on how to use the present document within the aforemenoned framework.
13
Scope of a standard
The aim of the Scope clause is to provide readers with a
succinct, factual statement of the purpose of the document.
This may include the subject of the standard, the area
of applicability, the type of product or service and other
relevant informaon such as the relaonship of the standard
to other standards – as long as such details clarify the Scope
of your document.
You should review the Scope text regularly as draing
proceeds to ensure that it remains correct, complete and in
alignment with the Work Item scope. Once the standard is
completed, you may want to align the Work Item Scope with
the scope of the standard.
The Scope
The ETSI Draing Rules provide guidance on how to
structure the Scope:
The present document
- species the funconal requirements for …
a method of …
the characteriscs of …
- establishes a system for …
general principles for …
- gives guidelines for …
- gives terms and denions …
The present document is applicable to …
1 Scope
The present document species the formats for messages that are produced and handled by a Registered Electronic Mail (REM)
service according to the concepts and semanc dened in ETSI EN 319 522 parts 1 [7] and 2 [8] and ETSI EN 319 532 parts 1
[10] and 2 [11]. More specically:
a) Species how the general ERDS concepts like user content and metadata are idened and mapped in the standard
email structure.
b) Species how the aforemenoned concepts are mapped in the REM service messaging structures.
c) Species how the ERDS evidence set is plugged inside the REM service messaging structures.
d) Species addional mechanisms like digital signature and other security controls.
14
References and Bibliography
References form a vital part of a standard and should be
handled carefully and consistently. If your standard has both
normave and informave references, you should include
them in two disnct sub-clauses within the References
clause:
• Normave references idenfy other documents that
are directly referenced within normave provisions in
the standard. They are eecvely part of the standard,
even though they are actually another document, so
it is imperave that you ensure that all referenced
documents are publicly available!
• Informave references idenfy other documents that
are directly referenced from within the main body of
the standard purely to provide addional informaon
for the purposes of juscaon or claricaon. To full
their purpose, they should also be publicly available.
References can relate to either a specic edion of a
document or, if the date and version are omied, they relate
generically to the latest edion. Be careful! If the user of the
standard uses a dierent version of the referenced document
to what you intended, their implementaon may be wrong!
As a rule, references should always be made to specic
clauses, paragraphs, gures or tables in another document.
This is of parcular importance for normave references.
You may be aware of documents that are not referred to
within the standard but which might assist the readers.
You can help your readers by lisng these documents in a
Bibliography annex.
Denitions, symbols and abbreviations
If your standard is to be implemented correctly, you need
your readers to understand it in exactly the same way that
you do. In order to avoid misunderstanding, you should
dene terms that are included in requirements – this is
parcularly important if those terms are specialized or not
widely known.
You should also dene terms that are used regularly in the
document and, where appropriate, idenfy a dened term by
an abbreviaon. This helps the reader, as well as simplifying
your task because it allows you to refer repeatedly to objects
or concepts without having to describe them in detail each
me you menon them.
Where you have dened a term or abbreviaon, you should
use it – always and consistently. For example, it could be
confusing (and certainly irritang!) to read a standard that
somemes refers to “ADSL”, somemes to “Asymmetric
Digital Subscriber Line”, somemes to “Asymmetric Digital
Subscriber Loop” and somemes to “a digital line with
dierent bit rates in the uplink and downlink”. Having
dened the term, “Asymmetric Digital Subscriber Line”, and
its abbreviaon, “ADSL”, you should use either the full term
or the abbreviaon whenever the concept is menoned.
Denitions
If you use any specialist terms in the standard that
require specic interpretaon you should list and
dene them in the Denions clause. Each entry in
the clause should comprise the term followed by a
denion of that term, for example:
interface: common boundary between two
associated systems
The denion of a term should never include a
requirement.
Symbols
All technical symbols (including mathemacal and
scienc symbols and units) used in the standard
should be listed in the Symbols clause. Each entry
should comprise the symbol and a very brief
explanaon of what it represents, for example:
Ro reference distance
µ microns
ƛ wavelength
Abbreviations
All abbreviaons (including acronyms) used in the
standard should be listed in the Abbreviaons
clause. Each entry should comprise the abbreviaon
itself and the corresponding full term, for example:
IPv6 Internet Protocol version 6
ITS Intelligent Transport System
ITS-S ITS Staon
RX Receiver
TX Transmier
15
In your standard you should provide lists of the terms,
symbols and abbreviaons that you have used in the
document, together with the meanings that you have given
them. As far as possible of course, those meanings should
also be the same as those used in related standards and,
where appropriate, throughout the industry. This need
for consistency applies not just to individual documents
but across related standards, which is why it can be
useful to create a separate document that contains all the
abbreviaons, symbols and denions of terms used within
a set of related standards. It also avoids wasng your eort,
and that of other standards-writers, in dening terms that
have already been dened.
The Terms and Denions Database, Interacve (TEDDI) on
the ETSI Portal (hp://webapp.etsi.org/Teddi/) is a helpful
tool for achieving consistency in your documents, since it
records denions and abbreviaons that have already been
dened in other documents. However, you should make sure
that TEDDI denions are applicable and consistent with
your needs.
The technical content of the document
The structure of the technical content will depend on the
subject of the standard but the following principles will help
you achieve a good result:
• Group related topics in clauses or sub-clauses with
appropriate tles.
• Order the topics in a logical way so that preceding text
helps the reader to understand what follows.
• Clearly disnguish between normave and informave
text
- Put informave descripons in separate clauses and
consider marking them as informave.
- If it is not possible to insert informave material as a
separate clause and it has to sit within a normave
part of the standard, present the material as ‘Notes’ to
disnguish it. (Do not use footnotes!)
• Improve the readability of the main body of the
standard by moving self-contained parts to annexes.
Such parts might be:
- the normave specicaon of a complete funconality
or service,
- informave descripons for understanding and
background,
- specicaons in specialized notaons such as ASN.1,
XML or TTCN-3.
• If you are producing a set of associated standards,
adopng a common structure for all technical content
will make the documents easier to read.
Numbering of clauses, gures and tables
The numbering of clauses, gures and tables is clearly
specied in the ETSI Draing Rules and all standards should
follow these guidelines. The reason for numbering is simple:
the reader should be able to idenfy every requirement in a
standard by a reference.
Bear in mind that the numbering within a document can
change if the document is updated, bringing a risk of
confusion and possible mis-applicaon of requirements.
Note that 3GPP draing rules (TR21.801) require that you
avoid renumbering of all elements (clauses, gures, tables,
references) when documents are updated.
Follow the style guide
In addion to dening a structure, ETSI has dened a
comprehensive range of Microso® Word® styles for use in
ETSI deliverables. This helps ensure a consistent appearance
to all published documents. These styles address most
editorial requirements and you should not need to add new
styles to a document – neither should you modify the styles
provided.
16
Requirements range from the high-level, such as stang
that equipment shall support a specic funconality or
capability, to the low-level, such as seng specic values or
characteriscs or behaviour.
Some basic principles
Any suitably qualied reader should be able to understand
your standard – without misinterpretaon! Remember that
many readers of your standard will not have parcipated
in the commiee that produced it. Misinterpretaon due
to deciencies in a standard is a major cause of incorrect
implementaon and can lead to non-interoperable products.
It is therefore essenal that all requirements in a standard
are unambiguous.
The technical content of a standard should specify
the minimum requirements necessary to achieve the
objecves of the standard, while leaving room for product
dierenaon. In other words, standards should specify
what is to be achieved by an implementaon rather than
how to achieve it. They are not product specicaons. The
technical commiee has the responsibility for deciding what
funconality should be specied in a standard and what
should not.
ETSI standards are limited to dening normave provisions
such as essenal physical or electrical characteriscs, or open
interfaces and common data formats for communicaon
protocols.
The technical content of
the standard – How to
write good requirements
17
Use of English
ETSI deliverables are wrien in the English language but
idiom, spelling and grammar dier from country to country.
Given ETSI’s European context, Brish English is preferable to
any other variant.
As standards are contribuon-driven, they may contain a
mixture of variees of English and styles of wring. During
the later phases of draing you will need to raonalize the
language in order to:
• align the wring styles of dierent contributors to make
the standard read like a consistent document rather
than a collecon of contribuons
• make it consistently Brish English throughout
• eliminate grammacal errors and misspellings (poor
spelling and poor grammar not only lead to ambiguity
but also give the impression of a low-quality deliverable
that cannot be trusted)
• eliminate non-standard idiom that might not be
understood by many readers.
Unambiguous requirements have a single, clear
interpretaon. The clear and concise use of English
is important. For example, wring
the bitstreams shall be aggregated
does not make it obvious what or who will perform
the task of aggregang the bitstreams. The
ambiguity is removed when the requirement is
wrien as
the mulplexer shall aggregate the bitstreams.
Lack of precision also leads to ambiguity:
If the mer T1 expires before receipt of a T-DISCONNECT_
indicaon the SPM requests a transport_disconnecon
with a T-DISCONNECT_request. The mer is cancelled on
receipt of a T-DISCONNECT_indicaon.
In this example there are two sources of ambiguity. Firstly,
the use of the present tense (“requests” and “is cancelled”)
makes it unclear whether this is actually a requirement or
not. Secondly, it is ambiguous whether or not the second
sentence is part of the condion in the rst sentence.
Most probably these are two completely separate
requirements as the cancellaon of an expired mer makes
lile sense. A beer approach would be:
The mer T1 shall be cancelled on receipt of a
T-DISCONNECT_indicaon.
If the mer T1 expires before receipt of a T-DISCONNECT
indicaon the SPM shall request a transport disconnecon
by sending a T-DISCONNECT_ request.
If the cancellaon of the mer was indeed intended (even
aer expiry), then the second requirement should be as
follows (the rst requirement remains unchanged):
If the mer T1 expires before receipt of a T-DISCONNECT_
indicaon the SPM shall request a transport disconnecon
by sending a T-DISCONNECT_request and the SPM shall
cancel Timer T1.
Keep it impersonal
Do not use the 1st person (I, we), 2nd person (You), or
the 3rd person personal (He, she, they).
Thus, these examples are acceptable:
… the equipment shall respond with a
CALL_ACCEPTED message
…the potenal shall be set to +5 volts.
The following are not acceptable:
…you should set the audio level to 0dB
…we recommend that it should not exceed 100µA.
18
Shall, should and may
In an ETSI deliverable, requirements are each expressed
using specic verbs: SHALL, SHOULD and M AY.
• SHALL is used to express mandatory requirements
(provisions that have to be followed):
- the negave form is SHALL NOT.
- Do not use the verb MUST as an alternave to SHALL.
It is forbidden by the ETSI Draing Rules!
Example:
During call set-up, TVP shall not be incremented during
call setup synchronizaon bursts but shall be repeated
across each slot of the frames containing the DM-
SETUP or DM-SETUP PRES messages.
Alternative forms
The Draing Rules menon alternaves for some
situaons (such as is required to, ought to, will and
is) but they can make the text very dicult to read
and may cause confusion. For this reason…
…avoid any of these alternave forms!
Warning!
Do not use SHALL in informave text, as the word
implies a requirement. Similar terms that imply a
requirement, such as ‘have to’ and ‘required to’, are
also not permied in informave text.
If you nd that your informave text seems to need
the use of such words, you should check that it
really is purely informave!
Remember that this restricon applies not just to
informave material in a standard but equally to
informave types of documents (EG, TR, SR and GR).
• SHOULD is used to express recommendaons
(provisions that an implementaon is expected to
follow unless there is a strong reason for not doing so):
- the negave form is SHOULD NOT.
Examples:
For best subjecve speech quality the CNF parameters
should be esmated using periods of no input speech
acvity.
An MS that does not support authencaon should not
select a cell that broadcasts “authencaon required”.
• MAY is used to express permissions (provisions that
an implementaon is allowed to follow or not follow):
- the negave form is NEED NOT (in English MAY NOT is
ambiguous, so NEED NOT is used instead).
- Do not use the verb CAN as an alternave to MAY.
Examples:
Members of an SCK set may be shared amongst
dierent DMO nets. They may be allocated in either the
home V+D network of the MS or by an external body.
Speech frames marked “NO_IMPORTANCE” need not
be transmied over the air interface.
19
Functional decomposition
Start with high-level requirements and work down
to the detailed or lower-level requirements. For
example, a high-level requirement such as
The equipment shall support funconality F1
is a simple statement even though funconality
F1 may need a large number of subsequent
requirements to specify it completely. For example:
The Base Band Interface shall support the
Radio Applicaon Interface for baseband signal
processing.
Structuring the requirements
Wring well-structured requirements that are consistent,
complete and precise will go a long way to removing
ambiguies and potenal misunderstandings.
To ensure that your standard is understandable and usable,
structure the requirements in a logical and consistent
manner:
• Keep each requirement as simple as possible
- Avoid unnecessary complexity (e.g. long sentences
covering several requirements or long requirements
covering several sentences).
- Use numbered or bulleted lists rather than complex
sentences.
• Make the logical structure of each requirement, or
combinaon of requirements, clear
- Ensure that the requirements specied in a clause are
directly related to the tle of that clause.
- Clearly idenfy the context in which a requirement
appears, any pre-condions that may apply to the
requirement and any subsequent or alternave
requirements that may need to be specied.
• Specify the requirement in one place
- Avoid spling a requirement (for example, parally
dening the requirement on one page and nishing
it o several pages later). If spling is unavoidable,
make sure the link to the two parts is clearly explained
and referenced.
- Avoid mulple denions of the same requirement.
If similar requirements are found, decide whether
they are truly dierent or just poor expressions of the
same thing. If there are strong similaries between
two dierent requirements make it clear that they are
separate to prevent the reader thinking one is just an
inconsistent version of the other!
Identifying requirements
Remember that it must be possible to reference
every requirement. This can be done through clause
numbering, but it can also be done by giving each
requirement a unique idener. There is no xed
format but it could be:
• An alphanumeric string
• Unique within the standard (or set of
standards)
• Easily idenable as a requirement idener
(for example, it has the format REQ nnnnn).
- Group related requirements (architectures, protocols,
service primives, etc.) in separate clauses.
- Avoid implicit requirements (for example, having the
denion of one requirement implied by another).
• Specify the requirements in a logical order
- Avoid lisng requirements that assume requirements
which only appear later in the document.
- Use funconal decomposion.
• Use well-established design pracces for protocol
layering, reference points, naming etc.
• Consider the use of specialized notaons to increase
precision
- Some requirements can be very dicult, if not
impossible, to express precisely in text, such as the
structure of communicaon messages. Specialized
notaons exist to overcome these dicules.
- Specialized notaons can also be used to add clarity
to requirements which can be expressed in text.
• “A good picture is worth a thousand words.”
- Charts and diagrams can also help explain concepts
that are dicult to express in text.
20
Static and dynamic requirements
Stac requirements specify characteriscs that do not
change over me and are not dependent on previous events.
They can be expressed as single statements and may be
wrien in any order.
No-load condions shall not exceed 0.3 Wa.
Dynamic requirements express the behavioural aspects of
equipment and usually state what is required to happen
when something else happens – in other words, cause and
eect. In the example below the cause is in bold text:
When a new SIM is inserted in the preferred reader,
the user shall be oered the ability to select the new SIM
aer the call is terminated.
Usually, dynamic requirements are more complex than stac
requirements and there may be dependencies between them
that mean they cannot be wrien in an arbitrary order. In
these situaons, careful aenon to the overall composion
of the standard will ensure clarity.
Putting requirements into context
Oen, a requirement or set of requirements only applies
within a given context. In such a situaon, you should take
care to ensure that the scope of that context is well-dened
and can be easily related to the relevant requirements. There
are essenally two kinds of context: environmental and
descripve.
The environmental context describes maers that directly
relate to the standard. These may be interacons with
peer enes or other systems, typically specied in other
standards.
For example:
A standard specifying the behaviour of a terminal needs
to describe responses to messages received from a
network that is the subject of a separate standard.
The network standard species that it shall send a
CALL_TERMINATED message in response to a received
DISCONNECT message and that it may send a CALL_
PROCEEDING message in response to a received SETUP
message.
The terminal standard then species that the network
will respond with a CALL_TERMINATED message to the
terminal’s DISCONNECT and that it can respond with a
CALL_PROCEEDING message in response to its SETUP.
The descripve context provides addional informaon to
readers to help them understand the requirement. In the
following example, the bold text is the context and the non-
bold text is the actual requirement:
The address eld range is extended by reserving the rst
transmied bit of the address eld octets to indicate the
nal octet of the address eld. The presence of a 1 in
the rst bit of an address eld octet signals that it is the
nal octet of the address eld. The double octet address
eld for LAPD operaon shall have bit 1 of the rst octet
set to a 0 and bit 1 of the second octet set to 1.
Note that the requirement would not be changed in any way
if the descripve context were removed.
In pracce, the context may not be adjacent to the
requirement text. It may be a clause introducing a whole set
of subsequent requirements.
21
Conditions under which a
requirement applies
A requirement may depend on one or more condions
(somemes referred to as pre-condions) that must be met
for the requirement to apply.
In this example, the bold text is the condion and the non-
bold text is the actual requirement:
With the ME switched o and with the power source
connected to the ME the voltages on contacts C1, C2,
C3, C6 and C7 of the ME shall be between 0 and ±0.4 V
referenced to ground (C5).
It usually helps the reader if you put the condion rst in the
sentence, followed by the requirement, as in the example
above. However, in some instances it might be clearer if the
condion comes aer the requirement or is even embedded
in it as illustrated below. It is up to you as the author to
decide which is preferable.
When a new SIM is inserted in the preferred reader
during a call, the user shall be oered the ability to select
the new SIM aer the call is terminated.
In some cases, a requirement may be the condion for
another requirement, typically of the form:
If REQ1 is implemented then REQ2 applies.
For example:
If the ME is able to detect a 5V only SIM according to the
procedure in clause 5.1.3, or if the procedure cannot be
completed, then the ME shall deacvate and reject the
SIM immediately (maximum of 5s) without issuing any
further command.
Several requirements may be valid within a single condion,
for example:
If addional carriers are supported by the equipment, the
applicant shall declare the band edge limits FL and FU
and shall declare the carriers supported
In such cases, it is important to be very clear about the scope
of the condion and to which requirement or requirements
it applies. You need to be careful to avoid ambiguity. A
sentence such as the following may confuse the reader:
If COND1 is fullled then REQ1 and REQ2 apply.
Does the condion apply only to REQ1 or to REQ2 as well?
You can avoid any confusion by careful use of language: for
example:
If COND1 is fullled then both REQ1 and REQ2 apply.
Remember that it can happen that the condion is dened
in a dierent part of the document, so you should take care
to ensure that it can be easily idened and understood by
the reader.
Error and exceptional behaviour
Requirements related to error or exceponal
behaviour need to be specied just as precisely
as the normal behaviour. Lack of precision
in expressing error behaviour oen leads to
interoperability problems.
Specifying alternatives to
conditional requirements
Your reader needs to be clear what should happen if a
condion is not met. Oen, this will be obvious but you need
to take care to ensure that the reader is not le in doubt. This
may mean that you will need to dene the consequences if the
condion is not met.
If COND1 is fullled then REQ1 applies otherwise REQ2
applies.
A simple condional requirement with an alternave might be:
If installed in an emergency vehicle the equipment shall be
painted red otherwise it shall be painted blue.
Expressing this as two separate requirements (with mutually
exclusive condions) may make it clearer:
If installed in an emergency vehicle the equipment shall be
painted red.
If installed in any vehicle except an emergency vehicle the
equipment shall be painted blue.
22
Combining requirements
The specicaon of an item may consist of several
requirements. You could simply list them but this may read
awkwardly. For example:
The equipment shall have a length of 15 cm.
The equipment shall have a width of 20 cm.
The equipment shall have a height of 10 cm.
It might be beer to write this as a single requirement:
The equipment shall have the dimensions of 15cm x 20cm
x 10cm (length x width x height respecvely).
Or as a combinaon of three requirements in a single
statement:
The equipment shall have a length of 15 cm and shall
have a width of 20 cm and shall have a height of 10 cm.
The requirements in the above examples are all stac
requirements and you could list them in any of these forms
because their order is not important.
However, the order of a combinaon of dynamic
requirements may somemes be signicant. In the following
example, the standard does not require that the two acons
(sending the SETUP message and starng the mer T30) are
done in any parcular order.
When requested by the user the terminal equipment shall
send a SETUP message and shall start mer T30.
Conversely, if the sequence is important you should make it
clear by wring the requirement in the following manner:
When requested by the user the terminal equipment shall
send a SETUP message and then shall start mer T30.
As you can see, it is important to describe dynamic
requirements correctly so that the reader is not confused
or made to misunderstand what is intended. Words such
as and, or, either, neither and not are useful for combining
requirements, but care is sll needed.
For example, the text dening a set of
requirements could take the form:
REQ1 and REQ2 or REQ3 but not REQ4.
But this is ambiguous! Does REQ3 apply as
an alternave to REQ2?
REQ1 and (REQ2 or REQ3) but not REQ4
Or is REQ3 an alternave to both REQ1 and REQ2?
(REQ1 and REQ2) or REQ3 but not REQ4
In these abstract examples, parentheses help to clarify the
intenons but, in a real standard, words or phrases such as
either, neither, both, at least can be used to achieve the
same eect. For example:
REQ1 and (REQ2 or REQ3) could be expressed in prose as
REQ1 and either REQ2 or REQ3.
Ensuring that your requirements
are testable
All requirements should be testable. At least in principle,
it should be possible to devise a test to verify whether a
requirement has been correctly implemented in a product.
In pracce (usually for economic reasons), it may not be
feasible to implement a parcular test but, even in such
cases, the requirement must be theorecally testable.
Testability and observability go hand-in-hand. If it is truly
impossible to test a requirement, this implies that there is
no possible way of observing the specied characterisc or
behaviour, and therefore you should queson whether that
requirement is valid.
A requirement that appears to be testable because it has an
observable outcome may, in fact, not be testable because it
lacks precision or completeness. Consider:
When the equipment receives a SERVICE_REQUEST
message, it shall respond immediately with a
SERVICE_ACK message.
This is not a testable requirement because it does not specify
how soon “immediately” is. Rewring it as:
When the equipment receives a SERVICE_REQUEST
message, it shall respond with a SERVICE_ACK message
within 30ms
makes the requirement both implementable and testable.
23
Expressing optional requirements
You may nd it necessary to make some of the requirements
oponal within a standard.
However, this can result in imprecise standards, as each
opon may need to be considered in combinaon with every
other opon. The resulng lack of precision may well lead to
interoperability or interacon problems in implementaons
of the standard. You should therefore aim to minimize
the number of oponal requirements although you may
be unable to eliminate them altogether. In addion, you
must ensure that your standard claries the consequences
of whether or not a parcular oponal requirement is
implemented.
Optional requirements
A standard that includes oponal requirements
should clearly specify:
• under what condions oponal requirements
apply and which other oponal requirements
may become ‘mandatory’ as a result of an
oponal requirement being implemented
• the consequences, if any, of oming oponal
requirements.
Opons can range from the oponal implementaon of
enre features or capabilies (high-level requirements)
to choices about the support of specic characteriscs or
behaviour (low-level requirements).
The choice of opons must be made in such a way that
interoperability remains assured.
For example, when the sending of a message is oponal, the
receiving enty must support the recepon of that message.
Likewise, when a eld in a message is oponal for the sending
side, the receiving side must be able to receive the message
with or without the oponal eld.
Optional features
If you need to include oponal features in a standard, you
should make this clear by using appropriate introductory text
such as:
The following feature (or features) may be supported.
You should follow this statement by specifying the
requirements that dene the feature. Remember that the
correct use of the verbs SHALL, SHOULD, MAY and their
negave forms is crucial even when specifying a feature that
is itself oponal.
Proles
It is important to avoid an excess of opons, but some
standards may contain many opons for good reasons.
The development of proles of the standard can help
ensure interoperability between implementaons. Proles
state which opons must be implemented for a parcular
situaon (eecvely making those opons mandatory) and
which should not be implemented. A prole should itself
be a standard. There may be a dierent prole of the base
standard for each context in which it applies.
As an example, the DECT™ General Access Prole (GAP)
species an interoperability prole for simple telephone
capabilies that most manufacturers implement. There are
several other interoperability proles that specify the use of
DECT in applicaons such as data services and radio local-
loop services.
24
Specifying requirements with
specialized notations
Natural languages (English, etc.) all have their limitaons
that can result in misunderstanding and confusion. Some
requirements are dicult to express precisely in text and can
somemes be described more precisely and more eecvely
by using specialized languages such as ASN.1 (Abstract
Syntax Notaon 1) and UML (Unied Modelling Language®).
They can be used either as the primary means of specifying
requirements, or to complement the text of a standard in
order to illustrate and clarify requirements.
In any case, you should only use languages that are
internaonally standardized and known in the industry,
and you should respect their syntax and semanc rules.
Dedicated tools exist for most of these languages, which can
be helpful in detecng errors in specicaons. ETSI’s Centre
for Tesng and Interoperability can advise you about their
use.
Readers need to be clear about which parts of a standard
are normave and which are informave. Since specialized
languages can be used for either purpose, it is important
that the reader is not le in doubt. A statement such as the
following will make the situaon clear:
In the present document, ASN.1 is used for the specicaon
of the content of all protocol primives (normave) and
service primives (informave).
If both the English language text and alternave descripons
(in ASN.1 etc.) are considered to be normave, the text needs
to make clear how any apparent misalignments between
two descripons will be resolved. Typically, this is done by
stang which takes precedence.
Specifying interactions
and use cases
Interacon is a fundamental part of communicaon
standards. The text of a standard can provide a complete
or paral descripon of an interacon, but the inclusion of
a graphical descripon may help the reader considerably.
Languages that are parcularly suitable for this purpose
are Message Sequence Charts (MSCs) and UML Sequence
Diagrams. They are very similar and either may be chosen.
Their simplicity and intuive nature made them popular.
Despite their simplicity, they provide a powerful notaon
with built-in mechanisms to describe interacons that
include such things as mers, loops, oponal, alternave and
exceponal behaviour. Some guidelines for the use of MSCs
in standardizaon are given in EG 201 383; these guidelines
can be extended to UML sequence diagrams.
UML Use Case Diagrams are parcularly well-suited to the
inial requirements capture phase of standardizaon, for
documenng interacons between systems and with users.
Specifying messages
Communicaon standards enable devices to interoperate
by specifying precisely the messages that can be exchanged,
including their detailed sub-structuring and encoding.
For this parcular task, plain textual descripon is never
adequate but, fortunately, two suitable languages exist, XML
(Extensible Markup Language) and ASN.1.
Specifying the behaviour of
communicating systems
If a standard describes complex interacons and ming
paerns, it may be benecial to use some form of state-
oriented descripon to complement the text. There are
two standardized notaons parcularly well-suited for this
purpose, SDL process diagrams and UML state charts. EG 202
106 provides guidance for their use.
Advantages of XML and ASN.1
• They have well-dened syntax and semancs.
• Specialized tools are available to check the
correctness and completeness of specicaons
wrien in XML and ASN.1.
• Specicaons in XML or ASN.1 can be used
directly in products implemenng the standard,
independent of the programming language
used, thus eliminang the risk of conicng
interpretaons.
• Accompanying standards exist that dene how
data values are encoded and transmied. The
tools can generate encoders and decoders.
25
If you have followed this guide, you will have included
validaon acvies in your schedule. Even the simplest of
validaon acvies can improve the quality of a dra standard
but a well-planned and systemac validaon process may
idenfy technical and editorial inaccuracies, inconsistencies
and ambiguies that might otherwise have remained in the
published document. The process is therefore important for
maximizing the quality of the standard as well as providing
valuable feedback into on-going standards-making acvies.
EG 201 015 details various validaon techniques. These
techniques are not all suited to the full range of subjects
standardized by ETSI but almost every standard can be
validated in one way or another. Two common validaon
methods described in EG 201 015 are peer reviews and
interoperability events.
Peer review
A peer review is a method of evaluang specicaons that
can idenfy many of the inaccuracies and inconsistencies
present in the specicaons. In fact, reviews are eecve
in validang most types of standard, regardless of their
content or presentaon. The results of the review can
provide feedback automacally into the standard itself as
the rapporteur and other contributors should be present
during the review.
The implicit imparality of the ETSI Technical Ocers makes
them ideal candidates for leading reviews.
Validation of standards
Interoperability events
During these events, companies are able to interconnect
prototype or producon implementaons of standards
in order to test for interoperability and, where needed,
conformance to requirements. Interoperability events
provide a highly cost eecve and praccal way of idenfying
inconsistencies in either an implementaon or the standard
itself.
Holding regular events, in me with the development of the
standard and as new or enhanced implementaons become
available, is an excellent way to obtain prompt, relevant
feedback into the standardizaon process.
Implicit methods of validation
In addion to these ‘explicit’ validaon methods there are
also a number of ‘implicit’ methods such as the preparaon
of a requirements catalogue, the development of test
specicaons and the implementaon of the standard in a
product; in other words, any acvity which requires close
scruny of the requirements specied in the standard.
Although the explicit methods described above are the most
eecve means of validaon, implicit methods may oen
produce results faster.
Plugtests™
ETSI’s Centre for Tesng and Interoperability
(CTI) organizes interoperability events, known as
Plugtests. For more details visit:
hps://www.etsi.org/events/plugtests
26
Maintenance of standards
When a standard requires revision to correct defects ETSI
publishes a new version. In the early stages of standardizaon,
it may be possible to plan revisions at regular intervals
because the number of change requests is likely to be high.
These should diminish as the standard matures and a more
ad hoc (or ‘as required’) approach to maintenance can be
used. In any case, the ecient maintenance of standards
requires an eecve change management system to collect,
evaluate and implement change requests.
Evolution of standards
Somemes the capabilies or characteriscs of a parcular
technology are so extensive that it would be unreasonable to
delay publicaon of the standard unl every aspect has been
specied. It may then be advisable to publish the standard
progressively as a carefully planned and evolving set of
‘releases’.
Before the rst release is prepared, a clear release strategy
should be devised and documented. The content of each
release should be idened and a schedule drawn up
to indicate broadly when each release is expected to be
published. It may not be possible or desirable to include all
of the capabilies planned in each release, so the release
strategy should have some exibility and evolve with
the standards. It should not be treated as a rigid set of
requirements.
Maintaining compatibility
There is always a danger, even with planned revisions and
releases, that an updated standard will become incompable
with earlier versions of itself, and also with other standards.
Standards-writers should make compability one of their
highest objecves.
Incompability should be less of a problem in a planned
set of releases. However, although it is not desirable,
incompability between releases can somemes be an
intenonal part of a release strategy; in such cases the
nature of the expected incompability should be made very
clear from an early stage.
In addion to maintaining compability between versions
of a single standard, it is also necessary to consider its
compability with other standards. This can be more dicult
to achieve because it is not always possible to know which
other standards make normave references to the standard
being revised. It is equally dicult to avoid incompabilies
caused by references to other documents, parcularly if they
are not ETSI standards.
Maintenance and
evolution of standards
27
Therefore:
• Before you decide to implement any change request
you should review it in the context of the whole
standard and those that are directly related to it.
• You should plan any change to the technical content
of a standard together with any consequent changes
to related standards in order to minimize periods of
inconsistency or incompability.
• The use of hierarchical Work Items will help to idenfy
the range of standards that might be aected by any
given change request.
• Normave references to specic versions of other
standards should be used when necessary.
• Technical commiees should systemacally review the
status and validity of the normave references in each
of their published standards on a regular basis.
Maintaining numbering in new
versions of standards
Be alert to the danger that re-numbering clauses, gures
and tables in an updated version of a standard may cause
problems when it is referenced by other standards. This
is especially a risk where the document uses a conguous
unique numbering scheme. In each new version of the
standard, the same clauses, gures or tables could possibly
have dierent numbers compared with the previous version
– a potenal source of great confusion!
An alternave approach is to maintain the same number
for each item (clause, table or gure) across all versions
of the standard, to mark deleted items as void and to use
alphanumeric suxes for addional items (for example, if
a new clause was added between clause 5.1.3 and 5.1.4, it
would be given the number 5.1.3a).
Both methods have their merits and their drawbacks;
the commiee should decide which to use.
Change management
ETSI uses several approaches to change management.
The simplest of these are oriented towards the
collecon, allocaon and resoluon of requests for
improvement and defect reports. Other approaches
are more concerned with the processing of fully
marked-up changes to exisng standards. It is the
responsibility of each technical commiee to select
its preferred method and the tools to support it.
Irrespecve of the method chosen, you should
ensure that certain principles are respected:
• Change Management should be implemented
for all deliverables once they have been
approved by the relevant technical commiee.
• Every request for a change should idenfy:
- the name of the individual raising the request
- the number, tle and version of the
deliverable for which the change is requested
(this should be the latest published version of
the standard and not an earlier version or an
unpublished version)
- the proposed change, either in summary or in
detail
- the reason for the change.
• Each change request should be evaluated to
determine whether the proposed change is:
- Necessary – does it correct a defect
that prevents accurate or consistent
implementaon of the standard?
- Desirable – does it extend the specicaon
with a capability that is aracve to the
market? Does it modify the approach
to an exisng capability, for example to
improve its eciency or eecveness in an
implementaon?
- Feasible – can the defect be addressed within
the constraints of the technology, cost and
mescale?
• No guarantees should be made to the proposers
that every submied request will result in the
proposed change to the deliverable. Only those
ulmately approved by the technical commiee
will be implemented in a subsequent revision of
the standard.
28
It is normal pracce within ETSI to publish test specicaons
for each of our base standards. This is parcularly helpful for
those specifying protocols or services. You should decide as
early as possible in the development of the base standard
whether you will also create test specicaons.
If you follow the guidelines in this guide, your standards will
contain testable requirements that will be easy to idenfy.
Test specicaons are derived from the requirements in the
base standard so, the beer those requirements are wrien,
the beer the test specicaons will be. If you have used
the verbs SHALL, SHOULD and MAY correctly, the task of
categorizing the corresponding tests as being mandatory or
oponal will be reasonably straighorward.
ETSI test specicaons dene either conformance or
interoperability test suites and typically consist of three
components:
• An Implementaon Conformance Statement (ICS) –
a standardized proforma in which the requirements
specied in a base standard are collected together into
a table of quesons (to be answered by an implementer
or equipment supplier) with a limited set of possible
answers. The most common example of a specic ICS
within ETSI is the Protocol (specicaon) ICS, or PICS.
• Test Purposes – a prose descripon of what is to be
tested.
• A Test Suite, usually in TTCN-3 code.
Standardized tesng has a narrower scope than proprietary
tesng because it can only use the normave interfaces. By
contrast, proprietary tesng will typically access internal
funcons and internal interfaces of the product that may
not have been dened in the standard. Performance tesng
is a good example of this. Most standards have lile to say
about product performance: in the case of protocols, this
is usually expressed in the standard as response mes to
certain messages whereas proprietary tests will also handle
characteriscs such as load, throughput and capacity.
Test specications
Conformance and
interoperability testing
Conformance tesng determines whether a single
product or service conforms to the requirements
specied in the standard(s) that it implements. The
development of all ETSI conformance test standards
should follow the well-established methodology
dened in ISO/IEC 9646 Conformance Tesng
Methodology and Framework.
Interoperability tesng considers operaons at the
funconal or user level. Its purpose is to determine
the extent to which mulple implementaons of a
standard (or a set of standards) will interoperate.
It is concerned less with strict adherence to the
requirements specied in the base standard and
more with the overall funconality implied by that
standard. EG 202 237 contains the methodology that
should be followed when creang interoperability
test standards.
29
You are not alone!
Do not hesitate to call upon the support and assistance of
the Secretariat. There is a wealth of experience and experse
for you to draw on. Over the years ETSI has produced more
than 48 000 standards and enabled key technologies that
have revoluonized telecommunicaons and IT. It is only by
sharing our skills and experience that we can write the world
class standards that our industries need.
Within the ETSI Secretariat we provide a range of resources
that are there to help you. These include:
• The Technical Ocers and support sta assigned to each
commiee, who have extensive technical and praccal
knowledge in the areas in which those commiees
work. They can guide you to other sources of experse
as necessary.
• The editHelp! Service, for maers relang to the
draing, approval and publicaon of your standard.
• The Centre for Tesng and Interoperability (CTI) which
can help you ensure that the requirements in your
standard are testable in pracce, as well as providing
experse in the use of specicaon languages and the
producon of test specicaons.
Closing remarks
• Secretariat sta dedicated to maers such as relaons
with the European Commission, relaons with other
partner organizaons, use of standards in regulaon,
and the use and interpretaon of the ETSI Direcves.
• The Specialist Task Force (STF) service, which can
arrange dedicated teams of technical experts to work
on specic standards-related tasks.
• The ETSI website and Portal, which contain a wide range
of informaon about the work of ETSI, its standards,
meengs, key people and much more.
• Numerous guides and other resources, some of which
are listed in the References and Resources secon of
this guide.
We could wish you “good luck” but luck has very lile to do
with producing world class standards! It takes dedicaon,
care and commitment – and a respect for the rules and good
pracces. We wish you every success!
30
ETSI resources
ETSI Draing Rules (EDR) hp://portal.etsi.org/edithelp/home.asp
ETSI Direcves hp://portal.etsi.org/Direcves/home.asp
Use of English (interacve) hp://portal.etsi.org/edithelp/Files/other/UOE.chm
Use of English (PDF) hp://portal.etsi.org/edithelp/Files/pdf/Use%20of%20English.pdf
Standards-making process hp://portal.etsi.org/chaircor/process.asp
Terms and denions database hp://webapp.etsi.org/Teddi/
Eding checklist hp://portal.etsi.org/edithelp/Files/zip/ETSI_eding_checklist.zip
Tesng and interoperability hp://www.etsi.org/services/tesng-interoperability-support
The editHelp! web pages (hp://portal.etsi.org/edithelp/home.asp) contain a wide range of guides, tools and skeleton
documents to help you in the standards-making task.
Various documents relang to methodologies and best pracces are available at:
hp://portal.etsi.org/edithelp/StandardsDevelopment/home.htm?page=Documentaon
References and useful resources
3GPP™ resources
TR 21.801 Specicaon draing rules
TR 21.905 Vocabulary for 3GPP Specicaons
oneM2M resources
oneM2M-Draing-Rules
ETSI Guides on standards-writing,
testing and validation
EG 201 058
Methods for Tesng and Specicaon (MTS);
Implementaon Conformance Statement (ICS) proforma
style guide.
EG 201 015
Methods for Tesng and Specicaon (MTS); Specicaon
of protocols and services; Validaon methodology for
standards using SDL; Handbook.
EG 201 383
Methods for Tesng and Specicaon (MTS); Use of SDL
in ETSI deliverables; Guidelines for facilitang validaon
and the development of conformance tests.
EG 202 106
Methods for Tesng and Specicaon (MTS); Guidelines
for the use of formal SDL as a descripve tool.
EG 202 107
Methods for Tesng and Specicaon (MTS); Planning for
validaon and tesng in the standards making process.
EG 203 336
Electromagnec compability and Radio spectrum
Maers (ERM); Guide for the selecon of technical
parameters for the producon of Harmonised Standards
covering arcle 3.1(b) and arcle 3.2 of Direcve
2014/53/EU.
ITU-T three-stage process
ITU-T Recommendaon I.130:
Method for the characterizaon of telecommunicaon
services supported by an ISDN and network capabilies
of an ISDN
Specication languages
ITU-T Recommendaon Z.100-Z.106 (2011)
Specicaon and Descripon Language
ITU-T Recommendaon X.680-X.683 (2008) | ISO/IEC 8824-1
to 4:2008
Informaon technology – Abstract Syntax Notaon One
(ASN.1)
ITU-T Recommendaon X.690 (2008) | ISO/IEC 8825-1:2008
Informaon technology – Abstract Syntax Notaon One
(ASN.1):
Informaon technology – ASN.1 encoding rules:
Specicaon of Basic Encoding Rules (BER), Canonical
Encoding Rules (CER) and Disnguished Encoding Rules
(DER)
ITU-T Recommendaon Z.120 (2011)
Message Sequence Chart (MSC)
OMG (2011): Unied Modeling Language UML, v 2.4.1
W3C (2008): Extensible Markup Language (XML) 1.0
W3C (2006): Extensible Markup Language (XML) 1.1
Other resources
ISO/IEC 9646
Conformance Tesng Methodology and Framework
Oxford Guide to English Usage (ISBN: 9780192800244)
31
32
© European Telecommunicaons Standards Instute 2020
DECT™, PLUGTESTS™, oneM2M™ and the ETSI logo are Trade Marks of ETSI
registered for the benet of its Members.
3GPP™ is a Trade Mark of ETSI registered for the benet
of its Members and of the 3GPP Organizaonal Partners.
UML® and Unied Modeling Language®
are either registered trademarks
or trademarks of Object Management Group,
Inc. in the United States and/or other countries.
33
ETSI
650, Route des Lucioles
06921 Sophia Anpolis CEDEX, France
Tel +33 4 92 94 42 00
info@etsi.org
www.etsi.org
leprincipedestappler.com
