CEFACT/ICG/005

BUSINESS REQUIREMENTS SPECIFICATION

(BRS)

Documentation Template

Approved UN/CEFACT Forum Bonn 2004-03-09

Version: 1
Release: 5
 CEFACT/ICG/005

Table of Contents

1 REFERENCE DOCUMENTS............................................................................3
1.1 CEFACT/TMWG/N090R10 UN/CEFACTS MODELLING METHODOLOGY.............3
1.2 OMG UNIFIED MODELING LANGUAGE SPECIFICATION ...........................................3
2 DEFINITIONS .....................................................................................................3
3 INTRODUCTION................................................................................................3
4 TEMPLATE OUTLINE......................................................................................5
4.1 INTRODUCTION .........................................................................................................5
4.2 BUSINESS REQUIREMENTS SPECIFICATION BASIC OUTLINE ......................................5
4.3 TITLE AND CONTENTS INFORMATION .......................................................................6
4.4 PREAMBLE ................................................................................................................8
4.5 REFERENCES .............................................................................................................8
4.6 OBJECTIVE ................................................................................................................8
4.7 SCOPE SECTION .........................................................................................................9
4.8 BUSINESS REQUIREMENTS SECTION ..........................................................................9
4.8.1 Business requirements views..................................................................9
4.8.1.1 Business process elaboration .............................................................9
4.8.1.2 Information flow definition..............................................................10
4.8.1.3 Information model definition...........................................................10
4.8.2 Business rules.......................................................................................10
4.8.3 Definition of terms ...............................................................................10
5 CONCLUSION ..................................................................................................11
 CEFACT/ICG/005

1 Reference documents
1.1 CEFACT/TMWG/N090R10 UN/CEFACTs Modeling methodology

1.2 OMG Unified Modeling Language Specification

2 Definitions
These definitions are proposed to assist the reader in the use of this document. For
their formal definition consult the relevant reference document.
Use case diagram: A “use case” diagram shows the relationships that exist between
actors and delimited functions (or frequently called “use cases”)
within a system. A delimited function or “use case” can be defined as
the specification of a sequence of actions, including variants that can
be performed through the interaction with the actors of the system.
An actor that interacts with the use case represents a coherent set of
roles that may be played to correctly carry out the use case. A use
case diagram brings together the set of use cases that are required to
satisfy the business process being described. A use case within a
diagram may be decomposed into more detailed use cases within
another use case diagram.
Activity diagram: An activity diagram is used for modeling workflow and as such it
provides a valuable insight into the information flows that occur between
actors. An activity diagram may be divided into columns (termed
“swimlanes”) where each column identifies an actor’s area of
responsibility.
Sequence diagram: A sequence diagram presents a collaboration with a superposed
interaction. In general a sequence focuses on one specific type of action
that should be highlighted.
Collaboration diagram: A collaboration diagram shows an interaction organized
around the roles in the interaction and their links to each other. Unlike a
sequence diagram, a collaboration diagram shows the relationships among
the objects playing the different roles. However, the collaboration diagram
does not contain any notion of time.
Class diagram: A class diagram shows the static structure of the information model,
in particular, the things that exist, their internal structure, and their
relationships to other things. A class diagram does not show temporal
information.

3 Introduction
In order to successfully introduce a normalized form of business requirements
specifications based on the UMM philosophy, it will be necessary to develop and put
 CEFACT/ICG/005

into place a phased approach that gradually enables TBG business groups to learn and
take increasing advantage of the of UMM.
Effectively, in this transitional period, initial requirements will for the most part be
orientated around single processes that take account of UN/EDIFACT and the
introduction of initial XML implementations.
As a consequence of this progressive introduction of UMM the documentary
requirements will be minimized in an initial phase and will gradually increase as new
conceptual requirements are introduced as the population begins to master new
concepts.
This document therefore proposes the first template for the introductory phase where
the TBG business groups are required to provide business requirements specifications
as opposed to simply message specifications.
Each Business Requirements Specification may be accompanied by a Requirements
Specifications Mapping, serving to separate the aspects of a requirement that are of
greatest concern to business interests from those that are of concern to technical
design interests.
 CEFACT/ICG/005

4 Template outline.
4.1 Introduction
This outline is based on the work carried out by EAN.UCC with the Business
Requirements Document (BRD). It attempts to reduce duplication to a minimum and
puts its accent on the requirement for specifications rather than the requirement for a
complete set of UMM artifacts. It is in essence a much simplified subset of the UMM
requirements.

4.2 Business requirements specification basic outline

The Business Requirements Specification (BRS) shall have the following basic
outline. This outline is considered to be the minimum that must be contained in the
BRS. This does not exclude additional information being provided.
1. Business requirements specification
1.1. Objective
1.2. Scope
1.3. Business requirements
1.3.1. “Business requirements” views
1.3.1.1. Business process elaboration
1.3.1.2. Information flow definition
1.3.1.3. Information model definition
1.3.2. Business rules
1.3.3. Definition of terms
Each of these sections will be outlined in more detail in the rest of this document.
 CEFACT/ICG/005

