Академический Документы
Профессиональный Документы
Культура Документы
Team 10
Jared Hostmeyer
Jeffrey Rogers
Keegan Heilman
3 November 2006
Student Event System, Software Requirements Specification
3 November 2006
Table of Contents
Introduction .................................................................................................................................................. 3
Functional Requirements .............................................................................................................................. 4
Priority Level One...................................................................................................................................... 4
Priority Level Two ..................................................................................................................................... 6
Priority Level Three ................................................................................................................................... 6
Non-Functional Requirements ...................................................................................................................... 6
Priority Level One...................................................................................................................................... 6
Priority Level Two ..................................................................................................................................... 7
Priority Level Three ................................................................................................................................... 7
Use Case Diagram ......................................................................................................................................... 7
Use Case Descriptions ................................................................................................................................... 8
Detailed Use Cases ...................................................................................................................................... 10
Scenarios ..................................................................................................................................................... 13
Requirement Traceability Matrix ................................................................................................................ 15
Glossary ....................................................................................................................................................... 17
System Interface ......................................................................................................................................... 19
Contributions .............................................................................................................................................. 22
References .................................................................................................................................................. 22
NCAA Sports ............................................................................................................................................ 22
University of Maryland ticketing............................................................................................................. 22
LA Times .................................................................................................................................................. 23
Ticketmaster ........................................................................................................................................... 23
Note ........................................................................................................................................................ 23
Checklist ...................................................................................................................................................... 23
2
Student Event System, Software Requirements Specification
3 November 2006
Introduction
Student events and athletics have always been a large attraction for universities across the nation. A
major piece of these events are the invitation, ticket distribution and reservation, and reporting tools
used by administration and campus leaders. Here at the University of Nevada, the process is often
manually carried out; but given the recent implementation of the new student ID system, the
development of new web services, and the future improvements of the on-site ticket processing
equipment, a new student event management system is warranted. This proposal is for a new multipart,
integrated solution for students, offering ease of use and high accessibility, known as the Student Event
System (SES). The original project concept included only development related to athletics ticketing, but
the new system has been expanded to handle many types of events and activities on campus, as well as
new and innovative features.
The project includes a multi-faceted system for student event ticket distribution. By extending an
existing web application, namely the Associated Students of the University of Nevada website, a process
for students to login and reserve a ticket for any sporting event, performance, or activity will be
developed. This part of the project will have several sections, a web application for the online
reservation, a standalone application for information desk and possible kiosk reservations, and an on-
site check-in and reservation retrieval system.
In addition to the original project concept, the following features have been included in the project
specification for development. Event invitations, allowing event planners and administrators to send
bulk email invitations to students and the campus community about events and activities. Invitations
can be responded to in the reservation system, allowing for events to be identified as requiring a
reservation or optionally requiring a reservation. Online reservations will allow for more readily made
reports based on expected attendance and will reduce to congestion at information desks and offices.
Further, the project includes specifications for a feedback system, providing leaders with survey results
on the success of the program. Feedback surveys will be easily augmented with the addition of the
attendance tracker, which will have a localized application for on-site attendance logging using the new
student ID cards. Finally, event attendance can be rewarded by event coordinators in the proposed
rewards system. Here, students will earn points based on the event and the given attendance. With
these points, administrators can distribute rewards to those heavily involved groups and individuals.
All of these features, new and old, will be accessible through an easy to use portal for students and
adm inistrators. The Event Portal w ill show all of the user’s “m yEvents,” w hich include things like
upcoming activities, recently attended events, reservations, awaiting invitations and any rewards which
may have been disbursed.
The project as a whole will be primarily a web application. The user login component will be using
existing user authentication information held in the University Active Directory and facilitate in the web
application over a secure socket layer. Scheduled events will be posted in the system manually through
an administrative user interface or loaded dynamically from an RSS or XML feed supplied by the
3
Student Event System, Software Requirements Specification
3 November 2006
University/Athletics department. Students will then be able to select an event and perform a variety of
actions on the event in the Event Portal.
The standalone application for the information desks and potential use of kiosks would have near same
functionality as parts of the web application. The standalone application will connect to the web site for
the information retrieval over XML web services in the .NET framework.
4
Student Event System, Software Requirements Specification
3 November 2006
Functional Requirements
Requirements have been distributed among three levels, Priority Level One requirements are necessary
for the project’s success,Priority LevelTw o requirem ents are im portant to the project,but m ay be less
likely because of time constraints or future and/or unforeseen limitations of the system, and finally
Priority Level Three requirements are elements of the project which would be beneficial to the system,
but are extremely unlikely to be implemented.
1.1. [R01] The system shall provide distribution of event invitations by free-text email list.
1.2. [R02] The system shall provide distribution of event invitations by selection from a list
of users.
1.3. [R03] The system shall provide for the distribution of event invitations by email to
event invitees.
1.4. [R04] The system shall place in records the notification of invitation to users.
1.5. [R05] The system shall display to administrators the event invitees.
1.6. [R06] The system shall display to administrators the date and time of the event
invitation.
1.7. [R07] The system shall send notification of event cancellation in the case of such
matter to all invitees.
1.8. [R08] The system shall provide appropriate connections to content for event
invitation purposes.
1.9. [R09] The system shall send notification of event cancellation in the case of such
matter to all event attendees.
1.10. [R10] The system shall provide users a method of reviewing all event invitations as
assigned.
1.11. [R11] The system shall provide a method to respond to event invitations through the
reservation system.
1.12. [R12] The system shall provide a method to users for event reservations as applicable.
1.13. [R13] The system shall provide a method to users for the review of event reservations.
1.14. [R14] The system shall provide a method for events to be added to the system.
1.15. [R15] The system shall provide a method for events to be edited in the system.
1.16. [R16] The system shall provide a method for events to be cancelled in the system.
1.17. [R17] The system shall provide a method for events to be viewed in a calendar.
1.18. [R18] The system shall provide a method for past events to be viewed.
1.19. [R19] The system shall provide a method by which student reservations are validated
against the active student body through the use of the NetID.
5
Student Event System, Software Requirements Specification
3 November 2006
1.20. [R20] The system shall provide a method for administrators to view list of reservations
per event.
1.21. [R21] The system shall provide a method for events to be identified as needing
reservations.
1.22. [R22] The system shall provide a method for events to be identified as optional made
by reservation.
1.23. [R23] The system shall provide a method for event reservations to begin by a specified
date.
1.24. [R24] The system shall provide a method for event reservations to end by a specified
date.
1.25. [R25] The system shall provide a method for the specification of the maximum
number of reservations.
1.26. [R26] The system shall provide a method for the report of attendance at events.
1.27. [R27] The system shall provide a method for attendance to be recorded at events.
1.28. [R28] The system shall provide for the connection between students and event
attendance.
1.29. [R29] The system shall provide a method for the recording of reward points.
1.30. [R30] The system shall provide a method for the identification of point values per
event.
1.31. [R31] The system shall provide a method for assignment of rewards.
1.32. [R32] The system shall provide a method for the display of rewards and distributions.
1.33. [R33] The system shall provide for a method by which event attendees may submit
feedback about a particular event.
1.34. [R34] The system shall provide for a method by which anonymous visitors may submit
feedback about a particular event.
1.35. [R35] The system shall provide for a method by which administrators may review
summary statistics for event feedback.
1.36. [R36] The system shall provide for the cancellation of a reservation.
1.37. [R37] The system shall provide an event portal for individual users to facilitate event
actions and activities.
1.38. [R38] The system shall provide for a method by which a feedback survey may be
closed.
1.39. [R39] The system shall provide distribution of event invitations by selection from
predefined invitation lists.
1.40. [R40] The system shall place in the message queue the invitation to specified users, if
applicable.
6
Student Event System, Software Requirements Specification
3 November 2006
1.41. [R41] The system shall provide for a method by which length of period for feedback
submission.
1.42. [R42] The system shall provide for multiple reservations batches per event.
1.43. [R43] The system shall provide for administrator customization of event feedback
surveys.
1.44. [R44] The system shall provide an application for reading student ID cards for event
attendance.
1.45. [R45] The system shall provide an application for reading student ID cards for event
reservations.
1.46. [R46] The system shall provide for a method to retrieve an event reservation at the
event.
1.47. [R47] The system shall provide for a method by which event reservations may be
made by the general public.
1.48. [R48] The system shall provide for a method by which events may have costs levied
for attendance.
1.49. [R49] The system shall provide for a method by which event costs may be collected.
7
Student Event System, Software Requirements Specification
3 November 2006
Non-Functional Requirements
Requirements have been distributed among three levels, Priority Level One requirements are necessary
for the project’s success,Priority LevelTw o requirem ents are im portant to the project,but m ay be less
likely because of time constraints or future and/or unforeseen limitations of the system, and finally
Priority Level Three requirements are elements of the project which would be beneficial to the system,
but are extremely unlikely to be implemented.
8
Student Event System, Software Requirements Specification
3 November 2006
Event Manager
SentEventInvite ConfirmInvite
* *
CancelEventInvite DenyInvite *
*
* * *
*
*
* ViewRewards
OpenReservation *
* User
* *
* *
Admin
*
EndReservation ViewEvent
*
* *
GenerateReport ViewReport *
*
*
* * Public
SubmitFeedback
*
9
Student Event System, Software Requirements Specification
3 November 2006
UC02 CancelEventInvite The admin can cancel event invites by specific user, all users,
and predefined groups; the system will send out email
notification to users.
UC03 OpenReservation The admin can open reservation for an event through the
specific event’s page. Reservations can be restricted by
admin to length, number of attendees, predefined groups,
and invite only.
UC04 EndReservation The admin can end reservation for specific event by selecting
from all events. Reservations can be ended before allotted
time or for events with unrestricted length.
UC06 ConfirmInvite The user can RSVP for specific event when they receive an
invite and reservation is open.
UC07 DenyInvite The user can deny invitation to event; reason why user is
unable to attend can be included.
UC08 ViewRewards The user can view the rewards they have obtained by
attending awarded events through their personal portal.
UC09 ViewEvent The user and the public can view available events and
corresponding information. Some events may not be
viewable to the public.
10
Student Event System, Software Requirements Specification
3 November 2006
UC10 ViewReport The user and the public can view attendance reports
generated by the admin if made available to them.
UC11 SubmitFeedback The user and the public can leave feedback for a specific
event from the event page or from the feedback page by
selecting the specific event from a list of all events.
Feedback will be in the form specified by the admin, which
may be radio button forms and/or free-text.
11
Student Event System, Software Requirements Specification
3 November 2006
12
Student Event System, Software Requirements Specification
3 November 2006
13
Student Event System, Software Requirements Specification
3 November 2006
14
Student Event System, Software Requirements Specification
3 November 2006
Scenarios
15
Student Event System, Software Requirements Specification
3 November 2006
16
Student Event System, Software Requirements Specification
3 November 2006
17
Student Event System, Software Requirements Specification
3 November 2006
Use Case
UC01 UC02 UC03 UC04 UC05 UC06 UC07 UC08 UC09 UC10 UC11
R01 X
R02 X
R03 X
R04 X
R05
R06
R07 X
R08 X X
R09 X
R R10
e R11 X
q R12 X X X
u R13 X
i R14
r R15
e R16
m R17
e R18
n R19 X
t R20 X
R21 X
R22 X
R23 X
R24 X
R25 X
R26 X
R27
R28 X X
R29 X
R30
R31
R32 X
R33
R34 X
R35
R36 X
R37 X
R38 X
R39 X
R40 X
R41 X
R42 X
R43 X
R44
R45
R46
R47 X
R48 X
R49
18
Student Event System, Software Requirements Specification
3 November 2006
Glossary
Paper Ticket A slip of paper serving as evidence that the holder has paid the
fare or admission to a particular event.
Public User An anonymous user of the system who has not identified
himself/herself via login with NetID.
19
Student Event System, Software Requirements Specification
3 November 2006
Student ID Card Plastic card with photograph and full name of student, for
identification, integrated with tools developed to make on-site
transactions.
20
Student Event System, Software Requirements Specification
3 November 2006
System Interface
21
Student Event System, Software Requirements Specification
3 November 2006
22
Student Event System, Software Requirements Specification
3 November 2006
Figure 4: Demonstration of existing portal environment which could be converted to an event portal.
23
Student Event System, Software Requirements Specification
3 November 2006
Contributions
The following are the contributions of the team members toward Part II: Software Requirements
Specification.
Jared Hostmeyer Wrote introduction, based partially on introduction from Part I: Project
Concept. Defined project requirements, both functional and non-
functional. Identified useful snapshots and defined in document.
Compiled completed document and formatting.
Jeffrey Rogers Designed and created use case diagram. Wrote template for and
content of detailed use cases. Wrote template for and content of
detailed scenarios. Researched reference materials and provided
descriptions.
Keegan Heilman Designed and created requirement traceability matrix including linking
requirements in specification to use cases in specification. Compiled
and wrote descriptions for glossary of terms.
24
Student Event System, Software Requirements Specification
3 November 2006
References
NCAA Sports
http://www1.ncaa.org/membership/membership_svcs/sponssummary
This page from the N CAA’s w ebsite lists the num ber of universities w hich partake in individual sports.
The huge numbers shows there is a substantial market for an event manager software package and it
has the potential to be sold to many different groups. This just shows the market for athletics which is
huge in itself and does not even take into account the market for other events.
At the University of Maryland there is a similar system to ours already in place. Examining the way their
system works will enable us to offer additional features and possibly builder on some of theirs. The
demand is obviously there for our software since similar systems are already in place.
LA Times
http://www.latimes.com/sports/college/usc/la-sp-uscrep19sep19,1,1936480.story?coll=la-headlines-
sports-collusc&ctrack=1&cset=true
These articles from the LA Times shows even though there are already similar systems in use they have
their flaw s. O ur system w ill learn from other system ’s flaw s and m ay be m ore appealable to
organizations that already have these systems in place.
Ticketmaster
http://www.ticketmaster.com/h/about_us.html
Ticketmaster is the leading source of event ticketing in the U.S. Our software has low priority
requirements that may be implemented in the future to integrate with ticketmaster for events.
Note
Unfortunately, due to the nature of the software, little references could be identified in literature or on
the Internet. As a resource, event management systems are not one of the heavily published
applications.
25
Student Event System, Software Requirements Specification
3 November 2006
Checklist
The following checklist was extracted from the checklist provided to us for use in Project Part II and was
completed on November 3, 2006.
T h e S R S d o cu m en t …
… h a s a co ve r p a g e . YES
… th e co ve r p a g e h a s a p p ro p ria te in fo rm a tio n o n u n ive rsity,
department, course, project title, project part, team name, team YES
members, instructor, and date.
… h a s a ll p a g e s numbered. YES
… h a s a ta b le o f co n te n ts. YES
… th e ta b le o f co n te n ts sh o w s p a g e n u m b e rs fo r a ll se ctio n s a n d
YES
subsections.
… h a s a n In tro d u ctio n . YES
… .th e In tro d u ctio n h a s a t le a st 4 0 0 w o rd s a n d a t m o st 8 0 0 . YES
26
Student Event System, Software Requirements Specification
3 November 2006
S cen ario s …
… e a ch sce n a rio re la te s to a u se ca se . YES
… e a ch sce n a rio h a s a u n iq u e ID th a t re la te s to a u se ca se … YES
… is initiated by at least an actor ... YES
… h a s a t le a st 5 ste p s … YES
... has pre-co n d itio n (s) … YES
… h a s p o st-co n d itio n (s) … YES
… d o e sn 't in clu d e if-then-else or loop constructs. YES
S n ap sh o ts o f th e u ser in terface …
… a t le a st < 3 /4 > a re in clu d e d in th S R S . YES
… e a ch sn a p sh o t h a s a ca p tio n … YES
… a n d a b rie f d e scrip tio n . NO
G lo ssary o f term s …
… a t le a st < 1 5 /2 0 > te rm s a re in clu d e d in th e glossary. YES
… e a ch te rm is re la te d to th e p ro je ct's a p p lica tio n d o m a in . YES
… e a ch te rm is u se fu l to a n o n -expert to get a better understanding of
YES
the application domain.
27
Student Event System, Software Requirements Specification
3 November 2006
28