<Project Name> Report ReferenceUser Requirement Specification Month Year

<PROJECT NAME>

KEMENTERIAN KESIHATAN MALAYSIA

User Requirement Specification

Month Year

Report Reference:

KKM/BPM/ <Abbreviations For Project Name>/SQAD/02/001

Prepared by Reviewed by Approved by Date

_________________ ________________ _________________ (dd/mm/yyyy)

<<Subsystems> Team Leader Name>

<Project Manager Name>

<Project Director Name>

<date> / Issue <IssueNumber> Page 1 of 14

<Project Name> Report ReferenceUser Requirement Specification Month Year

<Subsystems> Team Leader

Project Manager Project Director

<date> / Issue <IssueNumber> Page 2 of 14

<Project Name> Report ReferenceUser Requirement Specification Month Year

Status Final

Client Deliverable Item Yes

Configuration Item No

Distribution Client : <Project Owner>Project Library

Amendment History

Issue Status Date Change Description

References

None.

Abbreviations(List the abbreviation use)

e.g :

e-SPKB Electronik Sistem Perancangan dan Kawalan Belanjawan

BAS Branch Accounting System

BASFE Branch Accounting System Font End

DTB Desktop Banking

LFEP Legacy Front End Processor

Definitions

None.

<date> / Issue <IssueNumber> Page 3 of 14

<Project Name> Report ReferenceUser Requirement Specification Month Year

TABLE OF CONTENTS

1. PURPOSE.........................................................................................................42. SCOPE..............................................................................................................53. OVERVIEW OF <SUBSYSTEMS FRONT END> AND THE INTERFACES......6

3.1 System Processes Overview.................................................................................................74. < SUBSYSTEMS> INTERFACES......................................................................8

4.1 e-SPKB To < subsystems> Interface ....................................................................................84.1.1 Input To < subsystems>..................................................................................................84.1.2 Output From < subsystems>...........................................................................................8

4.2 < subsystems> To< systems> Interface................................................................................94.2.1 Output To e-SPKB...........................................................................................................9

4.3 < subsystems> To <other Entity> Interface..........................................................................104.3.1 Input To < subsystems>................................................................................................104.3.2 Output From < subsystems>.........................................................................................10

4.4 <other Entity> To < subsystems> Interface..........................................................................104.4.1 Input To < subsystems>................................................................................................114.4.2 Output From < subsystems>.........................................................................................11

5. INTERFACE BETWEEN HOSTS.....................................................................126. ENHANCEMENTS OF < SUBSYSTEMS>......................................................13

6.1 < subsystems> modifications required:................................................................................136.2 New <subsystems front end> module:.................................................................................13

<date> / Issue <IssueNumber> Page 4 of 14

<Project Name> Report ReferenceUser Requirement Specification Month Year

1. PURPOSE

This document provides the User Requirement Specification based on the Requirement Study currently done. This user requirement specification will serve as a baseline for the Functional Specification for the <subsystems front end> component.

<date> / Issue <IssueNumber> Page 5 of 14

<Project Name> Report ReferenceUser Requirement Specification Month Year

2. SCOPE

This section details out the functionalities required by the < subsystems> and <subsystems front end> systems. The following are the areas covered in this section:

a. the input to the < subsystems> and <subsystems front end> systems.

b. the daily processing of < subsystems> and <subsystems front end> systems related to the <Project Name> project.

c. the output of < subsystems> and <subsystems front end> systems.

<date> / Issue <IssueNumber> Page 6 of 14

<Project Name> Report ReferenceUser Requirement Specification Month Year3. OVERVIEW OF <SUBSYSTEMS FRONT END> AND THE INTERFACES

Figure 3-1: Overview Of <subsystems front end> Interfaces

Figure 3-1 above depicts the overview of data flows between <subsystems>, <other subsystems> and <third party systems> sub-systems. To complete the integration of <other Entity>- <systems>-<other Entity>, the complementing components that will be required are:

1. <subsystems front end>

2. <main systems>

3. <third party systems>

The basis for the < subsystems>-<main systems>-<third party systems>communication and integration implementation will be described in further detail in the following section. Refer to the respective documentations for <third party systems> and <main systems> components.

The following diagram shows the overall system processing flows for the <subsystems> interfaces to the various components directly related to <subsystems>:

<date> / Issue <IssueNumber> Page 7 of 14

EXAMPLE

<Project Name> Report ReferenceUser Requirement Specification Month Year

3.1 System Processes Overview

LFEP PC Server BASFE BAS

Figure 3.1-1: System Processing Flows Overview

<date> / Issue <IssueNumber> Page 8 of 14

EXAMPLE

<Project Name> Report ReferenceUser Requirement Specification Month Year

4. < SUBSYSTEMS> INTERFACES

There are four main components of <subsystems> interfaces, namely:

(a) <other subsystems> to <subsystems>

(b) <subsystems> to <other subsystems>

(c) <third party subsystems> to <subsystems>

(d) <subsystems> to <third party subsystems>

