A CASE Lab Report - Project File on "ATM - Banking System"

1
A
Case Lab Report
On
" ATM - Banking System "
Submitted in partial fulfilment for the award of the degree of
BACHELOR OF TECHNOLOGY
In
COMPUTER SCIENCE & ENGINEERING
2018-2019
Submitted To: Submitted By:
Er. NAVEEN TIWARI Ashwani Sharma
Assistant Professor (16EAYCS015)
Computer Science & Engineering Bharat Saini
(16EAYCS019)
DEPARTMENT OF COMPUTER SCIENCE & ENGINEERING
ARYA COLLEGE OF ENGINEERING & RESEARCH CENTRE,
JAIPUR RAJASTHAN TECHNICAL UNIVERSITY, KOTA

2
CONTENT
S. No Topic Page No.
1. Introduction
 Objective
 Scope
 CASE tool
3
2. SDLC 5
3. Requirement Analysis
 Feasibility Study
 Project Planning
 SRS
8
4. Implementation
 ER Diagram
 DFD Diagram
 Modules
 UML Diagram
15
5. Testing
 Introduction
 Unit Testing
 Integration Testing
 White Box Testing
 Black Box Testing
21
6. Conclusion and future scope 22
7. References and Bibliography 23

3
Topic – 1
INTRODUCTION
1.1 Objective:-
The aim of this project is to develop ATM based software that can perform the
following objectives.
oTo make the bank transaction in the most efficient manner.
oTo enable more people, have access to ATM banking facility.
oTo encourage the transition to cashless society.
oReduce the risk involved in carrying huge sum of money about by making
deposit in ATM.
oPeople can save and withdraw the money at any time by themselves and
reduce staff work through ATM banking.
1.2 Introduction:-
The software to be designed will control a simulated automated teller machine
(ATM) having a magnetic stripe reader for reading an ATM card, a keyboard and
display for interaction with the customer, a slot for depositing envelopes, a
dispenser for cash (in multiples of $20), a printer for printing customer receipts, and
a key-operated switch to allow an operator to start or stop the machine. The ATM
will communicate with the bank's computer over an appropriate communication
link. (The software on the latter is not part of the requirements for this problem.)
1.3 Scope:-
The software supports a computerized banking network called ‘Bank24’. The network
enables customers to complete simple bank account services via automated teller
machine (ATMs) that may be located off premise and that need not be owned and
operated by the customer’s bank. The ATM identifies a customer by a cash card and
password. It collects information about a simple account transaction (e.g., deposit,
withdrawal, transfer, bill payment), communicates the transaction information to the
customer’s bank, and dispenses cash to the customer.
The bank provides their own software for their own computers.

4
1.4 CASE Tools:-
Computer-Aided Software Engineering (CASE), in the field of Software Engineering
is the scientific application of a set of tools and methods to a software system which
is meant to result in high-quality, defect-free, and maintainable software products,
it also refers to methods for the development of information system together with
automated tools that can be used in the software development process. The CASE
function include analysis, design, and programming. CASE tools automate methods
for designing, documenting, and producing structured computer code in the
desired Programming language.
Computer-aided software engineering (CASE) is software to support software
development and evolution process.
Two key ideas of Computer-aided Software System Engineering (CASE) are:
oThe harbouring of computer assistance in software development and or
software maintenance processes, and
oAn engineering approach to the software development and or
maintenance.

5
Topic – 2
SOFTWARE DEVELOPMENT LIFE CYCLE (SDLC)
Q.What is SDLC model?
Software Development Life Cycle (SDLC) is a process used by the software industry
To design. Develop and test high quality software's. The SDLC aims to produce a
High-quality software that meets or exceeds customer expectations, reaches
Completion within times and cost estimates.
oIt is also called as Software Development Process
oSDLC is a framework defining tasks performed at each step in the software
Development process.
The following figure is a graphical representation 0f the various stages of a typical
SDLC.
Planning
Defining
Designing
Building
Testing
Deployment
SDLC

