Chapter-Three

Requirements Elicitation

Requirement Elicitation
 Outlines
2

 Requirement elicitation

 Requirement validations

 Types of requirements

 Functional requirement
 Non-functional requirement

 Analysis concepts, activities and models

 Identifying actors, scenarios, use cases,

 Refining use-cases, identify relationship between actors and use-
cases
Requirement Elicitation
 Introduction
3

A requirement: is a feature that the system must have or a constraint

that it must satisfy to be accepted by the client.

Requirements engineering: is the process of identifying stakeholders

and their needs, modeling and documenting them.

Requirements engineering includes two main activities:-

 Requirements elicitation: is the process of discovering

specification of the system that the client understands
 Requirement Analysis: which results into an analysis model that the
developers can unambiguously interpret the requirement.
Requirement Elicitation
 Introduction
4

What is Requirements elicitation ?

A Sometimes called Requirements discovery.

It certainly seems simple enough to ask the customer, the users, and others

 What the objectives for the system or product are

 What is to be accomplished
 How the system or product fits into the needs of
the business and
 how the system or product is to be used on
a day-to-day basis.

Requirement Elicitation
 Requirements elicitation
5

 Requirements elicitation: focuses on describing the purpose of the system.

 The client, the developers, and the users identify a problem area and define

a system that addresses the problem.

 Such a definition is called a system specification and serves as a contract

between the client and the developers.

 The system specification is structured and formalized during analysis to

produce an analysis model.

 Both system specification and analysis model represent the same

information.

Requirement Elicitation
 Cont…
6

 They differ only in the language and notation they use.

 The system specification is written in natural language, where as the analysis

model is usually expressed in a formal or semiformal notation.

 The analysis model supports the communication among developers.

 Requirements elicitation and analysis focus only on the user’s view of the

system:-
 The system functionality.
 The interaction between the user and the system.
 The errors that the system can detect and handle.
Requirement Elicitation
 Cont…
7

 Developers elicit requirements by:

 Interviewing
 Questioner
 Observation
 Document analysis - organizational charts, process models, standards, and user
manuals, etc
 Developers first represent the user’s current work processes as scenarios.

 and then develop visionary scenarios describing the functionality provided by

the system.
 Requirements are continuously validated with the client and the user.
Requirement Elicitation
 Requirement validation
8

 Validation is a critical step in the development process given

both the client and developer depend on the requirements

specification.
 Requirement validation involves checking if the specification

is correct, complete, consistent, unambiguous, and realistic.

 Correctness: A specification is correct if it represents

client’s view of the system.

 Clarity: there are no ambiguities in the requirements.

Requirement Elicitation
 Cont…
9

 Consistency: the system specification is consistent if it does not

contradict itself.
 Completeness: all possible scenarios through the system are described,

including exceptional behavior by the user or the system.

 It is complete if all the possible scenarios through the system are
described, including exceptional behavior.
 Verifiable: The SRS is verifiable if once the system is built, repeatable

tests can be designed to demonstrate that system fulfills the requirements

specification.
Requirement Elicitation
 Cont…
10

 Realism: requirements can be implemented and delivered.

 unambiguous: The SRS is unambiguous if exactly one system is defined [ i.e.., it

is not possible to interpret the specification two or more different ways.]

 Traceability: Each system function can be traced to a corresponding set of

functional requirements.

 Traceability enables the tester to access the coverage of the test case, to

identify which requirements are tested and which are not.

Requirement Elicitation
 Requirements Engineering Models
11

 As the definition of the system matures and stabilizes,

developers and the client agree on a system specification in

the form of use cases.
 Depending on the source of the requirements, requirements

elicitation activities can be classified into three:

 Greenfield engineering - the development starts from scratch,

no prior system exists.

Requirement Elicitation
 Cont…
12

Greenfield Engineering - the development

starts from scratch, no prior system exists.

 Development starts from scratch

 No prior system exists

 Requirements come from end users and clients

 Triggered by user needs

Requirement Elicitation
 Cont…
13

 Reengineering: is the redesign and reimplementation of an

existing system newer technology triggered by technology

enabler.
 (The requirements of the new system are extracted from an existing

system).

 Interface engineering: is the redesign of the user interface of

an existing system.

 Provision of existing services in a new environment

 Triggered by technology enabler or new market needs

