Part I

The Credit Card Processing System which is use to purchasing an item from any shop mall, and it is
used to maintain the limitation of credit card balance and current transaction process could be update
via credit card machine. This project mainly used for large amount of item can be easy to buy from
anywhere and required transaction process should be maintained them. The customer should select the
item to be purchase from the shop by using credit card payment then the vendor should give a bill for
the selected item .The customer should give his card to swap and request for the kind of amount
transaction. After processing the transaction, the CREDIT CARD MACHINE should give the balance
print statement or receipt.

1 Customer should select the item from the shop.

2 Vendor makes the bill for the selected item.

3 Customer gives the credit card to the vendor to swap the card.

4 They required amount transaction is done by the card reader.

5 Vendor will issue the balance statement to the customer.

6 Customers put the signature in the receipt and return to the vendor

1
 Task 1
Design of problem statement, perform a detailed feasibility study and finalize the
process model to be used.
Aim:
The aim is to design a problem statement, performa detailed feasibility study and finalize the
process model to be used.
PROBLEM STATEMENT:
Credit Card Application Management System Project is a web-based technology the main
purpose of this project is to provide all online credit card application management. Users can apply
for credit cards online and check the application status by using his/her name /mobile
number/application number.
SCOPE:
The Scope of Credit Card Management system is to allow users to
Filling application form, Proof verification, Credit limit calculation, Card replacement
Credit card renewal, Purchase through credit card, Payment, Credit card monthly statement (
fine if any + purchase details
FEASIBILITY STUDY:

Feasibility Study is used to evaluate a project's potential, including the technical, financial,
and economic aspects, and to determine whether it should proceed.

 Technical Feasibility: The technical feasibility study always focuses on the existing
computer hardware, software and personal. This also includes need for more hardware,
software or personal and possibility of procuring or installing such facilities. Electronic Cash
Counter is a system that can work on single stand alone Pentium machine with 128 MB
RAM, Hard disk drive size of 80 GB, mouse, monitor and keyboard & it also require internet
connection to corresponding computer.The equipments are easily available in the market, so
technically the system is very much feasible
 Economical Feasibility: This feasibility is useful to find the system development cost and
checks whether it is justifiable. The cost overheads include software and hardware
maintenance cost, training costs that includes cost required for manpower, electricity,
stationary etc. The Electronic Cash Counter system will provide the right type of information
at right time, and in the required format. This will save time required for decision-making and
routine operations. Considering all these advantages, the cost overheads of the system are
negligible. So the system is economically feasible.
 Operational Feasibility : It is also known as resource feasibility. The operation users of the
system are expected to have minimum knowledge of computer. The developed system is
simple to use, so that the user will be ready to operate the system. The Electronic Cash
Counter system can be developed using JAVA programming language & Mysql database
which is platform independent and user friendly. So the system is operationally feasible.

2
PROCESS MODEL
Agile Model

The Agile process model is preferred for developing an Electronic Cash Counter due to
several reasons,
1. Iterative and Incremental Development:
Agile promotes an iterative and incremental development approach. This allows for
continuous refinement and improvement of the system based on user feedback.
2. Flexibility to Changing Requirements:
Agile allows for flexibility in adapting to changes during the development process, ensuring
the system aligns with the evolving requirements and market conditions.
3. Frequent User Involvement:
Agile emphasizes regular collaboration with end-users. In the context of an Electronic Cash
Counter system, involving users throughout the development process ensures that the system meets
their needs, enhances usability, and aligns with regulatory requirements.
4. Continuous Integration and Testing:
Agile encourages continuous integration and testing, allowing developers to identify and
address issues early in the development cycle. This helps in ensuring the reliability and security of the
software.
5. Rapid Delivery of Value:
Agile focuses on delivering a minimum viable product (MVP) quickly. In the case of an
Electronic Cash Counter, this means that essential functionalities can be delivered and deployed
rapidly, allowing users to start benefiting from the system sooner.
6. Adaptability to Risks:
The financial sector comes with inherent risks and uncertainties. Agile provides a framework
for adapting to changes and managing risks effectively during the development process, ensuring that
the system can respond to unforeseen challenges.
7. Close Collaboration Between Teams:
Agile encourages close collaboration among cross-functional teams. For a complex system
like an Electronic Cash Counter, this collaboration is essential as it involves integrating hardware,
software, security measures, and compliance considerations.
8. Customer Satisfaction:
Agile focus on customer satisfaction aligns with the goal of delivering a reliable and user-
friendly Electronic Cash Counter system. Regular feedback and involvement of end-users contribute
to a product that better meets their expectations.

Result:
Thus the problem statement has been defined, feasibility study has been explained in detail
and the process model is finalized.
Task 2
Software Requirement Specification Document

3
Aim:
To prepare Software Requirement Specification Document for Book Bank system.

1 Introduction
1.1 Purpose
1.2 Scope
1.3 Definition,AcronymsandAbbreviation
1.4 Reference
1.5 Overview
2 SystemDescription
2.1 ProductPerspective
2.2 ProductFunctions
2.3 UserFunctions
2.4 SystemConstraints
2.5 SystemDependencies
2.6 RequirementsSubdomain
3 SpecificSystemRequirements
3.1 FunctionRequirements
3.2 Non-FunctionalRequirements
3.3 ExternalInterfaces
4 Appendices

Filling application formProof verificationCredit limit calculationCard replacement

Credit card renewalPurchase through credit cardPaymentCredit card monthly statement
Credit Card Application Management System Project is a web-based technology the main
purpose of this project is to provide all online credit card application management. Users can apply
for credit cards online and check the application status by using his/her name /mobile
number/application number.

1 Introduction
The Credit card Management System version 1.0 is a sophisticated solution, aiming to
revolutionize the way of using credit card, fostering a culture of learning and literary exploration. the
Credit card management System is a comprehensive platform designed to Credit Card Application
Management System Project is a web-based technology the main purpose of this project is to provide
all online credit card application management. Users can apply for credit cards online and check the
application status by using his/her name /mobile number/application number .

1.1Purpose
The purpose of this document is to illustrate the requirements of the project Credit card
Management System. The document gives the detailed description of both functional and non
functional requirements proposed by the client. The document is developed after a number of
consultants with the client and considering the complete requirements specifications of the given
project. The final product of the team will be meeting the requirements if this document.
1.2 Scope
The Credit card System will include features such as Filling application formProof
verificationCredit limit calculationCard replacementCredit card renewalPurchase through
credit cardPaymentCredit card monthly statement
1.3 Definitions, Acronyms, and Abbreviations

4
Member The one who registers himself and implement online transaction.
Database Database is used to store the details of Credit card
Administrator The one who verifies the Credit card
1.4 References
The references for the above software are as follows:-
i. www.google.co.in
ii. www.wikipedia.com
iii. IEEE. Software Requirements Specification Std. 30-1993.
1.5 Overview
 Chapter 1.0 discusses the purpose and scope of the software.
 Chapter 2.0 describes the overall functionalities and constraints of
the software and user characteristics.
 Chapter 3.0 details all the requirements needed to design the software.

2. System description
2.1 Product Perspective
This Credit card Management system replaces the traditional, manual Credit card
management by which lot of paper work will be reduced. This system will provide a search
functionality to facilitate the resources..
2.2.Product Function
There are two different users who will be using this product.
1)User(Member)
2)Admin
The practise of issuing credit or reclaiming credit when it is due is known as credit card
management. It guarantees that the company's credit policy is followed, as well as doing other
credit-related tasks. The bank's purpose in credit control is to increase revenue and profit. It's
accomplished by raising sales while lowering financial risks.
A credit manager is someone who works in the credit department and is in charge of it.
Decisions are made by the manager in the following areas: Limitations on credit, Payment
terms, Enforcement Actions with Customer, Accounts, Acceptable Levels of Risk, Receive and
Collect

