ORGANIZATION OF AN EVENT

Group Members:

Maria Zakria (BITF20M008)

Roheen Zainab (BITF20M037)

Software Requirements Specification (SRS)

Document

Deliverable 1
Table of contents
1. Business requirements
1.1Background
1.2Business opportunity
1.3Business objectives
1.4Success metrics
1.5Vision statement
1.6Business risks
1.7Business assumptions and dependencies

2. Scope and limitations

2.1Major features
2.2Scope of initial release
2.3Scope of subsequent release
2.4Limitations and exclusions

3. Business content
3.1Stakeholders profiles
3.2Project priorities
3.3Deployment considerations

4. Context diagram
5. Ecosystem map
6. Feature tree
7. Event list
 1. Business requirements:

1.1 Background:
The aim is to introduce a system in the market for the ease of users to access all the event
organizing entities from a single platform. As the online services are quite common in some
developed areas that helps people a lot to book their orders in short time from their busy
schedules, so the aim is to provide such a facility in some nascent areas also, letting people
free from the hectic manual procedure of venues' bookings.

1.2 Business opportunity:

The system will improve online services' experience of users. The system will provide the user
with a much better interface and other facilities rather than any other online system. It will
freed the user from hectic manual processing. It would also give the market recognition to the
system that will definitely result in a huge income.

1.3 Business objectives:

The key objective is to open all the venues', restaurants and other catering services' doors for
the people's ease from a single platform. System is supposed to lower the booking costs by 20-
25% in the next 1 to 2 years to invite more customers by registering more and more venues.
And to increase the system's market repute and share by efficient performance in the next 5
years

1.4 Success metrics:

1-Attendee engagement
2-Feedback forms
3-Number of registrations
4-Ratings

1.5 Vision statement:

This System is the one that would provide indoor, outdoor event organizing facility by taking
bookings online via a web-based system for the people who want to place their orders online.
Unlike the current manual ordering systems, our system will provide services from a single
platform. i.e a lot of venues and catering services will be offered from a single platform.
1.6 Business risks:

1-Data privacy and online security risks

2-Unauthorized access to the accounts
3-Delete data due to human error

1.7 Business assumptions and dependencies:

Dependencies:
Following are the tools / technologies, on which our system depends for its completion,
Programming language: C++
Front-End: HTML, CSS
Hardware interface: 512 MB RAM, WINDOWS 7/8
Database: My SQL Server
Tools: Visual Studio

Assumptions:
1. The client will be able to see available time slots for an event online.
2. Most of the people will have internet connection to approach our web
application.
3. Most of the people will visit our website which are interested to see an
event.
4. Online user will be able to get the information like timing slots, packages etc.
of different halls.
5. User will be able to search any wedding lawn by name and have full access to
information of relevant marriage hall/wedding lawn.
6. User may be facilitating for online payment.
7. If a user follows the profile of a wedding lawn or a marriage hall he/she
may get the recent notifications through their mobile number.
 2. Scope and limitations:
2.1 Major features:

This system would have the following features:

 Registration of customer:
Registration of customer by creation of an account.

 Schedule of venues:
Display of welcome page and complete schedule of venues and all the offers being offered by
the system.

 System’s previous services:

Visual display of system's previous services.

 Display of all options:

Display of all options through which customer can place, review and cancel order.

 Accessibility of Manager:
Manager's accessibility to the data of customer, bank and venues.

 Event updation:
Event updation and monthly record's access to the manager and venue head.

 Rating of the system:

A visual display of the rating of the system (how many customers have already been facilitated)
to the new customer.

 Display of pictures and videos:

Display of pictures and videos of all the venues and available restaurants for indoor catering
services.

 File a complaint:
Display of contact details of the manager and option to file a complaint.

2.2 Scope of initial release:

On the initial stages of release, the system will only take bookings for indoor event organization
from the user.
 2.3 Scope of subsequent release:
Then the system will register venues and other catering services to facilitate user in a broader
way.

