<Company Name>

uGather Event Management System 
Software Requirements Specification 
 
 
Version 1.0 

 
 
uGather Event Management System Version: 1.0
Software Requirements Specification Date: 18/Feb/09
uGather SRS Document

Revision History 
Date  Version  Description  Author 
18/Feb/09  1.0  Initial creation of SRS document   
       
       
       
 

Confidential Page 2
uGather Event Management System Version: 1.0
Software Requirements Specification Date: 18/Feb/09
uGather SRS Document

Table of Contents 

1.  Introduction  4 
1.1  Purpose  4 
1.2  Scope  4 
1.3  Definitions, Acronyms and Abbreviations  4 
1.4  References  4 
1.5  Overview  4 

2.  Overall Description  5 
2.1  Use‐Case Model Survey  5 
  2.1.1      Use‐Case #1: Manage an Event  5 
  2.1.2      Use‐Case #2: Manage a Profile  8 
  2.1.3      Use‐Case #3: Manage a Registration  10 
  2.1.4      Use‐Case #4: Manage a Template  12 
2.2  Assumptions and Dependencies  13 

3.  Specific Requirements  14 

3.1  External Interface Requirements  14 
3.2  Classes/Objects  15 
3.3  Sequence Diagrams  20 
3.4  Object Collaboration Diagrams  24 
3.5  Object Behavior Diagrams  26 
3.6  Performance Requirements  32 
3.7  Design Constraints  32 

Confidential Page 3
uGather Event Management System Version: 1.0
Software Requirements Specification Date: 18/Feb/09
uGather SRS Document

Software Requirements Specification  
Software Requirements Specification  
1. Introduction 
1.1 Purpose 
The purpose of this SRS Document is to describe the behavior of the uGather system 
to be developed. This document includes the use cases that describe all of the 
interactions the users will have with the software; this includes but not limited to 
Manage Template, Manage Registration, Manage Profile and Manage Event. The 
classes include but not limited to User, Attendee, Administrator, Registration, 
Template, Event and Event Planner. 

1.2 Scope 
With uGather, a Web‐based event creation and registration system, end‐users will 
have the ability to either create or register for events at locations of their choosing, 
with management of the system falling into the uGather team’s hands. The system 
will have separate access for end‐users and the uGather team.  Added to the SRS 
Document is the specific use‐cases for uGather. 

1.3 Definitions, Acronyms and Abbreviations 
SRS: Software Requirements Specification. A detailed document listing the 
requirements for making the software described in this plan. 
SRD: Software Design Document. A detailed document listing expectations and plans 
for the design of the software described in this plan. 

1.4 References 
These documents show the course outline 
Course Website: 
[Link]
 
These websites show fundamentals we will use for uGather: 
[Link]
[Link]

1.5 Overview 
Section 2 of the SRS Document gives the overall Description. It describes the general 
factors that affect the product and its requirements. Section 3 is the Specific 
Requirements of the system. This section contains all of the software requirements 
and the use‐cases models. Also include is the different interfaces and classes used 
for the software. Section 4includes all of our table of contents, index and appendix.  

Confidential Page 4
uGather Event Management System Version: 1.0
Software Requirements Specification Date: 18/Feb/09
uGather SRS Document

2. Overall Description 
2.1 Use­Case Model Survey 
Use Case #1: Manage an Event 
Diagram 

   
Description 
Use case name:  ID:   Priority: 
Manage an Event  ME  high 
Primary actor:  Source:  Use case type:  
Event Planner  The system requires that the  Both business and technical – all activity 
  end­user have the ability to  will take place through the system, but the 
Secondary actor:  create, modify, and delete the  event management is the primary business 
Administrator  events.   requirement of the project. 
Interested Stakeholders: 
Other than the primary actor, stakeholders are: 
1. Hisham Haddad, project sponsor and instructor 
2. Nathan Wilder, team leader 
3. Tomas Delgado, project team member 
4. Jamie Haney, project team member 
5. Joe Spera, project team member 
6. Zach Voss, project team member 
Brief description:  
This use­case describes the events taken when the end­user needs to manage an event – the 
management of an event can involve the creation, modification, and deletion of an event, as well as 
management of certain event features, such as registration status.  
Precondition:   
User must be logged in and authenticated with a valid account. The user must be the manager of an 
event in order to modify and or delete the event. 
 
