meeting -*- Outline -*- * 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. ------------------------------------------ Q: 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 ------------------------------------------ ** two column variation There is also a two-column variation see pp. 53-54 idea is to emphasize the division between the actor's actions and the system's responsibilities can identify who's doing what in the one-column format by: not mixing system and actor's actions in one step (and mentioning the actor in each step) ** fully dressed scenario (6.6, 6.7) Fully dressed example should be developed in front of and with students, based on section 6.6-6.7 of Larman's book Parts of fully-dressed scenario *** Primary Actor Primary Actor: Cashier *** Stakeholders and Interests Stakeholders and Interests - Cashier: wants accurate, fast entry and no payment errors, as cash drawer shortages are deducted from salary - Salesperson: wants sales commissions updated - Customer: - Company: - Government: - Payment Authorization Service: This section is important the system helps stakeholders to interact, it's a (social) contract among them "The idea of use cases are to capture all and only the behaviors related to satisfying the stakeholder's interests" -- Cockburn Thus thinking about what the stakeholders want helps figure out what should go in the use case. Also helps make sure noone's requirements are forgotten e.g. salesperson and their commissions (In general it's helpful to split things up this way, so can focus on different aspects at different times.) *** preconditions and postconditions ------------------------------------------ PRECONDITIONS AND POSTCONDITIONS (ASSUMPTIONS AND SUCCESS GUARANTEES) preconditions: - what must - are postconditions: - what must ------------------------------------------ ... always be true before beginning a scenario ... not tested withing the use case (assumed!) focus on noteworthy ones (not that the system has power) ... always be true on successful completion of the use case either main success scenario, or some alternatvive path the guarantee should meet the needs of all stakeholders e.g. Preconditions: Cashier is identified and authenticated. Success Guarantee (Postconditions): Sale is saved. Tax is correctly computed. Accounting and inventory are updated. Commissions are recorded. Receipt is generated. *** Main Success Scenario (or Basic Flow) also called the "happy path" typical usage, satisfies all stakeholders often doesn't include any conditions or branching (Larman suggests defering all branching to extension section) Kinds of steps: - Trigger event (usually step 1 of scenario) - Interaction between actors and the system - A validation (usually by the system) - A state change by the system (recording, modifying something) Main Success Scenario (or Basic Flow): 1. Customer arrives ata a POS checkout with items to purchase. 2. Cashier starts a new sale. 3. Cashier enters item identifier. ... Q: Why don't we include the cashier greeting the customer? *** Extensions (or Alternate Flows): very important, often larger and more complex than the happy path The extensions are branches from main success scenario, so their numbering starts from it Extensions 3a. Invalid identifier: 1. System signals error and rejects entry 3b. There are multiple of the same item category and tracking unique identity is not important (e.g., 5 bananas): 1. Cashier can enter item category and the quantity Extensions have two parts: the condition and how it's handled guideline: write the condition as something that the system (or an actor) can detect Alternatives may apply to more than one step, and may take several steps: 3-6a: Customer asks Cashier to remove an item from the purchase. 1. Cashier enters the item identifier for removal from the sale. 2. System displays updated running total. Can deal with extensions within extensions: 7b: Paying by credit: 1. Customer enters their credit account information. 2. System requests payment validation from external Payment Authorization Service System. 2a. System detects failure to collaborate with external system. 1. System signals error to Cashier. 2. Cashier asks Customer for alternative payment. If an extension condition is possible during any (or most) steps, then use labels *a, *b, ...: *a. At any time, System crashes: In order to support recovery and correct accounting, ensure that all transaction sensitive state and events can be recovered at any step in the scenario. 1. Cashier restarts the System, logs in, and requests recovery of prior state. 2. System reconstructs prior state. *** Special Requirements describe non-functional requirements, quality attributes, or constraints specific to this use case (e.g., performance, reliability usability, design constraints -- such as I/O devices): Special Requirements. - Touch screen UI on large flat panel monitor. Text must be visible from 1 meter. - Credit autorization response within 30 seconds 90% of the time - Language internationalization on the text displayed. - Pluggable business rules to be insertable at steps 2 and 6. These are often conslidated in the Supplementary Specification, later, because the affect the architecture *** Technology and Data Variations list Decisions that are mandated, often relating to I/O devices or standards. Best to avoid these if possible, but sometimes cannot. Technology and Data Variations List: 3a. Item identifier entered by laser scanner or keyboard. 3b. Item identifier may be UPC, EAN, JAN, or SKU coding scheme. 7a. Credit information entered by card reader or keyboard. 7b. Credit payment signature captured on paper receipt. But with two years, we predict many customers may want digital signatures. Suggestion: (p. 59) Don't use multiple steps in this section to express varying behavior; if that is necessary, use the extensions section.