Software Requirements Specification - KSU Web...

<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

Confidential

Revision History Date Version Description Author

18/Feb/09 1.0 Initial creation of SRS document


Confidential

Table of Contents

1. Introduction 4 1.1 Purpose 4

Acronyms and Abbreviations 1.2 Scope 4

s, s

1.3 Definition 4 1.4 Reference 4 1.5 Overview 4

2. raO ll Description 5 ve.1 2 Use‐Case Model Survey 5 2.1.1 Use‐Case #1: Manage an Event 5

n 2.1.2 Use‐Case #2: Manage a Profile 8

egistratioemplate

2.1.3 Use‐Case #3: Manage a R 10 2.1.4 Use‐Case #4: Manage a T 12

Dependencies 2.2 Assumptions and 13

3. cifSpe ic Requirements 14 quirements 3.1 External Interface Re 14

3.2 Classes/Objects 15

s 3.3 Sequence Diagrams 20 3.4 Object Collaboration Diagram 24

grams ements

3.5 Object Behavior Dia 26 3.6 Performance Requir 32 3.7 Design Constraints 32


Confidential

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: http://science.kennesaw.edu/~hhaddad/Spring2009/CS4850/CS4850_Page.htm These websites show fundamentals we will use for uGather: http://www.cvent.com/ http://www.regonline.com/

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.

http://science.kennesaw.edu/%7Ehhaddad/Spring2009/CS4850/CS4850_Page.htm

http://www.cvent.com/

http://www.regonline.com/


Confidential

2. Overall Description

2.1 UseCase Model Survey Use Case #1: Manage an Event

Diagram

Description

Use case name: Manage an Event

ID: ME

Prio ity: rhigh

Primary actor: Event Planner Secondary actor: Administrator

Source: The system requires that the enduser have the ability to create, modify, and delete the events.

Use case type: Both business and technical – all activity will take place through the system, but the event management is the primary business 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 usecase describes the events taken when the enduser 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: Ue

ser must be logged in and authenticated with a valid account. The user must be the manager of an vent 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

new one.

Relationships: ot : Extend: Manage a Template

Relationships with her usecases. Include Manage a Profile

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.



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

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 Sy tem sends the message. s

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.

l8g. Event Planner desires to delete Event. 3. Notification of deletion is sent to al Attendees.

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

Use Case #2: Manage a Profile

Diagram

Description

Use case name: Manage Profile

ID: MP

Priority: Medium

Primary actor: Event Planner Administrator Attendee

Source: Any user that needs to manipulate a profile.

Use case type: Technical


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, pr ject team member o

roje6. Zach Voss, p ct 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

Re Extend: Manage Event, Manage Registration

lationsh Relationships with other usecases. ips: Include:

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, owever in

actual use, many alternate flows or orders of actions are possible. h

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

Use Case #3: Manage a Registration

Diagram

Description

Use case name: Manage a Registration

ID: MR

Prio ity: rhigh

Primary actor: Attendee Secondary actor: Administrator, Event Planner

Source: The system requires that an Attendee to an event have the ability to sign up for events created by endusers.

Use case type: Both business and technical – all activity will take place through the system, but the event management is the primary business requirement of the project.


1. Hisham Haddad, project sponsor and instructor 2. Nathan Wilder, team leader 3. Tomas Delgado, project team member 4. 5. 6. Zach Voss, project team member

Jamie Haney, project team member Joe Spera, project team member

Brief description: This usecase describes the situation in which an enduser 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: Ur

ser must be logged in and authenticated with a valid account. The user must be attempting to egister for an active, valid event.

Trigger: This is an event that initiates the execution of the usecase.


. Include anage an Event, Manage a Profile

Confidential

Relationships: : M Extend:

Relationships with other usecases

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. N Event Planner. otification of deletion of event registration is sent to both Attendee and the

Assumptions: 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 1.

details. Implementation Constraints and Specifications:

1. User will handle financial things and more somewhere other than the website.


Confidential

Use Case #4: Manage a Template

Diagram

Description

Use case name: Manage Template

ID: MT

PMriority: edium

Primary actor: Administrator Secondary actor: Event Planner

Source: Administrator makes changes to available templates. Event Planner adds or removes components from their event template.

Use case type: Technical


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: U ser 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

event.

Relationsh Relationships with other usecases. ips: :

Extend: Include

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 Assum iopt ns and Dependencies 1. The use‐cases were built assuming a web‐based system would be used.

be a Specific technology has been avoided as much as possible, but this will 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

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 Externa n nts

l i terface requireme

1. User interfaces

• Website

• Platform indep2. Hardware interfaces

endent (operating systems)

• Com up ter i. Mouse Keyboard ii.

• Phone 3. Software interfaces

rnet Explorer, Firefox, Chrome, and Safari) • Browser Types (Inte4. Communication interfaces

• al‐up, DSL and Cable ) Internet (Di

• Phone (G3) 5. Memory constraints

• None


Confidential

3.2 Classes/Objects Class Diagram


Confidential

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

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

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

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

3.3 Sequence Diagrams Manage an Event


Confidential

Manage a Profile


Confidential

Manage a Registration


Confidential

Manage a Template


Confidential

3.4 Object Collaboration Diagrams Manage an Event object diagram

Manage a Profile object diagram

Manage a Registration object diagram


Confidential

Manage a Template object diagram


Confidential

3.5 Obj ect Behavior Diagrams

Administrator State

Attendee State


Confidential


Confidential

Event Planner State


Confidential

Event State


Confidential

Profile State


Confidential

Registration State


Confidential

Template State

3.6 Performance requirements . Web1 server that can handle the load of many users.

multiple simultaneous connections (logged users). a. Keep performance with2. No delayed actions in system a. Quick load time between pressing login button and being logged in.

any page submission and page loading. b. General quick load times for3. Compatibility with most browsers. 4. System should be able to store an adequate number of Events, Users, and Registrations.

3.7 Design constraints formation, etc.) 1. System will not handle financials (payment, credit card in

2. System will not be feature rich (due to time constraints) 3. Interface will be function over form (due to time constraints)

Software Requirements Specification - KSU Web...

Documents

Transcript of Software Requirements Specification - KSU Web...