Agrani Bank Limited IT Division

A Practicum Report Submitted By

Afroja Haq Tanni

ID: 18103161

A practicum report submitted to fulfillment of the requirements for the award of Bachelor of

Computer Science and Engineering

Department of Computer Science and Engineering

College of Engineering and Technology

IUBAT–International University of Business Agriculture and Technology

Spring 2022

i
Development of Checque Book Requisition System for
Agrani Bank Limited
Afroja Haq Tanni

A practicum report submitted to fulfillment of the requirements for the degree of

Bachelor of Computer Science and Engineering (BCSE)

The practicum has been examined and approved

_______________________________________

Prof Dr. Utpal Kanti Das

Chairman and Professor

________________________________________

Dr. Hasibur Rashid Chayon

Coordinator and Associate Professor

________________________________________

Mr. Rashedul Islam

Assistant Professor

Department of Computer Science and Engineering

College of Engineering and Technology

IUBAT –International University of Business Agriculture and Technology

Spring 2022

ii
 Abstract

In this report I have tried to list the overall aspects of the internship experience. I have

summarized what is expected in the next chapters of this report. The report consists of nine

chapters. In the first chapter of the report, it delivers information about the company. It starts with

a brief history of the company. Also, in this chapter we will describe the missions, visions and

objectives of the company. I tried to establish the organizational structure of the head office. In

the second chapter of the report, it describes mainly about the internship project. It starts by

describing the sections, I have been working on and to tell the different types, requirements and

features. The third and fourth chapter of the report describes the requirement engineering and

system planning. User and system requirements, functions of the proposed system, function

description, system project planning etc. are being described in this section. The fifth chapter

describes analysis and designing the project. Activity diagram, swim lane diagram, sequence

diagram, context level data flow diagram - all are being described in this chapter. The sixth

chapter describes risk analysis. Risk management and the RMMM plan are being described in this

chapter. The chapter seven describes system quality and testing phases. It also describes the

review and audit process. The chapter eight describes interface design. The final chapter nine

finishes this report with a conclusion and references.

iii
 Letter of Transmittal

17th April, 2022

Chairman
Practicum and Placement Committee College of Engineering and Technology
College of Engineering and Technology
IUBAT - International University of Business Agriculture and Technology
4, Embankment Drive Road, Sector 10
Uttara Model Town, Dhaka -1230, Bangladesh

Subject: Letter of Transmittal

Dear Sir,
With due respect, this is my pleasure to present my project report entitled –Checque Book
Requisition System for Agrani Bank Limited. I have prepared this report as partial fulfillment
of the practicum. I have tried my level best to prepare this project to the required standard.
It was a great opportunity to work on this paper to actualize my theoretical knowledge in the
practical arena. Now, I am looking forward to your kind appraisal regarding this practicum report.
I shall remain deeply grateful to you, if you kindly go through this report and evaluate my
performance. I hope that you would find the report comprehensive and competent augmented.

Sincerely yours,

_______________
Afroja Haq Tanni

Id: 18103161

Program: BCSE

iv
 Student’s Declaration

I am Afroja Haq Tanni, student of IUBAT–International University of Business Agriculture and

Technology, declaring that, this project paper on the stated topic has only been prepared for the

fulfillment of CSC490 (Practicum), as the partial fulfillment of―Bachelor of Computer Science

and Engineering degree.

It has not been prepared for any other rewards, purposes, or presentation.

_________________

Afroja Haq Tanni

ID.18103161

Program: BCSE

v
 Acknowledgement

In the name of Allah who is the most merciful and the most graceful, it‟s my pleasure to take this
occasion to thank a few people, who have, assisted, encouraged, directed and supported me
throughout my practicum program.

Firstly, I want to thank my family, who has endowed their immeasurable-innumerable support
and encouragement to attain this exquisite event of my life.

I am very appreciative to Prof. Dr. Utpal Kanti Das, Chair and Professor of Department of
Computer Science and Engineering, IUBAT- International University of Business Agriculture and
Technology for his unrelenting direction and sustain throughout the semester.

I would like to pay my gratitude to my practicum supervisor Mr. Rashedul Islam, Assistant
Professor of Computer Science and Engineering Department, who has given me the opportunity
to make such a report for not only in this semester but also throughout my education life at
IUBAT by giving her valuable suggestions and advices at any time, at any situation. I would be
able to make this report effectively and properly only for her right direction.

Sincerely,

____________________

Afroja Haq Tanni

ID: 18103161

Program: BCSE

vi
 Supervisor’s Declaration

This is to certify that Practicum report on “Checque Book Requisition System for Agrani Bank
Ltd” has been carried out by Afroja Haq Tanni, ID: 18103161 of IUBAT - International
University of Business Agriculture and Technology as a partial fulfillment of the requirement of
practicum defense course. The report has been prepared under my guidance and is a record of the
bona fide work carried out successfully. To the best of my knowledge and as per his declaration,
no part of his report has been submitted anywhere for any degree, diploma or certificate.

Now he is permitted to submit the report. I wish him all success in his future endeavors.

Practicum Supervisor

_________________

Mr.Rashedul Islam

Assistant Professor, Department of Computer Science and Engineering

IUBAT - International University of Business Agriculture and Technology

vii
 Department Certification

On behalf of the Department of Computer Science and Engineering of International University of

Business Agriculture and Technology, we the undersigned certify that this Practicum Report

“Checque Book Requisition System for Agrani Bank Ltd” for the award for the bachelor of

Computer Science and Engineering (BCSE) degree was duly presented by Afroja Haq Tanni,

ID: 18103161 and accepted by the department.

____________________

Dr. Hasibur Rashid Chayon

Co-Supervisor, Co-Ordinator and Associate Professor

____________________

Mr.Rashedul Islam

Supervisor, Assistant Professor

viii
Organization Certification

ix
 Table of Content
