Requirements Engineering and Management INFO 627

1
Requirements Engineeringand ManagementINFO 627

• Storyboarding and Use Cases
• Glenn Booker

2
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

3
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)

4
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 isnt set the
  facilitator decides when ideas have run out

5
Brainstorming Rules

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

6
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?

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

8
Running the Session

• Its important to capture ideas right away, and
  in the words first said
• Thats why each person writes their own ideas,
  instead of having a single scribe
• Dont criticize ANYTHING, even as simple as
  observing duplicated ideas
• Keep going until it reaches a natural end

9
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

10
Idea Reduction

• Four major steps in idea reduction
• Pruning
• Feature Definition
• Grouping Ideas
• Prioritization

(order switched from the book)
11
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 dont have some of these, didnt
  brainstorm very well!

12
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

13
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.

14
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

15
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

16
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

17
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

18
Web-based Brainstorming

• Sometimes in-person brainstorming isnt 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

19
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

20
Traditional Storyboards

• Storyboards are cheap, easy ways to provide early
  user review of the user interface
• They are easy to create and modify
• Dont want to make them too detailed, or youll
  get lost in detailed design
• Can also be used to model business rules or
  algorithms

21
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

22
Traditional Storyboard
23
Traditional Storyboard
24
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

25
Storyboarding Guidance

• Keep it simple dont 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
  shouldnt be carved in stone!
• Interactive is better if possible

26
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 dont belong in the
  same sentence

27
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

28
Problem-solving Storyboard
29
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)

30
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
31
Mind Mapping Storyboard
32
Mind Mapping Storyboard

• Once all the ideas are expressed on the
  storyboard, each can be reduced and analyzed as
  we saw for brainstorming

33
Use Cases

• Use cases focus on what the system does for its
  users
• Cockburns 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

34
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

35
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?

36
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?

37
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.

38
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

39
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

40
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.

41
Role Playing

• To understand the needs of stakeholders, so far
  weve 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 well try to experience it through role
  playing

42
Role Playing

• This is great for resolving Yes, But issues
  and working out details of use case
  specifications
• Users often cant describe what they do every
  day, because its so routine
• They may overlook key assumptions or implied
  activities, because its always been that way

43
Role Playing

• Role Playing is often quick an hour is a long
  time, yet can yield valuable insights
• Naturally, role playing doesnt always apply or
  work well use common sense!
• To do role playing, literally go to the
  stakeholders work environment, and do a few
  examples of each type of activity

44
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?

45
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

46
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.)

47
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

48
Prototyping

• Prototyping is an excellent way to hammer out
  functionality-related needs
• Focus is on part of the system where requirements
  arent clear
• Key is to have a partial system with which users
  can interact

49
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

50
Requirements vs Technology

• A requirements prototype is focused on
  determining what the users 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

51
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)
52
Throwaway vs Evolutionary

• Throwaway prototypes are meant to show appearance
  only their structure has nothing to do with the
  final products
• Evolutionary prototypes have the same
  architecture as the proposed product, hence they
  may become a building block for the real product

53
Prototyping

• Keep in mind that prototypes do little to define
  non-functional requirements
• Customers can build prototypes too, to express
  what they want
• Dont overdevelop a requirements prototype
• Make sure prototype focuses on an area needing
  clarification

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