2.3 User Function

a) Admin:
Card product management develops and implements credit card product strategies, as
well as marketing plans, in order to drive corporate growth and meet industry
standards.
To issue a credit card, you must first select the card. Then you must apply for the card
and finally activate it. A credit card authorization confirms that a customer's card has
sufficient money to cover the transaction. This is an issuer's approval, which is
normally obtained through a credit card processor
b) User (Member):
Customers will only think about the card's yearly charge. However, there are a
number of other credit card fees to consider, including Payday Loans Fee, Over-limit Fee,
Charges for late payments, Rates of Interest. After the moratorium, credit card charges
were paid.
Interest is applied to all debts, while extra charges are applied to debts that
aren't paid on time. The interest rate changes from time to time, but it might also be the
same. Missed payments have no effect on the interest rate.
.
2.4 System constraints
System constraints outline limitations or restrictions that may impact the development or
operation of the Credit card management System.

5
  Compatibility Constraints: The system must be compatible with modern web browsers such
as Google Chrome, Mozilla Firefox, and Safari.
 Budgetary Constraints: The development and maintenance budget for the Book Bank
System is limited, requiring cost-effective solutions and efficient resource utilization.
 Infrastructure Requirements: The system is dependent on a reliable internet connection for
users to access online features and services.
 User Access Constraints: Users must have internet access to benefit from the online
reservation and personalized recommendation features.
 Hardware Limitations: The system should be designed to run on standard hardware
configurations, taking into account potential limitations in processing power and memory.
 Data Privacy and Security Compliance: The system must adhere to data privacy and
