Event Management

SOFTWARE REQUIREMENTS SPECIFICATION DOCUMENT

17.12.2015

[Misbah sajid abbasi]

SESSION: 2018 - 2020 | <NICAAS COLLEGE>
 Event Management System

Revision History
Date Description Author Comments
<date> <Version 1> <Your Name> <First Revision>

Document Approval
The following Software Requirements Specification has been accepted and approved by the following:

Signature Printed Name Title Date

Dr. Supervisor, CSIT 21306 <date>
 Event Management System

Table of Contents

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

2. The Overall Description 2

2.1 Product Perspective 3
2.1.1 Operations 3
2.1.2 Site Adaptation Requirements 3
2.2 Product Functions 4
2.3 User Characteristics 4
2.4 Design Implementation, Constraints, Assumptions and Dependencies 4

3. Specific Requirements 5
3.1 External Interface Requirements 5
3.1.1 System Interfaces 5
3.1.2 Interfaces 5
3.1.3 Hardware Interfaces 5
3.1.4 Software Interfaces 5
3.1.5 Communications Interfaces 5
3.2 Functional Requirements 6
3.2.1 <Functional Requirement or Feature #1> 6
3.3 Use Cases 6
3.3.1 Use Case #1 8
3.3.2 Use Case #2 8
3.4 Classes / Objects 9
3.4.1 <Class / Object #1> 9
3.4.2 <Class / Object #2> 9
3.5 Non-Functional Requirements 9
3.5.1 Performance 10
3.5.2 Reliability 10
3.5.3 Availability 10
3.5.4 Security 10
3.5.5 Maintainability 10
3.5.6 Portability 10
3.6 Inverse Requirements 10
3.7 Logical Database Requirements 10
3.8 Design Constraints 11
3.8.1 Standards Compliance 11
 Event Management System

4. Analysis Models 11
4.1 Sequence Diagrams 12
4.2 Data Flow Diagrams (DFD) 12
4.3 State-Transition Diagrams (STD) 13

5. Supporting Information 14
 Event Management System

1. Introduction
Event Management is the process of analyzing, planning, marketing, producing and
evaluating an event. It is a different way of promoting a product, service or idea. If
an event is managed efficiently and effectively, it can be used as a very powerful
promotional tool to launch or market a product or service.

1.1 Purpose
This System Requirement Specification (SRS) aims to provide the readers and users information
about the system and its functions and specifications.SRS describes the data, functional and
behavioral requirements of the software.
This software is designed to manage the events in the party.This will take the users requirements
for about party events According to the ures requirement it estimate how much cost are coming
in the whole event .The main purpose of it provide services related to event to the user in very
optimize cost.

1.2 Scope
The scope of this project is to develop a system that effectively manages all the data
related to the various events that take place in an organization. The purpose of “Online
Event Management System” is to provide better way to select event halls for different
events like Wedding Functions, College parties, Political Meeting etc. Online Event
Management System manages events like live shows, Birthday Events, Concerts;
Wedding Events User can see decoration of halls, style of halls and also can book them
online without going to the management office.
The system provides time efficiency as it saves a lot of time of the user because users did
not need to go outside. It also provides the reporting feature which explains the reports of
previous years and months etc. The users which involve in this system are
Administrators, Vendors and Customer.
Objective 1.2.1
Present over all event to top management.
Scheduling of Future Event.
Plan every event according to customer requirement.
Manage events according to its budget.

SRS Document 1.0 Page 1 of 9 10/09/20 f

 Event Management System

1.3 Definitions, Acronyms, and Abbreviations.

Abbreviations Definitions

SRS Software requirements specification

EMS Event Management System

HTML Hyper Text Markup Language

PHP Personal home page

CSS Cascading Style Sheet

1.5 Overview
Event management is the application of project management to the creation
and development of large-scale events such as festivals, conferences, ceremonies, weddings,
formal parties, concerts, or conventions. The events industry now includes events of all sizes
from the Olympics down to business breakfast meetings.

2. The Overall Description

Sometimes, certain events don’t get the recognition that they should. The main method of
communication for these events is via a poster or mouth to mouth. It is getting very clear
that these methods of communication are becoming more and more dated. Recently,
twitter and facebook have been shown to be more receptive in regards to communication
via a Client and the attendees. To follow this trend, this system is being implemented to
facilitate communication between the clients and the potential event-goers. As well as
provide up to the minute updates and information about the event.