4.3 Title and contents information

The title page of the Business Requirements Specification and shall be laid out as
described in figure 1.

Figure 1
There are 8 pieces of information that have to be provided on this page:
1. The business domain that the document belongs to.
2. The business process that is being described.
3. The unique identification of the document within the UN/CEFACT system.
4. The title of the document
5. The trade facilitation and Business process working group (TBWG)
responsible for the document or the TBG steering committee in the case of
cross domain projects.
6. The version of the document
7. The release of the document
8. The date of the document release (i.e. date of TBG final approval).
 CEFACT/ICG/005

Figure 2
The second page contains the change history log for the document as outlined in
figure 2. This page retraces all the changes that have occurred between version and
release changes.
The third page provides the table of contents as outlined in figure 3. The table of
contents may be complemented as necessary but the basic paragraphs shall always be
provided.
 CEFACT/ICG/005

Figure 3
These three basic pages shall be present in every Business requirements specification.
The rest of the document shall be composed of text and the necessary UMM diagrams
that are required to accompany the text. The UMM worksheet information may be
provided if this improves the comprehension of the specification.

4.4 Preamble
The preamble shall declare the document’s authority, describe the document structure
and define the process of creating and approving the document in question.

4.5 References
The references shall cite any required authorities or guidance for the document.

4.6 Objective
This section shall provide the intended business goal of the business process being
described in the document.
 CEFACT/ICG/005

4.7 Scope section

This section shall describe the extent and limits of the business process within the
business domain being described in the document.
The intended range of applicability for the information flows that are defined, or the
constraints on their use in any particular setting shall also be described. The following
categories may be used to assist in “dimensioning” applicability.
Categories Description and Values

Business Process

Product Classification

Industry Classification

Geopolitical

Official Constraint

Business Process Role

Supporting Role

System Capabilities

4.8 Business requirements section

This section shall describe in detail the business requirements that the information
flows are intended to satisfy. This section is the essential part of the document and
shall be divided into a set of sub-sections that are detailed below.

4.8.1 Business requirements views

The business requirements may be expressed from several views, for example,
operation, process, collaboration and transaction. Each of these views outlines the
contexts of elaboration, information flow definition and information model definition.
The number of views used within the requirements specification depends on the
complexity of the subject matter being described. In a simple case for example, a
business process viewpoint may be sufficient to provide all the necessary
requirements. In more complex cases additional views may be necessary. The BRS
template will only outlines the simple case. It should be noted that the three sub
sections described below are equally valid for each view.

4.8.1.1 Business process elaboration

The business process elaboration sub section shall describe the overall business
process behaviour of the system without going into the detailed the internal workings
of each entity. It shall essentially define the external requirements of the business
process. In order to correctly do this, it shall make use of a number of “use case”
diagrams.
Each use case diagram produced shall be fully described.
 CEFACT/ICG/005

4.8.1.2 Information flow definition

The process elaboration shall also provide one or more activity diagrams centered
around the area of interest that identified all the significant information flows between
the various actors of the scenario. The activity diagram shall also be described in
detail.
In some cases a sequence diagram may be used to provide an overall perspective of
the sequence of events. It shows an interaction arranged in time sequence. In
particular, it shows the instances participating in the interaction by their “lifelines”
and the triggers they exchange arranged in time sequence. It does not show the
associations among the objects.
In some cases it might be more advantageous to make use of a collaboration diagram
along with, or instead of a sequence diagram.
The process elaboration shall terminate with more detailed activity diagrams
describing the information flows that are the main subject matter of the specification.

4.8.1.3 Information model definition

Once the information flows that are the subject matter of the document have been
clearly identified it is necessary to identify the required content of each flow. This is
achieved through the use of “class” diagrams that describe the necessary classes of
information, the relationship between the different classes and the required attributes
that are to be found within each class. Each of these pieces of information shall be
fully described. It is important to stress that the class diagram for an information flow
shall reflect the business requirements for that flow in a totally neutral form. The
diagram shall not attempt to map in any way to a syntax dependent implementation of
the information in question.
At this level the class diagram represents the set of classes(or entities) that are
required to convey the necessary information in the information flow being described.
It also indicates the relationships and cardinality that exists between each of the
classes.
Each class and its associated attributes shall be completely defined in a business
context rather than a technology context.

4.8.2 Business rules

In order to fully describe the interactions and interrelationships that exist between the
activity diagrams, the class diagrams and the information within them, a table of
business rules shall be defined explaining all the rules that are necessary to ensure the
coherence of the business process as viewed within this document. It naturally
includes the business rules that the information flows have to adhere to as well as the
rules governing the conditionality of the information within the class diagrams.
The business rules shall also include any “service” requirements, such as security,
system level acknowledgements, etc…

4.8.3 Definition of terms

This final required information shall provide a definition of all the business terms that
are used in detailing the process that the information flows satisfy.
 CEFACT/ICG/005

5 Conclusion
The requirements set out in this document shall be considered the minimum
requirement for a business requirements specification. It does not exclude a more
detailed documentation making use of all the artifacts described within the UMM.