Requirement Elicitation
 Cont…
14

 Define requirements from different point of views, be sure

to identify the rational for each requirements that is recorded

 Identify ambiguous requirements

 Create user scenarios to help customers/users to identify key

requirements
 Identify the customers, users or other stockholders who

participate in the system

Requirement Elicitation
 Cont…
15
 Requirements elicitation includes the following activities:-

 Identifying actors- During this activity, developers identify the

different types of users the future system will support.
 Identifying scenarios- developers observe users and develop a set
of detailed scenarios for typical functionality provided by the future
system.
 Identifying use cases- Once developers and users agree on a set of
scenarios, developers derive from the scenarios a set of use cases
that completely represent the future system.
Requirement Elicitation
 Cont…
16

Refining use cases- developers ensure that the system specification is

complete, by detailing each use case and describing the behaviour of

the system in the presence of errors and exceptional conditions.
Identifying relationships among use cases- developers consolidate

the use case model by eliminating redundancies. This ensures that the
system specification is consistent.
Identifying non-functional requirements- developers, users, and

clients agree on aspects that are visible to the user but not directly
related to functionality.
Requirement Elicitation
 Type of Requirements
17
Functional requirements: describe the interactions
between the system and its environment.
The environment includes the user and any other
external system that interact with the system.
Example: the following is an example of functional
requirements for SatWatch, a watch that resets itself
without user intervention.

Requirement Elicitation
Cont…
18
Non-functional requirements: user visible aspects of
the system not directly related to functional behavior. It
includes quantitative constrains such as response time,
accuracy etc.
 The response time must be less than 1 second

 The accuracy must be within a second

 The system should be available 24 hours of a day

 Example of non-functional requirements for

SatWatch is:
 The battery life of SatWatch is limited to 5 years.

Requirement Elicitation
 Requirements elicitation activities
19
 Requirements elicitation activities include:-
Identifying actors
Identifying scenarios
Identifying use cases
Identifying relationships among use cases
Identifying participating objects
Identifying non-functional requirements

Requirement Elicitation
 Cont…
20

 Identifying actors
 Actors represent external entities that interact

with the system.

 An actor can be human or an external system.

 In the SatWatch example;

 The watch owner
 The GPS satellites , and
 The Wi-Fi watch serial device are actors.

Requirement Elicitation
Cont…
21
 How do we find an actor?
 Ask the following questions
Who uses the system?
Who installs the system?
Who Starts up the system?
What other systems use this system?
Who gets the information from the system?
Who provides information to the system?
 Note: Actor is always external to the system. They are
never part of the system to be developed.
UML
Cont…
22

 Identifying scenarios

A scenario is a concrete, focused, informal description of

a single feature of the system from the viewpoint of a
single actor.
 Example of scenario for the Distributed information
system for incident response.
 In this scenario, a police officer reports a fire and a
Dispatcher initiates the incident response.
Requirement Elicitation
Cont…
23
 Scenarios can have many different uses during
requirements elicitation and during other activities of
the life cycle.
 Below is a selected number of scenario types:
1. As-is scenarios describe the current situation.
2. Visionary scenarios describe the future system.
3. Evaluation scenarios describe user tasks against
which the system is to be evaluated.
4. Training scenarios are tutorials used for introducing
new users to the system.
Requirement Elicitation
Cont…
24

 Questions for identifying scenarios

What are the tasks that the actor wants the system to
perform?
What information does the actor access?
Who creates that data? Can it be modified or
removed? By whom?
Which external changes does the actor need to inform
the system about? How often? When?
Which events does the actor need to be informed by
the system about? With what latency?
Requirement Elicitation
 Cont…
25

 Identifying use cases

 A scenario is an instance of a use case, that is, a use

case specifies all possible scenarios for a given piece of

functionality.
 A use case is initiated by an actor.

 After its initiation, a use case may interact with other

actors as well.

Requirement Elicitation
Cont…
26

 How do we find use cases?

 Ask following questions.
What are the functions that the actor want
from the system?
Does the system store information?
Who will create, read, update or delete that
information.
Does the system need to notify an actor about
changes in its internal states?
UML
Cont…
27
 Identifying relationships among actors and use cases
 Relationships among actors and use cases enable the
developers and users:-
To reduce the complexity of the model
To increase its understand ability.
 We use communication relationships between actors and
