EventaPR Documentation

Asaan Qurban
Online Qurbani Sites
Project ID: Asaan Qurban
Project Advisor: Mr. Abrar Ahmed
Submitted By
Kainat Malik Imtiaz Kakyzai B-21023, 2017-2021

Iftikhar Gulzar B-21516, 2017-2021
Malik Afaq Nadeem B-21541, 2017-2021
University of South Asia

Department of Computer Science
Statement of acceptance
This is to certify that these students have submitted their final year project,
which the department of computer science has
accepted and evaluated. The final year project completion is one of the
mandatory requirements to be fulfilled by the students towards the
conclusion of their degree of
BS in Computer Science (BSCS).
Project ID: get this ID from the projects convener

EventaPR- Event Management System
Kainat Malik Imtiaz Kakyzai B-21023, 2017-2021

_______________________________ _________ ________________________

_ Masroor Hussain
<write adviser/supervisor's name > Projects' Convener
Project Adviser Department of Computer Science
Department of Computer Science
______________________________________
.
Proofreading Certificate
It is to certify that I have read the document meticulously and circumspectly. I am convinced that the
resultant project does not contain any spelling, punctuation or grammatical mistakes. As much as
expected from the graduating students at the bachelors’ level. All in all I find this document well
organized.
__________________________________
Mr. Abrar Ahmed

Lecturer, University of South Asia.
Acknowledgement
Most of all we thank Allah our creator and Sustainer.

Above all we thank Allah our Creator and Sustainer, for enabling and letting us to be what we are
now. We truly acknowledge the cooperation and help given by our Adviser, Mr. Hassan Bashir
Lecturer at University of South Asia. He has been a constant source of guidance throughout the
course of this project. We would also like to thank Sir Mr. Hassan Bashir Lecturer at University
of South Asia, 47 Tufail Rd, Cantt, Lahore, Punjab for their help and guidance throughout this
project. We are also thankful to our friends and families whose silent support led us to complete our
project.
Kainat Malik Imtiaz B-21023, 2017-2021
Date:
July 06, 2021
Contents
Submitted By......................................................................................................................................................1
Statement of acceptance.....................................................................................................................................2
EventaPR- Event Management System.....................................................................................................2
Proofreading Certificate..........................................................................................................................3
Acknowledgement....................................................................................................................................4
1. Introduction..............................................................................................................................................10
1.1 Abstract:................................................................................................................................................10
1.2 Project Background:.............................................................................................................................10
1.3 Project Source:......................................................................................................................................10
1.4 Project Description:..............................................................................................................................10
1.4.1 Project Objectives:............................................................................................................................10
1.4.2 Project Scope:...................................................................................................................................10
1.4.2.1 Agile Model:.....................................................................................................................................10
1.4.2.2 Scrum:...............................................................................................................................................11
1.4.2.3 Phases of Agile Model:.....................................................................................................................11
1.4.2.3.1 Requirement Gathering:................................................................................................................11
1.4.2.3.2 Design of Requirement:.................................................................................................................11
1.4.2.3.3 Construction/Iteration:...................................................................................................................12
1.4.2.3.4 Testing:..........................................................................................................................................12
1.4.2.3.5 Development:................................................................................................................................12
1.4.2.3.6 Feedback:.......................................................................................................................................12
Agile-Model Software Process................................................................................................................12
1.4.2.4 Feasibility Analysis Report:..............................................................................................................12
1.4.2.5 Technical Feasibility:........................................................................................................................13
1.4.2.6 Social feasibility:...............................................................................................................................13
1.4.2.7 Ethical feasibility:.............................................................................................................................13
1.4.2.8 Economic feasibility:........................................................................................................................13
1.4.2.9 Resource feasibility:..........................................................................................................................13
1.4.2.10 Operational feasibility:..................................................................................................................13
1.4.3 Methodology:....................................................................................................................................13
1.5 Feature:.................................................................................................................................................13
1.5.1 Admin Panel:.....................................................................................................................................13
1.5.2 Vendor Panel:....................................................................................................................................14
1.5.3 Customer/user Panel:........................................................................................................................14
1.5.4 Registration:......................................................................................................................................14
1.5.5 Location:...........................................................................................................................................14
1.5.6 Reservation:......................................................................................................................................14
1.5.7 Places:...............................................................................................................................................14
1.5.8 Categories:........................................................................................................................................14
1.5.9 Search:...............................................................................................................................................14
1.5.10 Compare the Places:..........................................................................................................................14
1.5.11 Feedback:..........................................................................................................................................14
1.5.12 Payment:............................................................................................................................................14
1.5.13 Rating:...............................................................................................................................................15
1.6 Deliverables Module of the Proposed System:.....................................................................................15
1.6.1 Manage whole Platform:...................................................................................................................15
1.6.2 Manage admin Record:.....................................................................................................................15
1.6.3 Manage all vendor’s Record:............................................................................................................15
After Registration.....................................................................................................................................15
1.6.4 Manage all user Record:...................................................................................................................16
After Registration.....................................................................................................................................16
1.6.5 Manage the whole online payment method:.....................................................................................16
1.7 Project Architecture:.............................................................................................................................16
Three Tier Architecture:..........................................................................................................................16
1.7.1 Presentation tier:...............................................................................................................................16
1.7.2 Business tier:.....................................................................................................................................16
1.7.3 Data/Database tier:............................................................................................................................16
1.8 System Architecture:............................................................................................................................17
1.8.1 System Architecture Diagram (Explanation):...................................................................................17
1.8.1.1 Front End:.........................................................................................................................................17
1.8.1.2 Back End:..........................................................................................................................................17
1.8.1.3 Internet (Server Side):.......................................................................................................................17
1.9 Tool and Technologies:........................................................................................................................18
1.9.1 Development Tool:...........................................................................................................................18
1.9.2 Hardware:..........................................................................................................................................18
1.9.3 Tools and technologies used with reasoning:...................................................................................18
1.10 Product Scope:......................................................................................................................................19
1.11 Uniqueness and Mark Impact:..............................................................................................................19
1.12 Constructive Estimation through Cocomo model:...............................................................................19
1.12.1 COCOMO models are defined for 3 classes of software projects. Using Boehm’s terminology
these are:..........................................................................................................................................................19
1.12.1.1 Organic Mode:..............................................................................................................................20
1.12.1.2 Semi-detached Mode:...................................................................................................................20
1.12.1.3 Embedded Mode:..........................................................................................................................20
1.12.2 According to Boehm, software cost estimation should be done through three stages:....................20
1.12.2.1 Basic Model:.................................................................................................................................20
1.12.2.2 Intermediate Model:......................................................................................................................20
1.12.2.3 Advanced Model:..........................................................................................................................21
Cost Drivers:....................................................................................................................................................21
2. Requirement Gathering:...........................................................................................................................25
2. System Diagrams:....................................................................................................................................69
3. Test Cases:...............................................................................................................................................73
4. Interface...................................................................................................................................................81
4.1 System Interface:..................................................................................................................................81
4.1.1 Home Page:.......................................................................................................................................81
4.1.2 Customer Signup:..............................................................................................................................82
4.1.3 Customer Login:...............................................................................................................................82
4.1.4 Vendor Signup:.................................................................................................................................82
4.1.5 Vendor Login:...................................................................................................................................83
4.1.6 Admin Login:....................................................................................................................................83
4.1.7 Admin Dashboard:............................................................................................................................84
4.1.8 Admin Mange User/Customer:.........................................................................................................84
4.1.9 Admin Manage Vendor:....................................................................................................................85
4.1.10 Admin Add Event:............................................................................................................................85
4.1.11 Admin Manage Reservation:............................................................................................................86
4.1.12 Vendor Dashboard:...........................................................................................................................86
4.1.13 Vendor Add Event:...........................................................................................................................87
4.1.14 Vendor Manage Reservation:............................................................................................................87
4.1.15 Vendor Change Reservation Payment Status:..................................................................................88
4.1.16 Vendor Chat with User/Customer:....................................................................................................88
4.1.17 Vendor Add Discount Coupons:.......................................................................................................89
4.1.18 Check Vendor Profile:......................................................................................................................89
4.1.19 Book There Event Slot:.....................................................................................................................90
4.1.20 Customer Update Profile:..................................................................................................................90
4.1.21 See Payment History:........................................................................................................................91
4.2 Mobile View Home Page:....................................................................................................................92
4.2.1 Home Page:.......................................................................................................................................92
4.2.2 Admin Login:....................................................................................................................................95
4.2.3 Customer Login:...............................................................................................................................96
4.2.4 Customer Signup:..............................................................................................................................97
4.2.5 Admin Panel:.....................................................................................................................................98
4.2.6 Vendor Dashboard:...........................................................................................................................99
6.1 Conclusion:..............................................................................................................................................102
6.2 Future work:.............................................................................................................................................102
CHAPTER 01: INTRODUCTION
1. Introduction
1.1 Abstract:
Asaan Qurban “Web-Based” software. It is a online management system that allows any person to
reserve/buy or slaughter your animal and you can also apply for aqiqah/sadqa. You can contact us
for professional Online Qasai booking. The main target that the software addresses are those people
who do not have any time to go manually for any booking and overseas Pakistani can easily perform
there Sunnah of Qurbani.
1.2 Project Background:
Unlike previous years, the trend of online booking for Eid ul Adha sacrifices has increased because of the
Covid-19 pandemic. Cattle dealers who have arranged an online booking for the purpose have increased
their prices by 20 to 25 per cent. The price for each share of sacrificial animal has also been increased.
District administrations have prohibited the setting up of cattle markets in metropolitan cities, including
Lahore, to contain the spread of the virus – a move which has led to a growing trend of online booking to
carry out the sacrificial ritual.
Subsequently, various welfare hospitals, religious schools, charitable organizations, and other institutions
have started marketing sacrificial animals on social media platforms and are inviting citizens to perform the
religious obligation through online purchases.
1.3 Project Source:
Agile is a process by which we will manage a project by breaking it up into several stages and
involving constant collaboration with stakeholders and continuous improvement and iteration at every
stage. We begin with our project description and how the end product will be used and what problem
it will solve. Once the work begins, our cycle through a process of planning, executing, and evaluating
— which might just change the final deliverable to fit the Project needs better. By completing this
project, we will be able to make people safe as it is covid-19 and people are afraid to go into crowded
areas. So, we are providing a platform to be safe at home and perform the beautiful Sunnah for our
Prophet.
1.4 Project Description:

