ISO/IEC TR 14143-4:2002

Information technology — Software measurement — Functional size measurement — Part 4: Reference model

Part 4 of ISO/IEC 14143 defines the reference model (Figure 0.1) to be used when verifying a Functional Size Measurement (FSM) method. The reference model consists of two components: - a classification framework of Reference User Requirements (RUR) which can be sized using an FSM Method. Included are examples of such RUR as well as references to further publications of User Requirements (UR) which can be used for RUR, and - guidance on selecting Reference FSM Methods, against which an FSM Method can be compared. The reference model is an input to the evaluation process of an FSM Method. The formulation and execution of evaluation tests and the interpretation of their results is outside the scope of this Technical Report. The RUR and additional references contained in this Technical Report only represent examples of UR in some domains and situations. Additional RUR and RUR for domains and situations not covered by Annex A, B, or C may be generated with the assistance of the framework described in this Technical Report. The requirements for Reference FSM Methods may assist in selecting Reference FSM Methods.

Technologies de l'information — Mesurage du logiciel — Mesurage de la taille fonctionnelle — Partie 4: Modèle de référence

General Information

• Status: Published
• Publication Date: 25-Sep-2002
• ICS: 35.080 - Software
• Technical Committee: ISO/IEC JTC 1/SC 7 - Software and systems engineering
• Drafting Committee: ISO/IEC JTC 1/SC 7 - Software and systems engineering
• Current Stage: 9093 - International Standard confirmed
• Start Date: 06-Jul-2022
• Completion Date: 12-Feb-2026

Overview

ISO/IEC TR 14143-4:2002 - "Information technology - Software measurement - Functional size measurement - Part 4: Reference model" defines a reference model to support verification of Functional Size Measurement (FSM) methods. The Technical Report provides a structured classification framework of Reference User Requirements (RUR) and guidance for selecting Reference FSM Methods. It is an input to FSM method evaluation and benchmarking; the design and execution of specific evaluation tests and interpretation of results are outside its scope.

Key topics and requirements

• Reference model composition
  • Two main components: a classification framework for Reference User Requirements (RUR) and guidance for choosing Reference FSM Methods.
• Reference User Requirements (RUR)
  • Framework for identifying, classifying and selecting RUR usable with any FSM method.
  • Includes examples and normative RUR in Annex A (business applications) and Annex B (real-time/control systems).
  • Annex C provides an informative RUR reference list for additional domains.
  • Defines how an RUR Collection is formed to match specific evaluation purposes.
• Reference FSM Methods
  • General requirements (Clause 6) to help select FSM methods that can serve as benchmarking references.
  • Reference methods provide standard points of comparison when verifying another FSM method.
• Terms and definitions
  • Clarifies concepts such as Functional User Requirements (FUR), Quality Requirements (QR), Technical Requirements (TR), RUR, and Reference FSM Method in alignment with ISO/IEC 14143-1.
• Normative context
  • Cross-references ISO/IEC 14143-1:1998 (concepts) and ISO/IEC 9126 (software quality).

Applications and users

ISO/IEC TR 14143-4:2002 is practical for:

• Organizations and teams validating or selecting an FSM method for software sizing and cost estimation.
• Measurement and quality assurance specialists benchmarking FSM tools and procedures.
• Procurement and contract teams requiring standardized sizing evidence for bids and vendor comparisons.
• Tool vendors and FSM method developers seeking to demonstrate method transparency and comparability.
• Researchers and consultants performing comparative studies of functional size measurement techniques.

Practical uses include creating representative RUR Collections for benchmarking, selecting suitable Reference FSM Methods, and establishing repeatable inputs for method verification and cross-method comparison.

Related standards

• ISO/IEC 14143-1:1998 - Definition of concepts (part of the same family)
• ISO/IEC 14143-2 / -3 / -5 - Conformity evaluation, verification, and domain determination of FSM methods
• ISO/IEC 9126 - Software product quality characteristics

Keywords: ISO/IEC TR 14143-4:2002, functional size measurement, FSM, Reference User Requirements, RUR, Reference FSM Method, software measurement, software sizing, benchmarking, verification.

Standards Content (Sample)

TECHNICAL ISO/IEC
REPORT TR
14143-4
First edition
2002-08-15
Information technology — Software
measurement — Functional size
measurement —
Part 4:
Reference model
Technologies de l'information — Mesurage du logiciel — Mesurage de la
taille fonctionnelle —
Partie 4: Modèle de référence
Reference number
©
ISO/IEC 2002
PDF disclaimer
This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but shall not
be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In downloading this
file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat accepts no liability in this
area.
Adobe is a trademark of Adobe Systems Incorporated.
Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation parameters
were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In the unlikely event
that a problem relating to it is found, please inform the Central Secretariat at the address given below.

