Chapter 5

Requirements Elicitation and Analysis

Software Development Process:
Classify Requirements Elicitation

Requirements System Detailed Implemen-

Analysis Testing
Elicitation Design Design tation
cont.

Requirements System Detailed Implemen-

Analysis Testing
Elicitation Design Design tation

Use Case
Model
Cont.

Requirements System Detailed Implemen-

Analysis Testing
Elicitation Design Design tation

Expressed in
terms of

Use Case Application

Model Domain
Objects
Cont.

Requirements System Detailed Implemen-

Analysis Testing
Elicitation Design Design tation

Expressed in Structured
terms of by

Use Case Application

Domain Sub-
Model
Objects systems
Cont.

Requirements System Detailed Implemen-

Analysis Testing
Elicitation Design Design tation

Expressed in Structured
Realized by
terms of by

Use Case Application Solution

Domain Sub-
Model Domain
Objects systems
Objects
Cont.

Requirements System Detailed Implemen-

Analysis Testing
Elicitation Design Design tation

Implemented by
Expressed in Structured
Realized by
terms of by

class...
class...
class...
Use Case Application Solution
Domain Sub- Source
Model Domain
Objects systems Code
Objects
Cont.

Requirements System Detailed Implemen-

Analysis Testing
Elicitation Design Design tation

Implemented by
Expressed in Structured
Realized by Verified
terms of by
By
class...
class... ?
class... ?
class....
Use Case Application Solution
Domain Sub- Source Test
Model Domain
Objects systems Code Cases
Objects
Cont.

Requirements System Detailed Implemen-

Analysis Testing
Elicitation Design Design tation

Implemented
Expressed in By
Structured By Realized By
Terms Of Verified
By

class...
class...
class... ?
class.... ?
Use Case Application Solution
Domain Subsystems Source Test
Model Domain
Objects Code Cases
Objects
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 Application Problem to
requirements for a cataloguing Domain be solved
system, you must have a general
knowledge of libraries and how Stakeholder
Business
libraries work. Needs and
constraints
context

• 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
trains.
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 Application Problem to
system, you must understand how Domain be solved

a particular library categorizes its

Stakeholder
collection. Needs and
Business
context
constraints
• 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.
Components of requirements elicitation
• Business understanding: You
must understand how systems
interact and contribute to
overall business goals.
• Understanding the needs and Application Problem to
Domain be solved
constraints of system
stakeholders: Stakeholder
Business
• You must understand, in detail, Needs and
constraints
context

the specific needs of people

who require system support in
their work.
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.
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.
Elicitation, analysis and negotiation: Yet another view on RE( spiral)
Process of Requirements Elicitation: Products of Requirements
Process
Requirements analysis and negotiation-Analysis checks

• Necessity checking:
• Sometimes requirements don’t contribute to the business goals of
the organization or to the specific problem to be addressed by the
system.
• Consistency and completeness checking:
• Cross-checking for consistency and completeness (no
contradictions, no services or constraints are missed out).
• Feasibility checking:
• the context of the budget and schedule.
Requirements negotiation

• Requirements discussion:
• Requirements highlighted as problematical are discussed.
• The stakeholders involved present their views about the
requirements.
• Requirements prioritization:
• Identification of critical requirements.
• Requirements agreement:
• A compromised set of requirements are agreed.
• A changes to some of the requirements.
2. Elicitation techniques
• Specific techniques which may be used to collect knowledge
about system requirements.
• This knowledge must be structured:
• Partitioning - aggregating related knowledge.
• Abstraction - recognizing generalities.
• Projection - organizing according to perspective.
• Elicitation problems:
• Not enough time for elicitation.
• Insufficient preparation by engineers.
• Stakeholders are unconvinced of the need for a new
system.
Specific elicitation techniques

