1 Questions? CSSE 490 - Requirements Steve Chenoweth Department of Computer Science & Software...

38
1 Questions? CSSE 490 - Requirements Steve Chenoweth Department of Computer Science & Software Engineering RHIT Session 3 – Wed, June 20, 2007 Above – BrainWriting – a divergent group elicitation technique. Concept is that as you brainstorm silently around a circle, building on each other’s thoughts, someone will have an interesting new idea. Pic from www.laatukeskus.fi/default.as
  • date post

    19-Dec-2015
  • Category

    Documents

  • view

    214
  • download

    0

Transcript of 1 Questions? CSSE 490 - Requirements Steve Chenoweth Department of Computer Science & Software...

1Questions?

CSSE 490 - Requirements

Steve ChenowethDepartment of Computer Science &

Software EngineeringRHIT

Session 3 – Wed, June 20, 2007Above – BrainWriting – a divergent group elicitation technique. Concept is that as you brainstorm silently around a circle, building on each other’s thoughts, someone will have an interesting new idea. Pic from www.laatukeskus.fi/default.asp?docid=9938 .

2Questions?

Today

• Review problem statements.• Bonus Revisited –

Synthesis & Analysis.• Practice elicitation methods – • Use cases.• How Req should look.• Product mgmt & Req. • Keeping a lid on Req.• New Bonus – Six Sigma & Req• Upcoming Exam

Interviewing

Req workshops

Brainstorming

Storyboarding

3Questions?

Review problem statements

• What was easy to do, using the format provided?

• What was tough?

• How long is it?

• Are the features prioritized?

• What other “form” considerations did you find?

4Questions?

Bonus Revisited – Synthesis & Analysis

Let’s relook at this one:• It is commonly claimed that requirements is an analysis, whereas engineering proper is a

synthesis. Argue the reverse.

Key issues here are:1. Science vs. engineering –

a. Synthesis is used carefully in science, like to propose a new hypothesis. Anything synthesized needs to be tested somehow, before we decide it’s “true.”

b. Synthesis must be used more liberally in engineering – our whole point is to build things.

2. Traditional view is –a. Of requirements – They’re “facts” or “musts” which we can’t argue with. Our goal is

to figure out what they mean. That’s analysis.b. Of “engineering” things – What follows analyzing the task is mostly creative.

3. Arguing the reverse –a. Of requirements – You or the customer have to invent the expression of

requirements, just like everything else. There’s some guesswork and best-practices involved. Requirements are not all scientific facts or even data the customer won’t change their mind about.

b. Of “engineering” things – You have to do lots of analysis to build things right – for example, in checking your decisions or testing the end results.

5Questions?

Practice elicitation methods –Interviewing

• Ch 10 in R

• Ask context-free questions

– Who is the customer?

– Why does this problem exist?

• Solutions-context questions – later

• Book’s questions – pp. 104-5

6Questions?

Practice elicitation methods –Interviewing

Some expert questions, from my experience:• Where does the data come from that will go into this

system?• Who else do I need to talk to?• It sounds like these other people will be impacted by the

system. Where might you and they differ as to what’s most important about the system?

• How long have you been using your existing system?• How much will it cost you if the system isn’t working?• Is there anything else important we didn’t talk about?• How much is it worth to solve this problem? Why?• In summary, is this the priority of importance for the

features we discussed? …

7Questions?

Practice elicitation methods –Interviewing

Practice set up:• Take out a sheet of paper. Put your name on it.• Take 5 min to:

– Write down a definition of a problem you’re familiar with, but which others probably are not.

– List some key stakeholders.– Add a few sentences about ways this has to be

solved.

• Then…

8Questions?

Practice elicitation methods –Interviewing

Practice session:

• Give your problem sheet to someone else

• Study the one you got and write down questions you’d like to ask the author.

• We’ll take turns, and each person gets to be both interviewer and interviewee.

• Audience responsible for suggesting additional questions and other ideas.

9Questions?

Practice elicitation methods – Req workshops

• Ch 11 in R• Gets all stakeholders in a room at once, to agree on

requirements• Political issues come out• It promotes ongoing cooperation• Output is available right away• A famous variation these days – Scrum’s Sprint

Reviews:– See http://www.controlchaos.com/,

http://en.wikipedia.org/wiki/Scrum_(development) .

• Uses lots of brainstorming & idea reduction Next topic

10Questions?

Practice elicitation methods – Req workshops

Key aspect of doing this right - Preparation:• Sell the idea (not easy – it’s time & travel from

valuable people)• Pick an outside facilitator (top guns are about $

3000 / day, 2 days minimum)• Get all the right people in the room• Get the logistics and agenda right• Provide materials (like product info)• Have a great warm-up exercise (like Synectics’

“Design a $100 grizzly bear repellant”)

