Requirements and

Specification
Learning outcome
•Requirements engineering
•Modeling types
•System Prototyping
•Formal sepcification
Requirements Engineering
• Theprocess of establishing the services that the customer requires from a system and the constraints
under which it operates and is developed.

• Therequirements themselves are the descriptions of the system services and constraints that are
generated during the requirements engineering process.

• It
may range from a high-level abstract statement of a service or of a system constraint to a detailed
mathematical functional specification.

• This is inevitable as requirements may serve a dual function:

May be the basis for a bid for a contract -therefore must be open to interpretation;
May be the basis for the contract itself -therefore must be defined in detail;
Types of Requirements
• User requirements
Statements in natural language plus diagrams of the services the system provides and
its operational constraints. Written for customers.
• System requirements
A structured document setting out detailed descriptions of the system’s functions,
services and operational constraints. Defines what should be implemented so may be
part of a contract between client and contractor.
User and System Requirements
Functional and Non-Functional
Requirements
Functional Requirements
Statements of services the system should provide, how
the system should react to particular inputs and how the
system should behave in particular situations.
May state what the system should not do.
Describe functionality or system services.
Depend on the type of software, expected users and the
type of system where the software is used.
Functional user requirements may be high-level
statements of what the system should do.
Functional system requirements should describe the
system services in detail.
Non-Functional Requirements
Constraints on the services or functions offered by the
system such as timing constraints, constraints on the
development process, standards, etc.
Often apply to the system as a whole rather than individual
features or services.
These define system properties and constraints e.g.
reliability, response time, and storage requirements.
Constraints are I/O device capability, system
representations, etc.
Process requirements may also be specified mandating a
particular IDE, programming language or development
method.
Non-functional requirements may be more critical than
functional requirements. If these are not met, the system
may be useless.
Types of Non-Functional Requirements
Non-functional requirements may affect the overall
architecture of a system rather than the individual
components.

For example, to ensure that performance requirements are

met, you may have to organize the system to minimize
communications between components.

A single non-functional requirement, such as a

security requirement, may generate a number of
related functional requirements that define system
services that are required.

It may also generate requirements that restrict existing

requirements.
Case study for MHC-PMS
Functional Requirements Non-Functional Requirements

A user shall be able to search the Product requirement

appointments lists for all clinics. The MHC-PMS shall be available to all clinics
during normal working hours (Mon–Fri, 0830–
The system shall generate each day, for 17.30). Downtime within normal working hours
each clinic, a list of patients who are shall not exceed five seconds in any one day.
expected to attend appointments that day. Organizational requirement
Users of the MHC-PMS system shall
Each staff member using the system shall authenticate themselves using their health
be uniquely identified by his or her 8-digit authority identity card.
employee number.
External requirement
The system shall implement patient privacy
provisions as set out in HStan-03-2006-priv.
Use-Case Diagram for MHC-PMS
Use-cases are a scenario based technique in the
UML which identify the actors in an interaction and
which describe the interaction itself.

A set of use cases should describe all possible

interactions with the system.

High-level graphical model supplemented by more

detailed tabular description (see Chapter 5).

Sequence diagrams may be used to add detail to

use-cases by showing the sequence of event
processing in the system.
Goals and Requirements
Non-functional requirements may be very difficult
to state precisely and imprecise requirements may
be difficult to verify.
Example
The system should be easy to use by medical staff
Goal and should be organized in such a way that user
A general intention of the user such as ease of use. errors are minimized. (Goal)

Verifiable non-functional requirement Medical staff shall be able to use all the system
A statement using some measure that can be objectively functions after four hours of training. After this training,
tested. the average number of errors made by experienced
users shall not exceed two per hour of system use.
Goals are helpful to developers as they convey the (Testable non-functional requirement)
intentions of the system users.
Non-Functional Requirements Metrics
 Domain Requirements
• Domain requirements Problems of Domain Requirements
•The system’s operational domain (constraints) imposes requirements
on the system. Understandability
Requirements are expressed in the language of the
For example, a train control system has to take into account the braking application domain;
characteristics in different weather conditions.
This is often not understood by software engineers
•Domain requirements can be new functional requirements, constraints developing the system.
on existing requirements, or define specific computations.
Implicitness
• If domain requirements are not satisfied, the system may be Domain specialists understand the area so well
unworkable. that they do not think of making the domain
requirements explicit.
Requirements Specification
The process of writing down the user and system requirements in a requirements
document
User requirements have to be understandable by end-users and customers who do
not have a technical background
System requirements are more detailed requirements and may include more technical
information
The requirements may be part of a contract for the system development
It is therefore important that these are as complete as possible
Ways to write Requirements
Specification
Guideline
Create a standard format and use it for all
requirements.