1.4.1 Project Objectives:
The aim of our proposed system is to manage, Buying (aqiqah), Selling, Slaughter online as
well as customer can pay online in this way time is not wasted because all activities are
done online by only using mobile phone. The purpose/main objective of the project is to
build a web application program that reduce the manual work and reduce time.
1.4.2 Project Scope:
1.4.2.1 Agile Model:
We will be using Agile Model to complete this project. In the Agile model, the requirements are
decomposed into many small parts that can be incrementally developed. The Agile model adopts
Iterative development. Each incremental part is developed over an iteration. Each iteration is
intended to be small and easily manageable and that can be completed within a couple of weeks
only. At a time one iteration is planned, developed and deployed to the customers. We are using
Agile Model because Agile give us the freedom to change requirement. New changes can be
implemented at very little cost. There is a possibility that we may change our requirement or add
new things that why we are using agile model.
1.4.2.2 Scrum:
Scrum is a subset of Agile. It is a lightweight process framework for agile development, and
the most widely-used one.
Scrum is most often used to manage complex software and product development, using
iterative and incremental practices. Scrum significantly increases productivity and reduces
time to benefits relative to classic “waterfall” processes. Scrum processes enable
organizations to adjust smoothly to rapidly-changing requirements, and produce a product that
meets evolving business goals.
An agile Scrum process benefits the organization by helping it to
 Increase the quality of the deliverables
 Cope better with change (and expect the changes)
 Provide better estimates while spending less time creating themes
 Be more in control of the project schedule and state
1.4.2.3 Phases of Agile Model:
Phases of Agile model are:

1. Construction/ iteration
2. Testing/ Quality assurance
3. Deployment
4. Feedback
5. Requirements gathering
6. Design the requirements
1.4.2.3.1 Requirement Gathering:

In requirement gathering all the necessary requirements are defined. Business opportunity,
time, cost, plan and effort that are required to build the project must be explained in this
phase. Technical and economic feasibility can be evaluated that are based on all these
information.
1.4.2.3.2 Design of Requirement:
After identifying the project, work with the stakeholders to define requirements. Data Flow
Diagram and UML diagram can be used for showing the work of new features and how it
will put on the existing system.
1.4.2.3.3 Construction/Iteration:
After the overall requirement is defined by the team, the actual work begins. Coding is
started in this phase. Designers and developers start making the interface with the aim of
deploy the working product. After designing the product will go through various stages for
improvement than it will include simple and minimal functionality.
1.4.2.3.4 Testing:
In testing Phase, the Quality Assurance Team inspect the performance of the product and
fined error and bug in the product. All testing techniques are apply in this phase.
1.4.2.3.5 Development:
In deployment phase, the team issues a product for the working environment for the users.
1.4.2.3.6 Feedback:
Feedback is the last step and it is done when the product is release. The team receives the
good or bad feedback about the product and then work accordingly.
Agile-Model Software Process

