Sunday, 7 August 2011

What is software

What is software?
Many people equate the term software with computer programs. However, I prefer a
broader definition where software is not just the programs but also all associated documentatlon
and configuration data that is needed to make these programs operate correctly.
A software system usually consists of a number of separate programs,
configuration files, which are used to set up these programs, system documentation,
which describes the structure of the system, and user documentation, which explains
how to use the system and web sites for users to download recent product information.
Soft\\iare engineers are concerned with developing software products, i.e., software
which can be sold to a customer. There are two fundamental types of software
product
1. Generic products These are stand-alone systems that are produced by a development
organisation and sold on the open market to any customer who is able
to buy them. Examples of this type of product include software for pes such as
databases, word processors, drawing packages and project management tools.
2. CuslOmised (or bespoke) products These are systems which are commissioned
by a particular customer. A software contractor develops the software especially
for that customer. Examples of this type of software include control systems
for electronic devices, systems written to support a particular business process
and air traffic control systems.

Question Answer
What is software7
What is software engineering?
What is the difference between
software engineering and
computer science?
What is the difference between
software engineering and system
engineering?
What is a software process?
What is a software process
model?
What are the costs of software
engineering?
What are software engineering
methods?
What is CASE (Computer-Aided
Software Engineering)?
What are the attributes of good
software?
What are the key challenges
facing software engineering?
Computer programs and associated documentation. software products
may be developed for a particular customer or may be developed for a
general market
Software engineering is an engineering discipline which is concerned
with all aspects of software production.
Computer science is concerned with theory and fundamentals; software
engineering is concerned with the practicalities of developing and
delivering useful software.
System engineering is concerned with all aspects of computer-based
systems development, including hardware, software and process
engineering. Software engineering is part of this process.
A set of activities whose goal is the development or evolution of
software.
A simplified representation of a software process, presented from a
specific perspective.
Roughly 60% of costs are development costs, 40% are testing costs. For
custom software, evolution costs often exceed development costs.
Structured approaches to software development which include system
models, notations, rules, design advice and process guidance.
Software systems which are intended to provide automated support for
software process activities. CASE systems are often used for method
support.
The software should deliver the required functionality and performance
to the user and should be maintainable, dependable and usable.
Coping with increasing diversity, demands for reduced delivery times
and developing trustworthy software.

An important difference between these types of software is that, in generic products,
the organisation that develops the software controls the software specification.
For custom products, the specification is usually developed and controlled by the
organisation that is buying the software. The software developers must work to that
specification.
However, the line between these types of products is becoming increasingly blurred.
More and more software companies are starting with a generic system and custQmising
it to the needs of a particular customer. Enterprise Resource Planning (ERP) systems,
such as the SAP system, are the best examples of this approach. Here, a large
and complex system is adapted for a company by incorporating information about
business rules and processes, reports required, and so on.

What is software engineering

What is software engineering?
Software engineering is an engineeling discipline that is concerned with all aspects
of software production from the eady stages of system specification to maintaining
the system after it has gone into use. In this definition, there are two key phrases:
1. Engineering discipline Engineers make things work. They apply theories, methods
and tools where these are appropriate,. but they use them selectively and always
try to discover solutions to problems even when there are no applicable theories
and methods. Engineers also recognise that they must work to organisational and
financial constraints, so they look for solutions within these constraints.
2. All aspects of software production Software engineering is not just concerned
with the technical processes of software development but also with activities
such as software project management and with the development of tools, methods
and theories to support software production.
In general, software engineers adopt a systematic and organised approach to their
work, as this is often the most effective way to produce high-quality software. However,
engineering is all about selecting the most appropriate method for a set of circumstances
,md a more creative, less fOlmal approach to development may be effective
in some circumstances. Less formal development is particularly appropriate for the
development of web-based systems. which requires a blend of software and graphical
design skills.

User requirements

The user requirements for a system should describe the functional and nonfunctional
requirements so that they are understandable by system users without detailed
technical knowledge. They should only specify the external behaviour of the system
and should avoid, as far as possible, system design characteristics.
Consequently, if you are writing user requirements, you should not use software
jargon, structured notations or formal notations, or describe the requirement by describing
the :,ystem implementation. You should write user requirements in simple language,
with simple tables and forms and intuitive diagrams.
How,~ver, various problems can arise when requirements are written in natural
languag'~ sentences in a text document:
1. Lack ofclarity It is sometimes difficult to use language in a precise and unambiguous
way without making the document wordy and difficult to read.
2. Requirements confusion Functional requirements, non-functional requirements,
sysicem goals and design infonnation may not be clearly distinguished.
3. Requirements amalgamation Several different requirements may be expressed
together as a single requirement.
This requirement includes both conceptual and detailed information. It expresses
the concept that there should be an accounting system as an inherent part of LIBSYS.
However, it also includes the detail that the accounting system should support
discounts for regular LIBSYS users. This det:lil would have been better left to
the system requirements specification.
It is good practice to separate user requirements from more detailed system requirements
in a requirements document. Otherwise, non-te:chnical readers of the user requirements
may be overwhelmed by details that are really only relevant for technicians.
Figure 6.9 illustrates this confusion. This example is taken from an actual requirements
aocument for a CASE tool for editing software design models. The user may
specify that a grid should be displayed so that entities may be accurately positioned
in a diagram.

GrId facilities To assist in the positioning of entities on a diagram, the user
may tum on a grid in either centimetres or inches, via an option on the control
panel. Initially, the grid is off. The grid may be tumed on and off at any time during
an editing session and can be toggled between inches and centimetres at any time.
Agrid option will be provided on the reduce-to-fit view but the number of grid lines
shown will be reduced to avoid filling the smaller diagram with grid lines.

The fIrst sentence mixes up three kinds of requirements.
1. A conceptual, functional requirement states that the editing system should provide
a grid. It presents a rationale for this.
2. A non-functional requirement giving detailed information about the grid units
(centimetres or inches).
3. A non-functional user interface requirement that defmes how the grid is
switched on and off by the user.
The requirement in Figure 6.9 also gives some but not all initialisation information.
It defInes that the grid is initially off. However, it does not defIne its units
when turned on. It provides some detailed information-namely, that the user may
toggle between units-but not the spacing between grid lines.
User requirements that include too much information constrain the freedom of
the system developer to provide innovative solutions to user problems and are diffIcult
to understand. The user requirement should simply focus on the key facilities
to be provided. I have rewritten the editor grid requirement (Figure 6.10) to
focus only on the essential system features.
Whenever possible, you should try to associate a rationale with each user
requirement. The rationale should explain why the requirement has been included
and is particularly useful when requirements are changed. For example, the rationale
in Figure 6.10 recognises that an active grid where positioned objects automatically
'snap' to a grid line can be useful. However, this has been deliberately
rejected in favour of manual positioning. If a change to this is proposed at some
later stage, it will be clear that the use of a passive grid was deliberate rather than
an implementation decision.
To minimise misunderstandings when writing user requirements, I recommend
that you follow some simple guidelines:
I. Invent a standard format and ensure that all requirement defInitions adhere to
that format. Standardising the format makes omissions less likely and requirements
easier to check. The format I use shows the initial requirement in boldface,
including a statement of rationale with each user requirement and a
reference to the more detailed system requirement specifIcation. You may also
include information on who proposed the requirement (the requirement source)
so that you know whom to consult if the requirement has to be changed.
2. Use language consistently. You should always distinguish between mandatory
and desirable requirements. Mandatory requirl~ments are requirements that the
system must support and are usually written using 'shall'. Desirable requirements
are not essential and are written using 'should'.
3. Use text highlighting (bold, italic or colour) to pick out key parts of the
requirement.
4. Avoid, as far as possible, the use of computer jargon. Inevitably, however, detailed
technical tenns will creep into the user requirements.
The Robertsons (Robertson and Robertson, 1999), in their book that covers the
VOLERE requirements engineering method, recommend that user requirements be
initially written on cards, one requirl~ment per card. They suggest a number of fields
on each ,~ard, such as the requirements rationale, the dependencies on other requirements,
the source of the requirements, supporting materials, and so on. This
extends the fonnat that I have used, and it can be used for both user
and system requirements.

The software requirements document

