<<The name of the use case should be a concise verb phrase term that captures the essence of the activity being described. Example: "send a message", "authenticate to a service", "discover a transaction endpoint".>>
Description
<<Provide a description of the use case.>>
Champion / Stakeholder
<<Identify the champion(s) who will develop the use case, and stakeholder(s) with a tangible interest in the use case.>>
Actors
<<Provide a list of the actors, including what type of entity they are and what their role in the use case.>>
<<Should we consider including bad actors who do not do what they are "supposed to"?>>
Alice | A person who sends a message. |
Bob | A person who receives a message. |
Mal | A person who intercepts a message. |
Prerequisites / Assumptions
<<Provide a description of all assumptions or prerequisites that need to be in place for the use case to be applicable or possible.>>
Use Case Steps/Sequence Diagram
<<At the risk of being pedantic - sequence diagrams are farther down the development chain. Before we get there we should be able to articulate a use case using a use case diagram, n'est ce pas?
...
<<Provide the list of steps.>>
1 | Alice sends Bob a Message. |
2 | Bob thinks about it. |
3 | Bob sends Alise a Response. |
<<Do we want to use sequence diagrams? There's a nice online tool here.>>
End State
Describe the end state or states at the end of the Use Case. If the use case proceeds as it is supposed to, what is the successful (and hopefully testable) end state. If the use case does not proceed, how does it fail?
Success
...
Failure
...
...