Requirements Engineering


                                An Overview

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 space

Requirements Engineering

•      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 representation formats

•      Checking the accuracy of the understanding gained

The Problem Domain

•      The part of the universe within which the problems exist

•      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.

Requirements – Definitions

• 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 sensor’s nominal position, the sensor sends a hi signal; otherwise a low signal.


•      ‘Ordinary’ requirements are often called functional or behavioural requirements.

•      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

     Design constraints include:

•      Target machine(s) upon which the solution system must operate

•      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

– Tacit knowledge

•   Finding the right people to ask

•   Getting access to the right people

•   Handling large amounts of requirements

•        Specifying the requirements so that both you, the customer, your developers, and your testers can understand and use them

Requirements Engineering Phases

•      Elicitation

•      Analysis & Negotiation

•      Documentation

•      Validation

•      Management


     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

•      Interviews

•      Use-Case-based discussions

•      Observations

•      Brainstorming

•      Questionnaires

•      Prototyping

•      Incremental deliveries

•      Analysis of written documents

System Scope

•      What is the scope of the system?

–System boundaries

•      What should you do?

•      What should you not do?

Requirements Negotiation

•      What should you not do? Why?

•      What is too costly to do?

•      Are there any conflicts?

Requirements Specification

•   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 specification

•   Involve client in the process

•   Decrease risk

Reasons for the
Requirements Specification

•   Facilitate Communication

•   Primary driver of

– Design Process

– System Testing Process

– Management Process

•   Control the evolution of the system

Contents of Requirements Specification

•   System Scope

•   Terms, Abbreviations & Definitions

•   User Characteristics

•   General Constraints

•   Assumptions and Dependencies

•   Functional Requirements

•   Quality Requirements

Different Types of Requirements

•   Interface Requirements

– User Interface

•   Functional Requirements

– What the system shall do

•   Quality Requirements

– “Non-Functional Requirements”


     Checks should be carried out on the requirements. These checks include:

•      Validity checks: Further analysis including different stakeholders needs

•      Consistency checks: No contradictory constraints of the same system function

•      Completeness checks

•      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

Validation Techniques

•      Requirement reviews: The requirements are analysed by a team of reviewers looking for





•      Prototyping

•      Test-case generation

Common Quality Requirements –
 ISO/IEC 9126

•   Functionality

– Suitability, Accuracy, Interoperability, Security, Functionality Compliance

•   Reliability

– Maturity, Fault Tolerance, Recoverability, Reliability Compliance

•   Usability

– Understandability, Learnability, Operability, Attractiveness, Usability Compliance          

Common Quality Requirements –
 ISO/IEC 9126 (Cont.)

•   Efficiency

– Time Behaviour, Resource Utilisation, Efficiency Compliance

•   Maintainability

– Analysability, Changeability, Stability, Testability, Maintainability Compliance

•   Portability

– Adaptability, Installability, Co-Existence, Replaceability, Portability Compliance  

Functional Requirements and
Quality Requirements

•   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?


•     “A written judicial document defining the terms for business related agreements”

–Verbal agreements

–Written agreements

•     Defines



•     Written in sunshine, used in storm

Contract Types

•     Fixed price

•     Running price

•     Cost-plus

•     Roof price

•     Combinations

Contract Contents

•     Definition of Services

•     Time period

•     Contact persons

•     Costs

•     Deliveries

•     General conditions

•     Connected to:

–A specific version of the requirements specification

–Project plan?

Important points

•     The contract defines what you shall do

•     The 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