Software Development Life Cycle - Case study

An example of a conversation between a client (representative from a bank) and a

business analyst discussing the requirements for implementing a new database system
for the banking domain. This conversation highlights key points in the requirement
gathering process.

Client (C): Thank you for meeting with us today. We are looking to develop a new database
system to manage our banking operations more efficiently.

Business Analyst (BA): Thank you for having me. I'm here to understand your requirements
and ensure we design a system that meets your needs. Let's start with an overview. Can you
describe the main functionalities you need from this new database?

C: Sure. We need to manage customer accounts, track transactions, handle loans, and ensure
security and compliance with banking regulations.

BA: That’s a good start. Let’s break these down. First, regarding customer accounts, what
specific information do you need to store?

C: We need to store personal information like name, address, contact details, date of birth, and
social security number. Additionally, we need account details like account number, account type,
balance, and account creation date.

BA: Understood. How about transaction tracking? What types of transactions are we looking at,
and what details do you need to capture?

C: We need to track deposits, withdrawals, transfers, and payments. For each transaction, we
need to capture the date and time, amount, type of transaction, and the accounts involved.

BA: That makes sense. Regarding loans, what information do you need to store and track?

C: For loans, we need to track loan types, loan amounts, interest rates, loan terms, payment
schedules, and customer details related to the loans. We also need to track the payment history
for each loan.

BA: Okay. Security and compliance are crucial in the banking sector. Can you elaborate on your
security and regulatory requirements?

C: Yes, we need to ensure data encryption, both at rest and in transit. We need role-based
access control to restrict data access based on user roles. Additionally, we need to comply with
regulations like GDPR and PCI DSS, which require specific data protection and auditing
measures.

BA: Absolutely, we’ll make sure to incorporate those security and compliance requirements. Are
there any other specific features or functionalities you need?

C: We need robust reporting capabilities to generate various financial and regulatory reports.
Also, we need the system to integrate with our existing banking software and third-party
services like credit scoring and fraud detection.

BA: Integration with existing systems and third-party services is noted. We’ll ensure the
database is designed to support these integrations. What about performance? Are there any
specific performance requirements we should be aware of?

C: The system should handle high transaction volumes without significant latency. It should be
scalable to accommodate future growth. Additionally, we need high availability and disaster
recovery mechanisms to ensure continuous operation.

BA: High performance, scalability, and availability are critical for banking operations. We’ll
design the database with these factors in mind. Lastly, are there any specific user interfaces or
user roles we need to consider?

C: Yes, we need interfaces for bank tellers, loan officers, customer service representatives, and
managers. Each role will have different levels of access and functionality based on their
responsibilities.

BA: Got it. Different user roles with appropriate access levels. I think we have a good
understanding of your requirements. We’ll draft a detailed requirements document and share it
with you for review. Once we have your feedback, we can move on to the conceptual design
phase.

C: That sounds perfect. Thank you for your thorough understanding. We look forward to seeing
the detailed requirements document.

BA: Thank you for your time. We’ll be in touch soon with the next steps.

This conversation provides a comprehensive overview of the initial requirements gathering

phase, ensuring that the business analyst captures all necessary details to design a robust
database system for the banking domain.

what does business analyst do after getting feedback from the client on the
requirements' document
After receiving feedback from the client on the requirements document, a business analyst (BA)
will follow these steps to ensure the project proceeds smoothly and accurately:

1. Review Client Feedback

● Thoroughly Review Feedback: Carefully read through all the feedback provided by the
client, noting any changes, clarifications, or additional requirements.
● Clarify Ambiguities: If any feedback is unclear, the BA should arrange a meeting or
communicate with the client to clarify the points of confusion.

2. Update Requirements Document

● Revise Document: Update the requirements document to reflect the client’s feedback.
Ensure all changes are clearly incorporated.
● Version Control: Use version control to track changes and ensure that the document
versioning is clear. Label the updated document appropriately (e.g., Requirements
Document v2).

3. Validate Changes

● Internal Review: Conduct an internal review with the project team (including developers,
designers, and testers) to validate the changes. Ensure the team understands the
revised requirements.
● Impact Analysis: Perform an impact analysis to understand how the changes affect the
project scope, timeline, and resources.

4. Obtain Final Approval

