CSE 5324 Quiz 3 due at 5 PM, Thursday, 28 August 2014

1. 3. Case Studies, 4. Inception ≠ Requirements Phase, 5. Evolutionary Requirements CSE 5324 Quiz 3 due at 5 PM, Thursday, 28 August 2014

2. 3. Case Studies • Introduction: • Learn fundamentals of OOA/D, requirements analysis, UML and patterns • (i.e., the application logic layer)… • from two familiar examples… • that are rich in complexity and design problems.

3. 3.1 Case Studies Coverage • Focus: core application logic layer (Fig. 3.1). • Similar on all platforms. • The O-O skills obtained also apply to other layers. • Also touches these other other layers: • UI elements, • Database access, • Collaborations with external HW & SW. Fig. 3.1. Sample layers in O-O systems & case study focus.

4. 3.2 Case Study Strategy • Thisbook’s “1st iteration” (of iterative learning) applies OOA/D to core functions. • Analysis/design, UML notation, patterns are iteratively and incrementally introduced later. • Subsequent learning iterations expand into new ideas, more UML and more patterns. Fig. 3.2. Learning path follows iterations.

5. 3.3 The NextGen POS System • The NextGenpoint-of-sale (POS) system: • Records retail sales and handles customer payments. • Interfaces with 3rd-party tax calculator and inventory control systems. • Tolerates faults (runs when 3rd-parties fail). • Supports a variety of POS terminals (e.g., cell phones, thin-client web browsers, Javanese PCs). • Software adapts to various business (rule) plans. • Iterative development includes requirements analysis, OOA/D and implementation.

6. 3.4 The Monopoly Game System • The Monopoly video game: • Very different from POS; same iterations apply. • Runs as a simulation of n players, plus one real player. • Simulated players move in real player’s real time.

7. R U O K ? • Why should you focus your OOA/D studies on the core application layers of example systems? __ • Those layers are similar on all platforms. • The O-O techniques illustrated there also apply to all other layers. • Other layerscan be technology/platform dependent, requiring background knowledge of Java, .NET or Python. • All of the above. • None of the above.

8. R U O K ? 2. What makes the NextGen POS system attractive for application of OOA/D? __ • It is a real system. • Everybody knows generally how it works. • It is a straightforward problem domain. • But it embodies interesting requirements and design problems. • All of the above. • None of the above.

9. R U O K ? 3. What makes the Monopoly game system attractive for application of OOA/D? __ • Strikingly different from the POS system. • But it also provides a rich medium for applying domain modelingand UML and design patterns. • Everybody knows generally how it works. • It is a straightforward problem domain. • All of the above. • None of the above.

10. 4. Inception ≠ Requirements Phase • Objectives: define inception, motivate study. • Introduction: Inception. • Initial short step (project kickoff). • Establishes common vision, scopes project. • Analyzes ~20% of use cases (most critical ones). • Creates business case. • Establishes development environment for programming in the next (elaboration) phase.

11. 4.1 What is Inception? • Proposal Red Team answers these questions: • Vision & business case? (New market segment?) • Proposed work feasible? (Teleportation, anti-gravityand perpetual motion didn’t work out.) • Buy and/or build? (Competitor’s product?) • Order-of-magnitude cost? (And payback?) • Stop or go? • Explore just enough requirements to answer.

12. 4.2 How Long is Inception? • Establishing an initial common vision, deciding the project is feasible, and saying “Go”… • happens quickly if this already is your market. • could take weeks for inexperienced start-ups.

13. 4.3 What Artifacts May Start in Inception? • Only Vis. & Bus. Case artifact is essential (Table 4.1). • Only detailed as needed for understanding. • The Use-Case Model gets most emphasis: • Name most of the use cases and actors. • Describe only ~20% of those in significant detail. • Might reuse old prototype code to prove feasibility of (otherwise “show-stopper”) concept. Table 4.1. Sample inception artifacts.

14. 4.4 Understand Inception? • Inception is not… • A “few weeks” long. • A detailed requirements analysis. • A reliable source of estimates or plans. • An architectural design workshop. • Too many (or not enough) detailed Use Cases to scope the problem.

15. 4.5 How Much UML During Inception? • Little or none, beyond… • simple UML use case diagrams • that help illustrate • the project’s basic scope and • the top ~20% of requirements.

16. R U O K ? 4. Which of the following does NOT accurately describe a UP project’s Inception phase? __ • Short first step of every project (kickoff). • Establishes a common vision. • Gathers all of the project’s requirements. • Determines project scope. • Analyzes (most critical) ~20% of use cases. • Creates a business case. • Stops projects that are judged infeasible.

17. R U O K ? 5. What might shorten an Inception phase’s duration? __ • A company’s prior successes on similar projects. • A start-up company’s burning desire to enter a fertile new market. • An obvious “show stopper” feasibility threat. • Top management’s lack of “vision” in the new product’s market. • All of the above. • None of the above.

18. R U O K ? Arrange the following Inception phase artifacts in order of their importance (most important first): 6. __ 7. __ 8. __ 9. __ 10. __ • A comprehensive list of verbal requirements. • A reused prototype program that clearly demonstrates feasibility. • The Vision & Business Case artifact. • Names of most use cases and actors. • Significantly detailed diagrams of the most important ~20% of the named use cases.