2.1 Product Perspective

The software will be a new independent product, that it, it is not a component of another
program. It is intended for the administration of the management and other concerned users. The

SRS Document 1.0 Page 2 of 9 10/09/20 f

 Event Management System

product will import its data from Microsoft Access2010 database and use the Visual Basic.NET
for its integrated development environment that uses COM as programming model.

This information can only be accessed by the staff members and the manager/supervisor aside
from the developers. All the forms used in the product follows a clear and logical structure.
Errors will be minimized through the use of drop-down buttons and command buttons to
eliminate the excessive use of text input. Management of data includes searching, adding,
modifying and deleting. The product specified will be developed for Microsoft Windows XP and
Microsoft Windows 7. It does not also require any new hardware to function.

2.1.1 Operations
Specify the normal and special operations required by the user such as:
(1) The various modes of operations in the user organization
(2) Periods of interactive operations and periods of unattended operations
(3) Data processing support functions
(4) Backup and recovery operations
(Note: This is sometimes specified as part of the User Interfaces section.) If you
separate this from the UI stuff earlier, then cover business process type stuff that would
impact the design. For instance, if the company brings all their systems down at
midnight for data backup that might impact the design. These are all the work tasks that
impact the design of an application, but which might not be located in software.

2.1.2 Site Adaptation Requirements

In this section:
(1) Define the requirements for any data or initialization sequences that are specific to a
given site, mission, or operational mode
(2) Specify the site or mission-related features that should be modified to adapt the
software to a particular installation
If any modifications to the customer’s work area would be required by your system, then
document that here. For instance, “A 100Kw backup generator and 10000 BTU air
conditioning system must be installed at the user site prior to software installation”.
This could also be software-specific like, “New data tables created for this system must
be installed on the company’s existing DB server and populated prior to system
activation.” Any equipment the customer would need to buy or any software setup that
needs to be done so that your system will install and operate correctly should be
documented here.

2.2 Product Functions

Event management system is a program designed to assist managers, event organizers, firms, and
other users whose line of business deals with events management to manage their
participants’ data in an orderly manner. It shall perform the following functions:

SRS Document 1.0 Page 3 of 9 10/09/20 f

 Event Management System

 Protect the database of the firm by requiring a correct and registered username and
password. 

 Make data organization easier by classifying participants according to sub-types of

personal events. 

 Facilitate a step-by-step process of entering, organizing, retrieving, modifying and

deleting data from the database without the need to go the database itself.

 Add new client information easily.

 Provide an option for users to update information.

 Delete existing client information.

 Create new events.

 Provide an easy function where you can go back one form whenever necessary.

 Present a list of participant codes representing existing clients.

 Add new supplier contacts with which future collaboration is expected.

 Display client information in an organized manner for easy understandability.

 Display payment terms of participant including the total event fee, amounts paid by the
participants and the balance.

2.3 User Characteristics

 Event Heads:

The primary target users of this software are the Event heads. They are in-charge of scheduling
events and managing participant information, thus, they will be the most frequent users of this
software. Moreover, these people are assumed to be familiar with basic computer processes that
will enable them to use this software. Their aim in the use of this software is to access or update
existing participant information, add new participant information and make easy the billing
procedure of the participants.

SRS Document 1.0 Page 4 of 9 10/09/20 f

 Event Management System

 Event Managers:

The managers and the supervisors shall also have access to the software. They must possess
computer literacy and analytical skills so as to use the software and make good use of the
information provided by the same. They will use it in monitoring what their head has
accomplished and what still needs to be done. Furthermore, they shall also use it in times when
they want to check on a certain participant or event or when there is no staff available to attend
to a participant.

2.4 Assumptions and Dependencies

 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 s
ystem. 
 The system will be on a pre‐selected server, and must comply
with the technology and space limitations of that server.
 Additional functionality may be created, and the use-cases comprise the four
most urgent and essential bits of functionality for the system.
 A major project risk is the time constraint  there is a steady deadline, and it is most
important to get the key functionality done by then.
 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.
 All of the use-case flow being the most common or standard typical flow of use-case
events. Cases were made with the typical full functionality should be implemented for
alternate flows, since they are key features of the system.