● Client Approval: Share the updated requirements document with the client for final
approval. Make sure the client acknowledges and agrees with all changes.
● Formal Sign-off: Obtain a formal sign-off from the client, which could be in the form of a
signed document, an email confirmation, or an official approval in a project management
tool.

5. Create Detailed Functional Specifications

● Detailed Specifications: Develop detailed functional specifications based on the

approved requirements document. These specifications should include detailed
descriptions of the system’s functionality, use cases, user stories, and any specific
business rules.
● Wireframes and Prototypes: If applicable, create wireframes or prototypes to provide a
visual representation of the system’s user interface and flow.

6. Transition to Design and Development

 ● Hand Over to Design Team: Share the functional specifications with the design team to
start the conceptual and logical design phases. Ensure the design team understands the
requirements and any constraints.
● Collaborate with Development Team: Work closely with the development team to
translate functional specifications into technical specifications. Ensure the team
understands the requirements and the overall system architecture.

7. Ongoing Communication and Updates

● Regular Updates: Maintain regular communication with the client to provide updates on
the progress. Inform them about any potential issues or changes.
● Feedback Loop: Establish a feedback loop with the client throughout the design and
development phases to ensure the project stays aligned with their expectations.

8. Testing and Validation

● Develop Test Plans: Create test plans and test cases based on the functional
specifications. Ensure the testing team is prepared to validate the system against the
requirements.
● Client Validation: Plan for client validation sessions where the client can test the system
and provide feedback before final deployment.

9. Training and Documentation

● User Training: Develop training materials and conduct training sessions for the client’s
staff to ensure they understand how to use the new system.
● Comprehensive Documentation: Provide comprehensive documentation, including
user manuals, technical documentation, and any other relevant materials.

10. Go-Live and Support

● Deployment Plan: Develop a detailed deployment plan to ensure a smooth transition to

the new system.
● Post-Go-Live Support: Plan for post-go-live support to address any issues that arise
after the system is in production.

By following these steps, the business analyst ensures that the project moves forward efficiently
and meets the client’s needs and expectations.
conceptual designing thoughts between the team
example of a conceptual design discussion between the project team for a banking domain
database system. The team includes a Business Analyst (BA), Database Designer (DD),
Developer (Dev), and a Tester (T).

BA: Alright team, we've got the final approval on the requirements document from the client.
Let's discuss the conceptual design for our banking domain database system. Our goal is to
outline the key entities and relationships.

DD: Great, let's start with the main entities based on the requirements: Customers, Accounts,
Transactions, Loans, and Branches. Each entity will have its attributes and relationships.

Dev: That sounds good. Let's dive into each entity. For Customers, we need to store personal
details. What attributes should we include?

BA: Customers will have attributes like CustomerID, FirstName, LastName, DateOfBirth,
Gender, Address, PhoneNumber, Email, and SocialSecurityNumber. CustomerID will be the
primary key.

T: Should we consider any constraints or validations for these attributes?

DD: Yes, we'll need to ensure the SocialSecurityNumber is unique and properly formatted. We'll
also validate the email format and phone number length. Now, let's move on to Accounts.

Dev: Accounts will need attributes such as AccountID, CustomerID (foreign key), AccountType,
Balance, CreationDate, and Status. AccountID will be the primary key, and CustomerID will
reference Customers.

BA: Right. Accounts can be of different types like savings, checking, or fixed deposits. We'll
need to capture that in the AccountType attribute.

T: For transactions, we should capture the transaction history. What attributes should be
included?

DD: For Transactions, we'll have TransactionID, AccountID (foreign key), TransactionType,
Amount, TransactionDate, and Description. TransactionID will be the primary key, and
AccountID will reference Accounts.

Dev: TransactionType could be deposit, withdrawal, transfer, or payment. We should also think
about indexing TransactionDate for faster queries.
BA: Good point. Now, for Loans, we'll need attributes such as LoanID, CustomerID (foreign
key), LoanType, LoanAmount, InterestRate, LoanTerm, StartDate, EndDate, and
PaymentSchedule. LoanID will be the primary key, and CustomerID will reference Customers.

T: How will we manage the payment schedule for loans?

DD: We can create a separate table for LoanPayments with attributes like PaymentID, LoanID
(foreign key), PaymentDate, PaymentAmount, and BalanceRemaining. PaymentID will be the
primary key, and LoanID will reference Loans.

Dev: What about the Branches entity? What attributes should we include?

