A191 STID3024

SYSTEM ANALYSIS AND DESIGN

(GROUP G)

PBL 1
TRANSPORTATION MANAGEMENT SYSTEM
(TMS)

NAME MATRIC NUMBER

PHAN JIA LE 262755

CHOONG HUI ZHI 265763

LEONG JIA WEI 261570

LIST OF REQUIREMENTS
Listed below are the functional requirements and non-functional requirement of the system.
In the priority column, the following short hands are used:

● 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

.

TMS_01 Manage transport

1. TMS_01_01 Clerk can add transport. M

2. TMS_01_02 Clerk can delete transport. M

3. TMS_01_03 Clerk can edit transport. M

4. TMS_01_04 Clerk, PK HEM and principal can view transport. D

TMS_02 Manage bus services

5. TMS_02_01 Clerk can add student who require bus services. M

6. TMS_02_02 Clerk can delete student who cancel bus services. M

TMS_03 Manage route

7. TMS_03_01 Clerk can assign bus routing places. M

8. TMS_03_02 Clerk can assign bus scheduled. M

TMS_04 Manage driver

9. TMS_04_01 Clerk can add driver. M

10. TMS_04_02 Clerk can delete driver. M

11. TMS_04_03 Clerk can edit driver. M

TMS_05 Manage report

12. TMS_05_01 Clerk can generate report. M

13. TMS_05_02 Clerk can submit report. M

14. TMS_05_03 PK HEM and principal can view the report. M

TMS_06 Book transport

15. TMS_06_01 Teacher can request to book transport . M

16. TMS_06_02 PK HEM and principal can view the request of transport M
booking.

17. TMS_06_03 PK HEM and principal can accept or reject the request of M
transport booking.

B. NON-FUNCTIONAL REQUIREMENTS

No Requirement ID Requirement Description Priority

.

TMS_07 Compatibility issues

18. TMS_07_01 Application should be able to be used on devices with M

different hardware.

19. TMS_07_02 Application should be able to run on different operations M

system.

TMS_08 Reliability issues

20. TMS_08_01 If the system crashes, it should behave perfectly normal M

when reloaded again.
TABLE OF CONTENT
1. USE CASE: MANAGE TRANSPORT

1.1 BRIEF DESCRIPTION

1.2 PRE-CONDITIONS
1.3 CHARACTERISTICS OF ACTIVATION
1.4 FLOW OF EVENTS
1.4.1 Basic Flow
1.4.2 Alternative Flow
1.4.3 Exceptional Flow
1.5 POST-CONDITION(S)
1.6 RULE(S)
1.7 CONSTRAINT(S)

2. USE CASE: MANAGE BUS SERVICES

2.1 BRIEF DESCRIPTION
2.2 PRE-CONDITIONS
2.3 CHARACTERISTICS OF ACTIVATION
2.4 FLOW OF EVENTS
2.4.1 Basic Flow
2.4.2 Alternative Flow
2.4.3 Exceptional Flow
2.5 POST-CONDITION(S)
2.6 RULE(S)
2.7 CONSTRAINT(S)

3. USE CASE: MANAGE ROUTE

3.1 BRIEF DESCRIPTION
3.2 PRE-CONDITIONS
3.3 CHARACTERISTICS OF ACTIVATION
3.4 FLOW OF EVENTS
3.4.1 Basic Flow
3.4.2 Alternative Flow
3.4.3 Exceptional Flow
3.5 POST-CONDITION(S)
3.6 RULE(S)
3.7 CONSTRAINT(S)
4. USE CASE: MANAGE DRIVER
4.1 BRIEF DESCRIPTION
4.2 PRE-CONDITIONS
4.3 CHARACTERISTICS OF ACTIVATION
4.4 FLOW OF EVENTS
4.4.1 Basic Flow
4.4.2 Alternative Flow
4.4.3 Exceptional Flow
4.5 POST-CONDITION(S)
4.6 RULE(S)
4.7 CONSTRAINT(S)

5. USE CASE: MANAGE REPORT

5.1 BRIEF DESCRIPTION
5.2 PRE-CONDITIONS
5.3 CHARACTERISTICS OF ACTIVATION
5.4 FLOW OF EVENTS
5.4.1 Basic Flow
5.4.2 Alternative Flow
5.4.3 Exceptional Flow
5.5 POST-CONDITION(S)
5.6 RULE(S)
5.7 CONSTRAINT(S)

6. USE CASE: BOOK TRANSPORT

