See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/2669020

SRSM: A Software Requirements Specification Method

Article · April 1994

Source: CiteSeer

CITATIONS READS
0 62

2 authors:

Jacco Wesselius Frans Ververs

TNO Delft University of Technology
14 PUBLICATIONS   124 CITATIONS    6 PUBLICATIONS   16 CITATIONS   

SEE PROFILE SEE PROFILE

Some of the authors of this publication are also working on these related projects:

EnableS3 View project

All content following this page was uploaded by Frans Ververs on 22 January 2014.

The user has requested enhancement of the downloaded file.

 SRSM: A Software Requirements
Specification Method

Report 91-84

Jacco Wesselius
Frans Ververs

Faculteit der Technische Wiskunde en Informatica

Faculty of Technical Mathematics and Informatics
Technische Universiteit Delft
Delft University of Technology
ISSN 0922-5641

Copyright c 1991 by the Faculty of Technical Mathematics and Informatics, Delft, The
Netherlands.
No part of this Journal may be reproduced in any form, by print, photoprint, microfilm,
or any other means without permission from the Faculty of Technical Mathematics and
Informatics, Delft University of Technology, The Netherlands.

Copies of these reports may be obtained from the bureau of the Faculty of Technical
Mathematics and Informatics, Julianalaan 132, 2628 BL Delft, phone +3115784568.
A selection of these reports is available in PostScript form at the Faculty’s anonymous
ftp-site. They are located in the directory /pub/publications/tech-reports at ftp.twi.tudelft.nl
 SRSM:
A Software Requirements Specification Method

Jacco Wesselius
Frans Ververs

November 18, 1991

Abstract

In previous papers [6, 5] we argued that the specification of software requirements in a

clear unambiguous way that enables communication among customers, users, specifiers,
and developers is an essential step towards the achievement of software quality control.
In this paper an approach to software requirements specification is presented that is
centered around the definition of a problem specific language. The approach is intended
to result in requirements specifications that are understandable to the customer, and
that yet have a formally well-defined meaning.

. both: Delft University of Technology, Faculty of Technical Mathematics and Informatics, Sec-
tion Software Engineering, Julianalaan 132, P.O. Box 356, 2600 AJ Delft, The Netherlands, e-
mail:fjacco,fransg@dutiaa.tudelft.nl

1
Contents

1 Introduction 3
2 Software requirements specification is a communication
process 4
3 Stages in Requirements Specification 5
3.1 Stage One: Specify Services 5
3.2 Stage Two: Partition, and Demarcate the System 8
3.3 Stage Three: Determine Internal System Structure 9
3.4 Into the Recursion 10
3.5 The Constituents of a Software Requirements Specification
Method 11
4 A Case: The Library 13
4.1 Defining a Terminology for the Library 13
4.2 Required Services 20
4.3 Partitioning the system, Reciprocal Services 21
5 Summary, and Future Work 23

2
Chapter 1

Introduction

The achievement of quality control in software development is an essential step

towards a professional software engineering discipline. Therefore research is geared
to the development of methods, and techniques related to software quality control.
Our research project has also been started with this aim. After we studied the
problems involved in quality control we concluded that the specification of software
requirements is essential to the assessment of the quality of a product [6].
The aim of our project therefore is the development of a method for software require-
ments specification. Such a specification plays an important rôle in a development
project as a means of communication: the specifier expresses his 1 perception of the
customer’s wishes and expectations, which can thus be passed to the developer. In
order to enhance the confidence of all parties involved that the specifier’s perception
comes close enough to the customer’s real wishes, it is important that the contents
of the specification can be understood by the customer. When developing a method
for requirements specification this aspect should be taken into consideration [5].
In this paper we propose an approach to requirements specification (SRSM). First we
discuss the stages we identified in software requirements specification. Doing this,
we will also introduce some terms, and concepts relevant to software requirements
specification. This chapter results in the identification of three components of a
requirements specification. By means of a well-known case the language supporting
the approach is introduced in the next chapters. This paper will be concluded with
a discussion of future work.

1. Throughout this paper ‘he’, ‘him’ etc. are interchangeable with the female equivalents, and vice
versa

3
Chapter 2

Software requirements specification is a communication

process

A software requirements specification serves as a means for communicating the de-