BA: Branches will have BranchID, BranchName, Address, PhoneNumber, and ManagerID.
BranchID will be the primary key. ManagerID can reference an employee in the bank, so we
might need an Employees table.

DD: Yes, an Employees table would be useful. Attributes can include EmployeeID, FirstName,
LastName, Position, HireDate, BranchID (foreign key), and Email. EmployeeID will be the
primary key, and BranchID will reference Branches.

T: For security and compliance, we need to ensure data encryption, role-based access control,
and audit logs. How should we handle these?

Dev: We’ll encrypt sensitive data like SocialSecurityNumber and balance information. For
role-based access control, we'll implement a UserRoles table with UserID, Role, and
Permissions attributes. Audit logs can be managed with an AuditLogs table capturing UserID,
Action, Timestamp, and Details.

BA: Excellent. Let’s summarize our entities and relationships before moving to the next steps.
Here’s what we have:

● Customers: CustomerID, FirstName, LastName, DateOfBirth, Gender, Address,

PhoneNumber, Email, SocialSecurityNumber
● Accounts: AccountID, CustomerID, AccountType, Balance, CreationDate, Status
● Transactions: TransactionID, AccountID, TransactionType, Amount, TransactionDate,
Description
● Loans: LoanID, CustomerID, LoanType, LoanAmount, InterestRate, LoanTerm,
StartDate, EndDate, PaymentSchedule
● LoanPayments: PaymentID, LoanID, PaymentDate, PaymentAmount,
BalanceRemaining
● Branches: BranchID, BranchName, Address, PhoneNumber, ManagerID
● Employees: EmployeeID, FirstName, LastName, Position, HireDate, BranchID, Email
● UserRoles: UserID, Role, Permissions
● AuditLogs: LogID, UserID, Action, Timestamp, Details
DD: That covers the main entities and their relationships. Next, we’ll create the ER diagram to
visualize these relationships and ensure we have captured all the necessary details.

Dev: Once the ER diagram is finalized, we can move on to the logical design phase, where we’ll
define the actual tables, keys, and relationships in SQL.

T: I'll start working on the test cases to ensure each entity and relationship is accurately
implemented and meets the requirements.

BA: Perfect. Let’s aim to have the ER diagram and initial logical design ready for review by the
end of the week. Thank you, everyone, for your input.

This conversation highlights the collaborative effort in the conceptual design phase, ensuring all
team members understand the requirements and contribute to a comprehensive database
design.

the work that is to be done by developers, database designers

and testers

A detailed breakdown of the tasks for developers, database designers, and testers for
implementing the banking domain database system:

Developers

Tasks:

1. Database Setup:
○ Install and configure MySQL server.
○ Set up the initial database and user roles.
2. Schema Implementation:
○ Write SQL scripts to create tables based on the logical design.
○ Define primary keys, foreign keys, and indexes.
3. Application Development:
○ Develop backend logic to handle CRUD operations for each entity.
○ Implement business logic for transactions, loan processing, and account
management.
○ Develop APIs for integration with front-end applications and third-party services.
4. Security Implementation:
○ Implement encryption for sensitive data.
○ Set up role-based access control.
○ Develop audit logging mechanisms.
5. Performance Optimization:
 ○ Optimize queries for performance.
○ Implement caching strategies where applicable.
○ Ensure database transactions are efficient and fast.
6. Integration:
○ Integrate with existing banking software.
○ Develop modules for integrating with third-party services like credit scoring and
fraud detection.
7. Documentation:
○ Document code and database schema.
○ Provide API documentation for frontend developers and third-party integrations.

Database Designers

Tasks:

1. ER Diagram:
○ Create and finalize the Entity-Relationship Diagram based on the conceptual
design.
○ Validate the ER diagram with the project team and client.
2. Logical Design:
○ Define table structures, relationships, and constraints.
○ Create SQL scripts for table creation, including primary keys, foreign keys, and
indexes.
3. Normalization:
○ Normalize database tables to reduce redundancy and improve data integrity.
○ Ensure that the database schema adheres to normalization standards (e.g.,
3NF).
4. Performance Considerations:
○ Design indexes to optimize query performance.
○ Plan for partitioning and sharding strategies if needed for large datasets.
5. Security Design:
○ Design encryption strategies for sensitive data.
○ Define role-based access control policies and table-level permissions.
6. Backup and Recovery:
○ Design backup and recovery strategies.
○ Implement scripts for regular database backups.
7. Documentation:
○ Document the database schema and design decisions.
○ Provide a data dictionary describing each table and field.

