SRE -

Requirement Elicitation

Lecture 07
Objectives
●
To describe the processes of requirements elicitation and analysis.
●
To introduce a number of requirements elicitation and requirements analysis
techniques.
●
To discuss how prototypes may be used in the RE process.
Elicitation, Analysis &Negotiation: Zig-zagging
and Backtracking
Components of Requirements Elicitation
Components of Requirements Elicitation
●
Application domain understanding
●
Application domain knowledge is knowledge of the general area where the
system is applied.
●
Problem understanding
●
The details of the specific customer problem where the system will be applied
must be understood.
●
Business understanding
●
You must understand how systems interact and contribute to overall business
goals.
● Understanding the needs and constraints of system stakeholders
●
You must understand, in detail, the specific needs of people who require
system support in their work.
Requirement Elicitation Process
Elicitation Stages
●
Objective setting
●
The organizational objectives should be established including general goals of
the business, an outline description of the problem to be solved, why the
system is necessary and the constraints on the system.
●
Background knowledge acquisition
●
Background information about the system includes information about the
organization where the system is to be installed, the application domain of
the system and information about existing systems.
●
Knowledge organization
●
The large amount of knowledge which has been collected in the previous stage
must be organized and collated.
●
Stakeholder requirements collection
●
System stakeholders are consulted to discover their requirements.
Elicitation Techniques

● Interviews
● Scenarios
● Observations and social analysis
● Requirements reuse
●
Prototyping
Interviews
●
The requirements engineer or analyst discusses the system with different
stakeholders and builds up an understanding of their requirements.
●
Types of interview:
●
Closed interviews. The requirements engineer looks for answers to a
predefined set of questions
●
Open interviews There is no predefined agenda and the requirements
engineer discusses, in an open-ended way, what stakeholders want from
the system.
Often it is MIXED
Interviewing Essentials
●
Interviewers must be open-minded and should not approach the interview
with pre-conceived notions about what is required.

●
Stakeholders must be given a starting point for discussion. This can be a
question, a requirements proposal or an existing system.

●
Interviewers must be aware of organizational politics - many real
requirements may not be discussed because of their political implications.
Scenarios
● Scenarios are stories which explain how a system might be used.
● They should include:
● a description of the system state before entering the scenario
● the normal flow of events in the scenario
● exceptions to the normal flow of events
● information about concurrent activities
●
a description of the system state at the end of the scenario

●
Scenarios are examples of interaction sessions which describe how a user
interacts with a system
●
Discovering scenarios exposes possible system interactions and reveals
system facilities which may be required
Library Scenario – document ordering

1.Log on to EDDIS system

2.Issue order document command
3.Enter reference number of the required document
4.Select a delivery option
5. Log out from EDDIS
6. This sequence of events can be illustrated in a diagram
Library Scenario
Scenarios and OOD
●
Scenarios are an inherent part of some object-oriented development
methods
●
The term use-case (i.e. a specific case of system usage) is sometimes used
to refer to a scenario
●
There are different views on the relationship between use-cases and
scenarios:
●
A use-case is a scenario
●
A scenario is a collection of use-cases. Therefore, each interaction is
represented as a separate use-case
Observations and Social Analysis
●
People often find it hard to describe what they do because it is so natural to
them. Sometimes, the best way to understand it is to observe them at work.
●
Ethnography is a technique from the social sciences which has proved to be
valuable in understanding actual work processes.
●
Actual work processes often differ from formal, prescribed processes.
●
An ethnographer spends some time observing people at work and building
up a picture of how work is done.
●
Spend time getting to know the people and establish a trust relationship
●
Keep detailed notes of all work practices. Analyze them and draw conclusions
from them
● Combine observation with open-ended interviewing
●
Organize regular de-briefing session where the ethnographer talks with people
outside the process
● Combine ethnography with other elicitation techniques
Requirements Reuse
●
Reuse involves taking the requirements which have been developed for one
system and using them in a different system

●
Requirements reuse saves time and effort as reused requirements have
already been analyzed and validated in other systems

●
Currently, requirements reuse is an informal process but more systematic
reuse could lead to larger cost savings

●
Reuse leads to a consistency of style across applications.
Prototyping
●
A prototype is an initial version of a system which may be used for
experimentation

●
Prototypes are valuable for requirements elicitation because users can
experiment with the system and point out its strengths and weaknesses.
They have something concrete to criticize

●
Rapid development of prototypes is essential so that they are available early
in the elicitation process
Types of Prototyping
●
Throw-away prototyping
●
Intended to help elicit and develop the system requirements.
●
The requirements which should be prototyped are those which cause most
difficulties to customers and which are the hardest to understand.
Requirements which are well-understood need not be implemented by the
prototype.
●
Evolutionary prototyping
●
Intended to deliver a workable system quickly to the customer.
●
Therefore, the requirements which should be supported by the initial versions
of this prototype are those which are well-understood and which can deliver
useful end-user functionality. It is only after extensive use that poorly
understood requirements should be implemented.
Prototyping Benefits
●
The prototype allows users to experiment and discover what they really need to
support their work

●
Establishes feasibility and usefulness before high development costs are
incurred

●
Essential for developing the ‘look and feel’ of a user interface

●
Can be used for system testing and the development of documentation

●
Forces a detailed study of the requirements which reveals inconsistencies and
omissions
Prototyping – costs and problems
● Training costs - prototype development may require the use of special
purpose tools

●
Development costs - depend on the type of prototype being developed

●
Extended development schedules - developing a prototype may extend the schedule
although the prototyping time may be recovered because rework is avoided
– Questions ?