1Questions?

CSSE 490 - Requirements

Steve ChenowethDepartment of Computer Science &

Software EngineeringRHIT

Session 4 – Wed, June 27, 2007Above – Quality – the 4th dimension of the 3-legged engineering stool. Its inclusion in project planning has varying impacts on the other three. Pic from www.codinghorror.com/blog/archives/2006_10.html .

2Questions?

Today• Review use cases and “early prototypes.”• Req vs design.• Use cases design.• Quality attributes & the Supplementary spec.• How much detail?• Use cases test cases.• Implementing (in our case, prototyping).• Traceability.• Change management.• What are quality Req?• Team skills.• Can it be agile? – picking an approach.• Take-home exam.

3Questions?

Review use cases and “early prototypes”

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

• What was tough?

• How long (big) are they?

• Did your sources understand these?

4Questions?

Req vs design

• Ch 20 in R• What it is, vs how to do it• Building the right system, vs building it right• Req only, not design, go into “Req”• Also, no project info in “Req,” like schedules• In theory, it’s all:

– Inputs & outputs (the features – the “Function”)– Quality attributes (how well – the “Form”)– Constraints in which it must work (“Economy” &

“Time”)

5Questions?

Req vs design

• In theory, maybe Req is just:– Inputs & outputs

• …if these are slightly extended to also describe “how well” & relationship to the environment:

Image from hydram.epfl.ch/VICAIRE/mod_1b/chapt_1/text.htm , which also introduces general systems theory.

6Questions?

Req vs design

• E.g., customer needs a thermostat :

Is it enough to say, “We want the one on the left, not the one on the right”?

Image from http://perso.orange.fr/michel.terrier/radiocol/detail2003/thermostat-gb.htm.

7Questions?

Req vs design

• Engineers developing it will disagree about “what’s design” – from their perspective, Req is everything you have to tell them

• What’s the gap before engineers can implement what you’ve got already?

• What should the next document be, if any?– Typically “design” (the rest of it you have to tell them)– In big, messy systems – “architecture” comes next (or

before)

8Questions?

Req vs design

• If Req is “everything you have to tell them,” then “design” or “architecture” creeps in, at least:

Image also from hydram.epfl.ch/VICAIRE/mod_1b/chapt_1/text.htm. The “SS” boxes are sub-systems. Arrows inside the whole system depict their communications. This is “architecture” – the highest-level design.

9Questions?

Req vs design

• Exercise – See if you can spot “design” disguised as “requirements” in someone else’s work.

• See problem statement handout…• Read the document• Find the “most obvious 2 examples” of design

posing as requirements• We’ll go around the room – say what it’s about

and what the two examples were…

10Questions?

Req vs design

• A part of the problem is that engineers like to jump right to the solution if they can – “Blink* decisions.” This works great if it’s a subject you know all about!

• Also (need we mention) everyone’s rewarded for acting that way in business.

• New stuff isn’t like that, though…• Which is why, say, we have to make everyone

“turn that off” when we do brainstorming.*See Blink: The Power of Thinking Without Thinkingby Malcolm Gladwell, ISBN 0316010669.

11Questions?

Req vs design• For new stuff…• Use something like the Synectics model,

described last week, or• The Creative Problem Solving Process of

Osborn – Parnes* -- 1993 version follows • Shows where the following people would be

involved:– Cust = Customers / clients, etc.– SE’s = Systems Engineers, Req people, etc.– Engrs = Other Engineers developing solution

*See for example http://www.unc.edu/~gdhughes/ARTICLES.HTM, http://www.greggfraley.com/OsbornParnes.htm.

12Questions?

Purpose

To singleout a goal or objective and set its priority.

Outcomes

Decision to solve using CPS and reasons for doing so

Goal

To get a betterunderstanding of the “mess”or objective

To identify challenges

More informa-tion enabling aclearer under-standing and generating aninitial problemstatement.

To broadenawareness ofthe problem and its sub-problems.

Series of prob-lem statementsfrom which tochoose the most opportune challenge to solve.

To generateanswers to theproblem state-ment (possiblesolutions).

Series of ideasor alternative actions thatmay solve theproblem.

To select andevaluate fromaction alterna-tives for “fit.”

One or more solutions tothe problemselected fromideas oralternative actionspreviouslygenerated.

To identifyresources thatwill support theselectedsolution.

Listing of resources andaction stepsneeded to sell and implementthe selectedsolution.

To put intoaction theselectedsolution.

Action monitorand evaluateprogress.

Purpose and Outcomes

Objective FACT PROBLEM IDEA SOLUTION ACCEPTANCE Implementation“Mess” Finding Finding Finding Finding Finding

General Purpose Problem SolvingThe Osborn– Parnes “Creative Problem-Solving” (CPS) Model… Question: Who does most of the work at each stage?

Cust X X X x ? x X SE’s x X X x ?Engrs ? x X X X

13Questions?

Use cases design

• Ch 21 in R• Use cases are supposed to evolve as you get into “how it works,”

becoming a key part of the design• Add design info (like interface operation details in “UseCase-

SaveDegreeProgram.doc”) Ch 25• More alternative flows as design is elaborated• But save the “requirements version of use cases,” too• And keep up to date

