ProjID - XXX - SDS - VX.X (TMPLT - V1.1-Zai)

System Design
Specification
<XXX>
Submitted by
Mesiniaga Berhad
(Company No: 79244V)
Menara Mesiniaga,
No 1A, Jalan SS 16/1,
47500 Subang Jaya,
Selangor, Malaysia.
Tel: 603 5635 8828

Fax: 603 5635 5222
Private and Confidential

No part of this publication may be reproduced or distributed in any form or by any means, or stored in a
database or retrieval system, without prior written permission of the publisher.
©Mesiniaga Berhad 2022
SDS
DocId:- ProjID - XXX - SDS - vX.X Page 1
Document Sign-Off Sheet

Human Resource Develeopement Corporation (HRD Corp) and Mesiniaga Berhad (MSB) acknowledge
that they have review User Requirement & Solution Specification ( URSS) document for the New Core
System (NCS) project, both parties understood it, and that once it is signed by both parties’ Authorized
Representatives, agree to be bound by its requirements scope. The signature below signifies that the
parties involved have accepted this requirement specification as final.
Document Approval –Mesiniaga Berhad
PREPARED BY REVIEWED BY
…………………………………… ……………………………………
NAME: NAME:
DESIGNATION: DESIGNATION:
DATE: DATE:
APPROVED BY
……………………………………
NAME:
DESIGNATION:
DATE:
Document Approval – HRD Corp

SDS
VERIFIED BY
…………………………………… ……………………………………
NAME: NAME:
DATE: DATE:
…………………………………… ……………………………………
NAME: NAME:
DATE: DATE:
APPROVED BY
……………………………………
NAME:
DESIGNATION:
DATE:
Document Version History

SDS
Version Remarks Amended By Release Date
1.0 Baselined Tan Ho Lim

SDS
TABLE OF CONTENTS
1 INTRODUCTION...............................................................................................................................5
1.1 PURPOSE AND SCOPE.........................................................................................................................5
1.2 GLOSSARY........................................................................................................................................5
1.3 DOCUMENT REFERENCES.....................................................................................................................5
1.4 SYSTEM OVERVIEW............................................................................................................................6
1.5 DESIGN CONSTRAINTS.........................................................................................................................6
1.6 FUTURE CONTIGENCIES.......................................................................................................................6
2 SYSTEM ARCHITECTURE..................................................................................................................6
2.1 SYSTEM HARDWARE ARCHITECTURE......................................................................................................6
2.2 SYSTEM SOFTWARE ARCHITECTURE.......................................................................................................6
3 FILE STORAGE AND DATABASE DESIGN...........................................................................................7
3.1 DATABASE MANAGEMENT...................................................................................................................7
3.2 FILE MANAGEMENT...........................................................................................................................7
4 SCREEN DESIGN AND ELEMENTS.....................................................................................................8
4.1 COMMUNAL MODULES.......................................................................................................................8
4.1.1 Login Module.........................................................................................................................8
4.1.2 User Dashboard Module......................................................................................................17
4.1.3 Profiles.................................................................................................................................19
4.1.4 Configurations.....................................................................................................................19
4.2 CONSOLIDATE PAYMENT MODULE......................................................................................................19
4.2.1 Flowchart.............................................................................................................................19
4.2.2 Check Tasklist for Payment Screen.......................................................................................20
4.2.3 View Payment Details Screen..............................................................................................20
4.2.4 Generate Payment Bill – SPPM............................................................................................23
4.2.5 Generate Payment Bill – SPPB.............................................................................................28
4.2.6 Generate Payment Bill – SPPJ..............................................................................................32
4.2.7 Generate Payment Bill – SPPW............................................................................................38
4.3 APPLICATION/MODULE NAME...........................................................................................................43
4.3.1 Flowchart.............................................................................................................................43
4.3.2 Screens and Elements PartA................................................................................................43
4.3.3 Screens and Elements PartB................................................................................................43
5 REPORTS SPECIFICATION...............................................................................................................43
6 INTEGRATION SPECIFICATION.......................................................................................................43
7 APPENDICES..................................................................................................................................43
SDS
1 Introduction
[Provide a brief overview of the project.]
1.1 Purpose and Scope

