Requirement Elicitation

Chapter 7
Requirements Elicitation
 Elicit means to gather, acquire, extract, obtain, or discover etc.
 Requirements elicitation means gathering requirements or discovering
requirements
 Elicitation is the process of discovering the requirements for a system by
communication with customers, system users and others who have a stake in
the system development.
 Elicitation is concerned with learning and understanding of the needs of users
and project sponsors with the ultimate aim of communicating those needs to the
system developers
 Activities involved in discovering the requirements for the system require
 Knowledge Acquisition
 Reading
 Interviewing
 Listening
 Asking
 Observing etc.
Requirements Elicitation
 Requirement elicitation is the most difficult, most critical, most error prone
and communicative intensive activity. It focuses on following aspects:
 Elicitation objectives
 Exploring use cases
 Validating market data
 Elicitation strategies
 Some combination of surveys, workshops, customer visits,
individual interviews, and other techniques
Sources for Requirement Elicitation
 Interviews and discussions with potential users
 Documents that describe current or competing products
 System requirements specifications
 Problem reports and enhancement requests for a current system
 Marketing Survey and user questionnaires
 Observing users at work
 Events and responses etc.
Requirement Elicitation Problems
 Requirements elicitation is a complex and imprecise process that varies
greatly for different projects
 Understanding large and complex system requirements is difficult
 Study by Beichter indicate that 70% of the systems errors are due to
inadequate system specification
 Many technical problems are related to this process
 Scope problems
 Problems related to the process itself
 Many problems pertaining to human nature
Requirement Elicitation Problems
 Problems of Scope
 Boundary of system is not well defined
 Problems of understanding
 Users have incomplete understanding of their needs;
analysts have poor knowledge of the problem domain
 Conflicting requirements
 Difficult to express
 A Savant Institute study found that “56% of errors in
installed systems were due to poor communication
between user and analyst in defining requirements
 Problems of volatility
 Requirements evolve over time
 Elicitation process should not be executed only once
Elicitation Problems
Elicitation Techniques

 Traditional
 Collaborative
 Knowledge
 Contextual
Traditional Techniques

 Introspection
 Requires analyst to develop requirements based on what he/she
believes the users and stakeholders want and need from the system
 Starting point for other elicitation techniques
 Is used when analyst is quite familiar with goals and objectives and
also expert in business processes performed by the user
 Reading Existing Documents
 Company reports, policy manuals, org-charts, etc.
 Analyzing hard data
 Facts and figures, financial information, reports used for decision
making, survey results, marketing data, etc.
Document Analysis
 Document analysis entails examining any existing documentation for potential
software requirements.
 The most useful documentation includes requirements specifications, business
processes, lessons-learned collections, and user manuals for existing or
similar applications.
 Documents can describe corporate or industry standards that must be
followed or regulations with which the product must comply.
 When replacing an existing system, past documentation can reveal
functionality that might need to be retained, as well as obsolete
functionality.
 For packaged-solution implementations, the vendor documentation mentions
functionality that your users might need, but you might have to further
explore just how to implement it in the target environment.
Document Analysis

 Comparative reviews point out shortcomings in other products that you could
address to gain a competitive advantage.
 Problem reports and enhancement requests collected from users by help desk
and field support personnel can offer ideas for improving the system in future
releases.
 Document analysis is a way to get up to speed on an existing system or a new
domain.
 Doing some research and drafting some requirements beforehand reduces the
elicitation meeting time needed.
 Document analysis can reveal information people don’t tell you, either
because they don’t think of it or because they aren’t aware of it.
Traditional Techniques (Interviews)
 Types:  The requirements engineer or analyst discusses
 Structured the system with different stakeholders and
builds up an understanding of their
 Open-ended (for exploration, limited requirements
domain understanding)
 Planning is very important before going for
 Advantages: conducting interview
 Rich collection of information
 Interviews are less effective for understanding
 Can probe in depth and adopt follow-up the application domain and the organizational
questions issues due to terminology and political factors
 Disadvantages
 Interview must be planned and scheduled
 Large amounts of qualitative data can
be hard to analyze  Interviewers must be open-minded and should
 Hard to compare different respondents
not approach the interview with pre-conceived
notions about what is required
 Too much detail in some areas and
ignore others (open-ended)  Stakeholders must be given a starting point for
discussion. This can be a question, a
 Limit the investigation of new ideas requirements proposal or an existing system
(structured)
 It is a difficult skill to master  Interviewers must be aware of organizational
politics. Many real requirements may not be
 Watch for: discussed because of their political
 Unanswerable questions implications
 Removal from context
 Interviewer’s attitude may cause bias