There will be a pc server residing in between the <subsystems> host and the <main systems>host to handle the FTP of files automatically between the two hosts. It will be described in section 5 of this documentation.

4.1 <other subsystems>To < subsystems> Interface

Figure 4.1-2: <other subsystems>To < subsystems> Interface Overview

4.1.1 Input To < subsystems>

< subsystems> will receive the following input transactions from < other subsystems>

e.g :

(a) Allocation warrants

(b) Payment vouchers

(c) Journal vouchers

(d) Collector’s statements

Each document or voucher will be received in an ASCII file. The transaction files are sent to < subsystems> by batch. Each batch can only have one document or voucher.

<date> / Issue <IssueNumber> Page 9 of 14

EXAMPLE

<Project Name> Report ReferenceUser Requirement Specification Month Year4.1.2 Output From < subsystems>

There are six types of information that have been identified to be sent from <subsystems> to <other subsystems>:

(a) Daily transaction from <subsystems> to <other subsystems>

(b) DCS code

(c) Bulk agency code

(d) Monthly bulk transactions

(e) Rejected financial e-documents

(f) Payment advice

4.2 <subsystems> to <other subsystems> Interface

Figure 4.2-3: <subsystems> to <other subsystems>Interface Overview

4.2.1 Output To <other subsystems>

There are six types of information that have been identified to be sent from BAS to e-SPKB:

1. Daily transactions from <subsystems> to <other subsystems>

2. DCS Code

3. Bulk Agency Code

4. Monthly Bulk Transactions

5. Rejected financial e-docs

6. Payment advice

<date> / Issue <IssueNumber> Page 10 of 14

EXAMPLE

<Project Name> Report ReferenceUser Requirement Specification Month Year

4.3 < subsystems> To <third party subsystems> Interface

Figure 4.3-4: < subsystems> To <third party subsystems> Interface Overview

4.3.1 Input To < subsystems>

Input to BAS are basically the four types of documents/vouchers: allocation warrants, payment vouchers, journal vouchers and collector’s statements.

4.3.2 Output From < subsystems>

As part of the <outside systems> system, payment orders are electronically sent from < subsystems> to <third party subsystems> via < main systems>. The payment file is the only type of data that < subsystems> generated related to <outside systems> for the <third party subsystems> to process.

4.4 <third party subsystems> To < subsystems> Interface

Figure 4.4-5: <third party subsystems> To < subsystems> Interface Overview

<date> / Issue <IssueNumber> Page 11 of 14

EXAMPLE

EXAMPLE

<Project Name> Report ReferenceUser Requirement Specification Month Year4.4.1 Input To < subsystems>

After the Bank has processed the payment order file, the Bank will send <subsystems> the payment status file via <main systems>. The file contains the payment detail and the status of the payment.

4.4.2 Output From < subsystems>

There will be a payment status file sent to <subsystems> via <main systems>. It has a status to indicate whether the individual payment is processed successfully by the <third party subsystems>

<date> / Issue <IssueNumber> Page 12 of 14

<Project Name> Report ReferenceUser Requirement Specification Month Year

5. INTERFACE BETWEEN HOSTS

An interfacing system running in Windows/Windows NT is proposed to handle the file transferring process for the two systems <main systems> and <subsystems> systems.

Figure 4.4-6:Interface Overview Between Hosts

<date> / Issue <IssueNumber> Page 13 of 14

EXAMPLE

<Project Name> Report ReferenceUser Requirement Specification Month Year

6. ENHANCEMENTS OF < SUBSYSTEMS>

There are two types of changes that are required to be done in < subsystems>. A new < subsystems> front end (<subsystems front end>) module needs to be developed in < subsystems> to intercept and process the data from <main systems> before passing it to < subsystems> for processing. The existing < subsystems> required changes to differentiate the type of input source, whether it is an e-transaction or non-e transaction, so that < subsystems> can process the e-transactions correctly.

6.1 < subsystems> modifications required:

1) Use an existing field to differentiate the type of input source.

2) Use the GLI process to load data from <subsystems front end> to < subsystems>.

3) Change edit programs to verify the payee’s bank codes.

4) Change cheque printing program to exclude e-transaction.

5) Develop new <outside systems> listings.

6) Develop new <outside systems> extract programs.

7) Develop new online <third party subsystems> code maintenance screen.

8) Develop the reversal program for payment rejected by the <third party subsystems>.

6.2 New <subsystems front end> module:

1) Create a new <subsystems front end> module in < subsystems> so as not to disturb the core system and processing of < subsystems>.

2) Develop a program to read the files sent by the PC server to <subsystems front end> and consolidate the files into one file.

3) Develop a new program to reformat the file into a format that is readable by < subsystems>.

4) Develop a set of programs/processes to automate the reading of files sent by PC server to <subsystems front end>.

5) Develop a new loading program similar to GLI process.

6) Develop the flexibility of automating and allowing the user to manually initiate the consolidation and loading processes.

<date> / Issue <IssueNumber> Page 14 of 14