reset password

Sci-CAFE Data Requirements

The preliminary project description of the Sci-CAFE Web Portal and App can be found here. This document focuses on the data requirements of the project. System functions will be described in more details in another document.

Users

There are two types of users in the system for the purpose of access control: administrators and regular users.

Anyone can register and becomes a regular user in the system. During registration, a user must provide the following information:

Optional information provided by a user during registration include:

Events

Any user can submit events to be posted on the web portal. An event must be reviewed and approved by an administrator before it is posted, except that if a user is designated as an Event Organizer, the events submitted by the user can be posted directly.

An event has a name, a description, a location, a start time and an end time. An event may have tags, which are keywords describing event type, content, affiliations, and so on. For example, a workshop on robotics hosted by the ACM Student Chapter can be tags with "Robotics", "ACM", "Computer Science".

The system must keep track of who attended an event (we assume there will be a check-in mechanism).

Rewards

Rewards are used to encourage people to attend events. For example, a reward can be extra credit in a class, or some Cal State LA gears, or early registration privilege. It should be noted that the actual rewards are given outside the Sci-CAFE system. Sci-CAFE is responsible for a) publishing the reward information, and b) letting the reward provider know who should receive the reward.

Any user can submit rewards to be posted on the web portal. A reward must be reviewed and approved by an administrator before it is posted, except that if a user is designated as a Reward Provider, the rewards submitted by the user can be published directly.

A reward includes a description of the reward, the name of the person/organization providing the reward (note that the user who submits the reward may not be the same person/organization that provides it), and a reward period (only events held during the reward period are eligible for the reward). In order for the system to determine who should receive a reward, a reward must also specify qualified events and reward criteria.

Qualified events are the events the reward is for, and in turn, the participants of these events become the candidates for the reward. There are two ways to specify qualified events:

Reward criteria determine who should receive the reward out of all the people who attended the qualified events. Because of practical considerations, reward criteria should be easy to specify by a user and easy to determine by the system. For now, we assume that reward criteria are expressed in the form of "minimum n events attended". For example, suppose there are three LSAMP workshops and a reward requires that the students attend all of them, then n would be 3. Another reward may require that the students participate in at least six ACM Student Chapter events, in which case the reward can be associated with the tag "ACM" and n would be 6.

Misc.

In addition to users, events, and rewards, the system should also keep track of organizational units and programs so they can be added and modified. Organizational units should be organized in a hierarchical manner with CSULA at the top, under which are the colleges and various university offices, and under the colleges are the departments.

Each program should have a name (e.g. FYrE@ECST), a full name (e.g. First-Year Experience Program at ECST), and a description.