Functional Requirements

The overall functionality must:

• Provide a secure interface for users to login to TerraWeb applications
• Provide a centralized way to manage users and their access/priority level
• Use a web-based interface
• Allow the user to:

• Supply a user name and password to be granted access to applications
• Supply personal preferences

• Allow the administrator to specify users, access levels, priority levels, and available applications
• Store all the data in its database

The following specific functions must be provided:

1. User Accounts:

• Shall provide storage of user information including but not limited to: user login name, password, priority level, access rights, group membership, and interface preferences.
• Will be administered through an administrator interface.

2. Centralized User Login:

• Will require use of user login name and password to access the software.
• Shall provide users the ability to change the password at any time.
• Shall use encryption to send data.
• May have expiration times for passwords set by administrators and will force users to change their passwords after the expiration time.

3. Interactive Web Application for Administrators:

• Will be an independent application available exclusively to administrators.
• Shall provide the ability to add or delete information that can be stored for users.
• Shall provide the ability to alter information stored for any given user.
• Shall provide the ability to add or delete users.
• Shall provide options to set the password expiration time.
• Shall provide monitoring of user activities and the option to enable outputting of activities to a log file.

• Shall use secure login.
• Shall provide access to the Maui Cam, TerraData, and Photo Archive applications.
• Shall provide user interface customization stored with their user data.
• Shall allow applications to retrieve the user’s customization.
• Shall allow users to view and manage their system accounts in one place.
• Shall allow users to use TerraWeb applications they have been granted access to.
• Shall allow users the option to change their password.

Functional Client-side requirements

There are three kinds of users:

• Administrators: Users who use the administration application to edit user information in the database. They enter data such as who the user is, what privileges the user has and the priority level of the user.
• Editors: Users belonging to a specific work group or multiple work groups who have access to all information belonging to their group. These users also have read access to information that is marked public by other groups.
• Guests: Users who are allowed very limited access and information to applications. These users can only search and read information that is marked as public.

Administrators

Administrators manage users and teams and what information they can access. The following table is a list of the identified requirements for the administrators.

Requirements prioritized with 1 = Crucial, 2 = Very high, 3 = High, 4 = Average, 5 = Low, 6 = Very low. Difficulty is rated from 1 to 10 where 10 = very difficult and 1 = very easy.

Table 4.1: Administrator Requirements

Editors

Editors are the main users of the interface and applications. These users do the actual work. The following table is a list of the identified requirements for the editor.

Requirements prioritized with 1 = Crucial, 2 = Very high, 3 = High, 4 = Average, 5 = Low, 6 = Very low. Difficulty is rated from 1 to 10 where 10 = very difficult and 1 = very easy.

Table 4.2: Editor Requirements

Guest

Guests are just able to view certain information and have limited access to applications. The following table is a list of the identified requirements for the Guest.

Requirements prioritized with 1 = Crucial, 2 = Very high, 3 = High, 4 = Average, 5 = Low, 6 = Very low. Difficulty is rated from 1 to 10 where 10 = very difficult and 1 = very easy.

Table 4.3: Guest Requirements

External Interface Requirements

Performance Requirements

1. System development must use the technical tools/languages as specified by USGS sponsor. See Design and Implementation Constraints below for the technical constraints.
2. System must be user-friendly for non-technical users.

• The system will use a simple web-based interface.
• It shall be accessible by all standard methods of Internet access.
• It should require little or no training to use.

3. System must be maintainable.

• The code will be well commented.
• Documentation will be created about the software design and implementation.
• System should be accessible from any machine.
• The system will reside on a network visible to the Internet.

4. System must be highly secured.

• The system will enforce user login, which will determine level of accessibility.
• It shall use encryption to send information across networks.

5. System must be scalable.

• The system will use a modular design.
• The system will use a simple and well-documented interface between modules and external software.

Non-Functional Requirements

These are constraints on the services that do not impact the functionality of the product. The system must follow design guidelines presented in the capstone design course. The system must be designed using technical constraints listed in table 4.4 below.

• Documents in electronic forms: PDF, HTML, or MS Word.
• Code should be delivered well commented in electronic form.

• Users should require little to no training to use interface.
• Administrators should require at most an hour worth of training to use application.
• Application developers that want to use interface should require less than an hour of training to interface (Reading documentation should be enough).

• User logins should take no longer than 30 seconds.
• Access to applications should be seamless.
• Errors should give a friendly error message and direct the user toward help.
• Basic help should be available.
• Users can only be logged in once.
• Messages will be displayed when server is unavailable for logins.

Design and Implementation Constraints

Below are the constraints that have been proposed by the client as well as those which reflect project domain specifications.

General security constraint

Technical constraints

• The system will be designed to be scalable to meet future needs of the client.
• The implementation must utilize specific technologies provided on the server.

Table 4.4: Technical Requirements

Business Rules

1. System must comply with the Rehabilitation Act of 1973, Amendments of 1998, Section 508
2. System must adhere to accessibility and government guidelines (System must not use cookies, etc)
3. System must not require specific browser to be run.
4. System development/integration/testing must be completed by April 26, 2002, for the Capstone Project Conference.

User Documentation

1. All the documentation must be in PDF, HTML, or Microsoft Word.
2. All deliverable documentation should be submitted electronically.
3. Documentation and reports should be formatted so they will make usable two-sided hardcopies.
4. Documentation should be readable on a computer screen.
5. Documentation on setup/implementation of system, database, and security must be provided.
6. Code must be well commented.
7. Manuals for programmers, system/database/web administrators must be provided.
8. Online, context-sensitive help must be provided.