Вы находитесь на странице: 1из 28

Department of Computer Science

University of Nevada, Reno

S.E.S.: Student Event System

Team 10

Jared Hostmeyer

Jeffrey Rogers

Keegan Heilman

Sergiu Dascalu, Professor

Sandra Rodriguez, Advisor

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.

Priority Level One

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.

Priority Level Two

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.

Priority Level Three

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.

Priority Level One

1.1. [R50] The system shall match appearing of existing systems.


1.2. [R51] The system shall match formatting and organization of existing systems.
1.3. [R52] The system shall match coding techniques, languages, and support structures of
existing systems.
1.4. [R53] The system shall integrate with existing data structures and stores.
1.5. [R54] The system shall authenticate all user NetID logins with University
authentication systems.
1.6. [R55] The system shall have centralized event resource access for all users.
1.7. [R56] The system shall have centralized event resource access for all administrators.
1.8. [R57] The system shall have printer friendly pages.

Priority Level Two


No Non-Functional Priority Level Two requirements have been established.

Priority Level Three


No Non-Functional Priority Level Two requirements have been established.

8
Student Event System, Software Requirements Specification
3 November 2006

Use Case Diagram

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

Use Case Descriptions

Use Case Descriptions


UC01 SendEventInvite The admin can send event invites through email by a free-
text email list or by selecting users and/or predefined
groups.

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.

UC05 GenerateReport The admin can generate attendance reports by customizable


options such as demographics. Reports can then be
published to users, predefined groups, or the public.

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

Detailed Use Cases

Use Case: SendEventInvite


Use Case ID UC01
Actor(s) Admin
Precondition(s) 1. Admin is logged in.
2. Event is created.
3. Email system is configured.
4. Correct emails are input for users
Flow of Events 1. The use case starts when the admin navigates to the specific event page
and clicks “Invite G uests”.
2. The admin selects event from list of all events.
3. The admin selects specific user and/or groups.
4. The admin adds additional emails via free-text.
5. The admin selects time and date for invitations to be sent.
6. The admin adds optional free-text comment.
7. The admin presses the send button.
8. The system sends emails through previously configured email.
Post Condition(s) 1. Emails are sent by system and received by users.

12
Student Event System, Software Requirements Specification
3 November 2006

Use Case: OpenReservation


Use Case ID UC03
Actor(s) Admin
Precondition(s) 1. Admin is logged in.
2. Event is created.
Flow of Events 1. The use case starts when the admin navigates to specific event page and
clicks “O pen Reservations”
2. The admin selects date range for reservation or unlimited
3. The admin selects to start accepting reservations when finished or at a
specified time.
4. The admin selects the number of attendees allowed or unlimited.
5. The admin enables predefined groups, invitees only, or any user to make
reservations.
6. The adm in clicks “Subm it” to subm it info to system .
7. The system sets-up reservation form for the specific event.
Post Condition(s) 1. Users can make reservations through the specific event page.

13
Student Event System, Software Requirements Specification
3 November 2006

Use Case: SubmitFeedback


Use Case ID UC11
Actor(s) User
Public
Precondition(s) 1. Admin has made feedback available for specific event.
2. If user
2.1. User is logged in.
Flow of Events 1. The use case starts w hen user or public clicks “Leave Feedback” on event
page or by selecting specific event on Feedback page.
2. While feedback is open for event
2.1. The user and/or public can fill out feedback form or type free-text.
2.2.The user and/or public clicks “Subm it” to subm it feedback.
3. The system forwards feedback to admin.
Post Condition(s) 1. The admin moderates feedback and decides to publish or not to publish
event feedback.

14
Student Event System, Software Requirements Specification
3 November 2006

Scenarios

Use Case: SendEventInvite


Use Case ID UC01.1
Actor(s) Admin
Precondition(s) 1. Admin is logged in.
2. Event is created.
3. Email system is configured.
4. Correct emails are input for users
Primary Scenario 1. The use case starts when the admin navigates to the ASUN BBQ event
page and clicks “Invite G uests”.
2. The admin confirms the specific event is selected from the list of all
events.
3. The admin selects the ASUN member group.
5. The adm in selects “w hen finished” for tim e to send invitations.
6. The adm in adds “H opefully the w eather is good!” in the free-text
comment field.
7. The admin presses the send button.
8. The system sends email invites to all ASUN members for the BBQ.
Post Condition(s) 1. ASUN and only ASUN members receive email invites for the BBQ