Table of Contents
1.1 Organizational Overview ....................................................................................................... 1
1.2 Organization Services ............................................................................................................. 2
1.3 Organization Location ............................................................................................................ 3
1.4 Organization Vision ................................................................................................................ 3
1.5 Organization Mission ............................................................................................................. 3
1.6 My Position in This Organization ......................................................................................... 3
1.7 Organizational Structure ....................................................................................................... 5
Chapter 2: Introduction ............................................................................................................... 6
2.1 Project Overview ..................................................................................................................... 6
2.2 Background Study .................................................................................................................. 8
2.3 Project Features ...................................................................................................................... 8
2.4 Objectives................................................................................................................................. 7
2.5 System Benefits........................................................................................................................ 9
2.6 Software Process Model ......................................................................................................... 9
2.7 Feasibility Study .................................................................................................................... 10
2.7.1 Technical feasibility ................................................................................................... 10
2.7.2 Economic feasibility ................................................................................................... 11
2.7.3 Operational feasibility ............................................................................................... 11
Chapter 3: Requirement Engineering ....................................................................................... 12
3.1 User and System Requirements ........................................................................................... 12
3.2 Functional Requirements ..................................................................................................... 14
3.3 Non-Functional Requirements ............................................................................................. 14
Chapter 4: System Planning....................................................................................................... 15
4.1 Function of Proposed System ............................................................................................... 15
4.2 System Project Planning....................................................................................................... 16
4.2.1 System Project Estimation ........................................................................................ 17
4.2.2 Function Oriented Metrics ........................................................................................ 17
4.2.3 Function point for Checque Book Requisition ........................................................ 18
4.2.4 Effort Distribution ..................................................................................................... 24
4.2.5 Task Scheduling ......................................................................................................... 25
4.2.6 Project Schedule Chart .............................................................................................. 26
4.2.7 Cost Estimation .......................................................................................................... 26

x
 4.2.7.1 Personnel Cost………………………………………………...…………………27

4.2.7.2 Hardware Cost…………………………………………………………………..27

4.2.7.3 Software Cost……………………………………………………………………28

4.2.7.4 Other Cost……………………………………………………………………….28

4.2.7.5 Total Cost………………………………………………………………………..29

Chapter 5: Analysis and Designing ........................................................................................... 30

5.1 Activity Diagram ........................................................................................................... 30
5.2 E-R Diagram.................................................................................................................. 39
5.3 Use Case Diagram ......................................................................................................... 40
5.4 Data Flow Diagram……………………………………………………………………41

Chapter 6: Risk analysis ............................................................................................................. 44

6.1 Risk Management ................................................................................................................. 44
6.2 The RMMM Plan .................................................................................................................. 46
6.2.1 Type of Impact: .......................................................................................................... 46
Chapter 7: System Quality and Testing .................................................................................... 51
7.1 System Testing ....................................................................................................................... 51

7.2 Software Quality Management Process .............................................................................. 53

7.3 Review & Audit Process ....................................................................................................... 54
7.3.1 Management reviews ................................................................................................. 54
7.3.2 Technical reviews ....................................................................................................... 54
7.3.3 Inspections .................................................................................................................. 55
7.3.4 Walk-through ............................................................................................................. 55
7.4 Testing .................................................................................................................................... 56
Chapter 8: Interface Design ....................................................................................................... 59
8.1 Database Field Design........................................................................................................... 59
8.2 Front End Interface design .................................................................................................. 61
Chapter 9: Conclusion ................................................................................................................ 66
9.1 Practicum and Its Value ....................................................................................................... 66
9.2 Future Work .......................................................................................................................... 66
9.3 Conclusion…………………………………………………………………………………...67

xi
9.4 References .............................................................................................................................. 68

List of Figures
Figure 1.1: Organization Location 3
Figure 1.2: Organizational Structure of Agrani Bank Ltd. 5
Figure 4.1: Effort Based Estimation 24
Figure 4.2: Project Schedule Chart 26
Figure 4.3: Total Personnel Cost of Proposed System 27
Figure 4.4: Total Hardware Cost of Proposed System 27
Figure 4.5: Total Software Cost of Proposed System 28
Figure 4.6: Total Other Cost of Proposed System 29
Figure 4.7: Total Cost Estimation of Proposed System 29
Figure 5.1: Activity Diagram 31
Figure 5.11: ER Diagram for Cheque Book Requisition System 39
Figure 5.12: Use Case Diagram for Cheque Book Requisition System 40
Figure 5.13: Data Flow Diagram level - 0 for Cheque Book Requisition System 41
Figure 5.13: Data Flow Diagram level - 1 for Cheque Book Requisition System 42
Figure 5.13: Data Flow Diagram level - 2 for Cheque Book Requisition System 43
Figure 8.1: Database of Cheque Book Requisition System 56
Figure 8.2: Database table of user 57
Figure 8.3: Database table of role 57
Figure 8.4: Database table of role_menu 57
Figure 8.5: Database table of branch info. 58
Figure 8.6: Interface design of Home page 58
Figure 8.7: Interface design of Requisition Form 59
Figure 8.8: Interface design of Branch panel 59
Figure 8.9: Interface design of Admin page 60
Figure 8.11: Interface design of Manage user page 61

xii
Figure 8.12: Interface design of Branch Login page 61
Figure 8.13: Interface design of manage menu page 62

List of Tables
Table 4.1: Functions of Proposed System 15
Table 4.2: Identifying Complexity for Proposed System (Transaction Function) 18
Table 4.3: Identifying Complexity for Proposed System (Data Function) 20
Table 4.4: UFP for Proposed System (Transaction Function) 21
Table 4.5: UFP for Proposed System (Data Function) 22
Table 4.6: Complexity Adjustment Value for Proposed System 22
Table 6.1: Project Risk (P01) 44
Table 6.2: Project Risk (P02) 44
Table 6.3: Business Risk (B01) 45
Table 6.4: Business Risk (B02) 45
Table 6.5: Technical Risk (T01) 46
Table 6.6: Technical Risk (T02) 47
Table 7.1: Testing Scenario No: 01 53
Table 7.2: Testing Scenario No: 02 53
Table 7.3: Testing Scenario No: 03 53
Table 7.4: Testing Scenario No: 04 53
Table 7.5: Testing Scenario No: 05 54
Table 7.6: Testing Scenario No: 06 54
Table 7.7: Testing Scenario No: 07 54
Table 7.8: Testing Scenario No: 08 54
Table 7.9: Testing Scenario No: 09 55

xiii
 Chapter 1: The Organization
Chapter 1 is representing an organizational overview, mission, and company‟s vision and about
company‟s services. In this chapter the detailed organizational overview is discussed along with
the organization‟s mission and vision followed by numerous services.

1.1 Organizational Overview

Agrani Bank was the National Commercial Bank under the Bangladesh Bank. It was invented at

1972 vice president order no.26. Previously it was named as Habib Bank after that it was named

commerce Bank and now it is named as Agrani Bank Ltd. The bank was incorporate as state owned

Commercial Bank on 17 May 2007. Then Agrani Bank was applied for ownership and Bangladesh

Ministry of finance of people’s Republic of Bangladesh and the Board of Directors found the bank as

Agrani Bank at 01 july 2007.

I had worked there as an intern senior officer at IT Division. There is a big IT Division at Agrani Bank