Trigger:   
User selects ‘Manage Events’ option, which provides the opportunity to modify an event or create a 

Confidential Page 5
uGather Event Management System Version: 1.0
Software Requirements Specification Date: 18/Feb/09
uGather SRS Document

new one. 

Relationships:    Relationships with other use­cases. 
     Include:          Manage a Profile 
     Extend:           Manage a Template 
     Depends on:  Manage a Profile 
Typical flow of events: 
1. Event Planner decides to create a new event. 
2. Event Planner’s profile is automatically uploaded for event contact information. 
3. Event Planner inputs basic event information: date(s), time(s), location(s), etc. 
4. Event Planner selects a template based on desired event, e.g. wedding. 
5. Event Planner completes all applicable template fields. 
6. Event Planner views confirmation of event details, and approves the event for 
publishing. 
7. System notifies the Event Planner of a successful registration and/or successful 
change in Event. 
8. Event Planner views event details and list of Attendees. (See alternate flow for edits.) 
9. Event Planner ends session. 
 
Alternate flow of events: 
1a. Event Planner decides they need to edit an existing event. 
1. Event Planner is authenticated as owning the event, and system follows to step 2. 
2a. Event Planner edits the information provided by default and/or adds additional information 
about themselves. 
2b. Event Planner elects to skip step 2, or does not enter any information (or changes). 
1. Move on to step 3, use existing information if applicable, default system settings otherwise. 
3a. Event Planner elects to skip step 3, or does not enter any information (or changes). 
1. Move on to step 4, use existing information if applicable, default system settings otherwise. 
4a. Event Planner elects to skip step 4, or does not enter any information (or changes). 
1. Move on to step 5, use existing information if applicable, default system settings otherwise. 
5a. Event Planner elects to skip step 5, or does not enter any information (or changes). 
1. Move on to step 5, use existing information if applicable, default system settings otherwise. 
6a. Event Planner does not confirm and approve event, wishes to start over or make changes. 
1. Move back to step 2. 
6b. Event Planner does not confirm and approve event, wishes to cancel entire process. 
1. Delete Event and all Attendees to Event if Event already exists. 
2. Notification of deletion of Event is sent to all Attendees, if they exist. 
3. Move to Step 9. 
8a. Event Planner decides to modify an Attendee. 
1. Event Planner selects an Attendee to edit. 
2. Event Planner changes registration status of Attendee, if applicable. 
3. Event Planner modifies Attendee registration, if applicable. 
4. Event Planner approves changes to Attendee registration. 
5. Notification of change is sent to Attendee. 
8b. Event Planner desires to contact an Attendee. 

Confidential Page 6
uGather Event Management System Version: 1.0
Software Requirements Specification Date: 18/Feb/09
uGather SRS Document

1. Event Planner selects a Attendee to contact. 
2. Event Planner inputs message to Attendee. 
3. Event Planner approves message, and System sends the message. 
8c. Event Planner decides to modify Attendees in mass. 
1. Event Planner selects the mass modification of Attendees option. 
2. Event Planner changes registration status of all Attendees at once. 
3. Event Planner approves changes to all Attendee registrations. 
4. Notification of changes are sent to all Attendees. 
8d. Event Planner desires to contact Attendees in mass. 
1. Event Planner selects the mass modification of Attendees option. 
2. Event Planner inputs message to Attendees. 
3. Event Planner approves message, and System sends the message. 
8e. Event Planner desires to delete an Attendee. 
1. Event Planner selects an Attendee to delete.  
2. Event Planner approves deletion of Attendee. 
3. Notification of deletion is sent to Attendee. 
8f. Event Planner desires to delete all Attendees in mass. 
1. Event Planner selects the mass deletion of Attendees option.  
2. Event Planner approves deletion of all Attendees. 
3. Notification of deletion is sent to all Attendees. 
8g. Event Planner desires to delete Event. 
1. Delete Event and all Attendees to Event. 
2. Notification of deletion of Event is sent to all Attendees. 
Assumptions: 
1. Normal flow of events assumes actions are taken in a specific order, however in 
actual use, many alternate flows or orders of actions are possible. 
Implementation Constraints and Specifications: 
1. Event Planners cannot use more than one template on a single Event, which means a 
Wedding and a Birthday, for example, may not be combined. 
2. Event locations, travel arrangements, and financial issues cannot be handled by the 
system, but may be reflected in the Attendee status area.  
 