veloper’s perception of the customer’s wishes and expectations. When the developer
has specified what he thinks the customer expects to find in the product, this will
be fed back to the customer who can thus indicate flaws in the developer’s percep-
tion. When the customer’s expectations, and the specification thereof have converged
sufficiently, the requirements specification serves as specification of the agreement
reached between the developer and the customer.
Next the specification can be passed on to those who are to manufacture the product.
To them it serves as a standard to judge their work by. Therefore the specification
should be unambiguous, and complete. This means that all knowledge needed to
develop the product should be stated explicitly, and unambiguously. It has therefore
been argued that a requirements specification should be specified using a formal
language.
In a formal language all syntactical constructs have been attached a unique, and
well-defined meaning to. The meaning of an expression can be derived from its syn-
tactical structure. The consequence very often is that a formal language has an
elaborate set of syntactical rules, and constructions. Interpreting a formal language
then requires the reader to be familiar with every detail of the language. A lan-
guage that is understandable to the customer, and yet formally well-defined should
therefore be some kind of a compromise. In [5] we decided that the development of
a such a method and language would be the aim of our research. We also argued
that our approach would be centered around the definition of a problem specific
terminology by means of a formal – yet simple – language.

4
Chapter 3

Stages in Requirements Specification

Our this approach to requirements specification is based on the stages that can be
distinguished in requirements specification. In this chapter we discuss these stages.
We distinguished three stages in the process of requirements specification (see
fig. 3.1):
 Specify Services: Determine and specify the services the system will offer.
 Partition the System: Identify the components that can be distinguished by
the user of the services. Demarcate these components.
 Determine Internal Structure: Identify components “inside the system”,
i.e. invisible to the user.

3.1 Stage One: Specify Services

Any system is developed with a specific purpose. The first stage in requirements
specification deals with the specification of this purpose. It has to be specified which
services the customer expects the system to offer. In addition to this, the costs
involved in using, and obtaining the services will be specified.
Both the customer, and the developer will assess the feasibility of the proposed ser-
vices, and costs. Each determines whether developing the system would be profitable
from his point of view.
To estimate the effort needed to develop the system, agreement has to be reached
about the environment the system will be used in. In a real-world that is constrained
(i.e. that can only be in a restricted set of states), less difficulties will be encountered,
than in an environment that no constraints apply to. The customer and the developer
have to agree about the environment states the system has to function in; when the
agreed upon constraints are corrupted the system need not function properly. To
use the system, someone should be responsible for assuring that the agreed upon
environment model is complied with.
Thus, a requirements specification addresses both the required services, and the
environment these services will be offered in. These we will shortly discuss in order.

Required Services
The reason for initiating the development of a new system are the benefits the system
will offer the customer. The services to be offered by the system have to be specified

5
6 3 Stages in Requirements Specification

Figure 3.1: Stages in Software Requirements Specification

as the first step in requirements specification. We consider three aspects of required

services:
 The service contents.
When specifying the contents of the service, it is determined what the service
consists of, when it is offered, and whom it will be offered to. These three
aspects will be expressed in terms of the state of the system’s environment,
rather than in terms of an internal model the system has of its environment.
What: This may be either the information it can give about its environment,
or the effects it causes in the environment.
When: This may be done by specifying either a real-world condition that
triggers the system, or a user that may request the service. This user may
be a person, or some system existing in the system’s environment.
To whom: When the system offers information, this has to be offered to a
specific environment entity. This entity has to be identified.
 The service attributes.
When a service is offered it has certain attributes, like: response time, accu-
racy, reliability, robustness etc. To the customer it is important that services
will be offered with attributes that secure their usability. In many cases the
services are available already (if only manual), but the new system has to offer
these services better. The services should be closer to perfection: cheaper, more
3.1 Stage One: Specify Services 7

reliable, more accurate, etc.

Therefore it is necessary to specify the attributes the services should be offered

with. In order to enhance to objectivity of the requirements specification the
attributes should be stated such that their value can be measured. This means
that in addition to the required value, a method of measurement should be
agreed upon by the customer, and the developer. It is important to specify this
measurement method in combination with the required value, because the
agreed upon value would likely be different for different methods of measure-
ment.

To enhance the understandability of the specification, it is a good idea to also

specify the current value for the specified attribute. Thus, the improvement
to be achieved becomes more tangible. More on this topic has been written
by Tom Gilb [2, 3]. His PLANGUAGE offers a scheme for specifying required
attributes, in combination with a method of measurement, the current value,
and the interval the attributes should be in. The information specified this way
is important when estimating the effort required to build the system, because
it shows the magnitude of the improvement to be realized.
 The service presentation.
One of the relevant attributes of a service is its “user-friendliness”. This means
it has to be assured that the customer, and the future users appreciate the
user interface. It would be possible to simply consider this as one of the ser-
vice attributes, to agree on a method for measuring it, and to set a required
value for it. Because this aspect depends very much on personal preferences of
the customer, it is a very subjective aspect. Developing a user interface with-
out prior agreement with the customer on the “looks-and-feels” of the system
would therefore be a risky business. It is important to reach a clear agreement
with the customer about the user interface. For those aspects that are most
subjective, the most detailed agreement has to be reached by the customer,
and the developer.

