Block 1 Units 1-4 From Domain To Requirements: TM354 Software Engineering

TM354 Software engineering
Block 1 Units 1–4

From domain to requirements
This publication forms part of the Open University module TM354 Software engineering. Details of this and other Open University
modules can be obtained from the Student Registration and Enquiry Service, The Open University, PO Box 197, Milton Keynes MK7
6BJ, United Kingdom (tel. +44 (0)845 300 60 90; email general-enquiries@open.ac.uk).
Alternatively, you may visit the Open University website at www.open.ac.uk where you can learn more about the wide range of
modules and packs offered at all levels by The Open University.
To purchase a selection of Open University materials visit www.ouw.co.uk, or contact Open University Worldwide, Walton Hall,
Milton Keynes MK7 6AA, United Kingdom for a catalogue (tel. +44 (0)1908 858779; fax +44 (0)1908 858787; email ouw-customer-
services@open.ac.uk).
The Open University, Walton Hall, Milton Keynes MK7 6AA

First published 2014.
Copyright © 2014 The Open University
All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, transmitted or utilised in any form or by
any means, electronic, mechanical, photocopying, recording or otherwise, without written permission from the publisher or a licence
from the Copyright Licensing Agency Ltd. Details of such licences (for reprographic reproduction) may be obtained from the Copyright
Licensing Agency Ltd, Saffron House, 6–10 Kirby Street, London EC1N 8TS (website www.cla.co.uk).
Open University materials may also be made available in electronic formats for use by students of the University. All rights, including
copyright and related rights and database rights, in electronic materials and their contents are owned by or licensed to The Open
University, or otherwise used by The Open University as permitted by applicable law.
In using electronic materials and their contents you agree that your use will be solely for the purposes of following an Open University
course of study or otherwise as licensed by The Open University or its assigns.
Except as permitted above you undertake not to copy, store in any medium (including electronic storage or use in a website), distribute,
transmit or retransmit, broadcast, modify or show in public such electronic materials in whole or in part without the prior written
consent of The Open University or in accordance with the Copyright, Designs and Patents Act 1988.
Edited and designed by The Open University.
Printed and bound in the United Kingdom by Martins the Printers, Berwick-upon-Tweed.
ISBN 978 1 7800 7915 8

1.1
Contents
Unit 1
Approaches to software development 1
Unit 2
Requirements concepts 67
Unit 3
From domain modelling to requirements 125
Unit 4
The case study: part 1 193
Acknowledgements 239
Index 241
Unit 1 Approaches to software
development
Contents
1 Introduction 5
2 Software and software engineering 7
2.1 What is a system? 7
2.2 The nature of software 9
2.3 Characteristics of a software system 10
2.4 Maintainability and other software problems 12
2.5 Divide and conquer? 15
2.6 Architecture 22
2.7 Summary of section 26
3 An introduction to software development 28
3.1 Software development as an engineering activity 28
3.2 The role of development processes 30
3.3 Choosing an appropriate process 36
3.4 Traceability 41
4 Modelling in software development 48
4.1 Importance of modelling 48
4.2 Models illustrate points of view 52
4.3 Introducing the Unified Process 53
4.4 Activities and artefacts in the development process 56
5 Summary 63
References 65
1 Introduction
Introduction 1
In this module we present an engineering approach to the development of
software systems – a software engineering approach. This means we pay
particular attention to issues of software quality, in terms of both product
(what is built) and process (how we build it).
The material is organised in a distinctive way. We adopt an object-oriented
approach to software development and assume you are familiar with the basic
concepts of objects. This approach uses a fairly standard set of development
techniques. We take a broad view, and in most units of this module these
techniques are discussed fairly independently of exactly where and when they
would be used. In parallel with this, however, Units 4, 8, and 12 feature a
running case study that demonstrates how the techniques might be applied in
practice.
There has always been debate in the computing industry about just how useful
any particular development technique is. We believe that the techniques that
have been introduced over the last 30 years or so, and many others currently
being researched, are important because they address fundamental issues
concerning software quality. You are probably already familiar with some of
the techniques used in this module. Studying these techniques is more about
how to use them to address the quality issues of what you are developing and
how you are developing it rather than about how to use them in practice.
In this module you will see a precise way of applying techniques, but we will
also discuss, in parallel, a more light-weight approach to software
development. You will become familiar with the purpose of utilising these
techniques and will also develop an understanding of when their systematic
use may or may not be appropriate. With experience you will be able to make
decisions on which is the right combination of techniques for a particular
project.
Software systems are built to meet requirements. A successful software project This leads to the developer’s
must: mantra, ‘Software must be
delivered on time, to budget and
. resolve the diverse and possibly conflicting needs of users in a disciplined to specification.’ You may know
way it in another form.
. satisfy the users’ expectations
. have been developed and delivered in a timely and economical manner
. be resilient to the changes that will be introduced during its operational
lifetime
. demonstrate good overall system quality.
This is a daunting prospect for those developing and maintaining software. A
central aim of this module is to give you the intellectual tools to cope with the
challenge.
This unit provides an introduction to software engineering. Assuming you
already have some experience of software development, some of this material
will be familiar to you, though your existing knowledge will be consolidated
5
Unit 1 Approaches to software development
and will begin to be extended to more advanced areas. We discuss some of

the ideas that underpin software development in Section 2, and consider the
basic activities of software development in Section 3. Section 4 looks at the
role of models and modelling languages, introduces a well-known software
development process and presents the specific way we will organise the
development process for the main case study used throughout this module.
6
2 Software and software engineering
Software and software engineering 2

This section describes the basic characteristics of a ‘good software system’,
and considers how such software systems may be developed. Once built,
software rarely remains static and can change on a regular basis, so
maintaining software is a key activity in software engineering.
Our intention in this section is to provide the background for a more detailed
discussion that comes later. We therefore recommend that you read quickly
through this section and then reread it once you have gained some more
insight into the software development process, both at the end of this unit and
again at the end of the module.
2.1 What is a system?

The word system is in regular everyday use. We talk about the social-security
system, the telephone system, computing systems and even ‘The System’. The
trouble is that our everyday language is often imprecise, and people use the
same word to mean different things (that is one reason why software
development can be an arduous process).
We define a system as ‘an assembly of components that are connected The word system is derived from
together in an organised way’. The term organised is important here. For the Greek word meaning ‘to set
example, it tells us that components are affected by being part of a system. up’.
Example 1
A pile of old telephones, exchange-switching gear and wiring that are
awaiting disposal may once have been a system. But heaped together, they are
not a system. Both the organisation and the connections have been lost.
A system, therefore, is greater than the sum of its parts, and it has properties
that cannot be deduced or predicted by examining any one of its components
in isolation (or even all of its components, if they are not organised and
connected). From the above example, could you deduce the properties of the
telephone system by examining a single, disconnected telephone (or even a
big pile of disconnected telephones)? No, because it no longer works as
expected, even though it has not changed physically (it is not broken).
The assembly of components that forms a system does something, it carries
out some process. This process will work on inputs, carry out transformations
and produce outputs in order to achieve a goal. If you view your body as a
system, it consists of organs, it takes oxygen and food as inputs, and does
transformations that keep you alive. As a system, it has a well-defined
boundary and a control mechanism that will keep it adapting to changes in the
environment.
This module is specifically about software systems, systems where software
plays a major role. However software does not do anything without the
hardware where it is installed and running, and software systems are usually
7
part of a much wider context that involves not only other technical
components, but also people, organisations and other social structures. The
‘whole’ of all these components is also known as a sociotechnical system.
Sociotechnical systems are complex systems that need to be understood as a
whole rather than as a sum of their isolated components.
In focusing on the software we will therefore be ignoring many other
components of the whole system in which software is just a part. However as
a software engineer you will need to be aware of how software is used and
the interactions with hardware, people and organisations. The popular press is
full of reports of software failures, many of which may relate directly to
problems with the software but may also relate to other issues of the wider
sociotechnical systems context as in Example 2.
Example 2
You may find it interesting to One well-studied case is that of the unmanned European Ariane 5 rocket,
read about other examples of which failed on its launching flight due to a software problem. During the
software failures, such as the launch one of its computers stopped working due to a variable exceeding a
Therac 25 software-controlled
radiation therapy machine, which limit – a data conversion resulted in an overflow software exception.
was responsible for the death of There is some controversy about where the exact blame should fall for the
several patients in the late 1980s
(Leveson and Turner, 1993).
problems that occurred, but there is an agreement that they were related to the
reuse of a module from a previous rocket without proper enforcement of
constraints. This case became well known due to the huge expense of the
rocket ($500 million), the amount of time it took to develop (10 years) and
what it meant for European space projects (Lions, 1996).
A system can be, and often is, a personal ordering of reality, the result of
seeing some degree of orderly interconnectedness in some part of the world.
So a system can be many different kinds of system simultaneously, depending
on who is studying it and why. Different viewpoints of a system correspond
to different sets of users and therefore different purposes. In this sense, it is a
subjective ordering of reality.
Example 3
A telephone system is a communications system to its users. For the engineers
who set it up and maintain it, it is a technical system (that is linked to an
employment system – a job – in their view). Similarly someone who designs
telephone switches considers each switch as a system in its own right – a
switch can record usage data as well as route your calls.
As Example 3 shows, there is a notion of what is included within a system,

and what is excluded. Naturally this notion depends on the stakeholders
involved in the modelling and development of the system and the viewpoints
that they have over it. Identifying the scope of a system is an essential step in
the development process.
The system boundary is a conceptual line that divides the system that you
want to study from ‘everything else’. It is useful to think of a system’s
8
environment as being made up of those things that are not part of the system,
but can either affect the system or be affected by it. Example 4 takes you into
a particular area of interest, which is known as a domain, to look at system
boundaries and how they can change.
Example 4
A hospital is a domain where software is put to a variety of uses. A hospital
might, for example, join together a series of patient-monitoring systems with
the database management system that manages medical records, creating a
larger system with a different scope. A forward-looking hospital might wish to
go further and add weather-forecasting software. This extension would allow
planners to deal with the variations in flow of patients that arise according to
the season. Beds may be allocated and other resources, such as drugs, bought
in preparation.
SAQ 1
In Example 4, we suggested that two systems, for patient monitoring and

managing medical records, might be combined into a single system.
Suggest an additional function that might be possible with the combined
system that would not have been possible with either of the two original
systems alone. What can you say about the boundary of the combined
system compared with the boundaries of the original separate systems?
Answer
Suppose the monitoring system detected that a patient taking a common

drug had a heart problem. If the two systems were combined, it would be
possible to automatically check whether the heart problem might be due to
a known allergy recorded in the patient’s record.
The boundary of the combined system encompasses a wider scope than the
combined boundaries of the separate systems because the combination of
patient monitoring and medical records supports a wider range of
verifications.
2.2 The nature of software

Software is often spoken of as being invisible or intangible, and hence is
thought of as being different from physical artefacts, which can be measured,
touched, broken, and so on. This invisibility can lead to unrealistic
expectations concerning the capabilities of software, which in turn may
contribute to some of the myths that surround software and its development,
for example, that accommodating change is straightforward.
Software can, and does, contain errors. There are three important
characteristics of software that affect its development and the likelihood of
errors:
9
. Malleability. Software is easy to change (programmers are often tempted to

tweak their code). This malleability creates a constant pressure for
software to be changed rather than replaced. Every change introduces the
possibility of new errors.
. Complexity. Software is often complex. Complexity can usually be
recognised, but it is less easy to define. One item of software can be
considered more complex than another if it requires more explanation. Part
of that complexity arises from the potential variety of pathways between
the components of a system. The number of errors is likely to depend on
the complexity of a system.
. Size. It is likely that there will be more errors in a large piece of software
than in a small one.
You have already encountered an aspect of the intangible nature of software if
you have programmed in, for example, Java. The instructions and statements
that you write in Java are translated into bytecode, which you do not see.
You might think that, because it is ‘invisible’, software is inherently more
difficult to develop than a physical artefact. However various techniques can
be used to model software and its behaviour – just as an industrial designer
uses geometric abstractions and other tools to model a physical product before
it is built. We will explore such uses of models throughout the module.
SAQ 2
For each of the three characteristics of software mentioned above, explain

why errors might arise in a piece of developed software.
Answer
Malleability. As change is easy to make, often changes are introduced

without thorough consideration of the full consequences of each new
change introduced.
Complexity. The more complex a piece of software becomes, the more
chances there are of a change affecting other parts of the software.
Size. The greater the number of lines of code in a piece of software, the
greater the number of likely errors.
2.3 Characteristics of a software system

Having considered the basic terms system and software, we can move on to
the notion of a software system. There are two important questions that we
want to address.
. What characteristics should we be looking for in a software system so that
we can develop one that meets the needs of all its users?
. What attributes should a software system have in order to be of high
quality?
We develop a software system in response to an identified need. For the
purpose of this module, we assume a software system is to solve a customer’s
10
problem – this is not always the case as software can be developed without a
specific customer in the hope that someone will buy or use it in the future.
The contract between customer and developer, as provider, includes the
requirements specification, which identifies what the software should do and
the environment in which it must work. We expect a software system to be
useful, as otherwise it cannot meet the needs of its users.
To its users, the user interface represents the software system. No matter what
functionality is contained in the software, it cannot be used to its full potential
if that interface is difficult to use. We expect a software system to be usable –
otherwise the user is hindered in their use of the software to carry out tasks.
We expect a software system to be reliable, in that errors are minimised, as
otherwise its users will not be able to perform those tasks that need its
support.
While developers are busy constructing a software system, it is probable that
the users’ needs will change. In addition new requirements are likely to be
identified once a software system becomes operational. It is also possible that
the developer may miss a requirement during the specification process. We
expect a software system to be flexible, because it is important to be able to
change it easily as time goes by. In addition, a flexible software system makes
it easy to correct errors.
In order to operate in its target environment, any design solution to a
requirements specification must be turned into machine-readable code. No
matter how useful or usable a software system might be, we expect it to be
available in the target environment, offering continually available services in
the customer’s environment.
The contract between the customer and the developer will also include
delivery dates and costs. Whatever process is used, the developer is expected
to meet such contractual constraints. We could also say that the developer’s
working practices affect the availability of a software system, including its
initial delivery and any subsequent changes. From the customer’s point of
view, the software system must be affordable to buy and maintain.
From the developer’s point of view, there must be a way of keeping control of
a project. Labour resources are the most significant component of a
developer’s contract, and often become the two-edged sword that leads to the
success or failure of a software development project.
Much of this module is concerned with the activities that lead to a useful
software system – techniques that will help you to define a requirements
specification and then produce a design solution to the problem contained in
the specification.
SAQ 3
(a) What is the defining quality of a good software system, and what are
its main characteristics?
(b) How might greater flexibility make a software system more
affordable over its whole life?
11
(c) Give two reasons why a delivered software system might not meet
its users’ needs.
Answer
(a) A good software system is one that meets its users’ needs. We can
characterise a good software system as useful, usable, reliable,
flexible, available and affordable.
(b) Users’ needs will change over time. The time taken to implement the
changes in requirements in a flexible system is less than for less
flexible software. As labour costs are the most significant component
of software costs, flexible software is more affordable.
(c) Software systems are usually out of date even as they are being
developed because:
◦ some needs are often missed during requirements capture
◦ users’ needs change with time.
2.4 Maintainability and other software problems

A software system should be both available, so that users can decide whether
or not it still meets their needs, and flexible, so that the developer can change
it to meet its users’ needs. Maintenance is the key activity for the coordination
and control of changes to a software system. In order to be maintainable, a
software system should be written and documented in such a way that changes
can readily be made. This means that we must take into account the process
used to develop a software system. What the developer does during
development affects the ease with which it can be maintained. If a change is
easy to make, the cost of that change (labour) can be minimised so that the
You will study maintainability and software system continues to be affordable. The maintainability of software
other quality factors in Block 3 is greatly influenced by how software is designed, written and documented.
Unit 11.
Problems of maintenance also apply to software that is purchased as an off-
the-shelf package, or software that is offered as a service by another provider.
Example 5
For anything you buy and use, there are costs associated with its purchase and
with the maintenance required for its continued operation. For example, there
are costs associated with buying a car and with its continued operation. As the
vehicle ages, the costs of maintenance rise, and there comes a point when you
have to decide whether it would be preferable to buy a new car or continue
with the existing one. Perhaps surprisingly, there are similarities between the
maintenance of vehicles and the maintenance of software.
Legacy systems
A significant problem relates to software systems that have been in operation
for some time. If a particular software system continues to meet its users’
needs, there may be little or no motivation to replace it, especially if that
12
software is associated with a critical service within a company. Such systems

are called legacy systems and typically have the following characteristics:
. old
. large
. developed using outdated techniques
. implemented with old programming languages
. critical to the business
. changed a number of times since their inception
. difficult to understand because of either a lack of documentation about
their internal structure or a lack of experience within the group responsible
for them
. difficult to maintain because of the above factors.
One option would be to replace an ageing software system with a new one.
But the change from old to new can have serious implications for the
company involved. It is not just the users who need to be retrained to use the
new software. In some companies the whole internal organisation is based
around their major software systems. Changing these may require a costly
company-wide reorganisation to reflect the new software systems more
accurately. There is also the issue of maintaining continuity of service during
the changeover and the risk that the new and therefore unknown system may
not work – in contrast, the legacy system is a known quantity.
There is an additional twist that makes the problem of legacy systems worse.
Staff turnover may mean that there is no one left in the company that
developed the software who understands the legacy system enough to continue
maintaining it. Even if those who developed the original software system have
not left, they may be working on other projects or be unwilling to look after
an old system. When faced with the choice of working on a new or an old
system, many people prefer to produce something new.
There is every chance that tomorrow’s legacy systems are being built today.
We might say that today’s solutions are tomorrow’s problems.
Unsuccessful software systems
Example 6
In 1992, the London ambulance service commissioned a computer-aided
dispatch (CAD) system for getting ambulances and their crews to reported
incidents. It was intended to replace an existing paper-based system. There
were two notable failures of the new system in November 1992 that resulted
in severe delays in ambulances reaching certain incidents.
The final report on the system failures (South West Thames Regional Health
Authority, 1993) identified a number of major management problems with the
project. A technical audit revealed that the CAD system was incomplete and
not fully tested. Its ability to deal with heavy loads had not been tested and
nor had a backup service been tested. There were also outstanding problems
13
with the accuracy of the information needed to initiate each dispatch (South
West Thames Regional Health Authority, 1993).
Unfortunately, successful software systems rarely make the news. Example 6

illustrates the kind of failure that does break through into the public domain
(in this case, the failure became a series of headline stories). The London
ambulance service had a software system that was lacking in usefulness,
usability, reliability and availability.
This discussion of software problems has probably given you a rather
pessimistic view of software development. You must not forget that many
software systems work, and work well, given the fact that they are used in
every aspect of modern life. However the rate at which the role of software is
evolving is so fast that there must be practices involved in developing
software that can cope effectively with this expansion.
SAQ 4
(a) Suggest a means of measuring the maintainability of a software

system.
(b) What can we learn from legacy systems about developing a good
software system?
(c) Suggest a reason why legacy systems will always be a problem.
Answer
(a) We could measure the effort required by a developer to locate and

implement a given change to a software system. That effort can be
classified in two components – the effort needed to locate and fix
errors (bugs), and the effort needed to adapt the software system to
meet its users’ needs.
(b) A legacy system may have started out with all the characteristics of a
good software system, yet those characteristics may have changed
over time, resulting in a less flexible and maintainable product. As
change is inevitable, the right processes should be in place to make
change happen in a more controlled way. This requires the adoption
of standards and documentation conventions that help decision
making on changes and how to introduce them. Any changes need to
be well documented so that software is still understandable and less
dependent on the people initially involved with developing and
maintaining the software.
(c) The inherent malleability of software makes it easy to change. You
have already seen that a legacy system is lacking in flexibility as a
result of the number of changes made to it during its operational
lifetime. (The analogy with metalworking through malleability is
useful. Once a blacksmith forms some component, usually in iron,
there is a limit to the number of times that it can be heated, formed
and cooled before that component becomes brittle and hence liable to
failure.)
This explains why our ability to bolt features and fixes onto a legacy
system means that it will eventually become too fragile, and it will
14
become precarious to go any further. The staff issues mentioned in (b)

compound these problems.
2.5 Divide and conquer?

As computing technology has improved, we have tried to construct software
systems that can deal with larger and more complex problems. In order to
provide such solutions, the software systems themselves have become larger
and more complex. Unfortunately there is a limit to how much we can take in
and understand at any one time. How can we cope with tricky problems or The Romans had a strategy called
situations where there is just too much information? divide et impera – divide and rule.
However this covered the idea
The main technique for dealing with such messy situations is decomposition. that it was easier to rule over
We can decompose a problem into smaller and smaller parts or chunks until groups in conflict with each
each one can be comprehended or dealt with by an individual. In terms of our other.
earlier definition of a system, we are looking for patterns and/or components
within a system and creating internal boundaries around them to identify
smaller subsystems, sometimes referred to as modules. We will expose some
form of hierarchy in our attempt to simplify a complex system.
The concept of decomposition can also be applied to the way you develop a
software system. As you will see in Section 3, you can identify a number of
different activities or tasks that an individual or group of individuals might
perform in a software development project.
An individual can successfully build small software systems because it is
possible for that person to understand all that is needed about the problem and
its solution. There is a long history of individuals attempting to develop more
complex systems – so-called heroic programming – where success has been
less certain. Sometimes the circumstances resulting from poor planning lead to
a situation where it is the only way out to achieve a piece of workable
software. However there are systems that are so large and complex, such as
those that monitor and control air traffic, that they cannot be built by a single
individual. The development of such a software system requires a team of
people whose work must be well coordinated and managed. There must be a
well-defined process if they are to produce an appropriate solution – a
software system that is useful, usable, reliable, flexible, available and
affordable. In practice, the process of software development is partitioned to
enable individuals to specialise in different development activities such as
analysis, design and implementation.
Problem and solution

By dividing one large problem into a set of smaller subproblems, we might
expect to reach a point where we can capture, understand and describe each
subproblem. But there are two difficulties.
. How do we know that each identified subproblem is any easier to
understand and solve than the original problem?
15
. How do we know that all of our subproblems will fit back together again
and recreate that original problem?
The key to finding subproblems that you recognise and understand is prior
knowledge and experience. As a developer, you may know how to create a
good design or a good program, but you may not be familiar with the
problem domain.
As a developer, the problem that you face is in the world outside the
computing system, where you aim to provide a solution. The software that
you construct can provide solutions to problems because they are connected to
the world outside, as illustrated in Figure 1.
the problem is in computing system

the world outside
connections between the world

and the computing system
Figure 1 Separating a problem from its solution
The main issue that you as a developer should focus on is solving the
problems identified by the users, rather than worrying about how to write the
program code. When projects fail it may be because of mistakes that were
made quite early on in the design stage, often resulting from poor
understanding of the problem domain, not because of what happens at the
coding stage.
Example 7
One way to find out whether you have a good solution to a problem is to
consider the kinds of complaint you would receive from users if your software
did not work properly. For example, suppose someone had made a reservation
to stay in a hotel but when they arrived, the receptionist told them that there
was no reservation in their name. In another case, they might have reserved
rooms for six people only to find that there was only room for one.
By doing such thought experiments you may often be able to spot flaws in
your solution, although of course there may always be situations you have
overlooked, so you can never be completely certain that your solution is
comprehensive.
Modules and interfaces

In software development, there is a long history of decomposing a system into
smaller modules. This modularisation is the standard technique for dealing
16
with large and complex systems. The modules partition the system design or
code. Some typical examples of modules are:
. whole programs or applications
. software libraries
. classes, in an object-oriented language such as Java.
Although modules may appear as self-contained elements, because they are all
parts of a larger whole there must always be relationships between them that
need to be taken into account, as Example 8 shows.
These relationships limit the ability to change one module without affecting
other modules.
Example 8
In developing a software system for a typical manufacturing business, we can
identify a number of possible subsystems – areas for development, such as
systems to deal with customers, production, accounts (payments) and
deliveries. While we might want to treat these areas as independent (as
partitions), there are connections between them. For example, customers are
expected to pay for the goods that they have ordered from the business, and
the deliveries department is expected to deliver to the customer. Similarly in
the production subsystem, the progress of each customer’s order would be
tracked through the factory and on to the delivery of the completed goods to
the customer.
In general, we say that the interface to a module defines how other modules
can use that module. An interface is the means of connecting one module to Sometimes, you can define more
another. It tells you what to expect about the behaviour of a given module and than one interface for a module
what services the module will provide, without telling you how those services to allow yourself to be more
precise about which services will
will be provided. For example, the interface can define how a bank accounts be offered to different kinds of
module will respond to queries about the balance of an account or the types of client.
accounts available.
The interface of a module is a description of all the externally visible
operations and what other modules need to know and do to make use of them,
but without any details of how the operations are implemented internally.
From an object-oriented point of view, we say that the interface to the bank
accounts module is an encapsulation of what we know about accounts in a
bank.
A module that provides services to other modules may in turn need to use the
services of yet other modules. These required services are called its context
dependencies. A module’s context dependencies and its interface, including
any requirements that prospective clients need to meet, together form a sort of
contract with clients. The contract describes what the module does and what
needs to be true for the module to do it. Clients can assume that if the
necessary conditions are met the module will fulfil its specified
responsibilities.
17
The concept of an interface helps the developer to be more productive. If you

can rely on the specification contained in another module’s interface, there is
less for you to understand because you do not need to know how it works.
Furthermore, you have a better chance of understanding your part of the
software system because you can focus on the things you need to perform
your task. A side effect of this added understanding is that you are less likely
to introduce errors. Furthermore, if a module is hidden behind an interface it
is potentially replaceable.
Once your software system contains a set of modules that are well understood,
each with its own interface and context dependencies, you can consider
whether any of them can be reused. It may be that a popular set of modules is
adopted as a standard.
The ability for different computing systems to communicate over a network
has developed because of the adoption of such a standard set of modules.
Control over the complexity of computer communications has been gained by
decomposing the problem into a number of layers. Each layer has a well-
defined interface through which the layer above it accesses its services.
Abstraction is a particular way of viewing a complex problem to arrive at
some useful decomposition of that problem. The idea is to group together
similar objects or situations and, while ignoring their differences, focus on one
particular and common aspect of the problem that all these objects/situations
possess and/or reflect. The key task in developing a software system is to
decide upon the most suitable abstractions in the problem domain.
We can say that we have achieved a useful abstraction in a particular module
if the potential software clients of that module do not need to know more than
is contained in its interface. For example, a dedicated module to deal with
date handling is a useful abstraction. The fact that it may be complex to
implement is immaterial to clients that use the services defined in its interface.
Coupling and cohesion

As Example 8 shows, developers need to deal with the dependencies that arise
as a result of their decomposition of a problem and its solution into a number
of modules. We say that a module of a system depends on another if it is
possible that a change to one module requires a change to another. For
example, if a business changes its production methods this may cause a
consequent change in the way it calculates the payments required for the
goods it produces.
A developer must not only deal with the nature of each dependency but also
the number of dependencies. In software engineering, the term coupling is
used to refer to the degree of interdependence among the different parts of a
system. It is easy to see that certain systems can have chains of interdependent
modules where, for example, module A depends on module B, which depends
on module C, and so on. In some cases these chains may join up and create a
circular dependency, which is a particular form of strong (or high) coupling.
Developers try to construct loosely coupled systems because they are easier to
understand and maintain. So a good software system has low coupling, which
18
means that changes to one part are less likely to propagate through the rest of
the system. A further benefit of low coupling is that components are easy to
replace and, potentially, reuse.
Whatever the level of coupling in a software system, it is important to know
which modules are coupled. If there were no records of the coupling between
modules, a developer would have to spend time working through the modules
to determine whether or not each was affected by a change. The result would
be a lot of effort spent on checking, even if no changes were needed.
Example 9 illustrates the danger of having more than one module making use
of common or shared data.
Example 9
Date handling has always been a problem for software developers. For
applications of a certain age, the most applicable storage format for
representing a year was a number between 0 and 99. It made sense because
1966 was stored as 66, 1989 as 89, and so on, therefore less space was
needed to store just two digits. Furthermore, if dates were stored as numbers,
tasks that involved sorting by date order were simple – 22 January 1989
stored as 890122, is after 22 December 1966 stored as 661222.
Unfortunately, a number of these applications were still in use as the year
2000 approached, so every module in every application that used the short
form of year had to be investigated.
A major aspect of the problem in Example 9 was that different developers had
different ways of reading and manipulating the values stored in variables that
used the six-figure date format. This increased the effort required to resolve
the so-called millennium bug. If developers had had a consistent way to
manipulate dates that did not rely upon the storage format, the millennium
bug would not have been an issue of concern.
Cohesion is a way of describing how closely the activities within a single
module are related to each other. Cohesion is a general concept – for example,
a department in an organisation might have a cohesive set of responsibilities
(accounts, say), or not (miscellaneous services). In software systems, a highly
cohesive module performs one task or achieves a single objective – ‘do one
thing and do it well’ is a useful motto to apply. A module should implement a
single logical task or a single logical entity.
Low coupling and high cohesion are competing goals. If every module does
only one thing at a low level of abstraction, we might need a complex edifice
of highly coupled modules to perform an activity at higher levels of
abstraction. A developer should try to achieve the best balance between the
levels of coupling and cohesion for a software system. For example, hotels
generate income by letting out their rooms to guests. The concept of room is
likely to be represented somewhere in the software system for reservations for
a hotel. It may be convenient to use a module or class representing the
concept of room to collect and store data about the income generated by
letting rooms. However a better solution is to have a separate bill or payment
module, because it is more cohesive, especially when a hotel generates income
19
in other ways, for example from serving meals to people who are not resident
guests.
SAQ 5
(a) Why might you consider splitting up a large project into smaller
chunks?
(b) How does the complexity of a software system affect the
maintenance task?
(c) What is a module?
(d) Why does it help to have low coupling in a software system?
(e) Give examples of the kinds of information that would be valuable
when considering a change to a given module.
(f) What are the context dependencies of a module? How do they relate
to a module’s interface?
(g) What are the benefits of using modules with defined interfaces?
(h) Why does it help to have high cohesion in the modules of a software
system?
(i) What characteristics should a module display that will help to ensure
that it is easy and cheap to develop and maintain, and that errors are
kept to a minimum?
(j) Why is it important to achieve a balance between coupling and
cohesion?
Answer
(a) There is a limit to how much one person can understand at any one
time. So there is a limit to the size of a software system that any one
person can deal with. By splitting a large project into smaller
chunks, it is possible to identify a number of more manageable tasks
for those involved.
(b) It is essential to be able to make a change to a software system
without having to know all about that system. Each change becomes
difficult when the flow of control and dependencies within programs
are complex. The greater the number and nature of the dependencies,
the harder it is to maintain a software system.
(c) A module is any identifiable part of a software system that is
considered separately. For example, modules may be subroutines (in
a procedural language equivalent to methods), classes (in an object-
oriented language), library functions or other constructs that may be
treated independently.
(d) With low coupling, there are few dependencies between modules.
Therefore changes made to one part (one or more modules) of a
software system are less likely to propagate throughout the whole
system. (A clear record of the dependencies between modules helps
you to predict the impact of a proposed change to a software
system.)
(e) There are two kinds of information that contribute to the analysis of
a proposed change:
20
◦ Which modules are clients of the module in question? This

information indicates how far a change may propagate
through the software system.
◦ What assumptions have been made in client modules of the
module in question? An understanding of the expected
services of a module will help assess the risks associated with
a particular change.
(f) The context dependencies for a module are the services of other
modules that the module needs in order to work correctly. You can
express the context dependencies for a module in terms of other
interfaces. In effect, you can express the responsibilities of a module
in terms of its interface and context dependencies. If the context
provides the services that the module needs and clients meet any
conditions specified in the interface, the module can guarantee the
provision of the services described in its interface.
(g) The benefits are as follows:
◦ Developers will need to know only about the module’s
interface (its syntax and what it requires and achieves – its
semantics), not how it provides those services. Consequently
developers can be more productive.
◦ Developers can understand aspects of the software system
more thoroughly, so fewer bugs will be introduced.
◦ It should be easier to find bugs, as irrelevant modules are
avoided.
◦ The possibility of module reuse is increased once it is known
what that module provides and requires.
(h) With high cohesion, a module carries out a sensible set of operations
or activities. Ideally high cohesion implies just one major abstraction
per module. The interface abstracts away from what a developer
must know in order to use a module. This makes it easier for
developers to understand the purpose of the module and how to use
it. In addition high cohesion tends to make a module more reusable
in other applications, because it provides a set of operations that sit
naturally together.
(i) A module should have low coupling and high cohesion, represent a
good abstraction, and have a well-defined interface that is an
encapsulated abstraction of a well-understood concept.
(j) In constructing a system, you may have a choice between a smaller
set of loosely coupled, less cohesive modules, or a larger set of
tightly coupled, more cohesive modules. In the former case each
module may be difficult to understand, while in the latter case the
relationships between them may be over-complex. You need to strike
an appropriate balance.
21
2.6 Architecture
In software development the term architecture is associated with the overall
structure of a software system or, at a higher level, a family of software
systems. For this module, we will adopt the following definition, taken from
Bass et al (2012).
The software architecture of a system is the set of structures needed to

reason about the system, which comprise software elements, relations among
them, and properties of both.
It is important to understand the software architecture because it tells the

developer, among other interested parties, about the overall shape of the actual
or proposed software system. It explains how the development team can use
various technologies to construct or assemble a software system.
Software requirements come in all shapes and sizes, so developers need to
consider what is the most appropriate process to develop an architecture for a
given context. Choosing a software architecture, or at least part of it, is one of
the earliest decisions a development team has to make. There is always
something that can be called a software architecture, whatever software system
is being developed. Even a basic software system has an architecture.
Architecture serves as a main guide for developers but it is also of importance
to other stakeholders in software development, all of whom will have different
concerns about the software. For example:
. users may be concerned with how easy it is to use and learn
. the customer is interested in how much it will cost and when it will be
delivered
. software maintainers will be thinking about how easy it is to modify and
understand the repercussions when a change is required to one of the
modules.
The architecture will therefore embody many decisions that will affect how
the concerns of the many stakeholders are dealt with. It will also serve as an
important means of communication between the different groups of
stakeholders. It is the role of the software architect to balance these different
concerns and reach compromises among competing concerns.
SAQ 6
Suggest some similarities and differences between software architecture and

building architecture.
Answer
They are both abstractions of the structure of a system. They represent

decisions that will affect concerns of different stakeholders. They are used
as a communication vehicle with different stakeholders.
Changing a building once complete is expensive, whereas changing details
or internal decoration is quite cheap but may incur costs in wastage in
22
materials. Software has different properties from building components, in

particular its malleability and complexity. Reworking the whole architecture
of a software system is also expensive because of the complexity involved
– making internal changes does not incur costs in wastage of materials, as
software is malleable, but it incurs other costs in terms of time and work
invested.
Layers, components and services

A software architecture identifies a set of rules for decomposition – the
assumptions used to modularise a software system. A major aspect of the
architecture is the identification of the different partitions into which you can
put the various pieces of software that are going to be used to provide your
solution to a problem. Any proposed change to a system will have a different
impact, depending on the software architecture chosen. Here we look at three
ways of decomposing an architecture, with layers, with components and with
services.
Figure 2 illustrates one instance of a layered architecture that can be found
in distributed computing systems. The top layer concentrates on the
presentation aspects concerned with the user interface, which are more prone
to change than the rest of a software system. (It is natural to expect a number
of requests from users to make a software system more usable.)
The application domain is concerned with support for the way a user performs
a given task, such as the processing of a customer’s order. A business may
redesign the tasks that its employees perform, but perhaps not as often as
amendments will be made to the user interface. Unless a business makes a
radical shift in its core business concepts and transformations, the business
services are less prone to change than the user interface.
The infrastructure contains the system support that usually includes the
operating system and the databases, which allows the system to be more
easily ported to new platforms.
presentation
application
domain
infrastructure
(OS, databases, etc)
Figure 2 Three-layered architecture
Reuse is one strategy to deal with increased complexity of software and it

addresses the concerns of maintainability, minimising costs, short delivery
times and quality of software. In this module, we will see many examples of
different types of reuse and discuss it in more depth in another unit.
23
We use the term component to denote a unit of reuse or replacement in a

software system. A component could be a module or class with certain
properties that make it reusable or replaceable in a given software architecture
and it may depend on other components. Components are well understood,
each with its own interface and context dependencies (see Figure 3 for
representations of a component to be discussed later in this module). It may
be that a popular set of components is adopted as a standard. What is
important is to have one, or possibly more than one, standard in mind when
you are deciding whether or not a particular module or class is a component.
Enterprise Java Beans (EJB), .Net and CORBA are examples of standards for
components. The user of a component needs to adopt the same technology as
that with which the component was developed.
provided interface graphical stereotype
«component»
IProvided MyComponent
MyComponent «provided»
IProvided
IRequired «required»
IRequired
required interface
(a) (b)
Figure 3 Two graphical representations of a component
A similar concept is that of a service. A service is also a unit of reuse

corresponding to a piece of functionality, described in a standard language,
with published interfaces through which the service execution can be
requested. A service, however, is technology-neutral in the sense that it can be
invoked using standard communication protocols, while a component is
usually technology-dependent as a client needs to use the same technology as
the component.
A service is also discoverable, meaning that it can be used by clients
independently of where it is located – service repositories can be accessed to
locate services according to their definitions. A service-oriented architecture
(SOA) structures software as a set of services.
The notion of services being accessed remotely through a web browser –
software as a service (SaaS) – is popular now with systems such as those
provided by Google (for example, Gmail and Google Docs).
Services may not be owned by the organisation developing the software
systems that use them. They come with a service description and reside in a
provider server. Programmers (consumers) who use them in their systems do
not have access to the code that implements them – they need to find them in
a registry of service descriptions and once found they can invoke them (see
Figure 4).
24
find service
consumer registry description
bind and invoke publish
service
description
provider
service
Figure 4 Services
Components tend to relate to entities, while services relate to processes.

Components are assembled together through connectors (usually called glue)
that are static structures, while services are bound at run-time in a dynamic
way when they are discovered (Mašek et al, 2009).
Layers, components and services are different ways of structuring an
architecture. They can also be used in conjunction with each other. Later in
this module we will discuss architecture styles in more depth and we will see
reuse of basic forms of architectures, of styles, and of complete architectures,
such as frameworks and product lines.
SAQ 7
(a) What are the characteristics of a component?

(b) How does the concept of an architecture contribute to component
reuse?
(c) Which form of decomposition might be used in a software
architecture?
(d) What are the similarities and differences between components and
services?
Answer
(a) A component is a module that is considered to be a sufficiently good

abstraction for the problem in hand. A component should be capable
of being reused in future projects having the same software
architecture, or being easily replaced at a later date within the
existing software system. As with all modules, a good component
has a well-defined interface and is an encapsulated abstraction of a
well-understood concept, with strong cohesion and low coupling.
25
(b) The architecture of a software system embodies high-level decisions

about the overall structure of the system, and this architecture may
apply to more than one system.
(c) The basic form of decomposition used in a software architecture is
partitioning to meet a number of separate concerns, each concern
being addressed by a subsystem. For example, you might want to
separate the user interface layer from the core business services
layer, or you may decide to build or reuse components and/or
services for some of the partitions.
(d) There are similarities between a service and a component. They both
promote reuse and flexibility. They both use public interfaces to
allow requesters to make use of their functionality without relying on
their implementation.
There are differences too. A component is usually implemented in a
specific object-oriented technology, therefore only clients compliant
with that technology can easily communicate and integrate with it. In
contrast, a service uses communication standards that allow the
interoperation of diverse technologies.
Finally, components tend to be associated with business entities, while
services tend to be associated to business processes – they may realise
part or the whole of the functions within such a process and may
involve several business entities. Be aware that although this is a
widely accepted classification, not everyone follows it, and you may
see components called services and vice versa.
2.7 Summary of section

This section has briefly examined the nature of software, and identified the
desirable characteristics of a software system. You have seen:
. that a good software system is one that meets its users’ needs
. examples that illustrated the connections between the usefulness, usability,
reliability, flexibility, availability and affordability of a software system
. that a software system can soon be out of date, as users’ needs change
with time, and that needs can often be missed during requirements capture
. that modularisation is the main method of dealing with the size and
complexity of a software system
. the problems that arise with legacy systems
. the significance of maintenance
. the importance of software architecture.
Software systems are becoming all-pervasive in our society, and the demand
for new systems is growing rapidly. There are significant risks associated with
software systems when they are critical to a business. This all points to the
need for software development processes that will deliver software systems
that are easy to maintain and reliable, while at the same time ensuring that the
systems serve some useful purpose for their users. Good development
26
processes will produce well-engineered components based on reusable

architectures.
27
3 An introduction to software development

In this section we will introduce the basic activities involved in the
development of software. Then, we will consider the general concept of a life
cycle for software development and discuss examples of different life cycles.
At the same time, we will consider the importance of models as part of
software development.
3.1 Software development as an engineering

activity
Software development has a great deal in common with the discipline of
engineering, from which the term software engineering arose, and is said to
be:
1 The application of a systematic, disciplined, quantifiable approach to the

development, operation, and maintenance of software; that is, the
application of engineering to software.
2 The study of approaches as in (1).
(IEEE, 1990)
Carrying out a systematic, disciplined and quantifiable approach implies

management, and assumes that project management is a necessary activity
within the discipline of software development.
As discussed in Section 2, words such as reliable, flexible and maintainable
(among others) describe characteristics of software systems. They are all
aspects of software quality. To obtain a high-quality software product
requires a well-managed development process.
But the term engineering for software development is also associated with a
few other factors:
1 Developers are concerned with meeting a set of requirements – there is
usually an identifiable problem that they can solve.
2 There is a defined process that can be used to produce a solution and,
within that process, there are a number of identifiable phases or activities.
3 There are tasks to be done in each phase that result in one, or possibly
more than one, artefact related to the final product (software, hardware or
document). Developers undertake different roles to perform such tasks
(designer, programmer, tester and so on).
4 The quality of both the products and the processes by which they are made
is important: the right product is being built (validation), the product is
built in the right way (verification), and the product is behaving as
expected (testing).
5 There are tools to improve the effectiveness and efficiency of the tasks
performed by developers in their various roles.
28
6 There is a body of knowledge that developers might use and/or add to.
There are ways of working to support the previous five factors (such as
standards and rules for decomposition in a given context).
7 There is a recognised professional activity with its own code of practice
and legal framework.
You might like to look at some dictionary definitions of the term engineering
and see how the above observations fit them.
While there is considerable argument about the term software engineering,
there is no doubt that software development does require certain skills and
knowledge of certain ideas and principles. This section looks at what is
needed to ‘engineer software’. What should a developer do in order to
produce a software system that meets the needs of its users?
In Section 2, you saw that there are three characteristics of software that affect
its development and use – malleability, complexity and size – and that these
all contribute to the likelihood of errors. Issues arising from size and
complexity are addressed through modularisation. In order to ensure that the
introduction of errors is minimised whenever a change occurs, you need to
pay special attention to the development process.
Software development is a human activity. Software systems are developed by
one group of people for another group of people to use. The success or failure
of a project is determined by social as well as technical factors.
Users want a system that does what they need and that they can use. One that
is technically superior but does not meet these criteria will fail. Users will
resent, ignore or, in the worst case, completely reject it.
SAQ 8
Give the characteristics of an engineering approach that support the

argument that software development is an engineering discipline.
Answer
Software development follows an engineering approach provided that the

following conditions are met:
. it is concerned with meeting a set of requirements that are defined as
clearly as possible
. it uses a defined process with clear activities, each of which has at
least one identifiable end product
. developers can apply their skills and experience to the tasks
demanded of them
. validation and verification are regarded to be as essential as building
the software itself
. it makes sensible use of tools and standards
. it follows a code of practice.
29
3.2 The role of development processes

A development process is a set of rules that defines how a software
development project should be carried out, and a set of software engineering
activities associated with the development of software. Each activity
undertakes some clearly defined process, starting with a number of inputs
from any preceding activities. On completion of an activity there may be one
or more outputs, which are known as deliverables.
The order in which these activities are carried out is called a life cycle or
process model, and outlines an overall process for the development of a
software system. Project management and quality management activities
permeate the life cycle of software development. A complete life cycle takes
us from the first ideas about the need for a software system to its final
withdrawal.
This approach of following a well-defined process has been promoted as the
best way to meet the potential diversity of users’ needs, and the primary
mechanism to understand and harmonise conflicting demands on the
development process. However this approach has also been contested as too
prescriptive, heavy on documentation, and not helping to meet the
expectations of customers. In this section, we will start by presenting a well-
defined process for software development but will also discuss some lighter-
weight alternatives.
In Section 2, we introduced the notion that a good software system is one that
meets its users’ needs. In general, we will identify a customer as someone
who pays for a software system, in contrast to the people who use it on a day-
to-day basis – the users (although a customer may also be one of the intended
users). A successful development project will deliver a product that meets, or
even exceeds, the customer’s expectations.
Software can also be developed without an identified customer – in that case
it is successful if it can find someone who will become a customer and buy it.
We will assume that a customer (or someone acting as a customer) has
assessed the feasibility of some initial ideas with a potential group of users
and has decided that a software system may be required.
Typical technical activities for the development of software

There are many and varied methods used to develop software. However each
one typically includes activities that can be roughly classified as follows:
. Domain modelling. Understanding the environment in which a system
may be introduced – the business processes and rules. This is typically an
activity that precedes a decision to develop a software system.
. Requirements (also known as requirements engineering). A set of steps
including requirements elicitation, where you identify the problem, and
requirements analysis, where you categorise, prioritise and model
requirements. This defines what the system is to do.
. Design. Determining how you will solve the problem.
30
. Implementation. Acting upon the decisions made at the design stage.

. Testing. Testing what you have done so that you can determine whether or
not you have solved the problem.
Different methods may subdivide the above activities or use different
terminology. A specific approach, the Unified Process (UP), will be introduced
in Section 4 and illustrated in the main case study. By themselves, however,
these activities are not enough to develop a good software system. Other
activities are needed to a greater or lesser extent depending on the context, as
you will see in this section.
You are likely to break up most problems into smaller, more manageable
chunks, and deal with each one separately. It will then be necessary to bring
the chunks together into a unified whole. This process is known as
integration and is sometimes identified as a separate activity. Sometimes
delivery of the software system is also identified separately, especially when
there are contractual implications such as payment.
A software system is likely to change during its operational lifetime. This is
the maintenance activity, which allows a software system to evolve in order
to:
. correct errors
. adapt to a changing environment
. introduce enhancements required by the customer
. improve the software in anticipation of future changes.
The four activities of analysis (analysis is often used as a generic term for the
activities that precede design), design, implementation, and testing are the
ones you will see most often in diagrams depicting the process model of
software development.
It is important to recognise that they are not the only activities involved in the
process of developing a good software system. Project management and
quality management are the two additional activities that hold the process of
development together – the all-important glue for software engineering
activities. Maintenance will inevitably involve the activities of requirements,
design, implementation and testing, and will itself need to be managed, as
illustrated in Figure 5.
31
project
management
maintenance
analysis
testing design
implementation
quality
management
Figure 5 Activities for the development of a good software system
An overall process model

A process model (or life cycle) is a description of all the events and activities
in the life of a software system or product and the sequence in which they
happen. So you can choose how to connect the activities together to form a
process model, which you can then use to elaborate a process for developing
software. For example, if you arrange the five activities of requirements,
design, implementation, testing and maintenance into a single sequence, you
have the classic waterfall model.
However in practice it is not usually possible to complete each activity
correctly in one attempt. In addition, as development proceeds, the products of
earlier stages become dated, as your understanding of both the software and
its environment evolves.
If projects use a strictly sequential process model, a working version of the
software system will not be available until late in the testing activity. This will
represent a long wait for both customer and users, who won’t be able to see a
working response to their requirements until the final product is finished. In
addition, any errors detected in the working version of the software could be
disastrous as it would be too late to correct them. Real projects rarely follow a
purely sequential process model. The act of reviewing is an important activity
when testing the quality of any development process and its resulting
products.
An alternative process model is to iterate around one or more of the activities.
Iteration allows the developers to improve the outputs from a given set of
32
activities and get feedback before moving on to the next activity. In particular,
iteration allows a group of people, usually developers, to perform a review of
a sequence of activities, or of an activity and its outputs.
In general, reviewing a proposed solution provides the feedback necessary to
modify it and improve the solution. Think what happens when you need to
tune a guitar or violin. You pluck a string, a note sounds, and you adjust the
tension on that string. You repeat the process until you get the desired pitch.
It is often difficult to identify all requirements and state them explicitly at the
outset of a development project. It is a good idea to start with a subset of the
requirements and incrementally grow the system with feedback from each
iteration. This approach is known as iterative and incremental development.
As shown in Figure 6, each iteration is a complete small project, with a short,
fixed timeframe (timeboxed), consisting of requirements, design,
implementation, testing and integration, and resulting in a partially working
system. Each of these repeated short iterations adds complexity until the final
system is produced.
feedback from
requirements requirements
iteration n leads
to refinement and
design design
adaptation of the
time
requirements and
implementation and implementation and
design in iteration
test and integration test and integration
n+1
and more design and more design
final integration final integration

and system test and system test
3 weeks (for example)

iterations are fixed in the system grows
length, or timeboxed incrementally
Figure 6 Iterative and incremental development process (Larman 2005, p. 20)
In an iterative and incremental development, users obtain useful and usable

software quickly. This method also enables the developers to take on board
feedback from users as the software develops – an increment may simply be
an enhancement of the previous version. Increments can be developed
sequentially or in parallel, depending on circumstances. For example, a small
team might choose to develop increments sequentially, according to a priority
agreed with the users.
SAQ 9
(a) What is a development process?
33
(b) What should the role of project management be with respect to the
deliverables of a development project?
(c) What is the difference between a customer and a user?
(d) Suggest a reason why maintenance is a core activity in the
development of a good software system.
(e) What additional task is needed when the development of a software
system is partitioned into a number of increments?
(f) What are the assumptions on which the waterfall model is based?
Answer
(a) A development process is a set of rules that defines how a software

development project should be carried out. It incorporates a number
of activities, and a process model (or life cycle) that indicates how
these activities are ordered.
(b) A good software system must be affordable and available within an
appropriate timeframe. Each deliverable uses resources, such as
developers’ time, that add to its cost. Project management involves
the identification of the appropriate deliverables for a given set of
requirements and controlling the cost of producing them. Project
management also involves ensuring that deliverables are produced on
time and taking steps to cope with any delays.
(c) A customer is the person who pays for a software system, whereas a
user is someone who will use that system on a day-to-day basis. A
customer will also be a user when the proposed software system is
intended to support their job.
(d) Maintenance allows a software system to evolve over its operational
lifetime so that it continues to be useful.
(e) A task devoted to the integration of the increments to form the final
software system will be needed.
(f) There is an assumption that once a particular activity or phase is
finished, it is not re-entered, and that the activities do not overlap but
follow each other in a sequential life cycle. There is no need for
reviewing or reworking. All this presupposes that an end point for
each activity can be identified.
Agile development
Agile development has become, in the last twenty years, a popular approach
to software development. It is an umbrella term used to describe a variety of
(agile) methods that promote a set of practices that encourage simpler, more
light-weight, faster and nimbler software development that can adapt to the
inevitable changes in customer requirements. The continual realignment of
development goals with the needs and expectations of the customer aims at
software that better serves its purpose.
As seen below in the manifesto, agile development is an approach to software
development that puts people and working software at the forefront of the
development process.
34
The movement towards a more agile way of developing software has been
gathering momentum for a long time. Many of its proponents were associated,
throughout the 1990s, with several approaches known as light-weight in
opposition to more prescriptive approaches to software development. In 2001,
leading proponents of the agile approach got together and wrote a manifesto
(Figure 7).
Manifesto for Agile Software Development
We are uncovering better ways of developing

software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools

Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.
Kent Beck James Grenning Robert C. Martin

Mike Beedle Jim Highsmith Steve Mellor
Arie van Bennekum Andrew Hunt Ken Schwaber
Alistair Cockburn Ron Jeffries Jeff Sutherland
Ward Cunningham Jon Kern Dave Thomas
Martin Fowler Brian Marick
© 2001, the above authors

this declaration may be freely copied in any form,
but only in its entirety through this notice.
Figure 7 Manifesto for agile software development
Agile practices of simpler, lighter-weight, faster and nimbler software

development that can adapt to change are best practices that are not new.
Iterative and incremental development, for example, has been promoted for a
long time in the short history of software development and adopts some of
these practices. However what the agile approach does is to promote the
implementation of those practices with well-defined rules. The emphasis on
the people involved in the development is also common to all agile
approaches and is the basis of the sense of fun, motivation and productivity
usually associated with it.
The agile movement also has its deprecators and critiques, one of them being
that agile methods do not scale up to larger systems. It is however accepted
that some old practices of software development sometimes lead to problems
and agile practices, although not a panacea, may bring better ways of
working.
Extreme programming (XP) (Beck, 2004) is one of the best-known agile
methods. It is a light-weight method, based on intensive testing and
35
incremental development. It defines a series of practices about how individuals

and teams should work, how the environment should be set up, and how the
work should be carried out. These practices include incremental design, test-
first programming, programming in pairs, continuous integration, planning for
the week, and so on. Scrum (Schwaber and Sutherland, 2011), which is also a
popular agile approach, defines a set of roles, events, artefacts and rules. All
events are timeboxed and have well-defined rules – scrum events comprise:
. the sprint – a development phase, no longer than a month, that has as a
deliverable a useable working increment
. the sprint planning meeting – lasts no more than eight hours
. the daily scrum – a daily meeting, no longer than 15 minutes, looking at
what has been done and planning the work for the next 24 hours.
Many of the agile practices are geared to better communication and
collaboration among developers.
Several agile practices have been recognised and incorporated in other more
prescriptive development processes, in particular the emphasis on people as
opposed to process, short iterations and the acceptance that systems change.
The term agile can be found now in many contexts, and it is interesting to
see, for example, a report from a UK government agency, the National Audit
Office, on Governance for Agile Delivery (National Audit Office, 2012).
In this module you will follow an iterative and incremental approach to
software development and will learn a set of techniques and procedures and
how to use them. We will also be discussing how an agile approach can be
taken at each step but will not be discussing in any great detail specific agile
methods and their rules.
It requires experience to be able to pick, choose and adapt the elements of a
development process that best suit a real situation. This is often what happens
in practice and many development processes get adapted rather than used as
mandated. By learning a set of techniques and a process to apply them, and
by discussing possible alternatives you will be in a better position to make
these decisions. Software development is not an exact science and many
factors, such as context, the organisation and the problem will dictate how
development proceeds.
We will be using the term agile (with a small ‘a’) to refer to best practices, as
opposed to Agile (with a big ‘A’) to refer to specific agile methods. We will
use the term plan-driven development to distinguish traditional, more
prescriptive approaches to software development from agile development
approaches.
3.3 Choosing an appropriate process

By definition, a good software system must be fit for its intended purpose. It
should therefore be evident that because software is needed for such a variety
of purposes, there is no single development process that will suit all purposes.
Consider the following reasons for building systems:
36
. to control a series of gates at level crossings

. to control a manufacturing process for chemicals
. to manage an international stock market
. to manage a supermarket
. to manage a public lending library
. to administer the activities of a university
. to help you manage your personal finances
. to control your television and video recorder
. to play a game on a mobile phone
. to manage electronic funds stored on a smartcard.
The people who use these systems will have different views about what it
means to have a software system that is useful, usable, reliable, flexible,
available and affordable. So it should be no surprise that there are different
development processes for different types of system. Indeed software
companies often specialise in developing software for specific kinds of
business, such as banking or manufacturing.
Choosing the appropriate level of formality

The following two examples illustrate how the amount of formality in a
development process varies.
Example 10
Government legislation often requires software systems to be built to support
new administrative functions. When developers compete to supply such
software systems, they are asked to conform to government-approved
standards. One of those standards is known as PRINCE, which stands for
‘PRojects IN Controlled Environments’ and relates to the management of
projects and the quality of the developed software.
Commonly, developers must be able to show that their development process
conforms to the regulations set out in PRINCE. In addition, developers may
be required to adopt an approved process for their analysis and design
activities. The most common of these for use with PRINCE is known as the
structured software analysis and design methodology (SSADM).
Example 11
In certain financial areas, being first to offer some new service is the way to
make the most profit. In other words, time-to-market is critical because if you
miss out your competitor takes the spoils. When there is a need for a software
system to support such a service, development is almost a race against time.
Every aspect of the development process has to be tuned to meet the time-to-
market.
So the aim is to do the simplest things needed that could possibly work when
delivered. It also means that communication overheads must be minimised, so
there will be few developers (say, two) who work to a minimal set of agreed
37
procedures. Also, if the amount of actual code produced is small, the chance
of introducing errors is reduced.
Of course, there must still be testing to ensure that the software performs its
intended purpose, but if the complexity of the software is also minimal, there
will be fewer tests to do.
Examples 10 and 11 show that there is no single development process that is

appropriate to all kinds of software product. The amount of information
recorded during development may be different in the two examples.
Example 10 illustrates the need for a formal development process. Although it
is a slow and deliberate course of action, the resultant software system must
be able to deal with all the nuances of the legislation. The developers must be
able to show that each aspect of the legislation has been incorporated into the
Software configuration final software system. The control and maintenance of the integrity of a
management is the discipline of project’s deliverables (ensuring that they do not become corrupted or
managing and controlling change inconsistent) is the responsibility of the configuration management activity,
in the evolution of software
systems (IEEE, 1990, p. 20).
which is related to the need for integration.
In contrast, Example 11 relates to software that is required for a specialised
purpose with a minimal development time. The developers have the benefit of
a narrow scope for the software system, and the short development time
means that it is unlikely that the users will request many changes, further
reducing the demands on development.
In general, the size of a project influences the choice of development process.
As illustrated in Example 11, the amount of formality in the process can be
minimal. Small teams of up to 10 people can communicate and respond to
changes informally.
In larger projects, such as in Example 10, a well-defined procedure for
controlled development is necessary – an informal communication network on
its own is not enough. One approach to the solution of the problem of large
projects is to split the group into smaller teams according to the
responsibilities set out in a given development process. Just as modularisation
is the way to deal with the complexity of a software system, developers can
be assigned different activities and deliverables within a given project. This
partitioning allows developers to specialise and become analysts, designers,
programmers and so on.
Agile development encourages collaborative development to reduce the
problems of communication that can arise in large projects. XP promotes pair
programming where the code is written by pairs of programmers to encourage
communication, feedback, encouragement (Beck, 2004), and in Scrum the
daily scrum meeting promotes team awareness, with every member of the
team knowing what others are doing. In Example 11, developers may opt for
an agile approach with pair programming, as in XP, and quickly deliver an
initial version that is then updated on short iteration cycles.
At some point, a software system will have outlived its usefulness. The
developers should consider the expected lifetime of the prospective software
when they assess the risks of producing a successful product. In Example 11,
38
the time-to-market is a significant factor, but the expected lifetime is likely to

be short because of the nature of financial markets. So a slow and deliberate
development process is inappropriate.
Dealing with risk

A software solution to a problem needs to be considered in the broad context
of the domain to allow you to manage the risks associated with a development
project. For example, if delays cause the team in Example 11 to miss the
market ‘window’, it does not matter how much software has been developed,
because it is no longer of benefit to the customer and users. Assessing risks
and taking steps to reduce them are important activities in software
development – this is known as risk management.
In a typical project, the major risks are around the requirements. Do you
understand them? Have you got them all? Are they changing too frequently?
Anything that you can do to increase your confidence that the requirements
you have are both necessary and sufficient can reduce the risk of project
failure. In general, for every decision you make there is a risk that your
decision is wrong, or at least inappropriate, and you should consider
identifying and reviewing major decisions. If the risks cannot be overcome,
the project is unlikely to succeed.
An agile approach takes the view that requirements will change during
development, and therefore they should be under continuous review. By
involving customers throughout development it is easier to address changes in
requirements and reduce the risk of making the wrong decision.
In any project there is likely to be a trade-off between what can be delivered
in a given time to a specified budget and the functionality of the software
system. Often the number of desirable features of a solution exceeds those that
can be delivered for a given price and within a given timescale, so choices
have to be made. One way to make such choices is to estimate the risk of not
delivering each feature. That is, if a feature were not to appear in the final
product, what effect would this have on such things as the usability,
usefulness, reliability and flexibility of the product?
Figure 8 illustrates a simple spiral process that deals with risk explicitly and
can be used in the development of a software system. There are four steps that There are many interpretations
are repeated with each iteration of the spiral: and variations upon Barry
Boehm’s original spiral
. determine the objectives, the alternatives and the constraints (Boehm, 1986).
. evaluate the objectives and identify and resolve the associated risks
. develop and verify a (partial) solution or product
. review that solution, and plan the activities for the next iteration.
39
determine the objectives, the evaluate the objectives;

alternatives and the constraints identify and resolve the
associated risks
review that solution and plan develop and verify a (partial)

the activities for the next iteration solution or product
Figure 8 Spiral process to deal with risk
The spiral process starts when it is recognised that a particular organisational

process can be improved or supported with the aid of a software system. The
distance from the origin is intended to show how many resources have been
used, the cumulative cost of a project.
There is no need for a complete solution to be produced by the end of the first
iteration of the spiral. For example, the first iteration could focus on the
question ‘Can we build an acceptable software system with the resources that
can be brought to bear?’ After each iteration of the spiral, new risks come to
light and plans are made for the next iteration in order to resolve those risks.
With successive progressions, you should reach a point where your review
indicates that you have an acceptable solution – a software system that meets
the needs of its users.
Agile development follows, loosely speaking, a spiral approach and has
mitigation of risks as an important concern. There are however some
indicators that would distinguish an agile process from the generic spiral
model. In agile development the short timeboxed iterations, for example,
result in partially working systems, and an iteration would, typically, be no
longer than 1 month.
Such a risk-driven model is also helpful when developing large software
systems or systems where the developers have little experience of the problem
domain. In both cases there is a high risk of failure. For example, if you have
never built a realtime system, you need to gain some understanding of the
scheduled execution of tasks.
40
SAQ 10
(a) Why might a software development company specialise in a certain

kind of customer, such as those in banking or health care?
(b) In which of the activities in Figure 5 would you expect to do your
configuration management during a project?
(c) Why are there additional risks when developing large projects?
(d) What is added to a development process with the introduction of risk
management?
Answer
(a) Through specialisation, a software development company can foster

experience in a given domain, whether it is banking, health care or
any other field of interest. The developers in that company would
have (or would hope to gain) sufficient knowledge to understand the
problems raised by the users and therefore be able to present
solutions in a form that can be understood by those users. In
addition, the company may develop and use a consistent
development process that is appropriate to the set of customers in
that domain.
(b) Maintenance deals with change. Configuration management is the
discipline of managing and controlling change, and so you would
expect maintenance to be where you would perform many of the
configuration tasks. However there is a role for configuration
management during the development process in, for example,
ensuring the consistency of models. Quality management is the
activity in which you would perform these tasks.
(c) The chances of failure increase as the size of a software project
increases, as more errors are likely to be introduced. Effective
communication between the members of a large team also becomes
more difficult.
(d) The most important additional aspect is the use of the identification,
evaluation and reviewing of risks that are carried out with each
iteration of the development. These steps introduce feedback into the
process to help ensure that the deliverables at each stage are leading
in a timely manner towards the correct product, and risks are
controlled.
3.4 Traceability
The need for a software system often comes from a set of potential users, who
may not be employed in the same company as the developers of the software
system. Initially developers must find out about the users’ domain and express Sometimes software development
their understanding of the problem in a form that is appropriate for the has no clearly identified customer
proposed development process. other than the developer.
Software is developed hoping
If a plan-driven process is followed, early in the process developers produce a that someone will buy it.
requirements specification document that identifies what the proposed software
system should do and the environment in which it must work. It relates what
41
the users want to what the developers aim to provide. This implies that there
is a need to record more than just the requirements. It allows for the tracing of
the history of each requirement from its origin in the problem domain,
through the various intermediate activities, so that it is possible to reconstruct
the significant events that led to the final operational software system.
The ability to trace the history of each requirement is known as traceability.
Among other things, traceability is essential for dispute resolution (knowing
what was agreed during a project), for seeing the effect later in the project of
changing or deleting requirements, and for demonstrating that you have dealt
with each requirement. The chosen development process will determine which
events can be reconstructed and hence determine the level of traceability. It is
important to recognise that the amount of documentation should be
commensurate with the desired level of traceability – neither too much nor too
little.
Agile approaches are sometimes identified with the demise of documentation.
The agile manifesto contrasts working software with comprehensive
documentation and agility has emerged as a reaction to heavy documentation
as required in rigorous management methods (such as the capability maturity
model).
However agile approaches take a pragmatic approach to documentation and
traceability (see Example 12). They emphasise the balance between the
amount of documentation and the pay-off it brings. Heavy documentation is
difficult to keep updated and is sometimes never used. Agile documentation
should be simple to understand, have a well-defined purpose and should
maximise the pay-off of the effort that is put into it. The involvement of
stakeholders in an agile project will help determine the amount of
documentation required.
Example 12
An agile project has documentation in the form of user stories and tests. A
user story describes some functionality required by a user, while a test is an
executable form of a user story and therefore directly related to it. Tests are
written before coding and are also directly related to the code produced.
Changes over time can therefore be tracked through with the help of a tool
that manages source code, and traceability can be preserved.
On a given project, there may be a number of deliverable documents that

record your activities. You should treat your documents as part of the
explanation of what is done. When you write down what you know about a
problem, it helps to clarify your understanding of that problem and helps you
to communicate with others and share the same mental model. Furthermore,
writing and drawing helps you to explore the problem and the potential
solutions.
Remember that the program code is a necessary but not a sufficient
deliverable if there is a need to understand decisions taken. Documentation
adds to your explanation, which we will expand upon as you study the rest of
the module. However the main purpose of software development is to produce
42
quality software and documentation should serve that purpose. The approach
taken to software development, the problem being addressed, contractual
obligations and other factors will determine how much to document and what
to document.
Keeping a project notebook is a disciplined approach to organising your
thoughts and actions as a software developer. Your project notebook is a
record of notes, thoughts, drawings, ideas and decisions (and the reasons for
taking those decisions) as you work on a project. In its simplest form a
project notebook will be paper based, but it could be recorded in files on a
personal computer.
For it to be effective, you should keep your project notebook with you at all
times, so that you can use it, save it and review it. There is no limit to what
you can record in the notebook. For example, you can note down what your
users say about their needs, make some preliminary sketches of models or
even record telephone numbers and URIs that may be useful while at work.
Whatever you record, you should date-stamp your notes, and review them on
a regular basis to ensure that your questions have been addressed and that you
have extracted the information that is useful on a given project. You must
keep accurate dates and times for the information recorded in your notebook
for the following three reasons (all of which relate to traceability):
. your project notebook may be required as evidence in some enquiry or
even in a court of law
. it helps you to review what you have done and how long you took to do
some task
. it facilitates learning.
SAQ 11
(a) Why is traceability important to the development of software?

(b) How does documentation contribute to traceability within a
development project?
(c) Which activity or activities in the development process (shown in
Figure 5) are most affected by poor documentation?
(d) For what kind of software system might you minimise or even avoid
any documentation?
(e) How would you characterise agile documentation?
(f) Why is it important to review the contents of your project notebook?
Answer
(a) Traceability is important for the reconstruction of significant events.

In software development it should be possible to follow all the
activities undertaken in response to a proposed change. In particular,
you should be able to trace backwards from an implemented
component or components, through their design, to a given
requirement.
(b) Within a development project, documentation records the progress
from requirements to implementation (and beyond). It is possible to
43
identify each requirement and follow the actions taken to implement

a solution to that requirement. You might, quite simply, be required
to show that you have implemented each requirement correctly.
(c) All seven activities will be affected by poor documentation. The
maintenance and quality management activities will be most affected
because they rely on the existence of traceability within the outputs
of a development activity. (You saw this problem earlier when we
looked at legacy systems.)
(d) If a proposed software system is likely to have a short lifetime and
will be discarded after use, it may be acceptable to minimise or
avoid the task of documentation.
(e) Agile documentation should be gathered with a purpose, should be
easy to use and above all should justify the effort put into gathering
it. There is no reason why this shouldn’t apply to any kind of
documentation but often software development produces heavy
documentation that is rarely used.
(f) The act of reviewing your notes helps you to identify what worked
and what did not, as long as the notebook records accurately what
you did and when. A review helps you to trace the events that led to
the decisions you made since your previous review. Regularly
reviewing your notes also enables you to check that you have
followed up on all the decisions that you made.
Exercise 1
What are the main problems associated with the development of software?
You should be able to identify at least six.
Solution
Here is our list of problems that affect software development (you may have
identified others):
. difficulty in capturing all the user requirements
. difficulties in managing and developing large and complex systems
. not meeting users’ requirements and avoiding dissatisfaction with the
completed software
. continual changes in user requirements (often referred to as requirements
creep)
. maintaining poorly documented software
. the presence of errors introduced unknowingly during development
. a changing world leading to changes in the needs of the users and
decreasing the usefulness of the software
. low productivity of those developing software, and difficulties in
measuring that productivity
. ensuring the quality of a software system.
44
Exercise 2
(a) How do you think a large-scale project differs from a small-scale project
in terms of the management of the development team?
(b) What management steps might be taken to tackle the problems that arise
in a large-scale project?
Solution
(a) As the size of a project increases, so does the number of people involved,
and consequently the complexity of the interactions involved, and the
difficulty of managing the team. As with programs, the greater the
complexity of interaction, the greater the chance of errors occurring due to
poor communication.
(b) One of the functions of software project management is to manage project
complexity. One way to achieve this aim is to modularise project teams by
splitting them up into a number of groups. Each group performs a specific
task and communicates with the other groups through one person (for
example, the head of the group). Another way, encouraged by an agile
approach to development, is to encourage practices of communication and
cooperation in development, such as working in pairs and having daily
short meetings.
Exercise 3
Process models sometimes show only the software-creation activities and
exclude software maintenance. What problems are associated with the use of
such models?
Solution
If maintenance is not mentioned, it is likely that it will not be considered to
be an integral part of the overall software process model. This may result in a
design that does not take the needs of maintenance into account, and hence a
product that is difficult and expensive to change. This is especially likely if
time and/or budget are already tight.
Exercise 4
What kinds of software system would be best suited to an iterative and
incremental development process?
Solution
Software systems where the problem can grow incrementally or where it falls
naturally into partitions, each of which represents a fairly self-contained unit
that could be developed and delivered on its own to provide the users with a
useful chunk of functionality, would be well suited to this model. An iterative
and incremental approach allows several design issues to be tackled
simultaneously and enables the system to be implemented in relatively small
steps in order to contain the complexity. Of course, this assumes that the
design can be partitioned.
45
Exercise 5
Figure 8 shows a spiral process for software development. Into which
quadrant of that figure does each of the seven technical activities of Figure 5
fit? Notice that there is not a one-to-one match.
Solution
The analysis, design, implementation and testing activities all fit into the
‘develop and verify a (partial) solution or product’ segment. The analysis
activity also overlaps the evaluation quadrant where objectives and risks are
analysed. The testing activity overlaps the ‘review and plan’ quadrant. The
maintenance, project management and quality management activities
(including configuration management) operate in all four quadrants.
Exercise 6
It has been said that ‘the maintenance activity begins with the first deliverable
of a development project’. What does this imply about the maintenance
activity?
Solution
This refers to the fact that there could be deliverables, such as requirements
documents, that exist prior to any software being built, and these also require
maintenance. For example, you might detect errors or inconsistencies in a
document that lists the important terms in your users’ domain, or you might
have to respond to changes in the environment, which may be due to new
regulations or market forces.

This section considered how you might approach the development of a good
software system as follows.
. Large software projects are prone to problems because of their size and
complexity.
. Software is inherently easy to change, and this makes it easy to introduce
new errors (‘break’ it).
. Software development is similar to engineering when it involves a defined
process with clear activities, each of which has one or more products that
can be tested against the users’ requirements.
. A basic process for the development of software is a set of rules that
define how a software development project should be carried out. It
incorporates a number of activities, and a life cycle (or process model) that
indicates how these activities are ordered. It helps to coordinate and
control the use of those methods and any tools that support them.
. Process models can be sequential, iterative, incremental or some
combination of these.
. A disciplined approach to software development implies that you must
make some effort to record your activities from both a personal view and a
project view. It means that documentation is an important task for all those
46
who work on a project. In particular, it must be sufficient for the level of

traceability required.
. An agile approach to software development puts an emphasis on people
rather than on process or documentation, on short iterations and quickly
working software, and on the acceptance that systems change. It also
encourages practices that promote cooperative work in software
development.
47
4 Modelling in software development

In this section we will consider the importance of models as part of software
development, present a popular software development process and introduce
the software development process followed in this module.
4.1 Importance of modelling

Much of this module is concerned with modelling in general and the
techniques to represent models in particular. Modelling is a way of thinking
about things and ideas in the ‘real world’. A model is an abstract
representation of a situation in reality, or of a system from a particular point
of view. In effect a model is a way of expressing a particular view of an
identifiable system of some kind.
In terms of the development of software systems, models are:
. a way of understanding the problems involved
. an aid to communication among those involved, especially between the
developer and the user, as part of some deliverable
. a component of the processes used in development activities such as
analysis and design.
A good model is an abstraction, which allows those involved to concentrate
on the essentials of a (complex) problem by keeping out non-essential details.
In Section 2, you saw that there is a limit to how much a person can
understand at any one time. So we build models to help us in activities such
as the development of software systems. For example, developers build
different models at different stages during the development process in order to
confirm that the eventual software system will meet the users’ requirements.
Models contain a representation of the significant states, objects and events in
a real-world situation or within a software system. In one respect models are
an idealisation, because they are less complicated than reality, and so they are
easier to use for software development. The benefit arises from the fact that
only the relevant properties of the outside world are represented. For example,
a road map is a model of a particular part of the earth’s surface. We do not
show things like birds’ nests as they are not relevant to the map’s purpose. We
use a road map to plan our journeys from one place to another, and so the
map should contain only those aspects of the real world that serve the purpose
of planning journeys.
When we model, we are trying to show or reveal what something is like.
Models can do more than this because they can help us explain the past and
the present (the problem), and they can help us predict and control the future
(the solution – a software system). However remember that the model and the
real world are alike in some ways, but different in others. For example, road
maps are helpful because they represent distances between (and relative
positions of) places, as well as routes between them. They use the relevant
properties of the real thing with just a change in scale – one centimetre on the
48
road map, for instance, may be equivalent to one kilometre on the ground.
They may however be unhelpful if they show only major roads.
We can also use one property in a model to represent another in the real
world. In the case of the road map, we can use different colours to represent
different classes or types of road. Such a road map should have a key or
legend so that those who read the map can understand what the different
coloured lines are intended to represent. On a road map, a blue line might
represent a motorway, and a yellow line a narrow track.
Models of a problem situation are only an approximate representation of that
situation. The real-world situation is normally complex – so much so that an
exact representation is likely to be impossible to achieve. The problem
therefore confronting a developer is to find some way of achieving an
acceptable balance between completeness and manageability. In a software
development project, there will be a number of practical considerations that
result in some compromise in completeness.
If the constructed model is so complex that the developer (or other team
members) cannot use it, it is of little or no value. So the model must simplify
the reality a good deal. However the developer should make explicit all
simplifying assumptions for a given model, as well as their consequences. At
some point in a development project, any of these assumptions may need to
be justified.
Models are subject to change. At the very least, they require some form of
periodic testing so that a model can maintain its correspondence with reality.
As towns and cities expand and contract, a road map must be changed to
reflect the new situation. In the worst case, a change in scope necessitates a
whole new model. For example, if there were a need to reflect the current
status of roads and the traffic density on them, a simple road map would be
inadequate.
Agile modelling
Agile modelling is Scott Ambler’s approach to lighter modelling
(Ambler, 2002). It proposes a set of values, principles and practices to help
software developers become agile modellers. These are mostly common sense
but reinforce the alignment of modelling with an agile approach. Modelling
should not be seen as a routine exercise that has to be done independently of
how models are going to be used. Models should only be done with a purpose
and up to the point where they stop being useful. There is no justification in
spending too much time in getting a model right (consistent, complete,
accurate) if the only aim is to communicate an overview of the structure that
is in the developer’s mind. A typical activity of an agile modeller is to stand
up with others in front of a whiteboard, sketch a few models, discuss these
sketches, and then discard them if they serve no further need.
In this module you will learn about different modelling techniques and how to
use them. You will practice by applying them to a case study in a systematic
way. But you will also be reflecting on how an agile approach can be taken to
modelling.
49
It requires practice to be able to pick, choose and adapt the modelling

techniques that best suit a real situation. But that is often what happens in
practice and many software organisations adapt development processes to their
needs rather than using them as mandated. However there are also situations
when it is not easy to assess how much effort should be put into a
development activity, and in that case it is worth carrying modelling through
in a systematic way to achieve a more complete view.
There are also tools to help in the creation of models from existing software.
They can be used to document a piece of code that has not been modelled
throughout development.
A standard notation
In developing a software system, a developer will not just use a single ‘catch
all’ model – a set of related models is more likely. It would be preferable to
have a consistent way of representing each of the different models for a given
software system. A modelling language allows the developer to make useful
connections between those different models. In software development, a
modelling language is often based on diagrams and their construction,
meaning and use. There are two sets of rules within a diagram-based
modelling language:
. one that determines what diagrams exist and what symbols are used on
each one – its syntax
. one that determines what the diagrams and symbols mean – its semantics.
What should you look for when choosing a modelling language? On any
given development project there are decisions to be made about every model.
You should favour a modelling language that:
. allows you to express the many facets of the subject of your model
. helps you to resolve misunderstandings rather than introducing new ones
. is easy to learn and use – you want to make progress quickly
. is supported by tools that allow you to use your modelling skills rather
than your drawing skills
. is widely used and is accepted within the industry.
It is advantageous if a modelling language is widely used. If you leave one
team of developers and join another that uses the same modelling language,
you need only learn about the new problem situation. The advantage is
amplified if you move to a new team in a new company. Naturally, the team
that you join will expect you to be more productive than you would be if you
had to learn a completely new modelling language.
Unified Modeling Language (UML) is now accepted as the standard object-
oriented modelling language. It is intended to be a general-purpose language
for software development. It is not meant to be a complete language for
modelling all aspects of all systems.
Its success is partly due to its separation from any particular method. It is
available for anyone to include in their own method for software development.
50
The Object Management Group (OMG), an industry consortium for modelling

and integration standards, has adopted UML and is the main body responsible
for its development.
UML is predominantly diagrammatic, but does allow developers to add text in
appropriate places.
SAQ 12
(a) What is a model?

(b) What is a ‘good model’?
(c) What are the two kinds of rule that govern the use of a modelling
language?
(d) Does a modelling language need to be associated with a particular
development process?
(e) What are the required characteristics of a standard modelling
language?
(f) How does a standard modelling language contribute to software
development?
Answer
(a) A model, in terms of software development, is an abstract

representation of a specification, a design or a system, from a
particular point of view. In general, it is a simplification of reality,
created in order to understand an aspect or viewpoint of the system
in question.
(b) A ‘good model’ is an abstraction that allows those involved to
concentrate on the essentials of a complex problem by excluding
non-essential details while capturing those of interest.
(c) A modelling language is normally diagrammatic, although it can be
textual. In common with natural language, there are two distinct
kinds of rule:
◦ those that determine whether or not a diagram is legal – the
syntax of a diagram
◦ those that define what a legal diagram means – the semantics
of a diagram.
(d) No, a modelling language does not dictate how it should be used and
it is up to a development process to define which notations are
appropriate and how they should be used. With experience
practitioners tend to pick and mix from different modelling languages
and use the notations that are most appropriate to the task – most
modelling languages do not provide notations for all types of tasks.
(e) When choosing a modelling language, it should be:
◦ sufficiently expressive
◦ easy to learn and use
◦ unambiguous
◦ widely used
◦ supported by suitable tools.
51
(f) A standard modelling language helps when new people join a project
– a common modelling language reduces the time needed to enable
them to become productive team members. Also, when a modelling
language is widely used, it is likely that project components will
have been constructed using that language. This makes the software
easier and cheaper to maintain.
4.2 Models illustrate points of view

To understand the architecture of a software system, you will need a number
of complementary and related views. If the main influence is the users, a view
that expresses their requirements is essential. This is quite normal. Every
development process you will encounter will encompass one or more views of
the software systems within its scope.
During software development, you will be interested in different aspects or
views of the problem, and its solution at different times. It follows that you
will construct different models to suit those aspects. As mentioned above, it is
unrealistic to expect to put everything into just one model. Too much detail in
a model can only be a distraction.
When it comes to the development of an object-oriented software system,
there are two distinct kinds of model:
. structural (or static) models, which describe the objects in the real world
or in a (software) system and their relationships to other objects
. behaviour (or dynamic) models, which describe the behaviour in the real
world or of a (software) system over time.
In practice, such a simple partition of a software system is not enough. For
example, in a distributed system a developer must also consider the potential
location of the modules (or classes). So the overall process of software
development takes a number of different views into account. When developing
the software architecture you will be identifying the differing views. In
practice, the developers are likely to produce a system architecture for the
software system during certain project activities such as analysis or design.
Each view can be thought of as a model that expresses a particular aspect of
the overall system – each one is an abstraction. The views interact with each
other – this will become evident as you continue this module.
SAQ 13
(a) Should you try to capture everything about a design in a single

model?
(b) What is the difference between a structural and a behaviour model?
(c) Do the models used in a given development project need to be
consistent?
52
Answer
(a) No, because you will be interested in different aspects of a design at

different times, and different models of your design will be built to
reflect your interpretations of users’ needs.
(b) A structural model describes the elements of the system and their
relationships to other elements. A behaviour model describes the
behaviour of a system over a period of time.
(c) Yes, the whole set of diagrams should contain the different aspects of
a single software system, so they should not contradict one another.
For example, there must be some consistency checking between the
static and dynamic models. This can be automated by a suitable tool.
4.3 Introducing the Unified Process

The Unified Process (UP) (Jacobson et al, 1999) has emerged as a popular
iterative and incremental development process for building enterprise systems
based on an object-oriented approach, and using UML. It promotes a set of
best practices, namely that development should be organised in short
timeboxed iterations and that it should be adaptive to accommodate inevitable
change. A commercial version of the UP, the Rational Unified Process (RUP)
(Krutchen, 1999), is its most well-known implementation although there are
many others around. RUP was developed by Rational, which was acquired by
IBM in 2003. We will, from here onwards, be talking about the UP but the
characteristics of the process that are mentioned are also present in the RUP.
Timeboxing means that a (usually) short fixed period – for example, three to
four weeks – is devoted to each iteration. Consequently, at each iteration only
a small set of requirements is considered and progressed to the
implementation and testing stages. Each iteration results in a working but
possibly not yet complete system that normally delivers an increment of
functionality on the previous incomplete system. Typically many iterations
with progressive integration of increments are required before the product can
be delivered.
Being adaptive means that adjustments are allowed at each iteration. The
motivation for this is the recognition that requirements may change throughout
development, and that such changes should be welcome rather than resisted.
By involving customers and users at each iteration, feedback can be gained
quickly and the required adjustments made within the next iteration. So each
iteration may provide an increment over the previous one, or simply revisit its
output.
Other best practices promoted by UP are:
. dealing with high-risk issues in early iterations
. prioritising the user’s perspective by involving users in requirements,
evaluation and feedback
. building a view of the system’s architecture in early iterations.
53
A UP project is organised into four major phases:

1 Inception. The business case is developed, together with an idea of the
scope of the system and a rough estimate of the effort required.
2 Elaboration. The core of the system is developed in an iterative fashion.
In this phase all major risks are addressed and resolved, most of the
requirements are identified and dealt with, and a more realistic estimate of
the effort required is made.
3 Construction. The final product is constructed, including the remaining
lower-risk and easier elements of the system, again in an iterative fashion.
4 Transition. This includes beta testing and deploying the system.
Within the UP phases, development work is organised within many
disciplines, the UP term for development activities such as requirements,
analysis, design and testing. An example of disciplines and their relationship
to UP phases is shown in Figure 9.
UP phases
inception elaboration construction transition
business modelling
requirements
analysis and design
implementation
testing
project management
deployment
UP disciplines iterations
Figure 9 UP phases and disciplines
The figure illustrates what a UP project might look like. The columns
represent iterations. For each discipline, the relative effort is represented
throughout the UP phases and their iterations. For instance, most of the
domain modelling (referred to as business modelling in the UP) occurs in the
early iterations of the inception and elaboration phases, while most of the
implementation occurs within the construction phase.
54
Views in the UP
The UP was developed by the same people who originally specified UML and
UML is its modelling language. A system’s architecture includes models that
address five different views:
. The use case view contains the basic scenarios that describe the users and
the tasks that they need to perform with the aid of a software system.
These scenarios are partitioned into use cases, which we will describe in
Unit 3.
. The logical view is concerned with the functional requirements of the
software system. What should the software do for its intended users?
Typically this involves the construction models that represent the main
elements of a system and how they interact. We will discuss these models
from Block 2 Unit 5 onwards.
. The implementation view is concerned with the organisation of the code
modules that comprise a software system. Typically it addresses the
management of source code, data files and executables.
. The deployment view is concerned with the relationship between the
various executables (and other run-time components) and their intended
computer systems. We will touch briefly on implementation and
deployment in Block 3 Unit 12.
. The process view is concerned with aspects of concurrency. What are the
processes and threads? How do they interact? It deals with such things as
response time, deadlock and fault tolerance. Concurrency is outside the
scope of this module.
Figure 10 shows that the central use case view relates to the other four views.
logical deployment
view view
use case view
process implementation
view view
Figure 10 Five views of a software system’s architecture
Agile UP
The UP was never intended to be a heavy process and some of its practices
are also promoted by agile developers, notably iterative and incremental
development, timeboxing, dealing with requirements change and being itself
an adaptive process. It is possible to apply the UP in an agile manner and it is
often the context in which it is used – the will and experience of developers
will dictate whether an agile development takes place.
55
4.4 Activities and artefacts in the development

process
The approach we take to developing a case study is loosely based on the UP,
with a focus on the elaboration phase and the disciplines of domain
modelling, requirements, analysis and design, implementation and testing. We
will be focusing mostly on the use case and the logical views.
The techniques used in the module are not specific to the UP – they can be
used in many iterative and incremental processes based on an object-oriented
approach to software.
Here, we identify the core activities we will use in this module to develop
software. This will give you an initial understanding of how the activities you
will learn about contribute to the overall development process. As mentioned
earlier, different ways of subdividing the development process and different
terminology may be used elsewhere.
Our core activities follow the UP disciplines:
. domain modelling – modelling what already exists in the domain
. requirements – identifying, categorising, prioritising and modelling what
the system must do
. analysis – modelling how the structure and behaviour of the system will
meet its specification from a user’s perspective, moving from the domain
to a software solution
. design – deciding on the distribution of responsibilities to fulfil that
specification
. implementation – producing code that will meet the user requirements
. testing – ensuring that the software does meet its requirements
. deployment – configuring the code to give a runnable system.
It therefore makes sense to talk of models corresponding to each of these
activities. So we have a domain model, a requirements model, an analysis
model and so on. However these models generally need to cover a number of
views of the system. For example in the previous subsection we talked about
structural and behaviour models. A domain model, for example, will usually
include both of these. A design model typically consists of a number of more
specific models.
There will be other documents that accompany the models, and so we will use
the term artefact to refer to both models and other documents. The artefacts
from the activities earlier in the list above feed into the activities that follow.
Domain modelling
Our starting point will be to document and model the structure and processes
of the organisation’s business. Starting from some description of the problem,
the initial problem statement, you will learn how to identify elements of the
real-world problem and their properties, and build corresponding structural
56
and dynamic models. The emphasis at this stage is on understanding the

current domain situation.
The behaviour model provides descriptions of business processes and
behavioural aspects of the domain. You will meet modelling techniques such
as activity diagrams. Business rules are used to express constraints on the
dynamic model. For example, given a behaviour model describing aspects of a
library, there might be a business rule determining the limit on the number of
books an individual member can borrow. A structural domain model, also
called the conceptual model, describes the significant concepts in the domain
and how they are related.
A glossary of relevant terms and definitions is also produced. This textual
document grows throughout the duration of the project.
Some artefacts involved in domain modelling (as well as some used in other
phases) are shown in Figure 11.
57
glossary problem business domain structural model

statement processes – conceptual classes and
identifier and name
industry copy
of rules
associations
initiator
– conceptual attributes
goal industry copy
of rules
industry copy
of rules
– no operations or interfaces
domain pre-condition business as yet
modelling post-condition industry copy
rules
of rules
*
*
industry copy
of rules
glossary problem use case elaborated use functional and non-

statement model cases functional software
identifier and Name
requirements
make a reservation
identifier and Name
requirements initiator
cancel a reservation initiator
SF12: UC_1, Step 7
goal description: the system shall assign a unique number for a reservation
goal
check-in guest
pre-condition
pre-condition
receptionist
post-condition check-out guest
post-condition
glossary system operations analysis structural model

– analysis classes
context
identifier and Name
pre: ... – constraints
initiator
post: ... –
goal
analysis
pre-condition
*
*
post-condition
glossary behaviour model design structural model

(interaction diagrams) – navigability
identifier and Name
– qualified associations
initiator
– class operations
design goal
–
pre-condition
post-condition
*
Figure 11 Some development artefacts
SAQ 14
(a) What is the purpose of domain modelling?
58
(b) What is the role of each of the artefacts produced during domain
modelling?
Answer
(a) Domain modelling is concerned with gaining an understanding of the

environment in which any system that is designed must operate.
(b) During domain modelling, we produce the following artefacts:
◦ initial problem statement – a description of the problem
◦ behaviour model – a description of the business processes
and behaviour of the domain
◦ business rules – constraints on the way the behaviour model
operates
◦ glossary – definitions of relevant terms
◦ structural domain model – an initial structural model
representing the concepts relevant to the domain.
Requirements
The next step is to gather and document the requirements for your system and
to model what the system is intended to do. Requirements are the expression
of the things the system must do or the qualities the system must have in
order to meet the stakeholders’ needs. Starting from some description of the
problem, you will learn how to systematically record requirements
information.
Unit 2 discusses requirements, how they are recorded and the properties we
expect them to have. In particular, you will be shown how to use the Volere
template, which provides a disciplined way of recording requirements. We
model requirements at various levels of detail, using use case models, use
cases elaborated as text and detailed software requirements stating what the
system should do.
Some artefacts involved in requirements are shown in Figure 11.
SAQ 15
What is the purpose of the requirements phase?

Answer
The requirements phase is concerned with establishing and modelling what

a software system must do.
Analysis
During analysis, with both use cases and software requirements, you start
looking at a system to be implemented, and build both structural and
behaviour models. The structural model evolves from that of the domain – it
no longer represents concepts from the domain, but rather entities in a
59
software solution. This is usually called the analysis model. Use cases and
software requirements lead to the specification of what is expected from the
system from the user perspective. The system operations show how this
behaviour can be carried out by the entities chosen.
It is at this stage also that architectural decisions are taken in terms of the
overall structure of the system.
Some artefacts involved in analysis are shown in Figure 11.
Design
During design, your goal will be to decide how the expected functionality is
to be allocated to each part of the system. You need to make choices about
which classes the system operations should be allocated to. These decisions
can be explored and documented using further behaviour models. UML uses
interaction (sequence and communication) diagrams that show a set of
classes and the messages between them.
During design both structural and behaviour models are elaborated. In fact
you will see that behaviour models are used for both external and internal
behaviour of objects.
Some artefacts involved in design are shown in Figure 11.
SAQ 16
(a) What is the purpose of analysis?

(b) What is the purpose of design?
(c) What is the role of each of the artefacts produced during design?
Answer
(a) Analysis starts modelling the structure and behaviour of a software

solution from a user’s perspective.
(b) Design is concerned with making decisions concerning how a system
will meet its specification.
(c) During design you produce the following artefacts:
◦ structural model, an updated version of the one produced
during analysis but with its operations specified
◦ behavioural models, showing how objects in the system will
interact and behave internally, and also how functionality will
be distributed across the system.
Implementation
The implementation model is a description of the assembled components that
comprise the working version of the software. It describes how classes are
packaged together, and shows some of the relationships between such
packages of classes. These relationships are modelled using a component
diagram.
60
Testing
The implementation needs to be tested against its requirements to ensure that
it meets them. Tests will be drawn up based on the requirements, and held in
a test document. Notice therefore that tests can be drawn up as soon as you
know the requirements.
In fact there is a trend towards test-driven design. In this approach, the tests
for a system are drawn up before design and automated testing procedures are
set up. An initially empty implementation can be run against the tests and the
subsequent failure can be used to drive design. As time goes on, this process
is repeated as the implementation is built up, until no tests fail. This is the
approach followed by some agile approaches such as XP. In this module you
will see how you can start thinking about testing from early on in
development.
Deployment
Many significant computer systems will consist of a variety of software
components located on a number of machines communicating via a variety of
hardware and software mechanisms. A deployment model records how various
components are to be mapped onto different machines and how they will
communicate. This can be represented using a deployment diagram.
Exercise 7
Suppose you and a colleague used UML on a particular development project.
What would be the consequences of introducing symbols or notations that
were not defined in UML?
Solution
Such an extension would incur costs as well as offering potential benefits. The
costs include the need to communicate the syntax and semantics of your new
symbols or notation to other developers. The benefits include the ability to
express concepts specific to your project that could be more meaningful in
your context.
Exercise 8
In the past, there have been many attempts to standardise modelling notations
and languages. How might the choice of modelling language affect the
maintenance of a software system?
Solution
Every time a new standard notation or language is defined, it allows new
software systems to be built using that standard. It can only help with existing
software retrospectively. For example, a developer might use the new standard
to express a proposed change to the software.
There is no guarantee that an existing software system used any modelling
language at all, let alone any agreed standard for one. Even if a standard was
used, new staff arriving on the team for the purpose of maintenance might not
know about it. Each variety of standard would affect the organisation of a
61
component library. For example, if components using a particular standard

were to be put in a library, the descriptions would be likely to require some
maintenance as that standard changes over time.

As you become more familiar with the activity of modelling, it should become
apparent that there is considerable flexibility in the construction of models.
There is no guarantee that different developers, when confronted by the same
problem, will select the same things to model, and even if they do, will
produce identical models, although there should be a great deal of similarity
in most cases.
This section considered the role of modelling in the development of a good
software system:
. A model is an abstract representation of a concept, a specification, a
design or a system from a particular point of view of either the user or the
developer. In general, it is a simplification that is used to understand an
aspect of the system in question.
. A standard modelling language helps those involved in software
development projects to communicate effectively. If the standard is widely
used, it will reduce the time taken for developers to become familiar with
a new project.
. The Unified Modeling Language (UML) is a useful standard because it is
easy to use, sufficiently expressive, unambiguous and widely used. There
are also a variety of tools that support UML.
. During software development, there may be many models made from a
variety of viewpoints. They must not contradict each other, that is, they
must be consistent.
The UP is a popular iterative and incremental development process. It defines
a series of timeboxed iterations and promotes a set of best practices that are
high-risk driven, user centred and architecture focused. It is possible to take
an agile approach to the UP as many of its practices are also supported by
agile developers. The process followed in this module will be loosely based
on the UP and we will be also discussing agile alternatives in parallel.
62
5 Summary
Summary 5
In this unit you have extended your knowledge of the important ideas in
software development. We investigated the characteristics of a good software
system, and considered what a development process would need to include to
build such software. You saw that there is no single development process to
suit the variety of users’ requirements. However there must be a disciplined
approach to software development, especially in the case of large projects.
We introduced the notion that it is good practice to split a project into smaller,
more manageable activities. When developing good software systems, you
should focus on the users’ needs and, wherever possible, make use of
replaceable and reusable modules – components. The overall software
architecture should be constructed around the users’ requirements.
We then introduced the role of modelling in the development of software. In
particular, the concepts of object orientation allow us to represent users’
requirements in a way that reflects our natural tendency to view the world
around us in terms of objects. The way we relate the various activities of
software development and associated artefacts (including models) was then
described.
Now that you have more knowledge of the software development process, you
may wish to read Section 2 again.
On completion of this unit you should be able to:
. describe the essential characteristics of a good software system
. identify, using examples, the connections between the characteristics of a
good software system
. explain why a software system can be out of date even as it is being
developed
. explain the importance of modularisation
. suggest reasons why large software projects are prone to problems and
give examples to support your case
. give examples to support the notion that software development can be
considered as an engineering discipline
. describe the elements of a basic software development process
. illustrate the variety of different life cycles by using examples
. explain the role of documentation in a software development project
. understand the motivation for, and best practices of, an agile approach to
software development
. explain why a standard modelling language is beneficial to a development
process
. explain the benefits of the Unified Modeling Language (UML) as a
standard notation for modelling
. identify the different kinds of model used in the development of software
63
. describe the relationship between models, viewpoints and software

development
. understand the relationship between activities and artefacts used in this
module.
64
References
Ambler, S. (2002) Agile Modeling: Effective Practices for Extreme
Programming and the Unified Process [Online], New York, John Wiley &
Sons. Available at http://libezproxy.open.ac.uk/login?url=http://open.eblib.com/
patron/FullRecord.aspx?p=131031 (Accessed 2 December 2013).
Bass, D.L., Clements, D.P. and Kazman, D.R. (2012) Software Architecture in
Practice [Online], 3rd edn, Upper Saddle River, NJ, Addison Wesley.
Available at http://libezproxy.open.ac.uk/login?url=http://proquestcombo.
safaribooksonline.com/book/software-engineering-and-development/
9780132942799 (Accessed 2 December 2013).
Beck, K. (2004) Extreme Programming Explained: Embrace Change [Online],
Upper Saddle River, NJ, Addison Wesley. Available at www.open.ac.uk/
libraryservices/resource/ebook:0321278658/provider/
ProQuest_Safari_Tech_Books_Online (Accessed 2 December 2013).
Boehm, B. (1988) 'A spiral model of software development and enhancement',
Computer, vol. 21, no. 5, pp. 61–72 [Online]. Available at http://ieeexplore.
ieee.org.libezproxy.open.ac.uk/xpls/abs_all.jsp?arnumber=59 (Accessed 2
December 2013).
IEEE (1990) 610.12-1990: IEEE Standard Glossary of Software Engineering
Terminology [Online], IEEE. Available at http://libezproxy.open.ac.uk/login?
url=http://ieeexplore.ieee.org/servlet/opac?punumber=2238 (Accessed 2
December 2013).
Jacobson, I., Booch, G. and Rumbaugh, J. (1999) The Unified Software
Development Process, Upper Saddle River, NJ, Addison Wesley.
Krutchen, P. (1999) The Rational Unified Process: An Introduction, Upper
Saddle River, NJ, Addison Wesley.
Larman, C. (2005) Applying UML and Patterns: An Introduction to Object-
Oriented Analysis and Design and iterative Development [Online], Pearson.
Available at http://proquestcombo.safaribooksonline.com.libezproxy.open.ac.
uk/book/software-engineering-and-development/agile-development/0131111558
(Accessed 2 December 2013).
Leveson, N. and Turner, C. (1993) ‘An investigation of the Therac-25
accidents’, Computer, July, pp. 18–41 [Online]. Available at http://ieeexplore.
ieee.org.libezproxy.open.ac.uk/stamp/stamp.jsp?
tp=&arnumber=274940&isnumber=6812 (Accessed 2 December 2013).
Lions, J. L. (1996) ARIANE 5 Flight 501 Failure, Report by the Inquiry Board
[Online]. Available at www.di.unito.it/~damiani/ariane5rep.html (Accessed 2
December 2013).
Mašek, K., Hnetynka, P. and Bureš, T. (2009) 'Bridging the component-based
and service-oriented worlds', 2009 35th Euromicro Conference on Software
Engineering and Advanced Applications, Patras, August 27–29 2009. IEEE,
pp. 47–54 [Online]. Available at http://ieeexplore.ieee.org.libezproxy.open.ac.
65
uk/stamp/stamp.jsp?tp=&arnumber=5349894&isnumber=5349835 (Accessed 2
December 2013).
National Audit Office (2012) Governance for Agile Delivery [Online].
Available at www.nao.org.uk/publications/1213/governance_for_agile_delivery.
aspx (Accessed 2 December 2013).
South West Thames Regional Health Authority (1993) Report of the Inquiry
into the London Ambulance Service [Online]. Available at www0.cs.ucl.ac.uk/
staff/a.finkelstein/las/lascase0.9.pdf (Accessed 2 December 2013).
Schwaber, K. and Sutherland, J. (2011) The Scrum Guide [Online]. Available
at www.scrum.org/Portals/0/Documents/Scrum%20Guides/Scrum_Guide.pdf
(Accessed 2 December 2013).
66
Unit 2 Requirements concepts
Contents
1 Introduction 71
2 Requirements 72
2.1 The nature of requirements 73
2.2 Requirements dependencies 74
2.3 The requirements engineering process 75
2.4 An agile perspective of requirements 77
2.5 Requirements and architecture 78
2.6 Requirements and testing 79
3 Functional requirements 82
3.1 Elicitation, analysis and negotiation 82
3.2 Describing requirements 85
4 Non-functional requirements 93
4.1 Look-and-feel requirements 94
4.2 Usability and humanity requirements 95
4.3 Performance requirements 97
4.4 Operational and environmental requirements 98
4.5 Maintainability and support requirements 98
4.6 Cultural requirements 99
4.7 Legal requirements 100
4.8 Security 101
5 Conformance testing and fit criteria 107
5.1 Examples 109
5.2 SAQs and exercises 111
6 Representing the requirements 115
6.1 The Volere template 115
6.2 An agile representation of requirements 121
7 Summary 122
References 123
1 Introduction
Introduction 1
In this unit we introduce the concepts of user and software requirements. The approach taken in this unit
We discuss the importance of documenting and managing requirements, and draws in a number of ways on
the complexity of the requirements engineering process. Sections 3 and 4 that taken in Robertson and
Robertson (2012).
define the two main classes of requirements: functional and non-functional,
and Section 5 discusses the links between requirements and testing. In
Section 6 we introduce a template for requirements documentation that is
based on a well-known method in the literature.
Unit 3 will discuss in detail the techniques used to represent and specify
requirements.
Figure 1 Dilbert does user requirements gathering
71
2 Requirements
The hardest single part of building a software system is deciding what to

build … No other part of the work so cripples the resulting system if done
wrong. No other part is more difficult to rectify later.
(Brooks, 1987)
The end product of software development is a software system whose

success will be judged by how well it meets its intended purpose. This
purpose is defined as the system’s requirements. Requirements are the
information about what a system will be and do that needs to be known
before development starts. They involve descriptions of different aspects of
the system including its behaviour, constraints on its operation and
specifications of its properties.
The process of reaching and documenting an agreed set of requirements is
known as requirements engineering. This is a complex process that involves
diverse interested parties:
. the people who are going to use the system
. those who are paying for it (the clients)
. those who are to benefit from it
. those who are developing it.
These people are called the stakeholders of the system. Stakeholders may
also include others who need to have a say in the development of the system,
for example regulatory bodies, professional associations, the general public.
Discovering who they are, finding out what they want and documenting it is
the purpose of the requirements engineering process.
Requirements engineering is an important activity in software development
and the consequences of poor or no attention to this activity are costly. Many
of the commonly cited problems with software products can be grouped in the
following categories:
. the system is delivered late and/or is more expensive than initially thought
. the system does not deliver what the end-users want
. the system is unreliable and has errors.
All these problems usually stem from a lack of understanding of the
requirements of the system to be developed and from the lack of a clear
agreement on what is to be developed. The later problems are encountered,
the more difficult they are to solve. The cost of errors made at the
requirements stage is high. Any change that needs to be made to requirements,
if detected later in the software development, will incur much higher costs
than if the change was made before design and implementation.
The Standish Group has been publishing reports on the success of software
projects since 1994. In its latest report (2012) it identified that:
72
2 Requirements
. only 39 per cent of all projects were being delivered on time, on budget,
with required features and function
. 43 per cent were late or over budget or not delivering all required features
. 18 per cent were either cancelled before delivery or delivered but never
used.
In its 2010 report the Standish Group also identified major problems and
proposed its own solutions. Among these problems were the following:
. poor, or lack of, user involvement
. lack of clear business objectives
. under and over building – building features that are never used and not
building all the required features
. lack of support for agile processes and poor support for requirements and
solutions evolving together through collaborative teamwork.
Recently some authors have criticised the way data has been gathered for
these reports and the lack of open access to the data, and have even
challenged the credibility of the reports (Eveleens and Verhoef, 2010). But
even if the reports portray a worse picture for software projects than is the
case in reality, they still point to the need for a thorough understanding of
what the requirements are and the need for supportive processes.
2.1 The nature of requirements

The specification of the requirements for a system is not an easy task:
. requirements are not usually stable and they tend to change as the
environment changes
. there are usually many stakeholders and they do not always have the same
view or priorities for the system to be developed
. it is not always clear and easy to identify what the requirements for a
system are
. there are many factors that influence what the requirements are and these
are not always explicit.
Let us consider the example of a hospital admittance service. The stakeholders
are many and with different interests (doctors, nurses, administrative staff,
patients, regulatory bodies, standardisation and professional bodies).
What is intended of the system may not be clear until specific requests have
been considered, some of which may not have occurred before. Any change in
the organisation of the hospital may affect what is intended of the system.
Therefore there has to be a consideration of which changes are likely to occur
and how they may affect the system. For example, is the division into wards
stable or might wards be split or merged over time?
Finally, it is likely that in such a large organisation there are organisational
and political factors that will influence the system but may not be clearly
stated. For example, there might be conflicts between the interests of doctors
and administrators in the way the system is used.
73
Requirements have to be carefully defined and checked for different

properties. They need to be:
. Necessary and traceable – each requirement should fulfil a purpose and it
should be clear where each requirement comes from.
. Non-ambiguous and realistic – there should be no alternative
interpretations for one requirement and it should be possible to carry each
requirement through to development.
. Complete – in a plan-driven development all the intended functionality is
described as completely as possible, although in practice it is often not
possible to be absolute about this and it is important to allow for
requirements that emerge later in the system development and during
maintenance. Agile development makes a strong argument that
requirements will emerge during development and cannot be considered
complete in advance. The level of completeness of requirements will also
depend on the system to be developed and on the development
environment.
. Consistent – requirements should not contradict each other.
. Verifiable and validated – it should be possible to check that a requirement
has been implemented, and that what is implemented corresponds to what
was intended.
Requirements should also be independent of design and implementation,
avoiding design and implementation decisions that are not relevant at this
stage. However, avoidance of all design and implementation issues is not
always practical.
The requirements for a system effectively form a contract between those
commissioning the system and the developers of the system. In order to know
whether or not that contract has been fulfilled, the requirements need to be
expressed clearly and in such a way that it is possible to tell if the system
meets them. That is, they need to be testable. While gathering requirements
the analyst may choose to defer the issue of testability, since it is a concern
that can be addressed separately. For this reason this unit defers further
consideration of testability until Section 5.
2.2 Requirements dependencies

Requirements have numerous complex and non-trivial dependencies. They
often conflict with each other when they make contradicting statements about
the system’s properties, or they cooperate when they mutually enforce the
system’s properties. For example, consider a requirement that, when executed,
makes a complex request for execution-time resources. This requirement can
interact in unexpected ways with other requirements such as performance,
security or reliability.
Or think of a mobile phone on which, because of the small screen size, only a
few lines of the text can be displayed at one time, requiring the user to scroll
up and down to view the text. Here the required portability of the mobile
phone, and therefore its small size and display area, conflicts with the
74
2 Requirements
usability of the phone. So the requirements of usability and portability cannot

both be implemented exactly as desired.
Despite well-specified requirements, many software projects are vulnerable to
failure, or don’t meet the stakeholders’ requirements. This is because
sometimes the dependencies between requirements are not investigated at the
requirements engineering stage of the software development life cycle. The
importance of this investigation of dependencies can be seen in the following
example (Boehm and In, 1996).
Example 1
In the New Jersey Department of Motor Vehicles licencing system, engineers
were faced with two conflicting goals – low development costs and rapid
development, versus the need for the system to be able to process licence
applications quickly. Unfortunately the approach they took to ensuring low
development costs and rapid development produced a system that failed
because of performance problems.
A practical approach for investigating the dependencies between requirements

is to consider a few representative scenarios from a set of all the possible
scenarios that illustrate the requirements in practice. By scenario, we mean a
specific sequence of activities that might occur when a system is used. For
example, in a banking system an analyst might consider the scenario where a
user withdraws fifty pounds from their account. They could check that the
transaction was correctly carried out and within the performance timings
required.
Scenarios can be helpful in contextualising the requirements and for
identifying the conflicts and cooperations between them. Unfortunately there is
no formal way to select the ‘right’ scenarios. The selection is based on an
analyst’s experience. New requirements for an existing system, or
requirements that cross-cut different parts of the system, are some of the
candidates for generating the scenarios and investigating the dependencies
among them. Scenarios will be discussed in detail in Unit 3.
2.3 The requirements engineering process

The requirements engineering process, like any other process, takes a set of
inputs, carries out a set of activities, and delivers a set of outputs.
The inputs of a requirements engineering process are the information from
which the requirements can be derived. As you saw at the beginning of
Section 2, the stakeholders’ needs are one of the inputs into this process.
Other inputs come from existing knowledge of the domain, existing
regulations, the organisation’s standards, and existing systems.
The outputs of a requirements engineering process are a set of artefacts that
can help in understanding the intended requirements for a system. In plan-
driven development, this output takes the shape of a requirements document
and the models of what the system is intended to do.
75
In Section 6 you will look at a requirements document that includes the

requirements specification containing the precise and accurate descriptions of
each requirement. In agile development, although requirements are not all
specified upfront, there are ways of documenting them as illustrated in
subsection 6.2.
As for the activities that take place in the requirements engineering process,
there are many different models for describing, naming and ordering them.
Differences in the process come from the structure and culture of the
organisation for which the system is developed, and the experience of people
using it.
There is, however, a set of activities that can be identified as common to
many requirements engineering processes even if they have different names.
These are requirements elicitation, requirements analysis and negotiation,
requirements documentation and requirements validation.
Requirements elicitation is the activity concerned with identifying the
requirements. This is done by consulting the stakeholders, reading existing
documents, understanding the domain, defining the boundaries of the system,
and understanding the possibilities of change.
There are many techniques for elicitation such as interviews, focus groups,
team meetings, brainstorming sessions, and more recent approaches such as
crowd sourcing. Often several of these techniques are used in conjunction.
There are also modelling techniques to help this process such as activity
diagrams, use cases, scenarios, and user stories. We will discuss them in
Unit 3.
The goal of elicitation is to find out what the system to be developed will do.
This involves finding the system’s stakeholders, defining the boundaries of the
system, and discovering the main objectives the system has to meet. At this
stage the requirements engineer is discovering and recording requirements.
Requirements analysis and negotiation is the activity where requirements are
categorised, prioritised and examined for their properties of consistency,
completeness and ambiguity. This activity also involves the negotiations
around conflicting interests and requirements. Models of requirements are
created to help communication with the customers and developers.
Requirements documentation is usually done through a template document.
You will see one such template in Section 6. Documentation also includes the
modelling artefacts, which will be discussed in Unit 3.
Requirements validation consists of a careful check of the overall requirements
documentation, usually following a checklist of questions. This is a way of
ensuring that the requirements correspond to what is really intended of the
system.
Elicitation and analysis occur primarily, but not exclusively, at the beginning
of a project, and their relative importance and effort vary over time. Therefore
the process of requirements engineering is not generally linear and sequential.
The different activities are iteratively visited during the process and
76
2 Requirements
adjustments are made. Some of the activities may be carried out to some
degree in parallel.
Figure 2 illustrates the relative effort of requirements elicitation and analysis
in the early phases of a project. Figure 2 is naturally a simplification because
it omits the other activities of the requirements engineering process. Initially,
elicitation is dominant. Most of the time the two activities interact and inform
each other – requirements elicitation informs the modelling of functionality
and data (which is part of analysis), while analysis helps to discover new
requirements.
proportion of effort
requirements
elicitation
requirements
analysis
time
Figure 2 Relative effort of requirements elicitation versus analysis over time
It is useful to understand the different activities that take place in the

requirements process but it is often not easy to distinguish when one stops
and another starts. It is also not realistic to separate the elicitation from the
analysis and negotiation. In some cases, software is developed without
elicitation, for example when there is no identified customer and the software
is developed in the hope of finding someone to buy it.
The Unified Process (UP), which you met in Unit 1, defines an inception
phase which is mostly about understanding the problem and having a rough
idea of what the system is about. Requirements are mostly done during the
UP’s elaboration phase although they will be revisited in later phases.
2.4 An agile perspective of requirements

The agile approach to software development has emerged from concerns about
the way software was being developed, including the concern about heavy
documentation, the need for it and its usefulness. Agile development stresses
the importance of documenting only when there is a well-defined purpose.
Documenting requirements is done to communicate, to agree on and to
preserve a shared model of what is needed of a system and of the rationale
behind any decisions taken at this stage.
It is not always necessary to write a formal document, and other forms of
communication and sharing can be considered. An agile approach to a
requirements document may take the shape of a product backlog (as in
77
Scrum), which is an ordered, structured list of what needs to be done to a

system.
In their latest edition of Mastering the Requirements Process (2012), Suzanne
and James Robertson accept that ‘The requirements do not have to be written,
but they have to become known to the builders’ (Truth 5, Chapter 1).
Agile methods such as extreme programming (XP) or Scrum see requirements
as unpredictable, continually being discovered, evolving, and being decided
throughout development. These methods have their own processes to plan
software development and requirements feed into development. The methods
do not pretend to have a complete set of requirements upfront.
It is outside the scope of this module to discuss all the details of any specific
agile process. We will, however, discuss some techniques used in agile
methods to help with requirements. In this unit we assume a requirements
initial stage but it is important to always keep in mind that requirements will
change and evolve and will need to be visited repeatedly, and this can be
addressed only if customers are involved in the development process.
2.5 Requirements and architecture

When discussing what a system is going to be about it is almost impossible
not to start thinking about its architecture. Few systems are completely new
and different from any other existing systems. It is therefore natural that in
understanding the requirements, developers will be led to compare what is
intended from a system with what other existing systems provide and how
they are structured.
Requirements may contradict each other, for example (as mentioned in
subsection 2.2) portability and usability in a mobile device, and a compromise
will need to be achieved. Solving these conflicts involves taking decisions that
will affect the architecture of a system.
Also some styles of architecture will be able to support some non-functional
requirements better than others. The parallel with building architecture should
help you to understand this. If you are planning a building that has to serve,
for example, people working in responsible jobs that require periods of
concentration or confidential interactions with others, you should probably
decide against an open-plan building.
Some techniques that we will use to represent requirements help in taking
decisions that affect the overall architecture of the intended system. We will
discuss this further in Unit 3.
You may think that software architecture is incompatible with an agile
approach to development, as you will not have a comprehensive set of
requirements upfront. This is not necessarily the case and we will look at this
in more detail later in the module, in Block 3 Unit 9.
78
2 Requirements
2.6 Requirements and testing

Testing is usually regarded as an activity that takes place at the end of
software development, and this is what a waterfall process model suggests.
However, testing can be done as soon as requirements are being analysed.
Requirements do not make much sense if there is no way that they can be
tested. Therefore, when defining requirements, a developer may be implicitly
thinking about tests that a system will have to go through. In Section 5 we
will discuss how to associate tests with requirements.
Requirements, if they are to be implemented successfully, must be

measurable and testable.
(Robertson and Robertson, 2012, Truth 10, Chapter 1)
SAQ 1
Where and when does the requirements engineering process take place in
an iterative and incremental development process?
Answer
The main output of a requirements engineering process is the contract

between those commissioning the system and the developers of the system.
It has therefore to take place early in the software development process.
However, an iterative and incremental process recognises that requirements
are not stable and revisiting, clarifying and specifying requirements occur in
parallel with the other phases of development.
SAQ 2
(a) Identify the stakeholders for a system to book appointments for a

hospital.
(b) Suggest ways in which requirements may evolve.
Answer
(a) Hospital administrators, receptionists, doctors, nurses, patients,

general public.
(b) Examples are:
◦ new requirements may be added
◦ existing requirements may change because of changes in the
environment or in the organisation
◦ some requirements may become obsolete
◦ technologies may evolve
◦ other systems may emerge that introduce interoperability
requirements
◦ regulations may change.
79
SAQ 3
Consider the following list of poorly expressed requirements, indicate

which properties are not respected and ask questions to clarify their
meaning:
(a) The software system should provide acceptable performance under
maximum load conditions.
(b) If the system fails in operation there should be minimal loss of data.
(c) The software should be developed so that it can be used by
inexperienced users.
Answer
(a) The requirement is ambiguous and not verifiable. How can

performance be measured? What is maximum load?
(b) The requirement is ambiguous and not verifiable. What is minimal
loss of data?
(c) The requirement is ambiguous. What are the usability criteria?
SAQ 4
(a) What are requirements and stakeholders and how do they relate to
each other?
(b) What are the benefits of documenting requirements within a project?
Answer
(a) Requirements are the functions and qualities that are wanted of a
product. Stakeholders are the people and organisations with a vested
interest in the product. Requirements arise from stakeholders’ needs.
(b) Requirements record decisions. They are the main reference for what
should be built and the basis for validation of the built system.
Therefore they need to be documented so that they can be used
throughout development.
SAQ 5
What is an agile approach to requirements engineering documentation?

Answer
In an agile approach, requirements documentation serves a purpose and

should be done only to the extent that it contributes to that purpose. It
should serve as a vehicle for common understanding, communication and
future traceability.
SAQ 6
Which other activities will be taking place in parallel with requirements

engineering?
80
2 Requirements
Answer
The definition of the system architecture and an elaboration of tests for the
requirements. When defining requirements there are implications for the
architecture of the system and each requirement will be related to some test
of the final system.
Exercise 1
(a) Who are the stakeholders in a hotel reservation system?
(b) Consider the example of a hotel reservation system and invent some
examples of the main inputs for a requirements engineering process.
Solution
(a) The hotel owners, receptionists, existing customers, the general public
accessing the system to make a reservation.
(b) Examples include:
◦ stakeholder needs – there should be a help system for first-time
users of the system
◦ domain information – rooms are identified by a number where the
first digit indicates the floor and the subsequent digits indicate the
number of the room in a floor
◦ existing documentation – the manual system used for reservations
◦ regulations and organisational standards – an acknowledgement is
sent to every customer who makes a reservation.

In this section we introduced software requirements and discussed their
relevance in software development and the consequences that arise from a
poor effort at understanding the requirements for a system. We discussed the
importance of involving the various stakeholders in the definition of
requirements and the need to document requirements as a contract for
development. We considered the perspectives on requirements documents of
plan-driven and agile approaches. We also described the activities that take
place in a requirements engineering process and other activities happening in
parallel with requirements engineering.
81
3 Functional requirements
Functional requirements are those requirements that specify the behaviour of a
system, as opposed to non-functional requirements, or qualities, that specify
more general properties such as usability, reliability and maintainability. In
their book Mastering the Requirements Process, Robertson and Robertson
(2012) define functional requirements as:
functional requirements are things the product must do.
Another useful description is given by Alexander and Stevens (2002) in their

book Writing Better Requirements, where they firmly distinguish between the
needs of the user:
A requirement is a statement of need, something that some class of user or

other stakeholder wants
and what a product (the solution) does:
A function is something that a system or subsystem does, presumably

because a requirement made it necessary. … A functional requirement … in
practice just means the same as function.
An example of a functional requirement is, ‘The system shall accept a credit

card number from a client’. Associated with this requirement are other issues
such as a need for the function to be done securely and within a given time
period. These last two requirements are traditionally considered to be non-
functional requirements. They constrain a functional requirement to being
realised in certain ways.
However, the distinction between functional and non-functional requirements
is to some extent pragmatic rather than fundamental, since, for example,
security is associated with functionality. For this reason, many authors now
use the term quality requirements instead of non-functional requirements.
Whether or not you are convinced that there is a real difference between
functional and non-functional requirements, we will continue with the
distinction as it helps in drawing up checklists of places to look for
requirements.
3.1 Elicitation, analysis and negotiation

When eliciting functional requirements, attention must be paid to their relative
importance. It is important to identify those requirements that are essential
(often said to be ‘core requirements’) and those that are inessential but would
be nice to have. The reason is because more requirements tend to increase
both cost and the time for development. Therefore identifying the core
requirements ought to identify the minimum cost and time for development.
82
More generally, it is felt that functional requirements should be prioritised so

that the most important requirements can be identified. This enables a
judgement to be reached on what can be delivered for a given price or what
the cost will be for a given set of requirements.
In practice, when eliciting requirements you would probably use a way that
best suits your experience and applications and that results probably from a
combination of different approaches. In this module one specific way for In Unit 3 we discuss use cases in
eliciting requirements based on use cases is described in detail in Unit 3 but great detail and use a template to
in outline is as follows. represent them and the
associated scenarios.
The starting point is to look at the domain, the current business situation –
that is, how the work is carried out before any development takes place. The
domain modelling activity will identify a set of business processes that are
triggered by business events.
Once a decision is taken to develop a system, these business processes and
events are the context for the system being developed. Some of the business
events are relevant for the new system and each of these events will then be
associated with a use case, a chunk of functionality – that is, a description of
how the new system is to be used for a specific goal.
Use cases are derived from business events and each use case is described by
a set of scenarios. A scenario is a series of steps that complete the functional
tasks of a use case, described from the point of view of a user. A task is
something that the actor identifies as being part of the work of the use case.
The steps in a scenario therefore provide a mechanism, or thinking technique,
for determining all the functional requirements needed by each scenario.
One way to discover the requirements of a system is to see what the system
needs to do to support each step in a use case. For example, in a scenario for
checking in a guest in a hotel, there is a step ‘allocate room’. This step maps
directly to the requirement ‘the system shall allocate a room’. In contrast the
step ‘issue key to guest’ might be a completely manual operation and unlikely
to involve any software requirements. For complex tasks or steps, several
requirements may well be involved.
One advantage of deriving requirements from use case descriptions is that you
can then associate the requirements with the specific goal of the use case to
which they relate, and this is a way of structuring requirements. As you work
through the use cases of a system you are likely to find requirements that are
repeated, that is, a single requirement that belongs to several use cases.
Identifying these repeated requirements will allow you to implement them just
once.
In reality, of course, the elicitation of requirements and the scoping of the
system starts from an initial set of high-level and quite general requirements,
for example ‘Accept a reservation’ or ‘Check a guest in’. So the process
described in the last paragraph can be seen as a way of obtaining the detailed
requirements of the system.
83
Iterative requirements gathering

The collection of requirements has finished when they constitute a description
of everything the system must do. In other words the system can be built
without further reference to the client or users of the system.
This does not mean of course that the system will not be constructed until all
the requirements are gathered. In an iterative approach quite the opposite will
be the case. Furthermore, it is likely that requirements will continue to emerge
long after the system has to be installed. It is therefore crucial that
requirements are carefully managed, and failure to do so is one of the most
important causes of project failure.
One approach to prioritisation, which is used in the DSDM framework
DSDM is an iterative and (dynamic systems development method), is the MoSCoW scheme, where
incremental approach that adapts requirements are classified as must have, should have, could have, and won’t
the agile manifesto principles have. This classification scheme can be used at the level of each iteration,
(www.dsdm.org/content/what-
dsdm).
allowing an iteration to be timeboxed. When the time allocated runs out,
‘should have’ and ‘could have’ requirements are delayed to a later iteration.
Requirements through stories

Agile methods promote continuous interaction and communication with
customers and users and their involvement throughout the software
development process. The process of gathering requirements is achieved
through stories written by the intended users of a system or their
representatives – user stories.
User stories describe some functionality that is of value to the person or
persons writing the story, that is, the stories represent the users’ expectations
of the system. They are written at the beginning of a project but also
throughout the whole project. They are traditionally recorded on a story card
(an index card) and consist typically of a paragraph such as ‘As a customer I
can see days, times and cost of flights to the destination’. An example of a
typical format is ‘as a [role] I want [feature] so that [reason]’.
Stories trigger conversations that add detail. For example, does the customer
want to see flight details of days around the chosen date? What other
information is needed about a flight? These conversations suggest further
detail, and help to define priorities of stories, to estimate their cost, to plan
accordingly, and to specify how the stories can be tested.
The user story technique is defined by Beck and West (2004) as follows:
. The customer (user) thinks of something she wants the system to do.
. The desire is written down on an index card, given a name and a
number.
. An estimate is made of how long it will take to realize the story in fully
functional and releasable form.
. Stories are factored – split into smaller stories – if it appears they will
take too long to implement as written.
. Stories are factored if one aspect of the story is more important than
others.
84
. Stories are factored if they are long and rambling or overly general.
. Stories are prioritized.
. Stories are aggregated into collections, each collection defining the scope
of work undertaken by the team this period.
. Work products are validated. Their ability to satisfy the original story is
confirmed.
. The customer uses the developed system and new stories are conceived.
. Iterate.
(Beck and West, 2004)
User stories emphasise communication between users, customers and

developers rather than documentation. The documentation will consist of the
story cards, the tests written for each story, diagrams in a whiteboard, the
code, and so on.
Writing stories is an art in itself and there is guidance on what is a good story,
how it should be written, and how it can be split into other stories. Cohn
(2004) lists the following characteristics as essential for a good story:
independent, negotiable, valuable to users and customers, estimable, small,
testable. Beck and West (2004) highlight four characteristics of a story:
discrete, estimable, testable and prioritised. It is outside the scope of this
module to teach you how to facilitate the writing of good stories but you will
see some examples at the end of this section.
3.2 Describing requirements

In writing requirements the aim is for clear statements of the form ‘The
system shall …’. In doing this it is important to avoid ambiguity, and this is
not easy because natural language is notoriously ambiguous. For example,
consider the requirement ‘The system shall allocate a room, and it should be
cheap’. Using the word ‘it’ has introduced the possibilities that it is either the
room or the system that should be cheap. Furthermore, what does cheap
mean? Pronouns (for example ‘it’, ‘their’) should be avoided, as should words
with multiple meanings.
Another source of ambiguity is the way in which words may have multiple
meanings, or, even where they have essentially one meaning, can be
interpreted in different ways by different people. For example, are the users of
a library system the members of the library, staff or both? For this reason any
words that have technical meanings or meanings specific to the business
should be given definitions that get recorded in the requirements specification.
For similar reasons, abbreviations, including acronyms, should be defined
there.
Statements may also need to be constrained in other ways. For example, if a
hotel has to deal with VIP guests then a requirement such as ‘The system
shall allocate a deluxe room’ may be necessary and stating just ‘The system
shall allocate a room’ is too loose a statement.
Requirements should be described at a level of detail that the people
commissioning the system can understand. However, such descriptions may
85
not be sufficiently detailed for developers. Therefore the question arises of

what is the appropriate level of detail to be provided by a requirements
analyst.
Sommerville distinguishes two types of requirements as follows:
Requirements specification [is] the activity of translating the information

gathered during the analysis activity into a document that defines a set of
requirements. Two types of requirements may be included in this document.
User requirements are abstract statements of the software requirements for
the customer and end-user of the system; system requirements are a more
detailed description of the functionality to be provided.
(Sommerville, 2011)
Developers need to work with both types of requirements. They need user
requirements when interacting with stakeholders external to the project and
system requirements to inform system design. The two forms of requirements
are related as the software must be designed to meet the user requirements.
The first type of requirement is usually written in natural language for obvious
reasons. Natural language or more formal approaches such as mathematical
specifications can be used for system requirements. In both cases requirements
will be recorded in a structured document – you will see more about this in
Section 6.
It is important to distinguish between the requirements and the systems that
are introduced to satisfy them, that is, to produce the required behaviour –
there is a distinction to be made between a requirement and its solution. For
example there might be the requirement, ‘The system shall produce a list of
names in alphabetical order’. It would not help to specify this as, ‘The system
will sort a list of names using the bubble sort algorithm’.
You must ensure that you do not write solutions instead of requirements. You
need to understand the essence of the business, not its implementation. This is
important because it is too easy to hide significant functionality by describing
an implementation, and too easy to select one implementation when better
ones may exist.
Another issue that arises from consideration of solutions is technical solution
requirements. These relate to functionality that is needed purely because of the
chosen technology. Technical solution requirements are not there for business
reasons, but to make the chosen implementation work correctly. They are
constraints on the behaviour of the product.
It is essential to ensure that the technical requirements are not introduced
before the business requirements have been fully understood. For example,
there may be a need to authenticate the user of a system. This is a business
requirement. However, stating that this should be done in a particular way
such as using a password, as opposed to, say, an iris scan, is a technical
solution requirement.
SAQ 7
(a) What are the purposes of requirements?
86
(b) What is a functional requirement?

(c) Indicate one property that a functional requirement should not
possess?
(d) What is a non-functional requirement?
(e) What are a technical solution requirement and a business functional
requirement? Why is it useful to distinguish them?
(f) What overarching property should the set of functional requirements
that result from a requirements-gathering process possess?
(g) How do business events and use cases help in determining functional
requirements?
(h) How do user stories help in determining functional requirements?
Answer
(a) Communication – from the requirements engineer to the designer.

As a contract with the client (and other stakeholders) for what the
system must do.
(b) A functional requirement describes an action that the product must
take if it is to carry out the work it is intended to do.
(c) A functional requirement should not be a statement about a general
property such as usability, reliability or maintainability. A functional
requirement should not be about the implementation of a solution.
(d) A non-functional requirement is a requirement about a quality that
the product must have.
(e) A technical solution requirement is a constraint on the product
resulting from the technology of the solution that must be adopted.
Business functional requirements are a specification of the work,or
business, independent of the way that work will be carried out.
The two types of requirement therefore arise from different domains –
the business domain and the solution domain. It is important to keep
issues related to the business separate from those of the solution.
(f) The set of functional requirements must fully describe the actions
that the intended product should perform. That is, the product’s
builder must be able to construct the product desired by the client
from the descriptions contained in the functional requirements.
(g) One way to discover the requirements of a system is to use the steps
in use case scenarios. Use cases are derived from business events
and each use case is described by a set of scenarios. Each step in a
scenario details a functional task. All the functional requirements
associated with a use case can be collected from these tasks.
(h) User stories are written by the people who will get some value out of
the system and therefore highlight elements of functionality relevant
to them. User stories encourage communication and involvement of
users and customers with the development process, allowing for
change and discovery of requirements throughout.
87
SAQ 8
(a) How do you discover whether or not a set of functional requirements

is sufficient for the product to be useful and whether the
functionality is correct?
(b) Why must functional requirements be testable?
(c) Can you think of some generic questions to ask that can help in
making requirements precise and complete?
(d) What is the major problem with a requirement that is written in a
natural language such as English?
(e) Is it possible or desirable to avoid ambiguity entirely in a
requirements specification? What steps can you take to reduce
ambiguity in a requirements specification?
(f) Why record the meaning of business and technical words in a
requirements specification?
Answer
(a) Ask the user.

(b) So that it is possible to determine whether the delivered product
meets the intention of the user.
(c) Questions of the form ‘when should something happen?’ and ‘to
whom should something be sent?’ are useful. You may have thought
of others.
(d) Ambiguity.
(e) It might be possible to avoid ambiguity entirely, but the cost of
being so precise can be enormous and the result unreadable. To
avoid ambiguity attention has to be given to the language used to
represent requirements.
(f) To avoid ambiguity and aid clarity in the usage of terms.
SAQ 9
Summarise the overall process (based on use cases) described in this

section for determining a set of functional requirements.
Answer
(a) Understand the domain and determine the business processes and
business events.
(b) Determine the scope of the new system and which business events
are relevant.
(c) Draw up a set of use cases for the product associated with those
events.
(d) Describe each use case by one or more scenarios – a set of steps.
(e) Work through each step of each scenario to determine a set of
system requirements.
(f) Check for similar requirements from different use cases.
(g) Search out and remove ambiguity.
88
SAQ 10
Describe a process for capturing a set of functional requirements based on

user stories.
Answer
A requirements capture process based on user stories usually starts with a

brainstorming workshop with users and customers to generate an initial set
of stories. A story is recorded on a card and triggers a conversation which
helps with understanding the detail, and outline tests for each story. Stories
are prioritised, grouped and allocated to an iteration. The outcome of an
iteration is validated against its user stories.
Exercise 2
Here is a list of requirements that apply to a product X. For each requirement
say whether it is a functional or non-functional requirement and, if it is a
functional requirement, whether it is a business requirement or a technical
solution requirement.
. X must check a user’s identity
. X must check a user’s password
. X must produce a statement of the user’s account
. X must validate the user’s identity and password within three seconds
. X must be usable by users with limited dexterity
. X must employ the company’s proprietary password maintenance system
. X must operate in arctic climates.
Solution
X must check a user’s identity functional, business requirement (the requirement states
what needs to be done, not how to do it)
X must check a user’s password functional, technical solution requirement (access to the
system can be achieved in many ways – passwords are just
one mechanism, biometrics may be more appropriate to
this product)
X must produce a statement of the user’s account functional, business requirement (the requirement states
what needs to be done, not how to do it)
X must validate the user’s identity and password within non-functional
three seconds
X must be usable by users with limited dexterity non-functional
X must employ the company’s proprietary password functional, technical solution requirement (a specific
maintenance system technology is mandated)
X must operate in arctic climates non-functional
89
Exercise 3
Derive some functional requirements for the step of a scenario in a hotel
management system stated as, ‘The system shall allocate an available cleaner
to each occupied room’. Confine yourself to what must be done, not how it is
to be done.
Solution
Here are some suggestions:
. the system shall identify occupied rooms
. the system shall identify available cleaners
. the system shall allocate occupied rooms among the available cleaners
while balancing their workloads.
Exercise 4
Imagine that you have been commissioned to produce a requirements-
recording tool. The purpose of the tool is to allow a requirements analyst to
record information about each requirement for a product. An important
requirement for the tool is that it should give its users the impression that they
are dealing with a stack of cards, each recording a requirement.
Without considering the detail of the information to be kept about each
requirement, identify four functional requirements for managing a collection of
such records. That is, what would you want the tool to do that would help
you record the requirements you have elicited so far and maintain those
requirements as you learn more about the required product? If the tool is to be
used on different projects what additional functionality should it possess?
Solution
Here are some of the functional requirements that relate to the management of
a set of requirements. Yours may differ.
. the product shall enable a new requirement to be entered
. the user shall be able to view each requirement in the set
. the product shall enable a user to amend (edit) an individual requirement
. the product shall enable the user to delete a selected requirement from the
set of requirements
. the product shall enable the user to view the summary of all requirements
. the product shall show all requirements that conflict with each requirement
. the product shall perform a range of checks on the set of requirements
. the user shall be able to view all requirements satisfying given criteria
. the product shall show a list of all requirements associated with a selected
business event
. the product shall enable the user to create and amend a set of requirements
for a new product.
90
Exercise 5
From the following list of user stories indicate which ones are good stories
and why.
(a) As a user I can select the language for the pages of the website because I
am not a native speaker.
(b) As a user I can learn how to use the system easily so that I do not spend
too much time.
(c) As a chief information officer (CIO) I want the software to be written in
C++.
(d) As a user I want to be able to run the system on an Android phone.
Solution
As a user I can select the language for Good, but may be too small
the pages of the website because I am
not a native speaker
As a user I can learn how to use the Not a good story because it is not
system easily so that I do not spend too measurable
much time
As a CIO I want the software to be Not a good story because it is a
written in C++ constraint on development. It could be a
good story if the users were
programmers wanting some library to be
developed, or if there was a good reason
for it. (Notice that the reason part of the
story is missing in ‘as a [role] I want
[feature] so that [reason]’.)
As a user I want to be able to run the Good story. Notice that you can write a
system on an Android phone user story for a non-functional
requirement.
Source: adapted from Cohn (2004)
91

In this section we defined functional requirements and illustrated a process for
eliciting them. Also we discussed briefly an alternative agile process for
dealing with requirements based on user stories. We considered issues around
the documentation of requirements and distinguished between technical
solution requirements and business functional requirements.
92
4 Non-functional requirements
Non-functional requirements 4
Functional requirements state what a product must do. In contrast, non-
functional requirements are qualities that the system should have: such as
being secure, fast, usable or maintainable. So, for example, while there may
be a requirement that a banking system should compute and display a client’s
balance, there may be non-functional requirements attached to this, such as it
should be done securely and within, say, five seconds.
Non-functional requirements may be associated with a particular piece of
functionality – a use case or group of use cases – or with the overall system.
If they are associated with the overall system it may well be necessary to
break down what is meant. For example, given a non-functional requirement
that ‘The system shall be secure’ it would probably be necessary to know
what this means in terms of individual use cases as well as for the overall
system. However, a non-functional requirement such as ‘All responses from
the machine shall complete in one second’ can be applied globally with little
further clarification.
One useful way to think of non-functional requirements is as constraints on
the functional requirements. From this perspective, functional requirements tell
you what the system should do, and non-functional requirements constrain the
ways in which those things are done – securely, quickly, and so on.
This means that, in effect, non-functional requirements make sense only in
relation to what they say about functional requirements. Functional
requirements are more standalone in that they can be understood in isolation,
but they by no means give the full picture of what needs to be developed.
Requirements engineers have begun to change their terminology from non-
functional requirements to quality requirements simply because the new term
is more suggestive and less confusing than the original. However, both terms
as well as some others are in common usage.
Non-functional requirements (sometimes called NFRs for short) are elicited by
working from a list of categories, deciding whether they apply to each
requirement and use case and, if so, in what way. We will explore such
categories in this section, and a list of them is used in the requirements
template introduced in Section 6.
When working with user stories, non-functional requirements that are
associated with a piece of functionality, a user story, can be annotated as
constraints in the back of a user story card. However, as you saw in
Exercise 5, user stories can also be written for non-functional requirements.
Perhaps the most surprising aspect of non-functional requirements is that not
only do they enable the functionality of the product, but also they can add up
to a significant part of the specification. The significance can be in terms of
size (the proportion of the specification dealing with non-functional
requirements) and perception (how the users perceive the product – its
usability and appearance, for example). No matter how well a product does its
93
work, whether or not people will use it can depend crucially on its quality
aspects.
At one time, it was generally felt that non-functional requirements were
difficult to deal with because they were felt to be ‘nebulous’. Today,
developers view non-functional requirements in the same light as functional
requirements – in order to be useful, requirements must be testable, which
We are using the terminology of means that they must be measurable. Precisely how to make non-functional
fit criteria from Robertson and requirements measurable is dealt with in Section 5, but the idea of fit criteria
Robertson (2012). is used.
In Unit 1 we mentioned the role of architecture. Non-functional requirements
constrain the choice of architecture in that the chosen architecture must allow
the required qualities such as speed or maintainability to be achieved.
Robertson and Robertson (2012) identify the following eight classes of non-
functional requirements:
. Look-and-feel requirements. The spirit of the product’s appearance.
. Usability and humanity requirements. The product’s ease of use and any
special usability considerations.
. Performance requirements. How fast, how safe, how accurate, how
reliable, and how available the functionality must be.
. Operational and environmental requirements. The environment on
which the product will have to work (under water, for example), and what
considerations must be made for this environment.
. Maintainability and support requirements. Expected changes, and the
time allowed to make them.
. Cultural requirements. Special requirements that come about because of
the people involved in the product’s development and operation.
. Legal requirements. The laws and standards that apply to the product.
. Security requirements. The security and confidentiality of the product.
While the above list represents a useful way of categorising non-functional
requirements, you should not think of it as exhaustive. Depending on context
other ways of categorising requirements may be more appropriate.
We will now consider each of the above categories in varying amounts of
detail, considering how each can be recorded. We will give particular attention
to security requirements, as at the time of writing (2013) this area is attracting
a lot of attention and they constitute a particularly interesting example of how
to deal with non-functional requirements.
4.1 Look-and-feel requirements

Look-and-feel requirements are about the overall impression a product will
make on a user – the appearance and style of its interface. For example, in a
banking environment you might want the product to have a conservative feel
with limited use of colours and animation. If the product is a game, then the
opposite might apply.
94
These requirements are not about the specifics of the user interface, so they
are often described in quite general terms. An exception to this is when the
product will run on an operating system and the decision is made to conform
to the quite detailed user interface guidelines provided by the manufacturers of
the operating system.
Some examples of look-and-feel requirements are:
. the product shall comply with the iOS human interface guidelines
. the product shall use only two colours
. the product should use a lot of animation
. the product shall use a large range of exciting sounds.
SAQ 11
(a) What does the phrase ‘look and feel’ refer to?
(b) When identifying non-functional requirements for the look and feel
of a product, why should you avoid the temptation to provide a
design for the user interface?
(c) The description of a look-and-feel requirement is often loosely
worded and therefore difficult to turn into a good design. What
should be done to rectify this situation?
(d) What general characteristics should the look and feel of a consumer
product have?
Answer
(a) Look-and-feel requirements describe the overall appearance of the

product to its users.
(b) The production of a design is the task of the product’s designers,
once they know the requirements. The look-and-feel requirements are
not about the specifics of the user interface.
(c) Fit criteria (dealt with in detail in Section 5) should be added to the
requirements in order to make each one measurable.
(d) The look and feel is concerned with the impression you wish to
make. You want it to reflect the distinctive values, ethos and style of
your organisation.
4.2 Usability and humanity requirements

One of the key criteria for measuring the success of a product is whether users
can use it to fulfil their tasks and are satisfied with it. A product with poor
usability may result in poor productivity, high error rates because of ‘misuse’,
and high stress levels for users. In some cases users will refuse to use the
system.
In order to specify usability requirements engineers need to think about the
types of people who will use the system. For example, do the users have lots
of experience with the type of system the team intends to produce? Usability
95
and humanity requirements can be split into the two issues of how ‘easy to
learn’ is the software and how ‘easy to use’ is it?
The requirement that a product be easy to learn is contextual. An easy-to-learn
website for buying books might require zero training. An easy-to-learn
accounts package might require a two-hour tutorial rather than a week of on-
site training. An easy-to-learn nuclear reactor control system might require
several months of training but not several years of experience.
Easy-to-use products are designed to facilitate efficiency and users may
require training to be done before the product can be used effectively. Such a
product might be complex and take some time to learn, but the cost of
training is outweighed by the resulting efficiency gain.
Easy-to-learn products are often aimed at tasks that are performed infrequently
and that therefore have to be relearned from time to time, and are often aimed
at the public market. When training is infeasible the products have to be easy
to learn and are not normally complex.
Another aspect of usability and humanity relates to the way a user feels
treated by a software system. A typical example of poor treatment is when a
website discards all the data you had previously filled in because the wrong
password is entered. This is not acceptable. Aspects of accessibility and
personalisation should also be considered as usability and humanity
requirements.
Some examples of usability and humanity requirements are:
. a university graduate should be able to learn to use 50 per cent of the
functionality of the product in 2 hours
. ninety per cent of the general population should be able to place an order
from a web interface within 5 minutes – 90 per cent of elderly users
should be able to place an order from a web interface within 10 minutes
. it should be possible to use the system to pay in different currencies
. the system should comply with the Disability Discrimination Act.
SAQ 12
(a) What do usability and humanity requirements describe?

(b) What are the effects of usability and humanity on a product?
(c) How might you express a usability and humanity requirement more
precisely than simply ‘easy to learn’?
Answer
(a) They describe how easy to use the product should be for its intended
users under specified circumstances, and how satisfied they are with
it. This includes how easy it is to learn to use the product.
(b) Usability and humanity impacts on productivity, error rates, stress
levels and acceptance. It determines how well the human part of the
system can perform.
96
(c) A usability and humanity requirement can be expressed more

precisely by describing the level of achievement required after the
required training or learning period.
4.3 Performance requirements

Performance requirements relate to the effectiveness of a system in carrying
out its tasks. This includes the speed with which the system should operate,
how much data or information it can handle, how safe it is to operate, how
accurately it can produce its results and how reliable and available it is in
relation to failure.
The apparent speed of a system can be influenced by the number of
transactions or amount of data it is able to process in a given time (known as
throughput and volume respectively). A system may be able to deal with a
single transaction with the requisite speed, but if the volume of transactions
increases the system may not be able to deliver the same performance.
Reliability is usually measured as the mean time between failures.
Some examples of performance requirements are:
. the product shall calculate a guest’s bill in 2 seconds
. the product shall handle up to 10 users simultaneously
. the product shall report wind speeds within 5 miles per hour of the actual
speed
. the product shall, on average, operate without failure for 20 days.
SAQ 13
(a) What are the main kinds of performance requirements?

(b) Rather than accept requirements that state that something should be
done speedily and/or efficiently, what should you aim for?
(c) What are the problems of specifying performance requirements for
web-based systems?
Answer
(a) Normally the main performance requirements involve speed (the time
to do something), capacity, safety, accuracy, reliability and
availability.
(b) You should look for requirements that specify the speed and
efficiency in ways that can be measured objectively. Take into
account the possible effects of throughput and volume.
(c) It is hard to specify performance of web-based systems because there
are too many unknowns, for example the speed of connection.
97
4.4 Operational and environmental requirements

Operational and environmental requirements relate to the environment in
which a product is to be used. For example, imagine a system designed to
coordinate a mountain rescue team. While the main system might be located
in an office it might be that the rescue team will interact via portable devices,
and these will therefore need to deal with extreme conditions of coldness,
damp and light. Furthermore the ability to use the devices will also be
affected by these conditions.
Another area that can easily be overlooked is those requirements that relate to
the installation of the product and the needs of the installers.
One approach to finding the operational and environmental requirements is to
investigate the product boundary (the scope as defined by the use cases) and
consider the needs of each system it interacts with. Note that an operational
requirement, as may be suggested by its name, is not about the operating
system or any specific device on which the system will operate, but rather
about the environment in which the system will operate.
Some examples of operational and environmental requirements are:
. the product shall be usable above an altitude of x, in icy and wet
conditions, and both in the dark and in bright sunshine
. the product will be used in a standard office environment, except that high
levels of background noise may occur
. the product will need to be installed at 58 locations around the proposed
route of the race in 2 days by 3 semi-skilled workers.
SAQ 14
How do operational requirements differ from performance requirements?

Answer
Operational and environmental requirements describe the operational

environment (factors external to the product) in which the product must
function correctly, whereas performance requirements deal with issues such
as speed and size (factors internal to the product).
4.5 Maintainability and support requirements

There are two quite different notions of maintaining and supporting a product.
The first is to do with keeping the product updated in the light of expected
changes. For example you may know that new requirements are likely to
occur at some point in the future. This might be because the way a business
operates is likely to change, or because the laws that apply to the business
area are to be updated. You may also want to specify the need to port the
software to new hardware or software environments at some later stage. The
second notion of maintainability is to do with mending the product when it
fails. Support requirements concern any decisions on how the product is going
98
to be supported that may affect the design, for example is there going to be a
help desk?
Some examples of maintainability and support requirements are:
. the product shall be able to be modified to cope with a new class of user
. the product shall be able to be modified to cope with minor changes to
European law that occur every six months on average
. the product shall be portable to all the operating systems currently used in
our Slough office.
4.6 Cultural requirements

It may be obvious to you that if a product is to be sold in a different country
from your own there will be potential cultural requirements to consider. But
what might they be?
Less dramatic, but still important, are the cultural differences between
organisations. If you are eliciting requirements for an organisation that is not
your own, you should be wary of cultural differences. Don’t assume that you
will observe the same reaction to your investigations that you might in your
own organisation. A way to overcome these problems is to seek the help of
someone who is knowledgeable about the culture.
An example of a cultural requirement is:
the language used in the interface should be formal and polite.
SAQ 15
(a) When do cultural requirements usually arise?

(b) What is the best approach to dealing with cultural issues?
(c) Why are cultural requirements often difficult to deal with?
Answer
(a) Cultural requirements usually arise when:

(i) the aim is to sell a product in a different country,
particularly a country with a different culture and language
from the one that the product was initially designed for
(ii) eliciting requirements in an organisation different from one’s
own.
(b) Obtain the help of stakeholders from that culture.

(c) Cultural and political requirements often involve having to ask
personal questions and can be difficult to quantify. Such questioning
is likely to be sensitive.
99
4.7 Legal requirements

Two important areas from which requirements must be elicited are the law and
the standards that apply to the product. Two important pieces of UK law for
which there are likely to be equivalents in other countries are the Data
Protection Act 1998 and health and safety legislation.
When developing computer systems it is important to satisfy yourself that the
relevant laws will be complied with either by examining the legislation or,
preferably, by asking a lawyer. Failure to comply with the law might involve a
range of penalties. It is important to look at the environment in which the
system will operate and what other systems and people it will interact with.
A third area related to law is the regulatory structure that controls some
industries. For example, companies that make computer-based medical devices
(for example Roche) must have their equipment approved by the relevant
regulatory authority (the European Commission in this case) before it can be
used in a medical setting. This is often described as regulatory compliance.
There may be sets of criteria that the equipment has to satisfy. Indeed, the
companies may have to show how the software was developed and hence
meet a number of traceability requirements. The regulatory framework can
therefore add a large number of requirements to every such product.
For a company working in a wider international market, the consequences can
be even more severe because each country outside Europe is likely to have
different and possibly conflicting regulations.
As well as ensuring that systems under development comply with all relevant
laws you also need to ensure that any contracts entered into with clients are
honoured. The cost of litigation is one of the risks for commercial software
and can be expensive for other kinds of software. Furthermore, the way in
which a contract is drawn up plays a strong role in determining whether the
software development subsequently undertaken is profitable and reflects well
on the professional standing of those involved.
SAQ 16
(a) What is the most pressing reason for considering legal requirements?
(b) How should you determine the appropriate law that affects the
product?
Answer
(a) The cost of litigation is a risk for commercial software and can be
expensive for other software. There are penalties for non-
conformance with the law – fines, imprisonment, and loss of
reputation.
(b) Obtain help from the company’s lawyers.
100
4.8 Security
This subsection provides a general introduction to issues of security and
protection. It covers some of the threats that face computer systems.
There are many definitions of security but in this module we define computer
security as being concerned with the detection and prevention of unauthorised
actions by users of a computer system. For example, you might allow
(authorise) everybody in the world to read pages on your website but only a
limited number of users would be allowed (authorised) to change or delete
those pages.
With a standalone computer it is possible to achieve security by physical
means. For example the computer could be placed in a room to which only
certain people have access. In a simple version of this scheme, those who
have access to the machine would have the power to perform any action on
the machine.
You may wish to restrict the actions of individual users and you could do this
by having a mechanism whereby the user has to provide a name and a
password for identification, then rely on the operating system to restrict
individuals to certain actions – access to data, running particular applications,
and so on. These approaches are, of course, solutions to the problem of
security, not requirements.
For a distributed computing system, which involves a number of
interconnected computers, security becomes an issue. Although
communication and sharing are the motivations for forming a distributed
computer system, you may not want to share your resources with everyone.
The same is true for communication – you may not want other people to be
able to intercept users’ communications. This interception might be passive
(just listening to the communications) or active (listening and retransmitting
the messages with or without changes).
On an external network, such as the internet, communications pass via a
number of computer systems over which the user has no control. In particular,
the user does not know what security mechanisms these systems have in
place. Therefore security goes beyond the basic protection of resources to
considering the computing system in its surroundings or environment.
A particular example where security is a major issue is that of ecommerce. We
define ecommerce as a system where commercial transactions take place
through the use of a distributed computing system, often using the internet.
Such transactions might be the sale of goods or services or banking services.
Mechanisms can be devised to stop casual attacks from pranksters or
disaffected employees, but they will not deter everyone. Also audit logs can
be kept to help identify the presence of an intrusion. Ultimately no computer
system can be completely secure from attacks, but it can be made difficult for
attacks to succeed by making the cost of mounting a successful attack high in
terms of time, money, equipment and people.
101
SAQ 17
(a) In the context of a computer system, what is meant by security?

(b) There are two problem areas for a distributed computing system that
go beyond the normal security requirements. What are they?
(c) From the point of view of a security administrator, suggest a useful
starting point to monitor potential threats.
Answer
(a) Security is about the prevention of unauthorised access to the system.

(b) The additional security problems that arise with a distributed system
are:
(i) the communication medium is insecure and users’
communications may be intercepted en route and read or
altered
(ii) on an external network communications will pass through
many third-party systems with unknown security measures
which cannot be controlled.
(c) One useful focal point is at the boundary of the security domain for
which the administrator is responsible. In practice, this is likely to be
a firewall for a protected network.
Security requirements
Security is a good illustration of conflicting requirements. It is possible to
make a system secure to deter unauthorised access but at the cost of making
access by legitimate users extremely difficult.
Security requirements cover access, privacy, integrity, audit and immunity:
. access addresses uninterrupted or continual access to data and functionality
by authorised users
. privacy addresses the protection of data from unauthorised access and
disclosure
. integrity addresses consistency of data, the ability to prevent unauthorised
modification or deletion of data
. audit addresses both how the correctness of product and data can be
verified, and how to help detection of inappropriate access and intrusion
. immunity addresses the protection of a system against threats and attacks.
As well as costs incurred from losing data if its integrity is compromised,
there may be costs if data is unavailable because work cannot then be
completed and contractual arrangements may not be met. Important costs are
also associated with loss of privacy, as commercial secrets may be exposed,
individuals may sue, and the organisation’s reputation may be harmed in a
way that loses it future business. For example, a bank’s reputation for privacy
is critical to its ability to attract and retain customers.
102
A computing system and its resources need to be protected from unauthorised

access by those who seek to gain some advantage or act maliciously. They are
intruders who try to read, change or delete the data that is stored, processed or
passed around a computing system. They may attempt to carry out an
unauthorised transaction, passing themselves off as another person, and may
extract financial gain or advantages through such use. At the extreme, there is
a chance of physical damage or destruction.
Some examples of intruders are:
. ‘crackers’ who test their skills against the security measures of a system
for their personal pleasure
. competitors who try to gain access to commercially secret information
. fraudsters who try to obtain financial gain from the owner of the system or
some third party.
Security is an important issue and getting it wrong may be disastrous. Where
developers have not been trained in security it would be prudent to have a
security expert on the team to advise them.
SAQ 18
(a) What are the five aspects of security from a requirements

perspective?
(b) Distinguish between the five aspects of security.
Answer
(a) Access, privacy, integrity, audit and immunity.

(b) Access – authorised users of data should not be prevented or
unnecessarily delayed from accessing that data. This implies that
steps should be taken to prevent loss of data and to prevent denial of
service attacks.
Privacy – data must not be made available to anyone except authorised
users. This implies identification of those who are authorised to access
specific items of data.
Integrity – the data held by the system corresponds to the data supplied
to the system. Integrity implies that data does not become corrupted.
Audit – the data and functionality of the product can be verified and
inappropriate access can be traced.
Immunity – the product is protected against external threats and attacks.
More on threats and attacks against assets

For any kind of computing system, it is important to ensure that all resources
(also known as assets) are accessed and used as intended under all known
circumstances. If you can prevent misuse, the computing system is secure.
However, the cost of making a system secure must be balanced against the
difficulties the security measures impose on legitimate users.
103
The forms an attack might take are as follows:

Disclosure of private information or the unauthorised release of information.
For example, an intruder might intercept the network and read your messages
en route. From an ecommerce transaction such as an electronic order you have
placed, an intruder might be able to access your credit card details and
illegally use them.
Modification, loss of integrity, or the unauthorised alteration of data or
information. Intruders might change messages or stored data. They might
increase their bank balance either by directly modifying the data or by altering
a message so that they become the payee of an online fund transfer, withdraw
all the funds and then disappear.
Denial of use or service or loss of access, where there is some denial of
network service to its authorised (legitimate) users. The intruder redirects
messages or creates congestion by recycling messages. They might also
covertly gain control of the computers owned by innocent third parties and
use these computers to bombard a site with messages. The intruder might be a
competitor who is trying to put the company out of business by preventing
access to its system by its customers.
Repudiation, where a legitimate user claims that they did not send or receive
a particular message that was sent or received. For example, somebody who
ordered holiday insurance online might after the holiday claim that they did
not order the insurance. The insurer could do a similar thing and repudiate
that the customer ordered insurance if an insurance claim is made.
Example 2
Suppose that a university uses a distributed computing system for all its
students to support distance learning. If all module and assessment material is
held within such a system, you could envisage the following security
problems:
1 disclosure of personal information
2 disclosure of educational materials to people who have not paid for them
3 disclosure of students’ assignment solutions to other students
4 unauthorised modification or alteration of data
5 unauthorised changes to educational materials
6 unauthorised alteration to students’ marks
7 denial of use or service
8 inability to access material by students
9 slow replies to service requests
10 (non-)repudiation
11 inability to verify that a student has submitted a particular assignment.
There is no single solution to these and other potential problems. A variety of

mechanisms need to be applied, which may affect the operational efficiency of
the university in the above example. In one organisation, a security policy, or
104
set of rules, would govern the choice of mechanisms for use in response to
particular threats.
In a well-defined network, which contains a known set of access points, a
security policy may be straightforward. However, a single policy may not be
possible in an interconnected network where there can be multiple ownerships
of resources and the number of potential access points increases the security
threat.
In general terms, a distributed computing system may consist of a number of
domains, each one separately managed, operating different security policies
and diverse security mechanisms.
Exercise 6
Consider a patient-monitoring system in a hospital. What do you think would
be a suitable user requirement for the access of such a system? Does this
requirement imply any others? How might you measure the system’s
availability and reliability?
Solution
The first thing to discover about a patient-monitoring system is ‘who are the
users?’ Inside a hospital, the doctors and nurses will be responsible for
monitoring the patients’ health. So they will be the users, not the patients,
although patients certainly have an interest in the reliability of such systems.
A suitable requirement might be, ‘The system should be unavailable for no
more than six hours per year’.
Perhaps this also indicates another requirement, namely, ‘It must be obvious
when there is any fault’. Notice that we didn’t write something like ‘When the
system fails it should sound an audible warning’ as this would be an
unnecessary constraint which is not actually part of the requirements, even
though it might well form part of the eventual solution.
You might measure availability and reliability by the following:
. the proportion of time that the system is operating satisfactorily
. the number of false alarms.
Exercise 7
A company sells computer accessories – paper, printer ink, modems, and so
on. It wishes to introduce an ecommerce system to enable customers who
have credit accounts to use the internet for their purchases. Some customers
pay cash with order and some order on credit. Goods that are ordered on
credit are sent with an invoice to the customers, and payment is required later.
Not all the customers have credit accounts and for those that do there is a
limit to the amount of credit they can have. Customers have a customer
account number to identify themselves.
What security issues are involved in the proposed ecommerce system?
105
Solution
The main security issues are as follows:
1 Authentication is needed to establish the identity of the principal user, that

is, the customer placing the order.
2 Authorisation is needed to check that the customer making the credit order
has a credit account and is authorised to order on credit, and that the
amount of the order does not exceed the credit limit.
3 Repudiation by a customer who claims not to have made the order may
occur. The company might similarly try repudiating an order it received.
4 Private information used in the transaction for authentication, customer
details and the contents of the order may be disclosed.
5 The integrity of the order must be assured, for example the quantities of
items must not change.
Not all the issues would necessarily be addressed by having a component in
the network or computer systems to manage them. For example, non-
repudiation of the order by the customer may be accepted as a commercial
risk and the customer be allowed to return unwanted goods.

In this section we described the different types of non-functional requirements
and their main characteristics and illustrated each type of non-functional
requirement. We looked in more detail at security requirements and the issues
they raise.
106
5 Conformance testing and fit criteria
Conformance testing and fit criteria 5

The software product that is developed should satisfy all the functional and
non-functional requirements that have been identified. In other words, the
software product must conform to its requirements. To find out if this is the
case in the absence of a formal proof (a rigorous mathematical argument), the
product must be tested against its requirements, that is, perform conformance
testing.
However, in order to do this, each requirement needs to be expressed in such
a way that it can indeed be tested. We will therefore consider what criteria can
be added to each functional and non-functional requirement, to allow us to tell
whether that requirement has been satisfied. A fit criterion makes precise some
aspect of a requirement.
A fit criterion is a precise and testable statement of a requirement. It may
specify a quantitative measure for some aspect of the system’s behaviour or
performance, or define some other quality that the system must possess if it is
to meet the requirement. Whatever form it takes, it must be capable of being
tested in an objective fashion. A fit criterion provides a benchmark against
which to decide whether an implementation satisfies a requirement or not. To
test the implementation of a requirement, it would probably be necessary to
add detail that is not available at this point.
The process of attaching a fit criterion to a requirement also helps to clarify
the requirement, and determining the fit criteria will involve interacting with
the client and other stakeholders to check if the criteria being specified are
acceptable and reflect the correct understanding of the requirement. Specifying
fit criteria can therefore be a helpful communication or negotiation tool for
interacting with different stakeholders. When a designer addresses a set of
requirements they should fit each part of the solution to the relevant
requirement – in other words ensure that each part of the solution satisfies the
relevant requirement.
The fit criteria for a functional requirement need to be written in such a way
that you can tell whether or not the product satisfies that requirement, that is,
whether the system succeeds or not in fulfilling the requirement. For example,
consider the requirement:
the system shall accept a credit card number from a client.
A suitable fit criterion might be ‘A valid credit card number has been stored in
the system’. If you were to test whether the implementation satisfied the
requirement you would need to know details of how to check that a credit
card number had been stored, which are not available when you define the
requirements.
The fit criteria for a non-functional requirement need to be expressed in terms
of some measurable quantity, so some scale of measurement must be used. A
scale of measurement is the unit against which the conformance of the product
is tested. It is the unit used in defining the fit criterion. For example, a
107
usability requirement of ‘Time taken to complete a task’ has the scale of time
– microseconds, seconds, minutes, and so on.
To find an appropriate scale of measurement, the description and rationale of
the requirement are analysed to derive a fit criterion and the scale of
measurement is the unit that is specified as a part of the fit criterion.
For example, consider the following non-functional requirement associated
with the above functional requirement:
the credit card number should be accepted securely.
The following fit criterion might be appropriate:
the credit card number should be revealed to a third party in fewer than
0.0001 per cent of cases.
Here the scale is implicitly the number of cases when the credit card number
is used.
The following non-functional requirement contains its own fit criterion, as it is
already expressed in terms of the quantity time:
the credit card number should be accepted within five seconds.
As well as fit criteria for requirements, it is also useful to have fit criteria for
groups of related requirements, for example all the requirements associated
with one use case. (Recall that a use case is a description of how a system is
to be used for a specific goal.) The fit criteria of a use case specify the
measurable goal or outcome of the use case.
It is good practice for the requirements analysts to specify fit criteria by
involving testers early in the development life cycle. In fact, the fit criteria can
be specified as the requirements are discovered and clarified. The testers act as
consultants to specify the fit criteria. From their experience, testers can help to
identify whether or not something needs to be tested and/or can be tested, and
whether the fit criteria being specified is an appropriate measure of the
requirement.
However, it may not be possible to specify the fit criteria when first eliciting a
requirement. The clarification of requirements and fit criteria may involve
visiting users and observing their current work practices, or interviewing
users, or meeting up with domain experts, determining business and resource
constraints, trade-offs between requirements, and so on.
The fit criteria are useful for developers as they develop the product to meet
the standard set by the fit criteria. Fit criteria are also acceptance criteria by
which the client can judge the product against the requirements and then
accept or reject it. Therefore fit criteria may form part of the contract between
the client and the developers.
Sometimes a requirement turns out to consist of several requirements and in
this case each requirement will have to have its own fit criterion. Sometimes
also a requirement has not been properly thought through and, while
determining the fit criterion and clarifying it with the users or client, it
108
becomes clear that it is not a requirement after all and should be deleted from
the specification.
5.1 Examples
We now look at some further examples drawn from a range of systems such
as an ATM machine, websites and the OU TMA/EMA system. These illustrate
that a range of ways of tackling fit criteria are appropriate and that there is
some scope here for creativity.
Example 3 Product failure

Description. The ATM machine shall allow the customer to make a
withdrawal as fast as possible.
The fit criterion can be determined by asking the client, ‘What would be
considered a failure to meet this requirement?’ The client might say that
customers will abandon the transaction if they are unable to make the
withdrawal within 30 seconds, therefore 30 seconds is the acceptable time
limit. The fit criterion might be:
Fit criterion. Ninety per cent of experienced customers should take no more
than 30 seconds to make a withdrawal.
The definition of experienced customers will need to be clarified with the
client. For example, experienced customers could be those who use the ATM
machine at least once in a fortnight. Also, the acceptability of the 90 per cent
success rate to the client will have to be checked.
Example 4 Look-and-feel requirement

Description. The student website for this module shall have a similar look and
feel to other OU module websites.
Fit criterion. The TM354 module website shall conform to the OU web
design and accessibility guidelines.
This fit criteria would be used to test the website by the quality assurance
group before the site goes live.
Example 5 Usability and humanity requirement

Description. The public information kiosk at the railway station shall be
usable by a member of the public who may not speak or read English.
Fit criterion. Fifteen out of 20 non-English speakers or readers shall be able
to use the kiosk without referring to the online help or walking away without
the desired information.
There are other possible fit criteria related, for example, to the languages that
can be used.
109
Example 6 Performance requirement

Description. An existing customer shall be able to complete the checkout
process (specifying the delivery address and delivery mode) on the ecommerce
website as quickly as possible.
Fit criterion. Ninety per cent of existing customers should take no more than
five minutes to complete the checkout process.
However, in specifying this fit criterion, you would need to find out what an
‘existing’ customer means. An existing customer could be one who has
shopped on the site before and their credit card details and preferred addresses
for delivery are already held in a personalised account on the website. You
would also need to check whether 90 per cent is acceptable to the client.
Finally, five minutes should be an acceptable time limit, with some evidence
to back it up – such as observations of existing customers on the website if
the site is already operational and an update is being planned, or from the web
log data. The time limit should be realistic and allow for the slower customers
not to be cut off in the middle of their transaction.
Example 7 Operational and environmental requirement

Description. The railway-ticketing machine shall be usable in a humid
environment.
Fit criterion. The product shall function correctly even when exposed to a
humidity of greater than 80 per cent for up to 48 hours at a time.
Example 8 Maintainability and support requirement

Description. The websites of OU modules shall be updated frequently.
Fit criterion. Updates to OU module websites shall be made weekly and be
visible to students within eight hours of being loaded.
Example 9 Security requirement

Description. The product procurement prices shall be accessible only to
warehouse staff.
Fit criterion. Non-warehouse staff shall be unable to access product
procurement prices.
Example 10 Cultural requirement

Description. The terminology and icons on student websites of the OU shall
not be UK-centred.
Fit criterion. Student websites of The Open University must conform to the
university’s web design guidelines for internationalisation.
Example 11 Legal requirement

Description. The material on the TM354 website shall have all its copyrights
cleared before it goes live.
110
Fit criterion. The rights department has obtained clearance for all copyright
material on the site.
5.2 SAQs and exercises

SAQ 19
(a) What is the first step towards finding whether a solution fits a
requirement?
(b) What is a fit criterion?
Answer
(a) The first step towards finding whether a solution fits a requirement is
to attach a quantifiable measure to the requirement so that it is
testable.
(b) A fit criterion is a quantification or measurement of a requirement,
such that the design solution can be measured to find if it
unambiguously meets the requirement.
SAQ 20
(a) Who needs the fit criteria?

(b) When are fit criteria specified?
Answer
(a) The developers of the product use the fit criteria to develop the
product to meet those criteria. The testers use the fit criteria to
determine whether the delivered product meets the original
requirements. The clients for whom the product is being developed
use the fit criteria as acceptance criteria for the product.
(b) The fit criteria can be written or elicited as the requirements are
elicited, for example once use cases have been drawn up and the
requirements for each task in each use case have been determined.
SAQ 21
(a) What is a fit criterion for a functional requirement?

(b) Do the fit criteria of functional requirements have scales of
measurement?
(c) Does a fit criterion indicate how the functional requirement would be
tested?
Answer
(a) A fit criterion for a functional requirement specifies the completion

of the function of the product that is specified by that functional
requirement. For example, if the required function is to send an
email to a student after a marked TMA has been uploaded by the
111
tutor, then the fit criterion for this requirement is that an email has
indeed been sent to the student and reflected in the receiving
mailbox.
(b) No, the fit criteria of functional requirements do not have scales of
measurement. Success is tested in terms of a yes/no answer that
implies whether the required function is achieved or not.
(c) No, a fit criterion provides some target which, when the solution is
tested, reveals whether the solution conforms to the requirement. The
fit criterion does not indicate how the product will be tested. It
merely states that the tester should ensure that the product complies
with that fit criterion.
SAQ 22
What does the fit criterion for a non-functional requirement specify?

Answer
A fit criterion for a non-functional requirement specifies a value or values,

on a particular scale of measurement, that must be attained by the property
or quality that the requirement is concerned with. These values should be
realistic, as discussed in the performance requirements example.
Exercise 8
How might you determine the fit criterion for the performance requirement,
‘The customer services personnel should be able to respond rapidly to
customer queries’?
Solution
Talking to the users about their own expectations and those of their customers
might reveal that the preferred task time is one minute and currently it takes
three minutes to answer a customer query because of a cumbersome search
facility on the existing system. So the fit criterion for this requirement might
be something like, ‘The customer services personnel must be able to find an
answer to a customer’s query in not more than one minute of a customer’s
call.’
This example shows that the fit criterion is backed by empirical data of the
current situation.
Exercise 9
Here is an example of a situation and a possible fit criterion for a requirement
to address it.
Situation. Customers send letters to the customer services department
complaining about unsatisfactory experiences with a particular product.
Fit criterion. To determine customer satisfaction, a possible fit criterion would
be the number of letters complaining about the product within a defined time
period.
112
Give suggestions of possible fit criteria for performance requirements to

address the following situations:
(a) Customers return the product if they are unhappy with it after a purchase
has been made.
(b) Users don’t find the system user-friendly because of the number of errors
that are made in completing a task.
(c) Staff members are satisfied and fewer of them are leaving the
organisation.
Solution
(a) To determine customer satisfaction, a possible fit criterion would be the
percentage of product items returned within a particular time period as
compared with the number of products sold within that time period.
(b) A possible fit criterion would be that errors shall not occur on more than a
specified proportion of the occasions on which the task is executed.
(c) A possible fit criterion would be that the staff turnover does not exceed
some specified level and there is a month-on-month reduction in the
number of staff leaving.
Exercise 10
Listed below are some requirements and their fit criteria from the requirements
tool in Exercise 4. Assess the suitability and clarity of the fit criteria.
(a) Requirement. The product shall enable the user to view the summary of all
requirements.
Fit criterion. The product should show a summary of all requirements.
(b) Requirement. The product shall show all requirements that conflict with
each requirement.
Fit criterion. The product should show all conflicts with each
requirement.
(c) Requirement. The product shall perform a range of checks on the set of
requirements.
Fit criterion. The product should display the results of a range of
checks.
Solution
(a) The fit criterion doesn’t make it clear what the ‘summary’ consists of.
Also, it doesn’t make it clear whether it is the summary of each
requirement or a composite summary of all the requirements.
A better fit criterion might be that a list will be produced giving a one-
line summary for each requirement. This might mean that you need to
enter a name for each requirement such as ‘Accept a reservation’ at an
earlier stage.
(b) It’s not clear from the fit criterion whether the requirements that conflict
with one requirement need to be shown or whether it’s the nature of the
conflicts that needs to be shown.
113
A better fit criterion might be that for a given requirement state the

number of any requirement that conflicts, along with the reason.
(c) The requirement and the fit criterion do not make it clear what the range
of checks is nor what the result should consist of.
A better fit criterion might be that the requirements will be checked and
the number of any requirement where all fields are not correct will be
reported as well as the number of any requirement that conflicts with
any other.
Exercise 11
Are fit criteria always attainable?
Solution
No. Fit criteria should specify realistic values, but even then they are not
always attainable. Whether they are actually attainable or not depends on what
happens during the development cycle. Constraints can arise when attempting
to achieve the fit criteria because of, for example, the product’s operating
environment, the client’s budget, or time. Measurements of fit criteria can only
be made in reasonable ways and in reasonable times.

In this section we discussed the need for, and the concept of, fit criteria and
applied them to different types of functional and non-functional requirements.
114
6 Representing the requirements
Representing the requirements 6

We discussed requirements documentation in Section 2, together with different
perspectives on how much documentation should be written. Here, we
introduce the Volere approach by Robertson and Robertson (2012), which is a
guide for documenting requirements in a rigorous manner. In this edition of
their book the authors suggest that there are different ways to write the
document and that some sections may be written first rather than following the
sequence of the Volere template. You should therefore view this template as a
tool that may help you recording what is important but that should be used
wisely to help a project and not just for the sake of using a tool.
6.1 The Volere template

The Volere template is a template for a document that collates all the
requirements of a system, together with other issues that may affect those
requirements. The template provides a sort of container in which the
information can be organised systematically. The following describes the
template in its entirety, although you will use only parts of it.
A requirements document is organic. It grows and changes during the
development of a project. The Volere template supports a disciplined way of
recording requirements as they are discovered and refined. The template is
organised into five main sections, each including a number of requirements
categories.
Volere template
Project drivers
These are the reasons and motivators of the project.
1 The purpose of the project. This is the reason for building the
product, and the business advantage if it is done. It describes the
problem faced by a customer, or a business opportunity a customer
wants to exploit, and it explains how the product is going to help.
For instance:
We are expanding our business internationally; our current
billing system is based on pounds sterling; we need a new
system that can deal with foreign currency.
2 The stakeholders. These are the people and organisations, other than
the users, with a vested interest in the product. They include the
client, the customer, other stakeholders and the intended end-users of
the product. Their description should also include how they affect the
product’s usability requirements. For instance:
115
The users of the system are potential passengers interested in

train timetables and journey information. We can’t assume they
are in any way familiar with the technology; they should be
able to use the system with hardly any support.
Project constraints
These are restrictions and limitations that apply to the project and the
product. In this section of the template the following types of
information are recorded.
3 Mandated constraints. These are constraints on the way the product
must be designed or on the project itself. For instance, they could
state how the product should look or which technology it should
comply with; or existing software that should be considered; or they
could define the environment in which the product will work; or they
could place restrictions on the development budget and time. Note
that these are not requirements in themselves, but they put restrictions
on the requirements: only requirements that can be satisfied within
the given constraints can actually be addressed by the project.
Typically constraints are raised by management policies.
4 Naming conventions and terminology. This is the vocabulary of the
project, including terms and definitions that are commonly used in
communication with the stakeholders. A more formal companion to
this, the glossary, is also introduced incrementally in the project to
include the definitions of all relevant and technical terms.
5 Relevant facts and assumptions. These are external facts that may
have an effect on the product and the assumptions made by the
project team, but they do not necessarily translate into requirements.
For instance, for a system that should monitor and forecast the de-
icing of frozen roads in certain geographical regions, relevant facts
could be:
One ton of de-icing material is required to de-ice 2 kilometres of

single-lane carriageway.
or
No more than 100 users will be connected to the system at any one
time.
or
The system will sample the road surface temperature every

200 milliseconds.
Functional requirements
These cover the functionality of the product. They include the following.
6 The scope of the work. This defines the boundaries of the business
area that will be improved by the product, and this area fits within its
environment. To be able to set the product boundaries, you first need
to understand the context of the system – the working environment in
116
which it will operate. This is typically represented by a context model

that shows the work to be done at the centre and all the elements in
the environment it will connect to. The elements can be people,
organisations and other systems (hardware and software).
7 Business data model and data dictionary. This defines the data that is
manipulated.
8 The scope of the product. This defines the product boundaries. Once
the scope of the work has been determined the scope of the product
is typically represented by a use case diagram representing the use
cases of the product and those who interact with them.
9 Functional requirements. These are what the product must do to
contribute to the product goal. They could be functions or actions the
product must perform. For instance:
The product should record road weather conditions
is a function, while
The product should alert the operator when the temperature

falls below 0 °C
is an action.
Non-functional requirements
These are the properties the product must have. They include the
following.
10 Look-and-feel requirements. The intended appearance and style of the
product.
11 Usability and humanity requirements. These are based on the intended
users and ergonomic acceptance of the product.
12 Performance requirements. How fast, safe, accurate, reliable,
available, and so on the product must be.
13 Operational and environmental requirements. The product’s intended
operating environment.
14 Maintainability and support requirements. How easily the product can
change and what support is needed.
15 Security requirements. The access, integrity, privacy, audit, and
immunity of the product.
16 Cultural requirements. Human factors that may affect the product.
17 Legal requirements. Conformance of the product to applicable laws
and standards.
Project issues
These are not requirements, but concerns that are brought to light by the
requirements activities. They appear in the requirements document
because they help to clarify the requirements further.
117
18 Open issues. These are issues that have arisen from the requirements
activities, but are not yet resolved. These issues may have to do with
changes that have occurred in the business, the requirements or the
project.
19 Off-the-shelf solutions. This is a record of ready-made components
that might be used in the project and their impact on the product
requirements.
20 New problems. This category is used to highlight possible problems
caused by the introduction of the product, for instance changes that
are required in current working practices or the need for special
training.
21 Tasks. This category highlights the effort required to deliver the
product, whether it is a complete build or the acquisition of existing
off-the-shelf solutions.
22 Migration to the new product. These are things that need to be done
after the product has been installed but before it can work
successfully. Typically, they include tasks to convert data or processes
from existing systems.
23 Risks. These are the risks the project is likely to face, together with
strategies for coping, should they become problems at some point
during the project.
24 Costs. This is an estimate of the cost or effort needed to build the
product.
25 User documentation and training. The plan for writing the user
instructions and documentation.
26 Waiting room. This covers requirements that for some reason cannot
be included in the current release of the product, but might be
included in future releases.
27 Ideas for solutions. These are design ideas that may become useful.
We acknowledge that this document uses material from the Volere

Requirements Specification Template, copyright © 1995–2012 the
Atlantic Systems Guild Limited.
Source: Robertson and Robertson (2012)
Functional and non-functional requirements are the core of the requirements

document. While all other sections of the template can be filled in as freestyle
text, the Volere approach recommends a more formal recording of functional
and non-functional requirements.
The following information should be recorded for each functional and non-
functional requirement, in what is known as a requirement shell or a snowcard
(see Figure 3):
. requirement number – this is to identify the requirement uniquely
. event/use case – identify which use case or event is associated with this
requirement
118
. description – a one-sentence statement of the intent of the requirement

. rationale – why the requirement is considered important or necessary
. originator – who raised the requirement in the first instance
. fit criterion – this is the acceptance criterion, written in a quantified
manner so that the solution can be tested against the requirement
. customer satisfaction/dissatisfaction – this is an indication of the
customer’s reaction to the requirement’s omission from the solution
. priority – a mark of the value of the requirement for the customer
. conflicts – requirements that contradict this one or make this one less
feasible
. supporting materials – link to other documents to help understand the
requirement
. history – origin of and changes to the requirement.
There are two particularly notable entries in this list. First, history indicates
that requirements do not remain unchanged during the development process.
Requirements are recorded, refined and even discarded, usually through a
process of analysis and negotiation with the system’s stakeholders.
Second, conflicts indicate that requirements do not exist in isolation, but
generally relate to other requirements by being in conflict with them. This
means that changes to requirements may need to be propagated to other
requirements, and that conflicts need be identified and resolved.
119
Figure 3 Requirements snowcard
The complexity of the Volere template is a clear indication that managing

requirements of realistic systems is not a trivial task. Tracking requirements
and their changes throughout a project is vital to the success of the project, as
a customer’s satisfaction depends on it. In large projects, the use of tools for
requirements management is beneficial, if not essential.
SAQ 23
What is the advantage of capturing requirements using a template rather

than adopting your own format?
Answer
The template is divided into a fixed set of categories, which means you are
less likely to forget some types of requirements. It also saves having to
work out what categories of requirements to deal with each time you start a
new document. It helps to communicate requirements to other developers
because if there is a standard template then everyone will know what
information to expect and in what order. It might also allow projects to be
compared and even requirements to be reused more easily.
120
6.2 An agile representation of requirements

In Section 3.1 we mentioned user stories as a way to record requirements.
User stories usually correspond to low-level requirements. The use of cards is
popular with agile approaches, and user stories are usually represented in a
card as in Figure 4.
Figure 4 User story card
The user story in a card is, however, not a full documentation of a

requirement. In Figure 4, the back of the card is annotated with
‘Confirmations’ but you may find other annotations, for example ‘Constraints’,
‘Notes’, or references to other artefacts such as models on a whiteboard.
Cards are not expected to be complete representations of a requirement –
rather, they are intended to trigger conversations about any additional detail
that might be needed. The detail is represented in the acceptance tests written
for each user story. An acceptance test will determine what is needed for the
implementation to satisfy the user story (Cohn, 2004).
User stories are usually gathered in a prioritised and structured list; in Scrum,
for example, a product backlog is the agile correspondent to a requirements
document.

In this section we introduced the Volere template for the description of
requirements. We will give a detailed example of how the Volere template is
used in Unit 4. We also briefly introduced cards as a representation commonly
used in agile development to trigger discussions on requirements.
121
7 Summary
In this unit you read about the importance of understanding the different types
of requirements and other relevant information. You identified the differences
between functional and non-functional requirements and the ways in which
each of these can be recorded. The importance of attaching measurable fit
criteria to each requirement was established. Finally, you saw how to make
use of the Volere template to help ensure that all the categories of
requirements are covered, and you briefly considered an alternative agile
approach with different demands on documentation.
After studying this unit you should be able to:
. understand the nature and importance of requirements
. describe the activities of a requirements engineering process
. be aware of an agile approach to requirements
. define and distinguish between functional and non-functional requirements
. describe the various types of non-functional requirements
. discuss the relation between requirements and testing
. produce clear functional and non-functional requirements
. produce measurable, and hence testable, functional and non-functional
requirements
. discuss the relation between requirements and testing
. use a requirements template to write a requirements document in a
structured way.
122
References
Alexander, I. F. and Stevens, R. (2002) Writing Better Requirements, Harlow,
Pearson Education.
Atlantic Systems Guild (2010) Atlantic Systems Guild [online]. Available at
www.systemsguild.com (Accessed 6 November 2013).
Beck, K. and West, D. (2004) ‘User stories in agile software development’, in
Alexander, I. and Maiden, N. (eds) Scenarios, Stories, Use Cases: Through
the Systems Development Life-Cycle, [Online] Chichester, Wiley, pp. 265–79.
Available at http://libezproxy.open.ac.uk/login?url=http://proquestcombo.
safaribooksonline.com/9780470861943?uicode=open (Accessed 13
February 2014).
Boehm, B. and In, H. (1996) ‘Identifying quality-requirement conflicts’, IEEE
Software, vol. 13, no. 2, pp. 25–36.
Cohn, M. (2004) User Stories Applied: For Agile Software Development,
[Online] Boston, MA, Addison Wesley. Available at http://libezproxy.open.ac.
uk/login?url=http://proquestcombo.safaribooksonline.com.libezproxy.open.ac.
uk/0321205685?uicode=open (Accessed 13 February 2014).
Eveleens, J. L. and Verhoef, C. (2010) ‘The rise and fall of the chaos report
figures’, IEEE Software, vol. 27, no. 1, pp. 30-36.
Robertson, S. and Robertson, J. C. (2012) Mastering the Requirements
Process: Getting Requirements Right, 3rd edn, [Online] Boston, MA, Addison
Wesley. Available at http://libezproxy.open.ac.uk/login?url=http://
proquestcombo.safaribooksonline.com/book/software-engineering-and-
development/software-requirements/9780132942850 (Accessed 13
February 2014).
Sommerville, I. (2011) Software Engineering, 9th edn, Boston, Pearson.
Standish Group (2010, 2012) Standish Group Blog [Online]. Available at
http://blog.standishgroup.com (Accessed 9 September 2013).
123
Unit 3 From domain modelling to
requirements
Contents
1 Introduction 129
2 Business rules and business processes 130
2.1 Business rules 130
2.2 Business processes 132
3 Simple use case models 145
3.1 Use cases 145
3.2 Emphasis on the user 146
3.3 Stepping from the problem to its solution 148
3.4 Actors 150
3.5 Describing use cases 151
3.6 Use cases in development activities 156
3.7 Use cases and agile development 160
4 More details on use case models 166
4.1 More about actors 166
4.2 Modelling the relationships between use cases 167
4.3 Problems with use cases 175
5 Getting users involved 184
5.1 Prototyping for and with the user 184
5.2 Linking activities to user interfaces 186
6 Summary 191
References 192
1 Introduction
Introduction 1
In this unit, we study some well established techniques for capturing and
documenting user requirements and system behaviour.
We start by looking at the business domain as the context in which a software
solution may be applied. The main concepts in a business domain are its
resources (people, products, information and materials), processes (the
activities that manipulate, transform and use these resources), rules that
constrain the processes and goals that define the purpose of the business
(Eriksson and Penker, 2001). Understanding the business that it is meant to
support is an essential step in developing any software solution. The Unified
Process (UP) calls this the business modelling discipline; we use the term
domain modelling. In this module we will discuss enough of the business to
understand the context and the requirements for a system within that context.
In-depth discussion of business modelling is outside the scope of this module.
Section 2 introduces the concepts of business rules and business processes,
together with activity diagrams as the technique for modelling these processes.
Once a decision has been taken to develop a software system to solve a
specific problem within a particular business, the initial set of user
requirements can be modelled. Understanding and modelling requirements for
a software solution, an activity that UP calls requirements discipline requires
understanding the business domain of the solution. Sections 3 and 4 of this
unit introduce use cases as a tool for requirements. Use cases record chunks of
functionality that users want from a system. You will study relationships
between different use cases and how they represent interaction of the users
with the intended system.
Finally, in Section 5, we consider how prototyping can help with requirements
engineering. At the end we bring all these ideas together and look at how
activity diagrams can help us identify where user interfaces will be needed.
129
Unit 3 From domain modelling to requirements
2 Business rules and business processes

2.1 Business rules
Business rules constrain how a business is run. They are not specific to any
project but they influence each project’s development – they typically include
policies, physical laws, government laws, etc. Business rules reflect the way
the business works, independently of any new system being introduced in that
business domain.
Understanding the business rules is key to modelling a business and to
specifying how any system to be developed can support the correct
functioning of the business processes. There is a clear distinction between the
business processes and the constraints imposed on them. For example, in a car
rental company, renting a car is one of the processes of the business – one
business rule that may apply to this process is that the car allocated is the
lowest-mileage car that is available in the chosen group.
Example 1
Consider the following extract from a business description.
A typical lending library keeps a stock of books for the use of its members.
Each member can take out a number of books, up to a certain limit. After a
given period of time, the library expects members to return the books that
they have on loan.
When borrowing books, a member scans their card in the library self-service
scanning machine and then scans the barcodes of their chosen books. Each
new loan is recorded in the system for that member. When a book is on loan
to a member, it is associated with that member – possession of the book
passes from the library to the member for a defined period. The normal loan
period for each book is two weeks. If the member fails to bring the book
back on or before the due date, the library imposes a fine.
We can identify two business processes in this domain: issue a book and
return a book.
The following business rules could characterise the way this business operates.
. There is a limit to the number of books a member can take out.
. A loan is for a period that is normally two weeks.
. A loan can be renewed only three times.
. Late returns incur a fine.
Representing business rules

It is important that business rules are identified and recorded, as they are the
basis of decision making. As they may apply to different projects it is wise to
keep them documented separately from individual projects. They are also the
part of the business that is more likely to change as the business adapts to
external pressures, to become more competitive or to seize new opportunities.
130
Ideally, a record of the business rules should be kept, to provide quick and
easy access whenever there is a change.
Business rules need to be correctly represented and they should support the
business processes and strategy. Their understanding is important for assessing
the quality of any solution, i.e. the verification and validation activities:
. Verification is the set of activities that ensure that a solution is being
correctly developed, in this case that it is taking into account the business
rules.
. Validation ensures that what is being built satisfies the business, i.e. that
the business rules implemented are the ones that the business wants.
Verification can be done automatically if the rules are well specified – the
models in development should be checked to ensure that they comply with
these rules. Validation of the rules is not an easy process and can only be
done through review by the stakeholders – are the rules the ones intended for
what the business wants to achieve? There is an argument for expressing
business rules in natural language, as they need to be read and understood by
business people. The language used should be well defined and structured, so
that verification can be made easier if not automatic. In Unit 2, we saw that
user stories can be annotated with constraints to express non-functional
requirements – these annotations can also be used for business rules. A simple
annotation may be a sufficient record of a business rule that is specific to a
project. A user story such as ‘As a library member I want to be able to renew
a book over the phone’ can be annotated with the business rule that constrains
the number of renewals. It is important however that traceability can be
established between the implementation and the business rules.
UML and Object Constraint Language (OCL) can also be used to represent OCL is a formal language used to
constraints. Some of the rules identified for the lending library can be represent constraints in UML 2
represented in a UML model either as annotations or using the features of the models.
model. We will look later at how each model represents the constraints
imposed. There are benefits in using OCL to represent business rules more
formally, in particular enabling automated verification. However the
representation of constraints in UML and OCL is always done in conjunction
with other models. Business rules are not first class citizens in UML – there is
no UML notation to model them explicitly and independently of other models,
so they are more difficult to manage. Ideally you should be able to analyse
and validate business rules and change them as the business evolves.
Traceability should be established between the rules of the business and their
representation throughout the development process and implementation.
SAQ 1
(a) What are the important properties that a representation of business

rules should have?
(b) Consider whether business rules can be modelled in UML; discuss
the consequences in the light of the properties in your answer to (a).
131
Answer
(a) The important properties are as follows:

◦ Business rules that apply to the whole business should be
represented separately from project specific models.
◦ They should be easy to verify (possibly automatically) and
validate.
◦ They should be represented in a readable language that is
easy to verify.
(b) UML can support the specification of business rules either as

annotations to the models or in a more formal way through OCL.
However UML and OCL do not provide a separate explicit notation
for business rules. As a consequence, it does not:
◦ facilitate documentation of the rules independently of other
models
◦ facilitate their analysis, validation and change
◦ facilitate their traceability from the business needs to the
software solution.
2.2 Business processes

Business processes define what is done in a business, by whom, in what
order, needing which resources, and with what consequences. Much has been
written on process modelling, and there are many techniques to do it. A full
presentation of such techniques is well outside the scope of this course. The
main reason we look at business processes is to get an understanding of what
a business does, and to gain the domain expertise needed to develop software
Workflow is defined as ‘a solutions in the business context.
sequence of activities that
produces a result of observable
value’ (Krutchen, 2003). Here we Representing business processes
discuss how to represent these If you are familiar with the UML technique of activity diagrams and their use
activities.
in representing business processes, you can skip this subsubsection, up to
‘Activity diagrams and workflows’.
In this module we model business processes using UML activity diagrams.
An activity diagram shows a process as a set of activities and describes how
they must be coordinated – which ones depend on others having been
completed first and where activities can be carried out in parallel.
Activity diagrams help us to understand the business situation before any
decisions are taken about a software solution and its boundaries. They model
behavioural aspects of the domain.
The notion of an activity is very much dependent on the specific context. An
activity could be a task that a person or a computer might perform. In this
section the emphasis is on the use of activity diagrams to support the
understanding of a business context. When modelling requirements for a
132
solution to a business problem, developers try to understand the problem

domain. They want to know what users are trying to achieve in their particular
domain, be it a hotel, a lending library, a bank or a manufacturing process.
Example 2
Suppose, after a hard day’s work, you decide to make yourself a hot drink.
What do you do to achieve that goal? What are the actions and how do you
organise them?
We start with a process called make hot drink. At the centre of this task is
boiling water in a kettle. Usually, there are two steps.
1 Fill the kettle with water.
2 Boil the water.
There are also some decisions to be made, such as the choice of beverage. We
will consider instant coffee (as a particular scenario) to begin with. Finally,
you need a cup to drink from. Figure 1 shows an activity diagram that models
the process of making a hot drink of instant coffee with milk. It shows one
way of preparing a cup of coffee. ‘… Pour boiled water into a cup containing
coffee. Add milk. Drink coffee.’ Of course, there are other ways of achieving
the same result, and this will be true of problems in other domains.
initial
state
enter
kitchen
synchronisation
bar (a fork)
activity
fill kettle get cup
transition
boil add
water coffee
synchronisation
bar (a join)
pour drink
water add milk coffee
final
state
Figure 1 Activity diagram for making a cup of coffee
133
The basic elements of an activity diagram are activities and transitions. The
completion of an activity triggers an outgoing transition. Similarly, once the
Strictly, the term used in UML 2 incoming transition has been triggered an activity may commence.
for a unit of behaviour is action,
while an activity comprises a In an activity diagram, activities are shown as rounded boxes, while
series of actions and is transitions are shown as lines with arrows. There are two predefined activities,
represented by a whole activity start and stop, which are represented as filled circles (see Figure 1). A diagram
diagram. In this module however may include more than one stop node if it makes it clearer.
we will use the term activity for
each unit of behaviour. The order of the activities of boiling the water and adding coffee to a cup is
immaterial and so we show them as two concurrent flows in the diagram. The
model shows that we expect some boiled water in the kettle and some coffee
A transition may involve the
execution of actions and these in a cup before we pour the water into the cup. Figure 1 shows two
need to be completed (even if synchronisation bars, denoted by thick horizontal lines. The upper one
they take negligible time) before denotes a fork and the lower one a join. The upper bar allows for separate
the destination activity can activities to be carried out in parallel, so between the two synchronisation bars
commence. the two separate strands can be performed concurrently. You could, for
instance, get a cup and then add some instant coffee to it before filling the
kettle with water and turning it on. Alternatively you might start boiling the
water before getting the cup and coffee. Or you could invite a friend to add
the coffee to the cup while you fill the kettle! The lower bar prevents you
from carrying on until both strands that lead into it are completed. You cannot
add the water until it has boiled and there is coffee in the cup.
The diagram is annotated with notes to indicate the features of the activity
diagram. In UML, a note is shown as a rectangle with the top right-hand
corner folded down. A dashed line is used to attach the note to the model
element to which it refers.
Example 2 showed one way of making coffee. You can model alternative
ways of making coffee in different activity diagrams. The ability to model
alternatives allows you to investigate different ways of working. For example,
you might model alternative ways to process the lending and returning of
books in order to provide a gain in efficiency.
In an activity diagram the transition from one activity to the next is denoted
by a stick arrow. It signifies that one activity has been completed and that it is
time to move on to the next one. For example, in Figure 1, once you have
filled the kettle you can boil the water by turning it on. We have assumed that
most people use hot rather than cold water when making coffee. So you wait
until the water has boiled before you add it to the cup containing the coffee.
When there are two or more alternative ways out of an activity, it is essential
to indicate under which circumstances each transition is taken. Since the flow
in an activity diagram is intended to proceed from one activity to the next, it
would not be sensible to have two or more possible outflows without giving
some idea of how the individual who is carrying out the activities might
choose between them. UML provides decision nodes to represent alternative
mutually exclusive, ways out of an activity. A decision node is drawn as a
diamond. Figure 2 shows how decision nodes are used to deal with the
possibility that the coffee cup is dirty.
134
In Figure 2, the flow between activities is constrained with a Boolean test,

known as a guard, which is represented inside a pair of square brackets. Each Guards are associated with
of the transitions leaving the first decision diamond has a guard to determine transitions. A transition takes
which path should be taken under a given condition. One outgoing transition place only if its guard evaluates
to true at the time the flow of
should always be taken – this means that exactly one of the relevant guards control reaches that transition.
must always evaluate to true. In this example, if the cup is clean you take one
path, but if it is dirty you take the other path. In an activity diagram, the only
label that can be applied to a transition is a guard that is intended to constrain
the flow from one activity to the next.
enter
kitchen
[dirty]
fill kettle get cup wash cup
[clean]
boil add
water coffee
pour drink
water add milk coffee
Figure 2 Using decision diamonds
A diamond shape is also used as a merge node, which brings together

alternative mutually exclusive flows, as shown in Figure 2. A merge node will
be reached only by one of the alternative flows and has a single outgoing
flow.
An activity has only one transition into and out of it. This is enforced by
decision and merge nodes for alternative outgoing and incoming transitions,
and by synchronisation bars for concurrent outgoing (fork) and incoming
(join) transitions.
As you find out more about the business domain in question you may need to
perform a further decomposition of the activities in your original diagrams.
For example, the activity fill kettle in Figure 1 may be better represented by
showing the steps involved in filling a kettle, especially when you have more
than one type of kettle to choose from. Modelling alternatives helps you
investigate possible improvements in a given process. However the
investigation of alternatives for process improvement purposes requires
135
knowledge of the problem domain. Making coffee is probably a very familiar

domain to you. In practice, the domains you are likely to meet will not be as
familiar.
SAQ 2
(a) What causes a transition in an activity diagram?

(b) What is a synchronisation bar, and when is one used in an activity
diagram?
(c) Figure 1 represents a particular way of making a cup of coffee.
Suggest a reason why the activity add coffee has been placed before
the joining synchronisation bar rather than immediately after the bar.
Answer
(a) A transition in an activity diagram is caused by the completion of

an activity.
(b) A synchronisation bar is used to mark the point when two or more
activities can take place concurrently (a fork) or when a number of
concurrent tasks must finish before continuing to the next activity (a
join).
(c) When the kettle is full and you are waiting for the water to boil,
there is some time that you can use to add coffee to the cup. Placing
the activity ‘add coffee’ after the joining synchronisation bar rather
than before it would mean that you would have to wait to carry out
the activity until the water had boiled, and the overall time taken for
the task would be longer than for the activity diagram shown in
Figure 1.
Activity diagrams and workflows

A role is the behaviour of a A business process is intended for a particular group of roles taken by people
person participating in a process. carrying out, and interacting with, the process. This flow of activities that
One person may take different takes place in a business process is known as a workflow.
roles – for example, in a library
the same person may take both An activity diagram can be used to represent the workflow of an existing
the role of a librarian and that of process. It represents the sequence of activities and helps identify the stages at
a member. That is why we talk
which each role requires some interaction with the process. This is of
about roles rather than people.
particular benefit when we want to investigate the steps that people – and any
existing systems – take in order to do their jobs. When modelling a workflow
that involves more than one role, it is possible to identify which role is
responsible for a particular activity. To do this in UML, we partition an
activity diagram into swimlanes – one swimlane for each role.
Example 3
Consider the library described in Example 1
Book issue
Figure 3 illustrates the process of issuing a copy of a book in a library. The
activity diagram has two swimlanes separated by a vertical line. The left-hand
136
swimlane contains the activities that a library member performs when

borrowing a book, while the right-hand swimlane shows the library’s self-
service system workflow for the same process (‘issue copy of book’).
Member LibrarySelfServiceSystem
find a book
[more books]
[no more books]
present card scan card
present book scan book
[more books]
record loan
[no more books]
leave with
books
Figure 3 An activity diagram for issuing a copy of a book
The diagram shows that a member looks for books on the library shelves and
selects one or more to borrow. The library needs a record of each book that
has been borrowed. So the member must first scan their library card and then
scan the selected books in the library scanning machine for the loans to be
recorded.
Figure 3 shows that transitions may cross swimlanes. The diagram shows the
repetitive business activity being performed by the member for several copies.
137
The activity record loan is likely to involve:

. identifying the particular copy of a book
. identifying the member who wants the book
. recording the loan – creating a link between the member and the copy
. identifying the period of the loan.
Book return
We will now consider how the books are returned. This is illustrated in
Figure 4. When the member brings the books back into the library they have
to scan their card and then scan the books and drop them in a postbox.
Figure 4 does not include any other activity inside the library, such as the
librarian activity for returning copies of books to the library shelves. To do
this, we would need to know more about how restocking shelves takes place.
It is likely that we would model this as a different process since it will happen
at a different time (when a number of books have been returned, i.e. not after
each member has returned books) and also doesn’t involve members at any
stage.
bring books
[more books]
record return
[no more books]
drop books
in postbox
Figure 4 An activity diagram for returning a copy of a book
138
Although the question of overdue books was identified in the description of

the library, we have not addressed handling fines. If we were designing a
library system in real life we would need to investigate the fines system at this
point by asking the library staff. This could lead to an amendment of the
activity diagram to reflect the processes for handling fines and the
specification of business rules to express constraints that should be met (such
as the level of fine for different cases). However we will not be pursuing the
issue of the fines system here.
SAQ 3
(a) How does the partitioning of activities into swimlanes help us

understand a set of activities?
(b) Give one reason for modelling a workflow in an activity diagram.
Answer
(a) Swimlanes group activities associated with different roles. The

swimlanes show the role that is responsible for each activity.
(b) Activity diagrams represent the sequence of activities. When you are
modelling a workflow that involves more than one role, it is possible
to identify which role is responsible for a particular activity. An
activity diagram can help identify the stages at which each role
requires some interaction with the process.
Exercise 1
Figure 1 shows one way to model the preparation of a cup of coffee with
milk. Redraw the figure to allow the choice between coffee with milk and
coffee without milk.
Solution
We can add a decision node to control the addition of milk to the coffee, as
shown in Figure 5.
139
enter
kitchen
fill kettle get cup
boil add
water coffee
pour drink
water coffee
[no milk]
[milk]
add milk
Figure 5 Extending the coffee-making activity diagram
We can choose either to add milk or not to add milk. This choice gives rise to
alternative paths to the final activity of drinking the coffee. In contrast, the
joining synchronisation point requires that the water has boiled and that there
is coffee in a cup.
Note that with synchronisation bars, both paths are taken and execute
concurrently. With decision and merger nodes, exactly one path is taken and
there is no concurrency.
Exercise 2
Draw an activity diagram to illustrate the preparation of a pot of tea, replacing
the activities relating to coffee shown in Figure 1. The new diagram should
allow the choice of both milk and sugar when the tea is poured.
Solution
There are a number of concurrent activities that allow a fairly efficient
workflow. The activity diagram in Figure 6 shows one of the ways of making
a pot of tea. There are a number of possible ways of modelling this, and your
diagram could be slightly different but still ‘correct’. For example, ‘get cup’
could be concurrent with ‘pour water into teapot’, and some people put the
sugar and milk before pouring the tea in the cup. Note that we have not
represented all possibilities, such as warming the teapot before use or the use
140
of a spoon when milk and sugar are involved. The activities of choosing
whether or not to add milk and sugar to a cup end with a diamond that joins
together the paths representing the different choices. The convention is that
the paths out of a decision node should be brought together at some stage at a
merge node or activity. For example, the high-level activity of deciding
between sugar and no sugar has been expanded in such a way that there is
only one path into the decision node and one way out from the merge node.
enter
kitchen
fill kettle
get
get tea teapot
boil
water
add tea
to teapot
pour water
into teapot
get cup
pour tea
[no milk] [no sugar]
[milk] [sugar]
add milk add sugar
drink tea
Figure 6 An activity diagram for making tea
141
Example 4
In Example 3, you saw one way to represent the borrowing and returning of
books in a library. Here we use Figures 3 and 4 to produce a single activity
diagram that models the borrowing and returning of books. When two
processes have some commonality you may want to show this by representing
them in a single diagram. But you need to be aware that diagrams may
become too complex and combining them may not be such a good idea.
To combine processes we show you a simplification of notation. We said
above that a merge node has only one outgoing node and that a decision node
has only one single input. The UML allows the combination of a merge node
with a decision node using the same symbol as shown below. We show this
here as you may encounter similar examples of combined nodes, but we
suggest that you avoid using these as they make diagrams complex.
merge merge and decision nodes

node together using the
same symbol
decision
node
decision and merge nodes

decision together using the
node same symbol
merge
node
Figure 7 Combining merge nodes and decision nodes
In the combined activity diagram, we use a series of merge and decision

nodes to control the flow between the different activities for borrowing and
returning books. Figure 8 includes all of the activities from Figures 3 and 4.
The initial combined node is needed to bring the borrower and returner’s
workflows together. The next combined node has a merge of the outputs from
find a book and bring books and a decision for the inputs into the decision
node leading to find a book and the activity present card. The last combined
node has a merge of the outputs from record loan and record return and a
decision for the inputs into the three activities present book, leave with books
and drop books in postbox.
142
[returner]
bring books
[borrower]
find a book combined

merge and
decision node
[borrower looking
for more books] [no more
books or returner]
[returner]
[more books] [borrower]
record loan record return
[no more combined

[no more books merge and
borrower] books returner]
decision node
leave with drop books

books in postbox
Figure 8 An activity diagram for borrowing and returning books to the library
Although we have made several assumptions here, in reality we would ask the
librarian what happens in practice.
143
A cautionary note should be heeded at this point. The activity diagram is

becoming complex and more difficult to comprehend. Keeping the two
original processes separate may be the better course of action.
Exercise 3
In Example 4, there are several assumptions that have been made about what
a member can and cannot do. Can you identify one such assumption?
Solution
The main assumption is that a member cannot be a borrower and a returner at
the same time. This is illustrated in the decision node at the bottom where the
member leaves with books or drops books off. The decision node at the top
also makes that assumption.
Example 4 and Exercise 3 highlight the complexities that can be illustrated in

an activity diagram for even relatively straightforward processes. You should
avoid combining diagrams when the complexity increases and they become
much less readable.

Business processes define the activities that take place, their ordering and the
roles required to carry them out. Business processes can be represented by
activity diagrams.
Activity diagrams are a way of understanding the workflows within the
business domain. They allow you to record the things that users do or want to
do. From a simple problem description, you can show the flow of control
between the activities that are carried out by different roles.
144
3 Simple use case models
Simple use case models 3

This section introduces a means of defining what a proposed system should do
from a user’s perspective. This can provide the basis for a contract between
the customer and the developer.
3.1 Use cases

Your aim is to construct a software system that will meet the needs of its
users. Hence you must identify who does what. To do this, you search or
explore the problem description, any domain models and the initial set of user
requirements to determine the people involved, the work that they do and the
events that trigger some work to be done. The domain models may include,
for example, activity diagrams representing the business processes in the
domain. Later in this module you will also discuss models that represent the
structure of the domain.
During the exploration of the problem and the domain, you are likely to
identify a variety of people, some of whom may be playing a number of
different roles and may be associated with different business events. If you
modelled business processes, you will have already identified roles interacting
with these processes. Some of these roles will be roles that will also interact
with the proposed new system, but others may disappear. Your aim should be
to find out who will really do the work – or who is associated with the events
that trigger the work – that will be helped by the proposed software system.
You need to ask yourself who the actual users will be and what tasks they
must perform with the aid of your software system. In doing so you will take
decisions about which roles are no longer relevant in the interactions with the
proposed system.
UML employs the term actor to identify a user of a system. An actor can also
be an external software system or subsystem that will interact with the
proposed system. A shop, for example, might have a point of sale system for
the goods it sells to customers. If customers pay by credit card that point of
sale system might communicate with a credit-checking system owned by the
customer’s bank. So the credit-checking system is an actor with respect to the
point of sale system. In other words, an actor is someone or something that is
external to your intended software system. In a hotel, for example, one aim is
to allow potential guests to make reservations. In this case, a guest is a
potential actor – which we will name Guest – with respect to the intended
software system. At this stage, it is not clear whether this is an actual guest or
someone acting on behalf of that guest – this is something to be resolved
during the development project.
Use cases are a way of capturing functional requirements. A use case is
something that an actor needs to do with the help of a software system; it may
relate to a business process of the domain that will be now carried out with
the software system or it may represent a new process. It should lead to a
result that brings some observable value to that actor. If making a reservation
145
is something that a guest can do with the new hotel system, the phrase make
reservation would be a reasonable name for the use case for the actor Guest.
The phrase that describes a use case can, of course, hide quite complex
behaviour.
There are a number of possible things that can happen when a guest makes a
reservation. For example, a guest may or may not want to take up the hotel’s
offer. In practice, the name of a use case reflects the task’s goal. A typical
Guest, for example, expects that make reservation is going to succeed.
A use case diagram in UML is one way to record and communicate your
understanding of the use case view of a system. These diagrams may be
helpful in giving a quick overview of all use cases, but it is often the case that
a textual description of use cases (as will be seen in Section 3.5) is enough.
Figure 9 is a simplified use case diagram for the hotel reservation subsystem.
The main elements in the diagram are:
. the actors, represented by stick figures
. the use cases, represented by ovals
An association is a relationship . the relationships between actors and use cases – their associations –
between two types, in this case represented by lines.
between actor and use case,
which represents all the links
between instances of those types.
Guest make reservation
check in guest Receptionist
check out guest
Figure 9 A use case diagram for a hotel chain
3.2 Emphasis on the user

Use case analysis is related to an activity called user-centred design, which is
part of the discipline of human–computer interaction (HCI). User-centred
design differs from other approaches to design because it focuses on people,
their work, their environment and how technology can be best designed and
deployed to support them. Use case analysis employs a similar approach, with
146
its focus on the user and the system from the user’s point of view. User-
centred design involves a rapid, iterative process with comprehensive user
evaluations. But, as with all approaches to developing software, there is no
one approach that is best for all problems.
User-centred design and use cases are more concerned with external
functionality than with how internal components of a software system interact.
In short, users are interested in what the proposed software system will do,
not in how the developers will produce the software, provided that it meets
their understanding of a ‘good software system’.
The main purpose of use cases is to help with the requirements phase. In
Unit 2, we described how detailed software requirements can follow from a
description of a use case. Use cases define the scope of a system, as they
represent the interaction of a system with its environment. They also help with
project planning and quality assurance, as you will see later in this and other
units. Furthermore, they act as a discussion tool between developer and user,
and offer a common language for agreeing on the functions of the software
system.
One use case represents one of the possible ways a system can be used. The
use cases for a software system are a record of the intended user-visible
behaviour of the system. This behaviour is what the software system is
required to do when responding to the events that arise from its interactions
with a set of actors, whether people or other software systems and devices. Do
not be misled by the stick-person notation for an actor, as used in Figure 9.
Representing other (sub)systems as actors lets you focus on your area of
concern, leaving the internal structure and behaviour of the other (sub)system
to someone else or for later on.
The contents of the use case represent some task – or coherent unit of
functionality, as UML defines it – which the software system is meant to
perform. The detailed description of each use case can be held inside a
modelling tool or a document. A use case diagram is a concise representation
of the main tasks and their relevant users.
The simple notations for the elements of a use case diagram, like those in
Figure 9, are intended to be intuitive, even for a layperson who is unfamiliar
with the notation and is unlikely to know anything about UML. It is possible
to exploit this simplicity to represent the main functions of a particular
business. In Block 2 Unit 5, you will see how UML is used to represent the
business objects that the business considers to be significant. For example, if
your business were a lending library, the main functions to be represented in a
use case diagram would be the borrowing of books, DVDs and CDs by its
members. Copies of books, films and music are the things handled or used by
people and are examples of business objects.
Use cases deal with functional requirements alone. In Unit 2 you encountered
non-functional requirements. Examples of non-functional requirements for the
lending library could include:
. the number of borrowing transactions that a new software system must be
able to deal with in a given period (say, one transaction per second)
147
. the time within which the system has to respond to queries against the
library catalogue.
No matter what non-functional requirements are asked for, the developer’s
goal is to be confident that all the critical requirements are understood before
investing any substantial effort in the development. In order to ensure that
non-functional requirements are not ‘lost’, each one needs to be associated
with the use case it relates to. We adopt a template to document each
individual requirement and related information – examples of this template
will be shown in Unit 4.
SAQ 4
(a) Name two aspects of software development where use case

modelling can help.
(b) Suggest a reason why use case diagrams are an aid to
communication between user and developer.
Answer
(a) So far we have encountered these two: eliciting requirements;

representing requirements. Later in the module we will also discuss
planning iterations of development and validating software systems.
(b) Use cases offer users an opportunity to understand the system since
the use case notation is relatively simple and doesn’t require an
understanding of UML. This provides a mechanism that enables
developer and client to share a common understanding of the system,
as long as the developer provides some text to demonstrate their
understanding of the problem.
3.3 Stepping from the problem to its solution

As you saw in Section 2 of this unit, the problem that a developer needs to
understand is in the world outside the computing system. In terms of the
models described in Section 2, the developer documents their understanding of
the problem domain with activity diagrams. The next step is to understand the
requirements for a system that will be a solution in that domain. The
requirements are the basis for development and the specification of that
solution. As we saw in Unit 2, the relevant business events from the domain
can be associated with a use case for the system to be developed. The context
of the new system will be defined by the use cases for all relevant business
events. In a problem that involves an existing software system, you might find
that there is already a set of use cases representing the existing software
system.
The system boundary is an important conceptual line that separates what we
are interested in from the rest of the world. In drawing the boundary around
the software system represented in your use case diagram, you are setting the
scope of your solution. In UML, a solid box drawn around the use cases with
148
the actors located outside it represents the system boundary. Figure 10 shows
a boundary for the hotel-chain use cases.
a guest or a receptionist
can make a reservation
Guest make reservation
check in guest Receptionist
check out guest
Figure 10 A use case diagram for a hotel chain, showing the system boundary
The previous figure, Figure 9, illustrates a problem. From the diagram alone,
it is not clear which of the two actors, Guest or Receptionist, initiates the
make reservation use case. It may even be that both are needed to complete
the use case successfully. In fact, potential guests will be allowed to use the
internet to make a reservation, but in other cases the receptionist will perform
the task. UML provides several ways to deal with the problem. The simplest,
which is shown in Figure 10, is to use a textual note to record this
observation, and then refine the model when you know more about the use
case.
In simple use case diagrams, it is common to leave out the box showing the
system boundary, since it is not a compulsory model element. Unless we are
discussing a complex problem that might involve several subsystems, we will
not show the system boundary.
SAQ 5
What is the purpose of a system boundary? Is it always necessary to draw

one in a use case diagram?
Answer
The purpose of a system boundary is to identify a single system,

distinguishing between the internal and external components. Typically, the
149
external components are the actors and the internal components are the use
cases. UML says that the system boundary is optional.
3.4 Actors
Iteration is a natural part of the modelling process. It does not matter whether
you start by looking for the actors or the use cases. We have chosen to begin
with the actors, since it is a way of expressing the system boundary implicitly
and identifying the different views that need to be taken into account. In
practice, you are likely to find that the actors are to be found in the roles that
people play as employees in the problem domain, such as the hotel’s
receptionist or manager. You have already encountered these roles in activity
diagrams for the business processes of the domain.
Actors are not intended to represent particular individuals. Rather they tell us
about a particular role that someone or something might adopt in order to
interact with a software system. For example, someone who works as a
receptionist in one hotel might want to stay in another hotel as part of their
holiday, ie. they will adopt the role of a guest.
If you have drawn activity diagrams for business processes you need to decide
which of the identified roles will correspond to actors and which will not. If
you have not drawn activity diagrams for the business processes you need to
know where to start to find the actors. Given the relationship to organisational
roles, you might identify the actors by looking for the groups of people who
are going to use the software system in order to do their work. It might be
easy to find those who perform the main tasks, such as the receptionists who
work on the front desk of a hotel, but harder to find those who need the
software system in support of their administrative or maintenance tasks. For
example, would the maintenance engineers and cleaners in the hotel interact
with your intended software system directly?
In the case of the hotel chain, it is likely that you will need to pass
information about a guest’s stay to an accounting system. At some later point,
you may be asked to provide an interface to the restaurant side of the hotel in
order to associate the costs of meals with the guests who ate them. When a
guest leaves the hotel, there may be a requirement to collect payment for the
guest’s stay from an external banking or credit card system. In each case, you
should consider whether or not there is some value in an exchange between
the use case in the software system, which you are to develop, and any
identified external system. For each one that you have chosen to include, treat
it as though it were an autonomous black box. You do not need to know how
it works. You only need to know about the interface of the external system.
It is important to distinguish between an actor and the way that actor
communicates with the software system. For example, when analysing a
system you should not be concerned with the mechanism used by the
receptionist to check guests in and out of the hotel system. It could involve
the use of a keyboard and a mouse to interact with a series of screens on a
PC. It might include a TCP/IP connection or voice recognition software. You
should concentrate on the meaning of the stimuli and responses for any given
150
use case, not the communication mechanism that is used. That mechanism is
part of the solution you intend to provide.
In situations where two or more actors are associated with a use case, one of
them must initiate the actions. The other actors will play a passive role. For
example, when a guest checks into a hotel in person, the receptionist performs
the check in process, and the guest is passive. When it comes to describing a
use case, treat the software system as a black box, as in the case of an
external system. It will accept stimuli from the actors and generate responses.
SAQ 6
(a) Explain why the actors in a use case diagram do not represent actual
individuals.
(b) Suggest a guideline that will help you decide whether or not to
include an interaction with an external system on your use case
diagram.
(c) Are roles in business process models the same as actors in use cases?
Answer
(a) An actor in a use case diagram represents a particular role that an

individual might play when interacting with a software system. For
example, a receptionist checks guests into and out of a hotel (see
Figure 10). But it could be that the person who works as a
receptionist at one hotel becomes a guest at another hotel in the
chain and hence takes on another role. Actors can also represent
other systems, rather than people/roles.
(b) One possible guideline would be to show interaction with an external
system if the use case needs to communicate with the actors that
represent the external system.
(c) Roles in business process models may not correspond directly to
actors in use cases as although they interact with a business process
they may not interact with a proposed system. Some roles may
become irrelevant when introducing a new system or may not need
to interact with the system.
3.5 Describing use cases

Before you can describe detailed requirements or carry out a sensible
estimation and planning process for the whole project, you need, among other
things, a good idea of what each use case means. To get a feel for what this
might entail look again at Figure 10, a simple use case model for a hotel
chain. The main activities involve making reservations and checking guests in
and out of rooms.
What do the use cases make reservation, check in guest and check out guest
mean? No doubt, using your own experience of reserving rooms at hotels, the
names of the use cases are quite indicative of what they mean. However you
should never rely on intuition or personal experience, but rather create a
151
description of the use cases that you and the customer can agree upon. For
example, a description of the check in guest use case might be as follows (for
a particularly simple system).
Upon arrival, each guest provides the reference number for their reservation
to the hotel’s receptionist, who enters it into the software system. The
software system reveals the details of that reservation for the guest to
confirm. The software system allocates an appropriate room to that guest and
opens a bill for the duration of the stay. The receptionist issues a key for the
room.
Having read this description you are probably thinking of all the deficiencies
it contains. In real life, you would of course check with the customer to
clarify that the description contains all the necessary information. However,
for the sake of our imaginary example, we will assume the description given
is sufficient.
Preconditions and postconditions

The information relevant to a use case records decisions that have been made.
We look now at what these can be. We draw your attention to the following
observations about the requirements of the check in guest use case.
. There is a condition, known as a precondition, that must hold before a
room can be allocated to a guest:
There must be a reservation for the guest, there must be at least one room
available (of the desired type) and the guest must be able to pay for the
room.
. There is a condition, known as a postcondition, that will hold after a
room has been allocated to a guest:
The guest will have been allocated to a room for the period identified in
the reservation, the room will have been identified as being in use for a
specific period, a bill will have been opened for the duration of the stay
and a key will have been issued.
In other words, we have captured the meaning of check in guest in terms of
two statements: one that must be true before the use case can be carried out
(the precondition) and one that will be true once the use case has been
completed (the postcondition). The advantage of describing a use case in
terms of a precondition and a postcondition is that when you go on to
elaborate the use case in more detail these same conditions must still be
satisfied – they will continue to specify the starting point of the use case and
its required outcome.
Pre- and postconditions provide a more formal description of the check in
guest use case described above. Notice that such a specification does not say
how a use case must be performed, but simply what conditions must be
satisfied. We will now look at other aspects that should be recorded about a
use case.
152
Goal and scenarios

The purpose of a use case is to meet the goal of its associated actor or actors,
such as a guest making a reservation with a hotel. So a use case should
include all the steps necessary to meet that goal with the aid of the software
system. For example, if it is necessary to check the availability of rooms in
the hotel for the desired length of stay before accepting a reservation then we
expect the use case to perform that check. In general a use case contains a
narrative about the flow of events that specifies a particular use of the
software system.
A scenario illustrates one particular way the use case can unfold, by the
sequence of interactions the actors have with the system. You can think of a
scenario as being an instance of a use case, much as an object is an instance
of a class.
For each use case, we normally start by considering a main scenario in which
the goal of the use case is successfully achieved – the ‘sunny day scenario’.
We then go on to consider other scenarios in which things go less smoothly:
the goal is not achieved, or there has to be some variation in the sequence of
actions that is carried out.
Here, for example, are two scenarios for making a reservation at a hotel – first
the main success scenario, then an unsuccessful scenario in which no
reservation is made.
Main scenario
The guest wants to reserve a double room at the Ritz Hotel for 14 July. A
double room is available for that date, and so the system makes a
reservation for the guest.
Unsuccessful scenario
The guest wants to reserve a single room at the Savoy Hotel for the first
week of August. There is no single room that is free for seven days in
August, but there is one room available for four days and another of the
same type for the following three days. The system presents that option to
the guest, who rejects it.
Both scenarios are possible instances of the make reservation use case. Their
interactions and outcomes are different. In the first, there is a description of
the use case leading to a successful outcome. In the second, there is an
exception to the main success scenario. Exceptions to the normal behaviour
for a use case are common, especially where actors decide to cancel a use
case without completing it. However the common theme among all the
scenarios is the intent of an actor to reach the goal defined by a use case. In
the unsuccessful scenario above, the guest was trying to make a reservation at
the Savoy Hotel but rejected the option of changing rooms during the stay.
This sort of situation is common and a use case must always cater for any
unusual or alternative courses of action that are likely, as you will see in
subsection 3.6.
153
You could start with the simple identification of a use case and its main
success scenario, and refine or adapt it during the process of development.
You will need to decide the way in which you record the information for each
use case – not just for the main success scenario but for all the relevant
scenarios. At its simplest, you can record a textual description (narrative) that
details each scenario together with its outcome.
A use case description

Remember that your description of a use case expresses what the software
system should do without constraining how it should do it. Since the
description takes an external viewpoint, all the behaviour is in the form of
observable results. While the structure and format might vary among the
different development processes, we suggest that you include the following
items as a minimum:
. a unique identifier for the use case, to allow traceability throughout
development
. the name of the actor that initiates the use case
. a short description of the goal of the use case
. a single sequence of steps that describe the main success scenario – you
may find it helpful to number these steps for traceability, for identifying
the detailed software requirements that they generate and for cases where
you need to identify any extensions or variations that occur as a result of
the other scenarios of a use case
. a textual description of the pre- and postconditions.
In some circumstances you may want to start with a simplified version of the
template and then add the rest of the information later. In other circumstances
you may have to include other information. For example, the identity of the
authors may be required where there is a large team of developers. In a risk-
driven process you might be required to record an assessment of the risks,
assumptions and outstanding issues to support the decision-making process. It
will generally be useful to record the assumptions made during the use case
analysis.
Opinions vary about the correct format of the description of a use case. One
development process might require a detailed structure with tightly controlled
phrasing and numbering of each item in the description. Another might place
few or no limitations, such that each use case reads like a story, with a
beginning, a middle and an end. You should use the language of the domain
to formulate the use cases, as the developer (as supplier) and the users (as
customers) need to have a clear understanding of what is captured in each use
case and what it means.
On an individual project or within a particular organisation all the developers
should work to an agreed common format for documenting use cases. Table 1
illustrates the style we follow in this course to structure and record a use case.
154
Table 1 A textual description of a use case in the hotel domain
Identifier and name UC1 make reservation

Initiator Guest or Receptionist
Goal A room in a hotel is reserved for a guest.
Precondition None (i.e. there are no conditions to be satisfied prior
to carrying out this use case).
Postcondition A room of the desired type will have been reserved for
the guest for the requested period, and the room will
no longer be free for that period.
Assumptions The expected initiator is a guest (using a web browser
to perform the use case) or a receptionist. The guest is
not already known to the hotel’s software system (see
step 5).
Main success scenario
1 The guest/receptionist chooses to make a reservation.
The guest/receptionist selects the desired hotel, dates and type of room.
2
The hotel system provides the availability and price for the request. (An
3
offer is made.)
The guest/receptionist agrees to proceed with the offer.
4
The guest/receptionist provides identification and contact details for the
5
hotel system’s records.
The guest/receptionist provides payment details.
6
The hotel system creates a reservation and gives it an identifier.
7
The hotel system reveals the identifier to the guest/receptionist.
8
The hotel system creates a confirmation of the reservation and sends it to
9
the guest.
The main success scenario always contains a stepwise description of what

happens when nothing goes wrong – for most use cases this will be the
situation that occurs most often. It is assumed that the steps are performed in
the order described with no concurrent behaviour. In the next section, you will
see how each step can be used as a decision point to deal with exceptional
circumstances (giving rise to other scenarios). For example, what should be
done if there is no available room for the desired stay?
SAQ 7
(a) What is the relationship between a use case and a scenario? Give
examples to illustrate your answer.
(b) What is meant by a main success scenario?
155
Answer
(a) For each use case there is a set of possible scenarios. A scenario is
an instance of a use case. A scenario describes a sequence of
interactions between the system and some actors.
Here are two examples of scenarios. A member of a lending library
wishes to borrow a book, and is allowed to do that as long as they have
no outstanding loans. Another member wishes to borrow a book, but
has exceeded the quota for the number of books that can be borrowed.
In each scenario the member wishes to borrow a book, but both the
circumstances and outcomes of events are different in each instance. So
a use case includes a complex set of requirements that the system must
meet in order to cope with every eventuality.
(b) The main success scenario shows the steps normally followed to
achieve the stated goal of the use case. But there can be other
scenarios for the same use case, each one having different outcomes
depending upon circumstances.
3.6 Use cases in development activities

Representing requirements with use case diagrams
It is possible to represent requirements in a wide variety of forms – you might
use a mixture of text, diagrams and mathematical expressions. In practice you
will find that each development process has something to say about the way
developers should express a given set of requirements. We discussed
documentation in Unit 1 and you should always consider the intended
audience for any document that you produce.
You have seen how use cases can record the tasks that actors want to do using
the proposed software system. In practice the use cases are equivalent to the
users’ requirements that you plan to satisfy. For simple systems, there may be
only one use case diagram, as in the hotel example of Figure 10. For large
systems, you will need a number of use case diagrams, each representing just
one aspect of the software system as a whole. Thus use case diagrams are an
essential feature in the management of requirements. For simple use cases, we
may equate the user requirement represented by the use case with one single
software requirement. For more complex use cases the corresponding user
requirement will be refined into a set of more detailed software requirements
corresponding to the steps of the scenarios.
Each use case diagram should focus on a clearly defined aspect of a software
system, and should contain the actors and their use cases that are essential to
express your understanding of that context. There is a balance to be struck
concerning the level of detail within each diagram – too much or too little
detail will detract from the diagram’s usefulness in communicating your
understanding of an aspect of a software system. You need to provide
sufficient detail to be understandable while still maintaining an adequate level
of abstraction.
156
Detailed software requirements

Use cases can be used to elicit detailed software requirements as described in
Unit 2. Each step in a use case scenario may correspond to one or more
functional requirements. This will be illustrated in detail in Unit 4 – here we
give a simple example.
Step 2 of the use case in Table 1 (‘The guest/receptionist selects the desired
hotel, dates and type of room.’) corresponds to a set of detailed software
requirements, as shown below. Each detailed requirement is associated with a
scenario step and, apart from its description, there is an indication of its
associated fit criteria, as discussed in Unit 2. (SFR2 stands for software
functional requirement 2 (assuming that there is only one software functional
requirement, SFR1, for scenario step 1), UC1 for use case 1, and Step 2 for
scenario step 2.)
SFR2: UC1, Step 2
Description: The system shall obtain a hotel name from the user.
Fit criterion: A valid hotel name shall be accepted.
SFR3: UC1, Step 2
Description: The system shall accept a range of dates from the user.
Fit criterion: A valid range of dates shall be accepted.
SFR4: UC1, Step 2
Description: The system shall accept a room type from the user.
Fit criterion: A valid room type shall be accepted.
Sometimes a simple use case corresponds to one requirement and needs no
further detailing. However for more complex use cases decomposition into
more detailed software requirements will be carried out as shown here.
Use cases as a planning aid

By the time you work through your requirements phase, you should have both
a good idea of what each use case means and an understanding of users’
expectations of each one. If your chosen development process includes risk
analysis you should have recorded some assessment of the risks associated
with each use case.
You will now be in a position to produce a plan for the project as a whole.
You have to decide the order in which to implement your use cases, involving
the customer in these decisions. Part of your planning task will be to assign a
priority to each use case to indicate its importance with respect to the users.
You can also use other factors to determine the priority of a use case – for
example, some authors suggest the following criteria (Krutchen, 2003):
. risk, including complexity of requirements, unknown required effort
(involving significant research or new and risky technology, for example)
and political issues. A sign of complexity of requirements is, for example,
the existence of dependencies between use cases (discussed in Section 4)
157
. coverage, which requires that the initial set of use cases should give an
overall view of the system
. criticality, measured in terms of business value – the main business
processes, for example. The main functions of the system should be
covered early.
In many cases, there will be one or more immovable deadlines that will affect
your choice. In some circumstances, you may be faced with the choice of
removing functionality from your use case model in order to meet such
deadlines.
Use cases and architecture

Use cases represent functionality, they do not represent the qualities of a
system – the non-functional requirements – which are the main factors that
drive a system’s architecture. However decisions on planning use cases need
to both take into account and influence the architecture of the system.
Coverage of use cases, for example, can only be determined with an idea of
the architecture, so that different parts of the system are considered. On the
other hand, by choosing to gather two or more use cases into a package for
development as one increment also drives decisions on structure of data or
user interface design, as you are forcing certain parts of the system to go
together.
Scenarios, which have been described above as a technique for requirements,
can also be used to evaluate how a system’s architecture satisfies the non-
functional requirements of a system, in particular those that are architecturally
significant. For example, negative scenarios, i.e. scenarios associated with
actors who have a hostile intent, have been used to check security and safety
systems (Alexander and Maiden, 2004). Working through different scenarios
will help with checking any needed changes of the architecture to support
required interactions and their properties.
In Block 3 Unit 10 we will discuss how scenarios are used as tests for
qualities of a system and of how an architecture satisfies them.
Use cases and testing

Each detailed software requirement is tested against fit criteria. But it will also
be necessary to carry out testing at a higher level of granularity, considering a
series of use cases.
A simple and useful technique for validating a requirements specification is to
act out or walk through each use case in turn. By involving the potential
users, you can determine the extent to which your solution will meet their
expectations. The walk-through technique can be used to specify acceptance
Acceptance testing consists of a tests, where you need to demonstrate that your software solution has met the
series of tests carried out by the specified requirements.
customer in conjunction with the
developer. These act as a final The same technique can be used for system testing where you need to verify
check that the system does what that your design conforms to its specification. For each scenario in a use case
the customer expects it to do. you can identify a set of specific object instances to show that your solution
can deal with each main success scenario and its variations and extensions.
158
For example, you would design test cases to show that a guest can make a
reservation for a room in the hotel. In the same way, you could also show that
reservations are not possible when there are no rooms available for an
identified stay in the desired hotel.
SAQ 8
How do use cases help with:

(a) requirements capture
(b) the elicitation of detailed software requirements
(c) development
(d) the system’s architecture
(e) system validation (checking that the system actually supports the
functionality required by the users)?
Answer
(a) Use cases help with requirements capture through the identification
of actors and tasks in the system. For each actor, the set of use cases
establishes what that actor requires from the software system. The
association between an actor and a use case is about communication.
(b) Detailed software requirements can be associated with each step in a
use case scenario. There may be more than one requirement for each
step.
(c) One of the difficulties that developers face is planning delivery
times. Often a customer can put pressure on the developer to meet a
particular deadline. It is part of the developer’s job to elicit from the
users the use cases that have the highest priority and to indicate what
functionality in the software system can be met under such
constraints. The use case descriptions help the developer to:
◦ understand the complexity of each use case
◦ determine which actors interact with each use case and to
what extent
◦ establish which use cases carry the most risk
◦ estimate how long each use case is likely to take to
implement.
Understanding these aspects of the system can help developers plan the
order in which the use cases should be developed, and provide an
appropriate time frame. Several criteria – such as risk, coverage and
criticality – can be used to help establish priorities of use cases.
(d) Use cases, as standalone chunks of system specification, dictate the
sorts of functionality that need to be provided by the system and
constitute an aid for identifying interfaces in an architecture. Use
cases can also be grouped in terms of similar functionality, therefore
influencing the architecture of the system. Scenarios can be used to
check how an architecture meets non-functional requirements, in
particular those that can be affected by the architecture, such as
security and safety requirements.
159
(e) One way to validate a system is to use the walk-through technique,

checking the functionality related to each use case in turn. The walk-
through technique can also be used to elicit system tests where each
use case is required to deal with a number of scenarios – a process
known as verification. For each software requirement generated from
a step of a scenario, the fit criterion helps to devise the test.
3.7 Use cases and agile development

So far we have given a detailed account of use cases and how to use and
describe them. In Unit 2, we mentioned use cases in the context of a
traditional requirements process and user stories in the context of a more agile
development. Do use cases also have a place in agile development? The
answer is yes, as long as they are used in an agile manner. Agile development
is not about dictating the tools that you can and cannot use, but rather about
ways of working that will support teams in delivering software on time and
that satisfies the customer.
Use cases and user stories are also not contradictory. Initially you may write
some use cases to give a rough first idea of the big chunks of functionality
and how they should be prioritised, and then write user stories for smaller bits
of functionality. These user stories are not detailed requirements, rather
triggers for conversations that will clarify at a finer level what the user wants.
An agile approach would not prevent you from using use cases. There are
many tips on how use cases can be used in an agile approach (Cockburn
2002, Cockburn 2003, Leffingwell, 2010), such as:
. write use cases as needed instead of writing all use cases upfront
. write just enough content rather than complete descriptions
. write use cases that are useful for communication, not heavy ones that are
difficult to understand and change.
The main message, which applies to all techniques, is that use cases should be
adapted to the needs of the project, rather than inflexibly applied for the sake
of the rules.
To take a more agile approach to development with use cases it is important
to have in mind a set of agile modelling practices such as those proposed by
Scott Ambler (2002). These include:
. following an iterative an incremental approach
. using models that are effective in teamwork and communication
. modelling with simplicity in mind
. thinking on how you are going to test what you model.
In this module we give you an opportunity to learn different techniques. It
requires practice and a good understanding of the context, in terms of both the
organisation you are working with and the problem you are trying to solve, to
be able to decide which techniques – or their combinations – are more useful
in each circumstance.
160
Exercise 4
A typical lending library (as the one in Example 1) keeps a stock of books for
the use of its members. Each member can take out a number of books up to a
certain limit. After a given period, the library expects members to return the
books that they have on loan.
When borrowing books, members are expected to scan a library card in the
library self-service scanning machine and then scan the barcodes of their
chosen books. Each new loan is recorded in the system for that member.
When a book is on loan to a member, it is associated with that member –
possession of the book passes from the library to the member for a defined
period. The normal loan period for each book is two weeks. If the member
fails to bring the book back on or before the due date, the library imposes a
fine.
The library wants to extend the existing system so that anyone should be able
to browse the stock of books held in the library, but only a member will be
able to reserve a book. The ability to browse and make reservations will be
provided through a web-browser interface.
In the extension to the existing system, the librarians should also be able to
enrol new library members.
Draw a simple use case diagram for the proposed extension to the library, and
identify the constraints or assumptions that you make. (Ignore the issue of
fines, because there is not enough information.)
Solution
A good first step is to establish the context for the proposed system by
identifying the actors that surround it. When you have identified the actors
you can investigate the behaviour that each one will expect from the proposed
system, which will eventually give rise to the use cases for your model.
Your task is to determine the roles that people will adopt in order to use the
proposed software system. In general the customer (the person who is buying
the software) will have some say in who is a legitimate user. In this problem
domain the library owns the books. Librarians are responsible for the
enrolment of new members.
Browsing through the library’s catalogue is a common activity performed by
both members and librarians. As a catalogue is only a kind of list that shows
what the library offers for loan, it can be read by anyone: non-members are
also to be allowed to browse the catalogue.
There appear to be two scenarios related to the activity of reservation. In the
first, a member might want to borrow a specific book but finds that all the
available copies are out on loan. In the second, a member might want to make
sure that at least one copy is available and reserve it in order to avoid a
wasted trip to the library.
There is already a library self-service system that deals with the borrowing
and returning of books. We would need to investigate what this system does,
but here we assume it deals with the updating of members’ and books’
161
records. We can consider this system as an actor that will deal with this part
of the extended library system.
We conclude that there are four basic actors:
. Member
. Librarian
. Browser
. LibrarySelfServiceSystem
What is missing from the given description of the system is any indication of
how people join the library and become members. Is there a fee to join the
library? Do prospective members have to prove their identity? How do
members prove their membership? So this is a potential use case that requires
later elaboration.
In addition, someone – a librarian, we presume – will be expected to make
sure that the catalogue reflects the actual stock held at the library. A
corresponding use case is needed for this.
Our solution includes six basic use cases for the library software system:
. borrow copy of book
. return copy of book
. reserve book
. browse catalogue
. update catalogue
. enrol new member
Figure 11 shows a possible use case diagram for the proposed system. You
may have used different names on your diagram, and you may have identified
a different number of use cases – there is no one correct solution. You may
have defined use cases that combine two or more of our use cases, but in
doing this it is likely that you assumed knowledge of the internal structure of
the proposed system. In a use case diagram, you should identify only the
behaviour that will bring some discernible value to at least one actor.
In reaching your solution, you might have gone through several iterations.
This is to be expected. Your first guess could have been done in your
notebook, as opposed to using a tool. In practice, you might alternate between
pencil and paper and a tool. Whatever your chosen means of recording, focus
on getting a useful result. A rough diagram that is useful is better than a
pretty one that is not!
Finally, you should have included some notes with both the diagram and the
elements in it. For example, in Figure 11, the borrow copy of book use case
has a note associated with it indicating the loan period. Notes are an excellent
way to record constraints on the behavioural requirements.
162
non-members, members and

librarians can browse
Browser browse catalogue
two-week
loan period
reserve book
Member borrow copy of book LibrarySelfServiceSystem
return copy of book
update catalogue
Librarian
new use case that
requires further elaboration
enrol new member
Figure 11 A use case diagram for a lending library
Another use of a note is to indicate something that needs further attention or

revision.
At some future point, once you have learnt more about the library, you would
revise the use case diagram.
Exercise 5
Suggest a precondition and a postcondition for a check out guest use case that
appears in Figure 10. The goal of this use case is for the guest’s bill to be
paid and the room made available.
Solution
Precondition: the guest must be currently allocated to a room.
163
Postcondition: the room will have been made available (either designated as
free to be reserved by another guest or assigned to a pending reservation) and
the guest’s bill will have been paid.
Exercise 6
Prepare a textual description of the check in guest use case that appears in
Figure 10. Follow the example of Table 1, which shows the main success
scenario and other criteria for the make reservation use case. As part of your
working, identify any exceptions to the main success scenario (you will learn
how to record these formally in Section 4). You will need to make some
reasonable assumptions that need to be recorded.
Solution
The actor for the check in guest use case is the Receptionist, as shown in
Figure 10. You need to consider the exchanges that take place between a guest
and the hotel’s receptionist. This is an assumption, as there are some hotels
with automatic check-in and no receptionists; we are not considering that type
of hotel.
The main success scenario describes the simplest path for checking a guest
into a room in a hotel. Our solution is shown in Table 2.
Table 2 A textual description of the check in guest use case
Identifier and name UC2 check in guest

Initiator Receptionist
Goal A guest takes up a reservation and occupies a room at
the desired hotel.
Precondition There is a reservation for the guest for an available
room of the desired type, and the guest can pay for the
room.
Postcondition The guest will have been allocated to a room for the
period identified in the reservation, a bill will have
been opened for the duration of the stay and a key will
have been issued.
Assumptions The guest is already known to the hotel’s software
system.
The hotel is confident that the guest can pay. For

example, the guest has a valid credit card.
1 The guest provides a reservation reference number to the receptionist.
The receptionist enters the reference number to find the reservation.

2
The hotel system provides the details of the requested reservation.
3
The receptionist confirms the details of the room type and duration of
4
stay with the guest.
The hotel system allocates a room to the guest.
5
164
The hotel system opens a bill for the guest. (It could be that there is a
6
separate billing package, which must be notified upon check in.)
The receptionist issues a key to the guest.
7
Even at this early stage in the development, it is possible to see that a further
partitioning can be performed on the check in guest use case. The main
business of hotels is to provide rooms for guests, receiving payment in return.
However a typical hotel is likely to provide more than just the rental of
rooms. For example, the hotel’s restaurant could be available to the general
public, and in larger hotels there could be function rooms for meetings and
wedding receptions. As a result, we might decide to have a separate use case
that deals with payment.
The following exceptions could be considered: a guest does not have a
reservation, a guest has a reservation but lost the reservation number, or a
guest has a reservation but decides to change the type of room. We will
explore ways of recording such exceptions in Section 4.

In this section, you saw how use case diagrams help you define what a
proposed system should do from a user’s perspective. Use case can also
provide a basis for a contract between the customer and the developer
because:
. use case models are used to drive the work to be done in software
development
. from a simple problem description, it is possible to draw a use case model
that can be understood by people who are unfamiliar with UML
. each use case should lead to a result that brings some observable value to
at least one of its actors
. the requirements of a use case can be captured through either a written
statement or, more formally, the use of pre- and postconditions
. detailed software requirements can be generated from each step of a
scenario of a use case
. scenarios, which are particular sequences of possible actions within a
given use case, can be walked through to determine the extent to which
customer’s expectations will be met
. ‘walkthroughs’ of scenarios help with the validation of the architecture of
a system
. use cases can be used in an agile approach.
165
4 More details on use case models

In this section we will examine the relationships between use cases. You will
also see two ways of refining a use case model to help you identify potential
components and variations on existing tasks, when dealing with unusual
circumstances.
4.1 More about actors

In the hotel example shown in Figure 10, the Guest actor is not associated
with the use cases for checking in and out because we have assumed that the
only real user for these two use cases is the receptionist – self check in and
In larger hotels, a separate actor check out is not being considered.
may be needed for reservations.
You would alter your use case An aim of the new system is to allow potential guests to use their web
model accordingly. browser to make reservations, as an alternative to contacting a hotel directly.
Hence the diagram shows Guest as an actor for the make reservation use case.
However since people will still be using other methods of requesting a room,
such as telephone or letter, we should allow for a member of the hotel’s staff
to perform the service and so Receptionist is also shown as being associated
with make reservation.
UML provides a notation to use generalisation between actors. When two
actors share the same behaviour (interacting with the same use cases) and one
of them has some extra behaviour, then the common behaviour can be
associated with a generalised actor and the more specific behaviour with the
specialised actor. You can change Figure 10 to show a new actor called
Reserver associated with the make reservation use case. You can still show the
actors Receptionist and Guest as specialisations of Reserver, as shown in
Figure 12. By using the open-headed arrow from Guest to Reserver, you are
saying that a Guest can do the same things that a Reserver can, but may do
something else that a Reserver does not. Reserver is a generalised actor and
Guest a specialised one.
166
Reserver make reservation
Guest Receptionist check in guest
check out guest
Figure 12 Relating the roles that actors play
SAQ 9
What is the purpose of identifying relationships between actors?

Answer
The purpose of identifying relationships between actors is to indicate

generalisations and establish which use cases can be performed by which
actors. Figure 12 illustrates a Receptionist being a special type of Reserver.
A Receptionist can do the same things that a Reserver can, but may be able
to do something else that a Reserver cannot, in this case check in guest and
check out guest.
4.2 Modelling the relationships between use cases

Use cases can be related to one another. There are two very common and
important forms of relationship:
. Inclusion: This is when two or more use cases have an overlapping area of
functionality (i.e. a common task) that can be factored out as a distinct use
case. The new use case can then be used by each of the original use cases,
so avoiding duplication. Inclusion of use cases is always unconditional.
. Extension: This is when a use case has a main success scenario but also
alternative scenarios that demand a variation on the original use case –
different or additional actions. Each variation can be separated out as a use
case that is distinct from but related to the original use case. An extension
is always dependant on the satisfaction of some condition.
167
In both situations, the new tasks become new use cases and, as you will see
below, UML provides a suitable notation to represent the relationship between
the original use cases and the new ones.
The main disadvantage of this approach is the additional complexity it brings
to a model, in contrast to the simple use cases considered in the previous
section. The simplest advice for you as the developer is to remember why you
are creating the model and who it is for. We consider the problems of use case
modelling later in this section.
Stereotypes
UML is extensible – it is possible to add to its basic language. One way this
can be done is by adding stereotypes. A stereotype can be used to specialise
a UML model element of any kind. For example, a class can be given the
stereotype «abstract», to show that it is a class of a special sort.
The convention is that a UML stereotype name is always enclosed between
double angle brackets «…» called guillemets.
UML predefines a number of stereotypes and we can also add our own. For
instance, we could add a stereotype «tm354» but we would need to agree on
its meaning. Stereotypes that are most often used in practice are the ones
already defined in UML, because they are generally accepted and understood.
The two predefined stereotypes we are concerned with here are «include» and
«extend».
Sharing behaviour between use cases

In the process of eliciting and specifying requirements, you may find a certain
amount of common behaviour in two or more of your use cases. You may
even find that an existing software component can provide part or all of that
common or shared behaviour.
You can record the shared behaviour in a new use case and connect it to the
use cases that it came from with a dashed arrow (indicating a dependency
relationship) pointing from the original use case to the new one. Think of the
new use case as always being included in each of the originals. Hence the
dependency arrow is labelled with the «include» stereotype. Figure 13 shows
an example taken from the domain of a lending library.
168
«include»
extend loan
Librarian
check reservation
«include»
return copy of book
Figure 13 Shared behaviour in a lending library
Members of a lending library can borrow a certain number of books and, for
any book borrowed, renew the loan up to three times. A loan can only be
renewed if there are no existing reservations for that book by other members,
when all other copies are on loan. Let us assume that when a member returns
a book there must be a check to see whether there are outstanding reservations
for that book by other members. In this case the book will not be returned to
the shelf, but will instead be assigned to the highest priority reservation. This
same check needs to be carried out when a member extends a loan. The
reservation check is a shared piece of behaviour, a common scenario, which
can be developed separately as the check reservation use case. Note that this
is unconditional behaviour – the reservation check must be performed
whenever a loan is extended or a book is returned.
A dependency arrow has a source (where it comes from) and a target (where
it goes to). In Figure 13, check reservation is the target use case for both
dependency arrows. extend loan and return copy of book are the source use
cases. If the target use case changes during development, the source use case
will also be affected. In practice the source use case will need to be reviewed
if the scenarios in the target use case change. Note that the dependency is
unidirectional. The target use case is not affected by changes in the source use
case. (In the worst case, it simply becomes irrelevant and the dependency is
broken.)
The arrows for stereotyped associations point in the direction indicated by the
verb – for «include» the arrow points to the use case that is included.
By taking out any common or shared behaviour, you can benefit from a
simplification of the original use cases and make them easier to understand.
There is a further benefit in terms of the internal consistency of the final
requirements. Instead of having two or more different scenarios for a
reservation check, for example, there will be just one main success scenario
for the new check reservation use case.
In addition, there is a chance to consider the reuse of existing components and
the potential identification of new components. You also need to keep in mind
that a use case is only useful to the extent that it helps as a communication
169
tool, and you should therefore only use «include» if it helps understanding of
the model.
Alternatives to the main success scenario

If a use case incorporates a scenario that is significantly different from the
main success scenario, you may decide to create a new subsidiary use case.
There may even be a need to create more than one subsidiary, depending on
what happens in different circumstances. For example, a typical lending
library will set an upper limit on the number of books that its members can
borrow at any one time. A copy of a book cannot be borrowed if that limit
would be exceeded.
Figure 14 shows a fragment of a use case diagram that identifies a new use
Beware. This one often catches case, refuse loan. The new use case (the source) is connected to the original
people out, because they expect (the target) with a dashed arrow and labelled with the stereotype «extend».
the arrow to point to the Note that the arrow points again in the direction indicated by the verb. For
extension, but it does not: it goes
the other way.
«extend», the arrow points to the use case that is extended. The new refuse
loan use case depends on the original. This is conditional behaviour, as it is
only performed when the member would have too many books. Compare this
with the unconditional behaviour associated with an «include» dependency.
Note that the violation of a condition and the undertaking of an alternative
does not necessarily imply the introduction of a new use case with an
«extend» relation. It does so only if there are several actions to be performed
to handle the alternative.
member has maximum

number of books
on loan
«extend»
Member borrow copy of book
refuse loan
Figure 14 Alternative behaviour in a lending library
UML provides a number of ways to record the event that triggers the
subsidiary use case. In Figure 14, we have used the general purpose notation
for a note to indicate that refuse loan is performed when a member already
has the maximum number of books on loan.
The new use case should record a description of the corresponding scenario.
There are two key points that it should contain:
. the condition that triggers the subsidiary use case
170
. the places in the main success scenario where the condition is tested –
called extension points.
Extensions can be treated more formally than a simple UML note on a use Not all UML tools support the
case diagram. Figure 15 shows an example taken from the description of the representation of extension
make reservation use case in the hotel-chain system. The make reservation use points inside a use case.
case has an extension point called alternatives, and is extended at that
extension point by the use case select alternatives; select alternatives is only
executed when the extension point alternatives (in the main scenario of make
reservation) is reached and the condition room not available is true. The
condition and the reference to the extension point are shown in a note
attached to the corresponding extend relationship (in UML 2).
condition: {room not available}

extension point: alternatives
«extend»
extension points
alternatives
Reserver select alternatives
make reservation
Guest Receptionist
Figure 15 An extension to making a reservation
Extending the use case description

Table 3 shows how the original description of the make reservation use case
contained in Table 1 has been changed to take into account the extension to
deal with instances where the hotel has no free room available for the
requested period, and the introduction of a new actor called Reserver. Each
step in the main success scenario acts as a potential extension point, from
which the relationship to a new use case can be defined. Here, step 3 is the
extension point that leads to the additional steps described in 3.a.1 and 3.a.2.
As the extension point at step 5 shows, some work can be avoided if the guest
of the reservation has stayed somewhere in the hotel chain before. Where such
choices arise, your main success scenario should reflect the more dominant or
typical flow. Table 3 reflects an emphasis upon new guests for the hotel chain.
171
Table 3 Extending the description of a use case in the hotel domain
UC1 make reservation

Identifier and name
Initiator Reserver (may be a Guest or a Receptionist)
Precondition None
Postcondition A room of the desired type will have been reserved for
the guest for the requested period, and the room will
no longer be free for that period.
Assumptions The expected initiator is a guest (using a web browser
to perform the use case) or a receptionist. The guest is
not already known to the hotel’s software system (see
step 5).
1 The reserver chooses to make a reservation on behalf of a potential
guest.
The reserver selects the desired hotel, dates and type of room.
2
The hotel system provides the availability and price for the request. (An
3
offer is made.)
The reserver agrees to proceed with the offer.
4
The reserver provides identification and contact details for the hotel
5
system’s records.
The reserver provides payment details.
6
The hotel system creates a reservation and gives it an identifier.
7
The hotel system reveals the identifier to the reserver.
8
The hotel system creates a confirmation of the reservation and sends it
9
to the guest identified by the reserver.
Extensions
3.a room not available
3.a.1 The hotel system offers alternative dates and types of room.
3.a.2 The guest selects from the alternatives or declines the offer.
5.a guest already on record
5.a.1 Resume at step 6.
The convention we follow in numbering extensions is to use the number of

the step followed by a letter. For example, extension 3.a starts an alternative
path to step 3 in the scenario (3.a corresponds to the extension point in
Figure 15). If there is a series of steps in this extension they will be numbered
3.a.1, 3.a.2 and so on. If there are other alternative extensions for step 3 of
the scenario, they will be numbered 3.b, 3.c and so on.
In this example we do not create a new use case for each of the extension
points as the actions to be performed are relatively simple. However when
looking further into their detail it may be the case that their complexity
justifies a use case for some of the extensions.
172
To extend or include?
Decisions between these two options frequently present system developers and
modellers with a dilemma. Analogously to natural languages, UML allows a
number of ‘grammatically correct’ options, each of which will make more or
less sense depending on the context. This is well illustrated with the example
below of a log on use case.
Whatever kind of software system you intend to develop, you need to
consider its security. Usually only trustworthy people are allowed to use the
new software system. We can therefore envisage a log on use case, which
describes how a user gains access through a unique identifier and a password.
How should such a requirement be included in the example of the hotel chain
shown in Figure 9?
For example, we could show the log on use case as a component of every use
case that is associated with an actor, as shown in Figure 16.
Reserver make reservation

«include»
«include»
check in guest log on
Guest
«include»
Receptionist
check out guest
Figure 16 Including the log on use case in the hotel domain
You can also redraw Figure 16, as in Figure 17, showing the three original
use cases as variations of the log on use case. It would be ‘grammatically
correct’, although it would be difficult for the reader to see the intended
purpose of the system because we have shifted the emphasis to the action of
logging on and away from the primary functions. So although this is
grammatically correct in UML it probably makes less sense than the first
diagram. Note that although the use cases are placed differently in the two
figures, there is no implication of ordering – time ordering is not shown in use
case diagrams.
173
Reserver «extend» make reservation
«extend»
log on check in guest

Guest
«extend»
Receptionist
check out guest
Figure 17 Making log on the main use case
Avoiding over-complex use case diagrams

You should beware of making your diagram too complex. The general
approach to managing complexity is to partition a problem into subproblems,
and use abstraction to reduce the detail and extract what is most significant to
the problem. The same applies to use case diagrams.
Reduce the complexity of your use case diagram by:
. redrawing it at a higher level of abstraction
. splitting it up into smaller modules.
In the case of the hotel chain, we might partition our solution into three
subproblems, usually called packages (a way of grouping cases):
. reservations
. checking guests in and out of their rooms
. system access.
Each package may then be assigned to a separate developer for
implementation. However the project team must then deal with the
dependencies between the three packages as they work towards a solution. We
will return to the subject of packages later in the module.
SAQ 10
(a) What is a stereotype in UML?

(b) What is the meaning of the «include» stereotype?
(c) What is the meaning of the «extend» stereotype?
(d) Is it necessary to place the «include» and «extend» stereotypes on all
diagrams?
174
(e) How would you modify a use case model to show that you intend to
employ a component that already exists?
Answer
(a) A stereotype is a way of attaching extra classifications to a model

adding to its basic language. Stereotypes can be user defined – this is
a way of extending UML.
(b) The «include» stereotype indicates a situation where a use case is
reused. In Figure 13, the diagram illustrates the check reservation use
case, which is used by two other use cases. The purpose is to
demonstrate commonality between tasks so that reuse can be
achieved. The additional use case is included unconditionally in the
original (base) use case.
(c) The «extend» stereotype indicates a conditional extension to the
original use case, known as alternative behaviour. This is used to
illustrate a case where there are two or more significantly different
scenarios, so that the main case and the additional subsidiary cases
are clearly differentiated. The main purpose of this classification is to
separate out a special case. You should add a condition to each
extension – with either a note or an extension point – to specify
when the variant behaviour will be included.
(d) No, it is not necessary to place the «include» stereotype and the
«extend» stereotype on all diagrams. In fact, in some situations they
can cause confusion since they will not be understood by everyone.
(e) Each use case that benefits from the component must have a
relationship to that component shown on the diagram. This
relationship should have the «include» stereotype attached to it.
4.3 Problems with use cases

The above example about access to the hotel system illustrates a more general
modelling problem for the developer. It is often difficult to separate a problem
from its solution. In practical terms, you might express it as a question about
the activities of analysis and design: ‘Am I analysing the problem or
designing a solution?’
In object-oriented software development the question is hard to answer. You
may find it easier to think of analysis as the activity of investigating a
problem and opening up choices, in contrast with design as the activity of
taking decisions and narrowing down the number of choices to arrive at a
solution. In practice, a use case diagram represents a vision of what the
solution, a new software system, will do for its users.
With use cases, you also run the risk of straying into a top-down, functional
decomposition and away from the object-oriented viewpoint that is embedded
within UML. It is easy to decompose each use case into smaller use cases in
your search for reuse through the «include» stereotype. Indeed, if you are
making your project plans according to the use cases that you identify, the
urge to find a use case of a size that you can easily estimate is understandable.
175
A good project manager will make some assessment of this risk and review it
upon each iteration of the life cycle.
Another common problem with use case modelling is deciding the size and
scope of each use case. There is no consensus on this issue, because of the
wide variety of contexts and viewpoints. However we can say that a use case
should be larger than a single method of a class but smaller than a business
process. In the hotel chain, for example, the handling of reservations would be
treated as a business process separate from checking in and out. That is to say,
make reservation is only one of the tasks in the process of handling
reservations.
No single technique can guarantee that you will collect and identify all the
users’ requirements. If you spend too much time modelling use cases you can
become distracted by the process of modelling and lose track of the main aim,
which is to capture the behavioural requirements for a software system.
Modelling should always be done with a purpose and only so far as it aids in
communication. There is also a danger of missing some of the requirements,
especially if emphasis is placed on actors and their tasks, because some
requirements may not emerge in this process. A developer should use more
than just one technique to understand a proposed system. For example, class
modelling (discussed in Block 2 Unit 5) should be performed alongside use
case modelling, since one informs the other. Scott Ambler’s (2002) agile
modelling practices of iterative and incremental modelling, as mentioned in
Section 3, reinforce the need of:
. applying the right modelling technique(s), and
. using different models in parallel.
We may set off to produce use cases that are intelligible to customers, but
allow them to get so elaborate that the customer can no longer understand
them. Having decided to represent requirements in one or more use case
models, the most important thing to consider is their intended audience. You
need use cases that can be read and understood by the domain experts as well
as the team of developers. The domain experts usually come from the
customer’s area. If you cannot demonstrate the benefits of your proposed
solution to them, there is little chance that it will be acceptable to the
customer.
Similarly use case models must be useful to the rest of your development
team. For example, those who will be testing the software system must be
able to generate their test scripts from the use cases and the subsequent design
artefacts. In the approach followed in this module, by detailing software
requirements for each step of a use case and defining a fit criterion for each of
these requirements, the path is well defined for the development team.
In terms of the content of each use case diagram, you should avoid the use of
the «include» and «extend» stereotypes for an audience that is less familiar
with UML than your team members. The simple notation for actors and their
associations with use cases has been a factor in their favour.
176
Scott Ambler’s (2002) agile modelling practices supporting effective team

work and communication and simplicity are important in judging the most
adequate level of use case modelling.
SAQ 11
What problems may arise when developing a software system from a set of
use cases?
Answer
One problem is that the focus may end up being top-down and function-
oriented, resulting in an inflexible and difficult-to-maintain system.
Focusing on use cases may cause the developer to sacrifice the object-
oriented nature of the system, thus losing any advantage that UML offers.
Another danger lies in mistaking design for requirements, where a design
decision is mistaken for a constraint. Focusing on the requirements in a use
case may cause the developer to view the system too operationally, where a
sequence of events is assumed to be the only answer. Developers need to
distinguish between requirements and preferred designs.
Use cases need to be used in a way that is understandable to the customer
but also useful to the developer.
Exercise 7
What are the tasks involved in preparing a use case model (for a moderately
large system) intended for the development team?
Solution
The tasks comprise:
. defining the context for the model by identifying the actors involved in the
aspect of the system in question
. analysing the behaviour that each actor expects from the proposed system,
and identifying the use cases (as units of functionality within the overall
requirements)
. identifying the common behaviour that may be reused by other actors, and
the variations on common behaviour (the stereotypes «include» and
«extend»)
. drawing a model that shows the use cases, the actors and the relationships
between them
. annotating the use cases as you learn more about the requirements.
For large projects, you will need to record separately any constraints that
affect more than one use case diagram. One way is to produce a use case
model at a higher level of abstraction.
177
Exercise 8
Recall the hotel example, which was introduced in Section 3 (see Figures 9
and 10). Redraw Figure 9, taking into account the information contained in
Tables 1, 2 and 3 to show common tasks and any extensions to the main
success scenarios.
(Do not show the log on use case from Figure 16.)
Solution
Our solution is given in Figure 18.
When a Guest checks in, we can identify two components: identify reservation
and check for available rooms.
When a Guest checks out, we can identify at least one component: prepare
bill. A bill is assumed to exist because the check in guest use case includes
open new bill for the guest. This is something for the developer to check in
discussions with the users. We will also assume that the records of payments
made by guests are held separately, which is a typical accounting procedure.
Hence we have identified a new actor called AccountsSystem that
communicates with open new bill and prepare bill.
Since a room must be cleaned after a guest has checked out we have identified
a use case named request room cleaning. This is the kind of detail that you
are likely to discover as you find out more about the problem domain.
Finally, there may be an early design decision to change the way that
reservations are created. The difficulty arises because there is a subsidiary goal
to create a new guest record if the person identified during reservation is not
known to the hotel system. For example, you may decide to have a software
component that identifies those who have already been entered into the hotel
system (in a use case called identify guest, say). Such a component is very
likely to be reused in other use cases. As a consequence, creating a new guest
could be seen as an extension of identify guest, whenever a condition such as
guest not found is encountered.
178
«extend»
«include» identify guest create new guest may become

different use
cases upon
further analysis
Reserver make reservation «include»
check for available rooms

«include» identify reservation
Guest
«include»
«include»
Receptionist check in guest
«include» confirm details
open new bill AccountsSystem
«include» prepare bill
check out guest «include» assumed new

use case
request room cleaning
Figure 18 A use case diagram for a hotel
Undoubtedly, your diagram will differ in some aspects from Figure 18, but
you should be able to justify your choices. You should have used «extend» to
show variant behaviour and «include» to show the potential use of
components. We have deliberately added enough new use cases to show how
easy it is for use case diagrams to become quite complicated. Such complex
use case diagrams are unlikely to be shown to the intended users – they are
intended for the development team.
179
Exercise 9
An online bookshop wants to extend its operation to films by mail order or
online downloads. Anyone will be allowed to browse through its titles but it
will require customers to register as members to order films by post or to
watch them online.
Anyone can join the scheme online by providing credit card details as well as
their postcode, which allows the company to perform a credit check and locate
the prospective member’s home address while they wait. The payment is a
monthly fee and membership can be cancelled at any time.
The new software system should enable a member to browse films, add films
to a rental queue and prioritise the films in the rental queue by the order they
should be posted. The films will be sent in the order of the rental queue (if
possible), either one or three at a time, depending on the scheme joined.
Films can be kept by members as long as they want except that more films are
only sent when those rented out are received back.
Members can also watch films instantly online. At most three films can be
watched simultaneously for one membership.
Draw a use case diagram for the proposed system, and identify the constraints
or assumptions that you make.
Solution
The notion of renting films is similar to that of lending books, which you saw
in Example 1, i.e. the two domains are similar, which should help you identify
the actors. (We need to take care, of course, that we do not make unjustified
assumptions.) This example is more complex due to rental queues and instant
downloading of films.
A good first step is to establish the context for the proposed system by
identifying the actors that surround it. When you have identified the actors,
you can investigate the behaviour that each one will expect from the proposed
system, which will eventually form the use cases for your model.
Working with the analogy to the library case study, the two basic actors are:
. Member
. FilmLibrarian
Two other actors are the person who just wants to browse the films available
and the person who wants to become a new member. We distinguish between
the two (CreditCardHolder and Browser) as there is a constraint restricting the
kind of people who can join. This raises the need for a connection to an
external system that can perform credit checks. Thus there are three more
actors:
. Browser
. CreditCardHolder
. CreditAgency
180
Thinking about what a Member can do we have the following use cases:
. browse films
. add to rental queue
. prioritise queue
. online watching
. cancel membership
. upgrade/downgrade scheme
The use cases for the FilmLibrarian are:
. update catalogue
. receive DVD
. issue DVD
And the use case for a Browser:
. browse films
As both CreditCardHolder and Browser can also browse films, Browser is a
generalisation of these two actors.
There is an additional use case that is shared by more than one actor, which
we will call join scheme, since it links credit card holders with the
CreditAgency authorisation service.
Note that there is a use case for the FilmLibrarian to receive a DVD but no
use case for a Member to return a DVD. This is because to return a DVD the
member does not use the system, just the postal service, while receiving a
DVD requires updating the system.
181
browse films update catalogue

Browser
FilmLibrarian
join scheme receive DVD
CreditCardHolder
add to rental «include» issue DVD

queue
«include»
CreditAgency
number of DVDs
sent depends on
prioritise queue membership
«include»
«include»
check rental queue
Member
online watching «extend» no more than

three simultaneous
watches
refuse instant
watching
«include»
cancel membership
«include»
downgrade scheme check membership

«include»
upgrade scheme
Figure 19 A use case diagram for a film rental business
The diagram in Figure 19 is one possible use case diagram for the proposed
system. You may have used slightly different names on your diagram and you
may have identified alternative use cases to those we have shown. There are
many possible solutions. You might have tried to share some of the use cases,
but this would assume knowledge of the internal structure of the proposed
182
system. You should check that in your use case diagram you have included
the behaviour that will bring some discernible value to the actors.
Finally, you should have included some notes with both the diagram and the
elements in it. For example, the diagram shows a note with the refuse instant
watching use case indicating the maximum number of simultaneous watches
for a member. This is an excellent way to record constraints on the
requirements.

In this section, you have seen that use case models play a key role in the
development of a software system, especially when the user is placed at the
centre of a development process. Use cases help you record the proposed
requirements for a software system and add detail to their relationships as
follows.
. The «extend» relationship between a new use case and an original use case
shows how the system should deal with conditional behaviour.
. The «include» relationship shows how a subsidiary use case can provide
some common functionality to two or more use cases at a higher level of
abstraction.
. The «include» relationship between use cases shows how the system can
employ a pre-existing component.
Hence use cases provide a starting point for project and quality management.
183
5 Getting users involved

In this section you will learn how to involve users in the process of software
development.
Finding requirements involves identifying, recording and documenting the
things that the intended users do as part of their interaction with a system.
Usually a developer will produce textual descriptions of the potential
scenarios and attach them to the relevant use cases. In Section 2 you saw that
an activity diagram enables a developer to model one or more processes in
order to understand the work involved in the users’ domain, such as a library.
However the domain of the developer’s expertise is software development,
whereas the users are experts in their own domain. Even with the support of
experts in the users’ domain, the most significant mistakes are usually made
during requirements analysis. The cost of rectifying such errors increases the
later they are detected in the development process. Thus identifying use cases
and then testing them helps to detect or avoid the kinds of error that might
arise:
. by missing a requirement
. by not understanding a requirement
. through ambiguity.
Agile developers stress, as discussed before, a close involvement with the
customer, accept that requirements will be identified throughout development
and that they will change.
5.1 Prototyping for and with the user

One of the ways to improve the analysis and identification of requirements is
for the developers to produce a prototype. A prototype could be a paper-
based model, or a simplified software system that is a subset of the eventual
product. It can take several forms:
. a mock-up of the human–computer interface for a specific group of users
(remember that good software systems must be usable)
. a working version of a subset of the functions required from the eventual
product
. an existing piece of software that has some relevance to the users’ needs
and may be considered for further improvement for use in the eventual
product.
One of the main uses of prototyping is to help with the design of the user
interface for the proposed software system. It is a way of getting the users
directly involved with the development of the software. By working closely
with the users you can minimise or avoid any misunderstanding and
consequent false expectations on the part of either the developer or the users.
When the final product becomes available it is less of a surprise to its users
184
and this helps the customer overcome any resistance to change that can
undermine the investment made in the software system.
The activity diagram in Figure 20 illustrates the general process of
prototyping. There are two important guidelines that should be followed. First,
the developer and the user must know what the particular prototype is to be
used for and they need to agree on a goal that must be achieved. This will
include an agreed schedule for building the prototype.
Second, the prototype should be evaluated against its goal.
discuss purpose
and scope
[purpose and scope

identified] design build
prototype prototype
[purpose and scope

not identified] [not finished]
evaluate
[finished] prototype
Figure 20 Activity diagram for the prototyping process
A prototype is not intended to be a complete working version of the software.

It is not necessary to spend a great deal of time on getting the code ‘right’,
because you may choose to scrap the code after completing the evaluation of
the prototype. For this reason, a prototyping tool can be beneficial. For
example, a good tool can help you assemble screen or report layouts quickly
and rework them after each evaluation.
Note that the main goal is to make sure that the prototype meets the needs of
its intended users. It is important not to agree to produce a prototype that does
not benefit the users. It is time to stop when you are not generating any new
requirements (or when there are only minor requirements that would not be
paid for by the customer). Next the developer needs to document what has
been achieved – the evaluation of the prototype. This will provide the
information on the final software system for all those people involved in its
development.
Finally the people who should be involved in the development of the
prototype are the ‘real’ users – those who will use the interfaces that are
developed from the prototype. They know their own needs for their day-to-
day role and they have the most to gain from a successful implementation.
185
It is often the case that a very light prototype may be sufficient. For example,
prototypes for user interfaces comprising a series of sketches that will
illustrate different screens may be sufficient to get users’ feedback.
SAQ 12
(a) Who initiates the prototyping process?

(b) Who should test a prototype?
Answer
(a) The developers would normally start the prototyping process because
they have detected or identified a particular problem in their
requirements analysis. (But note that the project manager would need
to get approval from the customer for the additional effort.)
(b) The intended users should test it. For example, if you developed a
series of interfaces as part of a prototype for the borrowing and
returning of books, the library members would be the testers.
5.2 Linking activities to user interfaces

Before any prototyping of user interfaces can take place the developer needs
to identify the appropriate interfaces from the users’ requirements and
determine where and when they will be needed. One way to achieve this goal
is to use an activity diagram.
186
NonMember Librarian LibrarySystem
request
request enrolment
enrolment information
provide
enrolment
information
record enrolment record new

information member
issue issue
receive membership membership
card card number
Figure 21 An activity diagram for the enrol member use case
Consider the activity diagram in Figure 21 illustrating the enrol new member
use case for the lending library of Exercise 4. It shows the interactions
involved in enrolling a new member and the activities carried out. A non-
member of the library interacts with a librarian. The non-member requests to
be enrolled and provides information when requested by the librarian. The
librarian then uses the system to record the enrolment information. Therefore
the librarian needs an interface with the software system for recording the
information. This interface will be needed when a non-member request to
enrol is dealt with by a librarian. This transaction is complete when the library
system:
. checks the information entered
. generates a membership number
. creates a new member record with the information entered and the
membership number
. informs the librarian of the membership number
Thus the user interface for the use case enrol new member must be available
to the librarian when dealing with the enrolment request.
Hence the developer can record the association between activities and
interfaces, as shown in Table 4.
187
Table 4 Associating interfaces with user activities
Activity Interface
record enrolment information enrol new member
This is a very simple illustration of how to identify a user interface from the
activities carried out in a use case. We would need to consider the other use
cases within the library.
One of the goals for a prototype would be to design and/or construct an
interface for the library’s system to enable all the use cases. Members and
The developer can also gain a librarians would test the prototype to find out what is good or bad about it.
greater understanding of the Both librarian and developer should ensure that nothing is ‘missing’. The
domain through the prototyping librarian can see whether or not each requirement has been addressed, thereby
process
relating requirements to implementation (i.e. there is traceability in the design
of the prototype).
Finally we must stress that software development involves a variety of
modelling activities, which we will continue to investigate in the following
units. For example, we must look for the real-world objects that go into our
conceptual model, which means that we must also look at a class model.
Use case and activity diagrams are only a starting point. They are an
incomplete representation of a software system, and you may have to return to
them for modification in a later iteration of the project.
SAQ 13
(a) What is the main benefit of identifying user interfaces in your

activity diagrams?
(b) Suppose the developer built a prototype interface that could deal
with all identified use cases in the first iteration of the library system.
Suggest a criterion that a librarian might use when evaluating the
prototype, which goes beyond the completion of the underlying tasks
within each use case.
Answer
(a) The main benefit of recording user (or any other) interfaces in an
activity diagram is traceability. To the users, the interface is the
software system: an unacceptable interface can lead to failure. The
user interface is the link between what the users want and what the
developer produces in response.
Also, the developer can identify the relative importance of each user
interface for the project plan, particularly when resources are needed for
a prototype.
(b) This was the example we thought of, but you may have thought of
others. Librarians may find it essential that the system makes it very
easy to switch between different tasks. They will expect the
prototype to provide evidence that the eventual system will meet this
criterion.
188
Exercise 10
Draw an activity diagram to show the separate responsibilities of the
receptionist and the hotel system for the check in guest use case. Your
diagram should contain the main success scenario. You do not need to show
any extensions.
Solution
We can use the textual description of the check in guest use case from
Exercise 6 of this unit. Figure 22 shows an activity diagram showing the
exchange of information that takes place at the user interface.
Receptionist Hotel System
[guest has
no reservation]
[guest has reservation]
enter reservation
reference number
look up
reservation
confirm guest’s
details
request allocate
room room
open new bill

for the guest
issue key prepare for

to guest next entry
Figure 22 Separating the responsibilities during a prototyping activity
189
The receptionist initiates the use case, as shown in the diagram. Some of the
activities show the conscious acts that a receptionist needs to undertake in
order to make progress in the main success scenario for checking in a guest.
This helps to identify the interfaces that would need to be included in a
prototype.

In this section, you have seen that activity modelling can help identify when
the user would need to use an interface to the proposed software system. You
can use activity diagrams for any of the scenarios of a use case where some
interaction with an actor is expected. Prototyping the user interface brings
developers and users into close contact with each other. By working together
it is possible to minimise any misunderstanding that might lead to false
expectations on either side.
190
6 Summary
Summary 6
In this unit, you have learnt how modelling can help with the process of
requirements engineering in a variety of situations. In particular, you studied
the roles of activity diagrams and use cases. We used activity diagrams to
understand business processes of the domain. We also used them to help
developers identify when users would need to have an interface available in
order to complete their activities in different scenarios. Prototyping plays a
important role in this task. Use cases help with the identification of the
requirements for a software system. You have explored how use case and
activity modelling can be used to help in consultations with the users and
have also seen some of the limitations of these techniques.
On completion of this unit you should be able to:
. discuss the connection between users’ activities and the interface to a
software system
. use techniques such as activity diagrams that allow you to understand a
business domain and model the context of a proposed software system
. use modelling techniques such as use cases to help with the elicitation and
detailed representation of requirements
. apply use cases confidently and discuss their use throughout software
development
. carry out a detailed analysis of users’ activities.
191
References
Alexander, I. and Maiden, N. (2004) ‘Negative Scenarios and Misuse Cases’,
inAlexander, I. and Maiden, N. (eds) Scenarios, Stories, Use Cases through
the Systems Development Life-Cycle [Online], Chichester, John Wiley & Sons.
Available at http://www.open.ac.uk/libraryservices/resource/
ebook:0470861940/provider/ProQuest_Safari_Tech_Books_Online (Accessed
10 January 2014).
Ambler, S. (2002) Agile Modelling [Online], New York, John Wiley & Sons.
Available at http://www.open.ac.uk/libraryservices/resource/512396 (Accessed
10 January 2014).
Cockburn, A. (2002) Use Cases, Ten years Later [Online]. Available at http://
alistair.cockburn.us/Use+cases%2c+ten+years+later (Accessed 28
January 2014).
Cockburn, A. (2003) Agile Use Cases [Online]. Available at http://alistair.
cockburn.us/get/2231 (Accessed 23 January 2014).
Cockburn, A. (2006) Agile Software Development, 2ndedition [Online],
Addison Wesley. Available at http://www.open.ac.uk/libraryservices/resource/
ebook:0321482751/provider/ProQuest_Safari_Tech_Books_Online (Accessed
10 January 2014).
Eriksson, H.E. and Penker, M. (2001) Business Modeling with UML: Business
Patterns at Work, New York, John Wiley & Sons.
Krutchen, P. (2003) The Rational Unified Process: An Introduction, 3rd
edition [Online], Reading, MA, Addison Wesley. Available at http://www.
open.ac.uk/libraryservices/resource/ebook:0321197704/provider/
ProQuest_Safari_Tech_Books_Online (Accessed 9 January 2014).
Leffingwell, P. (2011) Agile Software Requirements, Reading, MA, Addison
Wesley.
192
Unit 4 The case study: part 1
Contents
1 Introduction 197
2 The UP in practice 200
2.1 What happens in inception 200
2.2 What happens in elaboration 201
2.3 An agile UP 202
2.4 Approach followed in the case study 202
3 Initial problem statement: the hotel chain 203
3.1 One iteration of the case study 203
4 Understanding the domain 205
4.1 Business rules 205
4.2 Business processes 205
5 Scope of the new system 212
5.1 Use cases 212
5.2 User stories 215
6 Volere template 217
7 Detailed software requirements 220
7.1 Elaborating the use cases 221
7.2 Software requirements 224
7.3 Initial architecture 232
8 Testing 234
8.1 Testing with scenarios 234
8.2 Testing with fit criteria 235
8.3 Testing with user stories 236
9 Summary 237
References 238
1 Introduction
Introduction 1
In this unit, we investigate the requirements for a reservations system for a
chain of hotels. We start from an initial problem statement and work through a
range of activities, to arrive at sufficiently detailed requirements to support the
analysis, design and implementation of the system. Our goal in this unit, then,
is to arrive at a set of use cases for the proposed system, along with a set of
software requirements.
We also illustrate an agile approach to this stage of development. Agile
development relies heavily on the work of a team and on conversations
between developers and customers; we illustrate some of the techniques used
to generate these conversations.
In later units, we will continue with the development of the system, based on
the work carried out here. The overall development process we use will be
loosely based on the UP (Unified Process) (Jacobson et al., 1999) introduced
in Unit 1 and further discussed in Section 2.
An initial problem statement contains information on the current business
processes of a hotel in the chain, as described in Section 3. To elaborate on
this information, we need to understand the domain well and to document the
business rules and current business processes, as described in Section 4; we
will be using activity diagrams to represent the business processes. Domain
modelling allows us to check that we understand the way the current business
works. This is particularly important if we start with a poor conception of how
the hotel operates its business. Another reason that domain modelling is useful
is that some of the business rules and processes will carry through to the new
system; therefore we need to understand them to be able to implement them in
the new system. In practice, of course, domain modelling would be done in
consultation with the stakeholders. The same is true of eliciting the initial
problem statement. Indeed, these tasks would probably be carried out
iteratively and would perhaps be intertwined.
From the initial problem statement and the domain modelling, in Section 5 we
draw up a use case model, show an alternative approach based on user stories,
and define the scope of the system to be developed. Again, in practice, this
would involve eliciting information from the stakeholders to elaborate on any
details that are unclear or unspecified. We can, at this stage, start sketching a
high-level architecture for the solution which separates the main parts to be
developed.
Having scoped the system, in Section 6 we record the user requirements using
the Volere template (introduced in Unit 2). Once again, in practice, this would
generally involve consultation with stakeholders. In fact, such consultation is
likely to occur throughout requirements engineering.
The next phase of the requirements process is to draw up the software
requirements (Section 7). This work will draw on the artefacts produced
previously. We begin by providing detailed scenarios for each of the use
cases. We then extract from the use cases the detailed functional software
197
requirements, refining them to the stage where they have clear fit criteria. We
also need to ensure that the non-functional requirements are similarly refined,
and indicate the use cases and/or individual functional requirements to which
each non-functional requirement applies. In principle, the resulting functional
and non-functional software requirements can be added to the Volere template.
We use the same headings as the ones in the template without duplicating the
whole template. In a large development it would be sensible to use a tool to
manage the requirements; this might also save on duplication when a
requirement gets updated.
With a set of use cases and a list of requirements with associated fit criteria,
in Section 8 we discuss the tests that can be defined, at this stage, to validate
the final product.
The use cases we develop in this unit will be used later during analysis and
design, to indicate what functionality needs to be supported. The software
requirements play a number of roles:
. providing extra details during design, where a step in a use case scenario
needs clarification
. drawing up system tests – here we exploit the fit criteria of the functional
and non-functional requirements
. indicating, from non-functional requirements, how suitable our choice of
architecture is
. checking the design and implementation elements that support each use
case.
In this unit, we develop a case study and present an approach to a given
problem based on a number of decisions that could have been made
differently. We are not claiming that the approach here is the best possible –
only that it illustrates a plausible, practical application of the material in the
preceding three units.
198
1 Introduction
business business
glossary problem rules
statement processes
Identifier and Name Industry copy
of rules
Initiator
Industry copy Industry copy *

Goal of rules of rules
*
domain Pre-condition
modelling Post-condition
Industry copy
of rules
Industry copy
Structural domain model

of rules
– conceptual classes and associations

– conceptual attributes
– no operations or interfaces as yet
glossary problem use case elaborated use functional and non-

statement model cases functional software
Identifier and Name
requirements
Make a reservation
Identifier and Name
requirements Initiator
Cancel a reservation Initiator
SF12: UC_1, Step 7
Goal Description: The system shall assign a unique number for a reservation
Goal
Check-in guest
Pre-condition
Pre-condition
Receptionist
Post-condition Check-out guest
Post-condition
glossary
*
Identifier and Name

system operations *
Initiator
Context
analysis Goal Pre: ...
Pre-condition
Post: ...
Post-condition Structural analysis model

– analysis classes
– constraints
glossary communication structural design model

diagram
– operations
Identifier and Name
*
– navigability
Initiator
design Goal
*
– qualified associations
Pre-condition
– system class
Post-condition
and operations
Figure 1 Parts of the development process covered in this unit (in grey)
199
2 The UP in practice
The UP (Jacobson et al., 1999), which was introduced in Unit 1, is a popular
iterative and incremental development process for building enterprise systems
based on an object-oriented approach. Here we mention the two initial phases
of the UP, inception and elaboration, but will mostly focus on elaboration.
2.1 What happens in inception

Inception is the initial planning phase of development. It is when a vision is
defined, a business case is made and development is justified. Is there the
capacity to carry out the development? How is the software going to be used?
Is the project going to deliver value? The activities carried out are usually
defined under project management and are not covered in this module. They
include:
. planning the project schedule
. finding the right people to work on the project and assigning them to tasks
. making sure the team is properly trained and has the proper tools and
work environment
. liaising with the customer
. analysing and managing the risks
. estimating the effort required
. making sure that the lessons learnt on other projects in the organisation
feed into this project and that this project’s lessons are passed on to others.
When a project to develop software is established, it is important to have a
good idea, at the outset, of how much effort will be required and for how
long. Once estimates have been made, the work required must be assigned to
people or teams, and to periods of time, to give a work plan for the project.
Progress of the project is then monitored and assessed relative to this plan.
During inception, an initial use case model may be drafted to define the scope
of the project, as well as an initial architecture. In the UP, inception is mostly
done upfront but it can also be revisited in the first iterations.
What happens in an agile approach

Agile methods, such as XP and Scrum also define a planning phase. For
example, in XP, Beck (2000) proposes the Planning game, with two
participants, the business and the development. This game takes place not
only at the beginning of the project but also at regular intervals (say, every
three weeks) to determine the priorities and work for the next release and to
define a plan. The game is played with the story cards, and the moves of the
game can be split into the three following phases: finding out new things that
can be done (exploration), deciding what to do next (commitment), and
steering to update the plan based on reality. Iterations are planned in an
200
2 The UP in practice
iteration planning game which is a similar game that occurs at an even more
frequent rate; instead of story cards the pieces of the game are tasks.
In Scrum, planning is done also regularly for each sprint; a sprint is a
timeboxed period of a maximum of a month where usable software is
delivered. The sprint planning meeting, also timeboxed, lasts no more than
eight hours and plans the work for the sprint.
2.2 What happens in elaboration

It is in the elaboration phase that most analysis and design occur. Some of the
activities in inception will carry on to elaboration, such as the refinement of
the vision, business case, project plan and risk assessment.
There will be some domain modelling (in the UP it is called business
modelling), requirements, analysis, design, implementation and testing in each
iteration, but the amount of work involved in each of these will vary from one
iteration to the next, as shown in Figure 2.
UP phases
inception elaboration construction transition
business modelling
requirements
analysis and design
implementation
testing
project management
deployment
UP disciplines iterations
Figure 2 UP phases and disciplines
In this unit we explore both domain modelling and requirements. You will be
modelling to an extent that would probably not be fully carried out if you
were part of an agile team. As part of an agile team you would probably be
standing around a whiteboard and scribbling some diagrams to get a quick
shared understanding. In this module, you may, instead, be using a tool that
201
will help you with correct diagrams. These are not incompatible activities; by
understanding the details of the techniques used and their correct use you will
be in a better position to take decisions, in a real project, of how much
precision you will need in your models.
2.3 An agile UP
Agile approaches give more emphasis to testing and implementation than to
analysis and design. Analysis and design will still take place, not as fully
developed complete activities, but as support to communication and achieving
a shared understanding within a team and with the customer. In agile
development the unit tests (tests associated with a unit of functionality, such
as a class) are in reality the design, as they are developed before the code is
written.
The UP is a flexible process and most of the artefacts it proposes are not
mandatory. It is therefore easy to adapt. The culture of the organisation, the
ways of working of the development team, and the problem and its context
dictate which models, diagrams, and documents are useful and how they
should be used. Scott Ambler (2012) and Craig Larman (2005) propose an
agile UP where the initial disciplines of the UP (business or domain model,
requirements, analysis and design) are collapsed into a single ‘model’
discipline where iterations are short (weeks rather than months) and frequent;
product is delivered incrementally if at all possible; design and
implementation do not wait until all the requirements are found;
implementation of the core system is started while requirements and
architecture are still being refined. These are all possible in the UP as it
promotes timeboxed iterations and adaption.
The main principles behind an agile approach to the UP are those of the agile
manifesto (that you encountered in Unit 1), stressing simplicity, agility, and
focus on activities that return value and on a product that satisfies customers’
needs. However, agility should not be confused with a lack of process. On the
contrary, agile approaches such as Scrum or XP propose a well-defined
process that requires careful training.
2.4 Approach followed in the case study

In this unit we look at two of the disciplines of the UP: domain modelling and
requirements. We will concentrate mostly on the elaboration phase of the UP.
We will focus on a single iteration of the system and will identify a small set
of use cases as a suitable set of requirements for the first iteration. These will
provide a usable slice of functionality. We will also focus during the first
iteration on the main success scenarios for these use cases, although we will
document relevant extensions for future reference.
202
3 Initial problem statement: the hotel chain
Initial problem statement: the hotel chain 3

A business that runs a chain of hotels in London has decided to commission a
new computer system to manage reservations, and to check in and check out
guests. Currently, the company has a software package that can carry out these
tasks for an individual hotel, and each hotel runs this package. However, this
is problematic. For example, if one hotel is full and receives a reservation
request, the company tries to locate a suitable room in another of its London
hotels. To do this a receptionist has to ring around the other hotels. Similar
problems arise if a customer wants to transfer between two hotels in the chain.
The new software should resolve this business problem by implementing a
single, common reservation system across the whole chain. Additionally, the
business wishes to gain a competitive edge with a frequent-guest programme
to encourage repeat custom. Customers who rebook will be given discounts
and other benefits, such as free newspapers.
The system should provide a system administrator with the ability to add new
hotels to the system as they are acquired or built. Additionally, hotel managers
should be able to add and remove rooms and room types to and from the
system in response to activities such as decorating and building work.
Currently, each hotel deals only with reservation requests made by phone or
email, but the future system must also deal with reservation requests made
directly from a web browser. Payments are currently dealt with by each hotel,
but in the new system a web browser reservation will require the customer to
enter details of a debit/credit card account, which will be debited
automatically on the check out day. In the event of a late cancellation (less
than 24 hours before the check in date) or a ‘no show’, the customer will
automatically be charged for one night’s accommodation. The total charges to
all customers booking via the web will be recorded on a weekly and monthly
basis.
As the hotels do a lot of conference trade, block bookings are important to the
business. A receptionist can check how many rooms are available in their
hotel, but must then manually reserve each room required. Any overflow
involves the receptionist phoning other hotels in the chain to book rooms
elsewhere. This makes it hard to keep track of every person associated with a
block booking. That in turn makes application of block-booking discounts
extremely tedious. In the new system it must be possible to automate block
bookings and deal with any overflow by automatically booking rooms in other
nearby hotels in the chain.
3.1 One iteration of the case study

In order to achieve a quick overview both of the techniques used and of a
manageable iteration of development, we will focus on individual customers
and not on block bookings. Either block bookings can be dealt with in future
iterations, or a decision may be taken that an implementation should be
carried through relatively quickly for individual customers, and once this is
203
achieved a new increment can then be carried out to deal with block
bookings.
204
4 Understanding the domain
Understanding the domain 4

We look now at the existing business, its processes, and the rules that
constrain those processes. Understanding the current business situation is
either the product of extensive domain expertise or the result of many
observations of how people work, and discussions, consultations and
interviews with domain experts, stakeholders and current users of the system.
4.1 Business rules

The rules of the existing business that have been identified by talking to
domain experts so far are the following.
. a guest who cancels a reservation within 24 hours of the check in date will
be charged for one night’s accommodation – a ‘no show’ leads to the same
charge
. if a guest has reserved with a credit card, final payments with that credit
card can be processed automatically.
Many other rules could be considered, such as a rule for what is done when
there are overlapping reservations for the same guest. For the moment, we
will keep to a simple view of the existing system. In future iterations, we
would deal with any more complex rules imposed in the new system, and how
to model them. The current rules are important as they may still be imposed
in the new system. Decisions about which rules are relevant need to be taken
in the elicitation of requirements for the new system. Here, we are particularly
concerned with understanding how things are currently done and how we can
model the activities that take place.
SAQ 1
Suggest a business rule that constrains overlapping reservations made by

the same person.
Answer
Overlapping reservations made by the same person are allowed only if the
guests for each reservation are different.
4.2 Business processes

Below we describe the main processes of the current business. These
processes will most likely still be supported by the new system and it is
therefore important to understand:
. the activities that currently take place
. the problems currently encountered
. what the users would like to do but are currently unable to do.
205
For each process, we give an informal description of its normal behaviour and
describe the exchange of information between the different roles involved in
that process.
Make reservation
The reservation process begins when someone contacts the hotel chain’s
reservation system, normally by phone. The caller (also identified as reserver
or customer) will reserve a room in a particular hotel for one or more nights.
The caller may make reservations on behalf of more than one person. Each
hotel has more than one type of room. Therefore callers must identify the type
of room required by each potential guest and the dates that they wish to stay.
The existing system provides a price for each reservation of a given type of
room, or suggests alternatives when there is no availability. If the caller
accepts an offer, they must then provide the names and contact details for
each guest identified in the reservation. Reservers need to provide credit card
details (we use credit card, from now onwards, as a simplification for credit/
debit card) to keep the reservation. The existing system confirms the
reservation and provides a reservation number that identifies each reservation
for a room. In the simplified version for this first iteration, we are assuming
that a single room is booked in each transaction. Potential guests and hotel
staff can subsequently use the reservation number to speed up the process of
checking in.
There are three roles in the reservation process: the reserver who initiates the
process, the receptionist who deals with the request, and the existing hotel
system. These are represented in Figure 3 by each of the three swimlanes.
This activity diagram is only a first attempt at understanding the reservation
process and more discussion is needed to get the exact detail. It illustrates the
main participants and the main activities carried out, leaving out details such
as what information is provided; it also does not show what happens when
there is no availability and an alternative is suggested.
206
Reserver Receptionist HotelSystem
request a reservation for

one room of a specific
type for specified dates
check
availability
[offers available]
look up dates, number
and types of rooms
[no availability]
make an
offer
[proceed] request guest

details
[do not proceed]
inform
reserver
provide
details
confirm
reservation
record reservation
and allocate a room to
the reservation
get give reservation

number number
Figure 3 Activity diagram for the make reservation business process
207
Cancel reservation
Exercise 1
Write an informal description for the process that cancels a reservation and
draw the corresponding activity diagram.
Solution
Your solution may diverge from the one proposed here; this is just a first
attempt at detailing the cancellation process.
Cancel reservation
The cancellation process begins when someone calls the hotel chain’s
reservation system. The caller will cancel a reservation, giving the reservation
number or the dates of the reservation and the name and address of the guest.
The existing system looks up the reservation, checks whether the cancellation
is being made less than 24 hours from the date of the reservation – in which
case it charges the credit card with the amount corresponding to one night’s
accommodation – closes the reservation and confirms the cancellation.
An activity diagram for this process is shown in Figure 4.
208
Reserver Receptionist HotelSystem
request a cancellation
for a reservation number
or the dates and name
and address of the guest
check reservation number
or the dates and name
and address of the guest
look up reservation
[less than 24 hours from

start of reservation]
[24 hours or more from

start of reservation]
calculate
charge
charge
credit card
close reservation
confirm
cancellation
Figure 4 Activity diagram for the cancel reservation business process
Check in guest
On arrival, a guest gives the reservation number or the dates and name and
address for their reservation to the hotel’s receptionist, who enters it into the
current system. The system reveals the details for that reservation so that the A room is initially allocated to a
reservation; at check in the room
guest can confirm them. The software system allocates an appropriate room to
becomes allocated to the guest
that guest and opens up a bill for the duration of the stay. The receptionist staying in that room.
issues a key for the room.
209
Guest Receptionist HotelSystem
present reservation
number or the dates enter reservation number
and name and address or the dates and name look up reservation
of the guest and address of the guest
request
confirm confirmation of
details details
enter
confirmation
allocate room
to guest
issue key open new bill
Figure 5 Activity diagram for the check in guest business process
In the check in process, instead of the reserver there is now the guest, that is,
the person who is taking up the reservation. Notice that the activity diagram
of Figure 5 illustrates only the normal behaviour of the process, as we assume
that the reservation number or the dates and name and address presented have
a corresponding reservation. In understanding the current process, this is
probably sufficient. When it comes to the new system to be developed, we
need to detail how the system will react whenever the normal path is not
followed. We will look into this later in the unit.
Check out guest

Guests return their keys to the reception desk to signify that their stay in the
hotel is over and they intend to leave. The software system uses the key
number to identify and complete each guest’s bill. Any other expenses made
by the guest and not yet recorded in the system, such as the use of a minibar
in the guest’s room, are added. The system provides an itemised bill for
confirmation by the guest. If the guest is paying with the credit card used for
the reservation, then payment is processed immediately. Otherwise the guest
has to pay by other means, and once payment has been received from the
guest the system notifies the accounts system.
210
Guest Receptionist HotelSystem
return keys retrieve bill look up bill

and request bill
indicate further enquire about

expenses any other expenses
record further
expenses
provide
itemised bill
check bill
[payment not
with reservation
credit card]
provide payment
[payment with
reservation
credit card] process payment
with credit card
accept
payment
close bill
Figure 6 Activity diagram for the check out guest business process

In this section we described the current operation of the business, looking at
its main processes and the rules that constrain them. The business processes
need to be understood, and any problems with them highlighted, before
addressing a software solution.
211
5 Scope of the new system

Having understood the domain, and having an initial problem statement, we
can now start thinking about what is required of the new system to be
developed. We assume that inception has taken place and that there is,
therefore, a business case and a vision for a new system. There may even be a
Architecture will be discussed in sketch of a high-level architecture of the system proposed and an
detail in Block 3 Unit 9. understanding of who the users are and what they would want from the
system.
In this section, we determine the scope of the system from the user’s
perspective. At this stage of development, elaboration, we would be working
with both users and customer, defining requirements, deciding on risks,
estimating effort and deciding on iterations and priorities.
We look at using both use cases and user stories as alternative techniques to
help with understanding the scope of the system and what is intended of the
system. We also outline an architecture for the solution.
In the following sections, we establish the user requirements, that is, what the
proposed system should do from a user’s perspective, and start outlining tests
derived from these requirements. The scope and requirements provide the
basis for a contract between the customer and the developer.
5.1 Use cases

The initial problem statement describes how the new system will extend from
a single hotel to deal with all the hotels owned. The system’s interface will
cover all of the following:
. front desk staff in each hotel dealing with:
◦ reservations by email, phone, post, or in person
◦ cancellations of reservations
◦ check in and check out of guests
. anyone using a web browser to view information and make reservations
. managers:
◦ adding or removing a room type
◦ adding or removing a room
. system administrators adding or removing a hotel
. the external payment system to handle payments.
We will now look at the business processes identified for the existing system
that will be carried through to the new system. Each will correspond to one or
more use cases for the existing system.
Make reservation. The receptionist interacts with the system to make a
reservation.
212
Cancel reservation. The receptionist interacts with the system to cancel a

reservation.
Check in guest. The receptionist interacts with the system to check in a guest.
Check out guest. The receptionist interacts with the system to check out a
guest.
make reservation
cancel reservation
Receptionist
check in guest
check out guest
Figure 7 Use case diagram for the existing system
Note that in Figure 7 there is a single main actor: only the Receptionist
interacts with the system. The new system will have other roles interacting
with it.
The new system will deal, in a first iteration, with the following use cases.
Add/remove hotel. A system administrator’s role will include adding and
removing hotels in the system.
Add/remove room type. A manager’s role will include adding and removing
room types in the system.
Add/remove room. A manager’s role will include adding and removing rooms
in the system.
Make reservation. A reservation can be made either directly by a receptionist
or on the internet by a reserver.
Cancel reservation. A reservation can be cancelled either directly by a
receptionist or on the internet by a reserver.
213
Check in guest. A receptionist will check in guests.

Check out guest. A receptionist will check out guests; this use case will also
interact with the external payment system.
Figure 8 shows the use case diagram for the new system.
make reservation
Reserver
cancel reservation
Receptionist
check in guest
ExternalPaymentSystem check out guest
SystemAdministrator add/remove hotel
add/remove room type
Manager
add/remove room
Figure 8 Use case diagram for the new system
214
So far, all we have identified are the main use cases of the system. These use
cases give a good overview of the system, so fulfilling the criteria for a good
coverage (discussed in Unit 3). They correspond to the main business
processes that will be carried out with the new system. Taking these together
with the initial problem statement, in Section 6 we outline the main user
requirements of the system. In Section 7 we will detail the use cases to define
the software requirements for the new system.
An alternative approach to beginning the requirements process, based on a
lighter and more agile process, might be based on user stories.
5.2 User stories

User stories play a different role from that of use cases.
A use case corresponds to a business process, is written (usually following a
template) to document an agreement and is as complete as possible for the
derivation of requirements.
User stories are not a way of documenting agreed functionality of a system;
they represent the perspective of a single user wanting some bit of
functionality described at the instance level. They should be small enough to
be implemented in a single iteration, they are used to plan iterations and
releases, and they serve to trigger the conversations needed to understand
what the requirements of the system are.
A use case may contain several user stories.
User stories may be annotated with constraints and other detail but they are
not an agreed contract to which developers can return.
Examples of user stories are:
. as a guest I can pay in advance with a credit card
. as a guest I can choose the type of room to reserve
. as a guest I can cancel a reservation with a reservation number.
In agile development we might then start to produce code to satisfy these user
stories, eliciting the requirements as we do so. So while we are collecting
requirements we are not writing them down as a distinct model. Rather, the
requirements get embodied in working code, and depending on the clarity of
the code this could be seen as either a good or bad thing! At one extreme,
then, the approach in Sections 6 and 7 becomes redundant. Alternatively, an
agile approach could be adopted with selective use of the techniques in those
sections, but without a commitment to use, during maintenance, the artefacts
produced. That is, explicit models might be built, but on a throw-away basis.
Both use cases and user stories can be gathered using a common set of
techniques to interact with users and other stakeholders such as interviews,
questionnaires, observation and workshops (Cohn, 2004).
215
SAQ 2
What are the main differences between a use case and a user story?
Answer
A use case describes a business process or a self-contained task within a

process. It is as complete as possible, lasts as a document, is agreed (by
customers and developers) and is used to generate requirements.
A user story is small enough to be implemented in a single iteration,
represents an instance from a user perspective, is not complete, does not
last and instead is used as a reminder for a conversation.
SAQ 3
Consider the required characteristics of a user story as described in Unit 2:

independent, negotiable, valuable to users and customers, estimable, small,
testable. Give an example of another valid user story for this case study and
of a user story that would not satisfy these criteria.
Answer
Another valid user story could be:

. as a manager I can remove a room from the bookable rooms in a
hotel when the room is being refurbished.
An example of a user story that does not satisfy the criteria is:
. as a guest I must find the interface friendly – this is not a good
example as it is not a testable story.

The scope of the new system has been defined, listing the actors the system is
to interact with and the use cases it should carry out. We also looked at the
use of user stories in scoping the new system.
216
6 Volere template
Volere template 6
We use the Volere template here to start outlining the user requirements of the
system. The use cases identified in subsection 5.1 for the new system serve as
the basis for the functional requirements in the template below. Later on, to
proceed with development, we will need detailed software requirements at a
level where each can be tested. We will derive these from the steps of the use
case scenarios as shown in Section 7.
We use a shortened version of the Volere template to list the initial set of
requirements in the box below. Given how vague these are, there would be
problems in verifying whether our system satisfies them. This vagueness is not
unrealistic: in a real project, you could certainly expect many of the initial
requirements to be ambiguous or unverifiable. However, they form a starting
point from which to generate more detailed use case scenarios and software
requirements.
Hotel chain system user requirements
Product constraints
1 The purpose of the project. A company runs a chain of hotels in
London and has decided to commission a new computer system to
manage reservations, checking in, and checking out across the whole
chain of hotels. Currently it has a software package that is able to
carry out these tasks for each individual hotel, but there is no way of
dealing with reservations across all the hotels. The company also
wants to introduce a frequent-guest programme to encourage repeat
custom. Guests who rebook will be given discounts and other
benefits, such as free newspapers.
The new system should provide some managers with the ability to
add/remove room types and rooms to the system. System
administrators should have the ability to add/remove hotels.
2 The stakeholders. The customer is the hotel chain that has
commissioned the new system. The main stakeholders are the
receptionists, managers, system administrators and guests.
The users of the system are potential reservers interested in making
reservations, front desk receptionists and managers. We cannot
assume they are in any way familiar with the technology; they
should be able to use the system with hardly any support.
3 Mandated constraints The system should be operational within
18 months.
217
The system will integrate with the external payment system.

The website will be accessible and usable from all types of
browsers.
4 Naming conventions and terminology. None at present.
5 Relevant facts and assumptions. None at present.
Functional requirements
6 The scope of the work. The new system will be developed for a chain
of hotels.
7 Business data model and data dictionary. Not yet considered.
8 The scope of the product. The new system will deal with all the
hotels owned. The system’s interface will deal with the following:
◦ front desk staff in each hotel handling: reservations by email,
phone, post, or in person; cancellations of reservations; check
in and check out of guests
◦ anyone using a web browser to view information and make
reservations
◦ managers adding or removing a room type or a room
◦ system administrators adding or removing a hotel
◦ the external payment system to handle payments.
As mentioned above the 9 Functional requirements. The system shall:

requirements here are rather
vague; they need to be seen in ◦ keep track of all hotels, room types and rooms
conjunction with other artefacts, ◦ handle all reservations, cancellations, and ‘no shows’
such as the use cases already
presented and further detailed in ◦ check in guests
the next section ◦ check out guests
◦ keep track of all current and past guests.
10 Look-and-feel requirements
LF1: The system shall make use of a small number of bright
colours, to conform to the brand image of the hotel chain.
LF2: The system shall have uncluttered forms.
11 Usability and humanity requirements
218
6 Volere template
U1: The system shall be easy to use for receptionists, reservers

using the internet, and managers.
12 Performance requirements
P1: The system shall be able to handle a range of large and small
hotels.
P2: The system shall respond to most user input within 1 second.
P3: The system shall respond to a complex user request within
10 seconds.
P4: The system shall have high availability.
13 Operational and environmental requirements
O1: The system shall operate across the hotel chain, with a set of
terminals in each hotel and a single central server.
14 Maintainability and support requirements
M1: The system shall be able to add support for several European
languages.
15 Security requirements
S1: Only managers and system administrators shall be able to
perform management/administration operations.
S2: Credit/debit card details shall be securely managed.
S3: Reservers shall be able only to browse and make or cancel
reservations.
S4: Only receptionists shall be able to check guests in or out.
S5: Information on which guests have been checked in or out shall
not be alterable.
16 Cultural requirements
C1: The system shall reflect the child-friendly policy of the hotel
chain.
17 Legal requirements
L1: The system shall operate in accordance with European and
local law.
219
7 Detailed software requirements

The next stage is to detail what the proposed software system must do, but
avoid describing how it should work. If design options are identified, they
should be recorded for later discussion in the development team, and then the
focus should return to the users’ needs.
Another risk at this stage is the introduction of new requirements by the
developer. As you study the problem domain, you may think of things that the
new software system could or should do. If you find yourself doing this, by
all means discuss your ideas with the users but do not invent requirements. In
the case of the hotel chain, for example, you would formulate a series of
questions for users such as the following.
. Does a reservation have to exist before someone can check in?
. What forms of payment are acceptable: cash, credit card and cheque?
. Is the information about a reservation to be kept after the payment? How
long for?
. What information about guests is to be kept independently of having a
current reservation?
The aim is to construct a software system that will meet the needs of its users.
Therefore you must identify ‘who does what’. To do this, you will search or
explore the problem description to determine the people involved and the
work that they do. During that exploration, you are likely to identify a variety
of people, some of whom may play a number of different roles. Your aim
should be to find out who will really do the work that will be helped by using
your software system. You should ask yourself who the actual users will be
and what tasks they must perform with the aid of your software system.
In the case study units (this unit and Units 8 and 12) we will deal with only a
small set of use cases – make reservation, cancel reservation, check in guest
and check out guest. In this increment, we will look at just the first iteration
through the use cases. This allows us to carry through the steps of
development within our constraints (of time and space), and at the same time
obtain quick feedback. Some issues, mainly related to non-functional
requirements, will not be addressed in this iteration, as discussed below.
The first task we need to undertake is to elaborate the details of each use case
assigned to iteration 1 in the form of a scenario expressed as a number of
steps. From the scenario, we can extract the functional software requirements.
These are atomic requirements that detail the functional requirements in the
Volere template above. We can then revisit the users’ non-functional
requirements in the Volere template, and refine them into software
requirements as well.
220
7.1 Elaborating the use cases

We will elaborate each of the use cases identified for the first increment of the
new system, using scenarios. For later reference, we will also give the names
and identifiers of the other use cases.
Note that the make reservation use case can have either a reserver or a
receptionist as its main actor. A reserver will trigger the use case when
starting a reservation online; a receptionist will trigger the use case when
requested to make a reservation by phone, by email or in person. Notice that
the detail of the use case varies slightly from the domain process model in
some respects. The customer has indicated that:
. if the hotel requested has inadequate space, then it is acceptable to offer
rooms in a nearby hotel in the chain
. if a guest’s details are already known, they should not be requested again.
We have also decided to tackle, in a first iteration, only the simplest case for a
reservation: one room only, and the room will be allocated at reservation time.
Table 1 A textual description of the make reservation use case
Identifier and name UC1 make reservation

Initiator Reserver or Receptionist
Precondition None (that is, there are no conditions to be
satisfied before carrying out this use case).
Postcondition A room of the desired type will have been
reserved for the guest for the requested period,
and the room will no longer be free for that
period.
Assumptions The expected initiator is a reserver or
receptionist, using a web browser to perform the
use case. The guest is not already known to the
hotel’s software system (see step 5). The
receptionist (if an actor) communicates details
to the client when making a booking.
1 The reserver/receptionist makes a reservation
request.
2 The reserver/receptionist selects the desired
hotel, dates and type of room.
3 The hotel system provides the availability and
price for the request; that is, one or more offers
are made.
4 The reserver/receptionist accepts the offer.
5 The hotel system requests identification and
contact details.
6 The reserver/receptionist provides identification
and contact details of the guest for the hotel
system’s records, as well as credit card details.
221
7 The hotel system creates a reservation and

gives it a number.
8 The hotel system allocates a room to the
reservation.
9 The hotel system reveals the reservation
number to the reserver/receptionist.
Extensions
3.a.1 No availability in this hotel. The hotel system
offers alternatives at a different hotel or hotels
within a limited radius.
3.b.1 No availability in this hotel or in any other
hotels within a limited radius. The hotel system
informs the reserver and terminates the use
case.
4.a.1 Offer not accepted. The hotel system terminates
the use case.
6.a.1 Guest already on record. The guest is identified
and (if needed) their record is updated and the
scenario continues at step 7.
Exercise 2
Write a description of the cancel reservation use case.
Solution
Table 2 A textual description of the cancel reservation use case
Identifier and name UC2 cancel reservation

Initiator Receptionist or Reserver
Goal A guest’s reservation of a room at a hotel is cancelled.
Precondition There is an active reservation (in the future and not
cancelled) for a room at a hotel for a guest with a
reservation number.
Postcondition The reservation will have been cancelled, the allocated
room will be freed, and a charge to the credit card will
have been made if the cancellation was initiated within
24 hours of the start of the reservation.
Assumptions The expected initiator is a receptionist or reserver.
1 The receptionist/reserver requests the cancellation of a reservation.
2 The receptionist/reserver enters the reservation number, or the dates,
name and address.
3 The hotel system retrieves the corresponding reservation.
4 The hotel system frees the allocated room.
5 The receptionist/reserver confirms the cancellation.
6 The reservation is cancelled, and the hotel system informs the
receptionist/reserver of the cancellation.
222
Table 2 continued
Extensions
6.a.1 If the cancellation was initiated within 24 hours of the beginning of the
reservation, the hotel system charges the credit card whose details are kept in the
reservation.
Now we look at the check in guest use case.
Table 3 A textual description of the check in guest use case
Identifier and name UC3 check in guest

Goal A guest takes up a reservation and occupies a room
at the desired hotel.
Precondition There is a room (of the desired type) reserved for
the correct reservation number, for today, and the
guest can pay for the room.
Postcondition The guest will have been allocated to a room for the
period identified in the reservation, and a bill will
have been opened for the duration of the stay.
Assumptions The guest is already known to the hotel system.
The hotel is confident that the guest can pay. For
example, the guest has a valid credit card.
1 The guest provides a reservation number or the dates and name and
address to the receptionist.
2 The receptionist enters the reservation number or the dates and name
and address to find the reservation.
3 The hotel system retrieves the details of the requested reservation.
4 The receptionist confirms the details of the room type and duration
of the stay with the guest.
5 The hotel system allocates the reserved room to the guest.
6 The hotel system opens a bill for the guest. (It could be that there is
a separate billing package, which must be notified on check in.)
7 The receptionist issues a key to the guest.
Extensions
None
Finally, we look at the check out guest use case.
Table 4 A textual description of the check out guest use case
Identifier and name UC4 check out guest

Goal A guest pays a bill and frees the hotel room.
Precondition The guest currently is allocated to a hotel room.
223
Postcondition The guest will have paid the bill for the room, and
the room will have been freed.
Assumptions The guest had provided details of a valid credit
card, but may want to pay by different means.
1 The guest requests a bill for a room.
2 The receptionist enters the room number to find the bill.
3 The hotel system provides the details of the bill so far.
4 The receptionist requests details from the guest about any further expenses.
5 The guest provides details.
6 The receptionist calculates the final bill.
7 The receptionist processes payment with the credit card details held for the
guest.
8 The hotel system closes the bill and frees the room.
Extensions
7.a.1 Guest wants to pay by different means. Payment is provided.
The following are the identifiers and names of the other use cases:
UC5 add hotel
UC6 remove hotel
UC7 add room type
UC8 remove room type
UC9 add room
UC10 remove room.
7.2 Software requirements

Our use cases show how actors will interact with the system. We will now
draw up the software requirements showing what the system must do to
support these interactions. Each software requirement needs to be as
unambiguous as possible. Notice that we say what the system must do rather
than how it will do it. Each requirement we arrive at will have a fit criterion
attached; this adds precision and enables acceptance tests to be drawn up.
You will see that some of our functional requirements add relatively little
information beyond that included in the corresponding scenario step, whereas
in other cases there is more clarification. In a real system development, it
would be sensible to apply some discretion as to whether all steps require
elaboration into software requirements; you will see below that some steps are
rather trivial.
Functional requirements: UC1 make reservation

We will begin by extracting initial software functional requirements (SFRs)
from each of the steps in use case UC1, make reservation. Whenever there is
an extension for a step, we write a separate corresponding functional
224
requirement. Some of these requirements are still vague at this stage. Later on,
design and user interface decisions will require adjustment to some of the fit
criteria.
SFR1: UC1, Step 1 There may be decisions later that
require different interfaces for
Description: The system shall allow a reserver/receptionist to initiate a different users. Some steps in the
reservation. use case scenario will be
Fit criterion: The Reservation page shall be displayed. decomposed into several system
requirements, as is the case with
SFR2: UC1, Step 2 Step 2 (SFR2–SFR4).
Description: The system shall obtain a hotel name from the user.
Fit criterion: A valid hotel name shall be accepted. User interface decisions may
require changes to these fit
SFR3: UC1, Step 2 criteria, for example if dates are
picked up from a calendar. These
Description: The system shall accept a range of dates from the user. considerations apply to other
Fit criterion: A valid range of dates shall be accepted. functional requirements.
SFR4: UC1, Step 2

SFR5: UC1, Step 3
Description: The system shall check the availability of a given room type
in a given hotel for a given range of dates. One or more offers shall be
made and their price shall be stated.
Fit criterion: Offers consistent with the availability of a room shall be
made, and the correct price for the room shall be supplied.
SFR5.a.1: UC1, Step 3.a.1
Description: No availability in this hotel. The system shall check the
availability of alternatives at a different hotel or hotels within a limited
radius. One or more offers shall be made, and their price shall be stated.
made and the correct price for the room shall be supplied.
SFR5.a.2: UC1, Step 3.b.1
Description: No availability in this hotel or in any other hotels within a
limited radius. The reserver shall be informed and the use case exited.
Fit criterion: No offer shall be made and the reserver shall be informed.
SFR6: UC1, Step 4
Description: The system shall accept confirmation from the user.
Fit criterion: A response indicating confirmation shall be accepted.
SFR6.a: UC1, Step 4.a.1
Description: Offer not accepted. The system shall accept non-confirmation
from the user and exit the use case.
Fit criterion: A No response shall be accepted.
225
SFR7: UC1, Step 5

Description: The system shall allow identification and contact details to be
entered.
Fit criterion: The Guest details page shall be displayed.
SFR8: UC1, Step 6
Description: The system shall accept the identification of the guest.
Fit criterion: Identification details shall be accepted.
SFR9: UC1, Step 6
Description: The system shall accept contact details of the guest.
Fit criterion: The street number, street name, town and postcode shall be
accepted.
SFR9.a: UC1, Step 6.a.1
Description: Guest already on record. The guest is identified and (if
needed) their record updated, and the system shall proceed to Step 7.
Fit criterion: Guest record shall be retrieved and if needed updated.
SFR10: UC1, Step 6
Description: The system shall accept valid credit card details.
Fit criterion: A valid credit/debit card number shall be accepted.
SFR11: UC1, Step 7
Description: The system shall create a reservation in a given hotel for the
given dates.
Fit criterion: A reservation shall be created for the guest between the given
dates.
SFR12: UC1, Step 7
Description: The system shall assign a unique number for a reservation.
Fit criterion: A unique number shall be assigned to the reservation.
SFR13: UC1, Step 8
Description: The system shall allocate a room for a reservation.
Fit criterion: A room shall be assigned to the reservation.
SFR14: UC1, Step 9
Description: The user shall be issued with the reservation number.
Fit criterion: The correct reservation number shall be issued.
While you can see that some of these requirements add very little to the
corresponding scenario steps, there are some important exceptions. For
example, in SFR3, value is added by validation of the date. This may require
an existing functional requirement to be strengthened.
226
Functional requirements: use cases 2, 3 and 4

Most of the steps in use cases 2, 3 and 4 are relatively straightforward. This is
partly because a lot of the relevant information has been collected in use
case 1 and so can be taken as a given. We have therefore decided not to
explicitly state the software requirements for use cases 2, 3 and 4 as it would
not add any benefit to what has been done above. We also feel that a designer
who has worked with the more explicit software requirements for use case 1
will be in a position to interpret other use cases based on that experience. We
would take a different view if we were developing a control system for some
potentially dangerous machinery. This is the sort of pragmatic decision that
can be made on the basis of experience. In a real development, it is important
to use appropriate techniques (and tools) where they add value, and not
simply because they can be used.
SAQ 4
(a) In the Volere template in Section 6, we recorded some non-functional

requirements. What further work is needed in order to produce the
software requirements?
(b) What else needs to be done in terms of non-functional requirements?
Answer
(a) We need to remove any ambiguities and add clear fit criteria.

Additionally, we need to identify which functional requirements they
constrain; in some instances, they will apply to whole use cases.
Often we will need to consult the system stakeholders for further
details.
(b) We should look at each use case and see whether we identify other
non-functional requirements based on the use case steps. We can do
this by looking at the functional software requirements in turn (each
corresponding to a use case step), and considering whether there are
any non-functional requirements that apply to them but have been
omitted. We should not assume that the stakeholders will supply a
complete set of requirements, so cross-checks such as this are
essential.
In Exercise 3, we consider the non-functional software requirements. Your

solution will probably vary quite considerably from that given below, owing
to the open nature of the exercise. The solution is therefore indicative but it
will be used later on in the case study.
Exercise 3 Non-functional software requirements

(a) Take the non-functional requirements recorded in the Volere template in
Section 6 and state appropriate fit criteria, together with the use cases and,
where appropriate, specific functional requirements to which they apply.
227
Assume that the stakeholders have been consulted and have supplied
appropriate information.
(b) Consider each of the functional software requirements given above for
UC1, and consider whether any of the non-functional requirements can be
refined.
Solution
(a) The following non-functional requirements are suggested.
Look-and-feel requirements
LF1: The system shall make use of a small number of bright colours, to
conform to the brand image of the hotel chain.
On consultation with the stakeholders we arrive at the following.
Fit criterion: The system shall be designed with black-and-white forms
with a sky-blue title bar and a yellow motif in the bottom right-hand
corner copied from the company logo.
Applies: All use cases.
LF2: The system shall have uncluttered forms.
Fit criterion: Each form shall be limited to a maximum of 8 textual
input boxes; each box shall have an accompanying caption of up to
20 characters. Any preamble text shall be limited to 20 words.
Usability and humanity requirements
U1a: The system shall be easy for receptionists to use.
Fit criterion: Receptionists shall be able to learn how to use the
system in 1 hour. All current receptionists shall be able to complete a
reservation, check in or check out form in 2 minutes, assuming the
guest has no special requirements.
Applies: UC1, UC2, UC3, UC4.
U1b: The system shall be easy for reservers to use.
Fit criterion: No training shall be required for use of the system’s
online facilities. At least 90 per cent of reservers shall be able to make
a reservation in 5 minutes.
Applies: UC1, UC2.
U1c: The system shall be easy for managers and system administrators
to use.
Fit criterion: Managers and system administrators shall be able to
learn how to use the system in 2 hours. All of the current managers
shall be able to perform any of the management operations in 1 minute.
Applies: UC5, UC6, UC7, UC8, UC9, UC10.
Performance requirements
P1: The system shall be able to handle a range of large and small
hotels.
228
Fit criterion: The system shall be able to handle up to 100 hotels,

varying in size from 10 rooms to 1000 rooms.
P2: The system shall respond to most user inputs within 1 second.
Fit criterion: The system shall be able to respond to more than
50 per cent of user inputs within 1 second.
Applies: All use cases except UC1.
The exceptions in the above fit criterion relate to user requests where
we expect the system to have to do a greater amount of processing than
we can guarantee in 1 second.
10 seconds.
Fit criterion: The system in use shall be able to respond to all
complex user requests within 10 seconds.
Applies: UC1 (since the system needs to search for availability).
P4: The system shall have high availability. This percentage may be worse
than intended. Availability of
Fit criterion: The system shall be available 99 per cent of the time
99 per cent of the total number
for 24 hours a day, 7 days a week, with any period of unavailability of hours in a year means
lasting 1 hour at most. 87 hours when it is unavailable.
Applies: All use cases. This may be problematic mainly if
unavailability occurs at peak time.
Operational and environmental requirements
O1: The system shall operate across the hotel chain, with a set of
terminals in each hotel and a single central server.
Fit criterion: Self-contained.
Maintainability and support requirements
M1: The system shall be able to add support for several European
languages.
Fit criterion: Another two European languages shall be supported in
addition to English.
Security requirements
S1: Only managers and system administrators shall be able to perform
management/administration operations.
Fit criterion: No more than one breach per year shall occur.
Applies: UC5, UC6, UC7, UC8, UC9, UC10.
S2: Credit/debit card details shall be securely managed.
Fit criterion: A fraud shall occur in no more than 1 in a million
card transactions.
Applies: UC1, UC2, UC3, UC4 specifically, but also to any part of
system where credit card details are accessible.
229
S3: Reservers shall be able only to browse and make or cancel

reservations.
Applies: UC1, UC2.
S4: Only receptionists shall be able to check guests in or out.
Applies: UC3, UC4, but also to any part of system where relevant
details are accessible.
S5: Information on which guests have been checked in and out should
not be alterable.
Applies: UC3, UC4, but also to any part of system where relevant
details are accessible.
Cultural requirements
C1: The system shall reflect the child-friendly policy of the hotel chain.
Fit criterion: The system shall distinguish between child and adult
This and other non-functional guests in order that children can be treated appropriately.
requirements lead to functional
Applies: UC1, UC2, UC3, UC4.
requirements (e.g. the
reservation system should offer Legal requirements
the possibility of requesting an
extra cot for a room). This L1: The system shall operate in accordance with European and local
would require further discussion law.
with the customer and revisiting Fit criterion: The system shall pass an audit by the hotel chain’s
the functional requirements; we
will not be considering these legal department.
extra functional requirements at Applies: All use cases.
this stage.
(b) Looking at the individual functional requirements for the use cases, it
seems clear that only functional software requirements SFR5, SFR5.a.1,
SFR7, SFR9, SFR10, SFR12 and SFR13 can be considered as complex
user requests. So it would seem reasonable to refine the performance
requirements in two ways. First, we will allow specific times for each of
these steps and, second, we will allow 1 second for each of the other
steps.
Now the relevant performance requirements become as follows.
P2: The system shall respond to most user input within 1 second.
50 per cent of user inputs within 1 second.
Applies: All use cases, except UC1 – SFR5, SFR5.a.1, SFR7, SFR9,
SFR10, SFR12, SFR13.
10 seconds.
50 per cent of user inputs within 10 seconds.
Applies: UC1 – SFR5, SFR5.a.1, SFR7, SFR9, SFR10, SFR12, SFR13.
230
A similar process of refinement of these requirements would be

appropriate for the other use cases, so the information about where the
requirements apply will continue to become more specific.
You may have found other specific details that require the given non-
functional software requirements to be refined in this way.
Alternatively, you may have found some completely new non-functional
requirements.
Checking for completeness

Our software requirements have now become quite detailed, and at this point
it is appropriate to check them for completeness against the user requirements
and in particular the contents of the Volere template.
For example, comparing use case UC1 against the purpose of the product in
the template, you can see that we have not addressed the frequent-guest
programme. We need to either elaborate on our existing functional
requirements or add further ones. We use the former approach here. We need
to amend the way prices are calculated, and associate repeat-custom
information with the guest. On consultation with the stakeholders, we also
learn that it would be useful for reservations from repeat guests to be
indicated clearly in the reservation code. In fact, the stakeholders thought we
knew this and were expecting it in the system. We therefore amend a further
software requirement, and note that we should add information about the
reservation code to the user requirements in the original Volere template.
The updated software requirements are as follows.
SFR5: UC1, Step 3
made and their prices shall be stated. The prices shall indicate discount
offered for the frequent-guest programme.
made, and correct price for the room shall be supplied, taking account of
the frequent-guest programme.
SFR5.a.1: UC1, Step 3.a.1
Description: No availability in this hotel. The system shall check the
availability of alternatives at a different hotel or hotels within a limited
radius. One or more offers shall be made, and their price shall be stated,
taking account of the frequent-guest programme.
made, and the correct price for the room shall be supplied, taking account
of the frequent-guest programme.
SFR12: UC1, Step 7
Description: The system shall assign a unique number for a reservation. If
the guest has stayed in one of the hotels before, the reservation code shall
begin with an R.
231
Fit criterion: A unique number shall be assigned to the reservation. This

number shall be preceded by an R if the guest has stayed in one of the
chain’s hotels before.
SAQ 5
(a) Is it also necessary to check the non-functional software requirements

against the original user requirements?
(b) Is it possible that elaborating the functional requirements as above
might require us to revise our non-functional requirements? What if
we were to add new functional requirements?
(c) Can elaboration of our software requirements lead to inconsistencies?
Give an example.
Answer
(a) Yes. For example, as well as the possibility of simply missing

explicit non-functional requirements in the template, there might well
be non-functional requirements implied under product constraints.
(b) Yes, in both cases. There may well be constraints on the added
functionality that are not covered by the existing non-functional
requirements.
(c) Yes. For example, if we add sufficient extra functionality, the time
taken by the system to carry out the necessary work might mean that
we are unable to satisfy the time constraint in usability
requirement U1.
7.3 Initial architecture

The initial problem statement describes how the new system will extend from
a single hotel to deal with all the hotels owned. We could have taken into
account the existing hotel-based system instead of discarding it entirely for a
new system for the chain of hotels. This is a discussion that should have been
held with the customer to see the risks and effort of each option.
We assume a completely new system is chosen for the chain of hotels. Even
before we discuss in detail different types of architectures (in Block3 Unit 9)
we can already identify several parts to this system.
We identified above different types of roles of people interacting with the
system, and a complex interface needs to be customised for each role. We can
envision that there will be some part of the system that will deal with these
aspects, and we will call it the presentation. Presentation is independent of
In the Volere template we had as how the functionality of the system will be carried out.
functional requirements: ‘keep
track of all hotels, room types Whatever system we end up with, it will need to keep information about its
and rooms’ and ‘keep track of all customers and all the hotels in the chain in a persistent way – that is, the
current and past guests’. information will last even across events such as system crashes and updates.
This is part of the system’s infrastructure that includes the databases. The data
will change regularly but its structure will be more stable.
232
Finally, there will be the regular functioning of the system dealing with
reservations, bookings and cancellations, which was the main focus of the
case study in this unit. The part of the system dealing with this functionality
will be called here the application domain. This is also the part of the system
that may change more often, for example as new business rules are
implemented.
These three parts of the system can be organised in a three-layer architecture
that you have already encountered in Unit 1. Adjacent layers will
communicate with each other but they can be developed independently. This
architecture will evolve as architecture decisions are taken to satisfy the
system’s requirements. Later in the module we will discuss, in particular, how
the satisfaction of non-functional requirements will influence the architecture.
presentation
application
domain
infrastructure
(OS, databases, etc)
Figure 9 A layered architecture
In this module we will be mainly focusing on the application domain layer.

In this section we detailed the software requirements for the software system
to be developed. We started by describing use cases in detail and extracted the
functional software requirements from the scenarios. We then derived the
users’ non-functional requirements in the Volere template with fit criteria and
checked for completeness. An initial architecture was outlined.
233
8 Testing
You saw in Unit 2 that requirements must be measurable and testable. In this
unit we developed two types of artefacts that will help in testing the system to
be developed: scenarios for use cases and fit criteria for requirements. In this
section we will look at some examples of how to derive tests from these
artefacts.
8.1 Testing with scenarios

A scenario describes a particular instance of a use case. To generate test cases
from use cases, the different paths through scenarios need to be covered
(Alexander, 2004). One test case is generated from the main success scenario.
Every extension should be included in at least one test case which starts by
following the main success scenario and then deviates through the extension.
Exercise 4
Consider UC1 make reservation and suggest a set of test cases for this use
case.
Solution
You should suggest the following test cases:
1 one for the main success scenario

2 one starting with the main success scenario but for when there is no
availability in the chosen hotel
3 one starting with the main success scenario but for when there is no
availability either in the chosen hotel or in any other hotel of the chain
4 one starting with the main success scenario but for when the user does not
accept the offer from the hotel
5 one starting with the main success scenario but for when the guest is
already known to the hotel.
Note that scenario-based testing covers only some aspects of testing; it does
not address, for example, the testing of non-functional requirements
234
8 Testing
8.2 Testing with fit criteria

We look now at some of the fit criteria in Section 7 and how easy it is to
derive tests from them. Some fit criteria may be more easily testable than
others and some will need more detail to be added
The following fit criteria will be easily testable, for example if the system
only allows the user to enter a type of room from an allowed list of types.
SFR4: UC1, Step 2
Other fit criteria will need a bit more work in order to generate the right tests.
For example
SFR5: UC1, Step 3
made, and their price shall be stated. The price shall take account of the
frequent-guest programme.
made, and the correct price for the room shall be supplied, taking account
of the frequent-guest programme.
This requires a bit more work to write a test case. A test case for a
requirement consists of the data to be used, the fixture, and an oracle, which
is the criteria that helps define whether the test is passed. Fit criteria should be
written in such a way that they are the oracle. A fixture is the current state and
the data to be used in a test.
For the example above, the fixture would consist of a specific hotel, a room
type, and a range of dates, and naturally a given state of the system. The word
‘consistent’ in the fit criteria is vague and we could probably express it in a
more formal way, easier to test. For example, ‘All the offers will consist of a
room and a price; the room is in the required hotel, is of the required types,
and is available for that range of dates, and the price supplied is the correct
price for that room for those dates.’ It is also not clear what ‘taking account
of the frequent-guest programme’ means and this would require some more
investigation.
Exercise 5
Consider the following requirement:
SFR12: UC1, Step 7
Description: The system shall assign a unique number for a reservation. If
the guest has stayed in one of the hotels before, the reservation code shall
begin with an R.
235
Fit criterion: A unique number shall be assigned to the reservation. This

number shall be preceded by an R if the guest has stayed in one of the
chain’s hotels before.
Discuss in more detail a test case for this requirement.
Solution
The fixture would consist of a specific hotel, a room type, a range of dates,
and a guest who has stayed in the hotel before.
The oracle is reasonably expressed by the fit criteria and would require a
check that the reservation has an identifier, which is unique and starts with an
R.
8.3 Testing with user stories

Testing early is at the heart of agile development, which promotes, for
example, that acceptance tests should be written for each user story before any
code is written. Ideally, these tests should be written by customers or at least
in a collaboration between customers and developers. Tests will help to
consider, from early on, details about the story that would otherwise be
forgotten, such as special cases of missing data.
In the example of the user story ‘As a guest I can pay in advance with a
credit card’ the following tests were suggested (Cohn, 2004):
. test with Visa, MasterCard, American Express, Diner’s Club
. test with good, bad, and missing card ID numbers
. test with expired cards
. test with a range of money values.
These tests and others are written as annotations to user stories and result
from the conversations with customers and developers that are triggered by
the user story.
236
9 Summary
Summary 9
This is a practical unit, in which you had the chance to apply the concepts
learnt so far about software development.
We discussed the activities undertaken in the two initial phases of the UP, in
particular those carried out in the development followed in the case study
units.
You saw how to undertake domain analysis to understand a real-world
situation, identifying the main business processes and representing them. You
read how to decide on the scope of a software system to be developed to
address an initial set of user requirements. The unit then described how to
document the initial set of requirements using the Volere template, and how to
elicit detailed software functional and non-functional requirements and their fit
criteria. An initial architecture was outlined. You also saw how to start
deriving tests from both scenarios and fit criteria.
As you apply the techniques learnt in this module through this case study you
will also see that you do not need to create models in detail for every aspect
of the system; some judgement needs to be applied on how useful and
justified these activities are.
After studying this unit you should be able to:
. explain the main characteristics of the Unified Process
. analyse the description of a domain situation and identify business rules
and business processes
. represent processes with activity diagrams
. define the scope for a software system, and identify and describe its main
use cases
. outline a requirements document based on the Volere template
. elicit software functional requirements from use cases and scenarios, and
define their fit criteria
. elaborate on non-functional requirements and their fit criteria
. understand the role of user stories and how they are used in an agile
approach
. derive tests from requirements.
237
References
Alexander, I. (2004) ‘Use cases, test cases’ in Alexander, I. and Maiden, N.
(eds) Scenarios, Stories, Use Cases through the Systems Development Life-
Cycle, [Online] Chichester, John Wiley. Available at http://www.open.ac.uk/
ProQuest_Safari_Tech_Books_Online (Accessed 9 January 2013).
Ambler, S. W. (2012) The Agile Unified Process (AUP) [Online] Ambysoft,
Scott Ambler & Associates. Available at http://www.ambysoft.com/
unifiedprocess/agileUP.html (Accessed 17 November 2013).
Beck, K. (2004) Extreme Programming Explained: Embrace Change [Online],
Upper Saddle River, NJ, Addison Wesley. Available at http://www.open.ac.uk/
ProQuest_Safari_Tech_Books_Online (Accessed 2 December 2013).
Cohn, M. (2004) User Stories Applied: For Agile Software Development,
[Online] Boston, MA, Addison Wesley. Available at http://libezproxy.open.ac.
uk/login?url=http://proquestcombo.safaribooksonline.com.libezproxy.open.ac.
uk/0321205685?uicode=open (Accessed 4 December 2013).
Jacobson, I., Booch, G. and Rumbaugh, J. (1999) The Unified Software
Development Process, Upper Saddle River, NJ, Addison Wesley.
Larman, C. (2005) Applying UML and Patterns: An Introduction to Object-
Oriented Analysis and Design and iterative Development, [Online] Boston,
Pearson. Available at http://proquestcombo.safaribooksonline.com.libezproxy.
open.ac.uk/book/software-engineering-and-development/agile-development/
0131111558 (Accessed 2 December 2013).
238
Acknowledgements
Acknowledgements
Grateful acknowledgement is made to the following sources.
Every effort has been made to contact copyright holders. If any have been
inadvertently overlooked, the publishers will be pleased to make the necessary
arrangements at the first opportunity.
Unit 1
Text
Subsection 3.2. Manifesto for agile software development: © Ward
Cunningham, et al (2001) http://agilemanifesto.org.
Figures
Figure 6. Larman, C. (2004) Applying UML and Patterns, 3rd edn, Prentice
Hall Inc.
Unit 2
Text
Subsection 6.1, Volere template. We acknowledge that this document uses
material from the Volere Requirements Template. Copyright © Atlantic
Systems Guild Limited.
Figures
Figure 1. Copyright slug: © 2001 Scott Adams. Dist. by Universal Uclick.
Reproduced by permission via Knight Features.
Figure 3. Robertson, S. and Robertson, J. (2012) Mastering the Requirements
Process, Copyright © Atlantic Systems Guild Limited.
Figure 4. © Scott W. Ambler.
Unit 4
Text
Section 6, Volere template. We acknowledge that this document uses material
from the Volere Requirements Template. Copyright © Atlantic Systems Guild
Limited.
239
Index
Ariane 5 rocket 8 business rules 205

Index artefacts 28
in the development process 56–
functional requirements 197–8,
218, 224–7, 230, 231–2
62 initial architecture 232–3
Note: index entries in bold type
associations 146 initial problem statement 197,
indicate glossary entries.
assumptions 34, 49, 116, 144 203–4
description of use cases 154, non-functional requirements 198,
.Net 24 155, 164 218–19, 227–31, 232
attacks 101, 102, 103–5 scope of the new system 197,
abstraction 18, 21 audit 102, 103 212–16
acceptance testing 121, 158, 160, authentication 106 testing 198, 234–6
236 authorisation 106 use cases 212–15, 221–4
access 102, 103 availability 11–12, 97, 105 Volere template 197, 217–19
activities 132, 132–4 changeover, problems of 13
in the development process 56– behaviour models 52, 53, 56, 57, circular dependency 18
62 58, 59–60 class modelling 176, 188
linking to user interfaces 186–90 block bookings 203–4 clients 17, 72
activity diagrams 76, 129, 132, building architecture 22–3, 78 cohesion 19, 19–20, 21
132–44 business data model 117 combined nodes 142–3
case study 206–11 business domain 129, 130–42 commitment 200
and designing user interfaces business entities 25, 26 common behaviour 168–70, 175
186–90 business events 83 competitors 103
and workflows 136–44 business functional requirements complaints 16, 112–13
actors 145, 146, 150–1, 156, 159 86, 87, 89 completeness of requirements 74
generalised and specialised 166– business modelling 54, 129 checking for 231–2
7 see also domain modelling complexity
affordability 11–12 business objects 147 complex use case diagrams 174,
agile development 74, 184, 197 business processes 57, 58, 59, 83, 178–83
development processes 34–6, 38, 129, 130, 132, 132–44 software 10, 15, 20, 29
39, 40 activity diagrams and components 24, 25, 26
documenting requirements 77–8, workflows 136–44 conceptual model (structural
80, 121 actors and roles 150, 151 domain model) 57, 58, 59
planning 200–1 case study 205–11 conditional behaviour 170
use cases and 160–5 representing 132–6 configuration management 38, 41
agile documentation 42, 44 services and 25, 26 conflicts 119, 120
agile modelling 49–50, 160, 176, business rules 57, 58, 59, 129, conformance testing 107, 107–14,
177 130 235–6
agile UP 55, 202 case study 205 consistency 74
alternative behaviour 170–1, 175 representing 130–2 constraints 121
ambiguity 74, 80, 85, 88 business rules 57, 58, 59, 129,
analysis 30–1, 32, 46, 54, 175, 199 cards, user story 121 130–2, 205
activities and artefacts 56, 58, case study 193–238 mandated 116, 217–18
59–60 detailed software requirements project constraints 116, 217–18
analysis model 58, 59–60 197–8, 220–33 construction phase 54
annotations see notes checking for completeness context dependencies 17, 21
application domain 23, 233 231–2 contract 17, 74, 100
architecture 22 elaboration of use cases 221– CORBA 24
building architecture 22–3, 78 4 core requirements 82
software architecture see domain modelling 197, 205–11 costs 118
software architecture business processes 205–11 coupling 18, 18–20, 21
241
coverage 158 disciplines (in UP) 54 attainability 114
‘crackers’ 103 disclosure 104, 106 case study 225–6, 227–32, 235–
criticality 158 divide and rule strategy 15 6
cultural requirements 94, 99, documentation testing with 107–14, 235–6
110, 117, 219, 230 business rules 130–2 fixture 235–6
customer 30, 34 requirements see requirements flexibility 11–12
customer satisfaction 112–13, 119, documentation fork 133, 134
120 traceability 41–4 formality 37–9
domain 9, 76 fraudsters 103
daily scrum 36, 38 problem domain 16, 132–3, functional decomposition 175–6
data dictionary 117 135–6 functional requirements 71, 82–
Data Protection Act 1998 100 domain modelling 30, 30–1, 54, 92, 93
databases 23, 232–3 129, 145, 199 case study 197–8, 218, 224–7,
date handling 18, 19 activities and artefacts 56–9 230
decision nodes 134, 135, 140, 141 business domain 129, 130–42 checking for completeness
combined with merge nodes case study 197, 205–11 231–2
142–3 DSDM (dynamic systems describing 85–91
decomposition 15, 15–21 development method) 84 documentation 116–17, 118–19
architecture 23–6 dynamic models see behaviour elicitation, analysis and
functional 175–6 models negotiation 82–5
deliverables 30 fit criteria 107, 111–12
delivery 31 easy-to-learn products 96
denial of use or service 104 easy-to-use products 96 generalised actors 166–7
dependencies ecommerce 101, 105–6, 110 glossary 57, 58, 59, 116
context 17, 21 elaborated use cases 58, 59, 171–2 goals 129
coupling and cohesion 18–20, case study 221–4 use cases 153–4, 155, 164
21 elaboration phase 54, 77, 201–2, Governance for Agile Delivery
requirements 74–5 212 (National Audit Office) 36
dependency arrows 168–9 encapsulation 17 guards 135
deployment 54, 56, 61 engineering 5 guillemets 168
deployment view 55 software development as an
design 30, 30–1, 32, 33, 46, 54, engineering activity 28–9 health and safety legislation 100
72, 74, 175, 199 Enterprise Java Beans (EJB) 24 heroic programming 15
activities and artefacts 56, 58, entities 25, 26 high cohesion 19–20, 21
60 errors 9–10 hospital systems 9, 73, 79, 105
test-driven 61 European Ariane 5 rocket 8 hotel systems 19–20, 159
user-centred 146–7 expected lifetime 38–9 actors 145–6, 149, 150–1, 166–7
detailed software requirements see exploration 200 cancel reservation
software requirements extension 167–8, 170–5, 178–9 business process 208–9
development processes 30, 30–6, extension points 171, 172 use case 213–14, 222–3
199 external networks 101, 102 case study see case study
activities and artefacts in 56–62 external systems, interaction with check in guest
agile development 34–6 150, 151 business process 209–10
choosing an appropriate process extreme programming (XP) 35–6, use case 146, 149, 151–2,
36–41 38, 78, 200–1 164–5, 189–90, 213–14, 223
formality 37–9 check out guest
overall process model 32–4 feedback 33 business process 210–11
risk management 39–41 film rental business 180–3 use case 146, 149, 163–4,
technical activities 30–2, 46 financial services 37–8, 38–9 213–14, 223–4
development team 176, 177 fit criteria 94, 107, 119, 120, 157
242
Index
complex use case diagram 178– domain see domain modelling

9 layered architecture 23, 233 importance 48–52
describing use cases 151–5 legacy systems 12-13, 13, 14–15 Unified Process see Unified
log on use case 173–4 legal requirements 94, 100, 110– Process
make reservation 11, 117, 219, 230 modelling language 50, 50–2, 61–
business process 206–7 lending library 130 2
use case 146, 149, 153, 166– activity diagrams 136–9 models 48, 48–9, 51
7, 171–2, 212–14, 221–2, combined activity diagram modification 104
224–6, 234 142–4 modularisation 16–17, 29
packages 174 alternative behaviour 170 modules 15, 20
relationships between use cases book issue 130, 136–8 and interfaces 16–18, 21
171–2, 173–4 book return 130, 138–9 MoSCoW scheme 84
requirements 81, 83, 85, 90 non-functional requirements
detailed software 147–8 naming conventions 116
requirements 157 shared behaviour 168–9 National Audit Office 36
system boundary 149 use cases and agile negative scenarios 158
use cases and agile development 161–3 New Jersey Department of Motor
development 163–5 user interface 187–8 Vehicles 75
user interface 189–90 life cycle (process model) 30, 32– new problems 118
4, 45, 132 non-ambiguity 74
ideas for solutions 118 light-weight approaches 35–6 non-functional requirements
immunity 102, 103 logical view 55 (NFRs) 71, 82, 87, 93–106, 147–
implementation 31, 32, 33, 46, London ambulance service 13–14 8
54, 60, 72, 74 look-and-feel requirements 94, case study 198, 218–19, 227–31
activities and artefacts 56, 60 94–5, 109, 117, 218, 228 checking for completeness
implementation view 55 low coupling 18–19, 20, 21 232
inception phase 54, 77, 200–1, documentation 117, 118–19
212 main success scenario 153–4, 155, fit criteria 107–8, 112
inclusion 167–70, 173–5, 179 156, 164–5, 221–4 see also under individual types
infrastructure 23, 232–3 maintainability 12, 12–15 of NFR
initial architecture 232–3 maintainability and support notebook, project 43, 44
initial problem statement 56–7, 58, requirements 94, 98–9, 110, 117, notes 121, 131
59, 197, 203–4 219, 229 activity diagrams 133, 134
integration 31, 33, 34 maintenance 31, 32, 34, 46 use case diagrams 162, 163,
integrity 102, 103, 106 process models and 45 182, 183
interaction diagrams 58, 60 malleability 10, 29
interfaces 17 mandated constraints 116, 217–18 Object Constraint Language
modules and 17–18, 21 Manifesto for Agile Software (OCL) 131–2
user interfaces 11, 184, 186–90 Development 35, 42 Object Management Group
internet 101 merge nodes 135, 140, 141 (OMG) 51
intruders 103, 104 combined with decision nodes object-oriented approach 5, 175
iteration 32–3 142–3 off-the-shelf solutions 118
iteration planning game 201 migration to the new product 13, open issues 118
iterative and incremental 118 operating system (OS) 23, 232–3
development 33, 34, 35, 45, 79, millennium bug 19 operational and environmental
176 modelling 48, 48–62, 188 requirements 94, 98, 110, 117,
iterative requirements gathering 84 activities and artefacts in the 219, 229
development process 56–62 oracle 235–6
Java 10 agile 49–50, 160, 176, 177
join 133, 134 business 54, 129 packages 174
243
pair programming 38 process 75–7, 79
partitioning 38 quality management 31, 32, 46 requirements-recording tool 90,
architecture 23, 26 quality requirements see non- 113–14
development teams 38, 45 functional requirements (NFRs) requirements shell/snowcard 118–
patient-monitoring system 105 19, 120
performance requirements 94, Rational Unified Process (RUP) 53 requirements specification 11,
97, 98, 117 regulatory framework 37, 100 41–2, 76
case study 219, 228–9, 230–1 relevant facts 116 requirements validation 74, 76
fit criteria 110, 112–13 reliability 11–12, 97, 105 reservations see cancel reservation;
plan-driven development 36, 41– replacement, problems of 13 make reservation
2, 75 repudiation 104, 106 resources 129
planning 200–1 requirements 28, 30, 54, 71, 72– reuse
use cases as a planning aid 157– 81, 184, 199 architecture 23–6
8, 159 activities and artefacts 56, 58, of use cases 169, 175
Planning game 200 59 risk 118, 157
postconditions 152, 154, 155, 164 agile perspective 77–8 risk management 39, 39–41
preconditions 152, 154, 155, 163, and architecture 78 road maps 48–9
164 case study 197–8, 220–33 roles 136, 145, 150, 151
presentation 23, 232–3 completeness 74, 231–2 swimlanes 136–7, 139
PRINCE (PRojects IN Controlled dependencies 74–5 see also actors
Environments) standard 37 development process 30–1, 32,
priority 119, 120 33 scenario-based testing 234
use cases as a planning aid 157– discipline (in UP) 54, 129 scenarios 75, 76, 83, 153
8, 159 functional see functional alternatives to the main success
privacy 102, 103 requirements scenario 170–1
problem, and solution 15–16, 175 nature of 73–4, 80 and architecture 158, 159
problem domain 16, 132–3, 135– non-functional see non- case study 221–4, 234
6 functional requirements (NFRs) descriptions of use cases 153–4,
problem statement, initial 56–7, 58, purposes of 87 156
59, 197, 203–4 representation with use case main success scenario 153–4,
process model (life cycle) 30, 32– diagrams 147, 156, 159 155, 156, 164–5, 221–4
4, 45, 132 and testing 79, 81 negative 158
process view 55 with fit criteria 107–14, 235– unsuccessful 153–4
processes 7, 25, 26 6 scope
business see business processes use cases 147–8 of new system 197, 212–16
development see development see also software requirements; of product 98, 117, 218
processes user requirements of work 116–17, 218
product backlog 77–8, 121 requirements analysis and Scrum 36, 38, 78, 121, 201
product boundaries 98, 117 negotiation 30, 76, 76–7 security 101, 101–2
product failure 109 functional requirements 82–5 security requirements 94, 101–6,
project constraints 116, 217–18 requirements documentation 76, 110, 117, 219, 229–30
project drivers 115–16 115–21 semantics 50, 51
project issues 117–18 agile approach 77–8, 80, 121 sequence and communication
project management 31, 32, 34, Volere template 59, 115–20, diagrams (interaction diagrams)
45, 46, 54, 200 197, 217–19, 231–2 58, 60
project notebook 43, 44 requirements elicitation 30, 76, sequential process model 32, 34
project size 38, 41, 45 76–7 service-oriented architecture
prototyping 184, 184–6, 188, functional requirements 82–5 (SOA) 24
189–90 use cases 147, 157, 159 services 24, 24–5, 26
purpose of a project 115, 217 requirements engineering 30, 72 shared behaviour 168–70, 175
244
Index
size stakeholders 72, 79, 80, 115–16, requirements and 79, 81

project 38, 41, 45 217 conformance testing 107–14,
software system 10, 29 standard modelling language 50–2, 235–6
snowcard, requirements 118–19, 61–2 use cases and 158–9, 160
120 standards textual descriptions of use cases
sociotechnical systems 8 for components 24 154–6, 164–5, 171–2, 221–4
software architecture 22, 22–6 development processes 37 Therac 25 radiation therapy
case study 232–3 set of modules 18 machine 8
layered 23, 233 Standish Group 72–3 threats 102, 103–5
requirements and 78, 81, 94 static models see structural models throughput 97
use cases and 158, 159 steering 200 time-to-market 37
software as a service (SaaS) 24 stereotypes 168, 168–75, 176, timeboxing 33, 53
software characteristics 9–10 178–9 traceability 41–4, 42, 74, 188
software development 28–47, 72 structural domain model transition phase 54
choosing an appropriate process (conceptual model) 57, 58, 59 transitions (activity diagrams)
36–41 structural models 52, 53, 56, 57, 133, 134, 135, 136, 137
as an engineering activity 28–9 58, 59–60
problems affecting 44 structured software analysis and unconditional behaviour 169
risk management 39–41 design methodology (SSADM) 37 Unified Modeling Language
role of development processes subproblems 15–16, 174 (UML) 50, 50–1, 53, 60, 131–2,
30–6 subsidiary use case 170–1 147
spiral process 39–40, 46 subsystems 17, 26 activity diagrams see activity
technical activities 30–2, 46 supporting materials 119, 120 diagrams
traceability 41–6 swimlanes 136, 136–7, 139 Unified Process (UP) 31, 53, 53–
software failures 8, 13–15 synchronisation bars 133, 134, 5, 56, 77, 129, 197, 200–2
software quality 28 135, 136, 140 agile 55, 202
software requirements 58, 59, 71 syntax 50, 51 elaboration 54, 77, 201–2, 212
case study 197–8, 220–33 system architecture see software inception 54, 77, 200–1, 212
checking for completeness 231– architecture views in 55
2 system boundary 8–9, 148–50 unsuccessful scenarios 153–4
functional see functional system operations 58, 60 unsuccessful software systems 13–
requirements system requirements 86 15
non-functional see non- systems 7, 7–9 usability 11–12
functional requirements (NFRs) software see software systems usability and humanity
use cases and 147, 157, 159 requirements 94, 95–7, 109, 117,
see also requirements tasks 118, 147, 156, 159 218–19, 228
software systems 7–8, 72 tea-making activity diagram 140–1 use case diagrams 146, 147, 148
characteristics 10–12 technical activities 30–2, 46 avoiding over-complexity 174
legacy systems 12–13, 14–15 technical solution requirements 86, complex 178–83
reasons for building 36–7 87, 89 use case view 55
unsuccessful 13–15 terminology 116 use cases 58, 59, 76, 129, 145,
solution, problem and 15–16, 175 test cases 235–6 145–83
specialisation 38, 41 test-driven design 61 actors 145, 146, 150–1, 156,
specialised actors 166–7 testability 74 159, 166–7
speed of a system 97 testing 28, 31, 32, 33, 42, 46, 54, and agile development 160–5
spiral process for software 71 and architecture 158, 159
development 39–40, 46 acceptance 121, 158, 160, 236 case study 212–15, 221–4
sprint 36, 201 activities and artefacts 56, 61 description of 151–6
sprint planning meeting 36, 201 case study 198, 234–6 textual description 154–6,
staff turnover 13 prototypes 186, 188 164–5, 171–2, 221–4
245
detailed software requirements viewpoints 8
157, 159 illustrated by models 52–3
determination of functional in the UP 55
requirements 83, 87, 88 Volere template 59, 115–20
in development activities 156– case study 197, 217–19
60 checking software requirements
difference from user stories 215, for completeness against 231–2
216 volume 97
elaborated 58, 59, 171–2, 221–4
emphasis on the user 146–8 waiting room 118
fit criteria 108 walk-through technique 158–9, 160
modelling relationships between waterfall model 32, 34
167–75 web browser reservations 203
as a planning aid 157–8, 159 work plan 200
problems with 175–83 workflows 132, 136, 136–44
requirements capture 147, 156,
159 XP (extreme programming) 35–6,
shared behaviour 168–70, 175 38, 78, 200–1
system boundary 148–50
tasks involved in preparing a use
case model 177
and testing 158–9, 160
user interfaces 187–90
usefulness 11–12
user-centred design 146, 146–7
user documentation and training
118
user interfaces 11, 184
linking activities to 186–90
user requirements 71, 86, 220
checking software requirements
for completeness against 231–2
user stories 42, 76, 160
annotation 121, 131
case study 215–16, 236
difference from use cases 215,
216
gathering requirements 84–5, 87,
89, 91, 93, 121
testing with 236
user story cards 121
users 29, 30, 34, 41, 220
involvement 184–90
use cases and emphasis on 146–
8
validation 28, 131, 158, 160

requirements 74, 76
verifiability 74
verification 28, 131, 158–9, 160
246

Block 1 Units 1-4 From Domain To Requirements: TM354 Software Engineering

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Block 1 Units 1-4 From Domain To Requirements: TM354 Software Engineering

Uploaded by

Copyright:

Available Formats

TM354 Software engineering

Block 1 Units 1–4

The Open University, Walton Hall, Milton Keynes MK7 6AA

ISBN 978 1 7800 7915 8

and will begin to be extended to more advanced areas. We discuss some of

Software and software engineering 2

2.1 What is a system?

As Example 3 shows, there is a notion of what is included within a system,

In Example 4, we suggested that two systems, for patient monitoring and

Suppose the monitoring system detected that a patient taking a common

2.2 The nature of software

. Malleability. Software is easy to change (programmers are often tempted to

For each of the three characteristics of software mentioned above, explain

Malleability. As change is easy to make, often changes are introduced

2.3 Characteristics of a software system

2.4 Maintainability and other software problems

software is associated with a critical service within a company. Such systems

Unsuccessful software systems

Unfortunately, successful software systems rarely make the news. Example 6

(a) Suggest a means of measuring the maintainability of a software

(a) We could measure the effort required by a developer to locate and

become precarious to go any further. The staff issues mentioned in (b)

2.5 Divide and conquer?

Problem and solution

the problem is in computing system

connections between the world

Figure 1 Separating a problem from its solution

Modules and interfaces

The concept of an interface helps the developer to be more productive. If you

Coupling and cohesion

◦ Which modules are clients of the module in question? This

The software architecture of a system is the set of structures needed to

It is important to understand the software architecture because it tells the

Suggest some similarities and differences between software architecture and

They are both abstractions of the structure of a system. They represent

materials. Software has different properties from building components, in

Layers, components and services

Figure 2 Three-layered architecture

Reuse is one strategy to deal with increased complexity of software and it

We use the term component to denote a unit of reuse or replacement in a

provided interface graphical stereotype

Figure 3 Two graphical representations of a component

A similar concept is that of a service. A service is also a unit of reuse

bind and invoke publish

Components tend to relate to entities, while services relate to processes.

(a) What are the characteristics of a component?

(a) A component is a module that is considered to be a sufﬁciently good

(b) The architecture of a software system embodies high-level decisions

2.7 Summary of section

processes will produce well-engineered components based on reusable

3 An introduction to software development

3.1 Software development as an engineering

1 The application of a systematic, disciplined, quantiﬁable approach to the

Carrying out a systematic, disciplined and quantiﬁable approach implies

Give the characteristics of an engineering approach that support the

Software development follows an engineering approach provided that the

3.2 The role of development processes

Typical technical activities for the development of software

. Implementation. Acting upon the decisions made at the design stage.

Figure 5 Activities for the development of a good software system

An overall process model

final integration final integration

3 weeks (for example)