6
Software Development Life Cycle consists of the
following Stages –
Stage 1: Planning and Requirement Analysis
Requirement analysis is the most important and fundamental stage in SDLC. It is
performed by the senior members of the team with inputs from the customer, the
sales departments, market surveys and domain experts in the industry. This
information is then used to plan the basic project approach and conduct product
feasibility study in the economical, operational and technical areas.
Stage 2: Defining Requirements
Once the requirement analysis is done the next step is to clearly define and
document the product requirements and get them approved from the customer or
the market analysis. This is done through an SRS (software Requirement
Specification) document which consists of all the product requirements to be
designed and developed during the project life cycle.
Stage 3: Designing the product architecture
SRS is the reference for product architects to come out with the best architecture
for the product to be developed. Based on the requirements specified in SRS,
usually more than one design approach for the product architecture is proposed
and documented in a DDS – Design Document Specification.
This DDs is reviewed by all the important stack holder and based on various
parameters as risk assessment, product robustness, design modality, budget and
time constraints, the best design approach is selected for the product.
Stage 4: Building or Developing the Product
In this stage of SDLC the actual development starts and the product is built. The
programing code is generated as per DDS during the stage. If the design is
performed in a detailed and organized manner, code generation can be
accomplished without much hassle.
Developers must follow the coding guidelines defined by their organization and
Programming tools like compilers, interpreters, debuggers, etc. are used to
generate the code. Different hill. Level programming languages such as C, Pascal.
Java 7 and PHP are used for coding. The programming language is chosen with
respect to the type of software being developed

7
Stage 5: Testing the Product
This stage is usually a subset of all the stages as in the modern SI. Models, the testing
activities are most, involved in all the stages of SDLC. However, this stage refers to
the testing only stage of the product where product defects are reported, tracked,
fixed and retested, until the product reaches the quality Standards defined in the
SRS.
Stage 6: Deployment in the Market and Maintenance
Once the product is tested and ready to be deployed it is released formal, in the
appropriate late market. Sometimes product deployment happens in stages as per
the business strategy of that organization. The product may first be released in a
limited segment and tested in the real business environment (UAT- User acceptance
testing). Then based on the feedback, the product may be released as it is or with
Suggested enhancements in the target market segment • after the product is
released in the market. Its maintenance is done for the existing customer base.

8
Topic – 3
Requirement Analysis
It is a software engineering task that bridges gap between the system level requirements
engineering and software design. In ATM what the requirements system wants are
mentioned with the classification of requirements.
3.1 Types of Requirements in ATM System :-
There are different types of requirements including customer requirements,
functional requirements, performance requirements, design requirements,
behavioural requirements, derived requirements, and allocated requirement. In
order to design the new system, information obtained from methods that are used
to identify customer, functional, and behavioural requirements is used.
The following sub-sections present common types of requirements categories in
ATM system.
 Customer Requirements
Customer requirements define the expectations customer's in terms of objective,
environment, constraints and measure of effectiveness of the project/system.
They help identify the following:
a) Operational set-up:-
At what location(s) will the system (ATM) be installed and used
by stakeholders?
b) Mission:-
What is the objective of the system? In other word, what is its
mission and how will it achieve this?
c) Performance:-
What are the milestones and results that are needed to be
achieved for comparison and evaluation against the objective
of the system?
d) Utilization:-
The system will have many parts to it that make up the overall
system. How will they be used?
e) Effectiveness:-
In order to achieve its objective, the ATM system has to be
functioning effectively. This effectiveness is measured.

9
f) Life Cycle:-
Once the system is live and being used by the user, how long will
its life cycle be
g) Environment:-
Similar to the operational set-up, this distinguishes the
environments in which the system will effectively operate in.
 Architectural requirements
Architectural requirements define system architecture that includes
both structure and behaviour of the ATM system.
 Structural requirements
Structural requirements define the ATM system structure.
 Behavioural requirements
Behavioural requirements identify the behaviour of the ATM system. In
other words, it identifies the way the system interacts with the user and
the effect it will on the user.
 Functional requirements