[This section provides a brief description of the Systems Design Document’s purpose and scope.]
1.2 Glossary
[Supply a glossary of all terms and abbreviations used in this document. If the glossary is several pages
in length, please move this chapter into bottom of the document before appendix.]
The following are terms and abbreviations, and the respective definitions that are used throughout
this document.
Abbreviation Definition
MSB Mesiniaga Berhad
PSMB Pembangunan Sumber Manusia Berhad
HRD Corp Human Resource Development Coorporation
PMC Project Management Committee
Symbol Definition
System Process
Document
Manual Process
System Process
Decision
1.3 Document References

[Name the documents that were sources of this document. Include meeting summaries, white paper
analyses, and other System Development Life Cycle deliverables, as well as any other documents that
contributed to the FRD. Include the Configuration Management identifier and date published for each
document listed.]
List documents need to be referred to for getting an in-depth understanding of this document.
Document Name Document ID

SDS
[Proposal, Project Charter, URSS, and etc.]
1.4 System Overview

[This section describes the system in narrative form using non-technical terms. It should provide a high-
level system architecture diagram showing a subsystem breakout of the system, if applicable. The high-
level system architecture or subsystem diagrams should, if applicable, show interfaces to external
systems. Supply a high-level context diagram for the system and subsystems, if applicable. Refer to the
requirements trace ability matrix (RTM) in the User Requirement and Solution Specification (URSS), to
identify the allocation of the functional requirements into this design document.]
1.5 Design Constraints

[This section describes any constraints in the system design (reference any trade-off analyses conducted
such, as resource use versus productivity, or conflicts with other systems) and includes any assumptions
made by the project team in developing the system design.]
1.6 Future Contigencies

[This section describes any contingencies that might arise in the design of the system that may change the
development direction. Possibilities include lack of interface agreements with outside agencies or
unstable architectures at the time this document is produced. Address any possible workarounds or
alternative plans.]
2 System Architecture
[In this section, describe the system and/or subsystem(s) architecture for the project.]
2.1 System Hardware Architecture

[In this section, describe the overall system hardware and organization. Include a list of hardware
components (with a brief description of each item) and diagrams showing the connectivity between the
components. If appropriate, use subsections to address each subsystem.]
2.2 System Software Architecture

[In this section, describe the overall system software and organization. Include a list of software modules
(this could include functions, subroutines, or classes), computer languages, and programming computer-
aided software engineering tools (with a brief description of the function of each item). Use structured
SDS
organization diagrams/object-oriented diagrams that show the various segmentation levels down to the
lowest level. All features on the diagrams should have reference numbers and names. Include a narrative
that expands on and enhances the understanding of the functional breakdown. If appropriate, use
subsections to address each module.
Note: The diagrams should map to the FRD data flow diagrams, providing the physical process and data
flow related to the FRD logical process and data flow.]
3 File Storage and Database Design

[Interact with the Database Administrator (DBA) when preparing this section. The section should reveal
the final design of all database management system (DBMS) files and the non-DBMS files associated
with the system under development. Additional information may add as required for the particular
project. Provide a comprehensive data dictionary showing data element name, type, length, source,
validation rules, maintenance (create, read, update, delete (CRUD) capability), data stores, outputs,
aliases, and description. Can be included as an appendix.]
3.1 Database Management

[This section reveals the final design of the DBMS files and includes the following information, as
appropriate (refer to the data dictionary):
 relationship diagrams, and other logical design information
 A physical description of the DBMS schemas, sub-schemas, records, sets, tables, storage page
sizes, etc.
 Access methods (such as indexed, via set, sequential, random access, sorted pointer array, etc.)
 Estimate of the DBMS file size or volume of data within the file, and data pages, including
overhead resulting from access methods and free space
 Definition of the update frequency of the database tables, views, files, areas, records, sets, and
data pages; estimate the number of transactions if the database is an online transaction-based
system]
3.2 File Management

[In this section, provide the detailed description of all non-DBMS files and include a narrative description
of the usage of each file—including if the file is used for input, output, or both; if this file is a temporary
file; an indication of which modules read and write the file, etc.; and file structures (refer to the data
dictionary). As appropriate, the file structure information should:
 Identify record structures, record keys or indexes, and reference data elements within the records
SDS
 Define record length (fixed or maximum variable length) and blocking factors
 Define file access method—for example, index sequential, virtual sequential, random access, etc.
 Estimate the file size or volume of data within the file, including overhead resulting from file
access methods
 Define the update frequency of the file; if the file is part of an online transaction-based system,
provide the estimated number of transactions per unit time, and the statistical mean, mode, and
distribution of those transactions]
4 Screen Design and Elements