Confidential Page 7
uGather Event Management System Version: 1.0
Software Requirements Specification Date: 18/Feb/09
uGather SRS Document

Use Case #2: Manage a Profile 
Diagram 

 
Description 
Use case name:  ID:   Priority: 
Manage Profile  MP  Medium 
Primary actor:  Source:  Use case type:  
Event Planner   Any user that needs to  Technical  
Administrator  manipulate a profile.  
Attendee 
Interested Stakeholders: 
Other than the primary actor, stakeholders are: 
1. Hisham Haddad, project sponsor and instructor 
2. Nathan Wilder, team leader 
3. Tomas Delgado, project team member 
4. Jamie Haney, project team member 
5. Joe Spera, project team member 
6. Zach Voss, project team member 
Brief description:  
The purpose of this use case is to allow users to manage their profiles. This includes changes 
that may happen to different aspects of a profile throughout the life of an event or users 
profile such as profile creation, deletion, and modification.  
Precondition:   
User must be logged in and authenticated. To edit or delete an existing profile, the profile must exist 
and belong to the registered user attempting to access it. 
 
Trigger:   
User desires to create a new profile, or to edit or delete an existing profile. 

Confidential Page 8
uGather Event Management System Version: 1.0
Software Requirements Specification Date: 18/Feb/09
uGather SRS Document

Relationships:    Relationships with other use­cases. 
     Include:           
     Extend:           Manage Event, Manage Registration 
     Depends on:   
Typical flow of events: 
1. Actor decides to create a profile. 
2. Actor starts profile by creating user name and password.  
3. System generates new user profile. 
4. System requests remaining profile information. 
5. Actor inputs basic information to complete the profile: name, address and contact 
information, or profile type. 
6. Actor submits profile to system with notification sent to edited profiles contact 
information. 
7. System sends notification of profile to new user. 
8. System presents user with confirmation of changes (views profile).  
9. Actor ends session. 
 
Alternate flow of events: 
1a.  Actor decides they need to edit an existing profile.  
1. Attendee is authenticated as having an existing profile and follows step 5. 
2. Event Planner is authenticated as having an existing profile and follows step 5.  
3. Administrator is presented with a search box to find the user to edit.   
       2a. Actor changes their mind and does not make any changes.  
1. Actor cancels their action. 
2.  System returns actor to their main screen. 
3a. Actor decides to delete their profile. 
1. Attendee is authenticated as having an existing profile and follows step 5. 
2. Event Planner is authenticated as having an existing profile and follows step 5.  
3. Administrator is presented with a search box to find the user to edit.   
4. Actor deletes profile 
5. System follows to step 8. 
       4a. Actor inputs incorrect information (system finds in step 7) 
1. Actor is presented with an error 
2. Actor is returned to step 5.  
Assumptions: 
1. Normal flow of events assumes actions are taken in a specific order, however in 
actual use, many alternate flows or orders of actions are possible. 
2. The term ‘Actor’ includes Administrator, Event Planner, or Attendee.  
Implementation Constraints and Specifications: 
1. Only Administrators can edit any profile.  
2. Event Planners can only edit the status in profiles other than their own where they 
can edit all. 
 

Confidential Page 9
uGather Event Management System Version: 1.0
Software Requirements Specification Date: 18/Feb/09
uGather SRS Document

Use Case #3: Manage a Registration 
Diagram 

 
Description 
Use case name:  ID:   Priority: 
Manage a Registration  MR  high 
Primary actor:  Source:  Use case type:  
Attendee  The system requires that an  Both business and technical – all activity 
  Attendee to an event have the  will take place through the system, but the 
