Requirements Engineering and Management INFO 627

Requirements Engineeringand ManagementINFO 627 Storyboarding and Use Cases Glenn Booker Lecture #4

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 Lecture #4

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) Lecture #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 isn’t set – the facilitator decides when ideas have run out Lecture #4

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

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? Lecture #4

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!!! Lecture #4

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 Lecture #4

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 Lecture #4

Idea Reduction • Four major steps in idea reduction • Pruning • Feature Definition • Grouping Ideas • Prioritization (order switched from the book) Lecture #4

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! Lecture #4

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 Lecture #4

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. Lecture #4

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 Lecture #4

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 Lecture #4

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 Lecture #4

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 Lecture #4

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 Lecture #4

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 Lecture #4

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 Lecture #4

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 Lecture #4

Once upon a time Lived in the woods Maiden captured by evil king Rescue by the prince Happily ever after Traditional Storyboard Lecture #4

User Validation Main Menu Select Search Criteria Output Report Exit Application Traditional Storyboard Lecture #4

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” Lecture #4

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 Lecture #4

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 Lecture #4

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 Lecture #4

Analyze Problems Identify Scope List Problems and Opportunities Find Solution For Problems Analyze Opportunities Find Solution For Opportunities Merge Solutions Finish Problem-solving Storyboard Lecture #4

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) Lecture #4

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 Lecture #4

Competitiveadvantages? Competition Project team members? Funding for staff? Application features CONCEPT What staff can we use? Release before competition? How easy to use? Hardware compatibility Upgrade costs? Timeline issues Mind Mapping Storyboard Lecture #4

Mind Mapping Storyboard • Once all the ideas are expressed on the storyboard, each can be reduced and analyzed as we saw for brainstorming Lecture #4

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 Lecture #4

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 Lecture #4

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? Lecture #4

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? Lecture #4

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. Lecture #4

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 Lecture #4

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 Lecture #4

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. Lecture #4

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 Lecture #4

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 Lecture #4

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 Lecture #4

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? Lecture #4

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 Lecture #4

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.) Lecture #4

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 Lecture #4

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 Lecture #4

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 Lecture #4

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 Lecture #4

Requirements Engineering and Management INFO 627