1.4.2.4 Feasibility Analysis Report:
Feasibility study of our project is revolving around 7 major areas in which we have discussed all
the possibilities and aspects related to our project. To make a clear picture of all the aspects
related to our project, in the reader's mind we had done feasibility study. It should be simplified
for them to understand the abstract idea of the project.
1.4.2.5 Technical Feasibility:
It includes whether the technical resources meet the capacity or either team is capable of
completing this type of project. So during the study of technical feasibility of our project we
have found that the project will be technically feasible for the development team. All the
resources are meeting the requirements and the team’s skill meets the required criteria.
1.4.2.6 Social feasibility:
It shows the impact of projects in people’s mind. Our Team study shows that the project will be
a revolutionary product for the users. Because it will be a complete management tool for the
content of the daily business activities of different organizations and they would be able to
manage its functionality without paying any extra maintenance cost.
1.4.2.7 Ethical feasibility:
It includes the legal aspects of the project. In our project case, the major sensitive component we
will be handling is multiple users and the data should be kept safe from unauthorized access and
it should not be mixed out. Because it will be a single platform and is providing a dynamic
working environment to multiple users and their data will be handled by a single platform.
1.4.2.8 Economic feasibility:
It deals with the question of how this product will be economical to develop and how it will be
completed under reserved cost. We had studied about it thoroughly. The project will be
economical and will not demand extra cost. All we need is to arrange an optimized server to
accommodate a large number of users. And after that it demands a team of at-least two software
developers in order to develop the project.
1.4.2.9 Resource feasibility:
It deals with the study of resources that are available to develop the project. This study demands
to tally the resources, if they are enough for the successful development of project. After
studying about the resources that are required for the completion of project we have found them
enough for the successful development of our project.
1.4.2.10 Operational feasibility:
In this we have studied about the skills of our team to solve problems, face constraints and
hurdles that will be facing during the development of our project. And either we are skillful
enough to tackle these problems during the development of the project.
1.4.3 Methodology:
In this proposed system Agile Methodology is used while Scrum framework is used in it.
1.5 Feature:
1.5.1 Admin Panel:
 Manage vendors
 Send Customer to Pending state
 Active and Inactive Vendor
 Manage the customer/user active/inactive
1.5.2 Vendor Panel:

 Manage animals
 Manage orders
1.5.3 Customer/user Panel:

 Customer give request to vendor for booking
 Customer contact with vendor by phone
 Customer contact with vendor by chat
 Customer also visit place/vendor office
1.5.4 Registration:
 Vender can register their self
 Customers can register their self
1.5.5 Categories:
 Admin can add categories
 Vender can add their animals in categories
 Customers can see different animals in different categories
1.5.6 Sub-Categories:
 Admin can add sub-categories
 Vender can add their animals in sub-categories
 Customers can see different animals in different sub-categories
1.5.7 Search:
 Customers can search different animals
1.5.8 Feedback:
 Customers/User can give feedback
1.6 Deliverables Module of the Proposed System:
The deliverable modules of the proposed system are:
1. Manage whole Platform
2. Manage admin record
3. Manage all vendor’s Record
4. Manage all user Record
5. Manage the whole online payment method

1.6.1 Manage whole Project:
 Manage Admin Record
 Manage Vendors Record
 Manage User Record
 Manage Payment
1.6.2 Manage admin Panel:

 Sign up
 Create new account.
 Email confirmation via Gmail etc.
 Verified code through Phone
 Login after account is made
After Registration
 Manage vendors, customers
1.6.3 Manage all vendor:
 Sign up
After Registration
 Add animals on the website
 Manage Products/Orders
1.6.4 Manage all user Data:

After Registration
 See animals for booking
 Request for booking
 Pay online/COD
1.7 Project Architecture:

Three Tier Architecture:
Three Tier Architecture is used in it because it contains presentation, business and data layer/tier.
1.7.1 Presentation tier:

In presentation tier we can put over all the front end (GUI) because we are going to use MVC
technique to develop the project follow feature are in this tier:
 Log in form
 Sign up form
 All the button
 User site view
 Admin site view
 Vendors site view
1.7.2 Business tier:

In this tier we can put all the backend code and all other scripts that are:
 Classes
 Java script
 PHP
 CodeIgnitor
1.7.3 Data/Database tier:

In this tier we can put all thing related to database that are:
 Record of admin
 Record of vendors
 Record of client/user
 Record of all registered grounds
1.8 System Architecture:
1.8.1 System Architecture Diagram (Explanation):

The diagram we have developed to represent the system architecture of our project. In this diagram
we have divided the architecture in to three parts.
1. Front end
2. Back end
3. Internet (server side).
1.8.1.1 Front End:
The front end of the system architecture shows the pages that the user is interacting with. These
are front dynamic pages and user is interacting with that pages to perform different functions.
These dynamic pages are displaying the user related content dynamically.
1.8.1.2 Back End:

The backend of our application contains the server-side coding and logics, and this backend is
directly interacting with the front-end dynamic pages, this back end is continuously performing
the operations requested by the user and giving feedback to the user. The backend of the system
contains all the functionalities and business logic of the application. The front dynamic pages
are interacting with this end and sending requests, the backend responds to these requests and
communicate with the server side and fulfills the requests of front-end pages.
1.8.1.3 Internet (Server Side):

The server side is shown at the last, and it is directly interacting with the internet, this side
contains a central database, main server and connection with internet. Through which all these
components are interacting and performing their functionalities and keeping all the related
records in the central database. In the central database the users are entered when they perform
login, so their records are entered in the database after the signup, registration.
1.9 Tool and Technologies:
1.9.1 Development Tool:

 Adobe Photoshop/illustrator/XD
 CodeIgnitor (Backend)
 Sublime Text 3
 Xampp
 Html
 CSS
 PHP (Core-Language)
 Java Script
 Bootstrap
 SQL
1.9.2 Hardware:
 CSS
 PHP (Core-Language)
 Java Script
1.9.3 Tools and technologies used with reasoning:

Development of Asaan Qurban would require frontend using HTML, CSS (for front end
development for the better iteration of animation) and backend development in
CodeIgnitor (Backend) .The reasons for using these tools are listed here under:
• Development of Asaan Qurban would be on codeignitor as it had good MVC
structure, better in routing, has custom security features, libraries in codeignitor
could be used for customization and it will also streamlined with database and API
integration.
• PHP would be the core language of the platform.
• For graphical illustrations Photoshop and illustrator would be used in producing an eye-
catching front end.
• Team of the Asaan Qurban would be distributed in the tasks of not only on the development
of the web-application. But also participating in venturing the business and business
development.
• Budget of this web-application is segregated among following factors:
o Development cost
o Marketing cost
o Designing cost
o Maintenance cost
1.10 Product Scope:

This platform provides an easy approach and almost free of cost for registration. It’s a time efficient
project because you don’t had to go through different places for information all you need is a mobile
phone and you get all information by sitting at home. The people will have no need to pay for anything
for using this application. A Person with less knowledge of using a smartphone can easily use this
website/application because it is user-friendly.
1.11 Uniqueness and Mark Impact:

This software is unique because it connects all ground, lawn, pools, stadium, etc. together at one place.
There is no single platform available in our society where you can check different type of services
regarding sports and events with a single click. Unlike HAP- Event Booking application that only
provides places where events occurs but not provide sports places. EventaPR provides the facility of all
stadium for sports as well as all events like birthdays, weddings etc. reservation online. Developing this
product will reduce time that is wasted by going manually. This project can be useable for Business
Purposes. So users/customers can easily find the place for the event or sports and also find comparison
between them according to their needs.
1.12 Constructive Estimation through Cocomo model:

Cocomo model is used for the cost consequences of the decision made in commissioning,
developing and supporting a software product. It is one of the most generally used software
estimation models in the world. COCOMO predicts the efforts and schedule of a software product
based on the size of the software.
The key boundary that defines the quality of any software products that are also a result of the
Cocomo are primarily Effort & Schedule:
 Effort:
The amount of labor that will be required to complete a task is known as effort. It is measured in
person-months units.
 Schedule:
The amount of time required for the completion of the job, which is, of course, proportional to
the effort put is known as schedule. It is measured in the units of time such as weeks, months.
1.12.1 COCOMO models are defined for 3 classes of software projects.
Using Boehm’s terminology these are:
1. Organic Mode.
2. Semi-detached Mode.
3. Embedded Mode.
1.12.1.1 Organic Mode:
Project that deals with developing a well-understood application program, the size of the
development team is reasonably small, and the team members are experienced in developing
similar methods of projects than the project is organic mode
1.12.1.2 Semi-detached Mode:
Projects with Intermediate (medium sized teams) that consists of both experienced and
inexperienced members. Members may have some or limited experience of similar systems
or may be unfamiliar with some aspects of the current system. Neither large nor small
projects (medium). This type of project is known as Semi-Detached mode
1.12.1.3 Embedded Mode:
Projects that are relatively large sized and where difficulties are expected. The project in
which the software being developed is strongly coupled to complex hardware, software and
operational constraints. These type of project is known as embedded mode.
1.12.2 According to Boehm, software cost estimation should be done through

three stages:
1. Basic Model
2. Intermediate Model
3. Advanced Model
1.12.2.1 Basic Model:
It computes software development effort as a function of program size. Program size is

expressed in DSI.
MM = a X (KDSI)b
Tdev = c X (MM)d
1.12.2.2 Intermediate Model:

It computes software development effort as a function of program size and a set of cost
drivers that includes subjective assessment of product, project attributes etc
MM = a X (KDSI)b X EAF
Tdev = c X (MM)d
1.12.2.3 Advanced Model:
This model incorporates all characteristics of the intermediate version with an assessment of
the cost driver’s impact on each phase distribution of the software engineering process.
Value of a,b,c,d are calculated from the above table:
Project Mode A b C D
Organic 2.4 1.05 2.5 0.38
Semi-detached 3.0 1.12 2.5 0.25
Embedded 3.6 1.20 2.5 0.32
Cost Drivers:
Characteristics Level Factor
Required Software Reliability High 1.15
Database Size High 1.08
Product Complexity Normal 1
Execution Time Constraints Normal 1
Main Storage Constraints Normal 1
Virtual Machine Volatility High 1.3
Computer Turn-Around Time Normal 1
Analyst Capability Normal 1
Application Experience Normal 1
Programmer Capability Normal 1
Virtual Machine Experience High 0.9
Programming Language Experience High 0.95
Use of Modern Programming Practices High 0.91
Use of Software Tools High 0.91
Required Development Schedule Normal 1
Module Size (KDSI)
Registration
Collecting data for a new login account 0.4

Saving the data of all login accounts 0.2
Separate fields in database for each user 0.4
Reliable and efficient server for fast processing 0.2
Booking System
Request to Register Place 0.4
Request Accept 0.3
Request Reject 0.2
Request for Booking of an Event 0.4
Request Accept 0.3
Request Reject 0.2
Get Current Location 0.5
Visit the Place 0.4
Total KDSI 3.9
Our project is Intermediate Semi-Detached mode because it contains cost drivers and database.
Project Effort:
Person Month(MM):
Tdev = c X (MM)d
a = 3.0, b = 1.12
c = 2.5, d = 0.25
KDSI = 3.9
EAF = 1.14
MM= 3.0(3.9)1.12 (1.14)
MM = 15.7
Time Duration:
Tdev = c X (MM)d
Tdev = 2.5 (15.7)0.25

Tdev = 4.9
So the project duration will be 5 months
Team Size:
Team Size = MM/ Tdev
Team Size = 15.7/4.9
Team Size = 3.2
So the Team Size (people required) are 3
Development Cost:
Developer rate = 100 per hour
Number of developer = 3
Cost = 3 * 160 * 100 = 48000
Total Development Cost = 48000 * 5
Total Development Cost = 240000

CHAPTER 02: Requirement Gathering
2. Requirement Gathering:
In Requirement Gathering we collect Requirement that are required for our project
2.1 Requirement Gathering:

For the process of gathering requirement we conduct interviews, questionnaires. We interview
many people especially those who are very busy in their routine and had no time to go for booking.
We also give them some Questionnaires and after getting their answer we got many information
that are very useful for the project. We also gather requirements by doing a meeting with some
software houses and with some sports clubs and societies
After the interview with people and did meetings with some companies we get some useful
requirements which we divide as functional and non-functional requirements as follow:
2.2 Functional Requirement:

Functional requirements are:
1. Log in to the system as admin
2. Approve, disapprove vendors, customers
3. Add places
4. Add Event Category
5. Approve/disapprove event reservation
6. Update payment status
7. Log in to the system as vendor
8. Click on add places option
9. Add event categories for reservations
10. Approve/disapprove event reservation
11. Add previous event arrangement for user facility
12. Add Price etc.
13. Add Rating option
14. Reply to message by customer
15. Log in to the system as user
16. Choose place
17. Review the place you choose.
18. Reserve the ground
19. Request can be approved by vendors
20. Message to vendor, admin
21. After request approved provide payment details
22. Give Ratings
2.3 NON-Functional Requirement:
Non-functional requirement are:
1. Security
2. Compatibility
3. Usability
4. Performance
5. Quick Response
6. Robustness
7. Reliability
8. Maintainability
9. Language
10. User Friendly GUI
2.4 Use Case:
SIGN UP
<<include>>
LOGIN IN
Admin <<include>>
<<extend>>
Approve
<<include>> Invalid
<<extend>> <<extend>>
Vendor Customer
<<include>> Customer/User
Manage
<<extend>>
Event Category
<<extend>> <<include>>
<<extend>>
City
Vendor
Location Event
Select
Event Category
Event
Reserve an Event
Status of Reservation
Payment
Coupan
By Cash Online
Pay out Request
Recieve Payment
Status of Payout Request
Rating
Message
Reply to message
2.4.1 UC_01:
Fig
ure 2.5.1 UC- Admin-Login
ID: UC-01
Title: Admin-Login
Description: Admin login himself in system.
Level Admin Goal.
Primary Actors: Admin
Actor: Secondary Actors:
Stakeholders Admin: wants to login his account in the system to open his dashboard
and Interests: to manage system.
Pre-conditions: Must have the internet connection.
Post-conditions: User login himself successfully.
Main Success Admin opens login page.
Scenario: Admin can enters his username and password information.
Admin can submits login form.
Admin receives ‘success message’.
Extensions: Admin enters wrong username and require password.
System prompts that admin entered wrong input and asks admin to enter
password again.
2.4.2 UC_02:
Figure 2.5.2 UC- Approval

ID: UC-02
Title: Approval
Description: Admin can check request.
Level Admin Goal.
Actor: Secondary Actors: Customer, Vendor
and Interests: to manage systems
Pre-conditions: Vender must add his personal account information.
Customer must add his personal account information.
Post-conditions: Vender can successfully add their place.
Customer can successfully reserve event
Main Success Admin check details of the vendors.
Scenario: Admin check details of the customers.
Extensions: Vendor does not enter complete information.
Customers does not enter complete information.
2.4.3 UC_03:
Figure 2.5.3 UC- Status