©  ISO/IEC 2002
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means, electronic
or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or ISO's member body
in the country of the requester.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail [e-mail]
Web www.iso.ch
Printed in Switzerland
ii © ISO/IEC 2002 – All rights reserved

Contents Page
1. SCOPE . 1
2. NORMATIVE REFERENCES . 1
3. TERMS AND DEFINITIONS . 2
4. ABBREVIATED TERMS. 3
5. REFERENCE USER REQUIREMENTS. 3
5.1. General requirements . 3
5.2. Examples . 5
6. REFERENCE FSM METHOD . 6
6.1. General requirements . 6
6.2. Example Use of Reference FSM Methods. 6
ANNEX A: BUSINESS APPLICATION RUR (NORMATIVE) . 7
A.1 RUR A1: Hotel Accommodation System (Reservation). 7
A.2 RUR A2: Hotel Accommodation System (Reservations) - Initial Requirement. 17
A.3 RUR A3: Hotel Accommodation System (Reservations) – Mock-up. 19
A.4 RUR A4: Adding automatic name look-up to Hotel Reservation System. 19
A.5 RUR A5: Adding automatic name look-up to Hotel Reservation System. 19
A.6 RUR A6: Adding automatic name look-up to Hotel Reservation System. 20
A.7 RUR A7: TRAX Transaction Reporting. 20
A.8 RUR A8: Requirements Paris Bourse Netting. 38
ANNEX B: REAL TIME / CONTROL RUR (NORMATIVE). 46
B.1 RUR B1 : Basic Subtraction . 46
B.2 RUR B2: Significantly larger function . 46
B.3 RUR B3: Slightly larger function. 46
B.4 RUR B4: User requirement of a single display field . 47
B.5 RUR B5: User requirement for error messages. 47
B.6 RUR B6: User requirement of user maintained error messages. 47
B.7 RUR B7: User requirement of an internal function. 47
B.8 RUR B8: Automatic line switching . 48
B.9 RUR B9: Valve Control System . 50
B.10 RUR B10: Gateway System . 52
B.11 RUR B11: L-Euchre card game (minimal implementation). 78
B.12 RUR B12: L-Euchre system (Usable system implementation) .90
B.13 RUR B13: Standard Euchre system. 90
B.14 RUR B14: Super Euchre system . 90
ANNEX C: RUR REFERENCE LIST (INFORMATIVE). 91
C.1 RUR name: Sales/order system. 91
C.2 RUR name: Travel arrangements. 91
C.3 RUR name: Standing orders support. 91
C.4 RUR name: Production Planning and control. 91

© ISO/IEC 2002 – All rights reserved iii

C.5 RUR name: Marketing Information System.92
C.6 RUR name: Business Analysis.92
C.7 RUR name: Accounting System.92
C.8 RUR name: Payroll .92
C.9 RUR name: Purchasing .92
C.10 RUR name: Accounts Payable .93
C.11 RUR name: Human Resources System .93
C.12 RUR name: Revised Human Resources System .93
C.13 RUR name: Traffic Control System .93
C.14 RUR name: Student Selection System.93
C.15 RUR name: Stock Taking System.94
C.16 RUR name: Accounts Payable System .94
C.17 RUR name: Enhanced Accounts Payable System .94
C.18 RUR name: Package Routing.94
C.19 RUR name: Simple Library System .94
C.20 RUR name: Library System II.95

iv © ISO/IEC 2002 – All rights reserved

Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical Commission)
form the specialized system for worldwide standardization. National bodies that are members of ISO or IEC
participate in the development of International Standards through technical committees established by the
respective organization to deal with particular fields of technical activity. ISO and IEC technical committees
collaborate in fields of mutual interest. Other international organizations, governmental and non-governmental, in
liaison with ISO and IEC, also take part in the work. In the field of information technology, ISO and IEC have
established a joint technical committee, ISO/IEC JTC 1.
The main task of technical committees is to prepare International Standards, but in exceptional circumstances a
technical committee may propose the publication of a Technical Report of one of the following types:
 type 1, when the required support cannot be obtained for the publication of an International Standard, despite
repeated efforts;
 type 2, when the subject is still under technical development or where for any other reason there is the future
but not immediate possibility of an agreement on an International Standard;
 type 3, when a technical committee has collected data of a different kind than that which is normally published