security regulations, imposing constraints on the collection, storage, and processing of user
data.
 Software Dependency Constraints: The system may rely on third-party software or
libraries, and any dependencies should be clearly defined.
 Accessibility Standards: The Book Bank System must comply with accessibility standards
to ensure usability for individuals with disabilities.
 Backup and Recovery Constraints: The system must implement regular backup procedures,
and recovery mechanisms should be in place in case of data loss or system failures.
2.5 System dependencies
Credit card management system depends on a designated database system for the storage and
management of Credit card transaction and user records. Network infrastructure is crucial for
online features and communication between system components, while barcode scanning
technology is essential for automated check-in/check-out processes.
The system may use third-party libraries or APIs for functionalities such as personalized book
recommendations. Web technologies, including HTML, CSS, and JavaScript, are integral to the
user interface and online features. Integration with an existing user authentication system, stable
server infrastructure, and compliance with geographical data hosting and accessibility standards
are additional dependencies. Backup and recovery mechanisms safeguard against data loss, and the
choice of programming language and framework, along with potential integration with a payment
gateway, further contribute to the system's functionality.

3.Specific system requirement

3.1Functional Requirements:
3.1.1. New card
The customer gives their information to enroll a new card. The information is all about their
contact details. They can create their own login and password for the future use of the card.
3.1.2 Login
In Login Form module presents site visitors with a form with username and password fields.
If the user enters a valid username/password combination they will be granted access to additional
resources on website. Which additional resources they will have access to can be configured
separately.
3.1.3 Security information
In Security information module it will get the information detail andstores in database.If the
card is lost then the Security information module form arise. It has a set of question where the user
has to answer the correctly to move to the transaction section.
3.1.4 Transaction
The credit card owner initiates a credit card transaction by communicating to a credit card
number, and storing therein, a distinguishing piece of information that characterizes a specific
transaction to be made by an authorized user of the credit card at a later time.
3.1.5 Verification
In verification the process will seeks card number and if the card number is correct the
relevant process will be executed. If the number is wrong, mail will be sent to the user saying the card
no has been block and he can’t do the further transaction.

6
3.1.6 Authentication:
The user information should always be authenticated. Only authorized person would login.
3.2 Non-Functional Requirements :
3.2.1 Performance Requirements
Performance requirements tells about the software capability to respond on users’ action
such as:
Upon running the application, it should not take more than 3 seconds.
Data validation shouldn’t take above 5 seconds.
Result generation should be achieved within 5 seconds.
3,2,2 Security requirements
Security is implemented in our project as we have implemented any security things like login
form or authentication to users.As our system which is secured so it cannot be accessed by any
unauthorized user.
3.2.3 Reliability
The system will never crash or hang, other than as the result of an operating system error. The
system shall provide graceful degradation in the face of Frauds.
3.2.4 Maintainability The code will be fully documented. Each function will be commented with
pre- and post- conditions the code will be modular to permit future modifications. The software admin
should be able to manage the data.
3.2.5 Availability
The software can be used anytime.
3.3 External Interface
3.3.1User Interface
It will provide a platform through which the user can communicate with the vendors
3.3.2 Hardware Interface
 User Devices-The system should be compatible with standard personal computers, laptops,
and mobile devices for user access.
 Barcode Scanners- Self-service kiosks require compatible barcode scanners for automated
check-in and check-out processes.
 Network Compatibility- A stable network infrastructure is essential to facilitate
communication between the server and user devices.
3.3.3 Software interface
The software interfaces are specific to the target book bank software systems.
 Languages supported: java (Front end)
 Database: SQL Server (Back end)
 MS-Office
 ArgoUml /StarUml
3.3.4 Communication Interface
These are protocols that are needed to directly interact with the customers. Apart
from these protocols, to maintain a healthy relationship with the customer, both formal and
informal meetings, group discussions and technical meetings will be conducted frequently
4.Appendices
Appendix A: Definition
Appendix B: Database Schema

Result:
Thus the Software Requirement Specification Document for Book Bank system has been
Prepared.

Task 3
To Prepare a detailed estimate using the FP and COCOMO Model. Also prepare a detailed
schedule of the project.

7
Aim:

To perform the estimation (FP and COCOMO) and to develop a project schedule.

FP Model:

The functional size of the product is measured in terms of the function point, which is a
standard of measurement to measure the software application.

 Step-1:
F = 14 * scale
Scale varies from 0 to 5 according to character of Complexity Adjustment Factor
(CAF). Below table shows scale:
0 - No Influence
1 - Incidental
2 - Moderate
3 - Average
4 - Significant
5 - Essential

 Step-2: Calculate Complexity Adjustment Factor (CAF).

