6.8. Example: Process Sale, Fully Dressed Style
Fully dressed use cases show more detail and are structured; they dig deeper.In iterative and evolutionary UP requirements analysis, 10% of the critical use cases would be written this way during the first requirements workshop. Then design and programming starts on the most architecturally significant use cases or scenarios from that 10% set.Various format templates are available for detailed use cases. Probably the most widely used and shared format, since the early 1990s, is the template available on the Web at alistair.cockburn.us , created by Alistair Cockburn, the author of the most popular book and approach to use-case modeling. The following example illustrates this style.Main Success Scenario and Extensions are the two major sections First, here's the template:
Use Case Section | Comment |
---|---|
Use Case Name | Start with a verb. |
Scope | The system under design. |
Level | "user-goal" or "subfunction" |
Primary Actor | Calls on the system to deliver its services. |
Stakeholders and Interests | Who cares about this use case, and what do they want? |
Preconditions | What must be true on start, and worth telling the reader? |
Success Guarantee | What must be true on successful completion, and worth telling the reader. |
Main Success Scenario | A typical, unconditional happy path scenario of success. |
Extensions | Alternate scenarios of success or failure. |
Special Requirements | Related non-functional requirements. |
Technology and Data Variations List | Varying I/O methods and data formats. |
Frequency of Occurrence | Influences investigation, testing, and timing of implementation. |
Miscellaneous | Such as open issues. |
Please note that this is the book's primary case study example of a detailed use case; it shows many common elements and issues. It probably shows much more than you ever wanted to know about a POS system! But, it's for a real POS, and shows the ability of use cases to capture complex real-world requirements, and deeply branching scenarios. |
Scope : NextGen POS applicationLevel : user goalPrimary Actor : CashierStakeholders and Interests :
Preconditions: Cashier is identified and authenticated.Success Guarantee (or Postconditions): Sale is saved. Tax is correctly calculated. Accounting and Inventory are updated. Commissions recorded. Receipt is generated. Payment authorization approvals are recorded. |
Main Success Scenario (or Basic Flow) :
*a. At any time, Manager requests an override operation: |
Special Requirements:
Technology and Data Variations List: *a. Manager override entered by swiping an override card through a card reader, or entering an authorization code via the keyboard.3a. Item identifier entered by bar code laser scanner (if bar code is present) or keyboard.3b. Item identifier may be any UPC, EAN, JAN, or SKU coding scheme.7a. Credit account information entered by card reader or keyboard.7b. Credit payment signature captured on paper receipt. But within two years, we predict many customers will want digital signature capture. Frequency of Occurrence: Could be nearly continuous.Open Issues :
|