Riphah Eventor

Faculty of Computing
Riphah International University, Islamabad
Spring/Fall 2022

1
 Chapter:1
Introduction

2
Chapter 1: Introduction
1.1 Background
In Riphah International University there is no such existing platform where students can
be notified about different events held in university on time. All of the work being done
is manual and students have to appear physically for an event registration. Faculty, Head
of department and Organizers cannot communicate in an efficient manner to inform about
various events. There is no calendar of events presented where anyone can view it. Due
to this, clashes appear while booking of events. There is no mechanism of feedback after
an event. There is no existing mechanism where we can do analysis on the success rate of
an event via reports. No common platform is present for uploading and downloading
event-based documents.

1.2 Stakeholders and Opportunity:

Stakeholders:

• Admin

• Head of department

• Organizer

• Attendee

Opportunity:

Event management is one of the major issues often seen in different institutions. This
problem is also observed in Riphah International University. There should be a
platform to help Head of department to manage future events properly. A common
coordination platform should be there for Head of department, Students, and Event
Organizer. It is a system to handle events properly. The work done manually is not as
much efficient as if there were a platform where event records can be handled
efficiently. Students should be informed about an event efficiently and registration
should be easy. Event feedback can help organizers for creating future events and
organizer can create online events.

3
1.3 Motivation and Challenges
Currently there is no system for Event Management in Riphah international university
(Main Campus I-14). Our aim is to provide an exclusive system to Head of department to
facilitate the Students, Organizers and Faculty. The very first thing that motivated us was
that this idea will facilitate our Faculty of computing department in our university from
Organizers to Attendees. In Riphah International university events manage manually its
time consuming to register an attendee. The main challenge for us that we are going to
provide Faculty of computing Department an entire system in which there will be an
event calendar, previous history, Feedback option and mainly it will notify for upcoming
events. Head of department will get ease to do work on a system instead manually.

1.4 Goals and objectives

This project aims to create an automated system that will facilitate Head of department
their activities and other stakeholders. The main goal of this system is that manual work
will be replaced by an automated system. It will provide ease and a detection of
upcoming events to every user. Goal is to make online system to create events, register
event and calendar is to notify everyone about upcoming events. The main thing which is
very necessary after an attended event is its feedback. The purpose of launching this
system is to help everyone in one platform where they can communicate each other. To
develop a web application, we will follow some aspects mention below.

 Create events, registered in events through online web application

 Auto generated calendar notify others for upcoming events.
 Feedback should be given by the attendant of the system.
 Payment status should be shown on the system after giving the payment.

4
1.5 Solution overview

To create the system for Riphah International University. This system provides the
facilities to Head of Department, Organizers and Attendee. In this system Admin
manages Head of Department, Organizers and Attendees. Students can give feedback
through reviews after an event. Stakeholders can communicate efficiently about various
events. This platform can give real-time notification through Email/SMS. An organizer
can create various events and generate event reports. Attendees can register online. This
system is effective and saves time for the user
There are four users:

1. Admin

2. Head of Department (HOD)

3. Organizer

4. Attendee

1. Admin

 Register the Organizer

 Register the Head of Department.
 Login on the system.
 Manage profile
 Manage users
2. Organizer
 Create event.
 Upload event report
 View event calendar
 View feedback of any event
 Send notification.
 Manage profile.

5
3. Attendee
 View events.
 Register for events.
 View notification.
 Give feedback.
 Manage profile
4. Head of Department (HOD)

 Manage profile
 View events
 Approve event
 View event calendar.
 View feedback of any event.
 View event reports.
 View notifications

6
 Chapter 3:
Requirement Analysis

Chapter 3: Requirement Analysis

3.1 Introduction
This chapter includes the requirements of the system, illustrating the problem statement,
functional requirements, and non-functional requirement, covering the scope of the
project.

7
3.2 Problem Scenario

