Table of Contents

Usage Scenarios Summary

<Use-case 1: Name>

<Use-case 2: Name>

Appendix: Guidelines for Constructing Use Cases

General Approach

Questions to Drive Brainstorming

Developing Scenarios

Step 1: Begin With Primary Scenarios

Step 2: Define Secondary Scenarios

Step 3: Documenting Scenarios

Step 4: Define interfaces between solution and actors

Step 5: Document dynamic behavior of use case

Sample Usage Scenario

Smart Card Enrollment Control Usage Scenario

[Introduction to the Template

Description: The Usage Scenarios document describes the set of activities that the solution will address and support. These activities are described in terms of what the user wants the solution to do and what other interfacing applications and systems need the solution to do. This information is expressed in terms of actions (functions), actors (users in a specific situation), paths (moving from one state to another within a function), conditions (what must occur to move down the path), and results (output). The Appendix contains guidelines on how to develop this information. 

Justification: Use cases are an important expression of why the solution is needed and what it must do. This information is the description of how the solution must behave in the business environment to meet both business and the user’s functional needs.

Team Role Primary: Program is responsible for ensuring that the Usage Scenarios document is completed. Development has the primary responsibility for creating the document’s content. User Experience is responsible for ensuring that the document is developed by acknowledging all the relevant user roles and gathering the user perspectives and needs for each of those roles.

Team Role Secondary: Product Management will review and understand the Usage Scenarios in order to convey those to parties external to the team and to ensure that those scenarios are represented according to initial project sponsor requirements. Test will review the Usage Scenarios to ensure test plans are in place to validate them. Release Management will review the document to ensure operational, deployment, migration, interoperability and support needs are addressed.}]

Usage Scenarios Summary

[Description: The Usage Scenarios Summary section lists the use cases this document contains. It also provides a summary of those cases by describing them as a set of activities specific to a business scenario. These use cases will be very specific to your project. 

Justification: This information will provide the reader with an understanding of the solution’s business context and the scope of this document’s content. Some readers may not need to review the details of every use case but will need to know that all relevant activities have been accounted for in this document.]

<<Begin text here>>

<Use-case 1: Name>

