EXPERIMENT NO.

AIM: To prepare a PROBLEM STATEMENT for BANK MANAGEMENT SYSTEM.

REQUIREMENTS:
Hardware Interfaces
 Minimum: Intel Core i3 processor, 4GB RAM.
 Recommended: Intel Core i5 or higher, 8GB RAM or more for better performance.
 Screen Resolution: At least 1366 x 768 for optimal UI display.
 Internet Connection: Required for online banking functionalities and real-time
transactions.
 Storage: Minimum 1GB free space for installation, database, and logging.
Software Interfaces
 Operating System: Windows 10/11, Linux, or macOS.
 Programming Language: Python 3.x / Java / C# (based on the chosen technology stack).
 Web Framework: Django/Flask (Python) or Spring Boot (Java) for web-based UI.
 Database: MySQL / PostgreSQL / MongoDB for secure transaction storage.
 APIs & Libraries:
 Pandas, NumPy (For financial calculations and data handling).
 NLTK (For text-based customer support/chatbot, if applicable).
 TensorFlow/PyTorch (For fraud detection or AI-based analysis, if included).
 Secure Authentication Modules (OAuth, JWT, or SSL for secure login).

THEORY:
Problem Identification:
Banks play a critical role in the financial ecosystem, and managing banking operations
efficiently is crucial for ensuring smooth customer service, regulatory compliance, and
financial security. Many banks and financial institutions still rely on outdated systems or
manual processes, leading to inefficiencies, security risks, and difficulties in managing
transactions.
Without an automated system, banks struggle with tracking customer accounts, processing
transactions securely, and generating financial reports for regulatory purposes. The lack of a
centralized banking system also makes it challenging to detect fraudulent activities, manage
loans effectively, and provide personalized banking services to customers.

1
Problems That Can Be Solved:

 Account Management Issues:

1. Difficulty in managing multiple customer accounts efficiently.
2. Challenges in updating account information in real-time.

 Transaction Processing Inefficiencies:

1. Time-consuming manual transaction processing.
2. Increased risk of human errors in transaction entries.
3. Difficulty in tracking and reconciling transactions.

 Customer Relationship Management (CRM):

1. Inadequate records of customer interactions and service history.
2. Lack of personalized banking services and targeted marketing.
3. Difficulty in managing customer feedback and complaints.
 Security and Fraud Detection:
1. Lack of robust authentication mechanisms, increasing fraud risks.
2. No real-time fraud detection system to prevent unauthorized transactions.
3. Delays in detecting suspicious activities or cyber threats.

Solution:
A Bank Management System can effectively address these challenges by automating processes
such as account management, transaction processing, customer relationship management,
compliance reporting, and employee monitoring. The system will enhance operational
efficiency, improve accuracy, and provide a better customer experience.

Conclusion
A Bank Management System is essential for modernizing banking operations by automating
core functions such as account management, transaction processing, loan handling, security,
and reporting. By implementing this system, banks can reduce manual errors, enhance
efficiency, improve security, and offer better customer service.
The ability to generate real-time financial insights enables banks to make informed decisions,
comply with regulations, and detect fraudulent activities proactively. Overall, this system

2
ensures a secure, efficient, and customer-friendly banking environment, providing a
competitive edge in the modern financial sector.

EXPERIMENT NO. 2

AIM: To prepare a SRS for BANK MANAGEMENT SYSTEM.

REQUIREMENTS:
Hardware Interfaces:
 Pentium(R) 4 CPU 2.26 GHz, 128 MB RAM

 Screen resolution of at least 800 x 600 required for proper and complete viewing of
screens. Higher resolution would not be a problem.

Software Interfaces:
 Any Windows-based operating system (Windows 95/98/2000/XP/NT)

 WordPad or Microsoft Word

THEORY:
A Software Requirement Specification (SRS) serves as a comprehensive description of the
functionalities, features, and technical requirements of a system. For an Online Food Ordering
System, the SRS defines how the system will handle order management, delivery tracking, inventory
control, and customer data management. It outlines the functional requirements such as user
registration, menu management, order placement, and payment processing. Additionally, non-
functional requirements like usability, performance, and data security are specified to ensure the
system operates efficiently under various conditions. The SRS also describes the system
architecture, including the client-server model and database design, along with assumptions like
internet connectivity and platform constraints. This document acts as a blueprint for developers to
design, implement, and maintain the Online Food Ordering System, ensuring all stakeholders have a
clear understanding of the project scope and objectives.

SRS Should Address the Following:

 Functional Requirements

 Non-Functional Requirements

 System Architecture

 User Interface Requirements

 Performance Requirements

3
  Security Requirements

 Assumptions and Constraints

 Data Flow and Storage

Characteristics of a Good SRS:

Characteristics of a Good Software Requirements Specification (SRS). A well-defined SRS document
is crucial for the success of any software project. Below are the key characteristics:

1. Correctness

 The SRS should correctly define all functionalities and constraints of the system.
 It should align with the actual user needs and system requirements.
 Each requirement should be verified for accuracy.

2. Completeness

 The document should cover all aspects of the system, including functional and non-
functional requirements.
 It must define all inputs, outputs, processing logic, and constraints.
 No essential requirement should be left undefined.

3. Unambiguity

 Requirements should be stated in clear, precise language to avoid confusion.

 Avoid words like "etc.," "approximately," or "to be determined."
 Use diagrams and models where necessary for better clarity.

4. Consistency

 There should be no conflicting or contradictory requirements.

 All terminologies should be used consistently throughout the document.
 Functional and non-functional requirements should complement each other.

5. Ranked for Importance and Stability

 Each requirement should be prioritized based on its importance and stability.

 Critical features should be clearly separated from optional enhancements.
 Stability ensures requirements remain applicable throughout the development cycle.

6. Modifiability

 The document should be structured so that changes can be made easily.

 Well-organized sections and numbering should be used.
 Requirements should be modular, reducing dependencies on unrelated sections.

7. Verifiability

 Each requirement should be testable through inspections, reviews, or testing.

 Quantifiable metrics should be used where applicable.

4
  If a requirement cannot be verified, it should be redefined.

8. Traceability

 Each requirement should have a unique identifier for easy reference.

 The document should provide a way to trace requirements to their source (e.g., customer
needs, legal compliance).
 Traceability also helps in verifying that all requirements are implemented.

9. Design Independence

 The SRS should specify what the system should do, not how it should do it.
 Avoid discussing implementation details, programming languages, or system architecture.
 This ensures flexibility in design choices during development.

10. Feasibility

 The requirements should be realistic and achievable within the given constraints (time,
budget, technology).
 If a requirement is too complex or expensive, alternative solutions should be considered.
 The document should identify any assumptions that affect feasibility.

SRS should address the following

The basic issues that the SRS shall address are the following:

a) Functionality. What is the software supposed to do?

b) External interfaces. How does the software interact with people, the system’s hardware,
other hardware, and other software?
c) Performance. What is the speed, availability, response time, recovery time of various
software functions, etc.?
d) Attributes. What are the portability, correctness, maintainability, security, etc.
considerations?
e) Design constraints imposed on an implementation. Are there any required standards in
effect, implementation language, policies for database integrity, resource limits, operating
environment(s) etc.?

5
A sample of basic SRS Outline
1. Introduction
1.1 Purpose
1.2 Document conventions
1.3 Intended audience
1.4 Additional information
1.5 Contact information/SRS team members
1.6 References

2. Overall Description
2.1 Product perspective
2.2 Product functions
2.3 User classes and characteristics
2.4 Operating environment
2.5 User environment
2.6 Design/implementation constraints
2.7 Assumptions and dependencies

3. External Interface Requirements

3.1 User interfaces
3.2 Hardware interfaces
3.3 Software interfaces
3.4 Communication protocols and interfaces

4. System Features
4.1 System feature
4.1.1 Description and priority
4.1.2 Action/result
4.1.3 Functional requirements
4.2 System feature B

5. Other Nonfunctional Requirements

5.1 Performance requirements
5.2 Safety requirements
5.3 Security requirements
5.4 Software quality attributes
5.5 Project documentation
5.6 User documentation

6
6. Other Requirements
Appendix A: Terminology/Glossary/Definitions list Appendix B: To be determined
Conclusion: The SRS was made successfully by following the steps described above.

S O F T WA R E R E QU I R E M E N T S
S P E C I F I C AT I O N

Bank Management System

Version 1.0
21 February, 2025

7
 Table of Contents

1. Introduction
 1.1 Purpose
 1.2 Document Conventions
 1.3 Intended Audience
 1.4 Additional Information
 1.5 Contact Information/SRS Team Members
 1.6 References
2. Overall Description
 2.1 Product Perspective
 2.2 Product Functions
 2.3 User Classes and Characteristics
 2.4 Operating Environment
 2.5 User Environment
 2.6 Design/Implementation Constraints
 2.7 Assumptions and Dependencies
