App-Trac

App-TracSoftware Requirements Specification Document

Date Issued: February 5, 2008Revision: 2.2Revision History:

2.2 2/19/08 - Sklutovsky – added use case diagram, use case scenarios, concept screenshot

2.1 2/19/08 - Sklutovsky – updated Specific Requirements Section, merged with Revision 2.0, edited other sections.

2.0 2/18/08 - Padilla - updated Introduction Section. Garvey – updated General Description Section.

1.5 2/14/08 - Sklutovsky – various formatting / editing updates.

1.4 2/12/08 – Garvey – filled in General Description Section.1.3 2/12/08 – Padilla – fixed Table of Contents.1.2 2/7/08 – Sklutovsky – filled in Specific Requirements

Section.1.1 2/6/08 – Padilla – filled in Introduction Section.1.0 2/5/08 – Padilla – created template for requirements.

Owner: University of Hartford – Computer Science Department

University of Hartford Page 1 of 23 5/27/2023

App-Trac

Contents 1. AUTHORS...........................................................................................................................32. INTRODUCTION............................................................................................4

2.1 PURPOSE...................................................................................................................42.2 SCOPE.......................................................................................................................42.3 DEFINITIONS, ACRONYMS AND ABBREVIATIONS.............................................................42.4 REFERENCES..............................................................................................................42.5 OVERVIEW.................................................................................................................4

3. GENERAL DESCRIPTION................................................................................53.1 PRODUCT PERSPECTIVE..............................................................................................53.2 PRODUCT FUNCTIONS.................................................................................................53.3 USER CHARACTERISTICS.............................................................................................53.4 GENERAL CONSTRAINTS..............................................................................................63.5 ASSUMPTIONS AND DEPENDENCIES.............................................................................6

4. SPECIFIC REQUIREMENTS.............................................................................74.1 FUNCTIONAL REQUIREMENTS......................................................................................7

4.1.1 Functional Requirement 1: DB Interface...............................................................74.1.1.1 Introduction.................................................................................................................74.1.1.2 Inputs..........................................................................................................................74.1.1.3 Processing...................................................................................................................74.1.1.4 Outputs.......................................................................................................................7

4.1.2 Functional Requirement 2: Logins and Permissions..............................................74.1.2.1 Introduction.................................................................................................................74.1.2.2 Inputs..........................................................................................................................74.1.2.3 Processing...................................................................................................................74.1.2.4 Outputs.......................................................................................................................7

4.1.3 Functional Requirement 3: Automatic Backup......................................................84.1.3.1 Introduction.................................................................................................................84.1.3.2 Inputs..........................................................................................................................84.1.3.3 Processing...................................................................................................................84.1.3.4 Outputs.......................................................................................................................8

4.1.4 Functional Requirement 4: Report Generation.....................................................84.1.4.1 Introduction.................................................................................................................84.1.4.2 Inputs..........................................................................................................................84.1.4.3 Processing...................................................................................................................84.1.4.4 Outputs.......................................................................................................................8

4.1.5 External Interface Requirements..........................................................................84.1.5.1 User Interfaces............................................................................................................84.1.5.2 Hardware Interfaces....................................................................................................94.1.5.3 Software Interfaces.....................................................................................................94.1.5.4 Communication Interfaces..........................................................................................9

4.2 PERFORMANCE REQUIREMENTS...................................................................................94.3 DESIGN CONSTRAINTS................................................................................................9

4.3.1 Standard Compliance...........................................................................................94.3.2 Hardware Limitations...........................................................................................9

4.4 ATTRIBUTES.............................................................................................................104.4.1 Availability..........................................................................................................104.4.2 Security Requirements.......................................................................................104.4.3 Maintainability....................................................................................................10

4.5 OTHER REQUIREMENTS.............................................................................................104.6 USE CASE SCENARIOS..............................................................................................11

University of Hartford Page 2 of 23 5/27/2023

App-Trac

4.7 USE CASE DIAGRAM.................................................................................................124.8 CONCEPT SCREENSHOT.............................................................................................13

1. Authors

Victor SklutovskyChristopher PadillaMyles Garvey

University of Hartford Page 3 of 23 5/27/2023

App-Trac

2. Introduction

The goal of the App-Trac project is to develop an application to allow the Literacy Volunteers of Greater Hartford (LVGH) to monitor usage of literacy software applications to better evaluate students learning needs as well as streamline current report generation for management.

2.1 PURPOSEThe purpose of this document is to define the software requirements specification for the program set known as App-Trac.

2.2 SCOPEApp-Trac will act as a single interface to the various literacy applications used at LVGH, by its students, and an interface for administrators to monitor literacy application usage data.