use cases to describe the system in layers of functionality.
 We use extend relationships to separate exceptional and
common flows of events.
 We use include relationships to reduce redundancy among
use cases.
Requirement Elicitation
Cont…
28
 Include relationships between use cases
 Redundancies among use cases can be factored out using
include relationships.

 Fig 5: Example of include relationships among use cases.

Requirement Elicitation
 Cont…
29
 Identifying non-functional requirements

 Non-functional requirements describe user-visible aspects of the system that are

not directly related to the functional behaviour of the system.
 Non-functional requirements can be elicited by investigating the following
issues:
 User interface and human factors: what kind of interface should the system
provide?
 Hardware considerations: are there hardware compatibility requirements?
• Will the system interact with other hardware systems?

Requirement Elicitation
Cont…
30

 System modifications: What is the anticipated scope of future changes?

 Who will perform the changes?
 Performance characteristics: How responsive should the system be?
 How many concurrent users should it support?
 Error handling and extreme conditions: How should the system handle
exceptions?
 Quality issues: How reliable /available /robust should the system be?
 Security issues: Should the system be protected against external intrusions or
against malicious users?
Requirement Elicitation
 31

Object oriented system analysis

Object-Oriented System Analysis

 Introduction
32

 Requirement Analysis: which results into an analysis model that the

developers can unambiguously interpret the requirement.

 The client, the developers, and the users identify a problem area and define a

system that addresses the problem.

 Such a definition is called a system specification and serves as a contract

between the client and the developers.

 The system specification is structured and formalized during analysis to

produce an analysis model.

 Both system specification and analysis model represent the same information.

Object-Oriented System Analysis

 Cont…
33

 They differ only in the language and notation they use.

 The system specification is written in natural language, where as the analysis

model is usually expressed in a formal or semiformal notation.

 The system specification supports the communication with the client and users.

 The analysis model supports the communication among developers.

 Requirements elicitation and analysis focus only on the user’s view of the system:-

 The system functionality.

 The interaction between the user and the system.
 The errors that the system can detect and handle.

Object-Oriented System Analysis

An Overview of Analysis
34

 OO Analysis focuses on producing a model of the

system, called the analysis model, which is

correct, complete, consistent, and verifiable.
 Developers focus on structuring and formalizing the

requirements elicited from users

 In object-oriented analysis, developers build a model

describing the application domain.

Object-Oriented System Analysis

An Overview of Analysis
35

Products of requirements elicitation and analysis (UML activity diagram).

Object-Oriented System Analysis
An Overview of Analysis
36
Analysis class: the first step towards executables

Object-Oriented System Analysis

 Analysis Model
37

 The analysis model is composed of three individual models:

 The functional model- represented by use cases and

scenarios.
 The analysis object model- represented by class and
object diagrams.
 The dynamic model- represented by state chart, activity
diagram and sequence diagrams.

Object-Oriented System Analysis

Analysis Model
38

Analysis model

Object-Oriented System Analysis

 Analysis Concepts
39

 The analysis object model - consists of three basic objects.

 Entity objects: Represent the persistent information tracked by
the system.
 The main responsibilities of entity classes are to store and
manage information in the system.
 Boundary objects: represent the interactions between the actors
and the system.
 Control objects: represent the tasks that are performed by the
user and supported by the system.
 The interface to the system (represented by boundary objects)
is more likely to change than its basic functionality
(represented by the entity and control objects).
Object-Oriented System Analysis
Analysis Concepts
40

Object-Oriented System Analysis

Analysis Concepts
41

Object-Oriented System Analysis

Analysis Concepts
42

Role of boundary class

Object-Oriented System Analysis

Analysis Concepts
43

Object-Oriented System Analysis

Analysis Concepts
44

Object-Oriented System Analysis

Analysis activities
45

 From Use Cases to Objects, Analysis activities

include:-
 Identifying entity ,boundary and control objects

 Mapping use cases to objects

 Identifying associations among objects

 Identifying object attributes

 Modelling object’s behaviour with state charts

 Modelling generalization relationships

Object-Oriented System Analysis

Analysis activities
46

Object-Oriented System Analysis

Analysis activities
47

Example

Object-Oriented System Analysis

Identifying Entity Objects
48

Heuristics for identifying entity objects

 Developers or users need entity objects to clarify in order to understand the use
