Use Case Template s2

Use Case Name: Multiple Account Approval from Admin Dashboard Point of Contact Name: Patrick West

Use Case Name Give a short descriptive name for the use case to serve as a unique identifier. Consider goal-driven use case name.

Multiple Account Approval from Admin Dashboard

Goal The goal briefly describes what the user intends to achieve with this use case.

A DCO User Administrator to accept multiple account registration requests by users from the User Administrator’s Dashboard

Summary Give a summary of the use case to capture the essence of the use case (no longer than a page). It provides a quick overview and includes the goal and principal actor.

When a user submits a registration request to become part of the DCO community an email is sent to user administrators to have them accept or deny the request. But sometimes administrators can’t get to all the requests via email, for whatever reason.

In the previous system, where a user registered via Drupal, user administrators were presented with a dashboard where they could accept or deny account requests. This “dashboard” included some of the registration information to help the administrator to decide whether to accept or deny the registration request

In the new Single Sign-On system we need to provide that same functionality. A user administrator wants to go to the dashboard and see the current list of pending requests. The User Administrator is able to select multiple user requests to take bulk action. A dropdown is provided with the bulk actions allowed. The administrator selects to accept the selected requests and receives confirmation of each of those actions.

Actors List actors, people or things outside the system that either acts on the system (primary actors) or is acted on by the system (secondary actors). Primary actors are ones that invoke the use case and benefit from the result. Identify sensors, models, portals and relevant data resources. Identify the primary actor and briefly describe role.

 User Administrator – primary actor - a DCO administrator who’s responsibility it to manage account requests  User – someone who registers for a new account in the DCO  DCO Single Sign-On System – restful service that handles registration requests

Preconditions Here we state any assumptions about the state of the system that must be met for the trigger (below) to initiate the use case. Any assumptions about other systems can also be stated here, for example, weather conditions. List all preconditions.

 DCO Single Sign-On system is operational UseCase- -Template http://en.wikipedia.org/wiki/Use_cases#Use_case_templates 1  DCO User Administrator has access to the DCO Single Sign-On system  DCO User has successfully registered for and confirmed their account request

Triggers Here we describe in detail the event or events that brings about the execution of this use case. Triggers can be external, temporal, or internal. They can be single events or when a set of conditions are met, List all triggers and relationships.

Set of DCO User registration requests ready for approval

Basic Flow Often referred to as the primary scenario or course of events. In the basic flow we describe the flow that would be followed if the use case where to follow its main plot from start to end. Error states or alternate states that might be highlighted are not included here. This gives any browser of the document a quick view of how the system will work. Here the flow can be documented as a list, a conversation or as a story.(as much as required)

1) User Administrator goes to the User Management Dashboard 2) User Administrator sees the current list of pending requests 3) User Administrator clicks to see more information about a particular user 4) User Administrator selects multiple user requests they want to accept 5) User Administrator receives confirmation that each request has been accepted 6) User Administrator is taken to the new list of pending requests

Alternate Flow Here we give any alternate flows that might occur. May include flows that involve error conditions. Or flows that fall outside of the basic flow.

1) User Administrator denies the user registration requests 2) User Administrator receives alert that the list of pending requests could not be rendered 3) User Administrator receives alert that an accept of a request has failed

Post Conditions Here we give any conditions that will be true of the state of the system after the use case has been completed. Each user receives confirmation that their registration was accepted Each is able to login to the DCO System

Activity Diagram Here a diagram is given to show the flow of events that surrounds the use case. It might be that text is a more useful way of describing the use case. However often a picture speaks a 1000 words.

UseCase- -Template http://en.wikipedia.org/wiki/Use_cases#Use_case_templates 2 Notes There is always some piece of information that is required that has no other place to go. This is the place for that information.

The front page of the dashboard, the first page an administrator sees, lists the current list of pending requests. Tabs along the top take the administrator to requests of varying status.

In the basic flow section note #3 where the administrator can click on something to view more information about a user. This information is already on the client-side so could just hide those sections and view when the administrator clicks on something.

UseCase- -Template http://en.wikipedia.org/wiki/Use_cases#Use_case_templates 3 Resources In order to support the capabilities described in this Use Case, a set of resources must be available and/or configured. These resources include data and services, and the systems that offer them. This section will call out examples of these resources.

Data: Data Type Characteristics Description Owner Source System (dataset Remote, e.g. – no cloud Short description of the USGS, Name of the name) cover dataset, possibly including ESA, etc. system which In situ, rationale of the usage supports discovery Etc. characteristics and access User In situ Text-based Information provided User DCO Informatio by user to assist n admins in accepting or denying user’s registration request.

Modeling Services Model Owner Description Consumes Frequency Source System (model Organization Short List of data consumed How often Name of the name) that offers the description of the model system which model the model runs offers access to the model

Event Notification Services Event Owner Description Subscription Source System (Event Organization Short description of the event List of subscriptions Name of the system name) that offers the (and owners) which offers this event event More DCO SSO Administrator wants to see all DCO SSO Client DCO SSO Info the information about a user’s registration, clicks on something to view that information, expands in place. Accept DCO SSO Administrator clicks on a link DCO SSO Client DCO SSO to accept a user’s registration request. Deny DCO SSO Administrator clicks on a link DCO SSO Client DCO SSO to deny a user’s registration request. Confir DCO SSO Administrator receives a DCO SSO Client DCO SSO m confirmation that their action was successful List DCO SSO Administrator receives error DCO SSO DCO SSO UseCase- -Template http://en.wikipedia.org/wiki/Use_cases#Use_case_templates 4 Error popup that their request to view pending requests has failed and who to contact. Action DCO SSO Administrator receives error DCO SSO DCO SSO Error popup that their action to accept or deny a registration request failed and who to contact.

Application Services Application Owner Description Source System (Application Organization Short description of the application portal Name of the system name) that offers the which offers access to Application this resource SSO DCO Single Sign-On System which handles DCO SSO login, registration, username and password services Portal DCO Various web-based services provided by DCO System DCO such as Community Portal, Information Portal Data Store DCO System which stores the registration DCO SSO information and actions taken on it

Other resources Resourc Owner Description Availability Source System e (sensor Organization Short description of the resource How often the Name of system name) that owns/ resource is available which provides manages resource resource

UseCase- -Template http://en.wikipedia.org/wiki/Use_cases#Use_case_templates 5