Mostly there is no such existing platform where students can be notified about different
events on time. In Riphah International University all events are managed manually.
There is no mechanism where give feedback after an event and real-time notifications can
be sent through Email/SMS. Stakeholders cannot communicate efficiently about various
events. In Riphah there is no such type of system where attendees can register online and
reports are generated at the end of the event.

3.3 Functional Requirements

Functional Requirements defines a function of a system and its

components. Following are the functional requirements of the system:

FR-1: Registration:
FR-1.1 Admin and Attendee shall be able to register in the system.
FR-1.2 Admin shall be able to register Head of Department and Organizer through Email
and password.
FR-2: Login:
FR-2.1 Admin, Head of Department, Organizer, and Attendees shall be able to login on
to the system through Email and password.
FR-3: Manage Users:
FR-3.1 Admin shall be able to add user through Email and password.
FR-3.2 Admin shall be able to delete user .
FR-4: Manage profile:

FR-4.1 Admin shall be able to create and update the profile through Name, Contact
number, Address, Country and State.
FR-4.2 Head of Department shall be able to create and update the profile through Name,
Contact number, Address, Country and State.
FR-4.3 Organizer shall be able to create and update the profile through Name, Contact
number, Address, Country and State.

8
FR-4.4 Attendees shall be able to create and update the profile through Name, Contact
number, Address, Country and State.
FR-5: Create Event:
FR-5.1 Organizer shall be able to request to organize the event.
FR-5.2 Organizer shall be able to fill an event form through Category, Name, Start date,
End date, Maximum attendee, Entry fee, Guest name, Start time, End time and Venue
name.
FR-6: Approve Event:
FR-6.1 Head of Department shall be able to view event request, approve and reject event
and notify the organizer.
FR-7: View Calendar:
FR-7.1 Head of Department, Organizer, and Attendees shall be able to view the event
calendar.
FR-8 View archive Event:
FR-8.1 Head of Department, Organizer, and Attendees shall be able to view the past
events.
FR-8.2 Head of Department, Organizer and Attendees shall be able to view the report of
the past event.
FR-8.3 Head of Department, Organizer and Attendees shall be able to view the feedback.
FR-9: Give Feedback:
FR-9.1 Attendee shall be able to give feedback on attended events.
FR-10: Event Report:
FR-10.1 Organizer shall be able to create event reports.
FR-10.2 Organizer shall be able to download the report.
FR-11: Notifications:
FR-11.1 Head of Department, Organizer and Attendee shall be able to view notification.
FR-11.2 System shall be able to send confirmation notifications about status approval to
organizer.
FR-11.3 System shall be able to send notifications about the event through Email to
attendee.

9
FR-11.4 System shall be able to send notifications about the approve event request
through Email to Hod.
FR-12: Register event:
FR-12.1 Attendees shall be able to register in new events through User name, Email,
First name, Last name and User role.
FR-12.2 Organizer shall be able to update payment status
FR-12.3 System prompt user to download Voucher.

3.4 Non-Functional Requirements

A non-functional requirement is a requirement that specifies criteria that can be used to
judge the operation of the system, rather than specific behavior. Following are the non-
functional requirement of the system we selected from McCall’s Quality Model in terms
of:
3.4.1 Availability
AVA-1: Users can use all of the services at any time he/she needs.
3.4.2 Interoperability
INT-1: Users can use web services through any browser he/she uses (Google Chrome,
Firefox, Internet Explorer, etc.)
3.4.3 Usability
USA-1: The system shall be able to give appropriate feedback on any action performed
by user (click, processing etc.).
USA-2: All the buttons on every page have relevant and meaningful names and show
error messages on incorrect action.
USA-3: System provide about us page and contact us page. Every page has relevant title.

10
 Chapter 4:
System Design