ID: UC_03
Title: Status
Description: Admin change the status of vendor and customer.
Level Admin Goal.
Actor: Secondary Actors: Customer, Vendor
Stakeholders Admin can check the status and change the status of customer and
and Interests: vendor
Pre-conditions: Vendor must add the details
Customers must add the details.
Post-conditions: Vendor and add Event.
Customer can reserve event
Main Success Admin can change the status
Scenario:
Extensions: There is not a vendor.
There is not a customer.
2.4.4 UC_04:
Figure 2.5.4 UC-Dashboard

ID: UC_04
Title: Dashboard
Description: Admin edit information and status of vendors and users.
Level Administrator control.
Stakeholders Admin: Admin can view activity, approve, reject and edit the
and Interests: information and status of the vendors and users add category add city
location.
Pre-conditions: Admin must be login.
Post-conditions: Admin can successfully view activity, approve, reject and edit the
information and status of the vendors and users add category add city
location.
Main Success Admin can successfully view activities that held in system.
Scenario:
Extensions:
Admin cannot logged in.
2.4.5 UC_05:
Figure 2.5.5 UC-Edit

ID: UC_05
Title: Edit
Description: Admin manage users and vendors.
Level Admin Goal.
Stakeholders Admin can edit the status of reservation
and Interests:
Pre-conditions: There is must be a record for editing
Post-conditions: Admin can successfully edit the reservation.
Main Success Admin can view and edit the reservations
Scenario:
Extensions:
There is no record for edit.
2.4.6 UC_06:
Figure 2.5.6 UC-Coupon

\
ID: UC_06
Title: Coupon
Description: Admin can add the coupon information
Level Admin Goal.
Actor: Secondary Actors: Customer
Stakeholders
and Interests: Admin/Customer: Customer can use coupon for getting discount.
Pre-conditions: Customer must have coupon.

Admin have to add the details of coupon.
Post-conditions: Customer can successfully add the coupon and get discount.
Main Success Admin can get for customer as they deliver coupons for advertising.
Scenario:
Extensions: Admin have to add the details of coupon.
2.4.7 UC_07:
Figure 2.5.7 UC-City
ID: UC_07
Title: City
Description: Admin can add new city
Level User Goal.
Stakeholders
Admin/Customer: Admin have more customer from different cities.
and Interests: Customers can select more city as their choice.
Pre-conditions: Admin must have the information about the city
Post-conditions: Admin successfully add the city
Main Success Customers can select more city as their choice.
Scenario: Admin get more customers from more cities
Extensions:
Admin didn’t have the city information.
2.4.8 UC_08:
Figure 2.5.8 UC-Event
ID: UC_08
Title: Event
Description: Admin can add new event
Level Admin Goal.
Stakeholders
Admin/Customer: Admin have more customer from different event.
and Interests: Customers can select more event as their choice.
Pre-conditions: Admin must have the information about the event
Post-conditions: Admin successfully add the event
Main Success Customers can select more event as their choice.
Scenario: Admin get more customers from more event.
Extensions:
2.4.9 UC_09:
Figure 2.5.8 UC-Location
ID: UC_09
Title: Location
Description: Admin can add new location
Level Admin Goal.
Stakeholders
Admin/Customer: Admin have more customer from different locations.
and Interests: Customers can view more location as their choice.
Pre-conditions: Admin must have the information about the new location
Post-conditions: Admin successfully add the new location
Main Success Customers can view more location as their choice.
Scenario: Admin get more customers from more locations
Extensions:
Admin didn’t have the information of new location.
2.4.10 UC_10:
Figure 2.5.8 UC-Payment
ID: UC_10
Title: Payment
Description: Admin can get payment
Level Admin Goal.
Actor: Secondary Actors: Customer/Vendor
Stakeholders
Admin/Customer/Vendor: Admin get their commission.
and Interests:
Pre-conditions: Customer must have pay the reservation bill
Post-conditions: Admin successfully get payment
Main Success Customers can select more city as their choice.
Scenario: Admin get more customers from more cities
Extensions:
2.4.11 UC_11:
Figure 2.5.8 UC-Event Category
ID: UC_07
Title: Event Category
Description: Admin can add new event category.
Level User Goal.
Stakeholders
Admin/Customer: Admin have more customer from different event
and Interests:
category. Customers can select more category as their choice.
Pre-conditions: Admin must have the information about the new event category
Post-conditions: Admin successfully add the event category
Main Success Customers can select more event category according their choice.
Scenario: Admin get more customers from more category
Extensions:
Admin didn’t have the event category information.
2.4.12 UC_12:
Figure 2.5.8 UC-Message
ID: UC_07
Title: Message
Description: Admin can reply the message of customer
Level User Goal.
Stakeholders
Admin/Customer: admin and customer can chat with each other.
and Interests:
Pre-conditions: Admin must have logged in their account
Vendor must have logged in their account
Post-conditions: Admin successfully reply to the customer
Main Success Customer can contract with admin for getting information
Scenario:
Extensions:
Customer and cant not be logged in.
2.4.13 UC_13:
Figure 2.5.8 UC-Vendor Signup
ID: UC_13
Title: Vendor Signup
Description: Vendor can register their self.
Level Vendor Goal.
Primary Actors: Vendor
Stakeholders Vendor: Vendor wants to register his account in the application to
and Interests: create his workspace to manage projects.
Pre-conditions: Vendor must have to connect with internet.
Post-conditions: Vendor can registered successfully.
Main Success Vendor opens signup page.
Scenario: Vendor can enters his username and password information.
Vendor can submits signup form.
Vendor receives ‘success message.
Extensions: Vendor enters wrong email and require password.
System prompts that user entered wrong input and asks user to enter again.
Vendor email is already registered.
System prompts that user’s email is already registered and asks him to re-
enter different email.
2.4.14 UC_14:
Figure 2.5.8 UC-Vendor Login
ID: UC-14
Title: Vendor Login
Description: Vendor can login himself
Level Vendor Goal.
and Interests: to manage system.
Post-conditions: User login himself successfully.
Main Success Admin opens login page.
Scenario: Admin can enters his username and password information.
Admin can submits login form.
Admin receives ‘success message’.
Extensions: Admin enters wrong username and require password.
password again.
2.4.15 UC_15:
Figure 2.5.8 UC-Select City
ID: UC_15
Title: Select City
Description: Vendor can select city while adding event.
Level Vendor Goal.
Stakeholders Vendor: Vendor can add their place in different Cities.
and Interests:
Pre-conditions: Admin can provide the multiple cities
Post-conditions: Vendor can select city successfully.
Main Success More vendor can interact with system.
Scenario: Because site have more cities options.
Extensions: Admin cannot allow more cities.
2.4.16 UC_16:
Figure 2.5.8 UC-Category
ID: UC_16
Title: Select Event Category
Description: Vendor can select category while adding event.
Level Vendor Goal.
Stakeholders Vendor: Vendor can add their place in different category.
and Interests:
Pre-conditions: Admin can provide the multiple category.
Post-conditions: Vendor can select category successfully.
Main Success More vendor can interact with system.
Scenario: Because site have more category options.
Extensions: Admin cannot allow more category.
2.4.17 UC_17:
Figure 2.5.8 UC-Manage Event
ID: UC_17
Title: Manage Event
Description: Vendor can manage the event.
Level Vendor Goal.
Primary Actors: User
Stakeholders Vendor can manage the dashboard.
and Interests:
Pre-conditions: Vendor must have login account.
Post-conditions: Vendor can manage everything successfully.
Main Success Vendor get right of managing their system/dashboard.
Scenario:
Extensions: Vendor cannot be logged in.
2.4.18 UC_18:
ID: UC_18
Title: Coupon
Description: Vendor can add the coupon information
Level Vendor Goal.
Stakeholders
and Interests: Admin/Customer: Customer can use coupon for getting discount.
Vendor have to add the details of coupon.
Main Success Vendor can get for customer as they deliver coupons for advertising.
Scenario:
Extensions: Vendor have to add the details of coupon.
2.4.19 UC_19:
ID: UC_19
Title: Message
Description: Vendor can reply the message
Level Vendor Goal.
Stakeholders
Admin/Customer: Vendor can chat with Customer.
and
Interests:
Pre-conditions: Customer can send the message first.
Post-conditions: Vendor can reply successfully
Main Success Customers can chat with admin.
Scenario: Vendor can reply the message
Extensions:
Customer can send message to admin.
2.4.20 UC_20:
Figure 2.5.8 UC- Customer Signup

