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. ViewpointsSommerville 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-PaperExploring 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