11
Chapter 4: System Design
4.1 Introduction
After requirement analysis, elicitation system design and architecture are very important
for better understanding and implementation of the system. This chapter covers the high
level design details including the system use-case diagram, use case specification using
fully dressed format, enhanced entity-relationship diagram, system sequence diagram,
activity diagram, deployment diagram and level Architecture diagram.

Unlike requirement analysis, where focus is on "What", the design use to focus on
"How" part of the system. This chapter includes all the high level and low-level design
details of the software.

4.2 Functional Models

Functional Modeling gives the process perspective of the object-oriented analysis model
and an overview of what the system is supposed to do. It defines the function of the
internal processes in the system. It represents the functional derivation of the data values
without indicating how they are derived when they are computed, or why they need to
be computed.

12
4.2.1 Use case diagram:
Admin:

5: Figure 4.2.1.1 Admin Use Case Diagram

13
Attendee:

6: Figure 4.2.1.2 Attendee Use Case Diagram

14
Organizer:

7: Figure 4.2.1.3 Organizer Use Case Diagram

15
HOD:

8: Figure 4.2.1.4 HOD Use Case Diagram

16
4.2.2 Fully Dressed Use case:
Registration:

UC-ID UC-1
Use Case Name Registration
Scope Riphah Eventor
Level User Goal

Primary Actor Admin, Attendees

Stakeholders and Interests Admin and Attendees wants to register in order to login
in to the system

Pre-Conditions Admin and Attendees must be Go to the Signup page.

Post-Condition User must be logged in to the system.

Main Success Scenario 1) Website prompts the signup page.

2) User enter his/her name.

3) User enter his/her Email.

4) User enter his/her Password.

5) User press “Create Account” button.

6) Account is Successfully created.

Alternative flow 2a. If user enter invalid name.

1-System displays an error message “Enter valid name”
3a. If user enter invalid email address
1-System displays an error message “Enter valid email
Address”
4a. If user enter invalid password.

17
 1- System display an error message “ Enter valid
password”
Technical requirement Internet connection required.

Frequency of occurrence: Low

Table 2: 4.2.2.1 Use case Registration

Login:

UC-ID UC-2
Use Case Name Log In
Scope Riphah Eventor
Level User Goal

Primary Actor Head of Department, Organizer, Attendees

Stakeholders and Interests Admin, Head of Department, Organizer, Attendees

wants to login in order to create or manage the events
and perform other tasks
Pre-Conditions Admin, Head of Department, Organizer, Attendees must
be registered.

Post-Condition User must be Go to the Home page.

Main Success Scenario 1) User Go to the login page.

2) User enter his Email

3) User enter his Password.

4) User press “LOGIN” button.

5) User successfully Go to Home Page.

18
Alternative flow 2a. If user enter invalid Email address.
1-System displays an error message “Enter valid Email
address”
2b. If user doesn’t enter Email.
1- System displays an error message “Email is required”
3a. If user enter invalid password.
1-System displays an error message “Enter valid
password”
3b. If user doesn’t enter Password.
1- System displays an error message “Password is
required”

Technical requirement Internet connection required.

Frequency of occurrence: Medium

Table 3: 4.2.2.2 Use case Login

Manage Users:

UC-ID UC-03

Use Case Name Manage users

Scope Riphah Eventor

Level User goal

Primary Actors Admin

Stakeholders and interests Admin: Admin can add and delete Head of
Department and Organizer.

Pre-Conditions Admin shall be able logged in to the system.

19
Post-Conditions Admin shall be able to manage users into the system.

Main Success Scenario

1- Admin must be able to add users.

2- Admin click “Add” button

3- Admin approve Email and Password

4- Admin click “Save” button

5- Admin must be able to delete users.

6- Admin click “Delete” button

7- Admin select the user and click the “Delete” button

Alternative Admin fails to register Head of department and Organizer

because of following factors:
3a. If user doesn’t enter Email
1-System display an error message “Email is
required”.
3b. If user doesn’t enter Password
1-System display an error message “Password is
required”.
7a. If admin doesn’t select the user
1-System display an error message “select the user”

