System Requirements Specification

CLASP Password Manager
System Requirements Specification
COP4331 - Processes for Object Oriented Software Development - Fall 2014

Modification History:

Version	Date	Who	Comment
v0.0	09/02/2014	Cindy Harn	Created Template / Empty Document
v1.0	09/18/2014	Cindy Harn	Checked and uploaded all of the sections
v2.0	10/21/2014	Cindy Harn	Upgraded the design / layout of the page.

Team Name: Group 8

Team Website: http://www.cs.ucf.edu/courses/cop4331/fall2014/cop4331-8/

Team Members:

Contents of this Document

Introduction

Software to be Produced
Reference Documents
Applicable Standards
Definitions, Acronyms, and Abbreviations

Product Overview

Assumptions
Stakeholders
Event Table
Use Case Diagram
Use Case Descriptions

Specific Requirements

Functional Requirements
Interface Requirements
Physical Environment Requirements
Users and Human Factors Requirements
Documentation Requirements
Data Requirements
Resource Requirements
Security Requirements
Quality Assurance Requirements

Supporting Material

SECTION 1: Introduction

Software to be Produced:

Software will be a desktop application with an easy-to-use User Interface. The application will display several options for the user to create an account, or edit their current one if it exists. This includes adding, editing, and deleting usernames and passwords. The application then encrypts the user's database and stores it on a web-based server.

Reference Documents:

Applicable Standards:

The group will be using a web server to implement the Secure Password Manager that will be coded to a database using MySQL.
The encryption will be done using the Java Cryptography Architecture within the desktop application.
The desktop application will be written to be run in the Java 7 Run Time Environment.
The desktop application will communicate with the web server using public key cryptography.
No unencrypted data will be sent to or stored on the web server.
Passwords will only be shown if the user places the password into an environment outside the desktop application or chooses to display the password in the application by changing the default settings.

Definitions, Acronyms, and Abbreviations:

IDE - Integrated Development Environment - a program that allows for other programs to be created, compiled and executed.
JDK - Java Developer Kit - a set of tools and libraries for developing programs in the Java language.
MB - Megabyte - a unit of data storage, representing 1,000,000 bytes.
GB - Gigabyte - a unit of data storage, representing 1,000,000,000 bytes.
RAM - Random Access Memory - temporary memory used by the processor.
GHz - Gigahertz - a unit of frequency, representing 1,000,000,000 hertz.
VPS - Virtual Private Server - a private server created virtually.

SECTION 2: Project Overview

Assumptions:

The group is assuming that if the desktop app works on a Windows and Linux computer, then it will work on Mac OS.
If the desktop app works on the organizations computers then it will work on all computers.
The server will be able to communicate with any device.
The desktop app will be readily available for any willing user to download.
The client is willing to accept the organizations creativity.
Every team member will do an equal amount of work.
Every team member will show up to group meetings.

Stakeholders:

Each member in the group represents a stakeholder as these individuals will carry the responsibility of designing and implementing the software desired by the client.
The client is a stakeholder as the TA and the professor are the customers to inform the group of any requirements and adjustments to be done.
The potential users to the system will be stakeholders, as they will be utilizing the password manager system and be entrusting their information to the software.

Event Table:

Event Name	External Stimuli	External Responses	Internal Data and State
Can't reach server	User attempts to log in without connection / server is down	Report error through client software	Software cannot establish connection to the server, login does not succeed
Log In	User enters correct username and password and presses button to log in	User is successfully logged in, can access their accounts	User is logged in to the server successfully
Log In (Failed)	User attempts to log in with either invalid username or password	User is not logged in, error message is shown	User remains not logged in to the server
Log Out	User is currently logged in and presses button to log out	User is successfully logged out	User is no longer logged in to the server
Register	Account information is filled out correctly and submitted by user	User account is generated	Server creates new entry for the user, including account information
Password Recovery	User clicks on the password recovery button	User is allowed to recover or their main password after filling out information	Server verifies information and allows user to recover password
View User Database	User logs in successfully and clicks on the accounts button	User is shown a list of their accounts	Server verifies credentials and login state, and sends accounts list if valid
Add Account	User is in the user database screen and clicks the add account button	User is allowed to choose a name for their new account if still logged in	Server verifies credentials and login state and accepts / adds new account if valid
Login Timeout	User's login session times out and user attempts to access their information	User is presented with a login dialog box	Server verifies credentials and allows the user to continue if valid
Remove Account	User select account and clicks remove account button	User is presented with a dialog box asking them if they are sure, clicking yes completes the operation	Server verifies credentials and deletes the account if valid
Edit Account	User selects account and clicks edit account button	User is allowed to view and edit the details of the account	Server verifies credentials, and sends account details if valid
Save Account	User clicks save account button in edit account screen	User account is saved	Server verifies credentials and updates account information if valid

