Transcript Requirements Engineering and Management INFO 627 Understanding User Needs Glenn Booker INFO 627 Lecture #3 Extracting Requirements  Three common syndromes often make finding requirements difficult     “Yes, But” “Undiscovered Ruins” “User and.

Requirements Engineering
and Management
INFO 627
Understanding User Needs
Glenn Booker
INFO 627
Lecture #3
1
Extracting Requirements

Three common syndromes often make finding
requirements difficult




“Yes, But”
“Undiscovered Ruins”
“User and the Developer”
Many of the techniques we’ll use are
specifically to prevent these syndromes
INFO 627
Lecture #3
2
“Yes, But” Syndrome

Two reactions are common when a user sees
the new system for the first time



“This is great” (and other compliments)
“Yes, but what if it did this too?” Or “What about
this idea?” Or “Wouldn’t it be nice if…?” Or
“Whatever happened to…?”
The latter are based on the system not being
what they expected
INFO 627
Lecture #3
3
“Yes, But” Syndrome


Some “Yes, But” may prove very useful;
while others may need excessive changes
to the scope of the system
Avoid this by making sure the user sees early
prototypes of the system, so they have clear
expectations of what they will be getting
INFO 627
Lecture #3
4
“Undiscovered Ruins” Syndrome




Tourist: “So, how many undiscovered ruins
are there?”
The more requirements are found, the more
remain to be discovered
Indeed, requirements are often never
fully complete
Identifying all stakeholders helps find many
undiscovered ruins
INFO 627
Lecture #3
5
“User and the Developer” Syndrome


Users and developers speak different
languages, producing a communication gap
To avoid this:



INFO 627
Developer should learn and use the user’s
terminology
Try different ways to discover requirements
Try seeing the user’s perspective – literally,
if need be
Lecture #3
6
Fishing for Requirements

We’ll eventually discuss seven techniques
for eliciting (discovering) requirements







INFO 627
Interviewing and questionnaires
Requirements workshops
Brainstorming and idea reduction
Storyboards
Use cases
Role playing
Prototyping
Lecture #3
7
System Features

The development team must be active in order
to find requirements



Listen for phrases which hint at requirements, and
see if that is their intent
Ask “Do you want to add that as a requirement?”
or otherwise assess the idea’s importance
Start with identifying needs
INFO 627
Lecture #3
8
Stakeholder and User Needs



The top of our pyramid, the “needs” to be met
by the system are a possible starting point
Often the needs are expressed by a key
problem the system should solve – what will
fix the situation
Some users will express features – how
the need can be addressed
INFO 627
Lecture #3
9
Features

Features describe what kind of functionality
should meet the need



A feature is a service provided by the system
to meet some need
Should try to abstract the underlying need to
understand why the feature will be helpful
A need does not describe anything about the
system itself; a feature does
INFO 627
Lecture #3
10
Which is Which?



In the heat of meeting with a user, it isn’t
critical to identify immediately whether
something is a need or a feature
May help to capture the ideas, and sort
them out later (brainstorming)
For examples of features, see any software ad!
INFO 627
Lecture #3
11
How Many Needs and Features?


Needs are fairly few – maybe ten or less
Features are about an order of magnitude
more common – maybe 25-100 features (book
prefers under 50), depending on the size of the
system


See Table 8-1 for examples (p. 90)
Features are handy for scope discussions
INFO 627
Lecture #3
12
Features vs. Requirements


Features will be fleshed out in more detail to
provide detailed requirements later on
Priorities can be tentatively decided at the
features level


Defer to later, Implement now, Investigate
further, etc.
Describe desired features to help manage
them more easily
INFO 627
Lecture #3
13
Attributes of Features

Common attributes for tracking features are:




INFO 627
Status, such as {proposed, approved, rejected}
Priority, such as {high, medium, or low}
Effort, to rank how much effort is needed to
implement feature; again {high, medium, low}
Risk, to identify how challenging that feature is
to implement
Lecture #3
14
Attributes of Features




INFO 627
Stability; to identify how likely that feature is to
change, or how likely the means to implement the
feature will change
Target release; related to priority, what version
of the system will implement this feature?
Assigned to; identifies the lead person for
analysis or implementation of this feature
Reason; or Source – where did this feature come
from? Good for traceability later on…
Lecture #3
15
Interviewing

Interviewing appears simple, and is quite
direct, but developing the right questions can
be challenging


INFO 627
Want to avoid bias and assumptions in
the questions
For related ideas, look up police interrogation
techniques – we aren’t that intense, but some
concepts apply here too
Lecture #3
16
Interviewing



