1. Use Case Development Cathy Tilton, Daon Scott Shorter, Electrosoft Services 7 February 2013

2. Outline 2 What is a use case Purpose of use cases Levels of use cases What’s been done so far General approach Timeline Workshop plans What can be done between now and then

3. What is a use case? 3 Different for engineers than for business owners, users, or other species I like this one: a methodology used in system analysis to identify, clarify, and organize system requirements the use case is made up of a set of possible sequences of interactions between systems and users in a particular environment and related to a particular goal

4. Purpose of use cases (within the IDESG) 4 Basis for the development of other work products – provides context Method of eliciting requirements Helps define the problem(s) we are trying to solve “Determine commonalities so as to be able to design services” Guide our collective efforts – keep us aligned

5. Levels 5 Target – “scenario” level: What & Why High Level Low Level WHY HOW (diagram inspired by Writing Effective Use Cases, Alistair Cockburn) Once defined, progressively lower level use cases can be derived as needed Lower levels may have a specific focus (e.g., privacy, security, user experience,…)

6. What has been done so far 6 Use case template Draft list of potential use cases Began to identify sources of existing use cases Generated sample use cases Began collection effort

7. Use case template 7 Title & brief description Category Contributor Actors Goals Assumptions Requirements Process flow Success scenario Error conditions Citations

8. Use Case Template 8 Use Case: Name the use case here. Use an action verb name to describe the use case, not including the primary actor name, but identifying any subject actors. Verb modifiers may be used to refine the use case. Examples: authenticate to system with trusted identity, authenticate to system with pseudonymous identity, match names between systems, verify attributes with privacy protection Category: Describe what category the use case belongs to. (Categories of Use Cases slide for a list of categories and their descriptions). Contributor:Identify the person or organization that contributed the use case, including their stakeholder group. Actors: Identify actors associated with the use case. Provide the primary actor first. Actors can include people, roles, organizations, software processes or services. Actors should be listed in the Actor Template format provided in Table 2. Goals: A general description of the intended outcome of the use case from the perspective of the primary actor, including any artifacts created. This section may address risks and threats related to the use case and how they may be mitigated. Assumptions: A listing of any assumptions made about the use case including its actors, services, environment, etc. Pre-conditions – Conditions that must be met for to the use case being possible Post-conditions – Any assumed actions that take place upon completion of the use case Requirements: A listing of any requirements that must be met, these can be references to published standards and guidelines or requirements stated by the contributor. Examples : FIPS 201, ISO 27001, etc. Process Flow:A text or graphic description of the overall process flow of the use case. Success Scenario: Describe the successful execution of the use case here as a sequence of numbered steps. If multiple paths or multiple outcomes are permitted to occur, they should all be documented. Error Conditions: Describe errors that can take place, considering what can go wrong at each step of the success scenario. For each error, describe how the actors should handle the results. Citations:Provide any citations to additional information or references.

9. Use Case Template - Terms 9 TermDefinition Use Case A use case is the statement of the goal the primary actor has toward the system's declared responsibilities, and the collection of possible scenarios between the system under discussion and various actors, showing how the primary actor’s goal might be delivered or might fail. Actor An actor is something with behavior. Actors can include people, organizations, software processes or services, depending on the level of the use case. Primary Actor The primary actor is one whose goal the use case is supposed to satisfy. Secondary Actor A secondary actor is an external actor against which the system under design has a goal. There can be more than one secondary actor. Scenario A scenario is a sequence of interactions that happens under certain conditions, with the intent to achieve the primary actor’s goal, and having a particular result with respect to that goal. Typically, a scenario is phrased in generic terms, using placeholders for the identity of the primary actor and the actual values passed around. Step A step is a unit of writing in a use case. Usually one sentence, describing the behavior of only one actor. Steps may be described at various levels of detail, depending on the purpose.

10. Use Case Template - Categories 10 CategoryDescription Identity Registration Use cases in which initial identity claims are verified (through “identity proofing” processes) and applicants become users. Authentication Use cases in which claims about identities pertaining to registered users are verified. Identity Management Use cases for creating and maintaining online identities and trust frameworks. PrivacyUse cases supporting the protection of user privacy. Trust/Assurance Use cases pertaining to the establishment of trust and assurance in Identity Ecosystem participants. InteroperabilityUse cases pertaining to confirming and testing interoperability. Consumer ChoiceUse cases that support customer choice in Identity Ecosystems. E-NotarizationUse cases supporting binding high-value online transactions.

11. User Level Example –Two-Party Delegation 11 Use Case:Two-Party Delegation Category:Authentication Contributor:Scott Shorter Actors: Service Provider, Third-Party Service, User Goals: The goal is for a Service Provider to issue delegation credentials that are tailored for access to data for a Third Party Service on behalf of the User. Assumptions: Pre-conditions – User can authenticate to Service Provider, Third-Party Service does not have Delegated Credentials for User yet Post-conditions – Service Provider grants or denies access to Third-Party Service Requirements: Process Flow: 1.User accesses Third-Party Service which wants data from Service Provider 2.Third-Party Service requests Delegated Credentials for User 3.Service Provider obtains User consent for delegation 4.Service Provider grants Delegated Credentials to Third-Party Service Success Scenario: Third Party Service can access limited User data from Service Provider Error Conditions: Third-Party Service forges User consent for Delegation Citations:NIST IR 7817, Section 2.1.1

12. General Approach 12 Collection phase Filter Analyze and abstract Create deliverable set (v1)

13. Potential collaboration process (general) 13 Concept -> draft outline Contributions Wiki Initial/sample contentAdvertise Expanded content Review & Comment Jumpstart Existing Sources Moderate (format, apply criteria) ROW Steward Refined content Snapshot for Formalization (adoption) From stakeholders (including groups, workshops)

14. Where do use cases come from? 14 Existing sources e.g., NIST, OASIS Stakeholder (& stakeholder rep) contributions

15. How are they to be developed? 15 Multiple suggestions AHG with online meetings Each committee create their Top-3 Series of joint meetings Wiki (anyone in IDESG) Distributed small group sessions “Analyst group”

16. Timeline 16 Goal: Within 9 months, have an initial draft set of use cases Near term: February March April Collection Filter Draft criteria Workshop Wiki launched Wiki designPopulate Wiki NOTE: Notional – not socialized

17. (Proposed) May Workshop 17 Desired outcome: Agreed set of use cases for analysis (~10) Review filtered set of use cases Apply criteria Refinements Preconditions Agree set of criteria Committees, plenary members submit candidate use cases by 1 April

18. Needed 18 Criteria to be applied Priorities Levels Relevance Cross section How? Solicit inputs Joint meeting (or AHG) to review & define list

19. Between now and then 19 Get Wiki setup and operational Continue collection Agree criteria Detailed workshop planning Content & process We need you Committees Work with us on above Individuals Work with us on above

20. Questions? 20