A condition that must be true BEFORE a use case starts is a:
Use-Case Detailed Specification
Two templates (styles) for writing a detailed use-case specification: ID, actors, description, preconditions, postconditions, normal flow, alternative flows and exceptions.
How to read this page
Every original slide is shown unchanged. Yellow marks on a slide point to a numbered note: hover or tap a mark to jump to its note, and hover a note to see its marks. Questions tagged Past exam appeared on a real paper; Prediction questions are likely angles, not confirmed. Pick an answer to each question: a wrong pick tells you why it is wrong, so you can try again.
All 6 slides
- 1 PSU: Use-case Detailed Specification — Style 1
- 2 PSU: Use-case Detailed Specification — Style 1 (cont'd)
- 3 PSU: Use-case Detailed Specification — Style 1 (cont'd)
- 4 PSU: Use-case Detailed Specification — Style 2
- 5 PSU: Use-case Detailed Specification—Style 2 (cont'd)
- 6 PSU: Use-case Detailed Specification — Style 2 (cont'd)
PSU: Use-case Detailed Specification — Style 1
Notes
Fields: ID and name, primary/secondary actors, description, trigger, preconditions, postconditions, normal flow, alternative flows, exceptions, priority, business rules.
Exam angle
An error path such as "card declined" belongs in the:
PSU: Use-case Detailed Specification — Style 1 (cont'd)
PSU: Use-case Detailed Specification — Style 1 (cont'd)
PSU: Use-case Detailed Specification — Style 2
Notes
Style 2 writes the flows as numbered actor-action / system-response pairs.
PSU: Use-case Detailed Specification—Style 2 (cont'd)
PSU: Use-case Detailed Specification — Style 2 (cont'd)