Ltd.They had developed various kinds of software for their Bank. And there are so many software

developers who are trained from outer countries. There is different Networking site also. I had

worked there as a software developer on PHP, Some payment system of this banks happens on

online. For online payment they needs various kinds of Softwares. The IT division has created those

softwares and control them.

1
1.2 Organization Services

Agrani Bank emerged as a Nationalized Commercial Bank following the Bangladesh Banks. Now a
days Agrani Bank becomes very popular to the general people. It is the owned Bank. It has both the
commercial commitment to its client and national commitment to the nation. Besides the services of
its clients, it has also worked with some other services- transferring money, online payment system,
govt employees payment system. It has 921 branches at Agrani Bank in both urban and rural areas.

Here below are a few of such services Agrani Bank Limited provides:

1. Sells and purchases of prize bond.

2. Give the payment of Army/ Civil

4. Payment of non-government primary /secondary school/college /Madrasha teachers benefit.

5. Payment of Government primary school teachers salary

6. Payment of Honorarium to freedom fighters.

7. Payment of Govt. allowances to Bayaska, Bidava and Dostho Mohila.

8. Payment of stipend to Shishu Kallyan Trust in urban areas.

9. Payment of Food Procurement bills.

2
1.3 Organization Location

Agrani Bank Head office: 9/D Dilkusha Commercial Area, Dhaka - 1000, Bangladesh.

Figure 1.1: Organization Location

1.4 Organization Vision

The vision of Agrani Bank is to become the leading bank in Bangladesh. The services of this
Bank is very good. There is a big IT division in this Bank. Also this Bank wants to give the
international level of efficiency ,quality and customer services.

1.5 Organization Mission

The mission of Agrani Bank is that they wants to apply the technology and information
communication for the benefit to the customers and employees. It only focus on the customers
benefit and comfort. Agrani Bank only focus on the ideas and lessons from best practice to
explore new avenues to stay strong and competitive.

3
1.6 My Position in This Organization

I am an intern software developer to this organization. I have been guided by a supervisor in this
organization. He is very helpful and informative. I really learn a lot from him. I successfully
completed my project in time. It was only possible by the guidance of my supervisor. It was also
a big experience to maintain the office time for me. I also maintain the other rules of this
organization. I am really happy to work with this office. It‟s really made me prepare for the
beginning of my career.

4
1.7 Organizational Structure

Figure 1.2: Organizational Structure of Agrani Bank Ltd.

5
 Chapter 2: Introduction

An internship is a professional learning experience that offers meaningful, practical work related
to a student‟s field of study or career interest. An internship gives a student the opportunity for
career exploration and development, and to learn new skills. It offers the employer the
opportunity to bring new ideas and energy into the workplace, develop talent and potentially
build a pipeline for future full-time employees.

2.1 Project Overview

Cheque Book Requisition System is a project which was created based on the rquirement of Bank. This
project will help the customers to apply for new cheque book sitting on their home, no need to come to
the bank for apply. There are three actors in this project- Admin, Branch and Customer.Here Customer
can apply for new cheque book and can login to the system but customer do not need to do login for
apply. During application some information should required- account number, date of birth and number
of cheque book leaves.

Customer:

1. Existing account holder can request for cheque book.

2. Login not required for requisition application.
3. During application, following information is required:
a. Applicant‟s account number
b. Date of Birth
c. Number of check book leaves.
4. Following applicant information will be fetched from backend through CBS.
a. Mobile Number
b. Branch Code
c. Customer Name
5. Mobile Number must be included in the CBS.
6. Existing account must be at least one month old.
7. Customers will get an OTP code in mobile number for verification.

6
8. A requisition number will be placed in the system and a printed copy of the requisition
will be available to the customer for download, which can be stored as proof of the
requisition.
9. Account holder can login if they wants to view their request status.
10. Request process status will be sent to the account holder‟s mobile.
11. Customer should physically visit the branch to receive the cheque from branch. Branch
will manually identify the customer and also verify the customer requisition in the system
before handover the cheque.

Branch:

1. Branch manager/user should approve the requisition application.

2. System generated excel/csv file of customers‟ requisition will be generated, which will
sent to “Printing & Stationary Division” for cheque requisition.
3. A lot number will be provided by the “Printing & Stationary Division”. Branch will
update the lot number.
4. Branch will update the cheque order sequentially in the the cabinet and update the serial
number in the system.
5. During delivary/handover the cheque, branch user will have a search option by following
field:
a. Account number
b. Requisition number
c. Requisition date
d. Mobile Number
e. Lot number
All the information regarding the requisition will be visible to the branch user along with
the cabinet number for finding the cheque in a shortest period of time.
6. Requisition report download option.
Admin:

1. Managing branch info in the system.

2. Managing user info in the system.
3. Resetting user password of the system.
4. Generating various reports for the admin and management.

7
2.2 Background Study

Agrani Bank Limited (ABL) is established in 1972. It is a state owned bank. It is formed by the
composition of ex-Habib Bank ltd and ex-Commerce Bank ltd. Agrani Bank Limited is a Bank
with an Authorized Capital and Paid-up Capital of Tk.800.00 million and Tk.248.00 million
respectively. The total equity of the bank stands at 725.00 million as of December, 2010. The
total profit of last year is about Tk.680.00 million . There are about 867 branches in which 10
branches are corporate. There are about 341 town branches and 526 rural branches.

The weaknesses of ABL are: Absence of service providing mentality, Absence of IT

Applications. Somewhat manual based, Lack of motivation of workers, depends on Head Office.

The opportunities of ABL are: High demand of credit, High demand of small Enterprise
financing, high demand of remittance facility, High demand of investment by Deposits.

2.3 Project Features

 User sign in / sign up.

 Admin Panel.
 Branch Manager
 Apply for cheque Book
 Branch can approve the application
 Admin can check the previous records

2.4 Objectives

The objectives of this project are:

• To make customers cheque Book Requisition easy and comfortable
• To serve the customer without wasting their precious time.
• To make the system user friendly.
• Admin can manage the whole system

8
2.5 System Benefits

• Web based application, can be accessible from anywhere by internet browser.

• Platform independent can run on Windows, Mac or Linux.

• An account holder of ABL can apply for new cheque Book without coming at Bank

• The harrasement for new cheque Book was reduce.

2.6 Software Process Model

I choose the Agile software process model to develop this system. Agile software development
methodology is one of the simplest and effective processes for a business need into software
solutions. I choose the Agile process model because,

• It is a very realistic approach to software development.

• Promotes teamwork and cross training.

• Functionality can be developed rapidly and demonstrated.