The software requirements document (sometimes called the software requirements
specification or SRS) is the official statement of what the system developers should
implement. It should include both the user requirements for a system and a detailed
specification of the system requirements. In some cases, the user and system
requirements may be integrated into a single description. In other cases, the user
requirements are defined in an introduction to the system requirements specification.
If there are a large number of requirements, the detailed system requirements
may be presented in a separate document.
The requirements document has a diverse set of users, ranging from the senior
management of the organisation that is paying for the system to the engineers responsible
for developing the software. Figure 6.16, taken from my book with Gerald
Kotonya on requirements engineering (Kotonya and Sommerville, 1998) illustrates
possible users of the document and how they use it.
The diversity of possible users means that the requirements document has to be
a compromise between communicating the requirements to customers, defining the
requirements in precise detail for developers and testers, and including information
about possible system evolution. Information on anticipated changes can help system
designers avoid restrictive design decisions and help system maintenance engineers
who have to adapt the system to new requirements.
The level of detail that you should include in a requirements document depends
on the type of system that is being developed and the development process used.
When the system will be developed by an external contractor, critical system specifications
need to be precise and very detailed. When there is more flexibility in
the requirements and where an in-house, iterative development process is used, the
requirements document can be much less detailed and any ambiguities resolved during
development of the system.
A number of large organisations, such as the US Department of Defense and the
IEEE, have defined standards for requirements documents. Davis (Davis, 1993) discusses
some of these standards and compares their contents. The most widely known
standard is IEEE/ANSI 830-1998 (IEEE, 1998). This IEEE standard suggests the
following structure for requiremems documents:
I. Introduction
1.1 Purpose of the requiremt:nts document
1.2 Scope of the product
1.3 Definitions, acronyms and abbreviations
1.4 References
1.5 Overview of the remainder of the document
2. General description
2.1 Product perspective
2.2 Product functions
2.3 User characteristics
2.4 General constraints
2.5 Assumptions and dependencies
3. Specific requirements cover functional, non··functional and interface requirements.
This is obviously the most substantial part of the document but because
of the wide variability in organisational practice, it is not appropriate to define
a standard structure for this section. The requirements may document external
interfaces, describe system functionality and performance, specify logical
database requirements, design constraints, emergent system properties and
quality characteristics.
4. Appendices
5. Index
Although the IEEE standard is not ideal, it contains a great deal of good advice
on how to write requirements and how to avoid problems. It is too general to be
an organisational standard in its own right. It is a general framework that can be
tailored and adapted to define a standard geared to the needs of a particular organisation.
Figure 6.17 illustrates a possible organisation for a requirements document
that is based on the IEEE standard. However, I have extended this to include information
about predicted system evolution. This was first proposed by Heninger
(Heninger, 1980) and, as I have discussed, helps the maintainers of the system and
may allow designers to include support for future system features.
Of course, the information that is included in a requirements document must depend
on the type of software being developed and the approach to development that is
used. If an evolutionary approach is adopted for a software product (say), the requirements
document will leave out many of detailed chapters suggested above. The focus
will be on defining the user requirements and high-level, non-functional system requirements.
In this case, the designers and programmers use their judgement to decide
how to meet the outline user requirements for the system.
By contrast, when the software is part of a large system engineering project that
includes interacting hardware and software systems, it is often essential to define
the requirements to a fine level of detail. This means that the requirements documents
are likely to be very long and should include most if not all of the chapters
shown in Figure 6.17. For long documents, it is particularly important to include a
comprehensive table of contents and document index so that readers can find the
information that they need.
Requirements documents are essential when an outside contractor is developing
the software system. However, agile development methods argue that requirements
change so rapidly that a requirements document is out of date as soon as it is written,
so the effort that is largely wasted. Rather than a formal document, approaches
such as extreme programming (Beck, 1999) propose that user requirements should
be collected incrementally and written on cards. The user then prioritises requirements
for implementation in the next increment of the system.
=======================================================
Preface
This should define the expec:ted readership of the document
and describe its version history, including a rationale for the
creation of a new version and a summary of the changes
made in each version.
------------------------------------------------------
Introduction
This should describe the neE~d for the system. It should briefly
describe its functions and explain how it will work with other
systems. It ~;hould describe how the system fits into the
overall busi ness or strategic ,objectives of the organisation
commission1ing the software.

------------------------------------------------------

Glossary
This should define the technical terms used in the document
You should not make assumptions about the experience or
expertise of the reader.
------------------------------------------------------
User requirements definition
The service!; provided for thE~ user and the non-functional
system requirements should be described in this section. This
description may use natural language, diagrams or other
notations that are understandable by customers. Product
and proces!; standards which must be followed should be
specified.

------------------------------------------------------
System architecture
This chapter should present a high-level overview of the
anticipated system architecture showing the distribution of
functions ac:ross system modules. Architectural components
that are reused should be highlighted.
------------------------------------------------------
System requirements specification
This should describe the funlctional and non-functional
requirements in more detail. If necessary, further detail
may also bl! added to the Mn-functional requirements,
e.g. interfaces to other systems may be defined.

------------------------------------------------------
SystE!m models
This should set out one or more system models showing
the relationships between the system components and the
system and its environment These might be object models,
data-flow models and semantic data models.
------------------------------------------------------
System evolution
This should describe the fundamental assumptions on which
the system is based and anticipated changes due to hardware
evolution, changing user needs, etc.
------------------------------------------------------
Appendices
These should provide detailed, specific information which
is related tCI the application which is being developed.
Examples o·f appendices that may be inclUded are hardware
and database descriptions. Hardware requirements define the
minimal and optimal configurations for the system. Database
requirements define the logical organisation of the data used
by the system and the relaticmships between data.
------------------------------------------------------
Index
several indElxes to the document may be included. As well
as a nonmal alphabetic indeJ~ there
=======================================================
For business systems where requirements are unstable, I think that this approach
is a good one. However, I would argue that it is still useful to write a short supporting
document that defines the business and dependability requirements for the
system. It is easy to forget the requirements that apply to the system as a whole
when focusing on the functional requirements for the next system release.

System requirements

System requirements are expanded versions of the user requirements that are used
by software engineers as the starting point for the system design. They add detail
and explain how the user requirements should be provided by the system. They maybe used as part of the contract for the implementation of the system and should
therefore be a complete and consistent specification of the whole system.
Ideally, the system requirements should simply describe the external behaviour
of the system and its operational constraints. They should not be concerned with
how the system should be designed or implemented. However, at the level of detail
required to completely specify a complex software system, it is impossible, in practice,
to exclude all design information. There are several reasons for this:
1. You may have to design an initial architecture of the system to help structure
the requirements specification. The system requirements are organised according
to the different sub-systems that make up the system. As I discuss in Chapter
7 and Chapter 18, this architectural definition is essential if you want to reuse
software components when implementing the system.
2. In most cases, systems must interoperate with other existing systems. These constrain
the design, and these constraints impose requirements on the new system.
3. The use of a specific architecture to satisfy non-functional requirements (such
as N-version programming to achieve reliability, discussed in Chapter 20) may
be necessary. An external regulator who needs to certify that the system is safe
may specify that an architectural design that has already been certified be used.
Natural language is often used to write system requirements specifications as
well as user requirements. However, because system requirements are more
detailed than user requirements, natural language specifications can be confusing
and hard to understand:
1. Natural language understanding relies on the specification readers and writers
using the same words for the same concept. This leads to misunderstandings
because of the ambiguity of natural language. Jackson (Jackson, 1995) gives
an excellent example of this when he discusses signs displayed by an escalator.
These said 'Shoes must be worn' and 'Dogs must be carried'. I leave it to
you to work out the conflicting interpretations of these phrases.
2. A natural language requirements specification is overflexible. You can say the
same thing in completely different ways. It is up to the reader to find out when
requirements are the same and when they are distinct.
3. There is no easy way to modularise natural language requirements. It may be
difficult to fmd all related requirements. To discover the consequence of a change,
you may have to look at every requirement rather than at just a group of related
requirements.
Because of these problems, requirements specifications written in natural language
are prone to misunderstandings. These are often not discovered until later
phases of the software process and may then be very expensive to resolve.

--------------------------------------------------------------------------
Structured natural
language
This approach depends on defining standard forms or
templates to I!XpreSS the requirements specification.

---------------------------------------------------------------------------
Design description
languages
This approach uses a language like a programming language
but with mOrE! abstract feature!; to specify the requirements by
defining an operational model of the system. This approach is
not now widely used although it can be useful for interface
specifications.

---------------------------------------------------------------------------
Graphical notations
A graphical language, supplemented by text annotations is
used to definE! the functional requirements for the system. An
early example of such a graphical language was SADT (Ross,
1977) (SChoman and Ross, 19n). Now, use-case descriptions
(Jacobsen, et 411., 1993) and seqDence diagrams are commonly
used (Stevens and Pooley, 1999).
---------------------------------------------------------------------------
Mathematical
specifications
These are notations based on mathematical concepts such as
finite-state machines or sets. These unambiguous specifications
reduce the arguments between customer and contractor about
system functionality. However, most customers don't
understand fOlmal specifications and are reluctant to accept it
as a system cClntract.
---------------------------------------------------------------------------