4.1 Communal Modules
[Common Modules such as Login Portal, Application Dashboard, Back-Office modules, and etc that
shared across shall be in this category]
4.1.1 Login Module

4.1.1.1 Use Case
SDS
4.1.1.2 Login with Credential Screen
Field Label Element Field Length Remarks

Mandatory
Type /
Format
“ID Pengguna” Input Box Varchar 50 Y “ID Pengguna” input box is for user to key in
the login account name in the system.
“Kata Laluan” Input Box Varchar 50 Y “Kata Laluan” input box is for user to key in the
private password in order to log in into the
system.
“Log Masuk” Button N/A N/A After the usrname and password, click the “Log
Masuk” button in order to submit the
credentials to the system for verification
purpose.
“Lupa Kata Hyperlink N/A N/A If user forgot password that they used to enter
Laluan?” the system, they will click on the “Lupa Kata
Laluan?” button. He or she is then redirected to
a page where they are required to enter a valid
email address.
Upon successful email verification (system to

check if the email address has been registered in
the system), system will send an email to the
entered email address where user is required to
click on the hyperlink in the email.
User is then redirected to a page where they are

required to reset the password.
SDS
Mandatory
Type /
Format
“Daftar disini” Hyperlink N/A N/A For non-system user (PSP) that want to register
into the system, they can initiate the registration
process by clicking on this link.
Upon clicking on this link, the system shall

redirect the user to a registration screen [Refer
to the following chapter – New User
Registration Screen]
4.1.1.3 Invalid Credential Screen

[Screen Design]
[Screen/Data Element]
4.1.1.4 First Time Login Password Change Screen

[Screen Design]
4.1.1.5 Forgot Password Screen

[Screen Design]
SDS
4.1.1.6 Register as New User Screen

SDS

Mandatory
Type /
Format
Butiran Individu
Nama Penuh Input Box VarChar 100 Y

Pengguna
ID Pengguna Input Box VarChar 30 Y
Klasifikasi Combo Box VarChar Y Options as follow:

Pengguna
 “Arkitek”
 “Jurutera”
 “Perunding”
 “Orang Awam”
No default selected value.
No Kad Input Box VarChar 12 Y

Pengenalan
No. Pendaftaran Input Box VarChar 30 Y Hide this field if the Klasifikasi Pengguna =
Professional “Orang Awam”
Tarikh Sijil Date Picker Date NA Y Hide this field if the Klasifikasi Pengguna =
Pendaftaran “Orang Awam”
SDS
Mandatory
Type /
Format
Nama Syarikat Combo Box VarChar NA Y  Hide this field if the Klasifikasi Pengguna =
“Orang Awam”
 Options shall base on the list of “AKTIF”

company profiles maintained by the system.
 To add an extra option called “Lain-Lain”.
 “Lain-Lain” is to be chosen by the applicant

if their affiliated company is not available on
the given options.
 When “Lain-Lain” is chosen, the Butiran

Syarikat section shall become un-hidden for
data entry.
Butiran Syarikat
Nama Syarikat Input Box VarChar 100 Y
No Pendaftaran Input Box VarChar 30 Y

Syarikat
Jenis Syarikat Combo Box VarChar NA Y Options as follow:
 Arkitek
 Jurutera
 Perunding
The options shall base from master-code (“Kod

Utama”) configuration.
Alamat | 1 Input Box VarChar 100 Y
Alamat | 2 Input Box VarChar 100 N
Alamat | 3 Input Box VarChar 100 N
Bandar Input Box VarChar 100 Y
Poskod Input Box VarChar 20 Y
Negeri Combo Box VarChar NA Y Options shall base on master-code configuration

(“Kod Utama”)
SDS
Mandatory
Type /
Format
Negara Combo Box VarChar NA Options shall base on master-code configuration

(“Kod Utama”)
No. Telefon | Input Box Number 5 Y

Prefix
No. Telefon | Input Box Number 15 Y

No.
No. Faks | Input Box Number 5 Y

Prefix
No. Faks | No. Input Box Number 15 Y
Laman Web Input box Varchar 100 Y
Nama individu Input box Varchar 100 Y