CAF = 0.65 + ( 0.01 * F )
 Step-3: Calculate Unadjusted Function Point (UFP).
TABLE (Required)

Function Units Low Avg High

EI 3 4 6

EO 4 5 7

8
 Function Units Low Avg High

EQ 3 4 6

ILF 7 10 15

EIF 5 7 10

Multiply each individual function point to corresponding values in TABLE.

 Step-4: Calculate Function Point.
FP = UFP * CAF
Computing the function point when all complexity adjustment factor (CAF) and weighting factors are
average, Also computing the productivity, documentation, cost per function for the following data:
1. Number of user inputs = 24
2. Number of user outputs = 46
3. Number of inquiries = 8
4. Number of files = 4
5. Number of external interfaces = 2
6. Effort = 36.9 p-m
7. Technical documents = 265 pages
8. User documents = 122 pages
9. Cost = $7744/ month

9
Solution:

10
COCOMO Model
A project was estimated to be 400 KLOC. The effort and development time for each of the
three model i.e., organic, semi-detached & embedded is calculated by basic COCOMO.

The basic COCOMO equation takes the form:

Effort=a*(KLOC)b PM
Tdev=c*(efforts)d Months

Estimated Size of project= 400 KLOC

(i)Organic Mode

E = 2.4 * (400)1.05 = 1295.31 PM

D = 2.5 * (1295.31)0.38=38.07 PM

(ii)Semidetached Mode

E = 3.0 * (400)1.12=2462.79 PM
D = 2.5 * (2462.79)0.35=38.45 PM

(iii) Embedded Mode

11
 E = 3.6 * (400)1.20 = 4772.81 PM
D = 2.5 * (4772.8)0.32 = 38 PM

Project scheduling:

A project schedule is a timetable that organizes tasks, resources and due dates in an ideal
sequence so that a project can be completed on time.

Result:
Thus, the estimation(FP and COCOMO) has been performed project schedule is prepared.

12
 Task 4
Identify Use Cases and develop the Use Case model for the given scenario Draw the
relevant Entity Relationship Diagram and class diagram.

Aim:
The aim is to Identify Use Cases and develop the Use Case diagram,Entity Relationship
Diagram and class diagram for the given scenario.

Use case diagram

A use case diagram at its simplest is a representation of a user's interaction with the system
that shows the relationship between the user and the different use cases in which the user is involved.
Use case
A use case describes the sequence of actions a system performs yielding visible results

Actor
An actor represents the roles that the users of the use cases play. An actor may be a person
(e.g. student, customer), a device (e.g. workstation), or another system (e.g. bank, institution).

The actors in this use case diagram are customer, vendor and card reader. The use
cases are the activities performed by actors.

The actors in this use case diagram are

Customer – used to purchase some item from the shop by using credit card payment.
Vendor – used to issue a bill for selected item and verify the card holder signature and then
delivery the item.
Card reader – its make the amount transaction for required credit card and print the
balance statement.
Purchase item – customer enter the shop to purchase some item by using credit card
payment.
Bill issue – vendor will make a bill for the selected item.
Swap the card – vendor will swap the card.
Make transaction– card reader will processes the amount transaction.
Print the statement – after the transaction, balance amount should be printed.
Signature – customer should put the signature and give it to vendor.
Deliver the item–vendor issued to deliver a item..

13
E-R Diagram

 The Entity-Relation model represents real-world entities and the relationship between them.
An ER diagram is used to design database data models.
 Components of a ER Diagram
 Entities
 Attributes
 Relationship

14
Class Diagram
Class Diagram a type of static structure diagram that describes the structure of a system by
showing the system's classes, their attributes, operations (or methods), and the relationships among
objects

The purpose of the class diagram can be summarized as:

• Analysis and design of the static view of an application.
• Describe responsibilities of a system.
• Base for component and deployment diagrams.
• Forward and reverse engineering.

Class diagrams commonly contain the following things

• Classes
• Interfaces
• Collaborations
• Dependency, generalization and association relationships

DOCUMENTATION OF CLASS DIAGRAM:

The Classes used in this project are:
• Customer – is the class name. Its attributes are name, age, signature, and card number. The
operations performed in the customer class are purchase item and swap the credit card.
• Vendor – is the class name. Its attributes are name, address, and phone number. The operations
performed are make bill and then delivered item purchased by the customer.

15
• Card Reader – is the class name. Its attributes are machine number, software and company.
The operations performed are make the transaction and print balance statement.

Result

Thus the Use Cases has been identified and the Use Case diagram, Entity Relationship
Diagram and class diagram for the given scenario has been designed

16
 Task 5
Interaction Diagram(UML Sequence & Communication diagram).

Aim:
The aim is to find the interaction between objects and represent them using UML Sequence &
Communication diagrams.

