1

REQUIREMENT ELICITATION
AND ANALYSIS

CHAPTER-3

Prepared by: Hachalu M.

 Objectives
2

 To introduce various requirement engineering

tasks
 To introduce a number of requirements
elicitation techniques.
 To understand requirement and problem analysis
 To introduce about requirement specification
 To discuss how to negotiate with requirement
conflict
 Requirements inception and elicitation

Requirements Engineering Tasks

• Seven distinct tasks
 inception

 Elicitation

 Elaboration

 Negotiation

 Specification

 Validation

 Requirements Management

• Some of these tasks may occur in parallel and all are adapted to the needs of the
project
• All strive to define what the customer wants
• All serve to establish a solid foundation for the design and construction of the
 Cont….
4
 RE tasks
5
1. Inception: This phase gives an outline of how to get started on a project. A basic
understanding of the problem is gained and the nature of the solution is addressed.
2. Elicitation: This phase focuses on gathering the requirements from the
stakeholders. Understanding the kind of requirements needed from the customer is
very crucial for a developer.
3. Elaboration: it takes the requirements that have been stated and gathered in the
first two phases and refines them. to indulge in modelling activities and develop a
prototype that elaborates on the features and constraints using the necessary tools
and functions.
4. Negotiation: This phase emphasizes discussion and exchanging conversation on
what is needed and what is to be eliminated.
5. Specification: In the specification phase, the requirements engineer gathers all the
requirements and develops a working model.
6. Validation: This phase focuses on checking for errors and debugging.
7. Requirements Management: is a set of activities where the entire team takes part
in identifying, controlling, tracking, and establishing the requirements
 Requirements Inception
6
During inception, the requirements engineer asks a set of questions to
establish…
 a common vision of a product and basic scope for the project

 A basic understanding of the problem

 The people who want a solution during

 The nature of the solution that is desired

 The effectiveness of preliminary communication and collaboration

between the customer and the developer

Through these questions, the requirements engineer needs to…
 Identify the stakeholders

 Recognize multiple viewpoints

 Work toward collaboration(give and take policy)

 Continued …..
7

Inception will also include:

 Analysis of perhaps 10% of the use cases
 Analysis of the critical non-functional requirement
 Creation of a business case
 Feasibility Study
 Describe risks (business, technical, resource, schedule)
 Preparation of the development environment so that
programming can start in the following elaboration phase
 Describe the project’s scope
 The Levels of software
8
Requirement
 Product Vision and Project Scope

 Business requirements
 represent top level of abstraction in the requirements chain
 define the vision and scope
 Aligning with user requirements and software functional requirements
 Requirements that don't help the project achieve its business objectives shouldn't be
included.
 The product vision
 Aligns all stakeholders in a common direction.
 Describes what the product is about and what it eventually could become.
 The project scope
 Identifies what portion of the ultimate long-term product vision the current project will
address.
 Draws the boundary between what's in and what's out.
 Defines the project's limitations.
 Vision and Scope Document
10
 Vision and Scope Document
 collects the business requirements into a single document
 Some organizations create a project charter or a business case
document that serves a similar purpose.
 Organizations that build commercial software often create a market
requirements document (MRD).
 A template for a vision and scope document
11
 Elicitation and Analysis Process
12

 Requirements elicitation involves understanding the

application domain, the specific problem to be solved, the
organisational needs and constraints and the specific
facilities needed by system stakeholders.
 The processes of requirements elicitation, analysis and
negotiation are iterative, interleaved processes which must
usually be repeated several times.
 Components of requirements elicitation
13

Application Problem to be
domain solved

Stakeholder Business
needs and context
constraints
 Elicitation activities
14

 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.
 Elicitation, analysis and negotiation
15
Draft
statement of
requirements
Requirements
elicitation Requirements
analysis

Requirements
Requirements problems
document
Requirements
negotiation
 Elicitation stages
16

 Objective setting
 The organisational 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 organisation where the system is to be installed, the application
domain of the system and information about existing systems
 Knowledge organisation
 The large amount of knowledge which has been collected in the
previous stage must be organised and collated.
 Stakeholder requirements collection
 System stakeholders are consulted to discover their requirements.
 The requirements elicitation process