as an International Standard (“state of the art”, for example).
Technical Reports of types 1 and 2 are subject to review within three years of publication, to decide whether they
can be transformed into International Standards. Technical Reports of type 3 do not necessarily have to be
reviewed until the data they provide are considered to be no longer valid or useful.
Technical Reports are drafted in accordance with the rules given in the ISO/IEC Directives, Part 3.
Attention is drawn to the possibility that some of the elements of this part of ISO/IEC 14143 may be the subject of
patent rights. ISO and IEC shall not be held responsible for identifying any or all such patent rights.
ISO/IEC TR 14143-4, which is a Technical Report of type 2, was prepared by Joint Technical Committee
ISO/IEC JTC 1, Information technology, Subcommittee SC 7, Software engineering.
ISO/IEC 14143 consists of the following parts, under the general title Information technology — Software
measurement — Functional size measurement:
 Part 1: Definition of concepts
 Part 2: Conformity evaluation of software size measurement methods to ISO/IEC 14143-1:1998
 Part 3: Verification of functional size measurement methods
 Part 4: Reference model
 Part 5: Determination of functional domains for use with functional size measurement
Annexes A and B form a normative part of this part of ISO/IEC 14143. Annex C is for information only.

© ISO/IEC 2002 – All rights reserved v

Introduction
The user of an FSM Method must establish that the FSM Method is appropriate to quantify the functional size of the
software. The conformity to ISO/IEC 14143-1:1998 will be necessary but may not be sufficient. An evaluation
process of an FSM Method will have to consider practical evidence of the performance of the FSM Method. Such
an evaluation may require benchmarking the chosen FSM Method to compare its results for a collection of known
Reference User Requirements (RUR) with those obtained from a Reference FSM Method.
Part 4 of ISO/IEC 14143 provides standard RUR together with guidance on Reference FSM Methods. Figure 0.1
shows how these are used to establish reference results. The FSM Method to be evaluated determines functional
size results for a collection of appropriate RUR. The same collection of RUR is measured by one or more
Reference FSM Methods and these reference results are then compared with the results obtained from the FSM
Method to be evaluated.
FSM
Method to be
evaluated
measurement
according to FSM results
Method
RUR
evaluation
Collection
measurement
according to
reference
Reference FSM
results
Reference Method(s)
FSM
Method(s)
Figure 0.1: Use of RUR and Reference FSM Methods
Clause 5 of this part of ISO/IEC 14143 defines a framework for identifying, classifying and selecting RUR. Annexes
A and B provide examples of such RUR in two different domains. While it would be desirable to have an exhaustive
set of such RUR, the size of such collection would be prohibitive. Further RUR can be found in the RUR reference
list presented in Annex C. Additional appropriate RUR may be constructed according to the basic guidelines stated
in clause 5 RUR.
Clause 6 of this part of ISO/IEC 14143 introduces the general requirements for Reference FSM Methods. The
reference FSM Methods provide reference points, against which other FSM Methods can be compared.

vi © ISO/IEC 2002 – All rights reserved

TECHNICAL REPORT ISO/IEC TR 14143-4:2002(E)

Information technology — Software measurement — Functional
size measurement —
Part 4:
Reference model
1. Scope
Part 4 of ISO/IEC 14143 defines the reference model (Figure 0.1) to be used when verifying a Functional Size
Measurement (FSM) method.
The reference model consists of two components:
- a classification framework of Reference User Requirements (RUR) which can be sized using an FSM
Method. Included are examples of such RUR as well as references to further publications of User
Requirements (UR) which can be used for RUR, and
- guidance on selecting Reference FSM Methods, against which an FSM Method can be compared.
The reference model is an input to the evaluation process of an FSM Method. The formulation and execution of
evaluation tests and the interpretation of their results is outside the scope of this Technical Report.
The RUR and additional references contained in this Technical Report only represent examples of UR in some
domains and situations. Additional RUR and RUR for domains and situations not covered by Annex A, B, or C may
be generated with the assistance of the framework described in this Technical Report.
The requirements for Reference FSM Methods may assist in selecting Reference FSM Methods.
2. Normative references
The following normative documents contain provisions which, through reference in this text, constitute provisions of
this part of ISO/IEC 14143. For dated references, subsequent amendments to, or revisions of, any of these
publications do not apply. However, parties to agreements based on this part of ISO/IEC 14143 are encouraged to
investigate the possibility of applying the most recent editions of the normative documents indicated below. For
undated references, the latest edition of the normative document referred to applies. Members of ISO and IEC
maintain registers of currently valid International Standards.
ISO/IEC 14143-1:1998, Information technology — Software measurement — Functional size measurement —
Part 1: Definition of concepts.
ISO/IEC 9126:1991, Information technology — Software product evaluation — Quality characteristics and
guidelines for their use.
© ISO/IEC 2002 – All rights reserved 1