Interaction diagrams
Interaction diagram depict interactions of objects and their relationships. They also include the
messages passed between them. There are two types of interaction diagrams −
 Sequence Diagram
 Collaboration Diagram
Interaction diagrams are used for modeling
 the control flow by time ordering using sequence diagrams.
 the control flow of organization using collaboration diagrams.

Sequence diagram
A sequence diagram is a type of interaction diagram because it describes how—and in what
order—a group of objects works together. A sequence diagram shows, as parallel vertical lines
(lifelines), different processes or objects that live simultaneously, and, as horizontal arrows, the
messages exchanged between them, in the order in which they occur.
Drawing a sequence diagram helps to
 Represent the details of a UML use case.
 Model the logic of a sophisticated procedure, function, or operation.
 See how objects and components interact with each other to complete a process.
 Plan and understand the detailed functionality of an existing or future scenario.

Notations:
1.Object

2.Actor

3.Lifeline

DOCUMENTATION OF SEQUENCE DIAGRAM:

The customer wants to purchase some item from the shop; Vendor makes a bill for the
selected item. The Customer gives the credit card to the vendor to the swap the card. The further
transaction is proceeding for if the credit card is validated. Vendor will issue the required balance
statement to the customer. Customer put the signature in the receipt and returns the one copy of
statement to the vendor

17
Collaboration Diagram
The collaboration diagram is used to show the relationship between the objects in a system.
Both the sequence and the collaboration diagrams represent the same information but differently.
Instead of showing the flow of messages, it depicts the architecture of the object residing in the
system as it is based on object-oriented programming.
An object consists of several features. Multiple objects present in the system are connected to each
other. The collaboration diagram, which is also known as a communication diagram, is used to
portray the object's architecture in the system.
Notations
Notations used in communication diagrams are the same notations for sequence diagrams.
 Rectangles represent objects that make up the application.
 Lines between class instances represent the relationships between different parts of the
application.
 Arrows represent the messages that are sent between objects.
 Numbering lets you know in what order the messages are sent and how many messages are
required to finish a process.

18
DOCUMENTATION OF COLLABORATION DIAGRAM:
In this diagram there is sequence of ordered relationship should performing in the CCP, then
Customer will performed a selecting item, putting signature, and deliver the item, Vendor should
perform the swap the card, issue the statement and Card reader should perform amount transaction
and print the balance statement.

19
Result
Thus,interaction between objects and UML Sequence & Communication diagrams for the
given scenario has been designed.

20
 Task 6
User Interface diagrams, State Transition diagram and Activity diagrams

Aim:
The aim is to model the User Interface diagrams, State Transition diagram and Activity
diagram for the given scenario.

User Interface Diagram

User interface (UI) design is the process designers use to build interfaces in software or
computerized devices, focusing on looks or style.

User interface design for a book bank system aims to make it easy and straightforward for
users to find, borrow, and return books. It includes clear menus, search bars, and buttons for
navigation, ensuring users can quickly locate books they need. The design prioritizes simplicity and
ease of use, ensuring a pleasant experience for all users interacting with the system. Visual elements
like buttons, icons, and color schemes are chosen to enhance usability and guide users through the
process seamlessly. Additionally, the design ensures accessibility for users of all abilities, making it
simple for anyone to navigate and utilize the book bank system effectively.

State Transition diagram

The state machine diagram is also called the Statechart or State Transition diagram, which
shows the order of states underwent by an object within the system.
Notations

The Entire process of CCP could be shown in the start state to goal state behavior should
be performed by the Customer, Vendor and Card reader in this credit card processing system.

Activity diagram
Activity diagrams show the flow of one activity to another within a system or process

Notations

An activity diagram for a book bank system outlines the sequence of actions involved in
borrowing and returning books. It typically begins with a user accessing the system and logging in.

21
From there, the diagram branches into activities such as searching for books, selecting items for
borrowing, and checking out. Subsequently, it may depict activities like renewing loans or returning
books. Each action is represented by a sequential flow of steps, simplifying the process of how users
interact with the book bank system from start to finish.

Fig

Figure: Activity Diagram

Result

Thus the User Interface diagrams, State Transition diagram and Activity diagram for the given
scenario has been designed.

22
 Task 7
Object Diagram and Software Architecture Diagram

Aim:
The aim is to implement partial layered, Object Oriented and logical software architecture
diagram to visualize the high level design.

Object Diagram:
UML object diagram is an instance of a class diagram. An object diagram encompasses
objects and their relationships which may be considered a special case of a class diagram or
a communication diagram.

Object Diagram Symbols and Notations

1.Object Name

2.Object Attributes

3.Links

Diagram