• Resource requirements are minimum.

• Suitable for fixed or changing requirements

• Delivers early partial working solutions.

• Good model for environments that change steadily.

• Minimal rules, documentation easily employed.

• Enables concurrent development and delivery within an overall planned context.

• Little or no planning required.

9
 • Easy to manage.

• Gives flexibility to developers.

Though, Agile is not a solution to every problem I might have, but if Agile methodology is

applied intelligently in the right situations, it has huge advantages.

2.7 Feasibility Study

The feasibility of the project is analyzed in this phase proposal is put forth with a very
general plan for the project and some cost estimates. During system analysis the feasibility
study of the proposed system is to be carried out. This is to ensure that the proposed system is
not a burden to the company. For feasibility analysis, some understanding of the major
requirements for the system is essential.

2.7.1 Technical feasibility

Technical feasibility addresses concerns about hardware capability, reliability and availability
and the skills of the development team. So, I found that this model is technically feasible,
because this can be developed by the following lines. To develop this project, needed a high-
level programming language like PHP and scripting language like Razor View, CSS3, Bootstrap,
JavaScript. For database needed MSSQL and I had use there the Codeigneter framework ci-3. To
store data and an IDE (Visual studio) need a cloud server and a computing device like a
computer or Smartphone with a simple configuration and data connection. All the technology
which is mention above is ready to use. So, our project is technically feasible.

10
2.7.2 Economic feasibility

This assessment typically involves a cost vs benefits analysis of the project, helping
organizations determine the viability, cost, and benefits associated with a project before financial
resources are allocated. We tried to make our project as much as clean and simple as possible
with robust features. This helps to save our time and money. As my system has ecommerce
functionality, there have possibility of making money by selling item. This makes our project
economically feasible.

2.7.3 Operational feasibility

Operational feasibility addresses concerns about user acceptance, management support, and the
requirements of entities and factors in the organization‟s external environment. It is operationally
feasible. Anyone can easily understand the process of our website. They need not have any extra
training to understand it.

11
 Chapter 3: Requirement Engineering

Requirement engineering is a process of gathering and defining what services should be provided
by the system. It focuses on assessing if the system is useful to the business (feasibility study),
discovering requirements, converting these requirements into some standard format
(specification), and checking that the requirements define the system that the customer wants
validation. In practice, requirements engineering isn't a sequential process, it‟s an iterative
process in which activities are interleaved.

3.1 User and System Requirements

1.Admin can login via username and password

1.1. Admin can enter their username.

1.2. Admin can enter a password.

1.3. Admin can click on the login button.

1.4. Successful login will redirect to the admin dashboard.

2. Admin can manage -

2.1. Managing branch info in the system.

2.2. Managing user info in the system.

2.3. Resetting user password of the system.

2.4. Generating various reports for the admin and management.

3.Customer can view the item

3.1. Existing account holder can request for cheque book.

12
3.2. Login not required for requisition application.

3.3.During application, following information is required:

a. Applicant‟s account number
b. Date of Birth
c. Number of check book leaves.
3.4.Following applicant information will be fetched from backend through CBS.
d. Mobile Number
e. Branch Code
f. Customer Name
3.5.Mobile Number must be included in the CBS.

3.6.Existing account must be at least one month old.

3.7.Customers will get an OTP code in mobile number for verification.

3.8.A requisition number will be placed in the system and a printed copy of the
requisition will be available to the customer for download, which can be stored as proof
of the requisition.

3.9.Account holder can login if they wants to view their request status.

3.10.Request process status will be sent to the account holder‟s mobile.

4. Branch:

4.1. Branch manager/user should approve the requisition application.

4.2. System generated excel/csv file of customers‟ requisition will be generated, which
will sent to “Printing & Stationary Division” for cheque requisition.

4.3.A lot number will be provided by the “Printing & Stationary Division”. Branch will
update the lot number.

4.4.Branch will update the cheque order sequentially in the the cabinet and update the
serial number in the system.

4.5.During delivary/handover the cheque, branch user will have a search option by
following field:

13
 a. Account number
b. Requisition number
c. Requisition date
d. Mobile Number
e. Lot number
All the information regarding the requisition will be visible to the branch user along with
the cabinet number for finding the cheque in a shortest period of time.

4.6.Requisition report download option.

3.2 Functional Requirements

We did our functional requirement engineering as below,

1. System will validate username and password.

2. System will validate if a password is strong or not.
3. System will validate that username field, password, applicant account number, Date of
birth ,number of cheque Book Leaves field can‟t be empty.
4. There will be field validation for each inputted field. If a validation missing or wrong
value inputted, system will show error

5. For some pages, user authentication is needed. If user is not authenticated or not logged

in, he/she can‟t access that page.

6. Add, edit, delete functionality.

3.3 Non-Functional Requirements

1. Simple Interface.

2. Simple and user-friendly UI/UX.

3. Same login panel for Admin and User both.

4. Separate admin panel to manage Agrani Bank Ltd Cheque Book Requisition System.

14
 Chapter 4: System Planning

Systems Planning is the first phase of SDLC. During the planning phase, the objective of the
project is determined and the requirements of the system are considered. Meetings with
managers or stakeholders are held to determine the exact requirements of the project. An
estimate of resources, such as personnel and costs, is prepared, to either bring changes in the
current system or develop a new system. A schedule with toll gates is planned. All of the
information is analyzed to see if there is an alternative solution to creating a new item. A
feasibility study is conducted of the proposed project in the planning stage. If there is no other
viable alternative, the information is assembled into a project plan and presented to
management for approval. A rough budget for the project is prepared. Communication plans,
meetings, contracts and potential risks are discussed in this phase. Finally, a Requirement
Specification document is created which serves the purpose of guidelines for the next phase of
the model.

4.1 Function of Proposed System

Table 4.1: Functions of Proposed System

Login to the system F1
Apply for the new cheque Book F2
View request F3
Aprove the request F4
Add account number F5
View request history F6
Update request F7
Add Date of Birth for apply F8
Add cheque Book leaves F9

15
Add mobile number F10
Add Branch code F11
View Lot number F12

4.2 System Project Planning

Software project planning is the second activity of CPF. Software project management
commences with a set of activities that are collectively called software project planning. Before
starting any project, it is compulsory to estimate the work to be done, the resources that will be
required, the time will elapse from start to finish and to analyze the project to determine whether
it is feasible or not. The following activities of software project planning that have followed in
this project are:

● System Project Estimation

● Function Oriented Metrics

● Process Based Estimation

● Effort Distribution

● Task Scheduling

● Project Schedule Chart