2.4 Limitations and exclusions:

The limitations and exclusions for our system are following:

1) The system will receive orders at least 10 days before the event.
2) It will be compulsory for the venue organizers to make sure the availability of their venues
as per schedule and not to take any manual booking at that time slots.
3) After 12 hours of cancellation request, the customer will not be able to replace that
order.
4) The application will not work without internet service.

3. Business content:

3.1 Stakeholders profiles:

Stakeholders:

Stakeholders are the ones who are directly or indirectly involved in using the system. The
stakeholders of our system are given below:

Primary Stakeholders:

The primary stakeholders for our system would be:

1. Client
2. Venue's owners and organizers
3. System manager
4. Bank
Secondary Stakeholders:

They are indirectly affected by the business of the system. Secondary stakeholders for this
system would be:
1. Hosting community ( Decor team)
 2. Restaurant owners
3. End users

3.2 Project priorities:

1. All the data in the system should be secured and can only be
accessed by authorized people.
2. System should generate a monthly report depicting the monthly customer's record.
3. The system should be able to ask the reason of cancellation to the customers who
would cancel their orders later.
4. Customer is allowed to review the cancellation request within 12 hours, failure to
review the request will result in automatic cancellation.
5. All the strong entities must have access to the bank's details.
6. Booking confirmation and payment details should be sent to users at
their given contact number.
7. System should display accurate monthly orders forecast so that the
resources can be managed accordingly.
8. System should also give the language options to its users.

3.3 Deployment Considerations:

As this project is online web-based application so we must be followed the
following five steps during deployment steps:
Step1: Preparation
The three general ideas for this website application deployment are.

 The client has nothing (i.e. this is their first website)

 The client already has hosting, and you will be deploying the site on their
 server
 The client already has hosting, but you will be moving to a new server
Step2: Setup DNS records
Step 3: Set Up Email Accounts
Developers deploying a website often overlook email, but it will be a priority to
the client. Does your client have mail hosted on their old server? Are you moving
their email?
Step 4: Backup and Go Live
Deployment checklist:

 Have access to DNS record management or know the people to contact

 Set up the DNS records and make sure that all the settings are correct
 Set up and test the website on the production server (where it will live)
 Set up email
 Back up the old site (if applicable) and deploy the new on

Context diagram:

Schedule,budget,venue Registration
details details,schedule Venue
Client Organizer

Account number,
Approved venue ID,client’s details

Payment Event
approval of decoration
Verification Organization
Bank Decor
System Team
Account number, decoration details
Payment draft

Selected venue client’s details

Venue details

Manager

Ecosystem Map:
 Venue
Client
Organizing
System

Booking Details

Event
Account Number Organization Schedule Database
Bank
System

Database Database

Client’s details

Decorating
Management Confirmation Decor
Team

Feature tree:
F
T ran st er Make
Bank Payment Customer a complain / Enter query

Register
Receive
Login/sian I
Update ■amount
Up /
Monthly. from client Make
record • View recent account
research '
Provide Cheek Approval
receipt Change order
dclailSj/

Place Order
View Enter event detail

detail

Receive client"s
payment
Login

Number of events
managed / Provide schedule
Make Final Schedule

Monthly records
Profit/Loss Instruct about event \\
Payment management
Venue
organizer

Receive Venue
details Get ID
Heads decor team

Manager Take final reports Venue Register

Event List:
Event list for customer:
Sign up by customer
Customer selects schedule and places order
Customer's request for viewing order goes outdated
Customer cancels the order
Customer enters the complain

Event list for organizer:

Sign up by venue organizer
Organizer uploads venue schedule
Organizer receives payments

Event list for organizer:

Sign up by the manager
Manager receives client’s proposals
Manager receives venue details
Manager approves customer’s orders
Manager makes final schedule
Manager maintains monthly records

Event list for bank:

Bank manager signups to the system
Bank manager transfer payments to the system
Bank manager updates monthly records of the system