--------------------------------------------------------------------------

System models

User requirements should be written in natural language because they have to be
understood by people who are not technical experts. However, more detailed system
requirements may be expressed in a more technical way. One widely used technique
is to document the system specification as a set of system models. These models
are graphical representations that describe business processes, the problem to be solved
and the system that is to be developed. Because of the graphical representations
used, models are often more understandable than detailed natural language descriptions
of the system requirements. They are also an important bridge between the
analysis and design processes.
You can use models in the analysis process to develop an understanding of the
existing system that is to be replaced or improved or to specify the new system that
is required. You may develop different models to represent the system from different
perspectives. For example:
1. An external perspective, where the context or environment of the system is
modelled
2. A behavioural perspective, where the behaviour of the system is modelled
3. A structural perspective, where the architecture of the system or the structure
of the data processed by the system is modelled
I cover these three perspectives in this chapter and also discuss object modelling,
which combines, to some extent, behavioural and structural modelling.
The most important aspect of a system model is that it leaves out detail. A system
model is an abstraction of the system being studied rather than an alternative
representation of that system. Ideally, a representation of a system should maintain
all the information about the entity being represented. An abstraction deliberately
simplifies and picks out the most salient characteristics. For example, in the very
unlikely event of this book being serialised in a newspaper, the presentation there
would be an abstraction of the book's key points. If it were translated from English
into Italian, this would be an alternative representation. The translator's intention
would be to maintain all the information as it is presented in English.
Different types of system models are based on different approaches to abstraction.
A data-flow model (for example) concentrates on the flow of data and the functional
transformations on that data. It leaves out details of the data structures. By
contrast, a model of data entities and their relationships documents the system data
structures rather than its functionality.
Examples of the types of system models that you might create during the analysis
process are:
1. A data- flow model Data-flow models show how data is processed at different
stages in the system.
2. A composition model A composition or aggregation model shows how entities
in the system are composed of other entities.
3. An architectural model Architectural models show the principal sub-systems
that make up a system.
4. A classification model Object class/inheritance diagrams show how entities have
common characteristics.
5. A stimulus-response model A stimulus-responsc~ model, or state transition diagram,
shows how the system reacts to internal and external events.
All th,ese types of models are covered in this chapter. Wherever possible, I use
notations from the Unified Modeling Language (UML), which has become a standard
modelling language for object-oriented modelling (Booch, et al., 1999;
Rumbaugh, et al., 1999a). Where UML does not include appropriate notations, I use
simple intuitive notations for model description. A new version of UML (UML 2.0)
is under development but was not available when I wrote this chapter. However, I
understarld that the UML notation that I have used here is likely to be compatible
with UML 2.0.

Structured language specifications

Structured natural language is a way of writing system requirements where the freedom
of the requirements writer is limited and all requirements are written in a standard
way. The advantage of this approach is that it maintains most of the
expressiveness and understandability of natural language but ensures that some degree
of unifonnity is imposed on the specification. Structured language notations limit
the tenninology that can be used and use templates to specify system requirements.
They may incorporate control constructs derived from programming languages and
graphical highlighting to partition the specification.
An early project that used structured natura1language for specifying system requirements
is described by Heninger (Heninger, 1980). Special-purpose forms were designed
to describe the input. output and functions of an aircraft software system. The system
requirements were specified using these forms.
To use a fonn-based approach to specifying system requirements, you must define
one or more standard fonns or templates to express the requirements. The specification
may be structured around the objects manipulated by the system, the functions
perfonned by the system or the events processed by the system. An example
of such a fonn-based specification is shown in Figure 6.12. I have taken this example
from the insulin pump system that was introduced in Chapter 3.
The insulin pump bases its computations of the user's insulin requirement on the
rate of change of blood sugar levels. These rates of change computed using the current
and previous readings. You can download a complete version of the specification
for the insulin pump from the book's web pages.
When a standard fonn is used for specifying functional requirements, the following
infonnation should be included:
I. Description of the function or entity being specified
2. Description of its inputs and where these come from3. Description of its outputs and where these go to
4. Indication of what other entities are used (the requires part)
5. Description of the action to be taken
6. If a functionaJi approach is used, a pre-condition setting out what must be true
before the function is called and a post-condition specifying what is true after
the function is called
7. Description of the side effects (if any) of the operation.
Using formatted specifications removes some of the problems of natural language
specification. Variability in the specification is reduced and requirements are
organised more effectively. However, it is difficult to write requirements in an unambiguous
way, particularly when complex computations are required. You can see
this in the description shown in Figure 6.12, where it isn't made clear what happens
if the pre-condition is not satisfied.
To address this problem, you can add extra information to natural language requirements
using tables or graphical models of the system. These can show how computations
proceed, how the system state changes, how users interact with the
system and how sequences of actions are performed.
Tables are particularly useful when there are a number of possible alternative
situations and you need to describe the actions to be taken for each of these. Figure
6.13 is a revised description of the computation of the insulin dose.
Graphical models are most useful when you nef:d to show how state changes
(see Chapter 8) or where you need to describe a sequence of actions. Figure 6.14
illustrates the sequence of actions when a IIser wishes to withdraw cash from an
automated teller machine (ATM).
You should read a sequence diagram from top to bottom to see the order of the
actions that take place. In Figure 6.14, there are thre:e basic sub-sequences:
I. Validate card The user s card is validated by checking the card number and
user sPIN.
2. Handle request The user s request is handled by the system. For a withdrawal,
the database must be queried to check the user's balance and to debit the amount
withdrawn. Notice the exception here if the requestor does not have enough
money in their account.
3. Compl,qte transaction The user s card is Ireturned and, when it is removed, the
cash and receipt are delivered.

State machine models

Astate machine model describes how a system responds to internal or external events.
The state machine model shows system states and events that cause transitions from
one state to another. It does not show the flow of data within the system. This type
of model is often used for modelling real-time systems because these systems are
often driven by stimuli from the system's environment. For example, the real-time

alarm system discussed in Chapter 13 responds to stimuli from movement sensors,
door opening sensors, and so on.
State machine models are an integral part of real-time design methods such as
that proposed by Ward and Mellor (Ward and Mellor, 1985) and Harel (Harel, 1987;
Harel, 1988). Harel's method uses a notation called Statecharts and these were the
basis for the state machine-modelling notation in the UML.
A state machine model of a system assumes that, at any time, the system is in
one of a number of possible states. When a stimulus is received, this may trigger
a transition to a different state. For example, a system controlling a valve may move
from a state 'Valve open' to a state 'Valve closed' when an operator command (the
stimulus) is received.
This approach to system modelling is illustrated in Figure 8.5. This diagram shows
a state machine model of a simple microwave oven equipped with buttons to set
the power and the timer and to start the system. Real microwave ovens are actually
much more complex than the system described here. However, this model includes
the essential features of the system. To simplify the model, I have assumed that the
sequence of actions in using the microwave is:
1. Select the power level (either half-power or full-power).
2. Input the cooking time.
3. Press Start, and the food is cooked for the given time.
For safety reasons, the oven should not operate when the door is open and, on
completion of cooking, a buzzer is sounded. The oven has a very simple alphanumeric
display that is used to display various alerts and warning messages.
The UML notation that I use to describe state machine models is designed for
modelling the behaviour of objects. However, it is a general-purpose notation that
can be llSed for any type of state machine modelling. The rounded rectangles in a
model rl~present system states. They include a brief description (following 'do') of
the actions taken in that state. The labelled arrows represent stimuli that force a
transition from one state to another.
Therefore, we can see that the system responds initially to either
the full-power or the half-power button. Users can change their mind after selecting
one of these and press the other button. The time is set and, if the door is closed,
the Start button is enabled. Pushing this button starts the oven operation and cooking
takes place for the specified time.
The UML notation lets you indicate the activity that takes place in a state. In a
detailed system specification, you have to provide more detail about both the stimuli
and the system states . This information may be maintained in a data
dictionary or encyclopaedia that is maintained by the CASE
tools used to create the system model.
The problem with the state machine approach is that the number of possible states
increases rapidly. For large system models, theref~re, some structuring of these state
models is necessary. One way to do this is by using the notion of a superstate that
encapsulates a number of separate states. This superstate looks like a single state
on a high-level model but is then expanded in more detail on a separate diagram.
To illus:trate this concept, consider the Operation state . This is a superstate
that can be expanded.
The Operation state includes a number of sub-states. It shows that operation starts
with a status check, and that if any problems are discovered, an alarm is indicated
and operation is disabled. Cooking involves runnmg the microwave generator for
the specified time; on completion, a buzzer is sounded. If the door is opened during
operation, the system moves to the disabled state,