3. External Interface Requirements
 3.1 User Interfaces
 3.2 Hardware Interfaces
 3.3 Software Interfaces
 3.4 Communication Protocols and Interfaces
4. System Features
 4.1 Account Management
 4.1.1 Description and Priority
 4.1.2 Action/Result
 4.1.3 Functional Requirements
 4.2 Transaction Management
 4.3 Loan Management
 4.4 Customer Support & Dispute Management
5. Other Nonfunctional Requirements
 5.1 Performance Requirements
 5.2 Safety Requirements
 5.3 Security Requirements
 5.4 Software Quality Attributes
 5.5 Project Documentation
 5.6 User Documentation
6. Other Requirements
 Appendix A: Terminology/Glossary/Definitions

8
 Appendix B: To Be Determined (TBD)

7. Conclusion

1. Introduction
1.1 Purpose

The Bank Management System (BMS) is designed to automate and streamline banking
operations, providing a secure and efficient platform for financial transactions, customer
management, and regulatory compliance. The system ensures seamless banking experiences by
integrating core functionalities such as account management, transaction processing, loan
management, and security monitoring.
Objectives:
 To provide an automated banking solution that improves efficiency and reduces manual
errors.
 To offer secure and real-time transaction processing.
 To enhance customer experience with personalized banking services.
 To enable seamless management of loans, credit, and repayments.
 To ensure compliance with banking regulations and security standards.
 To support multi-user access with role-based authentication and permissions.

1.2 Document Conventions

This document follows the IEEE Standard 830-1998 for Software Requirements Specifications.
The conventions used throughout the document are:
 Bold Text – Used for section headings and important terms.
 Italic Text – Used for emphasis or defining key concepts.
 Monospace Text – Used for system commands, database queries, or code snippets.
 Numbered Sections – To ensure structured documentation and easy reference.
 Tables and Lists – Used for structured representation of data.
All requirements and functional descriptions will be defined clearly to avoid ambiguity.

1.3 Intended Audience

This document is intended for the following stakeholders:

1.3.1 Developers
 To understand and implement system requirements.
 To design and develop the backend, frontend, and database.
1.3.2 Project Managers

9
  To ensure development aligns with business objectives and project timelines.
 To allocate resources and track project progress.
1.3.3 QA Testers
 To create test cases based on functional and non-functional requirements.
 To validate system performance, security, and usability.
1.3.4 Business Stakeholders (Bank Owners, Investors, Regulators)
 To assess system feasibility and business impact.
 To ensure compliance with financial and legal regulations.
1.3.5 End Users (Bank Employees, Customers, Administrators)
 Customers will use the system for account management and transactions.
 Bank administrators will manage operations, accounts, and financial records.
 Employees will process customer queries and ensure smooth banking operations.

1.4 Additional Information

The Bank Management System is designed as a web-based and mobile application to ensure
accessibility and efficiency. The system will support the following key functionalities:
1.4.1 User Roles & Features
 Customers: Open accounts, manage transactions, apply for loans, and access banking
services.
 Bank Admins: Manage accounts, process transactions, review loan applications, and
generate reports.
 Employees: Assist customers, verify transactions, and handle complaints.
1.4.2 System Components
 Frontend: Web and mobile UI for customers and banking staff.
 Backend: APIs and database management for financial operations.
 Database: Secure storage for customer profiles, transaction records, and financial data.
 Payment Gateway: Secure integration for fund transfers and bill payments.
 Notifications: SMS, email, and push notifications for account activities.
1.4.3 Security Measures
 User Authentication: Multi-factor authentication for secure access.
 Data Encryption: Industry-standard encryption for sensitive data.
 Role-Based Access Control: Restricted access levels for different users.
1.5 References

This document is based on the following standards and references:

 IEEE Std 830-1998 – Recommended Practice for Software Requirements Specifications.
 Banking regulations and compliance guidelines.
 Best practices for online financial transactions and data security.

10
2. OVERALL DESCRIPTION

2.1 Product Perspective

The Bank Management System (BMS) is an online platform designed to manage core banking
operations, customer accounts, transactions, and loans seamlessly. It acts as a centralized system,
enabling customers to access their accounts, perform transactions, and apply for loans, while bank
staff manage customer records, approve transactions, and generate financial reports.

System Integration:

 The system will integrate with third-party payment gateways for secure online transactions
(e.g., Razorpay, PayPal, UPI).
 KYC Verification APIs will be integrated for customer identity verification.
 Credit Score Services to assess loan eligibility.
 SMS/Email Services for transaction notifications and alerts.

Type of System:

 Web Application: For bank staff and admin users.

 Mobile Application: For customers to access banking services on Android and iOS devices.
 Cloud-Based Architecture: To ensure scalability, data redundancy, and real-time updates.

2.2 Product Functions

The Bank Management System will provide the following key functionalities:

2.2.1 Customer Features:

 User Registration/Login: Customers can create accounts, log in securely, and reset
passwords.
 Account Management: View account details, balances, and transaction history.
 Fund Transfers: Transfer money between accounts or to external accounts.
 Loan Management: Apply for loans, view repayment schedules, and track EMI payments.
 Payment Integration: Pay bills, credit card dues, and other financial obligations.
 Notifications & Alerts: Get SMS/email alerts for transactions, loan approvals, or account
changes.

2.2.2 Bank Staff Features:

 Customer Management: Create, update, and delete customer records.

 Transaction Approval: Review and approve high-value or flagged transactions.

11
  Loan Processing: Verify customer documents, assess eligibility, and approve/reject loans.
 Cash Flow Management: Monitor bank cash reserves and transaction volumes.

2.2.3 Admin Panel Features:

 User Management: Manage bank employees, assign roles, and monitor activities.
 Audit & Compliance Monitoring: Generate detailed reports for audits and regulatory
compliance.
 Security Management: Configure security policies, manage access controls, and monitor
system logs.

2.3 User Classes and Characteristics

The system caters to multiple user roles, each with specific access rights and capabilities:

 Customers: Perform personal banking functions (e.g., fund transfers, bill payments, loan
applications).
 Bank Tellers: Handle over-the-counter services, process customer requests, and assist with
account issues.
 Loan Officers: Review and approve loan applications, monitor repayments, and assess credit
scores.
 System Administrators: Manage overall system settings, user permissions, and security
protocols.

2.4 Operating Environment

The Bank Management System will operate under the following environments:

2.4.1 Hardware Requirements:

 For Customers: PC, laptop, or smartphone with internet access.

 For Bank Staff: Desktops or laptops with secure VPN access.
 For Servers: High-performance cloud servers for data storage and processing.

2.4.2 Software Requirements:

 Web Application: Compatible with Chrome, Firefox, and Edge.

 Mobile Application: Android (Android 8+) and iOS (iOS 12+).
 Backend: Built with Node.js, Python, or Java, using MySQL/PostgreSQL for database
management.
 Hosting: AWS, Azure, or Google Cloud for reliable and scalable hosting.

2.4.3 Network Requirements:

12
  Internet Connection: Required for online banking, with a recommended speed of 5 Mbps or
higher.
 VPN Access: For bank employees to access the system securely from remote locations.

2.5 User Environment

The system is designed for both personal and corporate use:

 Customer Environment: Home, office, or on the go via mobile devices or personal
computers.
 Bank Branch Environment: Bank premises, with secured network access for internal
systems.

2.6 Design/Implementation Constraints

 Performance Constraints: The system must support thousands of concurrent users and
transactions.
 Security Constraints: Multi-factor authentication, data encryption, and regular penetration
testing.
 Regulatory Constraints: Compliance with GDPR, PCI DSS, and national banking regulations.
 Technical Constraints: Support for RESTful APIs for third-party service integrations (e.g.,
credit score providers).

2.7 Assumptions and Dependencies

 Stable Internet Connection: Users and bank staff will require internet access to use the
system.
 Third-Party Services: Payment gateways, KYC verification, and credit score services must be
operational.
 Timely System Updates: Regular system updates will be needed to maintain security and
compliance.

3. EXTERNAL INTERFACE REQUIREMENTS

3.1 User Interfaces
The Bank Management System (BMS) will provide intuitive and secure interfaces to enhance
user experience across various devices. The interfaces will be designed for customers, bank
staff, loan officers, and system administrators.
3.1.1 Web Interface:
 Responsive UI: Adapts to different screen sizes (desktop, tablet, mobile).
 Navigation Menu: For accessing accounts, transactions, loans, and reports.

13
  Dashboard: Real-time account summary, balance updates, and transaction history.
 Form-Based Inputs: For creating new accounts, applying for loans, and initiating
transactions.
 Notifications Panel: For alerts on transactions, loan approvals, or suspicious activities.
3.1.2 Mobile App Interface (Android & iOS):
 Secure Login: Multi-factor authentication (e.g., OTP, biometrics).
 Quick Access Features: View balances, transfer funds, and pay bills with a few taps.
 Push Notifications: For transaction confirmations, security alerts, and reminders.
 Dark Mode & Accessibility Features: For enhanced usability.