untuk
dihubungi
Email individu Input box Varchar 100 Y

untuk
dihubungi
Maklumat Hubungan Pengguna
Email Input Box Varchar 100 Y Upon Hantar, the system must check if the email
address adhere to format as defined on the
chapter generic features
No. Telefon Input Box Number 5 Y

Bimbit | Prefix

Bimbit | No.

Syarikat/Rumah
| Prefix

Syarikat/Rumah
| No.
SDS
Mandatory
Type /
Format
No. Telefon Input Box Number 6 N

Syarikat/Rumah
| Sambungan.
Dokumen Sokongan
Kad Pengenalan Upload Field NA NA Y Allow multiple files to be uploaded

(salinan dua
belah)
Sijil Upload Field NA NA Y  Allow multiple files to be uploaded

Pendaftaran
Professional  Hide this field if Klasifikasi Pengguna =
“Orang Awam”
Deklarasi Akta Perlindungan Data Peribadi(PDPA) 2010
Kandungan Hyperlink NA  Once click, the system shall download the

Akta MBPP version of PDPA form to user’s
Perlindungan computer.
Data
Peribadi(PDPA)
2010 [Sila
Baca]
Ya, saya/kami Checkbox NA Y

menyatakan
persetujuan
untuk Majlis
Bandaraya
Pulau Pinang
dan/atau Entiti-
entiti Lain yang
berkaitan untuk
memproses data
peribadi
saya/kami
untuk kegunaan
penyemakan
dan sebagainya.
Action Buttons
Hantar Button  Once click, the system shall check the

necessary as defined in the screen elements.
 Only when all of the criteria is satisfied,

system shall then allow the submission to
happen.
SDS
Mandatory
Type /
Format
 Applicant shall be directed to a “successful

submission screen”. This is as far as the
applicant get to in ILCS until they received
their credential from the system upon
approval.
Kembali ke Button  Once click, the system shall first confirm

halaman log with users about their action, and to warn
masuk any data-entry will be loss.
 Once confirm, the system to redirect the

applicant to the login page.
4.1.1.7 Successful Submission Screen

Mandatory
Type /
Format
Action Buttons
Kembali ke Button
halaman log
masuk
SDS
4.1.2 User Dashboard Module

SDS
4.1.2.1 Use Case
4.1.2.2 Tasklist Widget

[Screen Design]
4.1.2.3 Q&A Widget

[Screen Design]
4.1.2.4 Calendar Grid Widget

[Screen Design]
SDS
4.1.3 Profiles
[Use Case]
[List of Screen Design and its Elements]
4.1.4 Configurations
[Use Case]
[List of Screen Design and its Elements]
4.2 Consolidate Payment Module

4.2.1 Screen Flowchart
1.1 1.3
1.2 1.4
1.5
Note
1. Details and screens involved of Process (1.1) shall be referred to Chapter – Screen Design and
Elements > Communal Modules > Login Module.
2. Pre-requisite, the PSP had successful log into the system after Process (1.1)
SDS
4.2.2 Check Tasklist for Payment Screen
Note:
1. Clicking on the hyperlink Membuat Bayaran will lead to the screen as detailed on the subsequent
chapter – View Payment Details Screen.
4.2.3 View Payment Details Screen
P3 P1
P2 Hai
Hai
P4
Hai
P6 P5
Hai Hai
Code Description
P1  A static note to the PSP to disable the pop-up blocker in their browser.
SDS
Code Description
 This is because in the event PSP is making payment via online (e-bayar), window pop-up
is important for that process.
P2  If the application aka. (“Permohonan”) already has No. Fail, then use the value. Else, to
use the reference-number (“No. Rujukan”) that was assigned by the system during
application to OSC.
P3  Title of the application aka. (“Permohonan”).
P4  This table to outline all bills related to the application that required PSP payment.
 Citing SPPB for example, in the event a “PERMOHONAN BARU PELAN

BANGUNAN” has 2 bills required PSP payment namely (i) Yuran PELAN
BANGUNAN, and (ii) Kompaun; this table outline 2 records of payment respectively .
 PSP shall pay the payment bill one at a time.