23
Architecture diagram
Software architecture is all about how a software system is built at its highest level. Software
architecture provides a basic design of a complete software system. It defines the elements included in
the system, the functions each element has, and how each element relates to one another. It is a big
picture or overall structure of the whole system, how everything works together.

24
Result

Thus the Object Oriented and logical software architecture diagram to visualize the high level
design for the given scenario has been designed.

25
 Task 8
Data Flow Diagrams

Aim:
The aim is to implement the Data Flow Diagrams to perform the data modelling with Level 0,
Level 1, and Level 2 analysis.

Data Flow Diagarm

A data flow diagram (DFD) maps out the flow of information for any process or system. It
also gives insight into the inputs and outputs of each entity and the process itself. DFD does not
have control flow and no loops or decision rules are present.

Notations in DFD

Levels of DFD
DFD uses hierarchy to maintain transparency thus multilevel DFD’s can be created. Levels of DFD
are as follows:
 0-level DFD: It represents the entire system as a single bubble and provides an overall
picture of the system.
 1-level DFD: It represents the main functions of the system and how they interact with
each other.
 2-level DFD: It represents the processes within each function of the system and how
they interact with each other.
 3-level DFD: It represents the data flow within each process and how the data is
transformed and stored.

26
Level 0 DFD

Level 1 DFD

27
Level 2 DFD

Result

Thus the the Data Flow Diagrams to perform the data modelling with Level 0, Level 1and
Level 2 analysis for the given scenario has been designed.
Task 9

28
 Test cases for both Black box Testing and White Box Test Testing
Aim:
The aim is to write the test cases for both Black box Testing and White Box Test Testing

Black Box Testing:

Black box testing for a book bank system involves testing the system's functionalities without
knowing its internal code or structure. Here are some use cases for black box testing of a book bank
system.

est Cases Description

1. Verify that a registered user can log in successfully with the correct
username and password.
2. Test various combinations of incorrect usernames and passwords and
ensure that the system does not allow access.
3. Check if the system is case-sensitive when comparing usernames
during login.
4. After a certain number of failed login attempts, ensure that the user
account is locked and cannot be accessed until unlocked by an
administrator.
5. Ensure that users can deactivate their accounts and that they can’t log
in after deactivation.
6. Test the functionality of logging in using social media accounts (e.g.,
Login
Google, Facebook) if supported.
7. Verify that the session times out correctly after the specified period of
inactivity.
8. Verify that appropriate error messages are displayed for different
login failure scenarios, such as incorrect password, account locked, or
invalid username.
9. Test the logout functionality to ensure users can log out securely and
that they cannot access restricted pages after logout.
10. Verify that session data is maintained securely and cannot be
tampered with.
11. Test the behavior of the login functionality when users use the
browser’s back button after logging out.
1. Verify that the user registration form is accessible and displays
correctly in various browsers and devices.
2. Ensure that all required fields (e.g., name, email, password, date of
birth, contact information) are present and labeled correctly.
3. Test input validation for each field (e.g., valid email format, password
complexity, date of birth format).
4. Verify that appropriate error messages are displayed for invalid
inputs.
New User
5. Test that the system prevents users from registering with an email
address that is already associated with an existing account.
6. Verify that the user’s password is securely encrypted and stored in the
database.
7. Check if the application sends a confirmation email with a
verification link to the user’s provided email address.
8. Confirm that users can successfully register and login after email
verification.

29
 9. Verify that the registration form includes a CAPTCHA or a similar
mechanism to prevent automated bot registrations.
10. Confirm that the new user is assigned the appropriate user role (e.g.,
customer) during registration.
11. Verify that the application displays clear and user-friendly error
messages for registration failures (e.g., email already in use, server
errors).
1. Verify that there is a clear and easily accessible link or button on the
login page to access the “Forgot Password” functionality.
2. Test input validation for the email address or username field to ensure
it only accepts valid inputs.
3. Verify that appropriate error messages are displayed for invalid
inputs.
4. Check that submitting a password reset request with a valid email
address or username generates a confirmation message.
5. Verify that an email with a password reset link is sent to the user’s
registered email address.
Forgot
6. Ensure that clicking the password reset link from the email takes the
Password
user to a secure password reset page.
7. Verify that the password reset form is accessible and displays
correctly in various browsers and devices.
8. Ensure that all required fields (e.g., new password, confirm password)
are present and labeled correctly on the reset form.
9. Test input validation for the new password field, checking for
password complexity rules and error messages for invalid inputs.
10. Confirm that after successfully resetting the password, the user
receives a confirmation message.
11. Test that users can log in with the new password after resetting it.
1. Verify that users can access the account overview page after
successfully logging in.
2. Test that only authorized users can view their account overview and
that unauthorized users are redirected to the login page.
3. Confirm that the account overview displays a summary of the user’s
accounts (e.g., checking, savings, loans).
4. Check that clicking on each account in the overview provides detailed
information, including account number, transaction history, and interest
rates (if applicable).
Account 5. Verify that the transaction history for each account is displayed
Overview correctly and includes details such as date, description, amount, and
transaction type (e.g., deposit, withdrawal).
6. Test the functionality to download account statements or generate
PDF statements for each account.
7. Verify that the account overview respects the user’s selected currency
and locale preferences.
8. Confirm that the application correctly identifies and categorizes
different account types (e.g., checking, savings, credit card).
9. Check if users receive alerts or notifications for important account
events (e.g., low balance, large transactions).
Banking 1. Verify that users can access the service request section of the
Service application from the main menu or dashboard.