Functional requirements define the tasks/activities of the ATM system.
 Non-Functional Requirements
This type of requirement focuses on the operation of the ATM system,
not the way it interacts with the user. It looks at the inside of the system
rather than the interface.
 Performance requirements
Performance requirements define the expectation of the ATM system
mission in terms of the performance metrics such as quality, quantity,
coverage, timeliness, and readiness.
 Design requirements
Design requirements define how the project/system processes are to
be executed including building/designing the system, coding the
applications and buying requirements for products.

10
 Derived requirements
Derived requirements are implied, derived, and transformed from a
higher level requirement.
 Allocated requirements
Allocated requirements are established by breaking down a key
requirement into many minor ones. And also it is related in ATM
Systems.
So above mentioned are the classification of each and every
requirements of ATM system.
3.2 Feasibility Study :-
Feasibility Studies must be based on Conceptual Design decisions, i.e. the definition
of the main technical and commercial aspects of a project, with any alternative
solutions reduced to a minimum.
A Feasibility Study includes a number of steps, such as a technical analysis,
market analysis, project Cost Estimate, analysis of financial resources
and Profitability evaluation.
ATM has the suitable experience to assist its Customers to:
1. Identify the optimum solutions for all automation and telecom aspects;
2. Perform any relevant technical and economic analyses;
3. Identify a possible overall Control System Architecture;
4. Minimize project risks and uncertainties;
5. Perform the cost estimate for Automation and Telecommunication.
In order to answer these critical questions, a project feasibility study must be
conducted. The project feasibility study is a document containing a detailed
description of the project, followed by a set of different feasibility areas. These
are aspects of the project that will drive the success or failure of the project.
This study will provide the necessary information so that you can decide
whether or not your project will begin or whether it has a shot at success.
Steps to a Project Feasibility Study
1. Description of the Project :-
What are the important details of the ATM System?
The project feasibility study should start with the basic details of the project
And provide a purpose or goal for the project.
A project description must include a detailed description of the project

11
Scope and what the project will do and how it will do it. Also included is
information regarding the stakeholders; those who have a vested interest
in the project or will be impacted by the project. The description of the
project should contain a relatively detailed timeline and task breakdown,
including what will be done, when, and by whom. It is also important to
detail the end result of the project. What will the project produce or
create for the company?
2. Market Feasibility: -
Does anyone need this product or service?
Does anybody want this product or service? Will anybody use it? Is there a
similar product/service currently available that will prevent project
success? If your project assumes customers will pay for use of a
product/service, you must ensure that the market exists.
Where necessary, you must identify a pricing model and ensure similar
products/services are not currently available at a lower price.
If you continue with the project, investing time, money and resources, and
nobody pays for the service, the project will be a failure.
3. Team Feasibility:-
What are your team’s internal expectations for the campaign?
One of the most common challenges that non-profits face when
preparing for a fundraising campaign is a misalignment of internal
expectations.
In fact, your organization risks fundraising failure if your executive leaders,
staff, and board aren’t on the same page when it comes to important
campaign goals and expectations.
For example, as your non-profit prepares for the feasibility study your
consultant should determine if clarification is needed in areas such as:
 Campaign timeline.
 Fundraising goal.
 Stewardship strategy.
 Organizational growth strategies.
 Staffing assignments.
 Board responsibilities.
If there are misunderstandings related to the campaign’s fundraising plan,
now is the time to iron them out. By the time stakeholder interviews are
conducted, your proposed fundraising plan should be finalized and clearly
understood by your whole team.
After all, if different team members are under different impressions of how the
campaign will play out, the findings collected during the study simply won’t
be useful.

12
4.Path :-
What is a path forward with our non-profit consultant?
Your non-profit’s feasibility study isn’t over at the end of stakeholder
interviews. After your consultant has conducted interviews and
gathered the findings of your study.
3.3 Project Planning:-
Project planning is an organized and integrated management process,
which focuses on activities required for successful completion of the project.
It prevents obstacles that arise in the project such as changes in projects or
organization's objectives, non-availability of resources, and so on.
Project Planning Process
Project planning process consists of the following activities.
 Identification of project requirements: Before starting a project, it is essential to