Use language in a consistent way. Use

shall for mandatory requirements, should for
desirable requirements.

Use text highlighting to identify key parts

of the requirement.

Avoid the use of computer jargon.

Includean explanation (rationale) of why a

requirement is necessary.
Requirements and Design
 In principle, requirements should state what the system should do and the
design should describe how it does this.

 In practice, requirements and design are inseparable

A system architecture may be designed to structure the requirements;
The system may inter-operate with other systems that generate design requirements;
The use of a specific architecture to satisfy non-functional requirements may be a domain
requirement.

This may be the consequence of a regulatory requirement.

 Natural Language Specification
Natural Language Problems
Requirements are written as natural Lack of clarity
language sentences supplemented by Precision is difficult without making the document difficult to read.
diagrams and tables.
Requirements confusion
Used for writing requirements because it Functional and non-functional requirements tend to be mixed-up.
is expressive, intuitive and universal. This
means that the requirements can be Requirements amalgamation
understood by users and customers. Several different requirements may be expressed together.

Examples
 Insulin Pump (Example)

Structured Specification
 An approach to writing requirements where the
freedom of the requirements writer is limited and
requirements are written in a standard way.

 This works well for some types of requirements e.g.

requirements for embedded control system but is
sometimes too rigid for writing business system
requirements.
 Tabular Specification
Computation for Insulin Pump (Example)

 Used to supplement natural language

 Particularly useful when you have to define a number of

possible alternative courses of action

 For example, the insulin pump systems bases its

computations on the rate of change of blood sugar level
and the tabular specification explains how to calculate the
insulin requirement for different scenarios
Process of Requirement Engineering
Typical Users
The software requirements document is the official
statement of what is required of the system
developers.

Can include both a definition of user requirements

and a specification of the system requirements.

Itis NOT a design document. As far as possible, it

should set of WHAT the system should do rather
than HOW it should do it.
Structure of Requirements Document
 Stakeholders in the MHC-PMS
 Patients whose information is recorded in the system.
 Doctors who are responsible for assessing and treating patients.
 Nurses who coordinate the consultations with doctors and administer some treatments.
 Medical receptionists who manage patients’ appointments.
 IT staff who are responsible for installing and maintaining the system.
 A medical ethics manager who must ensure that the system meets current ethical guidelines for patient
care.
 Health care managers who obtain management information from the system.
 Medical records staff who are responsible for ensuring that system information can be maintained and
preserved, and that record keeping procedures have been properly implemented.
 Interview Scenario Ethnography
Formal or informal interviews with stakeholders are part Scenarios are real-life examples of A social scientist spends a considerable time
of most RE processes. how a system can be used. observing and analysing how people actually work.

Types of interview They should include People do not have to explain or articulate their
Closed interviews based on pre-determined list of questions A description of the starting situation; work.
Open interviews where various issues are explored with A description of the normal flow of events;
stakeholders. A description of what can go wrong; Social and organisational factors of importance
Information about other concurrent may be observed.
Effective interviewing activities;
Be open-minded, avoid pre-conceived ideas about the A description of the state when the scenario Ethnographic studies have shown that work is
requirements and are willing to listen to stakeholders. finishes. usually richer and more complex than suggested by
Prompt the interviewee to get discussions going using a simple system models.
springboard question, a requirements proposal, or by working
together on a prototype system. Ethnography is effective for understanding existing
processes but cannot identify new features that
 Normally a mix of closed and open-ended interviewing. should be added to a system.

 Interviews are good for getting an overall understanding of what

stakeholders do and how they might interact with the system.

 Interviews are not good for understanding domain requirements

Requirements engineers cannot understand specific domain
terminology;
Some domain knowledge is so familiar that people find it hard to
articulate or think that it isn’t worth articulating.
Requirements Validation Techniques
Requirements reviews
Systematic manual analysis of the requirements.

Regular reviews should be held while the requirements definition is being formulated.
Both client and contractor staff should be involved in reviews.
Reviews may be formal (with completed documents) or informal. Good communications between developers,
customers and users can resolve problems at an early stage.

Prototyping

Using an executable model of the system to check requirements. Covered in Chapter 2.

Test-case generation
Developing tests for requirements to check testability.
Requirements Management
Requirements management is the process of managing changing requirements during the requirements
engineering process and system development.

