Transcript Requirements Engineering and Management INFO 627 Storyboarding and Use Cases Glenn Booker INFO 627 Lecture #4

Requirements Engineering
and Management
INFO 627
Storyboarding and Use Cases
Glenn Booker
INFO 627
Lecture #4
1
Brainstorming

Brainstorming is really a two-part process




Idea generation (the part we most associate with
brainstorming)
Idea reduction (to consolidate the ideas)
Brainstorming is one of the most fun ways to
find undiscovered requirements
Usually done in person, though web-based
brainstorming is possible
INFO 627
Lecture #4
2
Brainstorming Benefits





Encourages participation by everyone
Allows ideas to build on each other
Generates lots of ideas quickly
Often generates a broad range of ideas
Encourages throwing away normal limitations
(out of the box thinking)
INFO 627
Lecture #4
3
How to do Brainstorming




Gather key stakeholders in a room
Give each one sticky notes (or index cards)
and a marker
Tell everyone the rules, and the objective for
the session (digression is easy to do!)
Usually a formal time limit isn’t set – the
facilitator decides when ideas have run out
INFO 627
Lecture #4
4
Brainstorming Rules




Do not allow criticism or debate
Let your imagination soar!
Generate as many ideas as possible
Mutate and combine ideas
INFO 627
Lecture #4
5
Objectives


Typical objectives are to focus on what
features, services, or things your system
should have or keep track of
What other objectives could a session have?
INFO 627
Lecture #4
6
Running the Session


As ideas are thought of, each person says their
idea aloud and writes it down on a piece of
paper
Mutating and combining ideas is allowed, and
to be encouraged!


Many of the most innovative ideas come
about this way
No criticism or debating allowed!!!
INFO 627
Lecture #4
7
Running the Session




It’s important to capture ideas right away, and
in the words first said
That’s why each person writes their own
ideas, instead of having a single scribe
Don’t criticize ANYTHING, even as simple
as observing duplicated ideas
Keep going until it reaches a natural end
INFO 627
Lecture #4
8
Running the Session

Keep in mind that lulls are normal during a
session, so beware of ending prematurely

After the end is clearly reached, idea
reduction can begin
INFO 627
Lecture #4
9
Idea Reduction

Four major steps in idea reduction




INFO 627
Pruning
Feature Definition
Grouping Ideas
Prioritization
(order switched
from the book)
Lecture #4
10
Pruning

Prune, or get rid of, ideas which are clearly
out of the question




Make sure everyone agrees to get rid of each
If anyone considers it worth keeping, do so
Group together duplicates
If you don’t have some of these, didn’t
brainstorm very well!
INFO 627
Lecture #4
11
Feature Definition



Write a short description of the idea, generally
by whoever came up with it
Want a clearer idea of its scope and intent, to
aid grouping and prioritization
One or two sentences often enough
description for now; just get the essence
of the idea
INFO 627
Lecture #4
12
Grouping Ideas

Start to group ideas, either by type
of suggestion


New features, performance issues, improve
existing features, user interface improvements
Or maybe by portion of the system affected

INFO 627
Customer service, marketing, sales,
transportation, packaging, etc.
Lecture #4
13
Prioritization


Optional step – may not do as part of
brainstorming session
Can do the basic three-level prioritization:



Critical, Important, Useful
High, Medium, Low
Or can use one of three voting schemes
INFO 627
Lecture #4
14
Prioritization Voting

A. Can give each person a budget for
“spending” on ideas



Total budget of $100
No more than some amount (e.g. $10 or $20) on
any one idea
Then add up the total amount spent on each
idea – most money = highest priority
INFO 627
Lecture #4
15
Prioritization Voting


Only can vote once – otherwise people
may bias their votes after seeing the
initial results
B. Alternate approach is to rate priority on
a 5-point scale, and add up ratings for
each idea (assume 1 = highest priority)

INFO 627
Lowest total is highest priority
Lecture #4
16
Prioritization Voting

C. Or can score high/medium/low voting




High = 9 points
Medium = 3 points
Low = 1 point
Then add up points – largest number of points
is highest priority
INFO 627
Lecture #4
17
Web-based Brainstorming



Sometimes in-person brainstorming isn’t
possible – have to resort to web-based
Can use a private chat room, list server,
web page with bulletin board, instant
messaging, or other techniques
Easy to save information this way, but harder
to build energy or synergy of ideas
INFO 627
Lecture #4
18
Storyboarding




Focuses on addressing the “Yes, But”
syndrome head-on
Traditional storyboarding is used for
sketching interface ideas
A prototype is a very elaborate storyboard
The other kinds of storyboarding support
problem analysis and brainstorming
INFO 627
Lecture #4
19
Traditional Storyboards