• 1.Interviews.
• 2.Scenarios.
• 3.Observations and social analysis.
• 4.Soft systems methods.
• 5.Requirements reuse.
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.
Interviewing essentials-two
• 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.
• Interviewers must be aware of organizational politics many
real requirements may not be discussed because of their
political suggestions.
Interviews
• Requires preparation and good communication
management
• Achieve interview objectives without preventing the
exploration of promising leads
• 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?
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
• Follow-up
• Many strategies for questioning
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…)
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
Interviews – Elicitation Notes
• Revise and complete the elicitation notes after the interview
• Needs to be done soon after because one forgets the details (and
everything else)
• 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
Common Interviewing Mistakes (1)

• Not interviewing all of the right people

• 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)
• e.g., camera design for novice photographer:
• How important is control over shutter speed and aperture?
(direct)
• Will you be taking action shots, still shots, or both? (indirect)
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
• 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
• 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 "what
he is eating"
• Need to narrow what is asked for down to what is needed
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
Interviews – Start Up Questions (1)

• Context-free questions to narrow the scope a bit

(Weinberg)
• 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?
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 (deliverables and dates)?
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)?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
Interviews – Specific Questions (9)

Precision and Accuracy

• How accurate must data calculations be?
• To what degree of precision must calculations be made?
Interview the User

• Interviewing is a common approach, but may not be most

effective

• 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

• Interactively build models, for example
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
2. Scenarios

• A scenario (according to the UML) 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
• Each scenario may require many test cases
• Rather used in a generic way in this course (as is often the
case in requirements engineering)
Scenarios (2)

• A use case includes primary and secondary scenarios

• 1 primary scenario
• Normal course of events
• 0 or more 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 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
Representation of Scenarios (1)

Various approaches
• Text (informal, formal), diagrams (state, sequence ...),
video, animation, comics, storyboard, collaborative
workshops (pass the microphone or the ball)…
• There are specialized notation such as UML (sequence,
activity, use case, interaction, and collaboration
diagrams), Message Sequence Charts (MSC), Live
Sequence Charts, and Use Case Maps (UCM)
Representation of Scenarios (2)

• 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
way1

• Some scenario-based approaches are very ideological or dogmatic

Library scenario - document ordering- Example
• 1. The user Log on to Electronic Document Delivery project
(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.
Library Scenarios
2.3.Observation and social analysis
• 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.
Ethnography guidelines
• 1. Assume that people are good at doing their job and look
for non-standard ways of working.
• 2. Spend time getting to know the people and establish a
trust relationship.
• 3. Keep detailed notes of all work practices. Analyze them
and draw conclusions from them.
• 4. Combine observation with open-ended interviewing.
• 5.Organize regular de-briefing session where the
ethnographer talks with people outside the process.
• 6. Combine ethnography with other elicitation techniques.
Ethnography in elicitation

Ethnographic Debriefing Focused

analysis meetings ethnography

System
System
prototype
prototyping

User
experiments
Ethnographic viewpoints
• The work setting viewpoint:
• This describes the context and the physical location of the work
and how people use objects to carry out tasks. Therefore, in a
study of a help desk (say), this would describe the objects which
the helper had to hand and how these were organized.
• Social and organizational perspectives:
• This tries to bring out the day-to-day experience of work as seen
by different people who are involved. Each individual typically sees
the work in a different ways and this viewpoint tries to organize
and integrate all of these perceptions.
• The workflow viewpoint:
• This viewpoint presents the work from a series of work activities
with information flowing from one activity to another.
2.4. Soft Systems methods
• These produce informal models of a social-technical system.
They consider the system, the people and the organization.
• Not techniques 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.
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
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.
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.
3. Prototyping
• 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
criticize.
• Rapid development of prototypes is essential so that they
are available early in the elicitation process.
Prototyping benefits
• 1.The prototype allows users to experiment and discover
what they really need to support their work.
• 2.Establishes feasibility and usefulness before high
development costs are incurred.
• 3.Essential for developing the ‘look and feel’ of a user
interface.
• 4.Can be used for system testing and the development of
documentation.
• 5.Forces a detailed study of the requirements which reveals
inconsistencies and errors.
Types of prototyping
• 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
• 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
• 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
• Fourth generation languages based around database
systems.
• Visual programming languages such as Visual Basic or
Object Works.
• Internet-based prototyping solutions based on World Wide
Web browsers and languages such as Java.
4. 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.