Technical Requirements Internet connection required

20
Frequency of Occurrence Medium

Table 4: 4.2.2.3 Use case Manage users

Manage profile:

UC-ID UC-04

Use Case Name Manage Profile

Scope Riphah Eventor

Level User goal

Primary Actors Admin, Head of Department, Organizer, Attendees

Stakeholders and interests Head of Department, Organizer, Attendees: He/she want

to manage the profile through Name, Contact number,
Address, Country and State.

Pre-Conditions User must be Go to manage profile page.

Post-Conditions Head of department, Organizer and attendees shall

be able to manage his profile.

Main Success Scenario 1- User click on manage profile option

2-User can change his/her Name, Contact number,
Address, Country and State.
3-User click “update” button
4-Successfully update
Alternative flow 2a. If user doesn’t fill all the filed
1-System display the error message “please fill the filed”

Technical Requirements Internet connection required

Frequency of Occurrence Once or twice a year.

Table 5: 4.2.2.4 Use case Manage profile

21
Register Event:
UC-ID UC-5

Use Case Name Register Event

Scope Riphah Eventor

Level User goal

Primary Actors Attendees

Stakeholders and interests Attendees: Attendees wants to register himself in events.

Pre-Conditions Attendees select the event

Post-Condition Attendees registered in the vent.

Main Success Scenario 1) Attendees view the events

2) Attendee selects the desired event displayed by the

system and press button “Register Event”.

3) Then click “Register Event” button.

4) System displays “Registered Successfully”.

Alternative flow Attendees fails to register event because of following

factors:
2a. If Attendee doesn’t select the desired event
1-System display the error message “please select the
event”

Technical Requirements Internet connection required

Frequency of Occurrence Could be nearly continuous.

Table 6: 4.2.2.5 Use case Register Event

22
View Calendar:

UC-ID UC-6

Use Case Name View Calendar

Scope Riphah Eventor

Level User goal

Primary Actors Head of Department, Organizer, Attendees

Stakeholders and interests Head of Department, Organizer, Attendees: He/she wants to

view event calendar in order to get information about upcoming
events.

Pre-Conditions Head of Department, Organizer, Attendees must be logged in to

the system

Post-Condition Head of Department, Organizer, Attendees view the calendar

Main scenario 1- User click the event calendar button

2- User view the event calendar

Alternative User fails to view event calendar because of following factors:

2a. If user is not able to view the calendar
1- User doesn’t click the event calendar button

Technical Requirements Internet connection required

Frequency of Occurrence Nearly continuous.

Table 7: 4.2.2.6 Use case View Calendar

View Archive Event:

UC-ID UC-7

Use Case Name View Archive Event

23
Scope Riphah Eventor

Level User goal

Primary Actors Head of Department, Organizer, Attendees

Stakeholders and interests Head of Department, Organizer, Attendees: User wants

to view Feedback, view past reports, view past events.

Pre-Conditions User select the archive event option

Post-Condition User viewed archive event.

Main Success Scenario 1) User click the feedback option

2) User view the feedback

3) User click the reports option

4) User view the reports

5) Users click the events option

6) User view the events

Alternative User fails to View archive event because of following

factors:

1a. If user doesn’t click the feedback option

1- User doesn’t view the feedback
3a. If user doesn’t click the report option
1- User doesn’t view the report
5a. If user doesn’t click the event option
1- User doesn’t view the events

Technical Requirements Internet connection required

24
Frequency of Occurrence Medium

Table 8: 4.2.2.7 Use case View archive event

View Notification:
UC-ID UC-8

Use Case Name view notification

Scope Riphah Eventor

Level User goal

Primary Actors Head of Department, Organizer, Attendees

Stakeholders and interests Head of Department, Organizer, Attendees: User wants

to get notification from system.

Pre-Conditions User must be click the Notification button.

Post-Condition User view the notifications.