3. Terms and definitions
For the purposes of this Technical Report, the terms and definitions given in the normative references and the
following apply. Figure 3.1 describes the composition of User Requirements, RUR, and RUR Collection.
3.1
Functional User Requirements (FUR)
A sub-set of the User Requirements. The Functional User Requirements represent the users practices and
procedures that the software must perform to fulfil the users' needs. They exclude Quality Requirements and any
Technical Requirements.
NOTE   As defined by ISO/IEC 14143-1:1998.
3.2
Quality Requirements (QR)
Any requirements relating to software quality as defined in ISO/IEC 9126.
NOTE   As defined by ISO/IEC 14143-1:1998. Quality Requirements are a subset of the User Requirements.
3.3
Reference FSM Method
An FSM Method to be used for comparison reasons when verifying the Functional Size Measurement results. It
conforms to the requirements as specified in 6.1.
3.4
Reference User Requirements (RUR)
A standard set of User Requirements which conforms to the requirements as specified in 5.1.1.
NOTE   Figure 3.1 shows the relationship of UR and RUR.
3.5
Reference User Requirement Collection (RUR Collection)
A subset of RUR which is selected to match the purpose in a specific evaluation. The selection requirements are
specified in 5.1.2.
NOTE   Figure 3.1 shows the relationship of RUR and RUR Collection.
3.6
Technical Requirements (TR)
Requirements relating to the technology and environment, for the development, maintenance, support and
execution of the software.
NOTE   As defined by ISO/IEC 14143-1:1998. Technical Requirements are a subset of the User Requirements.
3.7
User Requirements (UR)
The complete description of the set of user needs for the software to be provided. User Requirements include
Functional User Requirements, Technical Requirements and Quality Requirements.
2 © ISO/IEC 2002 – All rights reserved

RUR Collection
RUR
RUR
Selected for specific
evaluation (Sec.5.1.2)
RUR
RUR
RUR
Selected for general
use (Sec.5.1.1)
UR(RUR candidates)
FUR QR TR
FUR QR TR
Figure 3.1: Composition of User Requirements and RUR (informative)

4. Abbreviated terms
FSM Functional Size Measurement
FUR Functional User Requirements
QR Quality Requirements
RUR Reference User Requirements
TR Technical Requirements
UR User Requirements
5. Reference User Requirements
5.1. General requirements
To be acceptable for the evaluation of an FSM Method, the RUR Collection shall consist of RUR complying with
5.1.1 and which are selected according to the rules stated in 5.1.2.
© ISO/IEC 2002 – All rights reserved 3

5.1.1. RUR requirements
Individual RUR shall:
a) be documented in such a form that they can be understood by a human user specialised in the area
addressed by the RUR,
NOTE  The RUR should be representative of the user requirements. Acceptable presentation formats include textual and
graphical descriptions of the functionality, acceptable to the users in the particular Functional Domain. Examples of
unacceptable forms of documentation are technical design documentation, computer program listings, or terminology
representative of Information Technology.
b) represent a complete and self contained user practice or procedure, and
NOTE  The RUR should provide all requirements necessary to perform a user practice or procedure but need not provide a
complete set of requirements as would be needed for a practical system. Different FSM Methods will have different methods of
identifying Base Functional Components. RUR containing only a subset of a user practice or procedure may therefore distort the
results. An example of partial FUR would be the data entity requirements only (A.1.3) for the Hotel Accommodation System in
RUR A1, or the screen layout of the RES function in A.1.2.2.1 of RUR A1.
c) be tested and be free of ambiguities and inconsistencies.
NOTE  Acceptable compliance with this requirement would be that the RUR has been successfully implemented as a software
product, been published in a refereed textbook or journal, or been used successfully in an Functional Size Measurement.
5.1.2. RUR Collection selection requirements
RUR selected for a RUR Collection shall:
a) be representative of the Functional Domain for which the FSM Method is evaluated,
NOTE  The RUR should represent the Functional Domain(s) selected for evaluation of the FSM Method. The functionality
should be consistent with the characteristics of the Functional Domain.
b) not biased to a particular FSM Method or evaluation process,
NOTE  The RUR should be constructed or selected without any bias. They should not favour, or discriminate against, a
particular FSM Method or evaluation process.
c) include example FUR with equal, unequal, and significantly unequal Functional Size,
NOTE  The RUR should have example functions of different Functional Sizes to enable an FSM Method to distinguish between
small and large functionality. In the absence of an absolute Functional Size indicator such distinctions can only be rough and at
the order of magnitude level. Selection criteria could be user perception or any quantifiable functional characteristic such as
number of data fields, decision alternatives, business rules or data references.
d) include User Requirements not restricted to Functional User Requirements as defined in
ISO/IEC 14143-1:1998,
NOTE  Some RUR should include requirements such as Quality Requirements or Technical Requirements. Examples of non-
functional requirements include reliability, cost, development time, or computer architecture constraints.
e) when assessing an FSM Method for independence from technology or implementation techniques include
different versions of the same user requirement with different:
1. implementation technologies,
2. development methodologies, or
3. documentation levels,
4 © ISO/IEC 2002 – All rights reserved

