REQUIREMENTS ENGINEERING

JIMMA UNIVERSITY
JIMMA INSTITUTE OF TECHNOLOGY
FACULTY OF COMPUTING AND INFORMATICS

CHAPTER THREE
REQUIREMENT ELICITATION AND ANALYSIS
 Objectives
2

 Requirements Elicitation
 Components of Elicitation
 The requirements elicitation process
 Elicitation Techniques
 Requirements Analysis & Negotiation
 Activities for Requirements Analysis
 Requirement Analysis Techniques
 Activities for Requirements Negotiation
 Resolution of Requirements Conflicts
 Introduction
3

 Requirement elicitation is the process of collecting the

requirements of a system from users, customers and other

stakeholders.
 Determining requirement of a system or application through

consultation with stakeholders, from existing documents, domain

knowledge, and market studies.
 Requirements acquisition or requirements discovery
Components of Requirements Elicitation
4
 Components of Requirements Elicitation
5

1. Application domain understanding: Application domain

knowledge is knowledge of the general area where the system is
applied. For example, to understand the requirements for a
railway signaling system, you must have background knowledge
about the operation of railways and the physical characteristics
of trains.
2. Problem Understanding: The details of the specific
customer problem where the system will be applied must be
understood. Therefore, for a railway signaling system, you
must know the way in which speed limits are applied to
particular track segments.
 During problem understanding, you specialize and extend
general domain knowledge.
 Components of Requirements Elicitation
6

3. Business Understanding: Systems are generally intended to

contribute in some way to the development of a business or
organization.
 You must understand how these systems interact and affect the
different parts of the business and how they can contribute to
overall business goals.
4. Understanding the needs and constraints of system
stakeholders:
 System stakeholders are those people who are affected in some way
by the system.
 They may be end-users of the system, managers of departments
where the system is installed, etc.
 You must understand, in detail, their specific needs for system
support in their work.
Requirements Elicitation Process
7
 Requirements Elicitation Process
8

 A good requirements elicitation process should include four

critical activities.
1. Objective Setting: The overall organizational objectives
should be established at this stage. These include :
 General goals of the business
 An outline description of the problem to be solved
 An outline description of why the system may be
necessary
 An outline description of the milestones on the system
such as budget, schedule and inter-operability
constraints.
 Requirements Elicitation Process
9

2. Background knowledge acquisition: This is a very

important stage where the requirements engineers gather
and understand background information about the
system. This includes:
 Information about the organization where the system is
to be installed,
 Information about the application domain of the
system.
 Information about any existing systems which are in
use and which may be replaced by the system being
specified.
 Requirements Elicitation Process
10

3. Knowledge organization: The large amount of

knowledge which has been collected in the previous stage
must be organized and collated. This involves :
 Identifying system stakeholders and their roles in the
organization.
 Prioritizing the goals of the organization.
 Discarding domain knowledge which does not
contribute directly to the system requirements.
 Requirements Elicitation Process
11

4. Stakeholder requirements collection: It involves:

 Consulting system stakeholders to discover their
requirements
 Deriving requirements which come from the
application domain and the organization which is
acquiring the system.
 The output from the requirements elicitation process
should be a draft document which describes the system
requirements.
 This document is then analyzed to discover problems and
conflicts in the requirements definition.
 Elicitation Techniques
12

 Traditional techniques
 Introspection
 Analysis of Existing Systems

 Interviews

 Open-ended
 Structured
 Collaborative techniques
 Group techniques

 Focus Groups
 Brainstorming
 JAD workshops

 Prototyping
 Introspection
13

 Introspection is the first and the

most obvious technique for trying to
understand what properties a system
should have in order to succeed.
 Introspection is observing one’s
own thoughts and inner self.
 Analysts work for what they imagine
and observe by themselves how a
system design should be.
 It amounts to imagining what kind of
system I would want if I were doing
this job, using this equipment, etc.
 When is Introspection Appropriate?
14

 When users are not available, don’t want to answer your

questions or show lack of feedback , then Requirement
Engineer’s can use this technique to imagine the things which
he/she assumes that the user would require.
 when the users have little or no previous experience with
software systems in their work environment, a type of facilitation
introspection should take place.
 When is Introspection Effective?
15

 Introspection is only really effective when the analyst