15
Student Event System, Software Requirements Specification
3 November 2006

Use Case: OpenReservation


Use Case ID UC03.1
Actor(s) Admin
Precondition(s) 1. Admin is logged in.
2. Event is created.
Primary Scenario 1. The use case starts when the admin navigates to ASUN BBQ event page
and clicks “O pen Reservations”
2. The admin selects from 11/3/06 until 11/17/06 at 12:00pm (one day
before event) for reservations to be made.
3. The admin selects to start accepting reservations when the form is
submitted.
4. The admin selects unlimited for number of attendees.
5. The admin enables only the ASUN member group to make reservations.
6. The adm in clicks “Subm it” to subm it info to system .
7. The system sets-up reservation form for the ASUN BBQ.
Post Condition(s) 1. ASUN members can make reservation for the BBQ through the specific
event page.

16
Student Event System, Software Requirements Specification
3 November 2006

Use Case: SubmitFeedback


Use Case ID UC11.1
Actor(s) User
Public
Precondition(s) 1. Admin has made feedback available for specific event.
2. If user
2.1. User is logged in.
Primary Scenario 1. The use case starts w hen user clicks “Leave Feedback” on the ASUN BBQ
event page.
2. The user rates the food as a 5 and the entertainment as a 5 via radio
buttons. The user leaves “Ihad a really great tim e” in a free-text
comment field.
3. The user clicks “Subm it Feedback” and the form is forw arded to adm in
for review.
Post Condition(s) 1. The admin review the submitted feedback and publishes it for all users
and public to see on the ASUN BBQ event page.

17
Student Event System, Software Requirements Specification
3 November 2006

Requirement Traceability Matrix

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

Administrator The person(s) responsible for maintaining the system.

ASUN The Associated Students of the University of Nevada; ASUN is


made up of every undergraduate student at the University of
Nevada and provides a vehicle, through elected officials, to
voice student concerns.

Event Something that is planned by ASUN or entity involved with


ASUN to occur in a certain place during a particular interval of
time, commonly announced to attract attendance.

Feedback Evaluative information derived from a reaction or response to a


particular event.

Invitation A written request for someone's presence or participation for a


particular event.

Net ID Identification of a student, via login on university systems, by


the individual’s unique university distributed usernam e and
personally chosen password.

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

Reservation The record or assurance given of an arrangement by which


accommodations are secured in advance for a particular event.

Reward Points Points distributed for events attended by an individual which


will in the future be redeemable for rewards to be determined.

RSVP French: répondez s'il vous plait (please reply); to reply to an


invitation.

Student ID Card Plastic card with photograph and full name of student, for
identification, integrated with tools developed to make on-site
transactions.

User A person who uses the system, either as a public user,


anonymously, or identified by NetID.

Validation To prove or serve to prove that the subject in question is


approved by the University Active Directory authentication
system.

20
Student Event System, Software Requirements Specification
3 November 2006

System Interface

Figure 1: Demonstration of calendar interface.

Figure 2: Demonstration of general event management interface.

21
Student Event System, Software Requirements Specification
3 November 2006

Figure 3: Demonstration of general event addition interface.

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.

Figure 5: Demonstration of potential feedback survey manager.

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.

University of Maryland ticketing


Referrence the FAQ section, https://www.ticketreturn.com/umd/YourTickets.asp?Source=Home

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.

Requirements Specification Requirements Version no.


Review date:
Internal Review no.

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

S ystem req u irem en ts…


… in clu d e a t le a st < 1 8 /2 4 > fu n ctio n a l re q u ire m e n ts. YES
… in clu d e < 7 /9 > n o n -functional requirements. YES
… re q u ire m e n ts a re o rg a n ize d o n 3 le ve ls o f p rio rity. YES
… fu n ctio n a l re q u ire m e n ts a re re la te d to u se ca se s in a tra ce a b ility
YES
matrix.

