Chapter two

Requirements Elicitation

Lalise D. SWEG 2020 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..

Lalise D. SWEG 2020 2

Components of requirements elicitation
• Application domain understanding :
• Application domain knowledge is
knowledge of the general area
where the system is applied.
• Example 1 : understand the
requirements for a cataloguing
Stakeholder
Application
Problem to Domain
be solved
system, you must have a general Business context
Needs and constraints
knowledge of libraries and how
libraries work.
• Example 2 : understand the
requirements for a railway
signaling system, you must have
a background knowledge about
the operation of railways and the
physical characteristics of Lalise
trains.
D. SWEG 2020 3
Components of requirements elicitation
• Problem understanding:
• The details of the specific customer
problem where the system will be
applied must be understood.
• Example 1 : for a cataloguing
system, you must understand how
Stakeholder
Application
Problem to context
Domain
be solved
a particular library categorizes its Business
Needs and constraints
collection.
• Example 2 : 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.
Lalise D. SWEG 2020 4
Components of requirements elicitation
• Business understanding: You
must understand how systems
interact and contribute to
overall business goals.
• Understanding the needs of
stakeholders and constraints of
Stakeholder
Application
Problem to context
Domain
be solved
system: Business
Needs and constraints

• You must understand, in detail,

the specific needs of people who
require system support in their
work and constraints or
limitations of system.

Lalise D. SWEG 2020 5

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.
Lalise D. SWEG 2020 6
The good requirements elicitation process-Elicitation stages

• 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.
Lalise D. SWEG 2020 7
2. Elicitation techniques
• Specific techniques which may be used to collect knowledge
about system requirements.

1.Interviews.
2.Scenarios.
3.Observations and social analysis.
4.Soft systems methods.
5.Requirements reuse.

Lalise D. SWEG 2020 8

 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.
Lalise D. SWEG 2020 9
 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.

Lalise D. SWEG 2020 10

Interviews
• Requires preparation and good communication
management
• Interview as many stakeholders as possible
• Not just clients and users
• Ask problem-oriented questions
• Ask about specific details,
but…
• Detailed and solution-specific questions may miss the
stakeholder’s real requirements. Example:
• Would you like Word 2007, Excel 2007 or both?
vs.
• Would you like to do word processing, computations, or
both?
Lalise D. SWEG 2020 11
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
Lalise D. SWEG 2020 12
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…)
Lalise D. SWEG 2020 13
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
Lalise D. SWEG 2020 14
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
Lalise D. SWEG 2020 15
Common Interviewing Mistakes (1)

• Not interviewing all of the right people

• There are different points of view of stakeholders

• Asking direct questions too early

• e.g., design of a transportation system:

• How much horsepower do you need? (direct)
• How many passengers? How far? How fast? (indirect)

Lalise D. SWEG 2020 16

Common Interviewing Mistakes (2)
• Interviewing one-at-a-time instead of in small groups

• More people might help get juices flowing as in brainstorming

• Users cannot think of everything they need when asked
individually, but will recall more requirements when they hear
others' needs.
• This reduces spotlight on individuals (may produce more
interesting answers)
• This interaction is called synergy, the effect by which group
responses outperform the sum of the individuals' responses
• Therefore, do not let one participant dominate the discussion

• Assuming that stated needs are exactly correct

• Often users do not know exactly what they want and order
Lalise D. SWEG 2020 17
Common Interviewing Mistakes (3)

• Trying to convince stakeholders that YOU are smart – wrong

place to do that!
• Instead take every opportunity to show you think the stakeholder is
smart
• Contrast these two cases1 My Elevators
Are
Too Slow!

I See.
Tell Me Why I Don’t Think So.
You Feel They I Think You Have an
Are Too Slow. Elevator Throughput
Problem, not a Speed
Problem

Lalise D. SWEG 2020 18

Interviews – Start Up Questions (1)
• 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?

