CSSE 490 - Requirements

1. Note – I often put the next lecture out on the server so you can see what’s coming up. But I reserve the right to add/change things up till class time! CSSE 490 - Requirements Steve Chenoweth Department of Computer Science & Software Engineering RHIT Session 2 – Wed, June 13, 2007 Above – Tell us your requirements! The power advantage can be on either side. This scene’s actually from a production of the play “The Dumb Waiter” by Harold Pinter, www.bestheatre.com/ .

2. Today • Discuss case histories (5-10 min each). • Discuss project descriptions (~ 5-10 min each). • Problem analysis & problem statements (see Handouts). • Business modeling. • Req & Systems Engineering. • Why elicitation’s hard? • What’s a feature? • What you wanted in this course (review) • Bonus – What kinds of questions could be on an exam?

3. Discuss case histories (5-10 min each) • Trade with someone else • Read theirs • Read their analysis at the end • Tell us about it • Tell us if you agree with their analysis! • Was it believable?

4. Discuss project descriptions (~ 5-10 min each) • Generally describe your project (paying attention to intellectual property) • What’s your client like? • What’s the value of the project (generally)? • How easy will it be for you to get access to the right people?

5. Problem analysis & problem statements (see Handouts) • Ch 5 in R • This is the forerunner to requirements • Goal – deep understanding w/o details on this: • Step 1 – Get agreement on the problem • Step 2 – Root causes • Step 3 – Stakeholders & users • Step 4 – System boundary • Step 5 – Other constraints With new problems – all these steps cycle on you!

6. Problem statements Key aspects to a problem statement: • Readable by everyone • Define what it won’t do • Define what it will do – main features, at a high level* • Define how well – quality attributes • Always up to date • Tell it in different perspectives – like what? *More like “needs & wants,” perhaps.

7. Problem statements • Tell it in different perspectives – we stole these from CRSS*: • Function – Economy • Form – Time • F/F/E/T for short – But what are they? *CRSS, Houston, TX, was at the time the largest architectural firm in the US, specializing in this type of building (public & private, elementary, secondary, and higher education). They’re now part of HOK. See www.HOK.com. See also Problem seeking: An architectural programming primer, by William Peña, AAAI, 1977.

8. Problem statements F/F/E/T of a system: • Function: What does it do, and for whom? (Features perspective – the short list) • Form: What is it (its “quality attributes”)? (How well) • Economy: How does it create value (for whom?) at what cost (for whom?) • Time: How does it relate to past, present and future? (E.g., what’s it replace?)

9. Problem statements F/F/E/T of a system: Tricky ones -- E & T -- • Economy: What you’re looking for is • Single Greatest Benefit & Total Est. Benefit (of key features) • Then take Problem Stmt back to engg and calc • Single Greatest Cost & Total Est. Cost • For economic feasibility: • If SGB > TEC, then Can’t lose! • If SGC > TEB, then Can’t win! • If feature list changes, SGB can change

10. Problem statements F/F/E/T of a system: Tricky ones -- E & T -- • Time: Strategic pieces include: • What has to change in the environment to make room for it • What it has to make room for • Market window:Need to end up doing this  Right – Typical market C vs. P guess, from http://sustainable.tamu.edu/publications/organicproduce/markets/markets.html.

11. Problem Statements – Let’s do one! • I have 5 things to do in TH tomorrow morning: • Meet with a new prof about the course he’ll be teaching • Talk to a client about extending a current job • Talk to a dept head about a programming project he wants to do • Check in on my two dept heads about what I’m teaching this fall • Hear a readout from two consultants on a compliance analysis they did • Problem: How to do it? Format: See Ins & Outs of Problem Statements in Handouts.

12. Business modeling • Ch 6 in R • This is analogous to defining the environment in which a system must operate, in engineering generally • What’s the existing machinery / operation? • What’s this thing’s predecessor like? • How will the new system fit in?

13. Business modeling • There has to be a way to do this! • You want the engineers to visualize how the new system will fit in, as they work • Common tools – • Diagrams with explanations (like UML) • Simulations • SOP’s Image from simulation, at http://www.ifen.unibw-muenchen.de/research/gnss_simulator.htm.

14. Business modeling • Typical SOP’s – Easy to use? • For a taste, see OSU’s Compressed Gasses SOP’s: http://www.biosci.ohio-state.edu/safety/SOP/CompressedGases.htm. The OSU building for Industrial, Welding, and Systems Engineering, from www.osu.edu/mobile/map/building.php?building=280 . Hey Dave, do I smell a leak?

15. Req & Systems Engineering • Ch 7 in R • Means different things in different orgs: • At Lexis-Nexis, Sys Engrs keep systems running • At NCR, they are the technical people who support sales, doing pre-sale, installations and training • At AT&T, as noted last week: • In some orgs they translate requirements to terms the developers understand – a smaller role • In other orgs they are the system architects, and also invent a part of the design as “requirements” – a larger role • I.e., we had Sys Engrs who were pawns and some who were kings. • What do Sys Engrs do in your organization? • What’s INCOSE say? See esp their Evolution of Sys Engg article.

