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

INFO 627 Lecture #4 1

Requirements Engineeringand ManagementINFO 627

Storyboarding and Use Cases

Glenn Booker


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


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)


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


Brainstorming Rules Do not allow criticism or debate Let your imagination soar! Generate as many ideas as possible Mutate and combine ideas


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?


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!!!


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


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


Idea Reduction Four major steps in idea reduction

Pruning Feature Definition Grouping Ideas Prioritization

(order switched from the book)


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!


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


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

Customer service, marketing, sales, transportation, packaging, etc.


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


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


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) Lowest total is highest priority


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


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


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


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


Traditional Storyboards Storyboards can be:

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


Traditional Storyboard

Once upon a time

Lived in the woods

Maiden capturedby evil king

Rescue by the prince

Happily everafter


Traditional Storyboard

User Validation

Main Menu

Select SearchCriteria

Output Report

Exit Application


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 Soft and fuzzy tools better than “professional”


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


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


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


Problem-solving StoryboardIdentifyScope

List Problemsand Opportunities

Analyze Problems

Find Solution For Problems

Analyze Opportunities

Find Solution For Opportunities Merge

SolutionsFinish


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)


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


Mind Mapping Storyboard

CONCEPT

Project team members?

What staff can we use?

Hardwarecompatibility

Competition

Application features

Timelineissues

Competitiveadvantages?Funding

for staff?

Upgradecosts?

How easy to use?

Release before com

petition?


Mind Mapping Storyboard Once all the ideas are expressed on the

storyboard, each can be reduced and analyzed as we saw for brainstorming


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


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 Actors External systems Use cases, connected by lines to actors and

external systems System boundary


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?


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?


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.


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


Starting Use Cases Build up use cases in sections, as

recommended by Cockburn 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


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.


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


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


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


Role Playing Role playing can help identify critical aspects

of a procedure: 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?


Similar Concepts Scripted walkthroughs are similar to

role playing 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


Similar Concepts Class-Responsibility-Collaboration (CRC)

Cards are also similar to role playing 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.)


CRC Cards 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


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


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


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 A.k.a. proof of concept or technology demonstration


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)


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


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


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 riskKeep It Simple!

Documents

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