The scope of this document is focused on the broad requirements to satisfy the client, LVGH.

The scope of this project is limited to the following phases:Phase 1 (Spring 2008): The following functional requirements will be targeted for implementation.

4.1.1 : Database o Sufficient detail to allow log in, time logging and simple report

generation. 4.1.2 Logins and Permissions

o Handles all three types of users. 4.1.4 Report generation

o Generate two or three sample reports to be provided by client 4.1.5 External Interface

o Implement kiosk access system

2.3 DEFINITIONS, ACRONYMS AND ABBREVIATIONS LVGH — Literacy Volunteers of Greater Hartford. App-Trac — Name of this project for LVGH. SRS — Software requirements specification [document]. DB — Database. Lexia — Software currently used by LVGH.

University of Hartford Page 4 of 23 5/27/2023

App-Trac

Ellis — Software currently used by LVGH. EuroTalk — Software currently used by LVGH. MySQL — Backend DB software. PHP — Frontend web-based interface. Java — Programming language that will be used. HTML — Hypertext markup language that produces web

pages. OS — Operating system. Windows XP — OS that will be used. Kiosk Mode — Interface, prohibiting access outside of it.

Definitions, Acronyms and Abbreviations will be added as necessary.

2.4 REFERENCESReferences will be added as necessary.

2.5 OVERVIEWApp-Trac is an attempt to introduce an automated system to help streamline data gathering and processing, to help alleviate a significant amount of human overhead, freeing up valuable staff time, and to help reduce associated operational costs.

University of Hartford Page 5 of 23 5/27/2023

App-Trac

3. General Description

3.1 PRODUCT PERSPECTIVEThe LVGH currently have a rudimentary system in place to keep track of their application usage by their students. To organize and facilitate maintenance of the current system, a new system will be designed to handle the functions and features sought out by the LVGH. This new system will be open source, and hence will be available to other non-profit organizations that share a similar need.

LVGH currently does not have an independent system to monitor students’ usage of the organizations literacy application suite, which consists of a mixture of applications, from third party vendors. Currently the Technology Manager at LVGH has a rudimentary clock-in system to allow users to log when they use the computer. The manager manually accesses individual literacy application backend databases to export usage information to Microsoft Excel spreadsheets, which are then combined by hand to generate specific use data statistics for management and instructors. This present approach does not allow LVGH to gather all the statistics required, due to the overhead associated with the manual data retrieval and collation process.

App-Trac project is an attempt to introduce an automated system to help streamline the data gathering and processing, to help alleviate a significant amount of human overhead, freeing up valuable staff time and help reduce associated operational costs.

3.2 PRODUCT FUNCTIONSThe system currently in place uses a simple time tracker that could easily lose track of who logs onto the computer and information is sent to a spreadsheet. Additionally, the “Log out?” box that appears immediately after a student logs in can be confusing, and is equally easy to bypass. The new system will involve a simple splash screen that appears when the computer is booted up and after it automatically logs in to Windows through the guest account, as well as a back end system providing administrators and volunteers access to reports and information from the DB. Logging out option will only be available when appropriate, thus simplifying the task. There will be three tiers of user access: administrators, volunteers and students. On the front page of the splash screen will be a login box with existing student and staff user accounts. Each username will have permissions associated with it,

University of Hartford Page 6 of 23 5/27/2023

App-Trac

dictating who has permissions to what aspects of App-Trac. When a user logs in, a set of applications will be presented to them. Current application set consists of Lexia, Ellis, and EuroTalk. A time tracker in the background will keep track of how long the user is logged on and how long they are using a specific application. App-Trac will also prohibit users from exiting the splash screen so they will only be given access to the applications the staff allows them to access. Other optional functions will include automatic backup and automated data transfer.

The following functional requirements are to be met by App-Trac. Serve as a single point of entry for students using the Literacy applica-

tion suite provided by LVGH. Able to interface automatically or via batch upload of user data from

3rd party literacy applications such as Lexia and Ellis. Provide capability for administrator to customize the set of accessible

applications. Generate customized reports that meet managements/instructors

needs. Provide a management interface for administrators to make configura-

tion changes and generate reports.

3.3 USER CHARACTERISTICSUsers of App-Trac will be presented a user-friendly interface. User names will not only be the names of the students, but also unique pictures of either the user or some other object. A unique username, which will not be visible to students, can be composed of the first name, followed by last name, followed by 3-digit number, which can be assigned to the picture they choose as their avatar. To avoid accidental “mislogins”, the student will have to press a separate button to login once their name is selected. LVGH will not have passwords for users, but for general purpose, an option will be added to turn on and off password protection for each user. This system is geared towards not only the administrative end, but also towards the students finding difficulties in reading. The interface will also allow flexibility for the addition of applications that may be needed by LVGH or other organizations. Students will not have access to the Windows operating system, but rather the computer would enter a kiosk mode that would only allow them access to the applications they are permitted to use.