P4 – “Bil”  Sequence 1,2,3 depending on the table’s record number.
P4 – “Bil No”  “Bil No” of the Payment Bill. Please refer to the following chapter for the specification
under the subsequent chapters:
o Generate Payment Bill – SPPM
o Generate Payment Bill – SPPB
o Generate Payment Bill – SPPJ
o Generate Payment Bill - SPPW
P4 – “Butiran  To display “Butiran Bayaran” / “Butiran Vot” of the related payment bill. Please refer to
Pembayaran” the following chapter for its specifications under the subsequent chapters:
P4 – “Jumlah  To detail the payment bill amount.

(RM)”
 For “Bayaran Kaunter”, the amount to pay shall be as it is. However for online payment
via “e-bayar credit card”; extra charge shall incur in addition to the bill’s amount.
P4 –  To make available two payment options to the PSP as follow:

“Tindakan”
o “Bayar di Kaunter”
o “Bayar Online”
SDS
Code Description
 When “Bayar di Kaunter” is chosen, the system to generate payment bill as described
under the subsequent chapters:
 When “Bayar Online” is chosen, the system shall launch the MBPP’s e-bayar system.
 Upon PSP chosen the payment method, the system shall disable the other payment
option from PSP selection.
P4 – “Status  This is to show the payment’s status as follow:

Bayaran”
o “TELAH DIBAYAR”
o “BELUM DIBAYAR”
o “DIKECUALIKAN BAYARAN”
o “BATAL”
 “TELAH DIBAYAR” ; The payment shall get this status upon successful payment by
the PSP either via ‘Online Payment’ / ‘Kaunter’.
 “BELUM DIBAYAR”; All payment that is pending for PSP payment shall has this
status.
 “DIKECUALIKAN BAYARAN”; Payment with “rayuan” from PSP that has been
approved, shall has this status.
o As for now, this scenario shall only applicable to SPPB.
 “BATAL”; This status was introduced first in SPPB but no longer in used as it has been
replaced by status “DIKECUALIKAN BAYARAN”. Nonetheless, the new ILCS shall
still retain this status for historical SPPB data that referred to it.
P4 – “Semak  This feature shall only available to PSP when PSP had made payment “via kaunter”; but
Status” the payment result is not updated yet.
o Note: The payment result will not be immediately updated into ILCS upon
PSP had physically made the payment at the counter.
o Note: There will be an automated scheduler in place that will run/activate

twice a day (11PM and 5 AM) from ILCS to the counter-system to acquire
payment’s status
o Note: Only then, the PSP payment’s status will be updated by the system
 This feature shall allow the PSP to invoke the system to check the payment’s status
immediately without waiting for the scheduler.
SDS
Code Description
P5  Static statement to explain to the PSP that extra charge will incur for when doing online
payment.
P6  A function for PSP to navigate back to their previous screen in the event they do not
intend to proceed with their payment.
4.2.4 Generate Payment Bill – SPPM

4.2.4.1 Bill’s Header
H1
H2
H3
Field Label / Element Field Length Remarks

Mandatory
Code Type /
Format
Code – H1 Display Text VARCHA  Static Text

R

R

R
 As of now, the Tel No is based on the
official contact number on
http://www.mbpp.gov.my/
The number shall subject to change if

MBPP wish to provide department’s
specific contact number later.
 Important note: For time being, we

assume that there shall be an official email
address for the ILCS (ilcs@mbpp.gov.my).
However this shall subject to change when
an actual address is decided.
SDS
4.2.4.2 Bill’s Content
C1
C3 C2
C5
C4
C6 C7 C8
C9
C10
Field Label / Element Field Type Length Remarks

Mandatory
Code / Format
Code – C1 Display Text VARCHA  Label – “Tarikh Bil: “

R
 Value – Bill’s Date
Code – C2 Barcode Barcode  System shall convert the “No. Bil” into
barcode format.
 For example, the barcode is generated

from the“No Bil” with value
‘PM721011902031’ as illustrated
Code – C3 Display Text VARCHA  Label 1 – “No Bill”

R
 Value 1 – System to generate an unique
SDS
Mandatory
Code / Format
reference code for the payment bill with

combination as follow:
PM + <VOT NO> + <Year in ‘YY’

format> + <5 digit running numbers>
e.g. PM + 72101 + 19 + 02031
“PJ721031902031”
 Label 2 – “Tajuk”
 Value 2 – Title of the application

