Stix 3913 (Group C) Project 1 FIRST SEMESTER 2019/ 2020: Appendix 1-2 List of Requirements

APPENDIX 1-2 List Of Requirement
STIX 3913 (GROUP C)

PROJECT 1
FIRST SEMESTER 2019/ 2020
LECTURER : PROF NUR AZZAH BT ABU BAKAR
TITLE : EVENT MANAGEMENT SYSTEM (EMS)
SUPERVISOR: DR.MUHAMMAD SYAFIQ BIN MOHD POZI
NO NAMA NO MATRIK
1. VISNU S/O MANIMARAN 252959
DOCUMENT IDENTIFICATION
College of Arts & Sciences SYSTEM NAME DESCRIPTION NO. VERSION PAGE
EVENT MANAGEMENT SYSTEM 1.0 1 / 23

(EMS)
LIST OF REQUIREMENTS
EVENT MANAGEMENT SYSTEM

(EMS)
PREPARED BY:
VISNU S/O MANIMARAN
Listed below are the functional requirements and non-functional requirement of the system. In
the priority column, the following short hands are used:

(EMS)
▪ M – mandatory requirements (something the system must do)

▪ D – desirable requirements (something the system preferably should do)
▪ O – optional requirements (something the system may do)
A. FUNCTIONAL REQUIREMENTS
No. Requirement ID Requirement Description Priority

EMS_01 Sign Up
New user must sign up a new account by providing user M
1. EMS_01_01
information name, e-mail, phone number and password.
The system will display a reminder message when the user enters M
2. EMS_01_02
a username that already exist in the system.
The system will display a reminder message when the user enter
3. EMS_01_03 password on the confirm password field is different from the M
password on the password field.
The system should allow user to resend the verification email
4. EMS_01_04
when user does not receive the verification email. M
EMS_02 Login
System administrator and user should login the system by key in
5. EMS_02_01 user ID and password. An error message will pop up if the M
password is wrong.
The system will display an error message “Wrong password!
6. EMS_02_02 Please try again.” if user or system administrator key in password O
wrongly. The system only login until user the correct password.
System administrator and user can allow to forget password if
7. EMS_02_03 they didn’t remember their user ID and password. System can O
send reset password to user email who forgot their password.
System administrator and user may allow to login again once
8. EMS_02_04 O
they have reset their password.

(EMS)
EMS_03 Manage Event Registration

The system should allow the user to add event in menu where a M
9. EMS_03_01
registration form will be provided.
The system will display a reminder message when the user M
10. EMS_03_02
forgets to fill the blanks in registration form.
11. EMS_03_03 The system should allow the user to update the registration form. M
The system should allow the user to delete event registration M
12. EMS_03_04
form by click delete button.
EMS_04 Manage Event Order

The system should allow the administrator can view, verify and
13. EMS_04_01 create or delete the event registration that made by user. System M
will provide create event field after verification process.
The system should allow the administrator to click the create new
14. EMS_04_02 M
event to place a event.
System should allow the administrator to delete the event that
15. EMS_04_03 M
submitted by administrator clicking the delete button.
System should provide event calendar in order user able to view
16. EMS_04_04 M
and plan their event.
System will send successful message or rejection message to user
M
17. EMS_04_05 where their event registration application passed or failed after
the verification process.
EMS_05 Manage Event Payment

Admin will send the total bill to the user who have successful
18. EMS_05_01 register their event. The payments will be paid both in online M
banking system or can paid in counter of student affairs HEA.
After payment process done system will send notification to user
19. EMS_05_02 email whether payment failed or successful. O
System administrator collects payment from user and will send O

20. EMS_05_03
the receipt to user email.
If any error occurs during the process of payment the report will
O
21. EMS_05_04 return to administrator. Any process will be terminated and
restart from the beginning.

(EMS)
B. NON-FUNCTIONAL REQUIREMENTS
No. Requirement ID Requirement Description Priority

EMS_06 Reliability issues
23. EMS_06_01 If the systems crash, it should behave perfectly normal when M
reloaded again.
EMS_07 Usability
24. EMS_07_01 The application should be user friendly M
25. EMS_07_02 The system should not be any useless or hidden feature inside M
the system.
EMS_08 Performance
26. EMS_08_01 All the features in the system must respond instantly when the M
user press the button.
EMS_09 Security
27. EMS_09_01 The system must provide the facilities to back up the entire M
system.
28. EMS_09_02 The user’s account ID must be unique. M
29. EMS_09_03 The personal details of the user should be encrypted inside the M
database.

(EMS)
USE CASE SPECIFICATION