NOTE  The RUR should enable the FSM Method to demonstrate its independence from implementation technology and
development methodology and its coverage at various stages of software development.
and
f) include examples of changes of requirements when assessing an FSM Method for software enhancement
measurement.
5.2. Examples
Annexes A and B include examples of RUR for the areas of business application and real time / control. Annex C
provides references to published User Requirements, which in addition could be used as RUR. The references in
Annex C, however, have not been formally checked against the rules stated in 5.1.1.
5.2.1. Business application
Annex A lists 8 RUR: RUR A1 to RUR A8. The first 6 RUR describe part of a hotel reservation system but do so in
different forms and functionality. As such they provide an example for the requirements 5.1.1.a) (documentation),
5.1.1.b) (completeness), 5.1.1.c) tested and unambiguous, 5.1.2.c) (range of functional size), 5.1.2.e)
(implementation independence) and 5.1.2.f) changed requirements:
- RUR A1 includes a detailed specification of the layout of the user interfaces,
- RUR A2 provides a more general description of the same requirement, but lacks some of the details
shown in RUR A1,
- RUR A3 has the same user interface as RUR A1 but only simulates the business functions rather than
executing the business logic of the operations,
- RUR A4-A6 describe several modifications to RUR A1, and
- RUR A7 and RUR A8 are examples of complex RUR, describing sections of actual requirements used
by a financial organisation.
5.2.2. Real Time /control
Annex B contains several RUR of different size and implementation. These RUR provide examples for the
requirements 5.1.1.b) (completeness), 5.1.2.c) (range of functional size), and 5.1.2.d) (non-functional
requirements):
- RUR B1 sets the baseline for RUR B2 to B7,
- RUR B2 should have a substantially larger functional size compared with RUR B1 since it contains
three times the number of functions of RUR B1. RUR B3 again should be larger in functional size when
compared with RUR B2 since additional functions are performed,
- RUR B4, RUR B5, and RUR B6 describe three different non-functional technical or implementation
requirements for RUR B3,
- RUR B7 describes a different use for the requirement of RUR B3,
- RUR B8 addresses a process control application, which continuously monitors and controls a
communication line,
- RUR B9 describes a valve control application, and
- RUR B10 is an example of a complex RUR for a communication control system.
© ISO/IEC 2002 – All rights reserved 5

6. Reference FSM Method
Reference FSM Methods in combination with RUR can be used to establish a known baseline of results (see figure
0.1). This will then allow a benchmark to be performed for an FSM Method (see figure 0.1). Compared with results
of a Reference FSM Method, an FSM Method can establish its position relative to that Reference FSM Method.
A Reference FSM Method may be valid for only some Functional Domains. It will provide a reference point for the
relative evaluation of a chosen FSM Method for a specific situation.
6.1. General requirements
A Reference FSM Method itself shall:
a) conform to ISO/IEC 14143-1:1998 according to ISO/IEC 14143-2,
b) cover the same Functional Domain as that described within the FSM Method to be assessed,
c) be publicly available, and
d) be verified for its minimum effectiveness to the purpose of the evaluation.
6.2. Example Use of Reference FSM Methods
Using several different Reference FSM Methods will provide a range of references in relation to which FSM
Methods can be positioned. Suitable Reference FSM Methods for the creation of such a range of reference results
would be a superficial Reference FSM Method at one end of the range and a comprehensive Reference FSM
Method at the other end.
6.2.1. Superficial Reference FSM Method
A superficial Reference FSM Method would formally conform to ISO/IEC 14143-1:1998. Verification according to
PDTR 14143-3, however, should reveal a very limited capability of measuring Functional Size. Such a superficial
Reference FSM Method could be the starting point of an evaluation scale.
6.2.2. Comprehensive Reference FSM Method
A comprehensive Reference FSM Method would have an enhanced capability of identifying Functional Size in a
wide range of instances. Compared with a superficial Reference FSM Method, its performance parameters, as
established by PDTR 14143-3, should be substantially improved.

6 © ISO/IEC 2002 – All rights reserved