11Questions?

Practice elicitation methods – Req workshops

Running the workshop:

• Setting may be “politically charged, confrontational.”

• People’s instinctive attitudes need to be managed for this event– E.g., “A question is really an objection.”– “Let me devil’s advocate here” – ditto.

12Questions?

Practice elicitation methods - Brainstorming & Idea Reduction

• Ch 12 in R• Overview – Brainstorming is a divergent thinking process,

often practiced in groups, which fits into the Discover part of the “diamond” of general purpose problem solving:

Describe

Discover

Decide

Time

Results come out here

Start

Done

Describe = A problem statement

Discover = Divergent thinking

Decide = Convergent thinking

13Questions?

Practice elicitation methods - Brainstorming & Idea Reduction

• Brainstorming is an example of requirements elicitation where Synthesis is encouraged!

• A cazillion of these are in a Handout!

• We’ll try a couple…There are all different flavors of brainstorming. Not all even use words as artifacts. Here a team explores possible forms for a hydrogen fuel cell vehicle designed for fuel economy races. From www.paccar.ethz.ch/history/index .

14Questions?

Practice elicitation methods - Brainstorming & Idea Reduction

Cool brainstorming method:  BrainWriting

Good for: Analyzing the costs and impacts of bad quality – fishing for the big ones!

Prereq knowledge:  Requirements you have; plus how the requirements imply that the proposed software system should work.

Expected outcomes:  Surprise impacts which no one person would have anticipated.

More

15Questions?

Practice elicitation methods - Brainstorming & Idea Reduction

BrainWriting, cntd:

How to do it:  Sit in circle (8-10 people), each person holding a pad of paper.  To begin, each person

thinks of a problem or other quality impact which they believe could occur with this design.  Everyone quickly writes their idea at the top of the top sheet on their pad.  Then the pads are passed to the left. 

Each person silently reads the prior idea written by the last person, then thinks of a new problem or impact, related or unrelated, and writes that below it on the same sheet.  The pads are passed to the left again, and the reading and writing process is repeated to create another new entry on each sheet.

When each pad has (simultaneously) gone around the whole circle, the person holding a particular pad silently reads the 8-10 ideas on the sheet they began.  They circle the three most interesting ones contributed by others, using “surprise” as the criterion.  They then put a star next to the one which sounds “surprising and most important.” 

Each person takes turns reading the one surprising and important impact which they starred, explaining why they believe this is an important impact to study for the proposed software system.

More

16Questions?

Practice elicitation methods - Brainstorming & Idea Reduction

BrainWriting, cntd:

Special environmental concerns:  For more people, may need multiple circles. For less, may not work.

Ideally everyone sits in a circle, visually expressing their position of equal brainstorming contributors.  However, the passing of the paper pads can in fact be done in a variety of room configurations.

How to evaluate results:  Speed at which the pads move around the circle (faster is better, given that full ideas are written on them).

Self-rating by people involved, of the surprise and value of the results.

Note: Don’t forget also to do a systematic analysis of issues! This method is designed as a check on that, to avoid those surprises.

17Questions?

Practice elicitation methods – Req workshops & Brainstorming

Let’s practice both of these at once:

• Warm-up exercise - “Design a $100 grizzly bear repellant”

18Questions?

Practice elicitation methods - Brainstorming & Idea Reduction

How about idea reduction?Typical sequence:Clustering & combiningSelecting for interestWorking on those, sequentially, to “push them over” toward acceptabilityEnding-up not just with a list to consider further, but an action plan and who’s going to do what about them

– See handout

19Questions?

Practice elicitation methods - Brainstorming & Idea Reduction

How about idea reduction?

Don’t prune right away (as book suggests)

Need to -- Work on those, sequentially, to “push them over” toward acceptability

– Acceptability +

xx

x

x

xx

x

But how?Brainstormedideas

Poss. Value

xx

20Questions?

Practice elicitation methods - Brainstorming & Idea Reduction

How about idea reduction?How to -- “push them over” toward acceptabilitySynectics adds these steps after picking one with more risk:A.  Ways & Means (How to make it happen – Verbs)B.  Articulation of emerging idea C.  Itemized Response (+’s and –’s) D.  Possible Solution (Reformulation)E.  Next Steps (Action item list)

Let’s try these with the Grizzly Bear Repellant

21Questions?

• Steve’s tips from experience:• Never let people send delegates. You need to

have the decision makers there. They leave with promises to do things, not to seek approvals.

• People need to leave the room with clear action items and dates for completion.

• The facilitator must be allowed to ride herd on anyone’s behavior that’s dysfunctional in the special environment of creating new ideas.

Practice elicitation methods - Brainstorming & Idea Reduction

