In this slide:
__________________________________________________
SRE –
Requirement Elicitation
BSEF15
(V)
Abdul
Razaq Ali
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
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
Incompleteness
-it may not be
possible to prototype critical system requirements
Questions ?
No comments :
Post a Comment