University of Hartford Page 7 of 23 5/27/2023

App-Trac

The following user characteristics are envisioned for the following users of the App-Trac application.

3.3.1 Student Users:App-Trac would serve as a gateway for the student to access LVGH application suite. The student would authenticate and launch the desired Literacy application through App-Trac. The tracking capabilities of App-Trac need not be apparent to the user. Student users will be logging in either individually or as part of a class/group. If they do log in as part of a group, the user needs to log which volunteer/instructor was with them. The system is required to track if the student connected as part of a class activity or individually. App-Trac is required to log the duration of the class. (eg. Student logged in from 10am-11am as part of class, then from 11am-12pm individual usage. This information is required for meet funding organizations reporting needs.

3.3.2 Administrator:App-Trac would provide a management interface for an administrator. The following functionality will be available to a user with administrative privileges:

Ability to configure a list of predefined applications that can be ac-cessed by the student

Ability to generate customized reports on particular users or applica-tions.

Ability to view user authentication logs. Ability to export database data as flat Microsoft Excel compatible work-

sheets. Ability to add and remove user credentials

3.3.3 Volunteers:App-Trac would provide an interface for volunteers (instructors) to track their class progress.

3.4 GENERAL CONSTRAINTSAs mentioned before, App-Trac will be open source, and hence the constraint is mainly put onto which programming language is used and which compliances need to be followed. Other constraints include hardware used

University of Hartford Page 8 of 23 5/27/2023

App-Trac

by LVGH, adaptation to current DB systems, and adaptations to current applications.

3.5 ASSUMPTIONS AND DEPENDENCIESApp-Trac both will be based off of an independent DB, and must also adapt to current DB systems. Applications will be presented to users, so administrators will be able to add any new and remove any old applications from the system with very little trouble. The format of the DB is still to be determined, but since open source is required, it would be logical to use MySQL as well as PHP for DB access. A secure computer on the network will be the host for the DB. Synchronization will be dynamic, meaning once data needs to be written, it will be written immediately to the server and not stored on a local machine, unless the network is down at the time, in which case all new data will be stored locally until connectivity is restored. The front end of App-Trac will be running on systems using Windows XP.

University of Hartford Page 9 of 23 5/27/2023

App-Trac

4. Specific Requirements

4.1 FUNCTIONAL REQUIREMENTS

4.1.1 Functional Requirement 1: DB Interface

4.1.1.1IntroductionThe application must interface with an open-source DB, where all the data gathered from other applications is kept in a centralized manner (details to be provided by client) Currently there is an issue of duplicate records, which must be eliminated in the new system.

4.1.1.2InputsInputs consist of DBs of the literacy software already in place, including Lexia and Ellis, and possibly of DBs of other applications yet to be added. See attached copies provided by the client. Input fields are shown in screenshots (extracts from Laces). Information includes personal details, time log information.

A1: Student Record Data 1 A2: Student Record Data 2 A3: Existing lab sign in sheet

4.1.1.3ProcessingData from input DBs will be parsed and filtered to a specified extent, and will be stored inside the new DB. The new DB must be field-editable.

4.1.1.4OutputsNew DB, various reports.

4.1.2 Functional Requirement 2: Logins and Permissions

4.1.2.1IntroductionCentralized login and permission control.

4.1.2.2InputsInputs consist of a unique username and some password. Usernames must follow some naming convention (TBD), and will determine user’s permissions: regular users will only have limited access, whereas

University of Hartford Page 10 of 23 5/27/2023

App-Trac

administrators will have access to data gathering tools, the DB, various reports and options.

4.1.2.3ProcessingLogin information should be encrypted. When a user logs on, the system checks what access they have and displays the appropriate dialog box.

4.1.2.4OutputsAppropriate interface.

4.1.3 Functional Requirement 3: Automatic Backup

4.1.3.1IntroductionThe central DB should be backed up automatically at user-specified intervals.

4.1.3.2InputsThe central DB.

4.1.3.3ProcessingBackup and save the copy in a user-specified location, following a user-specified naming convention.

4.1.3.4OutputsCopy of the central DB.

4.1.4 Functional Requirement 4: Report Generation

4.1.4.1IntroductionApp-Trac must include features for easy report generation and access. Current reports have image-represented percentages, which must be changed to number-represented percentages. Sample reports for Phase 1 will be provided by client.

4.1.4.2InputsThe central DB, report format.

4.1.4.3ProcessingData for reports is extracted from the central DB per user specifications.

4.1.4.4OutputsPrinted or displayed through a web browser reports.

University of Hartford Page 11 of 23 5/27/2023

App-Trac

4.1.5 External Interface Requirements

4.1.5.1User InterfacesThe application must operate in kiosk mode: as soon as Windows loads and automatically logs in as a guest, the application must open on the entire screen and listen for keystrokes, so that the user cannot get to the Windows desktop or any other application aside from App-Trac. Essentially, App-Trac must hijack the screen and special key combinations, like ALT+TAB.

However, users should be able to terminate the session, as long as they do it properly: exit the application and log out – at any time.

For ease of administration, there should be a special key combination, like CTRL+ALT+DEL, which will bring up administrator login box. Having logged in, authorized users will be able to access administrative features and exit to Windows.

User interface, especially for non-administrator users, must be more graphics-reliant than text-reliant. Due to the nature of this project, many users will be unable to read, so they should be accommodated graphically.

As described in the use cases separate UI features should be designed for three types of users : students, volunteers, administrators.

4.1.5.2Hardware InterfacesThis section will be updated soon.

4.1.5.3Software InterfacesApp-Trac must interface with Windows, an open-source DB, and DBs of applications already used by LVGH.

4.1.5.4Communication InterfacesThis section will be updated soon.

4.2 PERFORMANCE REQUIREMENTSIt is yet to be determined how many users should be handled concurrently. But one thing is for sure, App-Trac’s DB must be accessed by many terminals at the same time, so any implementation-specific conflicts must be resolved. Other performance requirements are yet to be determined.

4.3 DESIGN CONSTRAINTSApp-Trac must be written in Java.

University of Hartford Page 12 of 23 5/27/2023

App-Trac

4.3.1 Standard Compliance

Standards are yet to be determined.

4.3.2 Hardware Limitations

Client’s hardware will be examined, after which this section will be updated.

4.4 ATTRIBUTES

4.4.1 Availability

In terms of hardware failures, it should be handled externally (by Windows) as much as possible, and where Windows fails to handle them, App-Trac must catch all errors and exceptions and display a message on the screen, describing what went wrong. App-Trac may also generate a log to be analyzed by a trained professional.

4.4.2 Security Requirements

As stated in section (4.1.5.1), App-Trac must operate in kiosk mode. For reference, a good kiosk mode application is used by the Borders book store on their in-store customer-useable “Title Sleuth” terminals, where the only access a user has is to the search interface, and not the underlying OS.

User login information must be encrypted (or encryptable).

4.4.3 Maintainability

This section will be updated soon.

4.5 OTHER REQUIREMENTSThis section will be updated soon.

University of Hartford Page 13 of 23 5/27/2023

App-Trac

4.6 USE CASE SCENARIOSUse Case Scenario 1: New User Arrives

1. Users comes in2. User asks volunteer where to begin3. Volunteer creates new account4. Central DB is updated5. User logs into App-Trac6. Central DB is updated7. User accesses an application8. User quits the application9. Central DB is updated10. Go to Step 7 or Step 1111. User logs out of App-Trac12. Central DB is updated

Use Case Scenario 2: Existing User Arrives1. Users comes in2. User logs into App-Trac3. Central DB is updated4. User accesses an application5. User quits the application6. Central DB is updated7. Go to Step 4 or Step 88. User logs out of App-Trac9. Central DB is updated

Use Case Scenario 3: Administrator Adds Application1. Administrator logs onto App-Trac2. Administrator goes to Add/Remove Application Section of App-Trac3. Administrator chooses the program to Add4. Administrator adds the chosen program5. Go to Step 3 or Step 66. Administrator logs out of App-Trac

University of Hartford Page 14 of 23 5/27/2023

App-Trac

4.7 USE CASE DIAGRAM

University of Hartford Page 15 of 23 5/27/2023

App-Trac

Following use cases takes into account all three types of users.

University of Hartford Page 16 of 23 5/27/2023

App-Trac

2) Log-in User Case

University of Hartford Page 17 of 23 5/27/2023

App-Trac

3) Ellis / Lexia/ etc. User Access User Case

University of Hartford Page 18 of 23 5/27/2023

App-Trac

4) Check Progress User Case

University of Hartford Page 19 of 23 5/27/2023

App-Trac

5) Generate Reports User Case

University of Hartford Page 20 of 23 5/27/2023

App-Trac

6) Edit User User Case

University of Hartford Page 21 of 23 5/27/2023

App-Trac

7) Create User User Case

University of Hartford Page 22 of 23 5/27/2023

App-Trac

4.8 CONCEPT SCREENSHOT

University of Hartford Page 23 of 23 5/27/2023