22Questions?

Practice elicitation methods - Storyboarding

• Ch 13 in R• Show what happened to the players• Sketchy and changeable• Get early “Yes, But’s”

From www.bluntpencil.com/industrial_logistical .

23Questions?

Practice elicitation methods - Storyboarding

• Sketchier than that…

From http://www.copywritersboard.com/special-announcements/4330-death-salesletter-2.html.

24Questions?

Practice elicitation methods - Storyboarding

• Or more professional…

From http://blogs.sun.com/MartinHardee/entry/design_comics_templates_1_0, which also has tips on storyboard use for systems.

25Questions?

Practice elicitation methods - Storyboarding

Steve’s tips:• Works great to

connect with customers and product managers

• Technical people want technical details almost immediately! From

http://www.mercury.com/us/services/consulting/performance-center/performance-validation/works.html.

26Questions?

Use cases

• Ch 14 in R• Purpose – An artifact about how the

system interacts with the outside world• You can evolve it from requirements

through design to acceptance testing• Understandable by audiences on “both

sides”• An alternative way for writing most of a set

of requirements, vs. zillions of “one liners”

27Questions?

Use cases

• What’s in a use case?

• Actors

• A dialog-style flow of events:

– Actor does this

– System does that in response

• We’ll use Alistair Cockburn’s use case style – see template in Handouts

28Questions?

Use cases

Let’s try a use case --Description: Grizzly bear interacts with our

solution to the Repellant:Actors:Pre-conditions:Flow of events:Extensions:Post-conditions:

29Questions?

Use cases

• What do real ones look like?

• See “UseCase-SaveDegreeProgram.doc” in Handouts

• Main thing to get right – showing both sides of the dialog clearly

30Questions?

How Req should look

• Ch 15 in R

• Traditional single document – when it’s part of a contract – completeness and clarity are critical

• Overview with separate additional documents – when agility is the goal – ability to keep enhancing is critical

31Questions?

How Req should look

• Basic design of the document, when you use the agile, separate approach:

• Do it on the web, with lots of hyperlinks – Maybe a Wiki (like Wikipedia uses)?

• Organization and accessibility need to be planned• Pieces include:

– Use cases – Ch 14, 21 in R– Supplementary spec – Ch 22 in R– More – if “requirements” include design-style information

(functional flows, data layout, etc.) – Ch 24 in R

32Questions?

We skipped discussing…

• Ch 16 in R – The vision document

• If you need a separate internal document describing how one project fits in with the overall plans of your engineering group – check it out.

• Could be considered a part of product management.

33Questions?

Product mgmt & Req• Ch 17 in R• Applies to product-type engineering projects,

where sales to multiple customers are expected• Usually a high-level manager does funding, a

product champion below them works with each product line

• Product lines and project teams tend to compete for internal resources

• Need roadmaps for products, technologies, and customers

TechnologyRoadmap

ProductRoadmap

CustomerRoadmap

34Questions?

Product mgmt & Req

• If you’re doing a general-purpose product, there’s more to do:

• At Procter & Gamble, 50% of product planning money goes to R&D…

• Development group always end up supporting what they build…

35Questions?

Keeping a lid on Req

• Ch 18 in R – Establishing product scope• Ch 19 in R – Managing your customer• Functionality, resources and time make a

“triangle” of task scope• Creeping requirements – almost the worst

problem – why?• Agile methods claim to overcome this!

36Questions?

New Bonus – Six Sigma & Req

• Six Sigma is inherently about process improvement

• Especially, improving quality in repetitive tasks

• Design tasks are only somewhat repetitive – you get a new result with every design

• If the design is wrong, all the products stemming from it are wrong – zero sigma

37Questions?

New Bonus – Six Sigma & ReqSix Sigma has requirements and a problem statement as

part of the team charter, which is in Define Phase:

• Team Readiness• Customers (and CTQs*)

– Customer(s) identified and segmented according to their different needs and requirements and

– Data collected and displayed to better understand customer(s) critical needs and requirements. Then

• Team Charter  -- – Project management charter, including business case, problem

and goal statements, project scope, milestones, roles and responsibilities, communication plan.

• Business Process Mapping

*CTQs (Critical to Quality) are the key measurable characteristics of a product or process whose performance standards or specification limits must be met in order to satisfy the customer. From http://www.isixsigma.com/library/content/six_sigma_dmaic_quickref_define.asp.

38Questions?

Upcoming exam

• Next class, June 27, there will be a take home exam. Due to be turned in (to Angel drop box) by Tues night, July 3, 11:59 PM.

• Est. 2 hours to do.

• It will cover everything through what we discuss on Wed, June 27.

• Questions will be like those listed on the final slide of the June 13 lecture.