Traditional Techniques (Surveys/Questionnaires)
used during early stages of RE and may consist of open/closed questions
 Advantages:
 Can quickly collect info from large number of people
 Can be administered remotely
 Can collect attitudes, beliefs, characteristics
 Information checklist – fundamental elements are being addressed
 Disadvantages
 No room for users to convey their real needs
 Lack the opportunity to convey new ideas
 No mechanism for participants to request clarification or correct misunderstanding
 Watch for:
 Bias in sample selection, Bias in self selecting respondents
 Small sample size, Leading or ambiguous or open-ended questions
 Questionnaires are used when we want to gather requirements from peoples who are far
away and large in number
 Format of questionnaire should be user friendly and comprehensible
 Can quickly collect info from large numbers of people
 Avoid open ended and ambiguous questions in questionnaire
 Ask short, precise, rating scale, ranking scale , interactive type of questions
 Success depends on the return rate
 Use double envelope method
Traditional Techniques (cont..)

 Meetings
 Used for summarization and feedback
 Meet with stakeholders towards the end of each stage
 Are an important managerial tool
 Used to move a system development project forward
 Needto determine the objectives for the meeting:
presentation, problem solving, conflict resolution, etc.
 Planthe meeting carefully: agenda, time,
presentation/discussion, follow-up summary to be distributed
Collaborative Techniques
Group Elicitation Techniques  Brainstorming involves both idea generation and idea
 Focus groups reduction
 Brainstorming  Stakeholders come up with creative ideas or new approaches
to a problem
 Advantages
 The most creative, innovative ideas often result from
 More natural interaction between combining, seemingly unrelated ideas
people than formal interview
 Promotes free thinking  Generate as many ideas as possible, combine ideas, reduce
ideas and prioritize ideas
 Discover new solutions
 Disadvantages  Various voting techniques may be used to prioritize the ideas
created
 May create unnatural groups
 to engage in informal discussion to rapidly generate as many
 Danger of groupthink ideas as possible without focusing on any one in particular;
 Requires a highly trained facilitator avoid exploring or critiquing ideas in great detail
 Watch for  A focus group is a form of qualitative research in which a
group of people are asked about their attitude towards a
 Sample bias product, service, concept, advertisement, idea, or packaging.
 Dominance and submission Questions are asked in an interactive group setting where
participants are free to talk with other group members.
 Highly political situations
 A moderator guides the group through a discussion that probes
attitudes about a client's proposed products or services. The
discussion is loosely structured, and the moderator encourages
the free flow of ideas. The moderator is typically given a list of
objectives or an anticipated outline. He/she will generally have
only a few specific questions prepared prior to the focus group.
These questions will serve to initiate open-ended discussions.
Collaborative Techniques (JAD)

Joint Application Development (JAD)

 Involvesall the available stakeholders to discuss
problems and suggest solutions
 Main goals of the system have already been established
 Focus on the needs of business and users rather
technical issues
 Advantages
 Sessions very well structured with defined steps,
actions and roles of participants
 With all parties present decisions can be made quickly
Collaborative Techniques (Prototyping)
Provides stakeholders with prototypes of the system to support the
investigation of possible solutions to gather detailed information and
relevant feedback
 A prototype is an initial version of a system which may be used for
experimentation
 Prototype may be a quick rough version of the system
 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
 Advantages
 Encourage stakeholders to play an active role in developing the
requirements
 Useful when stakeholders are unfamiliar with the available solutions
 Disadvantages
 Expensive to produce
 User become attached with prototype and may be resistant to
alternative solutions
Knowledge Elicitation Techniques in
RE
 Concerned with discovering expert knowledge
 Originally focused on deriving expert’s “rules” or
Rule-based Systems
 More recently focused on “problem-solving methods”
 But KE is hard
 Separation of domain knowledge from performance
knowledge
 Modeling problems
 Representational problems
 Expert Bias
KE Techniques: Card Sorting

 Eliciting Domain Knowledge

 Card sorting - for a given set of domain objects, written on cards:
 Stakeholders sort the cards containing the domain entities into groups
 Explain the rationale for the way in which the cards are sorted
 Possible only when the domain is well understood by both the analyst and the participants
 Cards are used to assign responsibilities to users and components of the system
 CRC: Class responsibilities collaboration
Contextual Approaches (Ethnographic
Techniques)
 Participant Observation
 Study of people in their natural setting, involves the analyst actively or passively
participating in the normal activities of the users over an extended period of time
whilst collecting info on the operations being performed.
 What methods people use to make sense of the world around them
 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 an extended time observing people at work and building