Apart from services offered to a human user, we already mentioned that ser-
vices may be offered to a non-human user. For the system to communicate
with this external system, it has to use a certain communication protocol. The
presentation of information should be agreed upon2 .
The three aspects of required services are not independent: the latter two factors
depend on the specification of the first; without identifying the contents (i.e. the
meaning) of a service, it is irrelevant to discuss its attributes, or how it will be
represented. For, what does it mean to specify that service xyz will be offered with a
response time of only 1 millisecond, unless we have agreed what this response will
consist of. Therefore, as we discussed in [5] a method for requirements specification
should first capture the specification of the service contents. When this has been

2. In case the external system already exists, this may simply be a reference to some technical
document coming with the external system
8 3 Stages in Requirements Specification

achieved successfully, the specification method may be enhanced to capture the other
aspects too. of services attribute, and presentation requirements may be based on
the existing method for specifying service contents requirements. Currently we will
therefore restrict our attention to the specification of service contents requirements.

The Environment
The constraints regarding the environment the system will be functioning in have to
be agreed about. The developer agrees to develop a system that will function properly
when the constraints have been complied with, and the customer accepts that the
system will only function properly when the environment behaves according to the
stated constraints.
During this stage the events that occur in the environment have to be identified, and
it has to be identified when events may occur, and what changes the cause. Further-
more, conditions have to be identified that are known to hold in the environment.
After stage one has been completed we have identified the services to be offered,
and the environment they will be offered in. This means the profits using the new
system will bring to the customer have been specified. In the next stage the effort
the customer has to spend in order to use the system will be addressed: the system
will be separated from the environment, resulting in services to be offered to the
system by entities in the system’s environment.

3.2 Stage Two: Partition, and Demarcate the System

In this stage, the system will be partitioned into several sub-systems that contribute
to the achievement of the required services. The task of the primary component is
reduced, and parts of the task are delegated to other components. These components
offer services to the primary component that enable this component to offer the
services specified in stage one. The subsystems offering services to the primary
component are considered part of the primary component’s environment. We zoom
in on one component.
The services offered to the primary component by its environment are called the
reciprocal services offered to the system. These reciprocal services may consists
of:
 Offering information about the environment.
For the system to function properly, it has to be informed about the events oc-
curring in the environment. When we are dealing with a software component,
this information has to be offered by an external component that can directly
access the environment.
 Causing an effect.
When the services required by the customer include that the system has to
cause certain effects in the environment (e.g. opening, or closing a valve, in-
creasing the speed of a car etc.) an entity has to be identified that can change
the environment as a reciprocal service offered to the software.
3.3 Stage Three: Determine Internal System Structure 9

These reciprocal services may be offered by a hardware component, or by a user of

the system. The reciprocal services to be offered are the price to pay for the services
offered by the system. Especially when reciprocal services require human effort, it
is important to reach an agreement with the customer about the required reciprocal
services. The agreement means that the services will only be offered by the primary
component if all the identified reciprocal services will be offered by some component
in its environment.
After stage two has been completed the interfaces of the distinguished components
have been completely characterized: the services, and the reciprocal services have
been specified. Every system offering the specified services, and not asking more than
the specified environmental services should be suited for the customer’s purpose. The
next stage towards the implementation of a system deals with the internal structure
of the components.

3.3 Stage Three: Determine Internal System Structure

A software system system will have an internal model of its environment, containing
all information needed for offering the required services. During this stage a conve-
nient internal model has to be designed, i.e. one that is both concise and sufficient.
Also an internal system structure has to be designed that is suited to manipulate
the internal model.
To the customer these design issues are irrelevant. It matters to him that the agreed
upon system characteristics will be realized, and he may be confident that the devel-
oper is capable of doing so, because the developer has agreed upon the requirements
specification too. Just how the developer manages to succeed is not important to
the customer. Therefore this stage should not be considered part of requirements
specification; it is the first step into software design.
In some cases the customer will have requirements regarding the way the system
will be constructed. He may want a standard to be complied with, a programming
language to be used etc. In that case these requirements are intended to enhance his
confidence that the developer will succeed. The stated requirements are not a goal
in themselves, but are meant to assure other requirements will be complied with.
Stating that programming language xyz should be used, may be a means to assure
that required maintainability, or portability levels will be achieved. By expressing
these requirements the customer takes part of the responsibility of implementing
the system, which would otherwise be the developer’s.
In [5] we addressed the different types of requirements. There, we called the re-
quirements that specify the required services, and the maximum costs genuine
requirements. The requirements biasing the way the developer implements the
system we called auxiliary requirements. We argued that a requirements specifi-
cation should only contain genuine requirements. If auxiliary requirements have to
be stated, they should be part of the project (quality) plan.
10 3 Stages in Requirements Specification

Figure 3.2: Requirements Specification: a Recursive Process

3.4 Into the Recursion

After stage two has been completed, we end up with a system, offering certain
services, but that can only offer these services when some other services will be
offered by the environment in return. For the customer’s requirements to be fulfilled,
two things have to be done:
 A system has to be implemented that offers the required services, provided