identify the project requirements as identification of project requirements helps in
performing the activities in a systematic manner. These requirements comprise
information such as project scope, data and functionality required in the software,
and roles of the project management team members.
 Identification of cost estimates: Along with the estimation of effort and time, it is
necessary to estimate the cost that is to be incurred on a project. The cost
estimation includes the cost of hardware, network connections, and the cost
required for the maintenance of hardware components.
 Identification of risks: Risks are unexpected events that have an adverse effect on
the project. Software project involves several risks (like technical risks and business
risks) that affect the project schedule and increase the cost of the project.
 Identification of critical success factors: For making a project successful, critical
success factors are followed. These factors refer to the conditions that ensure
greater chances of success of a project.
 Preparation of project charter: A project charter provides a brief description of the
project scope, quality, time, cost, and resource constraints as described during
project planning. It is prepared by the management for approval from the sponsor
of the project.
 Preparation of project plan: A project plan provides information about the
resources that are available for the project, individuals involved in the project, and
the schedule according to which the project is to be carried out.
 Commencement of the project: Once the project planning is complete and
resources are assigned to team members, the software project commences.

13
3.2 Software Requirement Specification :-
A SRS should be selected or defined at the starting of the Requirements Analysis.
There is no perfect SRS of any software, however a good SRS must have following
characteristics:
1. Correct:
An SRS is correct if every requirement if every requirement included in the SRS
represents something required in the final system. Correctness ensure that what
is specified is done correctly, completeness ensures that everything is indeed
specified.
2. Complete:
An SRS is complete if this software is supposed to do the responses of the
software to all classes of input data are specified data into SRS.
3. Unambiguous (unmistakable):
An SRS is unambiguous if and only is every requirement stated or return has
one and only one interpretation.
4. Verifiable:
Verification of requirements is done through reviews. It also implies that an SRS
is understandable at least by the developer, by client and by the user.
5. Consistent:
An SRS is consistent if there is no requirement that conflict with another
terminology can cause in consistency. There may be logical conflict may be
requirement causing
inconsistency.
6. Ranked of importance / Stability:
An SRS is ranked for an importance a stable if for each requirement the
importance and stability of a requirements reflect a terms of expected
change stability of a requirement reflects in futures. Writing and SRS is an
interactive process, when the requirement systems are specified.
7. Modifiable:
They are later modified as the needs of the clients change. SRS should be
easy to modify. SRS is modifiable if its structures and style are such that any
necessary change can be made easily while continuing completeness and
consistency.

14
8. Traceable:
An SRS is traceable if the origin of each of its requirement is clear and if it fulfil
the reference in of each requirement in feature development should be
traceable to some design and code element and back word traceability
requirement. If be possible to trace design and code element to the
requirement.
9. Feasibility:
Though it may not be possible to confirm the feasibility of implementation of
all the requirements, any requirement which is apparent infeasible, should be
eliminated from SRS.
Sample SRS on ATM System
1. Introduction
1.1 Purpose of the ATM Software
1.2 Scope of the System
1.3 References
1.4 Overview of ATM System
2. General Description
2.1 Product Perspective
2.2 Product Functions
2.3 User Characteristics
2.4 General Constraints
3. Specific Requirements
3.1 Functional Requirements
3.1.1 Introduction
3.1.2 Inputs
3.1.3 Processing
3.1.4 Outputs
3.2 External Interface Requirements
3.2.1 Hardware Interfaces
3.2.2 Software Interfaces
3.3 Performance requirements
3.4 Design Constraints
3.4.1 Standard Compliance
3.4.2 Hardware Limitations
3.5 Attributes
3.5.1 Security
3.5.2 Maintainability
3.6 Other Requirement

15
Topic – 4
Implementation
4.1 ER Diagram :-