up a picture of how work is done
 Ethno-methodology
 Looks for behaviors that may be different in a specific culture but which have the
same underlying purpose or meaning (e.g. gaining status)
Elicitation Workshops
 Requirement analyst frequently facilitates elicitation workshops. The
following guidelines are followed during elicitation workshops.
 Set the ground rules
 Stay in scope
 Setting parking lots for latter discussions
 Time box discussions
 Keep team small and select appropriate members
 Keep everyone engaged
 Set an agenda before the workshop and publish it along with the other pre-
workshop documentation.
 Balance is the key, try to stay on the agenda, but do not strictly obey it,
especially if good discussion is going on
 Allow for human behavior, and have fun with it.
 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
 Studies have shown that similar systems can re-use up to 80% of the
requirements
 Currently, requirements reuse is an informal process but more systematic
reuse could lead to larger cost savings
 Reuse reduces risk. Reused requirements have a better chance of being
understood by all the stakeholders.
 Requirements reuse may lead to additional reuse in other lifecycle
activities.
Scenarios
 Scenarios are stories which explain how a system might be used. They
include
 A description of the system state before entering the scenario
 The normal flow of events in the scenario
 Exceptions to the normal flow of events
 Information about concurrent activities
 A description of the system state at the end of the scenario
 Scenarios are examples of interaction sessions which describe how a user
interacts with a system
Comparison of selected Elicitation
Techniques

[, Rogers, and Sharp “Interaction Design: Beyond human-computer interaction”, p1] Preece214
Elicitation Techniques by Project
Characteristic
Finding Missing Requirements
 Decompose high level requirements into details
 Check each user class represents input
 Represents requirements in multiple ways
 Check boundary value analysis
 Use decision tables and trees instead of boolean logic
Activities to prepare for a single
elicitation session
Preparing for Elicitation

 Plan session scope and agenda

 Prepare resources
 Learn about the stakeholders
 Prepare questions
 Prepare straw man models: Analysis models-use cases and process flows.
Create straw man, or draft, models ahead of your elicitation sessions. A straw
man serves as a starting point that helps you learn about the topic and
inspires your users to think of ideas. It is easier to revise a draft model than
to create one from scratch.
Performing Elicitation Activities
 Educate stakeholders
 Take good notes
 Exploit the physical space
 Facilitate collaborative sessions

Following up after elicitation

 Organizing and sharing the notes
 Documenting open issues
Classifying Customer Input

 Don’t expect your customers to

present a succinct, complete, and
well-organized list of their needs.
 Analysts must classify the myriad
bits of requirements information
they hear into various categories
so that they can document and use
it appropriately.
Business Requirements

 “Increase market share in region X by Y percent within Z months.”

 “Save $X per year on electricity now wasted by inefficient units.”

User Requirements
 “I need to print a mailing label for a package.”
 “As the lead machine operator, I need to calibrate the pump controller first
thing every morning.”
Business Rules

 Phrases such as “Must comply with . . . ,” “If <some condition is true>, then
<something happens>,” or “Must be calculated according to . . . ” suggest
that the user is describing a business rule. Here are some examples:
 “A new client must pay 30 percent of the estimated consulting fee and travel
expenses in advance.”
 “Time-off approvals must comply with the company’s HR vacation policy.”
Functional Requirements

 “If the pressure exceeds 40.0 psi, the high-pressure warning light should
come on.”
 “The user must be able to sort the project list in forward and reverse
alphabetical order.”

Quality Attributes
 Listen for words that describe desirable system characteristics: fast, easy,
user-friendly, reliable, secure
 “The mobile software must respond quickly to touch commands.”
 “The shopping cart mechanism has to be simple to use so my new customers
don’t abandon the purchase.”
External Interface Requirements

 Phrases such as “Must read signals from . . . ,” “Must send messages to . . . ,”

“Must be able to read files in <format>,” and “User interface elements must
conform to <a standard>” indicate that the customer is describing an external
interface requirement.
 “The manufacturing execution system must control the wafer sorter.”
 “The mobile app should send the check image to the bank after I photograph
the check I’m depositing.”
Constraints
 Phrases that indicate that the customer is describing a design or
implementation constraint include: “Must be written in <a specific
programming language>,” “Cannot exceed <some limit>,” and “Must use <a
specific user interface control>.”
 “Files submitted electronically cannot exceed 10 MB in size.”
 “The browser must use 256-bit encryption for all secure transactions.”

Data Requirements
 “The ZIP code has five digits, followed by an optional hyphen and four digits
that default to 0000.”
 “An order consists of the customer’s identity, shipping information, and one or
more products, each of which includes the product number, number of units,
unit price, and total price.”