I. Use-Case Model: Writing Requirements in Context (Larman, Ch. 6) A. goals and stories (6.1) ------------------------------------------ USE CASE MODEL REQUIREMENTS IN CONTEXT (LARMAN CH. 6) Use case = Key idea: Example in brief format (from StickSync): Add a Directory FOR YOU TO DO, IN PAIRS Write one use case, in brief format, for StickSync's Remove a File: ------------------------------------------ B. Use cases and adding value (6.3) ------------------------------------------ MORE TERMS (6.3) Actor = Scenario = So a use case is: ------------------------------------------ What are some of the actors in the POS system? In the StickSync system? ------------------------------------------ EXAMPLE CASUAL FORMAT USE CASE Add a directory Main Success Scenario: The user tells the system about a directory that should be synchronized with the selected remote computer and PMSD. The system remembers the directory name and the selected remote computer, and records this on the PMSD. Alternative Scenario: ------------------------------------------ II. use case types and formats (6.5) ------------------------------------------ WHAT VS. HOW Black box use cases record what Good (what): The system records the sale. Bad (how): The system writes the sale to the database. ------------------------------------------ Why is recording "how" information bad? ------------------------------------------ FORMALITY TYPES Brief = terse, 1 paragraph summary usually of main success scenario Casual = informal paragraph format, covers multiple scenarios Fully dressed = steps and variants written in detail, all scenarios, includes supporting sections ------------------------------------------ A. two column variation B. fully dressed StickSync example scenario (6.6, 6.7) 1. Primary Actor 2. Stakeholders and Interests Could the government be a stakeholder here? 3. preconditions and postconditions 4. Main Success Scenario (or Basic Flow) 5. Extensions (or Alternate Flows): 6. Special Requirements 7. Technology and Data Variations list C. fully dressed POS example scenario (6.6, 6.7) 1. Primary Actor 2. Stakeholders and Interests 3. preconditions and postconditions ------------------------------------------ PRECONDITIONS AND POSTCONDITIONS (ASSUMPTIONS AND SUCCESS GUARANTEES) preconditions: - what must - are postconditions: - what must ------------------------------------------ 4. Main Success Scenario (or Basic Flow) Why don't we include the cashier greeting the customer? 5. Extensions (or Alternate Flows): 6. Special Requirements 7. Technology and Data Variations list III. Goals and scope of a Use Case (Larman 6.8) A. EBPs What is a useful level to express use cases for application requirements analysis? ------------------------------------------ ELEMENTARY BUSINESS PROCESSES (6.8) What level to express use cases? An EBP = Also quiescence: an EBP starts in a quiescent state and finishes in a quiescent state minimality: an EBP should not contain other EBPs Corollaries big enough: an EBP should be interesting and not too small Guideline: for requirements analysis, focus on use cases at the level of EBPs. ------------------------------------------ Is printing a memo an EBP for a telephone company? Is printing approving credit an EBP for a credit card company? Is building an airport an EBP for a city government? Is hiring a contractor an EBP for a city government? What about a game? B. Use Cases and Goals (skip?) ------------------------------------------ USER GOAL-LEVEL USE CASES recommendation: - find the user goals - define a use case for each ------------------------------------------ what could you ask the user to get at a higher level goal, related to the one that they state? C. Subfunction Goals and Use Cases IV. Finding Primary Actors, Goals, and Use Cases (Larman, 6.9) ------------------------------------------ BASIC STEPS IN REQUIREMENTS ANALYSIS - Choose system boundary. - Identify the primary actors. - For each, identify their user goals. (Highest that is an EBP-level goal.) - ------------------------------------------ A. choose the system boundary what is the system boundary for the POS system? B. identify the primary actors who are the primary actors in the POS system? ------------------------------------------ CHECKLIST TO HELP FIND ACTORS AND GOALS - who starts and stops the system? - who does user and security management? - is there a monitoring process that restarts the system if it fails? - how are software updates handled? - who does system administration? - does the system do something in response to a time event? - who evaluates system activity or performance? - who evaluates logs? ------------------------------------------ 1. actor-goal list 2. event analysis What would be some external events for the POS system? 3. define use cases ------------------------------------------ CRUD CRUD = Common to collapse these goals into one use case: Manage e.g., Manage User ------------------------------------------ V. Other Aspects of Use Cases (Larman 6.10-6.18) A. use cases are imperfect (6.10) ------------------------------------------ THE USE CASES AREN'T RIGHT They will: - lack critical information - contain wrong statements Approaches: - waterfall model (try to do better) + iterative development ongoing personal communication ------------------------------------------ B. write use cases in an essential UI-free style ------------------------------------------ ESSENTIAL UI FREE STYLE "Keep the user interface out; focus on intent." (Cockburn) ------------------------------------------ C. actors (6.12) ------------------------------------------ KINDS OF ACTORS - primary: has goals fulfilled by system - supporting: proivdes services or info - offstage: has interest (e,g., government tax agency) ------------------------------------------ D. use case diagrams (6.13, omit?) E. comparison to feature lists (6.14) F. Use Cases Are Not Object-oriented (6.15) G. Use cases within the UP (6.16, skip) ------------------------------------------ USE-CASE DRIVEN DEVELOPMENT (6.16) - use-case model records requirements - iterative planning chooses use case scenarios or use cases - use-case realizations drive design - use-cases influence the organization of user manuals ------------------------------------------ ------------------------------------------ USE-CASES AND PHASES inception: - Concentrate on finding goals and stakeholders, system boundary - Most use cases identified by name and summarized in a short paragraph - Only 10% written in detail, to help explore risk elaboration - Get feedback at end of each iteration - Write ~20% more use cases in detail at each iteration (focus on most important ones, finish with 80-90% written) - Most use cases not implemented in this phase construction: - minor use case writing - deal with changes in requirements ------------------------------------------ H. case study ------------------------------------------ CASE STUDY USE CASES (6.17) In inception, which use cases in the StickSync system should be: Fully dressed: Casual: Brief: ------------------------------------------ Where is the risk, or importance?