Software requirements

The requirements for a system are the descriptions of the services provided by the
system and its operational constraints. These requirements reflect the needs of customers
for a system that helps solve some problem such as controlling a device,
placing an order or finding information. The process of finding out, analysing, documenting
and checking these services and constraints is called requirements engineering
(RE). In this chapter, I concentrate on the requirements themselves and how
to describe them.
The term requirement is not used in the software industry in a consistent way.
In some cases, a requirement is simply a high-level, abstract statement of a service
that the system should provide or a constraint on the system. At the other extreme,
it is a detailed, formal definition of a system function. Davis (Davis, 1993) explains
why these differences exist:
If a company wishes to let a contract for a large software development project,
it must defme its needs in a sufficiently abstract way that a solution is not predefined.
The requirements must be written so that several contractors can bid for
the contract, offering, perhaps, different ways of meeting the client organisation's
needs. Once a contract has been awarded, the contractor must write a system
definition for the client in more detail so that the client understands and can validate
what the software will do. Both of these documents may be called the requirements
document for the system.
Some of the problems that arise during the requirements engineering process are a result
of failing to make a clear separation between these different levels of description. I distinguish
between them by using the term user requirements to mean the high-level abstract
requirements and system requirements to mean the detailed description of what the system
should do. User requirements and system requirements may be defined as follows:
1. User requirements are statements, in a natural language plus diagrams, of what
services the system is expected to provide and the constraints under which it
must operate.
2. System requirements set out the system's functions, services and operational
constraints in detail. The system requirements document (sometimes called a
functional specification) should be precise. It should define exactly what is to
be implemented. It may be part of the contract between the system buyer and
the software developers.
Different levels of system specification are useful because they communicate infor
mation about the system to different types of readers. This example from a library system
shows how a user requirement may be expanded into several system requirements.
You can see from Figure 6.1 that the user requirement is more abstract, and the
system requirements add detail, explaining the services and functions that should
be provided by the system to be developed.

