IT:AD:Use Case

• A Use Case Diagram describing the Actors and one or more Use Cases.
• Each Use Case:
  • is one of the bubbles in the Diagram. (see diagram title below and desc above)
  • is named with a Verb-Noun of an achievable Business Goal (Goal is defined as an operation that delivers an outcome).

    • “Make Reservation” is one. So is “Edit Foo Record”.
    • “Select Country” is not one – it’s a Use Case Flow step that does not need to be included in a diagramming (unless we’re talking about a Sequence diagram).
    • associated to a Use Case Text (flipping the card) laid out as:
    • Precondition: conditions user can assume to be true before starting the use case.
    • Basic Flow: Steps involved in use case, and Actor involved.
    • Alternate Flow: Capture less common variations to the common flow (eg, new user, having to supply info not yet known)
    • Exception Flow: Capturing condition handling incorrect flow (Validation/etc.)
    • Postconditions: conditions user can assume to be true at end.

Where Use Cases cross over with scrum agile: * I think each Use Case Text can be seen as a User Story, with normal/alt/exception flows. For example:

• Normal flow: “As a Munchkin, I would like Cookies When I growl”
• Alternate flow: “As a Munchkin, who has not eaten all day, I would like more cookies when …”
• Etc.

* I think an Epic would be a logical group of Use Cases that work together. IE:a Use Case Boundary, or Use Case Diagram, containing 3 use cases all about Foo Records. Themes are Use Cases on the same subject, but not necessarily having to work together:

• “View FooRecord”
• “Edit FooRecord”

A SAD should have have few (less than 7) Use Case diagrams summarizing the system. If more, consider whether they are too fine-grain.

For example the following Diagram is could be considered too fine grain.
We're really talking about Creating, Editing, Merging, Approving, Retiring, where Login/Logout and Search are more like Flow steps. On the flip side, there is a point to be said that Login can get pretty complex with 2FA and definitely more than just a Flow step. But Search and Browse can be combined as one Use Case.

• Disadvantages:
  • Not well suited for non-interaction requirements (eg: business logic requirements) and IT:AD:Non-Functional Requirements
  • No formal way of expressing sequence, bar listing Actions vertically as best as possible.
  • No fully standard definitions of use cases.
  • Some use case relationships (eg: <<extends>>), are ambiguous and difficult for stakeholders to understand.

• https://en.wikipedia.org/wiki/Use_case
• https://www.visual-paradigm.com/tutorials/writingeffectiveusecase.jsp