3. Specific Requirements
This will be the largest and most important section of the SRS. The customer
requirements will be embodied within Section 2, but this section will give the D-
requirements that are used to guide the project’s software design, implementation, and
testing.
Each requirement in this section should be:
 Correct
 Traceable (both forward and backward to prior/future artifacts)
 Unambiguous
 Verifiable (i.e., testable)
 Prioritized (with respect to importance and/or stability)
 Complete
 Consistent

SRS Document 1.0 Page 5 of 9 10/09/20 f

 Event Management System

 Uniquely identifiable (usually via numbering like 3.4.5.6)

Attention should be paid to the carefully organize the requirements presented in this
section so that they may easily accessed and understood. Furthermore, this SRS is not
the software design document, therefore one should avoid the tendency to over-constrain
(and therefore design) the software project within this SRS.

3.1 External Interface Requirements

3.1.1 Interfaces
The interface of the software will provide options for a relatively easy data input processes text-
boxes that will be properly labeled. It will also have a user-friendly view of the whole system
with simple and easy undertaking of action-driven processes as command buttons are
functionally labeled. With all these, target users of this software will relatively find it not
difficult to use it.

3.1.2 Hardware Interfaces

To be able to run the system, the minimum requirements of the hardware for this system are:
 CPU 2.0 GHz or CPU (laptops) Core 2
 CPU (desktops) RAM 2 GB RAM
 HDD 60 GB min
 7200 RPM6 GB or at least 10% free space (whichever is greater)

The hardware used must have a competent firewall to secure the data in the system

3.1.3 Software Interfaces

The system was developed to serve as a database for the events' organizers. It is a stand-alone
system; hence, it does not need an internet connection. However, the system requires minimum
specifications for the software interfaces to be able to use it efficiently.

The operating system (OS) required in order to use the system is at minimum Windows XP, but
may also be Windows Vista, or Windows 7. Microsoft Visual Studio 2008 and Microsoft Office
Access 2010 must also be installed to their devices. These two application software were used to
make the database, thus, having them in the computers will make the system proceed
successfully and run error-free.

3.1.5 Commussssnications Interfaces

Communication interface is not needed as this software is a stand-alone system.

SRS Document 1.0 Page 6 of 9 10/09/20 f

 Event Management System

3.2 Functional Requirements

Registration
Description: To enter into this site user has to register himself first. Requirements of registration
are first name, last name, user name, password, email id, conform password etc.
Input: User details.
Output: Filled Registration details.
Processing : User details are checked with database. Password constraint is checked as per
validation.

User login
Description: The system provide the facility to login into the system.
Input: Enter user name and password.
Output: User profile page.
Processing: The system will check the input of the user and if valid then login is done.
Otherwise user will be asked to reenter the user name and password.

Select the event

Description: The user can select the event and also select payment method.
Input: Main event, sub event, enrollment number, add team member.
Output: Event selected successfully, see all detail and delete also.
Processing : The system will add selected data into database.

Forget password
Description: The user can send reset link to the mail to reset password.
Input: Email id.
Output: Reset link send to Email id.
Processing : By reset link we can easily change password and update store in database.

Admin panel

Description: The admin can add manager, main event, sub event also.

SRS Document 1.0 Page 7 of 9 10/09/20 f

 Event Management System

Input: Main event, sub event, manager.

Output: Add successfully in database.
Processing : The system will add selected data into database.

Manager panel
Description: The manager can add volunteer, main event, sub event also.
Input: Main event, sub event, volunteer.
Output: Add successfully in database.
Processing : The system will add selected data into database.

Logout
Description: The system provide the facility to logout from the site.
Input: Select logout option.
Output: Logout from the system.
Processing : User will logout.

SRS Document 1.0 Page 8 of 9 10/09/20 f

 Event Management System

3.3 Use Case

3.4 Classes / Objects

SRS Document 1.0 Page 9 of 9 10/09/20 f

 Event Management System

USER 1
ID
TEAM
NAME
ID
GENDER
USERNAME
CONTACT NO
PASSWORD
ENROLL NO
SELECT EVENT()
EMAIL ID
SELECT TEAM()
CONTACT ID
PAYMENT()
USER TYPE
USERNAME
PASSWORD
LOGIN()
0
EVENT
ID
EVENT NAME 1
ORGANIZATION DEPARTMENT
MANAGER ID WINNER
EVENT TYPE ID
USER ID
EVENT ID
POSITION

