Use Case Name: DCO User Admin Acts on List of Pending Requests
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.
DCO User Admin Acts on List of Pending Requests
Goal
The goal briefly describes what the user intends to achieve with this use case.
DCO User Admin to act on currently pending account registration requests
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.
DCO User Admins may not always be able to act on user account registration requests when
they receive the registration request email. Perhaps the admin requests additional
information from a user. Perhaps there is an issue with sending or receiving the emails.
Perhaps admins are simply unavailable to immediately act on requests. For whatever reason,
DCO User Admins may want to see a display of all pending requests with the ability to act
on those requests.
In order to do this the DCO User Admin will need to view the user’s information in the list
and have available to them a link to accept the user’s registration request and a link to deny
the user’s registration request.
If there are a lot of pending requests the admin may want to sort the list by the user’s name
(family, given) or to sort the list by when the user confirmed the request.
The admin may wish to take bulk actions. For example, select a number of registration
requests, or select them all, and accept them, or deny them.
UseCase- -Accept/Deny Request from List
1
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 – person who registers for an account within the DCO System
User Admin – administrator whose role is to review registration requests and either accept or
deny the request
DCO System – The Deep Carbon Observatory system
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.
The DCO System is up and operational
The User has successfully registered for an account
The User has successfully 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.
DCO User Admin browses to a page displaying list of current pending accout requests
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)
2)
3)
4)
5)
DCO User Admin enters URL or clicks link to view a list of current pending account registration
requests
DCO User Admin is instructed to provide their verification code allowing them to see list
DCO User Admin sorts the list by user’s name (family, given)
DCO User Admin clicks on a link to accept or deny the user’s request
DCO User Admin is taken back to the list with information at the top confirming the action they
had just taken
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)
2)
DCO User Admin selects a group of users to take bulk action on
DCO User Admin selects from a dropdown the action they wish to take
2)
DCO User Admin clicks box or link to select all users to take bulk action on
DCO User Admin selects from a dropdown the action they wish to take
1)
DCO User, after selecting all requests, deselects a box or clicks a link to deselect all the requests.
1)
UseCase- -Accept/Deny Request from List
2
1)
In place of a confirmation at the top of the page once admin submits request the system displays
an error message with instructions on what to do
Post Conditions
Here we give any conditions that will be true of the state of the system after the use case has been completed.
Action requested is performed and the user is notified of the action
Action requested is performed and all admins are notified of the actions taken
Action requested is performed and the list is updated with the requests removed
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.
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.
UseCase- -Accept/Deny Request from List
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
name)
Remote,
e.g. – no cloud
cover
Short description of the
dataset, possibly including
rationale of the usage
characteristics
USGS,
ESA, etc.
Name of the
system which
supports discovery
and access
User
In situ
Information
Password
secure
Information requested
of user for account
registration
User
DCO SSO
DCO User
Admin
verification
code
In situ
Secure
A verification code
known only by a user
administrator for
authorization to
perform actions
DCO
User
Admin
DCO SSO
Pending
Request
List
In situ
Secure
Current list of pending
user registration
requests to take action
on
DCO
SSO
DCO SSO
In situ,
Etc.
Modeling Services
Model
(model
name)
Owner
Description
Consumes
Frequency
Source System
Organization
that offers the
model
Short
description of
the model
List of data consumed
How often
the model
runs
Name of the
system which
offers access to the
model
Event Notification Services
Event
Owner
Description
Subscription
Source System
(Event name)
Organization
that offers the
event
Short description of the event
List of
subscriptions (and
owners)
Name of the system
which offers this
event
User
request
DCO SSO
A user fills in an account
registration request form
and submits the form
DCO SSO
DCO SSO
Admin
Request
DCO SSO
DCO User Admin requests
the current list of pending
user registration requests
DCO User
Admin
DCO SSO
Admin
Single
DCO SSO
DCO User Admin clicks a
link next to a user
DCO SSO
DCO SSO
UseCase- -Accept/Deny Request from List
4
Action
registration request to
accept or deny the request
Admin
Bulk
Action
DCO SSO
Admin
DCO SSO
Verification
Request
DCO User Admin selects
one or more user
registration requests to
accept or deny those
requests
DCO SSO
DCO SSO
DCO User Admin requests a DCO SSO
list of pending registration
requests and is asked to
verify their identity with a
admin specific verification
code.
DCO SSO
Application Services
Application
Owner
Description
Source System
(Application
name)
Organization
that offers the
Application
Short description of the application portal
Name of the system
which offers access to
this resource
SSO
DCO
Single Sign-On System which handles
login, registration, username and
password services
DCO SSO
System
DCO
Various services provided by DCO such
as Community Portal, Information
Portal
DCO System
Data Store
DCO
Storage service for user information
DCO SSO
Admin
Servies
DCO
Web-based services for DCO User
Admin’s to take action on user
registration requests
DCO SSO
Other resources
Resource Owner
Description
Availability
Source System
(sensor
name)
Short description of the resource
How often the
resource is available
Name of system
which provides
resource
Organization
that owns/
manages
resource
UseCase- -Accept/Deny Request from List
5