RE: Reports and Other Screenshots

Then Khaiim added the following:

Administrator can change all data, add all types of users, and change all settings.

Staff can change all data, add student and volunteer users, and not change settings.

Volunteers can add student users (not delete), View some data, and add some data (not delete).

Ideally, the Administrator is able to choose which groups can view, and change, and add to each field (as well as add new fields).

RE: Reports and Other Screenshots

Trishan responded to my question about permission levels with the following:

Between staff and volunteer, it’s a way of differentiating between a volunteer and a full time staff member at LVGH. In terms of permissions a volunteer wouldn’t have access to more sensitive information about a student such as social security number etc, while a staff member would. The administrator has authorization to do anything including adding/removing users, changing program settings etc…

Reports and Other Screenshots

This is the content of the e-mail from Khaiim, dated 02/21/08, which was forwarded by Trishan to team leaders. Regarding the three worker permission levels (read below), I e-miled a clarification request to Trishan. The 11 attachments are reports and various other screenshots.

Hi Trishan, this includes 2 reports that are complex, so 4 reports could be extrapolated from them.

Also included are screenshots of all the relevant Student keys.

Also included are all the fields that the LACES Database has, just to get an idea of the scope, but again, we are not concerned with most of this data, at least right now.

Major thoughts on requirements after reviewing with staff yesterday and today:

We need to know if a student is in the lab with a group, or not. One of the reasons is that attendance is taken in the classes, and we cannot count their hours twice (“double-dip”), especially when reporting to funding sources. We DO need to capture the hours, but we need to make sure we are not reporting class hours in the lab, as if they are non-class hours.

We need to track the program used (lexia, eurotalk, firefox), at the least, and at the most the activity/title within the program, as well as the scores (vowels level 1 unit 5 80%, gmail.com, funbrain.com “grammar gorillas”). We would like to track multiple activities in one session, which was not feasible before (if a student spends 10 minutes on email, then 20 on lexia, and 30 on ellis).

Related to the first issue above, we need to switch from “group” to “individual” hours if a student was in the lab with a teacher from 10 to 12, but remains in the lab after class.

We need to have a way to automatically log off, or force user to confirm info after a (changeable) set number of minutes. For example are you [name]? still with a group? Administrators should also have the option to set a time at which all users are logged off (for example 9 pm), and an optional time at which computers are reset or shut down.

There should be 4 different levels of permission: Student, Volunteer, Staff, Administrator 

The best model for the type of data that will be most useful to us is the laces screenshot “LacesGroupHours”, except that Type, would be more like Program name, and there would be more fields as described above. 

Will send another email soon.

Attachments (11):

SRS 2.2 With Accepted Changes Update

This is the merged SRS with input from all four teams and client revisions. This was posted on BlackBoard, and I haven’t changed the filename.

SRS 2.2 With Accepted Changes Update Sklutovsky

Another App-Trac mockup

Here is a mock up created of the “Kiosk-mode” splash screen. More mock up’s will be created in the future. This mock up features a list of the user names currently in the system. When a user name is selected, their person image is displayed on the left hand side. Upon verification that this image is the one they picked for their login, they can proceed to log in via the button below the image. In the bottom right hand corner is a “lock” to be used for admin access only. The idea of the lock is to always have immediate access at any kiosk rather then logging in as admin from another computer. This idea may not be the route to take but will be taken into further consideration at a later time.

Link

Trishan provided this link containing various materials pertaining to the project, including the two presentations, screenshots and sample data we have seen before:

http://www.cs.trincoll.edu/~tdelaner/uhartford/

You may want to bookmark it.

SRS 2.2 Update

SRS + use case scenarios + use case diagram + concept screenshot.

SRS 2.2 Sklutovsky

SRS Presentation 1.0

This is the presentation for 2/19/08. The presentation is complete, and follows SRS closely, so each team member will do their corresponding section. Also, below is a conceptual screenshot of the login screen.

SRS Presentation 1.0

SRS 2.1 Update

Here is the all-encompassing revision 2.1 of the SRS. I edited all sections a bit, adding the new information of course. I decided to not add use case scenarios into this document, but keep them separately.

SRS 2.1 Sklutovsky

SRS 2.0 Update (General Description)

general-description.doc