Functional Requirements Document
DCO User Information Flow
Version / Description of Change / Author / Date1.0 / Document Creation / Patrick West / 20141109
1.1 / Registration Information provided by user – Glossary B / Patrick West / 20141127
1.2 / Section numbering corrections, grammar and spelling corrections from Peter Fox / Patrick West
Peter Fox / 20141201
1.3 / Added various external ID fields for user information. Added user requirement and functional requirements for visualizing user informaiton / Patrick West / 20141202
1.4 / Grammar and spelling corrections from Frank Baker. Questions answered. User administrator will use their DCO password, not a verification code. / Patrick West
Frank Baker / 20141202
Version 1.4 Sign Off
__ Patrick West: Author
__ John Erickson
__ Frank Baker: Engagement
__ Peter Fox: DCO-DS
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
1 INTRODUCTION
A user has registered for a new account. At this point there is no information in either the DCO Information Portal at https://info.deepcarbon.net or in the DCO Community Portal at https://deepcarbon.net.
During the registration the user provided information, including at this point their given name, family name, email, username (uid), password, and the user’s organization.
1.1 Purpose
The purpose of these functional requirements is to make sure that we request from the user information to be kept within the system for the user, any and all information the user entered is put into the right places, that there is an individual profile for the person if one does not already exist in the information portal, and that the user is granted any and all permission they need as a new user, and be subscribed to the DCO newsletter.
1.2 Scope
These functional requirements cover the interaction between the DCO Single Sign-On System, the DCO Community Portal at https://deepcarbon.net, and the DCO Information Portal at https://info.deepcarbon.net.
The overall time to complete the information flow depends on the user, as the last piece to put in place requires the user to log in to the DCO Community Portal.
This document will not describe what information is seen by anonymous users viewing the contents of the system, or logged-in users who have access to view and possibly edit content.
1.3 Background
The DCO Single Sign-On system is responsible for account registration and the initial storage of the user’s information. Outside the scope of this document is user login, user single sign-on requirements, user lost password, and user change password.
The DCO Community Portal is responsible for allowing community members to coordinate activities, events, planning, community communication between community members, organization of community members into various groups, and more. The only information within this system will be used to make sure members are capable of performing these activities only.
The DCO Information Portal is responsible for maintaining any and all information within the Deep Carbon Observatory, including but not limited to, any and all information deemed needed about a DCO Community Member.
1.4 References
DCO Account Registration Use Case – Patrick West, John Erickson
DCO Account Accept/Deny via Email Use Case – Patrick West, John Erickson
DCO User Admin Acts on List of Pending Requests Use Case – Patrick West, John Erickson
1.5 Assumptions and Constraints
Constraint – The DCO SSO system is not able to communicate with the DCO Community Portal (Drupal) to provide user information because the user account has not yet been created. There is a lot of processing within Drupal when a new user logs into the system for the first time that we do not feel confortable enough with overriding. For this reason we have decided to add functionality within Drupal to communicate with DCO SSO.
All systems are available within the system at the time of user registration.
All systems are available within the system at the time the user logs into the DCO Community Portal.
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 the implementation of the requirements, the information needed to be maintained, and which component maintains the information, and how to transfer the information between the systems.
2 METHODOLOGY
These functional requirements start with the user registration. It is at this point that we decide what information is to be required of the user in order to register and where and how that information is stored.
Once the registration has been accepted by the DCO User Admin the system needs to push any of this information to the DCO Information Portal.
When the user logs into the DCO Community Portal for the first time the system needs to fill in any information required within Drupal, user permissions updated, and the user subscribed to the DCO Newsletter.
3 FUNCTIONAL REQUIREMENTS
4.1 Context Diagram
The system components described here include the DCO Single Sign-On system, with which the user initially interacts with and registration information is stored; the User Admin interaction with the DCO Single Sign-On system in order to accept or deny the account registration; the DCO Information Portal, where the information is initially pushed once the registration request has been accepted by the DCO User Admin; and the DCO Community Portal once the user initially logs in.
Exhibit 2 - Generic Context Diagram
4.2 User Requirements
4.2.1 New User
The user registers for a new account by providing information about themselves. The password provided during registration is required to be secure within the system. The information provided is to be used to populate information within other components of the system in order to allow the user to show up in member pages, group pages, search and browse functionality, and so on. The information requested should provide basic information for the user.
UR1 – User information collected to used in all the components of the system
UR2 – User information collected to provide the user with login ability to various system components
UR3 – User information collected to provide the user with subscription to DCO Newsletter
4.2.2 DCO User Administrator
DCO User Administrators can use the information provided by the user in order to assist them in determining whether or not to accept the user’s account registration request. There should be enough information collected by the system to help the DCO User Administrators.
UR4 – User information accessible to make determination to accept or deny account request
4.2.3 DCO Information Portal
The information portal requires user information in order to provide relationships between the user and artifacts of the community, such as but not limited to, datasets, instruments, publications, projects and field studies.
UR5 – Determine if the user already has a profile within the system
UR6 – If user already exists within the DCO Information Portal then the information collected will tie the user to their profile.
UC7 – If user does not already exist within the DCO Information Portal then the information collected will be enough to create the individual within the system, giving them both a URI and a DCO-ID.
UC8 – User information collected will give access for the user to login to the DCO Information Portal and have self-edit capabilities.
4.2.4 DCO Community Portal
The community portal requires enough user information in order to provide the user with the proper authorization to participate in various activities within the community such as, but not limited to, participation in the various communities and groups within the DCO and access to artifacts registered in the DCO portal.
UR9 – Information collected within the system will give the user authorization to participate and contribute to the various communities and groups within the DCO Community Portal.
UR10 – Information collected within the system will allow the user to login to the DCO Community Portal.
UR11 – Information collected within the system will be displayed on a DCO Directory page
UR12 – Information collected within the system will be displayed on a user’s profile page
4.3 Data Flow
User registration is the first point of data collection. The form provided to the user will allow them to provide the information, including required information as well as other information. The information needs to be stored for later use by the system.
The information collected by the user will be accessible by the DCO User Administrators to determine whether or not to accept the user’s registration request.
Once the DCO User Administrator accepts the request the information is updated in the DCO Single Sign-On system.
Using the user’s information it will be determined if the user’s profile already exists in the DCO Information Portal. If it does already exist then the existing profile will be updated with the provided information. If it does not already exist then a new profile will be created, creating a new URI to represent the user’s information, and a DCO-ID that gives external sources as well as the components within the DCO System linkage to the user’s information.
The first time the user logs in to the DCO Community Portal the Community Portal will access the user’s information from the DCO SSO system in order to pre-populate the user’s information within the community portal, grant the basic access privileges to the user, and subscribe the user to the DCO Newsletter.
4.4 Logical Data Model/Data Dictionary
4.4.1 Information collected at time of registration from the user by DCO SSO
· Given Name
· Family name
· Username (uid)
· Password (encrypted)
· Email Address
· Additional user information. See Glossary B for all the additional information collected.
4.4.2 Information stored in the DCO SSO System when submitted by the user
· User Information from list above plus.
· Date and time the account registration was submitted
· Status of the request = “requested”
4.4.3 Information stored in the DCO SSO System when confirmed by the user
· List in 4.4.2 above plus:
· Date and time the account registration was confirmed by the user
· Status of the request = “confirmed”
4.4.4 Information stored in the DCO SSO System once request has been acted on
· List in 4.4.3 above plus:
· Date and time the account registration was accepted/denied on
· Email address of the DCO User Administrator who accepted/denied the request
· Status of the request = “accepted” or “denied”
4.4.5 Information stored in the DCO Information Portal
· User Information from 4.4.1 list above plus:
· URI identifying the user within the system
· DCO-ID providing external linkage of the user
4.4.6 Information stored in the DCO Community Portal
· Username (uid)
· Email Address
· Initial portal role of dco_portal_user
4.4.7 Information stored in the DCO Newsletter mailman service
· Given Name
· Family Name
· Email Address
4.5 Functional Requirements
4.5.1 Functional Requirements Group 1 – New User
Section/ Requirement ID / Requirement DefinitionFR1 / The DCO SSO component shall store all the user’s provided information for later use by other components of the system.
FR2 / The DCO SSO component shall store user’s provided information in the LDAP system to allow the user to login to the various components of the system.
FR3 / The DCO SSO component shall add the user to the DCO Newsletter by sending an email to the mailman service.
4.5.2 Functional Requirements Group 2 – DCO User Administrator
Section/ Requirement ID / Requirement DefinitionFR4 / The DCO SSO component shall provide the DCO User Administrator with the ability to accept/deny the user’s request.
FR4.1 / The email sent by the DCO SSO component to the DCO User Administrators shall have links to allow the administrator to accept or deny the request
FR4.2 / The DCO SSO component shall provide the DCO User Administrator with a web-based page listing all pending requests with links to accept or deny the user’s request.
4.5.3 Functional Requirements Group 3 – DCO Information Portal
Section/ Requirement ID / Requirement DefinitionFR5 / The DCO Information Portal component shall provide the DCO SSO component the service to query it’s store to determine if a user already exists.
FR6 / The DCO Information Portal component shall provide the DCO SSO component the service to push updated information about the user to the DCO Information Portal.
FR7 / The DCO Information Portal component shall provide the DCO SSO component the service to create a new user profile in the DCO Information Portal.
FR8 / The DCO Information Portal component shall utilize the DCO SSO component to give access to the user to the DCO Information Portal.
4.5.4 Functional Requirements Group 3 – DCO Community Portal
Section/ Requirement ID / Requirement DefinitionFR9 / The DCO Community Portal component shall access the DCO SSO component to retrieve the user’s information the first time the user logs in to the component.
FR10 / The DCO Community Portal component shall utilize the DCO SSO component to give access to the user to the component.
FR11 / The DCO Community Portal component shall provide a DCO Directory of all DCO Users using the information collected in the DCO Information Portal.
FR12 / The DCO Community Portal component shall provide the information collected on the user’s profile page in the DCO Information Portal.
5 OTHER REQUIREMENTS
5.1 Interface Requirements
5.1.1 DCO SSO component interface
The DCO SSO component will be implemented as an extension to the existing RESTful service (LOGIN, LOST USERNAME/PASSWORD, CHANGE PASSWORD, DCO User Admin accept service, DCO User Admin deny service) to provide DCO User Administrators with a list of all pending user registration requests. The web page provided will have the same look and feel as all the other DCO SSO web pages. On the web page the administrator will have the ability to individually accept or deny a request, or be able to select one or more requests and take bulk action on those selected.