3.1.3 Bank Staff Dashboard:
 Customer Management Panel: Search, view, and manage customer profiles.
 Transaction Monitoring: Real-time logs of high-value and flagged transactions.
 Loan Management: Track applications, approvals, and overdue payments.
 Report Generation: For financial summaries, cash flow, and regulatory compliance.
3.1.4 Admin Interface:
 Role-Based Access Control: Manage employee access and permissions.
 Audit Logs: Track user activities and system events.
 System Health Monitor: View server performance and security logs.

3.2 Hardware Interfaces

The system will interact with various hardware components to ensure smooth operations.
 Customer Devices: Smartphones, tablets, laptops, desktops.
 Bank Branch Devices: Desktops, cash counters, check scanners, receipt printers.
 ATM Machines: For cash withdrawals, balance inquiries, and deposits.
 Servers: Cloud-based and on-premise servers for hosting applications and databases.

3.3 Software Interfaces

14
The Bank Management System will integrate with multiple third-party services and APIs.
 Operating Systems: Compatible with Windows, macOS, Linux, Android, and iOS.
 Database Management: MySQL, PostgreSQL for structured data storage.
 Payment Gateways: Razorpay, Stripe, PayPal, UPI, SWIFT for secure transactions.
 KYC & Credit Score APIs: For customer identity verification and loan eligibility checks.
 Notification Services: Twilio, SendGrid for email, SMS, and push notifications.

3.4 Communication Protocols and Interfaces

The system will use secure communication protocols to safeguard data and ensure seamless
connectivity.
 Client-Server Communication: HTTPS for secure data transmission.
 Database Communication: SQL queries for structured data retrieval.
 Payment Processing: SSL encryption and OAuth 2.0 authentication.
 Real-Time Features: WebSockets for live transaction updates and notifications.

4. SYSTEM FEATURES
4.1 System Feature: Account Management
4.1.1 Description and Priority
Description:
The system allows customers to create and manage bank accounts, view balances, update
personal information, and close accounts when necessary.
Priority:
 High (Essential for core functionality)

4.1.2 Action/Result
Action:
 Users sign up and provide KYC details for account creation.
 Users view account balances, recent transactions, and account statements.
 Users can update contact information, request checkbooks, or close accounts.
Result:
 The system updates the customer database in real-time.
 Users receive confirmation via SMS or email for any account changes.

15
  Admins can verify KYC details and approve or reject account creation requests.
4.1.3 Functional Requirements
 The system must allow secure account creation and deletion.
 The system should display real-time account balances.
 Users should receive notifications for any changes to account details.

4.2 System Feature: Transaction Management

4.2.1 Description and Priority

Description:
The system processes deposits, withdrawals, and fund transfers, ensuring transactions are
secure, fast, and accurate.
Priority:
 High (Essential for transaction processing)

4.2.2 Action/Result

Action:
 Users initiate deposits, withdrawals, or transfers through the web or mobile app.
 The system validates account details and checks for sufficient funds.
 The transaction is processed, and users receive a digital receipt.
Result:
 Transactions are logged with timestamps.
 Users get real-time notifications for successful or failed transactions.
 Bank staff can monitor and verify high-value transactions.

4.2.3 Functional Requirements

 The system must support real-time transactions.

 The system should automatically generate transaction IDs.
 Users should receive instant confirmation of transaction status.

4.3 System Feature: Loan Management

4.3.1 Description and Priority

Description:
The system automates loan applications, approvals, and repayment tracking, ensuring an
organized loan lifecycle.
Priority:
 High (Critical for loan services)

16
4.3.2 Action/Result

Action:
 Customers apply for loans and upload necessary documents.
 The system assesses credit scores and calculates eligibility.
 Loan officers review applications and either approve or reject them.
Result:

 Approved loans are added to the customer’s account.

 Users receive notifications on loan status and upcoming EMI payments.
 The system automatically deducts EMIs on scheduled dates.

4.3.3 Functional Requirements

 The system must validate customer credit scores.

 The system should generate repayment schedules.
 Users should get reminders for due EMIs.

4.4 System Feature: Customer Support & Dispute Management

4.4.1 Description and Priority

Description:
The system provides an integrated customer support portal for resolving disputes, handling
complaints, and offering live assistance.
Priority:
 Medium (Important for customer satisfaction)

4.4.2 Action/Result

Action:
 Users submit support tickets or live chat with support agents.
 The system categorizes issues (e.g., failed transactions, loan queries, fraud alerts).
 Support agents review cases, communicate with customers, and resolve issues.
Result:
 Users receive status updates and resolutions via email or SMS.
 The system logs and archives resolved disputes for future reference.
 Bank admins can analyze support data to improve services.

4.4.3 Functional Requirements

17
  The system must allow users to submit support requests.
 Support tickets should be tracked and categorized.
 The system should provide automated responses for common issues.

5. OTHER NON FUNCTIONAL REQUIREMENTS

5.1 Performance Requirements

 The system should handle at least 1000 concurrent users without lag.
 Response time for key actions (e.g., fund transfers, account balance checks) should be
less than 3 seconds.
 The system should process at least 10,000 transactions per hour during peak times.
 The database should support high availability and fast retrieval of transaction history.
 The web and mobile apps should load within 2-5 seconds on a standard 4G network.

5.2 Safety Requirements

 The system must ensure safe handling of financial data with regular backups and
disaster recovery.
 Transactions must be reversible within a set time frame to address accidental or
fraudulent activity.
 Session timeouts should automatically log users out after inactivity.
 Fraud detection mechanisms should monitor unusual account activities.
 Emergency Shutdown Protocol: The system should allow admins to initiate a
shutdown in case of a major security breach.

5.3 Security Requirements

 All user passwords must be encrypted using secure hashing algorithms (e.g., bcrypt).
 Financial transactions must comply with PCI DSS and AML (Anti-Money Laundering)
standards.
 The system should implement multi-factor authentication (MFA) for critical
operations.
 Users' personal and financial data must be stored securely, adhering to GDPR or local
data privacy laws.
 API requests should be protected using OAuth 2.0 and JWT authentication.
 Regular security audits and penetration testing should be conducted to identify
vulnerabilities.

18
  Data Masking: Sensitive data (like credit card numbers) should be masked or tokenized
to prevent exposure.
5.4 Software Quality Attributes

 Usability: The interface should be intuitive and accessible for all users, including those
with disabilities.
 Reliability: The system should have 99.9% uptime with automatic failover capabilities.
 Scalability: The platform should scale to support growing users and transaction
volumes.
 Maintainability: The system should follow a modular architecture for easier updates
and debugging.
 Portability: The system should function seamlessly across web browsers, Android, and
iOS devices.
 Interoperability: The system should be able to integrate smoothly with third-party
banking services, government APIs, and external auditing tools.

5.5 Project Documentation

 System Requirement Specification (SRS) Document: Outlines all functional and

nonfunctional requirements.
 Software Design Document (SDD): Covers system architecture, database design, and
workflows.
 Test Plan Document: Lists test cases, testing strategies, and quality assurance
protocols.
 Deployment Guide: Instructions for server setup, database configuration, and system
deployment.
 Maintenance Guide: Details for regular updates, security patches, and support
procedures.
 Compliance Guide: A document detailing the system's adherence to relevant laws and
standards.

5.6 User Documentation

 User Manual: Step-by-step guide for account management, transactions, and customer
support.
 FAQs and Troubleshooting Guide: Answers common user queries and troubleshooting
tips.
 Help Center: A dedicated support portal with chatbot assistance and live chat options.

19
  Training Material: Video tutorials and onboarding resources for new users and staff.
 Admin Handbook: A guide specifically for system administrators, detailing advanced
features and emergency protocols.
6. OTHER REQUIREMENTS
This section includes additional constraints, legal considerations, and future requirements to
ensure the system remains compliant, adaptable, and ready for future enhancements.
 Regulatory Compliance: The system must adhere to local and international banking
regulations (e.g., Basel III, GDPR, PCI DSS, AML laws).
 Third-Party Integration: The system should seamlessly integrate with external financial
services, like credit score providers, tax calculation tools, and government portals for
identity verification (e.g., KYC/AML checks).
 Localization & Multi-Currency Support: The system should support multiple
languages and currencies to accommodate global users.
 AI-Based Insights: Future updates could include AI-powered financial advice, fraud
detection, and personalized product recommendations.
 Blockchain Integration: For enhanced transaction transparency and security, future
versions could support blockchain-based ledgers.
 Voice-Enabled Banking: Future iterations could support voice commands for
transactions, balance checks, and customer service interactions.
 Sustainability Measures: The system could implement eco-friendly practices, like
paperless statements and energy-efficient server infrastructure.

Appendices
 Appendix A: Terminology/Glossary/Definitions
 Account ID: A unique identifier assigned to each bank account.
 SWIFT/BIC Code: A unique code identifying a specific bank during international
