To promote consistency in the contributed content, please read these style and composition notes for use cases. Thank you.
The guidance here is from the book Writing Effective Use Cases by Alistair Cockburn. The intent is to provide guidance to produce the smallest, essential parts of a use case.
The use case style is oriented to text descriptions of how the system behaves with respect to a list of Actors.
The book has a list of reminders for writers:
The book recommends the following order when writing:
NOTE: We expect to collect existing use case documents whenever possible rather than directly analysing organization processes, so this list can be viewed as an analysis appraoch when translating the contributions into a common style.
This section describes some artifacts that might be useful when analysing use cases. Use of these is not mandatory, but can help to tease out the right level of detail.
A simple list of topics about the system and an indication of whether the topic is in or out of scope for the system's use case description. Useful at the start of the exercise, and later, to remind the team of the functional scope of the system.
For this DG, functional topics related to identity assurance processes would typically be IN scope, while external processes or software details that support the assurance processes are probably out of scope (those are likely to be pre-conditions)
The Actor-Goal List captures the list of Actors that interact with the system, and their goals with respect to that system. The system operates a 'contract' between stakeholders; the use cases describe the functional behaviour of that contract. Stakeholders that are not present in the interaction have vested interests that should be satisfied (these might be understood as 'system guarantees'). Actors are a subset of Stakeholders.
|Stakeholder or Actor||Is Actor?||Goal or Interest|
|ID Proofing Manager||Y||Goal 1 (the actor's goal)|
|Interest 1 (the system guarantee)|
|The Individual||Y||Goal 2 (the actor's goal)|
|Regulator||N||Interest 2 (the system guarantee)|
We expect that analysis of the contributed use cases will result in a core list of stakeholders that are common to the identity assurance processes plus additional stakeholders that relate to process-specific or regulation-specific activities.
The use case brief is a 2-6 sentence description of the behaviour of the system from the point of view of each actor in turn. It might simply be a short description of the main success flow. It is a brief expansion of the actor's Goal statement.
|Actor (from A-G List)||(from A-G List)||Success flow, in summary.|
Minimal guarantees are what the system promises to the stakeholders, in particular when the primary actor's goal cannot be achieved. These are not the same as failure scenarios, but might be related to them.
The idea is that the minimal guarantees will satisfy the stakeholders that their interests have been protected when the goal does not succeed.
Success guarantees are what the system promises to the stakeholders at the conclusion of the main success scenario. It includes all of the MInimum guarantees, plus. It includes the main goals of the use case.
To figure out what the success gaurantees might be for each stakeholder, ask the question 'what would make the stakeholder unhappy at the end of a successful run?' then use the negative of the answer.
To reduce the burden and processing load on contributors, we will use a casual format.
|Use Case Name||A short name|
|Scope||The name of the system or business area or business function operated|
|Context||Text about the goal in its operational context|
|Primary Actor||The primary actor name or role|
|Stakeholders & Interests||List of all the stakeholders and their interests in the system operation. Stakeholders include actors that interact with the system and others who do not interact with the system.|
|Minimal Guarantees||An optional section listing the minimal guarantees|
|Success Guarantees||An optional section listing the success guarantees|
|Preconditions||What must be true before this use case can be triggered|
|Triggers||What causes the main scenario to start|
|Main Success Scenario|
A brief list of what the actors do which results in the goal being successfully achieved.
A second brief list of what the actors do when things don't go down the main path - includes alternative paths and major failure conditions.