(“Permohonan”)
 Label 3 – “No Fail”
 Value 3 – “No. Fail” of the application

(“Permohonan”)
 Label 5 – “Nama PSP”
 Value 5 – PSP Name
 Label 6 – “Syarikat PSP”
 Value 6 – PSP’s company name
 Label 7 – “No. K.P”
 Value 7 – PSP Identification Number.

Value can be retrieved from the user
profile.
 Label 8 – “Alamat”
 Value 8 – PSP Address. Value can be

retrieved from the user profile.
 Label 9 – “Tarikh Akhir Bayaran”
 Value 9 – Last date for PSP to make

payment. System shall calculate the date
based on the KPI day set on the relevant
Joget’s workflow process.
 Label 10 – “No. Vot”
 Value 10 – There is one Vot number used

for SPPM which is as follow:
Yuran Pelan Kebenaran Merancang -

“72101”
SDS
Mandatory
Code / Format
No Vot Display Text VarChar  Yuran Pelan Kebenaran Merancang -

“72101”
Butiran Display Text VarChar  “Yuran Pelan Merancang:” <No. Fail>

Vot
Jumlah Display Text Number (2  Amount to be paid. Value comes from the
decimal) respective application.
Jumlah Display Text Number (2  Sum of all ‘Jumlah’ value.

Bayaran decimal)
(RM)
Code – C5 Display Text VarChar  Static Text
“PENGARAH PERANCANGAN
PEMBANGUNAN”
 To have a dotted ‘Horizontal Rule’ line

after the text.
No. Bil Display Text VarChar  System to generate an unique reference

code for the payment bill with
PM + <VOT NO> + <Year in ‘YY’

e.g. PM + 72101 + 19 + 02031
“PM721011902031”
Tarikh Bil Display Text Date  Bill’s Date

(dd/mm/yy
yy)
Code – C7 Icon/symbol Icon/  An Icon showing an encircled “3-5”

Symbol
No VOT Display Text VarChar “72101”
Jumlah Display Text Number (2  Total amount need to be paid.

Amaun decimal)
(RM) and
thousand
separator
SDS
Mandatory
Code / Format
Code – C9 Display Text VarChar  Static text as shown in the illustration.
 Important note: the website URL is

temporary set to
“https://ilcs.mppp.gov.my”; This shall
subject to changes when MBPP had
decided a new Doman-Name to used for
the new ILCS website.

after the text.
Code – C10 Display Text VarChar  Static Text as shown in the illustration
4.2.5 Generate Payment Bill – SPPB

H1
H2
H3

Mandatory
Code Type /
Format

R

R

R
 Important note: As of now, the ‘E-
mail’ still using sppb@mbpp.gov.my;
However this shall subject to change if
MBPP decided a new address later.
SDS
C1
C3 C2
C5 C4
C6 C7 C8
C9
C10

Mandatory
Code / Format

R
barcode format.

‘PB721021902031’ as illustrated

R
PB + <VOT NO> + <Year in ‘YY’

SDS
Mandatory
Code / Format
e.g. PB + 72101 + 19 + 02031
“PB721021902031”
 Label 2 – “Tajuk”

(“Permohonan”)
 Label 3 – “No Pelan”

(“Permohonan”)
 Label 4 – “Tetuan”
 Value 4 – “Tetuan” from the application

(“Permohonan”).

 Value 8 – The Vot number specific for

the payment type. In SPPB, there are 2
types of fixed Vot No. involved as
follow:
72102 – Used for “Yuran Pelan”
76106 – used for “Kompaun”
Bil Display Text No  Sequence
Butiran Display Text VarChar  If the payment is for “Yuran Pelan”

Bayaran VOT=72102; then the description shall
be as follow
SDS
Mandatory
Code / Format
C “NO Pelan: <No. Fail>”

o
d  If the payment is for “Kompaun”
e VOT=76106; then the description shall
be as follow
–
“Kompaun: <No. Fail>”
C
4
Jumlah Display Text Number (2  Amount to be paid. Value comes from
decimal) the respective application.

Bayaran decimal)
(RM)
“PENGARAH BANGUNAN”

after the text.

PB + <VOT NO> + <Year in ‘YY’

e.g. PB + 72101 + 19 + 02031
“PB721021902031”

(dd/mm/yy
yy)