New requirements emerge as a system is being developed and after it has gone into use.

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.
Changing Requirements
The business and technical environment of the system always changes after installation.
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 required), and new legislation and
regulations may be introduced that the system must necessarily abide by.

The people who pay for a system and the users of that system are rarely the same people.
System customers impose requirements because of organizational 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.

Large systems usually have a diverse user community, with many users having different
requirements and priorities that 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 different users has to be changed.
 Requirements Change Management
Deciding if a requirements change should be
accepted
Problem analysis and change specification
During this stage, the problem or the change proposal is analyzed to
check that it is valid. This analysis is fed back to the change requestor
who may respond with a more specific requirements change proposal,
or decide to withdraw the request.
Change analysis and costing
The effect of the proposed change is assessed using traceability
information and general knowledge of the system requirements. Once
this analysis is completed, a decision is made whether or not to
proceed with the requirements change.
Change implementation
The requirements document and, where necessary, the system
design and implementation, are modified. Ideally, the document should
be organized so that changes can be easily implemented.
Requirements management decisions:
Requirements identificationEach requirement must be
uniquely identified so that it can be cross-referenced with
other requirements.
A change management processThis is the set of activities
that assess the impact and cost of changes. I discuss this
process in more detail in the following section.
Traceability policiesThese policies define the relationships
between each requirement and between the requirements
and the system design that should be recorded.
Tool supportTools that may be used range from specialist
requirements management systems to spreadsheets and
simple database systems.
System Modelling
•System modelling helps the analyst to understand the functionality of the system and models are
used to communicate with customers.
•Different models present the system from different perspectives
External perspective showing the system’s context or environment
Behavioural perspective showing the behaviour of the system
Structural perspective showing the system or data architecture
 Modeling Types
•Data processing model showing how the data is processed at
different stages.
•Composition model showing how entities are composed of
other entities.
•Architectural model showing principal sub-systems.
•Classification model showing how entities have common
characteristics.
•Stimulus/response model showing the system’s reaction to
events.
Context Model
ATM (Example)
•Context models are used to illustrate the operational
context of a system -they show what lies outside the
system boundaries.

•Social
and organisational concerns may affect the decision
on where to position system boundaries.

•Architectural models show the system and its relationship

with other systems.
Process Model

•Process models show the overall process and the

processes that are supported by the system.

•Data flow models may be used to show the

processes and the flow of information from one
process to another.
 Behavioural Models
•Behavioural models are used to describe the overall behaviour
of a system.
•Two types of behavioural model are:
Data processing models that show how data is processed as it
moves through the system;
State machine models that show the systems response to
events.
•These models show different perspectives so both of them are
required to describe the system’s behaviour.
Data Processing Models
•These show the processing steps as data flows
through a system.
•Simple and intuitive notation that customers
can understand.
•Show end-to-end processing of data.
State Machine Models
•These model the behaviour of the system in response to
external and internal events:
states as nodes and events as arcs between these nodes
when an event occurs, the system moves from one state to
another => they show the system’s responses to stimuli
•They are often used for modelling real-time systems.
•State charts are an integral part of the UML and are used to
represent state machine models.
 Data Flow Diagram (DFD)
•DFDs model the system from a functional perspective.

They are an intrinsic part of many analysis methods.

•Tracking and documenting how the data associated with a process is helpful to develop an overall understanding of the system.

•DFDs may be used:

to model the system’s data processing
in showing the data exchange between a system and other systems in its environment

Insulin Pump
(Example)
Microwave Oven Model (State Machine
Model Example)
State Charts

•State
Charts allow the decomposition of a model into
sub-models

A brief description of the actions is included

following the “do” in each state

•Can be complemented by tables describing the states

and the stimuli

Microwave Oven Operation (Example)

Data Dictionaries
•Data dictionaries are lists of all of the names used in the system models. Descriptions of the entities, relationships and attributes are also
included.

•Advantages

Support name management and avoid duplication

Store of organisational knowledge linking analysis, design and implementation

•Many CASE workbenches support data dictionaries.

Object Models
•Natural ways of reflecting the real-world entities manipulated by the system
•More abstract entities are more difficult to model using this approach
•Object models describe the system in terms of object classes and their associations.
An object class is an abstraction over a set of objects with common attributes and the services
(operations) provided by each object.
•Various object models may be produced
Inheritance models
Aggregation models
Interaction models
Unified Modelling Language (UML)
Class Hierarchy
Multiple Inheritance
•Rather than inheriting the attributes and services from
a single parent class, a system which supports multiple
inheritance allows object classes to inherit from several
super-classes.