– Then they’re still good to start the next release, or the next project like this, but…

– As design use cases are changed, maintenance of the Req version starts to feel like it’s a needless chore!

• Also make test cases out of use cases Ch 26

14Questions?

Quality attributes & the Supplementary spec

• Ch 22 in R• Next project doc – Supplementary spec• See template & example in Handouts• Use same Quality Attr as in Problem Stmt

– Usability – Modifiability – Availability – Security– Performance – Testability

– & Any others you added

15Questions?

Quality attributes & the Supplementary spec

• Let’s try Quality Attr scenarios for the grizzly bear repellant:– Usability – Modifiability – Availability – Security– Performance – Testability– Any others?

• See handouts of the Suppl Spec template – examples of scenarios

• Pick a quality attribute, and invent a scenario for the grizzly bear repellant requirements, which were, roughly, “Keep the bears out of transformers in the Canadian woods for $ 100 per installation.”

16Questions?

Quality attributes & the Supplementary spec

• Now, lets check these against our solution idea, for fun!

This idea was, roughly, “Find a bear-repelling frequency, then invent a device that emits that freq and can be attached to transformers in the woods (for $ 100).”

17Questions?

How much detail?

• Ch 23 in R• “Sweet spot” – time vs cost of misunderstanding• A learned skill, based on audiences• Ch 20 is based on theories of when to stop based on

quality vs time considerations• Stopping rules I’ve actually used:

– When the developers understand them– When the client agrees everything’s in them– When it’s time for the scheduled meeting to approve them– When the developers are done with their prior project– When you must start developing or you’ll be behind your

competition

18Questions?

Left out – Technical methods

• Ch 24 in R • Pseudocode• Finite state machines• Decision tables / trees• Flowcharts• Entity-relationship diagrams

There tend to be standard types used in each engineering discipline.

19Questions?

Implementing (in our case, prototyping)

• Ch 25 in R

• Also part of next week’s project work -- How could you make something one step more sophisticated than the storyboard prototype?

• How can you make it so that something can be tested / verified as a result?

20Questions?

Implementing (in our case, prototyping)

• What prototyping tools are available in your engineering domain?• General options:

– Simulation tools • Examples – http://www.idsia.ch/~andrea/simtools.html, Maya, Adobe After Effects,

Macromedia Flash, Camtasia• Discrete event simulations• Zillions exist (many also domain specific – just Google)• Example – Human gait analysis – http://www.frontiernet.net/~imaging/gait_model.html• Example – Hashing algorithm comparison –

http://www.engin.umd.umich.edu/CIS/course.des/cis350/hashing/WEB/HashApplet.htm • Example – Climate control – http://physioweb.med.uvm.edu/homeostasis/complex.htm

– Paper prototyping• See http://www.paperprototyping.com/what.html .• Gets users involved

– PowerPoint• Animation • Flip thru

21Questions?

Implementing (in our case, prototyping)

– PowerPoint -- Flip thru in action (from Example – Climate control)

22Questions?

Implementing (in our case, prototyping)

– PowerPoint -- Flip thru in action (from Example – Climate control)

23Questions?

Implementing (in our case, prototyping)

– PowerPoint -- Flip thru in action (from Example – Climate control)

24Questions?

Implementing (in our case, prototyping)

– PowerPoint -- Flip thru in action (from Example – Climate control)

25Questions?

Implementing (in our case, prototyping)

– PowerPoint -- Flip thru in action (from Example – Climate control)

26Questions?

Implementing (in our case, prototyping)

– PowerPoint -- Flip thru in action (from Example – Climate control)

27Questions?

Use cases test cases

• Ch 26 in R

• It’s 1 use case many test cases

• Modern technology lets us try for: “Make as many tests automated as possible”

• Since many of those tests can be on a model / prototype or otherwise be in software, it’s feasible

28Questions?

Traceability

• Ch 26 & 27 in R• Req use cases Acceptance testing

– “Black box” testing

• Impl use cases Integration & system testing– “White box” testing

• Testing terms – see p. 307• Traceability – vastly improved by having 1

interrelated set of documents

29Questions?

Change management

• Ch 28 in R

• Question of keeping Req up to date…

• In software, we recognize that Req changes occur, live with that

• What’s an “Easter Egg”?

30Questions?

What are quality Req?

• Ch 29 in R

• Ready to use when you need them

• Correctness

• Req process quality

31Questions?

Team skills

• “Getting Started” section in R• Need an encompassing Req management• Skill 1 – Analyzing the problem• Skill 2 – Understanding user & stakeholder

needs• Skill 3 – Defining the system• Skill 4 – Managing scope• Skill 5 – Refining the system definition• Skill 6 – Building the right system

32Questions?

Can it be agile? – picking an approach

• Ch 30 in R

• Process Q - How to mitigate risks

• Process options:– Extreme– Agile– Robust

33Questions?

Left out – Summary

• Ch 31 in R

• Simplified prescription: Understand the problem being solved

34Questions?

Take-home exam

• It’s under “Quizzes”

• Let’s take a look (available at class time)