case
 Recurring nouns in the use cases (e.g., Incident)
 Real-world entities that the system needs to keep track of (e.g., FieldOfficer,
Dispatcher, Resource)
 Real-world activities that the system needs to keep track of (e.g.,
EmergencyOperationsPlan)
 Use cases (e.g., ReportEmergency)
 Data sources or sinks (e.g., Printer)
Object-Oriented System Analysis
Identifying Boundary Objects
49

 Boundary objects represent the system interface with the actors.

 The boundary object collects the information from the actor and
translates it into an interface that can be used by the entity
objects and also by the control objects.
 Identify forms and windows that helps the users to enter data into
the system (e.g.,EmergencyReportForm).
 Identify notices and messages that the system uses to respond to
the user (e.g., AcknowledgmentNotice).
Object-Oriented System Analysis
 Identifying Control Objects
50

 Control objects are responsible for coordinating boundary and entity objects.
 It is responsible for collecting information from the boundary objects and dispatching it to

entity objects.
 The control objects describe the behaviour associated with:
 The sequencing of forms

 Dispatching information in a distributed system, etc.

 Example: the control flow of the ReportEmergency use case with a control object for each

actor;
 ReportEmergencyControl: for the FieldOfficer and
 ManageEmergencyControl: for the Dispatcher
Object-Oriented System Analysis
 Modelling Interactions Between Objects
51

 Sequence Diagrams

 A sequence diagram allow developers to represent interactions among objects over time.
 It shows how the behaviour of a use case (or scenario) is distributed among its participating objects.
 It model the sequence of interactions among objects needed to realize the use case.
 The columns of a sequence diagram represent the objects that participate in the use case.
 The leftmost column is the actor who initiates the use case.
 Horizontal arrows across columns represent messages, or stimuli, which are sent from one object
to the other.
 Time proceeds vertically from top to bottom.

Object-Oriented System Analysis

 Modelling Interactions Between Objects
52

 By constructing sequence diagrams

 We can model the order of the interaction among the objects.

 We also distribute the behaviour of the use case.
 Assign to each object responsibilities in the form of a set of
operations.
 Sequence diagrams are used to help identify:-

 New participating objects and

 Missing behaviour.
Object-Oriented System Analysis
Modelling Interactions Between Objects
53

 Example of sequence diagram

Object-Oriented System Analysis

Identifying Associations
54

 Sequence diagrams -allow developers to represent interactions

among objects over time.
 Class diagrams- allow developers to describe the connectivity
of objects.
 In this section, we discuss the use of class diagrams for
representing object attributes and associations among objects.
 An association shows a relationship between two or more
classes.
Object-Oriented System Analysis
Identifying Associations
55

Identifying Attributes
 Attributes are properties of individual objects.
 When identifying properties of objects, only the
attributes relevant to the system should be considered.

Object-Oriented System Analysis

 Modelling the Behaviour of Individual Objects
56
 Sequence diagrams are used to distribute behaviour across objects and
to identify operations.
 It represent the behaviour of the system from the perspective of a
single use case.
 State chart diagrams: represent behaviour from the perspective of a
single object.
 Viewing behaviour from the perspective of each object enables the
developer:-
 To identify missing use cases
 To build a more-formal description of the behaviour of the
object.
Object-Oriented System Analysis
Modelling the Behaviour of Individual Objects
57
 The following Figure displays a statechart for the Incident class.

 The examination of this state chart may help the developer check
if there are use cases for documenting, closing, and archiving
Incidents.

Object-Oriented System Analysis

Modelling Generalization Relationships Between
Objects
58

An example of inheritance relationship (UML class diagram).

Object-Oriented System Analysis

Modelling Generalization Relationships Between
Objects
59

Analysis activities (UML activities diagram).

Object-Oriented System Analysis
Cont…
60

End
Object-Oriented System Analysis
 Quiz(10%)
61

1. ________is responsible for collecting information from the boundary objects and
dispatching it to entity objects.
2. List and describe the individual models components analysis model?
3. List and describe the objects of analysis object model briefly ?
4. List at least four Object-Oriented system Analysis activities From Use Cases to
Objects?
5. Requirements elicitation and analysis focus only on the user’s view of the
system in term of
i. ____
ii. _____
iii. _____
Object-Oriented System Analysis
Cont…
62

End!
Requirement Elicitation