is not only very familiar with the domain and goals of
the system, but also expert in the business processes
performed by the users.
 This technique is effective with users who have a lot
of experience of their own fields but have less
knowledge about the other fields as well as the new
system.
Pros and Cons of Introspection
16

Pros: Cons:
It is hard for analysts to imagine the
Introspection is an
environment in which the new system works.
easier technique to It doesn’t allow discussion with stakeholders
apply. and other experts.
There are almost no Therefore, it is not encouraged if not used in
costs for implementing combination with other techniques.
this technique. Analysts and stakeholders need to be well
It can act as a good known about the domain.
 Introspection can be very inaccurate at
initial step to start
times because Requirement Analyst imagines
requirements
what is required rather than asking from the
elicitation.
user what he requires.
This technique is unlikely to reflect the
stakeholder’s goals and actual user
experiences.
 Analysis of Existing Systems
17

 Useful when building a related or new improved

version of an existing system.
 Important to know:
 What is used, not used, or missing

 What works well, what does not work

 How the system is used (with frequency and importance)

and it was supposed to be used, and how we would like to
use it
 How the system can integrate with the existing related
systems
 Interview
18

 Requires preparation and good communication management

 Achieve interview objectives without preventing the exploration

of promising leads
 Interview as many stakeholders as possible

 Ask problem-oriented questions

 Stakeholders must be given a starting point for discussion (a

question, a requirements proposal, an existing system)

“When people talk, listen completely. Most people never listen”

 Different Interview Techniques
19

 Structured (closed) interviews

 Stakeholders answer a predefined set of questions
 Easy to analyze

 Well-formed questions generate well-formed answers (you

have to know your goals)
 Knowledge about what and how to ask

 Non-structured (open) interviews

 No predefined scope

 Generating new ideas (experimental, brain storming)

 sometimes hard to handle (dynamics of discussion)

 In practice: mixed interview types are normal

 Interviews – Objectives and Process
20

 Three main objectives:

 Record information to be used as input to requirements analysis
and modeling
 Discover information from interviewee accurately and efficiently
 Reassure interviewee that his/her understanding of the topic has
been explored, listened to, and valued
 Process consists of four important steps:
 Planning and preparation
 Interview session
 Consolidation of information
 Follow-up
 Collaborative Techniques: Group techniques
21

 In the group work, different stakeholders are invited to conduct the

group meeting in a collaboration to elicit the requirements of the
system to be developed.
 Two types:
 Focus Groups

 Brainstorming

 Focus Groups
 Is a gathering of people who are representative of the users or
customers of a product to get feedback.
 produces data and insights that would be less accessible without
interaction found in a group setting—listening to others’
verbalized experiences stimulates memories, ideas, and
experiences in participants
 Brainstorming
22
 Brainstorming refers to the process of systematic and liberal generation of a large
volume of ideas from a number of participants.
 used to identify possible solutions to problems, and clarify details of
opportunities.
 Early on in a project particularly when:
 There is little expertise for the type of applications

 Innovation is important (e.g., novel system)

 Two main activities:

 The Storm: Generating as many ideas as possible (quantity, not quality) – wild
is good!
 The Calm: Filtering out of ideas (combine, clarify,
prioritize, improve…) to keep the best one(s) –
may require some voting strategy
 Roles: scribe, moderator (may also provoke),
participants
Brainstorming Phases
23
 Joint Application Design (JAD)
24

 JAD a collaborative way to gather requirements across

people or groups connected to the project.
 Used for making decisions on different aspects of a project
 Any process where consensus-based decision making
across functional areas is required, e.g.,
 Planning a project

 Defining requirements

 Designing a solution

“Governed by 6 “P”s”
 The 6 “P”s
25

1. Purpose - Why do we do things? (Goals, needs,

motivation)
2. Participants - Who is involved? (People, roles,
responsibilities)
3. Principles - How do we function? (Guidelines, working
agreements, ground rules)
4. Products - What do we create? (Deliverables, decisions,
plans, next steps)
5. Place - Where is it located? (Venue, logistics)
6. Process - When do we do what? (Activities, sequence)
JAD
26

Participants
Session Leader
Users
Managers
Sponsor
Systems Analysts
Scribe
IS Staff
 Prototyping
27

 A software requirements prototype is a mock-up or partial implementation

of a software system
 Helps developers, users, and customers better understand system