ID: UC_20
Title: Customer Signup
Description: Customer can register their self.
Level Customer Goal.
Primary Actors: Customer
Stakeholders Customer wants to register his account in the application to create his
and Interests: workspace to manage projects.
Pre-conditions: Customer must have to connect with internet.
Post-conditions: Customer can registered successfully.
Main Success Customer opens signup page.
Scenario: Customer can enters his username and password information.
Customer can submits signup form.
Customer receives ‘success message.
Extensions: Customer enters wrong email and require password.
System prompts that user entered wrong input and asks user to enter again.
Customer email is already registered.
System prompts that user’s email is already registered and asks him to re-
enter different email.
2.4.21 UC_21:
Figure 2.5.8 UC- Customer Login

ID: UC_21
Title: Customer Login
Description: Customer can login himself
Stakeholders Customer wants to login his account in the system to open his
and Interests: dashboard to manage system.
Post-conditions: Customer login himself successfully.
Main Success Customer opens login page.
Scenario: Customer can enters his username and password information.
Customer can submits login form.
Customer receives ‘success message’.
Extensions: Customer enters wrong username and require password.

password again.
2.4.22 UC_22:
Figure 2.5.8 UC-Browse City
ID: UC_22
Title: Browse City
Description: Manager/engineer creates partial domain model.
Stakeholders Use can select their entire city.
and Interests:
Pre-conditions: User must made internet connection.
Post-conditions: Customer can successfully browse city.
Main Success City can be browsed by the customer easily
Scenario:
Extensions: Customer didn’t want to browse the city
2.4.23 UC_23:
Figure 2.5.8 UC-Rating

ID: UC_23
Title: Browse Location
Description: Manager/engineer creates partial domain model.
Stakeholders Use can select their entire location.
and Interests:
Pre-conditions: User must made internet connection.
Post-conditions: Customer can successfully browse location.
Main Success Location can be browsed by the customer easily
Scenario:
Extensions: Customer didn’t want to browse the city
2.4.24 UC_24:
Figure 2.5.8 UC-Select Event Category

ID: UC_24
Title: Select Event Category
Description: Customer can select category while adding event.
Stakeholders Customer can find their place in different category.
and Interests:
Pre-conditions: Customer can provide the multiple category.
Post-conditions: Customer can select category successfully.
Main Success More customer can interact with system.
Scenario: Because site have more category options.
Extensions: Admin cannot allow more category.
© University of South Asia.

2.4.25 UC_25:

ID: UC_25
Title: Coupon
Description: Customer can add the coupon information
Actor: Secondary Actors: Vendor
Stakeholders
and Interests: Customer can use coupon for getting discount.
Vendor have to add the details of coupon.
Main Success Customer can reserve more places because of coupon code.
Scenario:
Extensions: Vendor didn’t have to add the details of coupon.

2.4.26 UC_26:
Figure 2.5.8 UC-Category

ID: UC_26
Title: Payment
Description: Customer can pay payment
Actor: Secondary Actors: Vendor/Admin
Stakeholders
Customer/Vendor: Admin and vendor get their payments.
and
Interests:
Pre-conditions: Customer must have reserve the place for event
Post-conditions: Customer successfully pay payment
Main Success Admin get their commission.
Scenario: Vendor get their payment
Extensions:
Customer must have to pay the reservation bill.

2.4.27 UC_27:

ID: UC_27
Title: Message
Description: Customer can reply the message
Actor: Secondary Actors: Vender
Stakeholders
Admin/Customer: Customer can chat with vendor.
and
Interests:
Pre-conditions: Customer can send the message first.
Post-conditions: Vendor can reply successfully
Main Success Vendor can reply the message
Scenario:
Extensions:
Customer can send message to admin.
2.4.28 UC_28:

Figure 2.5.8 UC-Reserve Event
ID: UC_28
Title: Reserve Event
Description: Customer can reserve event according to their need.
Stakeholders Customer can get reserve event.
and Interests:
Pre-conditions: Customer must be logged in.
Post-conditions: Customer can reserve successfully.
Main Success More customer can interact with system.
Scenario: And reserve more events.
Extensions: There is must be a place for reservation.
2.4.29 UC_29:
Figure 2.5.8 UC-Rating

ID: UC_29
Title: Rating
Description: Customer can give rating.
Actor: Secondary Actors: Vendor
Stakeholders Customer give rating.
and Interests:

Pre-conditions: Customer can must be logged in.
Post-conditions: Customer can successfully give rating.
Main Success Customer can give rating to vendor
Scenario:
Extensions: Customer didn’t logged in.
1.1 Sequence Diagram:

Admin Vendor Customer Login City Event Event Coupon Payment Database
Category
Attempt login Verify Login
Login Successful Verification
Update Successful
Manage City
Database
Show Updated Database
data Update Updated
Manage Event
Category Show Updated Database
Database
data Updated
Manage Event Update
Show Updated Database Database
Manage data Updated
Update
Coupon Database Database
Show Updated
Updated
data Update
Manage
Payment Database Database
Show Updated
Manage data Updated
Update
Vendor Database
data Updated
Manage Update
Customer Database
Database
Show Updated
Updated
data

Vendor Login City Event Event
Coupon Payment Database
Category
Attempt login Verify Login
Update Successful
Select City
Database
Select Event data Update Updated
Database
data Updated
Finalize Post and Update
Manage Events Show Updated Database Database
Manage data Updated
Update
Coupons Database Database
Coupons Detail
Updated
Request Update
Payment Database Database
Request Status Updated
Event
Customer Login City CategoryEvent Coupon Payment Rating Database
Attempt login
Verify Login
Update Successful
Select City
Database
Select Event data Update Updated
Database
data Updated
Make Update
Reservation Reservation Database Database
Add Coupons Status Updated
Update
Code Database Database
Coupons Status
Updated
Update
Database Database
Receipt
Update Updated
Gives Rating Database
Gives Rating
Show Rating Database
Updated
1.1.1 SD-1:

Admin Vendor User System Database
Attempt login
Authentication
Return
Attempt login
Response
Return
Attempt login
Return
1.1.2 SD-2:
Admin Event Database
Manage Event
Update Database
Updates completed
Database
Show Updated Updated
Data
1.1.3 SD-3:
Admin Event Category Database
Manage Event
Category Update Database
Updates completed
Database
Data

1.1.4 SD-4:
Admin Customer Database
Manage
Customer Update Database
Updates completed
Database
Data
1.1.5 SD-5:
Admin Vendor Database
Manage Vendor
Update Database
Updates completed
Database
Data
1.1.6 SD-6:
Admin Coupon Database
Manage
Coupon Update Database
Updates completed
Database
Data

1.1.7 SD-7
Admin Payment Database
Manage
Payment Update Database
Updates completed
Database
Data
1.1.8 SD-8:
Admin Payout Request Database
Manage
Updates completed
Database
Data
1.1.9 SD-9:
Admin PayoutCity
Request Database
Manage
Manage City
Updates completed
Database
Data

1.1.10SD-10:
Vendor Event Database
Manage Event
Update Database
Updates completed
Database
Data
1.1.11SD-11:
Vendor Event Category Database
Manage Event
Category Update Database
Updates completed
Database
Data
1.1.12SD-12:
Vendor Coupon Database
Manage
Coupon Update Database
Updates completed
Database
Data

1.1.13SD-13:
Vendor Payout Request Database
Request Payout
Update Database
Updates completed
Database
Request Updated
Generated
1.1.14SD-14:
Vendor Reservation Database
Manage
Reservation Update Database
Updates completed
Database
Data
1.1.15SD-15:
Customer Reservation Database
Event Reservation
Request Update Database
Updates completed
Database
Wait For Updated
Response

1.1.16SD-16:
Customer Coupon Database
Enter Coupon
Code Update Database
Updates completed
Database
Wait for Updated
Response
1.1.17SD-17:
Customer Payment Database
Make Payment
Update Database
Updates completed
Database
Payment Status Updated
Updated
1.1.18SD-18:
Customer Rating Database
Give Rating
Update Database
Updates completed
Database
Rating done Updated

1.2 Data Flow Diagram:
1.2.1 Level-0:
Admin
Vendor
EventaPR
Customer

1.2.2 Level-1:
Login
Response
Admin
City Info
Updated
Event Info Coupon info
Response Updated
Updated
Event info
Vendor
Payment
Update Status
Request Payment
Coupon info Make Payment
Response
Register / Login
EventaPr
Response
Response Register / Login
Reservation
Response
Rating
Added
Add Coupon Code
Customer Response
Request Payment
Make Payment

1.2.3 Level-2:
Add / View / Delete Coupon
Coupon
Admin Updated
Add / View / Delete Event Category
Add / View / Delete Event Category
Done
Updated Vendor
Payment
Event Category Update Status Add / View / Delete Coupon
Updated
Register Account EventaPr Approve / Disapprove
Approve / Disapprove Register Account

Gives Rating Update Status
Rated
Request Payment Event Request
Make Payment
Add Coupon code
Receive Coupon
Customer Reserve Event Payment

Approve / Disapprove / Pending

CHAPTER 03: Design

2. System Diagrams:
2.1 Class Diagram:

2.2 Entity Relation Diagram:

2.3 Domain:

CHAPTER 04: Test Cases

3. Test Cases:
3.1 TC-1:
Test Critical
priority
ID TC-1
Use case Register Account
name
Actor Vendor
Pre- Website should be open and internet connection should be
condition working.
Post- Vender will be able to add event and other activity after
condition registration.
S. No Test Expected Actual Status
stage result result
1 Open website After clicking As expected Pass
and click to registration
register page page should be
open
2 Add details User is able to As expected Pass
enter personal
details in the
text boxes.
3 Press Submit After pressing As expected Pass
Button submit button,
personal details
are entering.
3.2 TC-2:
Test Critical
priority
ID TC-2
Use case Login Account
name
Actor Vendor
condition working.
Post- The dashboard will be opened to the user for further activity
condition and processing.
stage result result
1 Enter user Vendor should As expected Pass
name and is able to enter
password. user name and
password.
2 Click log-in By clicking on As expected Pass

button log-in button
the main page is
opening for the
user
3.3 TC-3:
Test Critical
priority
ID TC-3
Use case Vendor Dashboard
name
Actor Vendor
Pre- Vendor dashboard should be open and vendor should be
condition interactive with interface
Post- Vender will be able to add event and perform other activity.
condition
stage result result
1 Add new After clicking As expected Pass
Event add event
button page
should be open
and add details
2 Manage Event After clicking As expected Pass
manage event
button page
should be open
and manage
events
3 Manage After clicking As expected Pass
Reservation manage
reservation
button page
should be open
and manage
reservation

3.4 TC-4:
Test Critical
priority
ID TC-4
Use case Logout Vendor Account
name
Actor Vendor
Pre- Vendor dashboard should be opened and vendor should be
Post- By logging out of portal, website should be closed and back to
condition login page
stage result result
1 Click on log By clicking log As expected Pass
out button out button the
website is
closed.
2 Website Vendor As expected Pass
should be redirects to
closed login page
3.5 TC-5:
Test Critical
priority
ID TC-5
Use case Admin Login
name
Actor Admin
condition working.
Post- Admin will be able to manage dashboard after logged in.
condition
stage result result
1 Enter user Admin should As expected Pass
name and able to enter
password. user name and
password.
2 Click log-in By clicking on As expected Pass
button log-in button
the main page is
opening for the
user

3.6 TC-6:
Test Critical
priority
ID TC-6
Use case Admin Logout
name
Actor Admin
Pre- Admin dashboard should be opened and admin should be
stage result result
website is
closed.
closed login page
3.7 TC-7:
Test Critical
priority
ID TC-7
Use case Admin Dashboard
name
Actor Admin
Pre- Admin dashboard should be opened
condition
Post- Admin will be able to manage dashboard after logged in.
condition
stage result result
1 Add new After clicking As expected Pass
Event add event
button page
should be open
and add details
2 Manage Event After clicking As expected Pass
manage event
button page
should be open
and manage
events

