Requirements Analysis

Tony Wasserman

Fall 2014 MiniBWeek 1

1

About this course

• You are turning your product vision into requirements, performing an analysis of competing products, and planning an initial release.Course website: http://sm.sv.cmu.edu/RAOngoing assessment and refinement of

product visionPreparation for engineering feasibility,

roadmap, product positioning, business viability

2

How we will work together

• Meet as a class every weekto discuss readingsto discuss the tasksto talk about whatever else you want to relevant to

the course

• Meet regularly with teams (weekly if needed)

• Email your drafts directly in PDFInclude your name and/or team name in the

document title

• Your grade will be 70% team and 30% individual

3

4

How would you proceed with the requirements process were it up to

you?

RA Tasks

• Refine and validate requirements for your product with potential users— Use case diagrams, storyboard and/or UI mockups

• Identify and evaluate RA tools (management, modeling): team and individual

• Produce User Requirements Document using RA tool(s)

• Evaluate competing products based on key requirements: team and individual

• Propose initial version of product (limited release)

• Final presentation to class and faculty

5

Refine and Validate Requirements

• What types of requirements do you need to develop and document?

• How do you make sure that you will create something useful and desirable?

• Work with users/stakeholders to review requirements

6

How to communicate with users?

• Long text document• Use case diagram(s)• Storyboards• User interface mockups or prototypes

7

Tools for Requirements Analysis

• Requirements ManagementKeep track of various requirements

• Graphical ModelingUML

• Storyboarding• UI Mockups and Prototyping

Web and/or mobile

8

Suggested due dates

• November 1: Use case diagrams, storyboard and/or UI mockups used for validation interviews

•November 10: Individual evaluations of requirements tools•November 15: Requirements document(s) using tools•November 22: Team and individual analysis of competing products•December 2: Final presentations in class•December 4: Description of initial viable product

9

What makes the requirements task hard?

10

CARO slides on the CHAOS Report (from 2006)

More complete CHAOS data

11

  1994

1996

1998

2000

2002

2004

2006

2009

Successful

16%

27%

26%

28%

34%

29%

35% 32%

Challenged

53%

33%

46%

49%

51%

53%

46% 44%

Failed 31%

40%

28%

23%

15%

18%

19% 24%

Source: Standish Group standishgroup.com

Challenges to Standish Group’s results• Problem: Standish measures success by only looking at

whether the projects were completed on time, on budget and with required features and functions. They measure only the accuracy of initial estimates, not such things as usefulness, profit, satisfaction

• Questionnaires may bias respondents towards failure stories

• Some organizations with very accurate estimates perform poorly according to Standish; on the other hand, organizations that badly over-estimate perform well!

• Informal surveys suggest 10-15% failures vs. Standish’s 70%

• And Standish’s measures are irrelevant to agile projects.See, e.g., “The Rise and Fall of the CHAOS Report

Figures”12

How do storyboards help you understand users?

• What are the essential characteristics of a storyboard?• What kind of user (e.g., interview subject, UX designer) might prefer a storyboard vs. UI mockups vs. use case diagrams?• In requirements validation, how might you best

– Avoid premature implementation decisions?– Create sufficient detail so that the

interview subject can react authentically and intuitively?

2

Essential characteristics of a storyboard

• Execution of a single task (single goal or subgoal)• Task flow (at a high level: 3-5 steps)

• Context (e.g., secondary actors, time passage, physical environment)

3

How to build a storyboard?• Identify the primary persona (aka

actor) and (sub)goal accomplished by a task• Create a simple script with a specific task focus for the actor.

• Translate to a simple set of storyboard “frames” or “panels.”

• Decide how much of each panel is the user interface vs. other contextual information

.

• Identify supporting actors if they are essential for the task’s context. Add them to the periphery of the panel.• One picture is not worth a thousand words

Include clarifying text.• If the passage of time is an important

component, include that information visually. 4

How might you start with a scenario?

• Does the scenario lend itself to a breakdown into distinct subtasks (i.e., each subtask = activities that can be accomplished in ~3-5 steps and accomplish a subgoal)?

• Are there particular places in the scenario where you want validation from target users?• Does the scenario identify supporting actors and artifacts that the user will need to see in order to understand the context and validate the requirements?

5

Who might prefer a storyboard vs. UI mockups vs. use case diagrams?

• Target user• Target customer (if buyer is not user)

• Software engineer or other storyboard “consumer” (e.g., UX designer, architect)

Storyboard emphasis UI mockup emphasis

Use case diagram emphasis

6

Requirements validation with storyboards:A question of balance

• Avoiding premature implementation decisions?• Creating sufficient detail so that the interview subject can react authentically and intuitively

• What other considerations must be addressed?

7

Mental Blocks in Creating Storyboards

• Where should the story start and end?• Do I have the basic artistic skills to convey my ideas?