User requirement definition
I. L1BSYS shall keep track of all data required by <copyright licensing
agencies in the UK and elsewhl!re
System requirements spedflcd(ln
1.1 On making a request for a document from L1BSYS, the requestor shall
be presented with aform that rl!Cords details of tile user and the request
made.
1.2 LIBSYS request forms shall be stored on the system for five years from
the date of the request.
1.3 All L1BSYS request forms must be indexed by user, by the name of the
material requested and by the supplier of the request.
1.4 L1BSYS shall maintain a log elf all requests that have been made to the
system.
1.5 For material where authors' lending rights apply, loan details shall be
sent monthly to copyright Iicensiing agencies that have registered
with L1BSYS.

software process

What is a software process?
A software process is the set of activities and associated results that produce a software
product. There are four fundamental process activities (covered later in the
book) that are common to all software processes. These are:
1. Software specification where customers and engineers define the software to
be produced and the constraints on its operation.
2. Software development where the software is designed and programmed.
3. Software validation where the software is checked to ensure that it is what the
customer requires.
4. Software evolution where the software is modified to adapt it to changing customer
and market requirements.
Different types of systems need different development processes. For example,
real-time software in an aircraft has to be completely specified before development
begins whereas, in e-commerce systems, the specification and the program are usually
developed together. Consequently, these generic activities may be organised in
different ways and described at different levels of detail for different types of software.
However, use of an inappropriate software process may reduce the quality or
the usefulness of the software product to be developed and/or increase the development
costs.

software process model

A software process model is a simplified description of a software process that presents
one view of that process. Process models may include activities that are part
of the software process, software products and the roles of people involved in software engineering. Some examples of the types of software process model that may
be produced are:
L A workflow model This shows the sequence of activities in the process along
with their inputs, outputs and dependencies. The activities in this model represent
human actions.
2. A dataflow or activity model This represents the process as a set of activities,
each of which carries out some data transformation. It shows how the input to
the process, such as a specification, is transformed to an output, such as a design.
The activities here may represent transfOlmations carried out by people or by
computers.
3. A role/action model This represents the roles of the people involved in the software
process and the activities for which they are responsible.
Most software process models are based on one of three general models or
paradigms of software development:
I. The waterfall approach This takl~S the above activities and represents them as
separate process phases such as requirements specification, software design, implementation,
testing and so on. After each s,tage is defined it is 'signed-off, and
development goes on to the following stage.
2. Iterative development This approach interleaves the activities of specification,
development and validation. An initial system is rapidly developed from very
abstract specifications. This is then refined with customer input to produce a
system that satisfies the customer s needs. The system may then be delivered.
Altematively, it may be reimpkmented using a more structured approach to
produce a more robust and maintainable system.
3. Component-based software engineering (CBSE) This technique assumes that
parts of the system already exist. The system development process focuses on
integrating these parts rather than developing them from scratch.

software engineering methods

A software engineering method is a structured approach to software development
whose aim is to facilitate the production of high-quality software in a cost-effective
way. Methods such as Structured Analysis (DeMarco, 1978) and JSD (Jackson, 1983)
were first developed in the 1970s. These methods attempted to identify the basic
functional components of a system; function-oriented methods are still used. In the
1980s and 1990s, these function-oriented methods were supplemented by objectoriented
(00) methods such as those proposed by Booch (Booch, 1994) and
Rumbaugh (Rumbaugh, et al., 1991). These different approaches have now been
integrated into a single unified approach built around the Unified Modeling
Language (UML) (Booch, et al., 1999; Rumbaugh, et aI., 1999a; Rumbaugh, et al.,
1999b).
There is no ideal method, and different methods have different areas where they
are applicable. For example, object-oriented methods are often appropriate for
interactive systems but not for systems with stringent real-time requirements.
All methods are based on the idea of developing models of a system that may
be represented graphically and using these models as a system specification or design.

software engineering and system

What is the difference betwE!en software engineering and system
engi~~ring? _
System engineering is concerned wilth all aspects of the development and evolution
of complex systems where software plays a major role. System engineering is therefore
concerned with hardware development, policy and process design and system deployment as well as software engineering. System engineers are involved in specifying
the system, defining its overall architecture and then integrating the different
parts to create the finished system. They are less concerned with the engineering of
the system components (hardware, software, etc.).
System engineering is an older discipline than software engineering. People have
been specifying and assembling complex industrial systems such as aircraft and chemical
plants for more than a hundred years. However, as the percentage of software
in systems has increased, software engineering techniques such as use-case modelling
and configuration management are being used in the systems engineering process.

Socia-technical systems

The teml system is one that is universally used. We talk about computer systems,
operating systems, payment systems, the educational system, the system of govemment,
and so on. These are all obviously quite different uses of the word system although
they share the characteristic that, somehow, the system is more than simply the sum
of its paJ1s.
Very abstract systems such as the system of government are well outside the
scope of this book. Consequently, I focus here on systems that include computers
and that have some specific purpose such as to enable communication, support navigation,
and compute salaries. Therefore, a useful working definition of these types
of systems is:
A system is a purposeful collection ofinterrelated components that work together
to achieve some objective.
This general definition embraces a vast range of systems. For example, a very
simple system such as a pen may only include three or four hardware components.
By contrast, an air traffic control system includes thousands of hardware and software
components plus human users who make decisions based on information from
the computer system.
Systems that include software fall into two categories:
Technical computer-based systems are systems that include hardware and software
components but not procedures and processes. Examples of technical systems
include televisions, mobile phones and most personal computer software.
Individuals and organisations use technical systems for some purpose but
knowledge of this purpose is not part of the system. For example, the word
proc1essor I am using is not aW~il'e that is it being used to write a book.
Socio-technical systems include one or more technical systems but, crucially,
also mclude knowledge of how the system should be used to achieve some broader
objective. This means that these systems have defined operational processes,
include people (the operators) as inherent parts of the system, are governed by
organisational policies and rules and may be affected by external constraints
such as national taws and regulatory policies. For example, this book was created
through a socio-technical publishing system that includes various processes
and technical systems.
Essential characteristics of socio-technical systems are as follows.
I. They have emergent properties that are properties of the system as a whole rather
than associated with individu~.l parts of the system. Emergent properties
depend on both the system components and the relationships between them. As
this is so complex, the emergent properties can only be evaluated once the system
has been assembled.
2. They are often nondeterministic. This means that, when presented with a specific
input, they may not always produce the same output. The system's
behaviour depends on the human operators, and people do not always react in
the same way. Furthermore, use of the system may create new relationships
between the system components and hence change its emergent behaviour.
3. The extent to which the system supports organisational objectives does not just
depend on the system itself. It also depends on the stability of these objectives,
the relationships and conflicts between organisational objectives and how people
in the organisation interpret these objectives. New management may reinterpret
the organisational objective that a system is designed to support, and
a successful' system may then become a 'failure'.
In this book, I am concerned with socio-technical systems that include hardware
and software, which have defined operational processes and which offer an interface,
implemented in software, to human users. Software engineers should have some
knowledge of socio-technical systems and systems engineering (White, et al., 1993;
Thayer, 2(02) because of the importance of software in these systems. For example,
there were fewer than 10 megabytes of software in the US Apollo space program
that put a man on the moon in 1969, but there are about 100 megabytes of
software in the control systems of the Columbus space station.
Acharacteristic of all systems is that the properties and the behaviour of the system
components are inextricably intermingled. The successful functioning of each
system component depends on the functioning of some other components. Thus,
software can only operate if the processor is operational. The processor can only
carry out computations if the software system defining these computations has been
successfully installed.
Systems are usually hierarchical and so include other systems. For example, a
police command and control system may include a geographical information system
to provide details of the location of incidents. These other systems are called
sub-systems. A characteristic of sub-systems is that they can operate as independent
systems in their own right. Therefore, the same geographical information system
may be used in different systems.
Because software is inherently flexible, unexpected systems problems are often
left to software engineers to solve. Say a radar installation has been sited so that
ghosting of the radar image occurs. It is impractical to move the radar to a site with
less interference, so the systems engineers have to find another way of removing
this ghosting. Their solution may be to enhance the image-processing capabilities
of the software to remove the ghost images. This may slow down the software so
that its performance becomes unac~eptable. The problem may then be characterised
as a 'software failure' whereas, in fact, it was a failure in the design process for
the system as a whole.
This situation, where software engineers are left with the problem of enhancing
software capabilities without increasing hardware cost, is very common. Many socalled
software failures were not a consequence of inherent software problems; they
were the: result of trying to change the software to accommodate modified system
engineeJing requirements. A good example of this was the failure of the Denver
airport baggage system (Swartz, 1996), where the controlling software was
expected to deal with several limitations in the equipment used.
Software engineering is therefore critical for the successful development of
complex, computer-based socio-technical systems. As a software engineer, you should
not simply be concerned with the software itself but you should also have a broader
awareness of how that software interacts with other hardware and software systems
and how it is supposed to be used. This knowledge helps you understand the limits
of software, to design better software and to participate as equal members of a
systems engineering group.

Risk-driven specification

Critical systems specification supplements the nonnal requirements specification process
by focusing on the dependability of the systlem. Its objective is to understand
the risks faced by the system and generate dependability requirements to cope with
them. Risk-driven specification has been widely used by safety and security critical
systems developers. In safety-critical systems, the risks are hazards that can result
in accidents; in security-critical systems, the risks are vulnerabilities that can lead to
a succt:ssful attack on a system.

Requirements validation

Requirements validation is concerned with showing that the requirements actually
define the system that the customer wants. Requirements validation overlaps
analysis in that it is concerned with finding problems with the requirements.
Requirements validation is important because errors in a requirements document
can lead to extensive rework costs when they are discovered during development
or after the system is in service. The cost of fixing a requirements problem by
making a system change is much greater than repairing design or coding errors.
The reason for this is that a change to the requirements usually means that the
system design and implementation must also be changed and then the system must
be tested again.
During the requirements validation process, checks should be carried out on the
requirements in the requirements document. These checks include:
1. Validity checks A user may think that a system is needed to perform certain
functions. However, further thought and analysis may identify additional or different
functions that are required. Systems havf: diverse stakeholders with distinct
needs, and any set of requirements is inevitably a compromise across the
stakeholder community.
2. Consistency checks Requirements in the document should not conflict. That is,
there should be no contradictory constraints or descriptions of the same system
function.
3. Completeness checks The requirements document should include requirements,
which define all functions, and constraints intended by the system user.
4. Realism checks Using knowledgt: of existing technology, the requirements should
be checked to ensure that they could actually be implemented. These checks
should also take account of the budget and schedule for the system developmen':.
5. Verifiability To reduce the potential for dispute between customer and contractor,
systt:m requirements should always be written so that they are verifiable. This
means that you should be able to write a set of tests that can demonstrate that
the delivered system meets each specified requirement.
A number of requirements validation techniques can be used in conjunction or
individually:
1. Requirements reviews The requirements are analysed systematically by a team
of reviewers. This process is discussed in the following section.
2. ProfOtyping In this approach to validation, an executable model of the system
is demonstrated to end-users and customers. They can experiment with this model
to see if it meets their real needs.
3. Test-case generation Requirements should be testable. If the tests for the
requirements are devised as part of the validation process, this often reveals
reqUirements problems. If a test is difficult or impossible to design, this usually
means that the requirements will be difficult to implement and should be
reconsidered. Developing tests from the user requirements before any code is
written is an integral part of extreme programming.
You should not underestimate the problems of r,equirements validation. It is difficult
to show that a set of requirements meets a user s needs. Users must picture
the system in operation and imagine how that system would fit into their work. It
is hard for skilled computer professionals to perform this type of abstract analysis
and even harder for system users. As a result, you rarely find all requirements problems
during the requirements validation process. It is inevitable that there will be
further requirements changes to correct omissions and misunderstandings after the
requirements document has been agreed upon.

Requirements reviews

A requirements review is a manual process that involves people from both client
and contractor organisations. They check the requirements document for anomalies
and omissions. The review process may be managed in the same way as program
inspectionsAlternatively, it may be organised as a broader activity
with different people checking different parts of the document.
Requirements reviews can be informal or formal. Informal reviews simply
involve contractors discussing requirements with as many system stakeholders as
possible. It is surprising how often communication between system developers and
stakeholders ends after elicitation and there is no confirmation that the documented
requirements are what the stakeholders really said they wanted. Many problems can
be detected simply by talking about the system to stakeholders before making a commitment
to a formal review.
In a formal requirements review, the development team should 'walk' the client
through the system requirements, explaining the implications of each requirement.
The review team should check each requirement for consistency as well as check
the requirements as a whole for completeness. Reviewers may also check for:
1. Verifiability Is the requirement as stated realistically testable?
2. Comprehensibility Do the procurers or end-users of the system properly understand
the requirement?
3. Traceability Is the origin of the requirement clearly stated? You may have to
go back to the source of the requirement to assess the impact of a change
Traceability is important as it allows the impact of change on the rest of the
system to be assessed. I discuss it in more detail in the following section.
4. Adaptability Is the requirement adaptable? That is, can the requirement be changed
without large-scale effects on other system requirements?
Conflicts, contradictions, errors and omissions in the requirements should be pointed
out by reviewers and formally recorded in the review report. It is then up to the
users, the system procurer and the system developer to negotiate a solution to these
identified problems.

Requirements management

The requirements for large software systems are always changing. One reason for
this is that these systems are usually developed to address 'wicked' problems (as
discussed in Chapter 2). Because the problem cannot be fully defined, the software
requirements are bound to be incomplete.. During the software process, the stakeholders'
understanding of the problem is constantly changing. These requirements
must then evolve to reflect this changed problem view.
Furthermore, once a system has been installed, new requirements inevitably emerge.
It is hard for users and system customers to anticipate what effects the new system
will have on the organisation. Once end-users have experience of a system, they
discove:r new needs and priorities:
1. Large systems usually have a diverse user community where users have diffen:
nt requirements and priorities. These may be conflicting or contradictory.
The final system requirements are inevitably a compromise between them and,
with experience, it is often discovered. that the balance of support given to diffen:
nt users has to be changed.
2. The people who pay for a system and the users of a system are rarely the same pe0ple.
System customers impose requirements because of organisational and budgetary
constraints. These may conflict with end-user requirements and, after delivery, new
features may have to be added for user support if the system is to meet its goals.
3. The business and technical envimnment of the system changes after installation, and
these changes must be reflected in the system. New hardware may be introduced,
it may be necessary to interface the system with other systems, business priorities
may change with consequent changes in the system support, and new legislation
and regulations may be introducl~ which must be implemented by the system.
Requirements management is the process of understanding and controlling
changes to system requirements. You need to keep track of individual requirements
and maintain links between dependent requirements so that you can assess the impact
of requirements changes. You need to establish a formal process for making change
proposals and linking these to system requirements. The process of requirements
management should start as soon as a draft version of the requirements document
is available, but you should start planning how to manage changing requirements
during the requirements elicitation process.

Requirements management planning

Planning is an essential first stage in the requirements management process.
Requirements management is very expensive. For each project, the planning stage
establishes the level of requirements management detail that is required. During the
requirements management stage, you have to decide on:
1. Requirements identification Each requirement must be uniquely identified so
that it can be cross-referenced by other requirements and so that it may be used
in traceability assessments.
2. A change management process This is the set of activities that assess the
impact and cost of changes. I discuss this process in more detail in the following
section.
3. Traceability policies These policies define the relationships between requirements,
and between the requirements and the system design that should be
recorded and how these records should be maintained.
4. CASE tool support Requirements management involves the processing of large
amounts of infonnation about the requirements. Tools that may be used range
from specialist requirements management systems to spreadsheets and simple
database systems.
There are many relationships among requirements and between the requirements
and the system design. There are also links between requirements and the underlying
reasons why these requirements were proposed. When changes are proposed,
you have to trace the impact of these changes on other requirements and the system
design. Traceability is the property of a requirements specification that reflects
the ease of finding related requirements.
There are three types of traceability infonnation that may be maintained:
1. Source traceability infonnation links the requirements to the stakeholders who
proposed the requirements and to the rationale for these requirements. When a
change is proposed, you use this infonnation to find and consult the stakeholders
about the change.
2. Requirements traceability infonnation links dependent requirements within the
requirements document. You use this infonnation to assess how many requirements
are likely to be affected by a proposed change and the extent of consequential
requirements changes that may be necessary.
3. Design traceability infonnation links the requirements to the design modules
where these requirements are implemented. You use this infonnation to assess
the impact of proposed requirements changes on the system design and implementation.
Traceability infonnation is often represented using traceability matrices, which
relate requirements to stakeholders, each other or design modules. In a requirements
traceability matrix, each requirement is entered in a row and in a column in the
matrix. Where dependencies between different requirements exist, these are
recorded in the cell at the row/column intersection.
Requirements management needs automated support; the CASE tools for this should
be chosf:n during the planning phase. You need tool support for:
l. Requirements storage The requirements should be maintained in a secure, managed
data store that is accessible to everyone involved in the requirements engineering
process.
2. Change management The process of change management (Figure 7.13) is simplified
if active tool support is available.
3. Traceability management As discussed above, tC101 support for traceability allows
related requirements to be discovered. Some Itools use natural language processing
techniques to help you discover possible relationships between the
requirements..
For small systems, it may not be necessary to use specialised requirements management
tools. The requirements management process may be supported using the
facilities availablt: in word processors, spreadsheet.s and PC databases. However,
for larger systems, more specialised tool support is required. I have included links
to infonnation about requirements management tools such as DOORS and
Requisitf:Pro in the book's web pages.

Requirements elicitation and analysis

The next stage of the requirements engineering process is requirements elicitation
and analysis. In this activity, software engineers work with customers and system
end-users to find out about the application domain, what services the system should
provide, the required performance of the system, hardware constraints, and so on.
Requirements elicitation and analysis may involve a variety of people in an organisation.
The term stakeholder is used to refer to any person or group who will be affected
by the system, directly or indirectly. Stakeholders include end-users who interact with
the system and everyone else in an organisation that may be affected by its installation.
Other system stakeholders may be engineers who are developing or maintaining
related systems, business managers, domain experts and trade union representatives.
Eliciting and understanding stakeholder requirements is difficult for several reasons:
I. Stakeholders often don't know what they want from the computer system except
in the most general terms. They may find it difficult to articulate what they
want the system to do or make unrealistic demands because they are unaware
of the cost of their requests.
2. Stakeholders naturally express requirements in their own terms and with
implicit knowledge of their own work. Requirements engineers, without experience
in the customer's domain, must understand these requirements.
3. Different stakeholders have different requirements, which they may express in
different ways. Requirements engineers have to consider all potential sources
of requirements and discover commonalities and conflict.
4. Political factors may influence the requirements of the system. For example,
managers may demand specific system requirements that will increase their influence
in the organisation.
5. The economic and business environment in which the analysis takes place is
dynamic. It inevitably changes during the analysis process. Hence the importance
of particular requirements may change. New requirements may emerge
from new stakeholders who were not originally consulted.general model, depending on local factors such as the expertise of the staff, the type
of system being developed and the standards used. Again, you can think of these
activities within a spiral so that the activities are: interleaved as the process proceeds
from the lOner to the outer rings of the spiral.
The process activities are:
1. Requirements discovery This is the process of interacting with stakeholders in
the system to collect their requirements. Domain requin:ments from stakeholders
and documentation are also discovered during this activity.
2. Requirements classijication and organisation This activity takes the unstructured
collection of requirements, groups related requirements and organises them
into coherent clusters.
3. Requirements prioritisation and negotiation Inevitably, where multiple stakeholders
are involved, requirements will conflict. This a,ctivity is concerned with
pnonusmg requirements, and finding and resolving requirements conflicts
through negotiation.
4. Requirements documentation The requirements are documented and input into
the next round of the spiral. Formal or informal requirements documents may
be produced.

Requirements discovery

Requirements discovery is the process of gathering information about the proposed
and existing systems and distilling the user and system requirements from this information.
Sources of information during the requirements discovery phase include documentation,
system stakeholders and specifications of similar systems. You interact
with stakeholders through interviews and observation, and may use scenarios and
prototypes to help with the requirements discovery. In this section, I discuss an
approach that helps ensure you get broad stakeholder coverage when discovering
requirements, and I describe techniques of requirements discovery including interviewing,
scenarios and ethnography. Other requirements discovery techniques thatStakeholders range from system end-users through managers and external stakeholders
such as regulators who certify the acceptability of the system. For example,
system stakeholders for a bank ATM include:
I. Current bank customers who receive services from the system
2. Representatives from other banks who have reciprocal agreements that allow
each other's ATMs to be used
3. Managers ofbank branches who obtain managemc~nt information from the system
4. Counter staff at bank branches who are involved in the day-to-day running of
the system
5. Database administrators who are responsible for integrating the system with
the b,mk's customer database
6. Bank security managers who must ensure that the system will not pose a security
hazard
7. The bank's marketing department who are likely be interested in using the system
as a means of marketing the bank
8. Hardware and software maintenance engineers who are responsible for maintaining
and upgrading the hardware and software
9. National banking regulators who are responsible for ensuring that the system
conforms to banking regulations
In addition to system stakeholders" we have already seen that requirements may
come from the application domain and from other systems that interact with the
system being specified. All of these must be considered during the requirements
elicitation process.
These requirements sources (stakeholders, domain, systems) can all be represented
as system viewpoints, where each viewpoint presents a sub-set of the requirements
for the system. Each viewpoint provides a fresh perspective on the system, but these
perspectivl~s are not completely indep<:ndent--they usually overlap so that they have
<;ommon requirements.
Viewpoil1lts
Viewpoint-oriented approaches to requirements I~ngineering (Mullery, 1979;
Finkelstein et al., 1992; Kotonya and Sommerville, 1992; Kotonya and Sommerville,
1996) organise both the elicitation proct:ss and the requirements themselves using viewpoints.
Akey strength of viewpoint-oriented analysis is that it recognises multiple perspectives
and provides a framework for discovering confliicts in the requirements proposed
by different stakeholders.Viewpoints can be used as a way of classifying stakeholders and other sources
of requirements. There are three generic types of viewpoint:
1. Interactor viewpoints represent people or other systems that interact directly
with the system. In the bank ATM system, examples of interactor viewpoints
are the bank's customers and the bank's account database.
2. Indirect viewpoints represent stakeholders who do not use the system themselves
but who influence the requirements in some way. In the bank ATM system,
examples of indirect viewpoints are the management of the bank and the bank
security staff.
3. Domain viewpoints represent domain characteristics and constraints that influence
the system requirements. In the bank ATM system, an example of a domain
viewpoint would be the standards that have been developed for interbank communications.
Typically, these viewpoints provide different types of requirements. Interactor
viewpoints provide detailed system requirements covering the system features and
interfaces. Indirect viewpoints are more likely to provide higher-level organisational
requirements and constraints. Domain viewpoints normally provide domain constraints
that apply to the system.
The initial identification of viewpoints that are relevant to a system can sometimes
be difficult. To help with this process, you should try to identify more specific
viewpoint types:
l. Providers of services to the system and receivers of system services
2. Systems that should interface directly with the system being specified
3. Regulations and standards that apply to the system
4. The sources of system business and non-functional requirements
5. Engineering viewpoints reflecting the requirements of people who have to develop,
manage and maintain the system
6. Marketing and other viewpoints that generate requirements on the product features
expected by customers and how the system should reflect the external image
of the organisation
Almost all organisational systems must interoperate with other systems in the
organisation. When a new system is planned, the interactions with other systems
must be planned. The interfaces offered by these other systems have already been
designed. These may place requirements and constraints on the new system.
Furthermore, new systems may have to conform to existing regulations and standards,
and these constrain the system requirements.

Interviewing
Formal or informal interviews with system stakeholders are part of most requirements
engineering processes. In these interviews, the requirements engineering team puts
questions to stakeholders about the system that they use and the system to be develped.
Requirements are derived from the answers to these questions. Interviews may
be of two types:
1. Closed interviews where the stakeholder answers a predefined set of questions.
2. Open interviews where there is no predefined agenda. The requirements engineering
team explores a range of issues with system stakeholders and hence
develops a better understanding of their needs.
In practice, interviews with stakeholders are normally a mix of these. Th
answers to some questions may lead to other issues that are discussed in a less structured
way. Completely open-ended discussions rarely work well; most interviews
require some questions to get started and to keep the interview focused on the system
to be developed.
Interviews are good for getting an overall understanding of what stakeholders
do, how they might interact with the system and the difficulties that they face with
current systems. People like talking about their work and are usually happy to get
involved in interviews. However, interviews are not so good for understanding the
requirements from the application domain.
It is hard to elicit domain knowledge during interviews for two reasons:
1. All application specialists use terminology and jargon that is specific to a domain.
It is impossible for them to discuss domain requirements without using this terminology.
They normally use terminology in a precise and subtle way that is
easy for requirements engineers to misunderstand.
2. Some domain knowledge is so familiar to stakeholders that they either find it
difficult to explain or they think it is so fundamental that it isn't worth mentioning.
For example, for a librarian, it goes without saying that all acquisitions
are catalogued before they are added to the library. However, this may not be
obvious to the interviewer so it isn't taken into account in the requirements.
Interviews are not an effective technique for eliciting knowledge about organisational
requirements and constraints because there are subtle power and influence
relationships between the stakeholders in the organisation. Published organisational
structures rarely match the reality of decision making in an organisation, but
interviewees may not wish to reveal the actual rather than the theoretical structure
to a stranger. In general, most people are reluctant to discuss political and organisational
issues that may affect the requirements.
Effective interviewers have two characteristics:
I. They are open-minded, avoid preconceived ideas about the requirements and
are willing to listen to stakeholders. If the stakeholder comes up with surprising
requirements, they are willing to change their mind about the system.
2. They prompt the interviewee to start discussions with a question, a requirements
proposal or by suggesting working together on a prototype system. Saying to
people 'tell me what you want' is unlikely to result in useful information. Most
people find it much easier to talk in a defined context rather than in general
terms.
Information from interviews supplements other information about the system
from documents, user observations, and so on. Sometimes, apart from information
from documents, interviews may be the only source of information about the
system requirements. However, interviewing on its own is liable to miss essential
information, so it should be used alongside other requirements elicitation
techniques.
Scenarios
People usually find it easier to relate to real-life examples than to abstract descriptions.
They can understand and critique a scenario of how they might interact with
a software system, Requirements engineers can use the information gained from this
discussion to formulate the actual system requirements.
Scenanos can be particularly useful for adding detail to an outline requirements
description. They are descriptions of example interaction sessions. Each scenario
covers one or more possible interactions. Several fonns of scenarios have been developed,
ea,~h of which provides different types of information at different levels of
detail about the system. Using scenarios to describe requirements is an integral part
of agile methods, such as extreme programming, that I discuss in Chapter 17.
The scenario starts with an outline of the interaction, and, during elicitation, details
are added to create a complete description of that interaction. At its most general,
a scenano may include:
I. A description of what the system and users expect when the scenario starts
2. A description of the normal flow of events in the scenario
3, A description of what can go wrong and how this is handled
4. Information about other activities that might be going on at the same time
5. A description of the system state when the sCf:nario finishes.

Use-cases
Use-cases are a scenario-based technique for requirements elicitation which were
first introduced in the Objectory method (Jacobsen, et al., 1993). They have nowbecome a fundamental feature of the UML notation for describing object-oriented
system models. In their simplest form, a use-case lldentifies the type of interaction
and the actors involved. For example, Figure 7.6 shows the high-level use-case of
the article printing facility in LIBSYS

Requirements change management

Requirements change management requirements document and, if appropriate, to the system design and implementation.
Once this analysis is completed, a decision is made whether to proceed
with the requirements change.
3. Change implementation The requirements document and, where necessary, the
system design and implementation are modified. You should organise the
requirements document so that you can make changes to it without extensive
rewriting or reorganisation. As with programs, changeability in documents is
achieved by minimising external references and making the document sections
as modular as possible. Thus, individual sections can be changed and replaced
without affecting other parts of the document. should be applied to all proposed
changes to the requirements. The advantage of using a formal process for change
management is that all change proposals are treated consistently and that changes
to the requirements document are made in a controlled way. There are three principal
stages to a change management process:
1. Problem analysis and change specification Th\~ process starts with an identified
lequirements problem or, sometimes, with a specific change proposal. During
this stage, the problem or the change proposal is analysed to check that it is
valid. The results of the analysis are fed back to the change requestor, and sometimes
a more specific requirements change proposal is then made.
2. Change analysis and costing The effect of the proposed change is assessed using
traceability information and general knowledge of the system requirements. The
cost of making the change is estimated in terms of modifications to the requirements document. This almost inevitably leads to the requirements specification
and the system implementation getting out of step. Once system changes have
been made, requirements document changes may be forgotten or made in a way that
is not consistent with the system changes.
Iterative development processes, such as extreme programming, have been
designed to cope with requirements that change during the development process.
In these processes, when a user proposes a requirements change, this does not go
through a formal change management process. Rather, the user has to prioritise that
change and, if it is high priority, decide what system features that were planned for
the next iteration should be dropped.

KEY POINTS
1111II·
The requirements engineering process includes a feasibility study, requirements elicitation
and analysis, requirements specification, requirements validation and requirements
management.
Requirements elicitation and analysis is an iterative process that can be represented as a
spiral of activities - requirements discovery, requirements classification and organisation,
requirements negotiation and requirements documentation.
Different stakeholders in the system have different requirements. All complex systems
should therefore be analysed from a number of viewpoints. Viewpoints can be people or
other systems that interact with the system being specified, stakeholders who are affected
by the system, or domain viewpoints that constrain the requirements.
Social and organisational factors have a strong influence on system requirements and may
determine whether the software is actually used.
Requirements validation is the process of checking the requirements for validity,
consistency, completeness, realism and verifiability. Requirements reviews and prototyping
are the principal techniques used for requirements validation.
Business, organisational and technical changes inevitably lead to changes to the
requirements for a software system. Requirements management is the process of managing
and controlling these changes.
The requirements management process includes management planning, where policies and
procedures for requirements management are designed, and change management, where
you analyse proposed requirements changes and assess their impact.

Professional and ethical responsibility

Like other engineering disciplines, software engineering is carried out within a legal
and social framework that limits the freedom of engineers. Software engineers must
accept that their job involves wider responsibilities than simply the application of
technical skills. They must also behave in an ethical and morally responsible way
if they are to be respected as professionals.
It goes without saying that you should always uphold normal standards of honesty
and integrity. You should not use your skills and abilities to behave in a dishonest
way or in a way that will bring disrepute to the software engineering profession. However,
there are areas where standards of acceptable behaviour are not bounded by laws but
by the more tenuous notion of professional responsibility. Some of these are:
1. Confidentiality You should normally respect the confidentiality of your
employers or clients irrespective of whether a formal confidentiality agreement
has been signed.
2. Competence You should not misrepresent your level of competence. You
should not knowingly accept work that is outside your competence.
3. Intellectual property rights You should be aware of local laws governing the
use of intellectual property such as patents and copyright. You should be careful
to ensure that the intellectual property of employers and clients is protected.
4. Computer misuse You should not use your technical skills to misuse other people's
computers. Computer misuse ranges from relatively trivial (game playing
on an employer s machine, say) to extremely serious (dissemination of viruses).
Professional societies and institutions have an important role to play in setting
ethical standards. Organisations such as the ACM, the IEEE (Institute of Electrical
and Electronic Engineers) and the British Computer Society publish a code of professional
conduct or code of ethics. Members of these organisations undertake to
follow that code when they sign up for membership. These codes of conduct are
generally concerned with fundamental ethical behaviour.
The ACM and the IEEE have cooperated to produce a joint code of ethics and
professional practice. This code exists in both a short form,
and a longer form (Gotterbam, et al., 1999) that adds detail and substance to the shorter version. The rationale behind this code is summarised in the first two paragraphs
of the longer form:
------------------------------------------------------------------------------
Computers have a central and growing role in commerce, industry, government,
medicine, education, entertainment and society at large. Software engineers are
those who contribute by direct participation or by teaching, to the analysis, spe ification,
design, development, certification, maintenance and testing ofsoftware
systems. Because of their roles in developing software systems, software engineers
have significant opportunities to do good or cause harm, to enable others
to do good or cause harm, or to influence others to do good or cause harm. To
ensure, as much as possible. thaI their efforts will be used for good, software
engineers must commit themselves to making software engineering a beneficial
and respected profession. In accordance with that commitment, software engineers
shall adhere to the following Code of Ethics and Professional Practice.
The Code contains eight Principles relau,d to the behaviour ofand decisions
made by professional software engineers, including practitioners, educators,
managers, supervisors and policy makers, as well as trainees and students of
Computers have a central and growing role in commerce, industry, government,
medicine, education, entertainment and society at large. Software engineers are
those who contribute by direct participation or by teaching, to the analysis, spe ification,
design, development, certification, maintenance and testing ofsoftware
systems. Because of their roles in developing software systems, software engineers
have significant opportunities to do good or cause harm, to enable others
to do good or cause harm, or to influence others to do good or cause harm. To
ensure, as much as possible. thaI their efforts will be used for good, software
engineers must commit themselves to making software engineering a beneficial
and respected profession. In accordance with that commitment, software engineers
shall adhere to the following Code of Ethics and Professional Practice.
The Code contains eight Principles relau,d to the behaviour ofand decisions
made by professional software engineers, including practitioners, educators,
managers, supervisors and policy makers, as well as trainees and students of
ltroduction
the profession. The Principles identify the ethically responsible relationships
in which individuals, groups, and organizations participate and the primary
obligations within these relationships. The Clauses ofeach Principle are illustrations
ofsome ofthe obligations included in these relationships. These obligations
are founded in the software engineer's humanity, in special care owed
to people affected by the work ofsoftware engineers. and the unique elements
of the practice of software engineering. The Code prescribes these as obligations
of anyone claiming to be or aspiring to be a software engineer.
------------------------------------------------------------------------------

In any situation where different people have different views and objectives, you
are likely to be faced with ethical dilemmas. For example, if you disagree, in principle,
with the policies of more senior management in the company, how should
you react? Clearly, this depends on the particular individuals and the nature of the
disagreement. Is it best to argue a case for your position from within the organisation
or to resign in principle? If you feel that there are problems with a software
project, when do you reveal these to management? If you discuss these while they
are just a suspicion, you may be overreacting to a situation; if you leave it too late,
it may be impossible to resolve the difficulties.
Such ethical dilemmas face all of us in our professional lives and, fortunately,
in most cases they are either relatively minor or can be resolved without too much
difficulty. Where they cannot be resolved, the engineer is faced with, perhaps, another
problem. The principled action may be to resign from their job, but this may well
affect others such as their partner or their children.
A particularly difficult situation for professional engineers arises when their
employer acts in an unethical way. Say a company is responsible for developing a
safety-critical system and because of time-pressure, falsifies the safety validation
records. Is the engineer s responsibility to maintain confidentiality or to alert the
customer or publicise, in some way, that the delivered system may be unsafe?
The problem here is that there are no absolutes when it comes to safety. Although
the system may not have been validated according to predefined criteria, these criteria
may be too strict. The system may actually operate safely throughout its lifetime.
It is also the case that, even when properly validated, a system may fail and cause an
accident. Early disclosure of problems may result in damage to the employer and other
employees; failure to disclose problems may result in damage to others.
You must make up your own mind in these matters. The appropriate ethical position
here depends entirely on the views of the individuals who are involved. In this
case, the potential for damage, the extent of the damage and the people affected by
the damage should influence the decision. If the situation is very dangerous, it may
be justified to publicise it using the national press (say). However, you should always
try to resolve the situation while respecting the rights of your employer.
Another ethical issue is participation in the development of military and nuclear
systems. Some people feel strongly about these issues and do not wish to participate
in any systems development associated with military systems. Others will work on military
systems but not on weapons systems. Yet others feel that national security is an
overriding principle and have no ethical objections to working on weapons systems.

In this situation it is important that both employers and employees should make
their views known to each other in advance. Where an organisation is involved in
military or nuclear work, it should be able to specify that employees must be willing
to accept any work assignment. Equally, if an employee is taken on and makes
clear that he does not wish to work on such systems, employers should not put pressure
OI, him to do so at some later date.
Tht: general area of ethics and professional responsibility is one that has
received increasing attention over the past few years. It can be considered from a
philosophical standpoint where the basic principles of ethics are considered, and
software engineering ethics are di,cussed with reference to these basic principles.
This is the approach taken by Laudon (Laudon, 1995) and to a lesser extent by Huff
and Martin (Huff and Martin, 1995).
However, I find their approach is too abstract and difficult to relate to everyday
experience. I prefer the more concrete approach embodied in codes of conduct and
practice. I think that ethics are best discussed in a software engineering context and
not as ;l subject in their own right. In this book, therefore, I do not include abstract
ethical. discussions but, where appropriate, include examples in the exercises that
can be: the starting point for a group discussion on ethical issues.

Object models

An object-oriented approach to the whole software development process is now
commonly used, particularly for interactive systems development. This means expressing
the systems requirements using an object model, designing using objects anddeveloping the system in an object-oriented programming language such as Java
or C++.
Object models that you develop during requirements analysis may be used
to represent both system data and its processing. In this respect. they combine
some of the uses of data-flow and semantic data models. They are also useful
for showing how entities in the system may be classified and composed of other
entities.
For some classes of system. object models are natural ways of reflecting the realworld
entities that are manipulated by the system. This is particularly true when the
system processes information about tangible entities. such as cars. aircraft or books.
which have clearly identifiable attributes. More abstract. higher-level entities, such
as the concept of a library. a medical record system or a word processor, are harder
to model as object classes. They do not necessarily have a simple interface consisting
of independent attributes and operations.
Developing object models during requirements analysis usually simplifies the transition
to object-oriented design and programming. However. I have found that endusers
of a system often find object models unnatural and difficult to understand.
They may prefer to adopt a more functional, data-processing view. Therefore. it is
sometimes helpful to supplement object models with data-flow models that show
the end-to-end data processing in the system.
An object class is an abstraction over a set of objects that identifies common
attributes (as in a semantic data model) and the services or operations that are provided
by each object. Objects are executable entities with the attributes and services
of the object class. Objects are instantiations of the object class, and many
objects may be created from a class. Generally, the models developed using analysis
focus on object classes and their relationships.
In object-oriented requirements analysis, you should model real-world entities
using object classes. You should not include details of the individual objects
(instantiations of the class) in the system. You may create different types of object
models, showing how object classes are related to each other, how objects, are aggregated
to form other objects. how objects interact with other objects and so on. These
each present unique information about the system that is being specified.The analysis process for identifying objects and object classes is recognised as
one of the most difficult areas of object-oriented development. Object identification
is basically the same for analysis and design. The methods of object identification
covered in Chapter 14. which discusses object-oriented design, may be used.
I concentrate here on some of the object models that might be generated during the
analysis process.
Various methods of object-oriented analysis were proposed in the 1990s (Coad and
Yourdon. 1990; Rumbaugh, et al., 1991; Jacobsen, et aI., 1993; Booch, 1994). These
methods had a great deaI in common, and three of the key developers (Booch.
Rumbaugh, and Jacobsen) decided to integrate their approaches to produce a unified
method (Rumbaugh et aI., 1999b). The Unified Modeling Language (UML) used in this
unified method has become a standard for object modelling. The UML includesnotations for different types of system models. We have already seen use-case models
and sequence diagrams in earlier chapters and state machine models earlier in this chapter.
An object class in UML, as illustrated in the examples in Figure 8.10, is represented
as a vertically oriented rectangle with three sections:
I. The name of the object class is in the top section.
2. The class attributes are in the middle section.
3. The operations associated with the object class are in the lower section of the
rectangle.
I don't have space to cover all of the UML, so I focus here on object models
that show how objects can be classified and can inherit attributes and operations
from other objects, aggregation models that show how objects are composed, and
simple behavioural models, which show object interactions.