that the specified reciprocal services will be offered to it by some entity in its
environment.
 The reciprocal services shall be provided by some entity in the system’s envi-
ronment.
When demarcating the system, this gives raise to a set of new requirements: services
have to be offered to the system.
The situation after stage two is similar to the one after stage one (see fig. 3.2). We
have identified a new environment, we have specified services that have to be offered,
and we have identified an entity these services have to be offered to (the user, and
the demarcated component respectively). The consequence of this is that we may
enter into stage two once more, in order to demarcate components that will offer
the reciprocal services. This recursive process continues until we arrive at reciprocal
services that can be offered by an existing entity having access to the environment
directly (a person, a hardware component, or a previously developed system).
3.5 The Constituents of a Software Requirements Specification Method 11

Figure 3.3: The SRSM Constituents put together

3.5 The Constituents of a Software Requirements Specification

Method
In the stages we identified in requirements specification four major components can
be distinguished:
 the system’s environment;
 the services to be offered by, or to the system;
 the partitioning of a system into components;
 the internal structure of the identified components.
We already argued that the fourth component is not part of the software require-
ments specification. The former three are, and they should be captured in a method
for requirements specification.
In the software requirements specification method we propose in this paper (SRSM)
we have recognized the fact that these components should be considered. The method
therefore constructs a software requirements specification out of three major con-
12 3 Stages in Requirements Specification

stituents: a dictionary containing a problem specifical terminology, a specification of

the environment the system will operate in, and a specification of the requirements
the system has to conform to (fig. 3.3).
 To speak about the system’s environment, a language is needed. We think it
would be a major advantage if this language captures the concepts relevant
to the problem domain of intercourse. Therefore we have chosen to develop a
domain term definition language (DTDL) that can be used to define terms, and
the related concepts relevant to the problem. The first constituent of SRSM is
therefore a definition of a problem specific terminology.
 The second component of a SRSM specification is a model of the environment
the services will be offered in. By means of the problem specific terminology,
expressions can be built, that in combination with a rudimentary language
for real-world modelling can be used for expressing constraints, and rules
applying to the problem environment.
 Finally the services have to be specified. This will be done by means of a lan-
guage for specifying services that may be combined with the problem specifical
terminology defined by means of DTDL. This language consists of a collection
of templates which expressions from the problem specifical terminology can be
substituted into. Currently this service specification language only captures
the contents of the required services.
In addition to these components, a mechanism is available for partitioning the sys-
tem into externally visible components. This mechanism allows services to be offered
by the system to be distributed among the identified components. Thus the require-
ments applying to the individual components can be specified.
SRSM is based on the stages discussed in this chapter. The method’s constituents we
identified are discussed in order in the next chapters. This will be done by means of a
well-known case: “the library” [1]. Not all features of the language will be addressed.
The intention of the discussion is to give an impression rather than a complete
description of the method, and the language we are working on. Giving a complete,
and formal specification of the method will be one of the activities planned for the
future (see chapter 5) after it has been tried in practice.
Chapter 4

A Case: The Library

In this chapter we will shortly discuss the proposed approach to requirements spec-
ification by means of a well-known case:
“Consider a small library database with the following transactions:

1. Check out a copy of a book. Return a copy of a book.

2. Add a copy of a book to the library. Remove a copy of a book from the library.
3. Get the list of books by a particular author or in a particular subject area.
4. Find out the list of books currently checked out by a particular borrower.
5. Find out what borrower has last checked out a particular copy of a book.

There are two types of users: staff users, and ordinary users. Transactions 1,2,4, and 5 are restricted
to staff users, except that ordinary users can perform transaction 4 to find out the list of books
currently borrowed by them selves.

The database must also satisfy the following constraints:

 All copies in the library must be available for checkout or be checked out.
 No copy of the book may be both available, and checked out at the same time.
 A borrower may not have more than a predefined number of books checked out at one time.”[1]
Several specifications of this problem have been discussed in [7].
We will not give a complete specification of this problem, but we will only discuss
some fragments that elucidate the important aspects of SRSM.

4.1 Defining a Terminology for the Library

The first step is the definition of a problem specific terminology. This terminol-
ogy consists of the terms that relevant to the problem environment. We have been
working on a Domain Terms Definition Language DTDL that offers mechanisms
to define a new terminology. The language has been kept simple in order to en-
hance customer communicativeness. This is important because the customer, and
the developer have to agree on the meaning of the terms used in the specification.
Therefore, the customer should be able to understand the specification.
To enhance the understandability we have chosen to use a syntax for terms similar
to the syntax used in Smalltalk-80 [4]. This means that the parameters of a term
are not collected together, but rather are put at a position where they would be in
natural language, and will be proceeded by a colon (’:’)3 .

3. The fonts used in the examples have no semantical value, but are only used to highlight the defined
terms.

