Chapter Three
Requirement Elicitation
1
Elicitation is the process of deriving the system
requirements through observation of existing systems,
discussions with potential users and customers, task
analysis, and so on.
In this activity, software engineers work with customers
and system end-users to find out
about the application domain
what services the system should provide
the required performance of the system
hardware constraints, and etc..
2
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. Application Problem to
During problem understanding, you Domain be solved
specialize and extend general domain
knowledge. Stakeholder
Business
Business Understanding: You must Needs and
context
understand how systems interact and constraints
contribute to overall business goals.
Understanding the needs of
stakeholders and constraints of
system:
You must understand in detail the specific
needs of people who require system
support in their work and constraints or
limitations of system.
3
1.The good requirements elicitation process-Elicitation stages
Objective setting: establish the overall organizational objectives:
determine why system may be necessary.
Background of knowledge acquisition: gather and understand
more background information about the system.
Knowledge organization: organize, prioritize and collate the
large amount of data collected in the previous phases.
Stakeholder requirements collection: involve system
stakeholders to discover their requirements
4
2. Elicitation Techniques
Specific techniques used to collect knowledge about
system requirements.
1.Interviews
2.Scenarios
3.Observations and social analysis
4.Soft systems methods
5.Requirements reuse
5
2.1.Interviews
The requirements engineer or analyst discusses the system
with different stakeholders and builds up an understanding
of their requirements.
Two 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.
Interviews
Requires preparation and good communication management
Interview as many stakeholders as possible: Not just clients
and users
6
Ask problem-oriented questions
Interviewing Essentials
1. Interviewers must be open-minded and should not
approach the interview with pre-conceived designs about
what is required.
2. Stakeholders must be given a starting point for discussion.
This can be a question, a requirements proposal or an
existing system.
3. Interviewers must be aware of organizational politics
many real requirements may not be discussed because of their
political suggestions.
7
Interviews – Objectives and Process
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(from different stakeholder)
Follow-up
8
Interviews – Planning and Preparation
Important to plan and prepare interviews
Set goals and objectives for the interview
Acquire background knowledge of the subject matter to
conduct an effective interview
• About the domain (vocabulary, problems...) but also about the
interviewee (work tasks, attitude...)
Prepare questions in advance, by subject
Organize the environment for conducting an effective
interview
Determine how the elicitation notes will be taken
(manually, audio, video, by whom…)
9
Interviews – Session
Make the interviewee comfortable and confident
Be polite and respectful!
Adjust to the interviewee
• You have your goals – be persistent but flexible
Interview several people at once to create synergy
Try to detect political aspects as they may influence the
said and the unsaid
10
Interviews – Elicitation Notes
Revise and complete the elicitation notes after the interview
Needs to be done soon after because they may forget what they
had told you.
Identify inconsistencies and address them in a follow-up
interview or by email
Keep all diagrams, charts, models created during the discussions
You are learning, so be precise
Pay attention to terminology
Use the interviewee’s terminology
Identify synonyms
Create a glossary if necessary
11
Common Interviewing Mistakes
Not interviewing all of the right people
• There are different points of view of stakeholders
Asking direct questions too early
• e.g., transportation system: How much horsepower do you need? (direct),
How many passengers? How far? How fast? (indirect)
Interviewing one-at-a-time instead of in small groups
Assuming that stated needs are exactly correct
Often users do not know exactly what they want and order
Trying to convince stakeholders that YOU are smart – wrong
place to do that!
12
Interviews – Start Up Questions
Context-free questions to narrow the scope a bit
Identify customers, goals, and benefits
Who is (really) behind the request for the system?
Who will use the system? Willingly?
Are there several types of users?
What is the potential economic benefit from a successful solution?
Is a (pre-existing) solution available from another source?
When do you need it by?
Can you prioritize your needs?
What are your constraints?
Time
Budget
Resources (human or otherwise)
Expected milestones (completion dates)?
13
Interviews – Start Up Questions (2)
Try to characterize the problem and its solution
What would be a "good" solution to the problem?
What problems are the system trying to address?
In what environment will the system be used?
Any special performance issues?
Other special constraints?
What is (un)likely to change?
Future evolution?
What needs to be flexible (vs. quick & dirty)?
Calibration and tracking questions
Are you the right person to answer these questions?
Are your answers "official"? If not, whose are?
Questions that cannot be asked directly (ask indirectly)
Are you opposed to the system?
Are you trying to obstruct/delay the system?
14
Interviews – Specific Questions (1)
Functional Requirements
What will the system do?
When will the system do it?
Are there several modes of operations?
What kinds of computations or data transformations must be performed?
What are the appropriate reactions to possible stimuli?
For both input and output, what should be the format of the data?
Must any data be retained for any period of time?
15
Interviews – Specific Questions (2)
Design Constraints
Physical environment
Where is the equipment to be located?
Is there one location or several?
Are there any environmental restrictions, such as temperature,
humidity, or magnetic interference?
Are there any constraints on the size of the system?
Are there any constraints on power, heating, or air conditioning?
Are there constraints on the programming language because of
existing software components?
16
Interviews – Specific Questions (3)
Design Constraints
Interfaces
Is input coming from one or more other systems?
Is output going to one or more other systems?
Is there a prescribed way in which input/output need
to be formatted?
Is there a prescribed way for storing data?
Is there a prescribed medium that the data must use?
Standards
Are there any standards relevant to the system?
17
Interviews – Specific Questions (4)
Performance
Are there constraints on execution speed, response time,
or throughput?
What efficiency measure will apply to resource usage and
response time?
How much data will flow through the system?
How often will data be received or sent?
Usability and Human Factors
What kind of training will be required for each type of user?
How easy should it be for a user to understand and use the system?
How difficult should it be for a user to misuse the system?
18
Interview the User
Interviewing is a common approach, but may not be the most
effective one.
Assumes users will know and be able to discuss their requirements
Questions often lead to specific answers and scope
Questionnaire
• Consider it as pre-work to a personal interview
Engage the user in the process so they are not passive
• Eg, Invite them in building models
19
Interview Structure
Set the interview in context to set scope and direction of discussion
Use business events as an anchor; work one event at a time
Ask a question, listen to the answer, then feed back your
understanding
Draw models and encourage user to change them
• Data flow models and work flow charts are effective
• Consider UML Activity Diagrams with data flow
Use the user’s terminology and artifacts, both conceptual and real
• Artifacts: papers, computers, meters, spreadsheets, machines,
instruction lists, software applications, etc.
• Avoid letting the user speak in technology/solution
Keep sample artifacts and documents
Thank the user for their time and tell them why it is valuable
20
2.2. Scenarios
A scenario is a scene or story that depicts user interaction
with a proposed system
(according to the UML) it is an instance of a use case
It expresses a specific occurrence of the use case (a specific
path through the use case)
• A specific actor ...
• At a specific time ...
• With specific data …
Many scenarios may be generated from a single use case description
21
Scenarios (2)
A use case includes primary and secondary scenarios
primary scenario
Normal course of events
secondary scenarios
Alternative/exceptional course of events, variations of primary scenario
An alternative scenario meets the intent of the use case but with a
different sequence of steps
An exceptional scenario addresses the conditions of main case and
alternative cases that differ from the norm and cases already covered
Example with consensus(general agreement) as a goal
Primary scenario: vote in a session
Alternative scenario: voting in several sessions
Exceptional scenario: what to do with a non-registrant who wishes to vote
22
2.3.Observation and social analysis
People sometimes find it hard to describe what they do.
The best way to understand such environment 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.
23
Ethnography Guidelines
Assume that people are good at doing their job and look for non-
standard ways of working.
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 or with other
elicitation techniques.
Organize regular de-briefing session where the ethnographer talks
with people outside the process.
24
2.4. Soft Systems Methods
They are qualitative techniques that applies system thinking to non-
systemic situations.
Devised to tackle unstructured and messy problems(b/c of d/t
perspective due to experiences, cultures, values, education.)
These produce informal models of a socio-technical system. They
consider the system, the people and the organization.
Do not use for detailed requirements elicitation. Rather, they are ways
of understanding a problem and its organizational context.
Software Systems Methodology (SSM) is probably the best known of
these methods.
• The essence of SSM is its recognition that systems are embedded in a
wider human and organizational context.
25
Stages of SSM
Problem situation assessment.
Problem situation description.
Abstract system definition from selected viewpoints.
Conceptual system modeling.
Model/real-world comparison.
Change identification.
• Recommendations for action. 26
2.5. 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.
27
Reuse Possibilities
Where the requirement is concerned with providing
application domain information.
Where the requirement is concerned with the style of
information presentation. Reuse leads to a consistency of
style across applications.
Where the requirement reflects company policies such as
security policies.
28
Elicitation Problems
Not enough time for elicitation.
Insufficient preparation by engineers.
Stakeholders are unconvinced of the need for a new
system.
29
Requirements analysis
• The goal of analysis is to discover problems, incompleteness
and inconsistencies in the elicited requirements. These are
then fed back to the stakeholders to resolve them through
the negotiation process.
• Analysis is inserted with elicitation as problems are
discovered when the requirements are elicited.
• A problem checklist may be used to support analysis. Each
requirement may be assessed against the checklist.
Analysis checklists
• 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
• 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
• A very important objective of requirements analysis is to
discover the interactions between requirements and to
highlight requirements conflicts and overlaps.
• A requirements interaction matrix shows how requirements
interact with each other. Requirements are listed along the
rows and columns of the matrix.
• 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
Interaction matrices
Requirements negotiation
• Disagreements about requirements are expected when a
system has many stakeholders. Conflicts are not ‘failures’
but reflect different stakeholder needs and priorities.
• Requirements negotiation is the process of discussing
requirements conflicts and reaching a compromise that all
stakeholders can agree to.
• In planning a requirements engineering process, it is
important to leave enough time for negotiation. Finding an
acceptable compromise can be time-consuming.
Negotiation meetings
• An information stage where the nature of the problems
associated with a requirement is explained.
• 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. Priorities may be assigned to
requirements at this 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.
