The Three Principal Development Activities
Analysis: Concerns the problem domain and the problems
that exist within it
Specification: Concerns the interaction between the
problem domain and the solution space
Design: Concerns the internal workings of the solution
Investigating and describing the problem domain
Develop requirements through an iterative co-operative
process of analysing the problem
Documenting the resulting observations in a variety of
Checking the accuracy of the understanding gained
The Problem Domain
The part of the universe within which the problems
Example lift: The problem domain will include any
existing hardware (lifts, motors, sensors, etc.), the building characteristics
(number of floors, etc.), the anticipated pattern of usage, the characteristics
of the users and so on.
The effects that the client
wishes to be brought about in the problem domain
An Introduction to Requirements
Engineering by Ian K. Bray, Addison Wesley, 2002
IEEE 1984: A condition or capability that must be met
by the system to solve a problem or achieve an objective
Distinction Between Requirements and Facts About The Problem Domain
Requirement: A lift will only reverse direction when
stopped at a floor.
Characteristic of the problem domain: When a lift is
within 20 cm vertically (above or below) of the sensors nominal position, the
sensor sends a hi signal; otherwise a low signal.
Ordinary requirements are often called functional or
Example: The lift doors are to be cycled every time
that a lift stops at a floor.
Design constraints are the true non-functional requirements.
They affect (constrain) how the system is built, not what it does.
Design constraints include:
Target machine(s) upon which the solution system must
Underlying architecture (distributed or local)
Memory size within which it must operate
Any front-end graphical user interface (GUI) packages
that must be employed
Operating system(s) under which it must operate
Design Constraints (Cont.)
Programming language(s) that must be used
Other software packages, such as database management
systems (DBMS) that must be incorporated
Development standards that must be applied
Design approaches that must be employed
Algorithms that must be incorporated
Difficulties in Requirements Engineering
The customer may not be able to express what he
or she wants so that you are able to understand it
Finding the right people to ask
Getting access to the right people
Handling large amounts of requirements
requirements so that both you, the customer, your developers, and your testers
can understand and use them
Requirements Engineering Phases
Analysis & Negotiation
Elicitation concerns the gathering of information. The three
main considerations are:
What information should be gathered?
From what sources can it be gleaned?
By what mechanisms or techniques may it be gathered?
Requirements Elicitation Techniques
Analysis of written documents
What is the scope of the system?
What should you do?
What should you not do?
What should you not do? Why?
What is too costly to do?
there any conflicts?
What the proposed system shall do
At what quality level
A documented common view
An agreement between developers and customer
Sign a contract based on the requirements
Involve client in the process
Reasons for the
Primary driver of
System Testing Process
Control the evolution of the system
Contents of Requirements Specification
Terms, Abbreviations & Definitions
Assumptions and Dependencies
Different Types of Requirements
What the system shall do
Checks should be carried out on the requirements. These checks
Validity checks: Further analysis including different
Consistency checks: No contradictory constraints of the
same system function
Realism checks: Could the requirements be implemented?
Consider also budget and schedule.
Verifiability: It should be possible to write a set of
tests that can demonstrate that the delivered system meets each specified
Requirement reviews: The requirements are analysed by a
team of reviewers looking for
Common Quality Requirements
Suitability, Accuracy, Interoperability, Security,
Maturity, Fault Tolerance, Recoverability,
Understandability, Learnability, Operability,
Attractiveness, Usability Compliance
Common Quality Requirements
ISO/IEC 9126 (Cont.)
Time Behaviour, Resource Utilisation, Efficiency
Analysability, Changeability, Stability, Testability,
Adaptability, Installability, Co-Existence,
Replaceability, Portability Compliance
Functional Requirements and
Functional Requirements are easier to test
Can, in general, spend less time on these
Quality Requirements must be better specified
to be testable
How should the requirement be measured?
What is the desired value?
What is the worst case value?
written judicial document defining the terms for business related agreements
in sunshine, used in storm
version of the requirements specification
contract defines what you shall do
contract also defines what you can expect from the customer
You sign the contract knowing that you can deliver what
is specified, under the specified conditions