This document discusses requirements elicitation techniques. It begins with an overview of requirements engineering activities like elicitation, analysis, representation, verification and management. It then covers various elicitation techniques like interviews, questionnaires, prototyping, scenarios, etc. and provides examples. Finally, it discusses grouping elicitation techniques and the relationships between different groups like interviews, domain-oriented, group-work techniques. The document aims to provide an overview of key requirements elicitation techniques.

1. Requirements Elicitation
Techniques
LECTURE 5

2. Recap
 Processes, Process Models and Process variability
 Coarse-grain activity models:
 Fine-grain activity models:
 Role-action models:
 RE Process – input and output
 Existing system info, user need, domain knowledge, org std, regulations
 Agreed Req, system specs, system models
 Req Elicitation Techniques
Muhammad Asif Saleem

3. Recap - Paper
 Elicitation Technique Selection:
 systems can be built with a high probability of resolving the Problems and satisfying the needs of customers and
users
 Elicitation is all about learning the needs of users, and communicating those needs to system builders
 Selection of elicitation technique is a key to success or failure.
 Effectiveness, availability, when, how, why
 Mass market research, customized or COTS
 Combinations of participants, problem domains, solution domains, and organizational contexts
• For each elicitation technique, there exists:
– a specific, unique, small set of predicates
concerning situational characteristics that drive
experts to seriously consider that technique.
• For collaborative sessions, the major drivers are
multiple stakeholders, disparate needs, and a demand
to reach consensus before proceeding
– a set of additional predicates which if true cause
experts to alter their primary choice. Known as
“Anomalies.”
• For collaborative sessions, the anomalies include
stakeholders who cannot know of each other’s
existence, geographical distribution of stakeholders or
no suitable venue
• For each elicitation technique, there exists:
– a set of basic analyst skills that must be present or
the technique will not be effective. Known as
“Prerequisite Skills.”
• For collaborative sessions, they include comm, leadership,
and the ability to facilitate meetings
– a set of additional skills that are not universally
needed, but that come into play during the
technique’s execution without pre-knowledge.
Known as “Success Enhancers.”
• For collaborative sessions, these include modeling, conflict
resolution, and creativity skills
Muhammad Asif Saleem

4. Requirements Engineering Activities
 Requirements elicitation/discovery
 Requirements analysis and reconciliation
 Requirements representation/modeling
 Requirements verification and validation
 Requirements management
 There are others, but these are the “major” ones
Muhammad Asif Saleem
• Requirements Elicitation/Discovery
– Involves uncovering what the customer needs
and wants
– Also involves discovering who the
stakeholders are (hidden stakeholders?)
– Don’t forget non-functional requirements!
• Requirements Analysis and Reconciliation
– Raw requirements don’t always make sense.
– Raw requirements often contradict one another (and
not always obviously so).
– Raw requirements are inconsistent
– Raw requirements are incomplete
– Raw requirements are vague or just wrong
– Raw requirements interact and are dependent on
each other
– Requirements analysis and reconciliation involves
techniques to deal with these problems.
• Requirements Representation
– Converting the requirements processed raw
requirements into some model (usual natural
language, math, and visualizations)
– Facilitates communication of requirements and
conversion into a system architecture and design
– Uses techniques that are
• Informal (e.g. natural language, diagrams)
• Formal (mathematically sound representation)
• Semi-formal (convertible to a sound representation or is partially
rigorous)
– Usually some combination of these are employed in
requirements representation
• Requirements Management
– Managing the realities of changing requirements over
time
– Fostering traceability through appropriate aggregation
and subordination of requirements
– Communicating changes in requirements to those
who need to know
– Intelligently providing “push back” when scope creep
ensues
– Using tools to track changes and maintain traceability

5. Elicitation Techniques*Brainstorming
Card Sorting
Domain Analysis
Ethnographic
Observation
Goal Based
Approaches
Group Work
Interviews
Introspection
JAD
Laddering
Protocol Analysis
Prototyping
Questionnaires
Repertory Grids
Scenarios
User Stories
Viewpoints
Workshops
Muhammad Asif S
*Based on a list by D. Zowghi and C. Coulin, “Requirements Elicitation: A Survey
of Techniques, Approaches, and Tools,” in Aurum and Wohlin, pp.19-46.

6. Brainstorming
 Informal gatherings with customers and other stakeholders:
 To generate overarching goals for the systems.
 Some preliminary requirements may be generated, but this aspect is secondary.
 JAD incorporates brainstorming
 Useful mostly for generating the mission statement
Muhammad Asif Saleem

7. Card Sorting
 Involves having stakeholders complete a set
of cards that include key information about
functionality ( may include ranking and
rationale)
 RE then organizes these cards in some manner
 The sorted carts can be used as an input to
the process to develop CRC (capability,
responsibility, class) cards to determine
program classes in the eventual code
Identify customer if
returning
Priority – high
Manage customer
loyalty feature
Priority – Medium
Prepare sales tax
reports
Priority – High
Apply sales tax to
non-food items
Priority – Medium
Update inventory
records
Priority – High
Inventory features
Tax functions
Customer management
Muhammad Asif Saleem

