Give Them What They WantKenneth M. AndersonUniversity of Colorado, BoulderCSCI 4448/5448 — Lecture 6 — 09/10/20091Lecture Goals• Review material from Chapter 2 of the OO A&D textbook• Give Them What They Want• Requirements and Use Cases• Discuss the Chapter 2 Example: Todd & Gina’s Dog Door• Emphasize the OO concepts and techniques encountered in Chapter 22Requirements and Use Cases• Chapter 2 does an excellent job of introducing you to the concepts of requirements and use cases• What’s a requirement?• It’s a specific thing your system has to do to work correctly• Who defines “correct” behavior?• The customer!• What’s a use case?• A use case describes what your system does to accomplish a particular customer goal• What’s the relationship between them?• Each requirement can be translated into one or more customer goals3The Scenario• Doug has a company that creates custom dog doors; you work for Doug• Todd and Gina are your first customers• They want a remote-controlled dog door for their dog, Fido• In realistic fashion, the book quickly codes up a solution• It is ALWAYS tempting to go straight to coding… humans love solving problems and humans love to create• for developers, what we create is code!4Brooks Intervention• Fred Brooks has written an excellent article on why developers get themselves into trouble when designing/building software systems• It is the first essay in his book called The Mythical Man-Month, an excellent book that has stood the test of time• First published in 1975• 20th Anniversary edition published in 1995• The article is called The Tar Pit5The Tar Pit• Developing large systems is “sticky”• Projects emerge from the tar pit with running systems• But most missed goals, schedules, and budgets• “No one thing seems to cause the difficulty--any particular paw can be pulled away. But the accumulation of simultaneous and interacting factors brings slower and slower motion.”• CHAOS Report from Standish Group• 34% of (reported) software development projects hit their estimates in 2002 (up from 28% in 2001)• e.g. many projects fail on some project management dimension• In recent years, the numbers have improved but we still have a long way to go6The Tar Pit, continued• The analogy is meant to convey that• It is hard to discern the nature of the problem(s) facing software development• Brooks begins by examining the basis of software development• e.g. system programming7Evolution of a Program8ProgramProgrammingSystemProgrammingProductProgrammingSystemProduct3x3x9xWhat makes programming fun?• Sheer joy of creation• Pleasure of creating something useful to other people• Creating (and solving) puzzles• Life-Long Learning• Working in a tractable medium• e.g. Software is malleable9What’s not so fun about programming?• You have to be perfect!• You are rarely in complete control of the project• Design is fun; debugging is just work• Testing takes too long!• The program may be obsolete when finished!10Returning from the Intervention: The Scenario• Doug has a company that creates custom dog doors; you work for Doug• Todd and Gina are your first customers• They want a remote-controlled dog door for their dog, Fido• In realistic fashion, the book quickly codes up a solution• It is ALWAYS tempting to go straight to coding… humans love solving problems and humans love to create• for developers, what we create is code!• In realistic fashion, the first attempt fails• Gina uses the dog door and discovers a rabbit in her kitchen!11Page 61: Classic Developer ReactionIt’s the User’s Fault!12Classic Developer Reaction• “There’s nothing wrong with our code! Gina must have forgotten to press the button on the remote again after Fido came back in. It’s not my fault she’s using the door incorrectly!”• Wrong!• The user is our customer• The system is not correct until it satisfies the user’s needs• Humbling Experience• Watch a system you’ve developed being tested for usability13Take Two• Given that the “code first, ask questions later” strategy has failed, we now adopt an alternative process• Gather requirements for the dog door by talking to Todd and Gina• Figure out what the door should really do• Get any additional information (i.e. iterate)• Build the door RIGHT• This is the start of an analysis process that will help us with step 1 of our OO!A&D process from last lecture• make sure your software does what the customer wants14What’s a Requirement? Revisited• Def: It’s a specific thing your system has to do to work correctly• A requirement is usually a single, testable thing your system has to do•This is also known as a functional requirement•In contrast to a non-functional requirement that might specify constraints on your system’s robustness, scalability, security, etc.• The focus is on the entire system• A system will typically have (a lot) more than one requirement• It’s the customer who decides what correct behavior is, not the developer• The key problem encountered with the original system was that Todd and Gina expected the dog door to close automatically• Gina opened the door to let Fido out, then never closed it, and the bunny took advantage. (Evil Bunny!)15Initial RequirementsRequirements List1. The dog door opening must be at least 12” tall.2. A button on the remote control toggles the state of the door: it opens the door if closed, and closes the door if open.3. Once the dog door has opened, it should close automatically after a short delay (take that Rabbit!)16Page 65: Classic Developer Reaction, Take Two• “Is this list really going to help? Todd and Gina completely forgot to tell us they wanted the door to automatically close before… won’t they just forget something again?”• Yes, but…• We have to start somewhere and we need to understand what the customer wants• Remember that analysis is an iterative process, you will cycle on• gather and interpret (use case creation)• implement• evaluate• many, many times!• Also be aware that customers will sometimes hold back requirements (because they don’t think you’re ready for them)!17Use Case Creation• After you have requirements, you start to think about what the system really needs to do• this includes thinking about issues that your customer didn’t raise• such as anticipating