Annex A
(normative)
Business application RUR
A.1 RUR A1: Hotel Accommodation System (Reservation)
A.1.1 Overview
The hotel reservation system is part of an accommodation system of a general hotel system. This section provides
an overview of the requested system. The detailed functionality of the hotel reservation system together with the
navigation to reach it within the hotel system will be described in the next section.
The reservation system supports the following business functions related to the letting of hotel rooms:
- maintain reservations
- confirm reservations
Room data used relates to room type, price, and description (in Dutch, English, French, or German), and anyone
can make a reservation for a room type. The System confirms a reservation in either English, Dutch, German or
French. It is possible to cancel a reservation.
The system uses a number of general data entities, which are maintained by other parts of the hotel
accommodation system:
- HOTEL, data includes: name, address, telephone, telex, fax, hotel manager name,
- COUNTRY, data includes country code and country name, and
- ROOM and ROOM TYPE, describe a hotel room and the various room classes.
The hotel reservation system ensures consecutive numbering by storing the last issued reservation number in a file
called “PARAMETERS.”
The following general requirements apply to all parts of the hotel accommodation system:
- help information must be available on screen level and field level,
- error messages are standard on Line 24 of the screen.
A.1.2 Detailed specifications
To identify the type of data entered into the accommodation system the menu layouts in this specification use a
string of "9" to denote numeric and a string of "x" to denote alphanumeric data.
A.1.2.1 Navigation
A.1.2.1.1 Main menu of hotel system
The main menu of the hotel system offers two choices: accommodation and invoice & payment. The reservation
system is part of the accommodation system.
Screen layout for the main menu:

© ISO/IEC 2002 – All rights reserved 7

HOTEL SYSTEM
< Hotel name >
1 ACCOMMODATION
2 INVOICE & PAYMENT
Choice: < S> F10
End
Functions:
F10 : Exit application
Screen elements:
Menu choice, Hotel name
A.1.2.1.2 Accommodation menu selections
Screen layout for the accommodation menu:

ACCOMMODATION SYSTEM
< Hotel name >
1  RESERVATION
2  CHECK-IN
3  CHECK-OUT
4  CANCEL
RESERVATION
MAINTAIN ROOM DATA
F10
Choice:
MENU
Function:
F10 : Return to Main menu
Screen elements:
Menu choice, Hotel name
NOTE  The reservation system functions are reached via the first option: Reservation.
8 © ISO/IEC 2002 – All rights reserved

A.1.2.2 Functions
A.1.2.2.1 Function: RES Reservation
A reservation request can be entered using the screen RES. All data except the reservation number is entered.
When changing the reservation data using screen RES, the reservation number can be found by name, or part of a
name. All data, except reservation number, can be changed. If there is more than one reservation with the same
name, the selection - screen (SEL- RES) is shown.
The system further checks if the stated quantity of rooms for the desired room type is available in the desired
period (not occupied or not reserved). “Being occupied” is checked on the basis of the data: room type, start date,
number of days, and quantity of reserved rooms.
If necessary more room types can be stored for the same period. Only room type and quantity of rooms can be
entered.
If the request can be met, the acceptance screen ACP-RES stores the reservation and a confirmation of the
reservation (CON-RES) is produced for the billing address. If the request cannot be met, room type report (RT-
REP) is called to look up an alternative choice.
Used screens: RES (request for reservation), SEL-RES (selection reservations), ACP-RES (accept reservation),
RT-REP (room type report), CON-RES (confirmation of reservation).
Screen layout for RES(ervation) function:

< Hotel name > RESERVATION
Reservation number: 999999
Arrival date: DD/MM/YYYY
Number of days: 99
Room type & quantity: xx 99
Name: xxxxxxxxxxxxxxxxxxxxxxxxx

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 999

Street & number:
Post code, City, Country: 99999 xxxxxxxxxxxxxxxxxxxx xx

Telephone number: 999999999999

Language code:
xx
F1 F2  F3 F10
Continue Confirm  Change Menu

Functions:
F1 : Continue reservation for the same period
F2 : Confirm reservation
F3 : Change reservation data (except reservation number) of this reservation number
F10: Return to previous menu
© ISO/IEC 2002 – All rights reserved 9

Screen elements:
Arrival date Street Number of days
Street number Telephone number Quantity
Name Country code Reservation number
City Hotel name Room type
Post code Language code
A.1.2.2.2 Function: ACP-RES Accept reservation
This function is performed by function RES when a reservation request can be met. It displays the reservation
details and the assigned reservation number. An accepted reservation can then be confirmed.
Screen layout for ACP-RES function:
< Hotel name >  ACCEPT RESERVATION
Reservation number: 999999
Name: xxxxxxxxxxxxxxxxxxxxxxxxx
Arrival date: DD/MM/YYYY
Number of days: 99
Room type & quantity Room type & quantity
xx 99 xx 99
xx 99 xx 99
xx 99 xx 99
xx 99 xx 99
xx 99 xx 99
F1 F2 F10
Continue Menu
Accept
Functions:
F1 : Continue reservation
F2 : Accept reservation, print confirmation, and return to previous menu
F10: Return to previous menu
10 © ISO/IEC 2002 – All rights reserved