Secondary actor:  ability to sign up for events  event management is the primary business 
Administrator, Event  created by end­users.  requirement of the project. 
Planner 
Interested Stakeholders: 
Other than the primary actor, stakeholders are: 
1. Hisham Haddad, project sponsor and instructor 
2. Nathan Wilder, team leader 
3. Tomas Delgado, project team member 
4. Jamie Haney, project team member 
5. Joe Spera, project team member 
6. Zach Voss, project team member 
Brief description:  
This use­case describes the situation in which an end­user desires to register for an event existing in 
the system. The primary actor is an Attendee – an Attendee is a registrant who requires the ability to 
view/find existing events, register for one, create a registration profile, and they also need the ability 
to edit and cancel/delete their registration record. 
Precondition:   
User must be logged in and authenticated with a valid account. The user must be attempting to 
register for an active, valid event. 
 
Trigger:   
This is an event that initiates the execution of the use­case. 

Confidential Page 10
uGather Event Management System Version: 1.0
Software Requirements Specification Date: 18/Feb/09
uGather SRS Document

Relationships:    Relationships with other use­cases. 
     Include:          Manage an Event, Manage a Profile 
     Extend:            
     Depends on:  Manage an Event, Manage a Profile 
Typical flow of events: 
1. Attendee decides to register for an Event. 
2. Attendee views a list of all existing, active Events in the System. 
3. Attendee selects an Event and views details for the Event. 
4. Attendee elects to register for the Event. 
5. A profile is created for the Attendee based on their existing account profile. 
6. Attendee inputs all information required by Event Planner for registration. 
7. Attendee views details of their registration and approves/confirms it. 
8. Attendee views event details, registration details, and a list of all Attendees. 
9. Attendee ends the session. 
 
Alternate flow of events: 
1a. Attendee decides they need to edit an existing registration. 
1. Attendee is authenticated as being the registration, and system follows to step 2. 
2a. Attendee wishes to find a specific event. 
1. Attendee opts to view by a certain filter (by name of Event Planner, location, Event type, etc.) 
2. Attendee views list of all existing, active Events meeting their criteria. 
4a. Event is either not open for registration, or Attendee is not permitted to register for the event. 
1. System alerts Attendee to error. 
2. System provides Attendee with a way to message the Event Planner and/or the Administrator. 
5a. Attendee edits the information provided by default and/or adds additional information about 
themselves. 
6a. Attendee does not fill in all information correctly as required by the Event Planner. 
1. System alerts Attendee to error(s). 
2. System allows Attendee to repeat Step 6. 
7a. Attendee does not confirm and approve event registration, wishes to cancel entire process. 
1. Delete event registration, if it already exists. 
2. Notification of deletion of event registration is sent to both Attendee and the Event Planner. 
7b. Attendee doest not confirm and approve event registration, wishes to start over. 
1. Return to step 5. 
8a. Attendee desires to contact the Event Planner. 
1. Attendee inputs message to Event Planner. 
2. Attendee approves message, and System sends the message. 
8b. Attendee desires to delete their event registration. 
1. Delete event registration 
2. Notification of deletion of event registration is sent to both Attendee and the Event Planner. 
Assumptions: 
1. Attendees do not need Event Planner permission to cancel a registration. 
2. Attendees do not need Event Planner permission to modify or edit their registration 
details. 
Implementation Constraints and Specifications: 
1. User will handle financial things and more somewhere other than the website. 
 

Confidential Page 11
uGather Event Management System Version: 1.0
Software Requirements Specification Date: 18/Feb/09
uGather SRS Document

Use Case #4: Manage a Template 
Diagram 

 
Description 
Use case name:  ID:   Priority: 
Manage Template  MT  Medium 
Primary actor:  Source:  Use case type:  
Administrator  Administrator makes changes  Technical  
  to available templates. Event 
Secondary actor:  Planner adds or removes 
Event Planner  components from their event 
  template.  