Storyboards are cheap, easy ways to provide
early user review of the user interface
They are easy to create and modify
Don’t want to make them too detailed, or
you’ll get lost in detailed design
Can also be used to model business rules
or algorithms
INFO 627
Lecture #4
20
Traditional Storyboards

Storyboards can be:



INFO 627
Passive – static images from what the system will
look like
Active – animated images, like a PowerPoint
slideshow or a movie walkthrough
Interactive – let the user try parts of the system
firsthand, click on stuff, see mock-ups or
simulations
Lecture #4
21
Traditional Storyboard
Once upon
a time
Maiden captured
by evil king
INFO 627
Lived in
the woods
Rescue by
the prince
Lecture #4
Happily ever
after
22
Traditional Storyboard
User
Validation
Select Search
Criteria
INFO 627
Main Menu
Output
Report
Lecture #4
Exit
Application
23
Storyboards

Storyboards focus on three key aspects




Who is doing something
What are they doing
How did it happen
Tools can include paper & pencil, Post-it
notes, PowerPoint slides, or special tools
for storyboarding

INFO 627
Soft and fuzzy tools better than “professional”
Lecture #4
24
Storyboarding Guidance

Keep it simple – don’t make it too complex
or too realistic, or the actual product
development will seem too time consuming



Sketchy and clunky are good
Play with lots of changes – a storyboard
shouldn’t be carved in stone!
Interactive is better if possible
INFO 627
Lecture #4
25
Storyboarding Guidance





Storyboard early in the project
Storyboard often
Storyboard for new features
Storyboards should be something to reshuffle,
throw on the floor, and start over
“Pristine” and storyboard don’t belong in the
same sentence
INFO 627
Lecture #4
26
Problem-solving Storyboard


The Problem-solving Storyboard is a tool for
working on problems and opportunities
Focus separately on finding a solution to
fix problems, then one to address
opportunities, then blend them together
and see what you get
INFO 627
Lecture #4
27
Problem-solving Storyboard
Identify
Scope
List Problems
and Opportunities
Find Solution
For Problems
Analyze
Opportunities
Find Solution
For Opportunities
INFO 627
Analyze
Problems
Merge
Solutions
Lecture #4
Finish
28
Mind Mapping Storyboard


The Mind Mapping Storyboard is a
brainstorming tool, to help look for
connections among issues related to
solving a problem
Goal is to think of factors separately, then see
if there are relationships among them
previously missed (undiscovered ruins)
INFO 627
Lecture #4
29
Mind Mapping Storyboard



The Mind Mapping Storyboard is generated
by starting the the problem or concept at the
center of a large board or piece of paper
Ideas are identified and connected to the
central concept or each other, as needed
Everyone writes on the same area at once
Problem solving and mind mapping storyboard concepts
from Tzipora Katz, based on the CIW curriculum
INFO 627
Lecture #4
30
Mind Mapping Storyboard
Funding
for staff?
Competition
Project team
members?
What staff
can we use?
Competitive
advantages?
Application
features
CONCEPT
How easy
to use?
Hardware
compatibility
INFO 627
Upgrade
costs?
Lecture #4
Timeline
issues
31
Mind Mapping Storyboard

Once all the ideas are expressed on the
storyboard, each can be reduced and analyzed
as we saw for brainstorming
INFO 627
Lecture #4
32
Use Cases

Use cases focus on what the system does for
its users



Cockburn’s “Writing Effective Use Cases” is the
quintessential reference on the subject
Use cases can also capture requirements for a
system, and guide design and testing
A use case describe a set of actions which
produce a useful result to some actor
INFO 627
Lecture #4
33
Use Case Model

The use case model consists of all actors and
systems which may interact with the system,
and all of the use cases which may be
performed by them




INFO 627
Actors
External systems
Use cases, connected by lines to actors and
external systems
System boundary
Lecture #4
34
Use Case Descriptions





Use cases are described in natural language
What are the steps needed to perform
an activity?
Who performs each step, and what is the
expected outcome? (like a procedure)
What happens if something goes wrong?
What other ways can we perform that task?
INFO 627
Lecture #4
35
Use Case Descriptions





What has occurred before this use case takes
place?
What is a successful outcome of this use case?
Unsuccessful?
How often does this use case occur?
How many people perform this use case?
What is the priority of implementing this use
case?
INFO 627
Lecture #4
36
Use Case Limitations

Notice that we can only describe use cases for
system users – other stakeholders are
not included


Could miss key requirements there
Use cases weak on finding non-functional
requirements – performance, -ilities, safety,
security, etc.
INFO 627
Lecture #4
37
Use Case Specifications



