Functional Requirements Document
User Management Dashboard
Version Description of Change Author Date
1.0 Initial Document Patrick West 20141127
Sign Off
__ Patrick West: Author
__ John Erickson
__ Frank Baker: Engagement
__ Peter Fox: DCO-DS
DCO User Manager Dashboard Flow Functional Requirements 2
CONTENTS
1 INTRODUCTION 4
1.1 Purpose 4
1.2 Scope 4
1.3 Background 4
1.4 References 4
1.5 Assumptions and Constraints 4
1.6 Document Overview 5
2 METHODOLOGY 5
3 FUNCTIONAL REQUIREMENTS 5
4.1 Context 5
4.2 User Requirements 5
4.3 Data Flow Diagrams 6
4.4 Logical Data Model/Data Dictionary 6
4.5 Functional Requirements 6
5 OTHER REQUIREMENTS 6
5.1 Interface Requirements 6
5.2 Data Conversion Requirements 7
5.3 Hardware/Software Requirements 7
5.4 Operational Requirements 7
APPENDIX A - GLOSSARY 11
DCO User Manager Dashboard Flow Functional Requirements 3
1 INTRODUCTION
As with many systems where users are allowed to register for accounts there will be the
need for administrators to see the current list of pending requests, or see the list of users
who have requested accounts but have not yet confirmed their registration, or to see when
action was taken on accepted or denied registrations.
1.1 Purpose
The purpose of these functional requirements is to ensure that DCO User Administrators
have the ability to handle user account registrations, to act on pending registrations and to
see the status of a user’s registration. The system implemented should allow user
administrators to accept or deny currently pending requests, to accept currently denied
requests, to see when and who acted on a user’s request, and to check the status of a
user’s request.
1.2 Scope
These functional requirements cover the interaction between a DCO User Administrator
and the DCO Single Sign-On (SSO) System to view and act on user’s account
registrations.
It does not cover the interaction of the user with the SSO system or the flow of the
information provided by the user in the DCO system once an account has been requested,
confirmed, or acted on.
1.3 Background
The DCO Single Sign-On system is responsible for account registration and the initial
storage of the user’s information. DCO User Administrators are responsible for acting on
any requests that have been confirmed by the user. Administrators already receive emails
after a user confirms their account registration. In addition to being able to act on
registrations via this email, Administrators also need to be able to see a list of pending
requests that have not yet been acted on, act on those pending request, and to perform
other actions based on requested, confirmed, accepted or denied registrations.
1.4 References
User Information Flow Functional Requirements – Patrick West
Single Account Registration Accepted from Dashboard – Use Case – Patrick West
Multiple Account Registrations Accepted from Dashboard – Use Case – Patrick West
User Registration Accepted from list of denied requests – Use Case – Patrick West
User Administrator view registrations with different status – Use Case – Patrick West
Other DCO Use Cases – Patrick West
DCO User Manager Dashboard Flow Functional Requirements 4
1.5 Assumptions and Constraints
1.5.1 Assumptions
If an account has already been denied and is not being accepted the system needs to re-
verify the request to make sure the user did not re-register.
1.5.2 Constraints
One of the examples listed above is the ability for an administrator to be able to accept an
already denied request. We feel this is a simple case as the user’s information is still
available and there’s nothing in the system that would need to be updated outside of the
Single Sign-On system.
Denying an already accepted request is far more complicated and will not be allowed by
this interface.
1.6 Document Overview
The first part of this document provides background for these functional requirements.
The remainder of the document will provide information about what will be provided to
the DCO User Administrator and how the administrator interacts with the system.
2 METHODOLOGY
These functional requirements start with when a DCO User Administrator visits the DCO
User Administrator’s Dashboard. This dashboard will provide the administrator with
organization of information and the ability to act on the information.
3 FUNCTIONAL REQUIREMENTS
4.1 Context
System components described here include the DCO User Administrator’s Dashboard,
from which administrators view and act on requests, and interactions with the DCO SSO.
Exhibit 2 - Generic Context Diagram
DCO User Manager Dashboard Flow Functional Requirements 5
4.2 User Requirements
4.2.1 View registrations of various status
User administrator’s need to be able to view account registrations based on their status in
the system. The status are requested, confirmed/pending, accepted, denied. The latter two
can be grouped together to represent any registrations that have been acted on.
UR1 – User Administrator view all confirmed/pending registrations
UR2 – User Administrator view all requested but not confirmed registrations
UR3 – User Administrator view all accepted registrations
UR4 – User Administrator view all declined registrations
UR5 – User Administrator view all acted on registrations
UR6 – User Administrator view all provided information from user
4.2.2 Accept/Deny pending requests
Registrations can be accepted or denied either by the original email (not covered in these
functional requirements) or from the confirmed/pending requests.
UR7 – User Administrator accept/deny a single registration from confirmed/pending list
via links
UR8 – User Administrator accept/deny multiple registrations from confirmed/pending list
in bulk
4.2.3 Accept previously denied requests
Occasionally a User Administrator might deny an account registration but later determine
that the registration should be accepted. A User Administrator should be able to accept
registrations from the list of denied registrations.
UR9 – User Administrator accept a single denied registration from denied list via link
UR10 – User Administrator accept multiple denied registrations from denied list via link
UR11 – User Administrator accept a single denied registration from acted on list via link
UR12 – User Administrator accept multiple denied registrations from acted on list in bulk
4.3 Data Flow Diagrams
All Interactions are between the User Administrator’s Dashboard and the DCO LDAP
Restful Service. This service, already used for user’s to be able to login, register, recover
their password, and change password, will also include the methods for managers to
retrieve information about the registrations and act on them via the Dashboard.
DCO User Manager Dashboard Flow Functional Requirements 6
4.4 Logical Data Model/Data Dictionary
The data model has already been defined in the DCO User Information Flow Function
Requirements Document (referenced above).
4.5 Functional Requirements
4.5.1 View registrations of various status
Section/
Requirement
ID Requirement Definition
FR1 The system shall return to the Dashboard the list of confirmed/pending
account registrations. The data returned will include all of the information
currently stored in the DCO SSO Data Store as a JSON Object. Displayed on
the screen initially will be each username, Name, Organization, when the
registration was requested, and when the user confirmed the registration.
FR2 The system shall return to the Dashboard the list of requested, but not yet
confirmed, account registrations. The data returned will include all of the
information currently stored in the DCO SSO Data Store as a JSON Object.
Displayed on the screen initially will be each username, Name, Organization,
when the registration was requested.
FR3 The system shall return to the Dashboard the list of accepted account
registrations. The data returned will include all of the information currently
stored in the DCO SSO Data Store as a JSON Object. Displayed on the screen
initially will be each username, Name, Organization, when the registration
was requested, when the user confirmed the registration, when the registration
was accepted and by whom.
FR4 The system shall return to the Dashboard the list of denied account
registrations. The data returned will include all of the information currently
stored in the DCO SSO Data Store as a JSON Object. Displayed on the screen
DCO User Manager Dashboard Flow Functional Requirements 7
initially will be each username, Name, Organization, when the registration
was requested, when the registration was denied and by whom.
FR5 The system shall return to the Dashboard the list of acted on account
registrations. That is, all accepted and denied registrations. The data returned
will include all of the information currently stored in the DCO SSO Data
Store as a JSON Object. Displayed on the screen initially will be each
username, Name, Organization, when the registration was requested, when
the user confirmed the registration, when the registration was acted on, the
action taken and by whom.
FR6 All the additional information will be available via a down arrow to the left of
the username. This information will be displayed in-place (expanded below
the user’s basic information). When expanded the down arrow is switched to
an up arrow. When the up arrow is clicked on the information is hidden.
4.5.2 Accept/Deny pending requests
Section/
Requirement
ID Requirement Definition
FR7 The system shall allow the administrator, from the pending list of
registrations, to click on an accept or deny link that is to the right of the user’s
basic information. This will accept/deny only that one registration.
FR8 The system shall allow the administrator, from the pending list of
registrations, to check a box on multiple registrations along with a drop-down
selection to accept or deny all the selected registrations.
4.5.3 Accept previously denied requests
Section/
Requirement
ID Requirement Definition
FR9 The system shall allow the administrator, from the list of denied registrations,
to click on an accept link that is to the right of the user’s basic information.
This will accept only that one registration.
FR10 The system shall allow the administrator, from the list of denied registrations,
to check a box on one or more registrations alon with a drop-down selection
to accept all the selected registrations.
FR11 The system shall allow the administrator, from the list of acted on
registrations, to click on an accept link that is to the right of any user’s basic
information who’s registration has been previously denied. This will accept
only that one registration.
FR10 The system shall allow the administrator, from the list of acted on
registrations, to check a box on one or more registrations that have been
previously denied, along with a drop-down selection to accept all the selected
registrations.
DCO User Manager Dashboard Flow Functional Requirements 8
5 OTHER REQUIREMENTS
5.1 Interface Requirements
[Describe the user interfaces that are to be implemented by the system.]
5.1.1 Hardware Interfaces
None defined.
5.1.2 Software Interfaces
The currently implemented DCO LDAP Restful service will be extended to facilitate the
functional requirements listed above. Currently existing interfaces to accept or deny a
registration will be extended to allow for multiple registrations to be accepted or denied.
5.1.3 Communications Interfaces
As the User Administrator’s Dashboard is a web-based interface the user’s system will be
interacting with the web server installed on the system’s host. From the web server
interactions will be proxied to the servlet application in order to handle the requests.
5.2 Data Conversion Requirements
Information stored in the DCO SSO Data Store will be converted into a JSON object and
returned to the front-end web application. Within the front-end web application the JSON
object returned will be translated into XHTML to be displayed on the page.
5.3 Hardware/Software Requirements
The DCO LDAP Restful service will be easily deployed as a servlet application.
5.4 Operational Requirements
[Provide the operational requirements in this section.
Do not state how these requirements will be satisfied. For example, in the Reliability
section, answer the question, “How reliable must the system be”? Do not state what steps
will be taken to provide reliability.
Distinguish preferences from requirements. Requirements are based on business needs,
preferences are not. If, for example, the user requires a special response but does not
have a business-related reason for it, that requirement is a preference.
Other applicable requirements on system attributes may be added to the list of
subsections below.]
Operational requirements describe how the system will run and communicate with
operations personnel.
5.4.1 Security and Privacy
DCO User Manager Dashboard Flow Functional Requirements 9
As sensitive information is being transferred between the front-end and back-end only the
https protocol will be supported. And only DCO User Administrators and System
Administrators will be allowed to view or act on any of the registrations.
A. Consequences of a breach of this security requirement:
1. If any of the information is lost in the interaction between the front-end and back-
end then the user administrator shall receive an error message that the actions
have failed and a means to recover from the errors.
2. If any of the information in the DCO SSO Datastore is lost or corrupted then the
Datastore will be restored from backups. The backups should be less then 24
hours old. Since emails are also received by user administrators it will be possible
to restore any information lost since the last backup.
3. If any of the user’s information is disclosed to users who are not user
administrators or system administrators then each user shall be notified that such a
breach of security occurred and directed to the DCO Privacy Policy.
4. Loss, disclosure, or corruption of information due to malware or viruses on the
user administrator’s host system should be reported to DCO Administrators. Each
user’s information that is lost, disclosed, or corrupted the user shall be notified
that such a breach of security has occurred and directed to the DCO Privacy
Policy.
B. Type of security required:
1. Only DCO User Administrators and System administators will have access to any
of the user’s information
2. Only DCO User Administrators and System Administrators will be able to act on
any of the user account registrations.
3. The DCO SSO System shall provide a trusted certificate for https interactions.
5.4.2 Audit Trail
Any and all actions taken by the user requesting an account and by user administrators
are recorded in the DCO SSO Datastore. This includes the data and time the registration
was requested, the data and time the user confirmed the request, the date and time the
registration was acted on, and the user administrator who acted on the request.
Logging is provided to the servlet applications log file as needed by the developers. This
will NOT include user information other then their username.
Debugging information shall be available when debugging is turned on. This will NOT
include user information other then their username.
5.4.3 Reliability
A. Component reliability:
1. Damage that can result from failure of this system
a) Loss of information provided by the user
DCO User Manager Dashboard Flow Functional Requirements 10
b) Incorrect or invalid information stored in components of the system, which
gives external sources incorrect information about the user.
2. The minimum level of reliability for the system is no less 100% except during
system maintenance. Maintenance includes, but is not limited to, the hardware
being upgraded or rebooted and when system components are upgraded and
restarted. When these events happen user’s will be notified and there will be
known downtime.
B. Required reliability:
1. System components should be monitored and notifications sent if not available.
Though we are a research lab within a polytechnic institute we should be able to
respond to such failures within a few hours.
2. If there are failures within the system then we must investigate the cause of the
failure to make sure that it does not happen again.
3. If there is a failure in the system we must provide enough information to the
community to let them know that there is an issue and that we are working on it.
4. If there is a failure in the system then resources will be immediately assigned in
order to quickly and efficiently respond to the failure.
Reliability is the probability that the system processes work correctly and completely
without being aborted.
5.4.4 Recoverability
A. In the event the DCO SSO component fails the mysql database will be backed up at
regular intervals. Currently that is every 24 hours. No redundancy is currently
available.
B. In the event the DCO SSO component fails the LDAP information will be backed up
at regular intervals. No redundancy is currently available.
C. If the processing site (hardware, data, and onsite backup) is destroyed, the system
must be made available again within 24 hours.
Recoverability is the ability to restore function and data in the event of a failure.
5.4.5 System Availability
All components of the system must be available to users 24 hours a day 7 days a week
except during regular maintenance. We perform system upgrades and potential reboots
once a month, 3rd Tuesday of the month, starting at midnight eastern/10pm mountain.
From time to time we may need to bring down a component of the system in order to
upgrade it. These upgrades should take no longer then 1 hours. We should also have a
back-out plan in case the upgrade fails. This should limit DCO system downtime.
System availability is the time when the application must be available for use. Required
system availability is used in determining when maintenance may be performed.
5.4.6 General Performance
DCO User Manager Dashboard Flow Functional Requirements 11
A. Response time for queries and updates: The system should respond in a reasonable
amount of time, especially when dealing with a user registering for an account. The
user should be notified immediately of any changes in their account request. Though
we should expect good response times for DCO User Administrators and DCO
System Administrators, it is not as important as response times to the user.
B. Throughput: There is not a great amount of information flowing between the
components for user information flow.
C. Expected rate of user activity: We typically see anywhere from 2-6 new user
registration requests per week.
5.4.7 Data Retention
User information provided for user registration requests should be retained indefinitely.
The exception here is for requests that have not been confirmed for over a certain amount
of time.
5.4.8 Error Handling
Any errors that occur within the system must be logged to the corresponding components
logging system, and DCO System Administrators must be notified in order to keep
information loss to a minimum. DCO System Administrators will then be able to
determine if any information is lost, and be able to retrieve the information from the
original user information provided.
Any errors that occur in the interaction between a user administrator and the DCO SSO
system will be reported to the user administrator via popup alerts or information on the
page. This information will include the means to contact system administrators in order to
resolve any issues.
5.4.9 Validation Rules
Before a DCO User Administrator can view or act on any user account registrations they
must verify their identity by logging into the system using their DCO username and
password.
5.4.10 Conventions/Standards
JSON formats will be used when transferring user information from the DCO LDAP
Restful Service to the DCO User Administrators Dashboard. All the information will be
in UTF-8 format.
Information passed from the DCO User Administrators Dashboard to the DCO LDAP
Restful Service will be the user’s from the DCO SSO Datastore.
DCO User Manager Dashboard Flow Functional Requirements 12
APPENDIX A - GLOSSARY
DCO – Deep Carbon Observatory
SSO – Single Sign-On, implemented using Shibboleth.
LDAP – Lightweight Directory Access Protocol
RPI – Rensselaer Polytechnic Institute, institute from where the DCO Data Science Team
operates
TWC – Tetherless World Constellation, DCO Data Science Team members are a part of
this group at RPI.
DCO Engagement – A team of DCO Community Members who interact with the
different DCO Communities and Groups.
DCO Data Science Team – A team of DCO Community Members who are responsible
for providing the DCO Community with Data Management and Data Science services.
DCO User Administrators – A team comprised of DCO Engagement and DCO Data
Science Team members.
DCO System Administrators – A team comprised of DCO Data Science Team members.
DCO User Manager Dashboard Flow Functional Requirements 13
