LECTURE 6

Topic: Requirements Elicitation-II

References: Text Book Chapter 7-8

May be the most powerful technique

for eliciting requirements.

If we were to be given only one requirements

elicitation techniqueone that we had to apply in
every circumstance, no matter the project

context, no matter what the time frame

we would pick the requirements workshop.

Designed to encourage consensus on the

requirements of the application and to gain rapid
agreement on a course of action, all in a very short
time.

Gathers all key stakeholders together for

a short but intensely focused period (1-2
days)

The use of an outside facilitator

experienced in requirements elicitation
can help ensure the success of the
workshop.

Brainstorming is the most important

part of the workshop.

Sell the Concept

communicate the benefits of the workshop approach
to prospective members of the team.
Ensure
the
Participation
of
the
Right
Stakeholders
These stakeholders will have already been identified
if the team analyzed the problem properly.

 Provide

Warm-Up Materials in Advance

To prepare the attendees and also to increase

productivity at the workshop session.

Project-specific information. bulleted lists of
suggested features, copies of interviews with
prospective users, analyst's reports on trends in the
industry, letters from customers, bug reports from
the existing system, and so on.
Out-of-the-box thinking preparation. Forget for
a minute what you know and what can't be done
due to politics or management. Simply bring your
insights on the features of this new project, and be
prepared to think out of the box.

It is recommended that the workshop be run by a nonstakeholder, someone outside the organization, who is
unaffected by any particular outcome and has no role in the
company other than to see a successful workshop outcome.
Ideally, the facilitator will also have experience with the
unique challenges and charged atmosphere of the
requirements workshop.
However, if this is not practical in your environment, the
workshop could be facilitated by a team member if that
person:
Has received some training in the process
Has demonstrated solid consensus-building skills
Is personable and well respected
Is strong enough to chair what could be a challenging
meeting

 If

the workshop is to be facilitated by

a team member, that person must
not contribute to the ideas and
issues at the meeting.

Otherwise,

the workshop is in danger

of losing the objectivity that is
necessary to get at the real facts.

Establish a professional and objective tone for

the meeting.
Start and stop the meeting on time.
Establish and enforce the "rules" for the meeting.
Introduce the goals and agenda for the meeting.
Manage the meeting and keep the team "on
track."
Facilitate a process of decision and consensus
making, but avoid participating in the content.
Manage any facilities and logistics issues to
ensure that the focus remains on the agenda.
Make certain that all stakeholders participate and
have their input heard.

 Involves

both idea generation

and idea reduction.

Various

voting techniques may be used

to prioritize the ideas created.

Although

live
brainstorming
is
preferred, Web-based brainstorming
may be a viable alternative in some
situations.

 It's

simple, fun, and an easy way to get

all stakeholders to contribute.

This

process will also help in the goal of

"finding the undiscovered ruins" and
thereby making sure that you have
complete input and that all stakeholder
needs are addressed.

It

allows participants to "piggyback" on

one another's ideas.

Many different ways are possible, we discuss one.

First, all the significant stakeholders gather in one room,

and supplies are distributed.

Then the facilitator explains the rules for brainstorming.

The facilitator also explains the objectives of

the process.
For example, the following questions are a few
ways to state the objectives.
What features would you like to see in the product?
What services should the product provide?
What opportunities are we missing in the product

or the market?

Note that the objective also helps you decide

when the session is done. When the objectives
are met and no one else has anything to add,
quit!

After stating the objective, the facilitator asks

participants to share their ideas aloud and to
write them down, one per sheet
Structured: take turns (contribute, or say Pass)
Unstructured: anyone, any time

Ideas are spoken out loud to enable others in

the room to piggyback on the ideas, that is, to
think of related ideas and to mutate and
combine ideas.

In this process, however, the first rule no

criticism or debate must be foremost in
people's minds.

As ideas are generated, the facilitator collects them and posts

them on a wall in the meeting room.

Idea generation should proceed until all parties feel it has

reached a natural end.

It is common for lulls to occur during idea generation. These

are not times to stop the process.

Longer lulls might be cause for the facilitator to state the

objective again or to ask stimulating questions.

Most idea-generation sessions last around an

hour, but some last two to three hours.

Under no condition should the facilitator end a

session that is going strong with a remark like, "I
know we're all doing great with this process, but
we need to move on." To the participants, this
remark says, "Your ideas are not as important as
my schedule."

The number of ideas generated will be a function

of how fertile the subject being discussed is, but
it is common to generate 50100 ideas.

 The

process tends to have a natural

end; at some point, the stakeholders
will simply run out of ideas. This is
typified by longer and longer gaps
between idea submissions.

At

this point, the facilitator ends the

session, and it may well be a great
time for a break.

When the idea-generation phase ends,

it is time to initiate idea reduction.

Pruning Ideas

"prune" those ideas that are not

worthy of further investment by
the group.
The facilitator starts by visiting
each idea briefly and asking for
concurrence from the group that
the idea is basically valid.
There is no reason for any
participant to be defensive or to
claim authorship for any idea;
any participant may support or
refute any idea.
if there is any disagreement
among the participants, the
idea stays on the list.

Grouping Ideas
most effective when participants from the session

volunteer to go to the wall and do the grouping.