Testers

Tasks:

1. Test Planning:
 ○ Develop a comprehensive test plan covering all aspects of the database system.
○ Define test cases for each module, including customer management, account
management, transactions, and loans.
2. Unit Testing:
○ Write and execute unit tests for CRUD operations on each entity.
○ Verify that each table and relationship is implemented correctly.
3. Integration Testing:
○ Test the integration between different modules of the system.
○ Ensure that transactions, loans, and account operations work seamlessly
together.
4. Performance Testing:
○ Conduct performance tests to evaluate database response times under various
loads.
○ Identify and report any performance bottlenecks.
5. Security Testing:
○ Test encryption and decryption of sensitive data.
○ Verify role-based access control by testing different user roles and permissions.
○ Conduct vulnerability assessments to identify potential security risks.
6. User Acceptance Testing (UAT):
○ Coordinate with the client to perform UAT.
○ Ensure that the system meets the client’s requirements and expectations.
○ Gather feedback and report any issues to the development team.
7. Regression Testing:
○ Perform regression testing after any changes or updates to ensure existing
functionality is not affected.
8. Documentation:
○ Document test cases, test results, and any issues found.
○ Provide detailed bug reports and track resolution progress.

Coordination and Communication

Regular Meetings:

● Schedule regular meetings between developers, database designers, and testers to

ensure everyone is on the same page.
● Use these meetings to discuss progress, address any challenges, and update the
project timeline.

Collaboration Tools:

● Use project management tools like JIRA or Trello for task management and tracking.
● Use version control systems like Git for managing code and database scripts.

Feedback Loop:
 ● Establish a feedback loop between the client and the project team to address any issues
promptly and ensure continuous alignment with client expectations.

By following these detailed tasks and ensuring effective coordination, the project team can
successfully implement a robust and efficient banking domain database system.

Implement logical design which is the task for database designers

the detailed implementation of the logical design for the banking domain database system. This
includes defining table structures, relationships, and constraints.

Logical Design

1. Customers Table

Stores information about the bank's customers.

CREATE TABLE Customers (

CustomerID INT AUTO_INCREMENT PRIMARY KEY,

FirstName VARCHAR(50) NOT NULL,

LastName VARCHAR(50) NOT NULL,

DateOfBirth DATE NOT NULL,

Gender CHAR(1) CHECK (Gender IN ('M', 'F')),

Address VARCHAR(255),

PhoneNumber VARCHAR(15),

Email VARCHAR(100) UNIQUE,

SocialSecurityNumber VARCHAR(11) UNIQUE NOT NULL,

CreatedAt TIMESTAMP DEFAULT CURRENT_TIMESTAMP

);

2. Accounts Table

Stores information about different accounts held by customers.

CREATE TABLE Accounts (

AccountID INT AUTO_INCREMENT PRIMARY KEY,

CustomerID INT NOT NULL,

AccountType ENUM('Savings', 'Checking', 'Fixed Deposit') NOT NULL,

Balance DECIMAL(15, 2) NOT NULL,

CreationDate DATE NOT NULL,

Status ENUM('Active', 'Closed') NOT NULL,

FOREIGN KEY (CustomerID) REFERENCES Customers(CustomerID)

);

3. Transactions Table

Stores details of transactions made within accounts.

CREATE TABLE Transactions (

TransactionID INT AUTO_INCREMENT PRIMARY KEY,

AccountID INT NOT NULL,

TransactionType ENUM('Deposit', 'Withdrawal', 'Transfer',

'Payment') NOT NULL,

Amount DECIMAL(15, 2) NOT NULL,

 TransactionDate TIMESTAMP DEFAULT CURRENT_TIMESTAMP,

Description VARCHAR(255),

FOREIGN KEY (AccountID) REFERENCES Accounts(AccountID)

);

4. Loans Table

Stores information about loans taken by customers.

CREATE TABLE Loans (

LoanID INT AUTO_INCREMENT PRIMARY KEY,

CustomerID INT NOT NULL,

LoanType ENUM('Home Loan', 'Personal Loan', 'Auto Loan',

'Education Loan') NOT NULL,

LoanAmount DECIMAL(15, 2) NOT NULL,

InterestRate DECIMAL(5, 2) NOT NULL,

LoanTerm INT NOT NULL, in months

StartDate DATE NOT NULL,

EndDate DATE,

PaymentSchedule TEXT,

FOREIGN KEY (CustomerID) REFERENCES Customers(CustomerID)

);