● Cost Estimation

4.2.1 System Project Estimation

The accuracy of a software project estimate predicted based on a number of things:

● Properly estimated the size of the project to build.

16
 ● The ability to translate the size estimation into human effort, calendar time and money.

● The degree to which the project plan reflects the abilities of the software team or

engineer.

● The stability of the project requirements and the environment that supports the software

engineering effort.

4.2.2 Function Oriented Metrics

Function point-based estimation focuses on information domain values rather than software
values. Function points are computed by comparing five information domain characteristics. The
information domain values are as follows:
1. Number of external inputs - Each user input that provides distinct application- oriented

data to the software is counted as inputs that should be distinguished from inquiries.

2. Number of external outputs - Each user output that provides application-oriented

information to the user is counted.

3. Number of external inquiries - An inquiry defined as an on-line input result in the

generation of some immediate software response in the form of an on-line output. Each

distinct inquiry counted.

4. Number of files - Each logical master file counted.

5. Numbers of external interfaces - All machine-readable interfaces that used to transmit

information to another system counted.

The weights of the domains are fixed, which are provided in appropriate table locations.

Weights can be divided into three categories according to the functionality of the system.

17
 They are simple, average and complex. The total system is a complex system but the part of

the total system. Once these data have collected, a complexity value is associated with each

count.

4.2.3 Function point for Cheque Book Requisition System of ABL

Table 4.2: Identifying Complexity for Proposed System (Transaction function)
Transition Fields/File involve DETs FTRs
function
Login to the Fields: User name, password 2 1
system Filename: user
(EQ)
Add application Fields: id, customer_id, branch_name, branch_code, 16 3
(EI) lot_number, otp_code, date of birth_descp,
request_history.
Filename: user_id,branch,category
View request Fields: id, id, application_code, user_name, lot_number, 16 3
(EO) date_of_birth, number_of_leaves, short_descp,
long_descp, request_history.
Filename: branch,application,category
Update request Fields: id, id, category_id, branch_name, branch_code, 16 3
(EI) item,lot_number, delivery_date, short_descp,
long_descp, application_history.
Filename: application,branch,customer
Add information Fields: id, user_name, mobile_number, customer_name 4 1
(EI) Filename: customer

View request Fields: id, customer_name, account_number, 4 1

info. (EO) mobile_number
Filename: customer

Update Fields: id, customer_name, A/C_number, lot_number 4 1

customer info Filename: customer
(EI)

18
 View Fields: id, user_id, branch_id, account_number, name, 17 1
application (EO) phone, post_code, notes, application_type, branch_id,

requisition_number, number of_leaves,

application_number, mobile_no, application_month,
return_date, receive_date
Filename: application
Add customer Fields:id,division_name,district_name,state_name 4 1
area (EI) Filename: customer_Area

View customer Fields:id,division_name,district_name,state_name 4 1

area Filename: customerArea
(EO)

Update Fields:id,division_name,district_name,state_name 4 1
customer area Filename: customerArea
(EI)

Create new Fields: name, user_id, phone, password, 6 1

account confirm_password, date_of_birth
(EI) Filename: user

Add to branch Fields: 8 1

(EI) name,delivery_date,account_no,leaves_no,branch__code,
requisition_number
Filename: requisition

19
 Table 4.3: Identify Complexity for Proposed System (Data Functions)
Data function Fields/File involve DETs FTRs
Appplication (ILF) Fields: id , branch_id, category_id, 16 1
customer_name_en, branch_code_bn,
application_code, lot_number, number_of_leaves,
lot_number, requisition_number, requisition_date,
short_descp, long_descp, applicatuion_overview,
cheque_deails.
Filename: application
Requisition (ILF) Fields: id, category_name, requisition_code, 4 1
branch_code
Filename: requisition

Branch (EIF) Fields: id, number_of_leaves, account_no, 5 3

application_id, branch_code
Filename: orderdetail, order, item
Customer (ILF) Fields: id, user_id, division_id, district_id, name, 17 1
phone, post_code, notes, cheque_type,
requisition_id, currency, amount,
application_number, invoice_no,
application_month, return_date, received_date
Filename: customer
User (ILF) Fields: id, password, name, phone, date_of_birth 6 1
Filename:user

20
 Table 4.4: UFP (Unadjusted Function point) for Proposed System (Transaction Functions)
Transition function DETs FTRs Complexity UFP
Login to the system (EQ) 2 1 Low 3
Add application (EI) 16 3 High 6
View application (EO) 16 3 Average 5
Update request (EI) 16 3 High 6
Add mobile no (EI) 4 1 Low 3
View history (EO) 4 1 Low 4
Update information (EI) 4 1 Low 3
Add branch code (EI) 4 1 Low 3
View branch area (EO) 4 1 Low 4
Update application code (EI) 4 1 Low 3
Create new account (EI) 6 1 Low 3
View profile (EO) 6 1 Low 4
Update profile (EI) 6 1 Low 3
Add lot number (EI) 8 1 Low 3
Add requisition number (EI) 3 2 low 3
Place application (EI) 12 3 Low 3
View application history (EO) 6 1 Low 4
Total UFP 63

21
 Table 4.5: UFP (Unadjusted function point) for Proposed System (Data functions)
Data function DETs FTRs Complexity UFP
Application (ILF) 16 1 Low 7
Customer (ILF) 4 1 Low 7
Branch (EIF) 5 3 Low 5
Requisition (ILF) 17 1 Low 7
User (ILF) 6 1 Low 7
Total UFP 33

Table 4.6: Complexity Adjustment Value for Proposed System

Number Factor Value
1 Data communication 5
2 Distributed data processing 1
3 Performance 4
4 Heavily used configuration 2
5 Transaction rate 3
6 Online data entry 4
7 End user efficiency 2
8 Online update 3
9 Complex processing 2
10 Reusability 3
11 Installation ease 2
12 Operation ease 2
13 Multiple sites 3
14 Facilitate change 2
Total Degree of Influence (TDI): 38

22
Value Adjustment Factor (VAF) = 0.65 + (.01 * TDI)

= 0.65 + (.01 * 38)

= 1.03

UFP = UFP (Transaction Function) + UFP (Data Function) = 90 + 65 = 155 Adjustment

Function Point Count (AFP) = UFP * VAF

= 155 * 1.03

=159.65

Effort for PHP = AFP * productivity

= 159.65 * 10.08 (productivity for PHP)

= 1609.27 person hours / 10

= 160.92 person days / 30

= 5.36 person months

23
4.2.4 Effort Distribution

Figure 4.1: Effort Based Estimation

Description:

1. 8% - Customer Communication

2. 9% - Planning

3. 10% - Analyzing

4. 14% - Designing

5. 30% - Coding

6. 12% - Testing

7. 17% - Implementation

24
For effort-based estimation we have used an effort allocation rule that is 41-30-29. Customer

communication, analysis, design, planning for total 41%. Coding is 30% and testing and

implementation is 29%.

4.2.5 Task Scheduling

Project scheduling is an activity of distributing the estimated efforts within the planned project

duration. There are some basic rules for project scheduling. They are as follows -

1. Compartmentalization - The project must compartmentalize into a number of

manageable activities and tasks.

2. Interdependency - The interdependency of each compartmentalized activity or task must

be determined. Some tasks must occur in sequence while others can occur in

parallel.

3. Time allocation - Each task to be scheduled must allocate some number of work units.

4. Effort validation - Every project has a defined number of staff members. It should

ensure that no more than the allocated number of people has scheduled at any given time.

5. Defined responsibilities - Every task that is scheduled should be assigned to a specific

team member.

6. Defined outcomes - Every task that is scheduled should have a defined outcome. The

outcome is normally a work item or a part of a work item.

25
4.2.6 Project Schedule Chart

Total system development is a combination of a set of tasks. These sets of tasks should be done
sequentially and timely. Project schedule works as the guideline of the system developer. The
following is the schedule chart of this project:

Figure 4.2: Project Schedule Chart

4.2.7 Cost Estimation

The approximation of the cost of a program is cost estimation. In this project, there are few

factors to analyze and calculate the cost. Given below:

1. Personnel Cost

2. Hardware Cost

3. Software Cost

4. Other Cost

26
4.2.7.1 Personnel Cost

Designation Person Working Salary Total

Hour Salary

System One 90 12,000

Analyst

Planner One 90 12,000

Designer One 130 18,000

Coder Two 420 1,00,000

1,54,000
BDT
Tester One 90 12,000

Figure 4.3: Total Personnel Cost of Proposed System

4.2.7.2 Hardware Cost

CPU 30,000 BDT

Monitor 9,000 BDT

Keyboard 700 BDT

Mouse 300 BDT

Others 500 BDT

Total 40,500 BDT

27
 Figure 4.4: Total Hardware Cost of Proposed System

4.2.7.3 Software Cost

Name Price

Window 10 No Cost

Visual Studo No Cost

Google Chrome No Cost

Git No Cost

Total 0.0 BDT

Figure 4.5: Total Software Cost of Proposed System

4.2.7.4 Other Cost

Name Price

Electric Bill 3,000 BDT

28
 Internet Bill 2,000 BDT

Office Rent 20,000 BDT

Extra 1,000 BDT

Total 26,000 BDT

Figure 4.6: Total Other Cost of Proposed System

4.2.7.5 Total Cost

Name Price Total Cost

Personnel Cost 1,54,000 BDT

Hardware Cost 40,500 BDT 2,20,500 BDT

Software Cost 0.0 BDT

Other Cost 26,000 BDT

Figure 4.7: Total Cost Estimation of Proposed System

29
 Chapter 5: Analysis and Designing

Software analysis and design is the process, where we attached all activities, which help the
transformation of requirement specification into implementation. Requirement specifications
relate to all functional and non-functional expectations from the software. All the requirement
specifications approach in the shape of human readable and understandable documents.

5.1 Activity Diagram

Activity diagrams describe the workflow behavior of a system. The diagrams describe the state

of activities by showing the sequence of activities performed.

30
 Activity diagram -

Customer

Registration Login Requisition Forget Password

A/C Number, Mobile

A/C number,Mobile No,
A/C Number/password number, Number of A/C Number , Password
Password
Leaves collection Branch

Check Validity SMS Temp poss

Check valid
A/C Varification
Customer

Send OTP
Send OTP
Dash Board

OTP Varification
OTP Varification

Request Accept

Registration
Request
Approval

Login Send SMS Request Confirm

Generate Excel

Print order

Print Received

Send SMS Disburstment

Deliver

Figure 5.1: Activity Diagram for Cheque Book Requisition

31
5.2 E-R Diagram

Login_type Role_name User_name

password

Login
User_mobile
User-ID User_name
num Role_type Role_name

Role_desc
Date_of_birth

address user Roles

has
Requisition_ Requisition_ Requisition_
id code date
OTP_code

Requisition

Cb_num_of_
Cb_id Cb_types
leaves

Cb_num

managing Cheque Book

Cus_mobile
Cus_passwo
rd
Cus_name Cus_id

Cus_address

Ac_id
Account
Customer
Ac_num

Send_to_print
ing Ac_desc

Approve_req Br.address
has Ac_type
Br_code

Branch

Figure 5.11 ER-diagram for cheque Book Requisition system

32
5.4. Use case Diagram

33
34
35
Figure 5.12 Use Case Diagram for Cheque Book Requisition

36
5.5. Data Flow Diagram

Data Flow Diagram level 0 :

37
Data Flow Diagram level 1:

38
Data Flow Diagram level 2 :

39
Data Flow Diagram level 3 :

Fig: Dataflow Diagram for cheque Book Requisition

40
 Chapter 6: Risk analysis

Risk analysis in software testing is an approach to software testing where software risk is
analyzed and measured. Traditional software testing normally looks at relatively straightforward
function testing. A software risk analysis looks at code violations that present a threat to the
stability, security, or performance of the code.

6.1 Risk Management

A risk is a serious problem that might or might not happen. It is necessary to analyze the
potential risks in a project. If the risks of a software project are not properly analyzed and
estimated, many problems can plague the software project. Risk analysis and management are a
series of steps that help a software team to understand and manage uncertainty. To establish a
risk management model the following phases are followed:
1. Identification: Risk identification is the process of detecting potential risks or hazards
through data collection. A range of data collection and manipulation tools and techniques
exists. The team is using both automated and manual techniques to collect data and begin
to characterize potential risks to Web resources. Web crawling is one effective way to
collect information about the state of Web pages and sites.

2. Classification: Risk classification is the process of developing a structured model to

categorize risk and fitting observable risk attributes and events into the model. The team
combines quantitative and qualitative methods to characterize and classify the risks to
Web pages, Web sites, and the hosting servers.

3. Assessment: Risk assessment is the process of defining relevant risk scenarios or

sequences of events that could result in damage or loss and the probability of these
41
 events. Rosenthal describes the characteristics of a generic standard for risk assessment as
