Original App-Trac Requirements
From Humanitarian FOSS Summer Institute 2008
Back to App-Trac page
Contents
|
Introduction
Purpose
The purpose of this document is to outline the functionality, capabilities, and requirements of the App-Trac system, as agreed upon by both the client and the developers.
Authors
Sarah Thayer, Myles Garvey, Chris Fei, Ernel Wint
Intended Audience
The intended audience for this document is LVGH, and other organizations interested in a similar program.
Definitions
- LVGH: Literacy Volunteers of Greater Hartford
- App-Trac: Name of project for LVGH
- SRS: Software Requirements Specification (document)
- DB: Database
- MySQL: Back-end DB
- PHP: Front-end web-based interface
- HTML: Hyper Text Markup Language used to produce web pages
- API: Application Programming Interface
- Java: Programming language to be used
- Javadoc: a tool for generating API documentation in HTML format from specific comments in the code
- OS: Operating System
- Windows XP: initial OS to be used
- Kiosk Mode: Interface, prohibiting access outside of it
- Lexia: Software application currently used by LVGH
- EuroTalk: Software application currently used by LVGH
- Logging In: Signing in to access application suite
- Clocking In: Signing in similar to a time punch (for volunteers)
Overall Description
Product Perspective
The purpose of App-Trac is a user-friendly interface that will allow multiple literacy applications to be connected into one system. Students, literacy volunteers, and administration personnel will be able to access information through the App-Trac kiosk system, removing the computers' OS from users' normal access. App-Trac will also keep progress data of all students and volunteers, and generate full or specific data reports on student performance to be analyzed by volunteers using App-Trac. Through the App-Trac interface, students will be able to access literacy applications by clicking in and out of each application through a kiosk instead of separate, standalone icons that would otherwise be on the desktop.
Product Functions
App-Trac will provide tracking for when a student logs in and out of the system. App-Trac is based on multi-tier user access: administrators, volunteers and students. Students will be able to log into their specific session of App-Trac by selecting their name from a selection menu and then logging in by selecting yes or no. Once users log in, a set of applications will be presented, and generated progress for each individual application will be mined by App-Trac to provide an overall report of a student. Lab coordinators will be able to use the App-Trac system as a functional way to clock in and out, informing users of the supervisor on duty. Depending upon the given access level of a volunteer, his or her personal account will be password protected allowing different amount of access to student-specific information. In addition, there will be a public volunteer forum viewable to users with access level of volunteer and above for general needs and student comments, a virtual discussion board. Only an admin user will be able to delete anything on the forum. Another optional function will include automatic backup and automated data transfer that will ensure the protection of the data.
User characteristics
App-Trac provides a user-friendly interface with names of the students and unique pictures (avatars) of either the user or some other object. Students will be given a unique username, which will not be visible to students, which can be composed of the first name, last name, and a 3-digit number. This can be assigned to the user's picture they choose as their avatar. To avoid accidental 'mislogins', the student will have to press a separate button to confirm their login once their name is selected. Students' general use of App-Trac does not require entering a password, though turning on or off password protection will be optional 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 any other organizations. Students will not have access to the Windows operating system. Instead, the computer will enter a kiosk mode that will only allow them access to the applications they are permitted to use for literacy training.
Operating Environment
App-Trac is primarily operating on the Windows OS, though there may be possible future cross-platform implementations. In Windows, App-Trac will be a full screen kiosk system that will restrict access to the underlying operating system. App-Trac will either be implemented as a standalone kiosk application, or as a centralized web application.
Design/Implementation Constraints
Constraints may include accessing each literacy application database for App-Trac data reporting.
Product Functions
App-Trac will consist of a set of functions necessary for both the needs of LVGH and other non-profit organizations with similar requirements. These functions include application tracking, specific website tracking, user management, data integration and management, report generation, and application management. App-Trac will be a module-based system, and hence will include functionality for extensibility. Examples of this extensibility will be found in the functions of user and application management as well as the report generation.
Tracking System (Core)
Within the core system of App-Trac will be a tracking system. This tracking system will include tracking of a student's activity during the use of a computer. It will record which applications the user visited and send timestamps to a database, which later can be used for report generation.
Specific Website Tracking
Along with the tracking of applications and logins of students on a specific computer, there will be the tracking of specific websites. This could either be a core function of App-Trac, or an extensible module (see 3.6). Only websites that an LVGH administrator desires and sees fit for useful information will be tracked.
User Login System (Core)
The login functionality will consist of name and password combinations. The logging system will meet the following requirements.
Logging In
Logging in is defined as the process of a user signing on to use a computer. How a user uses a computer is based on access level (see 4.1). The process is analogous to logging onto an OS, like windows, the only difference being that specific data is sent to the App-Trac database, which can later be used for reporting.
Clocking In
Clocking in is defined as the process of a user signing into LVGH or another specific non-profit organization. This system consists of 'clocking into work' by the simple click of a button. Note that a user can be clocked in and but not logged in at any particular time. The purpose of clocking in is to track volunteers that are on duty for a specific amount of time. This system can also be extended to any other user that may require a clocking system.
Idle Management
When a user logs in, sometimes that user fails to log out. This could cause problems for LVGH and other non-profit organizations with data analysis. A solution is an Idle Management system. This system would consist of a listener, so that every time a key is pressed or a mouse is clicked a timer would begin. After a given time (which could be determined on the administration end of App-Trac), App-Trac will display a warning message to the user, asking them if they are still using the application. After two minutes of no response, the system will log the current user out of App-Trac.
Class Management
There will be certain situations during which some users of the computers will be part of a class and other users will be using the computers on personal time. Due to legal and financial reasons, it is necessary to not only log time on the computers, but to differentiate this time between class time and personal time. When a student logs in, their login session defaults to personal time. Since classes and student rosters will be stored on the database, whenever a student logs in, App-Trac will query against the database to check whether the student is part of a class currently taking place. If the student is part of the roster of a current class, his session will start to record class time. After the class is over, his session will switch back to personal time.
Data Integration and Management (Core)
Synchronization of Application Data
In the initial installation of App-Trac, an administrator may want or need data from other applications to be automatically synchronized. This, however, could be quite a tedious task since data from other applications are stored differently. A synchronization process will be setup within App-Trac so that either user data from other applications can be imported into the database, or synchronized to matching unique IDs. This function will allow report generation across many applications all in one system, for dynamic and more timely reporting.
Application Data Integration
The data from applications currently at LVGH and other non-profit organizations are not standardized for interoperability, i.e., incompatible. App-Trac will attempt to provide a solution for easier data integration. The system will consist of gathering information from application's databases or data exports and either integrating all the data in a single database or just accessing the data directly from the currently available data sources. The biggest problem is the structure of the databases, for each application has its own structure. A simple solution to this could be a module that allows any administrator to pick and choose which data they need from a visual representation of the application's database. App-Trac will 'remember' the structure of each database based off of the administrator's decisions and could be used at a later time period in an easier fashion.
Data Backup System on Client Machines
Since data could easily be lost due to network connectivity or power failure, App-Trac will include a backup system, so if applications are still being used, App-Trac will still keep track of this data. When connectivity is reestablished, the local database will synchronize with the server database to reduce possible data loss and minimize interruption to computer usage.
Report Generation (Base Module)
Report Interface
Report generation is a key feature for App-Trac, but will be implemented in a module form on top of App-Trac. This will allow easy modifications to the report generation process without looking too much into the source code. The interface will consist of a visual representation of all the databases specified by the administrator (see 3.5). The visual representation will allow the administrator to choose which data should be included in a report. The report can either be viewed or exported (see 3.4.2).
Report Export
Reports can either be viewed or exported in any format necessary for the given non-profit organization. Possible formats include HTML, CSV, PDF, etc. These are all printable formats, and could all be implemented on a web-based system, so they could also be viewable through a browser.
Data Access (Is this necessary?)
User and Application Management (Base Module)
App-Trac will include an administrative end that allows users and applications to be added. This edition of App-Trac will be in the form of a module, so control can be customizable for the specific non-profit organization. The user management section will involve the user information to be stored in the database. That user may have a certain access level (see 4.1), with certain permissions to specific functionality (see 4.1). The management will also involve personal information of users, so vision of this may also depend on user permissions. Application management will work in a similar manner to user management, but will have the extra feature of 'pointing' to an application's data source. This data source can be a collection of exports or a database. This will allow report generation of application data.
Volunteer Forum (Base Module)
Many situations occur where a volunteer on one shift needs to relay information to a volunteer on another shift. These two volunteers will likely not see each other between these times, so a forum for volunteer use will be implemented. This forum will be divided into two subsections, and it will function similarly to a bulletin board: the most recent posts will appear on top for other volunteers to read. The two sections that will compose the forum are for general needs and for student progress. If any notes need to be taken on a student (such as the student is struggling and needs to be moved or a student is progressing satisfactorily) they will be posted on the subsection dedicated to this topic. The other subsection will deal with any other kind of notes volunteers may need to write to one another. Volunteers will be able to add new messages to be placed on the forum; however, they will not be able to delete said messages. This permission will be reserved for the administrator.
Extensibility
The function of modules will allow LVGH and other non-profit organizations to add features that they deem necessary without severe modifications to the core source code. App-Trac's module system will be an easy system that allows developers to code specific parts of App-Trac in a timely manner and simply add it on to the core system. This will prove extremely useful for other non-profit organizations needing a similar but not exact system as LVGH's needs for App-Trac.
User Characteristics
User Permissions
Students
Students will have the most limited access of all users. They will be required to log in and log out of the system for use. They will have access to standard LV applications such as Lexia and Eurotalk in addition to web applications such as Mozilla Firefox and an email application. These applications are determined by the administration of the non-profit organization or LVGH.
Volunteers
Volunteers will have specific permissions in addition to those of students. Volunteers will be able to access student information about habits and trends of use of the applications, particularly the learning applications. While viewing these statistics, they will be able to generate reports on the information and print out or export it to a spreadsheet. Volunteers may add a new student user with limited information: first and last name, and first language. A volunteer-exclusive permission is the ability to clock in and clock out (see 3.2.2). A volunteer can clock in from one computer and clock out from another.
Staff
Staff users inherit all permissions of Volunteers. In addition, staff users can access personal information about other users such as home address and phone number, and add and manage new users.
Data Admin/Tech Management (module addition)
This user has all permissions. They will be able to change any option and manage and view all data. This is an advanced status and an admin will be able to directly change, manage, and add modules to App-Trac. They are the only ones allowed to delete posts from the public volunteer forum. Database management is also allowed for an admin.
Customizable User Permissions
The above user statuses are simply saved templates or macros to streamline user creation. An admin certainly has the option of creating a new type of user with very specific permissions. That is, he or she can create a user with permissions in between those of a Volunteer and a Staff member. Any new template can be saved for later use.
User Interfaces
Students
A student interface will be easy to use and easy to interpret. Many of the student users have limited literacy, and thus the interface used by them will have to accommodate their needs. Pictures and even sounds will be incorporated into their interface to simplify their use of App-Trac as much as possible. They will be able to log in through a log in screen and access will then be given to a panel of applications to choose.
Volunteers
The logged in interface of a Volunteer will be nearly identical to that of a student, and will include the volunteer control panel. This allows for class management and general access options, and a link to the Public Volunteer Forum. The logged in interface of a Volunteer will be nearly identical to that of a student. In addition, there will be tabs to view student usage statistics and generate a report containing said statistics. There will also be an option off to the side -of all screens-? to allow Volunteers to clock in without monopolizing a computer.
Staff
The interface of a Staff user will be the same as that of a Volunteer, only with additional tabs. Personal information about users will now be able to be accessed and a New User tab will be added. This interface will not necessarily be as graphics-friendly as that of a student.
Data Admin/Tech Management
The admin will have the most complicated interface. There will be many options and tabs for the admin to choose and edit. Like a staff member, the admin's interface will not necessarily be flashy. The admin has all options of previous users, in addition to functionality for generating reports, adding new modules, adding and updating class rosters and schedules, creating and manipulating data, and changing user permissions.
Use Cases and Scenarios
| User | System |
|---|---|
| 1. Chooses name/avatar from App-Trac login screen | Checks class roster, time, name: user is not part of a class, so default ‘personal time’ in DB; records user, time |
| 2. Chooses application to use | Records time, application |
| 3. Closes application | Records time, synchronizes with application DB |
| 4a. Go back to 2 | Go back to 2 |
| 4b. IF user has class | Checks class roster, time, name: user is part of a class, so change to ‘class time’ in DB. Records user, time, teacher. Go to Case B #2. |
| 4c. User logs out of App-Trac | Records user, time |
| User | System |
|---|---|
| 1. Chooses name/avatar from App-Trac login screen | Checks class roster, time, name: user is part of a class, so change to ‘class time’ in DB; records user, time |
| 2. Chooses application to use | Records time, application |
| 3. Closes application | Records time, synchronizes with application DB |
| 4a. Go back to 2 | Go back to 2 |
| 4b. IF user has class | Checks class roster, time, name: user is part of a class, so change to ‘class time’ in DB. Records user, time, teacher. Go to Case B #2. |
| 4c. User logs out of App-Trac | Records user, time |
Case C: Guest student uses applications (Optional if guest student will use these applications.)
| User | System |
|---|---|
| 1. Logs in to App-Trac | Records user, time |
| 2. Goes to ‘Class Rosters’ tab, finds current class. Checks new student’s box to add (temporarily) to class, clicks ‘Save’ | System changes student’s time to ‘class time’ until class ends |
| 3. Logs out of App-Trac | Records user, time |
| User | System |
|---|---|
| 1. Goes to any computer, clicks ‘Volunteer Clock-in/out’ | |
| 2. Enters username, password (?), ‘Clock in’ | Records user, time |
| 3. Goes to any computer, clicks ‘Volunteer Clock-in/out’ | |
| 4. Enters username, password (?), ‘Clock out’ | Records user, time |
| User | System |
|---|---|
| 1. Logs in to App-Trac | Records user, time |
| 2. Goes to ‘Add Student’, inputs: first name, last name, first language, clicks ‘Save’ | Adds new user and information to DB |
| 3. Logs out of App-Trac | Records user, time |
| User | System |
|---|---|
| 1. Logs in to App-Trac | Records user, time |
| 2. Navigate to ‘Forum’ tab, chooses which section to post in (General Needs or Student Comments) | Access DB and display posts on the screen |
| 3. Click ‘Add Comment’, types comment, clicks ‘Save’ (or ‘Publish’…) | Gathers data, adds to forum page with user, time |
| 4. Logs out of App-Trac | Records user, time |
| User | System |
|---|---|
| 1. Logs in to App-Trac | Records user, time |
| 2. Goes to ‘Generate Report’ tab, chooses specific report type desired | Gathers all required data, synchronizes it together, generates report, displays (option to view or print) |
| 3. Logs out of App-Trac | Records user, time |
| User | System |
|---|---|
| 1. Logs in to App-Trac | Records user, time |
| 2. Goes to ‘Add User’, inputs: first name, last name, first language, home address, phone number (…?) as applicable, sets access level, clicks ‘Save’ | Adds new user and information to DB |
| 3. Logs out of App-Trac | Records user, time |
| User | System |
|---|---|
| 1. Logs in to App-Trac | Records user, time |
| 2. Goes to ‘Edit User’ (?), inputs rest of personal information as applicable, clicks ‘Save’ | Changes new user and information in DB |
| 3. Logs out of App-Trac | Records user, time |
| User | System |
|---|---|
| 1. Logs in to App-Trac | Records user, time |
| 2. Add User: goes to ‘Add/Remove User,’ selects ‘Add User’ and inputs necessary information. Clicks ‘Save’ | Adds new user and information to DB |
| 3. Remove User: goes to ‘Add/Remove User,’ selects ‘Remove User,’ selects user from current list, clicks ‘Remove’. Warning message: “Are you sure?”, clicks ‘Yes’ | Removes user and all related information from DB |
| 4. Change Permissions: goes to ‘User Permissions’, selects ‘Edit Permissions’, selects user from list of current users, checks boxes for certain permissions. If different from normal 4 types, can save as another type of access level-type in new name | Changes access level for user. If new level is added, save permissions as new type. |
| 5. Logs out of App-Trac | Records user, time |
| User | System |
|---|---|
| 1. Logs in to App-Trac | Records user, time |
| 2. Goes to ‘Class Rosters’ tab, ‘Add Class’ | |
| 3. Inputs teacher name, checks off all students in class from registered users list (searchable, for time/ease of use?), days/times of class, clicks ‘Save’ | Records all information to use for personal/class management of DB |
| 4. Logs out of App-Trac | Records user, time |
| User | System |
|---|---|
| 1. Logs in to App-Trac | Records user, time |
| 2. Navigate to Forum tab | Access DB and display posts on the screen |
| 3. Click ‘Delete’ link corresponding to the post to be deleted | Delete post from DB |
| 4. Logs out of App-Trac | Records user, time |
Case N: Admin database configurations
Case O: Admin adds modules
Operating Environment
Hardware
We do not currently have much information on the systems on which App-Trac will be running. With the eventual goal of distribution to other LV organizations, it is really impossible to tell what kind of system the application will be run on. Even so, our goal will be to allow App-Trac to run with as little overhead as possible.
Platform
The computers at LVGH were running Windows XP Professional. It is unknown whether a change to Linux will be implemented in the future. App-Trac will most likely be able to be implemented into a Linux environment due to the portability of Java code.
Network
Coordination with others on Network
The computers at LVGH are all networked together, sharing some common hard drives. Not much more is known about their network.
Possible Web Implementation
A web implementation of App-Trac is being considered. A problem arises with difficulties in accessing and executing local applications from a web browser. A student and volunteer interface may be difficult to implement in this way, but a web implementation may be a viable medium for a staff or admin interface that does not require executing local applications.
Design/Implementation Constraints
Legality of Information
One constraint that many be encountered is the legal issue of personal information. Not all students of LVGH and non-profit organizations may want their information seen by those besides the coordinators of the programs. For example, volunteers are not legally allowed to view students' personal information. Personal information may need to be encrypted and viewing access given only to those approved (see 6.5).
Hardware Constraints
Since App-Trac is focused towards non-profit organizations, the hardware may not be the most up-to-date. Careful algorithm design may be needed for the App-Trac system due to this constraint. Design for optimal performance must be considered.
Synchronization and Integration of Data
This may cause a problem due to the structure of databases of applications. Some applications may use different types of databases, as well as different structures. Finding a method for generalizing application data and integrating this into App-Trac may be a large constraint.
Generality
Developing App-Trac for LVGH is simpler than developing it for a general purpose. Some non-profit organizations may need features of App-Trac common to the ones needed for LVGH, but may also need completely different features. One approach to overcome this constraint is the design of a module system within App-Trac. The system must also be compatible for multiple operating systems.
Security
See 6.1 for the legality constraints. Due to these constraints, an encryption system may be needed to ensure that no personal information can be 'leaked' out to anyone with access to App-Trac. This task itself may cause some constraints since the encryption process itself may be difficult to develop for such a vast amount of information. Some information that needs to be secured is addresses, phone numbers, social security numbers, etc.
Other Nonfunctional Requirements
Security requirements
App-Trac is to operate in kiosk mode, allowing access to only the available applications in the kiosk. Users in general will not be allowed to access the underlying OS. Passwords will not be available to non-English speaking student users for ease of use, but will be made available to volunteers and administrators for security purposes. All user login information will be encrypted or at least encrypt able. To that end, all database information, particularly personal user information, must be protected from potential malfunctions in user permissions or hacking of the system.
Project documentation
Project documentation will consist of Javadoc comments and specific comments within the code. A possible wiki will be set up that will list all the functional aspects of App-Trac and will also allow new developers to easily pick up on making modifications to the system.
User documentation
User documentation will consist of a user manual designed for administrators, including how App-Trac works, how to perform an initial setup, and how to add new functionality. A couple of detailed tutorials will be added on how to add new modules to App-Trac for general needs. Documentation will also include end-use guides, with instructions on how to user App-Trac.
Appendices
Appendix A: References
Writing Software Requirements Specifications Donn Le Vie, Jr.
Back to App-Trac page