Screen elements:
Arrival date Number of days Reservation number
Name Quantity Room type
Hotel name
A.1.2.2.3 Function: SEL-RES Select Reservation
Reservation report based on the partial name of the one who makes the reservation. This function is activated by
RES when a reservation is accessed by billing name and there is more than one reservation stored for that name.
Screen layout for SEL-RES function:

< Hotel name >  SELECT RESERVATION
Name   City            Arrival Date   Res.no.
xxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxx   DD/MM/YYYY 999999
xxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxx   DD/MM/YYYY 999999
xxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxx   DD/MM/YYYY 999999
xxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxx   DD/MM/YYYY 999999
xxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxx   DD/MM/YYYY 999999
xxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxx   DD/MM/YYYY 999999
xxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxx   DD/MM/YYYY 999999
xxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxx   DD/MM/YYYY 999999
F1 F9 F10
Select Prior Menu
Functions:
F1 : Select a reservation and return to previous screen
F9 : Return to previous screen
F10: Return to previous menu
Screen elements:
Arrival date City Reservation number
Name Hotel name
© ISO/IEC 2002 – All rights reserved 11

A.1.2.2.4 Function: RT-REP Room Type Report
This report is provided when a requested room type is not available. Room type report shows the quantity of rooms
which:
- are not occupied, and
- are not reserved
Screen layout for RT-REP function:

< Hotel name >  ROOM TYPE REPORT

Arrival Date: DD/MM/YYYY 999999

Number of days: 99
Room type Quantity
xx 99
xx 99
xx 99
xx 99
xx 99
xx 99
F9 F10
Prior Menu
Functions:
F9 : Return to previous screen
F10: Return to previous menu
Screen elements:
Arrival date Quantity Room type
Hotel name Number of days
A.1.2.2.5 Function: CON-RES Confirmation of the reservation
This function is performed when an accepted reservation is confirmed. The confirmation can be made in four
languages ( EN, FR, GE, or NL).
12 © ISO/IEC 2002 – All rights reserved

Report layout for CON-RES function:

<1>
<2>
<3> <4>
<5>
Phone:
Fax: <6>
<7>
<8>
Report elements:
<9> <10>
<1> hotel name <7> name <14> number of days
<11>
<2> hotel street address <8> street address <15> Arrival date
CONFIRMATION OF RESERVATION
<3> postcode – hotel <9> postcode <16> room type
Reservation Number: <12> Date: <13>
<4> city - hotel <10> city <17> quantity
Dear Madam/ Sir,
<5> telephone number – hotel <11> country <18> description of room type
<6> fax - hotel <12> reservation number <19> hotel manager
We have made the following reservation:
<13> date (system)
Number of days: <14> Arrival Date: <15>

Description of Entities
Room description
The following business entities will be used by the Hotel Reservation System:
Room type: <16> Quantity: <17> <18>
A.1.2.3 BILLING ADDRESS
Room type: <16> Quantity: <17> <18>
A person or institution that will pay or has booked a reservation. The person or institution is identified by a system
Room type: <16> Quantity: <17> <18>
generated Billing-identification.
Room type: <16> Quantity: <17> <18>
Data elements: Billing-identification (key) 6
Room type: <16> Quantity: <17> <18>
name 25
Room type: <16> Quantity: <17> <18>
street address 30
post code 4
Kind Regards
city 20
Hotel Manager
telephone number 12
<19>
country code 2
R
© ISO/IEC 2002 – All rights reserved 13

Report elements:
<1> hotel name <7> name <14> number of days
<2> hotel street address <8> street address <15> Arrival date
<3> postcode – hotel <9> postcode <16> room type
<4> city - hotel <10> city <17> quantity
<5> telephone number – hotel <11> country <18> description of room type
<6> fax - hotel <12> reservation number <19> hotel manager
<13> date (system)
A.1.3 Description of Entities
The following business entities will be used by the Hotel Reservation System:
A.1.3.1 BILLING ADDRESS
A person or institution that will pay or has booked a reservation. The person or institution is identified by a system
generated Billing-identification.
Data elements: Billing-identification (key) 6
name 25
street address 30
post code 4
city 20
telephone number 12
country code 2
A.1.3.2 ROOM
Contains data about a room that can be let. There is at least 1 room and at most 30 rooms per room type.
Data elements: Room number (key) 3
Room type 2
14 © ISO/IEC 2002 – All rights reserved

