Requirements Elicitation
Section Two
Version: 1.0
Mehr 1386
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
1
Components of requirements elicitation
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
What
2
Elicitation activities
How
• 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.
• Business understanding
– You must understand how systems interact and contribute to
overall business goals.
• Understanding the needs and constraints of
system stakeholders
– You must understand, in detail, the specific needs of people who
require system support in their work.
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
3
The requirements elicitation process
How
Establish objectives
Understand background
Organise knowledge
Collect requirements
Business
goals
Organisational
structure
Stakeholder
identification
Stakeholder
requirements
Goal
prioritisation
Domain
requirements
Domain
knowledge
filtering
Organisational
requirements
Problem to be
solved
Application
domain
System
constraints
Existing
systems
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
4
Elicitation stages
How
• Objective setting
–
–
–
–
general goals of the business,
an outline description of the problem to be solved,
why the system is necessary
the constraints on the system.
• Background knowledge acquisition
– information about the organization where the system is to be installed
– the application domain of the system and information about existing
systems
• Knowledge organization
– The large amount of knowledge which has been collected in the
previous stage must be organized and collated.
• Stakeholder requirements collection
– System stakeholders are consulted to discover their requirements
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
5
Exercise
• What is the relationship between process
stages and elicitation activities?
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
6
Requirements analysis and negotiation
How
Requ irements analysis
Necessity
checking
Unnecessary
requirements
Requirements
discussion
Consistency and
completeness
checking
Conflicting and
incomplete
requirements
Requirements
prioritisation
Feasibility
checking
Infeasible
requirements
Requirements
agreement
Requ irements negotiation
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
7
Elicitation, analysis and negotiation
How
Draft
statement of
requirements
Requirements
elicitation
Requirements
analysis
Requirements
problems
Requirements
document
Requirements
negotiation
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
8
Elicitation activities
•
•
•
•
How
Application domain understanding
Problem understanding
Business understanding
Understanding stakeholders needs
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
9
Application Domain Understanding
What
• The process by which a software engineer
learns about the domain to better understand
the problem:
– The domain is the general field of business or
technology in which the clients will use the software
– A domain expert is a person who has a deep
knowledge of the domain
• Benefits of performing domain analysis:
– Faster development
– Better system
– Anticipation of extensions
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
10
Domain Analysis Outputs
What
 Business Vocabulary
 General knowledge about the domain
 Customers and users
 Environment
 Tasks and procedures currently
performed
 Competing software
 Similarities to other domains
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
11
Elicitation activities
•
•
•
•
How
Application domain understanding
Problem understanding
Business understanding
Understanding stakeholders needs
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
12
Gain Agreement on Problems
How
• What is the problem?
– We technologists tend to rush headlong into solution
providing - rather than taking time to truly understand
the problem
– Suggestion: Write it down, see if you can get everyone
to agree on it
• What is the problem, really?
– Searching for root causes - or the “problem behind the
problem” - often leads to a clearer understanding of the
real problem
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
13
Problem Understanding
What
• A problem can be expressed as:
– A difficulty the users or customers are facing,
– Or as an opportunity that will result in some benefit
such as improved productivity or sales.
• The solution to the problem normally will entail
developing software
• A good problem statement is short and succinct
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
14
Analyzing the Problem: Overview
Problem
Why
Problem
Space
Needs
Features
Solution
Space
Software
Requirements
The
Product
To Be
Built
Test
Procedures
Design
User
Docs
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
15
Why Is Analyzing the Problem Important?
Why
• To avoid the “Yes, …, but ….”
“Yes, {it meets the requirements},
but {it doesn’t solve my problem}.”
• Problem analysis time is on top of the pyramid
– It pays big dividends if you do it up front
• Analysis work is transferable

Problem Statement

Subject is customer
“I need to …”

Requirement Statement