Previous experience with related systems can
hinder interviewing – produces preconceived
ideas of what will be said
Make sure your knowledge of the problem’s
context doesn’t interfere with discovery of
this client’s problem
Want to ask context-free questions
INFO 627
Lecture #3
17
Context-free Questions

Key is to ask about the user’s problem,
without biasing the type of solution





Who is the user?
Who is the customer?
What are their needs?
What other ways can a solution be found?
Some sales techniques can also help
INFO 627
Lecture #3
18
Value-added Context

After the problem is clearly understood, we
can pursue possible types of solutions



After all, our job is to fix the problem
Identify what they think the solution might be
– sometimes they know best!
Hence the entire interview often starts
context-free, then adds focus on solutions
INFO 627
Lecture #3
19
How to Interview




Prepare specific context-free and contextrelated questions in advance, but be prepared
to digress if it’s meaningful
Research the person and organization to
be interviewed
Take notes manually during the interview
Verify key points occasionally
INFO 627
Lecture #3
20
1E p. 96-98
What to Ask?

Typical structure for an interview may contain
elements like these


INFO 627
Establish profile; verify who they are, what they
do, what they produce, and what determines
whether they’re successful
Assessing the problem; what problems remain
unresolved? Why do they exist? How do you deal
with it now? How do you think it should be
solved?
Lecture #3
21
What to Ask?


INFO 627
Understand User Environment; who uses the
existing system? What are their educational and
computer backgrounds? What platforms are in
use? What other applications work with it?
Recap the Problem; make sure you understand
the problem and its environment; any other
problems missed?
Lecture #3
22
What to Ask?



INFO 627
Analyst’s Input on Problem; suggest other areas
that might be troublesome, and see if they’re
actual problems in this case
Assess Solution; summarize your proposed
solution’s key features and benefits, ask which
ones are attractive
Assess Opportunity; how many people need this
solution? How valuable would it be?
Lecture #3
23
What to Ask?



INFO 627
Assess Non-feature Needs; ask about
expectations for the ‘ilities’, performance,
security, installation, support, and other kinds of
non-features
Other Requirements; are they aware of any
other legal, regulatory, environmental, or other
constraints or standards
Wrap Up; ask for other questions, and if you can
follow up with them if needed
Lecture #3
24
What to Ask?



Analyst’s Summary; right after the interview
is over, write down the three biggest needs or
problems faced
Do NOT have to use all these types of
questions – tailor the interview as needed
If they start babbling about the problems they
face, take notes quickly!
INFO 627
Lecture #3
25
Compiling Data


After a few interviews, the picture should
become fairly clear
Start identifying needs expressed by them


INFO 627
Look for themes or common threads
Tentatively sort them by priority
Lecture #3
26
Questionnaires

Questionnaires generally don’t work
in place of interviews, at least for
requirements gathering




INFO 627
Can identify some basic needs (profile, envir.)
Can’t explore interesting ideas or tangents
Hard to follow up on, or clarify responses
Missing interactive information from seeing
people in person – tone, body language, etc.
Lecture #3
27
Requirements Workshops




Often the best single requirements
gathering technique
Encourage rapid consensus (beware of
the ‘c’ word!)
Gather stakeholders for a short, focused time
to agree on key requirements
See also JAD session discussions here too
INFO 627
Lecture #3
28
Requirements Workshops




Helps to have impartial, trained,
outside facilitator
Helps build the team, and achieve buy-in on
project objectives
Preparation for the workshop is critical
Need the right people there – representatives
from key technical & business areas
INFO 627
Lecture #3
29
Requirements Workshops



Need to have a location removed from
everyday activities (distractions)
Ensure working environment is good
Send people materials to prepare in advance


INFO 627
Encourage both context-specific and
creative thinking
Try to put aside previous bad patterns; set
expectations high for a fresh start
Lecture #3
30
Requirements Workshops


Facilitator should have been trained to lead
such workshops, have excellent team building
skills, be objective, and be strong enough to
lead the workshop effectively
Define the agenda (1E p. 108), which will
include free idea generation (brainstorming),
then consolidate the ideas
INFO 627
Lecture #3
31
Requirements Workshops



People generally already know each other, so
icebreaker activities often not needed
Helps to have ideas for defusing the situation
(can get tense!) and yet keeping people
focused
Can help to have someone who can draw
ideas between sessions
INFO 627
Lecture #3
32
Requirements Workshops


Make sure to capture minutes from sessions,
and clearly document final decisions
Identify areas which need follow-up (action
items) – make sure you know what will be
done, who will do it, and when it’s due
INFO 627
Lecture #3
33