8. Domain Analysis
 Involves assessing the “landscape” of related and competing applications
 Can be useful in identifying essential functionality and later, missing functionality
 Can be used downstream for identifying reusable components (e.g. open source elements)
Muhammad Asif Saleem

9. Domain Requirements
Derived from the application
domain.
 May be:
New functional requirements.
Constraints on existing
functional requirements.
Specify how particular
computations must be
performed.
• Example
– For the baggage handling system, various
domain realities create requirements.
• Industry standards (you wouldn’t want the new
system to under perform versus other airlines’
systems)
• Constraints imposed by existing hardware
available (e.g. conveyor systems)
• Union contracts (there may be constraints based
on collective bargaining agreements)
Muhammad Asif Saleem

10. Ethnographic Observation
Based on detailed (at the level of a social
scientist) observations of human activity.
Involves long periods of observation
(hence, an objection)
Direct and indirect evidence is gathered
The work or activity itself
Evidence derived from the surroundings that
may not be communicated directly
• Example
• You are gathering requirements for a smart home for a
customer
• You spend long periods of time interviewing the customer
about what he wants
• You spend time interacting with the customer as he goes
about his day and ask questions (“why are you running the
air conditioner at night, why not in the morning?”)
• You spend long periods of time passively observing the
customer “in action” in their current home to get non-verbal
clues about his wants and desires
• You gain other information from the home itself – the books
on the book shelf, paintings on the wall, furniture styles,
evidence of hobbies, signs of wear and tear on various
appliances, etc.
Muhammad Asif Saleem

11. Goal Based Approaches
 Emanates from mission statement and provides lower level goals brought.
 Lower level goals are then branched out into specific high-level requirements
 High-level requirements then generate lower level ones
• Example Baggage Handling system:
• Mission Statement: “To automate all aspects of
baggage handling from passenger origin to
destination.”
• Goal 1: To completely automate the tracking
of baggage from check in to pick up
• Goal 2: To completely automate the routing
of baggage from check in counter to plane
• Goal 3: To reduce the amount of lost
luggage to .1%...
Muhammad Asif Saleem

12. Goals versus Requirements
A goal is something the business (or user) is trying to
achieve
Once business stakeholder decide on a strategy by
which they will achieve that goal, the business will
define requirements for the project that execute this
strategy
Some NFRs are difficult to define precisely making them difficult
to verify.
Should distinguish goals from NFRs
 Goal – a general intention of a stakeholder
The system should be easy to use by experienced operators
Verifiable NFR – statement using some objective measure.
Experienced operators shall be able to use all the system functions
after 2 hours of training
Muhammad Asif Saleem

13. Group Work
General term for any kind of group meetings
Difficult to organize and focus the many stakeholders
involved
Problems of openness and bluntness can occur
Certain individuals can dominate
Can lead to feelings of being “left out”
RE must be very skillful in leading these sessions to
avoid such problems
JAD is a subset of group work
Muhammad Asif Saleem

14. Interviews
Obvious and easy to use technique
Three kinds of interviews exist
Unstructured – conversational, can be hit-or-miss
based on skill of interviewer
Structured – uses pre-defined questions that have
been rigorously planned
Semi-structured – uses combination of the above
Care must be taken to ensure all of the right
questions are asked
Templates are very helpful when in employed
with interviewing
• Sample Interview Questions
• Name an essential feature of the system?
Why is this feature important?
• How important is this feature with respect to
other features?
• What other features are dependent of this
feature?
• What other features must be independent of
this feature?
• What other observations can you make about
this feature?
Muhammad Asif Saleem

15. Introspection
 Process of relying on Thinking, reasoning, and examining one‘s own thoughts or feelings.
 RE develops requirements based on what he “thinks” the customer wants
 Useful when the RE’s domain knowledge far exceeds the customers’
 Introspection is probably to be avoided in cases where the customer has experience in the domain
Muhammad Asif Saleem

16. Laddering
 Uses short prompting questions (“probes”) to elicit requirements
 Follow up questions dig deeper below the surface
 Assumes that information can be arranged in a hierarchical fashion
 Resultant information is then organized in some kind of tree structure
Muhammad Asif Saleem

17. Protocol Analysis
 Process where customers walk through the process that they are going to
automate
 Customers explicitly state the rationale for each step that is being taken
 Requirements Engineer is more passive in protocol analysis
Muhammad Asif Saleem

18. Prototyping
 Involves construction of models of the code in
order to discover new features
 Can involving working models (code) as well
as non-working (storyboards, GUIs)
 Code can be throwaway and non-throwaway
 Architects use prototyping in the manner
described previously
 Agile development consists of an ever
evolving non-throwaway prototype
Muhammad Asif Saleem

19. Questionnaires
 Straightforward technique consisting of survey
instruments
 Used at early stages to quickly define the scope
boundaries
 Survey questions can be closed (e.g. multiple
choice, true false) or open-ended
 Danger in over-scoping and under-scoping if