Symbol
No VOT Display Text VarChar  The Vot number specific for the payment
type. In SPPB, there are 2 types of fixed
Vot No. involved as follow:
72102 – Used for “Yuran Pelan”
76106 – used for “Kompaun”

SDS
Mandatory
Code / Format

Amaun decimal)
(RM) and
thousand
separator

stated “https://sppb.mppp.gov.my”; This
shall change to a new URL after MBPP
had decided the new Doman-Name to
used for the new ILCS website.

after the text.
4.2.6 Generate Payment Bill – SPPJ

H1
H2
H3

Mandatory
Code Type /
Format

R

R

R
SDS
Mandatory
Code Type /
Format
 As of now, both Tel No and Fax No are

based on the official contact number on
Both numbers shall subject to change if


assume that there shall be an official
email address for the ILCS
(ilcs@mbpp.gov.my). However this shall
subject to change when an actual address
is decided.
C1
C3 C2
C5 C4
C8
C6 C7
C9
C10
SDS
Mandatory
Code / Format

R
barcode format.

‘PJ721031902031’ as illustrated

R
PJ + <VOT NO> + <Year in ‘YY’

e.g. PJ + 72103 + 19 + 02031
“PJ721031902031”
 Label 2 – “Butiran”

(“Permohonan”)

(“Permohonan”)

profile.

SDS
Mandatory
Code / Format


the payment type. For SPPJ, there are 3
types of fixed Vot No as follow:
Pelan Kerja Tanah - “72103”
Pelan Parit dan Jalan – “72105”
Pelan Lampu Jalan – “72106”
No Vot Display Text VarChar  Pelan Kerja Tanah - “72103”
 Pelan Parit dan Jalan – “72105”
 Pelan Lampu Jalan – “72106”
Butiran Display Text VarChar  If the payment is for “Pelan Kerja

Vot Tanah”, then the description shall be:-
“Pelan Kerja Tanah: ”<No. Fail>
 If the payment is for “Pelan Parit dan

Jalan”, then the description shall be:-
“Pelan Parit dan Jalan: ”<No. Fail>
 If the payment is for “Pelan Lampu

Jalan”, then the description shall be:-
“Pelan Lampu Jalan: ”<No. Fail>


Bayaran decimal)
(RM)
“PENGARAH KEJURUTERAAN”

SDS
Mandatory
Code / Format
after the text.

PJ + <VOT NO> + <Year in ‘YY’

e.g. PJ + 72103 + 19 + 02031
“PJ721031902031”

(dd/mm/yy
yy)

Symbol
type. For SPPJ, there are 3 types of fixed
Vot No as follow:
Pelan Kerja Tanah - “72103”
Pelan Parit dan Jalan – “72105”
Pelan Lampu Jalan – “72106”

Amaun decimal)
(RM) and
thousand
separator

temporary set to

after the text.
SDS
4.2.7 Generate Payment Bill – SPPW

H1
H2
H3

Mandatory
Code Type /
Format

R

R

R
 As of now, the Tel No is based on the
official contact number on
The number shall subject to change if


assume that there shall be an official
email address for the ILCS
(ilcs@mbpp.gov.my). However this shall
subject to change when an actual address
is decided.
SDS
C1
C3 C2
C5 C4
C6 C8
C7
C9
C10

Mandatory
Code / Format

R
barcode format.

‘PW724251902031’ as illustrated

R
SDS
Mandatory
Code / Format
PW + <VOT NO> + <Year in ‘YY’

e.g. PW + 72425 + 19 + 02031
“PW724251902031”
 Label 2 – “Butiran”

(“Permohonan”)

(“Permohonan”)

profile.



the payment type. For SPPW, there are 2
types of fixed Vot No as follow:
Bayaran Pelan Permit / Bayaran Permit

Membaiki Bangunan / Bayaran Permit
Melukis Dinding - “72425”
Bayaran PRA-PM / Bayaran PRA-PB –

SDS
Mandatory
Code / Format
“72434”
No Vot Display Text VarChar  Bayaran Pelan Permit / Bayaran Permit

 Bayaran PRA-PM / Bayaran PRA-PB –

“72434”
Butiran Display Text VarChar  If the payment is for “Pelan Permit /

Vot Bayaran Permit Membaiki Bangunan /
Bayaran Permit Melukis Dinding”, then
the description shall be:-
“BAYARAN YURAN MEMPROSES