Subject is system
“The system provides …”
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
16
Definition of a Problem
What
“A problem can be defined as the
difference between
{Problem}
things as
perceived
and
things as
desired”
Gause & Weinberg, 1989
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
17
Problems
What
• Problems are undesirable situations that
prevent the organization from fully achieving its
purpose, goals, and/or objectives.
• Opportunities are chances to improve the
organization even in the absence of specific
problems.
• Directives are new requirements that are
imposed by management, government, or some
external influence.
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
18
The PIECES Problem-Solving Framework
P
the need to improve performance
I
the need to improve information (and
data)
E
the need to improve economics, control
costs, or increase profits
C
the need to improve control or security
E
the need to improve efficiency of people
and processes
S
the need to improve service to customers,
suppliers, partners, employees, etc.
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
What
19
Problem Statement
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
How
20
Ishikawa Diagram
What
• The Ishikawa diagram is a graphical tool used to
identify, explore, and depict problems and the causes
and effects of those problems.
• It is often referred to as a cause-and-effect diagram or a
fishbone diagram.
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
21
Cause-and-Effect Analysis
What
– Cause-and-effect analysis is a technique in which
problems are studied to determine their causes and
effects.
– In practice, effects can be symptomatic of more
deeply rooted or basic problems which, in turn, must
be analyzed for causes and effects until such a time
as the causes and effects do not yield symptoms of
other problems.
– List contributing causes to the identified problem.
– Keep asking “Why?” (expand each rib). How
much does each contribute?
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
22
What Is the Problem Being Solved?
How
Fishbone Diagram: One Method for Root-Cause Analysis
in Solving our Sample Problem
Our Customer’s
Stated Problem:
We Need
Recycling
Machines
Here
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
23
Focus on the Largest Contributors
How
% Contribution
Pareto Diagram
50
45
40
35
30
25
20
15
10
5
0
Too Much Litter
Too Hard to Recycle
Now
Environmental
Impact
Limited Natural
Resources
People Can Make
Money
Other Reasons
Contributing Causes
Rank in order and use the 80-20 Rule to focus on the top contributing
causes to address the greatest portion of the problem.
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
24
Elicitation activities
•
•
•
•
How
Application domain understanding
Problem understanding
Business understanding
Understanding stakeholders needs
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
25
System Improvement Objectives
What
An objective is a measure of success. It is something that you
expect to achieve, if given sufficient resources.
• Reduce the number of uncollectible customer accounts by 50
percent within the next year.
• Increase by 25 percent the number of loan applications that can be
processed during an eight-hour shift.
• Decrease by 50 percent the time required to reschedule a
production lot when a workstation malfunctions.
A constraint is something that will limit your flexibility in
defining a solution to your objectives. Essentially, constraints
cannot be changed.
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
26
Identify Constraints
Political
What
Economic
Environmental
Technical
Feasibility
System
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
27
Cause-and-Effect / System Improvement
Objectives
How
PROBLEMS, OPPORTUNITIES, OBJECTIVES, AND CONSTRAINTS MATRIX
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
28
Analysis checks
•
Necessity checking
–
•
The need for the requirement is analysed. In some cases,
requirements may be proposed which don’t contribute to the
business goals of the organisation or to the specific problem to be
addressed by the system.
Consistency and completeness checking
–
–
–
•
How
The requirements are cross-checked for consistency and
completeness.
Consistency means that no requirements should be contradictory
completeness means that no services or constraints which are
needed have been missed out.
Feasibility checking
–
The requirements are checked to ensure that they are feasible in
the context of the budget and schedule available for the system
development.
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
29
Requirements negotiation
How
• Requirements discussion
– Requirements which have been highlighted as
problematical are discussed and the stakeholders
involved present their views about the
requirements.
• Requirements prioritisation
– Disputed requirements are prioritised to identify
critical requirements and to help the decision
making process.
• Requirements agreement
– Solutions to the requirements problems are
identified and a compromise set of requirements
are agreed. Generally, this will involve making
changes to some of the requirements.
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
30
Elicitation activities
•
•
•
•
How
Application domain understanding
Problem understanding
Business understanding
Understanding stakeholders needs
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
31
Understanding Stakeholder Needs - Overview
I need …
Problem
What
Problem
Space
Needs
Features
Solution
Space
Software
Requirements
The
Product
To Be
Built
Test
Procedures
Design
User
Docs
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
32
What
What Are Sources for Our Requirements?
Requirement Specs
Business Plans
Personal Goals
Business Models
Partners
Customer
Analyst
Users
Bug Reports
Change Requests
Domain Experts
Problem Domain
Industry Analysts
Site Visits
Competitive info.
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
33
% of Target Domain Customers
What Are The Characteristics of Our Customers? What
35%
Technology Adoption
Profile
“Crossing the
CHASM”
30%
25%
20%
15%
10%
5%
0%
INNOVATORS
EARLY ADOPTERS
• Technical
• Have money
Influence
• Strong Influence
• No Money
• Specific features
• Discontinuous
innovation
• Company specific
Time
(the lifecycle of the technology)
EARLY MAJORITY
• Pragmatists
• Mission critical
systems
• Reliability
• Whole product
solutions
LATE MAJORITY
• Conservatives
• Price sensitive
• Simplify
• Commodity
• Demanding
LAGGARDS
• Skeptics
• Price
Moore, 1991
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
34
What Problems Might Be Encountered?
How
• Stakeholders know what they want but may not
be able to articulate it.
• Stakeholders may not know what they want.
• Stakeholders think they know what they want
until you give them what they said they wanted.
• Analysts think they understand user problems
better than users.
• Everybody believes everybody else is politically
motivated.
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
35
What Does This Process Look Like?
How
Ad hoc requirements
Requirements Spec
Rejected
Reworked Spec
Rejected
Customer
Reworked again
Development
Approved !
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
36
Elicitation techniques
What
• Specific techniques which may be used to
collect knowledge about system requirements
• This knowledge must be structured
– Partitioning - aggregating related knowledge
– Abstraction - recognising generalities
– Projection - organising according to perspective
• Elicitation problems
– Not enough time for elicitation
– Inadequate preparation by engineers
– Stakeholders are unconvinced of the need for a
new system
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
37
Techniques for Eliciting Stakeholder Needs
•
•
•
•
•
•
•
•
•
•
•
•
What
Document study
Observation
Work Sampling
Interviews
Questionnaires
Prototyping
Join Requirement Planning
Brainstorming & Idea Reduction
Use Cases
Role Playing
Business Modeling
Reviewing Customer Requirement Specifications
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
38
Document Study
• Developing a good feel for the system by
studying existing documentation, forms,
and files.
• A good analyst always gets facts first from
existing documentation.
• Organization chart (The first document the
analyst should seek out)
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
39
Documents that should be studied
• Documents that describe the problem
• Documents that describe the business
functions
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
40
Documents that Describe the Problem
• Interoffice memoranda, studies, memos,
suggestions, customer complaints, and
reports that document the problem area.
• Accounting records, performance reviews,
work measurements reviews and
operating reports.
• Past and Present Information systems
project requests.
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
41
Documentation of previous system studies
•
•
•
•
•
•
Various types of flowcharts and diagrams
Project dictionaries
Design documentation
Program documentation
Computer operations manuals
Training manuals
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
42
Documents that describe the business function
• The company’s mission statement and strategic
plan
• Formal objectives for the organization subunits
• Policy manuals that may place constraints
• Quality Manuals (ISO 9001,…)
• Standard Operating Procedures, job outlines, or
task instructions
• Completed forms
• Samples of manual and computerized
databases
• Samples of manual and computerized screens
and reports
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
43
Observation
How
Observation is a fact-finding technique
wherein the systems analyst either
participates in or watches a person
perform activities to learn about the
system.
Advantages?
Disadvantages?
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
44
Observation Guidelines
What
• Determine the who, what, where, when, why, and
how of the observation.
• Obtain permission from appropriate supervisors or
managers.
• Inform those who will be observed of the purpose of
the observation.
• Keep a low profile.
• Take notes during or immediately following the
observation.
• Review observation notes with appropriate
individuals.
• Don't interrupt the individuals at work.
• Don't focus heavily on trivial activities.
• Don't make assumptions.
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
45
Techniques for Eliciting Stakeholder Needs
•
•
•
•
•
•
•
•
•
•
•
•
What
Document study
Observation
Work Sampling
Interviews
Questionnaires
Prototyping
Join Requirement Planning
Brainstorming & Idea Reduction
Use Cases
Role Playing
Business Modeling
Reviewing Customer Requirement Specifications
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
46
Work Sampling
What
• Work sampling is a fact-finding technique that
involves a large number of observations taken at
random intervals.
• Sampling is the process of collecting a
representative sample of documents, forms, and
records.
– Determining the sample size:
• Sample Size = 0.25 x (Certainty factor/Acceptable error)2
– For a 90% certainty:
• Sample Size = 0.25(1.645/0.10)2 = 68
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
47
Sampling Techniques
How
Randomization is a sampling technique
characterized as having no predetermined
pattern or plan for selecting sample data.
Stratification is a systematic sampling technique
that attempts to reduce the variance of the
estimates by spreading out the sampling—for
example, choosing documents or records by
formula—and by avoiding very high or low
estimates.
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
48
Techniques for Eliciting Stakeholder Needs
•
•
•
•
•
•
•
•
•
•
•
•
What
Document study
Observation
Work Sampling
Interviews
Questionnaires
Prototyping
Join Requirement Planning
Brainstorming & Idea Reduction
Use Cases
Role Playing
Business Modeling
Reviewing Customer Requirement Specifications
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
49
Interviews
What
• A direct technique that can be used in both
problem analysis and requirements elicitation
• Designed to gain an understanding of real
problems and potential solutions from the
perspectives of the users, customers, and other
stakeholders
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
50
Types of Interviews
What
Unstructured interviews are conducted with only
a general goal or subject in mind and with few, if
any, specific questions. The interviewer counts
on the interviewee to provide a framework and
direct the conversation.
In structured interviews the interviewer has a
specific set of questions to ask of the
interviewee.
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
51
Types of Interview Questions
What
Open-ended questions allow the
interviewee to respond in any way that
seems appropriate.
Closed-ended questions restrict answers
to either specific choices or short, direct
responses.
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
52
Interview Questions
What
• Types of Questions to Avoid
– Loaded questions
– Leading questions
– Biased questions
• Interview Question Guidelines
–
–
–
–
–
Use clear and concise language.
Don’t include your opinion as part of the question.
Avoid long or complex questions.
Avoid threatening questions.
Don’t use “you” when you mean a group of people.
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
53
The Context-Free Question
What
• The context-free question is a high-level,
abstract question that can be posed early in a
project to obtain information about global
properties of the user’s problem and potential
solutions.
• Context-free questions:
– Are always appropriate
– Help you understand stakeholder perspectives
– Are not biased with solutions knowledge
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
54
The Context-Free User Questions
What
Roles:
• Who is the customer?
• Who is the user?
• Are their needs different?
• What are their backgrounds, capabilities,
environments?
Use as input when defining actors for Use
Cases
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
55
Context-Free Process Questions
What
Problems:
• What is the problem?
• What is the reason for wanting to solve this
problem?
• Are there other reasons for wanting to solve this
problem?
• What is the value of a successful solution?
• How do you solve the problem now?
• What is the trade-off between time and value?
• Where else can the solution to this problem be
found?
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
56
Context-Free Product Questions
What
Product:
• What problem does this product solve?
• What business problems could this product
create?
• What hazards could exist for the user?
• What environment will the product encounter?
• What are your expectations for usability?
• What are your expectations for reliability?
• What performance/precision is required?
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
57
Context-Free Meta-questions
What
Interview:
• Am I asking too many questions?
• Do my questions seem relevant?
• Are you the right person to answer these
questions?
• Are your answers requirements?
• Can I ask more questions later?
• Would you be willing to participate in a
requirements review?
• Is there anything else I should be asking you?
Gause & Weinberg, 1989
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
58
Interviews: Non-Context-Free Examples
What
• Leading questions
– You need a larger screen, don’t you?
• Self answering questions
– Are fifty items about right?
• Controlling statements
– Can we get back to my questions?
• Too long-too complex
– I have a three part question, ...
What are better questions to ask?
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
59
Interviews: Warning
What
• Don't ask people to describe things they don’t usually
describe.
– Assumes that users can describe complex activities
– Example: tying your shoelace
– In general, people can do many things they cannot
describe
– Empirical evidence - poor correlation
• Ask open-ended questions
• Avoid questions that begin with “Why…?”
– Can provoke a defensive posture
• Don’t expect simple answers
• Don’t rush the interviewee for answers Listen, listen,
listen!
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
60
Procedure to Conduct an Interview
How
1.Select Interviewees
2.Prepare for the Interview
1.An interview guide is a checklist of specific
questions the interviewer will ask the
interviewee.
3.Conduct the Interview
4.Follow Up on the Interview
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
61
Sample Interview Guide
How
Interviewee: Jeff Bentley, Accounts Receivable Manager
Date:
Tuesday, March, 23, 2000
Time:
1:30 P.M.
Place:
Room 223, Admin. Bldg.
Subject:
Current Credit-Checking Policy
Time
Allocated
Interviewer
Question of Objective
Interviewee
Response
1 to 2 min. Objective
Open the interview:
• Introduce Ourselves
• Thank Mr. Bentley for his valuable time
• State the purpose of the interview--to obtain an
understanding of the existing credit-checking policies
5 min.
Question 1
What conditions determine whether a customer’s order is
approvedfor credit?
Follow-up
5 min.
Question 2
What are the possible decisions or actions that might be
taken once these conditions have been evaluated?
Follow-up
3 min.
Question 3
How are customers notified when credit is not approved
for their order?
Follow-up
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
(continued)
62
Sample Interview Guide (concluded)
1 min.
Question 4
After a new order is approved for credit and placed in the
file containing orders that can be filled, a customer might
request that a modification be made to the order. Would
the order have to go through credit approval again if the
new total order cost exceeds the original cost?
Follow-up
1 min.
Question 5
Who are the individuals that perform the credit checks?
Follow-up
How
1 to 3 mins. Question 6
May I have permission to talk to those individuals to learn
specifically how they carry out the credit-checking process?
Follow-up
1 min.
Objective
Conclude the interview:
• Thank Mr. Bentley for his cooperation and assure him
that he will be receiving a copy of what transpired during
the interview
21 minutes Time allotted for base questions and objectives.
9 minutes
Time allotted for follow-up questions and redirection
30 minutes Total time allotted for interview (1:30 p.m. to 2:00 p.m.)
General Comments and Notes:
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
63
Techniques for Eliciting Stakeholder Needs
•
•
•
•
•
•
•
•
•
•
•
•
What
Document study
Observation
Work Sampling
Interviews
Questionnaires
Prototyping
Join Requirement Planning
Brainstorming & Idea Reduction
Use Cases
Role Playing
Business Modeling
Reviewing Customer Requirement Specifications
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
64
Questionnaires
What
Questionnaires are special-purpose documents
that allow the analyst to collect information and
opinions from respondents.
– Advantages?
– Disadvantages?
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
65
Types of Questionnaires
What
Free-format questionnaires offer the respondent
greater area in the answer.
A question is asked, and the respondent records
the answer in the space provided after the
question.
Fixed-format questionnaires contain questions
that require selection of predefined responses
from individuals.
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
66
Types of Fixed-Format Questions
What
• Multiple-choice questions
• Rating questions
• Ranking questions
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
67
Questionnaire Procedure
How
1. Determine what facts and opinions must be
collected and from whom you should get them.
2. Based on the needed facts and opinions,
determine whether free- or fixed-format
questions will produce the best answers.
3. Write the questions.
4. Test the questions on a small sample of
respondents.
5. Duplicate and distribute the questionnaire.
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
68
Techniques for Eliciting Stakeholder Needs
•
•
•
•
•
•
•
•
•
•
•
•
•
What
Document study
Observation
Work Sampling
Interviews
Questionnaires
Prototyping
Join Requirement Planning
Requirements Workshop
Brainstorming & Idea Reduction
Use Cases
Role Playing
Business Modeling
Reviewing Customer Requirement Specifications
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
69
Prototyping
What
• 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
criticise
• Rapid development of prototypes is essential so
that they are available early in the elicitation
process
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
70
Types of prototyping
What
• Throw-away prototyping
– To elicit requirements
– Use for the requirements which cause most
difficulties to customers and which are the hardest
to understand.
• Evolutionary prototyping
–
intended to deliver a workable system quickly to
the customer.
– Use for well-understood requirements and which
can deliver useful end-user functionality.
– After extensive use poorly understood requirements
should be implemented.
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
71
Prototyping costs and problems
What
• 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
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
72
Techniques for Eliciting Stakeholder Needs
•
•
•
•
•
•
•
•
•
•
•
•
What
Document study
Observation
Work Sampling
Interviews
Questionnaires
Prototyping
Join Requirement Planning
Brainstorming & Idea Reduction
Use Cases
Role Playing
Business Modeling
Reviewing Customer Requirement Specifications
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
73
Joint Requirements Planning
What
• Joint requirements planning (JRP) is a process
whereby highly structured group meetings are
conducted for the purpose of analyzing
problems and defining requirements.
• JRP is a subset of a more comprehensive joint
application development (JAD) technique that
encompasses the entire systems development
process.
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
74
Requirements Workshops
How
• Accelerate the Elicitation Process
• Gathers all stakeholders together for an
intensive, focused period
• Facilitator runs the meeting
• Everyone gets their say
• Results immediately available
• Provide a framework for
applying the other elicitation
techniques we will be
discussing
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
75
Benefits of JRP
Why
• JRP actively involves users and management in
the development project (encouraging them to
take “ownership” in the project)
• JRP reduces the amount of time required to
develop systems
• When JRP incorporates prototyping as a means
for confirming requirements and obtaining
design approvals, the benefits of prototyping are
realized
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
76
JRP Participants
•
•
•
•
•
What
Sponsor
Facilitator
Users and Managers
Scribes
IT Staff
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
77
Workshops: Planning and Executing
PRE
WORKSHOP
•Sell the
workshop
•Establish team
•Handle logistics
•Issue warm-up
material
•Prepare agenda
How
SESSION
PRODUCTION
FOLLOW-UP
•Facilitate
•Keep on track
•Record findings
•Summarize
conclusions
• Synthesize
findings
• Condense info
•Present to
customer
•Determine next
steps
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
78
How
Typical room layout for JRP session
41' 0"
Food & Refreshments
IT Professionals & Other Observers
Scribe
Flipchart
Workstation
(for CASE tool)
Users
and
Managers
Computer
Projection
Device
30' 0"
Scribe
Blackboard
Overhead Projector
JAD
Facilitator
Printer
Workstation
(for prototyping tool)
IT Professionals & Other Observers
Scribe
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
79
Guidelines for Conducting a JRP Session
•
•
•
•
•
•
•
•
How
Do not unreasonably change the list of questions
Stay on schedule
Ensure that the secretary is able to take notes
Avoid the use of technical words and phrases
Apply conflict resolution skills
Allow for breaks
Encourage group opinion
Encourage user and management participation
without allowing individuals to dominate the session
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
80
Workshops: Tricks of the Trade
Problem
Hard to get restarted after
breaks
Pointed criticism - petty
biases, turf wars, politics
and cheap shots
Grandstanding,
domineering positions,
uneven input from
participants
Flagging energy after
lunch
How
Solution
“Late From Break” ticket,
Kitchen timer, Charitable
contribution box ($1 after
ticket used)
“1 Free Cheap Shot”
ticket, “That’s a Great
Idea!!” ticket
Trained facilitator, “Five
Minute Position
Statement”
Light lunches, breaks,
coffee, soda, candies,
cookies, rearrange room,
change temperature
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
81
Techniques for Eliciting Stakeholder Needs
•
•
•
•
•
•
•
•
•
•
•
•
What
Document study
Observation
Work Sampling
Interviews
Questionnaires
Prototyping
Join Requirement Planning
Brainstorming & Idea Reduction
Use Cases
Role Playing
Business Modeling
Reviewing Customer Requirement Specifications
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
82
Brainstorming
What
• Brainstorming is a technique for generating
ideas during group meetings.
• Participants are encouraged to generate as
many ideas as possible
– in a short period of time
– without any analysis until all the ideas have been
exhausted.
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
83
Rules of Brainstorming
•
•
•
•
•
How
Clearly state the objective of the session
Generate as many ideas as possible
Let your imagination soar
Do not allow criticism or debate
prune and combine ideas
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
84
Brainstorming Exercise
How
1. Prepare
– Stack of Post-Its for each participant
– Large markers for all
2. Gather Ideas
– Write it down
– Shout it out
– Facilitator posts on board
3. Prune Ideas
– Combine like ideas
– Eliminate outrageous ideas
4. Organize Ideas
– Move the cards around
– Could organize by FURPS
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
85
Brainstorming: Idea Reduction
•
•
•
•
How
Discard redundant and outrageous ideas
Store “needs more development” ideas
Mix ideas
Prioritize those that remain
– Vote
• Single vote
• Cumulative voting
– By features
– Apply evaluation criteria
• Non-weighted
• Weighted
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
86
Brainstorming Guidelines
How
• Isolate the appropriate people in a place that will be
free from distractions and interruptions
• Make sure that everyone understands the purpose of
the meeting
• Appoint one person to record ideas
• Remind everyone of the brainstorming rules
• Within a specified time period, team members call
out their ideas as quickly as they can think of them
• After the group has run out of ideas and all ideas
have been recorded, then and only then should the
ideas be analyzed and evaluated
• Refine, combine, and improve the ideas that were
generated earlier
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
87
Techniques for Eliciting Stakeholder Needs
•
•
•
•
•
•
•
•
•
•
•
•
What
Document study
Observation
Work Sampling
Interviews
Questionnaires
Prototyping
Join Requirement Planning
Brainstorming & Idea Reduction
Use Cases
Role Playing
Business Modeling
Reviewing Customer Requirement Specifications
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
88
How Can a Use-Case Model Elicit Needs?
•
•
•
•
•
How
Discuss with customer what the system will do
Identify who will interact with the system
Identify what interfaces the system should have
Help verify that no requirements are missing
Verify that developers understand requirements
Use-Case Model
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
89
What Is a Use Case?
A
use case
defines a
sequence of
actions
performed by a
system that yields
an observable
result of value to
an actor
What
A use case describes a set (class) of
possible executions of the system
• A specific execution (instance) of a use
case is a scenario
• Work on the class level to identify and
describe the use case
Set of atomic activities, decisions, and
requests
• May be performed fully or not at all
• Started by actor
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
90
What
What Is a Use Case?
A use case
defines a
sequence of
actions
performed by a
system
Describes functions of the system
that yields an
observable result
of value
To avoid too detailed use cases
to
an actor
To avoid too complex use cases
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
91
What
Define System Boundaries and Functions
A Simple Phone System
Caller
Place Local Call
Callee
Place Long Distance Call
Long Distance
Provider
Customer
Bill Customer
Billing Manager
A model of what the system does and who it does it for
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
92
Useful Questions in Identifying Use Cases
Use Case
How
• What are the primary tasks the actor
wants the system to perform?
• Will the actor create, store, change,
remove, or read data in the system?
• Will the actor need to inform the
system about sudden, external
changes?
• Does the actor need to be informed
about certain occurrences in the
system?
• Will the actor perform a system
startup or termination?
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
93
A Use-Case Model Diagram
What
A Recycling Machine
Customer
Recycle Items
Operator
Print Daily Report
Change Refund Values
Manager
Add New Bottle Type
A model of what the system is supposed to do (use
cases), and the system's surroundings (actors).
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
94
Techniques for Eliciting Stakeholder Needs
•
•
•
•
•
•
•
•
•
•
•
•
What
Document study
Observation
Work Sampling
Interviews
Questionnaires
Prototyping
Join Requirement Planning
Brainstorming & Idea Reduction
Use Cases
Role Playing
Business Modeling
Reviewing Customer Requirement Specifications
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
95
Role Playing
How
• Tools and Techniques
– Scripted walkthroughs
– Scenario analysis
– Class Responsibility Collaboration
(CRC) Cards
• Have the analyst play the role of user or
customer to gain real insights into the problem
domain
• Have the customer play the role of a user to
understand the problems they may face
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
96
Techniques for Eliciting Stakeholder Needs
•
•
•
•
•
•
•
•
•
•
•
•
What
Document study
Observation
Work Sampling
Interviews
Questionnaires
Prototyping
Join Requirement Planning
Brainstorming & Idea Reduction
Use Cases
Role Playing
Business Modeling
Reviewing Customer Requirement Specifications
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
97
Business Modeling
Why
• Modeling, understanding, and improving a
business.
• A business model provides a static view of
the structure of the organization and a
dynamic view of the processes within the
organization.
• We need to model the business to localize
problems or identify opportunities for
improvements.
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
98
Why Business Modeling?
Why
• To understand current problems in the target
organization and identify improvement
potentials.
• To assess the impact of organizational change.
• To ensure that customers, end users,
developers, and other parties have a common
understanding of the organization.
• To derive the software system requirements
needed to support the target organization.
• To understand how a to-be-deployed software
system fits into the organization.
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
99
Business Modeling Discipline
• Assess the current organization and
develop a vision of the new organization.
• Defines the processes, roles, and
responsibilities of that organization
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
100
Business Modeling Artifacts in RUP
• The RUP provides a process for business
modeling.
• The Unified Modeling Language (UML)
can be effectively applied to modeling both
software and a business.
• Business Modeling Artifacts:
– Business use-case model
– Business-analysis model.
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
101
Business Modeling Scenarios
• Organization Chart: Building a simple map
of the organization and its processes to
get a better understanding of what the
requirements are on the application.
• Domain Modeling
• One Business Many Systems
• Generic Business Model
• Generic Business Model
• Revamp
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
102
Business Modeling Workflow in
RUP
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
103
Business Models Provide Input to Systems
What
• What should business models show?
– Business Processes
– Organizational structure
– Roles and responsibilities
 Products
 Deliveries
 Events
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
104
Techniques for Eliciting Stakeholder Needs
•
•
•
•
•
•
•
•
•
•
•
•
What
Document study
Observation
Work Sampling
Interviews
Questionnaires
Prototyping
Join Requirement Planning
Brainstorming & Idea Reduction
Use Cases
Role Playing
Business Modeling
Reviewing Customer Requirement Specifications
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
105
Reviewing Customer Requirement Specs
How
• How to identify requirements
– In general, ignore:
•
•
•
•
Introductions
General system descriptions
Glossary of terms
Other explanatory information
– Find application behaviors or behavioral attributes and
select and label uniquely
– Keep a list of all identified issues and assumptions -verify with the customer or user
• If you don’t know if something is a requirement,
ask the customer!
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
106
Exercise
• Which techniques should be used for which
Applications? Why and Why not?
Technique
Application
Observation
Interview
Prototyping
…
Web Based App.
New Systems
Extension for current
applications
….
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
107
Eliciting Needs: Which Tools to Use?
What
 Requirements
Workshop
Customer/User
Experience
Hi
“Catch Up”
“Mature”
 Brainstorming
 Use Cases
“Fuzzy problem”
“Selling/Teaching”
 Interviews
 Questionnaires
 Role Playing
Low
Low
Developer Experience
Hi
Which of these tools might you use
for each quadrant of the graph?
 Business
Modeling
 Requirement
Reviews
Amirkabir University of Technology, Computer Engineering Faculty,
Intelligent
Systems Laboratory
Adapted
from Alan Davis
108
A Fact-Finding Strategy
What
1. Learn all you can from existing documents,
forms, reports, and files
2. If appropriate, observe the system in action
3. Given all the facts that you've already collected,
design and distribute questionnaires to clear up
things you don't fully understand
4. Conduct your interviews (or group work
sessions)
5. (Optional). Build discovery prototypes for any
functional requirements that are not understood
or if requirements need to be validated
6. Follow up
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
109