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. 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 dress 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? B. Use Cases and Goals ------------------------------------------ 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?