"transparent, coherent, consistent, complete, comprehensive, impartial, uniform,
balanced, defensible, sustainable, flexible, and accompanied by suitable and sufficient
guidance.
4. Analysis: Risk analysis determines the potential impact of risk patterns or scenarios, the
possible extent of loss, and the direct and indirect costs of recovery. This step identifies
vulnerabilities, considers the willingness of the organization to accept risk given potential
consequences, and develops mitigation responses.

5. Implementation: Risk management implementation defines policies, procedures, and

mechanisms to manage and respond to identifiable risks. The implemented program
should balance the value of assets and the direct and indirect costs of preventing or
recovering from damage or loss.

To take comprehensive care of a web-based system we must consider the following points:

1. Hardware and software environment including any upgrades to the operating system and
Web server, the installation of security patches, the removal of insecure services, use of
firewalls, etc.
2. Administrative procedures such as contracting with reputable service providers, renewing
domain name registration, etc.
3. Network configuration and maintenance including load balancing, traffic management,
and usage monitoring.
4. Backup and archiving policies and procedures including the choice of backup media,
media replacement interval, number of backups made and storage location.

There are different categories of risks that should be considered in any software project. The
following categories of risks have been considered in this software project.

1. Project risks: These risks threaten the project plan. If these risks become real, it is likely
that the project schedule will slip and that costs will increase. Project risks identify potential

42
 budgetary, schedule, personnel, resource, customer and requirement problems and their
impact on the software project.
2. Technical risks: These risks threaten the quality and timeliness of the software to be
produced. If a technical risk becomes a reality, implementation may become difficult or
impossible. Technical risks identify potential design, implementation, interface, verification
and maintenance problems. Moreover, specification ambiguity, technical uncertainty,
technical obsolescence is also risk factors.

3. Business risks: These risks threaten the viability of the software to be built. The business
risks can be market risks, building a system that no one really wants. Strategic risks, building
a system that no longer fits into the overall business strategy for the company. Management
risks, losing the support of senior management due to a change in focus or a change in
people. Budget risks, losing budgetary or personnel commitment.

6.2 The RMMM Plan

1. Risk Mitigation: Proactive planning for risk avoidance.

2. Risk Monitoring: Assessing whether predicted risks occur or not, ensuring preventive

steps are being properly applied, collect information for future risk analysis, attempt to

determine which risks caused which problem.

3. Risk Management: Actions to be taken in the event that mitigation steps have failed and

the risk has become a live problem.

6.2.1 Type of Impact:

1. Catastrophic,

2. Marginal,

3. Tolerable,

43
 4. Critical.

● Very low (<10%),

● Low (10–25%),

● Moderate (25–50%),

● High (50–75%),

● Very high (>75%).

Project Risk (P01) Date: October 30, 2021

Name Changes of requirements

Probability Low (18%)

Impact Marginal (2)

Description Company may change their requirements

Mitigation & Monitoring Requirements are redefined by the company

due to time or business needs. Meetings will
be held with the company regularly. This
ensures that the item we are producing
solves a problem.

Management Emergency meeting between both parties to

identify new project requirements and goals.

Status Not occur

44
Project Risk (P02) Date: October 30, 2021

Name Poor Quality Documentation

Probability Low (23%)

Impact Marginal (2)

Description Poor quality documentation of the members

Mitigation & Monitoring Meetings will be held routinely to offer

documentation suggestions and topics. The
progress on documentation will also have a
monitor in each meeting.
Management The addition of new topics or removal of
unnecessary topics into the documentation
will be assigned to the responsible person.

Status Not occur

Business Risk (B01) Date: February 27 , 2022

Name Insufficient Budget

Probability Moderate (35%)

Impact Marginal (2)

Description If the budget is low, the project may not

complete.

Mitigation & Monitoring The project needs a server that is costly to

set-up. We find several alternative streaming
services to reduce the budget risk.

45
Management Refinement in project goal. A new plan to
regulate the budget.

Status Problem resolved.

Business Risk (B02) Date: March 30, 2022

Name End Users Accept System

Probability Low (15%)

Impact Critical (4)

Description The system fails to gain user‟s faith

Mitigation & Monitoring In order to prevent this from happening, the

software will develop with the end user in
mind. The user interface will design in a
way to make use of the program convenient
and pleasurable.

Management Training the users to familiarize them with

the new system. Releasing patches/bug fixes
for greater user satisfaction.

Status The risk has not arisen yet.

Technical Risk (T01) Date: April 03, 2022

Name Lack of Experience

Probability Low (20%)

Impact Tolerable (3)

Description Lack of members experience

46
Mitigation & Monitoring The development cost of the software may
increase by 20%. Consult with the System
Analyst during the system analysis, design
and testing phase of the project.

Management Though the development cost is increased

by 20%, the project is still feasible. Set an
appointment for a formal meeting with the
System Analyst to solve different problems
of each of the phases.

Status The risk has not arisen yet.

Technical Risk (T02) Date: April 10, 2022

Name Poor Comments in Code

Probability Low (20%)

Impact Catastrophic (1)

Description Poor comment in the coding part.

Mitigation & Monitoring Proper coding grammar is followed to make
sure that the codes are easily understandable
and reusable.

Management In an emergency a refinement in code

commenting should be done. This may slow

down the development process but it will
help the developers in the long run.

Status The risk has not arisen yet.

47
 Chapter 7: System Quality and Testing

7.1 System Testing

According to the common process framework (CPF), the software testing is the final activity that
has to be initiated after developing. Software testing is a critical element of software quality
assurance and represents the ultimate review of specification, design and code generation. A
quality management software system that is automated and connects all departments is essential
for a regulated or ISQ-compliant company. A QMS or a TQM (total quality management) system
can connect each phase in a item's development lifecycle with every department in a company.
This gives everyone an opportunity to provide feedback. Automated routing, with escalation,
ensures the rapid responses to inputs needed from the department. By building quality into items
as opposed to forcing QA to bear the burden of the responsibility, everyone wins, engineering,
regulatory, QA, manufacturing, sales and marketing. The quality of software is assessed by a
number of variables. These variables can be divided into external

and internal quality criteria. External quality is what a user experiences when running the
software in its operational mode. Internal quality refers to aspects that are code-dependent, and
that are not visible to the end-user. External quality is critical to the user, while internal quality is
meaningful to the developer only.
Some quality criteria are objective, and can be measured accordingly. Some quality criteria are
subjective, and are therefore captured with more arbitrary measurement. There are mainly two
types of quality,
1. Internal Quality

2. External Quality

48
Internal quality:

● Test coverage

● Testability

● Portability

● Thread-safeness

● Conciseness

● Maintainability

● Documentation

● Legibility

● Scalability

External quality