(EMS)
PREPARED BY:
VISNU S/O MANIMARAN

(EMS)
TABLE OF CONTENTS
1 USE CASE: SIGN UP (EMS_01) 9

1.1 BRIEF DESCRIPTION 9
1.2 PRE-CONDITIONS 9
1.3 CHARACTERISTIC OF ACTIVATION 9
1.4 FLOW OF EVENTS 9
1.4.1 Basic Flow 9
1.4.2 Alternative Flow 10
1.4.3 Exceptional Flow 10
1.5 POST-CONDITIONS 10
1.6 RULE(S) 10
1.7 CONSTRAINT(S) 10
2 USE CASE: LOGIN (EMS_02) 11

2.4.1 Basic Flow 11
2.6 RULE(S) 12
3 USE CASE: MANAGE EVENT Registration (EMS_03) 13

3.4.1 Basic Flow 13
3.6 RULE(S) 14
4 USE CASE: MANAGE EVENT ORDER (EMS_04) 15

4.4.1 Basic Flow 15

(EMS)
4.6 RULE(S) 16
5 USE CASE: MANAGE EVENT PAYMENT(EMS_05) 17

5.4.1 Basic Flow 17
5.6 RULE(S) 18

(EMS)
1 USE CASE: SIGN UP (EMS_01)
1.1 BRIEF DESCRIPTION

This use case is initiated by the user and system administrator .This use case will enable
user to sign up a new account.
1.2 PRE-CONDITIONS
New user and system administrator must sign up a new account.
1.3 CHARACTERISTIC OF ACTIVATION

Event Driven
1.4 FLOW OF EVENTS

1.4.1 Basic Flow (EMS_01)
● This use case begins from new user or system administrator.

(EMS)
● The system will display a register interface that allows user to fill in username,
password, email and etc. (E-1: Duplicate Username)
● The user will press the “Sign Up” button and the verification email will send to user
confirm their registration. (E-2: Wrong Password) (E-3: Resend Verification Email)
● The request and information will send to the system when the user press the
verification link from email.
● The system will validate and keep the register information to the database.
● The system will display the “Register Successfully” message.
1.4.2 Alternative Flow

Not Applicable
1.4.3 Exceptional Flow

E-1: Duplicate Username (EMS_01_02)
The system will display a reminder message when the user enter a username that already exists in
the system.
E-2: Wrong Password (EMS_01_03)

The system will display a reminder message when the user enter password on the confirm
password field is different from the password on the password field.
E-3: Resend Verification Email (EMS_01_04)

The system will allow user to resend the verification email when the user does not receive
the verification email.
1.5 POST-CONDITIONS
● New user and system administrator can login to the system.
● The system will update the account of new user and system administrator.
● The username and password is keep into the database.
1.6 RULE(S)
Email address must be valid
1.7 CONSTRAINT(S)
Not applicable.

(EMS)

(EMS)
2 USE CASE: LOGIN (EMS_02)
User
Administrator

This use case is initiated by the system administrator and user. This use case will enable the
system administrator and user to login into the system. System administrator and user may
allow retrieve their password if they forget their password. System administrator and user
may also reset their password.
2.2 PRE-CONDITIONS
User and system administrator need to register in the system.

Event-driven.
2.4 FLOW OF EVENTS

● This use case begins from user and system administrator. User and system
administrator may get into login once they register in the system.
● The user and system administrator need to choose user type, then key in their user
ID and password to login to the system.
● The system will validate the user ID and password once user clicks the “Login”
button. (E-1: Invalid Password)
● The user and system administrator can press “Forget Password?” if they forget their
own password. (A-1: Forget Password)
● User and system administrator may allow reset password. (A-2: Reset Password)
● The user and system administrator successfully login to their account

(EMS)
● The system will display the “Login Successfully” message and user will successfully
entered into their account after verification of their username and password is done.

A-1: Forget Password (EMS_02_03)
The system will proceed with a page for the user and system administrator to key in their
user ID and email to reset the password. The user and system administrator shall click the
“Confirm” button to proceed the system. After that, the system will display a message
which is “Your retrieve password will be sent to your e-mail now”.
A-2: Reset Password (EMS_02_04)

The system will proceed with a page for the user and system administrator to reset
password by key in user ID, old password, new password and confirm password. After the
user and system administrator click the button “Done”, the system will display a message
which is “Reset passwords successful”.
2.4.3 Exceptional Flow

