it:ad:use_case:home

IT:AD:Use Case

Summary

  • A Use Case is for mapping Business Goals.
  • 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.


!includeurl http://skysigal.com/_media/resources/configuration/plantuml/default.txt

User <|-- Admin

rectangle "Manage Session" {
User --> (Login)
User --> (Logout)
}
rectangle "Manage Foos" {
User --> (Search Foos)
User --> (Browse Foos)
User --> (Create Foo)
User --> (View Foo)
User --> (Edit Foo)
User --> (Foos Merge Request)
Admin --> (Approve Foos Merge Request)
User --> (Decommission Foo)
}

  • 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.