O 1
0 0
MANAGER
NORMAL VOLUNTEER ADMIN ID
ID ID ID USERNAME
USERNAME USERNAME USERNAME PASSWORD
PASSWORD PASSWORD PASSWORD ADD VOLUNTEER()
SELECT EVENT() PARTICEPANT() ADD VOLUNTEER() PARTICEPANT()
SELECT TEAM() TEAM DETAIL() ADD MANAGER() TEAM DETAIL()
PAYMENT() UPDATE PAYMENT() ADD EVENT() PAYMENT()
UPDATE WINNER() PARTICEPANT() WINNER()
TEAM DETAIL()
PAYMENT()
WINNER()

SRS Document 1.0 Page 10 of 9 10/09/20 f

WINNER
ID
USER ID
EVENT ID
POSITION
 Event Management System

3.5 Non-Functional Requirements

Non-functional requirements may exist for the following attributes.
3.5.1 Performance Requirements

Although the system is a simple one, a literate organizer who is able to understand simple
computer processes is needed to run the system. An organizer is one who is knowledgeable about
the ins and outs of the firm and is learned in the field of organizing events. The organizer will be
the person to enter the data needed into the system, thus an organizer needs also be efficient to
utilize fully the benefits that can be provided by this software. The system also needs MS Access
for the organizations database management system.

3.5.2 Safety Requirements                                        

Different information is entered into the database such as information about the different
caterers, suppliers and participants. Mismanagement of information might cause participant
dissatisfaction that will eventually lead to profit loss, only because of mistakes on giving
information. In line with this, the organizer should always double check which suppliers are
available.

3.5.3Security Requirements

The organizers have respective accounts with password that enables only the organizer/s to login
onto the system. Passwords are required so that no one else can access the system or database. In
the case of the administrator, he/she needs to have the adequate knowledge about maintaining
databases should the system encounter problems. Because the participants and suppliers
themselves provide the information entered into the database, there should be very little
problems about the information entered. However, the organizer should always triple check
every information given. Security systems need database storage just like many other
applications.

3.5.4Software Quality Attributes

SRS Document 1.0 Page 11 of 9 10/09/20 f

 Event Management System

Correct information must be entered into the system to prevent mismanaged conflicts to occur.
This will make the information provided by the system to be reliable and useful. However, in
case an error occurs, changes may be immediately effected provided the user notices the error.
This is why periodic monitoring and run-through of the database and the system must be done.
The target users of the system are deemed to understand basic computer processes so use of this
system will be easy for them. They will not need to undergo rigid training and instruction
in order to use the software.

3.6 Inverse Requirements

State any *useful* inverse requirements.

3.7 Logical Database Requirements

This section specifies the logical requirements for any information that is to be placed
into a database. This may include:
 Types of information used by various functions
 Frequency of use
 Accessing capabilities
 Data entities and their relationships
 Integrity constraints
 Data retention requirements
If the customer provided you with data models, those can be presented here. ER
diagrams (or static class diagrams) can be useful here to show complex data relationships.
Remember a diagram is worth a thousand words of confusing text.

3.8 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) 

3.8.1 Standards Compliance

Specify the requirements derived from existing standards or regulations. They might
include:
(1) Report format
(2) Data naming
(3) Accounting procedures
(4) Audit Tracing

SRS Document 1.0 Page 12 of 9 10/09/20 f

 Event Management System

For example, this could specify the requirement for software to trace processing activity.
Such traces are needed for some applications to meet minimum regulatory or financial
standards. An audit trace requirement may, for example, state that all changes to a
payroll database must be recorded in a trace file with before and after values.

4. Analysis Models
List all analysis models used in developing specific requirements previously given in this
SRS. Each model should include an introduction and a narrative description.
Furthermore, each model should be traceable the SRS’s requirements.

4.1 Sequence Diagrams

4.2 Data Flow Diagrams (DFD)

4.3 State-Transition Diagrams (STD)

5. Supporting Information

Appendix A – Background Research on:

 Topic 1
 Topic 2
 Topic 3
 ………
 Topic n

Appendix B – Data Dictionary

SRS Document 1.0 Page 13 of 9 10/09/20 f