transactions.
 KYC (Know Your Customer): A process used to verify customer identities.
 Loan ID: A unique identifier for tracking loans and repayment schedules.
 Payment Gateway: A service that processes online transactions (e.g., Stripe,
PayPal, Razorpay).
 User Roles: Categories of users such as Customers, Tellers, Loan
Officers, Branch Managers, and System Admins.

 Appendix B: To Be Determined (TBD)

 Selection of payment gateway providers for different regions.
 Implementation of AI-powered financial recommendations.
 Addition of biometric authentication for high-security transactions.
20
  Expansion to international markets based on scalability tests.

7. CONCLUSION

The Bank Management System is designed to modernize and streamline banking operations,
enhancing convenience, security, and efficiency for customers, bank staff, and administrators.
This Software Requirement Specification (SRS) document outlines the system's core
functionalities, nonfunctional requirements, and external interfaces to ensure a complete
understanding of the project's scope.

By implementing secure transactions, automated account management, and intelligent loan

processing, the system will provide a seamless experience for all users. The scalability,
performance, and compliance considerations detailed in this document lay a strong
foundation for future enhancements, such as AI-driven financial insights, blockchain security,
and voice-enabled banking services.

Furthermore, the system’s role-based access control and fraud detection mechanisms will
help safeguard sensitive data and prevent unauthorized activities. The ability to generate real-
time financial reports and predictive analytics will empower bank administrators to make
informed decisions and strategically plan for growth.

Moving forward, this document will act as a blueprint for developers, designers, and
stakeholders, guiding them through the system’s development, testing, and maintenance
phases. Regular updates and continuous integration will ensure that the system remains
adaptable to changing market trends, customer expectations, and regulatory requirements.

With a focus on innovation, customer satisfaction, and operational excellence, the Bank
Management System is well-positioned to adapt to the evolving financial landscape and
deliver long-term value to its users.

21
 EXPERIMENT NO. 3

AIM: To draw a sample ENTITY RELATIONSHIP DIAGRAM for real project or system.

REQUIREMENTS:
Hardware Interfaces
 Minimum: Intel Core i3 processor, 4GB RAM.
 Recommended: Intel Core i5 or higher, 8GB RAM or more for better performance.
 Input Devices: Standard keyboard and mouse.
 Display: Colored monitor with at least 800x600 resolution.
Software Interfaces
 Operating System: Windows 10/11, Linux, or macOS.
 ER Diagram Tool: Rational Rose or any ER modeling tool.
 Development Tools: Any text editor or IDE (e.g., Visual Studio Code, Eclipse).

THEORY:
Entity Relationship Diagrams (ERDs) play a vital role in designing the structure of any system
or projects (e.g. Bank Management System). They provide a visual representation of how
various entities within a system are interconnected, making it easier to understand and build a
well-organized, efficient database. By modeling these relationships, analysts can ensure data
integrity, reduce redundancy, and enable smooth data retrieval.
Entities:
In a bank, entities represent objects or concepts that hold data. For instance, customers,
accounts, loans, transactions, employees, and branches are all critical components of the
system. Each of these entities has specific attributes that store relevant information. For
example, a Customer entity may include attributes like Customer ID, Name, Address,
and Phone Number, while an Account entity may include Account Number, Account Type,
and Balance.

Relationships:
The relationships between entities are equally important. A Customer can hold
multiple Accounts, but each Account is associated with only one Customer. Similarly,

22
an Account can have multiple Transactions, but each Transaction belongs to a single Account.
In the case of loans, a Customer may apply for multiple Loans, and each Loan will have details
like loan amount, interest rate, and repayment schedule.
Cardinality:
Cardinality helps define the nature of these relationships. For example, the one-to-
many relationship between Customer and Account ensures that a customer can have multiple
accounts, but an account cannot belong to multiple customers. In cases where many-to-
many relationships exist, like customers applying for multiple loans, these can be resolved
using associative entities.
Each entity is uniquely identified by a primary key. For instance, Customer ID uniquely
identifies a customer, while Account Number uniquely identifies an account. These keys are
essential for establishing relationships and ensuring data integrity.
By carefully mapping out entities, attributes, and relationships, an ERD helps lay the
foundation for a robust Bank Management System. It ensures that data is stored logically,
reduces duplication, and makes future modifications or expansions to the system easier.

Attributes:
A data attribute is a characteristic common to all or most instances of a particular entity.
Attributes store important information about entities, helping define their unique
characteristics. For example, attributes of the Customer entity include Customer
ID, Name, Address, and Phone Number. Similarly, the Account entity may have attributes
like Account Number, Account Type, and Balance.

AN ENTITY RELATIONSHIP DIAGRAM METHODOLOGY: (One way of doing it)

23
A SIMPLE EXAMPLE

A bank has several branches. Each branch has a manager and at least one employee.
Customers must have at least one account, but they can hold multiple accounts.Customers can
apply for loans, but not every customer will have a loan. The key data fields include the names
of customers, employees, and branches, as well as unique identifiers like account numbers,
loan IDs, customer IDs, and employee IDs.
1. Identify Entities
The entities in this system are Branch, Customer, Employee, Account, and Loan.One might
consider Bank itself as an entity, but it would be a false entity because it represents only
one instance in this scenario. True entities must have multiple instances.
2. Find Relationships
We construct the following Entity Relationship Matrix:

24
3. Draw Rough ERD
We connect the entities whenever a relationship is shown in the entity Relationship
Matrix

4. Fill in Cardinality
 A bank has one or more branches, but each branch belongs to only one bank.
 A branch can serve multiple customers, and a customer can interact with
multiple branches.
 A customer can hold multiple accounts, but each account belongs to only
one customer.
 A branch can offer multiple loans, and a customer can take multiple loans from one or
more branches.
 An account can have multiple transactions, but each transaction is linked to exactly
one account.

5. Define Primary Keys:

In the bank management system, the primary keys are essential for uniquely identifying

25
entities. These include Bank ID, Branch ID, Customer ID, Account Number, Employee ID,
and Transaction ID. These keys ensure each entity instance is distinct and easily accessible.

6. Draw Key-Based ERD:

The rough ERD contains many-to-many relationships that need resolution. For instance,
a Branch can serve multiple Customers, and a Customer can belong to multiple Branches.
Similarly, a Branch can employ multiple Employees, and an Employee can work at one or
more Branches. To handle this, we introduce associative entities like Branch-
Customer and Branch-Employee with composite keys (Branch ID + Customer ID and Branch ID
+ Employee ID, respectively).

7. Identify Attributes:
Each entity carries essential attributes. Bank has attributes like Bank Name and Bank
ID. Branch includes Branch Name, Branch ID, and Location. Customer contains details such
as Customer ID, Name, Address, and Phone. Account tracks Account Number, Type, Balance,
and Creation Date. Bank Employee includes Employee ID, Name, Position, and Salary.
Finally, Transaction captures Transaction ID, Amount, Date, and Type.
8. Map Attributes

9. Draw Fully Attributed ERD

26
10. Check Results
The final Bank Management System ERD accurately models the data flow and relationships. It
captures entities like Bank, Customer, Account, Transaction, and Employee with their key
attributes and connections. The diagram reflects real-world scenarios, such as customers
holding multiple accounts and employees managing transactions.

FURTHER DISCUSSIONS
Step 1: Identify Entities
Entities represent real-world objects or concepts, like Customer, Account, Transaction, Bank
Employee, and Branch. Entities can be identified by consulting users or reviewing forms and
reports.
Step 2: Find Relationships
Key relationships include:
 Customer opens Accounts (1:M)
 Account belongs to one Branch (M:1)
 Branch employs Bank Employees (1:M)
 Employee processes Transactions (1:M)
 Customer requests Services (1:M)

27
Step 3: Draw Rough ERD
An initial ERD shows entities as rectangles and relationships as diamonds, capturing core
connections without detailed attributes or keys.
Step 4: Fill in Cardinality
Define relationship constraints:
 One customer → many accounts
 One branch → many customers
 One employee → many transactions

Step 5: Define Primary Keys

Each entity has a unique identifier:
 Customer → Customer ID
 Account → Account Number
 Transaction → Transaction ID
 Bank Employee → Employee ID
 Branch → Branch ID

Step 6: Handle Many-to-Many Relationships

Introduce associative entities to resolve many-to-many relationships:
 Customer-Account → (Customer ID + Account Number)
 Employee-Transaction → (Employee ID + Transaction ID)

Step 7: Identify Attributes

Key attributes for each entity:
 Customer: ID, Name, Address, Phone, Email
 Account: Number, Type, Balance, Date Opened
 Transaction: ID, Date, Amount, Type
 Bank Employee: ID, Name, Position, Salary
 Branch: ID, Location, Manager

Step 8: Map Attributes

