ArsDigita Archives

Events Module v. 3.4 Requirements

by Bryan Che

I. Introduction

This document describes the requirements for the ACS events module. The events module performs two primary functions: it allows administrators to create, plan, and manage events and events registration through the Web, and it allows users to register for these events over the Web.

II. Vision Statement

Online events registration offers little value for those either event planners or event registrants. The real significance of managing events online lies in it ability to empower event planners. Therefore, the events module has four main goals which center around event administrators. The events module aims to:
  • Simplify offering repeat events
  • Simplify handling registrations
  • Simplify coordinating registrants
  • Simplify communicating with registrants

III. Glossary

In this document, the following terms have specific meanings:
a kind of event; the type of thing for which people register. E.g. a lecture or a conference.
an instance of an activity, occurring during a specific time period and in a specific venue. E.g. a conference from April 2-4, 2000 in Boston, MA.
the physical location where an event occurs.
a mapping of a single user to a single event, signifying that the user who made the registration wishes to attend the event for which he registered
a mapping of a single user to a collection of at least one registration, signifying that this user has collectively placed the registration(s) in this order.

IV. System/Application Overview

The events module consists of:
  • An interface for creating and managing events. This involves creating and managing:
    • activities
    • venues
    • event times
    • event registration fields
  • An interface for managing event registrants. This includes approving, denying, wait-listing, and viewing registrations.
  • An interface for e-mailing event registrants.
  • An interface for viewing event order histories.
  • An interface for users to place registrations.

V. Use-cases and User-scenarios

The events module is intended for the following two classes of users, which may or may not overlap:
  • Event Administrators (referred to as the event administrator), who create and manage events and event registrations.
  • Users (referred to as the user), who find out information about events and register for them.

Event Creation

Annie Admin wants to plan a series of free seminars for her company which will occur in various places around the world over the next year. She first creates a seminar activity, with default registration fields and descriptions for users. Then, she creates the various venues in which her seminars will occur, filling out appropriate information such as address, contact info, and description. Finally, she creates her individual seminar events. Each individual seminar event occurs in a certain venue and time span. The seminars share the same basic description, registration fields, and form since they are all the same activity. But, Annie Admin could tailor individual seminars if she wished.

Annie Admin marks the events so that registrants require administrator approval and limits the number of registrants for each seminar to thirty people. Then, she makes her seminars available for registration.

Event Registration

Roger Registrant visits Annie Admin's company Web site and sees the list of seminars Annie Admin has created. He notices that one of the upcoming seminars will occur near him, so he clicks on that seminar to read about it. Finding the seminar interesting, Roger Registrant decides to register for it. He fills out the seminar's custom registration form and submits it. The Web site informs Roger that his registration has been received and requires approval to be finalized. It then e-mails Roger this confirmation and also e-mails Annie Admin, notifying her that there is a new registration for her seminar.

Registration Management

Annie Admin visits the events administration page and sees that, including Roger Registrant, thirteen people have registered for various seminars. She reads the thirteen applicants' applications and decides to approve eleven of them. Annie does not immediately approve Roger's registration. Instead, she marks it as "needing more information" and types in a note asking Roger to include more background information on his current job. Annie Admin denies the other registration.

All thirteen registrants receive e-mail notification regarding their registrations. The eleven approved registrants are notified that they are approved, the denied registrant is told he is denied, and Roger is asked to come back to provide more background information on his current job.

Roger Registrant re-visits Annie Admin's company Web site and edits his registration information to include more background on his job. The Web site notifies Annie Admin that Roger has edited his registration, so she comes back to the events administration pages and re-evaluates Roger's application. This time, she approves the registration. Roger receives e-mail notifying him that he may come to the seminar.

Event Communication

After Annie Admin's company seminars are over, she reviews the seminars' order histories. She finds that two particular seminars had an unusually high number of applicants. Since Annie Admin had set her seminars to automatically wait-list registrants once all thirty slots were filled, these two seminars had large numbers of wait-listed registrants. So, she decides to create two new seminars in these two popular locations. Then, Annie Admin e-mails all the wait-listed registrants of these two seminars, informing them that she has created new seminars for which they can register if they are still interested in attending them.

VI. Related Links

VII.A. Requirements: The Data Model

The data model for the events module must describe four main principals involved in events: activities, venues, events, and event registrations.

10 The Data Model

10.1 Activities

10.1.1 activities must have a name

10.1.2 activities must be able to be toggled between "available" or "not available"

10.1.3 activities should have a description

10.1.4 activities may belong to user groups or to no groups at all. A user group represents the specific organization or organization type that is offering the activity

10.1.5 activities may store default fields to collect from registrants

10.2 Venues

10.2.1 venues must have a name

10.2.2 venues must have a location

10.2.3 venues should have a description

10.2.4 venues may need to be reserved

10.2.5 venues may have contact information

10.2.6 venues may have capacities

10.3 Events

10.3.1 events must be instances of activities

10.3.2 events must have start times, end times, and registration deadlines

10.3.3 events may require registrants to be approved

10.3.4 events may store custom fields to collect from registrants

10.3.5 events may have organizers

10.4 Event Registrations

10.4.1 registrations have various states registration states should represent fully processed registrations, registrations requiring administrator approval, registrations which are wait-listed, and registrations which are canceled

10.4.2 people may place multiple registrations on behalf of others in a single order

VII.B. Requirements: Event Administration

20 Event Administration

20.1 Event Administrators

20.1.1 only the event administrator may access the event administration pages

20.1.2 the event administrator may only administrate activities for user groups to which he belongs or activities which do not belong to a user group

20.2 User Interface

20.2.1 Creating Activities the event administrator may create and manage activities, providing values for the activity properties listed in requirement 10.1.x

20.2.2 Creating Venues the event administrator may create and manage venues, providing values for the venue properties listed in requirement 10.2.x

20.2.3 Creating Events the event administrator may create and manage events, providing values for the event properties listed in requirement 10.3.x

20.2.4 Event Registrations the event administrator should be able to view the registrations status of all his own ongoing events the event administrator should be able to view, comment upon, and change the registrations states of individual registrations the event administrator should be able to view aggregate event registration statistics the event administrator should see order histories by dates the event administrator should see order histories by registration id the event administrator should see order histories by registration state the event administrator should see order histories by user group the event administrator should see order histories by activity the event administrator should see order histories by event the event administrator should be able to search for registrations

20.2.5 E-Mailing Registrants the event administrator should be able to e-mail individual registrants the event administrator should be able to e-mail specific events' registrants

VII.C. Requirements: User Registration

30 User Registration

30.1 the user may place only one non-canceled registration for an event

30.2 the user will be able to see a list of upcoming events for which he can register

30.3 the user will be able to read information about an event before registering for that event

30.4 the user cannot register for events which are full

30.5 the user cannot register for events which are not available

30.6 the user cannot register for events whose registration deadline have passed

30.7 the user may have to enter registration information as specified by that event's administrator

30.8 the user must be notified by e-mail of his registration status and any status changes

30.9 the user must be able to review his registration status from the Web site

30.10 the user may be able to edit his registration information, if the event is set to permit such changes

30.11 the user may be able to cancel his registration, if the event is set to permit such changes

VIII. Revision History

Document Revision # Action Taken, Notes When? By Whom?
0.1 Creation 8/29/2000 Bryan Che