16
4.2 DFD Diagram :-
Fig :- Level-0 DFD
Fig :- Level-1 DFD

18
4.4 UML Diagram :-
Class Diagram

19
Use case Diagram
UML Collaboration Diagram

21
Topic – 5
Testing of ATM System
5.1 Introduction
Software testing is the process of evaluation a software item to detect
differences between given input and expected output. Also to assess the
feature of A software item. Testing assesses the quality of the product.
Software testing is a process that should be done during the development
process. In other words, software testing is a verification and validation
process.
5.2 Unit Testing
Unit testing is the testing of an individual unit or group of related units. It falls
under the class of white box testing. It is often done by the programmer to
test that the unit he/she has implemented is producing expected output
against given input.
5.3 Integration Testing
Integration testing is testing in which a group of components are combined
to produce output. Also, the interaction between software and hardware is
tested in integration testing if software and hardware components have any
relation. It may fall under both white box testing and black box testing.
5.4 White box Testing
White-box testing (also known as clear box testing, glass box testing,
transparent box testing and structural testing, by seeing the source code)
tests internal structures or workings of a program, as opposed to the
functionality exposed to the end-user. In white-box testing, an internal
perspective of the system, as well as programming skills, are used to design
test cases.
5.5 Black box Testing
Black box testing is a testing technique that ignores the internal mechanism of the
system and focuses on the output generated against any input and execution of
the system. It is also called functional testing.Black box testing is often used for
validation and white box testing is often used for verification. One advantage
of the black box technique is that no programming knowledge is required.
Whatever biases the programmers may have had, the tester likely has a
different set and may emphasize different areas of functionality. On the other
hand, black-box testing has been said to be "like a walk in a dark labyrinth
without a flashlight.

22
Topic – 6
Conclusion and future scope
Conclusion
In this thesis we have tried to conclude various types of vulnerabilities exist in current
scenario and which type of security we are providing to overcome the vulnerabilities.
Various security aspects conclude in this thesis. Various categories of vulnerabilities
like physical, operational, communicational vulnerabilities are studied and Various
security issues are also studied and concluded in our findings which may helpful to
make the ATM transactions more safe and secure. This thesis covering security and
technical issues with ATM transaction. Because of our particular experience in the
area, we focused our research activities on ATM cards and encryption, beginning
with hardware vulnerability and security issues and then operational and (xv)
communicational vulnerability and security prospective and naturally continuing
with software aspects and operational issues of our present work.
Future Scope
The ATM technology has developed to such an extent that some ATMs can memorize
consumer preferences as per their past transactions, behaviour, and tailor services
accordingly. In many cases, ATMs have internet scope which facilitates two way
communications with live agents, provide biometric options, and have the ability to
demonstrate personalized advertisements.
Maintenance of web enabled ATMs are easy. These ATMs can be quickly connected
to central monitoring system of vendors.
Though ATM industry is growing rapidly, there are many challenges related to security
issues of the software, increase of rental costs by the day in major cities,
housekeeping, and replenishment of cash. Few banks have introduced biometric
ATMs in rural India, which are quite secure and easy to use by a common man.

23
Topic – 7
References and Bibliography
Books
oGiriappa Somu (2002), “Impact of Information Technology
on Banks”, Mohit Publication.
oCooper D. R., Schindler P. S. (2003), “Business Research
Methods”, Tata McGrawHill.
Reports
oReserve Bank of India. (1984). Report of the Committee on
Mechanisation in banking Industry.
oRBI (1989) Report of the committee on computerization in
banks (The Rangarajan committee) Mumbai: Reserve
Bank of India.
Websites
www.rbi.org.in
www.Banknetindia.com

A CASE Lab Report - Project File on "ATM - Banking System"

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to A CASE Lab Report - Project File on "ATM - Banking System"

Similar to A CASE Lab Report - Project File on "ATM - Banking System" (20)

Recently uploaded

Recently uploaded (20)

A CASE Lab Report - Project File on "ATM - Banking System"