Interested Stakeholders: 
Other than the primary actor, stakeholders are: 
1. Hisham Haddad, project sponsor and instructor 
2. Nathan Wilder, team leader 
3. Tomas Delgado, project team member 
4. Jamie Haney, project team member 
5. Joe Spera, project team member 
6. Zach Voss, project team member 
 
Brief description:  
The purpose of this use case is to all event templates to be edited or created by Administrators and 
manipulated by Event planners. 
Precondition:   
User must be logged in and authenticated with a valid account. The user must have a profile set up.   
 
Trigger:   
This use case is triggered when a user desires to create a new event or to edit or delete an existing 

Confidential Page 12
uGather Event Management System Version: 1.0
Software Requirements Specification Date: 18/Feb/09
uGather SRS Document

event. 

Relationships:    Relationships with other use­cases. 
     Include:           
     Extend:            
     Depends on:  Manage an event 
Typical flow of events: 
1. Event Planner selects base template while creating a new event. 
2. System gives available template options for event.  
3. Event Planner selects which components for their event. 
4. System adds components to the basic event template.  
 
Alternate flow of events: 
1a.  Administrator adds available components  
4. Administrator selects the base template.  
5. System lists available components. 
6. Administrator adds to list.  
7. Administrator ends session  
       2a. Administrator removes available components  
1. Administrator selects the base template.  
2. System lists available components. 
3. Administrator deletes from the list.  
4. Administrator ends session  
3a. Administrator edit an available component 
1. Administrator selects the base template.  
2. System lists available components. 
3. Administrator edits from the list.  
4. Administrator ends session  
Assumptions: 
1. Normal flow of events assumes actions are taken in a specific order, however in actual use, 
many alternate flows or orders of actions are possible. 
Implementation Constraints and Specifications: 
2. Only Administrators can add, edit or delete a template component.  
3. Event Planners will have the ability to specify custom data sections. Custom data is the 
component.   
2.2 Assumptions and Dependencies 
1. The use‐cases were built assuming a web‐based system would be used. 
Specific technology has been avoided as much as possible, but this will be a 
web‐based system. 
2. The system will be on a pre‐selected server, and must comply with the 
technology and space limitations of that server. 
3. Additional functionality may be created, and the use‐cases comprise the four 
most urgent and essential bits of functionality for the system. 

Confidential Page 13
uGather Event Management System Version: 1.0
Software Requirements Specification Date: 18/Feb/09
uGather SRS Document

a. A major project risk is the time constraint – there’s a steady deadline, 
and it’s most important to get the key functionality done by then. 
4. None of the use‐cases can work without the others – this all part of one 
cohesive program in which classes are shared so that use‐cases may assist 
other use‐cases. 
5. There are technology limitations – both in terms of working with the server, 
and in working with what is available to us. Microsoft Project, Microsoft 
Visio, IBM Rational Architect, and MySQL, among other programs, will be 
used to assist us with the project. 
6. All of the use‐cases were made with the typical flow being the most common 
or standard typical flow of use‐case events. Full functionality should be 
implemented for alternate flows, since they are very much key features of the 
system. 

3. Specific Requirements  
3.1 External interface requirements 
 
1. User interfaces 
• Website 
• Platform independent (operating systems) 
2. Hardware interfaces 
• Computer 
i. Mouse 
ii. Keyboard 
• Phone 
3. Software interfaces 
• Browser Types (Internet Explorer, Firefox, Chrome, and Safari) 
4. Communication interfaces 
• Internet (Dial‐up, DSL and Cable ) 
• Phone (G3) 
5. Memory constraints 
• None 

Confidential Page 14
uGather Event Management System Version: 1.0
Software Requirements Specification Date: 18/Feb/09
uGather SRS Document

3.2 Classes/Objects 
Class Diagram 

 
Confidential Page 15
uGather Event Management System Version: 1.0
Software Requirements Specification Date: 18/Feb/09
uGather SRS Document

Class name: User 
Brief description: a superclass that holds all users – Administrators, Event 
Planners, and Attendees – accounts. Subclasses provide permissions. 
 