Link attributes to entities:

 Customer Name → Customer

 Account Number → Account
 Transaction Type → Transaction
 Employee Position → Bank Employee

28
  Branch Location → Branch

Step 9: Draw Fully-Attributed ERD

With entities, relationships, keys, and attributes identified, refine the ERD for clarity — placing
central entities in the middle to reduce line crossings.

Step 10: Check Results

The final ERD should accurately represent banking processes, handling tasks like account
creation and transaction processing. Double-check cardinalities and attributes to ensure nothing
is missing.

EXPERIMENT NO. 4

AIM: To prepare DATA FLOW DIAGRAM for real project or system.

REQUIREMENTS:
Hardware Interfaces
 Minimum: Intel Core i3 processor, 4GB RAM.

29
  Recommended: Intel Core i5 or higher, 8GB RAM or more for better performance.
 Input Devices: Standard keyboard and mouse.
 Display: Colored monitor with at least 800x600 resolution.
Software Interfaces
 Operating System: Windows 10/11, Linux, or macOS.
 WordPad or Microsoft Word for documentation and report generation.

THEORY:
Data Flow Diagrams (DFD):
A Data Flow Diagram (DFD) visually represents how data flows through a system. It
highlights the sources, processes, and storage points that the data interacts with.

Purpose of DFD in Bank Management System:

 To illustrate how customer data, account details, and transactions are managed.
 To show the relationship between external entities (such as customers and
regulatory bodies) and the internal processes of the system.
 To provide a clear understanding of data input, processing, and output in a bank
management system.

Data Flow Diagram Notations

You can use two different types of notations on your data flow diagrams: Yourdon & Coad
or Gane & Sarson.

Process:

30
A process transforms incoming data flow into outgoing data flow.
Yourdon and Coad Notation:
 A process transforms incoming data into outgoing data.
 Represented by a circle or a rectangle with rounded corners.

Gane and Sarson Notation:

 Process: Represented by a rounded rectangle.
 Represents data transformation.

Datastore:
Datastores are repositories of data in the system. They are sometimes also referred to as
files.

Dataflow Notations:
Dataflows are pipelines through which packets of information flow. Label the arrows with
the name of the data that moves through it.

31
HOW TO DRAW DATA FLOW DIAGRAMS

Data Flow Diagram Layers

Draw data flow diagrams in several nested layers. A single process node on a high-level
diagram can be expanded to show a more detailed data flow diagram. Draw the context
diagram first, followed by various layers of data flow diagrams.
The Context Diagram (Level 0 DFD) depicts the system as a single process interacting with
external entities like customers and administrators.

Level 1 DFD expands this by detailing key processes such as account management and
transaction processing.
Level 2 DFD further breaks down these processes into specific tasks like customer
registration and fund transfers. These layers enhance clarity, helping both technical and
non-technical stakeholders visualize data flow and system interactions effectively.

32
Context Diagram (Level 0 DFD)
The Level 0 DFD for the Bank Management System (BMS) shows the system as a single
process interacting with:
 Customer: The customer initiates actions such as account registration, login,
balance inquiry, fund transfer, and loan applications. The system processes these
requests and provides relevant responses like account information, transaction
status, or loan details.
 Bank Administrator: The admin manages account updates, transaction
monitoring, and system maintenance. Admin inputs are processed to ensure
smooth system operations.
 Payment Gateway:Payment gateways handles secure transaction processing.
The system processes these inputs and provides relevant responses, ensuring
smooth operations.

Level-0 DFD — Bank Management System

Level 1 DFD for Bank Management System

The Level 1 DFD of the Bank Management System (BMS) provides a detailed view of
the major processes involved in handling customer transactions and internal
operations. It breaks down the context diagram into key processes that interact with
external entities and databases.

33
 Level-1 DFD — Bank Management System

Level 2 DFD for Bank Management System

Account Management System:

 Enables customers to access banking services by providing their details.
 Manages customer profiles, service requests, and sends data to other
systems like Transaction and Loan Management.
 Generates real-time account activity reports by extracting data from
associated databases.

34
 Level-2 DFD — Account Management System

Transaction Management System:

 Facilitates secure fund transfers and balance inquiries.
 Cashiers may assist with transaction processes, ensuring accuracy and
efficiency.
 Updates transaction records in the database upon successful completion of
transactions.

Level-2 DFD — Transaction Management System

Loan Management System:

 Allows customers to apply for loans and submit relevant details.
 Managers access the Loan_Details database to review, approve, or reject loan
applications.
 Enables banks to modify and update loan policies to align with business
requirements.

35
 Level-2 DFD — Loan Management System

Online Banking System:

 Provides a range of value-added services such as insurance, bill payments,
and other online services.
 Ensures seamless integration with external APIs for secure processing of
online transactions.

Level-2 DFD — Online Banking System

CONCLUSION:

The Data Flow Diagram (DFD) for the Bank Management System was created
successfully following the appropriate steps. The diagrams provide a clear
understanding of the system's workflow and interaction with external entities.
These diagrams will help in understanding, analyzing, and designing the system
effectively.

36
 EXPERIMENT NO. 5

AIM: Steps to draw the Use Case Diagram of Bank Management System using Rational Rose.
REQUIREMENTS:
Hardware Requirements:

 Minimum: Intel Core i3 processor, 4GB RAM

 Recommended: Intel Core i5 or higher, 8GB RAM or more for better performance
 Input Devices: Standard keyboard and mouse
 Display: Colored monitor with at least 800x600 resolution

Software Requirements:
 Operating System: Windows 10/11, Linux, or macOS
 WordPad or Microsoft Word for documentation and report generation
 Rational Rose

THEORY:
A Use Case Diagram is a type of UML diagram that represents the functional behavior of a
system from the perspective of end-users or external systems. It illustrates how different users
interact with the system to achieve specific goals through various use cases. Each use case
signifies a distinct function that may be automated or manual.

Use Case Diagrams help visualize the system's requirements and interactions in a simplified
manner without specifying the sequence of operations. These diagrams serve as an essential
tool for understanding, analyzing, and communicating the system's functional scope and
provide a clear context of the software being developed.

Use Case Diagrams in a Bank Management System (BMS) are particularly useful for:

 Capturing banking functionalities from the users' perspective.

 Demonstrating interactions between customers, staff, and system processes.
 Presenting an overview of core banking services and external interactions.

Key Concepts:

1. Use Cases:

37
A use case describes a sequence of actions that provide a measurable value to an actor. It is
drawn as a horizontal ellipse in a UML use case diagram.
In the BMS, the following use cases are commonly identified:
 Login
 View Account Details
 Withdraw Cash
 Deposit Cash
 Fund Transfer
 Bill Payment

Guidelines:
 Begin names with strong action verbs.
 Use domain-specific banking terminology.
 Place primary use cases in the top-left of the diagram.
 Use vertical stacking to suggest execution sequence.

2. Actors:
An actor is any user or system that interacts with the BMS. Actors typically include:
 Customer
 Cashier
 Manager
 Bank Headquarters (System Actor)

Guidelines:
 Place primary actors in the top-left.
 Draw actors outside the system boundary.
 Use singular, relevant business terms.
 Associate each actor with at least one use case.
 Use <> for non-human actors.
 Actors represent roles, not job positions.
 Use "Time" actor for scheduled actions if needed.

3. Relationships:
There are several relationship types in use case diagrams:
 Association between actor and use case
 Association between use cases
 Generalization among actors
 Generalization among use cases

Guidelines:

38
  Link actors and use cases only when relevant to the logic.
 Avoid arrowheads on actor-use case associations.
 Generalize only when significant behavior changes.
 Avoid deep nesting of associations.
 Use position and layout to indicate include/extend logic.

4. System Boundary Boxes:

A rectangle that encloses use cases and defines the functional boundary of the Bank
Management System’s Use Case diagram.
Guidelines:
 Clearly indicate scope with the boundary box.
 Avoid empty or redundant boundary boxes.

Creating Use Case Diagram:

1. Identify all relevant actors such as Customer, Manager, Cashier, and Bank Headquarters.
2. Determine primary use cases like Login, View Account Details, Fund Transfer,
Withdraw/Deposit Cash, Bill Payment, and Apply for Loan.
3. Draw associations between actors and their use cases

Procedure (for Rational Rose):

 Click on the File menu New.

39
 Now from the Dialogue Box that appears, select the language which you want to use for
creating your model.

 In the left hand side window of Rational Rose right click on Use Case view and select
New>Use

40
 Enter the name of new Use Case file in the space provided, and then click on that file name

 You can now use the window that appears on right hand side to draw your Use Case
diagram using the buttons provided on the vertical toolbar.

Conclusion: The use case diagram for the Bank Management System was successfully
created using Rational Rose. It visualizes actors and their interactions with system
processes, aiding in understanding the overall functional scope.

41
Sample Use Case Diagrams is given below:

USE CASE DIAGRAM FOR BANK MANAGEMENT SYSTEM

42
 EXPERIMENT NO. 6

