REQUIREMETS AALYSIS FOR SBS SYSTEM AD STUDY REVIEW
PROCESS ITERATIO DURIG REQUIREMETS PHASE
ALGHAMDI, HAA MUSAFER H
UIVERSITI TEKOLOGI MALAYSIA
REQUIREMENTS ANALYSIS FOR SBS SYSTEM AND STUDY REVIEW
PROCESS ITERATION DURING REQUIREMENTS PHASE
ALGHAMDI, HANAN MUSAFER H
A project report submitted in partial fulfillment of
the requirements for the award of the degree of
MSc. (Computer Science – Real Time Software Engineering)
Centre for Advanced Software Engineering
Faculty of Computer Science and Information System
Universiti Teknologi Malaysia
APRIL 2009
iii
DEDICATIO
To my beloved husband Fahad and my son Faisel, you are the best motivator.
iv
ACKOWLEDGEMET
In the name of Allah. Most Gracious, Most Merciful.
All praises and thanks be to Allah, the Lord of all the worlds, and peace be upon our
prophet Muhammad, his family and companions in entirety.
I would like to acknowledge the help and support provided by my Academic
Mentor Dr. Suhaimi Ibrahim, and my Industrial Mentor Pn. Noorhafizah Mat Syned. I
also would like to acknowledge the good friendship of my class mates especially
Nurdatillah Hashim and Norakmar Arbain.
And lastly not forgetting I would like to thanks to all my lecturers, Prof. Dr.
Shamsul Sahibuddin, Mr. Othman Mohd Yusop, Mr. Mohd Ridzuan Ahmad and Mr.
Azri Hj. Azmi.
Thank you very much and may Allah bless all of you.
v
ABSTRACT
This paper represented the experience gained and discussed the works done under
the title “Requirements Analysis For SBS System And Study Review Process Iteration
During Requirements Phase” by the author during her Industrial Attachment 2 Period,
from 13th October 2008 to 13th March 2009, at HeiTech Padu, Malaysia. The purpose of
this paper is to analyze requirements for Shared Banking Services system and study
reviews process that can be applied in requirement phase in order to get quality
requirements document with reduced errors. The SBS system is aimed to provide the
banking services, of one selected bank, through post office in order to give the customer
other alternative way to perform his or her banking services. There were some studies is
carried out to understand how the reviews process is important in requirement phase and
to show how to make the reviews process more effective by iterate it during the
development of SRS document. The required methodology to achieved objectives of this
paper began from initiation and planning, an analysis of Shared Banking Services system,
study about best practices in requirements engineering process and study requirements
review process. Finally, documentation of the output was performed. The development
team of SBS system used ADVISE methodology which is based in HeiTech Padu process
development. The deliverables of analyzing SBS system are Software Requirement
Specification (SRS), Requirement Traceability Matrix and User Manual documents. A
workflow is introduced to show how the reviews process can be iterated during
development of SRS document.
vi
ABSTRAK
Kajian ini membincangkan pengalaman dan hasil kerja yang telah dijalankan oleh
penulis di bawah tajuk “Analisis Keperluan Untuk Sistem SBS Dan Kajian Pengulasan
Proses Pengulangan Semula Semasa Fasa Keperluan” semasa Latihan Industri 2 beliau
yang bermula pada 13 Oktober 2008 hingga 13 Mac 2009 di HeiTech Padu, Malaysia.
Kajian ini bertujuan untuk menganalisis keperluan-keperluan untuk sistem Perkhidmatan
Perkongsian Perbankan dan untuk mengkaji proses pengulasan yang boleh diaplikasikan
ke dalam fasa keperluan untuk memperoleh dokumen keperluan yang berkualiti beserta
jumlah kesalahan minima. Sistem SBS mensasarkan untuk membekalkan perkhidmatan
perbankan, daripada satu bank terpilih, melalui pejabat pos dalam memberikan pelanggan
alternatif lain untuk menyempurnakan perkhidmatan perbankannya. Beberapa kajian
telah dijalankan untuk memahami kepentingan proses pengulasan dalam fasa keperluan
dan untuk mempamerkan bagaimana untuk menjadikan proses ini lebih efektif dengan
mengulangkan ia semula semasa pembangunan dokumen SRS.
Metodologi yang
diperlukan untuk mencapai objektif-objektif kajian ini bergerak dari permulaan dan
perancangan, analisis sistem Perkhidmatan Perkongsian Perbankan, kajian tentang
praktis-praktis terbaik dalam proses kejuruteraan keperluan dan juga kajian keperluan
proses pengulasan.
Akhirnya, proses dokumentasi hasil telah dijalankan. Kumpulan
pembangunan sistem SBS telah menggunakan metodologi ADVISE yang berdasarkan
proses pembangunan HeiTech Padu. Hasul daripada analisis sistem SBS adalah Perisian
Spesifikasi Keperluan (SRS), Matriks Keperluan Kebolehan Menjejaki dan dokumen
Manual Penggunaan.
vii
TABLE OF COTETS
CHAPTER
TITLE
PAGE
DECLARATIO .................................................................................... ii
DEDICATIO ....................................................................................... iii
ACKOWLEDGEMET .................................................................... iv
ABSTRACT ............................................................................................ v
ABSTRAK .............................................................................................. vi
TABLE OF COTETS ..................................................................... vii
LIST OF TABLES................................................................................. xi
LIST OF FIGURES.............................................................................. xii
LIST OF ACROYMS ....................................................................... xiv
LIST OF APPEDICES ...................................................................... xv
1
2
ITRODUCTIO ...................................................................................... 1
1.1
Company Background ....................................................................... 1
1.2
Project Background ........................................................................... 4
PROJECT OBJECTIVES / SCOPES ..................................................... 6
2.1
Introduction ....................................................................................... 6
2.2
Project Objectives ............................................................................. 6
2.3
Project Scopes ................................................................................... 7
2.4
Project Plan ....................................................................................... 8
viii
3
LITERATURE STUDY ............................................................................. 9
3.1
Introduction ....................................................................................... 9
3.2
Systems Development Life Cycle Overview .................................... 9
3.2.1
3.3
System Requirements Analysis Overview ...................................... 13
3.3.1
3.3.2
3.3.3
3.3.4
3.4
Rational Unified Process..................................................... 11
System Requirements Analysis Activities .......................... 14
3.3.1.1
Requirements Elicitation..................................... 15
3.3.1.2
Requirements Analysis ....................................... 16
3.3.1.3
Requirements Specification ................................ 17
3.3.1.4
Requirements Validation .................................... 18
3.3.1.5
Requirements Managements ............................... 19
Classification of Requirements ........................................... 20
3.3.2.1
Functional Requirements .................................... 20
3.3.2.2
Non Functional Requirements ............................ 21
System Requirements Analysis Modeling .......................... 21
3.3.3.1
Use Case Model .................................................. 21
3.3.3.2
Sequence Diagram .............................................. 27
3.3.3.3
Collaboration Diagram ....................................... 29
3.3.3.4
State Transition Diagram .................................... 30
Requirements Traceability .................................................. 32
Requirements Review Process ........................................................ 33
3.4.1
The Importance of Requirements Review .......................... 33
3.4.2
SRS Errors .......................................................................... 34
3.4.3
SRS Characteristics............................................................. 36
3.4.4
Recommended Review Techniques Can
Integrate in Requirements Analysis Phase .......................... 38
3.4.5
Study On Related Existing Approach ................................. 41
3.4.6
Requirements Review for HeiTech
Padu Berhad ........................................................................ 43
3.4.7
An Approach In Integrate Review in
Requirements Process ......................................................... 47
ix
4
PROJECT METHODOLOGY ............................................................... 50
4.1
Introduction ..................................................................................... 50
4.2
Project Methodology....................................................................... 50
4.2.1
Phase 1: Project Initiation and Planning ............................. 52
4.2.2
Phase 2: Analysis ................................................................ 52
5
Literature Review ............................................... 52
4.2.2.2
Analyze SBS System .......................................... 53
4.2.2.3
Survey ................................................................. 53
4.2.3
Phase 3: Develop Documentation ....................................... 54
4.2.4
Technique ............................................................................ 54
4.2.5
4.3
4.2.2.1
4.2.4.1
Research And Reading ....................................... 54
4.2.4.2
Object-Oriented Approach ................................. 55
4.2.4.3
UML Notation .................................................... 56
Tool ..................................................................................... 57
SBS System Development Methodology........................................ 58
4.3.1
SBS Requirements Process ................................................. 59
4.3.2
Standard and Guideline ....................................................... 60
PROJECT DISCUSSIO ........................................................................ 62
5.1
Introduction ..................................................................................... 62
5.2
Part One: SBS System .................................................................... 62
5.2.1
SBS System Architecture .................................................... 63
5.2.2
External Interface Requirements......................................... 67
5.2.3
SBS System Use Case Diagram .......................................... 68
5.2.3.1
User and Their Role ........................................... 70
5.2.3.2
Sign In Use Case ................................................ 70
5.2.3.3
Open Account Use Case ..................................... 71
5.2.3.4
Make Cash Deposit/Payment
Use Case ............................................................. 71
5.2.3.5
Withdraw Money Use Case ................................ 72
5.2.3.6
Inquire Balance Use Case................................... 73
x
5.2.3.7
Maintain Passbook Use Case.............................. 73
5.2.3.8
Remit Money Use Case ...................................... 74
5.2.3.9
Reverse Transaction Use Case ........................... 74
5.2.3.10 Require Override Use Case ................................ 75
5.2.3.11 Manage User Profile Use Case ........................... 75
5.2.3.12 Perform End Of Day Use Case........................... 76
5.2.3.13 Stock Control Register Use Case ....................... 77
5.2.3.14 View Electronic Journal And
Forex Rate Use Case .......................................... 77
5.3
6
5.2.4
SBS Sequence Diagram ...................................................... 79
5.2.5
User Manual ........................................................................ 81
Part Two: Requirements Review Iteration Method ........................ 82
5.3.1
Iteration 1: Scope ................................................................ 85
5.3.2
Iteration 2: High- Level ...................................................... 86
5.3.3
Iteration 3: Detailed ............................................................ 87
5.3.4
Iteration 4: Finalized ........................................................... 88
COCLUSIO ......................................................................................... 89
6.1
Conclusion And Recommendation ................................................. 89
REFERECES ............................................................................................................. 91
Appendices A - B .................................................................................................. 94 - 96
xi
LIST OF TABLES
TABLE O.
TITLE
3.1
Inspections versus Walkthroughs
3.2
Comparison Between other Approaches and
PAGE
40
HeiTech Padu Approach
45
4.1
The Software Required To Complete The Project
57
5.1
Transaction Subsystem Functions
64
5.2
Utilities Subsystem Functions
65
xii
LIST OF FIGURES
FIGURE O.
TITLE
PAGE
1.1
Applied Research and Development Department Structure
3
1.2
SBS System Components
5
3.1
Rational Unified Process Methodology
3.2
Coarse-Grain Activity Model Of The Requirements
12
Engineering Process
14
3.3
Requirements Validation Process
18
3.4
Use Case Model Steps
22
3.5
Actors Relationships and Use Cases Relationships
26
3.6
Objects Types
28
3.7
Sequence Diagram Sample
29
3.8
Collaboration Diagram Sample
30
3.9
State Transition Diagram Sample
31
3.10
Review Process For HeiTech Padu
43
3.11
An Approach In Integrate Review in Requirements
Process
47
4. 1
Project Methodology
51
4.2
Requirement Process for HeiTech Padu
59
5.1
SBS System Components
64
5.2
External Interface Requirements
67
5.3
Use Case Diagram for SBS System
69
5.4
Sign In Use Case Diagram
71
5.5
Open Account Use Case Diagram
71
5.6
Make Cash Deposit/Payment
72
xiii
5.7
Withdraw Money Use Case Diagram
72
5.8
Inquire Balance Use Case Diagram
73
5. 9
Maintain Passbook Use Case Diagram
73
5.10
Remit Money Use Case Diagram
74
5.11
Reverse Transaction Use Case Diagram
75
5.12
Require Override Use Case Diagram
75
5.13
Manage User Profile Use Case Diagram
76
5.14
Perform End Of Day Use Case Diagram
76
5.15
Stock Control Register Use Case Diagram
77
5.16
View Electronic Journal And Forex Rate
Use Case Diagram
5.17
Sequence Diagram for Require Override
Use Case -Basic Flow
5.18
5.21
80
Sequence Diagram for Manage User Profile
Use Case-Alternative Flow
5.20
79
Sequence Diagram for Manage User Profile
Use Case -Basic Flow
5.19
78
80
Sequence Diagram for Stock Control Register
Use Case-Basic Flow
81
Requirements Review Iteration Method
83
xiv
LIST OF ACROYMS
AR&D
-
Applied Research and Development
CMMI
-
Capability Maturity Model Integration
DSS
-
Device Service Server
ICT
-
Information and Communications Technology
UML
-
Unified Modelling Language
OOA
-
Object Oriented Analysis
RUP
-
Rational Unified Process
RFID
-
Radio Frequency Identification
SBS
-
Share Banking Services
SRS
-
System Requirements Specification
SDLC
-
System Development Life Cycle
xv
LIST OF APPEDICES
APPEDIX
TITLE
PAGE
A
Project Plan – IA Gantt Chart
93
B
System Requirements Specification for SBS Project
95
CHAPTER 1
ITRODUCTIO
This chapter explains about the company background, department structure and
the project background.
1.1
Company Background
HeiTech Padu is one of the largest information technology companies in Malaysia.
It provides comprehensive mission-critical solutions for public and private sectors.
HeiTech Padu was established on 1981 and it has more than 750 ICT professionals.
HeiTech Padu is an expert in transforming businesses’ manual processes to automated
systems by providing complete integrated ICT (Information and Communications
Technology) services and finally produces the effective information systems.
The main sectors that HeiTech adopts to provide ICT products and services are:
ICT infrastructure services, public sector, education, health, financial and defense and
public security.
2
The core businesses of HeiTech Padu are: manage data centre services, manage
network & communications services, systems integration services, solution &
consultancy offerings, and system integration and application development. In addition,
its vision is to be the technology-based transformational company in Malaysia and
beyond. In order to achieve this vision, HeiTech Padu has a mission which is providing
total solution, creating innovative product as well as consulting for a better world.
The industrial training was done at the Applied Research and Development
(AR&D). This department was established in October 2001. The AR&D Department’s
responsibilities and objectives consist of researching, developing, and improving HeiTech
Padu proprietary software products. Furthermore, AR&D Department aims to develop
application component which is application independent in itself.
Moreover, this
department does researching the new, advanced, and emerging technology that can be
useful to HeiTech Padu software development. AR&D department undertakes a variety of
research and development activities which are: E-connect, RFID Middleware, Device
Service Server and Hybrid Client. The AR&D Structure which includes the author is
shown in figure 1.1 as below.
3
Khairol Amin Mohd Salleh
Azlin Rusli
Research
Product
Development 1
Nor Hazilawati Awang
(Head)
Kamarulzaman Sali
Suzana Bee Abd Kadir
(Head)
Edge
(DSS- Device
Services Server)
Premise
(RFID Product)
Product
Development 2
Maliki Mohamed
(Head)
Halimatun Saadiah Ahmad
Mohamad Yamin Ishak
Khurram Junaid
Mohd Firdaus Basit
Hybrid
Product
Haslinda M Ros Noorhafizah Mat Syned
Mohd Fadzil Mohd Jaafar
Mohd Hairi Azly Harun
Suhani Sukor
Hanan Alghamdi (Practical)
Figure 1.1
Product
Management
Abu Bakar Yusof
(Head)
Mohd Rashidi Abd Manaf
Razif Bustamal
Mohamad Siss M Jamil
Application
Irina Ramli
Haidayu Anuar
Applied Research and Development Department Structure
4
1.2
Project Background
Organizations face many problems that slow down development of software
systems decisive to their operations and growth. Requirements process has always been
critical in the implementation of software systems. Many researchers have shown that
errors occur during requirements process are the most significant cause of software
defects, and over 40% of problems in the software development life cycle come from the
poor quality requirements [1].
Early detection and correction of requirements errors provide a high chance in
improving requirements quality and overcoming cost expending during the development
life cycle of software systems.
One of the purposes of this paper is to show that the requirements review is one
significant way to control requirements errors. This achieved by enterprise reviews or
walkthrough during developing SRS (Software Requirements Specification) in
requirements phase. In addition, this project has identified types of requirements errors
based on studying and research. After that, this project endeavored to introduce HeiTech
Padu with workflow on how to integrate review process in requirements phase. This
workflow can be applied during the development of SRS (Software Requirements
Specification) in order to produce quality requirements.
Another main purpose of this paper is to analyze requirements for Shared Banking
Service system. Shared Banking Services (SBS) is a counter-based transaction system
developed on top of a software framework name Hybrid Client for developing a frontend, transaction based system. SBS system offers services for selected banking used to
carry out at Post office branches. SBS system consists of two main systems which are
transaction systems and support/utility functions.
5
Technically, SBS system works based on the components provided by Hybrid
Client and Device Service Server (DSS) in its execution. The Hybrid Client components
are used to provide common services of a transaction system, while DSS used to offer
services for device sharing and device integration. The SBS system components diagram
is depicted in figure 1.2.
Shared Banking Services System
Transaction System
•Open Account
•Current, Saving account
•Deposit and Withdrawal
•Loan Repayment
•Credit Card
•Foreign Remittance
•Local Remittance
•Passbook Maintenance
•Inquiry
•Reversal
Support/Utility
•User Management
•Branch Management
•Electronic Journal
•Override
•Report facility
•Start of Day processing
•Rate Downloading
•Calculator
•Stock Control Register
Hybrid Client
.Net Framework
Device Service Server
Printer
Smart
Terminal
Figure 1.2
SBS System Components
MyKad
Reader
6
CHAPTER 2
PROJECT OBJECTIVES / SCOPES
2.1
Introduction
This chapter explains about objectives and scopes of the project. It includes
project plan that has been followed during Industrial Attachment with the project.
2.2
Project Objectives
The following section shows the objectives which need to be accomplished in
order to complete the industrial attachment.
(i)
To understand the current process that HeiTech Padu practice in requirements
phase.
(ii)
To analyze requirements for Shared Banking Services system (SBS).
(iii)
To manage and produce standard documentations which are Software
Requirement Specification (SRS), Requirement Traceability Matrix and User
Manual documents which based on requirements of Shared Banking Services
system.
7
(iv)
To study the requirements review processes during the development of SRS.
(v)
To introduce the workflow in applying review process during the development
of SRS.
2.3
Project Scopes
Scope of this project is to study requirements process based on HeiTech Padu
Berhad.
This study acts toward understanding of the steps for developing System
Requirements Specifications and applying requirements review in the requirements phase.
Furthermore, this project involves research at the key elements of requirements review
process that can be integrated while analyzing requirements. During research, this project
attempted to define the enterprise review process during the development of SRS.
Depending on the research and analysis, this project introduced approach to
improve practice of requirements review that can help HeiTech Padu to reduce
requirements errors. The introduced model has divided the process of the development of
SRS into phases prior to enterprise reviews or walkthrough process.
The other main aim of this project is to analyze the requirements in Shared
Banking Services system (SBS) for AR&D Department. In addition, SBS deliverables
are SRS and Requirement Traceability Matrix documents for SBS which followed
HeiTech Padu Berhad standard and guideline.
The project also focused on using the best practices of the software development
techniques and notations. The project includes the following notation and methodology:
(i)
Use Unified Modeling Language (UML) notation.
(ii)
Using Object-Oriented Analysis Methodology (OOA).
8
2.4
Project Plan
Kindly refer to Appendix A to view the project plan.
9
CHAPTER 3
LITERATURE STUDY
3.1
Introduction
This chapter explains about literature study carried out during Industrial
Attachment to achieve the objectives and scopes of this project.
3.2
Systems Development Life Cycle Overview
Systems Development Life Cycle (SDLC) is a framework used to structure, plan,
and control the process of developing an information system [2]. SDLC is a step-by-step
process that IT organizations practice for examining information system and improving it.
In any Systems Development Life Cycle model, there are standard phases and processes
should be followed based on the environment and tools used. However, each phase of the
Software Development Life Cycle is characterized by specific activities and the products
produced by those activities. These standards and phases included in the following stages
[3]:
10
(i)
System Initiation – this phase is the starting point of the project. It is used to
find high level view of the project and the scope of proposed solution. It also
describes costs and benefits, reexamines the proposed solution and identifies
other solution (if possible).
During this phase project charter will be
developed. Project chart describes how project scope will be managed and
how scope changes will be integrated into the project.
(ii)
System Requirement Analysis – this phase is an investigation of the project
problem and requirements. The business cases that justify the client needs
will be defined and analyzed. In this phase, project team headed by project
manager communicates with client in order to produce quality requirements.
(iii)
System Design – the design phase involves converting project requirement
into complete technical solution.
In this phase, project architecture,
specifications, standard, functions, inputs and outputs, strategies will be used
to do implementation and testing will be defined.
(i)
System Implementation – in this phase, the developers may transform the
project specification defined in Design phase into program using programming
language and development techniques. At the end of this phase, a workable
system is produced.
(ii)
System Testing – in this phase, project team ensure that the developed system
meet the client requirements. Testing phase involves three levels of test which
are unit, system integration and user acceptance testing. This phase used to
identify developed system defects or weaknesses based in the testing process.
(iii)
System Deployment – in which the developed information system must be
monitored to ensure that it is successful. This phase is the final phase of the
SDLC.
activities.
It involves maintenance, enhancement deployment and training
11
Over the past some development process took place using the Waterfall, V-Model,
RUP or another well-known methodology. In the next section, there is an overview of
RUP methodology.
3.2.1
Rational Unified Process
The Rational Unified Process (RUP) is a Software Engineering Methodology. It
provides a disciplined approach to assigning tasks and responsibilities within a
development organization. The goal of this methodology is to ensure the production of
high-quality software that meets the needs of its end-users, within a predictable schedule
and budget. The RUP methodology is shown in figure 3.1 below.
The inception phase is the start phase for any project. Inception begins when
there is a temporary idea undertaken needed to accomplish a particular goal. Then, the
research in this idea will start to manage how long this idea would take, how much it will
cost, or how possible the project is. The answers to these questions are what the inception
phase is all about.
12
Figure 3.1
Rational Unified Process Methodology
The purpose of the elaboration phase is to analyze the problem domain, establish a
sound architectural foundation, develop the project plan, and eliminate the highest risk
elements of the project.
During the construction phase, the remainder of the system is analyzed, designed,
and built. Using the architecture from the elaboration phase as a foundation, the team
will build the remainder of the system during construction. Tasks in the construction
phase include determining any remaining requirements, developing the software, and
testing the software.
The purpose of the transition phase is to shift the software product to the client
community. Once the product has been given to the end user, issues usually arise that
required to develop new releases, correct some problems, or finish the features that were
postponed
13
3.3
System Requirements Analysis Overview
System Requirements Analysis phase is one of the initial phases in the SDLC that
provides significant inputs to subsequent phases like design, implementation, testing and
maintenance. System Requirements Analysis is driven by business concerns, spastically,
system users. Hence, it addresses the data, process and interface from system user
perspective. This phase answers the question, what does the user need and want from the
new system.
In this stage, requirements are analyzed while discovered, and the analysis process
informs the discovery of further requirements. The term ‘requirements’ as used in this
study, refers to “Requirements are the description of how the system should behave, or of
a system property or attribute. They are capabilities and objectives to which software
must conform. Or in other words, they are constraints on the development process and
describe (1) User-level facilities (2) General system properties (3) Constraints on the
system and on the development of the system (Sommerville and Sawyer, 1997).” [4].
Requirements of a system can be classified into functional and non-functional
requirements. Classification of requirements is discussed in detail in section 3.2.2.
There are many strategic or techniques for performing System Requirements
Analysis. They include modern structures analysis and object oriented analysis. Modern
structured analysis is a process-centered technique used to model business requirements
for a system. The models are structured pictures that illustrate the processes, inputs,
outputs and files required to response to business events while the object-oriented
analysis (OOA) technique is used to study existing objects to determine whether they can
be reused or adapted for new usage or not. If not, new objects will be defined or existing
objects will be combined with modified objects to turn them into useful business
computing application. During object-oriented analysis, there is an emphasis on finding
and describing the objects - or concepts - in the problem domain.
Object-oriented
analysis methodology is used to clarify and amplify the Business requirements.
14
3.3.1
System Requirements Analysis Activities
A requirements analysis process is a structured set of activities which meant to
derive, validate and maintain system requirements document.
A complete process
description should include what activities are carried out, the structuring of these
activities, the inputs and output to/from the activity and tool used to support the
requirements analysis.
In performing object-oriented analysis, the purpose is to gain better understanding
of the system and its requirements. OOA requires the identification of the objects, their
data attributes, associated behavior and relationships that support the required business
system requirements. The main aim of OOA is to document the identified objects, the
data and behavior they encapsulate, plus their relationships with other objects.
Requirements are developed through requirements engineering processes.
Based on
Coarse-Grain activity model of the requirements engineering process, requirements
engineering is a process that include a set of activities which are requirements elicitation,
requirements analysis, requirements specifications and requirements validation see figure
3.2 [5]. All of these activities are described in detail in the following sections [5].
Requirements
Elicitation
User
Needs/Goals
Figure 3.2
Requirements
Analysis
Requirements
Specification
Requirements
Document
Requirements
Validation
Agreed
Requirements
Coarse-Grain Activity Model Of The Requirements Engineering Process
15
3.3.1.1 Requirements Elicitation
This activity consists of finding and identifying all the business objects and
requirements. This phase is to interpret, analyze, model and validate system information
from client. The following steps should be followed to accomplish this phase:
(i)
Find vision and scope of the system.
(ii)
Identify any functional requirements, object or inputs to which the system
must response.
(iii)
Identify any special policies, processing, decision that might be effect the
limitation of business functions and its inputs.
(iv)
Identify the normal business outputs to the business events, object or inputs.
(v)
Identify any information that must be produced or made available.
(vi)
Aligning functional requirements using use case modeling.
(vii)
Identifying the external interfaces diagram that show how the system interacts
with people, other hardware, other software, and other agencies.
One of the most popular and successful approaches used in this activity is use
case modeling. Use case modeling is the process of identifying and modeling business
functions, who initiated them, and how the system will respond to them. Use case
modeling is discussed in detail in Section 3.2.3.
Therefore, the output of requirements election phase is a formal requirements
document with use cases that represent the main functions of the system.
16
3.3.1.2 Requirements Analysis
This process is the completing activity of the requirements elicitations process.
Requirements analysis activity is concern in organize the use cases and objects and
identifying their relationships.
Requirements analysis phase analyzes the collected
requirements to determine whether are unclear, incomplete, ambiguous, inconsistencies,
contradictory or extra requirements. The purpose of this process is to map and model the
requirements as well as resolve conflicts between business requirements in order to
produce the requirements that can be verified by system users and understood by
development team.
In addition, this process involves the prioritized business
requirements to determine the degree of importance of each requirement to the system’s
users.
Requirements analysis process sometimes is done concurrently with the
requirements elicitation process. This means, this phase involves activities that elaborate
the defined use cases. This is done by adding the descriptions and scenarios to clarify in
detail the defined use cases, identifying the relationships and dependencies between the
defined use cases, and outlining use case behavior using collaboration diagram and
sequence diagram. Everyone of defined use case presents one or more scenarios that
express how the system should interact with the users. Use cases give the high-level view
of user’s perspectives and interactions with the system. Use case relationships, sequence
diagram and collaboration diagram discussed in detail in Sections 3.2.3.
In a sense, the system models bridge the communication gap that inevitably exists
between system users and development team [5]. The output of the requirements analysis
process is analysis models which can be sequence diagram, collaboration diagram and
complete use case model.
17
3.3.1.3 Requirements Specification
This process formalizes the results from the elicitation and analysis activity in a
document. The purpose of this process is to provide complete representation of the
system for the user’s review and approval. The activity of refining and elaborating the
results of the analysis process is involved in this process.
A requirements specification is a document that specify of what the system should
do and what the client needs from this system. Requirements specification should consist
not only of a specification of what the system requires, but also of additional information
that helps manage and understand the requirements. The system requirements should be
documented to form the System Requirements Specification (SRS) document.
SRS contains a complete description of the functional and nonfunctional
requirements for the system as well as identifies the input and output data needed to
satisfy the requirements.
SRS document expands the high-level diagrams in the
requirements to a lower level and supplies missing diagrams in order for all specifications
of the system to be represented in SRS. On the other hand, SRS does not offer design
suggestions, possible solutions to technology or business issues, or any other information
other than what the development team understands the user's system requirements to be
[6].
SRS is a useful vehicle for communicating ideas and for gathering specific
customer requirements.
The document should be detailed enough to allow the
implementation of the system without user involvement. The size and content of the
document, however, should reflect the size and complexity of the system. The System
Requirements Specification document should give some meaning to the product. It
describes the system requirements in a top-down manner, which allows a range of people
to review the document at their desired level of detail.
18
Therefore, the output of the requirements specification process is complete draft
of system requirements specification document that collect all system requirements with
the models used to define the requirements.
3.3.1.4 Requirements Validation
This process is the final process in system requirements analysis processes. It is
used to ensure that the proposed solution is usable and meets the business needs. It
concerns with finding problem within defined requirements.
It examines the
requirements listed in requirements document to decide whether it should be included in
this document or not. All activities included in this phase need to perform on complete
draft of system requirements specifications document. During this process, errors in the
SRS document are inevitably discovered. Requirements validation is vital because error
in SRS document may lead to expensive rework costs when they are discovered during
development phase or after the system is in service [7].
If there is any problem or error discovered while doing the requirements
validation session, it need to be reported back with further requirements and feedback.
After that, the discovered problem with requirements should be investigated in detail.
Figure 3.3 illustrates the input and output for requirements validation process. The
changes in SRS document can then be based at different process throughout the
requirements analysis phase in SDLC.
Software Requirements
Specification s document
Figure 3.3
List of problems
Agreed Action
Requirements Validation Process
19
Techniques such as reviews, prototyping, test case generating and automated
consistency analysis (tools) tend to concentrate on the coherence of the requirements
validation. The requirements review technique is discussed in detail in Section 3.3.
Requirements validation is difficult for two reasons. First, it is philosophical in
nature and concerns the question of truth and what is knowable. Second, it is social and
concerns the difficulty of reaching agreement among different clients with conflicting
goals [8].
After requirements validation process, the final approval of requirements
specification is sent to the developers for design and build phase. But, if there are some
errors of the defined requirements, the requirements management process will be
conducted.
3.3.1.5 Requirements Managements
Requirements management is the process of managing changing requirements
during the requirements analysis phase of SDLC. Requirements management process
provides the capability to control who, what, when and where change happens, the impact
of that change and how both are communicated externally. In this process, requirement
traceability document is used to find dependent requirements effected by the change. In
addition, requirements change request form is used to carry out the change request and
preparing it to be processed and managed.
To begin the requirements management process, first, the requirements problem
need to be identified and its validity to be checked. Second, the requirement problem is
analyzed to make decision whether to proceed with the requirements change or not.
Finally, the requirement change is implemented by modifying software requirements
specification document.
20
3.3.2
Classification of Requirements
Requirements of a system can be classified into functional and non functional
requirement. Functional and non functional requirements possess similar importance to
the system. Functional requirements often discord with non-functional requirements,
thus there will be requirements interdependence involved between them.
Using
functional and non-functional requirements concepts provides useful abstractions for
describing system requirements as a whole.
3.3.2.1 Functional Requirements
Functional requirements describe the service that the proposed system should
provide, tasks or functions the system is required to perform. It describes the system
function in detail, its inputs and output, expectation and flow of events. Functional
requirements are expressed by use cases. Typically, a requirements analyst generates
functional requirements after building use cases.
The functional requirements are
specified using the UML models, such as use cases, sequence and class diagram.
Modelling functional requirements deals with the preparing models for existing and
future system. Functional requirements are met by capabilities provided by the software
system.
Functional requirements also describe the communications between the system and
its environment based on its implementation. They are supported by non-functional
requirements, which impose constraints on the design or implementation (such as
performance requirements, quality standards, or design constraints).
Typically functional requirement contains a unique name and number, a brief
summary, and a rationale. This information is used to help the reader to understand why
the requirement is needed, and to track the requirement through the development of the
system.
21
3.3.2.2 on Functional Requirements
Non functional requirements describe the system service’s constraints and
limitation. It includes timing constraints and process developments constraints. It applies
to the system as a whole.
Typical non-functional requirements are hardware
considerations, performance characteristics, user interface, error handling, quality issues,
physical environment, security issues and resource issues.
Non functional requirements are used to find the “who,” “where,” “when” and
“how”.
These requirements do not influence the functionality implemented in the
system, but they play a huge role in determining how the functionality is designed and
constructed. It is very common to discover and collect these requirements while writing
use cases.
3.3.3
System Requirements Analysis Modeling
This section clarifies the models used in system requirements analysis phase of
SDLC. It discusses the models based in object-oriented analysis technique and UML
notation. The UML diagrams provide better understanding of the system. It encapsulates
the system behaviour, and the characteristics of the requirements. A description about
UML and OOA are in Chapter 4.
3.3.3.1 Use Case Model
Use case model is the process of identifying and modelling business functions,
who initiated them, and how the system responses to them. This technique is used to
discover the system requirements. It is achieved by breaking down the scope of system
functionality into many smaller statements of system functionality called use cases which
22
are initiated by users or system called actors. One advantages of use case model is that it
identifies and describes the system functions from the perspective of the system’s users.
Use cases model is a good practice for capturing functional requirements for the
system. In OOA, to capture a black-box view of the system, use case model is a good
technique for finding the ‘what’ rather than the ‘how’. Use case model is the starting
point for identifying the object of the system.
Figure 3.4
Use Case Model Steps
The following section discusses the steps involved in developing use case model.
Figure 3.4 above illustrates these steps.
23
(i)
Step 1: Identifying Actors
An actor represents anything that needs to interact with the system to
exchange information. An actor is a user or a role which can be an external
system or person. The communication between an actor and system under
development is done by sending and receiving messages to/from the system.
Actors are named with singular nouns that reflect the role of the person or
system in their relationship to the system under development in which they
are in involved.
There are two kinds of actor; active and passive. An active actor is the
one who starts the major, main, important use case in the system by supplying
the interaction across the system boundary and get some value in return. A
passive actor interacts with the system as part of the use case but does not
initiate it. A good practice to find actor is by analyzing the context model
diagram of the system. Because it illustrates the things going in and things
coming out from/to the system and it makes it easier to find out the system
actor. An actor is drawn as stick figure with the name below it.
(ii)
Step 2: Identifying Use Cases
A use case is a behaviourally related sequence of steps, both
automated and manual, for the purpose of completing a single system
function. Use case is used to model functionality of the proposed system.
Use case is an object method that connects system objects to related functions.
Use case describes who (actor) does what (communication) with the system
under development, for what purpose (goal), without dealing with the system
internals. Use case finds out the actor needs from the system. Use cases are
named with an active verb and indicate the return value required by the
system actor that starts it, either from the actor or from the system’s
perspective.
24
To identifying use case, it is needed to analyze the system context
model diagram and go through all the defined actors and define use cases for
each one. A use case is drawn as ellipse with its name inside or below it and
connected by solid lines to actor that interact with it. Each use case in the
system possess has different outcomes depending on the interaction with the
actors and particular conditions at the time it is carried out. The set of the use
cases represents all possible interaction to be represented in the system
requirements. However, since use cases focus in interactions, they are not
effective enough for electing system constraints and non-functional
requirements.
(iii)
Step 3: Constructing a Use Case Model
In this step every use case must be connected to an actor or a use case
to build a use case model diagram. A use case model diagram can be used to
graphically illustrate the system scope and boundaries in terms of use cases
and actors. This model is used to draw the basic association relationships
between actors and related use cases.
This is done by using a directed
association from an active actor to a use case and a directed association from
a use case to a passive actor. The use case model may involve partition of the
system behaviour to subsystem.
This is important in understanding the
system architecture and acts as a key in finding development strategy – which
use cases will be developed first and by whom.
(iv)
Step 4: Documenting the Use Cases
This step complements the use case model. For each identified use
case, it is needed to document the normal flow of events with text. A use case
normal flow of events is a step-by-step description starts with the actor
initiating the use case and ends with the business event. In this step, only the
major steps that occur in the majority of time are included. Furthermore, this
step concerns with documenting the name of the actor who initiates the use
25
case, a description of the use case, a normal flow of events describing the
interaction with the actor in the use case, precondition that describing the
system status before execute the use case, post-condition which describing the
state of the system after executing the use case as well as any rules or
constraints that limit the execution of the use case.
Furthermore, it is recommended to document each use case using the
template. Use case documents are written in an easy-to-understand structured
description using the vocabulary of the system domain.
This facilitates
validating and reviewing the use cases for the system users who can easily
follow and involve in defining the requirements. Later, all of the use cases
documents are combined in one document which is system requirements
specification document.
(v)
Step 5: Identifying Use Case Dependencies
This step involves defining the actor’s relationships and use cases
relationships.
Figure 3.5 illustrates these relationships and its symbol.
Identifying relationships enhances the understanding of system functionality
and it helps to identifying any missing use case.
26
Figure 3.5 Actors Relationships and Use Cases Relationships
Generalization relationships consist of superobjects and subobject –
the word “object” here may refer to actor or use case involved in this
relationship. The superobject is general which contains the common attribute
and behaviours of the hierarchy. The subobjects are specialized in a way they
contain attribute and behaviour unique to that object as well as inherit the
superobject’s attributes and behaviours.
Generalization relationships are
discovered by referring to use case model and objects that have common
attributes and behaviour. Generalization relationship is drawn as a line from
the subobject to the superobject with a large triangular arrowhead on the
superobject end as shown in figure 3.5.
27
One or more use cases may be dependent to the other use cases. There
are two type of dependency relationship, in addition to association with actor
relationship, which are extend and include relationship.
In an extend
relationship, one use case optionally extends the functionality provided by
another. This relationship is used to model optional system behavior.
An
include relationship is used whenever one use case needs to use the
functionality provided by another and it is used to model the common
behavior in one place which needs to be used in several other places. This
relationship implies that one use case always uses the other. The include
relationship points at the use case to be included; the extend relationship
points at the use case to be extended as shown in figure 3.5.
(vi)
Step 6: Document Alternative Flow in Use Cases
The previous steps of use case modelling focus on the basic flow of
use case.
This allows the concentration on the system concepts without
getting bogged down in too many details. In this step, all alternatives and
exception flows in the use case needs to be defined. The use case has one
basic flow of events and possibly many alternative and exception flows of
event. The alternative flows are deviation or branches from the normal flow.
However, the exception flow describes any predictable use case fail
conditions that may occur as use case execution fails for some unexpected
reason.
3.3.3.2 Sequence Diagram
After the use case is defined and make sure it is normal and alternative flows
documented, it is time to begin identifying the objects involved in the use cases and
prepare sequence diagram. Generally, sequence diagram describes the execution of the
28
operations. Sequence diagram is a set of sequence messages that exchange with the actor
and system objects.
Before depict the system interaction using sequence diagram, it is needed to find
the potential objects within the system. The object represents things or entities on system
domain that would like to capture information about it. Finding objects is accomplished
by reviewing the use cases to find nouns that correspond to the system entities or
function.
In OOA, objects are generally grouped into three types which are entity object,
boundary object and control object. Entity object is a meaningful chunk of information
and it often participates in different use cases to provide required functionality.
Boundary object allows actor to interact with the system since it serves as boundary layer
between the actor and entity object and perhaps it represents physical device or logical
input or output.
Control object is the coordinator of activities among entities and
boundary objects and usually control one use case. Figure 3.6 shows the types of objects
with its symbol.
Figure 3.6
Objects Types
After the system objects are identified, it is time to show communication
scenarios for these objects using sequence diagram. Sequence diagram is used to model
the behavior in a set of objects and mostly within single use case. Also, it is used to
realize the use case by showing the sequence of actions involved in a use case. Each use
case specifications related to one or more sequence diagram. Sequence diagram gives the
system developers a high level view of how the future system works.
29
In a sequence diagram, objects and actors are aligned along the top of the
diagram. An operation between objects is shown as an arrow from lifeline of object to
another one.
Boundary object is located at the initiation of the sequence diagram.
Furthermore, control object is created by boundary object while entity object is accessed
by control object. Figure 3.7 illustrates the sample of sequence diagram.
Figure 3.7
Sequence Diagram Sample
3.3.3.3 Collaboration Diagram
Sequence and collaboration diagrams show interactions, but they emphasize on
different aspect. A sequence diagram shows time sequence as geometric dimension, but
the relationships among the roles are implicit. A collaboration diagram depicts the
relationships among roles geometrically and relates messages to the connectors.
However, the time sequence is less clear since it is implied by the sequence number [9].
30
Collaboration diagram shows the sequence of messages exchanged by objects. In
collaboration diagram, the items are similar with sequence diagram. The relationships
between the objects are exposed as lines connecting to the objects. The messages between
objects are shown as labelled arrows connecting to the relevant objects along with the
message sequencing. Figure 3.8 illustrates the sample of collaboration diagram.
Figure 3.8
Collaboration Diagram Sample
3.3.3.4 State Transition Diagram
State transition diagram shows the lifecycle of an object and helps to identify the
changes to objects over time within the use case. It illustrates the object states and events
that cause transaction from one state to another. However, it does not show the data
flows within objects. Usually, there is one state transition diagram attached to an object
to describe the behavior, response, reaction of the events received. Developers will use
the state transition diagrams to get a detailed view of the pieces of the system and how
they relate.
31
An event represents the types of changes that an object may deduct, it is a
significant or noteworthy occurrence. A state is the status of an object at a moment in
time - the time between events. A transition is a communication between two states that
indicates when an event occurs, the object moves from the prior state to the subsequent
state. Each state communicates with the other by deducting events and responding to
them. When the object deducts an event, it is responding in a way that depends on its
current state. The response may lead a change to a new state. A state is represented as a
rounded rectangle and includes a brief description of the action taken in the state.
Furthermore, the labelled arrows represent stimuli which force a transaction from one
state to another [9] [10].
There are two special states; start state and stop state. The start state indicates
what state the object is in when it is first created, and it is represented by a black dot on
the diagram. The stop state shows what state the object is in just before it is destroyed,
and it is represented by a bull's eye. Figure 3.9 shows the sample of state transition
diagram.
Figure 3.9
State Transition Diagram Sample
32
3.3.4
Requirements Traceability
This section looks at determining the requirements traceability, the last step in
system requirements analysis. After those system requirements are identified, it is time
to trace each requirement in a specific objective. This traceability is used to ensure that
the software product fulfills all strategic goals and that individual requirements do not
include wrong or unrelated functionality.
The findings should be documented in a report called requirements traceability
document. Requirements traceability document is used to link the requirements to / from
their sources in other documents or people, the design phase and test cases.
The
importance of the requirement traceability document is to understand the source of
requirements, manage the scope of the project, manage changes to requirements, assess
the impact of a failure of a test on requirements and verify that all requirements of the
system fulfill the implementation phase.
Unlike requirements specification, requirements traceability is hard to manage in
a textual or document based format.
The most important thing of requirements
traceability is that it is used to show how the design and implementation of the proposed
solution is derived from the requirements. Specially, the trace must be defined between
any related non-functional requirements as well as between non-functional requirements
and the affected functional requirements for the system.
33
3.4
Requirements Review Process
This section is concerned with illustrating the importance of requirement review
process during developing the SRS document, common SRS errors, standard SRS
characteristics, possible techniques that can be used while developing SRS document for
the system and other related literature that interest in the same issue.
3.4.1
The Importance of Requirements Review
The requirements gathering in analysis phase is the critical phase in the SDLS.
The lack of understanding clients’ needs may cause the proposed system to fail. The
failure to understand the clients’ needs occur for many reasons, some of them associated
with people errors, other with process errors, or documentation errors. Every type of
errors is distributed into different classes, where each class groups similar errors together
and aiming to help development team to understand the characteristics of that class [11].
In this project, the author focused in one type of error, which is documentation
errors, to study the requirements review process and to show the importance of this
process during developing requirements phase of SDLC.
The review process is the only reliable way in system requirements analysis phase
to detect requirements errors that go against good SRS characteristics. It is recommended
to catch, and fix the errors, associated with poor understanding of clients’ needs, in the
early stage of SDLC [12]. Furthermore, the cost and effort to fix the requirements errors
after deployment phase is too high. Recent surveys and studies suggest that 44% to 80%
of all errors with the developed system are inserted in the requirements phase, and the
cost to fix these errors is between 5 and 10 times more during coding than during the
requirements analysis phase; and it costs between 100 and 200 times more during
maintenance phase of SDLC [13].
34
Requirements review process is the most effective way to reduce or remove
errors, since these errors can be easily addressed during requirements review step by
changing System Requirements Specifications document. This involves the proposed
systems’ clients, quality assurance team and system development team. Thus, it is easier
to ensure whether the development team have the same understanding about the proposed
system or not, whether this understanding is correct or not, whether it satisfies what the
clients want in the new system or not, and whether the document follows the standards
and meets the characteristics of the good SRS document to achieve the quality purpose or
not.
Hence, requirements review seeks to discover errors, gaps, additional information
or analysis needs and correct any errors occurred during the requirements analysis phase.
Clearly, requirements review is important, even if it is expected to be repeated as part of
an iterative software developments process [14].
3.4.2
SRS Errors
Prior to defining what SRS errors are, it is worth to explain the meaning of ‘Error’
used in this project. Errors are caused by mistakes made by project team members (e.g.
project manager, business analyst, user representative, designer or programmer) whilst
developing software systems. Errors may lead to defects (i.e. faults) in a software
system.
Such defects are nonconformities to stated requirements and/or to human
expectations [15].
There are different types of errors that usually occur while developing SRS
document during requirements analysis phase of SDLC. Many different types of errors
35
are possible, but the most common errors that occur can be classified in four types:
omission, inconsistency, incorrect fact, and ambiguity [16].
Omission is a common error in requirements document. In this type of error,
some necessary information of the proposed system has been uncompleted, omitted from
the SRS document or not complied with the clients’ needs. This error can happen for
instance: when using use case modeling approach to describe the requirements, a
common error is omitted of important alternative flow. The absent requirements may be
represent something essential to the client, affect one of the functions that the system
suppose to do, influence any constraints, attributes, or external interface or any other
factor. Omission error type can lead, later, to nonconforming requirements, poor product
quality, and unnecessary repair, cost, and rework. It appears directly in SRS documents
and easy for the clients to catch.
Another common form of error in requirements is inconsistency. Inconsistency
may happen if there are two requirements statements in SRS document which are
different and both cannot be true, thus they conflict each other. This type of error also
might occur if there is term used in different places of the SRS document with a different
understood meaning. This error causes a trouble to the system developers because it
confuses them, so, they cannot understand and catch the real requirements for the system.
This error type can lead to discrepancy systems’ functions.
The third common requirement error is incorrect fact. This type of error can
happen if there is some data or information regarding the proposed system is recorded in
the SRS but it is not correct. Or, some of the documented requirements in SRS cannot be
true in conditions specified for the proposed system. This error also includes wrong
assumptions, incorrect behavior of the proposed system or misunderstandings in
referencing to wrong requirements.
The fourth common error type is ambiguity. The ambiguity error in requirements
is obvious when there are some recorded requirements being unclear or confusing. An
ambiguity error caused by multiple interpretations of one requirement. Or, an ambiguous
36
technical term is used without knowing the meaning of it or without describing it clearly.
Ambiguity is a problem because different readers of the SRS document may understand
differently. An ambiguous requirement is not testable. An ambiguous requirements leads
to vague produced system that reflect wrong undershooting of clients’ needs.
3.4.3
SRS Characteristics
System Requirements Specifications document characteristics is a quality or
feature of SRS document that is typical of it. Based on the IEEE standard, the good SRS
document should be:
(i)
Correct;
(ii)
Unambiguous;
(iii)
Complete;
(iv)
Consistent;
(v)
Ranked for importance and/or stability;
(vi)
Verifiable;
(vii)
Modifiable;
(viii)
Traceable. [17].
The correct characteristic for SRS intends to have the requirements without
wrongly understanding it. So, every recorded requirement in SRS must be true in any
listed condition or constraints and does not conflict with other requirements. The correct
requirements reflect the real fact and information of clients’ needs.
The SRS document can be an unambiguous when every documented requirement
has only one interpretation of the document. An unambiguous feature makes the SRS
document clear and more understandable to the development team.
37
The complete feature for the SRS refers to the ability to specify all of the proposed
system requirements in the SRS document. This characteristic involves illustration of the
requirements associated with proposed system functionality, performance, design
constraints and external interfaces.
In addition, It is also involves full labels and
references to all figures tables, diagrams, and appendixes in the SRS and have a full
definition of all unknown term used in SRS document.
Consist attribute of SRS document is concerned with the use of one term in the
requirements document to possess similar meaning in the whole document. Or, the
specified requirement for the real clients’ needs should not be clash. This means, the term
used and the defined requirements for the system should not conflict with each other.
Consist characteristic let the proposed system requirements concert to each other and
make the SRS document, as a whole, stable and unconfused to any reader.
In SRS document, a recorded requirements specification is ranked for importance
and/or stability.
It means each requirement in it self must has an identifier.
The
Identifier indicates either the importance or the stability of that particular requirement.
Requirements that related to one system are not equally important; some essential other
may be desirable. Define the stability of the requirements reflect the opportunities to
changing this particular requirements in the future. So, ranking the requirements can give
guide to the system designer in making trade-off decision.
In SRS document, each requirement must be stated using related specifications
that represent the true clients’ needs. Requirement can be verified, involving clients, by
analysis, review, inspection, demonstration or test to discover and prove whether each
requirement has been met the clients’ needs or not.
Modifiable feature of SRS document is that every documented requirements
specification for the system can be easily modify or change. Modifiable feature require
that SRS document structures and styles for easy to use and easy to read purposes. In
addition, SRS document should include table of contents, table of figures and diagrams,
and table of appendixes to fulfill the modifiable characteristic.
38
In the SRS document, requirements for the system should be able to trace. It
means for every requirements the source and the reference should be identified. And, all
the identified requirement should collect in one place which known Requirements
Traceability Matrix document. This make easy for developer team and clients to know
the origins location for particular requirement and what the current situation for it
(modify, done, postpone).
By achieving all of these characteristics while developing SRS document, it will
reduce the chances for the trouble with the system in the future. Because, the SRS
document will contains the agreed requirements from the clients that based in the
development team understanding. The SRS document is the only trusted material will
refer during the next phases of the system development life cycle.
3.4.4
Recommended Review Techniques Can Integrate in Requirements Analysis
Phase
This section illustrates recommended technique can be used to reduce SRS
document errors. This section describes the possible techniques that can apply during
developing SRS document in requirements analysis phase of the SDLC.
All the SRS document errors can overcome by using the appropriate validation
techniques such as reviews, walkthroughs and inspections. Using reviews, scenarios, and
walkthrough to validate and verify requirements results in a more accurate requirements
specification and higher customer satisfaction [18].
The Software Requirements Specification (SRS) review is the most widely used
technique of requirements validation. It is an evaluation of the SRS in order to determine
if it is adheres to the eight standards characteristics of a good SRS listed in the section
above. A review process assures a common agreement on the requirements that satisfy
all clients’ needs of the system. Reviews are conducted according to the nature of the
organization development process. In general, the reviews process involve systems’
39
clients and group of people who read and analyze the requirements, look for problems
with the SRS document, meet to discuss these problems, and agree on a set of action to
address the identified problem.
Reviews catch 60% of the errors with the requirements [19]. The reviews process
during developing SRS document is the useful way to detect the problems with the
requirements at their insertion point because it’s cheaper in eliminating error than testing,
help to build technical knowledge, and suggest improvement to the work product [20].
Reviews process has different types which can be: formal and informal. The good formal
review technique can be used in requirements phase is inspection. However, the good
informal review technique can be used in requirements phase is walkthrough.
The basic idea for requirements inspection is a formal meeting to inspect
requirements document by one or more reviewer, after individual peroration for every
one of them has done.
It aims to detect the error with SRS document by investigate
whether the written requirements satisfy the clients. Besides, verify whether the SRS
document conforms to the organization standards or to the selected standards, and check
whether the SRS document meet the characteristics of the good SRS or not.
Requirements inspection is more effective when it involve different reviewers’
perspectives that can help in improving error finding capabilities of the inspection
process. Members for inspectors include the requirements analyst and potential users of
the documents, including designers, coders, and testers.
Requirements inspection is consider a formal review because it carries out based
in a well defined sequence steps. The requirements inspection technique has six stages
processes, which are: planning, overview, preparation, meeting, rework, and follow up.
During planning step, the requirements document will be introduced, the inspection
schedule will be identified, and the reviewer responsibilities will be defined and assigned
to the development team. The overview phase is to give more understanding to the
requirements.
The preparation step is the SRS error detection step where every
participant checks the requirements and defines the error individually. The meeting step
is the most significant because it’s the error collection step where all the participants will
meet to discuss the defined error and collect them. However, rework step is error
40
correction step where the entire meeting member will give suggestion in how to correct
the defined errors. Follow up step is the finalize step to complete the requirements
inspection process. In this step, the participants decide what the requirements document
state during the next step of the SDLC and when will be the next inspection, if it’s
required.
In contrast, the main purpose of the walkthrough is to find the SRS document
errors in order to give another alternative or suggestion help in the defined error. In this
technique, the requirements producer describes the product clearly, shows the difficulties
and the problem, ask for the other opinions and comments and discuss the other possible
way.
There are three phases need to conduct walkthrough, which are: preparation,
conduct meeting, and follow up. Preparation phase is the identification for the document
that needs to review and for the participants and their roles that they will involve in.
Furthermore, conduct meeting step is to discuss issues, questions, and comments after the
material is presented. And, define and collect the recommendation and summarize the
meeting minutes in report. Follow up step is to distribute the defined report to the
participants and decide about the current state for the reviewed document and when the
next walkthrough will be if it’s necessary.
The walkthrough process is different than inspection process.
This different
summarize in the table 3.1 according to [19].
Table 3.1 : Inspections versus Walkthroughs
Attribute
Objectives
Inspection
Walkthrough
Find problems.
Find problems.
Verify rework that is done.
Discuss alternative solutions.
Focus is on whether the product Focus is on demonstrating how
as written meets all
the product meets all
requirements.
requirements.
Decision
Inspection team makes all
Producer makes all decisions.
making
decisions based on consensus.
41
Leadership
Trained moderator.
Usually the producer.
Attendance
Peers with documented
Peers and technical managers.
attendance.
Attendance not documented.
Material presented by reader.
Material presented by producer.
Metrics
Formally required.
Optional.
Procedures
Formally documented.
Informal.
Training
Required for all participants.
No training required.
Presentation of
material
Therefore, requirements review is a common term which can include inspection
and walkthrough with meeting minutes taken. In the requirements review session, the
participants investigate the represented requirements using one or more of the available
reading techniques. Example of the reading techniques are ad-hoc and checklist-based.
The significant factor to success the review session is the level of the guidance that the
reviewer obtained in order to use these reading technique correctly to achieve the quality
goal of the requirements review session. Checklist-based consists of list of questions that
the reviewers have to answer in order to guide them in identifying the document errors
and let their attention focus in specific quality characteristics, that defined by the
organization, while reviewing the document. In other hand, in ad-hoc the reviewer is
based on their individual experience and their knowledge, no guidance.
3.4.5
Study On Related Existing Approach
Requirements review received a lot of attention in literature.
This section
introduces other defined process that aims to use requirements validation process as early
way of detection requirements errors. In addition, there is a brief of some selected
process that help the author in achieve the project objectives.
N-fold requirements inspection method is one of the methods that make the
requirements inspection significant way in early detecting of the requirements error. N-
42
fold inspection method is based in the inspection phase above. N-fold method divides the
participants in the inspection session into # small efficient teams and all teams inspect
the same requirements document in parallel [22]. N-fold inspection method aims to make
the requirements inspection repeatable by # different team.
In addition, N-fold
inspection method expects that every inspectors team will detect different errors type that
suppose is not same with the errors detected by another team. So, when the inspectors
conduct the inspection meeting they will have different issue to discuss related to the
same requirements document.
Additionally, a role-based requirement review process is another method that is
based in the reviewers’ roles.
It provides a series of quality characteristics which
describe different perspectives of the requirements quality, and let every role of the
participants concerns on different requirements quality characteristics [23]. Moreover,
every reviewer has own checklist according to his role. In this method, the quality of the
SRS requirements measured through the reviewers’ satisfactions. Furthermore, it aims to
calculate the satisfaction degree of every quality characteristics and then calculate the
satisfaction degree of the SRS quality. This method is applied in one case study and
found that most of the results are consist with the real result [23].
Two-phase requirements engineering approach is another method that focuses on
early verification and validation to reduce the errors and problem related to software
development. This approach consists of the two phases, local analysis which is an
iterative phase concentrating on eliciting, analyzing, documenting, and evaluating small
sets of related requirements, however, another phase is global analysis which is a set of
activities that complement the local analysis phase and focus on selected verification and
related business concerns of the more comprehensive set of requirements [24].
Use Case Evaluation (UCE) is another approach that focuses in inspection the use
cases to show the usability problems. This method consists of three overall activities,
which are inspection of use cases, assessment of use cases, and documentation of
evaluation [25]. The input for the first phase of this method is a collection of use cases
that describing the proposed systems’ functionality associated with brief description of
the system context usage. This phase involves two steps which are brainstorm, which the
43
evaluator goes through the use cases one by one without following any systematic
procedure, and systematic inspection, where the evaluator employs a structured procedure
for inspection of use cases [25]. Next phase is assessment of use cases which is to assess
the quality of the use cases by requires the evaluators provide some information that can
make the use case useful for inspection. In the last phase, documentation of evaluation,
all the results are combined, which contains descriptions of the problems that the
reviewers expect it to happen after developing the proposed system. Associated with
clear describing of the reason why it is seemed to be problem for the reviewers.
3.4.6
Requirements Review for HeiTech Padu Berhad
Software Requirement Specification (SRS) review is an important way for
HeiTech to control requirement quality. The review process for HeiTech Padu is shown
in figure 3.10. The most important step is Conduct Review. Quality Assurance Team,
Project Manager, Document Author and Analyst Team joined this meeting and checked
SRS based on their own skills and experiences. If there were severe errors, SRS had to
be modified and reviewed again. Otherwise, SRS could be put forward into the next
phase.
Figure 3.10
Review Process For HeiTech Padu
44
So, based on figure 3.10, it is clear that HeiTech Padue, just, conducts one review
process in requirements phase. And, this review process will be conducted once in the
end of SRS documentation process. Furthermore, if any errors detected in SRS, then it
required to conduct follow up task to review again the SRS document. Therefore, it
could be some requirements errors overpassed accidentally because the review conduct
for SRS document as a whole not as a part. The approach introduced in chapter 4 aimed
to avoid this problem.
Below is a comparison between HeiTech Padu approach in requirements review
and other existing approaches. The comparison focused in show each approach based in
what, the way for each approach and the number of evaluation of SRS in each approach.
45
Table 3.2 : Comparison Between other Approaches and HeiTech Padu Approach
Approach
Based In
The Way
umber
ame
of
Evaluation
Process for SRS
N-Fold
Based in the Divides the participants in the
Make
Inspection
inspection
inspection
into #
inspection
process
Method
phase.
small efficient teams and all
repeatable
by
teams
different team.
session
inspect
requirements
the
same
document
the
SRS
#
in
parallel.
Role-Based
Based in the Provides a series of quality
Requirements reviewers’
roles.
Review
Process
The number of SRS
characteristics which describe
evaluation is based
different perspectives of the
in the roles of the
requirements quality, and let
reviewers.
every role of the participants
concerns
on
different
requirements
quality
characteristics.
Use
Case Focuses
Evaluation
in - Consists of three activities, The number of SRS
inspection the
which are inspection of use evaluation is based
use cases to
cases, assessment of use in use case number.
show
cases, and documentation of
usability
problems.
the
evaluation.
- Inspection phase involves
two
steps
which
are
brainstorm, and systematic
inspection.
- Assessment of use cases
which
is
to
assess
the
quality of the use cases.
- Documentation
of
evaluation where all the
finding
results
are
46
combined.
- It is especially applicable to
apply in requirement phase.
HeiTech
The reviewers - The
Padu
will
Requirements review/walkth
review
procedure - Review process
consists of five activities,
will be conducted
which
once in the end of
are
review
Review
rough the SRS
preparation, conduct review,
SRS
Process
using
prepare
documentation
the
review form.
report
findings
submission,
report,
and
follow-up.
- The
process.
- If any errors
review
procedure
detected in SRS,
applies for all phases in
then it conduct
SDLC,
follow up task.
not
just
requirements phase.
for
- Review conduct
for SRS document
as a whole not as a
part.
47
3.4.7
An Approach In Integrate Review in Requirements Process
This approach is the closer approach that could make the help to the author in
achieving the objectives of this project.
According to [21], this approach aims to
integrate reviews in requirements phase. Figure 3.0.2 illustrates the workflow of this
approach.
Team
Walkthrough
Checklist,
Requirements
Deliverables
Requirements
Defects
Team
Review
Project
Charter
Requirements
Defects
Checklist,
Requirements
Deliverables
Scope
Workshop
Iteration 1
High-Level
Requirements Workshop
Iteration 2
Requirements
Defects
Requirements
Document
Detailed
Requirements
Requirements
Deliverables
Iteration 3
Requirements
Deliverables
Customer
Review
Figure 3.11
Requirements
Defects
Requirements
Deliverables
Customer
Walkthrough
Team
Inspection
An Approach In Integrate Review in Requirements Process
The approach by Ellen Gottesdiener (2002) have shown that in order to get
quality requirements document for the system under development, the requirements
phase should be divided to many iterations and integrate reviews process while
implement these iterations. This approach gives good idea for the system development
team in order to reduce the common errors that can be occurred in this phase of the
48
SDLC. At the same time, it gives the choices to the IT organization to define the proper
iterations and steps which can suit to their processes in SDLC phases.
In this approach, Ellen Gottesdiener (2002) gives some steps and instructions
should follow before start any workshops, the steps are as following:
(i)
First, define the type of models, text and diagram, that will be used to
represent and show the requirements.
(ii)
Use multiple and different formats of models which can be text and visual.
(iii)
For each requirement, there must be some attributes to be captured, such as
owner, status, and priority.
(iv)
Describe which requirements will be related to others, such as business rules
to use cases.
(v)
Decide which requirements deliverables can best be done and tested in
workshops and which will be done later, outside of workshops.
(vi)
Design the whole requirements phase as an iterative process.
(vii)
In each iteration, define the end state for each requirement (done or not yet
done).
(viii)
Apply workshops into each iteration where possible.
(ix)
For the requirement, create checklists based on the required end states.
(x)
Determine workshop deliverables based on the iteration, expected end state,
attributes, and relations.
(xi)
Create requirements traceability outline (process, tools, and procedures).
(xii)
Each workshop should be defined as a guide in 6 pages as minimum.
During each workshop, there are other instructions and steps should follow. These
steps are as following:
(i)
Make sure that the workshop participants include the direct users, subject
matter experts test and quality analysts and developers.
(ii)
Use various and different requirements models in workshops.
(iii)
Integrate reviews during the workshops.
(iv)
Use the checklists in the workshops.
49
(v)
Try to finish each expected deliverable.
(vi)
Relate requirements together and ensure the quality, free of requirements error
that described earlier.
(vii)
Document the resided requirements.
(viii)
Before end each workshop, provide a brief or show for workshop, to study
how to improve the workshop process in future.
After each workshop, there are other instructions and steps should follow. These
steps are as following:
(i)
After each workshop, do follow-up on all issues and actions regarding the
workshop.
(ii)
Transfer the results and deliverables of each workshop to all clients –
participating and non-participating clients.
(iii)
After complete all the workshops and deliver the requirements, provide a
phase debrief to study how to improve the requirements process and
requirements workshops.
(iv)
Get management support and recommendations for change.
50
CHAPTER 4
PROJECT METHODOLOGY
4.1
Introduction
This chapter explains about the methodology followed to fulfil the objectives and
scopes of this project. An appropriate methodology, models and techniques must be
defined to fit the project objectives. Furthermore, this chapter includes the tools and the
standards used.
4.2
Project Methodology
Project methodology discusses about methodology used to manage this project
from the beginning till the end. It describes the steps in the project life cycle.
The
project methodology is illustrated in figure 4.1. The required methodology for this
project began from initiation and planning, an analysis of Shared Banking Services
system, study about best practices in requirements engineering process and requirements
review process. Finally, documentation of the output was performed.
51
Figure 4. 1
Project Methodology
52
4.2.1
Phase 1: Project Initiation and Planning
Project initiation and planning phase is the beginning of this project. The purpose
of this phase is to get more information and knowledge about the research field. It
focused on the problem definition and objectives. In addition, the scope and schedule of
this project were identified in this phase. After that, some research on the background of
the project was carried out in order to decide on the methodology of the project.
This phase includes identifying of the objectives, scopes, schedule, methodology
as well as proposal for this project.
4.2.2
Phase 2: Analysis
Analysis phase consists of three steps which are: analysis of the SBS system,
literature review and survey. The analysis phase was carried out through reading and
research online journals, article and books. The aim of this phase is to gain better
understanding about research field and how to achieve the project objectives and scope.
In the end of this phase, the SBS requirements were identified using best practice in
requirements engineering.
Furthermore, the issue of integrate requirements reviews
process during developing SRS also was figured out such as common failure and feature
of SRS document as well as best practice on applying review process during developing
SRS document.
4.2.2.1 Literature Review
In this step, there were some researches done in the studies that support
requirements engineering process such as the flow, the model, the notation, the approach.
Therefore, it involved study the significant of the requirements review process in
53
reducing requirements document errors in order to get quality requirements for the
system.
4.2.2.2 Analyze SBS System
This step involved electing and analyzing the requirements for Shared Banking
Services system.
Analyzing SBS system step was done based on HeiTech system
development methodology, because the development team used this methodology which
described in Section 4.3. In this step, a detailed description explained about what the
software is supposed to do and gives the user general idea about the software. By the end
of this step, the functional and non functional requirements for SBS system were
identified and analyzed.
characterized.
In addition, the users, architecture and limitation were
Furthermore, purpose, scope and definitions for SBS system were
determined.
4.2.2.3 Survey
This step involved research and study in the issue of how to integrate
requirements reviews process during developing SRS. It is concerned with identifying
required reviews process to be applied in requirements phase of SDLC. From the survey,
the current common failures of the SRS and recommended practices to avoid it were
identified. Also, in this step the other literature that interest in the issue of ingrate
reviews process during requirement phase is described in brief.
54
4.2.3
Phase 3: Develop Documentation
This phase is the final phase of the project methodology.
It is concerned with
developing the documentation for the output of requirement phase for the SBS system.
In this phase, SRS document, requirements traceability document and Transaction user
manual for SBS were developed. While developing the SRS document, the objectoriented analysis approach and unified modeling language notation are used. These
documents were developed based on HeiTech standards, guideline and sample. These
documents are attached as appendixes for this paper.
4.2.4
Technique
This section discusses the techniques used to achieve the project objectives and
scope. The techniques used by the author to complete this project were:
(i)
Research And Reading.
(ii)
OO Approach.
(iii)
UML Notation.
4.2.4.1 Research And Reading
The research and reading method is a key technical activity that aims at achieving
the degree of understanding to accomplish particular objective. During this project, the
author used reading method to look for related information in order to fulfill the project
objectives and scopes. It helped to explore in the requirements engineering field.
55
Most of the related research paper, journals and articles were found from the
online resources.
Besides, the information was also obtained from reviewing
requirements engineering books. Those materials have assisted the research information
regarding review process and for better understanding of this project objectives and
purposes.
4.2.4.2 Object-Oriented Approach
Object-Oriented is a technique for developing models. It helps to make the
system development process stable. Object-Oriented Analysis (OOA) is the first phase of
the Object-Oriented approach. In OOA, the important item from the application domain
is represented as object.
System in OOA models as a number of objects interaction
model.
This is often a more natural way to describe the system. These items are normally
very stable. The changes normally affect one or a few items, this means that the changes
did not affect the system as a whole.
The model used in OOA consists of three parts: the use case model, the interface
description and the problem domain object model. The use case model specified the
system functionality that the system should capable to offer from the user’s perspective.
This model used actors to represents the user’s roles that they can play with the system,
while use cases represented the main functionality for the system under development.
Each use case should be supported with description illustrating the interface between one
use case to actors and other use cases. These specified in detail how the user interface
look likes when the use case was implemented. The problem domain object model
provided a conceptual picture and better understanding of the whole system.
56
A model which designed using an OOA is often easy to understand as it can be
directly related to the reality as well as easy to maintain. A model designed using OOA
is easy to represent using Unified Modelling Language. A description about UML
notation is in next section.
4.2.4.3 UML otation
As the saying goes, “A picture is worth a thousand words”. Using UML for
developing and documenting system presented a quick “Helicopter View” of the system.
UML is a graphical model notation commonly used in Object-Oriented Analysis.
UML is a group of tools and techniques for the description and definition of a
system’s behavior and architecture. It is used to provide a notation that is readable and
understandable by all business users. UML is a standard language for modelling software
requirements.
UML is a consistent language for specifying, visualizing, constructing, and
documenting the artifacts of software systems, as well as for business modeling [26].
UML is used to keep the organization’s function well-managed and up-to-date. The
UML approach clarifies the functions for the system under development that are expected
by the end users and provides an operational presentation of the functionality.
In
addition, it offers a textual annotation that can be related to any model element and is
used to add extra details about that element. UML has many diagrams capable to make
the clients state their approval about the requirement for the system under development.
The diagrams list includes the following: Use Case, Class, Collaboration, Sequence, State
chart, Activity, and Component diagrams.
57
4.2.5
Tool
Below are the software used to assist the author in completing this project.
Table 4.1 : The Software Required To Complete The Project
o
Software
Purpose
Microsoft project software was
1.
used to create Gantt chart of the
Microsoft Project 2003
project schedule. It was used to
represent project life cycle.
2.
Microsoft Office Words 2003
3.
Microsoft Office Visio 2003
Word processing software. It was
used for documentation purpose.
Microsoft Visio was used to
draw diagrams in this paper.
This software was used to create
4.
Adobe Photoshop 8.0
and edit images used in this
paper.
Rational Rose was used to create
UML model. Rational Rose is a
graphical
software
modelling
tool. This software was used as a
5.
IBM
Rational
Enterprise Edition 7.0.0
Rose
helping tool to model the SBS
system.
Example
diagram,
of
use:
Class
Use
case
Diagram,
Sequence Diagram and etc.
58
4.3
SBS System Development Methodology
The development team for SBS system is based on HeiTech software process
guidance. HeiTech Padu Berhad practices the Application Development Information
System (ADVISE) as their software process guidance for developing applications
system. It contains a practical application development processes, deliverables, checklist
and guidelines.
This ADVISE methodology was developed with input from HeiTech previous
projects experiences, current Custom Development Methodology and Rational Unified
Process (RUP) to define a set of activities and deliverables suitable for the development
of both internal and external systems [27]. The goal of this methodology is to establish
standardized requirements for application development and documentation. Furthermore,
CMMI has been adopted in this methodology as it process improvement model.
ADVISE methodology has five phases which are inception, elaboration,
construction, transition and maintenance. Inception phase gives a high level view of
project objectives based on the concurrence among all project’s clients. Elaboration
phase is to analyze the project domain, baseline the architectural foundation and develop
a project plan to present the project life cycle. Construction phase is to illustrate the
remaining requirements and integrate them into a system based on the defined
architecture and all system features tested. Transition phase is to ensure that system is
available for the client. Maintenance phase is to support, maintain and correct problems
of the software after deployment to the end users. [27].
Workflows or process areas for ADVISE are defined as the sequence of activities
performed in a business that produces a result of observable value to an individual actor
of the business. These are six core process areas and three support process areas. The
core process areas are: business modelling, requirements, analysis and design,
implementation, test, and deployment.
The support process areas are: project
management, environment, configuration and change management. Based on ADVISE,
all projects may follow all phases and process areas of the methodology. [27].
59
4.3.1
SBS Requirements Process
Requirement process is one of the process area for ADVISE methodology. SBS
system is based on ADVISE methodology. The author of this paper was involved in the
SBS requirements process phase. The following section illustrates the requirements
process tasks and activities that HeiTech Padu Berhad practices in managing requirement
for a project. Figure 4.2 depicts the requirements process and its output.
Project Initiation
Analyze the
Problem
Define The System
Business
Requirem ents
Specification
(B RS)
System
Requirem ents
Specification
(SRS)
Develop S ystem
Requirem ents
Specification (SR S)
Requirem ent
Traceability
D ocum ent
M anage Changing Requirem ents
Figure 4.2
Project Closeout
R equirem ents
Requirement Process for HeiTech Padu
First of all, the problems need to be analyzed. This phase concerns about the
definition and scope of the system’s problem. This process involves understanding the
problems and capture expectations, constraints and initial client needs using one of the
requirement techniques such as Object-Oriented technique and UML notation. Thus, the
output of this phase is the high-level view of system requirement.
Second, the system needs to be defined. This process is used to make better
understanding of the system. It involves managing the scope of the system by clarifying
use case model developing sequence diagram.
By the end of this phase, system
60
requirements are defined while the models and prototype of the system interface are
developed.
Third, the system requirements specification ought to be developed. The external
and internal interfaces and the non-functional requirements for the SBS system such as
constraints, sizing and timing requirements, quality requirements and licensing
requirements need to be identified. Then, all information collected regarding the system
and develop the System Requirements Specification (SRS) document are combined. SRS
document is to ensure that the entire client’s needs are defined, realized, verified and
determined if there are any new requirements. SRS document supports the defined
requirements with scenario, constraints and interface. After SRS document is developed,
the requirements review process is performed to evaluate the SRS document, using
System Requirement Specification Review Checklist.
Finally, change requirements process is managed. This process is to handle any
change request from the clients after the review process is conducted. This involves
reviewing the change, determining the effect of this change to the other requirements as
well as implementing this change into the system requirements. Then, all system
requirements are traced using the Requirements Traceability Document. Subsequently,
commitment in the requirements from the client is gained by ensuring that they commit to
the approved requirement and the resulting changes to the plan.
4.3.2
Standard and Guideline
Standard and guidelines is based on HeiTech application development standard
template that is being customized to suit the CMMI level 5. HeiTech Padu Berhad
possesses its own standard and guidelines which are [28]:
(i)
HeiTech Requirements Management Plan.
(ii)
HeiTech System Requirements Specification Guideline.
61
(iii)
SRS (System Requirements Specification) for SBS requirement
documentation.
(iv)
Requirements Traceability Document.
(v)
System Requirement Specification Review Checklist.
(vi)
User Manual for SBS system.
62
CHAPTER 5
PROJECT DISCUSSIO
5.1
Introduction
This chapter is based on methodologies discussed in the previous chapter. This
chapter explains about the requirements for the SBS system that the author analyzed
during industrial training. In addition, this chapter introduced one workflow which based
on the result and finding of how to integrate reviews process during developing SRS
document.
5.2
Part One: SBS System
For the SBS system, the development team used Object Oriented Analysis and
Design (OOAD) methodology in capturing the user requirement and designing the
application system. They applied the ADVISE development life cycle which is based on
process areas starting with capturing the user requirement, followed by analysis of these
requirements, designing the system and then implementing it by coding. The following
activities after that are testing the system, providing the system training, system
deployment and delivering related documents to the user or customer. For this project,
63
the author was only involved in requirement phase and prepared the User Manual for
Transaction module.
The sections below explains about capturing the requirement, use case diagram
based on user requirement, modules that were identified based on use case as well as user
interface for SBS.
5.2.1
SBS System Architecture
SBS system provides services for selected banking used to carry out at Pos office
branches. SBS has large numbers of functionalities. These functions are divided into two
subsystems which are Transaction systems and Support/Utility functions. Figure 5.1
shows the overall components view of SBS system. Table 5.1 illustrates all of the main
functions included in Transaction subsystem. Besides transaction subsystem, the SBS
system also provides several utilities for system’s users to do their task. Table 5.2 below
presents the list of the utilities provided.
64
Shared Banking Services System
Transaction System
•Open Account
•Current, Saving account
•Deposit and Withdrawal
•Loan Repayment
•Credit Card
•Foreign Remittance
•Local Remittance
•Passbook Maintenance
•Inquiry
•Reversal
Support/Utility
•User Management
•Branch Management
•Electronic Journal
•Override
•Report facility
•Start of Day processing
•Rate Downloading
•Calculator
•Stock Control Register
Hybrid Client
.Net Framework
Device Service Server
Printer
Smart
Terminal
Figure 5.1
MyKad
Reader
SBS System Components
Table 5.1 : Transaction Subsystem Functions
Functions
Transaction Description
1. SA Cash Deposit
2. SA Cash Deposit Reversal
3. CCA Cash Deposit
Deposit/Payment
4. PSV Cash Deposit
5. Loan Repayment
6. HP Payment via HP A/C No or Registration No
7. Credit Card Payment
Withdrawal
1. SA passbook Cash Withdrawal
2. SA passbookless Cash Withdrawal
1. Foreign Telegraphic Transfer
65
Remittance
2. Foreign Worker Telegraphic Transfer
3. GIRO Funds Transfer
1. SA last transaction inquiry
2. Name/IC No inquiry
3. CA last transaction inquiry
Inquiry
4. CA activity inquiry
5. Credit card inquiry
6. FTT transaction detail inquiry
7. FWTT transaction inquiry
8. GIRO transaction detail inquiry
9. HP transaction inquiry
10. Loan activity inquiry
11. SA activity inquiry
1. Open an individual savings account – passbook
Opening Account
2. Open an individual savings account – passbookless
3. Open a joint saving account – passbookless
4. Open a joint saving account – passbook
Reversal
1. Reversal by journal number
2. Reversal by electronic journal
Passbook
1. Passbook update
Maintenance
2. Change posting line
3. Change passbook status to new
1. Rounding mechanism
Others
2. Commission
3. Supervisor override
Table 5.2 : Utilities Subsystem Functions
Function
Utility Description
1. Add
2. Modify
3. List User
4. Change Password
66
User Profile
5. Force User Sign Off
6. Unlock User
7. Revoke/Unrevoke User
8. Reset Password
1. Balance Teller Total
2. Balance Branch Total
End Of Day
3. Balance Final Branch Total
4. Teller Activity Report
5. Branch Activity Report
1. Add Stock
2. Stock Distribution
3. Damaged/Lost Stock Register
Stock Control
Register
4. Stock Distribution Maintenance
5. Stock Control Register
6. View Stock Acknowledgement
1. FX Rate
2. EJ viewer
Other
3. Sign in/off
4. Start of day
Technically, SBS uses the components provided by Hybrid Client and Device
Service Server (DSS) in its execution. Hybrid Client components are to provide common
services of a transaction system. Hybrid Client is used as the transaction engine to speed
up the delivery of the proposed system. Common tasks of a transaction system such as
transaction creation, field validation, accessing database, integrating with local devices
and host access are pre-built and encapsulated within Hybrid Client.
DSS offers services for device sharing and device integration. Device Service
Server (DSS) was developed to make devices integration and device sharing easier. This
software provides a set of uniform APIs so that access to various devices can be done in a
unified manner. One of the prominent features of this server software is its ability to
67
enable integration with various devices for example printers, RFID readers, thumb print
scanners, and MyKad readers
5.2.2
External Interface Requirements
This section discusses the external interface requirements for SBS system. It is
used to identify the interfaces to other systems and external entities within the SBS
project scope. Figure 5.2 illustrates in detail the external interface requirements for SBS
system.
Bank Host
Request_Transaction
Reply_Transaction
CSCI SBS
System
Device_Demand
Device_Response
DSS
Figure 5.2
External Interface Requirements
Post office Mediator is a person who uses the SBS System to manage the banking
services at Post office branch level. This actor (which can be Manager, Officer or Teller)
communicates through the use cases. Refer to the next section to see more explanation
about user role and use cases.
68
Selected Bank’s Host is a mainframe that the Post office Mediator uses to manage
the SBS transactions at the branch level. The Selected Bank’s Host is an external
Interface that allows CSCI SBS to exchange transaction information’s through
Requist_Transaction to send requested transaction information from CSCI, and
Reply_Transaction to return back the transaction response information to CSCI.
DSS is software that provides the devices integration services for CSCI SBS
System. In CSCI SBS, With DSS, devices can be shared easily by multiple applications
from multiple workstations.
DSS enables device sharing even between different
platforms; ensuring devices that come only with drivers for Windows can still be used by
Linux applications.
DSS enables device sharing even between different platforms;
ensuring devices that come only with drivers for Windows can still be used by Linux
applications. It communicates to the CSCI through Device Demand to send the CSCI
request and Device Response to send back the device response to the CSCI.
For the internal interface requirements for CSCI SBS, Hyper Client used to speed
up the developments process for SBS system. It provides software framework to perform
and customize the common abilities for SBS components to meet the client’s needs. It
comes with a Graphical User Interface (GUI) development tool, called Hybrid Client
Studio, which can be used to create transaction screen in a standard and efficient manner.
It has component for accessing database, component for accessing devices, component
that handles communication to other systems and a simple workflow engine that enables
to set the execution flow of the system functions.
5.2.3
SBS System Use Case Diagram
The use case diagram is used to identify the primary function and process for the
SBS system. A use case is a set of scenarios that describes an interaction between a SBS
system’s users and a system. A use case diagram displays the communication and
relationship between actors and use cases. The study of the proposed system helps to
produce the use cases, and sequence diagrams. For SBS system there are thirteen use
69
cases which are Open Account, Make Cash Deposit/Payment, Withdraw Money, Inquire
Balance, Maintain Passbook, Remit Money, Reverse Transaction, Require Override, Sign
In, Manage User Profile, Perform End Of Day, Stock Control Register and View
Electronic Journal And Forex Rate use cases. The following sections describe in detail
the SBS system’s use cases. Figure 5.3 shows the use case diagram for SBS system. The
complete document of System Requirements Specification for SBS system is attached in
Appendix B.
<<extend>>
Remit Money
View Electronic Journal And Forex
Rate
Maintain Passbook
Inquire Balance
Open Account
Stock Control Register
Post Mediator
Rev erse Transaction
Sign In
<<include>>
Perf orm End of Day
<<extend>>
<<extend>>
Post Teller
Make Cash Deposit/Pay ment <<extend>>
<<extend>>
Withdraw Money
Require Ov erride
Manage User Prof ile
Post Manager Post Of f icer
Figure 5.3
Use Case Diagram for SBS System
70
5.2.3.1 User and Their Role
Interaction with the SBS system requires different user roles to create a complete
view of SBS system. Post office Mediator is a person who uses the SBS System to
manage the banking services at Post office branch level. This actor can be Manager,
Officer or Teller.
Manager is the person who has overall responsibility of staff management,
customer liaison, accounts monitoring, loans and other banking services. In other hand,
Officer is the person who supervises the Teller line and all operations processes in the
branch. Some of the Teller transactions have limitation and require Officer Override to
approve.
Teller is a person who deals directly with most customers and handles routine
banking transactions like deposits, withdrawals, and so forth. In addition, Teller usually
involve in services offered by selected bank, such as loans, open accounts, and reverse
transaction.
5.2.3.2 Sign In Use Case
This use case was initiated by Post office Branch Mediator. Its functionality is to
enable the Mediator to access the system via proper sign-in and authentication
procedures. Besides, this use case enables the users to change their password and log out
from the system. Some transactions involved in this use case are extended to Manage
User Profile Use Case. Figure 5.4 is the use case diagram for the Sign In Use Case. Refer
to section 2.2.1 of SRS document for more information about this use case.
71
<<extend>>
Sign In
Post Mediator
Figure 5.4
Manage User Profile
Sign In Use Case Diagram
5.2.3.3 Open Account Use Case
This use case provides capability for Customer to open bank account through Post
office Branch. Customer does not interact with the system directly; instead, for this use
case, a client interacts via a Post office Branch Teller. It offers different type of accounts
such as individual saving account (passbook or passbookless) or a joint saving account
(passbook or passbookless). Figure 5.5 is the use case diagram for the Open Account
Use Case. Refer to section 2.2.2 of SRS document for more information about this use
case.
Open Account
Post Teller
Figure 5.5
Open Account Use Case Diagram
5.2.3.4 Make Cash Deposit/Payment Use Case
This use case provides capability for Customer to Deposit/Payment transaction on
bank account through Post office Branch. Customer does not interact with the system
directly; instead a Customer interacts via a Post office Branch Teller. It offers services
such as SA deposit, credit card payment, loan repayment and HP payment.
Some
72
transactions involved in this use case are extended to Require Override Use Case. Figure
5.6 is the use case diagram for the Make Cash Deposit/Payment Use Case. Refer to
section 2.2.3 of SRS document for more information about this use case.
<<extend>>
Make Cash Deposit/Payment
Post Teller
Require Override
Make Cash Deposit/Payment
Figure 5.6
5.2.3.5 Withdraw Money Use Case
This use case provides capability for Customer to withdraw from his/her bank
account through Post office Branch. Customer does not interact with the system directly;
instead, a client interacts via a Post office Branch Teller. It offers services for saving
account (passbook or passbookless). Some transactions involved in this use case are
extended to Require Override Use Case. Figure 5.7 is the use case diagram for the
Withdraw Money Use Case.
Refer to section 2.2.4 of SRS document for more
information about this use case.
<<extend>>
Post Teller
Figure 5.7
Withdraw Money
Require Override
Withdraw Money Use Case Diagram
73
5.2.3.6 Inquire Balance Use Case
This use case provides capability for Post office Branch Mediator to check
whether the transaction is successful in bank Host or not. It offers different way to
inquire balance. Figure 5.8 is the use case diagram for the Inquire Balance Use Case.
Refer to section 2.2.7 of SRS document for more information about this use case.
Inquire Balance
Post Mediator
Figure 5.8
Inquire Balance Use Case Diagram
5.2.3.7 Maintain Passbook Use Case
This use case provides capability for Customer to maintain his/her bank passbook
through Post office Branch. Customer does not interact with the system directly; instead,
for this use case, a client interacts via a Post office Branch Teller. It offers services such
as update passbook, change posting line and change passbook status. Figure 5.9 is the
use case diagram for the Maintain Passbook Use Case. Refer to section 2.2.8 of SRS
document for more information about this use case.
Post Teller
Figure 5. 9
Maintain Passbook
Maintain Passbook Use Case Diagram
74
5.2.3.8 Remit Money Use Case
This use case provides capability for Customer to transfer money from one bank
account to another abroad account through Post office Branch.
Customer does not
interact with the system directly; instead a client interacts via a Post office Branch Teller.
This transaction follows the bank rules and policies for transferring money to aboard.
Figure 5.10 is the use case diagram for the Remit Money Use Case.
<<extend>>
Remit Money
Post Teller
Figure 5.10
View Electronic Journal And Forex
Rate
Remit Money Use Case Diagram
5.2.3.9 Reverse Transaction Use Case
This use case was initiated by Post office Branch Teller and requires Override
from Post office Branch Officer. It provides capability to reverse previous transaction if a
transaction is cancelled by the customer, or fails for any reason.
The Reversal can be
done using Journal number or by EJ. In this transaction, the printed voucher receipt is
used to retrieve some information to do reversal. This use case includes Require Override
use case in it execution. Figure 5.11 is the use case diagram for the Reverse Transaction
Use Case. Refer to section 2.2.6 of SRS document for more information about this use
case.
75
<<include>>
Post Teller
Figure 5.11
Reverse Transaction
Require Override
Reverse Transaction Use Case Diagram
5.2.3.10 Require Override Use Case
This use case is used to verify transactions done by Teller. The Teller requests
Override from Post office Branch Officer. This use case takes place when some criteria
of the transaction done by Teller require Officer’s approval (ex: transaction exit Teller
limit, Teller reverse transaction, etc.). The Officer, in this use case, may approve, return
the Teller transaction for some reason, or totally reject the transaction. Figure 5.12 is the
use case diagram for the Require Override Use Case. Refer to section 2.2.9 of SRS
document for more information about this use case.
Post Officer
Figure 5.12
Require Override
Post Teller
Require Override Use Case Diagram
5.2.3.11 Manage User Profile Use Case
This use case was initiated by Post office Manager. It provides the capability to
enable Manager to list existing users or add new user, modify user, force user sign off,
unlock, revoke, unrevoked and reset password of users as well as to save the data in
76
database. This use case allows the manager to manage the user profile under his/her the
branch. Figure 5.13 is the use case diagram for the Manage User Profile Use Case.
Refer to section 2.2.10 of SRS document for more information about this use case.
Manage User Profile
Post Manager
Figure 5.13
Manage User Profile Use Case Diagram
5.2.3.12 Perform End Of Day Use Case
This use case provides capability for Teller to view and print several report that
assist users during balancing. It obtains different kinds of reports for the user such as:
Teller total, Post office Branch total, final Post office Branch total, Teller activity report,
and Post office Branch activity report. Furthermore, this use case allows Manager to
perform reactivate online posting, that allow any transaction to proceed after performed
final Post office Branch total. Figure 5.14 is the use case diagram for the Perform End Of
Day Use Case. Refer to section 2.2.11 of SRS document for more information about this
use case.
<<extend>>
Post Teller
Figure 5.14
Perform End of Day
Require Override
Perform End Of Day Use Case Diagram
77
5.2.3.13 Stock Control Register Use Case
This use case is for Manager or Officer to control stock of Passbook and ATM
card. It provides capability to add Stock, distribute Stock, register damaged / lost Stock,
maintain Stock distribution, register Stock control and view Stock acknowledgement.
This use case follows the bank rules and policies during its execution. Figure 5.15 is the
use case diagram for the Stock Control Register Use Case. Refer to section 2.2.12 of
SRS document for more information about this use case.
Stock Control Register
Post Mediator
Figure 5.15
Stock Control Register Use Case Diagram
5.2.3.14 View Electronic Journal And Forex Rate Use Case
This use case was initiated by Post office Mediator. It provides capability to view
Electronic Journal. All transactions and system activities such as Start of Day, Sign In,
and Sign Off will be updated in an Electronic Journal for tracking and recovery exercises.
In addition, this use case provides utility to view and download rate provided by bank for
remittance purpose. Figure 5.16 is the use case diagram for the View Electronic Journal
And Forex Rate Use Case.
information about this use case.
Refer to section 2.2.13 of SRS document for more
78
Post Mediator
Figure 5.16
View Electronic Journal And Forex
Rate
View Electronic Journal And Forex Rate Use Case Diagram
79
5.3
SBS Sequence Diagram
For every use case of SBS system there will be one sequence diagram at least.
Sequence diagram shows the complete scenarios of communication between actors and
one use case in the system. It explains the messages among the system’s objects during
the communication. It specifies the SBS system path behaviour.
Sequence diagrams for SBS system was done using UML notation and IBM
Rational Rose tool. Figure 5.17, figure 5.18, figure 5.19 and figure 5.20 below show
some of the sequence diagrams for SBS system.
: PMB Officer
: PMB Teller
: OverrideFrm
: OverrideMngr
: SBSManager
1: Require Override
[A1: Remote
Override]
2: Show Override Dialog Box
3: Select "Local" Override
4: "Local" is Pressed
[A2: Cancel
Local Override]
5: displays "Local Override" dialog box
6: Enter "User ID" , "Password" and Clicks "OK"
[E1: Invalid "User
ID" or "Password"]
7: Submet
8: verifies "User ID" and "Password"
9: Unload Form
10: Local Override Approved
Figure 5.17
Sequence Diagram for Require Override Use Case-Basic Flow
80
: PMB Manager
: SBSFrm
: UserProfFrm : UserProfMngr
: SBSManager : Database
1: Select "User Profile"
2: Selects "Add"
3: "Add" is Pressed
[A1: Modify User], [A2: List
Users], [A3: Force User Sign
Off], [A4: Unlock User], [A5:
Revoke/Unrevoke User], [A6:
Reset Password].
4: Requist Add New User Screen
5: Load "Add New User" Screen
6: Fills in "User Information" and Clicks "OK" Button
7: Add User
8: Save Data in Database
9: Execute SQL
10: Shows Successful Message
Figure 5.18
Sequence Diagram for Manage User Profile Use Case-Basic Flow
: PMB Manager
: SBSFrm
: UserProfFrm
: UserProfMngr
: SBSManager : Database
1: Selects "Modify"
2: "Modify" is Pressed
3: Requist Modify User Screen
4: Load "Modify User" Screen
5: selects "User ID"
6: Submet Selectd "User ID"
7: Get User Info
8: Execute SQL
9: Fills in Required Information and Clicks "OK" Button
Use Case Continues
At Basic Flow No 8
10: Modify User
Figure 5.19
Sequence Diagram for Manage User Profile Use Case-Alternative Flow
81
: SBSFrm
: PMB Mediator
: StockCntrlFrm
: StockCntrlMngr
: SBSManager
: Database
1: Select "Stock Control Register"
2: Choose "Add Stock"
3: "Add Stock" is Pressed
[A1: Distribute Stock], [A2:
Register Damaged/Lost
Stock], [A3: Stock Control
Register].
4: Display Add Stock Screen
5: Load Add Stock Screen
6: Selects "Stock Type", fills in Serial Numbers
7: Submet Sreial Nos
8: Calculates Total Number of Stock
9: Display Total Number of Stock
10: Click "OK"
[A6: "Cancel"
Pressed].
11: Submet Stock Info
12: Add Stock
13: Save Data
14: Execute SQL
Figure 5.20
5.3.1
Sequence Diagram for Stock Control Register Use Case-Basic Flow
User Manual
For SBS system, the author is involved in documenting the user manual for one of
the module, which is transaction module. The transaction module is one subsystem of
SBS system. The task of document User Manual for the whole system was divided
between the author and another trainee. The User Manual is done based on HeiTech
Padu standard and guideline.
82
5.4
Part Two: Requirements Review Iteration Method
This section concerned in the result finding that the author can estimate it from the
research. The method explained, in this section, is to achieve the objective that requires
introducing a method to apply reviews process during developing System Requirements
Specification document. The method is shown in the figure 5.21 below.
83
Identify Objectives and Scope.
Define Glossary.
Name Actor.
Define Actor (description and type)
Name Use Case.
Draw Context Diagram
Define Use Case brief description.
Relate Actor with Use Case.
Determine pro and pre conditions.
Detail Use Case (basic scenario).
Collect potential objects.
Determine business rules and
constraints.
Draw Sequence and Collaboration
Diagrams to show basic scenario.
Find Non functional requirements.
o Time Constraints.
o Security Constraints.
o Maintainability.
o Design Constraints.
o Implementation Constraints.
o Hardware limitation.
Define Databases’ tables and
fields description.
Deliverable,
Checklist
Requirements
Error
Deliverable,
Checklist
Team
Walkthrough
Team
Review
Customer
Requirements Walkthrough
Error
Deliverable,
Checklist
Requirements
Error
Deliverable,
Checklist
Requirements
Error
Deliverable,
Checklist
Requirements
Error
Team
Walkthrough
Team
Inspection
Customer
Review
Finalized
Iteration 4
Define Use Case exception and
alternative scenarios.
Draw Sequence and Collaboration
Diagrams to show other scenarios.
Determine Use Cases dependencies
(Include, Extend).
Prioritize Use Cases.
Show User Interface Prototype.
Draw State Transition and Domain
Model Diagrams.
Requirements
Error
Detailed
Iteration 3
-Final Sequence
Diagram.
-Final Use Case
Model.
-Domain Model
-Final Collaboration
Diagram.
-State Transition
Diagram.
Deliverable,
Checklist
High-Level
Iteration 2
-Use Case Model
(first draft).
-Sequence
Diagram(first draft)
-Collaboration
Diagram (first
draft).
Scope
Iteration 1
-Context Diagram
-Actor Map.
SRS
Document
Figure 5.21
Requirements Review Iteration Method
The idea of Requirements Review Iteration method is to show some suggested
process to reduce the errors related to the early stage of the system development life
cycle. Requirements Review Iteration method is based on the approach described in the
84
section 3.3.5 which concerns about reviews process in requirements phase.
This
approach was chosen because It has shown to be applicable across a wide range of
contexts, and because it is among the most extensively requirements by collaboration
guidelines. This method divides the requirements phase to three iterations and integrates
the reviews process between these iterations.
Requirements Review Iteration method elaborated based on the author
understanding of the requirements analysis phase and based on implementing the
requirements processes of HieTech Padu through SBS system. The idea that the author
want to clarify through this method is that the development team should work on the
requirements analysis phase long enough to understood the system totally. This intends
that the large part of the work in SDLC is carried out during the requirements analysis
phase.
Based on the approach described in section 3.3.4, the author preferred to define
the Requirements Review Iteration method with four iterations which are: scope, highlevel, detailed, and finalized iterations. These iterations describe in the sections below.
The activities and the expected diagrams for each iterations are defined based on the
author understanding after literature study done. The goals of this method are: decrees the
number of changes to requirements after they are baselined, increase clients’ participation
during requirements phase, raise clients satisfaction with system outcome, increase the
quality of requirements and decrease the time taken in capturing the requirements.
Before start applying this method, there are some instructions that the
development team must be sure about it, which are: Identify potential participants,
recorder, and observers, assemble a planning team, draft initial vision statement, identify
iteration time constraints, refine the iteration purpose statement and schedule iteration
participants.
85
5.4.1
Iteration 1: Scope
The scope iteration is the first step in Requirements Review Iteration method.
This step aims to give an overview and introduction about the system under development.
The key aspect here is to clarify the motivation and business objectives that are driving
this project, and the scope of the project. Furthermore, this iteration gives an overall
perspective of the system—an overview of all the requirements of this system. In this
iteration detailed requirements are not required. In addition, this iteration shows the
relationship of the product to other products, to other hardware or to other peoples, it
shows the external interface. The main activities in this iteration are as below:
(i)
Identify objectives and scope for the system under development.
(ii)
Define terms that will use in the requirements by define the glossary.
(iii)
Give names for the Actors that play the main roles in the system and list all of
them.
(iv)
Define Actor by provide description for the Actor and mention the type of role
that the Actor play and define the relationship of each Actor.
(v)
Give names for the main functions that the system supposes to do and put
each function as one use case.
(vi)
Define the external interfaces for the system and map these interfaces by
drawing the Context Diagram.
After proceeding all these steps, the expected deliverable of this iteration are
Actor Map that shows the Actors and their relationships, and Context Diagram that shows
the external interface for the system under development.
Moreover, while doing all these steps, there is one type of validation needs to
apply repeatedly in order to achieve the main goals of this method. This type is team
walkthrough. Team walkthrough aims to find problems, discuss alternative solutions and
focus on representing how the defined requirements meet all customers’ needs. Through
team walkthrough, the participants receive the result of iteration steps and return the
defined errors with the requirements.
86
5.4.2
Iteration 2: High- Level
This step is the second step in Requirements Review Iteration method. This step
gives general abstract description of the functions, use case, to be performed by the
product. Schematic diagrams showing a general view of different use cases and their
relationships with other use case or Actors.
In addition, typical conditions of
implementing each functions, general constraints and rules are also specified during this
step. In this iteration, the activities required are as below:
(i)
Give a brief description for each use case to show the importance of it.
(ii)
Show the relationship between Actors with use case.
(iii)
For every use case, determine expected pro and pre conditions.
(iv)
Describe a basic scenario for each use case to show the flow of events that
happen in the majority of time.
(v)
Define and collect the potential objects.
The object represents things or
entities on system domain that would like to capture information about it
(vi)
For each use case, determine business rules and constraints that limit the
implementation of the use case.
(vii)
Represent the use case basic scenario flows with the defined objects by
drawing the Sequence Diagram and Collaboration Diagram.
After complete all these steps, the expected deliverable of this iteration are Use
Case Model (first draft) which shows the relationships between use cases and Actors,
Sequence and Collaboration Diagrams (first draft) which represent the use case basic
flow. In this Iteration it recommended to have a guideline in how to do Use Case Model,
Sequence Diagram and Collaboration Diagram. And also, standards of use case document
need to use.
Moreover, while doing all that steps, there are two type of validation needs to
apply frequently in order to achieve the main goals of this method. They are team review
and customer walkthrough. Team review includes inspection and walkthrough between
the development team. Customer walkthrough aims to find problems, and check on
87
represented diagrams how the defined requirements meet all customers’ needs. Through
this tow types, the participants receive the result of iteration steps and give back the
defined errors with the requirements.
5.4.3
Iteration 3: Detailed
The detailed step is the third step in Requirements Review Iteration method. It
describes the detailed capabilities of each use case by explaining the exceptions flows
and alternative flows for each use case. The use case has one basic flow of events and
possibly many alternative and exception flows of event. In addition, the graphical user
interface may prototyped in this step. Furthermore, the relationships between the defined
objects are specified. In this iteration, the activities required are as below:
(i)
Describe and define use case exceptions and alternatives flows that are based
in the basic use case flows.
(ii)
Represent the exceptions and alternatives flows by drawing the Sequence and
Collaboration Diagrams.
(iii)
Determine and define use cases dependencies relationship which can be
Include or Extend.
(iv)
Prioritize use cases to show the use case implementation priority.
(v)
Prototype graphical user interface for each use case.
(vi)
Draw State Transition diagram to show the main states for each use case and
represent the relationships between the defined objects by drawing the
Domain Model Diagram.
After complete all these steps, the expected deliverable of this iteration are Use
Case Model (final draft) which shows the relationships between use cases and Actors,
Sequence and Collaboration Diagrams (final draft) which represent all the use case flows.
In addition, the other expected deliverables are Domain Model and State Transition
Diagram. In this Iteration it recommended to have guidelines in how to develop the
expected deliverables. And also, standards of use case document need to use.
88
Moreover, through doing all these steps, there is one type of validation needs to
integrate repeatedly in order to achieve the main goals of this method. This type is team
walkthrough. Team walkthrough aims to find problems, discuss alternative solutions and
focus on representing how the defined requirements meet all customers’ needs. Through
team walkthrough, the participants receive the result of iteration steps and return the
defined errors with the requirements.
5.4.4
Iteration 4: Finalized
This step is the last step in Requirements Review Iteration method. From it name,
it means complete the requirement phase and combine all the defined use cases, Actors,
objects, scenarios, description and all diagrams in System Requirements Specification
document. In this step, both static and dynamic performance requirements are specified.
All the requirements that can consider as non functional requirements are defined (e.g.,
time constraints, security, Maintainability, design and implementation constraints and
hardware limitation). In this iteration, the activities required are as below:
(i)
Find and describe non functional requirements.
(ii)
Describe the database that the system needs in order to achieve the functions
and define databases’ tables and fields’ description.
(iii)
Prepare the final copy of System Requirements Specification by combining all
the defined requirements, descriptions, constraints and diagrams.
In this iteration, it recommended to use SRS standards and guideline to document
the requirements correctly.
Team inspection and customer walkthrough are also
recommended to apply during and after finish this iteration. Through this tow types, the
participants receive the result of iterations steps and give back the defined errors with the
requirements. Team inspection aims to verify rework that is done to find any errors or
problems and makes decisions based on consensus.
89
CHAPTER 6
COCLUSIO
6.1
Conclusion And Recommendation
As a conclusion, Industrial Attachment serves as learning process that exposed the
author to real life working environment as part of an academic curriculum. It helps the
author to develop and enhance academic, personal as well as professional competencies.
Five months of Industrial Attachment in HeiTech Padu Berhad, the author has
acquired knowledge and gained practical experience in the real working environment.
Therefore, the author has learnt business skills and practices which relates to the software
process approaches such as system analysis and requirement. Furthermore, the author has
successfully enhanced the communication and presentation skills (oral and written).
The author also took the opportunity to get to know how people (e.g. senior
engineers) analyze and solve problems, including their attitude towards them.
Undoubtedly, this will dramatically influence the way the author used to think and work
in future. Having learned the experiences of others enabled the author to analyse and
produce a better way to solve own problems and simultaneously practise the innovation
and creativity.
The author believes that this remarkable experience may assist in
adjusting more effectively and efficiently to future employment as well as in adapting the
foreign work environments during overseas assignments.
90
As future work, the author plan to apply the requirement review iteration
approach in one case study to see the effective of this approach.
And also it is
recommended to apply methods and tools in detecting requirement errors during
requirement phase for any system under development. Furthermore, the future it is
recommended to develop and use tools that analyze text and identify the errors with SRS
document.
91
REFERECES
1. The
Standish
Report
(2004).
Retrieved
On
October
20,
2008,
from
http://www.standishgroup.com
2. CMS, Office of Information Services. (2005, February). Selecting A Development
Approach. Retrieved On January 12, 2009, from http://www.cms.hhs.gov
3. Section III: System Development Life Cycle. Retrieved On January 13, 2009, from
http://www.oft.state.ny.us
4. Sommerville I. and Sawyer P. (1997). Requirements Engineering – A good practice
guide. John Wiley and Sons.
5. Requirements Engineering Process.
Retrieved On January 14, 2009, from
http://www.tbrc.fi/pubfilet/TBRC_500000178.pdf
6. SpringLink, Introduction to Requirements Engineering. Retrieved On January 15,
2009, from https://www.springerlink.com
7. Sommerville, Ian. (2004). Software Engineering (7th ed.). Addison Welsley.
8. Nuseibeh, B. and Easterbrook, S. Requirements Engineering: A Roadmap. Retrieved
On January 16, 2009, from http://citeseerx.ist.psu.edu
9. Rumbaugh, J.
, Jacobson, I.
nd
and Booch, G. (2005).
Language Reference Manual (2 ed.). Addison Welsely.
The Unified Modeling
92
10. Yousp, O. (2008).
Software Specification II.
Center for Advanced Software
Engineering.
11. Gursimran Walia and Jeffrey C. Carver. Using Error Abstraction and Classification
to Improve Quality of Requirements: Conclusions after Three Controlled
Experiments, Department of Computer Science and Engineering, Mississippi State
University.
Retrived
On
Febraury
23,
2009,
from
http://www.cse.msstate.edu/research/
12. IEEE.
IEEE Recommended Practice for Software Requirements Specifications.
IEEE Std 830-1998. 1998
13. Eberlein
A.
(1997).
Requirements
Acquisition
and
Specification
for
Telecommunication Services. Ph.D. Thesis. University of Wales, Swansea, UK.
Retrived On Febraury 24, 2009, from http://www2.enel.ucalgary.ca
14. Ronald J. L. (2000). Introduction to Software Engineering. Washington: CRC Press.
15. Quality standards Defect measurement manual (2000).
1.a. United Kingdom
Software Metrics Association, Metrics Practices Committee.
16. Jalote, P.
(2008).
A Concise Introduction to Software Engineering.
London:
Springer.
17. United Kingdom Software Metrics Association. Quality Standards Defect
Measurement Manual.
(2000).
Retrieved On February 17,
2009, from
http://www.uksma.co.uk
18. Ralph R. Y. (2002). Recommended Requirements Gathering Practices. The Journal
of Defense Software Engineering. 9-12.
19. Rakitin S. R. Software Verification and Validation for Practitioners and Managers
(2nd ed.). Artech House.
93
20. Ibrahim, S.
(2008). Quality and Integration.
Center for Advanced Software
Engineering.
21. Gottesdiener, E. (2002). Requirements by Collaboration: Workshops for Defining
#eeds. Addison Welsley.
22. Kantorowitz, E., Guttman, A., Arzi, L. (1997). The performance of the N-fold
requirement inspection method.
Requirements Engineering.
2 (3), 152-164.
Retrieved On March 4,2009, from http://www.springerlink.com
23. Li, J., Hou, L., Qin, Z., Wang, Q., and Chen, G. (2008). An Empirically–Based
Process to Improve the Practice of Requirement Review. In Wang, Q. (Ed.), Pfhal,
D. (Ed.), Raffo, D. M. (Ed.) Making Globally Distributed Software Development a
Success Story. (pp 135-146). Heidelberg: Springer Berlin.
24. Lobo L., O. and Arthur J., D. Local and Global Analysis: Complementary Activities
for Increasing the Effectiveness of Requirements Verification and Validation.
Proceedings of ACM Southeast Regional Conference. 2005. 256 – 261.
25. Hornbæk, K., Haegh, R. T., Pedersen, M. B., and Stage, J. (2007). Use Case
Evaluation (UCE): A Method for Early Usability Evaluation in Software
Development. In Baranauskas, C. (Ed.) , Palanque, P. (Ed.), Abascal, J. (Ed.),
Junqueira Barbosa, S.D. (Ed.) Human-Computer Interaction – I#TERACT 2007.
(pp 578-591). Heidelberg: Springer Berlin.
26. OMG Unified Modeling Language Specification. (1999). Retrieved On February 4,
2009, from http://www.scribd.com
27. ADVISE Requirement Management Plan, HEITECH Application Development
Methodology Repository, 2009.
28. HEITECH Project Deliverables. Retrieved On
http://ekms.heitech.com.my
October 21, 2008, from
94
Appendix A
95
Project Plan – IA Gantt Chart
96
Appendix B
97
SYSTEM REQUIREMETS SPECIFICATIO FOR SBS PROJECT
98
HEITECH PADU BERHAD
SYSTEM REQUIREMETS SPECIFICATIO
For
SBS PROJECT
SBS Project System Requirements Specification (SRS)
i
© HeiTech Padu Berhad, Kuala Lumpur, 2000.
Company Number: 310628-D
All rights reserved. No part of this publication may be reprinted, reproduced, stored
in a retrieval system or transmitted, in any form or by any means, without the prior
permission in writing from the owners.
First published and distributed in January, 2008.
SBS Project System Requirements Specification (SRS)
i
Document Authorization
© HeiTech Padu Berhad
DOCUMET AUTHORIZATIO
The enclosed document has been reviewed and accepted by the following people:
HeiTech Padu Berhad
NAME
POSITION
En. Kairol Amin Mohd
Head of ARAD
Pn. Suzana Bee Abd Kader
Project Manager
Noorhafizah Mat Syned
SIGNATURE
DATE
SIGNATURE
DATE
Sr Software Engineer
Owner/Stakeholders
NAME
POSITION
SBS Project System Requirements Specification (SRS)
i
Document Amendment Register
© HeiTech Padu Berhad
DOCUMET AMEDMET REGISTER
The enclosed document has been amended by the following description:
O.
DATE
REASO
CHAPTER
VERSIO
AUTHOR
1.
2.
3.
4.
5.
6.
7.
SBS Project System Requirements Specification (SRS)
ii
Table of Contents
© HeiTech Padu Berhad
TABLE OF COTETS
DOCUMENT AUTHORIZATION........................................................................................... I
DOCUMENT AMENDMENT REGISTER .......................................................................II
TABLE OF CONTENTS................................................................................................... III
LIST OF FIGURES ...................................................................................................... VIII
LIST OF TABLES .......................................................................................................... IX
1. INTRODUCTION ..................................................................................................... 1
1.1 PURPOSE ..................................................................................................... 1
1.2 SCOPE ......................................................................................................... 1
1.3 DEFINITIONS, ACRONYMS, AND ABBREVIATIONS ................................................ 1
1.4 REFERENCES ................................................................................................. 2
1.5 OVERVIEW ................................................................................................... 2
2. SYSTEM SPECIFICATION .......................................................................................... 4
2.1 SYSTEM INTERFACES SPECIFICATION ................................................................ 4
2.1.1
EXTERNAL INTERFACE REQUIREMENTS ........................................................ 4
2.1.1.1
2.1.1.2
2.1.1.3
2.1.2
INTERNAL INTERFACE REQUIREMENTS ........................................................ 5
2.1.2.1
2.1.2.2
2.2
INTERFACE POST MEDIATOR/CSCI SBS ............................................... 4
INTERFACE BANK HOST/CSCI SBS ..................................................... 5
INTERFACE DSS/CSCI SBS ............................................................. 5
HYBIRD CLIENT............................................................................. 5
CLICKONCE ................................................................................. 6
2.1.3
HARDWARE INTERFACE ........................................................................... 6
SYSTEM FUNCTIONAL REQUIREMENTS ............................................................... 7
2.2.1
USE CASE SIGN IN ................................................................................ 8
2.2.1.1 BRIEF DESCRIPTION ....................................................................... 8
2.2.1.2 CHARACTERISTICS OF ACTIVATION ...................................................... 8
2.2.1.3 PRE-CONDITION ........................................................................... 8
2.2.1.4 DESCRIPTION ............................................................................... 8
2.2.1.4.1 BASIC FLOW ...................................................................... 8
2.2.1.4.2 ALTERNATIVE FLOW ............................................................. 9
2.2.1.4.3 EXCEPTIONAL FLOW ............................................................. 9
2.2.1.5 POST CONDITION ........................................................................ 10
2.2.1.6 RULES ...................................................................................... 10
2.2.1.7 CONSTRAINTS............................................................................. 10
2.2.1.8 GUI ........................................................................................ 11
2.2.2
USE CASE OPEN ACCOUNT..................................................................... 12
2.2.2.1 BRIEF DESCRIPTION ..................................................................... 12
2.2.2.2 CHARACTERISTICS OF ACTIVATION .................................................... 12
2.2.2.3 PRE-CONDITION ......................................................................... 12
2.2.2.4 DESCRIPTION ............................................................................. 12
2.2.2.4.1 BASIC FLOW ..................................................................... 12
2.2.2.4.2 ALTERNATIVE FLOW ............................................................ 13
2.2.2.4.3 EXCEPTIONAL FLOW ............................................................ 16
2.2.2.5 POST CONDITION ........................................................................ 16
2.2.2.6 RULES ...................................................................................... 16
2.2.2.7 CONSTRAINTS............................................................................. 16
2.2.2.8 GUI ........................................................................................ 17
2.2.3
USE CASE MAKE CASH DEPOSIT/PAYMENT................................................. 18
2.2.3.1
2.2.3.2
2.2.3.3
2.2.3.4
BRIEF DESCRIPTION ..................................................................... 18
CHARACTERISTICS OF ACTIVATION .................................................... 18
PRE-CONDITION ......................................................................... 18
DESCRIPTION ............................................................................. 18
SBS Project System Requirements Specification (SRS)
iii
Table of Contents
© HeiTech Padu Berhad
2.2.3.4.1 BASIC FLOW ..................................................................... 18
2.2.3.4.2 ALTERNATIVE FLOW ............................................................ 19
2.2.3.4.3 EXCEPTIONAL FLOW ............................................................ 22
2.2.3.5 POST CONDITION ........................................................................ 23
2.2.3.6 RULES ...................................................................................... 23
2.2.3.7 CONSTRAINTS............................................................................. 23
2.2.3.8 GUI ........................................................................................ 24
2.2.4
USE CASE WITHDRAW MONEY ................................................................ 25
2.2.4.1 BRIEF DESCRIPTION ..................................................................... 25
2.2.4.2 CHARACTERISTICS OF ACTIVATION .................................................... 25
2.2.4.3 PRE-CONDITION ......................................................................... 25
2.2.4.4 DESCRIPTION ............................................................................. 25
2.2.4.4.1 BASIC FLOW ..................................................................... 25
2.2.4.4.2 ALTERNATIVE FLOW ............................................................ 26
2.2.4.4.3 EXCEPTIONAL FLOW ............................................................ 27
2.2.4.5 POST CONDITION ........................................................................ 28
2.2.4.6 RULES ...................................................................................... 28
2.2.4.7 CONSTRAINTS............................................................................. 28
2.2.4.8 GUI ........................................................................................ 28
2.2.5
USE CASE REMIT MONEY ...................................................................... 29
2.2.5.1 BRIEF DESCRIPTION ..................................................................... 29
2.2.5.2 CHARACTERISTICS OF ACTIVATION .................................................... 29
2.2.5.3 PRE-CONDITION ......................................................................... 29
2.2.5.4 DESCRIPTION ............................................................................. 29
2.2.5.4.1 BASIC FLOW ..................................................................... 29
2.2.5.4.2 ALTERNATIVE FLOW ............................................................ 30
2.2.5.4.3 EXCEPTIONAL FLOW ............................................................ 32
2.2.5.5 POST CONDITION ........................................................................ 32
2.2.5.6 RULES ...................................................................................... 32
2.2.5.7 CONSTRAINTS............................................................................. 33
2.2.5.8 GUI ........................................................................................ 34
2.2.6
USE CASE REVERSE TRANSACTION........................................................... 35
2.2.6.1 BRIEF DESCRIPTION ..................................................................... 35
2.2.6.2 CHARACTERISTICS OF ACTIVATION .................................................... 35
2.2.6.3 PRE-CONDITION ......................................................................... 35
2.2.6.4 DESCRIPTION ............................................................................. 35
2.2.6.4.1 BASIC FLOW ..................................................................... 35
2.2.6.4.2 ALTERNATIVE FLOW ............................................................ 36
2.2.6.4.3 EXCEPTIONAL FLOW ............................................................ 36
2.2.6.5 POST CONDITION ........................................................................ 36
2.2.6.6 RULES ...................................................................................... 37
2.2.6.7 CONSTRAINTS............................................................................. 37
2.2.6.8 GUI ........................................................................................ 37
2.2.7
USE CASE INQUIRE BALANCE.................................................................. 38
2.2.7.1 BRIEF DESCRIPTION ..................................................................... 38
2.2.7.2 CHARACTERISTICS OF ACTIVATION .................................................... 38
2.2.7.3 PRE-CONDITION ......................................................................... 38
2.2.7.4 DESCRIPTION ............................................................................. 38
2.2.7.4.1 BASIC FLOW ..................................................................... 38
2.2.7.4.2 ALTERNATIVE FLOW ............................................................ 39
2.2.7.4.3 EXCEPTIONAL FLOW ............................................................ 41
2.2.7.5 POST CONDITION ........................................................................ 41
2.2.7.6 RULES ...................................................................................... 41
2.2.7.7 CONSTRAINTS............................................................................. 41
2.2.7.8 GUI ........................................................................................ 41
2.2.8
USE CASE MAINTAIN PASSBOOK.............................................................. 42
2.2.8.1
2.2.8.2
2.2.8.3
BRIEF DESCRIPTION ..................................................................... 42
CHARACTERISTICS OF ACTIVATION .................................................... 42
PRE-CONDITION ......................................................................... 42
SBS Project System Requirements Specification (SRS)
iv
Table of Contents
© HeiTech Padu Berhad
2.2.8.4 DESCRIPTION ............................................................................. 42
2.2.8.4.1 BASIC FLOW ..................................................................... 42
2.2.8.4.2 ALTERNATIVE FLOW ............................................................ 43
2.2.8.4.3 EXCEPTIONAL FLOW ............................................................ 44
2.2.8.5 POST CONDITION ........................................................................ 44
2.2.8.6 RULES ...................................................................................... 44
2.2.8.7 CONSTRAINTS............................................................................. 44
2.2.8.8 GUI ........................................................................................ 45
2.2.9
USE CASE REQUIRE OVERRIDE ............................................................... 46
2.2.9.1 BRIEF DESCRIPTION ..................................................................... 46
2.2.9.2 CHARACTERISTICS OF ACTIVATION .................................................... 46
2.2.9.3 PRE-CONDITION ......................................................................... 46
2.2.9.4 DESCRIPTION ............................................................................. 46
2.2.9.4.1 BASIC FLOW ..................................................................... 46
2.2.9.4.2 ALTERNATIVE FLOW ............................................................ 47
2.2.9.4.3 EXCEPTIONAL FLOW ............................................................ 48
2.2.9.5 POST CONDITION ........................................................................ 48
2.2.9.6 RULES ...................................................................................... 48
2.2.9.7 CONSTRAINTS............................................................................. 48
2.2.9.8 GUI ........................................................................................ 48
2.2.10
USE CASE MANAGE USER PROFILE ........................................................... 49
2.2.10.1 BRIEF DESCRIPTION ................................................................... 49
2.2.10.2 CHARACTERISTICS OF ACTIVATION .................................................. 49
2.2.10.3 PRE-CONDITION ........................................................................ 49
2.2.10.4 DESCRIPTION ........................................................................... 49
2.2.10.4.1 BASIC FLOW ..................................................................... 49
2.2.10.4.2 ALTERNATIVE FLOW ............................................................ 50
2.2.10.4.3 EXCEPTIONAL FLOW ............................................................ 51
2.2.10.5 POST CONDITION ...................................................................... 51
2.2.10.6 RULES .................................................................................... 51
2.2.10.7 CONSTRAINTS ........................................................................... 51
2.2.10.8 GUI ...................................................................................... 52
2.2.11
USE CASE PERFORM END OF DAY ............................................................ 53
2.2.11.1 BRIEF DESCRIPTION ................................................................... 53
2.2.11.2 CHARACTERISTICS OF ACTIVATION .................................................. 53
2.2.11.3 PRE-CONDITION ........................................................................ 53
2.2.11.4 DESCRIPTION ........................................................................... 53
2.2.11.4.1 BASIC FLOW ..................................................................... 53
2.2.11.4.2 ALTERNATIVE FLOW ............................................................ 54
2.2.11.4.3 EXCEPTIONAL FLOW ............................................................ 54
2.2.11.5 POST CONDITION ...................................................................... 54
2.2.11.6 RULES .................................................................................... 54
2.2.11.7 CONSTRAINTS ........................................................................... 55
2.2.11.8 GUI ...................................................................................... 55
2.2.12
USE CASE STOCK CONTROL REGISTER ...................................................... 56
2.2.12.1 BRIEF DESCRIPTION ................................................................... 56
2.2.12.2 CHARACTERISTICS OF ACTIVATION .................................................. 56
2.2.12.3 PRE-CONDITION ........................................................................ 56
2.2.12.4 DESCRIPTION ........................................................................... 56
2.2.12.4.1 BASIC FLOW ..................................................................... 56
2.2.12.4.2 ALTERNATIVE FLOW ............................................................ 57
2.2.12.4.3 EXCEPTIONAL FLOW ............................................................ 59
2.2.12.5 POST CONDITION ...................................................................... 59
2.2.12.6 RULES .................................................................................... 59
2.2.12.7 CONSTRAINTS ........................................................................... 59
2.2.12.8 GUI ...................................................................................... 59
2.2.13
USE CASE VIEW ELECTRONIC JOURNAL AND FOREX RATE .............................. 60
2.2.13.1
2.2.13.2
BRIEF DESCRIPTION ................................................................... 60
CHARACTERISTICS OF ACTIVATION .................................................. 60
SBS Project System Requirements Specification (SRS)
v
Table of Contents
© HeiTech Padu Berhad
2.2.13.3 PRE-CONDITION ........................................................................ 60
2.2.13.4 DESCRIPTION ........................................................................... 60
2.2.13.4.1 BASIC FLOW ..................................................................... 60
2.2.13.4.2 ALTERNATIVE FLOW ............................................................ 61
2.2.13.4.3 EXCEPTIONAL FLOW ............................................................ 61
2.2.13.5 POST CONDITION ...................................................................... 61
2.2.13.6 RULES .................................................................................... 61
2.2.13.7 CONSTRAINTS ........................................................................... 61
2.2.13.8 GUI ...................................................................................... 61
3. DATA SPECIFICATION ........................................................................................... 62
3.1 TELLER ...................................................................................................... 62
3.2 TRANSLOG.................................................................................................. 64
3.3 UPLCNTRL .................................................................................................. 65
3.4 BRANCH ..................................................................................................... 66
3.5 USER ......................................................................................................... 67
4. CONSTRAINTS ..................................................................................................... 68
4.1 SOFTWARE STANDARD COMPLIANCE ..................................................... 68
4.2 SOFTWARE LIMITATIONS ....................................................................... 68
4.3 HARDWARE LIMITATIONS ...................................................................... 68
4.4 SOFTWARE DEVELOPMENT ..................................................................... 68
4.5 USER COMMUNICATIONS AND SUPPORT ............................................... 69
4.6 SYMBOLS AND TERMINOLOGY ............................................................... 69
4.7 USER DISPLAY ........................................................................................ 69
5. SIZING AND TIMING REQUIREMENTS........................................................................ 70
6. EXCEPTIONAL SITE/BRANCHES REQUIREMENTS......................................................... 71
7. QUALIFICATION REQUIREMENTS ............................................................................. 72
7.1 QUALIFICATION METHODS..................................................................... 72
8. QUALITY REQUIREMENTS ...................................................................................... 73
8.1 RELIABILITY ........................................................................................... 73
8.2 MODULARITY .......................................................................................... 73
8.3 MAINTAINABILITY ................................................................................. 73
8.4 SECURITY ................................................................................................ 73
9. ASSUMPTIONS AND DEPENDENCIES ......................................................................... 75
10. LICENSING REQUIREMENTS ................................................................................... 76
11. SBS CONFIGURATION REQUIREMENTS ............................................................... 77
11.1 SBS HIGH-LEVEL ARCHITECTURE .................................................................. 77
11.1.1
SYSTEM CONFIGURATION FOR SELECTED BANK ........................................... 77
11.1.1.1 BRIEF DESCRIPTION ................................................................... 77
11.1.1.1.1 SELECTED BANK ADMINISTRATOR LOGIN ................................... 78
11.1.1.1.2 BRANCH CONFIGURATION ..................................................... 78
11.1.1.1.3 MANAGER CONFIGURATION ................................................... 79
11.1.1.1.4 USER PROFILE .................................................................. 82
11.1.1.1.4.1 CHANGE PASSWORD ...................................................... 82
11.1.1.1.4.2 RESET PASSWORD ........................................................ 82
11.1.1.1.4.3 UPDATE PROFILE .......................................................... 82
11.1.1.1.5 TABLE MAINTENANCE .......................................................... 82
11.1.1.1.5.1 ADD TABLE ................................................................. 83
11.1.1.1.5.2 UPDATE/VIEW TABLE .................................................... 83
11.1.1.1.5.3 DELETE TABLE ............................................................. 84
11.1.1.1.6 VIEW ARCHIVE .................................................................. 85
11.1.2
SYSTEM CONFIGURATION FOR POST OFFICE ............................................... 85
11.1.2.1 BRIEF DESCRIPTION ................................................................... 85
11.1.2.1.1 POST OFFICE ADMINISTRATOR LOGIN ...................................... 85
11.1.2.1.2 MANAGER CONFIGURATION ................................................... 85
APPENDIX A: GRAPHICAL USER INTERFACE .............................................................. A-1
SBS Project System Requirements Specification (SRS)
vi
© HeiTech Padu Berhad
Table of Contents
APPENDIX B: SBS SEQUENCE DIAGRAMS .............................................................. B-1
APPENDIX C: SBS REQUIREMENTS TRACEABILITY DOCUMENT...........................C-1
SBS Project System Requirements Specification (SRS)
vii
© HeiTech Padu Berhad
List of Figures
LIST OF FIGURES
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
2.1: External Interface Requirements ..................................................................... 4
2.2: SBS System Use Case Diagram ........................................................................ 7
2.3: Use Case Sign In ............................................................................................ 8
2.4: Use Case Open Account ................................................................................ 12
2.5: Use Case Make Cash Deposit/Payment .......................................................... 18
2.6: Use Case Withdraw Money ............................................................................ 25
2.7: Use Case Remit Money ................................................................................. 29
2.8: Use Case Reverse Transaction ....................................................................... 35
2.9: Use Case Inquire Balance.............................................................................. 38
2.10: Use Case Maintain Passbook........................................................................ 42
2.11: Use Case Require Override .......................................................................... 46
2.12: Use Case Manage User Profile ..................................................................... 49
2.13: Use Case Perform End of Day ...................................................................... 53
2.14: Use Case Stock Control Register .................................................................. 56
2.15: Use Case View Electronic Journal And Forex Rate ......................................... 60
11.1: High Level Architecture View of SBS ............................................................ 77
SBS Project System Requirements Specification (SRS)
viii
© HeiTech Padu Berhad
List of Tables
LIST OF TABLES
Table
Table
Table
Table
Table
Table
Table
Table
Table
Table
Table
Table
1.1: Definitions, Acronyms, and Abbreviations .......................................................... 2
1.2: Overview ........................................................................................................ 3
2.1: Password Expiry Period .................................................................................. 11
2.2: Deposit/Payment Rounding Adjustment Mechanism ......................................... 24
2.3: Rounding Mechanism for Remittance Amount.................................................. 34
3.1: Table TELLER ................................................................................................ 63
3.2: Table TRANSLOG ........................................................................................... 65
3.3: Table UPLCNTRL ........................................................................................... 65
3.4: Table BRANCH .............................................................................................. 66
3.5: Table USER ................................................................................................... 67
7.1: Qualification methods for CSCI SBS ................................................................ 72
11.1: Teller/Transaction Limit ................................................................................ 83
SBS Project System Requirements Specification (SRS)
ix
Introduction
© HeiTech Padu Berhad
1.
INTRODUCTION
This document provides a brief overview of the system’s requirement
specification, which includes the subsection of purpose, scope, definitions,
acronyms, abbreviations, references and document overview.
1.1
PURPOSE
The purpose of Software Requirement Specifications (SRS) is to describe the
Shared Banking Services (SBS), which will be developed by HeiTech Padu
Berhad. The SRS is a detailed description explaining exactly what the
software is supposed to do and gives the user general idea about how to use
the software. The System Requirements Specification is designed to aid the
user as well as the developer in better understanding the workings of the
system. The document presents the functional, non-functional, and the design
and implementation constraints of the SBS system.
1.2
SCOPE
Shared Banking Services (SBS) is a counter-based transaction system
developed on top of a software framework name Hybrid Client for
developing a front-end, transaction based system. SBS system offers services
for selected banking used to carry out at Post office branches. SBS system
consists of two main systems which are transaction systems and
support/utility functions.
The SBS system takes into consideration of the following requirements:
• Enable ease of customization of selected bank proposed transactions (to
Post office) such as transaction creation, field validation (ex. check digit
calculation), database access, local devices integration, and selected bank
Host access.
• Provide support and utilities functions for efficient day-to-day operations
and ease of administration.
• Provide ease of deployment using ClickOnce deployment technology,
which enables centralized deployment to all Post office branches.
1.3
DEFIITIOS, ACROYMS, AD ABBREVIATIOS
This subsection provides the definitions of all terms, acronyms, and
abbreviations required to properly interpret the Software Requirements
Specification. This information may be provided by reference to the project’s
Glossary.
Term
ATM
BIC
BOP
Description
Automatic Teller Machine
Bank Identifier Code
Balance Of Payment
SBS Project System Requirements Specification (SRS)
1
Introduction
© HeiTech Padu Berhad
Current Account
CRedit
Contactless Smart Card
Date Of Birth
Electronic Journal
Foreign Exchange Rate
Foreign Telegraphic Transfer
Foreign Worker Telegraphic Transfer
Government Multipurpose Card
Secured HTTP
HeiTech Padu
Hire Purchase
Identity Card
Lembaga Hasil Dalam egeri
MalaYsian Ringgit
Philippine Clearing House Corporation
Philippine Peso
Permodalan ational Bhd
Personal Saving Account
Saving Account
Shared Banking Services
Simple Mail Transfer Protocol
Telegraphic Transfare
CA
CR
CSC
DOB
EJ
Forex
FTT
FWTT
GMPC
HTTPS
HTP
HP
IC
LHD
MYR
PCHC
PHP
PB
PSV
SA
SBS
SMTP
TT
Table 1.1: Definitions, Acronyms, and Abbreviations
1.4
REFERECES
This section provides references to all other publications that are applicable to
the System Requirements Specification document.
- “Technical Specification”, Vol. 4.0, September 2008, by Selected Bank.
- “User Functional Specification for Shared Banking Services”, Vol. 1.0,
December 2008, by HeiTech Padu Berhad.
- “HeiTech System Requirements Specification Guideline”, Vol. 2.0,
December 2008, by HeiTech Padu Berhad.
1.5
OVERVIEW
The following section summarizes the contents of System Requirements
Specification documents and explains how the document is organized.
Chapter 1
Chapter 2
Describes the overall purpose, document overview, all the
referenced documents and any additional information related
to this document.
Describes all aspects related to the external and internal
interfaces product requirements.
SBS Project System Requirements Specification (SRS)
2
Introduction
© HeiTech Padu Berhad
Chapter 3
Chapter 4
Chapter 5
Chapter 6
Chapter 7
Chapter 8
Chapter 9
Chapter 10
Describes the data requirements of the product.
Describes all aspects related to constraints to the product.
Describes the sizing and timing requirements.
Describes the site adaptation requirements.
Describes all aspects related to qualification methods.
Describes all aspects related to quality requirements.
Describes any changes to the requirements that can affect the
requirements in the SRS.
Defines any licensing enforcement requirements or other
usage restriction requirements that are to be exhibited by the
software.
Table 1.2: Overview
SBS Project System Requirements Specification (SRS)
3
System Specification
© HeiTech Padu Berhad
2.
SYSTEM SPECIFICATIO
This section shall be divided into the following sections and subsections to
specify the requirements for those interfaces to which externally and internally
applied to the system.
2.1
SYSTEM ITERFACES SPECIFICATIO
2.1.1
External Interface Requirements
Bank Host
Request_Transaction
Reply_Transaction
CSCI SBS
System
Post Mediator
Device_Demand
Device_Response
DSS
Figure 2.1: External Interface Requirements
2.1.1.1
Interface Post Mediator/CSCI SBS
Interface Identification: Post office Branch Mediator
Interface Type: Person
Description
This actor is a person who uses the SBS System to manage the banking
services at post office branch level.
Association
This actor (which can be Manager, Officer or Teller) communicates
through the Open Account, Make Cash Deposit/Payment, Withdraw
Money, Inquire Balance, Maintain Passbook, Remit Money, Reverse
Transaction, Require Override, Sign In, Manage User Profile, Perform
End Of Day, Manage Stock Control Register and View Electronic
Journal And Forex Rate use cases.
SBS Project System Requirements Specification (SRS)
4
© HeiTech Padu Berhad
2.1.1.2
System Specification
Interface Bank Host/CSCI SBS
Interface Identification: Bank Host
Interface Type: Mainframe
Description
This actor is a Mainframe that the Post office Mediator uses to manage
the SBS transactions at the branch level.
Association
The Bank Host is an external Interface that allows CSCI SBS to exchange
transaction information’s through Requist_Transaction to send requested
transaction information from CSCI, and Reply_Transaction to return back
the transaction response information to CSCI.
2.1.1.3
Interface DSS/CSCI SBS
Interface Identification: Device Service Server
Interface Type: Software
Description
This actor is Software who provides the devices integration services for
CSCI SBS System.
Association
The DSS use to make CSCI SBS devices integration and device sharing
easier by providing a set of uniform APIs so the access to various
devices cab be done in a unified manner. It communicates to the CSCI
through Device_Demand to send the CSCI request and
Device_Response to send back the device response to the CSCI.
2.1.2
2.1.2.1
Internal Interface Requirements
Hybird Client
The SBS system will be customized using Hybrid Client. Hybrid Client
is used as the transaction engine to speed up the delivery of the proposed
system. Common tasks of a transaction system such as transaction
creation, field validation, accessing database, integrating with local
devices and host access are pre-built and encapsulated within Hybrid
Client.
SBS Project System Requirements Specification (SRS)
5
© HeiTech Padu Berhad
2.1.2.2
System Specification
ClickOnce
Shared Banking Services (SBS) Application (Hybrid Client) will be
deployed using ClickOnce via a website through internet connectivity.
SBS Application could be loaded with direct HTTP request Internet
Explorer (IE) provided .NET Framework 2.0 or later.
ClickOnce is a deployment technology that enables self update to all SBS
Application with minimal user interaction. Users have to follow
instructions while installing SBS Application using ClickOnce. At the
client machine, users have to type the URL of the SBS Application in the
browser's address bar. The application is then downloaded from
Deployment Server (Bank Web Server), installed, and started on the end
user's workstation. Items are added to the Start Menu and Add or Remove
Programs in Control Panel. Because this strategy depends on network
connectivity, it works best on a local-area network or a high-speed
Internet connection.
2.1.3
Hardware Interface
- MyKad Reader
Manufactured
Product Series
Description
- Laser Jet Printer
Manufactured
Product Series
Description
- Passbook Printer
Manufactured
Product Series
Description
SBS Project System Requirements Specification (SRS)
6
System Specification
© HeiTech Padu Berhad
2.2
SYSTEM FUCTIOAL REQUIREMETS
This paragraph defines all the capability requirements that the CSCI SBS
must satisfy.
<<extend>>
Remit Money
View Electronic Journal And Forex
Rate
Maintain Passbook
Inquire Balance
Open Account
Stock Control Register
Post Mediator
Rev erse Transaction
Sign In
Perf orm End of Day
<<extend>>
<<include>>
<<extend>>
Post Teller
Make Cash Deposit/Pay ment <<extend>>
<<extend>>
Withdraw Money
Require Ov erride
Manage User Prof ile
Post Manager Post Of f icer
Figure 2.2: SBS System Use Case Diagram
SBS Project System Requirements Specification (SRS)
7
System Specification
© HeiTech Padu Berhad
2.2.1
Use Case Sign In
<<extend>>
Sign In
Post Mediator
Manage User Profile
Figure 2.3: Use Case Sign In
2.2.1.1
Brief Description
This use case is started / initiated by Post office Branch Mediator. It
functionality is to enable the Mediator to access the system via proper
sign-in and authentication procedures. Besides that, this use case also
enables the users to change their password and log out from the system.
2.2.1.2
Characteristics of Activation
The event is activated by Post office Branch Mediator (which can be a
Teller, Officer, or a Manager).
2.2.1.3
Pre-Condition
1. Shared Banking Services system is installed.
2.2.1.4
2.2.1.4.1
Description
Basic Flow
1. This use case begins when the Mediator open the SBS system. Sign In
screen will be displayed.
2. The Mediator enters “UserID” and “Password” and clicks “Sign In”
button.
3. The system will verify the “UserID” and “Password”. [E1: Invalid
Login], [E2: User Already Signed In].
4. The system check in database for the role of the logged in UserID.
5. If UserID entered is a Manager ID and Start of Day has not been
done, a “Start of Day” screen will be displayed [E3: Start of Day
Has ot Been Performed]. Manager clicks “OK” to perform Start of
Day.
6. System will display “Shared Banking Services” screen.
7. Mediator makes selection to change his password. [A1: Change
Password].
8. Mediator can log out or exit from the system. [A2: Log Out], [A3:
Exit].
SBS Project System Requirements Specification (SRS)
8
© HeiTech Padu Berhad
System Specification
9. At any time, system can sign the current user out [A4: Auto Sign
Out].
10. Upon successful signed in, system will send data to Host, update EJ
and branch status.
11. The use case ends.
2.2.1.4.2
Alternative Flow
[A1: Change Password]
1. This alternative flow will only happen if password expired, auto-sign
out occurred, new password created or password reset. [C3:
Password Expiry].
2. System will ask Mediator to change his password by displaying the
“Change Password” screen.
3. Mediator makes changes to the password and save the data.
4. The system will check and save the new password in the database.
[E4: Invalid ew Password].
5. The use case continues.
[A2: Log Out]
1.
2.
3.
4.
Mediator selects “Log out”.
The “Shared Banking Services” screen will be unloaded.
System shows “Sign In” screen.
The use case ends.
[A3: Exit]
1. Mediator selects “Exit”.
2. The Shared Banking Services system will exit completely.
3. The use case ends
[A4: Auto-Sign Out]
1. If system detected that there is idle or no active application [C2: Idle
Time], then it will sign the current Mediator out.
2. Mediator will see the “Sign In” screen.
3. Use case continues.
2.2.1.4.3
Exceptional Flow
[E1: Invalid Login]
1. If branch code and “UserID” not exist, the system will show an error
message.
2. Mediator enters a wrong password or did not enter a password. The
system will show an error message
3. The use case continues.
SBS Project System Requirements Specification (SRS)
9
© HeiTech Padu Berhad
System Specification
[E2: User Already Signed In]
1. If user is already signed in, the system will show “User Already
Signed In” message.
2. Use case extende to Manage User Profile Use Case to perform Force
User Sign Off.
3. Then the system will allow the Mediator to Sign In again.
[E3: Start of Day Has ot Been Performed].
1. If Start of Day has not been performed and UserID entered is Teller
ID or Officer ID, then the system will show error message. [C1: Start
of Day Conditions].
2. Use case continues.
[E4: Invalid ew Password]
1. An error message will be displayed.
2. Change new password fail.
3. Use case ends.
2.2.1.5
Post Condition
1. System sent data to Host and EJ and branch status updated.
2. “Shared Banking Services” screen will be loaded
3. The password will be changed.
2.2.1.6
Rules
Not Applicable.
2.2.1.7
Constraints
[C1: Start of Day Conditions]
1. Start of Day is done once a day.
2. Post office Mediator cannot start operations before Start of Day is
executed.
3. Start of Day done by Post office Manager.
[C2: Idle Time]
Any Shared Banking Services application that has been idle for 5 minutes
will cause all idle Shared Banking Services applications to be closed.
SBS Project System Requirements Specification (SRS)
10
System Specification
© HeiTech Padu Berhad
[C3: Password Expiry]
The table below explains on password expiry for Teller and
Officer/Supervisor.
User
Teller
Officer/Supervisor
Password expiry
(days)
14
14
Password expiry if
user inactive (days)
7
14
Table 2.1: Password Expiry Period
2.2.1.8
GUI
As shown in the Appendix A– Graphical User Interface.
SBS Project System Requirements Specification (SRS)
11
System Specification
© HeiTech Padu Berhad
2.2.2
Use Case Open Account
Post Teller
Open Account
Figure 2.4: Use Case Open Account
2.2.2.1
Brief Description
This use case provides capability for Customer to open bank account
using Post office Branch. Customer does not interact with the system
directly; instead, for this use case, a client interacts via a Post office
Branch Teller.
2.2.2.2
Characteristics of Activation
This event activated by Post office Branch Teller.
2.2.2.3
Pre-Condition
1. The Post office Start of Day system is already launched successfully.
2. The Post office Branch Teller is identified and authenticated.
3. The Customer provides some information (i.e. name, address, phone,
suitability, etc) to the bank by filling in Open Account form.
2.2.2.4
2.2.2.4.1
Description
Basic Flow
1. This use case begins when a Customer requires Teller to Open
Account by submitting a filled Open Account form to Teller.
2. The Teller ensures that the Customer is Applicable to Open Account.
[C1: Regulation of Opening Bank Account].
3. Teller selects “Account Opening” and chooses “Add Customer”. The
“Add Customer” menu will be displayed.
4. Based on Customer request, the Teller can select Account Type
whether opening an Individual or Joint Account. Also, Teller can
select Product Type whether Saving Account-Passbook or Saving
Account-Passbookless.
5. Teller selects “Saving Account-Passbook” under “Individual” menu to
open an Individual Saving Account-Passbook [A1: Opening an
Individual Saving Account-Passbookless], [A2: Opening Joint
Saving Account-Passbook]. System shows “Inquire Customer /
Segment” Screen.
SBS Project System Requirements Specification (SRS)
12
© HeiTech Padu Berhad
System Specification
6. System request Customer IC by using [A3: Inquire
Customer/Segment] Alternative Flow.
7. System request Teller to Add Account to the Customer by using [A4:
Add Account] Alternative Flow.
8. Upon successful Add Misc Code transaction, the system request Print
Specimen Card using [A5: Print Specimen Card] Alternative Flow.
9. If selection of “ATM Card” is yes, the system request Teller to Add
Card for the Customer by using [A6: Add Card] Alternative Flow.
10. At any transaction, when the Teller enters Amount, system verifies
that the Amount is within Teller limit and if not extend to Require
Override Use Case.
11. At any time, Teller can make the selection of “Repeat” [A7: Repeat
Transaction], or “Cancel” current transaction [A8: Cancel
Transaction].
12. The system will update EJ.
13. The use case ends when the Open Account screen is unloaded.
2.2.2.4.2
Alternative Flow
[A1: Opening an Individual Saving Account-Passbookless]
1. Teller selects “Saving Account-Passbookless” under “Individual”
menu to open an Individual Saving Account-Passbookless.
2. System shows “Inquire Customer/Segment” Screen.
3. The system will continue the flow in Basic Flow from step 2 to step
13.However, step 3 in [A5: Print Specimen Card] is excluded
(update Passbook Stock Control).
[A2: Opening Joint Saving Account-Passbook]
1. Teller selects “Saving Account-Passbook” under “Joint” menu to
open Joint Saving Account-Passbook. [A9: Opening Joint Saving
Account-Passbookless]. System shows “Inquire Customer/Segment”
Screen.
2. System request Customer IC by using [A3: Inquire
Customer/Segment] Alternative Flow.
3. Upon successful adding Primary Customer, the system displays again
“Inquire Customer/Segment” screen to Add Secondary Customer.
4. The flow number 2 will repeat again.
5. System request Teller to Add Account to the Customer by using [A4:
Add Account] Alternative Flow.
6. Upon successful Add Misc Code transaction, the system shows Add
Role screen. Teller Select “Relationship”, then click “OK” button.
The system will send Add Role transaction information to Host.
7. Upon successful Add Role transaction, the system will print
Application Form (to print both Customers). The system sends
“Please insert A4 paper into PASSBOOK printer” message to Teller.
8. The system request Print Specimen Card using [A5: Print Specimen
Card] Alternative Flow.
9. If selection of “ATM Card” is yes, the system request Teller to Add
Card for the Customer by using [A6: Add Card] Alternative Flow.
SBS Project System Requirements Specification (SRS)
13
© HeiTech Padu Berhad
System Specification
10. The flow from number 9 will repeat again for Secondary Customer.
11. This use case continues at step no 10 in Basic Flow.
[A3: Inquire Customer/Segment]
1. If Customer is GMPC holder, then Teller select to input IC No using
GMPC .The system prompt Teller to insert card by display “Please
Insert GMPC in Card Reader” message. The system starts verification
process.
2. If verification passed, the message “TP Verification Pass” will appear.
[E1: Verification Fail].
3. If Customer not GMPC holder, Teller has to input IC No either “New
I/C No.” or “Old I/C No”.
4. System inquires Customer Segment IC No from Host. [E2: IC Is
Duplicated].
5. System checks if the Customer exist or not [A10: Customer Exist].
6. System verifies Bankruptcy, Check Duplicate OCISS, and Check
OCISS/LIS/Staff. The system will show “Add Customer” screen.
7. The system retrieves the Customer’s “New IC No”, “Old IC No”,
“Name”, “Date Of Birth”, “Gender”, “Race Code”, “Address”,
“Postcode”, “State” and “Religion” from GMPC automatically and
display on “Add Customer” screen. [A11: on GMPC holder].
8. Teller fills in the required fields and Click “OK” button and the
system will send transaction information to Host.
9. Use case continues.
[A4: Add Account]
1. The system displays “Add Account” screen. Teller key in “Amount”
[C2: Amount Value Conditions], “Passbook No”, selects “Card
Charge Options” and selects “ATM Card (Y/N)”.
2. System checks whether the Amount is less than transaction limit [E3:
Amount More Than Transaction Limit] and verify that the Amount
is within Teller limit.
3. Upon successful Add Account transaction, the system will send
transaction information to Host.
4. The system will receive Host reply and automatically the system will
ask for a Voucher printing by send “Please Insert VOUCHER Into
PASSBOOK Printer” message to the Teller.
5. Then the system sends Add Misc Code transaction information to
Host.
6. Use case continues.
[A5: Print Specimen Card]
1. The system will print Application Form. The system sends “Please
insert A4 paper into PASSBOOK printer” message to Teller.
2. Upon successful printing application form, the system will print
Specimen Card. The system will ask to insert Specimen Card into
Passbook printer.
3. System will update Passbook Stock Control.
SBS Project System Requirements Specification (SRS)
14
© HeiTech Padu Berhad
System Specification
4. Use case continues.
[A6: Add Card]
1. The system shows “Add Card” screen. Teller enters the required fields
and click “OK” button. The system sends Add Card transaction
information to Host.
2. Upon successful Add Card transaction, the system will display “Pin
Issuance” screen. Teller fills in the required fields and click “OK”
button. The system will send PIN Issuance transaction information to
Host.
3. Upon successful Pin Issuance transaction, the system will update
ATM Card Stock Control.
4. Use case continues.
[A7: Repeat Transaction]
1. Teller clicks “Repeat” button.
2. System display new screen and enters same values as previous value.
3. Teller can perform this action by press”F9”.
[A8: Cancel Transaction]
1. Teller clicks “Cancel” button.
2. System cancels current transaction and display main transaction
screen.
[A9: Opening Joint Saving Account-Passbookless]
1. Teller selects “Saving Account-Passbookless” under “Joint” menu to
open Joint Saving Account-Passbookless.
2. System shows “Inquire Customer/Segment” Screen.
3. The system will continue the flow in Alternative Flow [A2: Opening
Joint Saving Account-Passbook] from step 2 to step 11. However,
step 3 in [A5: Print Specimen Card] is excluded (update Passbook
Stock Control).
[A10: Customer Exist]
1. If the Customer exists, then system inquires Customers’ Product Type
and Account Type and checks if it duplicates or not.
2. If duplicate, the system will reject the transaction by display reject
message.
3. The use case continues.
[A11: on GMPC Holder]
1. If Customer is non GMPC holder, on “Add Customer” screen Teller
has to input “Name”, “Date Of Birth”, “Gender”, “IC Type”, “Race
Code”, “Religion”, “Occupation”, “Occupation Desc”, “Occupation
Sector”, “Occupation Sector Desc ”, “Income”, “Address”,
SBS Project System Requirements Specification (SRS)
15
© HeiTech Padu Berhad
System Specification
“Postcode”, “State”, “Telephone number ” and “Employer Details”.
2. The use case continues.
2.2.2.4.3
Exceptional Flow
[E1: Verification Fail]
1. If verification failed, message “TP verification fail” will appear.
2. The transaction will be aborted.
3. The use case ends.
[E2: IC Is Duplicated]
1. If duplicate IC, the system will reject the transaction
2. Send reject message.
[E3: Amount More Than Transaction Limit]
1. The system will not allow transaction to proceed.
2. The system notifies and display error message.
2.2.2.5
Post Condition
1. An Individual Savings Account – Passbook, An Individual Savings
Account – Passbookless, An Joint Savings Account – Passbook or An
Joint Savings Account – Passbookless has been created.
2. If ATM Card Selection is yes, then ATM Card Stock Control updated.
Furthermore, if Product Type is Passbook, then Passbook Stock
Control updated.
3. The transaction sent to Host.
4. Specimen Card, Application Form and Voucher are printed.
2.2.2.6
Rules
Not Applicable
2.2.2.7
Constraints
[C1: Regulation of Opening Bank Account]
Account Opening is applicable to Malaysian only. External/foreigner is
not allowed.
[C2: Amount Value Conditions]
- Format of Amount must be RMSSS,SSS,SS9.99.
- The value of Amount must not be RM0.00.
SBS Project System Requirements Specification (SRS)
16
© HeiTech Padu Berhad
2.2.2.8
System Specification
GUI
As shown in the Appendix A- Graphical User Interface.
SBS Project System Requirements Specification (SRS)
17
System Specification
© HeiTech Padu Berhad
2.2.3
Use Case Make Cash Deposit/Payment
<<extend>>
Post Teller
Make Cash Deposit/Payment
Require Override
Figure 2.5: Use Case Make Cash Deposit/Payment
2.2.3.1
Brief Description
This use case provides capability for Customer to Deposit/Payment
transaction on Bank account using Post office Branch. Customer does not
interact with the system directly; instead, for this use case, a Customer
interacts via a Post office Branch Teller.
2.2.3.2
Characteristics of Activation
This event is activated by Post office Branch Teller.
2.2.3.3
Pre-Condition
1. The Post office Start of Day system is already launched successfully.
2. The Post office Branch Teller is identified and authenticated.
3. “Transaction” screen that contains list of Shared Banking Services
Transactions is loaded.
4. Customer is opened account successfully.
5. The Customer provides some information (i.e. name, account no,
cheque no, etc) to the bank by filling in Deposit/Payment form.
2.2.3.4
2.2.3.4.1
Description
Basic Flow
1. This use case begins when a Customer requires Teller to make
Deposit/Payment transaction by submitting a filled Deposit/Payment
form to Teller.
2. Teller selects “Cash Activities” and chooses “Deposit/Payment”. The
“Deposit/Payment” screen will be displayed.
3. The Teller key in Customers’ “Account Number” or “Vehicle Reg.
No” and press “Enter”. If the Teller key in wrong or incomplete data,
the system will notify and display error message.
4. If the Teller key in “Vehicle Reg. No”, the system will inquire the
account number.
5. The system verify the account number whether it within cleaning
code or not by check the 2nd and 3rd digit of account number against
SBS Project System Requirements Specification (SRS)
18
© HeiTech Padu Berhad
System Specification
the branch clearing code. [A1: Calculate Commission].
6. The system validate Customers’ product type base on Account
Number.
7. The system check if the Account Number is Exempted Account or
not. [C1: Exempted Account Condition], [E1: Exempted Account
umber].
8. The Teller can make cash Deposit/Payment based on Customers’
product type. [A2: Saving Account-Passbookless Deposit], [A3:
Saving Account-Passbook Deposit], [A4: CA Deposit], [A5: PSV
Deposit], [A6: Loan Cash Repayment], [A7: HP Payment], [A8:
Credit Card Cash Payment].
9. At any transaction, when the Teller enters Amount, system verifies
that the Amount is within Teller limit and if not extend to Require
Override Use Case.
10. At any time, Teller can make the selection of “Repeat” [A11: Repeat
Transaction], or “Cancel” current Transaction [A12: Cancel
Transaction].
11. The system will send the transaction to Host.
12. The system will update EJ and Teller total.
13. The use case ends when the “Deposit/Payment” screen is unloaded.
2.2.3.4.2
Alternative Flow
[A1: Calculate Commission]
1. If account number is not within the clearing code, the system will pop
up “Commission” screen. [E4: Receive Error From The Host].
2. The Teller chooses the technique that the Customer will use to pay the
commission whether by paying “Cash” or “deduct” from the cash
amount that the Customer provides for Deposit/Payment purpose.
3. The system calculates “Commission Amount” and display to the
Teller [C2: Commission Amount Status].
4. The system keeps commission accumulated by Teller in Teller Table
file.
5. The Teller collects Commission Amount from the Customer.
6. The Teller click “OK” button, the “Commission” screen is unloaded.
7. The use case continues.
[A2: Saving Account-Passbookless Deposit]
1. System displays appropriate “Saving Account Deposit” screen.
2. The Teller key in “Amount” [A9: Use Calculator] and clicks “OK”
button. [C3: Amount Value Conditions].
3. System checks whether the Amount is less than transaction limit [E2:
Amount More Than Transaction Limit] and verify that the Amount
is within Teller limit.
4. System sends the information to the Host.
5. The system will receive Host reply and automatically the system will
ask for a Voucher printing by send “Please Insert VOUCHER Into
PASSBOOK Printer” message to the Teller.
6. The use case continues.
SBS Project System Requirements Specification (SRS)
19
© HeiTech Padu Berhad
System Specification
[A3: Saving Account-Passbook Deposit]
1. System displays appropriate “Saving Account Deposit” screen.
2. The Teller key in “Amount” [A9: Use Calculator], “Passbook
Balance”, “Passbook Number” and clicks “OK” button. [C3: Amount
Value Conditions].
3. System checks whether the Amount is less than transaction limit [E2:
Amount More Than Transaction Limit] and verify that the Amount
is within Teller limit.
4. System updates Passbook and sends transactions information to the
Host. But if “Passbook Balance” and “Passbook Number” is not
inserted, the system only sends Deposit transaction information to the
Host.
5. The system will receive Host reply and automatically the system will
ask for a Voucher printing by send “Please Insert VOUCHER Into
PASSBOOK Printer” message to the Teller. Also, system send
“Please Insert PSSBOOK to PASSBOOK Printer” message to print
Passbook.
8. The use case continues.
[A4: CA Deposit]
1. The system will automatically display “CA Deposit” screen.
2. The system will check the account number against Special
Description table. If the account number is not listed in Special
Description table, the Teller insert “Amount” [A9: Use Calculator],
“Description” and “Reference Number” and click the “OK button.
[C3: Amount Value Conditions].
3. If the account number is listed in Special Description table, the system
will replace “Description” and “Reference Number” fields based on
Special Description table.
4. System checks whether the Amount is less than transaction limit [E2:
Amount More Than Transaction Limit] and verify that the Amount
is within Teller limit.
5. System sends the information to the Host.
6. The system will receive Host reply and automatically the system will
ask for a Voucher printing by send “Please Insert VOUCHER Into
PASSBOOK Printer” message to the Teller.
7. The use case continues.
[A5: PSV Deposit]
1. The system will automatically display “PSV Deposit” screen.
2. The Teller type “Amount” [A9: Use Calculator] and click the “OK
button. [C3: Amount Value Conditions].
3. System checks whether the Amount is less than transaction limit [E2:
Amount More Than Transaction Limit] and verify that the Amount
is within Teller limit.
4. System sends the information to the Host.
5. The system will receive Host reply and automatically the system will
SBS Project System Requirements Specification (SRS)
20
© HeiTech Padu Berhad
System Specification
ask for a Voucher printing by send “Please Insert VOUCHER Into
PASSBOOK Printer” message to the Teller.
6. The use case continues.
[A6: Loan Cash Repayment]
1. The system will automatically display “Loan Repayment” screen.
2. The Teller type “Amount” [A9: Use Calculator] and click the “OK
button. [C3: Amount Value Conditions].
3. System checks whether the Amount is less than transaction limit [E2:
Amount More Than Transaction Limit] and verify that the Amount
is within Teller limit.
4. The system check if the Amount need to adjustment or not. [A10
Calculate Rounding Adjustment].
5. System sends the information to the Host.
6. The system will receive Host reply and automatically the system will
ask for a Voucher printing by send “Please Insert VOUCHER Into
PASSBOOK Printer” message to the Teller.
7. System will prompt message “Please insert reverse of the customer’s
copy into PASSBOOK Printer”. This is to print the automated amount
of Rounding Mechanism on the back of the customer’s copy.
8. System will prompt message “Please insert GL VOUCHER into
PASSBOOK Printer”.
9. The use case continues.
[A7: HP Payment]
1. The system will automatically display “HP Payment” screen.
2. The Teller key in “Amount” [A9: Use Calculator], choose “Payment
Type” and click the “OK button. [C3: Amount Value Conditions].
3. System checks whether the Amount is less than transaction limit [E2:
Amount More Than Transaction Limit] and verify that the Amount
is within Teller limit.
4. The system check if the Amount need to adjustment or not. [A10
Calculate Rounding Adjustment].
5. System sends the information to the Host.
6. The system will receive Host reply and automatically the system will
ask for a Voucher printing by send “Please Insert VOUCHER Into
PASSBOOK Printer” message to the Teller.
7. The use case continues.
[A8: Credit Card Cash Payment]
1. The system will automatically display “Credit Card Payment” screen.
2. The Teller type “Amount” [A9: Use Calculator] and click the “OK”
button. [C3: Amount Value Conditions].
3. System checks whether the Amount is less than transaction limit [E2:
Amount More Than Transaction Limit] and verify that the Amount
is within Teller limit.
4. The system check if the Amount need to adjustment or not. [A10
Calculate Rounding Adjustment].
SBS Project System Requirements Specification (SRS)
21
© HeiTech Padu Berhad
System Specification
5. System sends the information to the Host.
6. The system will receive Host reply and automatically the system will
ask for a Voucher printing by send “Please Insert VOUCHER Into
PASSBOOK Printer” message to the Teller.
7. System will prompt message “Please insert reverse of the customer’s
copy into PASSBOOK Printer”. This is to print the automated amount
of Rounding Mechanism on the back of the customer’s copy.
8. System will prompt message “Please insert GL VOUCHER into
PASSBOOK Printer”.
9. The use case continues.
[A9: Use Calculator]
1.
2.
3.
4.
Teller clicks “Calculator” button on the transaction screen.
The “Calculator” screen will appear.
The Teller use Calculator buttons to calculate the Amount.
The system transfers the Amount on the “Calculator” screen to the
Amount on the transaction screen.
5. The use case continues.
[A10: Calculate Rounding Adjustment]
1. If the Amount need auto rounding adjustment, the system will display
“Rounding Mechanism Adjustment” screen. [E3: Host Error
Message].
2. The system retrieves the “Original Amount”
3. The system check the Amount ends in sen to define “Rounding
Adjustment”. [C4: Rounding Adjustment Mechanism].
4. System calculates and displays “Rounding Adjustment” and
“Rounding Totals” in screen. [R1: Rounding Mechanism
Calculation].
5. Teller clicks “OK”, then system sends rounding adjustment Amount
to the Host to print within the Deposit/Payment Voucher.
6. The use case continues.
[A11: Repeat Transaction]
1. Teller clicks “Repeat” button.
2. System display new screen and enters same values as previous values.
3. Teller can perform this action by press”F9”.
[A12: Cancel Transaction]
1. Teller clicks “Cancel” button.
2. System cancels current transaction and display main transaction
screen.
2.2.3.4.3
Exceptional Flow
[E1: Exempted Account umber]
SBS Project System Requirements Specification (SRS)
22
© HeiTech Padu Berhad
System Specification
1. The system excludes Deposit/Payment transaction from this account.
2. The system display “Transaction Not Authorized. Refer to Any
Selected Bank Branch.” message.
The List of Exempted Account table is shown in Appendix B.
[E2: Amount More Than Transaction Limit]
1. The system will not allow transaction to proceed.
2. The system notifies and display error message.
[E3: Host Error Message]
1. If the Amount need auto rounding adjustment but the system receives
error message from the Host, Teller has to do rounding adjustment
manually.
2. Teller selects “Rounding Mechanism Adjustment” under “Others”
folder in transaction module menu.
3. Use case continues at step no 2 in [A10: Calculate Rounding
Adjustment] Alternative Flow.
[E4: Receive Error From The Host]
1. If account number is not within the clearing code and the system
receives error message from the Host, the Teller has to do commission
manually.
2. Teller selects “Commission” under “Others” folder in transaction
module menu. “Commission” screen will be displayed.
3. Use case continues at step no 2 in [A1: Calculate Commission]
Alternative Flow.
2.2.3.5
Post Condition
1.
2.
3.
4.
2.2.3.6
The transaction sent to Host.
The EJ and Teller total updated.
The transaction Voucher printed.
Teller may return the Rounding Adjustment value (if any) to the
customer together with the printed Voucher.
Rules
[R1: Rounding Mechanism Calculation]
2.2.3.7
Round Up Calculation:
Rounding totals = Original Amount + Rounding Adjustment
Round Down Calculation:
Rounding totals = Original Amount - Rounding Adjustment
Constraints
[C1: Exempted Account Condition]
SBS Project System Requirements Specification (SRS)
23
System Specification
© HeiTech Padu Berhad
- The Account No is within the cleaning code.
- 1st digit of Account No is 0/5.
[C2: Commission Amount Status]
The conditions to calculate Commission Amount are as follow:
- If the Commission Type is “Nil”, then the “Commission Amount”
will be 0.00.
- For SAFE Transaction:
Commission Amount must not be less than minimum amount
of commission defined in Tellers’ profile.
Commission Amount must be less than RM1000.00.
- For CBS Transaction:
Commission Type must be “Cash” or “Nil”.
Commission Amount must not be less than minimum amount
of commission defined in Tellers’ profile.
[C3: Amount Value Conditions]
- Format of Amount must be RMSSS,SSS,SS9.99.
- The value of Amount must not be RM0.00.
[C4: Rounding Adjustment Mechanism]
The total Amount that ends in 1, 2, 6 and 7 sen to be rounded downwards
and 3, 4, 8 and 9 sen to be rounded upwards to the nearest multiple of 5
sen as in the table below:
Amount Ends
in Sen
1, 2
3, 4
6, 7
8, 9
Round Off to the
Nearest
5 Sen
Round Down
Round Up
Round Down
Round Up
Table 2.2: Deposit/Payment Rounding Adjustment Mechanism
2.2.3.8
GUI
As shown in the Appendix A– Graphical User Interface.
SBS Project System Requirements Specification (SRS)
24
System Specification
© HeiTech Padu Berhad
2.2.4
Use Case Withdraw Money
<<extend>>
Withdraw Money
Post Teller
Require Override
Figure 2.6: Use Case Withdraw Money
2.2.4.1
Brief Description
This use case provides capability for Customer to withdraw from his/her
Bank account using Post office Branch. Customer does not interact with
the system directly; instead, for this use case, a client interacts via a Post
office Branch Teller.
2.2.4.2
Characteristics of Activation
This event is activated by Post office Branch Teller.
2.2.4.3
Pre-Condition
1. The Post office Start of Day system is already launched successfully.
2. The Post office Branch Teller is identified and authenticated.
3. “Transaction” screen that contains list of Shared Banking Services
Transactions is loaded.
4. Customer is opened Saving Account successfully.
5. The Customer provides some information (i.e. Name, A/C No,
Amount, etc) to the bank by filling in withdraw form.
2.2.4.4
2.2.4.4.1
Description
Basic Flow
1. This use case begins when a Customer requires Teller to withdraw
money by submitting a filled Cash Withdrawal form to Teller.
2. Teller selects “Cash Activities” and chooses “Withdrawal”. The
“Withdrawal” screen will be displayed.
3. If Customer is MyKad holder, then Teller change value of
“Thumbprint Verification” to “Y” .The system prompt Teller to insert
card by display “Please Insert GMPC in Card Reader” message. The
system starts verification process.
4. If verification passed, the message “TP Verification Pass” will appear.
[E1: Verification Fail].
5. If not MyKad holder, Teller changes “Thumbprint verification” to
“N”.
6. The Teller key in Customers’ “Account Number” and press “Enter”.
SBS Project System Requirements Specification (SRS)
25
© HeiTech Padu Berhad
System Specification
If the Teller key in wrong or incomplete data, the system will notify
and display error message.
7. The system verify the account number whether it within cleaning
code or not by check the 2nd and 3rd digit of account number against
the branch clearing code. [A1: Calculate Commission].
8. The Teller can make cash Withdrawal based on Customers’ product
type. [A2: Saving Account-Passbookless Withdraw], [A3: Saving
Account-Passbook Withdraw].
9. At any transaction, when the Teller enters Amount, system verifies
that the Amount is within Teller limit and if not extend to Require
Override Use Case.
10. At any time, Teller can make the selection of “Repeat” [A4: Repeat
Transaction], or “Cancel” current Transaction [A5: Cancel
Transaction].
11. The system will send the transaction to Host.
12. The system will update EJ and Teller total.
13. The use case ends when the “Withdrawal” screen is unloaded.
2.2.4.4.2
Alternative Flow
[A1: Calculate Commission]
1. If account number is not within the clearing code, the system will pop
up “Commission” screen. [E3: Receive Error From The Host].
2. The Teller chooses the technique that the Customer will use to pay the
commission whether by paying “Cash” or “deduct” from the cash
amount that the Customer provides for Withdraw purpose. Otherwise
the Teller can choose “Nil”.
3. The system calculates “Commission Amount” and display to the
Teller [C1: Commission Amount Status].
4. The system will keep commission accumulated by Teller in Teller
Table file.
5. The Teller collects Commission Amount from the Customer.
6. The Teller click “OK” button, the “Commission” screen is unloaded.
[A2: Saving Account-Passbookless Withdraw]
1. System displays appropriate “Saving Account Withdrawal” screen.
2. The Teller key in “Amount” [A6: Use Calculator], “Card No” and
clicks “OK” button. [C2: Amount Value Conditions].
3. System checks whether the Amount is less than transaction limit [E2:
Amount More Than Transaction Limit] and verify that the Amount
is within Teller limit.
4. System sends the information to the Host.
5. The system will receive Host reply and automatically the system will
ask for a Voucher printing by send “Please Insert VOUCHER Into
PASSBOOK Printer” message to the Teller.
6. The use case continues.
SBS Project System Requirements Specification (SRS)
26
© HeiTech Padu Berhad
System Specification
[A3: Saving Account-Passbook Withdraw]
1. System displays appropriate “Saving Account Withdrawal” screen.
2. The Teller key in “Amount” [A6: Use Calculator], “Passbook
Balance”, “Passbook Number” and clicks “OK” button. [C2: Amount
Value Conditions].
3. System checks whether the Amount is less than transaction limit [E2:
Amount More Than Transaction Limit] and verify that the Amount
is within Teller limit.
4. System updates Passbook and sends transactions information to the
Host. But if “Passbook Balance” and “Passbook Number” is not
inserted, the system only sends Deposit transaction information to the
Host.
5. The system will receive Host reply and automatically the system will
ask for a Voucher printing by send “Please Insert VOUCHER Into
PASSBOOK Printer” message to the Teller .Also, system send
“Please Insert PSSBOOK to PASSBOOK Printer ” message to print
Passbook.
6. The use case continues.
[A4: Repeat Transaction]
1. Teller clicks “Repeat” button.
2. System display new screen and enters same values as previous value.
3. Teller can perform this action by press”F9”.
[A5: Cancel Transaction]
1. Teller clicks “Cancel” button.
2. System cancels current transaction and display main transaction
screen.
[A6: Use Calculator]
1.
2.
3.
4.
Teller clicks “Calculator” button on the transaction screen.
The “Calculator” screen will appear.
The Teller use Calculator buttons to calculate the Amount.
The system transfers the Amount on the “Calculator” screen to the
Amount on the transaction screen.
5. The use case continues.
2.2.4.4.3
Exceptional Flow
[E1: Verification Fail]
1. If verification failed, message ‘TP verification fail’ will appear.
2. The transaction will be aborted.
[E2: Amount More Than Transaction Limit]
1. The system will not allow transaction to proceed.
SBS Project System Requirements Specification (SRS)
27
© HeiTech Padu Berhad
System Specification
2. The system notifies and display error message.
[E3: Receive Error From The Host]
1. If account number is not within the clearing code and the system
receives error message from the Host, the Teller has to do commission
manually.
2. Teller selects “Commission” under “Others” folder in transaction
module menu. “Commission” screen will be displayed.
3. Use case continues at step no 2 in [A1: Calculate Commission]
Alternative Flow.
2.2.4.5
Post Condition
1.
2.
3.
4.
2.2.4.6
The transaction sent to Host.
The EJ and Teller total updated.
The transaction Voucher printed.
Teller gives the printed Voucher to the Customer.
Rules
Not Applicable.
2.2.4.7
Constraints
[C1: Commission Amount Status]
The conditions to calculate Commission Amount are as follow:
- If the Commission Type is “Nil”, then the “Commission Amount”
will be 0.00.
- For SAFE Transaction:
Commission Amount must not be less than minimum amount
of commission defined in Tellers’ profile.
Commission Amount must be less than RM1000.00.
- For CBS Transaction:
Commission Type must be “Cash” or “Nil”.
Commission Amount must not be less than minimum amount
of commission defined in Tellers’ profile.
[C3: Amount Value Conditions]
- Format of Amount must be RMSSS,SSS,SS9.99.
- The value of Amount must not be RM0.00.
2.2.4.8
GUI
As shown in the Appendix A– Graphical User Interface.
SBS Project System Requirements Specification (SRS)
28
System Specification
© HeiTech Padu Berhad
2.2.5
Use Case Remit Money
<<extend>>
Remit Money
Post Teller
View Electronic Journal And Forex
Rate
Figure 2.7: Use Case Remit Money
2.2.5.1
Brief Description
This use case provides capability for Customer to transfer money from
one Bank account to another account using Post office Branch. Customer
does not interact with the system directly; instead, for this use case, a
client interacts via a Post office Branch Teller.
2.2.5.2
Characteristics of Activation
This event is activated by Post office Branch Teller.
2.2.5.3
Pre-Condition
1. The Post office Start of Day system is already launched successfully.
2. The Post office Branch Teller is identified and authenticated.
3. “Transaction” screen that contains list of Shared Banking Services
Transactions is loaded.
4. The Customer provides some information (i.e. name, address, phone,
suitability, etc) to the bank by filling in Remittance form.
2.2.5.4
2.2.5.4.1
Description
Basic Flow
1. This use case begins when a Customer requires Teller to make
Remittance transaction by submitting a filled Remittance form to
Teller.
2. Based on Customer request, Teller can select Remittance type
whether it “FTT”, “FWTT” [A1: Foreign Worker Telegraph
Transfer] or “Interbank GIRO” [A2: GIRO Fund Transfer].
3. Teller selects “Cash Activities” and chooses “FTT” under
“Remittance” menu. The “Foreign Telegraphic Transfer” screen will
be displayed.
4. Teller has to select “Country”, “Currency Code”, “BIC Code” , “BOP
Info”, “Ringgit Fixed”, “Foreign Amount” [C1: Foreign Amount
Value], [R1: Foreign Amount Calculation], “Ringgit Amount” [C2:
Ringgit Amount Value], [R2: Ringgit Amount Calculation], and
“Cable Charge Amount” [R4: Cable Charge Amount Value]. [A3:
SBS Project System Requirements Specification (SRS)
29
© HeiTech Padu Berhad
System Specification
Use Calculator].
5. System display “Counter Rate” and “Comm Charge Amount”. [R3:
Commission Charge Amount Value].
6. Teller inserts Ordering Customer info which is “Name”, “Address”,
“ID No” and “Payment to Beneficiary”.
7. Teller inserts Beneficiary info which is “Account No”, “Name”,
“Address” and “Payment Details”.
8. Teller inserts Beneficiary Banker info which is “Name”, “Address”,
“City” and “Country”.
9. Teller inserts Beneficiary Banker info which is “Remitter Status”,
“Beneficiary Status”, “Same party/Different party”, “Foreign
Worker”, “Form P Purpose Code”, “Description” and “Relationship”.
10. System verifies the data and if incomplete or wrong data, the system
notifies the Teller by error message. [E2: Hybird Server is Offline].
11. At any transaction, when the Teller enters Amount, system verifies
whether the Amount is within Teller limit and if not extend to
Require Override Use Case. The system check if the Amount need
to adjustment or not. [A4: Calculate Rounding Adjustment].
12. At any time, Teller can make the selection of “Repeat” [A5: Repeat
Transaction], or “Cancel” current Transaction [A6: Cancel
Transaction].
13. Upon successful transaction, the system will receive Host reply and
automatically the system will ask for a Voucher printing by send
“Please Insert VOUCHER Into PASSBOOK Printer” message to the
Teller.
14. The system will send the transaction and Selected Bank base branch
code to Host.
15. The system will update EJ.
16. The use case ends when the “Remittance” screen is unloaded.
2.2.5.4.2
Alternative Flow
[A1: Foreign Worker Telegraph Transfer]
1. Teller selects “Cash Activities” and chooses “FWTT” under
“Remittance” menu. The “Foreign Worker Telegraphic Transfer”
screen will be displayed.
2. Teller key in “Membership ID” or “IC/Passport No” and press Enter
key.
3. System verifies the input and send to Host to retrieves info. [E1:
Customer Is ot A Member].
4. System display retrieved info on the screen which are “Country”,
“Payment Mode to Bene ”, “Currency Code”, “Ringgit Amount”,
“Counter Rate”, “Ringgit Fixed (Y/N)”, “Foreign Amount” , “Service
Charge” and “Cable Charge”. [A3: Use Calculator].
5. Teller has to input Remitter Details which are “Name”, “IC/Passport
No”, “DOB”, “Occupation”, “Address”, “Contact No”, “Purpose of
Payment” and “Foreign Worker (Y/N)”.
6. Teller has to input Beneficiary Details which are “Name/First Name
(PHP)”, “Surname”, “Address”, “IC/Passport No.”, “Account No”,
“Tel No”, “Bank Overseas Branch Code”, “Agent Bank Branch
SBS Project System Requirements Specification (SRS)
30
© HeiTech Padu Berhad
System Specification
Code”, “Bank Name”, “Bank Branch”, “PCHC Bank Code”, “PCHC
Branch Name”, “Non PCHC Bank Name/Branch”, “Payment Details”
and “BOP (Malaysia)”.
7. The use case continues at step no 10 in Basic Flow.
[A2: GIRO Fund Transfer]
1. Teller selects “Cash Activities” and chooses “Interbank GIRO” under
“Remittance” menu. The “GIRO Fund Transfer” screen will be
displayed.
2. Teller has to insert “Receiving Bank ”, “Amount” [C3: Amount
Value Condition], [A3: Use Calculator]., “Service Charge”,
“Applicant Type”, “Name”, “New IC”, “Old IC” [C4: “ew IC” and
“Old IC” value], “Oth Id Type”, “ID No.”, “Ref No.”, “Description”
and “BOP”.
3. The use case continues at step no 10 in Basic Flow.
[A3: Use Calculator]
1.
2.
3.
4.
Teller clicks “Calculator” button on the transaction screen.
The “Calculator” screen will appear.
The Teller use Calculator buttons to calculate the Amount.
The system transfers the Amount on the “Calculator” screen to the
Amount on the transaction screen.
5. The use case continues.
[A4: Calculate Rounding Adjustment]
1. If the Amount need auto rounding adjustment, the system will display
“Rounding Mechanism Adjustment” screen. [E3: Host Error
Message].
2. The system retrieves the “Original Amount”
3. The system check the Amount ends in sen to define “Rounding
Adjustment”. [C5: Rounding Adjustment Mechanism].
4. System calculates and displays “Rounding Adjustment” and
“Rounding Totals” in screen. [R5: Rounding Mechanism
Calculation].
5. Teller clicks “OK”, then system sends rounding adjustment Amount
to the Host to print within the Deposit/Payment Voucher.
[A5: Repeat Transaction]
1. Teller clicks “Repeat” button.
2. System display new screen and enters same values as previous value.
3. Teller can perform this action by press”F9”.
[A6: Cancel Transaction]
1. Teller clicks “Cancel” button.
2. System cancels current transaction and display main transaction
screen.
SBS Project System Requirements Specification (SRS)
31
© HeiTech Padu Berhad
2.2.5.4.3
System Specification
Exceptional Flow
[E1: Customer Is ot A Member]
1. If Customer is not a member, system will not receive any info from
the Host and Teller has to key in the info based on the form.
2. Use Case continues.
[E2: Hybird Server is Offline]
1. If offline at Hybrid Server happens, Teller could not download the
latest Forex rate.
2. System displays “Rate Mismatch.” error message.
3. Teller clicks “OK” button, system extends to View Electronic
Journal And Forex Rate Use Case.
4. Use Case continues.
[E3: Host Error Message]
1. If the Amount need auto rounding adjustment but the system receives
error message from the Host, Teller has to do rounding adjustment
manually.
2. Teller selects “Rounding Mechanism Adjustment” under “Others”
folder in transaction module menu.
3. Use case continues at step no 2 in [A4: Calculate Rounding
Adjustment] Alternative Flow.
2.2.5.5
Post Condition
1. The system sent the transaction and Selected Bank base branch code
to Host.
2. The EJ updated.
3. The transaction Voucher printed.
4. Teller gives the printed Vouchers to the Customer.
2.2.5.6
Rules
[R1: Foreign Amount Calculation]
- System calculate “Foreign Amount” if Ringgit Fixed is Y.
- Calculation:
Unit = 100; Foreign Amt = ( Ringgit Amt * 100) / Rate
Unit = 1; Foreign Amt = Ringgit Amt / Rate
[R2: Ringgit Amount Calculation]
- System calculate “Ringget Amount” if Ringgit Fixed is N
- Calculation:
SBS Project System Requirements Specification (SRS)
32
System Specification
© HeiTech Padu Berhad
Unit = 100; Ringgit Amt = Foreign Amt * Rate1/100
Unit = 1; Ringgit Amt = Foreign Amt * Rate
[R3: Commission Charge Amount Value]
-
Default RM2.00 if “Cable Charge Amount” is Y.
Amount is zero if “Cable Charge Amount” is N.
Any input allowed if Cable Charge is less than RM 999.99
Total amount (RM Amount + Cable Charges + Comm charges) must
not
exceed RM999,999,999.99.
If Total amount above RM5000.00, “Comm Charge Amount” is
RM0.00
If Total amount equal RM5000.00 and below, “Comm Charge
Amount” is RM2.00.
If “Country” is Bangladesh or Nepal/Nabil, “Comm Charge Amount”
is RM0.00.
If “Country” is Vietnam, India, China, Pakistan or Philippines,
“Comm Charge Amount” is RM2.00.
[R4: Cable Charge Amount Value]
- If “Country” is Singapore, selection of RM10.00/RM15.00/RM25.00.
- If “Country” is Bangladesh or Nepal/Nabil, cable charge is RM12.
- If others, default to RM25.00.
[R5: Rounding Mechanism Calculation]
2.2.5.7
Round Up Calculation:
Rounding totals = Original Amount + Rounding Adjustment
Round Down Calculation:
Rounding totals = Original Amount - Rounding Adjustment
Constraints
[C1: Foreign Amount Value]
- “Foreign Amount” input
9,999,999,999,999.99.
must
be
less
than
or
equal
to
[C2: Ringgit Amount Value]
- Amount must not be greater than MYR1,000,000.00 for Normal SSC.
- Amount checking depend on the Rate Type 1/2 :
Amount must not be greater than MYR50,000.00 .
Amount must be greater than MYR5,000.00 and less than
MYR50,000.00 for Normal SSC and Amount must be greater
than MYR5,000.00 for Forex Booth.
Amount must not be greater than MYR5,000.00 .
Amount must not be greater than MYR50,000.01 for Normal SSC
and amount must be greater than MYR10,000.01 for Forex
Booth.
SBS Project System Requirements Specification (SRS)
33
System Specification
© HeiTech Padu Berhad
[C3: Amount Value Condition]
- Format of Amount must be RMSSS,SSS,SS9.99.
- The value of Amount must not be RM0.00.
- Maximum amount RM10, 000.00.
[C4: “ew IC” value]
- “New IC” cannot be zero.
- “New IC” cannot be future date.
- Valid date for “New IC”.
[C5: Rounding Adjustment Mechanism]
- The total Amount that ends in 1, 2, 6 and 7 sen to be rounded
downwards and 3, 4, 8 and 9 sen to be rounded upwards to the nearest
multiple of 5 sen as in the table below:
Round Off to
Amount Ends the Nearest
in Sen
5 Sen
1, 2
Round Down
3, 4
Round Up
6, 7
Round Down
8, 9
Round Up
Table 2.3: Rounding Mechanism for Remittance Amount
2.2.5.8
GUI
As shown in the Appendix A – Graphical User Interface.
SBS Project System Requirements Specification (SRS)
34
System Specification
© HeiTech Padu Berhad
2.2.6
Use Case Reverse Transaction
<<include>>
Reverse Transaction
Post Teller
Require Override
Figure 2.8: Use Case Reverse Transaction
2.2.6.1
Brief Description
This use case is initiated by Post office Branch Teller and requires
Override from Post office Branch Officer. It provides capability to reverse
previous transaction if a transaction is cancelled by the customer, or fails
for any reason.The Reversal will do using Journal number or by EJ.
2.2.6.2
Characteristics of Activation
This event is activated by Post office Branch Teller and requires Override
from Post office Branch Officer.
2.2.6.3
Pre-Condition
1. The Post office Start of Day system is already launched successfully.
2. The Post office Branch Teller is identified and authenticated.
3. “Transaction” screen that contains list of Shared Banking Services
Transactions is loaded.
4. Any of financial transaction (Deposit/Payment, Withdrawal, or
Remittance) has been made.
2.2.6.4
2.2.6.4.1
Description
Basic Flow
1. This use case begins when Teller selects “Reversal” from the
“Transaction Module” menu and chooses “Reversal” [A1: Reversal
by Electronic Journal]. The “Reversal” screen will be displayed.
2. The system asks the Teller for Journal No. Teller can read Journal No
from the printed transaction Voucher.
3. The Teller Key in “Journal No” and then click “OK” button.
4. The system will display the screen that shows the related transaction
to be reversed based on Journal No.
5. The Teller clicks “Reverse” to start transaction Reversal.
6. The system request Override from Post office Branch Officer by use
Require Override Use Case.
7. When supervisor approves the requested Override, system sends the
information to the Host.
SBS Project System Requirements Specification (SRS)
35
© HeiTech Padu Berhad
System Specification
8. The system will receive Host reply and automatically the system will
ask for a Voucher printing by send “Please Insert VOUCHER Into
PASSBOOK Printer” message to the Teller.
9. At any time, Teller can click “Cancel” to cancel current process. [A2:
“Cancel” pressed].
10. The system will save the data in database.
11. The system will update EJ.
12. The use case ends when Reversal transaction screen is unloaded.
2.2.6.4.2
Alternative Flow
[A1: Reversal by Electronic Journal]
1. This alternative flow will only be used if the Teller doesn’t has the
transaction Voucher printed. The Teller can search the transaction by
using Electronic Journal.
2. Teller selects “Reversal” from the “Transaction Module” menu and
chooses “EJ Viewer”. The “EJ Viewer” screen will be displayed.
3. System shows current sign on “User ID” , current “Date” and give the
Teller options to perform the search using “Time”, “Account No”,
“Amount” , ”Sequence No ” , ”Transaction Code” or by select the
“Successful” of the financial transaction that done.
4. When the Teller choose “Time”, “Account No”, “Amount” or
”Sequence No ” option, then he has to give more information about
the transaction by edit “From” and “To” info. But if he choose
“Successful” option, then Teller can choose between “Y” and “No”
options.
5. The Teller has to clicks “Search” button; the system will display list
of records that contains info (i.e. Journal No, Date, Time, Account
No, Amount, Transaction Mode, etc) associated with selected search
criteria.
6. Teller selects one record to be reversed and then click “OK” button.
7. This Alternative Flow continues at flow number 6 in Basic Flow.
[A2: “Cancel” Pressed]
1. Teller clicks “Cancel” button.
2. System cancels current process and display main Transaction screen.
2.2.6.4.3
Exceptional Flow
Not Applicable.
2.2.6.5
Post Condition
1.
2.
3.
4.
The system saves the data in database.
The system updates EJ.
The required transaction reversed.
The transaction Voucher printed.
SBS Project System Requirements Specification (SRS)
36
© HeiTech Padu Berhad
2.2.6.6
System Specification
Rules
Not Applicable.
2.2.6.7
Constraints
Not Applicable.
2.2.6.8
GUI
As shown in the Appendix A– Graphical User Interface.
SBS Project System Requirements Specification (SRS)
37
System Specification
© HeiTech Padu Berhad
2.2.7
Use Case Inquire Balance
Post Mediator
Inquire Balance
Figure 2.9: Use Case Inquire Balance
2.2.7.1
Brief Description
This use case provides capability for Post office Branch Mediator to
check whether the transaction success in Selected Bank Host or not.
2.2.7.2
Characteristics of Activation
The event is activated by Post office Branch Mediator (which can be a
Teller, Officer, or a Manager).
2.2.7.3
Pre-Condition
1. The Post office Start of Day system is already launched successfully.
2. The Post office Branch Mediator is identified and authenticated.
3. “Transaction” screen that contains list of Shared Banking Services
Transactions is loaded.
4. Any of transaction (Deposit/Payment, Withdrawal, Account Opening,
Passbook Maintenance, Reversal or Remittance) has been made.
2.2.7.4
2.2.7.4.1
Description
Basic Flow
1. This use case begins when a Mediator selects “Inquiry” from the
“Transaction Module” menu. The “Inquiry” screen will be displayed.
2. Mediator can make Inquiry via Name/IC No, CA Last Transaction,
CA Activity, SA Activity, SA Last Transaction, Credit Card, FTT
Transaction Detail, FWTT Transaction Reference, FWTT
Transaction, GIRO Transaction Detail, HP Transaction, or Loan
Activity.
3. Mediator selects “Inquiry Type” as “Name/IC No” and enters
“Account Number” .Mediator clicks “OK”, system shows “Name/IC
Inquiry” screen. [A1: CA Last Transaction] , [A2: CA Activity] ,
[A3: SA Activity] , [A4: SA Last Transaction] , [A5: Credit Card]
, [A6: FTT Transaction Detail] , [A7: FWTT Transaction
Reference], [A8: FWTT Transaction] , [A9: GIRO Transaction
Detail], [A10: HP Transaction] , [A11: Loan Activity].
SBS Project System Requirements Specification (SRS)
38
© HeiTech Padu Berhad
System Specification
4. System sends transaction to Host and displays selected Inquiry
information on screen.
5. At any time, Teller can make the selection of “Repeat” [A12: Repeat
Transaction], or “Cancel” current Transaction [A13: Cancel
Transaction].
6. The system will update EJ.
7. The use case ends when Inquiry transaction screen is unloaded.
2.2.7.4.2
Alternative Flow
[A1: CA Last Transaction]
1. Mediator selects to “Inquiry Type” as “CA Last Transaction” and
enters “Account Number” .Mediator clicks “OK”, system shows “CA
Last Transaction Inquiry” screen.
2. Use case continues.
[A2: CA Activity]
1. Mediator selects to “Inquiry Type” as “CA Activity” and enters
“Account Number” .Mediator clicks “OK”, system shows “CA
Activity Inquiry” screen.
2. Mediator selects “Activity” as “Cash Deposit/Payment”.
3. Use case continues.
[A3: SA Activity]
1. Mediator selects to “Inquiry Type” as “SA Activity” and enters
“Account Number” .Mediator clicks “OK”, system shows “SA Last
Transaction Inquiry” screen.
2. Mediator can select “Activity” as “Cash Deposit/Payment” or “Cash
Withdrawal”.
3. Use case continues.
[A4: SA Last Transaction]
1. Mediator selects to “Inquiry Type” as “SA Last Transaction” and
enters “Account Number” .Mediator clicks “OK”, system shows “SA
Last Transaction Inquiry” screen.
2. Use case continues.
[A5: Credit Card]
1. Mediator selects to “Inquiry Type” as “Credit Card Activity” and
enters “Account Number” .Mediator clicks “OK”, system shows
“Credit Card Inquiry” screen.
2. Mediator selects “Activity” as “Cash Deposit/Payment”.
3. Use case continues.
SBS Project System Requirements Specification (SRS)
39
© HeiTech Padu Berhad
System Specification
[A6: FTT Transaction Detail]
1. Mediator selects to “Inquiry Type” as “FTT Transaction Detail” and
enters “Account Number” .Mediator clicks “OK”, system shows
“FTT Transaction Detail” screen.
2. Mediator key in “Reference Number” and clicks “OK” button.
3. Use case continues.
[A7: FWTT Transaction Reference]
1. Mediator selects to “Inquiry Type” as “FWTT Transaction Reference”
and enters “Account Number” .Mediator clicks “OK”, system shows
“FWTT Inquiry” screen.
2. Mediator key in “Reference Number” and clicks “OK” button.
3. Use case continues.
[A8: FWTT Transaction]
1. Mediator selects to “Inquiry Type” as “FWTT Transaction” and enters
“Account Number” .Mediator clicks “OK”, system shows “FWTT
Transaction Inquiry” screen.
2. Mediator has option to select country either “Philippines” or “Other
countries”.
3. If Philippines, Mediator selects “Agent Nostro” then clicks “OK”
button.
4. Use case continues.
[A9: GIRO Transaction Detail]
1. Mediator selects to “Inquiry Type” as “GIRO Transaction Detail” and
enters “Account Number” .Mediator clicks “OK”, system shows
“GIRO Transaction Detail Inquiry” screen.
2. Mediator key in “Reference Number” and clicks “OK” button.
3. Use case continues.
[A10: HP Transaction]
1. Mediator selects to “Inquiry Type” as “HP Inquiry” and enters
“Account Number” .Mediator clicks “OK”, system shows “HP
Inquiry” screen.
2. Mediator key in “Reference Number” and clicks “OK” button.
3. Use case continues.
[A11: Loan Activity]
1. Mediator selects to “Inquiry Type” as “Loan Activity” and enters
“Account Number” .Mediator clicks “OK”, system shows “Loan
Activity Inquiry” screen.
2. Use case continues.
SBS Project System Requirements Specification (SRS)
40
© HeiTech Padu Berhad
System Specification
[A12: Repeat Transaction]
1. Teller clicks “Repeat” button.
2. System display new screen and enters same values as previous values.
3. Teller can perform this action by press”F9”.
[A13: Cancel Transaction]
1. Teller clicks “Cancel” button.
2. System cancels current transaction and display main transaction
screen.
2.2.7.4.3
Exceptional Flow
Not Applicable.
2.2.7.5
Post Condition
1. The system updates EJ.
2. Retrieved the selected Inquiry information.
2.2.7.6
Rules
Not Applicable.
2.2.7.7
Constraints
Not Applicable.
2.2.7.8
GUI
As shown in the Appendix A– Graphical User Interface.
SBS Project System Requirements Specification (SRS)
41
System Specification
© HeiTech Padu Berhad
2.2.8
Use Case Maintain Passbook
Post Teller
Maintain Passbook
Figure 2.10: Use Case Maintain Passbook
2.2.8.1
Brief Description
This use case provides capability for Customer to maintain his/her
Selected Bank Passbook using Post office Branch. Customer does not
interact with the system directly; instead, for this use case, a client
interacts via a Post office Branch Teller.
2.2.8.2
Characteristics of Activation
This event is activated by Post office Branch Teller.
2.2.8.3
Pre-Condition
1. The Post office Start of Day system is already launched successfully.
2. The Post office Branch Teller is identified and authenticated.
3. “Transaction” screen that contains list of Shared Banking Services
Transactions is loaded.
4. Customer is opened Saving Account Passbook successfully.
5. The Customer provides his/her Passbook to Teller for maintain.
2.2.8.4
2.2.8.4.1
Description
Basic Flow
1. This use case begins when a Customer requires Teller to maintain
his/her Passbook request update Passbook, change posting line or
change Passbook status to new.
2. Teller selects “Passbook Maintenance” under “Transaction Module”
menu and chooses “Passbook Update” [A1: Change Posting Line],
[A2: Change Passbook Status To ew]. The “Passbook Update”
screen will display.
3. Teller key in “Account Number”, “Passbook Balance”, “Passbook
Number” and then click “OK” button. [C1: Passbook Balance
Condition].
4. The system verify the account number whether it within cleaning
code or not by check the 2nd and 3rd digit of account number against
SBS Project System Requirements Specification (SRS)
42
© HeiTech Padu Berhad
System Specification
the branch clearing code. [A3: Calculate Commission].
5. The system validate Customers’ product typed based on Account
Number.
6. At any time, Teller can make the selection of “Repeat” [A4: Repeat
Transaction], or “Cancel” current Transaction [A5: Cancel
Transaction].
7. The system will send the transaction to Host.
8. The system will receive Host reply and automatically the system will
ask for a Voucher printing by send “Please insert PASSBOOK to
PASSBOOK Printer” message to the Teller.
9. The system will update EJ.
10. The use case ends when the “Passbook Maintenance” screen is
unloaded.
2.2.8.4.2
Alternative Flow
[A1: Change Posting Line]
1. Teller selects “Passbook Maintenance” under “Transaction Module”
menu and chooses “Change Posting Line”. The “Change Posting
Line” screen will display.
2. Teller key in “Account Number”, “Previous”, “New” and then click
“OK” button.
3. The use case continues at step no 4 in Basic Flow.
[A2: Change Passbook Status To ew]
1. Teller selects “Passbook Maintenance” under “Transaction Module”
menu and chooses “Change Passbook Status To New”. The “Change
Passbook Status To New” screen will display.
2. Teller key in “Account Number” and “Passbook Number”
3. Teller selects “Condition of Sign” whether it “Solely to Sign”, “Either
One to Sign” or “All to Sign”, and then click “OK” button.
4. The use case continues at step no 4 in Basic Flow.
[A3: Calculate Commission]
1. If account number is not within the clearing code, the system will pop
up “Commission” screen. [E1: Receive Error From The Host].
2. The Teller chooses the technique that the Customer will use to pay the
commission whether by paying “Cash” or “deduct”.
3. The system calculates “Commission Amount” and display to the
Teller [C2: Commission Amount Status].
4. The system keeps commission accumulated by Teller in Teller Table
file.
5. The Teller collects Commission Amount from the Customer.
6. The Teller click “OK” button, the “Commission” screen is unloaded.
7. The use case continues.
SBS Project System Requirements Specification (SRS)
43
© HeiTech Padu Berhad
System Specification
[A4: Repeat Transaction]
1. Teller clicks “Repeat” button.
2. System display new screen and enters same values as previous values.
3. Teller can perform this action by press”F9”.
[A5: Cancel Transaction]
1. Teller clicks “Cancel” button.
2. System cancels current transaction and display main transaction
screen.
2.2.8.4.3
Exceptional Flow
[E1: Receive Error From The Host]
1. If account number is not within the clearing code and the system
receives error message from the Host, the Teller has to do commission
manually.
2. Teller selects “Commission” under “Others” folder in transaction
module menu. “Commission” screen will be displayed.
3. Use case continues at step no 2 in [A3: Calculate Commission]
Alternative Flow.
2.2.8.5
Post Condition
1.
2.
3.
4.
5.
2.2.8.6
The transaction sent to Host.
The Customers’ Passbook maintained.
The transaction Voucher printed.
Teller gives the printed Voucher to the Customer.
The EJ updated.
Rules
Not Applicable.
2.2.8.7
Constraints
[C1: Passbook Balance Condition]
- Format of “Passbook Balance” must be RMSSS,SSS,SS7.99.
- The value of “Passbook Balance” must not be RM0.00
[C2: Commission Amount Status]
The conditions to calculate Commission Amount are as follow:
- If the Commission Type is “Nil”, then the “Commission Amount”
will be 0.00.
- For SAFE Transaction:
Commission Amount must not be less than minimum amount
SBS Project System Requirements Specification (SRS)
44
System Specification
© HeiTech Padu Berhad
of commission defined in Tellers’ profile.
Commission Amount must be less than RM1000.00.
- For CBS Transaction:
Commission Type must be “Cash” or “Nil”.
Commission Amount must not be less than minimum amount
of commission defined in Tellers’ profile.
2.2.8.8
GUI
As shown in the Appendix A– Graphical User Interface.
SBS Project System Requirements Specification (SRS)
45
System Specification
© HeiTech Padu Berhad
2.2.9
Use Case Require Override
Require Override
Post Officer
Post Teller
Figure 2.11: Use Case Require Override
2.2.9.1
Brief Description
This use case used to verify transactions done by Teller. The Teller
request Override from Post office Branch Officer This use case take place
when some criteria of the transaction have done by Teller need Officer
approval (ex: transaction exit Teller limit, Teller reverse transaction, etc.).
2.2.9.2
Characteristics of Activation
The event is activated by Post office Branch Officer.
2.2.9.3
Pre-Condition
1. The Post office Start of Day system is already launched successfully.
2. The Post office Branch Officer is identified and authenticated.
3. Any of transaction from Teller is in process and need to approval.
2.2.9.4
2.2.9.4.1
Description
Basic Flow
1. The system requests supervisor Override by showing “Override”
dialog box to the Teller.
2. The Teller has the options to perform “Local” Override, “Remote”
Override or “Cancel” the Override.
3. The Teller selects “Local” option [A1: Remote Override], then the
system will displays “Local Override” dialog box.
4. Officer needs to go to the Teller PC and checks all the information.
5. The Officer can approve the transaction by enter “User ID” and
“Password” and clicks “OK” button. [A2: Cancel Local Override].
6. The system verifies “User ID” and “Password” and if they are correct,
the Teller can proceed with transaction. [E1: Invalid “User ID” or
“Password”].
7. The use case ends when Override screen is unloaded.
SBS Project System Requirements Specification (SRS)
46
© HeiTech Padu Berhad
2.2.9.4.2
System Specification
Alternative Flow
[A1: Remote Override]
Remote Override is done at Post office Officer’s workstation. An
Override server will be automatically running at each supervisor’s
workstation during PC startup.
1. The Teller selects “Remote” option, then the system will displays
“Supervisor List” dialog box.
2. Teller should select one of the supervisors from the list and click
“OK” button.
3. The system sends all the transaction information on the Teller’s
screen to the selected Officer’s workstation.
4. On Officer’s workstation, the system will display list of request from
Teller.
5. The supervisor can clicks “Refresh” button to see any new request,
“Exit” to close the dialog box or press “F10” key to fetch back the list.
6. If the supervisor doesn’t response to the Override, then the Override
will be timeout. [E2: Override Time Out].
7. Officer performs the Override by select which Teller he wants to
Override, then the system will display “Remote Override Screen
Viewer”.
8. Officer must check the information that he receive with the Override.
9. The Officer has the options to “Approve”, “Reject” or “Return” the
Teller transaction.
10. The Officer can approve [A3: Reject Remote Override], [A4:
Return Remote Override] the transaction by clicks “Approve” and
enters “Supervisor ID” and “Password”.
11. The system verifies “Supervisor ID” and “Password” and if they are
correct, the transaction will proceed and “Remote Override Screen
Viewer” will disappear. [E1: Invalid “User ID” or “Password”]
12. The use case ends.
[A2: Cancel Local Override]
1. The Officer can cancel the transaction by clicks “Cancel” button.
2. The System cancels the transaction.
3. The use case ends.
[A3: Reject Remote Override]
1. The Officer can reject the transaction by clicks “Reject” in “Remote
Override Screen Viewer”
2. The system disappear “Remote Override Screen Viewer” and
transaction done by Teller will be rejected.
3. The system sends and displays “Supervisor CANCEL Remote
Override!” message in Tellers’ workstation.
4. The Teller should click “OK” button on the message box and the
transaction screen will be closed.
5. The use case ends.
SBS Project System Requirements Specification (SRS)
47
© HeiTech Padu Berhad
System Specification
[A4: Return Remote Override]
1. The Officer can return the transaction by clicks “Return” in “Remote
Override Screen Viewer”, and then a reply message box will appear
asking the Officer to enter the reason for return the transaction.
2. The Officer must enter message and click “OK” button or he can
cancel by click “Cancel” button.
3. The system sends and displays the Officer return message on Tellers’
workstation.
4. The Teller will see the return message in transaction screen, he can do
the correction again and re-submit the transaction and the system will
request for Override again.
5. The use case ends.
2.2.9.4.3
Exceptional Flow
[E1: Invalid “User ID” or “Password”]
2. If “User ID” and “Password” is invalid, a error message will appear
3. The Officer should clicks “OK” button on the error message and
renter the correct “User ID” and “Password”.
[E2: Override Time Out]
2. If the Override times is out [C1: Override Response Time], the
system the system remove the expired requests from the queue and
displays “Time OUT !!, Please CHOOSE another Supervisor”
message on Teller’s workstation.
3. The Teller clicks “OK” button and the message box will disappear.
4. The system will ask for Override again.
2.2.9.5
Post Condition
1. The requested Override is approved, returned or canceled by Post
office Officer.
2.2.9.6
Rules
Not Applicable.
2.2.9.7
Constraints
[C1: Override Response Time]
Post office Officer must perform Override within 3 minutes.
2.2.9.8
GUI
As shown in the Appendix A – Graphical User Interface.
SBS Project System Requirements Specification (SRS)
48
System Specification
© HeiTech Padu Berhad
2.2.10 Use Case Manage User Profile
Post Manager
Manage User Profile
Figure 2.12: Use Case Manage User Profile
2.2.10.1
Brief Description
This use case is initiated by Post office Manager. It provides the
capability to enable Manager to list existing users or add new user,
modify user, force user sign off, unlock, revoke, unrevoked and reset
password of users. And save the data in database.
2.2.10.2
Characteristics of Activation
The event is activated by Post office Branch Manager.
2.2.10.3
Pre-Condition
1. The Post office Start of Day system is already launched successfully.
2. The Post office Branch Manager is identified and authenticated.
2.2.10.4 Description
2.2.10.4.1 Basic Flow
1. This use case begins when a Manager selects “User Profile” in
“Shared Banking Service” screen.
2. Manager makes selection to add new user, modify user, force user
sign off, unlock, revoke, unrevoked or reset password of users.
3. Manager selects “Add” under “User Profile” folder to add new user.
“Add New User” screen will display. [A1: Modify User], [A2: List
Users], [A3: Force User Sign Off], [A4: Unlock User], [A5:
Revoke/Unrevoke User], [A6: Reset Password].
4. Manager selects “User Role” and inserts “User ID”. Manager fills in
“User Information” and clicks “OK” button.
5. Upon successful Manager add user, system shows “Record
successfully created.” message.
6. At any screen, Manager can close screen and cancel the process. [A7:
“Cancel” Pressed].
7. The system will save the data in database.
SBS Project System Requirements Specification (SRS)
49
© HeiTech Padu Berhad
System Specification
8. The use case ends.
2.2.10.4.2 Alternative Flow
[A1: Modify User]
1. Manager selects “Modify” under “User Profile” folder to modify user
role. “Modify User” screen will display.
2. Manager selects “User ID”. System displays all user information on
the screen and the current user role will be checked.
3. If Manager wants to change the user’s role, uncheck the current user
role and check the new role.
4. Manager Fill in the required information and clicks “OK” button.
5. Upon successful Manager modify user, system displays “Record
Successfully Updates” message.
6. After modification done, the system will ask User to change password
during next Sign In.
7. Use case continues at step no 6 in Basic Flow.
[A2: List Users]
1. Manager selects “User List” under “User Profile” folder to show all
Post office branch users. “User List” screen will display.
2. System will list all the users of the Post office Branch and their signon status.
3. Manager can clicks “Print” button to print the list.
4. Use case continues at step no 6 in Basic Flow.
[A3: Force User Sign Off]
1. This alternative use if Teller accidentally logged out (unusually
terminated) eg: pc reboot suddenly, Manager can perform force user
sign off to allow the Teller to Sign In again.
2. Manager selects “Force User Sign Off” under “User Profile” folder.
“Force User Sign Off” dialog will display. Manager inserts “User ID”
and clicks “OK” button.
3. Upon successfully signing off the user, system displays “User
successfully signed off” message.
4. Use case continues at step no 6 in Basic Flow.
[A4: Unlock User]
1. This alternative use if one of users locked due to 3 failed attempts
Sign In.
2. Manager selects “Unlock User” under “User Profile” folder. “Unlock
User” dialog will display. Manager inserts “User ID” and clicks “OK”
button.
3. Upon successfully unlocking the user, system displays “User
successfully unlocked” message.
4. Use case continues at step no 6 in Basic Flow.
SBS Project System Requirements Specification (SRS)
50
© HeiTech Padu Berhad
System Specification
[A5: Revoke/Unrevoke User]
1. Manager selects “Revoke/Unrevoke” under “User Profile” folder.
“Revoke/Unrevoke User” dialog will display.
2. Manager inserts “User ID” and clicks “OK” button.
3. If the inserted User ID belongs to a revoked user, the user’s status will
be updated to N – Not Sign On. Else if the inserted User ID belongs to
a normal user, the user’s status will be updated to R – Revoked.
4. Upon successfully revoke/unrevoke the user, system shows a
message.
5. Use case continues at step no 6 in Basic Flow.
[A6: Reset Password]
1. This alternative flow use to reset user password response to user
request in case the user forgotten his password.
2. Manager selects “Reset Password” under “User Profile” folder. “Rest
Password” screen will display.
3. Manager selects “User ID” and system shows “User Name”. Manager
fills in the new password and clicks “OK”.
4. Upon successful resetting the password, “Password successfully
reset.” message will be shown.
5. After resetting password done, the system will ask the user to change
password during next Sign In.
6. Use case continues at step no 6 in Basic Flow.
[A7: “Cancel” Pressed]
1. Manager clicks “Cancel” button.
2. System cancels current process and display Shared Banking Service
screen.
2.2.10.4.3 Exceptional Flow
Not Applicable.
2.2.10.5
Post Condition
1. The new data about Post office Branch users saved in the database.
2.2.10.6
Rules
Not Applicable.
2.2.10.7
Constraints
Not Applicable.
SBS Project System Requirements Specification (SRS)
51
© HeiTech Padu Berhad
2.2.10.8
System Specification
GUI
As shown in the Appendix A– Graphical User Interface.
SBS Project System Requirements Specification (SRS)
52
System Specification
© HeiTech Padu Berhad
2.2.11 Use Case Perform End of Day
<<extend>>
Perform End of Day
Post Teller
Require Override
Figure 2.13: Use Case Perform End of Day
2.2.11.1
Brief Description
This use case provides capability for Teller to view and print several
report that assist users during balancing. Furthermore, this use case allows
Manager to perform reactivate online posting.
2.2.11.2
Characteristics of Activation
The event is activated by Post office Branch Teller. Also in this event,
Manager initiates reactivate online posting function.
2.2.11.3
Pre-Condition
1. The Post office Start of Day system is already launched successfully.
2. The Post office Branch Teller or Manager is identified and
authenticated.
2.2.11.4 Description
2.2.11.4.1 Basic Flow
1. This use case begins when a Teller expands “End of Day” folder on
Shared Banking Services. There are two folders under End of Day
which are “Balancing” and “Reporting”.
2. Teller can make options of the following:
a. Select “Teller Total” under “Balancing” folder to perform and
print Teller total ,
b. select “Branch Total” under “Balancing” folder to perform and
print Branch total,
c. select “Final Branch Total” under “Balancing” folder to perform
and print final Branch total [A1:Require Override], [E1:
Transaction eeds After Final Branch Total],
d. select “Teller Activity Report” under “Report” folder to perform
and print Teller activity report,
e. or select “Branch Activity Report” under “Report” folder to
perform and print Branch activity report.
3. System request required data from Host.
SBS Project System Requirements Specification (SRS)
53
© HeiTech Padu Berhad
System Specification
4. System asks Teller to insert paper for printing.
5. At any screen, Teller can close screen and cancel the process. [A3:
“Cancel” Pressed].
6. Use case ends.
2.2.11.4.2 Alternative Flow
[A1: Require Override]
1. System Require Override by extend to Require Override Use Case.
2. If Officer approves the Override, then use case continues at step no 3
in Basic Flow.
[A2: Reactivate Online Posting]
1. This alternative allows Manager to restart the system if a transaction
needs to be performed after Final Branch Total is done.
2. Manager expand “Manager Function” folder on Shared Banking
Services and clicks “Reactivate Online Posting” to reactivate.
3. Use case ends.
[A3: “Cancel” Pressed]
1. Teller clicks “Cancel” button.
2. System cancels current process and display Shared Banking Service
screen.
2.2.11.4.3 Exceptional Flow
[E1: Transaction eeds After Final Branch Total]
1. If a transaction needs to be performed after final branch total has been
initiated unless authorized by manager. [A2: Reactivate Online
Posting], [C1: Final Branch Total Done].
2.2.11.5
Post Condition
1. End of Day Reports are viewed and printed.
2. End of Day transmit related information for QC file to Hybrid Server
for consolidation of QC file for all branches. Then consolidated QC
file will be submitted to Selected Bank via FTP.
3. Online posting reactivated by Manager.
2.2.11.6
Rules
Not Applicable.
SBS Project System Requirements Specification (SRS)
54
© HeiTech Padu Berhad
2.2.11.7
System Specification
Constraints
[C1: Final Branch Total Done]
No transaction allowed after final branch total done.
2.2.11.8
GUI
As shown in the Appendix A– Graphical User Interface.
SBS Project System Requirements Specification (SRS)
55
System Specification
© HeiTech Padu Berhad
2.2.12 Use Case Stock Control Register
Post Mediator
Stock Control Register
Figure 2.14: Use Case Stock Control Register
2.2.12.1
Brief Description
This use case is for Manager or Officer to control stock of Passbook and
ATM card. It provides capability to add Stock, distribute Stock, register
damaged/lost Stock, maintain Stock distribution, register Stock control
and view Stock acknowledgement.
2.2.12.2
Characteristics of Activation
The event is activated by Post office Mediator (which can be Manager,
Officer or Teller).
2.2.12.3
Pre-Condition
1. The Post office Start of Day system is already launched successfully.
2. The Post office Branch Mediator is identified and authenticated.
2.2.12.4 Description
2.2.12.4.1 Basic Flow
1. This use case begins when a Mediator expands “Stock Control
Register” folder on Shared Banking Services.
2. Manager or Officer clicks “Add Stock” under “Stock Control” folder
to add stock. “Add Stock” screen will be displayed. [A1: Distribute
Stock], [A2: Register Damaged/Lost Stock], [A3: Stock Control
Register].
3. Manager or Officer Selects “Stock Type”, fills in “First Serial
Number” and “Last Serial Number”.
4. System calculates and displays total number of Stock based on Serial
No.
5. Manager or Officer clicks “OK”. System adds Stock and shows
“Stock successfully added” messages. [C1: umber of Created
Record].
6. At any screen, Mediator can close screen and cancel the process. [A6:
“Cancel” Pressed].
SBS Project System Requirements Specification (SRS)
56
© HeiTech Padu Berhad
System Specification
7. System will save data in database.
8. Use case ends when “Stock Control Register” closed.
2.2.12.4.2 Alternative Flow
[A1: Distribute Stock]
1. This alternative flow is for the Manager or Officer to distribute stock
to a Teller.
2. Manager or Officer clicks “Stock Distribution” under “Stock Control”
folder in Shared Banking Service screen.
3. System displays “Stock Distribution” screen that contains list of all
registered stocks, including the serial number and total number of the
stock.
4. Select Teller “User ID” whom the stock will be distributed to.
5. Tick on the stock which to be distributed to that Teller in “List of
Stock” section. [C2: umber Of Distributed Stock To Teller].
6. The selected Stock will be listed in the “Distribution List” section.
7. If the Stock to be given isn’t in full amount, change the “Last Serial
Number”. System calculates total number of Stock according to the
serial number.
8. To complete Stock distribution, clicks “OK” button. System will
update Stock records and displays “Record Successfully updated”.
9. Teller will get an acknowledgement receipt upon successful stock
distribution. System displays “New Stock has been distributed. Please
go to View Acknowledgement under Stock Control Module.”
message in Teller PC. [A4: View Stock Acknowledgement].
10. Use case continues at step no 6 in Basic Flow.
[A2: Register Damaged/Lost Stock]
1. This alternative flow is for Mediator (which can be Manager, Officer
or Teller) to record damaged/lost Stock.
2. Mediator clicks “Damaged/Lost Stock Register” under “Stock
Control” folder in Shared Banking Service screen. “Damaged/Lost
Stock Register” screen will be displayed.
3. Mediator selects “Stock Type”, fills in the “First Serial Number” and
“Last Serial Number” of the damaged /lost Stock.
4. System calculates and displays total number of Stock based on Serial
No.
5. Selects “Reason” of registering the stock, whether it is damaged or
lost and clicks “OK” button.
6. System updates Stock and shows “Stock successfully updated”
message.
7. Use case continues at step no 6 in Basic Flow.
[A3: Stock Control Register]
1. This alternative flow uses by Manager/Officer to show the registered
Stock control.
2. Clicks “Stock Control Register” under “Stock Control” folder in
SBS Project System Requirements Specification (SRS)
57
© HeiTech Padu Berhad
3.
4.
5.
6.
7.
8.
System Specification
Shared Banking Service screen. “Stock Control Register” screen will
be displayed.
Selects “Month” of which the Stock control register is to be displayed
and “Stock Type”.
System displays record for selected stock of the selected month in
both “Supervisor” and “Teller” sections. [C4: Time For Keeping
Record].
In “Supervisor” section, record will be displayed sorted by Date.
In “Teller” section, record will be displayed sorted by User ID.
Clicks “Print” button to print the report.
Use case continues at step no 6 in Basic Flow.
[A4: View Stock Acknowledgement]
1. This alternative flow will only used by Teller to alert him that there is
some Stock distributed to him.
2. The Teller selects “View Stock Acknowledgement” under “Stock
Control” Module. “Stock Acknowledgement” screen will be
displayed.
3. Teller can accept by clicks “OK” button or reject any of the
distributed Stock by tick on the “Reject” column at the stock that he
would like to reject.
4. Upon successful stock acceptance, a message “Stock successfully
accepted” will be displayed.
5. If there is rejected Stock, Manager/Offices will get an
acknowledgement receipt in his PC [C3: Supervisor PC Is Off] and
he need to cancel the distributed stock [A5: Maintain Stock
Distribution]. Manager or Officer need to do Stock Distribution
again.
6. Use case continues at step no 6 in Basic Flow.
[A5: Maintain Stock Distribution]
1. This alternative flow is for Manager or Officer to cancel the
distributed Stock, after acknowledgement receipt is sent to the Teller
or after the Teller rejects the distributed Stock.
2. Clicks “Stock Distribution Maintenance” under “Stock Control”
folder in Shared Banking Service screen. “Stock Distribution
Maintenance” screen will be displayed.
3. Selects “Searching Option”. Searching Option can be by “Stock
Type”, “Date” or “User ID”.
4. Clicks “View” button. System displays all distributed stocks of
today’s date sorted by “Stock Type if none of the searching option.
Otherwise, the record will be displayed according to the searching
option.
5. The status of each Stock will be displayed in “Status” column.
6. To cancel the distributed stock, ticks on “Remove” column at the
stock which to be canceled.
SBS Project System Requirements Specification (SRS)
58
© HeiTech Padu Berhad
System Specification
7. To complete maintain Stock distribution clicks “OK” button. System
cancels Stock from being distributed and displays “Stock successfully
cancelled” message will be shown.
8. Use case continues at step no 6 in Basic Flow.
[A6: “Cancel” Pressed]
1. Mediator clicks “Cancel” button.
2. System cancels current process and display Shared Banking Service
screen.
2.2.12.4.3 Exceptional Flow
Not Applicable.
2.2.12.5
Post Condition
1. System saved the data in database.
2. The Stock will be cancelled, added, maintained, registered, viewed or
distributed.
3. “Stock Control Register” report will be viewed and printed.
2.2.12.6
Rules
Not Applicable.
2.2.12.7
Constraints
[C1: umber of Created Record]
Each serial number will be created as one record.
[C2: umber Of Distributed Stock To Teller]
Manager or Officer can distribute more than one type of stock to a Teller
at one time.
[C3: Supervisor PC Is Off]
If the Teller rejects the Stock and Supervisor PC is off, Supervisor will
get the acknowledgement after Sign In.
[C4: Time For Keeping Record]
Records will be kept for 3 months. After 3 months, housekeeping will be
done. During housekeeping, only fully distributed stock will be clean up.
Outstanding stock will not be deleted.
2.2.12.8
GUI
As shown in the Appendix A– Graphical User Interface.
SBS Project System Requirements Specification (SRS)
59
System Specification
© HeiTech Padu Berhad
2.2.13 Use Case View Electronic Journal And Forex Rate
Post Mediator
View Electronic Journal And Forex
Rate
Figure 2.15: Use Case View Electronic Journal And Forex Rate
2.2.13.1
Brief Description
This use case is initiated by Post office Mediator. It provides capability to
view Electronic Journal. All transactions and system activities such as
Start of Day, Sign In, and Sign Off will be updated in an Electronic
Journal for tracking and recovery exercises. In addition, this use case
provides utility to view and download rate provided by Selected Bank for
remittance purpose.
2.2.13.2
Characteristics of Activation
The event is activated by Post office Branch Mediator (which can be
Manager, Teller or Officer).
2.2.13.3
Pre-Condition
1. The Post office Start of Day system is already launched successfully.
2. The Post office Branch Mediator is identified and authenticated.
2.2.13.4 Description
2.2.13.4.1 Basic Flow
1. This use case begins when a Mediator selects “EJ viewer” folder on
Shared Banking Services. “EJ Viewer” screen will be displayed. [A1:
View Forex Rate].
2. System shows current “Date” and give the Mediator options to
perform the search using “Time”, “Account No”, “Amount” ,
”Sequence No ” , ”Transaction Code” or by select the “Successful” of
the financial transaction that done. But if the signed in Mediator is
Manager or Officer, he also can do search in EJ using “User ID”.
3. When the Mediator choose “Time”, “Account No”, “Amount” or
”Sequence No ” option, then he has to give more information about
the transaction by edit “From” and “To” info. But if he choose
“Successful” option, then Mediator can choose between “Y” and
“No” options.
SBS Project System Requirements Specification (SRS)
60
© HeiTech Padu Berhad
System Specification
4. The Mediator has to clicks “Search” button; the system will display
list of records that contains info (i.e. Journal No, Date, Time, Account
No, Amount, Transaction Mode, etc) associated with selected search
criteria.
5. Use case ends when “EJ Viewer” screen is unloaded.
2.2.13.4.2 Alternative Flow
[A1: View Forex Rate]
1. This alternative flow begins when a Mediator selects “FX Rate”
folder on Shared Banking Services. “Bank Currency Converter Menu”
screen will be displayed.
2. The system will list the rates of the last updated date and time.
3. To download new rate once again, click “Download Rate” button.
4. The system will inquire the last Forex rate at Host and update the
current Forex rate.
5. The system will save the data in database.
6. Use case ends when “Bank Currency Converter Menu” screen is
unloaded.
2.2.13.4.3 Exceptional Flow
Not Applicable
2.2.13.5
Post Condition
1. Forex rate updated and save in database.
2. EJ and Forex rate viewed.
2.2.13.6
Rules
Not Applicable.
2.2.13.7
Constraints
Not Applicable.
2.2.13.8
GUI
As shown in the Appendix A– Graphical User Interface.
SBS Project System Requirements Specification (SRS)
61
Data Specification
© HeiTech Padu Berhad
3.
DATA SPECIFICATIO
This section describes the data involved in the SBS system; including data
elements, database requirements, data conversion, data specification and data
migration.
3.1
TELLER
Description:
This Table Stores all the data regarding Post office Branch Teller.
Column ame
branch_code
txn_date
oper_id
nrm_tot_amt_cr1
nrm_tot_amt_dr1
nrm_tot_amt_cr2
nrm_tot_amt_dr2
nrm_tot_amt_cr3
nrm_tot_amt_dr3
nrm_tot_amt_cr4
nrm_tot_amt_dr4
nrm_tot_amt_cr5
nrm_tot_amt_dr5
nrm_tot_amt_dr6
rvs_tot_amt_cr1
rvs_tot_amt_dr1
rvs_tot_amt_cr2
rvs_tot_amt_dr2
rvs_tot_amt_cr3
rvs_tot_amt_dr3
rvs_tot_amt_cr4
rvs_tot_amt_dr4
rvs_tot_amt_cr5
rvs_tot_amt_dr5
rvs_tot_amt_cr6
rvs_tot_amt_dr6
nrm_ctr_cr1
nrm_ctr_dr1
nrm_ctr_cr2
nrm_ctr_dr2
nrm_ctr_cr3
nrm_ctr_dr3
nrm_ctr_cr4
nrm_ctr_dr4
nrm_ctr_cr5
nrm_ctr_dr5
TELLER
Data Type
Char (10)
Char (8)
Char (10)
Long Integer(4)
Long Integer(4)
Long Integer(4)
Long Integer(4)
Long Integer(4)
Long Integer(4)
Long Integer(4)
Long Integer(4)
Long Integer(4)
Long Integer(4)
Long Integer(4)
Long Integer(4)
Long Integer(4)
Long Integer(4)
Long Integer(4)
Long Integer(4)
Long Integer(4)
Long Integer(4)
Long Integer(4)
Long Integer(4)
Long Integer(4)
Long Integer(4)
Long Integer(4)
Long Integer(4)
Long Integer(4)
Long Integer(4)
Long Integer(4)
Long Integer(4)
Long Integer(4)
Long Integer(4)
Long Integer(4)
Long Integer(4)
Long Integer(4)
Description
Branch Code
Transaction Date
Operator Id
Cash Amount Credit 1
Cash Amount Debit 1
Cash Amount Credit 2
Cash Amount Debit 2
Cash Amount Credit 3
Cash Amount Debit 3
Cash Amount Credit 4
Cash Amount Debit 4
Commission Amount Credit 1
Commission Amount Credit 2
Rounding Adjustment Dr
Reversal Cash Amount Credit1
Reversal Cash Amount Debit1
Reversal Cash Amount Credit2
Reversal Cash Amount Debit2
Reversal Cash Amount Credit3
Reversal Cash Amount Debit3
Reversal Cash Amount Credit4
Reversal Cash Amount Debit4
Reversal Cash Amount Credit5
Reversal Cash Amount Debit5
Reversal Cash Amount Credit6
Reversal Cash Amount Debit6
Counter Amount Credit1
Counter Amount Debit1
Counter Amount Credit2
Counter Amount Debit2
Counter Amount Credit3
Counter Amount Debit3
Counter Amount Credit4
Counter Amount Debit4
Counter Amount Credit5
Counter Amount Debit5
SBS Project System Requirements Specification (SRS)
62
Data Specification
© HeiTech Padu Berhad
Column ame
nrm_ctr_cr6
nrm_ctr_dr6
rvs_ctr_cr1
rvs_ctr_dr1
rvs_ctr_cr2
rvs_ctr_dr2
rvs_ctr_cr3
rvs_ctr_dr3
rvs_ctr_cr4
rvs_ctr_dr4
rvs_ctr_cr5
rvs_ctr_dr5
rvs_ctr_cr6
rvs_ctr_dr6
nrm_ftxn
rvs_ftxn
nrm_ntxn
rvs_ntxn
TELLER
Data Type
Description
Long Integer(4) Counter Amount Credit6
Long Integer(4) Counter Amount Debit6
Long Integer(4) Reversal Counter Amount Credit1
Long Integer(4) Reversal Counter Amount Debit1
Long Integer(4) Reversal Counter Amount Credit2
Long Integer(4) Reversal Counter Amount Debit2
Long Integer(4) Reversal Counter Amount Credit3
Long Integer(4) Reversal Counter Amount Debit3
Long Integer(4) Reversal Counter Amount Credit4
Long Integer(4) Reversal Counter Amount Debit4
Long Integer(4) Reversal Counter Amount Credit5
Long Integer(4) Reversal Counter Amount Debit5
Long Integer(4) Reversal Counter Amount Credit6
Long Integer(4) Reversal Counter Amount Debit6
Long Integer(4) Financial Transaction
Long Integer(4) Reversal Financial Transaction
Long Integer(4) Non Financial Transaction
Long Integer(4) Reversal Non Financial Transaction
Table 3.1: Table TELLER
SBS Project System Requirements Specification (SRS)
63
Data Specification
© HeiTech Padu Berhad
3.2
TRASLOG
Description:
This table keeps all transactions transacted by a branch. It is an audit trail of
the transactions performed by each teller of a particular branch.
Column ame
branch_code
base_brcode
txn_date
txn_time
mach_no
saftera_id
journal_no
ref_date
ref_time
ref_machno
txn_mode
txn_code
rvs_code
oper_id
oper_role
auth_id
auth_role
tdf_ind1
tdf_ind2
tdf_ind3
tdf_ind4
tdf_ind5
tdf_ind6
txn_ind1
txn_ind2
txn_ind3
txn_ind4
rpt_grp1
rpt_grp2
rpt_grp3
rpt_grp4
rpt_grp5
rpt_grp6
TRASLOG
Data Type
Char (10)
Char (10)
Char (8)
Char (6)
Char (2)
Char (6)
Char (10)
Char (8)
Char (6)
Char (2)
Char (1)
Char (6)
Char (6)
Char (10)
Binary (1)
Char (10)
Binary (1)
Binary (1)
Binary (1)
Binary (1)
Binary (1)
Binary (1)
Binary (1)
Binary (1)
Binary (1)
Binary (1)
Binary (1)
Binary (1)
Binary (1)
Binary (1)
Binary (1)
Binary (1)
Binary (1)
Description
Branch Code
Base Branch Code
Transaction Date
Transaction time
Machine No
Saftera Id
Journal No
Reference Date
Reference Time
Reference Machine No
Transaction Mode
Transaction Code
Reversal Code
Operator ID
Operator Role
Author ID
Author Role
Tdf Indicator 1
Tdf Indicator 2
Tdf Indicator 3
Tdf Indicator 4
Tdf Indicator 5
Tdf Indicator 6
Transaction Indicator 1
Transaction Indicator 2
Transaction Indicator 3
Transaction Indicator 4
Report Group 1
Report Group 2
Report Group 3
Report Group 4
Report Group 5
Report Group 6
SBS Project System Requirements Specification (SRS)
64
Data Specification
© HeiTech Padu Berhad
Column ame
ref_fid1
ref_fid2
ref_fid3
ref_fid4
ref_fid5
ref_fid6
amt_ctr
amt_len
vfl_len
txn_fld
TRASLOG
Data Type
LongInteger(4)
LongInteger(4)
LongInteger(4)
LongInteger(4)
LongInteger(4)
LongInteger(4)
LongInteger(4)
LongInteger(4)
LongInteger(4)
LongInteger(4)
Memo
Description
Reference Field Id 1
Reference Field Id 2
Reference Field Id 3
Reference Field Id 4
Reference Field Id 5
Reference Field Id 6
Amount Counter
Amount Length
Variable Fixed Length
Transaction Field
Table 3.2: Table TRASLOG
3.3
UPLCTRL
Description:
This table handles transaction information to be uploaded to the deployment
server.
Column ame
txn_date
txn_time
mach_no
ttl_rec_read
oper_id
transmit_date
transmit_time
UPLCTRL
Data Type
Char (8)
Char (6)
Char (2)
Long Integer (4)
Char (10)
Char (8)
Char (6)
Description
Transaction Date
Transaction Time
Machine No
Total Record Read
Operator ID
Transmission Date
Transmission Time
Table 3.3: Table UPLCTRL
SBS Project System Requirements Specification (SRS)
65
Data Specification
© HeiTech Padu Berhad
3.4
BRACH
Description:
This table stores information regarding a branch.
Column ame
br_code
clearing_code
base_br_code
sys_ready
tc_comm
br_start_date
br_start_time
last_start_date
last_start_time
br_name
br_add1
br_add2
br_add3
rec_acct
host_start_date
host_start_time
host_startup_ind
prod_dsn
train_dsn
first_ws
last_ws
first_ws2
last_ws2
first_ws3
last_ws3
vir_code
Person
Data Type
Char (6)
Char (2)
Char (6)
Char (1)
Long Integer(4)
Char (8)
Char (6)
Char (8)
Char (6)
Char (30)
Char (30)
Char (30)
Char (30)
Char (1)
Char (8)
Char (6)
Char (1)
Char (10)
Char (10)
Char (5)
Char (5)
Char (5)
Char (5)
Char (5)
Char (5)
Char (6)
Description
Branch Code
Clearing Code
Base Branch Code
System Ready
TC Commission
Branch Start Date
Branch Start Time
Last Start Date
Last Start Time
Branch Name
Branch Address 1
Branch Address 2
Branch Address 3
Record Account
Host Start Date
Host Start Time
Host Start-up Indicator
Production DSN
Training DSN
First Workstation
Last Workstation
First Workstation 2
Last Workstation 2
First Workstation 3
Last Workstation 3
Virtual Code
Table 3.4: Table BRACH
SBS Project System Requirements Specification (SRS)
66
Data Specification
© HeiTech Padu Berhad
3.5
USER
Description:
This table stores information regarding all the users in a branch that will be
using the system.
USER
Column ame
Data Type
Char (10)
oper_id
oper_name
Char (40)
Char (5)
saftera_id
Binary (1)
oper_role
mach_no
Char (2)
Long Integer (4)
oper_exp_dur
oper_exp_date
Char (8)
oper_last_signon
Char (8)
Char (8)
oper_effective_date
Long Integer (4)
oper_deactivate_dur
date_of_invalid_signon Char (8)
time_of_invalid_signon Char (6)
ip_address
Char (15)
onoffl_ind
Char (1)
teller_type
Char (1)
oper_email
Char (30)
oper_sts
Char (1)
officer_id
Char (2)
mgr_id
Char (2)
Description
Operator ID
Operator Name
Saftera Id
Operator Role
Machine No
Operator Expiry Duration
Operator Expiry Date
Operator Last Sign On
Operator Effective Date
Operator Deactivate Duration
Date Of Invalid Sign On
Time Of Invalid Sign On
IP Address
On Offline Indicator
Teller Type
Operator Email
Operator Status
Officer ID
Manager ID
Table 3.5: Table USER
SBS Project System Requirements Specification (SRS)
67
© HeiTech Padu Berhad
4.
Constraints
COSTRAITS
This section describes any requirements that will limit the developer’s options
for building the system
In SBS system, there are several constraints can be gathered which are
software standards compliance, software limitations, hardware limitations,
software development, user communication and support, symbols and
terminology and also user display. Below are the elaborations of these
constraints.
4.1
SOFTWARE STADARD COMPLIACE
- In terms of documenting, the Software Requirements Specification
document (SRS), Software Design Description document (SDD) and
Software Test Description (STD) document shall be documented in
accordance with the PROMISE. These documents will be using the
template and guidelines of Capability Maturity Model Integration
(CMMI).
4.2
SOFTWARE LIMITATIOS
- In this software Microsoft ClickOnce implementation tool used for central
deployment and automatic updates.
- In this software, Device Service Server used to manage device integration
and device sharing for devices like passbook printers, MyKad readers,
smart card readers, and receipt printer.
- The software is developed using Windows XP Platform.
4.3
HARDWARE LIMITATIOS
- The SBS system uses hardware that provides by Post office and CSC.
CSC is to provide all the servers and workstation including software and
technical support for the Selected Bank HQ setup. For this reason, the
software designers should be interfacing with the hardware already being
proposed, to identify any hardware limitations that would affect the
system.
- Input/Output: One or two-button mouse and keyboard.
- Biometric Equipments: using MyKad Reader.
- For Printing purpose, SBS system using Passbook Printer abd Laser Jet
Printer.
4.4
SOFTWARE DEVELOPMET
- Hybrid Client Studio used to assists in the creation of user interface and
manages field validation procedures. The features of this tool among
others are: drag-and-drop, automated XML formatting and performs
SBS Project System Requirements Specification (SRS)
68
© HeiTech Padu Berhad
-
4.5
Constraints
screen testing.
As for database management, Windows SQL Server 2005 Standard
Edition will be used for deployment server.
The .Net Framework 2.0.also is applied for SBS system and
Configuration Requirements.
The software for the SBS system shall be developed using Microsoft
Visual C++ and Microsoft Visual Studio.Net.
The programming languages uses for the software development are C++
and C#.
In-house software called Hybird Client application is used to design the
front end of the SBS system.
Host will be using for the back end processing.
USER COMMUICATIOS AD SUPPORT
- The outputs that result in the presentation of textual information to the
user shall communicate through the use of descriptive English-language
text.
- The Applied Research & Development (ARND) Department as user
supports will assist the software development team.
4.6
SYMBOLS AD TERMIOLOGY
- The SBS system shall be implemented and designed to use standard
zymology and conventions, user-oriented terminology, and representative
graphics for the operation and communication with the user.
4.7
USER DISPLAY
- The SBS system shall be designed with human performance
considerations that apply to the screen display to assure that it conveys
meaningful information.
SBS Project System Requirements Specification (SRS)
69
© HeiTech Padu Berhad
5.
Sizing and Timing Requirements
SIZIG AD TIMIG REQUIREMETS
Not Applicable.
SBS Project System Requirements Specification (SRS)
70
© HeiTech Padu Berhad
6.
Exceptional Site/Branches Requirements
EXCEPTIOAL SITE/BRACHES REQUIREMETS
This section defines the requirements for any data that are specific to a given
site, mission, or operational mode.
For SBS, it will be installed /deployed at 200 Post office branches initially.
SBS Project System Requirements Specification (SRS)
71
Qualification Requirements
© HeiTech Padu Berhad
7.
QUALIFICATIO REQUIREMETS
This section is divided into the following paragraphs to specify the
qualification methods that be used to ensure that the CSCI requirements have
been satisfied. The requirements for qualification and all the qualification
tests shall be described respectively in the Software Test Description.
7.1
QUALIFICATIO METHODS
Below is the qualification cross reference for all requirements in SBS System.
The qualification methods are shown on the Table 7.1.
ID
1.
Method
A- Analysis
2.
D- Demonstration
3.
I- Inspection
Description
The processing of accumulated data
obtained from other qualification
methods.
The operation of the CSCI or some
part of the CSCI, that relies on
observable functional operation not
requiring the use of elaborate
instrumentation or special test
equipment.
The visual examination of CSCI
source code and documentation etc.
Table 7.1: Qualification methods for CSCI SBS
For a detail qualification cross reference, please refer to Appendix D
Requirement Traceability Document for SBS Project
SBS Project System Requirements Specification (SRS)
72
© HeiTech Padu Berhad
8.
Quality Requirements
QUALITY REQUIREMETS
This section defines requirements with regard to system quality factors.
Quality factor identification is the responsibility of the person in charge of
documenting the requirements.
8.1
RELIABILITY
Reliability is the extent to which the SBS system consistently performs the
functions specified in this document. The SBS system software coding
standards shall include naming conventions, rules for indentation and
commenting, and specified programming languages and associated tools. The
reliability is measured by implementing appropriate test cases, which is stated
in the Software Test Description (STD) document. A program is reliable if it
can execute its functions, with the required precision.
8.2
MODULARITY
Modularity is the characteristic of software that describing the degree to
which a system’s components may be separated and recombined. The system
design representations and design structure shall be based on a formally
defined, unambiguous syntax. Commercial and reusable software shall be
identified separately from developed software in the preliminary design.
8.3
MAITAIABILITY
Maintainability is the degree of effort required to find and fix errors in the
SBS system. It shall be possible to generate and maintain the system using
only existing or developed support software as well as the usage of
supporting documentations. References to services that are unique to the
operating system, language implementation, and hardware implementation
shall be minimized.
8.4
SECURITY
Describe the factors that protect the system product from accidental or
malicious access, use, modification, destruction, or disclosure. Specific
requirements in this area could include the need to keep specific log or
history data sets, assign certain functions to different modules, restrict
communications between some areas of the program and check data integrity
for critical variables.
The SBS system comes with several security features which are:
- Role Based security – Access to the system is controlled based on the
defined roles. Access level can be customized up to transaction level.
- Sign-on – System level security (integrated with Windows security) and
application level security.
SBS Project System Requirements Specification (SRS)
73
© HeiTech Padu Berhad
Quality Requirements
- Encryption – Data level security.
- Audit Trail – Every transaction done through the system is logged.
- Remote and Local Override – Customizable, based on user
requirements.
SBS Project System Requirements Specification (SRS)
74
© HeiTech Padu Berhad
9.
Assumptions and Dependencies
ASSUMPTIOS AD DEPEDECIES
This section shall list each of the factors that affect the requirements stated in
the SRS.
For SBS the following Dependencies are applicable:
- MyKad Reader- Information and configuration is provided by Tricubes.
- Passbook Printer- OPOS (Interface) is provided by Post office.
- Data quality and message transaction is provided by IBM.
SBS Project System Requirements Specification (SRS)
75
© HeiTech Padu Berhad
10.
Licensing Requirements
LICESIG REQUIREMETS
Not Applicable.
SBS Project System Requirements Specification (SRS)
76
© HeiTech Padu Berhad
11.
Configuration Requirements
SBS COFIGURATIO REQUIREMETS
This section is divided into the following paragraphs to specify the SBS
configuration in Selected Bank and Post office.
11.1
SBS HIGH-LEVEL ARCHITECTURE
The following diagram shows High-Level Architecture view of SBS.
Figure 11.1: High Level Architecture View of SBS
The Web Server in the above diagram will act as the deployment server to
distribute SBS to the selected Post office branches. Communication between
Post office branches to the servers at Post office Headquarters (Post office
HQ) will be done via web services. To communicate with the backend (Host)
system, SBS will make use of Simple Object Access Protocol (SOAP).
11.1.1 System Configuration for Selected Bank
11.1.1.1
Brief Description
This section explains all configuration functions that done by Selected
Bank Administrator.
There are 5 functions provided: Branch Configuration, Manager
SBS Project System Requirements Specification (SRS)
77
© HeiTech Padu Berhad
Configuration Requirements
Configuration, User Profile, Table Maintenance, and View Archive.
For all of these functions, any first login for Selected Bank Administrator
after creation or modification of password will require change password
and every function will update EJ.
11.1.1.1.1
Selected Bank Administrator Login
1. Selected Bank Administrator opens Shared Banking Services web
application by typing the SBS URL.
2. Selected Bank Administrator fills in “User ID” and “Password”.
3. Selects “User Role” as “Bank ADMIN”.
4. Clicks “Login” button. Selected Bank Configuration screen will
be displayed.
11.1.1.1.2
Branch Configuration
Selected Bank Administrator can perform Branch Configuration
centrally at Selected Bank HQ. There are 4 functions provided: Add
Branch, Update Branch, Deactivate/Reactivate Branch and View
Branch.
Every branch creation and modification will update EJ and notify Post
office Administrators of the created branch via email.
11.1.1.1.2.1
Add Branch
1. Selected Bank Administrator clicks “Add Branch” under “Branch
Configuration”. Add Branch screen will be displayed.
2. Selected Bank Administrator fills in “Post office Branch Code”,
“Post office Branch Name”, “Branch Address”, “State”, “No. of
Workstation”, “Range of Saftera ID”, “Bank Base Branch Code”,
“Bank Virtual Branch Code” and “Clearing Code”.
3. For “Range of Saftera ID”, only First Saftera ID is allowed to be
modified. Last Saftera ID will be calculated based on No. of
workstation and First Saftera ID.
4. Then clicks “OK” button.
5. Upon successful branch creation, a “Record successfully added”
message will be shown
6. To cancel, clicks “Cancel” button and Home screen will be
shown.
11.1.1.1.2.2
Update Branch
1. Selected Bank Administrator clicks “Update Branch” under
“Branch Configuration”. Update Branch screen will be displayed.
2. Selects “State” from the dropdown list. Then clicks “OK” button,
list of all branches under the selected state will be displayed.
3. From the display list, clicks “Select” at the branch to be updated.
Update Branch screen will be displayed.
4. Selected Bank Administrator can change any information of “Post
office Branch Name”, “Branch Address”, “State”, “No. of
SBS Project System Requirements Specification (SRS)
78
Configuration Requirements
© HeiTech Padu Berhad
5.
6.
7.
8.
11.1.1.1.2.3
workstation”, “Range of Saftera ID” and “Clearing Code”.
For “Range of Saftera ID”, only First Saftera ID is allowed to be
modified. Last Saftera ID will be calculated based on “No. of
Workstation” and First Saftera ID.
Clicks “OK” button. The record will be updated.
Upon successful branch updating, a “Record successfully
updated” message will be displayed.
To cancel this transaction, clicks “Cancel” button and Home
screen will be shown.
Deactivate/Reactivate Branch
1. Selected Bank Administrator clicks “Deactivate/Reactivate
Branch” under “Branch Configuration”. Deactivate/Reactivate
Branch screen will be shown.
2. Selects “State” and “Status” from the dropdown list then clicks
“OK” button. List of all branches under the selected state and
status will be displayed.
3. From the display list, clicks “Select” at the branch to be
deactivated or reactivated. A screen as shown in Figure 3.10 will
be displayed
4. If the current status of the branch is Active, the button’s caption
will be “Deactivate” as the function of the screen is to deactivate
the branch. But if the current status of the branch is Inactive, then
the button’s caption will be “Reactivate” as the function of the
screen is to reactivate the branch.
5. Clicks “Deactivate” or “Reactivate” button.
6. If the branch is Active, the status will be updated to ‘Inactive’.
Else if the branch is Inactive, the status will be updated to ‘Active’
7. Upon successful of branch deactivation or reactivation, a message
will be displayed.
11.1.1.1.2.4
View Branch
1. Selected Bank Administrator clicks “View Branch” under “Branch
Configuration”. View Branch screen will be shown.
2. Selects “State” and “Status” from the dropdown list then clicks
“OK” button. List of all branches under the selected state and
status will be displayed.
3. From the display list, clicks “Select” the branch to be viewed. A
screen that contains all the Branch info will be displayed.
4. Clicks “Back” button to return to the previous screen or clicks
“Cancel” button to go to Home screen.
11.1.1.1.3
Manager Configuration
Selected Bank Administrator can perform Manager Configuration
centrally at Selected Bank HQ. There are 4 functions provided: Add
Manager, Update Manager Profile and Delete Manager.
SBS Project System Requirements Specification (SRS)
79
© HeiTech Padu Berhad
Configuration Requirements
Every Manager creation and modification will update EJ and notify
Manager via email.
11.1.1.1.3.1
Add Manager
1. Selected Bank Administrator clicks “Add Manager” under
“Manager Configuration”. Add Manager page will appear.
2. Selects “State” and “Branch” from the dropdown lists (Selected
Bank Administrator will only see the branch listed under the
selected State). “Range of Saftera ID” and “Officer ID” will be
displayed for reference.
3. Fills in “Manager ID”, “Manager Name” and “Email ID”. This
information should be provided by Post office.
4. Clicks “OK” button. Upon successful Manager created, a
“Manager ID successfully added” message will be displayed.
Automatically, an email containing above information including
an auto-generated password will be sent to the manager’s email ID
via SMTP.
11.1.1.1.3.2
Update Manager Profile
1. Selected Bank Administrator selects “Update Manager Profile”
under “Manager Configuration”. Update Manager Profile screen
will be displayed.
2. Selects “State” and selects “Branch” from the dropdown lists
(Selected Bank Administrator will only see the branch listed under
the selected State). Profile of the selected branch will be
displayed.
3. Only “Manager Name” and “Email ID” are allowed to be
modified. Changes any of the information, if required and click
“OK” button.
4. Upon successful updating manager’s profile, a “Manager Profile
successfully updated” message will be displayed.
5. To cancel, clicks “Cancel” button and Home screen will be
shown.
11.1.1.1.3.3
Delete Manager
1. To delete manager, clicks “Delete Manager” under “Manager
Configuration”. Delete Manager screen will be displayed.
2. Select “State”, then selects “Branch” from the dropdown lists
(Selected Bank administrator will only see the branch listed under
the selected State). Profile of the selected branch will be
displayed.
3. Click “OK” button. “Are you sure you want to delete this record?”
confirmation message will be prompted.
4. If Selected Bank Administrator clicks “OK” on the confirmation
message, Manager ID, Manager Name and Email ID information
will be deleted in the database.
SBS Project System Requirements Specification (SRS)
80
© HeiTech Padu Berhad
Configuration Requirements
5. Upon successful manager deletion, a “Manager
successfully deleted” message will be displayed.
Profile
SBS Project System Requirements Specification (SRS)
81
© HeiTech Padu Berhad
11.1.1.1.4
User Profile
11.1.1.1.4.1
Change Password
Configuration Requirements
1. Selected Bank Administrator clicks “Change Password” under
“User Profile”. Change Password screen will be shown.
2. Insert “Current Password”, “New Password” and “Confirm
Password”. Both entries must be the same.
3. Clicks “OK” button. System will check password.
4. Upon successful, a “Password successfully changed” message will
be displayed.
5. To cancel, clicks “Cancel” button and Home screen will be
shown.
11.1.1.1.4.2
Reset Password
This function is to reset administrator password. Selected Bank
Administrator can reset password Post office Administrator.
1. Selected Bank Administrator clicks “Reset Password” under “User
Profile”. Reset Password screen will be displayed.
1. Selects “Administrator ID” and fills in the “New Password”.
2. Clicks “OK” button. Upon successfully of password reset, a
message will be displayed. The new password will be sent to the
Administrator via email.
11.1.1.1.4.3
Update Profile
This function is to update Selected Bank Administrator email ID. This
email ID is used to notify the Administrator if the password has been
reset.
1. Clicks “Update Profile” under “User Profile”. Update Profile
screen will be shown.
2. Fills in “Email ID” and clicks “OK” button. Upon successfully, a
“Password successfully reset” message will be shown.
3. To cancel, click button “Cancel” and Home screen will be shown.
11.1.1.1.5
Table Maintenance
This function will allow Selected Bank Administrator create new table
and update record of existing tables.
All reference tables reside in each teller’s workstation. However, there
will be another master copy of reference tables reside in Hybrid
Server. These reference tables can be updated or added only by
Selected Bank Administrator. Deployment is done automatically to
branch if there are any changes on the tables.
Teller limit and Transaction limit tables are parameterized. The tables
can maintain using Table Maintenance function. The following table
SBS Project System Requirements Specification (SRS)
82
Configuration Requirements
© HeiTech Padu Berhad
shows default values of Teller/Transaction limit:
Reference Tables
Limit
Teller
0
Deposit Transaction
RM50, 000
Withdrawal Transaction
RM5,000
Remittance Transaction
RM10,000
Table 11.1: Teller/Transaction Limit
11.1.1.1.5.1
Add Table
1. Selected Bank Administrator clicks “Add Table” under “Table
Maintenance”. Add Table screen will be displayed.
2. Fills in “Table Name”, “Table Description “and click “OK”
button.
3. Add Record screen will be displayed. At this point, the table will
be created with blank record.
4. To add new record, fills in “Item ID”, “Description” and clicks
“OK”.
5. System will check for a unique ID. If success, the record will be
added and “Record successfully added” message will be
displayed.
6. To add another record in the table, repeat step no 4.
7. “Back” button is to go back to the first screen.
11.1.1.1.5.2
Update/View Table
11.1.1.1.5.2.1 Add Record
This function is to update a table with a new record.
1. Selected Bank Administrator clicks “Update Table” under “Table
Maintenance”. Update Table screen will be displayed. This screen
will list down a maximum of 10 existing tables. If there are more
tables, option to select the next 10 tables will be appeared at the
bottom of the list.
2. Clicks “Select” at the table to be updated. A screen that list down
a maximum of 10 existing records in the selected table will be
displayed.
3. Clicks “New”, fills in “Item ID” and “Description”. Clicks “OK”
button and the record will be added. If success, “Record
successfully added” message will be displayed.
4. ”Back” button is to go back to the first screen.
5. To cancel, clicks “Cancel” button and Home screen will be
displayed.
SBS Project System Requirements Specification (SRS)
83
© HeiTech Padu Berhad
Configuration Requirements
11.1.1.1.5.2.2 Update An Existing Record
This function is to update an existing record.
1. Selected Bank Administrator clicks “Update Table” under “Table
Maintenance”. Update Table screen will be displayed. This screen
will list down a maximum of 10 existing tables. If there are more
tables, option to select the next 10 tables will be appeared at the
bottom of the list.
2. Clicks “Select” at the table to be updated. A screen that list down
a maximum of 10 existing records in the selected table will be
displayed.
3. Clicks “Update”, edits “Description”. Clicks “OK” button and the
record will be updated. If success, “Record successfully updated”
message will be displayed.
4. ”Back” button is to go back to the first screen.
5. To cancel, clicks “Cancel” button and Home screen will be
displayed.
11.1.1.1.5.2.3 Delete An Existing Record
This function is to delete an existing record.
1. Selected Bank Administrator clicks “Update Table” under “Table
Maintenance”. Update Table screen will be displayed. This screen
will list down a maximum of 10 existing tables. If there are more
tables, option to select the next 10 tables will be appeared at the
bottom of the list.
2. Clicks “Select” at the table to be updated. A screen that list down
a maximum of 10 existing records in the selected table will be
displayed.
3. Clicks “Delete” at the particular record, the selected record details
will be appeared. Then, clicks “OK” button.
4. “Are you sure you want to delete this record?” conformation
message will be displayed.
5. Clicks “OK”. Selected record will be deleted. Record deletion
message will be shown
6. ”Back” button is to go back to the first screen.
7. To cancel, clicks “Cancel” button and Home screen will be
displayed.
11.1.1.1.5.3
Delete Table
This function is to delete an existing table.
1. Selected Bank Administrator clicks “Delete Table” under “Table
Maintenance”. Delete Table screen will be displayed. This screen
will list down a maximum of 10 existing tables. If there are more
tables, option to select the next 10 tables will be appeared at the
bottom of the list.
2. Clicks “Select” at the table to be updated. A screen that list down
a maximum of 10 existing records in the selected table will be
displayed as reference.
SBS Project System Requirements Specification (SRS)
84
© HeiTech Padu Berhad
Configuration Requirements
3. Clicks “Ok” to delete table.
4. “Are you sure you want to delete this table?” conformation
message will be displayed.
5. Clicks “OK”. Selected table will be deleted. Table deletion
message will be shown
6. ”Back” button is to go back to the first screen.
7. To cancel, clicks “Cancel” button and Home screen will be
displayed.
11.1.1.1.6
View Archive
This function is for Selected Bank Administrator to view EJ that is
kept for 2 years.
1. Selected Bank Administrator selects “State” and “Branch”.
2. Select “Searching Option”. Searching option can be more than one
category. Searching options are Date, Time, Journal No,
Successful Status – (Y or N), Account No or Amount.
3. Clicks “OK” button to view archive according to the selected
searching option. Search result will be displayed.
4. Only 20 records will be displayed. The next 20 records can be
viewed by clicking the page number at the bottom of the list.
5. To clear the screen, clicks “Reset” button.
1. To print, clicks “Print” button.
2. To cancel, clicks “Cancel” button and Home screen will be
shown.
11.1.2 System Configuration for Post Office
11.1.2.1
11.1.2.1.1
Brief Description
This section explains all configuration functions that done by Post office
Administrator.
There are 2 functions provided: Manager Configuration and
Administrator Profile.
For both of this functions, any first login for Post office Administrator
after creation or modification of password will require change password
and every function will update EJ.
Post Office Administrator Login
1. Post office Administrator opens Shared Banking Services web
application by typing the SBS URL.
2. Post office Administrator fills in “User ID” and “Password”.
3. Selects “User Role” as “Post office ADMIN”.
4. Clicks “Login” button. Post office Configuration screen will be
displayed.
11.1.2.1.2
Manager Configuration
In this function, Post office Administrator is only allowed to reset the
manager’s password. Creation of manager ID, update manager profile
and delete manager will be done by Selected Bank Administrator.
SBS Project System Requirements Specification (SRS)
85
© HeiTech Padu Berhad
11.1.2.1.2.1
Configuration Requirements
Reset Manager Password
This part is to reset the manager’s password, as requested by the
manager.
1. Post office manger clicks “Reset Password” under “Manager
Configuration”. A Reset Password screen will be displayed.
2. Selects “State” and “Branch” from the dropdown lists (Post office
administrator will only see the branch listed under the selected
State). “Manager ID” and “Manager Name” for the selected
branch will be displayed.
3. Clicks “Reset Password” button. Automatically, a new autogenerated password will be sent to the manager via email.
4. To cancel, clicks “Cancel” button and Home screen will be
shown.
11.1.2.1.2.2
Administrator Profile
11.1.2.1.2.2.1 Change Password
This function is for Post office Administrator to change his password.
1. Post office Administrator clicks “Change Password” under
“Administrator Profile”. Change Password screen will be
displayed.
2. Fills in “Current Password”, “New Password”, “Confirm
Password” and clicks “OK” button. Both entries of” New
Password” and “Confirm Password” must be the same
3. System will do password checking and if success, “Password
successfully changed” message will be displayed.
4. To cancel, clicks “Cancel” button and Home screen will be
shown.
11.1.2.1.2.2.2 Reset Password
This function is to reset Post office Administrator password.
1. Post office Administrator clicks “Reset Password” under
“Administrator Profile”. Reset Password screen will be displayed.
2. Fills in “New Password” and clicks “OK” button.
3. System will do password checking and if success, “Password
successfully reset” message will be displayed.
4. To cancel, clicks “Cancel” button and Home screen will be
shown.
5. If both Post office Administrators forget their password, they can
request Selected Bank Administrator to reset their password.
11.1.2.1.2.2.3 Update Profile
This function allows Post office Administrator to update his own
email ID.
1. Post office Administrator clicks “Update Profile” under
SBS Project System Requirements Specification (SRS)
86
© HeiTech Padu Berhad
Configuration Requirements
“Administrator Profile”. Update Profile screen will be displayed.
2. Fills in new “Email ID” and clicks “OK” button.
3. Upon successfully, “User Profile successfully updated” message
will be displayed.
4. To cancel, clicks “Cancel” button and Home screen will be
shown.
SBS Project System Requirements Specification (SRS)
87
© HeiTech Padu Berhad
Appendix A
APPEDIX A: GRAPHICAL USER ITERFACE
SBS Project System Requirements Specification (SRS)
A-1
© HeiTech Padu Berhad
APPEDIX B: SBS SEQUECE DIAGRAMS
SBS Project System Requirements Specification (SRS)
SBS Project System Requirements Specification (SRS)
BASIC FLOW
1. OPE ACCOUT
© HeiTech Padu Berhad
Appendix B - 1: Basic Flow - Open Account
B-1
Appendix B
: SBSFrm
: OpnAcountFrm
: AcountOpnMngr
: SBSManager
1.Teller selects "Saving Account
-Passbookless" under "Individual"
menu to open an Individual Saving
Account-Passbookless.
2.System shows "Inquire
Customer/Segment" Screen.
3.The system will continue the
flow in Basic Flow from step 2 to
step 13.However, step 3 in [A5:
Print Specimen Card] is excluded
(update Passbook Stock
Control).
SBS Project System Requirements Specification (SRS)
Appendix B - 2: Alternative Flow1- Opening an Individual Saving Account-Passbookless
continue the flow in Basic Flow from
step 2 to step 13.However, step 3 in
[A5: Print Specimen Card] is excluded
(update Passbook Stock Control).
4: Load "Inquire Customer/Segment" Screen
3: Open Individual Saving Account-Passbookless
2: "Saving Account-Passbookless" is Pressed
1: Select "Saving Account-Passbookless"
: PMB Teller
ALTERATIVE FLOWS
© HeiTech Padu Berhad
B-2
Appendix B
: SBSFrm
: AcountOpnMngr
: SBSManager
7: Load Add Role Screen
6: Requist Add Account for Customer
5: Request Customer IC
[A4: Add
Account]
This Flow will repeat again
for Secondary Cutomer
[A6: Add
Card]
16: Request Add Card for the Customer
15: Request Print Specimen Card
14: Print Application Form
[A5: Print
Specimen Card]
1.Teller selects "Saving AccountPassbook" under "Joint" menu to
open Joint Saving AccountPassbook. [A9: Opening Joint
Saving Account-Passbookless].
System shows "Inquire
Customer/Segment" Screen.
2.System request Customer IC by
using [A3: Inquire
Customer/Segment] Alternative
Flow.
3.Upon successful adding Primary
Customer, the system displays
again "Inquire Customer/Segment"
screen to Add Secondary Customer.
4.The flow number 2 will repeat
again.
5.System request Teller to Add
Account to the Customer by using
[A4: Add Account] Alternative Flow.
6.Upon successful Add Misc Code
transaction, the system shows Add
Role screen. Teller Select
"Relationship", then click "OK"
button. The system will send Add
Role transaction information to Host.
7.Upon successful Add Role
transaction, the system will print
Application Form (to print both
Customers). The system sends
"Please insert A4 paper into
PASSBOOK printer" message to
Teller.
8.The system request Print
Specimen Card using [A5: Print
Specimen Card] Alternative Flow.
9.If selection of "ATM Card" is yes,
the system request Teller to Add
Card for the Customer by using [A6:
Add Card] Alternative Flow.
10.The flow from number 9 will repeat
again for Secondary Cutomer.
11.This use case continues at step
no 10 in Basic Flow.
Appendix B - 3: Alternative Flow 2- Opening Joint Saving Account-Passbook
SBS Project System Requirements Specification (SRS)
use case continues at
step no 10 in Basic Flow
12: Show "Please insert A4 paper into PASSBOOK printer" Message
13: Insert A4 Paper
: Host
11: Send Add Role Transaction Info
10: Add Role Transaction
9: Submet Add Role transaction info
Flow no 4,5 will repeat again to
Add Secondary Customer
: PassbookPrinter
[A3: Inquire
Customer/Segment]
4: Load "Inquire Customer/Segment" Screen
3: Open Joint Saving Account-Passbook
2: "Saving Account-Passbook" is Pressed
: OpnAcountFrm
8: Select "Relationship", then Click "OK" button
[A9: Opening Joint Saving
Account-Passbookless]
1: Select "Saving Account-Passbook"
: PMB Teller
© HeiTech Padu Berhad
B-3
Appendix B
: SBSFrm
: OpnAcountFrm
: AcountOpnMngr
: SBSManager
: PassbookPrinter
SBS Project System Requirements Specification (SRS)
Appendix B - 4:Alternative Flow 3 - Inquire Customer/Segment
: Host 1.If Customer is GMPC holder,
then Teller select to input IC
No using GMPC .The system
prompt Teller to insert card by
1: Display "Please Insert GMPC in Card Reader" Message
display "Please Insert GMPC
in Card Reader" message. The
2: Insert GMPC
system starts verification
[E1: Verification
process.
Fail]
3: Get GMPC Info
2.If verification passed, the
message "TP Verification
4: Read GMPC
Pass" will appear. [E1:
Verification Fail].
5: Return GMPC Info
3.If Customer not GMPC
holder, Teller has to input IC
6: Display Message "TP Verification Pass"
No either "New I/C No." or "Old
I/C No".
[E2:
IC
Is
7: Input IC No
4.System inquires Customer
Duplicated]
Segment IC No from Host. [E2:
8: Is IC Duplicate
IC Is Duplicated].
5.System checks if the
Customer exist or not [A10:
9: Customer Segment IC No Is Required
Customer Exist].
6.System verifies Bankruptcy,
10: Inquires Customer Segment IC No
Check Duplicate OCISS, and
Check OCISS/LIS/Staff. The
system will show "Add
[A4: Customer 11: Is the Customer Exist
Customer" screen.
Exist]
7.The system retrieves the
12: Verify Customer
Customer's "New IC No", "Old
IC No", "Name", "Date Of
Birth", "Gender", "Race Code",
13: Load "Add Customer " Screen
"Address", "Postcode", "State"
and "Religion" from GMPC
14: Fills in the Required Fields and Click "OK" Button
automatically and display on
"Add Customer" screen. [A11:
15: Sumbet Inserted Info
Non GMPC holder].
8.Teller fills in the required
16: Add Customer Transaction
fields and Click "OK" button
and the system will send
17: Send Add Customer Transaction
transaction information to Host.
9.Use case continues.
: PMB Teller
© HeiTech Padu Berhad
B-4
Appendix B
: SBSFrm
: AcountOpnMngr
1: Load "Add Account" Screen
: OpnAcountFrm
: SBSManager
SBS Project System Requirements Specification (SRS)
8: Display "Please Insert VOUCHER Into PASSBOOK Printer" Message
: Host
Appendix B - 5: Alternative Flow 4 - Add Account
11: Send Add Misc Code Transaction
10: Add Misc Code Transaction
9: Print Vouchar
Extend to Require
Override Use Case.
[C2: Amount Value
Conditions], [E2:
Amount More Than
Transaction Limit]
: PassbookPrinter
7: Send Add Acount Transaction Info
6: Add Acount Transaction
5: Verifies Amount is within Teller Limit
4: Verify the Amount is within Transaction Limit
3: Submet inserted Amount and Info
2: Insert "Amount" and required Info
: PMB Teller
© HeiTech Padu Berhad
1.The system displays "Add
Account" screen. Teller key
in "Amount" [C2: Amount
Value Conditions],
"Passbook No", selects
"Card Charge Options" and
selects "ATM Card (Y/N)".
2.System checks whether
the Amount is less than
transaction limit [E3:
Amount More Than
Transaction Limit] and verify
that the Amount is within
Teller limit.
3.Upon successful Add
Account transaction, the
system will send transaction
information to Host.
4.The system will receive
Host reply and automatically
the system will ask for a
Voucher printing by send
"Please Insert VOUCHER
Into PASSBOOK Printer"
message to the Teller.
5.Then the system sends
Add Misc Code transaction
information to Host.
B-5
Appendix B
: OpnAcountFrm
: AcountOpnMngr
: SBSManager
Appendix B - 6: Alternative Flow 5 - Print Spiecment Card
1.The system will
print Application
Form. The system
sends "Please
insert A4 paper into
PASSBOOK
printer" message to
Teller.
2.Upon successful
printing application
form, the system
will print Specimen
Card. The system
will ask to insert
Specimen Card
into Passbook
printer.
3.System will
update Passbook
Stock Control.
: PassbookPrinter
8: Update Passbook Stock Control
7: Specimen Card Is Printed
6: Print Specimen Card
5: Insert Specimen Card
4: Insert Specimen Card
3: Print Application Form
2: Insert A4 Paper
1: Display "Please insert A4 paper into PASSBOOK printer" Message
: SBSFrm
SBS Project System Requirements Specification (SRS)
: PMB Teller
© HeiTech Padu Berhad
B-6
Appendix B
: SBSFrm
Appendix B - 7: Alternative Flow 6 - Add Card
10: update ATM Card Stock Control.
9: Send Pin IssuanceTransaction
8: Pin IssuanceTransaction
7: Submet Insered Info
: PassbookPrinter
5: Send Add Card Transaction
: SBSManager
4: Add Card Transaction
3: Submet Insered Info
6: Enters the Required Fields and Click "OK" Button
SBS Project System Requirements Specification (SRS)
: AcountOpnMngr
1: Load Add Card Screen
: OpnAcountFrm
2: Enters the Required Fields and Click "OK" Button
: PMB Teller
© HeiTech Padu Berhad
: Host
1.The system shows "Add
Card" screen. Teller enters
the required fields and
click "OK" button. The
system sends Add Card
transaction information to
Host.
2.Upon successful Add
Card transaction, the
system will display "Pin
Issuance" screen. Teller
fills in the required fields
and click "OK" button. The
system will send PIN
Issuance transaction
information to Host.
3.Upon successful Pin
Issuance transaction, the
system will update ATM
Card Stock Control.
4.Use Case Continues.
B-7
Appendix B
: AcountOpnMngr
1.Teller clicks
"Repeat" button.
2.System display new
screen and enters
same values as
previous values.
3.Teller can perform
this action by
press"F9".
Appendix B - 8: Alternative Flow 7 - Repeat Transaction
4: Enter Same value as Previous Values
3: Load New Form
2: Submet
: OpnAcountFrm
1: Prees "Repeat" Button
: PMB Teller
SBS Project System Requirements Specification (SRS)
© HeiTech Padu Berhad
B-8
Appendix B
Appendix B - 9: Alternative Flow 8 - Cancel Transaction
3: Unload Form
1.Teller clicks
"Cancel" button.
2.System cancels
current transaction
and display main
transaction screen.
: TransactionFrm
4: Load Form
: AcountOpnMngr
2: Submet
: OpnAcountFrm
1: Prees "Cancel" Button
: PMB Teller
SBS Project System Requirements Specification (SRS)
© HeiTech Padu Berhad
B-9
Appendix B
: SBSFrm
: OpnAcountFrm
: AcountOpnMngr
: SBSManager
1.Teller selects "Saving
Account-Passbookless" under
"Joint" menu to open Joint
Saving Account-Passbookless.
2.System shows "Inquire
Customer/Segment" Screen.
3.The system will continue the
flow in Alternative Flow [A2:
Opening Joint Saving Account
-Passbook] from step 2 to step
11. However, step 3 in [A5:
Print Specimen Card] is
excluded (update Passbook
Stock Control).
Appendix B - 10: Alternative Flow 9 - Opening Joint Saving Account-Passbookless
continue the flow in Alternative Flow [A2:
Opening Joint Saving Account-Passbook]
from step 2 to step 11. However, step 3
in [A5: Print Specimen Card] is excluded
(update Passbook Stock Control).
4: Load "Inquire Customer/Segment" Screen
3: Open Joint Saving Account-Passbookless
2: "Saving Account-Passbookless" is Pressed
1: Select "Saving Account-Passbookless"
: PMB Teller
SBS Project System Requirements Specification (SRS)
© HeiTech Padu Berhad
B - 10
Appendix B
Appendix B - 12: Exception Flow 2 - IC Is Duplicated
1.If duplicate IC, the system
will reject the transaction
2.Send reject message.
1: Reject Transaction
: AcountOpnMngr
2: Display Reject Message
: OpnAcountFrm
Appendix B - 11: Exception Flow 1 -Verification Fail
: AcountOpnMngr
: PassbookPrinter
1: Verification Failed
1.If verification failed,
message "TP
2: Display "TP verification fail"
verification fail" will
appear.
3: Abort Transaction
2.The transaction will
be aborted.
3.The use case ends.
: OpnAcountFrm
SBS Project System Requirements Specification (SRS)
EXCEPTIO FLOWS
© HeiTech Padu Berhad
B - 11
Appendix B
SBS Project System Requirements Specification (SRS)
© HeiTech Padu Berhad
1: Stop Transaction
: AcountOpnMngr
1.The system will not allow
transaction to proceed.
2.The system notifies and
display error message.
Appendix B - 13: Exception Flow 3 - Amount More Than Transaction Limit
2: Display Error Message
: OpnAcountFrm
B - 12
Appendix B
SBS Project System Requirements Specification (SRS)
BASIC FLOW
2. MAKE CASH/DEPOSIT PAYMET
© HeiTech Padu Berhad
B - 13
Appendix B
SBS Project System Requirements Specification (SRS)
Appendix B - 14: Basic Flow - Make Cash/Deposit Payment
B - 14
Appendix B
1.This us e cas e begins when a
Cus tom er requires Teller to m ake
: PMB Teller
: Hos t
: Trans actionFrm
: SBSManager : Depos itMngr
Depos it/Paym ent trans action by
: Depos itFrm
s ubm itting a filled Depos it/Payment
1: Select "Cas h Activities "
form to Teller.
2.Teller s elects "Cas h Activities " and
2: choos es "Depos it/Paym ent"
choos es "Depos it/Payment". The
"Depos it/Paym ent" s creen will be
3: Subm et
dis played.
3.The Teller key in Cus tom ers ' "Account
4: Load Depos it/Paym ent Form
Num ber" or "Vehicle Reg. No" and
pres s "Enter". If the Teller key in wrong
5: Form Load
or incom plete data, the s ys tem will
notify and dis play error m es s age.
6: Enter Cus tom ers ' "Account Num ber"
4.If the Teller key in "Vehicle Reg. No",
[A1: Calculate
the s ys tem will inquire the account
Com m is s ion]
7: s ubmet the account num ber
number.
5.The s ys tem verify the account num ber
whether it within cleaning code or not
8: verify the account num ber within cleaning code
[A2: Saving Account-Pas s bookles s Depos it],
by check the 2nd and 3rd digit of
[A3: Saving Account-Pas s book Depos it], [A4:
account number agains t the branch
CCA Depos it], [A5: PSV Depos it], [A6: Loan
clearing code. [A1: Calculate
9: validate Cus tom ers ' product type
Cas h Repaym ent], [A7: HP Paym ent], [A8:
Com mis s ion].
Credit Card Cas h Paym ent].
6.The s ys tem validate Cus tom ers '
10: check whether the Account Num ber is Exem pted Account
product typed bas e on Account Num ber.
7.The s ys tem check if the Account
Num ber is Exem pted Account or not.
11: m ake cas h Depos it/Paym ent
[C1: Exem pted Account Condition], [E1:
[C1: Exem pted Account Condition],
Exem pted Account Number].
12: m ake the s election of "Repeat" or "Cancel"
[E1: Exem pted Account Num ber]
8.The Teller can m ake cas h
Depos it/Paym ent bas ed on Cus tom ers '
13: Send Trans action Info
product type. [A2: Saving AccountPas s bookles s Depos it], [A3: Saving
14: Subm et Trans action Info
Account-Pas s book Depos it], [A4: CCA
Depos it], [A5: PSV Depos it], [A6: Loan
[A11: Repeat Trans action],
15: check Trans action Info
Cas h Repaym ent], [A7: HP Paym ent],
[A12: Cancel Trans action]
[A8: Credit Card Cas h Paym ent].
16: Receive Hos t Reply
9.At any trans action, when the Teller
enters Am ount, s ys tem verifies that the
17: Submet
Am ount is within Teller limit and if not
extend to Require Override Us e Cas e.
18: Dis play "Pleas e Ins ert VOUCHER Into PASSBOOK Printer" m es s age
10.At any tim e, Teller can m ake the
s election of "Repeat" [A11: Repeat
19: Ins ert Voucher
Trans action], or "Cancel" current
Trans action [A12: Cancel Trans action].
20: Subm et Ins erted Voucher
11.The s ys tem will s end the trans action
to Hos t.
21: Print
12.The s ys tem will update EJ and Teller
total.
13.The us e cas e ends when the
22: update EJ and Teller total
"Depos it/Paym ent" s creen is unloaded.
© HeiTech Padu Berhad
SBS Project System Requirements Specification (SRS)
: DepositMngr
: SBSManager
: CommissionFrm
2: Form Load
6: Display Commission Amount
5: calculates "Commission Amount"
4: Submet
8: click "OK" button
9: Form Unload
7: keeps commission accumulated by Teller in Teller Table file.
[C2: Commission
Amount Status].
3: chooses the technique that the Customer will use to pay the commissio
[E4: Receive Error
From The Host].
1: account number is not within the clearing code
: PMB Teller
Appendix B - 15: Alternative Flow 1 - Calculate Commission
1.If account number is not within
the clearing code, the system will
pop up "Commission" screen.
[E4: Receive Error From The
Host].
2.The Teller chooses the
technique that the Customer will
use to pay the commission
whether by paying "Cash" or
"deduct" from the cash amount
that the Customer provides for
Deposit/Payment purpose.
3.The system calculates
"Commission Amount" and
display to the Teller [C2:
Commission Amount Status].
4.The system keeps commission
accumulated by Teller in Teller
Table file.
5.The Teller collects Commission
Amount from the Customer.
6.The Teller click "OK" button,
the "Commission" screen is
unloaded.
7.The use case continues.
ALTERATIVE FLOWS
© HeiTech Padu Berhad
B - 15
Appendix B
SBS Project System Requirements Specification (SRS)
: DepositMngr
extend to
Require Override
Use Case.
5: verifies the Amount is within Teller limit
4: checks whether the Amount is less than transaction limit
Use Case Continues at
Step No 10 in Basic Flow
[A9: Use
Calculator], [C3:
Amount Value
Conditions]
3: Submet Inserted Amount
[E2: Amount
More Than
Transaction Limit]
1: displays "Saving Account Deposit" screen
: DepositFrm
2: key in "Amount" and clicks "OK" button
: PMB Teller
Appendix B - 16: Alternative Flow 2 - Saving Account-Passbookless Deposit
1.System displays appropriate
"Saving Account Deposit" screen.
2.The Teller key in "Amount" [A9:
Use Calculator] and clicks "OK"
button. [C3: Amount Value
Conditions].
3.System checks whether the
Amount is less than transaction limit
[E2: Amount More Than Transaction
Limit] and verify that the Amount is
within Teller limit.
4.System sends the information to
the Host.
5.The system will receive Host reply
and automatically the system will
ask for a Voucher printing by send
"Please Insert VOUCHER Into
PASSBOOK Printer" message to the
Teller.
6.The use case continues.
© HeiTech Padu Berhad
B - 16
Appendix B
Appendix B - 17: Alternative Flow 3 - Saving Account-Passbook Deposit
1.System displays appropriate
"Saving Account Deposit" screen.
: DepositMngr
: DepositFrm
2.The Teller key in "Amount" [A9:
: PMB Teller
Use Calculator], "Passbook
1: displays "Saving Account Deposit" screen
Balance", "Passbook Number"
and clicks "OK" button. [C3:
Amount Value Conditions].
2: Insert "Amount" Passbook Info and clicks "OK"
3.System checks whether the
[E2: Amount
Amount is less than transaction
More Than
3: Submet Inserted Amount
limit [E2: Amount More Than
Transaction Limit]
Transaction Limit] and verify that
the Amount is within Teller limit.
4: checks whether the Amount is less than transaction limit
[A9: Use
4.System updates Passbook and
Calculator], [C3:
sends transactions information to
Amount Value
the Host. But if "Passbook
Conditions]
5: verifies the Amount is within Teller limit
Balance" and "Passbook
Number" is not inserted, the
Use Case Continues at
system only sends Deposit
Step No 10 in Basic Flow
transaction information to the
6: updates Passbook
Host.
5.The system will receive Host
reply and automatically the
7: Display "Please Insert PSSBOOK to PASSBOOK Printer" message
system will ask for a Voucher
extend to
printing by send "Please Insert
8: insert Pssbook
Require Override
VOUCHER Into PASSBOOK
Use Case.
Printer" message to the Teller.
9: Submet Inserted Pssbook
Also, system send "Please Insert
PSSBOOK to PASSBOOK
10: Print Passbook
Printer" message to print
Passbook.
8.The use case continues.
SBS Project System Requirements Specification (SRS)
© HeiTech Padu Berhad
B - 17
Appendix B
SBS Project System Requirements Specification (SRS)
1.The system will automatically display
"CCA Deposit" screen.
2.The system will check the account
number against Special Description
table. If the account number is not listed
in Special Description table, the Teller
insert "Amount" [A9: Use Calculator],
"Description" and "Reference Number"
and click the "OK button. [C3: Amount
Value Conditions].
3.If the account number is listed in
Special Description table, the system
will replace "Description" and
"Reference Number" fields based on
Special Description table.
4.System checks whether the Amount
is less than transaction limit [E2:
Amount More Than Transaction Limit]
and verify that the Amount is within
Teller limit.
5.System sends the information to the
Host.
6.The system will receive Host reply
and automatically the system will ask
for a Voucher printing by send "Please
Insert VOUCHER Into PASSBOOK
Printer" message to the Teller.
7.The use case continues.
© HeiTech Padu Berhad
: DepositMngr
Appendix B - 18: Alternative Flow 4 - CCA Deposit
extend to
Require Override
Use Case.
6: verifies the Amount is within Teller limit
5: checks whether the Amount is less than transaction limit
4: Submet Inserted Amount
Use Case Continues at
Step No 10 in Basic Flow
[A9: Use
Calculator], [C3:
Amount Value
Conditions]
[E2: Amount
More Than
Transaction Limit]
2: Check Whether the account number is listed in Special Description table
1: displays "CCA Deposit" screen
: DepositFrm
3: key in Info and clicks "OK" button
: PMB Teller
B - 18
Appendix B
1.The system will automatically
display "PSV Deposit" screen.
2.The Teller type "Amount" [A9:
Use Calculator] and click the "OK
button. [C3: Amount Value
Conditions].
3.System checks whether the
Amount is less than transaction
limit [E2: Amount More Than
Transaction Limit] and verify that
the Amount is within Teller limit.
4.System sends the information to
the Host.
5.The system will receive Host
reply and automatically the
system will ask for a Voucher
printing by send "Please Insert
VOUCHER Into PASSBOOK
Printer" message to the Teller.
6.The use case continues.
SBS Project System Requirements Specification (SRS)
© HeiTech Padu Berhad
[E2: Amount
More Than
Transaction Limit]
Appendix B - 19: Alternative Flow 5 - PSV Deposit
extend to
Require Override
Use Case.
5: verifies the Amount is within Teller limit
4: checks whether the Amount is less than transaction limit
3: Submet Inserted Amount
Use Case Continues at
Step No 10 in Basic Flow
[A9: Use
Calculator], [C3:
Amount Value
Conditions]
: DepositMngr
1: displays "PSV Deposit" screen
: DepositFrm
2: key in "Amount" and clicks "OK" button
: PMB Teller
B - 19
Appendix B
6: print the automated amount of Rounding Mechanism
5: verifies the Amount is within Teller limit
4: checks whether the Amount is less than transaction limit
3: Submet Inserted Amount
[E2: Amount
More Than
Transaction Limit]
Use Case Continues at
Step No 10 in Basic Flow
11: Print Voucher
10: Submet Inserted Voucher
9: Insert GL Voucher
8: Display "Please insert GL VOUCHER into PASSBOOK Printer" message
7: Display "Please insert reverse of the customer's copy into PASSBOOK Printer" message
extend to
Require Override
Use Case.
[A9: Use
Calculator], [C3:
Amount Value
Conditions]
: DepositMngr
1: displays "Loan Repayment" screen
: DepositFrm
2: Insert "Amount" and clicks "OK"
: PMB Teller
Appendix B - 20: Alternative Flow 6 - Loan Cash Repayment
1.The system will automatically
display "Loan Repayment" screen.
2.The Teller type "Amount" [A9:
Use Calculator] and click the "OK
button. [C3: Amount Value
Conditions].
3.System checks whether the
Amount is less than transaction
limit [E2: Amount More Than
Transaction Limit] and verify that the
Amount is within Teller limit.
4.The system check if the Amount
need to adjustment or not. [A10
Calculate Rounding Adjustment].
5.System sends the information to
the Host.
6.The system will receive Host reply
and automatically the system will
ask for a Voucher printing by send
"Please Insert VOUCHER Into
PASSBOOK Printer" message to
the Teller.
7.System will prompt message
"Please insert reverse of the
customer's copy into PASSBOOK
Printer". This is to print the
automated amount of Rounding
Mechanism on the back of the
customer's copy.
8.System will prompt message
"Please insert GL VOUCHER into
PASSBOOK Printer".
9.The use case continues.
SBS Project System Requirements Specification (SRS)
© HeiTech Padu Berhad
B - 20
Appendix B
SBS Project System Requirements Specification (SRS)
[E2: Amount
More Than
Transaction Limit]
extend to
Require Override
Use Case.
5: verifies the Amount is within Teller limit
B - 21
Appendix B
4: checks whether the Amount is less than transaction limit
3: Submet Inserted Amount
Use Case Continues at
Step No 10 in Basic Flow
[A9: Use
Calculator], [C3:
Amount Value
Conditions]
: DepositMngr
1: displays "HP Deposit" screen
: DepositFrm
2: key in "Amount" and clicks "OK" button
: PMB Teller
Appendix B - 21: Alternative Flow 7 - HP Payment
1.The system will automatically display "HP
Payment" screen.
2.The Teller key in "Amount" [A9: Use
Calculator], choose "Payment Type" [C5:
Payment Type List] and click the "OK
button. [C3: Amount Value Conditions].
3.System checks whether the Amount is
less than transaction limit [E2: Amount
More Than Transaction Limit] and verify that
the Amount is within Teller limit.
4.The system check if the Amount need to
adjustment or not. [A10 Calculate Rounding
Adjustment].
5.System sends the information to the Host.
6.The system will receive Host reply and
automatically the system will ask for a
Voucher printing by send "Please Insert
VOUCHER Into PASSBOOK Printer"
message to the Teller.
7.The use case continues.
© HeiTech Padu Berhad
: DepositMngr
extend to
Require Override
Use Case.
6: updates Passbook
5: verifies the Amount is within Teller limit
4: checks whether the Amount is less than transaction limit
Use Case Continues at
Step No 10 in Basic Flow
10: Print Passbook
9: Submet Inserted Passbook
8: Insert Passbook
7: Display "Please Insert PSSBOOK to PASSBOOK Printer" message
[A9: Use
Calculator], [C3:
Amount Value
Conditions]
3: Submet Inserted Amount
[E2: Amount
More Than
Transaction Limit]
1: displays "Credit Card Payment" screen
: DepositFrm
2: Insert "Amount" Passbook Info and clicks "OK"
: PMB Teller
Appendix B - 22: Alternative Flow 8 - Credit Card Cash Payment
1.The system will automatically display
"Credit Card Payment" screen.
2.The Teller type "Amount" [A9: Use
Calculator] and click the "OK" button.
[C3: Amount Value Conditions].
3.System checks whether the Amount
is less than transaction limit [E2:
Amount More Than Transaction Limit]
and verify that the Amount is within
Teller limit.
4.The system check if the Amount need
to adjustment or not. [A10 Calculate
Rounding Adjustment].
5.System sends the information to the
Host.
6.The system will receive Host reply and
automatically the system will ask for a
Voucher printing by send "Please Insert
VOUCHER Into PASSBOOK Printer"
message to the Teller.
7.System will prompt message "Please
insert reverse of the customer's copy
into PASSBOOK Printer". This is to
print the automated amount of Rounding
Mechanism on the back of the
customer's copy.
8.System will prompt message "Please
insert GL VOUCHER into PASSBOOK
Printer".
9.The use case continues.
SBS Project System Requirements Specification (SRS)
© HeiTech Padu Berhad
B - 22
Appendix B
1.Teller clicks "Calculator"
button on the transaction
screen.
2.The "Calculator" screen
will appear.
3.The Teller use Calculator
buttons to calculate the
Amount.
4.The system transfers the
Amount on the "Calculator"
screen to the Amount on
the transaction screen.
5.The use case continues.
SBS Project System Requirements Specification (SRS)
© HeiTech Padu Berhad
: DepositFrm
: DepositMngr
: CalculatorFrm
Appendix B - 23: Alternative Flow 9 - Use Calculator
6: Transfer Amount to The Screen
5: Submet Calculated Amount
4: Use Calculator Buttons to Calculate Amount
3: Load Form
2: "Calculator" button is Pressed
1: clicks "Calculator" button
: PMB Teller
B - 23
Appendix B
SBS Project System Requirements Specification (SRS)
: PMB Teller
3: check the Amount ends in sen
2: Form Load
[E3: Host Error
Message]
: RoundingFrm
[R1: Rounding
Mechanism
Calculation]
6: clicks "OK"
5: display "Rounding Adjustment" and "Rounding Totals"
4: calculates "Rounding Adjustment"and "Rounding Totals"
[C4: Rounding
Adjustment
Mechanism]
: SBSManager
1: Amount need auto rounding adjustment
: DepositMngr
Appendix B - 24: Alternative Flow 10 - Calculate Rounding Adjustment
1.If the Amount need auto rounding
adjustment, the system will display
"Rounding Mechanism Adjustment"
screen. [E3: Host Error Message].
2.The system retrieves the "Original
Amount"
3.The system check the Amount
ends in sen to define "Rounding
Adjustment". [C4: Rounding
Adjustment Mechanism].
4.System calculates and displays
"Rounding Adjustment" and
"Rounding Totals" in screen. [R1:
Rounding Mechanism Calculation].
5.Teller clicks "OK", then system
sends rounding adjustment Amount
to the Host to print within the
Deposit/Payment Voucher.
6.The use case continues.
© HeiTech Padu Berhad
B - 24
Appendix B
: DepositMngr
1.Teller clicks
"Repeat" button.
2.System display new
screen and enters
same values as
previous values.
3.Teller can perform
this action by
press"F9".
Appendix B - 25: Alternative Flow 11 - Repeat Transaction
4: Enter Same value as Previous Values
3: Load New Form
2: Submet
: DepositFrm
1: Prees "Repeat" Button
: PMB Teller
SBS Project System Requirements Specification (SRS)
© HeiTech Padu Berhad
B - 25
Appendix B
Appendix B - 26: Alternative Flow 12 - Cancel Transaction
3: Unload Form
1.Teller clicks
"Cancel" button.
2.System cancels
current transaction
and display main
transaction screen.
: TransactionFrm
4: Load Form
: DepositMngr
2: Submet
: DepositFrm
1: Prees "Cancel" Button
: PMB Teller
SBS Project System Requirements Specification (SRS)
© HeiTech Padu Berhad
B - 26
Appendix B
1: Stop Transaction
: DepositMngr
2: Display Error Message
: DepositFrm
Appendix B - 28: Exception Flow 2 - Amount More Than Transaction Limit
1.The system will not allow
transaction to proceed.
2.The system notifies and
display error message.
SBS Project System Requirements Specification (SRS)
1: excludes Deposit/Payment transaction
: DepositMngr
2: Display "Transaction Not Authorized. Refer to Any MBB Branch."
: DepositFrm
Appendix B - 27: Exception Flow 1 - Exempted Account umber
1.The system excludes
Deposit/Payment transaction
from this account.
2.The system display
"Transaction Not Authorized.
Refer to Any MBB Branch."
message.
EXCEPTIO FLOWS
© HeiTech Padu Berhad
B - 27
Appendix B
: TransactionFrm
: SBSManager
3: Form Load
: RoundingFrm
Appendix B - 29: Exception Flow 3 - Host Error Message
Use case continues at step no
2 in [A10: Calculate Rounding
Adjustment] Alternative Flow.
2: Submet
1: selects "Rounding Mechanism Adjustment" under "Others" folder
: PMB Teller
SBS Project System Requirements Specification (SRS)
© HeiTech Padu Berhad
1.If the Amount need auto
rounding adjustment but
the system receives error
message from the Host,
Teller has to do rounding
adjustment manually.
2.Teller selects "Rounding
Mechanism Adjustment"
under "Others" folder in
transaction module menu.
3.Use case continues at
step no 2 in [A10:
Calculate Rounding
Adjustment} Alternative
Flow.
B - 28
Appendix B
Appendix B - 30: Exception Flow 4 - Receive Error From The Host].
1.If account number is
not within the clearing
code and the system
receives error message
: TransactionFrm
: CommissionFrm
: SBSManager
: PMB Teller
from the Host, the Teller
has to do commission
1: selects "Commission" under "Others" folder
manually.
2.Teller selects
2: Submet
"Commission" under
"Others" folder in
3: Form Load
transaction module
menu. "Commission"
screen will be displayed.
Use case continues at step no
3.Use case continues at
2 in [A1: Calculate
step no 2 in [A1:
Commission] Alternative Flow.
Calculate Commission]
Alternative Flow.
SBS Project System Requirements Specification (SRS)
© HeiTech Padu Berhad
B - 29
Appendix B
SBS Project System Requirements Specification (SRS)
BASIC FLOW
3. WITHDRAW MOEY
© HeiTech Padu Berhad
B - 30
Appendix B
: TransactionFrm
3: Submet
: WithdrawalFrm
7: Submet
5: Load Form
10: Get GMPC Info
: PassbookPrinter
21: Receive Host Reply
24: Insert Voucher
26: Print Voucher
Appendix B - 31: Basic Flow - Withdraw Money
27: Update EJ and Teller Total
25: Submet Inserted Vocher
23: Display "Please Insert VOUCHER Into PASSBOOK Printer" message
22: Submet
20: check Transaction Info
19: Submet Transaction Info
18: Send Transaction Info
15: validate Customers' product type
14: verify the account number within cleaning code
[A1: Calculate
Commission]
12: Return GMPC Info
11: Read GMPC
[E1: Verification
Fail]
13: Display message "TP Verification Pass"
[A2: Saving Account-Passbookless Withdraw],
[A3: Saving Account-Passbook W ithdraw].
17: make cash W ithdrawal
: WithdrawalMngr
4: Load W ithdrawal Form
: SBSManager
8: Display "Please Insert GMPC in Card Reader" message
16: make the selection of "Repeat" or "Cancel"
[A4: Repeat Transaction],
[A5: Cancel Transaction]
9: Insert GMPC
6: Enter Customers' "Account Number" /use GMPC
2: chooses "Withdrawal"
1: Select "Cash Activities"
: PMB Teller
SBS Project System Requirements Specification (SRS)
© HeiTech Padu Berhad
: Host
B - 31
Appendix B
SBS Project System Requirements Specification (SRS)
1.If account number is not
within the clearing code, the
system will pop up
"Commission" screen. [E3:
Receive Error From The Host].
2.The Teller chooses the
technique that the Customer
will use to pay the
commission whether by
paying "Cash" or "deduct"
from the cash amount that the
Customer provides for
Withdraw purpose. Otherwise
the Teller can choose "Nil".
3.The system calculates
"Commission Amount" and
display to the Teller [C1:
Commission Amount Status].
4.The system will keep
commission accumulated by
Teller in Teller Table file.
5.The Teller collects
Commission Amount from the
Customer.
6.The Teller click "OK" button,
the "Commission" screen is
unloaded.
ALTERATIVE FLOWS
© HeiTech Padu Berhad
: WithdrawalFrm
: SBSManager
: CommissionFrm
2: Form Load
6: Display Commission Amount
8: click "OK" button
9: Form Unload
7: keeps commission accumulated by Teller in Teller Table file.
[C1: Commission
Amount Status].
5: calculates "Commission Amount"
4: Submet
3: chooses the technique that the Customer will use to pay the commissio
[E3: Receive Error
From The Host].
1: account number is not within the clearing code
: PMB Teller
B - 32
Appendix B
SBS Project System Requirements Specification (SRS)
[E2: Amount
More Than
Transaction Limit]
extend to
Require Override
Use Case.
5: verifies the Amount is within Teller limit
4: checks whether the Amount is less than transaction limit
3: Submet Inserted Amount
Appendix B - 33: Alternative Flow 2 - Saving Account-Passbookless Withdraw
Use Case Continues at
Step No 15 in Basic Flow
[A6: Use
Calculator], [C2:
Amount Value
Conditions]
: WithdrawalFrm
1: displays "Saving Account Withdrawalt" screen
: WithdrawalFrm
2: key in "Amount" and clicks "OK" button
: PMB Teller
Appendix B - 32: Alternative Flow 1 - Calculate Commission
1.System displays appropriate "Saving
Account Withdrawal" screen.
2.The Teller key in "Amount" [A6: Use
Calculator], "Card No" and clicks "OK"
button. [C2: Amount Value
Conditions].
3.System checks whether the Amount
is less than transaction limit [E2:
Amount More Than Transaction Limit]
and verify that the Amount is within
Teller limit.
4.System sends the information to the
Host.
5.The system will receive Host reply
and automatically the system will ask
for a Voucher printing by send "Please
Insert VOUCHER Into PASSBOOK
Printer" message to the Teller.
6.The use case continues.
© HeiTech Padu Berhad
B - 33
Appendix B
SBS Project System Requirements Specification (SRS)
1.System displays appropriate
"Saving Account Withdrawal"
screen.
2.The Teller key in "Amount" [A6:
Use Calculator], "Passbook
Balance", "Passbook Number"
and clicks "OK" button. [C2:
Amount Value Conditions].
3.System checks whether the
Amount is less than transaction
limit [E2: Amount More Than
Transaction Limit] and verify that
the Amount is within Teller limit.
4.System updates Passbook and
sends transactions information to
the Host. But if "Passbook
Balance" and "Passbook Number"
is not inserted, the system only
sends Deposit transaction
information to the Host.
5.The system will receive Host
reply and automatically the
system will ask for a Voucher
printing by send "Please Insert
VOUCHER Into PASSBOOK
Printer" message to the Teller
.Also, system send "Please Insert
PSSBOOK to PASSBOOK
Printer " message to print
Passbook.
6.The use case continues.
© HeiTech Padu Berhad
: WithdrawalMngr
1: displays "Saving Account Withdrawa" screen
: WithdrawalFrm
6: updates Passbook
extend to
Require Override
Use Case.
5: verifies the Amount is within Teller limit
4: checks whether the Amount is less than transaction limit
10: Print Passbook
9: Submet Inserted Passbook
8: Insert Passbook
7: Display "Please Insert PSSBOOK to PASSBOOK Printer" message
Use Case Continues at
Step No 10 in Basic Flow
[A6: Use
Calculator], [C2:
Amount Value
Conditions]
[E2: Amount
3: Submet Inserted Amount More Than
Transaction Limit]
2: Insert "Amount" ,Passbook Info and clicks "OK"
: PMB Teller
B - 34
Appendix B
SBS Project System Requirements Specification (SRS)
© HeiTech Padu Berhad
4: Enter Same value as Previous Values
3: Load New Form
2: Submet
: WithdrawalMngr
Appendix B - 35: Alternative Flow 4 - Repeat Transaction
1.Teller clicks
"Repeat" button.
2.System display new
screen and enters
same values as
previous values.
3.Teller can perform
this action by
press"F9".
: WithdrawalFrm
1: Prees "Repeat" Button
: PMB Teller
Appendix B - 34: Alternative Flow 3 - Saving Account-Passbook Withdraw
B - 35
Appendix B
Appendix B - 36: Alternative Flow 5 - Cancel Transaction
3: Unload Form
1.Teller clicks
"Cancel" button.
2.System cancels
current transaction
and display main
transaction screen.
: TransactionFrm
4: Load Form
: WithdrawalMngr
2: Submet
: WithdrawalFrm
1: Prees "Cancel" Button
: PMB Teller
SBS Project System Requirements Specification (SRS)
© HeiTech Padu Berhad
B - 36
Appendix B
1.Teller clicks "Calculator"
button on the transaction
screen.
2.The "Calculator" screen
will appear.
3.The Teller use Calculator
buttons to calculate the
Amount.
4.The system transfers the
Amount on the "Calculator"
screen to the Amount on
the transaction screen.
5.The use case continues.
SBS Project System Requirements Specification (SRS)
© HeiTech Padu Berhad
: WithdrawalFrm
: WithdrawalMngr
: CalculatorFrm
Appendix B - 37: Alternative Flow 6 - Use Calculator
6: Transfer Amount to The Screen
5: Submet Calculated Amount
4: Use Calculator Buttons to Calculate Amount
3: Load Form
2: "Calculator" button is Pressed
1: clicks "Calculator" button
: PMB Teller
B - 37
Appendix B
1: Stop Transaction
: WithdrawalMngr
Appendix B - 39: Exception Flow 2 - Amount More Than Transaction Limit
2: Display Error Message
: WithdrawalFrm
Appendix B - 38: Exception Flow 1 - Verification Fail
3: Stop Transaction
1.If verification failed, message
'TP verification fail' will appear.
2.The transaction will be
aborted.
: PassbookPrinter
1: Verification Failed
: WithdrawalMngr
2: Display "TP verification fail" Message
: WithdrawalFrm
SBS Project System Requirements Specification (SRS)
EXCEPTIO FLOWS
© HeiTech Padu Berhad
B - 38
Appendix B
: TransactionFrm
Appendix B - 40: Exception Flow 3 - Receive Error From The Host
Use case continues at step no
2 in [A1: Calculate
Commission] Alternative Flow.
: CommissionFrm
3: Form Load
: SBSManager
2: Submet
1: selects "Commission" under "Others" folder
: PMB Teller
SBS Project System Requirements Specification (SRS)
© HeiTech Padu Berhad
B - 39
Appendix B
© HeiTech Padu Berhad
4. REMIT MOEY
BASIC FLOW
SBS Project System Requirements Specification (SRS)
Appendix B - 41: Basic Flow - Remit Money
1.This use case begins when a Customer
requires Teller to make Remittance
transaction by submitting a filled Remittance
form to Teller.
: PMB Teller : TransactionFrm : RemitFrm : SBSManager : RemitMngr : Host
2.Based on Customer request, Teller can
select Remittance type whether it "FTT",
1: Select "Cash Activities"
[A1: Foreign Worker
"FWTT" [A1: Foreign Worker Telegraph
Telegraph Transfer],
Transfer] or "Interbank GIRO" [A2: GIRO
2: Chooses "FTT" Under "Remittance" Menu
[A2: GIRO Fund Transfer]
Fund Transfer].
3.Teller selects "Cash Activities" and
3: Submet
[C1: Foreign Amount Value], [R1:
chooses "FTT" under "Remittance" menu.
Foreign Amount Calculation], [C2:
The "Foreign Telegraphic Transfer" screen
Ringgit Amount Value], [R2: Ringgit
4: Load Foreign Telegraphic Transfer Form
will be displayed.
Amount Calculation], [R4: Cable Charge
4.Teller has to select "Country", "Currency
Amount Value]. [A3: Use Calculator].
5: Form Load
Code", "BIC Code" , "BOP Info", "Ringgit
Fixed", "Foreign Amount" [C1: Foreign
6: Filles Required Fields
Amount Value], [R1: Foreign Amount
Calculation], "Ringgit Amount" [C2: Ringgit
Amount Value], [R2: Ringgit Amount
7: submet
Calculation], and "Cable Charge Amount"
[R4: Cable Charge Amount Value]. [A3: Use
8: Display "Counter Rate" and "Comm Charge Amount"
Calculator].
5.System display "Counter Rate" and
9: Inserts Ordering Customer Info
"Comm Charge Amount". [R3: Commission
[R3: Commission
Charge Amount Value].
10: Inserts Beneficiary Info
Charge Amount
6.Teller inserts Ordering Customer info which
Value]
is "Name", "Address", "ID No" and
11: Inserts Beneficiary Banker Info
"Payment to Beneficiary".
7.Teller inserts Beneficiary info which is
12: make the selection of "Repeat" or "Cancel"
[E2: Hybird
"Account No", "Name", "Address" and
Server is
"Payment Details".
13: Send Transaction Info Offline].
8.Teller inserts Beneficiary Banker info which
[A5: Repeat Transaction],
is "Name", "Address", "City" and "Country".
[A6: Cancel Transaction]
14: Verifiy the data
9.Teller inserts Beneficiary Banker info which
is "Remitter Status", "Beneficiary Status",
extend to
"Same party/Different party", "Foreign
15: Verify the Amount With Teller Limit
Require Override
Worker", "Form P Purpose Code",
Use Case.
"Description" and "Relationship".
10.System verifies the data and if incomplete
16: Check if the Amount Need to Adjustment
or wrong data, the system notifies the Teller
[A4: Calculate
by error message. [E2: Hybird Server is
Rounding
17: Submet Transaction Info
Offline].
Adjustment]
11.At any transaction, when the Teller enters
18: check Transaction Info
Amount, system verifies whether the Amount
is within Teller limit and if not extend to
19: Receive Host Reply
Require Override Use Case. The system
check if the Amount need to adjustment or
20: Submet
not. [A4: Calculate Rounding Adjustment].
12.At any time, Teller can make the
selection of "Repeat" [A5: Repeat
21: Display "Please Insert VOUCHER Into PASSBOOK Printer" message
Transaction], or "Cancel" current Transaction
[A6: Cancel Transaction].
22: Insert Voucher
13.Upon successful transaction, the system
will receive Host reply and automatically the
23: Submet Inserted Voucher
system will ask for a Voucher printing by
send "Please Insert VOUCHER Into
24: Print
PASSBOOK Printer" message to the Teller.
14.The system will send the transaction and
25: update EJ
MBB base branch code to Host.
15.The system will update EJ.
16.The use case ends when the
26: Unload
"Remittance" screen is unloaded.
Appendix B
B - 40
SBS Project System Requirements Specification (SRS)
1.Teller selects "Cash Activities" and
chooses "FWTT" under "Remittance"
menu. The "Foreign Worker
: PMB Teller
: TransactionFrm
Telegraphic Transfer" screen will be
: RemitFrm
: SBSManager
: RemitMngr
: Host
displayed.
1: Chooses "FWTT" Under "Remittance" Menu
2.Teller key in "Membership ID" or
"IC/Passport No" and press Enter key.
2: Submet
3.System verifies the input and send
to Host to retrieves info. [E1:
Customer Is Not A Member].
3: Load Foreign Worker Telegraphic Transfer Form
4.System display retrieved info on the
screen which are "Country", "Payment
4: Form Load
Mode to Bene ", "Currency Code",
"Ringgit Amount", "Counter Rate",
5: Inserts "Membership ID" or "IC/Passport No"
"Ringgit Fixed (Y/N)", "Foreign
Amount" , "Service Charge" and
6: submet
"Cable Charge". [A3: Use Calculator].
5.Teller has to input Remitter Details
[E1: Customer Is
which are "Name", "IC/Passport No",
7: Verify the Input
Not A Member]
"DOB", "Occupation", "Address",
"Contact No", "Purpose of Payment"
8: Retrieves Info for Customer
and "Foreign Worker (Y/N)".
6.Teller has to input Beneficiary
9: Get Customer Info
Details which are "Name/First Name
(PHP)", "Surname", "Address",
10: Send Customer Info
"IC/Passport No.", "Account No", "Tel
No", "MBB Overseas Branch Code",
11: Submet Retrived Info
"Agent Bank Branch Code", "Bank
Name", "Bank Branch", "PCHC Bank
Code", "PCHC Branch Name", "Non
12: Display Retrieved Info
PCHC Bank Name/Branch", "Payment
Details" and "BOP (Malaysia)".
13: Input Remitter Details
7.The use case continues at step no
10 in Basic Flow.
14: Input Beneficiary Details
use case continues at
step no 10 in Basic Flow
ALTERATIVE FLOWS
© HeiTech Padu Berhad
B - 41
Appendix B
Appendix B - 42: Alternative Flow 1 - Foreign Worker Telegraph Transfer
SBS Project System Requirements Specification (SRS)
Appendix B - 43: Alternative Flow 2 - GIRO Fund Transfer
1.Teller selects "Cash Activities"
and chooses "Interbank GIRO"
under "Remittance" menu. The
: PMB Teller
: TransactionFrm
: RemitFrm
: SBSManager
: RemitMngr
"GIRO Fund Transfer" screen will
be displayed.
2.Teller has to insert "Receiving 1: Chooses "Interbank GIRO" Under "Remittance" Menu
Bank ", "Amount" [C3: Amount
2: Submet
Value Condition], [A3: Use
Calculator]., "Service Charge",
3: Load GIRO Fund Transfer Form
"Applicant Type", "Name", "New
IC", "Old IC" [C4: "New IC" and
use case continues at
4: Form Load
"Old IC" value], "Oth Id Type", "ID
step no 10 in Basic Flow
No.", "Ref No.", "Description" and
"BOP".
5: Insert Required Fields
3.The use case continues at step
no 10 in Basic Flow.
© HeiTech Padu Berhad
B - 42
Appendix B
: RemitFrm
: RemitMngr
: CalculatorFrm
6: Transfer Amount to The Screen
5: Submet Calculated Amount
4: Use Calculator Buttons to Calculate Amount
3: Load Form
2: "Calculator" button is Pressed
1: clicks "Calculator" button
: PMB Teller
Appendix B - 44: Alternative Flow 3 - Use Calculator
1.Teller clicks "Calculator"
button on the transaction
screen.
2.The "Calculator" screen
will appear.
3.The Teller use Calculator
buttons to calculate the
Amount.
4.The system transfers the
Amount on the "Calculator"
screen to the Amount on
the transaction screen.
5.The use case continues.
SBS Project System Requirements Specification (SRS)
© HeiTech Padu Berhad
B - 43
Appendix B
SBS Project System Requirements Specification (SRS)
: PMB Teller
: SBSManager
3: check the Amount ends in sen
[R5: Rounding
Mechanism
Calculation]
6: clicks "OK"
5: display "Rounding Adjustment" and "Rounding Totals"
4: calculates "Rounding Adjustment"and "Rounding Totals"
[C5: Rounding
Adjustment
Mechanism]
[E3: Host Error
Message]
: RoundingFrm
2: Form Load
1: Amount need auto rounding adjustment
: RemitMngr
Appendix B - 45: Alternative Flow 4 - Calculate Rounding Adjustment
1.If the Amount need auto rounding
adjustment, the system will display
"Rounding Mechanism Adjustment"
screen. [E3: Host Error Message].
2.The system retrieves the "Original
Amount"
3.The system check the Amount
ends in sen to define "Rounding
Adjustment". [C5: Rounding
Adjustment Mechanism].
4.System calculates and displays
"Rounding Adjustment" and
"Rounding Totals" in screen. [R5:
Rounding Mechanism Calculation].
5.Teller clicks "OK", then system
sends rounding adjustment Amount
to the Host to print within the
Deposit/Payment Voucher.
6.The use case continues.
© HeiTech Padu Berhad
B - 44
Appendix B
: RemitMngr
1.Teller clicks
"Repeat" button.
2.System display new
screen and enters
same values as
previous values.
3.Teller can perform
this action by
press"F9".
Appendix B - 46: Alternative Flow 5 - Repeat Transaction
4: Enter Same value as Previous Values
3: Load New Form
2: Submet
: RemitFrm
1: Prees "Repeat" Button
: PMB Teller
SBS Project System Requirements Specification (SRS)
© HeiTech Padu Berhad
B - 45
Appendix B
Appendix B - 47: Alternative Flow 6 - Cancel Transaction
3: Unload Form
1.Teller clicks
"Cancel" button.
2.System cancels
current transaction
and display main
transaction screen.
: TransactionFrm
4: Load Form
: RemitMngr
2: Submet
: RemitFrm
1: Prees "Cancel" Button
: PMB Teller
SBS Project System Requirements Specification (SRS)
© HeiTech Padu Berhad
B - 46
Appendix B
: RemitFrm
3: Input Customer Info
: PMB Teller
: RemitMngr
2: Display Empty Fields
1: Customer Not A Member
: SBSManager
Appendix B - 48: Exception Flow 1 - Customer Is ot A Member
1.If Customer is not
a member, system
will not receive any
info from the Host
and Teller has to
key in the info
based on the form.
2.Use Case
continues.
SBS Project System Requirements Specification (SRS)
EXCEPTIO FLOWS
© HeiTech Padu Berhad
B - 47
Appendix B
1: Offline at Hybrid Server
: RemitMngr
extends to View
Electronic Journal And
Forex Rate Use Case.
2: Display Error Message
: RemitFrm
3: Click "OK"
: PMB Teller
Appendix B - 49: Exception Flow 2 - Hybird Server is Offline
1.If offline at Hybrid Server
happens, Teller could not
download the latest Forex rate.
2.System displays "Rate
Mismatch." error message.
3.Teller clicks "OK" button,
system extends to View
Electronic Journal And Forex
Rate Use Case.
4.Use Case continues.
SBS Project System Requirements Specification (SRS)
© HeiTech Padu Berhad
B - 48
Appendix B
: TransactionFrm
: SBSManager
3: Form Load
: RoundingFrm
Appendix B - 50: Exception Flow 3 - Host Error Message
Use case continues at step no
2 in [A10: Calculate Rounding
Adjustment] Alternative Flow.
2: Submet
1: selects "Rounding Mechanism Adjustment" under "Others" folder
: PMB Teller
SBS Project System Requirements Specification (SRS)
© HeiTech Padu Berhad
1.If the Amount need auto
rounding adjustment but
the system receives error
message from the Host,
Teller has to do rounding
adjustment manually.
2.Teller selects "Rounding
Mechanism Adjustment"
under "Others" folder in
transaction module menu.
3.Use case continues at
step no 2 in [A4:
Calculate Rounding
Adjustment} Alternative
Flow.
B - 49
Appendix B
© HeiTech Padu Berhad
5. REVERSE TRASACTIO
BASIC FLOW
SBS Project System Requirements Specification (SRS)
Appendix B - 51: Basic Flow - Reverse Transaction
1.This use case begins
when Teller selects
"Reversal" from the
: PMB Teller : TransactionFrm : SBSManager : ReversalFrm : ReversalMngr : Host
"Transaction Module"
menu and chooses
1: Select Reversal
"Reversal" [A1: Reversal
by Electronic Journal].
The "Reversal" screen
2: Choose "Reversal By Journal No"
will be displayed.
2.The system asks the
3: Submet
Teller for Journal No.
Teller can read Journal
[A1: Reversal by
4: Form Load
No from the printed
Electronic Journal]
transaction Voucher.
3.The Teller Key in
5: Key in "Journal No" And Click "OK" Button
"Journal No" and then
click "OK" button.
6: Submet
4.The system will
display the screen that
7: Search For Transaction Based On Inserted No
shows the related
transaction to be
reversed based on
8: Display Related Transactions
Journal No.
5.The Teller clicks
9: Click "Reverse"
use Require
"Reverse" to start
Override Use Case
transaction Reversal.
10: "Reverse" is Pressed
6.The system request
Override from PMB
11: Require Supervisor Override
Branch Officer by use
Require Override Use
Case.
12: Submet Override Requist
7.When supervisor
approves the Override
request, system sends
13: Requisted Override is Approved
the information to the
Host.
14: Send Transaction Info
8.The system will
receive Host reply and
15: Submet Transaction Info
automatically the
system will ask for a
16: Check Transaction Info
Voucher printing by
send "Please Insert
VOUCHER Into
17: Recive Host Reply
PASSBOOK Printer"
message to the Teller.
18: Submet
9.At any time, Teller can
click "Cancel" to cancel
current process. [A2:
19: Update EJ and Teller Total
"Cancel" pressed].
10.The system will save
20: Display "Please Insert VOUCHER Into PASSBOOK Printer" message
the data in database.
11.The system will
update EJ.
21: Insert Voucher
12.The use case ends
when Reversal
22: Submet Inserted Voucher
transaction screen is
unloaded.
23: Print Voucher
Appendix B
B - 50
SBS Project System Requirements Specification (SRS)
Appendix B - 52: Alternative Flow 1 - Reversal by Electronic Journal
1.This alternative flow will only be used if the
Teller doesn't has the transaction Voucher
printed. The Teller can search the
transaction by using Electronic Journal.
:
Host
: ReversalMngr
: ReversalFrm
: SBSManager
:
TransactionFrm
2.Teller selects "Reversal" from the
: PMB Teller
"Transaction Module" menu and chooses
"EJ Viewer". The "EJ Viewer" screen will be
1: Select Reversal
displayed.
3.System shows current sign on "User ID" ,
current "Date" and give the Teller options to
2: Choose "EJ Viewer"
perform the search using "Time", "Account
No", "Amount" , "Sequence No " ,
3: Submet
"Transaction Code" or by select the
"Successful" of the financial transaction that
4: Form Load
done.
4.When the Teller choose "Time", "Account
No", "Amount" or "Sequence No " option,
5: Choose Searsh Option And Click "Search" Button
then he has to give more information about
the transaction by edit "From" and "To" info.
6: Submet
But if he choose "Successful" option, then
7: Search For Transaction Record Bsed On Search Criteria Teller can choose between "Y" and "No"
options.
5.The Teller has to clicks "Search" button;
8: Display Related Transaction Record
the system will display list of records that
contains info (i.e. Journal No, Date, Time,
Account No, Amount, Transaction Mode,
9: Choose One Record And Click "OK"
etc) associated with selected search criteria.
6.Teller selects one record to be reversed
10: Submet Selected Record
and then click "OK" button.
continues at flow number
7.This Alternative Flow continues at flow
11 in Basic Flow.
number 6 in Basic Flow.
ALTERATIVE FLOWS
© HeiTech Padu Berhad
B - 51
Appendix B
Appendix B - 53: Alternative Flow 2 - "Cancel" Pressed
3: Unload Form
1.Teller clicks
"Cancel" button.
2.System cancels
current transaction
and display main
transaction screen.
: TransactionFrm
4: Load Form
: ReversalMngr
2: Submet
: ReversalFrm
1: Prees "Cancel" Button
: PMB Teller
SBS Project System Requirements Specification (SRS)
© HeiTech Padu Berhad
B - 52
Appendix B
: TransactionFrm
1: Select "Inquiry"
: PMB Mediator
: InquiryFrm
SBS Project System Requirements Specification (SRS)
7: Submet
4: Load Form
: Host
15: update EJ
14: Submet
13: Receive Inquired transaction Info
12: inquire Transaction Info
11: Submet Transaction Info
10: Send Transaction Info
Appendix B - 54: Basic Flow - Inquire Balance
16: displays selected Inquiry information on screen
9: make the selection of "Repeat" or "Cancel"
[A12: Repeat Transaction],
[A13: Cancel Transaction]
: InquiryMngr
3: Load Inquiry Form
: SBSManager
8: shows "Name/IC Inquiry" screen
2: Submet
[A1: CA Last Transaction] , [A2:
CA Activity] , [A3: SA Activity] ,
[A4: SA Last Transaction] , [A5:
Credit Card] , [A6: FTT Transaction
Detail] , [A7: FWTT Transaction
Reference], [A8: FWTT
5: Selects "Inquiry Type" as "Name/IC No"
Transaction] , [A9: GIRO
Transaction Detail], [A10: HP
Transaction] , [A11: Loan Activity]. 6: Enters "Account Number" And Clicks "OK
BASIC FLOW
6. IQUIRE BALACE
© HeiTech Padu Berhad
B - 53
Appendix B
: InquiryFrm
: InquiryMngr
SBS Project System Requirements Specification (SRS)
Appendix B - 55: Alternative Flow 1 - CA Last Transaction
1: Selects "Inquiry Type" as "CA Last Transaction"
1.Mediator selects to
"Inquiry Type" as "CA
Last Transaction" and
enters "Account
2: Enters "Account Number" And Clicks "OK
Number" .Mediator clicks
"OK", system shows
3: Submet
"CA Last Transaction
Use case
Inquiry" screen.
continues at
Basic Flow No 8
4: shows "CA Last Transaction"screen 2.Use case continues.
: PMB Mediator
ALTERATIVE FLOWS
© HeiTech Padu Berhad
B - 54
Appendix B
: InquiryFrm
: InquiryMngr
Appendix B - 56: Alternative Flow 2 - CA Activity
1: Selects "Inquiry Type" as "CA Activity"
1.Mediator selects to
"Inquiry Type" as "CA
Activity" and enters
2: Enters "Account Number" And Clicks "OK
"Account Number"
.Mediator clicks "OK",
system shows "CA
3: Submet
Use case
Activity Inquiry"
continues at
screen.
Basic Flow No 8
4: shows "CA Activity" screen 2.Mediator selects
"Activity" as "Cash
Deposit/Payment".
5: Select "Activity"
3.Use case continues.
: PMB Mediator
SBS Project System Requirements Specification (SRS)
© HeiTech Padu Berhad
B - 55
Appendix B
: InquiryFrm
: InquiryMngr
Appendix B - 57: Alternative Flow 2 -SA Activity
1.Mediator selects to
"Inquiry Type" as "SA
Activity"
and enters
2: Enters "Account Number" And Clicks "OK
"Account Number"
.Mediator clicks "OK",
3: Submet
Use case
system shows "SA Last
continues at
Transaction Inquiry"
Basic Flow No 8
screen.
4: shows "SA Activity" screen 2.Mediator can select
"Activity" as "Cash
5: Select "Activity"
Deposit/Payment" or "Cash
Withdrawal".
3.Use case continues.
1: Selects "Inquiry Type" as "SA Activity"
: PMB Mediator
SBS Project System Requirements Specification (SRS)
© HeiTech Padu Berhad
B - 56
Appendix B
: InquiryFrm
: InquiryMngr
Appendix B - 58: Alternative Flow 4 - SA Last Transaction
1: Selects "Inquiry Type" as "SA Last Transaction"
1.Mediator selects to
"Inquiry Type" as "SA
Last Transaction" and
2: Enters "Account Number" And Clicks "OK
enters "Account
Number" .Mediator
clicks "OK", system
3: Submet
Use case
shows "SA Last
continues at
Transaction Inquiry"
Basic Flow No 8
4: shows "SA Last Transaction"screen screen.
2.Use case continues.
: PMB Mediator
SBS Project System Requirements Specification (SRS)
© HeiTech Padu Berhad
B - 57
Appendix B
: InquiryFrm
: InquiryMngr
Appendix B - 59: Alternative Flow 5 - Credit Card
1.Mediator selects to
"Inquiry Type" as
"Credit Card Activity"
2: Enters "Account Number" And Clicks "OK
and enters "Account
Number" .Mediator
clicks "OK", system
3: Submet
Use case
shows "Credit Card
continues at
Inquiry" screen.
Basic Flow No 8
4: shows "Credit Card Inquiry"screen 2.Mediator selects
"Activity" as "Cash
Deposit/Payment".
5: Select "Activity"
3.Use case continues
1: Selects "Inquiry Type" as "Credit Card Activity"
: PMB Mediator
SBS Project System Requirements Specification (SRS)
© HeiTech Padu Berhad
B - 58
Appendix B
: InquiryFrm
: InquiryMngr
Appendix B - 60: Alternative Flow 6 - FTT Transaction Detail
1: Selects "Inquiry Type" as "FTT Transaction Detail"
1.Mediator selects to
"Inquiry Type" as "FTT
Transaction Detail" and
enters "Account Number"
2: Enters "Account Number" And Clicks "OK
.Mediator clicks "OK",
system shows "FTT
3: Submet
Use case
Transaction Detail"
continues at
screen.
Basic Flow No 8
4: shows "FTT Transaction Detail" screen 2.Mediator key in
"Reference Number" and
clicks "OK" button.
5: key in "Reference Number" and clicks "OK" button
3.Use case continues
: PMB Mediator
SBS Project System Requirements Specification (SRS)
© HeiTech Padu Berhad
B - 59
Appendix B
: InquiryFrm
: InquiryMngr
1.Mediator selects to
"Inquiry Type" as
"FWTT Transaction
2: Enters "Account Number" And Clicks "OK
Reference" and enters
"Account Number"
.Mediator clicks "OK",
3: Submet
Use case
system shows "FWTT
continues at
Inquiry" screen.
Basic Flow No 8
4: shows "FWTT Inquiry" screen 2.Mediator key in
"Reference Number"
and clicks "OK" button.
5: key in "Reference Number" and clicks "OK" button
3.Use case continues
: PMB Mediator
Appendix B - 61: Alternative Flow 7 - FWTT Transaction Reference
1: Selects "Inquiry Type" as "FWTT Transaction Reference"
SBS Project System Requirements Specification (SRS)
© HeiTech Padu Berhad
B - 60
Appendix B
: InquiryFrm
: InquiryMngr
Appendix B - 62: Alternative Flow 8 - FWTT Transaction
1.Mediator selects to "Inquiry
Type" as "FWTT Transaction" and
1: Selects "Inquiry Type" as "FWTT Transaction "
enters "Account Number"
.Mediator clicks "OK", system
2: Enters "Account Number" And Clicks "OK
shows "FWTT Transaction Inquiry"
screen.
2.Mediator has option to select
Use case
3: Submet
country either "Philippines" or
continues at
"Other countries".
Basic Flow No 8
4: shows "FWTT Transaction Inquiry" screen 3.If Philippines, Mediator selects
"Agent Nostro" then clicks "OK"
button.
5: Select "Countery", "Agent Nostro" and clicks "OK" button
4.Use case continues
: PMB Mediator
SBS Project System Requirements Specification (SRS)
© HeiTech Padu Berhad
B - 61
Appendix B
: InquiryFrm
: InquiryMngr
Appendix B - 63: Alternative Flow 9 - GIRO Transaction Detail
1: Selects "Inquiry Type" as "GIRO Transaction Detail"
1.Mediator selects to
"Inquiry Type" as "GIRO
Transaction Detail" and
2: Enters "Account Number" And Clicks "OK
enters "Account Number"
.Mediator clicks "OK",
system shows "GIRO
3: Submet
Use case
Transaction Detail Inquiry"
continues at
screen.
Basic Flow No 8
4: shows "GIRO Transaction Detail" screen 2.Mediator key in
"Reference Number" and
clicks "OK" button.
5: key in "Reference Number" and clicks "OK" button
3.Use case continues
: PMB Mediator
SBS Project System Requirements Specification (SRS)
© HeiTech Padu Berhad
B - 62
Appendix B
: InquiryFrm
Appendix B - 64: Alternative Flow 10 - HP Transaction
1.Mediator selects to
"Inquiry Type" as "HP
Inquiry" and enters
"Account Number"
.Mediator clicks "OK",
system shows "HP
Inquiry" screen.
2.Mediator key in
"Reference Number"
and clicks "OK" button.
3.Use case continues.
: InquiryMngr
4: shows "HP Inquiry" screen
3: Submet
5: key in "Reference Number" and clicks "OK" button
Use case
continues at
Basic Flow No 8
2: Enters "Account Number" And Clicks "OK
1: Selects "HP Inquiry"
: PMB Mediator
SBS Project System Requirements Specification (SRS)
© HeiTech Padu Berhad
B - 63
Appendix B
: InquiryFrm
: InquiryMngr
Appendix B - 65: Alternative Flow 11 - Loan Activity
1.Mediator selects to
"Inquiry Type" as
"Loan Activity" and
2: Enters "Account Number" And Clicks "OK
enters "Account
Number" .Mediator
3: Submet
clicks "OK", system
Use case
shows "Loan Activity
continues at
Inquiry" screen.
4: shows "Loan Activity"screen
Basic Flow No 8
2.Use case continues.
1: Selects "Inquiry Type" as "Loan Activity"
: PMB Mediator
SBS Project System Requirements Specification (SRS)
© HeiTech Padu Berhad
B - 64
Appendix B
2: Submet
: InquiryMngr
Appendix B - 66: Alternative Flow 12 - Repeat Transaction
4: Enter Same value as Previous Values
3: Load New Form
: InquiryFrm
1: Prees "Repeat" Button
: PMB Mediator
1.Teller clicks
"Repeat" button.
2.System display new
screen and enters
same values as
previous values.
3.Teller can perform
this action by
press"F9".
SBS Project System Requirements Specification (SRS)
© HeiTech Padu Berhad
B - 65
Appendix B
2: Submet
Appendix B - 67: Alternative Flow 13 - Cancel Transaction
1.Teller clicks
"Cancel" button.
2.System cancels
current transaction
and display main
transaction screen.
: TransactionFrm
4: Load Form
: InquiryMngr
3: Unload Form
: InquiryFrm
1: Prees "Cancel" Button
: PMB Mediator
SBS Project System Requirements Specification (SRS)
© HeiTech Padu Berhad
B - 66
Appendix B
© HeiTech Padu Berhad
Appendix B - 68: Basic Flow - Maintain Passbook
1: Select "Passbook Maintenance"
1.This use case begins when a
Customer requires Teller to
maintain his/her Passbook request 2: chooses "Passbook Update"
update Passbook, change posting
line or change Passbook status to
3: Submet
new.
2.Teller selects "Passbook
[A1: Change Posting
4: Load Maintainance Form
Maintenance" under "Transaction
Line], [A2: Change
Module" menu and chooses
Passbook Status To New]
5: Load Form
"Passbook Update" [A1: Change
Posting Line], [A2: Change
Passbook Status To New]. The6: Enter Customers' "Account Number", Pssbook Info and click "OK"
"Passbook Update" screen will
display.
7: Submet
3.Teller key in "Account Number",
[C1: Passbook
"Passbook Balance", "Passbook
Balance Condition]
8: verify the account number within cleaning code
Number" and then click "OK"
[A3: Calculate
button. [C1: Passbook Balance
Commission]
9: validate Customers' product type
Condition].
4.The system verify the account
number whether it within cleaning
10: make the selection of "Repeat" or "Cancel"
code or not by check the 2nd and
3rd digit of account number
11: Send Transaction Info
against the branch clearing code.
[A3: Calculate Commission].
12: Submet Transaction Info
[A4: Repeat Transaction],
5.The system validate Customers'
[A5: Cancel Transaction]
product typed based on Account
13: check Transaction Info
Number.
6.At any time, Teller can make the
14: Receive Host Reply
selection of "Repeat" [A4: Repeat
Transaction], or "Cancel" current
15: Submet
Transaction [A5: Cancel
Transaction].
7.The system will send the
16: Display "Please insert PASSBOOK to PASSBOOK Printer" message
transaction to Host.
8.The system will receive Host
17: Insert Passbook
reply and automatically the
system will ask for a Voucher
18: Submet Inserted Passbook
printing by send "Please insert
PASSBOOK to PASSBOOK
19: Print Passbook
Printer" message to the Teller.
9.The system will update EJ.
20: update EJ
10.The use case ends when the
"Passbook Maintenance" screen
is unloaded.
7. MAITAI PASSBOOK
BASIC FLOW
SBS Project System Requirements Specification (SRS)
: PMB Teller : TransactionFrm : MaintainFrm : SBSManager : MaintainMngr : Host
Appendix B
B - 67
SBS Project System Requirements Specification (SRS)
Appendix B - 69: Alternative Flow 1 - Change Posting Line
1.Teller selects
"Passbook Maintenance"
under "Transaction
: MaintainFrm
: SBSManager
: TransactionFrm
: PMB Teller
Module" menu and
chooses "Change
1: chooses "Change Posting Line"
Posting Line". The
"Change Posting Line"
2: Submet
screen will display.
2.Teller key in "Account
Number", "Previous",
use case continues at
3: Load "Change Posting Line" screen
"New" and then click
step
no
5
in
Basic
Flow
"OK" button.
3.The use case
continues at step no 4 in 4: Enter Customers' "Account Number", Posting Info and click "OK"
Basic Flow.
ALTERATIVE FLOWS
© HeiTech Padu Berhad
B - 68
Appendix B
Appendix B - 70: Alternative Flow 2 - Change Passbook Status To ew
1.Teller selects "Passbook
: MaintainFrm
Maintenance" under
: SBSManager
: TransactionFrm
: PMB Teller
"Transaction Module" menu
and chooses "Change
1: chooses "Change Passbook Status To New"
Passbook Status To New".
The "Change Passbook
2: Submet
Status To New" screen will
display.
2.Teller key in "Account
3: Load "Change Passbook Status To New" screen
Number" and "Passbook
Number"
3.Teller selects "Condition of
4: Enter Customers' "Account Number" and "Passbook Number"
Sign" whether it "Solely to
Sign", "Either One to Sign" or
"All to Sign", and then click
5: selects "Condition of Sign" and clicks "OK"
"OK" button.
4.The use case continues at
use case continues at
step no 4 in Basic Flow.
step no 5 in Basic Flow
SBS Project System Requirements Specification (SRS)
© HeiTech Padu Berhad
B - 69
Appendix B
: MaintainFrm
: SBSManager
: CommissionFrm
2: Form Load
6: Display Commission Amount
8: click "OK" button
9: Form Unload
7: keeps commission accumulated by Teller in Teller Table file.
[C2: Commission
Amount Status].
5: calculates "Commission Amount"
4: Submet
3: chooses the technique that the Customer will use to pay the commissio
[E1: Receive Error
From The Host].
1: account number is not within the clearing code
: PMB Teller
Appendix B - 71: Alternative Flow 3 - Calculate Commission
1.If account number is not
within the clearing code, the
system will pop up
"Commission" screen. [E1:
Receive Error From The
Host].
2.The Teller chooses the
technique that the Customer
will use to pay the
commission whether by
paying "Cash" or "deduct"
from the cash amount that
the Customer provides for
Deposit/Payment purpose.
3.The system calculates
"Commission Amount" and
display to the Teller [C2:
Commission Amount Status].
4.The system keeps
commission accumulated by
Teller in Teller Table file.
5.The Teller collects
Commission Amount from the
Customer.
6.The Teller click "OK"
button, the "Commission"
screen is unloaded.
7.The use case continues.
SBS Project System Requirements Specification (SRS)
© HeiTech Padu Berhad
B - 70
Appendix B
SBS Project System Requirements Specification (SRS)
© HeiTech Padu Berhad
3: Load New Form
2: Submet
: MaintainMngr
4: Enter Same value as Previous Values
1: Prees "Repeat" Button
: MaintainFrm
Appendix B - 72: Alternative Flow 4 - Repeat Transaction
1.Teller clicks
"Repeat" button.
2.System display
new screen and
enters same
values as
previous values.
3.Teller can
perform this
action by
press"F9".
: PMB Teller
B - 71
Appendix B
Appendix B - 73: Alternative Flow 5 - Cancel Transaction
3: Unload Form
1.Teller clicks
"Cancel"
button.
2.System
cancels current
transaction and
display main
transaction
screen.
: TransactionFrm
4: Load Form
: MaintainMngr
2: Submet
: MaintainFrm
1: Prees "Cancel" Button
: PMB Teller
SBS Project System Requirements Specification (SRS)
© HeiTech Padu Berhad
B - 72
Appendix B
SBS Project System Requirements Specification (SRS)
Appendix B - 74: Exception Flow 1 - Receive Error From The Host
Commission] Alternative Flow.
1.If account number is not within
the clearing code and the system
receives error message from the
:
TransactionFrm
: CommissionFrm Host, the Teller has to do
: SBSManager
: PMB Teller
commission manually.
1: selects "Commission" under "Others" folder
2.Teller selects "Commission"
under "Others" folder in transaction
module menu. "Commission"
2: Submet
screen will be displayed.
3.Use case continues at step no 2
3: Form Load
in [A3: Calculate Commission]
Use case continues at step no
Alternative
Flow.
2 in [A3: Calculate
EXCEPTIO FLOWS
© HeiTech Padu Berhad
B - 73
Appendix B
SBS Project System Requirements Specification (SRS)
1.The system requests
supervisor Override by showing
"Override" dialog box to the
Teller.
2.The Teller has the options to
perform "Local" Override,
"Remote" Override or "Cancel"
the Override.
3.The Teller selects "Local"
option [A1: Remote Override],
then the system will displays
"Local Override" dialog box.
4.Officer needs to go to the
Teller PC and checks all the
information.
5.The Officer can approve the
transaction by enter "User ID"
and "Password" and clicks
"OK" button. [A2: Cancel Local
Override].
6.The system verifies "User ID"
and "Password" and if they are
correct, the Teller can proceed
with transaction. [E1: Invalid
"User ID" or "Password"].
7.The use case ends when
Override screen is unloaded.
BASIC FLOW
8. REQUIRE OVERRIDE
© HeiTech Padu Berhad
Appendix B - 75: Basic Flow - Require Override
10: Local Override Approved
9: Unload Form
8: verifies "User ID" and "Password"
7: Submet
[E1: Invalid "User
ID" or "Password"]
5: displays "Local Override" dialog box
4: "Local" is Pressed
: SBSManager
1: Require Override
: OverrideMngr
2: Show Override Dialog Box
: OverrideFrm
3: Select "Local" Override
[A1: Remote
Override]
: PMB Teller
6: Enter "User ID" , "Password" and Clicks "OK"
[A2: Cancel
Local Override]
: PMB Officer
B - 74
Appendix B
SBS Project System Requirements Specification (SRS)
Remote Override is done at PMB
Officer's workstation. An Override
server will be automatically running
at each supervisor's workstation
during PC startup.
1.The Teller selects "Remote"
option, then the system will displays
"Supervisor List" dialog box.
2.Teller should select one of the
supervisors from the list and click
"OK" button.
3.The system sends all the
transaction information on the
Teller's screen to the selected
Officer's workstation.
4.On Officer's workstation, the
system will display list of request
from Teller.
5.The supervisor can clicks
"Refresh" button to see any new
request, "Exit" to close the dialog
box or press "F10" key to fetch back
the list.
6.If the supervisor doesn't response
to the Override, then the Override will
be timeout. [E2: Override Time Out].
7.Officer performs the Override by
select which Teller he wants to
Override, then the system will
display "Remote Override Screen
Viewer".
8.Officer must check the information
that he receive with the Override.
9.The Officer has the options to
"Approve", "Reject" or "Return" the
Teller transaction.
10.The Officer can approve [A3:
Reject Remote Override], [A4:
Return Remote Override] the
transaction by clicks "Approve" and
enters "Supervisor ID" and
"Password".
11.The system verifies "Supervisor
ID" and "Password" and if they are
correct, the transaction will proceed
and "Remote Override Screen
Viewer" will disappear. [E1: Invalid
"User ID" or "Password"]
12.The use case ends
ALTERATIVE FLOWS
© HeiTech Padu Berhad
: OverrideFrm
: OverrideMngr
3: Displays "Supervisor List" dialog box
2: "Remote" is Pressed
1: Select "Remote" Override
: PMB Teller
13: Submet
[E1: Invalid "User
ID" or "Password"]
Appendix B - 76: Alternative Flow 1 - Remote Override
20: Remote Override Approved
19: Unload Form
18: verifies "User ID" and "Password"
17: Submet
16: Enter "Supervisor ID" , "Password" and Clicks "OK"
15: clicks "Approve"
[A3: Reject Remote
Override], [A4: Return
Remote Override]
12: Select Teller
11: Display List of Request From Teller.
10: Search for Any New Request
9: Refresh
7: Display List of Request From Teller.
14: Display "Remote Override Screen Viewer"
8: Click "Refresh"
[E2: Override
Time Out]
: SBSManager
6: Sends All Transaction Info to the Selected Officer's Workstation.
5: Submet
4: Select One of Supervisors and Click "OK" Button.
: PMB Officer
B - 75
Appendix B
1.The Officer
can cancel
the
transaction
by clicks
"Cancel"
button.
2.The
System
cancels the
transaction.
3.The use
case ends.
SBS Project System Requirements Specification (SRS)
© HeiTech Padu Berhad
: OverrideMngr
: SBSManager
Appendix B - 77: Alternative Flow 2 - Cancel Local Override
4: Remote Override Canceled
3: Unload Form
2: Submet
: OverrideFrm
1: clicks "Cancel"
: PMB Officer
B - 76
Appendix B
SBS Project System Requirements Specification (SRS)
1.The Officer can reject
the transaction by clicks
"Reject" in "Remote
Override Screen Viewer"
2.The system disappear
"Remote Override
Screen Viewer" and
transaction done by
Teller will be rejected.
3.The system sends
and displays "Supervisor
CANCEL Remote
Override!" message in
Tellers' workstation.
4.The Teller should click
"OK" button on the
message box and the
transaction screen will
be closed.
5.The use case ends.
© HeiTech Padu Berhad
: OverrideMngr
2: Submet
: OverrideFrm
: SBSManager
4: Click "OK"
8: Unload Transaction Screen
7: Remote Override Rejected
6: Unload Form
5: Submet
3: Displays "Supervisor CANCEL Remote Override!" Message in Tellers' Workstation
1: clicks "Reject"
: PMB Teller
Appendix B - 78: Alternative Flow 3 - Reject Remote Override
: PMB Officer
B - 77
Appendix B
SBS Project System Requirements Specification (SRS)
1.The Officer can return the
transaction by clicks "Return"
in "Remote Override Screen
Viewer", and then a reply
message box will appear
asking the Officer to enter the
reason for return the
transaction.
2.The Officer must enter
message and click "OK" button
or he can cancel by click
"Cancel" button.
3.The system sends and
displays the Officer return
message on Tellers'
workstation.
4.The Teller will see the return
message in transaction screen,
he can do the correction again
and re-submit the transaction
and the system will request for
Override again.
5.The use case ends.
© HeiTech Padu Berhad
: OverrideMngr
2: Submet
: OverrideFrm
3: Enter the Reason for Return the Transaction
1: clicks "Return"
: PMB Teller
: SBSManager
9: Remote Override Returned
8: Unload Form
7: Submet
Appendix B - 79: Alternative Flow 4 - Return Remote Override
6: Click "OK"
5: Displays the Officer Return Message on Tellers' Workstation
4: Enter Reply Message and Click "OK"
: PMB Officer
B - 78
Appendix B
Appendix B - 80: Exception Flow 1 - Invalid “User ID” or “Password”
1.If "User ID" and
: PMB Officer
: OverrideMngr "Password" is
: OverrideFrm
invalid, a error
1: Display Error Message
message will appear
2.The Officer should
2: Click "OK"
clicks "OK" button
on the error
3: Renter the Correct "User ID" and "Password".
message and renter
the correct "User ID"
Use Case
and "Password".
Continues
SBS Project System Requirements Specification (SRS)
EXCEPTIO FLOWS
© HeiTech Padu Berhad
B - 79
Appendix B
: OverrideMngr
: SBSManager
1: Remove the Expired Requests From the Queue
: OverrideFrm
[C1: Override
Response Time]
5: Requisted Override Time Out
4: Submet
Start Require Override
Use Case
3: Clicks "OK" Button
2: Displays "Time OUT !!, Please CHOOSE another Supervisor" Messag
: PMB Teller
Appendix B - 81: Exception Flow 2 - Override Time Out
1.If the Override times is
out [C1: Override
Response Time], the
system the system
remove the expired
requests from the queue
and displays "Time OUT
!!, Please CHOOSE
another Supervisor"
message on Teller's
workstation.
2.The Teller clicks "OK"
button and the message
box will disappear.
3.The system will ask for
Override again.
SBS Project System Requirements Specification (SRS)
© HeiTech Padu Berhad
B - 80
Appendix B
SBS Project System Requirements Specification (SRS)
Appendix B - 82: Basic Flow - Sign In
1.This use case begins
when the Mediator open
the SBS system. Sign In
: PMB Mediator
: SignInMngr
: SBSManager : Database
: SignInFrm : StartOfDayFrm
: SBSFrm
screen will be displayed.
2.The Mediator enters
1: Load Sign In Form
"UserID" and "Password"
and clicks "Sign In"
2: Load Form
button.
3.The system will verify
3: Enters "UserID" and "Password"
the "UserID" and
"Password". [E1: Invalid
4: Clicks "Sign In" Button.
Login], [E2: User Already
[E1: Invalid Login], [E2:
Signed In].
User Already Signed In]
5: Submet
4.The system check in
database for the role of
6: Verify the "UserID" and "Password"
the logged in UserID.
5.If UserID entered is a
Manager ID and Start of
7: Submet SQL
Day has not been done, a
"Start of Day" screen will
8: Execute SQL
be displayed [E3: Start of
Day Has Not Been
9: Submet User Info
Performed]. Manager
clicks "OK" to perform
[E3: Start of Day Has
10: Set User Info
Start of Day.
Not Been Performed]
6.System will display
11: Check for the Role for the Logged in User
"Shared Banking
Services" screen.
7.Mediator makes
12: Load Form
selection to change his
password. [A1: Change
13: Click "OK"
Password].
8.Mediator can log out or
14: Start Of Day Done
exit from the system. .
[A2: Log Out], [A3: Exit].
15: Submet Start Of Day Done
9.At any time, system
can sign the current user
16: Update EJ and Branch Status
out [A4: Auto Sign Out].
10.Upon successful
signed in, system will
17: Send Data
[A1: Change Password],
send data to Host, update
[A2: Log Out], [A3: Exit],
EJ and branch status.
18: Form Load
[A4: Auto Sign Out]
11.The use case ends.
BASIC FLOW
9. SIG I
© HeiTech Padu Berhad
: Host
B - 81
Appendix B
SBS Project System Requirements Specification (SRS)
Appendix B - 83: Alternative Flow 1 - Change Password
1.This alternative flow will only
happen if password expired,
auto-sign out occurred, new
: PMB Mediator
: SignInMngr : SBSManager
: SBSFrm
: Database
password created or password
reset. [C3: Password Expiry].
1: Display "Change Password" Screen
2.System will ask Mediator to
change his password by
2: Changes the Password and Save the Data.
displaying the "Change
Password" screen.
3: Submet New Password
3.Mediator makes changes to
the password and save the
4: Check New Password
data.
4.The system will check and
save the new password in the
5: Update Password in Database
database. [E4: Invalid New
Password].
6: Execute SQL
[E4: Invalid New
5.The use case continues.
Password]
ALTERATIVE FLOWS
© HeiTech Padu Berhad
B - 82
Appendix B
SBS Project System Requirements Specification (SRS)
© HeiTech Padu Berhad
: SBSFrm
: SignInMngr
3: Unload Form
1.Mediator
selects
"Exit".
2.The Shared
Banking
Services
system will
exit
completely.
3.The use
case ends
: SBSFrm
: SignInMngr
Appendix B - 85: Alternative Flow 3 – Exit
3: Unload Form
2: Submet"Exit" is Pressed
1: Selects "Exit"
: PMB Mediator
: SignInFrm
4: Load Form
2: Submet"Log out" is Pressed
1: Selects "Log out"
: PMB Mediator
Appendix B - 84: Alternative Flow 2 - Log Out
1.Mediator
selects "Log
out".
2.The "Shared
Banking
Services"
screen will be
unloaded.
3.System
shows "Sign
In" screen.
4.The use
case ends.
B - 83
Appendix B
: SignInMngr
: SignInFrm
2: Unload Form
3: Load Form
[C2: Idle
Time]
1: Detect Idle/No Active Application
: SBSFrm
Appendix B - 86: Alternative Flow 4 -Auto Sign Out
1.If system detected
that there is idle or
no active application
[C2: Idle Time], then
it will sign the
current Mediator
out.
2.Mediator will see
the "Sign In" screen.
3.Use case
continues.
SBS Project System Requirements Specification (SRS)
© HeiTech Padu Berhad
B - 84
Appendix B
SBS Project System Requirements Specification (SRS)
EXCEPTIO FLOWS
© HeiTech Padu Berhad
1: Dedect Error
: SignInMngr
Use Case Continues
At Basic Flow No 3
2: Display an Error Message
: SignInFrm
Appendix B - 87: Exception Flow 1 - Invalid Login
1.If branch code and
"UserID" not exist, the
system will show an error
message.
2.Mediator enters a wrong
password or did not enter
a password. The system
will show an error
message
3.The use case continues.
B - 85
Appendix B
Appendix B - 88: Exception Flow 2 - User Already Signed In
1.If user is already signed
: SignInMngr
: SignInFrm
in, the system will show
"User Already Signed In"
1: Display "User Already Sign In" Message
message.
2.Use case extende to
2: Force User Sign Off
Manage User Profile Use
Case to perform Force
User Sign Off.
3: Allow User To Sign In
3.Then the system will
allow the Mediator to Sign
extende to Manage
In again.
4: Form Load
User Profile Use Case
SBS Project System Requirements Specification (SRS)
© HeiTech Padu Berhad
B - 86
Appendix B
SBS Project System Requirements Specification (SRS)
© HeiTech Padu Berhad
Appendix B - 89: Exception Flow 3 - Start of Day Has ot Been Performed
Use Case Continues
At Basic Flow No 3
: SignInMngr
1.If Start of Day has not
been performed and
UserID entered is Teller
1: Display an Error Message
ID or Officer ID, then the
system will show error
2: Sign In Fail message. [C1: Start of
[C1: Start of Day
Day Conditions].
Conditions]
2.Use case continues.
: SignInFrm
B - 87
Appendix B
SBS Project System Requirements Specification (SRS)
© HeiTech Padu Berhad
: SignInMngr
2: Change New Password Fail
1: Display an Error Message
: SBSFrm
Appendix B - 90: Exception Flow 4 - Invalid ew Password
3: Unload "Change New Password" Screen
1.An error
message will
be displayed.
2.Change new
password fail.
3.Use case
ends.
B - 88
Appendix B
SBS Project System Requirements Specification (SRS)
1.This use case begins when a
Manager selects "User Profile" in
"Shared Banking Service" screen.
2.Manager makes selection to add
new user, modify user, force user
sign off, unlock, revoke, unrevoked or
reset password of users.
3.Manager selects "Add" under "User
Profile" folder to add new user. "Add
New User" screen will display. [A1:
Modify User], [A2: List Users], [A3:
Force User Sign Off], [A4: Unlock
User], [A5: Revoke/Unrevoke User],
[A6: Reset Password].
4.Manager selects "User Role" and
inserts "User ID". Manager fills in
"User Information" and clicks "OK"
button.
5.Upon successful Manager add
user, system shows "Record
successfully created." message.
6.At any screen, Manager can close
screen and cancel the process. [A7:
"Cancel" Pressed].
7.The system will save the data in
database.
8.The use case ends.
BASIC FLOW
10. MAAGE USER PROFILE
© HeiTech Padu Berhad
: SBSFrm
5: Load "Add New User" Screen
10: Shows Successful Message
9: Execute SQL
8: Save Data in Database
7: Add User
Appendix B - 91: Basic Flow - Manage User Profile
: SBSManager : Database
4: Requist Add New User Screen
3: "Add" is Pressed
: UserProfFrm : UserProfMngr
6: Fills in "User Information" and Clicks "OK" Button
[A1: Modify User], [A2: List
Users], [A3: Force User Sign
Off], [A4: Unlock User], [A5:
Revoke/Unrevoke User], [A6:
Reset Password].
2: Selects "Add"
1: Select "User Profile"
: PMB Manager
B - 89
Appendix B
SBS Project System Requirements Specification (SRS)
1.Manager selects "Modify"
under "User Profile" folder to
modify user role. "Modify User"
screen will display.
2.Manager selects "User ID".
System displays all user
information on the screen and
the current user role will be
checked.
3.If Manager wants to change
the user's role, uncheck the
current user role and check the
new role.
4.Manager Fill in the required
information and clicks "OK"
button.
5.Upon successful Manager
modify user, system displays
"Record Successfully Updates"
message.
6.After modification done, the
system will ask User to change
password during next Sign In.
7.Use case continues at step
no 6 in Basic Flow.
ALTERATIVE FLOWS
© HeiTech Padu Berhad
: SBSFrm
: UserProfMngr
: SBSManager : Database
10: Modify User
9: Fills in Required Information and Clicks "OK" Button
8: Execute SQL
Use Case Continues
At Basic Flow No 8
7: Get User Info
6: Submet Selectd "User ID"
4: Load "Modify User" Screen
3: Requist Modify User Screen
2: "Modify" is Pressed
: UserProfFrm
5: selects "User ID"
1: Selects "Modify"
: PMB Manager
B - 90
Appendix B
1.Manager selects
"User List" under
"User Profile" folder
to show all PMB
branch users. "User
List" screen will
display.
2.System will to list
all the users of the
PMB Branch and
their sign-on status.
3.Manager can
clicks "Print" button
to print the list.
4.Use case
continues at step no
6 in Basic Flow.
: SBSManager
9: Print User List
8: Submet "Print" is Pressed
: Database
6: Execute SQL
5: Get All PMB Branch User s
4: Load "User List Screen
3: Requist User List Screen
2: "User List" is Pressed
: UserProfFrm : UserProfMngr
Appendix B - 93: Alternative Flow 2 - List Users
7: selects "Print"
1: Selects "User List"
: SBSFrm
Appendix B - 92: Alternative Flow 1 - Modify User
: PMB Manager
SBS Project System Requirements Specification (SRS)
© HeiTech Padu Berhad
B - 91
Appendix B
SBS Project System Requirements Specification (SRS)
1.This alternative use if
Teller accidentally logged
out (unusually terminated)
eg: pc reboot suddenly,
Manager can perform force
user sign off to allow the
Teller to Sign In again.
2.Manager selects "Force
User Sign Off" under "User
Profile" folder. "Force User
Sign Off" dialog will display.
Manager inserts "User ID"
and clicks "OK" button.
3.Upon successfully
signing off the user, system
displays "User successfully
signed off" message.
4.Use case continues at
step no 6 in Basic Flow.
© HeiTech Padu Berhad
: SBSFrm
: UserProfMngr
4: Load "Force User Sign Off" Dialog Box
7: Force Selected User Sign Off
6: Submet Selectd "User ID"
Appendix B - 94: Alternative Flow 3 - Force User Sign Off
Use Case Continues
At Basic Flow No 8
: SBSManager
3: Requist Force User Sign Off Screen
2: "Force User Sign Off" is Pressed
: UserProfFrm
5: selects "User ID" and Click "OK"
1: Selects "Force User Sign Off"
: PMB Manager
B - 92
Appendix B
1.This alternative use if
one of users locked due
to 3 failed attempts Sign
In.
2.Manager selects
"Unlock User" under
"User Profile" folder.
"Unlock User" dialog will
display. Manager inserts
"User ID" and clicks
"OK" button.
3.Upon successfully
unlocking the user,
system displays "User
successfully unlocked"
message.
4.Use case continues at
step no 6 in Basic Flow.
SBS Project System Requirements Specification (SRS)
© HeiTech Padu Berhad
: SBSFrm
: UserProfMngr
4: Load "Unlock User" Dialog Box
7: Unlock Inserted User
6: Submet Inserted "User ID"
Appendix B - 95: Alternative Flow 4 - Unlock User
Use Case Continues
At Basic Flow No 8
: SBSManager
3: Requist Unlock User Screen
2: "Unlock User" is Pressed
: UserProfFrm
5: insert "User ID" and Click "OK"
1: Selects "Unlock User"
: PMB Manager
B - 93
Appendix B
: SBSFrm
: UserProfMngr
: SBSManager
3: Requist Revoke/Unrevoke User Screen
2: "Revoke/Unrevoke" is Pressed
: UserProfFrm
Use Case Continues
At Basic Flow No 8
7: Revoke/Unrevoke User
6: Submet Inserted "User ID"
5: Inserts "User ID" and Click "OK"
4: Load "Revoke/Unrevoke User " Dialog Box
1: Selects "Revoke/Unrevoke"
: PMB Manager
Appendix B - 96: Alternative Flow 5 - Revoke/Unrevoke User
1.Manager selects
"Revoke/Unrevoke" under
"User Profile" folder.
"Revoke/Unrevoke User"
dialog will display.
2.Manager inserts "User ID"
and clicks "OK" button.
3.If the inserted User ID
belongs to a revoked user, the
user's status will be updated
to N - Not Sign On. Else if the
inserted User ID belongs to a
normal user, the user's status
will be updated to R Revoked.
4.Upon successfully
revoke/unrevoke the user,
system shows a message.
5.Use case continues at step
no 6 in Basic Flow.
SBS Project System Requirements Specification (SRS)
© HeiTech Padu Berhad
B - 94
Appendix B
SBS Project System Requirements Specification (SRS)
1.This alternative flow use
to reset user password
response to user request
in case the user forgotten
his password.
2.Manager selects "Reset
Password" under "User
Profile" folder. "Rest
Password" screen will
display.
3.Manager selects "User
ID" and system shows
"User Name". Manager
fills in the new password
and clicks "OK".
4.Upon successful
resetting the password,
"Password successfully
reset." message will be
shown.
5.After resetting password
done, the system will ask
the user to change
password during next Sign
In.
6.Use case continues at
step no 6 in Basic Flow.
© HeiTech Padu Berhad
: SBSFrm
: UserProfMngr
4: Load "Reset Password" Screen
9: Show "User Name"
12: Reset Password
Appendix B - 97: Alternative Flow 6 - Reset Password
Use Case Continues
At Basic Flow No 8
11: Submet New Password
: Database
8: Execute SQL
7: Get Selected User Info
6: Submet Selectd "User ID"
10: Fills in the New Password and Clicks "OK"
: SBSManager
3: Requist Reset Password Screen
2: "Reset Password" is Pressed
: UserProfFrm
5: selects "User ID" and Click "OK"
1: Selects "Reset Password"
: PMB Manager
B - 95
Appendix B
1.Manager
clicks "Cancel"
button.
2.System
cancels current
process and
display Shared
Banking Service
screen.
SBS Project System Requirements Specification (SRS)
© HeiTech Padu Berhad
: SBSFrm
: UserProfMngr : SBSManager
5: Load Form
4: Load SBS Form
3: Unload Form
2: Submet "Cancel" is Pressed
: UserProfFrm
Appendix B - 98: Alternative Flow 7 - "Cancel" Pressed
1: Click "Cancel"
: PMB Manager
B - 96
Appendix B
1: Select "End Of Day"
2: Choose "Teller Total"
© HeiTech Padu Berhad
: EndOfDayFrm : EndOfDayMngr : SBSManager : Host
: PMB Teller : SBSFrm
11. PERFORM ED OF DAY
BASIC FLOW
SBS Project System Requirements Specification (SRS)
Appendix B - 99: Basic Flow - Perform End Of Day
1.This use case
begins when a Teller
expands "End of
Day" folder on Shared
Banking Services.
There are two folders
under End of Day
which are "Balancing"
and "Reporting".
2.Teller can make
options of the
following:
a.Select "Teller Total"
under "Balancing"
folder to perform and
print Teller total ,
b.select "Branch
Total" under
"Balancing" folder to
perform and print
Branch total,
c.select "Final
Branch Total" under
"Balancing" folder to
perform and print final
Branch total
[A1:Require
Override], [E1:
Transaction Needs
After Final Branch
Total],
d.select "Teller
Activity Report" under
"Report" folder to
perform and print
Teller activity report,
e.or select "Branch
Activity Report" under
"Report" folder to
perform and print
Branch activity report.
3.System request
required data from
Host.
4.System asks Teller
to insert paper for
printing.
5.At any screen,
Teller can close
screen and cancel
the process. [A3:
"Cancel" Pressed].
6.Use case ends.
3: Request Teller Total
4: Get Teller Total
5: Choose "Branch Total"
6: Request Branch Total
7: Get Branch Total
8: Choose "Final Branch Total"
9: Request Final Branch Total
[A1:Require Override],
[E1: Transaction Needs
After Final Branch Total],
10: Get Final Branch Total
11: Choose "Teller Activity Report"
12: Request Teller Activity Report
13: Get Teller Activity Report
14: Choose "Branch Activity Report"
15: Request Branch Activity Report
16: Get Branch Activity Report
The Flow From 17 To 22
Will Usually Happent After
Flows No:4,7,10,13 and 16
17: Request Required Data
18: Return Data
19: Display Required Data
20: Press "Print"
21: Ask To Insert Paper
22: Print Report
Appendix B
B - 97
SBS Project System Requirements Specification (SRS)
© HeiTech Padu Berhad
B - 98
Appendix B
1: Require Override
: EndOfDayMngr
: SBSManager
1.System Require
Override by extend
to Require Override
Use Case.
2.If Officer
approves the
Override, then use
case continues at
step no 3 in Basic
Flow.
Appendix B - 100: Alternative Flow 1 - Require Override
Use Case Continues At
Step No 17 in Basi Flow
3: The Override Approved
extend to Require
Override Use Case 2: Extend To Require Override
SBS Project System Requirements Specification (SRS)
ALTERATIVE FLOWS
© HeiTech Padu Berhad
B - 99
Appendix B
Appendix B - 101: Alternative Flow 2 - Reactivate Online Posting
1.This alternative allows
Manager to restart the
: EndOfDayMngr
: SBSFrm
system if a transaction
: PMB Manager
needs to be performed
1: Select "Manager Function"
after Final Branch Total
is done.
2: Choose "Reactivate Online Posting"
2.Manager expand
"Manager Function"
folder on Shared Banking
3: "Reactivate Online Posting" is Pressed
Services and clicks
"Reactivate Online
4: Reactivate Online Posting
Posting" to reactivate.
3.Use case ends.
SBS Project System Requirements Specification (SRS)
© HeiTech Padu Berhad
B - 100
Appendix B
1.Manager
clicks "Cancel"
button.
2.System
cancels current
process and
display Shared
Banking
Service screen.
SBS Project System Requirements Specification (SRS)
© HeiTech Padu Berhad
: SBSFrm
5: Load Form
3: Unload Form
4: Load SBS Form
2: Submet "Cancel" is Pressed
: EndOfDayFrm : EndOfDayMngr : SBSManager
Appendix B - 102: Alternative Flow 3 - "Cancel" Pressed
1: Click "Cancel"
: PMB Manager
B - 101
Appendix B
1.If a transaction
needs to be performed
after final branch total
has been initiated
unless authorized by
manager. [A2:
Reactivate Online
Posting], [C1: Final
Branch Total Done].
: EndOfDayMngr
[A2: Reactivate Online
Posting], [C1: Final
Branch Total Done].
2: Is Branch Total Initiated
1: Transaction Need
: TransactionFrm
Appendix B - 103: Exception Flow 1 - Transaction eeds After Final Branch Total
SBS Project System Requirements Specification (SRS)
EXCEPTIO FLOWS
© HeiTech Padu Berhad
B - 102
Appendix B
SBS Project System Requirements Specification (SRS)
1.This use case begins
when a Mediator expands
"Stock Control Register"
folder on Shared Banking
Services.
2.Manager or Officer clicks
"Add Stock" under "Stock
Control" folder to add
stock. "Add Stock" screen
will be displayed. [A1:
Distribute Stock], [A2:
Register Damaged/Lost
Stock], [A3: Stock Control
Register].
3.Manager or Officer
Selects "Stock Type", fills
in "First Serial Number"
and "Last Serial Number".
4.System calculates and
displays total number of
Stock based on Serial No.
5.Manager or Officer clicks
"OK". System adds Stock
and shows "Stock
successfully added"
messages. [C1: Number of
Created Record].
6.At any screen, Mediator
can close screen and
cancel the process. [A6:
"Cancel" Pressed].
7.System will save data in
database.
8.Use case ends when
"Stock Control Register"
closed.
: SBSFrm
: SBSManager
5: Load Add Stock Screen
4: Display Add Stock Screen
13: Save Data
12: Add Stock
11: Submet Stock Info
9: Display Total Number of Stock
: Database
14: Execute SQL
8: Calculates Total Number of Stock
7: Submet Sreial Nos
Appendix B - 104: Basic Flow - Stock Control Register
[A6: "Cancel"
Pressed].
10: Click "OK"
: StockCntrlMngr
3: "Add Stock" is Pressed
: StockCntrlFrm
6: Selects "Stock Type", fills in Serial Numbers
[A1: Distribute Stock], [A2:
Register Damaged/Lost
Stock], [A3: Stock Control
Register].
2: Choose "Add Stock"
1: Select "Stock Control Register"
: PMB Mediator
STOCK CONTROL REGISTER
BASIC FLOW
12.
© HeiTech Padu Berhad
B - 103
Appendix B
SBS Project System Requirements Specification (SRS)
: SBSFrm
3: Display Stock Distribution Screen
11: Displays Acknowledgement Message in Teller PC
[A4: View Stock
Acknowledgement].
Use Case Continues in Step
No 10 in Basic Flow
7: Show List of Registed Stock Info
: Database
6: Execute SQL
5: Get All Registed Stock Info
4: Load Stock Distribution Screen
9: Tick on the Stock
10: Click "OK"
: StockCntrlMngr : SBSManager
2: "Stock Distribution" is Pressed
: StockCntrlFrm
8: Selects Teller "User ID"
[C2: Number Of Distributed
Stock To Teller]
1: Choose "Stock Distribution"
: PMB Mediator
Appendix B - 105: Alternative Flow 1 - Distribute Stock
1.This alternative flow is for the Manager or Officer
to distribute stock to a Teller.
2.Manager or Officer clicks "Stock Distribution"
under "Stock Control" folder in Shared Banking
Service screen.
3.System displays "Stock Distribution" screen that
contains list of all registered stocks, including the
serial number and total number of the stock.
4.Select Teller "User ID" whom the stock will be
distributed to.
5.Tick on the stock which to be distributed to that
Teller in "List of Stock" section. [C2: Number Of
Distributed Stock To Teller]
6.The selected Stock will be listed in the
"Distribution List" section.
7.If the Stock to be given isn't in full amount,
change the "Last Serial Number". System
calculates total number of Stock according to the
serial number.
8.To complete Stock distribution, clicks "OK"
button. System will update Stock records and
displays "Record Successfully updated".
9.Teller will get an acknowledgement receipt upon
successful stock distribution. System displays
"New Stock has been distributed. Please go to
View Acknowledgement under Stock Control
Module." message in Teller PC. [A4: View Stock
Acknowledgement].
10.Use case continues at step no 6 in Basic Flow.
ALTERATIVE FLOWS
© HeiTech Padu Berhad
B - 104
Appendix B
SBS Project System Requirements Specification (SRS)
Appendix B - 106: Alternative Flow 2 - Register Damaged/Lost Stock
B - 105
Appendix B
1.This alternative flow is for
Mediator (which can be Manager,
Officer or Teller) to record
: PMB Mediator : SBSFrm : StockCntrlFrm : StockCntrlMngr : SBSManager
damaged/lost Stock.
2.Mediator clicks "Damaged/Lost
1: Choose "Damaged/Lost Stock Register"
Stock Register" under "Stock
Control" folder in Shared Banking
Service screen. "Damaged/Lost
Stock Register" screen will be
2: "Damaged/Lost Stock Register" is Pressed
displayed.
3.Mediator selects "Stock Type",
3: Display Damaged/Lost Stock Register Screen
fills in the "First Serial Number"
and "Last Serial Number" of the
4: Load Damaged/Lost Stock Register Screen
damaged /lost Stock.
4.System calculates and displays
5: Selects "Stock Type", fills in Serial Numbers
total number of Stock based on
Serial No.
6: Submet Sreial Nos
5.Selects "Reason" of registering
the stock, whether it is damaged
Use Case Continues in Step
7: Calculates Total Number of Stock
or lost and clicks "OK" button.
No 10 in Basic Flow
6.System updates Stock and
shows "Stock successfully
8: Display Total Number of Stock
updated" message.
7.Use case continues at step no 6
9: Selects "Reason" and Click "OK"
in Basic Flow.
© HeiTech Padu Berhad
1.This alternative flow
uses by Manager/Officer
to show the registered
Stock control.
2.Clicks "Stock Control
Register" under "Stock
Control" folder in Shared
Banking Service screen.
"Stock Control Register"
screen will be displayed.
3.Selects "Month" of
which the Stock control
register is to be displayed
and "Stock Type".
4.System displays record
for selected stock of the
selected month in both
"Supervisor" and "Teller"
sections. [C4: Time For
Keeping Record].
5.In "Supervisor" section,
record will be displayed
sorted by Date.
6.In "Teller" section,
record will be displayed
sorted by User ID.
7.Clicks "Print" button to
print the report.
8.Use case continues at
step no 6 in Basic Flow.
SBS Project System Requirements Specification (SRS)
© HeiTech Padu Berhad
: SBSFrm
: StockCntrlFrm
: StockCntrlMngr
4: Load Stock Control Register Screen
8: Execute SQL
Appendix B - 107: Alternative Flow 3 - Stock Control Register
12: Print Report
11: "Print" is Pressed
9: Display Records for Selected Stock of the Selected Month
10: Click "Print"
: Database
7: Get Record for Selected Stock of the Selected Month
6: Submet Selected Stock,Selected Month
5: Selects "Stock Type", "Month"
: SBSManager
3: Display Stock Control Register Screen
2: "Stock Control Register" is Pressed
1: Choose "Stock Control Register"
: PMB Mediator
B - 106
Appendix B
SBS Project System Requirements Specification (SRS)
Appendix B - 108: Alternative Flow 4 - View Stock Acknowledgement
B - 107
Appendix B
1.This alternative flow will only
used by Teller to alert him that
there is some Stock distributed to
him.
: PMB Teller
: SBSFrm : StockCntrlFrm : StockCntrlMngr
: SBSManager
2.The Teller selects "View Stock
Acknowledgement" under "Stock
1: Choose "View Stock Acknowledgement"
Control" Module. "Stock
Acknowledgement" screen will be
displayed.
2: "View Stock Acknowledgement" is Pressed
3.Teller can accept by clicks
"OK" button or reject any of the
distributed Stock by tick on the
3: Display View Stock Acknowledgement Screen
"Reject" column at the stock that
he would like to reject.
4: Load View Stock Acknowledgement Screen
4.Upon successful stock
acceptance, a message "Stock
5: Click "OK"
successfully accepted" will be
displayed.
6: Submet "OK" Pressed
5.If there is rejected Stock,
Manager/Offices will get an
acknowledgement receipt in his
7: Display "Stock successfully accepted" Message
PC [C3: Supervisor PC Is Off] and
he need to cancel the distributed
8: Tick on the "Reject" Column
[A5: Maintain
stock [A5: Maintain Stock
Stock Distribution]
Distribution]. Manager or Officer
9: Submet Rejected Stock
need to do Stock Distribution
again.
10: Give Acknowledgement Receipt in Manager PC
6.Use case continues at step no
6 in Basic Flow.
© HeiTech Padu Berhad
Appendix B - 109: Alternative Flow 5 - Maintain Stock Distribution
1.This alternative flow is for Manager
or Officer to cancel the distributed
Stock, after acknowledgement
receipt is sent to the Teller or after
: StockCntrlFrm : StockCntrlMngr : SBSManager : Database
: PMB Mediator : SBSFrm
the Teller rejects the distributed
Stock.
1: Choose "Stock Distribution Maintenance"
2.Clicks "Stock Distribution
Maintenance" under "Stock Control"
2: "Stock Distribution Maintenance" is Pressed
folder in Shared Banking Service
screen. "Stock Distribution
Maintenance" screen will be
displayed.
3: Display Stock Distribution Maintenance Screen
3.Selects "Searching Option".
Searching Option can be by "Stock
4: Load Stock Distribution Maintenance Screen
Type", "Date" or "User ID".
4.Clicks "View" button. System
5: Selects "Searching Option" and Click "View"
displays all distributed stocks of
today's date sorted by "Stock Type if
6: Submet Searching Option
none of the searching option.
Otherwise, the record will be
7: Get All distributed Stocks of Today's
displayed according to the searching
option.
8: Execute SQL
5.The status of each Stock will be
displayed in "Status" column.
9: Show List of Distributed Stocks of Today's
6.To cancel the distributed stock,
ticks on "Remove" column at the
10: Selects Teller "User ID"
stock which to be canceled.
7.To complete maintain Stock
11: Tick on "Remove" Column at the Stock and Click "OK"
distribution clicks "OK" button.
System cancels Stock from being
distributed and displays "Stock
12: Submet
successfully cancelled" message will
be shown.
13: Cancel Distributed Stock
8.Use case continues at step no 6 in
Basic Flow.
14: Displays "Stock successfully cancelled" Message
SBS Project System Requirements Specification (SRS)
© HeiTech Padu Berhad
B - 108
Appendix B
1.Manager
clicks "Cancel"
button.
2.System
cancels current
process and
display Shared
Banking Service
screen.
SBS Project System Requirements Specification (SRS)
© HeiTech Padu Berhad
: SBSFrm
: StockCntrlMngr
5: Load Form
3: Unload Form
: SBSManager
4: Load SBS Form
2: Submet "Cancel" is Pressed
: StockCntrlFrm
Appendix B - 110: Alternative Flow 6 - "Cancel" Pressed
1: Click "Cancel"
: PMB Manager
B - 109
Appendix B
SBS Project System Requirements Specification (SRS)
: SBSFrm
: EJViewerMngr
: SBSManager
4: Load EJ Viewer Screen
3: Display EJ ViewerScreen
2: "EJ Viewer" is Pressed
: EJViewerFrm
: Database
10: Display List of Records
9: Execute SQL
8: Get Record Based on Selected Search Criteria
7: Requist Info Based on Selected Search Option
6: Submet Selected Search Option
5: Selects "Search Option" and Clicks "OK"
[A1: View
Forex Rate].
1: Select "EJ Viewer"
: PMB Mediator
Appendix B - 111: Basic Flow - View Electronic Journal And Forex Rate
1.This use case begins when a Mediator
selects "EJ viewer" folder on Shared
Banking Services. "EJ Viewer" screen will
be displayed. [A1: View Forex Rate].
2.System shows current "Date" and give
the Mediator options to perform the search
using "Time", "Account No", "Amount" ,
"Sequence No " , "Transaction Code" or by
select the "Successful" of the financial
transaction that done. But if the signed in
Mediator is Manager or Officer, he also can
do search in EJ using "User ID".
3.When the Mediator choose "Time",
"Account No", "Amount" or "Sequence No
" option, then he has to give more
information about the transaction by edit
"From" and "To" info. But if he choose
"Successful" option, then Mediator can
choose between "Y" and "No" options.
4.The Mediator has to clicks "Search"
button; the system will display list of
records that contains info (i.e. Journal No,
Date, Time, Account No, Amount,
Transaction Mode, etc) associated with
selected search criteria.
5.Use case ends when "EJ Viewer" screen
is unloaded.
BASIC FLOW
13. VIEW ELECTROIC JOURAL AD FOREX RATE
© HeiTech Padu Berhad
B - 110
Appendix B
: FxRateMngr
: SBSManager
13: Execute SQL
11: Update Current Forex Rate
12: Save Data
: Host
10: Require Last Forex Rate
9: Get Last Forex Rate
8: Download Rate
6: Execute SQL
5: Get Last Updated Rate
Appendix B - 112: Alternative Flow 1 - View Forex Rate
7: Selects "Download Rate"
: Database
3: Display MBB Currency Converter Menu Screen
2: "FX Rate" is Pressed
: FxRateFrm
4: Load MBB Currency Converter Menu Screen
: SBSFrm
1: Select "FX Rate"
: PMB Mediator
SBS Project System Requirements Specification (SRS)
1.This alternative
flow begins when a
Mediator selects
"FX Rate" folder on
Shared Banking
Services. "MBB
Currency Converter
Menu" screen will
be displayed.
2.The system will
list the rates of the
last updated date
and time.
3.To download new
rate once again,
click "Download
Rate" button.
4.The system will
inquire the last
Forex rate at Host
and update the
current Forex rate.
5.The system will
save the data in
database.
6.Use case ends
when "MBB
Currency Converter
Menu" screen is
unloaded.
ALTERATIVE FLOWS
© HeiTech Padu Berhad
B - 111
Appendix B
SBS Project System Requirements Specification (SRS)
© HeiTech Padu Berhad
B - 112
Appendix B
© HeiTech Padu Berhad
Appendix c
APPEDIX C: SBS REQUIREMETS TRACEABILITY DOCUMET
SBS Project System Requirements Specification (SRS)
C-1
Appendix c
© HeiTech Padu Berhad
HEITECH PADU BERHAD
REQUIREMETS TRACEABILITY DOCUMET
(REQTD)
For
SBS Project
© HeiTech Padu Berhad
January, 2008
Version 1.0
Appendix c
© HeiTech Padu Berhad
Appendix c
© HeiTech Padu Berhad, Kuala Lumpur, 2000.
Company Number: 310628-D
All rights reserved. No part of this publication may be reprinted, reproduced, stored in a retrieval
system or transmitted, in any form or by any means, without the prior permission in writing from
the owners.
First published and distributed in January, 2008.
© HeiTech Padu Berhad
Document Authorization
DOCUMET AUTHORIZATIO
The enclosed document has been reviewed and accepted by the following people:
HeiTech Padu Berhad
AME
POSITIO
En. Kairol Amin Mohd
Head International Operations
Pn. Suzana Bee Abd Kader
SIGATURE
DATE
.............................
.................
.............................
.................
Project Manager
This document was prepared by:
AME
POSITIO
Algahmdi, Hanan Musafer H
Trainee
SBS Requirements Traceability Document
SIGATURE
DATE
………………….
…………..
© HeiTech Padu Berhad
Document Revision History
DOCUMET REVISIO HISTORY
The enclosed document has been amended according to the following description:
REV.
DATE
DESCRIPTIO OF CHAGES
A
B
C
D
SBS Requirements Traceability Document
CHAPTER
IITIALS
© HeiTech Padu Berhad
SBS Requirements Traceability Document
Document Revision History
© HeiTech Padu Berhad
Table Of Contents
TABLE OF COTETS
FORWARD ........................................................................................................... C - 1
1. REQUIREMENTS TRACEABILITY ............................................................................ C - 1
SBS Requirements Traceability Document
© HeiTech Padu Berhad
Appendix C
FORWARD
The requirements traceability document is developed to maintain bidirectional traceability of
requirements for the SBS Project. Requirements are traceable from their sources to System
Requirements Specification (SRS) document, System Design Description (SDD) document and
test cases.
Requirements Traceability Document
C-1
Version 1.0
Requirements Traceability
Branch cannot start operations
before start of day is executed.
Post office User log off.
System signs the current user out.
Post office User change password.
Customer must fill in open account form
before open Bank account.
Account opening is applicable to
Malaysian only.
2.
1.
2.
3.
3.
Version 1.0
Requirements Traceability Document
Post office User sign in.
1.
A- SYSTEM SPECIFICATIO
(Based on Requirements Type)
Requirement Description
Requirement ID &
SRS
SRS
SRS
SRS
SRS
SRS
SRS
Source
Shared Banking Services System
Project ame:
Last Updated:
PSOFT1
H
H
H
H
H
H
H
(L, M, H)
Priority
Customer’s
L
L
M
M
M
M
M
(L, M, H)
System/Components)
(Impact to Whole
Architectural Impact
‘Architectural Impact’ and ‘Qualification Method’ columns.).
Project ID:
4.
12.
Appendix C
Demonstration
Demonstration
Demonstration
Demonstration
Demonstration
Demonstration
Demonstration
Method
Qualification
6 Months
Pn. Suzana Bee
2.2.2.7
2.2.2.3
2.2.1.3.2
2.2.1.3.2
2.2.1.3.2
2.2.1.3.3
2.2.1.3.1
2.2.1.3.1
in SRS
in SDD
Reference Reference
Test Case
System
Case
UAT Test
C-1
Code
Source
Allocated Allocated Allocated Allocated Allocated
Project Duration:
Project Manager:
Status/
Comments
This section lists all requirements in the SBS Project. (Refer HTP REQMP, Section 3.3 for guidance on the ‘Customer’s Priority’,
© HeiTech Padu Berhad
Open a joint saving accountpassbookless.
Inquire customer/segment.
8.
Version 1.0
Requirements Traceability Document
23. PSV cash deposit.
22. CCA cash deposit.
Customer must fill in deposit/payment
form before deposit/payment.
20. Saving account-passbookless cash
deposit.
21. Saving account-passbook cash deposit.
4.
19. Verify GMPC.
18. PIN issuance.
17. Add card.
16. Print application form.
14. Inquire customer account type/product
type.
15. Add customer.
13. SA post misc code.
12. Add role.
11. Print specimen card.
10. Add account.
9.
7.
6.
Open an individual saving accountpassbook.
Open an individual saving accountpassbookless.
Open a joint saving account-passbook.
5.
© HeiTech Padu Berhad
H
SRS
SRS
H
H
H
SRS
SRS
H
H
H
H
SRS
SRS
SRS
SRS
H
H
SRS
SRS
H
H
H
H
H
H
H
H
H
H
SRS
SRS
SRS
SRS
SRS
SRS
SRS
SRS
SRS
SRS
L
L
L
L
L
H
M
M
M
M
M
M
M
M
M
M
H
H
H
H
Demonstration
Demonstration
Demonstration
Demonstration
Demonstration
Inspection
Analysis
Analysis
Analysis
Analysis
Analysis
Analysis
Analysis
Analysis
Analysis
Analysis
Demonstration
Demonstration
Demonstration
Demonstration
2.2.3.4.2
2.2.3.4.2
2.2.3.4.2
2.2.3.4.1
2.2.3.3
2.2.2.4.2.1
2.2.2.4.2
2.2.2.4.2
2.2.2.4.2
2.2.2.4.2
2.2.2.4.2
2.2.2.4.2
2.2.2.4.2
2.2.2.4.2
2.2.2.4.2
2.2.2.4.2
2.2.2.4.2
2.2.2.4.2
2.2.2.4.2
2.2.2.4.1
C-2
Appendix C
Version 1.0
Requirements Traceability Document
39. SA last transaction inquiry.
38. SA activity inquiry.
37. CA activity inquiry.
36. CA last transaction inquiry.
35. Name/IC No inquiry.
34. Reverse financial transaction
(withdrawal, deposit, remittance) by
electronic journal.
33. Reverse financial transaction
(withdrawal, deposit, remittance) by
journal number.
32. GIRO fund transfer.
31. Foreign worker telegraph transfer.
Customer must fill in withdrawal form
before withdraw cash.
28. Saving account-passbookless cash
withdrawal.
29. Saving account-passbook cash
withdrawal.
6. Customer must fill in remittance form
before remit cash.
30. Foreign worker telegraph transfer.
5.
27. Credit card cash payment
26. HP Payment via vehicle Registration No.
25. HP Payment via HP A/C No.
24. Loan cash repayment.
© HeiTech Padu Berhad
H
H
H
SRS
SRS
SRS
SRS
SRS
SRS
SRS
SRS
SRS
SRS
SRS
H
H
H
H
H
H
H
H
H
H
SRS
SRS
H
H
H
H
H
SRS
SRS
SRS
SRS
SRS
L
L
L
L
L
L
L
L
L
L
L
L
L
L
L
L
L
L
Demonstration
Demonstration
Demonstration
Demonstration
Demonstration
Demonstration
Demonstration
Demonstration
Demonstration
Demonstration
Demonstration
Demonstration
Demonstration
Demonstration
Demonstration
Demonstration
Demonstration
Demonstration
2.2.7.4.2
2.2.7.4.2
2.2.7.4.2
2.2.7.4.2
2.2.7.4.1
2.2.6.4.2
2.2.6.4.1
2.2.5.3
2.2.5.3
2.2.5.3
2.2.5.3
2.2.4.4.2
2.2.4.4.1
2.2.4.3
2.2.3.4.2
2.2.3.4.2
2.2.3.4.2
2.2.3.4.2
C-3
Appendix C
Version 1.0
Requirements Traceability Document
59. Add user.
58. Calculate commission.
57. Rounding adjustment calculation.
56. Rounding mechanism adjustment.
55. Override time out
54. Cancel remote override.
53. Return remote override.
52. Approve remote override.
51. Remote override.
50. Local override.
49. Change passbook status to new.
48. Change passbook line.
47. Update passbook.
46. Loan activity inquiry.
45. HP transaction inquiry.
44. GIRO transaction detail inquiry.
43. FWTT transaction inquiry.
42. FWTT transaction reference inquiry.
41. FTT transaction detail inquiry.
40. Credit card inquiry.
© HeiTech Padu Berhad
SRS
SRS
SRS
SRS
SRS
SRS
SRS
SRS
SRS
SRS
SRS
SRS
SRS
SRS
SRS
SRS
SRS
SRS
SRS
SRS
H
H
H
H
H
H
H
H
H
H
H
H
H
H
H
H
H
H
H
H
L
H
H
H
H
H
H
H
H
H
L
L
L
L
L
L
L
L
L
L
Demonstration
Analysis
Analysis
Analysis
Analysis
Analysis
Analysis
Analysis
Analysis
Analysis
Demonstration
Demonstration
Demonstration
Demonstration
Demonstration
Demonstration
Demonstration
Demonstration
Demonstration
Demonstration
2.2.10.3.1
2.2.3.4.2
2.2.3.6
2.2.3.4.2
2.2.9.4.3
2.2.9.4.2
2.2.9.4.2
2.2.8.4.2
2.2.9.4.2
2.2.9.4.1
2.2.8.4.2
2.2.8.4.2
2.2.8.4.1
2.2.7.4.2
2.2.7.4.2
2.2.7.4.2
2.2.7.4.2
2.2.7.4.2
2.2.7.4.2
2.2.7.4.2
C-4
Appendix C
Version 1.0
Requirements Traceability Document
79. View Forex rate.
78. View Electronic journal.
77. Stock control register.
76. Maintain stock distribution.
75. Register damaged / lost stock.
74. View stock acknowledgement.
73. Distribute stock.
72. Add stock.
71. Reactivate online posting.
70. Reporting for branch activity report.
69. Reporting for Teller activity report.
68. Balancing for final branch total.
67. Balancing for branch total.
66. Balancing for Teller total.
65. Forced user sign off.
64. Revoke / unrevoke user ID.
63. Unlock user ID.
62. Reset password.
61. List users.
60. Modify user role.
© HeiTech Padu Berhad
SRS
SRS
SRS
SRS
SRS
SRS
SRS
SRS
SRS
SRS
SRS
SRS
SRS
SRS
SRS
SRS
SRS
SRS
SRS
SRS
H
H
H
H
H
H
H
H
H
H
H
H
H
H
H
H
H
M
M
M
M
M
M
M
M
M
M
M
L
L
L
L
L
L
L
M
M
L
L
M
Demonstration
Demonstration
Demonstration
Demonstration
Demonstration
Demonstration
Demonstration
Demonstration
Analysis
Analysis
Analysis
Analysis
Analysis
Analysis
Demonstration
Demonstration
Demonstration
Demonstration
Demonstration
Demonstration
2.2.13.3.2
2.2.13.3.1
2.2.12.3.2
2.2.12.3.2
2.2.12.3.2
2.2.12.3.2
2.2.12.3.2
2.2.12.3.1
2.2.11.3.2
2.2.11.3.1
2.2.11.3.1
2.2.11.3.1
2.2.11.3.1
2.2.11.3.1
2.2.1.3.3
2.2.10.3.2
2.2.10.3.2
2.2.10.3.2
2.2.10.3.2
2.2.10.3.2
C-5
Appendix C
Version 1.0
Requirements Traceability Document
90. Hybird Client application is used to
design the front end of the SBS system.
87. Software developed using Windows XP
Platform.
88. Uses hardware that provides by Post
office and CSC.
89. Software shall be developed using
Microsoft Visual C++ and Microsoft
Visual Studio.Net.
86. Device Service Server used to manage
device integration and device sharing for
devices.
C- COSTRAITS
84. In terms of documenting, the SRS, SDD
and STD documents shall be
85. Microsoft ClickOnce implementation
tool used for central deployment and
automatic updates.
83. MS Access will be used for Teller PC
(Users Info, Branches Info, Teller Info,
Machines No Configuration and Smart
Terminal Configuration).
82. MS Access will be used for Controller
(Users Info, Branches Info, Teller Info,
Machines No Configuration and Smart
Terminal Configuration).
81. For database management, Windows
SQL Server 2005 Standard Edition will
be used for deployment server (Users’
Info and Branches’ Info).
B- DATA SPECIFICATIO
80. Download Forex rate.
© HeiTech Padu Berhad
M
SRS
M
H
SRS
SRS
H
SRS
H
H
SRS
SRS
H
H
H
H
H
SRS
SRS
SRS
SRS
SRS
M
M
M
H
H
H
H
H
H
H
M
Analysis
Analysis
Analysis
Demonstration
Demonstration
Demonstration
Demonstration
Demonstration
Demonstration
Demonstration
Analysis
4.4
4.4
4.3
4.2
4.2
4.2
4.1
4.4
4.4
4.4
2.2.13.3.2
C-6
Appendix C
Version 1.0
Requirements Traceability Document
102. Delete Manager.
101. Update Manager profile.
100. Add Manager.
99. View branch.
98. Activate / Deactivate branch.
97. Update / view branch.
96. Add branch.
SRS
SRS
SRS
SRS
SRS
SRS
SRS
SRS
SRS
94. Every transaction done through the
system is logged.
H- COFIGURATIO
95. Selected Bank administrator log in.
SRS
SRS
SRS
93. Access to the system is controlled based
on the defined roles.
G- QUALITY
Not applicable
F- QUALIFICATIO
E- EXCEPTIOAL SITE/ BRACHES
92. System will be installed /deployed at 200
Post office branches initially.
Not applicable
D- SIZIG AD TIMIG
91. Host will be using for the back end
processing.
© HeiTech Padu Berhad
M
M
M
M
M
M
M
M
H
H
H
H
M
M
M
M
M
M
M
M
M
M
M
M
11.1.1.1.1
8.4
8.4
6
4.4
Demonstration 11.1.1.1.3.3
Demonstration 11.1.1.1.3.2
Demonstration 11.1.1.1.3.1
Demonstration 11.1.1.1.2.3
Demonstration 11.1.1.1.2.3
Demonstration 11.1.1.1.2.2
Demonstration 11.1.1.1.2.1
Demonstration
Analysis
Analysis
Analysis
Analysis
C-7
Appendix C
Version 1.0
Requirements Traceability Document
111. Post office administrator resets Manager
password.
112. Change Post office Administrator
password.
113. Reset Post office Administrator
password.
114. Update Post office Administrator profile.
103. Change Selected Bank Administrator
password.
104. Reset Selected Bank Administrator
password.
105. Update Selected Bank Administrator
profile.
106. Selected Bank Administrator adds new
table.
107. Selected Bank Administrator updates /
views table.
108. Selected Bank Administrator deletes
table.
109. Selected Bank Administrator views
archive of electronic journal.
110. Post office administrator log in.
© HeiTech Padu Berhad
M
M
SRS
SRS
M
SRS
M
M
SRS
SRS
M
SRS
M
M
SRS
SRS
M
SRS
M
M
SRS
SRS
M
SRS
11.1.2.1.1
Demonstration 11.1.2.1.2.2
Demonstration 11.1.2.1.2.2
Demonstration 11.1.2.1.2.2
Demonstration 11.1.2.1.2.1
Demonstration
Demonstration 11.1.1.1.5.2
Demonstration 11.1.1.1.5.2
Demonstration 11.1.1.1.5.2
Demonstration 11.1.1.1.5.1
Demonstration 11.1.1.1.4.3
Demonstration 11.1.1.1.4.2
Demonstration 11.1.1.1.4.1
Appendix D: Requirements Traceability Table
M
M
M
M
M
M
M
M
M
M
M
M
C-8
Appendix C