13
14 4 A Case: The Library

the (Books written by: NOAH about: BOAT BUILDING),

rather than:
the Books written by about(NOAH, BOAT BUILDING)
Since the parameters are put at their “natural place”, we think it should be easier
to read the former than to read the latter. When reading the latter the rôle of the
parameter has to be guessed, or derived from the way the term has been defined.
In the example above we used the term books written by:about: for NOAH, and
BOAT BUILDING. Whether this term has been used correctly this way, depends on
the way it has been defined. In the definition of a term, the signature of the defined
term has been given:
The (Books written by: a Person about: a Topic) is: a Book List : : :
This definition tells us that the term can be used for a person, and a topic respectively.
Therefore this term cannot be used in the following way:
the (Books written by: the EASTER BUNNY about: EGGS)
By means of some excerpts from the library terminology definition we will introduce
DTDL. After each of these we will discuss some concepts that are introduced in them.

Terms, and Concepts, Objects, and Entities

A terminology consists of a number of terms that are collected in a dictionary. Each
term refers to a concept. A concepts is the collection of entities the term “applies
to”. When we use the term “person” we refer to every entity that is a member of the
concept referred to by this term. If the entity NOAH is a member of this concept we
say: “NOAH is a person”, or “the term Person applies to NOAH”.
When all the entities contained in a concept are also contained in a different concept,
we say that the first is a subconcept of the second, or the second is a superconcept
of the first. When defining terms this relation between concepts is very important.
Very often we say that “an X is a Y, for which : : : ” This means that the term X refers
to a subconcept of the concept referred to by Y. When considering the applicability
of X to an entity we first have to consider the applicability of Y to the entity.
The subconcept-superconcept relation brings us to inheritance. Because a subcon-
cept contains entities that are all contained in the superconcept, the terms defined
for the entities in the superclass can also be used for the terms in the subclass. When
the concept “child” is a subconcept of the concept “person”, we can ask for “the name
of a child”, because the term “the name of ” can be used for persons, and is therefore
inherited by the concept “child”.
The entities contained in a concept may be of three kinds:
 a single object: e.g. a person
 a collection of entities: e.g. a group
 a combination of entities: e.g. a married couple
The difference between a combination and a collection is that the entities in a
combination may have different rôles; changing the position of the entities in a
combination results in a different combination. The entities in a collection at the
other hand can change places at will.

Person-Dictionary.

Use Standard-Dictionary.
4.1 Defining a Terminology for the Library 15

Primitive term: a Person.

Primitive term: the (Name of: a Person) is: a Text.

A Group is: a Person-collection.

A Married Couple is a certain kind of: [a Man, a Woman] for which :::

Using other dictionaries

Terms are often relevant to more than one problem. In that case, it would be in-
convenient to redefine them for every project they are relevant to. Therefore, we
have included a “use-clause” in DTDL. By using this clause the terms contained in a
different dictionary become available, to be used in a new dictionary.
In the example we refer to the “standard-dictionary”. This dictionary has been men-
tioned in figure 3.3. It is the dictionary containing the basic terms needed to define
new terms. This includes terms related to texts, number, time, events, forms etc. Be-
cause we are still working on the development of SRSM the contents of the standard
dictionary is still open to debate. Whether SRSM can be conveniently used will for a
large part depend on the decisions made about the standard dictionary.

Primitive Terms
To get the process of defining a terminology started some basic terms are needed
that are not defined, but that can none the less used. Often the exact meaning of
these terms is irrelevant to the problem. In case of the library, we need to speak of
persons, but we are not really interested when the term person becomes applicable,
and when it stops being applicable. In these cases we introduce the term in the
specification by saying that it is a primitive term.
There are three important restrictions to the use of primitive terms:
 The concept referred to by a primitive term should be fixed.
 The signature terms of a primitive term should also be primitive terms.
 The superterm of a primitive term should be a primitive term too.

Single, and Multiple Applicable Terms

In the example we defined the terms a person, and the name of a person. The
difference between these two is that the former may apply to more than one entity,
whereas the latter always applies to a single entity. We may therefore ask for “the
name of NOAH”, but we may not ask for “the person”.
We thus can identify two different types of terms:
 Multiple Applicable Terms
For these terms we may ask whether “X is: an Y”.
 Single Applicable Terms
For these terms we may ask both whether “X is: a Y”, and “whether X = the
Y”.
16 4 A Case: The Library

Book-Dictionary.

Use Person-Dictionary.
Use Standard-Dictionary.
Use Topics-Dictionary.

Primitive term: a Book.

A Book List is: a Book-collection.

Primitive term: a (Copy of: a Book).

Primitive term: The (Title of: a Book) is: a Text.

Primitive term: The (Authors of: a Book) is: a Group.
Primitive term: The (Topic of: a Book) is: a Topics List.