19. R U O K ? 11. Which of the following would you like to see in your next Inception phase kickoff meeting? __ • He has set aside a few weeks for it. • She offers her detailed analysis of requirements. • He relies heavily upon its estimates and plans. • She thinks it is architectural design workshop. • All of the above. • None of the above.

20. R U O K ? 12. Which of the following does NOT describe the UML diagrams typically found in Inception phase meetings? __ • Use case diagrams. • Minimal detail needed to scope the project. • Covering the top ~20% of requirements. • A few sequence diagrams to illustrate object interactions. • Actually all of the above can be found in Inception phase meetings.

21. 5. Evolutionary Requirements • Objectives: • Motivate evolutionary requirements analysis, • Describe FURPS+ • Define artifacts of UP’s Requirements discipline. • Introduction: • Iterative, evolutionary requirements defined. • Waterfall’s “complete” requirements fallacy.

22. 5.1 “Requirements” Defined • Capabilities and conditions to which the product & project must conform. • UP’s requirements management best practices: • A systematic approach to finding, documenting, organizing and tracking… • the changing requirements of a system. • Do it iteratively, skillfully, neatlyand in forms that… • speak clearly to stakeholders and developers.

23. 5.2 Evolutionary vs. Waterfall Rqmts Changing requirements are fundamental drivers: • Unlike low change rate mass manufacturing, • software is in the realm of novel, innovative, high-risk product development, • where 25% of requirements (average) change. • Freezing requirements before development • assures a 85% project failure rate (N=1027). • Such software products do not comply with • 45-64% of their frozen requirements (Fig. 5.1). Fig. 5.1. Actual use of waterfall’s frozen requirements.

24. 5.3 Skillfully Finding Requirements • UP’s requirements management best practices: “a systematic approach to finding, documenting, organizing and tracking them.” • Requirements elicitation techniques: • Sketch customers’ use cases. • Developer & customer requirements workshops. • Proxy customer focus groups. • Customers’ post-iteration demo feedback. • XP’s “story cards” for live-in customer-expert.

25. R U O K ? 13. What is a “requirement”? __ • A capability or condition to which a product or project must conform. • A user interaction, which the customer would like the product to provide. • The customer’s favorite color on the product’s package. • All of the above. • None of the above.

26. R U O K ? 14. Which of the following is NOT among UP’s requirements management best practices? __ • A systematic approach to finding, documenting, organizing and tracking requirements. • Gathering as complete a list of requirements as possible, as early as possible in every project. • Accommodating changes in system requirements throughout a project. • Gathering requirements iteratively, skillfully and neatly. • Presenting requirements in forms that speak clearly to stakeholders and developers.

27. R U O K ? 15. What is wrong with the waterfall software development life cycle? __ • Changing requirements are fundamental drivers in every software development project. • Unlike low change rate mass manufacturing, software is in the realm of novel, innovative, high-risk product development. • During an average software project, 25% of requirements change. • Freezing requirements before development assures a 85% project failure rate (N=1027 projects). • Waterfall-developed software products do not comply with 45-64% of their frozen requirements. • All of the above. • None of the above.

28. R U O K ? 16. Which of the following is the LEAST effective requirements elicitation technique? __ • Sketch customers’ use cases. • Developer & customer requirements workshops. • Proxy customer focus groups. • Customers’ post-iteration demo feedback. • XP’s “story cards” for live-in customer-expert.

29. 5.4 Requirement Types & Categories • Use the following as a requirements checklist: • Most fit into functional, usability, reliability, performance, supportability (FERPS) metrics. • Ancillary (+) requirements fit into implementation, interface, operations, packaging, legal (FERPS+) metrics. • Quality requirements fit into usability, reliability, performance, supportability metrics. • “Functional” requirements are behavioral. • These affect critical systems’ architectures.

30. 5.5 Requirements in UP Artifacts • Required scenarios in use cases. • Non-functional requirements in supplementary specs. • Validation rules & acceptable ranges in data dictionaries. • Project’s business case in a “Vision” executive overview. • Requirements spanning many projects (e.g., govt. regs.) in domain/business rules.

31. 5.6 Examples of These Artifacts? • Use case examples, pp. 61, 493 (table, p. 59). • Supplementary specification, data dictionary (glossary), vision, business rules, see p.101. Table, p. 59

32. 5.7 Recommended Resource • At www.IEEE-elearning.org, the IEEE Computer Society offers an online course called “Software Requirements for the Computer Software Development Associate (CDSA).”

33. R U O K ? 17. What does the FERPS+ acronym mean? __ • Functional, usability, reliability, performance and supportability requirements. • Ancillary (i.e., implementation, interface, operations, packaging and legal) requirements. • Both of the above. • None of the above.

34. R U O K ? Match the following requirements with the UP artifacts in which they can be found: 18. Required scenarios __ 19. Non-functional requirements __ 20. Validation rules & acceptable ranges __ 21. Project’s business case __ 22. Requirements spanning many projects __ a. Data dictionary. b. Domain/business rules. c. Use cases. d. Vision. e. Supplementary specs.