Professional Documents
Culture Documents
SRSM: A Software Requirements Specification Method: April 1994
SRSM: A Software Requirements Specification Method: April 1994
net/publication/2669020
CITATIONS READS
0 62
2 authors:
Some of the authors of this publication are also working on these related projects:
All content following this page was uploaded by Frans Ververs on 22 January 2014.
Report 91-84
Jacco Wesselius
Frans Ververs
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
Abstract
. 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
1. Throughout this paper ‘he’, ‘him’ etc. are interchangeable with the female equivalents, and vice
versa
3
Chapter 2
4
Chapter 3
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.
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
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.
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:
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.
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.
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
Person-Dictionary.
Use Standard-Dictionary.
4.1 Defining a Terminology for the Library 15
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.
Book-Dictionary.
Use Person-Dictionary.
Use Standard-Dictionary.
Use Topics-Dictionary.
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>).
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>”.
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.
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.
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”.
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 Returnal causes:
the <checked out copy> is: a copy on loan no longer,
the <checked out copy> becomes: an available copy.
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
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>).
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>).
Library system-Partitioning.
Library system-Components:
Loan Desk module,
Registration Desk module.
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
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