requirements
 Helps clarify and complete requirements

 Provides early response to “I'll know it when I’ll see (or won’t see) it”
attitude
 Effective in addressing the “Yes, But” and the “Undiscovered Ruins”
syndromes
 Helps find new functionalities, discuss usability, and establish priorities

 Prototyping is effective in resolving uncertainties early in the development

process
 Focus prototype development on these uncertain parts

 Encourages user participation and mutual understanding

 28

Discussion

Sit with your groups and discuss, which elicitation techniques

will be used in your proposed system(Your assignment title)
and why?
 Requirements Analysis & Negotiation

29

“The objectives of requirement analysis & negotiation is to

establish an agreed set of requirements which are complete
and consistent.

HOW TO DO IT:
Requirements Analysis
30
 The goal of analysis is to
discover the interaction
between requirements and to
highlight problematic
requirements(Conflicting,
overlapping, unrealistic etc. )
in the draft document.
 Input - A draft system
requirements document
 Output –A requirement
document which contains a
set of problematic
requirements
 Conflict: negatively affect
each other
 Overlap: affect each other but
not necessarily a conflict
Example for conflicting and overlapping
requirements
31

 R1: The file server shall respond to requests within

0.8 seconds
 R2: The file server shall serve up to 300 connection
simultaneously
Are R1 and R2 conflicting or overlapping requirements?
 R3: The file server shall allow logged in users of storing up
to 1GB of data daily(total)
 R4: The file server shall allow each logged in user to store
up to 10MB of data daily
Are R3 and R4 conflicting or overlapping requirements?
Example for conflicting and overlapping
requirements
32

 R1: The file server shall respond to requests within 0.5 seconds
 R2: The file server shall serve up to 200 connection
 Simultaneously
R1 and R2 are conflicting requirements. Because the file server hardware
resources may prevent requirements from being satisfied
simultaneously.
 R3: The file server shall allow logged in users of storing up to 2GB of
data daily(total)
 R4: The file server shall allow each logged in user to store up to 20MB
of data daily
R3 and R4 are overlapping requirements(no conflict). Because R3 and R4
affect each other, R5 might be extracted.
R5: the file server shall allow up to 100 users to login daily.
 Requirements Analysis & Negotiation
33

 During analysis process

 Missing requirements  Activities aim to
 Unnecessary requirements
discover problems with
are discovered the system/application
 Requirements conflict
requirements and reach
 Ambiguous requirements
agreement on changes to
 Overlapping requirements satisfy all system
 Unrealistic requirements stakeholders.
 For conflicting & ambiguous  The analyst involved
requirements stakeholders read the requirements,
should negotiate and agree on highlight problems and
modifications and meet in a requirements
simplifications of the review to discuss the
requirements requirements.
Activities for Requirements Analysis
34
 Activities for Requirements Analysis
35

1. Necessity checking: Ask Why?

 The need for the requirement is analyzed.
 Root cause analysis
 Determine (recursively) the factors that contribute to
the problem(s) found by stakeholders
 In some cases, requirements may be proposed
which don't contribute to the business goals of the
organization or to the specific problem to be
addressed by the system.
 Activities for Requirements Analysis
36

2. Consistency and completeness checking: The requirements

are cross-checked for consistency and completeness(no
contradictions, no services or constraints are missed out).
 Consistency means that no requirements should be contradictory.
 Completeness means that no services or constraints which are
needed have been missed out (organization, appl domain,). No
postponed decision or “to be defined” statement still exist
3. Feasibility checking: The requirements are checked to ensure
that they are feasible in the context of the budget, users need and
schedule available for the system development.
 The output from the requirements analysis process may lead for
requirements negotiation.
 Analysis Techniques
37

 Analysis checklists
A checklist is a list of questions which analysts may use to
assess each requirement
 Interaction matrices
 Interaction matrices are used to discover interactions
between requirements and to highlight conflicts and
overlaps
 Analysis checklists
38

 A checklist is a list of questions which the analyst may use to

assess each requirements.
 Analysis checklists can be implemented as a Spreadsheet
 Row - requirements identifiers

 Column - checklist items

 Cell –comments about potential problems of certain

requirements
 When potential problems are discovered, these should be noted
carefully
 The questions should be general, rather than restrictive, which
can be irrelevant for most systems
 Analysis checklists