•Can lead to semantic conflicts where

attributes/services with the same name in different
super-classes have different semantics

• Makes class hierarchy reorganization more complex

Objects Aggregation

•Aggregation model shows how classes which are

collections are composed of other classes.

•Similar to the part-of relationship in semantic data

models.
Objects Behaviour Modelling
•A behavioural model shows the interactions between
objects to produce some particular system behaviour
that is specified as a use-case.

•Sequencediagrams (or collaboration diagrams) in the

UML are used to model interaction between objects.
System Prototyping
•Prototyping is the rapid development of a system
•The principal use is to help customers and developers understand the requirements for the
system
Requirements elicitation
Requirements validation
•Prototyping can be considered as a risk reduction activity which reduces requirements risks
Prototyping Benefits
•Misunderstandings between software users and developers are exposed
•Missing services may be detected and confusing services may be identified
•A working system is available early in the process
•The prototype may serve as a basis for deriving a system specification
•The system can support user training and system testing
•Improved system usability
•Closer match to the system needed
•Improved design quality and / or maintainability
•Reduced overall development effort
Approaches to Prototyping
 Evolutionary Prototyping
•An approach to system development where an initial prototype is produced and
refined through a number of stages to the final system

• Must be used for systems where the specification cannot be developed in

advance e.g. AI systems and user interface systems

•Based on techniques which allow rapid system iterations

The objective of evolutionary prototyping is to deliver a working system to

end-users.

The development starts with those requirements which are best understood.
Advantages Problems
•Verification is impossible as there is no specification. Management problems
Accelerated delivery of the system
User engagement with the system Maintenance problems
•Validation means demonstrating the adequacy of the system. Contractual problems
Throw-away Prototyping
A prototype which is usually a practical implementation of the system is produced to help discover
requirements problems and then discarded. The system is then developed using some other development
process
•Used to reduce requirements risk
•The prototype is developed from an initial specification, delivered for experiment then discarded
The prototyping process starts with those requirements which are poorly understood
•The objective of throw-away prototyping is to validate or derive the system requirements.
•The throw-away prototype should NOT be considered as a final system
Some system characteristics may have been left out
There is no specification for long-term maintenance
The system will be poorly structured and difficult to maintain
Throw-away Prototyping
Problems with Throw-away Prototyping
•Developers may be pressurised to deliver a throw-away prototype as a final system
•This is not recommended
It may be impossible to tune the prototype to meet non-functional requirements
The prototype is inevitably undocumented
The system structure will be degraded through changes made during development
Normal organisational quality standards may not have been applied
Formal Specifications
•Formalspecification is part of a more general collection of techniques that are known as ‘formal
methods’.
•These are all based on mathematical representation and analysis of software.
•Formal methods include
Formal specification
Specification analysis and proof
Transformational development
Program verification
Acceptance of Formal Methods
•Formal methods have not become mainstream software development techniques as was once
predicted
Other software engineering techniques have been successful at increasing system quality.
Hence the need for formal methods has been reduced.
Market changes have made time-to-market rather than software with a low error count the key
factor. Formal methods do not reduce time to market.
The scope of formal methods is limited. They are not well-suited to specifying and analysing
user interfaces and user interaction.
Formal methods are still hard to scale up to large systems.
Use of Formal Methods
•The principal benefits of formal methods are in reducing the number of faults in systems.
•Consequently, their main area of applicability is in critical systems engineering. There have been
several successful projects where formal methods have been used in this area.
•In this area, the use of formal methods is most likely to be cost-effective because high system
failure costs must be avoided.
 Specification Components
•Introduction

Defines the sort (the type name) and declares other specifications Graphical Representation
that are used.
•Description

Informally describes the operations on the type.

•Signature

Defines the syntax of the operations in the interface and their

parameters.
•Axioms

Defines the operation semantics by defining axioms which

characterise behaviour.
Types of Operations
•Constructor operations: operations which create / modify entities of the type
◦ Create, Assign

•Inspection operations: operations which evaluate entities of the type being specified
◦ First, Last, Eval

---------------------------------------------
Rule of Thumb for Defining Axioms: define an axiom which sets out what is always true for
each inspection operation over each constructor.
 Description of Array
• Arrays are collections of elements of generic type Elem.

• They have a lower and upper bound (discovered by the operations

First and Last). Individual elements are accessed via their numeric
index.