The use case m o d el…


… co n ta in s u se ca se s to in itia lize a n d sh u td o w n th e a p p lica tio n . N/A
… is n o t o ve rly co m p lica te d . YES
… co n ta in s a t le a st 7 u se ca se s. YES
… co n ta in s a t le a st 1 a cto r. YES
… is d ra w n u sin g th e U M L n o ta tio n . YES

Each use case in the u se case m o d el co n sists o f…


… a g ra p h ica l re p re se n ta tio n in U M L n o ta tio n . YES
… a nam e … YES
… th a t co n sists o f a ve rb p h ra se … YES
… a n d co n ve ys th e p u rp o se o f th e u se ca se to re vie w e rs. YES
… a m e a n in g fu l te xtu a l d e scrip tio n o f 2 to 4 lin e s. YES
… a cto rs, e a ch o f w h ich …
… is b rie fly d e scrib e d … YES
… re p re se n ts a n e n tity e xte rn a l to th e syste m … YES
… a n d h a s a m e a n in g fu l n a m e . YES

26
Student Event System, Software Requirements Specification
3 November 2006

E ach d etailed u se case…


… is d e scrib e d u sin g a te m p la te a s in [A rlo w a n d N e u sta d t 2 0 0 2 ]. YES
… is initiated by one or more actors. YES
… h a s a t le a st 6 ste p s. YES
… h a s a u n iq u e ID . YES
… h a s p re -condition(s). YES
… h a s p o st-condition(s). YES
… h a s a n o rm a l flo w o f e ve n ts. YES
… [o p tio n a l] h a s a lte rn a te flo w s o f e ve n ts. NO

Overall (reg ard in g d etailed u se cases) …


… a t le a st < 3 /4 > d e ta ile d u se ca se s (w ith te m p la te s) a re in clu d e d in
YES
the SRS.

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

O verall (reg ard in g scen ario s) …


… a t le a st < 3 /4 > d e ta ile d scenarios are included in the SRS. YES
… a t le a st o n e d e ta ile d sce n a rio is a p rim a ry sce n a rio . YES

R eq u irem en ts traceab ility m atrix …


… a ll fu n ctio n a l re q u ire m e n ts a re liste d in th e m a trix. YES
… e a ch fu n ctio n a l re q u ire m e n t o n le ve l 1 o f priority is related (traced)
NO
to at least 1 use case.
… e a ch u se ca se is re la te d to a t le a st 1 fu n ctio n a l re q u ire m e n t. YES
… in th e m a trix, n o t a ll re la tio n sh ip s b e tw e e n re q u ire m e n ts a n d u se
YES
cases are 1 to 1 (that is, relationships N to 1 or/and 1 to N also exist).

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

… e a ch te rm h a s a d e scrip tio n . YES


… [o p tio n a l] so m e te rm s h a ve syn o n ym s indicated. NO
… [o p tio n a l] so m e te rm s a re h o m o n ym s (w ith a lte rn a tive m e a n in g s
NO
indicated).

L ist o f referen ces…


… a t le a st < 4 /6 > a re in clu d e d in th e S R S . YES
… e a ch re fe re n ce h a s a b rie f d e scrip tio n o f b e tw e e n 3 0 a n d 6 0 w o rd s. YES
… e a ch reference is properly listed such as the reader could get
YES
access to it via a web or library search.

C h ecklist (th is o n e!) …


… e a ch ch e ck th a t is n o t o p tio n a l h a s b e e n e va lu a te d a n d re ce ive d
YES
either a YES or NO answer.
… a t le a st 1 internal review has been completed. NO
… th e ch e cklist ta b le (th is o n e ) h a s b e e n in clu d e d in th e S R S o r
YES
attached to it as an appendix.

C o n trib u tio n s o f team m em b ers …


… e a ch te a m m e m b e r is liste d . YES
… fo r e a ch te a m m e m b e r, th e sp e cific se ctio n s/su b se ctio n s (o r, if
needed, items) of this part of the Project on which he or she has YES
worked are indicated.

28

Вам также может понравиться