Use Case Diagram:

Use Case Descriptions:

The user from the main menu will be able to do three actions: register for a new master account, recover their master password if they have forgotten it, or log on to the password manager. From there the user will be able to add, edit or remove any of the usernames and passwords associated to the various accounts the user has stored in the database.

SECTION 3: Specific Requirements

3.1 Functional Requirements:

Functional requirements will include validity checks on users accounts upon login, followed by communication with a web server if the login was successful. There will be a error handling exception at this point if the application does not have an active network connection, allowing the user to retry connection when applicable. The server then returns the user's password database, and decrypts it on the application. The user will now be free to access any username and password they have saved in the past. Depending on which user is logged in (the parameter), the program will return the necessary database. After the user is finished, they will log out and the database will be re-encrypted and sent back to the webserver, ready to be accessed and decrypted again at any time.

3.2 Interface Requirements:

Upon opening the application, the user will input their master username and password to access their database. The output will be the decrypted database of information sent back from the server in response to the login. The database will be consisted of strings for all the usernames and passwords stored by the user. Depending on different types of encryption, when stored in the web server database, the information will be turned into some form of hash code, but will still be a string. Since all the of the passwords should be case and character sensitive, it is crucial to ensure accuracy when transferring data so that the user will not lose account accessibility on saved information. The data will be transferred every time a user logs on or off of the application. The data shouldn't need to be accessed too frequently, leading to only a few recalls in a time period.

3.3 Physical Environment Requirements:

In order to host a web server for the user databases, a dedicated machine is necessary. In particular, our server will be a Xen VPS on a quad-core Xeon 3.0 GHz with 2GB RAM. This machine will be kept off site in a secure location, safe from physical intrusions. There are also precautions for temperature, humidity, fire safety, etc.

3.4 Users and Human Factors Requirements:

The system will be able to support regular users and administrators. The role of the administrators is to maintain the server and application. The user will only need a minimal skill set in order to operate the application since there will be a simple interface for them. Each user will have their own database that will be saved on the server. The interface will be universal for all users, since the options will be limited. If someone tries to log into another user's account without their permission, then the account will be locked for a set amount of time.

3.5 Documentation Requirements:

For the users, there will not be much necessary documentation aside from their personal database. Once they access the database from the web server, it will be sent back to them and printed on the screen (using special characters for the password so it can't be copied over the shoulder. The administrators will have these databases, along with some common logs and debug files.

3.6 Data Requirements:

The main calculations that will need to take place will be for the encryption and decryption of the databases. Depending on the technique used, different hash formulas may be used, requiring precise solutions. If some of the formulas are off, then they may not result in correctly encrypted and decrypted account information, leading to irreversible data loss. Keeping these formulas precise and consistent will ensure that all data is safe and reliably accessible to the user.

3.7 Resource Requirements:

Team of administrators to maintain the server and application
Space online for a server in order to store the encrypted user information
Working bi-weekly, span should last about three months
Funds for server fees and any other necessary tools
Eclipse IDE, JDK, web server

3.8 Security Requirements:

Access to the system must be controlled since there is account sensitive information
Even though all the information is encrypted on the server, it will still be kept separate for each user for simplicity
The User Interface will not store any information. It is used as a connection to the web server and as an encryption and decryption tool. The interface will be a separate entity from the OS and other programs
Everytime the user accesses their password information on the server, the information will be decrypted and then re encrypted when the user is finished
All of the information on the server will be backed up on a daily basis on a local and remote server backup
Server location will be protected against fire and has ample physical security to avoid theft

3.9 Quality Assurance Requirements:

Since this system will be hosting multiple users various account sensitive information, reliability is of utmost importance. If encryption techniques are even slightly off, then information can be permanently lost. These encrypted databases must also be available to the user at any time. The system should be simple to maintain with only an application and a web server to look after. With this use of this web server, users will be able to access their data from any platform at any location, so long as they have stable network connectivity. If there is no network connection, then the application will experience a fault and allow the user to retry when connection is successful. There will be another fault catch if the wrong user information is entered too many times, locking the application for a set amount of time. The system will be available for access by the users at all times since the machine running the webserver at a secure location will always be running. Each database will only be composed of text, which is relatively light in resources, leading to quick access and response times. This will mainly depend on the users connection strength. Storage for text is also quite small, so there will be ample room for a large number of users to store their data.

SECTION 4: Supporting Material:

All of the requirements are adequately described in the previous section, and can be supported by the diagrams below that can be found in the Project Management Plan page.
Software Life Cycle Process:
PERT Chart:

This page last modified on October 21, 2014.

Please do not reproduce this page.