Main Success Scenario 1) User selects option “Notifications”.

2) System displays notifications to the user.

3) User view the Notifications.

Alternative User fails to register event because of following factors:

1a-If user doesn’t click the Notification option
1-User doesn’t view the Notifications.

Technical Requirements Internet connection required.

Frequency of Occurrence Medium

Table 9: 4.2.2.8 Use case View Notification

25
Give Feedback:
UC-ID UC-09

Use Case Name Give Feedback

Scope Riphah Eventor

Level User goal

Primary Actors Attendees

Stakeholders and interests Attendees: Attendees wants to give feedback about an event
through this system.

Pre-Conditions Attendees must be registered in event.

Post-Condition Attendees gives feedback about events.

Main Success Scenario 1) Attendee select events

2) Attendee selects “Feedback” option.

3) Attendee gives feedback.

4) Attendee clicks “Feedback” button.

Alternative Attendees fails to give feedback because of following

factors:
2a. If Attendee does not click Feedback option.
1-Attendees cannot give feedback
3a. If Attendee doesn’t enter the comment in the field
1- System show error message “ fill the field”.
Technical Requirements Internet connection required.

Frequency of Occurrence Medium

Table 10: 4.2.2.9 Use case Give Feedback

26
Create Event:
UC-ID UC-10

Use Case Name Create Event

Scope Riphah Eventor

Level User goal

Primary Actors Organizer

Stakeholders and interests Organizer: Organizer wants to create events.

Pre-Conditions Organizer must be able to click the create event button.

Post-Condition Organizer created the event

Main Success Scenario

1) Organizer selects “Create event option”.

2) User fill the form through Category, Name, Start date,

End date, Maximum attendee, Entry fee, Guest name,
Start time, End time and Venue name.

3) Organizer click “Create event” button.

Alternative Organizer fails to create and send event proposal because of

following factors:
2a-If Organizer doesn’t fill all the fields in the form
1- System display error message fill all the fields.

Technical Requirements Internet connection required.

Frequency of Occurrence High

Table 11: 4.2.2.10 Use case Create Event

27
Event Report:
UC-ID UC-11

Use Case Name Event Report

Scope Riphah Eventor

Level User goal

Primary Actors Organizer

Stakeholders and interests Organizer: Organizer wants to create and download

Event Report.

Pre-Conditions Organizer must be able to click the create report option,

download report option.

Post-Condition Event report is successfully create and download by the

Organizer.

Main Success Scenario 1) Organizer click “create event report” button.

2) Organizer fill the details of event report through Name,

description and press “create report” button.

3) System display message “Report Created” Successfully

4) Organizer clicks “Download event report” button.

5) Organizer view the reports

6) Organizer select “Download Report” button

7) System display message “Report Downloaded”

Successfully.

Alternative Organizer fails to generate and download event report

because of following factors:
1a. If organizer does not fill all the fields
1- System display the error message

28
 6a. If organizer does not click the download report option
1- System doesn’t download the report.
Technical Requirements Internet connection required.

Frequency of Occurrence Medium

Table 12: 4.2.2.11 Use case Event Report

Approve Event:
UC-ID UC-12

Use Case Name Approve Event

Scope Riphah Eventor

Level User goal

Primary Actors Head of Department

Stakeholders and interests Head of Department: Head of Department wants to

approve event request.

Pre-Conditions Head of Department must be able to view the event request.

Post-Condition Head of Department notify the organizer about the event

request.
Main Success Scenario 1) Head of Department view the request

2) Head of Department selects “Approve event” button

3) Head of department select status and click the update

button.

4) System displays “Approval status set successfully”.

29
Alternative Head of Department fails to approve event because of
following factors:
2a. If Head of Department doesn’t set the status
1- Organizer doesn’t notify about the approval status

Technical Requirements Internet connection required.

Frequency of Occurrence High

Table 13: 4.2.2.12 Use case Approve Event

30