Attributes (fields)  Attribute Descriptions 
user_profile  An attribute that contains the users 
profile object. 
Methods (operations)  Method Descriptions 
Return profile form  Returns a profile form 
Authenticate user name  Authenticates the selected username 
Confirms information  User confirms profile information. 
Request profile confirmation  Requests confirmation of profile 
information. 
Display profile  System displays profile and edit options 
for user. 
Terminate session  System terminates session. 
Authenticate user  System authenticates session for user. 
 
Class name: Administrator 
Brief description: a subclass of User. Provides Administrator status. 
 
Attributes (fields)  Attribute Descriptions 
adminId  An id that provides administrator status. 
Methods (operations)  Method Descriptions 
Authenticate user  System authenticates session for 
administrator. 
Return list of events  System returns list of active events for 
Administrator 
Retrieve event details  System retrieves event details for a 
specific event. 
Request information  Request for information to be submitted. 
Confirm information  Request for information to be confirmed. 
Terminate session  System terminates session. 
 
Class name: Event Planner 
Brief description: a subclass of User. Provides Event Planner status. 
 
Attributes (fields)  Attribute Descriptions 
plannerId  An id that provides Event Planner status. 
Methods (operations)  Method Descriptions 
Display profile  System displays Event Planner profile 
with edit options. 
Authenticate user  System authenticates session. 
Create new event  Planner creates a new event. 

Confidential Page 16
uGather Event Management System Version: 1.0
Software Requirements Specification Date: 18/Feb/09
uGather SRS Document

Show available templates  System displays available templates. 
Display available components  System displays available components for 
a given template. 
Confirm template  System needs template confirmation. 
Terminate session  System terminates session. 
Confirm info  System requests confirmation of 
information. 
Confirm details  System request detail confirmation. 
Show event details  System displays event details to Event 
Planner. 
Display list of attendees  Displays a complete list of attendees (and 
options to edit) for Event. 
 
Class name: Attendee 
Brief description: a subclass of User. Provides Attendee status. 
 
Attributes (fields)  Attribute Descriptions 
aattendeeId  An id that provides Attendee status. 
Methods (operations)  Method Descriptions 
Authenticate user  System authenticates user. 
Return list of events  System provides list of events. 
Retrieve event details  System retrieves details of selected event. 
Request information  System requests information from 
Attendee. 
Confirm information  System requests confirmation of entered 
information. 
Terminate session  System terminates session. 
 
Class name: Event 
Brief description: a class that holds all information relevant to a particular Event in 
the system. 
 
Attributes (fields)  Attribute Descriptions 
template  Contains a record of the template used. 
location  Event location. 
time  Event time(s). 
date  Event date(s). 
Attendees  A container to hold all Attendees. 
title  Title of the event.  
Methods (operations)  Method Descriptions 
Store retrieved profile  Stores the retrieved profile for event 
profile information. 
Select event  Selects a specific event. 
Register for an event  Use requests to register for an event. 

Confidential Page 17
uGather Event Management System Version: 1.0
Software Requirements Specification Date: 18/Feb/09
uGather SRS Document

Add template to event  Add a template to an event. 
Input basic info  Input the basic information for an Event. 
Submit event  Submit the event for publishing. 
Request list of attendees  Request for a list of all attendees. 
 
Class name: Registration 
Brief description: a class that holds a record of a registration. 
 
Attributes (fields)  Attribute Descriptions 
registrationDetails  A container to hold registration 
information. 
registrationId  Holds a registration id. 
eventId  Holds the event id for the event the 
registration corresponds to. 
Methods (operations)  Method Descriptions 
Create registration  Creates a new event registration. 
Enter information  User enters registration information. 
View registration details  User views their registration information 
(with option to edit). 
 
Class name: Profile 
Brief description: holds a complete profile for any User in the system. 
 
Attributes (fields)  Attribute Descriptions 
status  Holds user status. 
email  Email address. 
phone  Phone number. 
name  User’s name. 
address  Full address. 
username  System username. 
password  System password. 
Methods (operations)  Method Descriptions 
Retrieve profile  Request to retrieve profile. 
Create username  User attempts to create username. 
Create password  User attempts to create password. 
Complete profile  User fills in profile information. 
Request to view profile  User wants to view their profile. 
Get profile form  System retrieves the basic profile form for 
entry. 
 