• When we (inevitably) create too many panels, how do we decide which ones to use?• How do we identify holes in our story before showing the storyboard to the interview subject (aka target user)?

• How do we identify a minimum set of storyboarding tools without having the tool identification take too much time?

8

I’m interested in meeting new people as well as saving some of the expense of driving. I don’t trust other people to drive. ….

“Basic”

Is there enough usage context?

Is there too much UI detail?

“Comic Book”

Also see Google’sChrome comic book.

“Video”

(This is clickable.)

It’s too early for a high-fidelity prototype.

Why?

Note: This is not a bad storyboard/ prototype; it’s just the wrong one to use for this purpose.

“Hi-Fi UI”

Storyboard 1:Choosing the best-qualified sales rep

I’ll check the experience database to find the best rep to handle it. Let me enter a few search criteria…

The VP of Sales is passed a lead from marketing.

Hmm… Bob has done well in the home improvement vertical, and he knows the VP of Ops at Home Depot. I’ll give it to him.

The system returns a rankedlist of prospective sales reps.

Qualifications

* askdjaslkdjas* asdasdasdasd

* asdasdasdasd* asdasdasdasd

Cool. A big ERP opportunity at Home Depot. I’ll check the RFP when I get to my desk. In the meantime, let me get the team together.

The VP clicks his mouse, andBob’s smart phone tingles.

And so on for a few more cells.

Storyboard 2:A Storyboard Focused on Context Rather than on Interface

That sounds interesting. Can I do deep packet

inspection?

Peter, I see an exciting opportunity to improve performance monitoring for your network. We

are offering next generation of monitoring software.

Jennifer and Peter are meeting to discuss datacenter optimization software

Yes. My system shows that you have multiple options to

pick the software that fits your need. Lets discuss the

requirement in more details.

Network at our Texas datacenter shows poor

performance in the data center and the network exhibits uncontrolled or

intermittently high levels of latency.

We have a perfect solution for your problem "Bandwidth Quality Manager". This software will help your monitor 10GB network as my

system show you have it.

Peter describes the problem.

BQM supports Application Deployment Engine, making it easier to monitor end-to-

end network.

Jennifer uses SellRite to answer Peter's questions on the products. This showcases the SellRite's ability to

recommend based on the customer specific configuration.

My system shows that we have another product "Mobile Wireless Transport Manager". This software is compatible with your network and BQM

software making it an integrated platform.

I need to monitor my wireless mobile internet network. Do you think BQM software is

sufficient?

OK. This will be easy for me.

You can purchase a one-year Software Application Support (SAS) contract that provides support and access to software

maintenance patches.

Jennifer shares licensing, delivery and compatibility of the software.

I see that there is a contract in place for your company. We will see how we can use

the same contract.

I want this in my datacenter as quickly

as we can. Let me work with my team to

close this deal.

I am sending you specific product documentation that takes care of your

network configuration into account via email. I will get this configuration validated by my

support engineer and send you the update.

Jennifer provides the documentation of the possible solutions and ends the meeting.

If you have any questions let me know. We can

discuss more before we close the deal.

Jennifer calls Bob to validate the options.

Is this SellRite assisted proposal?

Then it will be quick for me!

Hello, Bob. I want you to validate a proposal for my customer. I have emailed you a copy. Do you think you will be able validated

quickly?

Yes it is! That’s great! Thanks!

If you’re really interested in visual storytelling, read:

Storyboarding is a way to validate your early thinking…

… but that said, think of a storyboard interview more as an additional conversation about requirements than as evaluation of a design.

Requirements Tools

• Storyboarding• Modeling (use cases, etc.)• UI Mockups and Prototyping• Requirements Management

37

Evaluating Tools

• Fitness of purpose• Platform(s)• Installability and usability• Need for and availability of

support and training• Cost-benefit assessment

38

About the Tools Task

• Select a tool within a category (different team members choose different category)

• Evaluate against previous criteria• In your opinion, is it worth the total price?• Submit evaluation along with screen shot

to demonstrate use of the tool

39

Does the tool work as well in practice as the website suggests?

Readings for Early Requirements Capture

• Wiegers, Chaps. 1 and 2

• Holtzblatt, Karen et al, Chapter 12 (storyboarding; focus on theconcepts and goals, not on the detailed how-to prescriptions)

• Truong, Khai et al. “Storyboarding: An Empirical Determination ofBest Practices and Effective Guidelines” (note: focus is on the

storyboard consumer)

• Cockburn, Alistair. Writing Effective Use Cases, Chapter 1

• More Cockburn over the next few weeks

– Read 1-4, 6, and 7– Skim 5, 8-11, 19-22

– Table 20.1 provides a checklist for writing use cases

9

Questions?Image source: www.flickr.com/photos/tony_wasserman

FishingBoats-Marsaxlokk, Malta