A very detailed use case description is also
called a use case specification
Details exactly what is done for every step –
what fields are entered, what limits and
relationships are on and among fields, etc.
The main success scenario and its extensions
capture business process logic
INFO 627
Lecture #4
38
Starting Use Cases

Build up use cases in sections, as
recommended by Cockburn





INFO 627
Start with a basic idea; scope, actor, frequency
Add the primary success scenario
Add the extensions, variations, and related
use cases
Add performance and schedule goals
Identify secondary actors and interfaces
Lecture #4
39
Included Use Cases

An “included use case” is a use case
which is:



Called upon by two or more other use cases
Performs a clearly defined function
Included use cases might be portions of a
process which are used in several contexts,
such as validating a credit card, checking
inventory, etc.
INFO 627
Lecture #4
40
Role Playing


To understand the needs of stakeholders,
so far we’ve discussed it one-on-one
(interview), in a group (workshop), presented
ideas about it (storyboard),
and thought out how people interact with
it (use cases)
Now we’ll try to experience it through
role playing
INFO 627
Lecture #4
41
Role Playing



This is great for resolving ‘Yes, But’
issues and working out details of use
case specifications
Users often can’t describe what they do every
day, because it’s so routine
They may overlook key assumptions or
implied activities, because it’s always been
that way
INFO 627
Lecture #4
42
Role Playing



Role Playing is often quick – an hour is a long
time, yet can yield valuable insights
Naturally, role playing doesn’t always apply
or work well – use common sense!
To do role playing, literally go to the
stakeholder’s work environment, and do
a few examples of each type of activity
INFO 627
Lecture #4
43
Role Playing

Role playing can help identify critical aspects
of a procedure:





INFO 627
When do you know you have to perform it?
What decisions are involved?
What data or decisions are determined for you?
Who gets your work products, and what happens
to them then?
How hard is it to learn the task?
Lecture #4
44
Similar Concepts

Scripted walkthroughs are similar to
role playing



INFO 627
More formal; follows a script for a specific role,
like a use case description
Helps plan interaction with the system – who
does what, and when
More formal and controlled than role playing
Lecture #4
45
Similar Concepts

Class-Responsibility-Collaboration (CRC)
Cards are also similar to role playing



INFO 627
Used for object-oriented modeling
Index cards are used, one for each class of objects
in the system
On each card, describe the class name, its
responsibilities (the method or message it can
use), and the classes it may talk to (collab.)
Lecture #4
46
CRC Cards




INFO 627
Once the cards have been defined, try to walk
through a task, starting with the first class with
which an actor communicates
Try to perform the task, using the methods
described on the cards
Look for missing information or methods
Fix contents of the cards as needed, and keep
trying until it works
Lecture #4
47
Prototyping



Prototyping is an excellent way to hammer
out functionality-related needs
Focus is on part of the system where
requirements aren’t clear
Key is to have a partial system with which
users can interact
INFO 627
Lecture #4
48
Prototyping

Need to pick three aspects of a prototype




Requirements vs. Technology focus
Vertical vs. Horizontal scope
Throwaway vs. Evolutionary structure
Any combination of these choices
is possible
INFO 627
Lecture #4
49
Requirements vs Technology

A requirements prototype is focused on determining
what the user’s requirements and needs are for some
part of the system


In this course, we usually mean this kind
A technology prototype is to determine if a particular
technology can perform the kinds
of actions needed to support the product

INFO 627
A.k.a. proof of concept or technology demonstration
Lecture #4
50
Vertical vs Horizontal


Vertical prototypes demonstrate the exact
functionality of a small section of the
entire product (much detail, small scope)
Horizontal prototypes demonstrate a broad
spectrum of the product's features, but without
extensive functionality behind
each function (broad scope, little detail)
(Think of vertical and horizontal markets for an industry)
INFO 627
Lecture #4
51
Throwaway vs Evolutionary


Throwaway prototypes are meant to show
appearance only – their structure has nothing
to do with the final product’s
Evolutionary prototypes have the same
architecture as the proposed product,
hence they may become a building block
for the real product
INFO 627
Lecture #4
52
Prototyping




Keep in mind that prototypes do little
to define non-functional requirements
Customers can build prototypes too, to
express what they want
Don’t overdevelop a requirements prototype
Make sure prototype focuses on an area
needing clarification
INFO 627
Lecture #4
53
Prototyping




Once prototype completed, users should try it
out in as realistic a situation as possible
Try to get different types of users involved
Usually helps define fuzzy requirements, and
prompts ideas for new requirements
Generally recommend prototyping any new
application where it might reduce risk
Keep It Simple!
INFO 627
Lecture #4
54