Class name: uGather 
Brief description: system class. 
 
Attributes (fields)  Attribute Descriptions 

Confidential Page 18
uGather Event Management System Version: 1.0
Software Requirements Specification Date: 18/Feb/09
uGather SRS Document

none   
Methods (operations)  Method Descriptions 
Request new profile  Request for a new profile. 
Authenticate password  System authenticates password. 
Confirm profile  System requests for profile confirmation. 
Authenticate username  System authenticates username. 
Log out  Request to log out, 
Log in  Request to log in.  
Request list of active events  Request for a list of all active events. 
Approve and notify  Approve action and send notification to 
appropriate user. 
 
Class name: Template 
Brief description: holds any given Template. 
 
Attributes (fields)  Attribute Descriptions 
details  A container to hold template details. 
type  Template type, an id. 
Methods (operations)  Method Descriptions 
Request available templates  User requests list of templates to choose 
from. 
Add components  User adds components to the Event 
template. 
Submit template  User submits the template, adds to Event. 
Select a template  User selects a specific template. 
Edit components  User edits components to a template. 
Submit changes  User confirms template, template created 
and/or added to Event. 
Complete template details  User submits a completed template file. 
 

Confidential Page 19
uGather Event Management System Version: 1.0
Software Requirements Specification Date: 18/Feb/09
uGather SRS Document

3.3 Sequence Diagrams 
Manage an Event 

Confidential Page 20
uGather Event Management System Version: 1.0
Software Requirements Specification Date: 18/Feb/09
uGather SRS Document

Manage a Profile 

Confidential Page 21
uGather Event Management System Version: 1.0
Software Requirements Specification Date: 18/Feb/09
uGather SRS Document

Manage a Registration 

Confidential Page 22
uGather Event Management System Version: 1.0
Software Requirements Specification Date: 18/Feb/09
uGather SRS Document

Manage a Template 

Confidential Page 23
uGather Event Management System Version: 1.0
Software Requirements Specification Date: 18/Feb/09
uGather SRS Document

3.4 Object Collaboration Diagrams 
Manage an Event object diagram 

 
Manage a Profile object diagram 

 
Manage a Registration object diagram 

Confidential Page 24
uGather Event Management System Version: 1.0
Software Requirements Specification Date: 18/Feb/09
uGather SRS Document

Manage a Template object diagram 

Confidential Page 25
uGather Event Management System Version: 1.0
Software Requirements Specification Date: 18/Feb/09
uGather SRS Document

3.5 Object Behavior Diagrams 
Administrator State 

 
Attendee State 

Confidential Page 26
uGather Event Management System Version: 1.0
Software Requirements Specification Date: 18/Feb/09
uGather SRS Document

Confidential Page 27
uGather Event Management System Version: 1.0
Software Requirements Specification Date: 18/Feb/09
uGather SRS Document

Event Planner State 

Confidential Page 28
uGather Event Management System Version: 1.0
Software Requirements Specification Date: 18/Feb/09
uGather SRS Document

Event State 

Confidential Page 29
uGather Event Management System Version: 1.0
Software Requirements Specification Date: 18/Feb/09
uGather SRS Document

Profile State 

Confidential Page 30
uGather Event Management System Version: 1.0
Software Requirements Specification Date: 18/Feb/09
uGather SRS Document

Registration State 

Confidential Page 31
uGather Event Management System Version: 1.0
Software Requirements Specification Date: 18/Feb/09
uGather SRS Document

Template State 

3.6 Performance requirements 
1. Web server that can handle the load of many users. 
  a. Keep performance with multiple simultaneous connections (logged users). 
2. No delayed actions in system 
  a. Quick load time between pressing login button and being logged in. 
  b. General quick load times for any page submission and page loading. 
3. Compatibility with most browsers. 
4. System should be able to store an adequate number of Events, Users, and 
Registrations. 

3.7 Design constraints 
1. System will not handle financials (payment, credit card information, etc.) 
2. System will not be feature rich (due to time constraints) 
3. Interface will be function over form (due to time constraints) 

Confidential Page 32