AIM: To draw a sample Activity Diagram for a real system – the Bank Management System.
REQUIREMENTS:
Hardware Requirements:

 Minimum: Intel Core i3 processor, 4GB RAM

 Recommended: Intel Core i5 or higher, 8GB RAM or more for better performance
 Input Devices: Standard keyboard and mouse
 Display: Colored monitor with at least 800x600 resolution

Software Requirements:
 Operating System: Windows 10/11, Linux, or macOS.
 UML Modeling Tool: Rational Rose or any compatible UML software.

THEORY:
UML 2 Activity Diagrams are widely used in modeling business processes and operational
logic. In the context of a Bank Management System , these diagrams help visualize the
workflow of banking services such as account management, transaction handling, loan
processing, and customer service routines.

While activity diagrams can be used to model internal logic, they are best suited for
workflows or usage scenarios. They are the object-oriented equivalent of traditional
flowcharts and data flow diagrams. Each activity diagram begins at an initial node and ends
at an activity final node, which provides a complete picture of the control flow.

Basic Notations in the Bank Management System Context:

 Initial Node: A filled circle representing the start of a banking process (e.g., customer
login).
 Activity: Rounded rectangles representing actions like "Verify User Credentials",
"Deposit Money", or "Generate Statement".
 Decision: A diamond shape used to determine logic branches, such as [Sufficient
Balance?].

43
  Merge: Combines multiple flows, for example, from different service requests back to a
common end.
 Fork: A black bar indicating the start of parallel tasks like notifying both customer and
bank admin.
 Join: A black bar where parallel flows converge.
 Condition (Guard): Labels such as [Valid Account], [Loan Approved] on flows.
 Partition (Swimlane): Vertical divisions indicating roles such as Customer, Cashier,
Manager.
 Sub-activity Indicator: A rake symbol to indicate a subprocess like "Loan Evaluation".
 Flow Final: A circle with an X showing termination of a particular branch in the process.

GUIDELINES ASSOCIATED FOR DRAWING AN ACTIVITY DIAGRAM

1. General Guidelines
2. Activities
3. Decision Points
4. Guards
5. Parallel Activities
6. Swimlane Guidelines
7. Action-Object Guidelines

1. General Guidelines
To draw an effective activity diagram for the Bank Management System, begin by placing the
start point in the top-left corner using a filled-in circle, as this aligns with natural reading
patterns. Every diagram should include an end node—a circle with a border—to indicate
process completion. If a process is overly complex and difficult to diagram clearly, it is often a
signal that the process should be refactored into simpler components.

2. Activities
Activities should represent specific banking actions such as "Transfer Funds" or "Update
Balance". Avoid creating "black hole" activities (with only incoming flows) or "miracle" activities
(with only outgoing flows), as these typically indicate missing or incorrect transitions. Each
activity should have clear and logical entry and exit paths.

3. Decision Points
Use diamond shapes to represent decision points that immediately follow an activity. These
should reflect the outcome of the preceding activity. Guards (conditions in square brackets)
must be placed on each outgoing flow to indicate the decision criteria. Avoid redundant or
superfluous decisions when the logic can be implied.

44
4. Guards
Each transition leaving a decision point should be uniquely defined by a guard. Guards should
not overlap and must form a complete set to cover all possible scenarios. Optionally, a
[Otherwise] guard can be used to handle fallback conditions when no other guard applies.

5. Parallel Activities
To model concurrent banking processes, use forks (one input, multiple outputs) and joins
(multiple inputs, one output). Every fork should ideally have a corresponding join to ensure
proper synchronization of parallel paths. Avoid using unnecessary forks that could
overcomplicate the diagram.

6. Swimlane Guidelines
Use swimlanes to clearly identify which actor—such as Customer, Cashier, or Manager—is
responsible for each activity. Keep the number of swimlanes under five for simplicity and
arrange them in a logical sequence. Horizontal swimlanes may be used for business processes
where vertical alignment isn’t optimal.

7. Action-Object Guidelines
Action objects such as loan forms or transaction slips should be placed along swimlane
boundaries if shared between roles. When an object appears multiple times, use state names to
reflect its status (e.g., "Form Submitted", "Transaction Approved"). Limit objects to only those
critical to the process and visually distinguish them from activities by using smaller
representations.

ACTIVITY DIAGRAM FOR BANK MANAGEMENT SYSTEM :

Core System Architecture

The bank management system uses a three-tier interaction model with distinct roles and
responsibilities:
1. Client: End user who initiates and completes banking transactions
2. Bank Management System: The central automated processing system
3. Employee: Bank staff who verify and execute transactions
Transaction Processing Theory
The system follows a linear transaction processing flow with verification checkpoints:
Initial Transaction Phase
 The system initiates the process and presents transaction options to clients
 Clients make selections from predefined transaction types
 The system employs a request-response pattern for gathering client information
Verification and Processing Phase
 The system implements a dual verification model:

45
 o System-level verification through data collection
o Human verification through employee confirmation
 This creates a security checkpoint before transaction execution
Execution and Completion Phase
 Employee execution provides human oversight for transactions
 System maintains transaction status tracking
 Receipt generation serves as transaction proof and audit trail
Theoretical Principles
1. Segregation of Duties: The diagram shows clear separation between client actions,
system processing, and employee verification, implementing a security principle where
no single actor has complete control.
2. Checkpoint Validation: The diamond decision point in the client lane represents
validation gates that must be passed before proceeding.
3. Sequential Process Integrity: The system enforces a strict sequential processing order
that cannot be bypassed.
4. Transaction Finality: Once confirmed and processed, transactions reach a definitive
completed state with formal documentation.
This bank management system operates on principles of segregated responsibilities, dual
verification, and systematic documentation to ensure transaction security, accuracy, and
auditability.

46
Sample Activity Diagrams Based On The Given Use Cases :

Transaction Management

Core System Architecture

The system implements a comprehensive transaction flow with multiple security
checkpoints:
1. Authentication-First Design: All interactions begin with account holder
verification
2. Operation-Based Branching: System behavior adapts based on user operation
selection
3. Fraud Detection Integration: Explicit fraud detection pathway for suspicious
activities
Key Theoretical Principles
1. Security Tiering:
o Primary authentication of account holder
o Secondary authorization of specific transaction
o Tertiary identification management (release or invalidate)

47
 2. Fail-Safe Approach:
o Multiple exit points at different stages
o All authentication/validation failures lead to safe termination
o Identification management varies based on transaction outcome
3. Amount Validation Loop:
o Circular validation process for withdrawal amounts
o System notifies and redirects for invalid amounts rather than terminating
o Valid amounts proceed to authorization stage
4. Path Segregation:
o Successful paths follow a complete transaction cycle
o Failed paths terminate with appropriate identification management
o Fraud detection has dedicated high-security termination pathway

Loan Management

Core Architecture Summary

This loan approval process models a multi-party workflow involving the Customer, Bank, Credit
Rating Agency, and Property Agent. It emphasizes conditional risk handling, third-party
validation, and decision-based flow termination.

48
Key Design Principles
 Staged Risk Evaluation:
Initial and secondary assessments handle applications based on risk levels. Medium-risk
paths loop back for further checks.
 Safe Exit Strategy:
All rejections result in controlled termination. Approvals follow a distinct path to
completion.
 Parallel Verification:
Credit and property assessments are performed simultaneously, improving process
efficiency.
 Actor Segregation via Swimlanes:
Each lane reflects clear responsibility—customer initiates, bank assesses, third parties
verify.
 Guard-Driven Decisions:
Transitions like [Loan Approved] or [Medium Risk Application] guide precise control flow.

CONCLUSION:

The Activity Diagram for the Bank Management System effectively illustrates the sequence of
operations, conditional flows, and parallel processes involved in customer transactions. By
incorporating swimlanes, decision nodes, and guard conditions, the diagram clearly outlines
actor responsibilities and system behavior, enhancing both process clarity and design accuracy.
This modeling approach ensures a structured understanding of core banking operations such as
withdrawals, deposits, and loan processing.

49
 EXPERIMENT NO. 7

AIM: To prepare a State Chart Diagram for the Bank Management System.
REQUIREMENTS:
Hardware Requirements:

 Minimum: Intel Core i3 processor, 4GB RAM

 Recommended: Intel Core i5 or higher, 8GB RAM or more for better performance
 Input Devices: Standard keyboard and mouse
 Display: Colored monitor with at least 800x600 resolution

Software Requirements:
 Operating System: Windows 10/11, Linux, or macOS.
 UML Modeling Tool: Rational Rose or any compatible UML software.

THEORY:
✓ State Chart Diagrams are used in the Bank Management System to model the different states
through which a banking entity (like a loan request, transaction, or customer account)
progresses during its lifecycle.

✓ There are two special states in any state chart:

 The Start State, shown as a black filled dot, represents the initiation of a process (e.g.,
when a customer applies for a loan).
 The Stop State, shown as a bull’s eye symbol, signifies the end of the process (e.g., loan
approval or rejection).

