Events Module v. 3.4 Requirementsby Bryan CheI. IntroductionThis 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 StatementOnline 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:
III. GlossaryIn this document, the following terms have specific meanings:
IV. System/Application OverviewThe events module consists of:
V. Use-cases and User-scenariosThe events module is intended for the following two classes of users, which may or may not overlap:
Event CreationAnnie 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 RegistrationRoger 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 ManagementAnnie 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 CommunicationAfter 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 ModelThe 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 10.4.1.1 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 Administration20 Event Administration20.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 20.2.1.1 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 20.2.2.1 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 20.2.3.1 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 20.2.4.1 the event administrator should be able to view the registrations status of all his own ongoing events 20.2.4.2 the event administrator should be able to view, comment upon, and change the registrations states of individual registrations 20.2.4.3 the event administrator should be able to view aggregate event registration statistics 20.2.4.3.1 the event administrator should see order histories by dates 20.2.4.3.2 the event administrator should see order histories by registration id 20.2.4.3.3 the event administrator should see order histories by registration state 20.2.4.3.4 the event administrator should see order histories by user group 20.2.4.3.5 the event administrator should see order histories by activity 20.2.4.3.6 the event administrator should see order histories by event 20.2.4.4 the event administrator should be able to search for registrations 20.2.5 E-Mailing Registrants 20.2.5.1 the event administrator should be able to e-mail individual registrants 20.2.5.2 the event administrator should be able to e-mail specific events' registrants
VII.C. Requirements: User Registration30 User Registration30.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
bryanche@arsdigita.com |
|