● Features

● Speed

● Space

● Network usage

● Stability

● Robustness

● Ease-of-use

● Determinism

● Back-compatibility

● Security

● Power consumption

49
7.2 Software Quality Management Process
● The aim of Software Quality Management (SQM) is to manage the quality of software
and development and of its development process
● A quality item is one which meets its requirements and satisfies the user

● A quality culture is an organization environment where quality is viewed as everyone‟s

responsibility

Some of the specific SQM processes defined in standard:

1. Quality assurance process: Quality Assurance makes sure the project will be completed
based on the previously agreed specifications, standards and functionality required
without defects and possible problems. It's Monitors and tries to improve the
development process from the beginning of the project to ensure this. it is oriented to
prevention.

2. Verification & validation process: In software project management, software testing,

and software engineering, verification and validation (V&V) is the process of checking
that a software system meets specifications and that it fully fills its intended purpose. It is
normally the responsibility of software testers as part of the software development
lifecycle.

In the verification, a client will either view the software, or see it implemented in a test situation.
At this point it is imperative that the client who needs the software is able to ascertain that this
software is hitting all the parameters initially requested or desired only when this assurance is
made should the next part of the verification and validation process be started.
While this is not the last chance to “tweak” the software into doing the tasks required it is part of
the last steps before a project is completed, and in being too quick to approve the software as this
could cause problems later, and could also result in more money required for the software‟s later
changes.

50
The next step of verification and validation of software is simple. Client the company will
approve the software and validate it as being what is required. This stage usually means a
systematic checking of various requirements. While this might sound tedious, it is necessary part
of the procedure to ensure that again, the result is exactly to the specifications of all concerned.
The entire verification and validation process is part of a normal sequence of quality control for
software.

7.3 Review & Audit Process

A software audit review, or software audit, is a type of software review in which one or
more auditors who are not members of the software development organization conduct
“An independent examination of a software item, software process, or set of software
processes to assess.

7.3.1 Management reviews

The purpose of a management review is to monitor progress, determine the status of plans and
schedules, confirm requirements and their system allocation, or evaluate the effectiveness of
management approaches used to achieve fitness for purpose. This supports decisions about
changes and corrective actions that are required during a software project.

7.3.2 Technical reviews

The purpose of technical review is to evaluate a software item to determine its suitability for its
intended use. The objective is to identify discrepancies from approved specifications and
standards. The result should provide management with evidence confirming (or not) that the item
meets the specifications and adheres to standards and that changes are controlled. A technical
review requires that mandatory inputs be in place in order to proceed:

● Statements of objectives

● A specific software items

● The specific project management plan

● The issues list associated with this item

51
7.3.3 Inspections

The purpose of an inspection is to detect and identify software item anomalies. Two important
differentiators of inspections as opposed to reviews are as follows:

● An individual holding a management position over any member of the inspection team
shall not participate in the inspection
● An inspection is too led by an impartial facilitator who is trained in inspection techniques.
The inspection exit must correspond to one of the following three criteria:

● Accept with no or at minor reworking

● Accept with rework verification

● Re inspect

Inspection meetings typically last a few hours, whereas technical reviews and audits are usually
broader in scope and take longer.

7.3.4 Walk-through
The purpose of a walk-through is to evaluate a software item. A walk-through may be conducted
for educating an audience regarding a software item. The major objectives are
to:

● Find anomalies

● Improve the software item

● Consider alternative implementations

● Evaluate conformance to standards and specifications

The purpose of a software audit is to provide an independent evaluation of the

conformance of software items and processes to applicable regulations, standards,
guidelines, plans, and procedures. The audit is a formally organized activity, with
participants having specific roles, such as lead auditor, another auditor, a recorder, or an

52
 initiator, and includes a representative of the audited organization. The audit will identify
instances of nonconformance and produce a report requiring the team to take corrective
action.

7.4 Testing

Table 7.1: Test Scenario No: 01

Scenario User can login via username and password
Input‟s Enter username, password and click login button
Desired Output‟s User can be able to login
Actual Output‟s Homepage with successful login
Status Pass

Table 7.2: Test Scenario No: 02

Scenario Admin can add and manage info.
Input‟s Enter all info
Desired Output‟s Saved into the database
Actual Output‟s All information saved into the database
Status Pass

Table 7.3: Test Scenario No: 03

Scenario Branch can approve application
Input‟s Click on approve option
Desired Output‟s Can see the application history
Actual Output‟s Extracted all information from the database
Status Pass

Table 7.4: Test Scenario No: 04

Scenario Admin can edit info.
Input‟s Edit information and click to save
Desired Output‟s Can see updated information

53
Actual Output‟s Updated all information to the database
Status Pass

Table 7.5: Test Scenario No: 05

Scenario Admin can manage user

Input‟s click on manage user button
Desired Output‟s update from database
Actual Output‟s All information updates from the database
Status Pass

Table 7.6: Test Scenario No: 06

Scenario Admin can add manage menu
Input‟s Enter all info
Desired Output‟s Saved into the database
Actual Output‟s All information saved into the database
Status Pass

Table 7.7: Test Scenario No: 07

Scenario Admin can view application
Input‟s view customer
Desired Output‟s Can see the application list
Actual Output‟s Extracted all information from the database
Status Pass

Table 7.8: Test Scenario No: 08

Scenario Admin can edit branch
Input‟s Edit information and click to save
Desired Output‟s Can see updated information

54
Actual Output‟s Updated all information to the database
Status Pass

Table 7.9: Test Scenario No: 09

Scenario Admin can delete info.
Input‟s click on delete option
Desired Output‟s Delete from database
Actual Output‟s All information deletes from the database
Status Pass

55
 Chapter 8: Interface Design

8.1 Database Field Design

Figure 8.1: Database of “Cheque Book Requisition”

Figure 8.2: Database table of “user”

56
Figure 8.3: Database table of “Branch”

Figure 8.4: Database table of “role”

57
Figure 8.5: Database table of “Requisition”

Figure 8.6: Database table of “Status Log”

58
8.2 Interface design

Homepage

Figure 8.6: Interface design of Chque Book Requisition homepage

Figure 8.7: Interface design for Manage user page

59
 Figure 8.8: Requisition Form

Figure 8.9: Interface design for Menu Creation page

60
 Figure 8.10: Interface design of Role Creation Page

Figure 8.11: Interface design for Role Menu Page

61
 Figure 8.12: Interface design for Branch Accept

Figure 8.13: Interface design for Branch requisition list page.

62
Figure 8.14: Printing serial Number fill up

Figure 8.15: Branch issue cheque Book page

63