questions are not adequately framed
 Therefore, most useful when the domain is very
well understood by both stakeholders and RE
Muhammad Asif Saleem

20. Repertory Grids
Typically used when the customers are domain
experts
Involves a structured ranking system for various features
of the different entities in the system
Used for identification of agreement and disagreement
within stakeholder groups
Rows in the matrix represent system entities,
columns represent rankings based on each of the
stakeholders
Muhammad Asif Saleem

21. Scenarios
Informal descriptions of the system in use
Helps to provide a high level description of system
operation, classes of users, even exceptional
situations
Very useful when the domain is new
User stories are a form of scenario
Scenarios are stories which explain how a system might
be used. They should 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
Muhammad Asif Saleem

22. Scenario of Library System
• Log on to MCSLIB system
• Issue order document command
• Enter reference number of the required document
• Select a delivery option
• Log out from MCSLIB This sequence of events can be
illustrated in a diagram
Muhammad Asif Saleem

23. User Stories
 User stories are:
 short conversational text that are used for initial requirements discovery and project planning.
 widely used in conjunction with agile methodologies.
 written by the customers in terms of what the system needs to do for them and in their own “voice”.
 usually consist of two to four sentences written by the customer in their own terminology, usually on a three by five
inch card.
About 80 user stories is said to be appropriate for one system
increment or evolution, but the appropriate number will vary widely
depending on the application size and scope and development
methodology to be used (e.g. Agile versus incremental).
Muhammad Asif Saleem

24. Viewpoints
A way to organize information from the (point of view)
of different constituencies.
Various formats and applications for viewpoints in software
and systems engineering
In RE used for prioritization, agreement, and ordering of
requirements
Viewpoints incorporate a variety of information from
business domain, process models, functional
requirements specs, organizational models, etc.
Viewpoints are generated for each view, and then reconciled
using various approaches
Muhammad Asif Saleem

25. ViewpointsSommerville suggests the following components to
each view:
“A representation style which defines the notation used in
the specification.
A domain which is defined as ‘the area of concern
addressed by the viewpoint’.
A specification which is a model of a system expressed in
the defined style.
A work plan, with a process model, which defines how to
build and check the specification.
A work record which is a trace of the actions taken in
building, checking and modifying the specification.”
Muhammad Asif Saleem

26. Muhammad Asif Saleem
Identify Viewpoints in Baggage Handling System
• Baggage handling personnel
• Travelers
• Maintenance engineers
• Airport managers
• Regulatory agencies

27. Workshops
 Formal and informal gatherings of stakeholders to
hammer out requirements issues
 Formal workshops are well planned but can be
boring and tiring
 Informal workshops can be more lively, but
overlook important elements
 Waterfall style development emphasized multiple
workshops (critical reviews)
 Most commonly used in JAD
Muhammad Asif Saleem

28. Elicitation Techniques- summary
 Nuseibeh and Easterbrook (2000) have developed a classification of methods
according to the needs of the project.
 They divided the methods into six meta groups of:
 Traditional techniques,
 Group elicitation,
 Prototyping,
 Contextual techniques,
 Cognitive techniques, and
 Model-driven techniques.
Muhammad Asif Saleem

29. Elicitation Summary
All these techniques have advantages and
disadvantages (partially discussed)
Some are too general, some too specific, some rely too
much on stakeholder knowledge, some not enough,
etc.
Combination of techniques really the best way to go
We can group techniques in the following categories
(interviews, domain-oriented, group-work, ethnography,
prototyping, goals, scenarios, viewpoints)
Following tables show relationships between technique
groups
Muhammad Asif Saleem

30. Recap- Paper
 Towards the Unknown Unknowns:
 Req Elicitation is a mature area of RE, techniques are very well known and used but the process is still problematic.
 Challenge to Elicitation is to probes the boundaries of knowledge and who possesses it,-”Unknown-unknown”
 known knowns are clearly not a problem;
 known unknowns pose a process problem, since the analyst is aware of the type of required knowledge and is faced with the problem of
eliciting it from a stakeholder who may be unaware of it or have forgotten it.
Muhammad Asif Saleem

31. Recap- Paper
Unknown knowns are knowledge held by the stakeholder
and accessible to them, but not articulated
 Unknown unknowns, in which the analyst and stakeholder are unaware of the missing, but relevant, knowledge; it
isn’t accessible to either actor.
 This might be caused by a lack of domain knowledge on both sides or “tacit knowledge”
 For unknown unknowns, neither the analyst nor the stakeholder
can identify that there is missing knowledge, far less
identify what the missing knowledge is.
Muhammad Asif Saleem

32. Recap-PaperExploring Tacit knowledge
Identify Common Ground as accessible knowledge to
analyst and stakeholders
Contributes ‘tools for thought’ which can address the unknowns
problems and may uncover unknown concerns
Many traditional techniques the ability to detect the
known unknowns depends on the analyst’s plan and
the sampling strategy
Creative elicitation approaches directly address
unknown unknowns in the sense that the target
product is usually only partially known
Muhammad Asif Saleem