Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

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.

Implementation use cases

  • The use cases documented here should be for product implementations where a data receipt of some kind is utilized. 
  • The Kantara Receipt Specification describes a data structure and output format.
  • The implementation use cases describe, from the perspective of the Actors, how the Actors succeed or fail to accomplish their objectives with respect to the "System".

The overall objective of this use case collection exercise is to substantiate proposals for enhancement of the Kantara Consent Receipt Specification v1.1. New uses with requirements beyond those supporting v1.1 are anticipated. The WG will decide if or how to accommodate these new requirements. Drastic changes to Version 1.1 are not expected - the core use cases around regulatory compliance remain intact.

Use Case Writing Guidance

A use case is a description of the possible sequences of interactions between the system under discussion and its external actors, related to a particular goal.

  • The use cases should be written as if the purpose (main goal) of the 'system'

...

  • is creation, issuance, management and consumption of receipts. This is an odd viewpoint but it should help to clarify what data fields, semantics and non-functional needs exist for the receipts themselves.
  • For each use case, there is likely to be more than one Primary Actor. The text of the Main Success Scenarios are written in a way to explain how the goals of the Primary Actor are satisfied. If there is more than one Primary Actor, write parallel use cases with the focus on the additional primary actors. Be careful when deciding if there is more than one Primary Actor - the use case analysis will be more complex with multi-primary situations.
  • Flow diagrams are helpful to explain the use case text - but the text should be the main way of describing and understanding the use case, not the picture.

The remainder of the content on this page is a longer description about use case writing and suggestions for content and process.


Page Contents

Table of Contents
maxLevel2

...

Stakeholder or ActorIs Actor?Goal or Interest
ID Proofing ManagerYGoal 1 (the actor's goal)


Interest 1 (the system guarantee)
The IndividualYGoal 2 (the actor's goal)
RegulatorNInterest 2 (the system guarantee)

...