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.