The (Books written by: an Author <p>) is: a Book List equal to:
every Book <b> for which:
<p> is among: the (Authors of: <b>).

An Author is: a Person <p> for which:

<p> is among: the (Authors of: a Book).

Derivable Terms
The meaning of some terms can be expressed in terms of the meaning of previously
defined terms. Whether or not the term applies to an entity can in that case be
derived from the applicability of other terms, by evaluating an expression.
In the example above, two definitions of derivable terms can be found. The first
is the definition of the single applicable term (Books written by: an Author). This
definition expresses the meaning of this term in terms of the previously defined term
(Authors of: a Book). In the definition two parameters are used: one to refer to the
author, and another to refer to a book. In DTDL parameters are of the form <TEXT>.
The other derivable term in the example is the multiple applicable term Author.
This term has also been defined in terms of the term (Authors of: a Person). Because
this term may apply to more than one entity, it cannot be defined by an expression
pointing to the entity it applies to. Derivable multiple applicable terms will be
defined by means of an expression that returns a truthvalue for a given entity. This
expression is the criterion for assessing the applicability of the new term to a given
entity.
The expression by which a derivable multiple applicable term is defined, refers to
the entity being assessed. Therefore a parameter is needed that refers to this entity.
This parameter can be declared by putting it directly after the superterm in the
definition: “a Person <p>”.

Generic, and Specific Terms

In the example above the following subexpression can be found:
the (Authors of: a Book)
The signature term “a Book” has not be substituted in the expression. The expression
refers to the authors of a book in general; it is not important which book the person
is an author of. Terms with signature elements that are left uninstantiated are
4.1 Defining a Terminology for the Library 17

called Generic Terms. By instantiating all elements of the terms signature the
term becomes a Specific Term.
When assessing the applicability of a generic term, every entity the term could be
instantiated with has to be considered. In the example we have to consider every
book. The definition given in the example is equivalent to:
An Author is: a Person <p> for which:
exists a Book <b> for which:
<p> is among: the (Authors of: <b>).

To avoid ambiguities the use of generic terms has to be restricted. This we will
discuss when we give a complete description of DTDL (see chapter 5).

Member-Dictionary.

Use Person-Dictionary.
Use Standard-Dictionary.

A Member is a certain kind of: Person.

A Staff Member is a certain kind of: Member.
An Ordinary Member is a certain kind of: Member.
Any Member is either: a Staff Member, or: an Ordinary Member.

The (Registration Number of: a Member) is a certain: Number.

The (Loan Limit of: an Ordinary Member) is: a Number equal to: 10.
The (Loan Limit of: an Staff Member) is: a Number equal to: 20.

A Subscription is: an Event involving:

a Person as: the <new member>
a Staff Member as: the <registration employee>
a Number as: the <registration number>.

A Membership Cancellation is: an Event involving:

an Ordinary Member as: the <cancelling member>
a Staff Member as: the <registration employee>.

Occasional Terms, and Events

The applicability of some terms only changes at the occurrence of certain partic-
ular events. Concepts that change at certain predetermined occasions are called
occasional concepts. Hence, terms referring to them are called occasional terms.
Expressing the meaning of these terms would lead to specifications such as:
A Member is: a Person <p> for which:
exists a moment <m> for which:
exists a Subscription <s> for which:
<s> is: an (event occurred at: <m>) and
the <new member> involved in: <s> = <p> and
not exists a Membership Cancellation <t> for which:
<t> is: an (event occurred after: <m>) and
the <quitting member> involved in: <t> = <p>.
These specifications are not easy to read. If more than two events may change the
applicability of a term the expression becomes even more difficult to read. In these
cases it is more convenient to define that “a member” (see the example above) is a
subconcept of “a person” without stating by what criteria the applicability has to
be assessed. This information will be expressed in the environment model as the
consequences of the events described in the model.
18 4 A Case: The Library

In the example above also some terms have been defined that refer to subconcepts
of the concept “event”. The concept “event” is a primitive concept that is part of the
standard-dictionary. An event occurs at a single moment, and may cause a change.
What change it brings, and when it may occur will be specified in the environment
model. When defining a terminology, the term will only be introduced, and the rôles
an entity may play when it is involved in an event will be introduced. This allows
us to refer to the entities involved in an event, by naming the rôle they played. In
the example, we may refer to “the <new member> involved in: a Subscription”. The
definition tells us that this will always be a “person”.

Overloading, Disjoint, and Complementary Terms