Related ideas are grouped together in regions of
the walls. Name the groups of related ideas.
For example, the groups might be labeled as
follows:

New features
Performance issues
Enhancements to current features
User interface and ease-of-use issues

Defining Features:
Write a short description of what the idea
meant to the person who submitted it.
This gives the contributor the opportunity
to further describe the feature and helps
ensure that the participants have a
common understanding of the feature.
the facilitator walks through each idea and
asks the submitter to provide a onesentence description.

Prioritizing Ideas:
Once the idea groupings have stabilized
and been agreed to, it is time to move
on to the next step.
Again, a variety of techniques can be
used; we'll discuss two:
Cumulative Voting
Categorization

When live brainstorming is not possible, use

the Internet or an intranet to facilitate the
brainstorming process.
particularly suited for developing advanced
applications for which research is required
or a long-term view is critical, the concept is
initially fuzzy, and a wide variety and
significant number of user and other
stakeholders inputs are involved.
the project leader sponsors a list server or
discussion
group
for
recording
and
commenting on product features.

 Advantages:
Free formulation of new ideas
High quality outcome

Limitations
Heterogeneous communication skills:

Danger of opinion leadership

Power relations: manager vs. ordinary
staff
scheduling

The purpose of storyboarding is to

elicit early "Yes, But" reactions.
Storyboards identify the players,
explain what happens to them, and
describe how it happens.
Make the storyboard sketchy, easy to
modify, and not shippable.
Storyboard early and often on each
project with new or innovative content.

 Is
Is

extremely inexpensive
user friendly, informal, and
interactive
Provides an early review of the user
interfaces of the system
Is easy to create and easy to modify

 Storyboards

also offer an excellent

way
to
ease
the
"blank-page"
syndrome. When the users do not
know what they want or have trouble
envisioning any solution to the current
problem, even a poor storyboard is
likely to elicit a response of "No, that's
not what we meant, it's more like the
following," and the game is on.

 Passive

storyboards

Tell a story to the user.

They can consist of sketches, pictures,

screen shots, or sample application

outputs.
In a passive storyboard, the analyst
plays the role of the system and simply
walks the user through the storyboard,
with a "When you do this, this happens"
explanation.

Active storyboards
Try to make the user see "a movie that hasn't

actually been produced yet."

Active
storyboards
are
animated
or
automated, perhaps by an automatically
sequencing slide presentation, an animation
tool, a recorded computer script or
simulation, or even a home-made movie.
Active storyboards provide an automated
description of the way the system behaves in
a typical usage or operational scenario.

 Interactive

storyboards

Let the user experience the system in as

realistic a manner as practical.

They require participation by the user.
Interactive
storyboards
can
be
simulations or mock-ups or can be
advanced to the point of throwaway
code.

 Storyboards

for user-based systems

deal with the three essential
elements of any activity:
Who the players are
What happens to them
How it happens

Example: a storyboard for an automatedvehicle amusement park ride.

The who represents the guests who ride on the

vehicle.
The what represents the behavior of the vehicle
as it provides various events for the guests.
The how provides further descriptions of how this
interaction happensevents, state transitions
and describes both the guest states (surprised,
scared) and the vehicle states (accelerating,
braking, unloading).

 Don't

invest too much in a

storyboard.
Customers
will
be
intimidated about making changes if
it looks like a real work product.
If you don't change anything, you
don't learn anything. Make the
storyboard easy to modify. You
should be able to modify a
storyboard in a few hours.

 Whenever

possible,
make
the
storyboard
interactive.
The
customer's experience of use will
generate more feedback and will elicit
more new requirements than a
passive storyboard will.

Goal:
Goal check requirement adequacy
from direct user feedback, by
showing reduced sketch of softwareto-be in action
focus

on unclear, hard-to-formulate
requirements to elicit further

Prototype = quick implementation of

some aspects

Functional prototype
focus on specific functional requirements

User interface prototype

focus on usability by showing input-

output forms, dialog patterns

e.g.
static/dynamic interaction to get
participant constraints

Throw-away prototype (Mock-up):

(Mock-up) prototype is thrown away
(product = adequate requirements)
The objective is to validate or derive the system
requirements.
The prototyping process starts with those requirements
which are poorly understood
Evolutionary prototype:
prototype transformed towards efficient code
The objective is to deliver a working system to end-users.
Used when it is hard to come up with requirements

specification upfront e.g. user-interface systems

The development starts with those requirements which

are best understood.

Advantages:
Concrete flavor of what the software will look like
=> clarify requirements, elicit hidden ones, improve
adequacy,
understand implications, ...
Other uses:
user training, stub for integration
testing, ...
Limitations:
Does not cover all aspects
missing functionalities
ignores
important
non-functional
requirements
(performance, cost, ...)
Quick-and-dirty code, hard to reuse for software

development

 Elicitation Techniques
When to Stop?

 No simple signal
You'll never be completely done
Cues suggest that you're reaching

the point of diminishing returns:

If the users can't think of any more tasks/goals.

If users repeat issues that they already covered
in previous discussions.
If suggested new requirements are all out of
scope.
If proposed new requirements are all low
priority.
Another way is to create a checklist of common
functional areas to consider for your projects.