17

Establish objectives Understand background Organise knowledge Collect requirements

Business Organisational Stakeholder Stakeholder

goals structure identification requirements

Goal Domain
Problem to be Application prioritisation requirements
solved domain

Domain Organisational
System Existing knowledge
constraints systems requirements
filtering
 Elicitation

18

Eliciting requirements is difficult because of

 Problems of scope in identifying the boundaries of the system or
specifying too much technical detail rather than overall system
objectives
 Problems of understanding what is wanted, what the problem
domain is, and what the computing environment can handle
(Information that is believed to be "obvious" is often omitted)
 Problems of volatility because the requirements change over time
Elicitation may be accomplished through two activities
 Collaborative requirements gathering
 Quality function deployment
 Basic Guidelines of Collaborative Requirements Gathering

19

 Meetings are conducted and attended by both software

engineers, customers, and other interested stakeholders
 Rules for preparation and participation are established
 An agenda is suggested that is formal enough to cover all
important points but informal enough to encourage the free
flow of ideas
 A "facilitator" (customer, developer, or outsider) controls
the meeting
 The goal is to identify the problem, propose elements of
the solution, negotiate different approaches, and specify a
preliminary set of solution requirements
 Quality Function Deployment

20
 This is a technique that translates the needs of the customer into
technical requirements for software
 It emphasizes an understanding of what is valuable to the customer

and then deploys these values throughout the engineering process

through functions, information, and tasks
It identifies three types of requirements
 Normal requirements: These requirements are the objectives and

goals stated for a product or system during meetings with the customer
 Expected requirements: These requirements are implicit to the

product or system and may be so fundamental that the customer does

not explicitly state them
 Exciting requirements: These requirements are for features that go

beyond the customer's expectations and prove to be very satisfying

 Elicitation techniques
21

 Specific techniques which may be used to collect

knowledge about system requirements
 This knowledge must be structured
 Partitioning - aggregating related knowledge
 Abstraction - recognising generalities
 Projection - organising according to perspective
 Elicitation problems
 Not enough time for elicitation
 Inadequate preparation by engineers
 Stakeholders are unconvinced of the need for a new system
 Specific elicitation techniques
22

 Interviews
 Scenarios
 Observations and social analysis
 Requirements reuse
 Prototyping
 Interviews
23

 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 pre-defined 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.
 Interviewing essentials
24

 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 organisational
politics - many real requirements may not be
discussed because of their political implications
 Interview Steps
25

 Prepare
 Conduct
 Opening
 Body
 Closing
 Follow through
 Scenarios
26

 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
27

 Log on to EDDIS system (Electronic Document

Delivery Integrated Solution)
 Issue order document command
 Enter reference number of the required document
 Select a delivery option
 Log out from EDDIS
 This sequence of events can be illustrated in a
diagram
 Library Scenario this is exam
28
Operational terminal
Login OK
Order accepted
User id Document reference OK
Login to
Passwd EDDIS Delivery confirmed
Select order
document Input document
Exceptions reference
Confirm
Invalid id or Exceptions delivery details
password Logout from
Permission denied Exceptions EDDIS
Login retry Incorrect
Enter help system
reference
Input doc. Exceptions
reference Timeout
Enter help system Auto-logout
 Scenarios and OOD
29

 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
exceptional interaction is represented as a separate use-
case
 Observation and social analysis
30

 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
 Requirements reuse
31

 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 analysed and
validated in other systems
 Currently, requirements reuse is an informal
process but more systematic reuse could lead to
larger cost savings
 Prototyping
32

 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 criticise
 Rapid development of prototypes is essential so that
they are available early in the elicitation process
 Prototypes are effective for requirements elicitation
because stakeholders have something which they
can experiment with to find their real requirements.
 Prototyping benefits
33

 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
 Types of prototyping
34

 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 costs and problems
35

 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
 Approaches to prototyping
36

 Paper prototyping
 a paper mock-up of the system is developed and used
for system experiments
 ‘Wizard of Oz’ prototyping
 a person simulates the responses of the system in
response to some user inputs
 Executable prototyping
 a fourth generation language or other rapid
development environment is used to develop an
executable prototype
 Executable prototype development