Reservation manage
reservation
button page
should be open
and manage
reservation
Customer manage
customer button
page should be
open and
manage
customer status
Vendor manage vendor
button page
should be open
and manage
Vendor status
Payout- manage payout-
Request request button
page should be
open and check
requests.
3.8 TC-8:
Test Critical
priority
ID TC-8
Use case Register User Account
name
Actor User
condition working.
Post- User will be able to book event and do other activity after
condition registration.
stage result result
1 Open website After clicking As expected Pass
and click to registration
register page page should be
open
2 Add details User is able to As expected Pass
enter personal
details in the
text boxes.
3 Press Submit After pressing As expected Pass
Button submit button,
personal details
are entering.
3.9 TC-9:
Test Critical
priority
ID TC-9
Use case Logout User Account
name
Actor User
Pre- User dashboard should be opened and vendor should be
stage result result
website is
closed.
closed login page
3.10 TC-10:
Test Critical
priority
ID TC-10
Use case User Account Profile
name
Actor User
Pre- User account should be opened
condition
Post- User will be able to book event chat with vendor check history.
condition
stage result result
1 Book new After clicking As expected Pass
event Book your even
button page
should be open
and user can

book event
2 Chat with After clicking As expected Pass
vendors message button
page should be
open and user
can start with
vendors
3 Check history After clicking As expected Pass
payment history
button page
should be open
and user can
view history

CHAPTER 05: IMPLEMENTATION

4. Interface
4.1 System Interface:
4.1.1 Home Page:

4.1.2 Customer Signup:
4.1.3 Customer Login:
4.1.4 Vendor Signup:

4.1.5 Vendor Login:
4.1.6 Admin Login:

4.1.7 Admin Dashboard:
4.1.8 Admin Mange User/Customer:

4.1.9 Admin Manage Vendor:
4.1.10Admin Add Event:

4.1.11Admin Manage Reservation:
4.1.12Vendor Dashboard:

4.1.13Vendor Add Event:
4.1.14Vendor Manage Reservation:

4.1.15Vendor Change Reservation Payment Status:
4.1.16Vendor Chat with User/Customer:

4.1.17Vendor Add Discount Coupons:
4.1.18Check Vendor Profile:

4.1.19Book There Event Slot:
4.1.20Customer Update Profile:

4.1.21See Payment History:

4.2 Mobile View Home Page:
4.2.1 Home Page:

4.2.2 Admin Login:

4.2.3 Customer Login:

4.2.4 Customer Signup:

4.2.5 Admin Panel:

4.2.6 Vendor Dashboard:

CHAPTER 06: CONCLUSION

6.1 Conclusion:
EventaPR is an Event Reservation System. It’s a Web Application based system in
which any person can reserve ground, lawns, pools, marquees etc. for any event
near or far from its home online. User can also see previous events pictures, and can
pay online. We used Scrum Agile Methodology and COCOMO Model for the cost
estimation. We used different tools and technologies for the making of this project.
It’s will become very useful for any person as well as for clubs, society and for the
person who had ground or lawns.
6.2 Future work:
In Future we will add all sports facilities like different sports memberships. We will
organize tournaments, customers can see all the dates of the tournament and will be
participate by filling information form online and then they can participate on the
tournament in the stadium, ground.

NO PLAGIARISM AND FAIR PLAY DECLARATION
We the group members of the FYP titled “EventaPR”
Understand the meaning and consequences of the act of plagiarism in academic
works and we do solemnly declare and promise not to indulge ourselves directly or
indirectly in any acts of plagiarism and/or use or misuse of any work done by other
parties, or any activities that are considered miss-appropriate by the project
advisers/supervisors and/or considered to be illegal by the regulations of any kind;
unless of course permitted by our project adviser/supervisor that is within legal
bounds and is/are deemed necessary by them.
Our project and product(s) are unique, bear quality and are not a repetition or copy
of any previous project(s).We declare that we will produce work that is genuine
,innovative and reflective of all the study that we had as the students of university of
south Asia.
We promise to follow the schedule during which we shall seek feedback and
maintain a liaison with our adviser. We understand that any foul-play or
infringement on our part will result in the cancellation of our project and possibly
other penalties may be imposed upon us.
Our project efforts and the end-product are safe, harmless and helpful to humans
and society.
SIGNED.
B-21498 Aniqa Mujahid Signature:
email: b-21498@student.usa.edu.pk
Cell: 0320- 9435663 Session: 2017-21, FYP20-16-21498
Res: H # 136, M-block Johar Town LahoreSIGNED.
B-21572 Muhammad Sabtain Shakeel Signature:
email: sabtain.shakeel07@gmail.com
Cell: 0337-0435328 Session: 2017-21, FYP20-16-21572
Res: House no 24/D 1-A DhowlanWal Band Road Lahore.
SIGNED.
B-21592 Sameer Amir Signature:
email: b-21592@student.usa.edu.pk
Cell: 0345-6314417 Session: 2017-21, FYP17-21-21592
Res: Malik Pur Sharaqpur, Tehsil Sharaqpur, District Sheikhupura
Project Adviser Mr. Hassan Bashir Signature:

Mr. Masroor Hussain Mr. Illyas Butt
Projects convener HOD CS Department

EventaPR Documentation

Uploaded by

Copyright:

Available Formats

You might also like

EventaPR Documentation

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

EventaPR Documentation

Uploaded by

Copyright:

Available Formats

Asaan Qurban

Online Qurbani Sites

Project ID: Asaan Qurban

Project Advisor: Mr. Abrar Ahmed

Kainat Malik Imtiaz Kakyzai B-21023, 2017-2021

University of South Asia

BS in Computer Science (BSCS).

Project ID: get this ID from the projects convener

Kainat Malik Imtiaz Kakyzai B-21023, 2017-2021

_______________________________ _________ ________________________

Mr. Abrar Ahmed

Most of all we thank Allah our creator and Sustainer.

1.2 Project Background:

1.3 Project Source:

1.4 Project Description:

1.4.2.3 Phases of Agile Model:

Phases of Agile model are:

1.4.2.3.1 Requirement Gathering:

Agile-Model Software Process

1.5.2 Vendor Panel:

1.5.3 Customer/user Panel:

1.6 Deliverables Module of the Proposed System:

The deliverable modules of the proposed system are:

1. Manage whole Platform

2. Manage admin record

3. Manage all vendor’s Record

4. Manage all user Record

5. Manage the whole online payment method

1.6.2 Manage admin Panel:

1.6.3 Manage all vendor:

1.6.4 Manage all user Data:

 Create new account.

1.7 Project Architecture:

1.7.1 Presentation tier:

1.7.2 Business tier:

1.7.3 Data/Database tier:

1.8.1 System Architecture Diagram (Explanation):

1.8.1.2 Back End:

1.8.1.3 Internet (Server Side):

1.9 Tool and Technologies:

1.9.1 Development Tool:

1.9.3 Tools and technologies used with reasoning:

1.10 Product Scope:

1.11 Uniqueness and Mark Impact:

1.12 Constructive Estimation through Cocomo model:

1.12.1.1 Organic Mode:

1.12.1.2 Semi-detached Mode:

1.12.1.3 Embedded Mode:

1.12.2 According to Boehm, software cost estimation should be done through

1.12.2.1 Basic Model:

It computes software development effort as a function of program size. Program size is

1.12.2.2 Intermediate Model:

Collecting data for a new login account 0.4

Separate fields in database for each user 0.4

Reliable and efficient server for fast processing 0.2

Request to Register Place 0.4

Request Accept 0.3

Request Reject 0.2

Request for Booking of an Event 0.4

___________________________ _ ____________________