30
Requests 2. Test different types of service requests, including account statements,
fund transfers, bill payments, account closure, and credit/debit card
authorization, depending on the application’s offerings.
3. Verify that each service request type has a dedicated form with
appropriate fields.
4. Test input validation for service request forms, checking for valid data
entry and proper error handling for invalid entries.
5. Test whether users receive a confirmation email with the details of
their service request.
6. Check that users can track the status of their service requests, whether
they are pending, in progress, or completed.
7. Verify that the application displays clear and user-friendly error
messages for service request submission failures.
8. Test the process of canceling a pending service request before it is
processed.
9. See if the service request option allows users to access their
credit/debit card bill statements.
10. Check if users can apply for new cards and block old ones.
1. Verify that users can access the beneficiary management section from
the main menu or dashboard.
2. Ensure that the beneficiary addition form is accessible and displays
correctly in various browsers and devices.
3. Confirm that the beneficiary addition form includes fields for
beneficiary name, account number, bank name, branch details, and
payment method (e.g., NEFT, RTGS, IMPS).
4. Test input validation for each field in the beneficiary addition
Adding a form Ensure that the application prevents users from adding the same
Beneficiary beneficiary more than once.
5. Test the process for verifying the beneficiary’s details, which may
involve sending an OTP or confirmation email.
6. Confirm that users receive a confirmation page or message after
successfully adding a beneficiary.
7. Test the ability to edit beneficiary details, including name, account
number, and payment method.
8. Confirm that users can delete beneficiaries from their list if they are
no longer needed.
1. Verify that users can access the money transfer section from the main
menu or dashboard.
2. Test the ability to select recipients (beneficiaries) from the user’s
beneficiary list for money transfers.
3. Confirm that the application verifies recipient details (e.g., account
number, beneficiary name) before proceeding with the transfer.
4. Test the ability to enter the transfer amount, ensuring it meets account
Money Transfer
balance and transaction limits.
5. Test various payment methods (e.g., NEFT, RTGS, IMPS) and ensure
that the selected method is processed correctly.
6. Check the option to include a message or note with the money
transfer (if supported).
7. Ensure that users are required to enter a valid PIN or receive and
verify an OTP (One-Time Password) before completing the transfer.

31
 8. Confirm that the transaction details are accurately recorded in the
user’s transaction history.
9. Verify that the application enforces transaction limits and
communicates these limits clearly to users.
1.Verify that admin users can log in using their credentials.
2. Ensure that only authorized admin accounts can access the admin
panel.
3. Confirm that the admin dashboard displays up-to-date and relevant
information and statistics.
4. Test the ability of the admin to add, edit, and delete user accounts.
5. Verify that user details (name, contact information) can be modified
by the admin.
6. Test the admin’s ability to lock or unlock user accounts for security
reasons.
Admin Role 7. Verify that the admin can assign or modify user roles (e.g., teller,
manager, customer support) as required.
8. Ensure that the admin can access and review an audit trail of user
activities and system changes.
9. Check the accuracy and completeness of the audit log.
10. Verify that the admin can deactivate and reactivate user accounts,
temporarily or permanently.
11. Confirm that the admin can configure and enforce security policies
(e.g., password complexity, session timeouts) for users.
12. Confirm that the admin can create and manage access control lists
for different user roles and functions.
1. Verify that authorized users can access the branch management
section from the admin panel.
2. Confirm that the branch creation form includes fields for branch
name, address, contact information, and branch manager details.
New Branch 3. Check that each branch is assigned a unique branch code or identifier.
4. Test the ability to assign a branch manager to the new branch during
creation.
5. Verify that the application allows selection of the branch type (e.g.,
main branch, regional branch).


White Box Testing:
White box testing, also known as structural testing, involves examining the internal logic and
structure of the software system. For a book bank system, white box testing ensures that the internal
components, algorithms, and code paths function correctly. Here's how white box testing can be
applied to a book bank system, along with use cases:
Here are some white box test cases for a Book Bank System along with the expected results:

Challenges Description Solutions

32
 Use sanitized or anonymized test data in
Protecting sensitive customer data
Security Concerns test cases. Implement data masking or
during testing.
tokenization where necessary.

Ensuring that the application complies Regularly update test cases to reflect
Compliance with
with financial regulations and data changes in regulations. Involve
Regulations
protection laws. compliance experts in testing efforts.

Limit access to production-like data in

Data Privacy and Safeguarding customer information
testing environments. Use encryption
Confidentiality and transaction data.
and secure data transfer protocols.

Conduct load testing and stress testing

Performance Testing the application’s performance
to simulate peak loads. Monitor system
Testing under heavy loads.
resources and optimize code as needed.

Use automated tests to validate data

Data Integrity and Ensuring that account balances and
accuracy and perform regular data
Accuracy transaction history are accurate.
reconciliation.

Use multithreaded testing tools to

Concurrency and Detecting and addressing issues
simulate concurrent transactions and
Race Conditions related to concurrent transactions.
identify race conditions.

Conduct mobile compatibility testing on

Mobile Testing the application on various
different devices and platforms to
Compatibility mobile devices and screen sizes.
ensure a responsive design.

There may be gaps or incomplete

There should be complete participation
Specification information about functional and
of testers in the project right from the
Requirements non-functional in the specification
initial requirement analysis phases.
document.

Result
Thus the test cases for both Black box Testing and White Box Test Testing has be written
successfully.

33
 Task 10
Prototype of the Project
Aim:
The aim is to Develop a prototype of the project with database management system and
deploy the project.

Component Diagram
A component diagram is used to break down a large object-oriented system into the smaller
components, so as to make them more manageable. It visualizes the relationships as well as the
organization between the components present in the system.

A component diagram for a book bank system illustrates the different components or modules
that make up the system and how they interact with each other. The components identified are ECC
Machine, card reader, PIN pad, cash dispenser, network interface.

Notations in component Diagram

a) A component

b) A node

Package diagram

Package diagrams are structural diagrams used to show the organization and arrangement of
various model elements in the form of packages.

Notation in package diagram

34
Deployment Diagram

35
 The deployment diagram visualizes the physical hardware on which the software will be
deployed. The main purpose of the deployment diagram is to represent how software is installed on
the hardware component

Notations in Deployment Diagram

Result

Thus the prototype of the project with database management system and deployment of the project
has be designed successfully
Part II Use Cases

Use Cases 1: Analyse and implement the Employee management and Payroll Processing
application.
36
 Develop an Employee Management System for a start up company. The company has
multiple departments, each with its own team of employees. The goal is to create a
centralized system that efficiently manages employee data, facilitates HR processes, and
ensures smooth communication within the organization. Please outline the key features,
functionalities, and considerations for the Employee Management System. Additionally,
describe how the system would handle various scenarios, such as employee onboarding, leave
requests, performance evaluations, and security measures to protect sensitive employee
information. Consider both the HR team's perspective and the employees' experience.

Use Cases 2: Build the Library Management system application with project plans,
schedule, estimation and design.
Construct a Library Management System (LMS) for a city library. The library serves
a diverse community and houses a collection of books, journals, and multimedia resources.
The goal is to create a user-friendly system that enhances the efficiency of library operations,
improves user experience, and provides valuable insights for library administrators. Please
outline the key features, functionalities, and considerations for the Library Management
System. Additionally, describe how the system would handle various scenarios, such as user
registrations, borrowing and returning items, inventory management, and overdue fines.
Consider both the librarian's perspective for system administration and the user's experience
in borrowing and accessing library resources.

Use Cases 3: Design, Analyse and implement the Passport Automation System application
Develop a Passport Automation System for a government agency. The agency
processes a large volume of passport applications, renewals, and replacements. The goal is to
create an efficient and secure system that enhances the passport application experience for
citizens while ensuring accuracy and compliance with regulatory requirements. Please outline
the key features, functionalities, and considerations for the Passport Automation System.
Additionally, describe how the system would handle various scenarios, such as new passport
applications, expedited processing, biometric data collection, and security measures to
prevent identity theft and fraud. Consider both the applicant's perspective and the internal
processes involved in passport issuance.

Use Cases 4:Identify, plan, analyse and implement the E Voting System application.
Sketch an E-Voting System for a national election. The government aims to
modernize the voting process, increase accessibility, and enhance the overall efficiency of the
election. Please outline the key features, functionalities, and considerations for the E-Voting
System. Additionally, describe how the system would handle various scenarios, such as voter
registration, ballot casting, result tabulation, and security measures to ensure the integrity of
the election process. Consider both the voter's experience and the administrative aspects of
managing the election.

37