In the example above we defined the term “the loan limit” twice. First for an ordinary
member, next for a staff member. This may lead to ambiguities: when we ask for the
loan limit of JOHN, what should be answered? 10 or 20?
To avoid ambiguities special care should be taken in cases like these. It has to be
asserted that no entity exists for which more than one definition can be used. In the
example it has to be asserted that no member is both an ordinary member, and a
staff member. This means that the concepts “staff member”, and “ordinary member”
are disjoint terms regarding the concept “member”. In DTDL we could have said:
A Member is either: a Staff Member, or: an Ordinary Member.
In the example we make a stronger assertion, however. We say that any member
is either a staff member, or an ordinary member. This means these two terms are
complementary regarding the concept “member”. Consequently, if a term T has
been defined for both staff members and ordinary members, we know that for every
entity which is a member the term T has been defined. This is could be called
inverse inheritance. When checking the completeness of a DTDL-definition, the
inverse inheritance rule will be used.

A World Model
The terminology we have defined by means of DTDL can now be used to speak about
the environment the system will be functioning in. To do this a collection of envi-
ronment model templates have been defined that can be completed by substituting
expressions based on the terms in the problem specific terminology.
The model we construct this way can address the following issues:
 define the consequences of the events, i.e. what has changed. This can be used
to define how the applicability of occasional terms changes.
 define the preconditions to the occurrence of the events introduced in the
problem specific terminology;
 define what occasional terms apply initially (when a person becomes a member,
does he become a staff member, or an ordinary member?)
 define rules, and constraints to the state of the environment.
We will use a short extract from the Library-Model to discuss some of the available
templates.
4.1 Defining a Terminology for the Library 19

Library-Model.

Use Library-dictionary.

A Check Out causes:

the <checked out copy> becomes: a copy on loan,
the <checked out copy> is: an available copy no longer,
the (borrower of: the <checked out copy>) := the <borrowing member>.

A Returnal causes:
the <checked out copy> is: a copy on loan no longer,
the <checked out copy> becomes: an available copy.

A Subscription requires that:

the <registration number> is not: the (Registration Number of: a Member) and
the <new member> is not: a member.
A Subscription causes:
the <new member> becomes: a Member,
the (Registration Number of: the <new member>) := the <registration number>.

A Membership Cancellation requires that:

the (Number of Copies Borrowed by: the <cancelling member>) = 0.
A Membership Cancellation causes:
the <cancelling member> is: a Member no longer.

Initially a Person is not: a Member.

Initially a Member is: an Ordinary Member.

Constraint At Least One Staff Member:

exists a Staff Member.

This world model specifies the consequences of the events that have been defined
in the terminology. These consequences deal with the changes of the applicability of
occasional terms. For example, as a consequence of the event Subscription, and Mem-
bership Cancellation the applicability of the term Member changes. The changes in
the world model correspond to the complex definition of the term Member given in
the previous chapter.
Another issue is the specification of conditions that have to be satisfied for an event
to occur. In the example above, it has been specified that a Membership Cancellation
can only occur when the person who wants to cancel his membership has no books
on loan any more. Likewise it has been specified that a subscription may only occur
when the person is not a member yet.
The third type of information in the real world model is the initial applicability of
occasional terms. This information we need in addition to the information about the
moments of change of an occasional concept. In the example it has been specified
that a person is not a member when he comes into existence, and that a person is
an ordinary member, when he becomes a member of the library.
The last item in the example shows how constraints can be defined. By means of
an expression that is known to be true in the environment, the number of states
to be taken into consideration can be reduced. In the example it has been specified
that in the environment always at least one staff member will exist. This means
that when developing the system this condition may be taken for granted; no special
behaviour is required when this condition is not satisfied. The only reason to pay
special attention to this constraint is to offer a certain grade of robustness. Then,
20 4 A Case: The Library

checking this condition is a solution to a robustness problem, rather than a service

genuinely wanted by the customer.

4.2 Required Services

Like we have used the problem specific terminology in combination with a few
templates to specify an environment model, we may use it in combination with
service templates to specify the services a system has to offer. These templates
enable us to specify when a service has to offered, what it consists of, and whom it
has to be offered to.

library System-required services.

Use Library-dictionary.
Use Library User-dictionary.
Use Library-model.

borrowed copies-service:
At request by: an Ordinary User <u>,
– inform: <u>
about : the (copies borrowed by: <u>).

copies borrowed by a user-service:

At request by: a Staff User <u>
for: a Member <m>,
– inform: <u>
about : the (copies borrowed by: <m>).

books by author-service:
At request by: a User <u>
for: an Author <a>,
– inform: <u>
about : the (Books written by: <a>).

loan limit-service:
assure that satisfied:
for every Member <m>:
the (Number of Copies Borrowed by: <m>)  the (Loan Limit of: <m>).

In the example above, a dictionary called Library-Dictionary is referred to. This