✓ Conditions written in square brackets are known as guard conditions. These determine
whether a transition between states should occur. For example, a transition to "Loan Approved"
might only occur if [Credit Score > 700].

✓ Activities that occur while an entity (like a loan request) is in a particular state are known as
actions. For instance, "Credit Check" or "Risk Assessment" are actions performed in specific
states of the loan process.
These principles enable accurate modeling of complex banking workflows, such as loan
processing, account status changes, and transaction handling, ensuring clear visualization of
operational logic and transitions
STEPS TO DRAW STATE CHART DIAGRAM IN RATIONAL ROSE SOFTWARE
50
1. Open the Logical View in Rational Rose and insert a new State Chart Diagram:
 Navigate to Select → New → State Chart Diagram
 Enter relevant name such as Account State Diagram or Loan Processing State
2. Double-click the newly created diagram to open it:
 Click on the Start State button to begin
 Place the Start State icon on the canvas
3. Add relevant states representing different stages of a banking process:
 Example (Loan lifecycle): Application Submitted → Credit Check → Risk
Assessment → Approval/Denial
 Click the State button, place each state, and label them accordingly
4. Add the End State to conclude the process:
 Use the End State button and place it (e.g., Loan Approved, Loan Rejected)
5. Use the Transition Tool to show flow between states:
 Click the State Transition button
 Draw arrows between states indicating logical sequence
 Right-click each transition to label with event names or guard conditions, if
needed
6. Rearrange states for better readability:
 Drag state boxes to organize a clear layout
7. Add multiple transitions if a state can lead to more than one subsequent state:
 Define events and conditions clearly for each transition
 To edit transitions, right-click the relation line → Open Specification → add
name/condition → click OK
8. Review the entire diagram:
 Ensure it accurately reflects banking operations and conforms to system
requirements

Banking System State Management Theory

This diagram represents a state management model for banking systems with
several key theoretical elements:
1. Authentication Gateway: Login credentials serve as the primary entry point,
controlling access to all banking functions.
2. Branching Architecture: The system allows multiple functional pathways after
authentication (balance checking, transactions, cheque processing, e-banking).
3. Error Management: Defined error states with recovery paths prevent complete
session restarts.

51
4. Verification Layers: Multiple checkpoints throughout the workflow ensure
security and data integrity.
5. Integrated Services: The model unifies traditional banking operations with digital
services within a single framework.
6. State Persistence: The system maintains context awareness across complex multi-
step operations.
7. Account Differentiation: The architecture handles different account types while
maintaining operational consistency.

State Chart Diagram for Bank Management System

Conclusion: The State Chart Diagram for the Bank Management System was
successfully created using Rational Rose. It effectively models the transitions of
various banking operations, particularly focusing on the loan approval lifecycle. This
visual representation aids in understanding system behavior and designing secure,
efficient banking processes.

52
 EXPERIMENT NO. 8

AIM: To prepare a Sequence Diagram for the Bank Management System using Rational Rose.
REQUIREMENTS:
Hardware Requirements:
1. Intel Core i3 or higher processor (2.4 GHz recommended)
2. Minimum 4GB RAM (8GB preferred)
3. Standard keyboard and mouse
4. Colored monitor with at least 800x600 resolution

Software Requirements:
1. Operating System: Windows 10/11, Linux, or macOS
2. UML Modeling Tool: IBM Rational Rose or any equivalent UML design software

THEORY:
UML Sequence Diagrams model the flow of interactions between objects in the system. They
are used to document, validate, and visualize the sequence of messages exchanged for a
particular functionality.

In a Bank Management System, sequence diagrams are crucial for illustrating how customers
interact with services such as account creation, money transfer, loan applications, and
transaction processing.

Sequence diagrams are typically used to model:

Usage Scenarios: A usage scenario is a description of a potential way the system is used. The
logic of a usage scenario may be part of a use case, perhaps an alternate course. It may also be
one entire pass through a use case, such as the logic described by the basic course of action or a
portion of the basic course of action, plus one or more alternate scenarios. The logic of a usage
scenario may also be a pass through the logic contained in several use cases.
Example: A customer logs into the system, checks account balance, and makes a funds transfer.

Logic of Methods: Sequence diagrams can be used to explore the logic of a complex operation,
function, or procedure. One way to think of sequence diagrams, particularly highly detailed
diagrams, is as visual object code.
Example: Processing a loan approval request by verifying documents, checking credit scores,
and granting approval.

53
Logic of Services: A service is effectively a high-level method, often one that can be invoked by
a wide variety of clients. This includes web-services as well as business transactions
implemented by a variety of technologies such as CICS/COBOL or CORBA-compliant object
request brokers (ORBs)
Example: Banking services like online fund transfer, bill payments, or ATM withdrawal requests.

How to Draw Sequence Diagrams

Sequence diagramming is visual coding, even when modeling a usage scenario for a bank
management system.

Start by identifying the scope—typically small scenarios like login, balance inquiry, or fund
transfer—at the system or method/service level.

Work through the logic with a peer, laying out classifiers across the top. Add messages one at a
time, using meaningful names instead of explicitly showing return values.
While diagramming, you may discover new responsibilities or classes. Update the class model
accordingly. Agile modelers often Create Several Models in Parallel, supported by CASE tools.
Each message to a class triggers a static method; to an object, an instance method.

Prefer drawing messages left-to-right and return values right-to-left. Place message labels close
to arrowheads. Layer diagrams from left-to-right: actors (e.g., Customer), controller classes (e.g.,
LoginManager), user interfaces (e.g., MobileAppUI), business classes (e.g., Account), and finally
system or persistence classes (e.g., DatabaseService). This layout improves clarity and helps
detect architectural issues, such as direct persistence access by UI classes.

Procedure
Click on the File menu and select New.

54
Now from the Dialogue Box that appears , select the language which you want to use for
creating your model.

In the left-hand side window of Rational Rose right click on Use Case view and select
New>Sequence Diagram

Enter the name of new Sequence file in the space provided,and then click on that file name

55
You can now use the window that appears on right hand side to draw your Sequence diagram
using the buttons provided on the vertical toolbar.

56
Sequence Diagram for Bank Management System

This sequence diagram models the interactions involved in managing customer accounts in a
bank management system. It represents the communication between different entities: the
Bank, Customer, Saving Account, and Checking Account.
1. Adding a Customer:
The process begins when the Bank adds new customer by invoking the add
Customer("Cust 1") operation. This establishes customer's identity within the system.
2. Creating a Saving Account:
Once the customer is registered, the Bank initiates the creation of a saving account
associated with the customer by calling the savingAccount("Cust 1") message. This sets
up a savings facility for the customer.
3. Creating a Checking Account:
Following the saving account setup, a checking account is also created for the same
customer by invoking the checkingAccount ("Cust 1") message. This allows the customer
to manage everyday banking transactions.
4. Credit Operation:
After the accounts are set up, the Bank or Customer can perform credit operations.
The credit(amount) message is sent to the Saving Account object, indicating that a
specified amount is to be deposited.
5. Debit Operation from Saving Account:
The customer may also initiate a withdrawal. The Bank triggers debit (amount) message
to the Saving Account object, deducting the requested amount from the savings.
6. Debit Operation from Checking Account:
Similarly, for transactions related to the checking account, the debit(amount) message is
sent to the Checking Account object. This represents everyday withdrawals or payments
made by the customer.

57
Sequence Diagram for Transaction in a Bank

This sequence diagram represents the process of completing an IMPS transaction through a
banking application. The user initiates an IMPS transfer via the app, which requests the
transaction from the Bank Server. The server then triggers the OTP generation through the OTP
Service. Once the OTP is sent, the user enters it in the app, and the app submits it for
verification through the Authenticator. Upon successful OTP verification, the Bank Server
initiates and processes the transfer through the Transaction Server. After completion, the
system confirms the transaction and the app displays a success message to the user.

CONCLUSION
The Sequence Diagram for the Bank Management System was created successfully using
Rational Rose. It effectively models the interaction between users and the banking system
components for various banking operations such as account management, fund transfer, and
loan processing.

58
 EXPERIMENT NO. 9

AIM: To prepare a Collaboration Diagram for the Bank Management System using Rational
Rose.

REQUIREMENTS:
Hardware Requirements:
5. Intel Core i3 or higher processor (2.4 GHz recommended)
6. Minimum 4GB RAM (8GB preferred)
7. Standard keyboard and mouse
8. Colored monitor with at least 800x600 resolution

Software Requirements:
3. Operating System: Windows 10/11, Linux, or macOS
4. UML Modeling Tool: IBM Rational Rose or any equivalent UML design software