Create
takes the array bounds as parameters and creates the array, initializing its
values to Undefined.
Assign
creates a new array which is the same as the input with the specified
element assigned the given value.
Eval
reveals the value of a specified element. If an attempt is made to access
a value outside the bounds of the array, the value is undefined.
 Informal Description of Array
Array Signature
•Create (Integer, Integer) → Array
•Assign (Array, Integer, Elem) → Array
•First (Array) → Integer
•Last (Array) → Integer
•Eval (Array, Integer) → Elem
Array Axiom
1.First (Create (x, y)) = x
2.First (Assign (a, n, v)) = First (a)
3.Last (Create (x, y)) = y
4.Last (Assign (a, n, v)) = Last (a)
5.Eval (Create (x, y), n) = Undefined
6.Eval (Assign (a, n, v), m) = if m < First (a) or
m > Last (a) then Undefined else
If m = n then v else Eval (a, m)
Example
Let: A1 := Assign (Create (1, 3), 3, c)
A2 := Assign (A1, 2, b) By axiom 6,
Eval (Assign (A2, 1, a), 2) = if 2 < First (A2) = 1 or 2 > Last
A2 = [Undefined, b, c]
(A2) = 3 then Undefined else if 2 = 1 then a else Eval (A2, 2)
1 2 3
= Eval (A2, 2) = Eval (Assign (A1, 2, b), 2)
What is the value of:

Eval (Assign (A2, 1, a), 2) ?

b Again, by axiom 6,
Use axiom 6 to prove this. Eval (Assign (A1, 2, b), 2) = if 2 < First (A1) = 1 or 2 > Last
(A1) = 3 then Undefined else if 2 = 2 then b else Eval (A1, 2)
=b
More Examples
What are the values of the following operation sequences:
1.Eval (Assign (Create (-3, 0), -2, a), -2)
Visual Interpretation
More Examples
What are the values of the following operation sequences:
1.Eval (Assign (Create (-3, 0), -2, a), -2)
=a

2.Eval (Assign (Create (5, 5), 5, b), 5)

=b

3.Eval
(Assign (Create (3, -2), 1, c), 1) By axiom 6,
= Undefined
Eval (Assign (Create (3, -2), 1, c), 1) =
if 1< 3 or 1 > -2 then Undefined else…
= Undefined
Specification Instantiation
•A simple form of reuse.
•An existing specification utilizing a generic parameter is instantiated with some other sort, e.g.:
CHAR_ARRAY: ARRAY
sortChar_array instantiatesArray (Elem:=Char) importsINTEGER
Model Based Specification
•Algebraic specification is suited to subsystem interface
specification, where outputs of operations only depend
on the input parameters
Characteristic
•System model defined using well-understood
•Algebraicspecification can be cumbersome when the mathematical entities like sets and functions
object operations are not independent of the object •System state is not hidden like it is in algebraic
state. specification

•Model-based specification exposes the system state •State changes are straight forward to define
and defines the operations in terms of changes to that
•VDM and Z are the most widely used model-
state. based specification languages
•The Z notation is a mature technique for model-based
specification. It combines formal and informal
description and uses graphical highlighting when
presenting specifications.
Z Formal Language
•Based on set theory and first-order predicate logic
•Strongly typed
•Declarative language
•Makes use of a graphical construction known as a schema
provide an effective low level structuring facility
are useful as specification building blocks
can be understood fairly easily
Schemas
•Include
a unique name or identifier
a signature that declares entities and their types
a predicate part that defines invariants involving these entities
•Schemas can be included in other schemas and act as type definitions
•Names are local to the schema in which they are defined
Schemas: Declaration
•Contains local declarations (types and variables)
•Can import other types by listing their names
•Anonymous schemas (name omitted) are used to make global declarations
•Anonymous schemas usually do not contain a predicate part
Schemas: Predicate
•Statements about the entities defined in the declaration part of the schema
•These statements must be true at all times
•Multiple statements are assumed to be implicitly connected by a logical and
•Other logical connectives (e.g. or, implies, equivalent, etc.) can be used explicitly in compound
statements
Example Schema
• The symbol P is used to indicate the power set of a type, and the
• Symbol  is used to define a relation between two types (i.e. a set of ordered pairs from the
Cartesian product of the two types).
Z-Schema
Foundation of Z
•Model theoretic method
abstract model is constructed
properties of the model are proven
•Set theory (and other discrete math)
•First order predicate calculus
•Schema calculus provides incrementality
Predicate Logic Set Theory Functions & Relations

Sequences Schema Operators

Names
Birthday Book [Spivey 92]
•Example of use of schemas
•Describes a calendar with birthdates
Examples