Lalise D. SWEG 2020 19
Interviews – Start Up Questions (2)

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)?

Lalise D. SWEG 2020 20

Interviews – Start Up Questions (3)
Try to characterize the problem and its solution
• What would be a "good" solution to the problem?
• What problems is 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)?

Lalise D. SWEG 2020 21

Interviews – Start Up Questions (4)
Calibration and tracking questions
• Are you the right person to answer these questions?
• Are your answers "official"? If not, whose are?
• Are these questions relevant to the problem as you
see it?
• Are there too many questions? Is this the correct level
of detail?
• Is there anyone else I should talk to?
• Is there anything else I should be asking you? Have
you told me everything you know about the problem?
• Do you have any questions?

Lalise D. SWEG 2020 22

Interviews – Start Up Questions (5)
Questions that cannot be asked directly (ask indirectly)
• Are you opposed to the system?
• Are you trying to obstruct/delay the system?
• Are you trying to create a more important role for
yourself?
• Do you feel threatened by the proposed system?
• Are you trying to protect your job?
• Is your job threatened by the new system?
• Is anyone else's?

Lalise D. SWEG 2020 23

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?

Lalise D. SWEG 2020 24

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?

Lalise D. SWEG 2020 25

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?
Lalise D. SWEG 2020 26
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?

Lalise D. SWEG 2020 27

Interviews – Specific Questions (5)
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?

Lalise D. SWEG 2020 28

Interviews – Specific Questions (6)
Security
• Must access to the system or information be controlled?

• Should each user's data be isolated from data of other

users?

• Should user programs be isolated from other programs

and from the operating system?

• Should precautions be taken against theft or vandalism?

Lalise D. SWEG 2020 29

Interviews – Specific Questions (7)
Reliability and Availability
• Must the system detect and isolate faults?

• What is the prescribed mean time between failures?

• Is there a maximum time allowed for restarting the system

after failure?

• How often will the system be backed up?

• Must backup copies be stored at a different location?

• Should precautions be taken against fire or water damage?

Lalise D. SWEG 2020 30
Interviews – Specific Questions (8)
Maintainability
• Will maintenance merely correct errors, or will it
also include improving the system?

• When and in what ways might the system be

changed in the future?

• How easy should it be to add features to the

system?

• How easy should it be to port the system from

one platform (computer, operating system) to
another? Lalise D. SWEG 2020 31
Interviews – Specific Questions (9)

Precision and Accuracy

• How accurate must data calculations be?

• To what degree of precision must calculations be

made?

Lalise D. SWEG 2020 32

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

Lalise D. SWEG 2020 33

 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 andLalise
tell them
D. SWEG 2020 why it is valuable 34
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

Lalise D. SWEG 2020 35

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
Lalise D. SWEG 2020 36
• Exceptional scenario: what to do with a non-registrant who wishes to vote
Representation of Scenarios
Text (informal, formal), diagrams (state, sequence ...),
video, animation, comics , storyboard….
• Different representations may be useful in specific situations

• For example, storyboards, often used in the film industry, can

describe situations, roles, and sequences of tasks in a fast,
compact, and polyglot way.

Lalise D. SWEG 2020 37

Example- Library scenario - document ordering

1. The user Log in to Electronic Document Delivery-The

Integrated Solution (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.

This sequence of events can be illustrated in a diagram.

Lalise D. SWEG 2020 38

Library Scenarios

Lalise D. SWEG 2020 39

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. 40
Lalise D. SWEG 2020
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.
41
Lalise D. SWEG 2020
 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
Lalise D.context.
SWEG 2020 42
 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.

Lalise D. SWEG 2020 43
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.

Lalise D. SWEG 2020 44

 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.

Lalise D. SWEG 2020 45

Elicitation problems:
• Not enough time for elicitation.

• Insufficient preparation by engineers.

• Stakeholders are unconvinced of the need for a new

system.

Lalise D. SWEG 2020 46