39

 Premature design: Does the requirement include premature

design or implementation information?
 Combined requirements : Does the description of a
requirement describe a single requirement or could it be broken
down into several different requirements?
 Unnecessary requirements: Is the requirement “gold
plating”? That is, is the requirement a cosmetic addition to the
system which is not really necessary.
 Use of non-standard hardware: Does the requirement
mean that non-standard hardware or software must be used? To
make this decision, you need to know the computer platform
requirements.
 Analysis checklists
40

 Conformance with business goals : Is the requirement

consistent with the business goals defined in the introduction to
the requirements document?
 Requirements ambiguity : Is the requirement ambiguous i.e.
could it be read in different ways by different people? What are
the possible interpretations of the requirement?
 Requirements realism :Is the requirement realistic given the
technology which will be used to implement the system?
 Requirements testability: Is the requirement testable, that is,
is it stated in such a way that test engineers can derive a test
which can show if the system meets that requirement?
 Requirements Interactions
41

 A requirements interaction matrix shows how requirements

interact with each other, which can be constructed using a
spreadsheet.
 Each requirement is compared with other requirements,
and the matrix is filled as follows:
 For requirements which conflict, fill in a 1

 For requirements which overlap, fill in a 1000

 For requirements which are independent, fill in a 0

 An Interaction Matrix
42

Requirement R1 R2 R3 R4 R5 R6
0 0 1000 0 1 1
R1
0 0 0 0 0 0
R2
1000 0 0 1000 0 1000
R3
0 0 1000 0 1 1
R4
1 0 0 1 0 0
R5
1 0 1000 1 0 0
R6
 An Example for Interaction Matrix
43

 In the example, we are considering, we can see that

R1 overlaps with R3 and conflicts with R5 and R6
 R2 is an independent requirement
 R3 overlaps with R1, R4, and R6
 Remember: If you can’t decide whether
requirements conflict, you should assume that a
conflict exists. If an error is made it is usually fairly
cheap to fix; it can be much more expensive to
resolve undetected conflicts.
 Interaction Matrix
44

 The advantage of using numeric values for conflicts and overlaps

is that you can sum each row and column to find the number of
conflicts and the number of overlaps.
 A large number of conflicts or overlaps means that any changes
to that requirement will probably have a major impact of the rest
of the requirements.
 Interaction matrices work only when there is relatively small
number of requirements, as each requirement is compared with
every other requirement
 Requirements Negotiation
45

 The goal requirements negotiation is to reach agreement on

changes to satisfy all system stakeholders.
 Requirements negotiation stage involves the different
stakeholders to solve the conflicts and overlaps and agree on a set
of requirements.
 Conflicts are not ‘failures’ but reflect different stakeholder
needs and priorities
 Input –a set of conflicting or overlapped requirements

 Output –a compromised set of requirements

 In planning a requirements engineering process, it is important

to leave enough time for negotiation. Finding an acceptable
compromise can be time-consuming.
Activities for Requirements Negotiation
46

1. Requirements discussion: Requirements which have

been highlighted as problematical are discussed and the
stakeholders involved present their views about the
requirements.
2. Requirements prioritization: Disputed requirements
are prioritized to identify critical requirements and to
help the decision making process.
3. Requirements agreement: Solutions to the
requirements problems are identified and a compromise
set of requirements is agreed.
 Why prioritize47requirements?

Discussion
 Why prioritize requirements?
48

 Limited
resources
 Schedule
 Budget
 Effort  Customer
Resources expectations are high
Requirements  Too many Reqs
 Changing Reqs
 Conflicting Reqs

All requirements are mandatory, but some are essential/critical

while others are not.
 Resolution of Requirements Conflicts
49

 Meetings are the most effective way to negotiate requirements and

resolve requirements conflicts
 All requirements which are in conflict should be discussed individually
 Negotiation meetings should be conducted in three stages
1. Information stage: An information stage where the nature of the
problems associated with a requirement is explained
2. Discussion stage: A discussion stage where the stakeholders
involved discuss how these problems might be resolved. All
stakeholders with an interest in the requirement should be given the
opportunity to comment.
3. Resolution stage: A resolution stage where actions concerning the
requirement are agreed. These actions might be to delete the
requirement, to suggest specific modifications to the requirement or
to elicit further information about the requirement.
Any Question?

50