6.1 BRIEF DESCRIPTION
6.2 PRE-CONDITIONS
6.3 CHARACTERISTICS OF ACTIVATION
6.4 FLOW OF EVENTS
6.4.1 Basic Flow
6.4.2 Alternative Flow
6.4.3 Exceptional Flow
6.5 POST-CONDITION(S)
6.6 RULE(S)
6.7 CONSTRAINT(S)
USE CASE DIAGRAM
USE CASE DESCRIPTION

USE CASE 1 : MANAGE TRANSPORT

1.1 BRIEF DESCRIPTION

This use case is initiated by the clerk. This use case will enable clerk to update transportation
information.

1.2 PRE-CONDITIONS
Transportation information has to be changed.

1.3 CHARACTERISTIC OF ACTIVATION

On clerk’s and PK HEM’s demand

1.4 FLOW OF EVENTS

1.4.1 Basic Flow (TMS_01_01)
● This use case begins when clerk press manage transport button.
● The system shall display menu bar on screen.
● The menu bar will display add transportation button, delete transportation
button, view transportation button and edit transportation button.
● Clerk can press “add transport” button to fill in the transport information.
(A1-reset button)
● PK HEM fills up the form and presses “submit”. (E1-Incomplete
Information)
● Then the system will display a successful message.

1.4.2 Alternative Flow

● A1 - Delete Button
○ When Clerk press “delete” button to select transport to delete, the
system will display all transport and enable Clerk to delete any
transport in the list.
○ System will pop up notification confirmation when Clerk delete any
transport.
 ● A2 - Edit Button
○ When Clerk click the “Edit Transport” button, the system will display
all transport and Clerk can click on it to edit.
○ Clerk can click “submit” button after changed information. (A3-
cancel button)

● A3 - View Button
○ When PK HEM or principal click “view” button, the system will show
all transport and all transport information.

● A3 - Reset Button
○ Clerk can click reset button to clear all text box.

1.4.3 Exceptional Flow

● E1 - Incomplete Information
The message “Incomplete information.” will appear if the user tries to submit
the form without completing it.
● E2-Car number plate duplicated
If Clerk in the repeat car number plate, the system will display car number
plate duplicated.

1.5 POST CONDITION

● The database of transport’s information is updated.
● A new School bus will be added.
● Transport will be deleted from the system

1.6 RULES
● Not Applicable

1.7 CONSTRAINTS
● Not Applicable
USE CASE 2 : MANAGE BUS SERVICES

2.1 BRIEF DESCRIPTION

This use case is initiated by the clerk. This use case will enable the clerk to add students into
services list.

2.2 PRE CONDITION

Clerk log in to the system.

2.3 CHARACTERISTIC OF ACTIVATION

On teacher’s demand

2.4 FLOW OF EVENTS

2.4.1 Basic Flow
● This use case begins when the Clerk clicks on Manage Bus Services.
● The Clerk will be able to view a list all information provided by the system.
● The Clerk will be able to add/ remove student.
● When Clerk click “add” button, the system will require Clerk fill student’s id
to add student.
● Then the system will verify the information.(E1-Wrong id number)
● The system will show up student’s name if correct Clerk will click “confirm”
button. (A1-Cancel button)

2.4.2 Alternative Flow

● A1 - Delete Button
○ When Clerk click “delete” button, the system will show all the students
who have been added and Clerk can choose the students or search the
student to delete.
○ System will pop up confirmation notification.
● A2 - Cancel Button
When Clerk click cancel button, the system will direct to the page require
Clerk fill student’s id.

2.4.3 Exceptional Flow

● E1-Wrong id number
If the Clerk type the wrong id or the id does not exists, then the system will
pop up notification of wrong id number.

2.5 POST CONDITIONS

 ● Bus services will provide to the students.

2.6 RULE(S)
● Input student’s id should correct.

2.7 CONSTRAINTS
● Not Applicable.
USE CASE 3 : MANAGE ROUTE

3.1 BRIEF DESCRIPTION

This use case is initiated by the clerk. This use case will enable the clerk to access the list of
route and manage it.

3.2 PRE CONDITION

Route information has to be changed.

3.3 CHARACTERISTIC OF ACTIVATION

On Clerk’s demand.

3.4 FLOW OF EVENTS

3.4.1 BASIC FLOW
● This use case begins when the Clerk or PKHEM clicks on Manage Route.
● Clerk will be able to view the list of route.
● Clerk will be able to assign bus routing places and assign bus schedule.
● Clerk can click on button “bus routing places”, then the system will show all
transport in a list and allow Clerk to assign bus routing places for any bus.