16. Req & Systems Engineering • In some way, Sys Engg always refers to a role requiring a “systems view” – the big picture. • But the Sys Engg could be about: • Operations • Performance • Testing • Manufacturing • Etc • Or, all of these!

17. Req & Systems Engineering Most often, Sys Engg is about* -- • Creating or adapting systems so that they achieve a variety of goals • Solving hard problems where the goals may conflict • Having a big-picture, long-term view *See, for example, Arthur D. Hall’s books, A Methodology for Systems Engineering, Princeton NJ, 1962; and Metasystems Methodology: A New Synthesis and Unification (Ifsr International Series on Systems Science and Engineering, Vol 3), Pergamon, 1989, ISBN-10: 0080369561.

18. Req & Systems Engineering • As the book notes, Sys Engg also refers to someone who uses “systems thinking” • It’s all about the “lines and boxes” • Right – The architecture of “Ant,” from www.lattix.com/technology/antexample.php.

19. Why’s elicitation hard? • Ch 8 in R. • “Yes but” syndrome • “Undiscovered ruins” effect • “User and developer” cultures Right - Developer-think about users, in action. From http://headrush.typepad.com/creating_passionate_users/2005/week5/index.html.

20. Why’s elicitation hard? Security What gets built – the chosen solution space What should get built – The Real Problem Space Maint & Admin What the Client Asked For Reliability Performance A similar view – See Davis & Zowghi article. A cynical view: The “Solution Space” is governed by pragmatics. And, what the project focuses on (like features we can sell)

21. Why’s elicitation hard? It’s perceived as a little bit adversarial: “Conducted by a skillful intelligence collector, elicitation appears to be normal social or professional conversation and can occur anywhere – in a restaurant, at a conference, or during a visit to one’s home. But it is conversation with a purpose, to collect information about your work or to collect assessment information about you or your colleagues.” At least in the spy business… See http://rf-web.tamu.edu/security/secguide/T3method/Elicit.htm.

22. Why’s elicitation hard? • Time to try eliciting! • I’ll go through the slide presentation on Instant Connections (in Handouts on the web site)… as “Steve Jobless,” CEO. • You write down 4 good questions to ask as I talk. • You’ll have a few minutes to ask the questions. • We’ll all figure out what we now know about the Instant Connections product idea.

23. What’s a feature? • Ch 9 in R. • Feature = Desired system behavior. • For talking, need a short list. • And, need to prioritize A visual explanation of the difference, from http://spaceuser.blogspot.com/search/label/Space%20Automation.

24. What’s a feature? • Feature = details of clients’ wants & needs • Prioritize by asking how much they want it: Don’t want!   Need! Wouldn’t Don’t Don’t Like Gotta buy it if it like it care it have it! has that!

25. What’s a feature? Another view: • Req start as “needs and wants” • Usually explore Req top-down • Would like to build Sys bottom-up (and it all magically works when integrated!) • Not bloody likely! – need to match Req and Sys being built, at each level! Req Sys Figure from http://www.protoolkits.com/Analysisandrequirements/needsfeaturesandrequirements.html.

26. What’s a feature? Then, are these features (on a messaging Sys)? • Send to multiple recipients • Set min/max password length • Display active topics of all subforums • Set search flood interval to limit server load • Templates are cached • Set group avatar What issues do these features bring out? From http://www.phpbb.com/about/features/.

27. What you wanted in this course (review) • Functional Req for software • User Req • Automation / swre Req • Build on Sys Engg (3 people) • Product management / customer specs • Product management / internal (sales & applied engineering) & external

28. Bonus – What kinds of questions could be on an exam? • Suppose you need to find out what your wife (girlfriend) wants for her birthday, but you can’t ask her directly. Write the conversation that would take place through which you would discover what she wanted. • Everyone knows you should separate problem from solution. Then why does everyone mess up on this, and jump right to trying to solve it, after the client finishes his first sentence about requirements? • A lot of the value of having a problem statement comes from being able to match it against the high-level design. When you do that, what should you expect the designers to do? • In doing iterative development, everyone gets into starting the next cycle with just a list of new features and old bugs. They then try to prioritize that list, and figure out how much can be done in some timeframe. Propose a better basis for iterative cycles, and explain why it’s better! • So, when can you stop doing requirements? • XP claims you can just get short “user stories” at the start of a project, use that to plan stages based on those stories. Later, you get the details. When would this work well, and when not? • How are requirements inherently different when coming from a product manager, versus coming directly from a key customer? • Besides the existing SOP’s , what else must you know about the environment to close the Time loop in the problem statement? • It is commonly claimed that requirements is an analysis, whereas engineering proper is a synthesis. Argue the reverse. • What’s the proper order for the following activities, and why is that best? • Designing acceptance tests for the product • Getting the requirements from a customer • Architecting the product • Planning how to build the product • Detailing the product design