Customer Bank Account System Requirement

Background

Techlabs is a training expert and is looking at Customer Bank Account Management System
as a Standard Reference for students who will implement customer account management
functionality as a part of training. This project incorporates all the concepts taught during
course namely design patterns, various frameworks (Struts2, spring, Hibernate etc.), language
fundamentals maintaining high design and coding standards.

Purpose of this document

This document defines the Business process flow of Customer Bank Account
Management System. This document reflects the results of the discussions between the
stakeholders, program architect and experts from banking domain.

Definitions

 Stakeholder: Swabhav Techlabs Pvt Ltd

 Program Architect: Software Developers/Trainers from Swabhav Techlabs Pvt Ltd.
 Domain Expert: Senior program architect with 15+ years of experience in banking domain.

Actors

Below are the actors and their role with respect to the Customer Bank Account Management
System.
1. Employee: The user who will manage creation of a customer account, customer status, deposits
and withdrawals from branch.
2. Customer: People who will Deposit/Withdraw money from bank branch, transfer funds online to
the registered payee and change profile on need basis.

Business Objectives

 Create a system which can be used as a single point of reference for all topics covered in the
course by implementing account management functionality for bank customer.

System Requirement Document Page 1 of 6

  This document will act as point of reference for the students and trainers. Students and trainers
will get clear idea about how different actors interact with the system.

User Stories for Customer Bank Account Management System

User stories are the basis for defining the functions a business system must provide, and
to facilitate requirements management. It captures the 'who', 'what' and 'why' of a requirement in
a simple, concise way, often limited in detail by what can be hand-written on a small paper note
card. The user story can be thought of as a piece of the work that the system is going to deliver.
Below are user stories identified and categorised in small units which can be shipped in a release.

Sr. Use Case User Story

No #
1. UCEQ01 As an Employee he can add new Customer/Account.

2. UCEQ02 As a Customer he can view his account summary.

3. UCEQ03 As a Customer he can register payee so that he can transfer funds

4. UCEQ04 As a Customer he can transfer funds to the registered payee

5. UCEQ05 As an Employee he can change User Status to Active, Inactive, Locked

6. UCEQ06 As an Employee he can deposit and deduct amount from Customer Account for
a cash related transaction at the bank

7. UCEQ07 As a User (Customer, Employee), he can change his password

8. UCEQ08 As a User (Customer, Employee), he can update profile details

9. UCEQ09 As a User (Customer, Employee), he can request new password on forgot

password

10. UCEQ10 As a User (Customer, Employee), he can login

11. UCEQ11 As a User (Customer, Employee), he can logout from the system

System Requirement Document Page 2 of 6

UCEQ01
User Story: As an Employee he can add new Customer/Account.
Add new Customer/Account flow:
1. Customer applies for the bank account
2. Bank employee fills in details on the basis of application form in the system.
3. Business related validations take place as a part of process in the system.
4. New Customer account gets created for the registered Customer automatically.
5. System generates random one time use password which is sent to user by post on the registered
address for first login

UCEQ02
User Story: As a Customer he can view his account summary.
View account summary flow:
1. On successful login Customer can view his account summary on home page
2. Every time customer clicks on home tab account summary will be shown to customer.

UCEQ03
User Story: As a Customer he can register payee so that he can transfer funds
Register payee flow.
1. Customer has payee account to be registered.
2. Customer Add payee account and system does business validations to validate payee account and
authenticate user for system security.
3. Payee gets added to Customer payee list
4. Customer can have multiple payees.

System Requirement Document Page 3 of 6

UCEQ04
User story: As a Customer he can transfer funds to the registered payee.
Transfer funds flow:
1. Customer selects payee from registered payee list.
2. Customer selects account to transfer fund from.
3. System shows account details when customer account is selected.
4. On fund transfer system does business validations to check payee account status as well as
minimum balance check on both the accounts.
5. Transferred amount is deducted from payer account and gets added to payee account on
successful transfer.

UCEQ05
User Story: As an Employee he can change User Status to Active, Inactive and Locked
Change User Status flow:
1. User reports some suspicious activity in the account and calls customer care. Person on support
from bank (Bank Employee) searches for user account and locks it for all user activities.
2. User Forgets password and does change password process and calls customer care for further
assistance. Bank employee does telephonic verification before changing user account status to
Inactive. System generates random password for one time use which will be sent to user by post.

UCEQ06
User Story: As an Employee he can deposit and deduct amount from Customer Account for a
cash related transaction at the bank.
1. Customer visits bank for cash deposit/withdrawal.
2. Customer fills up deposit/withdraw slip and goes to teller.
3. Teller (Employee) logs into the system and searches for Customer based on the details provided.
4. Teller selects appropriate action (deposit/withdraw) and updates the system after collecting/giving
the cash
5. Amount gets added/ deducted from Customer account after successful operation.

System Requirement Document Page 4 of 6

UCEQ07
User Story: As a User (Customer, Employee), he can change his password.
1. User needs to maintain account security by changing password frequently.
2. User selects change password from the tab list.
3. After authentication based on current password, new password is updated in the system
4. User is redirected to login screen for relogin.

UCEQ08
User Story: As a User (Customer, Employee), he can update profile details.
1. Customer/Employee logs in the website.
2. Customer updates only profile details which are editable like occupation email and mobile.
3. Employee updates only profile details which are editable like Qualification email and mobile
4. Customer/Employee address details can only be updated by authorised bank employee

UCEQ09
User Story: As a User (Customer, Employee), he can request new password on forgot password.
Forgot password flow:
1. User clicks on forgot password link available on login page.
2. User has to put id and registered mobile, email correctly for authentication.
3. System locks user account for any activity.
4. User calls customer care for further assistance as instructed on change password screen.
5. Bank employee changes user status to Inactive and system will generate random password for one
time use.
6. The one time password will be sent to user by post.

UCEQ10
User Story: As a User (Customer, Employee), he can login.
1. User fills in user Id, Password on login page.
2. If User status in the system is inactive then user is forced to change password on login using one
time use password.

System Requirement Document Page 5 of 6

 3. On successful authentication Customer will see customer home page and employee will see
employee home page both having different entitlements.

UCEQ11
User Story: As a User (Customer, Employee), he can logout from the system.
1. When user is done using system user clicks on logout button.
2. System clears user session and redirects user to login page.

System Requirement Document Page 6 of 6