THEORY:
Collaboration diagrams are also relatively easy to draw. They show the relationship between
objects and the order of messages passed between them. The objects are listed as icons and
arrows indicate the messages being passed between them. The numbers next to the messages
are called sequence numbers. As the name suggests, they show the sequence of the messages
as they are passed between the objects. There are many acceptable sequence numbering
schemes in UML. A simple 1, 2, 3... format can be used, as the example below shows, or for
more detailed and complex diagrams a 1, 1.1 ,1.2, 1.2.1... scheme can be used.

In a Bank Management System, the collaboration diagram captures operations such as adding
a customer, creating saving and checking accounts, and performing credit and debit
transactions.

59
The sequence numbers next to each message define the order in which operations are
executed:
 1: addCustomer("Cust 1")
 2: savingAccount("Cust 1")
 3: checkingAccount("Cust 1")
 4: credit(amount)
 5: debit(amount)
The collaboration diagram combines the features of both sequence and class diagrams,
making it easier to understand object organization and message flow.
Collaboration Diagram for Bank Management System

Key Concepts Illustrated in the Diagram:

1. Actors and Systems: The diagram clearly identifies the participants in the interaction:
o Customer: Represented by a rectangle, this is an external entity (a user) who
interacts with the system.
o Online Banking System: Also represented by a rectangle, this is the system being
modeled.
2. Messages/Interactions: The numbered arrows represent messages or interactions
flowing between the customer and the online banking system. The numbers suggest a
possible sequence of actions initiated by the customer.
3. Direction of Flow: The arrows indicate the direction of the interaction. A right-pointing
arrow means the customer is sending a request or information to the system, while a
left-pointing arrow indicates a response or information being sent back to the customer.
4. Use Cases (Implicit): The numbered interactions (1, 2, 3, 5, 7, 9) can be seen as
representing different use cases or functionalities offered by the online banking system.
For example:
o 1: Send userid and password: Represents the login use case.
o 2: view account details: Represents the view account information use case.
o 3: withdraw money: Represents the cash withdrawal use case.

60
 o 5: deposit: Represents the deposit money use case.
o 7: check balance: Represents the balance inquiry use case.
o 9: logout: Represents the logout use case.
5. Responses from the System: The interactions flowing from the "Online Banking System"
back to the "Customer" (4, 6, 8) represent the system's responses to the customer's
requests:
o 4: Cash dispensed: Response to a successful withdrawal (interaction 3).
o 6: issue receipt: Likely a response after a transaction (withdrawal or deposit).
o 8: show balance: Response to a balance inquiry (interaction 7).
6. Iteration (Implicit): The curved arrow associated with "9: logout" might suggest that the
customer can perform multiple banking activities before finally logging out. The loop-
like structure indicates that the interactions 1 through (presumably) 8 can occur
multiple times.

Purpose of Such Diagrams in System Design:

 Understanding Requirements: These diagrams help in understanding the interactions

required between users and the system to fulfill specific tasks.
 Visualizing Flow: They provide a visual representation of the sequence of actions,
making it easier to grasp the dynamics of the system.
 Identifying Actors and System Boundaries: They clearly define the roles of different
entities interacting with the system and the boundary of the system itself.
 Early Design and Communication: They serve as a communication tool among
stakeholders (developers, designers, clients) during the early stages of system design.
 Basis for More Detailed Design: These high-level interactions can be further refined into
more detailed sequence diagrams or other design artifacts.

CONCLUSION

The Collaboration Diagram for the Bank Management System was successfully created using
Rational Rose, clearly showing object relationships and interaction sequences.

61
 EXPERIMENT NO. 10

AIM: To draw a Class Diagram for the Bank Management System (BMS).

REQUIREMENTS:
Hardware Interfaces:
 Intel Core i3 or higher processor
 Minimum 4GB RAM
 Screen resolution of at least 800 x 600
 CD ROM Drive (optional for installation)

Software Interfaces:
 Windows 10/11, Linux, or macOS
 IBM Rational Rose or any other UML modeling tool

THEORY:

A Class Diagram is a type of static structure diagram that describes the structure of a system by
showing its classes, their attributes, operations, and relationships. Class diagrams are widely
used in software development to illustrate the types of objects in a system and how they
interact with one another.

In the Bank Management System (BMS), class diagrams help model entities like Customer,
Account, Transaction, Loan, Service, and Admin. These diagrams provide a blueprint for both
understanding domain concepts and implementing object-oriented designs.

Class diagrams are typically used to:

 Explore domain concepts in the form of a domain model

 Analyze requirements using conceptual/analysis models
 Depict the detailed design of object-oriented systems

A class model consists of one or more class diagrams along with specifications for classes,
relationships, and interfaces. These diagrams support conceptual, specification, and
implementation views.

62
GENERAL GUIDELINES

Class diagrams may vary in style depending on whether they are used for high-level analysis or
detailed design. Typically, a class is represented as a rectangle with three compartments:

1. Class Name
2. Attributes (e.g., accountNumber, customerName)
3. Operations (e.g., deposit(), withdraw(), approveLoan())

A class defines the blueprint for objects, including the data (attributes) and functionality
(operations) it supports. Classes may also implement interfaces.
Class diagrams in BMS serve to model class structure and contents, and assist in solidifying the
overall design.

CLASS DIAGRAM ELEMENTS FOR BMS:

1. Classes:
Each class represents a banking entity such as Customer, Account, Loan, or Transaction. These
are the foundational elements in modeling the banking domain.

2. Interfaces:
Interfaces define a set of method signatures or properties. In BMS, an interface like Banking
Service could be used to define actions like performTransaction() or getAccountStatement()
that service classes must implement.

3. Relationships:
Relationships connect two or more classes and show how they interact.

 Association: are semantic connection between classes. When an association connects

two classes , each class can send messages to other in a sequence or a collaboration
diagram .Associations can be bidirectional or unidirectional.

 Generalization (Inheritance): The generalization relationship indicates that one of the

two related classes (the supertype) is considered to be a more general form of the other
(the subtype). In practice,this means that any instance of the subtype is also an instance
of the supertype.The generalization relationship is also known as the inheritance or "is
a" relationship. The supertype in the generalization relationship is also known as the
"parent"superclass, base class, or base type.The subtype in the generalization

63
 relationship is also known as the "child", subclass, derived class, derived type, inheriting
class, or inheriting type.

 Aggregation: is a variant of the "has a" or association relationship; composition is more

specific than aggregation. Aggregation occurs when a class is a collection or container
of other classes, but where the contained classes do not have a strong life cycle
dependency on the container--essentially, if the container is destroyed, its contents are
not.

4. Multiplicity: Multiplicity defines how many instances of a class relate to instances of another
class. Example: One Customer can have multiple Accounts (1:N).

HOW TO DRAW CLASS DIAGRAM

When designing classes the attributes and operations it will have are observed.Then
determining how instances of the classes will interact with each other. These are the very first
steps of many in developing a class diagram. However, using just these basic techniques one
can develop a complete view of the software system. There are various steps in the analysis and
design of an object oriented system.

64
 STEPS FOR ANALYSIS AND DESIGN

STEPS FOR DRAWING CLASS DIAGRAM

1. After completing the sequence diagrams and collaboration diagram which are a part of the
interaction diagrams. In Rational Rose, right click on the Use Case View and select new class
diagram.

2.Enter a class diagram name (e.g., BankClassDiagram).

65
3. Click the cursor on the block representing class from the table of predefined symbols into the
screen.

4.Select a new Class.

5. Double click on the class formed to enter the class name in the general field.

66
6. In the operation field right click and select insert option to add class operations or functions.

7.In the attribute field, enter the attribute names, their type and parent class in the respective
columns.

67
8.Add all relevant classes: Customer, Account, Transaction, Loan, Admin, Service.

9.If nested classes are needed (e.g., Loan has Collateral), add them under the nested field.

10.Draw relationships:

o Association: Use arrows between classes.

o Generalization: Use inheritance arrows.
o Use text annotations to label relationships.

Sample Class Diagram for Bank Management System:

(The provided diagram includes classes like Bank, Branch, Account, Customer, Loan,
Savings_Account, and Current_Account with clear inheritance and relationship modeling.)

The sample class diagram provided depicts the following:

 A Bank can manage multiple Branches, and each Branch has methods for managing
accounts and loans.
 Branches are associated with multiple Accounts and Loans. Each branch is
managed by a Zonal Head Office.
 The Account class is a parent to both Savings_Account and Current_Account,
showing inheritance. These classes define specific behaviors and constraints (e.g.,
Min_Balance or Interest_Rate).

68
  A Customer can have multiple Accounts (both current and savings types), but each
account is linked to only one customer.
 The Loan class captures loan-specific attributes and behaviors, with an association
back to Customer and Branch.

This diagram provides a structured and detailed representation of a bank's backend logic
and serves as a base for system implementation.

Class Diagram for Bank Management System

CONCLUSION:

The class diagram for the Bank Management System has been successfully constructed. It
provides a comprehensive structural view of system components and their interrelations,
supporting efficient system development, understanding, and documentation.

69