37

 Fourth generation languages based around database

systems
 Visual programming languages such as Visual Basic
or ObjectWorks
 Internet-based prototyping solutions based on World
Wide Web browsers and languages such as Java
 What is Requirements Analysis
38

 The process of studying and analyzing the customer and

the user needs to arrive at a definition of the problem
domain and system requirements
Objectives
 Discover the boundaries of the new system (or software)

and how it must interact with its environment within the

new problem domain
 Detect and resolve conflicts between (user) requirements

 Negotiate priorities of stakeholders

 Prioritize requirements
 Cont…
39

 Elaborate system requirements, defined in the

requirement specification document, such that
managers can give realistic project estimates and
developers can design, implement, and test
 Classify requirements information into various
categories and allocate requirements to sub-systems
 Evaluate requirements for desirable qualities
 How to Find the Real Problems?
40

Ask: Why?
 Root cause analysis

 Determine (recursively) the factors that contribute to the

problem(s) found by stakeholders

 The causes do not all have the same impact nor the same

weight
 Some may perhaps not deserve to be corrected, at least for

the moment
 Goal-oriented modelling can help understand these causes

and their relationships

 This analysis identifies problems that need to be solved
 Requirement Priorities
41

 Prioritization helps the project manager

–resolve conflicts,
–plan for staged deliveries, and
–make the necessary trade-offs
 Requirement Priorities
42

 a way to deal with competing demands for

limited resources
 importance and urgency

 customers must indicate which requirements

are needed initially and which can wait

Requirement Priorities…
 If all requirements are top priority,
– your project has a high risk of not being fully
successful
 When you evaluate priorities,

– look at the connections and interrelationships among

different requirements and their alignment with the
project's business objectives

10/22/2023
 High, medium, and low
44
approach
 subjective and imprecise
 stakeholders must agree on

 two dimensions: importance and urgency

 High priority requirements:

–important (the user needs the capability)

–urgent (the user needs it in the next release).
 High
45
 Medium priority requirements:
– important (the user needs the capability)
–but not urgent (they can wait for a later release).
 Low priority requirements:

–not important (the user can live without the capability if necessary)
and
– not urgent (the user can wait, perhaps forever).
 Requirements Analysis
46

 Problem analysis
 Development of product vision and project scope

 Analysis and elicitation feed each other

Elicitation

Elicitation Questions and points

Notes to consider

Analysis Requirements Specification

 Requirements Negotiation
47

 The customer and the developer enter into a process of

negotiation, where the customer may be asked to balance
functionality, performance, and other product or system
characteristics against cost and time to market.
 The intent of the negotiations is to develop a project plan
that meets the needs of the customer while at the same
time reflecting the real-world constraints (time, people,
and budget) that have been imposed on the software
engineering team.
 Requirements negotiation
48
 Requirements discussion
 Requirements which have been highlighted as problematical are

discussed and the stakeholders involved present their views about

the requirements.
 Requirements prioritisation
 Disputed/unclear requirements are prioritised to identify critical
requirements and to help the decision making process.
 Requirements agreement
 Solutions to the requirements problems are identified and a

compromise set of requirements are agreed. This will involve

making changes to some of requirements.
 Cont..
49

 Boehm defines a set of negotiation activities at the

beginning of each software process iteration. The
following activities are defined:
 Identify the key stakeholders. These are the people
who will be involved in the negotiation.
 Determine each of the stakeholders “win conditions”.
Win conditions are not always obvious.
 Negotiate; work toward a set of requirements that
lead to “win-win”
 Cont..
50

 To negotiate the requirements of a system to be

developed, it is necessary to identify conflicts and to
resolve those conflicts. This is done by means of
systematic conflict management. The conflict
management in requirements engineering comprises
the following four tasks:
 Conflict identification
 Conflict analysis
 Conflict resolution
 Documentation of the conflict resolution
 Requirement management
51

 It is a set of activities that help the project team

to identify, control and track the requirements
and changes can be made to the requirements at
any time of the ongoing project.
 After finalizing the requirement traceability
table is developed.
 The examples of traceability table are the
features, sources, dependencies, subsystems and
interface of the requirement.
Thank You!