3.4.2 Alternative Flow

● A1-Bus Schedule
When Clerk click on bus schedule, clerk will be able to assign all bus schedule
at this page.

3.4.3 Exceptional Flow

Not applicable

3.5 POST CONDITIONS

● All buses have their own bus routing places.
● All buses have their own bus schedule.

3.6 RULE(S)
Not applicable

3.7 CONSTRAINT(S)
Not applicable
USE CASE 4 : MANAGE DRIVER

4.1 Brief Description

This use case is initiated by the Clerk. This use case will enable the Clerk to add driver into
driver list or delete driver from the driver list.

4.2 PRE CONDITION

The driver information is needed to change.

4.3 CHARACTERISTIC OF ACTIVATION

On Clerk’s demand.

4.4 FLOW OF EVENTS

4.4.1 Basic Flow
● This use case begins when the Clerk click on manage driver.
● Clerk can click on add driver and fill in all driver information.(A2-reset
Button)
● Then clerk can submit after fill in all information (E1-Incomplete
Information)

4.4.2 Alternative Flow

● A1-Delete Button
○ When clerk click on the delete button, the system will show all driver
list.
○ Clerk can either search driver or select driver at the list to delete.
○ System will have confirmation notification when Clerk delete any
driver.
● A2-Reset Button
When clerk press “reset” button, the system will reset the form to empty form.

4.4.3 Exceptional Flow

● E1-Incomplete Information
The message “Incomplete Information” will appear if the clerk tries to submit
the form without completing it.

4.5 POST CONDITIONS

The list of driver will be updated.

4.6 RULE(S)
Not Applicable

4.7 CONSTRAINTS
Not Applicable
USE CASE 5 : MANAGE REPORT

5.1 BRIEF DESCRIPTION

This use case is initiated by the clerk. This use case will enable clerk to generate a
transportation report and submit the report to pkhem and principal.

5.2 PRE CONDITION

Not applicable

5.3 CHARACTERISTIC OF ACTIVATION

On clerk’s demand.

5.4 FLOW OF EVENTS

5.4.1 BASIC FLOW
● This use case begins when the clerk clicks on Manage Report.
● Clerk can click on generate report.
● Then the clerk can submit the report to pkhem and principal.(E1-Cancel
Button)

5.4.2 Alternative Flow

● A1 - Submit Button
When clerk click submit button, the system will submit the generated report to
pkhem and principal.

5.4.3 Exceptional Flow

● E1-Cancellation
When clerk click cancel button, the system will direct to the page of
generating report.

5.5 POST CONDITIONS

The report will be generated and submitted to pkhem and principal.

5.6 RULE(S)
Not Applicable

5.7 CONSTRAINTS
Not Applicable
USE CASE 6 : BOOK TRANSPORT

6.1 BRIEF DESCRIPTION

This use case is initiated by the teacher and pkhem or principal. This use case will enable
teacher to request a transportation booking, pkhem and principal can approve or reject the
request.

6.2 PRE CONDITION

There are school events that needed bus transportation.

6.3 CHARACTERISTIC OF ACTIVATION

On teacher’s demand.

6.4 FLOW OF EVENTS

6.4.1 BASIC FLOW
● This use case begins when the teacher clicks on Book Transport.
● System will show all available transport and enable teacher to choose.
● Then the teacher must fill up all information for transport booking.(A1-Reset
Button)
● The system will save information and wait for principal or pkhem to accept
after teacher submit all information.(E1-Incomplete Information)

6.4.2 Alternative Flow

● A1 - View Button
When pkhem or principal press view transport booking button, the system will
enable pkhem or principal to accept or reject all booking request.
● A2 - Reset Button
When teacher click on reset button, the system will empty the form.
● A3 - Accept Button
When pkhem or principal click accept button, the system will accept the
transportation booking made by teacher.
● A4 - Reject Button
When pkhem or principal click reject button, the system will reject the
transportation booking made by teacher.
 ● A5 - Submit Button
When clerk click submit button, the system will submit the booking to
booking list.

6.4.3 Exceptional Flow

● E1-Incomplete Information
The message “Incomplete Information” will appear if the teacher tries to
submit the booking form without completing it.

6.5 POST CONDITIONS

The booking made by the teacher is successful and inserted into a booking list.

6.6 RULE(S)
Not Applicable

6.7 CONSTRAINTS
Not Applicable
ACTIVITY DIAGRAM

Manage Transport
Manage Bus Services
Manage Driver