E-1: Invalid Password (EMS_02_02)
The system will display an error message “Wrong password! Please try again.” if user or
system administrator key in password wrongly. The system shall wait until user or system
administrator key in the correct password.
2.5 POST-CONDITIONS
● The user and system administrator can access to the system.
2.6 RULE(S)
●The user must enter the correct username and password.
●The password cannot be wrong more than three times.
2.7 CONSTRAINT(S)
User and system administrator need to have an account to access the system.
3 MANAGE EVENT REGISTRATION (EMS_03)

(EMS)
<<extend>> <<extend>>
<<extend>>

3.2 This use case is initiated by the system user. This use case will enable the system
user to add event, view event and delete event by click at the selected items. The system
administrator can verify the event registration made by user.
3.3 PRE-CONDITIONS
User and system administrator had been successfully login to the system.

System administrator's demand
3.5 FLOW OF EVENTS

● This use case begins when the system user click the "Manage Event Registration"
button.
● The system will allow the system user to add the event by given an event
registration form to fill.
● The system will display the “Successfully Added” message. (A-1: Update
Information)
● The system will display an interface that allows the system user to delete the event
registration in the table provided. (A-2: Delete Items)

(EMS)
● The system user can submit the event registration form they filled by clicking
“Submit” button after all the information are filled in.
● The system will check the information entered by system administrator and make
sure all the information is filled in the table provided. (E-1: Incomplete Information
● The system will validate and keep all the information in the database.

A-1: Update Event(EMS_03_03)
The system should allow the system user to edit the event by clicking the “Update Event
Details” button. The system will keep the information in the database and display the
“Successfully Added” message when the system user press the “OK” button to update the
list information.
A-2: Delete Items (EMS_03_04)

The system will display the “Successfully Deleted” message and all the event items will be
deleted from the database when the system user clicking the “Delete Event Registration”
button in the interface.
3.5.3 Exception Flow

E-1: Incomplete Information
The system will display a reminder message when the system user forgets to fill the certain
information in the table form.
3.6 POST-CONDITIONS
● The system will update the event registration information.
● The system will update the event calendar in order to help system user to
schedule an event .
● The system information is keep in the database.
3.7 RULE(S)
System user must fill all the event details in the table provided.
3.8 CONSTRAINT(S)
Not applicable.

(EMS)
4 MANAGE EVENT ORDER (EMS_04)

This use case is initiated by the system administrator. This use case will enable the
administrator add the event after some verification process. The system administrator can
update and edit the event or delete the event that proceed by system user according to
terms and rules.
4.2 PRE-CONDITIONS
System Administrator had been successfully login to the system.

Event Driven (Admin’s demand)

(EMS)
4.4 FLOW OF EVENTS

● This use case begins when user click the "Add Event Order" button.
● The system will display a events list that allow the admin to add the selected
event.
● The system administrator can remove the event by pressing the button “ “Remove
event”. (A-3: Cancel Order)
● The request will send to the system and system will update the database.
● The system will display the “Successfully Updated” message. (A-1: View Event
Order)(A-2: Delete Event Order)

A-1: View Event Order(EMS_04_02)
The system will allow the administrator to view the event list in the table . Then the
administrator will click the “Add” button to place the order, the request will send to system
and allow the user to make a final confirmation on the even that has been choose after
verification.
A-2: Delete Event Order(EMS_04_03)

The system will allow the administrator to delete the order at the final confirmation by
clicking the “Delete” button. The request is send to the system and the system will display
the Event Order Cancelled message.
A-3: Update Order (EMS_04_04)

The system able to update event order from the list by clicking the “Update” button. The
request is send to the system and the system will update the database. The system will
show “Successfully Updated” message.

E-1: Confirmation Order
The system administrator can view the event order information and proceed to the
payment. System will indicate the confirmation button once the system administrator
approved the order.
4.5 POST-CONDITIONS
● The system is updated.

(EMS)
4.6 RULE(S)
User has the privilege to view, add, delete and remove the event order in the system.
4.7 CONSTRAINT(S)
Not applicable.
5 MANAGE EVENT PAYMENT(EMS_05)

o This use case is initiated by the system user and system administrator.
5.2 PRE-CONDITIONS
User and system administrator had been successfully login to the system.

Event Driven

(EMS)
5.4 FLOW OF EVENTS

● This use case begins when user click the "Manage Payment" button.
● The system will display the payment/bill to the user who have ordered for an
event.
● The payment will be paid as online banking or paid at UUM HEA counter.
● The system administrator will send the event will send payment details to system
user . (A-1: View Payment)
● The system administrator will collect the payment from user and will give the
receipt to the user by send an email to user. (A-2: Payment Settle)
● If error occurs the report will be return to system administrator. (E-1: Payment Fail)

A-1: View Payment (EMS_05_02)
The system administrator will send the payment details to system user in order user to
make payment.
A-2: Payment Settle (EMS_05_03)

The system administrator will collect the money from the user and send the receipt to the
user.

E-1: Payment Fail (EMS_05_04)
If any error occurs during the process of delivery the report will be return to system
administrator.
5.5 POST-CONDITIONS
● The payment is done
5.6 RULE(S)
● The payment should be done.
5.7 CONSTRAINT(S)
Not applicable.

(EMS)
USE CASE DIAGRAM

(EMS)

(EMS)

(EMS)
ACTIVITY DIAGRAM

(EMS)
PREPARED BY:
VISNU S/O MANIMARAN

(EMS)

(EMS)

Stix 3913 (Group C) Project 1 FIRST SEMESTER 2019/ 2020: Appendix 1-2 List of Requirements

Încărcat de

Informații document

Descriere originală:

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Stix 3913 (Group C) Project 1 FIRST SEMESTER 2019/ 2020: Appendix 1-2 List of Requirements

Încărcat de

Drepturi de autor:

Formate disponibile

APPENDIX 1-2 List Of Requirement

STIX 3913 (GROUP C)

LECTURER : PROF NUR AZZAH BT ABU BAKAR

TITLE : EVENT MANAGEMENT SYSTEM (EMS)

SUPERVISOR: DR.MUHAMMAD SYAFIQ BIN MOHD POZI

1. VISNU S/O MANIMARAN 252959

EVENT MANAGEMENT SYSTEM 1.0 1 / 23

EVENT MANAGEMENT SYSTEM

VISNU S/O MANIMARAN

EVENT MANAGEMENT SYSTEM 1.0 2 / 23

▪ M – mandatory requirements (something the system must do)

No. Requirement ID Requirement Description Priority

EVENT MANAGEMENT SYSTEM 1.0 3 / 23

EMS_03 Manage Event Registration

EMS_04 Manage Event Order

EMS_05 Manage Event Payment

System administrator collects payment from user and will send O

EVENT MANAGEMENT SYSTEM 1.0 4 / 23

No. Requirement ID Requirement Description Priority

EVENT MANAGEMENT SYSTEM 1.0 5 / 23

USE CASE SPECIFICATION

EVENT MANAGEMENT SYSTEM

VISNU S/O MANIMARAN

EVENT MANAGEMENT SYSTEM 1.0 6 / 23

1 USE CASE: SIGN UP (EMS_01) 9

2 USE CASE: LOGIN (EMS_02) 11

3 USE CASE: MANAGE EVENT Registration (EMS_03) 13

4 USE CASE: MANAGE EVENT ORDER (EMS_04) 15

EVENT MANAGEMENT SYSTEM 1.0 7 / 23

5 USE CASE: MANAGE EVENT PAYMENT(EMS_05) 17

EVENT MANAGEMENT SYSTEM 1.0 8 / 23

1 USE CASE: SIGN UP (EMS_01)

1.1 BRIEF DESCRIPTION

1.3 CHARACTERISTIC OF ACTIVATION

1.4 FLOW OF EVENTS

EVENT MANAGEMENT SYSTEM 1.0 9 / 23

1.4.2 Alternative Flow

1.4.3 Exceptional Flow

E-2: Wrong Password (EMS_01_03)

E-3: Resend Verification Email (EMS_01_04)

EVENT MANAGEMENT SYSTEM 1.0 10 / 23

EVENT MANAGEMENT SYSTEM 1.0 11 / 23

2 USE CASE: LOGIN (EMS_02)

2.1 BRIEF DESCRIPTION

2.3 CHARACTERISTIC OF ACTIVATION

2.4 FLOW OF EVENTS

EVENT MANAGEMENT SYSTEM 1.0 12 / 23

2.4.2 Alternative Flow

A-2: Reset Password (EMS_02_04)

2.4.3 Exceptional Flow

3 MANAGE EVENT REGISTRATION (EMS_03)

EVENT MANAGEMENT SYSTEM 1.0 13 / 23

3.1 BRIEF DESCRIPTION

3.4 CHARACTERISTIC OF ACTIVATION

3.5 FLOW OF EVENTS

EVENT MANAGEMENT SYSTEM 1.0 14 / 23

3.5.2 Alternative Flow

A-2: Delete Items (EMS_03_04)

3.5.3 Exception Flow

EVENT MANAGEMENT SYSTEM 1.0 15 / 23

4 MANAGE EVENT ORDER (EMS_04)

4.1 BRIEF DESCRIPTION