PERMOHONAN PERMIT &
PEMBAIKAN”
 If the payment is for “PRA-PM /

Bayaran PRA-PB”, then the description
shall be:-
“BAYARAN YURAN MEMPROSES

PRA-RUNDINGAN PELAN
BANGUNAN / PELAN
MERANCANG”


Bayaran decimal)
(RM)
“PENGARAH KONSERVASI
WARISAN”

after the text.
SDS
Mandatory
Code / Format

PW + <VOT NO> + <Year in ‘YY’

e.g. PW + 72425 + 19 + 02031
“PW724251902031”

(dd/mm/yy
yy)

Symbol
type. For SPPJ, there are 3 types of fixed
Vot No as follow:
Bayaran Pelan Permit / Bayaran Permit

Bayaran PRA-PM / Bayaran PRA-PB –

“72434”

Amaun decimal)
(RM) and
thousand
separator

temporary set to

after the text.
SDS
4.3 Application/Module Name

4.3.1 Flowchart
[Cross-Functional Flowchart]
4.3.2 Screens and Elements PartA

[Screen Design]
4.3.3 Screens and Elements PartB

[Screen Design]
5 Reports Specification
6 Integration Specification
7 Appendices

ProjID - XXX - SDS - VX.X (TMPLT - V1.1-Zai)

Uploaded by

Document Information

Original Title

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

ProjID - XXX - SDS - VX.X (TMPLT - V1.1-Zai)

Uploaded by

Copyright:

Available Formats

System Design

Tel: 603 5635 8828

Private and Confidential

DocId:- ProjID - XXX - SDS - vX.X Page 1

Document Sign-Off Sheet

Document Approval –Mesiniaga Berhad

Document Approval – HRD Corp

DocId:- ProjID - XXX - SDS - vX.X Page 2

Document Version History

DocId:- ProjID - XXX - SDS - vX.X Page 3

Version Remarks Amended By Release Date

1.0 Baselined Tan Ho Lim

DocId:- ProjID - XXX - SDS - vX.X Page 4

DocId:- ProjID - XXX - SDS - vX.X Page 5

1.1 Purpose and Scope

1.3 Document References

Document Name Document ID

DocId:- ProjID - XXX - SDS - vX.X Page 6

[Proposal, Project Charter, URSS, and etc.]

1.4 System Overview

1.5 Design Constraints

1.6 Future Contigencies

2.1 System Hardware Architecture

2.2 System Software Architecture

DocId:- ProjID - XXX - SDS - vX.X Page 7

3 File Storage and Database Design

3.1 Database Management

 relationship diagrams, and other logical design information

3.2 File Management

DocId:- ProjID - XXX - SDS - vX.X Page 8

4 Screen Design and Elements

4.1.1 Login Module

DocId:- ProjID - XXX - SDS - vX.X Page 9

4.1.1.2 Login with Credential Screen

Field Label Element Field Length Remarks

Upon successful email verification (system to

User is then redirected to a page where they are

DocId:- ProjID - XXX - SDS - vX.X Page 10

Field Label Element Field Length Remarks

Upon clicking on this link, the system shall

4.1.1.3 Invalid Credential Screen

4.1.1.4 First Time Login Password Change Screen

4.1.1.5 Forgot Password Screen

DocId:- ProjID - XXX - SDS - vX.X Page 11

4.1.1.6 Register as New User Screen

DocId:- ProjID - XXX - SDS - vX.X Page 12

Field Label Element Field Length Remarks

Nama Penuh Input Box VarChar 100 Y

ID Pengguna Input Box VarChar 30 Y

Klasifikasi Combo Box VarChar Y Options as follow:

No default selected value.

No Kad Input Box VarChar 12 Y

DocId:- ProjID - XXX - SDS - vX.X Page 13

Field Label Element Field Length Remarks

 Options shall base on the list of “AKTIF”

 To add an extra option called “Lain-Lain”.

 “Lain-Lain” is to be chosen by the applicant

 When “Lain-Lain” is chosen, the Butiran

Nama Syarikat Input Box VarChar 100 Y

No Pendaftaran Input Box VarChar 30 Y

Jenis Syarikat Combo Box VarChar NA Y Options as follow:

The options shall base from master-code (“Kod

Alamat | 1 Input Box VarChar 100 Y