A.1.3.3 HOTEL
Contains data concerning the hotel that uses the system. The entity contains only one occurrence and can never
contain more.
Data elements: Hotel name (key) 30
Street address 30
City 20
Post code 7
Telephone number 12
Telex 12
Fax 12
Hotel manager 25
A.1.3.4 ROOM CLASS
Indicates the quality and price of a number of similar rooms. There are at most 10 room types.
Data elements: Room type (key) 2
Price of accommodation 6
Description-EN 30
Description-FR 30
Description-GE 30
Description-NL 30
A.1.3.5 COUNTRY
Country where the person, who has made/ paid the reservation, lives. Do not confuse Country code with language.
There are 4 languages supported by the system but the customers may live in many more countries.
Data elements: Country code (key) 2
Country-EN 25
Country-FR 25
Country-GE 25
Country-NL 25
© ISO/IEC 2002 – All rights reserved 15

A.1.3.6 PARAMETERS
Parameter data for reserving rooms and producing invoices.
Data elements: Last issued reservation number 6
Last issued invoice number 6
Last issued payment number 6
A.1.3.7 RESERVATION
The number of rooms of a certain type that have been promised for a reservation. Language code can be one of
the 4 supported languages (EN, FR, GE, NL).
Data elements: Reservation number (key) 6
Start date 10
Number of days 2
Billing-identification 6
Language code 2
A.1.3.8 RESERVATION DETAIL
Denotes the quantity in a certain room type that has been promised for a reservation.
Data elements: Reservation number (key) 6
Room type 2
Quantity 2
16 © ISO/IEC 2002 – All rights reserved

A.2 RUR A2: Hotel Accommodation System (Reservations) - Initial Requirement
A.2.1 Business Functions to be supported
The system supports the following administrative functions of a hotel business in relation to the letting of hotel
rooms:
a) maintain reservations
1) create a reservation: obtain a reservation no. and enter all reservation details
2) update a reservation: change any reservation details except reservation number
3) continue a reservation: continue a complex reservation of more than one input screen
4) accept a reservation: finalise a reservation

b) confirm reservations
1) letter to client confirming the reservation details

c) reports
1) room type report: lists room availability from an arrival date for a number of days
2) reservation report: lists arrival date and reservation number for the reservation's billing name and address.

Room data used relates to room type, price, and description (in Dutch, English, French, or German).
Anyone can make a reservation for a room type. The System confirms a reservation in English, Dutch, German or
French.
A.2.2 General requirements
The accommodation reservation system has to ensure consecutive and unique numbering of the reservation
number.
The following general conventions apply to the accommodation system:
- identification – each functional screen should list the hotel name and the function name,
- navigation – function keys should be used to select, confirm, change, scroll, or continue business
processes,
- help information must be available on screen level and field level, and
- error messages should be displayed when applicable on each screen.
A.2.3 Data Model
The general data files used by the accommodation reservation system include HOTEL, COUNTRY, ROOM, and
ROOM TYPE.
These data files are maintained by other parts of the hotel system.
Entity Descriptions are as follows:
BILLING ADDRESS - A person or institution that will pay or has booked a reservation,
HOTEL - Data concerning the hotel that uses the system. The entity never contains more than one occurrence,
ROOM - A room, which can be let. There is at least one room and at most 30 rooms per room type,
ROOM CLASS - Indication of quality and price of a number of similar rooms. There are at most 10 room types,
COUNTRY - Country where the person, who has made/ paid the reservation, lives,
RESERVATION - Promise to a customer that during a certain period a stated number of rooms for stated room
types can be accommodated, and
© ISO/IEC 2002 – All rights reserved 17

RESERVATION DETAIL - Number of rooms in a certain room type that has been promised for a reservation.
The data model of the hotel reservation system is shown in Fig.A.1.
Room
Room number (k)
Hotel
Room class
Room type
Hotel name (k)
Room type(k)
Street address,
Reservation details
Price of accommodation
City
Reservation number (k)
Description-EN
Post code
Room type (k)
Description-NL
Telephone number
Number of reserved rooms
Description-GE
Telex, Fax
Description-FR
Hotel manager
Billing address
Country
Reservation
Billing-identification(k)
Country code(k)
Reservation number (k)
Name
Country-EN
Start date
Street Address
Country-NL
Number of days
Post code ,City
Country-GE
Billing-identification
Telephone number
Country-FR
Language code
Country code
Figure A.1 — Data model of Hotel Reservation System
18 © ISO/IEC 2002 – All rights reserved

--
...