[Description: The Use-case 1 section provides a detailed description of the subject use case. This information may be expressed in a table (see below0, as narrative, or as step-by-step prose.

Description	<Brief description of use case>
Scenario identifier	<Use identifier, e.g. B1 for “Basic scenario 1,” or A1 for “Administrative scenario 1.” This is used for traceability tracking. >
Author	<Who contributed to the text>
Date
Revised
Actors	<List actors>
Pre-conditions	<List the conditions that must exist before this scenario can be started>
Actions	<List actions or services in this use case>
Post-conditions	<List any conditions that must be met before the scenario can be completed>
Includes	<Reference any other use cases that this scenario uses>
Extends	<List any use case this scenario extends or builds upon>
Generalizes	<List any use case that this scenario is a generalization of>

<<Begin text here>>

<Use-case 2: Name>

[Description: The Use-case 2 section provides a detailed description of the subject use case. This information may be expressed in a table (see below), as narrative, or as step-by-step prose.

Description	<Brief description of use case>
Scenario identifier	<Use identifier, e.g. B1 for “Basic scenario 1,” or A1 for “Administrative scenario 1.” This is used for traceability tracking. >
Author	<Who contributed to the text>
Date
Revised
Actors	<List actors>
Pre-conditions	<List the conditions that must exist before this scenario can be started>
Actions	<List actions or services in this use case>
Post-conditions	<List any conditions that must be met before the scenario can be completed>
Includes	<Reference any other use cases that this scenario uses>
Extends	<List any use case this scenario extends or builds upon>
Generalizes	<List any use case that this scenario is a generalization of>

<<Begin text here>>

Appendix: Guidelines for Constructing Use Cases

General Approach

·        The purpose is communication – use language appropriate to reader.

·        Develop iteratively by walkthroughs to add detail and identify alternative paths.

·        If there are alternative paths, initially pick the most likely paths.

·        Each path through a use case is called a scenario.

·        Brainstorm all of the functions of the solution.

Questions to Drive Brainstorming

·        What functions will the actor want from the solution – what does the user want the solution to do?

·        Does the solution store information?

·        What actors will create, read, update, or delete information?

·        Model other external systems (e.g., ERP, OS, etc) as an actor.

·        Does the solution need to notify an external actor about internal changes?

·        Are there external events the solution must know about?

Developing Scenarios

Step 1: Begin With Primary Scenarios

·        Identify action

·        Identify actors

·        Establish flow of events for “normal” situation

·        Resist temptation to get too detailed

·        Define preconditions – assumed starting point

·        Define post conditions – the state at which all paths end

·        Explicitly note if a sequence can be changed without changing results

·        Represent branching flows using If, Else statements

·        Represent repeated events using For each…Next, or While…. end pseudocode

·        May describe exceptions and alternative paths

Step 2: Define Secondary Scenarios

·        Start with primary scenario

·        Look for alternative paths and error conditions

·        Go through each line or step and ask:

1.      Is there some other action that could be taken (alternative scenario)?

2.      Could something go wrong (error scenario)?

3.      Is there some behavior that could happen at any time?

Step 3: Documenting Scenarios

·        Use Universal Modeling Language notation (stick figure and ovals)

·        Simplify diagram using:

1.      “Uses” notation

2.      “Extends” notation

3.      “Generalizes” notation

4.      Actor inheritance

Step 4: Define interfaces between solution and actors

Step 5: Document dynamic behavior of use case

·        Activity diagrams (flow charts)

·        State-diagrams

·        Event-message

Sample Usage Scenario

Smart Card Enrollment Control Usage Scenario

The following scenario illustrates the use of the Smart Card Enrollment control by an administrator issuing smart cards for an organization. All methods and properties referenced are provided by the Smart Card Enrollment control.

1.      The administrator obtains an enrollment agent certificate (also known as a signing certificate). The private key associated with this enrollment agent certificate is used to sign a PKCS #7 request; the PKCS #7 request, in turn, contains the user's PKCS #10 request (which is signed with the user's private key).

The administrator can use the Certificate Manager MMC snap-in to obtain an enrollment agent certificate. Note that although the administrator's enrollment agent certificate will be used to sign the certificate request, the certification authority (CA) will issue and sign the certificate that is stored on the smart card once enrollment has completed.

2.      The administrator uses a machine that is running the Smart Card Enrollment Control; the machine must contain one or more smart card readers. (If the administrator's enrollment agent certificate is stored on a smart card, the machine must contain two smart card readers: one for reading the administrator's enrollment agent smart card certificate, and one for generating the user's smart card certificate).

3.      The administrator sets the name of a certificate template to be used by calling the setCertTemplateName method. An example of a certificate template name is "User". (If the administrator wishes to determine the available certificate templates, the getCertTemplateCount method retrieves the number of available certificate templates, and the enumCertTemplateName method can be used to enumerate their names).

4.      The administrator sets the name of a CA to be used to issue the certificate. This occurs by calling the setCAName method. (If the administrator wishes to determine the available CAs, the getCACount method returns the number of available CAs, and the enumCAName method can be used to enumerate their names).

5.      The administrator sets the name of a Cryptographic Service Provider (CSP) to be used. This occurs by setting the CSPName property. (If the administrator wishes to determine the available CSPs, the CSPCount property contains the number of available CSPs and the enumCSPName method can be used to enumerate their names).

6.      The administrator specifies a signing certificate to be used to sign the certificate request. This signing certificate is synonymous with the enrollment agent certificate obtained in Step 1. The selectSigningCertificate method invokes a user interface, allowing the administrator to choose the signing certificate. An alternative to using a user interface to select the signing certificate is to call setSigningCertificate. (Once a signing certificate has been specified, the getSigningCertificateName method can be called to retrieve the subject name of the certificate). If the administrator's signing certificate is on a smart card, the smart card must be placed in the smart card reader.

7.      The administrator places the user's smart card in the smart card reader. (Note that if the administrator's signing certificate is on a smart card, there would be at least two smart card readers on the machine: one reader would contain the smart card representing the administrator's enrollment agent certificate, and the other would contain the smart card which is to be issued the user certificate).

8.      The administrator specifies the name of the user to be issued the certificate. This can be done in one of two ways: (a) the administrator can invoke the Select User interface by calling the selectUserName method and choosing the user name, or (b) the administrator can call the setUserName method to specify the desired user name.

9.      The administrator requests a certificate on behalf of the user by calling the ISCrdEnr::enroll method. The CA receiving the request will verify the administrator's signature on the PKCS #7 (as well as verifying that the administrator's enrollment agent certificate was acceptable for enrolling on behalf of a user). The CA will also verify the user's signature on the PKCS #10. If the request is successful, the resulting certificate is automatically placed on the smart card.

10.  [Optional] The administrator can inspect the resulting certificate by calling the getEnrolledCertificateName method.

11.  The administrator removes the user's smart card and issues it to the user.

12.  The administrator calls the resetUser method, which clears the user's name and certificate from the Smart Card Enrollment control's memory, thereby preparing the control for the next user's certificate enrollment.

13.  The administrator repeats steps 7 through 12 for the remaining users on whose behalf the administrator is enrolling for certificates. Optionally, the administrator can change the certificate template, CA, CSP or signing certificate prior to each certificate enrollment.