CSSE 490 - Requirements

CSSE 490 - Requirements Steve Chenoweth Department of Computer Science & Software Engineering RHIT Session 4 – Wed, June 27, 2007 Above – 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 .

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.

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?

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

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.

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.

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)

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.

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…

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 Thinking by Malcolm Gladwell, ISBN 0316010669.

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.

General Purpose Problem Solving The Osborn– Parnes “Creative Problem-Solving” (CPS) Model… Question: Who does most of the work at each stage? Objective FACT PROBLEM IDEA SOLUTION ACCEPTANCE Implementation “Mess” Finding Finding Finding Finding Finding Cust X X X x ? x X SE’s x X X x ? Engrs ? x X X X Purpose and Outcomes Purpose To single out a goal or objective and set its priority. Outcomes Decision to solve using CPS and reasons for doing so Goal To get a better understanding of the “mess” or objective To identify challenges More informa- tion enabling a clearer understanding and generating an initial problem statement. To broaden awareness of the problem and its sub- problems. Series of problem statements from which to choose the most opportune challenge to solve. To generate answers to the problem statement (possible solutions). Series of ideas or alternative actions that may solve the problem. To select and evaluate from action alterna- tives for “fit.” One or more solutions to the problem selected from ideas or alternative actions previously generated. To identify resources that will support the selected solution. Listing of resources and action steps needed to sell and implement the selected solution. To put into action the selected solution. Action monitor and evaluate progress.

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

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

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

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

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

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.

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?

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

Implementing (in our case, prototyping) • PowerPoint -- Flip thru in action (from Example – Climate control)

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

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

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

What are quality Req? • Ch 29 in R • Ready to use when you need them • Correctness • Req process quality

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

Can it be agile? – picking an approach • Ch 30 in R • Process Q - How to mitigate risks • Process options: • Extreme • Agile • Robust

Left out – Summary • Ch 31 in R • Simplified prescription: Understand the problem being solved

Take-home exam • It’s under “Quizzes” • Let’s take a look (available at class time)

CSSE 490 - Requirements