5. LoanPayments Table

Tracks loan payments made by customers.

CREATE TABLE LoanPayments (

PaymentID INT AUTO_INCREMENT PRIMARY KEY,

LoanID INT NOT NULL,

PaymentDate DATE NOT NULL,

PaymentAmount DECIMAL(15, 2) NOT NULL,

BalanceRemaining DECIMAL(15, 2) NOT NULL,

FOREIGN KEY (LoanID) REFERENCES Loans(LoanID)

);

6. Branches Table

Stores information about the bank's branches.

CREATE TABLE Branches (

BranchID INT AUTO_INCREMENT PRIMARY KEY,

BranchName VARCHAR(100) NOT NULL,

Address VARCHAR(255),

PhoneNumber VARCHAR(15),

ManagerID INT

);

7. Employees Table

Stores information about the bank's employees.

CREATE TABLE Employees (

EmployeeID INT AUTO_INCREMENT PRIMARY KEY,

FirstName VARCHAR(50) NOT NULL,

LastName VARCHAR(50) NOT NULL,

Position VARCHAR(50),

HireDate DATE NOT NULL,

BranchID INT NOT NULL,

Email VARCHAR(100) UNIQUE,

FOREIGN KEY (BranchID) REFERENCES Branches(BranchID)

);

8. UserRoles Table

Manages role-based access control.

CREATE TABLE UserRoles (

UserID INT AUTO_INCREMENT PRIMARY KEY,

Role ENUM('Admin', 'Teller', 'Loan Officer', 'Customer Service',

'Manager') NOT NULL,

Permissions TEXT

);

9. AuditLogs Table

Tracks changes and actions within the system for security and auditing purposes.

sql
Copy code

CREATE TABLE AuditLogs (

LogID INT AUTO_INCREMENT PRIMARY KEY,

UserID INT NOT NULL,

Action VARCHAR(255) NOT NULL,

Timestamp TIMESTAMP DEFAULT CURRENT_TIMESTAMP,

Details TEXT,

FOREIGN KEY (UserID) REFERENCES UserRoles(UserID)

);

Indexes and Performance Optimization

Indexes:

● Customers: Index on LastName for faster searches.

● Accounts: Index on CustomerID and Status.
● Transactions: Index on AccountID and TransactionDate.
● Loans: Index on CustomerID and LoanType.
● LoanPayments: Index on LoanID and PaymentDate.

Customers Indexes

CREATE INDEX idx_customers_lastname ON Customers (LastName);

Accounts Indexes

CREATE INDEX idx_accounts_customerid ON Accounts (CustomerID);

CREATE INDEX idx_accounts_status ON Accounts (Status);

 Transactions Indexes

CREATE INDEX idx_transactions_accountid ON Transactions (AccountID);

CREATE INDEX idx_transactions_transactiondate ON Transactions

(TransactionDate);

Loans Indexes

CREATE INDEX idx_loans_customerid ON Loans (CustomerID);

CREATE INDEX idx_loans_loantype ON Loans (LoanType);

LoanPayments Indexes

CREATE INDEX idx_loanpayments_loanid ON LoanPayments (LoanID);

CREATE INDEX idx_loanpayments_paymentdate ON LoanPayments

(PaymentDate);

Additional Constraints and Validations

Customers:

● Email format validation.

● Social Security Number uniqueness and format validation.

Accounts:

● Ensure balance is non-negative.

Transactions:

● Ensure the amount is positive.

Loans:
 ● Validate loan terms and interest rates.

Backup and Recovery Strategy

● Regular Backups: Schedule daily and weekly backups.

● Automated Scripts: Use automated scripts for regular backups.
● Offsite Storage: Store backups in an offsite location for disaster recovery.

Documentation

● Data Dictionary: Provide a data dictionary detailing each table, column, data type, and
constraints.
● ER Diagram: Include an updated ER diagram with the logical design documentation.
● Security Measures: Document encryption strategies, role-based access policies, and
compliance with regulatory requirements.

By implementing this logical design, the database designers ensure that the database is
structured efficiently, meets all requirements, and is prepared for the development and testing
phases.