dictionary introduces the terms ordinary user, and staff user. The former term refers
to users of the system, that are ordinary members, whereas the latter refers to those
that are staff members. This distinction is needed to specify that staff members
have certain privileges. These show from the definition of the borrowed copies-
service, and the copies borrowed by a user-service. These services correspond to
transaction 4 in the case. The specification of these services shows that a staff
member may ask for the copies borrowed by any member of the library, whereas an
ordinary member can only use the borrowed copies-service, giving him the copies
he has borrowed himself.
The services to be offered in the case are all triggered by a request from a user.
In many cases services have to be offered when a certain condition is satisfied. A
requirement of this type could be:
Signal Illegal Check Out-service:
When occurs: an Illegal Check Out <chk>,
– cause: a switch on alert signal,
4.3 Partitioning the system, Reciprocal Services 21

– inform: the <loan desk employee> involved in: <chk>

about: the <borrowing member> involved in: <chk>.
The meaning of this specification is that this service will be triggered by the oc-
currence of an event. When this event has occurred the system shall inform the
employee involved in the illegal check out, and it shall also cause an alert signal to
switch on (this should be defined as a term referring to an event in the terminology
definition).
The final service specified in the example shows how to specify that the system should
assure that a certain condition in the real world will be satisfied. For the system
to offer this service, certain reciprocal services may be needed: some entity should
prevent a copy from being checked out when the system signals an illegal check out.
These reciprocal services will be specified in the next stage, when separating the
system from its environment.

4.3 Partitioning the system, Reciprocal Services

The final step of our approach consists of the partitioning of the system into com-
ponents that are visible to the customer. In the example below we have arbitrarily
cut the library system into two components: one that deals with the registration of
members, and books, the other dealing with check outs, and returnals. Each required
service will be assigned to one of the identified components.
After the components have been identified, they will be separated from the environ-
ment by identifying the environment services they rely on. These reciprocal services
have to be offered for the components to function properly. They may either be offered
by a user, or any other entity that is already present in the environment, or a new
system may be developed to offer these services. The latter leads to the recursive
process discussed in chapter 3.4.

Library system-Partitioning.

Use Library System-required services.

Library system-Components:
Loan Desk module,
Registration Desk module.

Loan Desk module offers:

borrowed copies-service,
borrowed by a user-service,
loan limit-service,
.
..

Registration Desk module offers:

Books by author-service,
Books by topic-service,
.
..

Library System-required environment services:

check out info-service:

When occurs: a Check Out <b>,
– inform: loan desk module
22 4 A Case: The Library

about: the <member> involved in: <b>,

the <checked out copy> involved in: <b>.

returnal info-service:
When occurs: a Returnal <r>,
– inform: loan desk module
about: the <returned copy> involved in: <r>.

subscription info-service:
When occurs: a Subscription <s>,
– inform: registration desk module
about: the <new member> involved in: <s>,
the <registration employee> involved in: s .
< >

To offer the required services a reciprocal service not specified above would be needed.
In order to offer the books by author-service the system has to be informed about
every book that has been published. This may be inconvenient. Therefore this service
may be restricted to the books that are in the library collection. Identifying reciprocal
services may thus lead to reformulating the required services. It is all a matter of
comparing costs and benefits.
Chapter 5

Summary, and Future Work

In this paper we have proposed an approach to software requirements specification

based on the definition of a problem specific terminology. The language for defining
this terminology has been informally introduced. The discussion of fragments of a
case has shown what a requirements specification would look like using the proposed
approach.
A lot of work still has to be done to improve the proposed approach:
 It has to be tried on more extensive cases to validate the claim that starting
with the formal definition of a terminology improves the communicativeness
of a formal requirements specification.
 Doing these cases is also required to establish a standard dictionary that
contains sufficient terms to use the method conveniently.
 After the approach has been tried, and has been proven useful it has to be
fully formalized, to make it a real formal software requirements specification
method.
A limitation to the approach is that we have currently only considered the specifica-
tion of “functional requirements”. As discussed in chapter 3.1 other aspects have to
be considered too. We have restricted the scope of SRSM based on the fact that the
other types of requirements can only be specified after the functional requirements
have been captured [5]. To make SRSM a real method for requirements specification
the other types have to be considered too.

23
 Bibliography

[1] Problem set for the fourth international workshop on software specification and design. ACM Software
Engineering Notes, pages 94–96, April 1986.
[2] Tom Gilb. Planguage: a result-driven planning language handbook. Obtainable from Tom Gilb, London +(441)
583-9279, 1988.
[3] Tom Gilb. Principles of Software Engineering Management. Addison-Wesley, 1988.
[4] Adele Goldberg and David Robson. Smalltalk-80 – The Language and its Implementation. series in
Computing Science. Addison-Wesley, 1983.
[5] Jacco Wesselius. Software quality control & requirements specification. Technical Report 91-48, Delft University
of Technology, Faculty of Technical Mathematics & Informatics, July 1991.
[6] Jacco Wesselius and Frans Ververs. Some elementary questions on software quality control. IEE Software
Engineering Journal, 5(6):319–330, November 1990.
[7] Jeannette M. Wing. A study of 12 specifications of the library problem. IEEE Software, 5(4):66–76, July 1988.

24

View publication stats