Atm Doc

UOM IBM MS (Tech) 7th Semester
1. ABSTRACT
In this Project we present a a model for the utilization of biometrics

equipped Automatic Teller Machines (ATMs) to provide a number of
social services including identity verification and disbursement of social
security, unemployment, welfare and pension benefits to a la rge
segment of the population. The paper summarizes how ATMs have
matured into a technology application providing financial services to a
segment of our society, and the technical functionality behind the
provisioning of those services. Biometrics innovation and functionality
is explored and a technical model is developed for its integration
to existing ATM devices, networks and databases. The paper concludes
by outlining potential benefits to business, government and individuals,
as well as some of the social and legal barriers to be overcome.
ATM Management system-Biometric ATM , a Proposal -1-

2. INTRODUCTION
ATM innovation paralleled the growth of the PC and

telecommunications industries. Each machine operated in a local mode
without any connection to the banking systems, and transaction
authorization took place based on the information recorded in the
magnetic bands of the cards. The next step in the evolution of this
industry was to connect these devices to the bank’s centralized
systems; by then, mid -1980’s, banks would work in a dual modality,
in other words, the ATM would work on-line but in the event of
communication loss it had the ability to authorize the transaction with
the information recorded on the magnetic band.
In the early 90’s, taking advantage of the technological boom in

microcomputers and communications, ATMs started to work exclusively
on-line implying that, if the ATM loss communication with its central
system, there would not be service. Once ATMs were connected
directly, the need arose to protect the information in the card and the
client’s PIN (Personal Identification Number) found in messages that
had to travel across public telecommunication lines. For this purpose,
from the beginning, algorithms that allowed for the encryption of the
information were utilized; the most commonly utilized algorithm
is(Delta Encryption Standard).

1.1.1 Purpose, Scope, and Objectives
The purpose of the project is to analyze the requirements of, design,

implement, and maintain the software for both the central bank server and
the ATM client machines that will comprise the specific Bank ATM
network, according to the requirements specified by the client.
All activities directly related to the purpose are considered to be in scope. All
activities not directly related to the purposes are considered to be out of
scope. For example, issues concerning ATM hardware and network
availability are not within the scope of this project.
The objectives of the project are as follows:
• complete the project by the project due date
• complete the project within budget
• provide all deliverables identified in section 1.1.3 by the project due date
• fulfill all stated requirements, as in the SRS, of the software product

deliverable, which fall into one of the following categories
 central bank customer database modifications

 interface with central bank computerized accounting system
 customer ATM transactions
 customer ATM statement
 weekly statistical report of ATM operations

Assumptions and Constraints
The project will be planned with the following assumptions:
• this project is a component of a larger project
• this project will deliver only the software components of the larger project
• initial estimates for the project as provided in this SPMP are +/- 40%
• the larger project that this project is a part of has already defined the
hardware that the software will run on
• the software products will be Windows NT-based using Windows Open

Services Architecture / eXtensions for Financial Services (WOSA/XFS),
supporting NNB’s desire for an open architecture ATM product
• the ATM hardware has documentation available suitable for interface

discovery
• the ATM hardware is defined (4th generation NCR ATM hardware) and
detaileddocumentation about the platform will be delivered to Terasoft by
June 1, 2004.
• a documented physical ATM computer network is being created in a

separate project and will exist between each ATM client and the central bank
in time for acceptance testing
• the ATM hardware is being handled as a separate project and will be

available in time for the installation phase
• we will be able to acquire the expertise of two outside consultants from

Banks, Etc. to assist with the requirements elicitation and detail design of the
ATM client/server software
• this SPMP is submitted as a firm-fixed-price (FFP) bid; the project shall

not exceed the established budget
The project will be planned with the following constraints:
• budget
 $3,000,000 (25% of total $12,000,000 budget; software portion only)

 Time : one year: once the software product is installed on the ATM
machines, it will take 30 days for NNB to install the physical ATM
machines in their permanent locations
 Staff two outside consultants from Banks Etc. will be required to
assist in the requirements and detail design phases of the project, so as
to lend their extensive ATM experience to the project. The consultants
will also supplement our team elsewhere, as necessary.
 Maintenance : the software will have to be designed such that
maintenance expenses do not exceed $100,000 per year (software
maintenance portion of the total $600,000 budget)

Project Deliverables
• Software program and library binaries
• Software documentation
 Installation documentation
 End-user documentation
 updates applied to NNB’s central bank documentation
• Installation of software program and library binaries on target

hardware
• Software training performed against affected users
 ATM site users (i.e. bank branch staff)

 ATM site installers
 Software maintenance team
• Project documentation
 Software Requirements Specification (SRS)

 Software Design Specification (SDS)
 Software Project Management Plan (SPMP)
 Software Test Plan (STP)
 Software Quality Assurance Plan (SQAP)
 Software Configuration Management Plan (SCMP)
 Software Verification and Validation Plan (SVVP)

Evolution of the Plan
The plan is considered to be a dynamic document and will be updated

monthly by default and on an unscheduled basis as necessary
Scheduled updates to the plan will occur once every month, on the
last business day of the month. Notification of scheduled and
unscheduled updates to the plan will be communicated via e-mail to
all project participants according to the Reporting Plan.
Start-up Plan
Estimation Plan
Schedule, Cost, and Resource Estimates: An estimation chart
showing activities, estimated duration, estimated cost, and estimated
resource requirements.
Estimation methods
Schedule duration and work estimation for each leaf activity in the
Work Breakdown Structure (WBS) will be performed using a
combination of the following methods and data sources:
o Resource input
For the resource(s) identified as being required to complete the
activity, the resources will be asked for an estimate of the amount of
time required to complete the activity. A detailed estimate will be
requested, broken down into subactivity milestones. Subactivity
milestones tied to the “% complete” metric will force a consideration
of everything that is involved in the activity as well as providing a
basis for EVM monitoring.

o When more than one resource is assigned to the activity, their

estimates will be collected independently and, if substantially
different, meetings will be held between the project manager and all
resources so that an agreement may be reached on a final estimate.
This is in the spirit of the wideband delphi approach, but is modified
for the size of our organization and tight project schedule.
o Organizational project history data

Data from those that are most relevant will be used to fine-tune the
estimates for the activities on this project.
o Contractor project history data

o The contracting company that we use to assist in financial software
development project has a substantial project history from which we
can draw. The acquisition of two contractors from the company, as
outlined in the project staffing plan, will give us access to this data
for the purpose of making estimates.
PROJECT STAFFING PLAN
In terms of domain-specific knowledge as it relates to the

development ATM software, we have accommodated our limited
experience in this area by recognizing the need for two consultants
from a company with which we have had a good working relationship
in the development of financial software. The two consultants whose
services we will acquire from Banks, Etc. will fill our knowledge gap in
this area.

WORK PLAN
Work activities must be documented. Schedule allocation , Resource

allocation and Budget allocation must be recorded
5. PROJECT ORGANIZATION
5.1 PROCESS MODEL
The project shall utilize a combination of Iterative and Waterfall

development approach, with three interim deliveries prior to the final
build. Content of each build shall be determined by the Program
Manager with direct input from the customer regarding need dates for
required functionality.
PROJECT RESPONSIBILITIES
PROGRAM MANAGER - The Project Manager shall be responsible for
defining and controlling project work activities and schedules. Other
team members shall work in conjunction with the project manager to
define the elements of their task assignments, establish a schedule
baseline, collect metric data to assess performance against that
baseline, and conduct re-base lining activities as required. The Project
Manager shall submit the initial baseline and any baseline modifications
to the Program Manager for approval.
CONFIGURATION MANAGER - The CM is responsible for maintaining a
matrix of all customer approved requirements; is responsible for
oversight of the requirements change control process; is responsible

for applying changes to requirements matrix; is responsible for

maintaining the modification history of requirements.
QA/TEST MANAGER - The QA/Test Manager is responsible for verifying
that the delivered product satisfies the approved requirements; is
responsible for documenting the results of the requirements
verification in a Test Analysis Report.
BUSINESS ANALYST - is responsible for analyzing and evaluating
requirements for feasibility and impact to the project.
RISK MANAGER - The Risk Manager is responsible for identifying the

risks likely to compromise the project success; is responsible for
assessing the loss probability and loss magnitude for each identified
risk; will prioritize the risks as they are identified and bring them to the
attention of the group; is responsible for planning for, resolving and
monitoring each risk item.
DEVELOPER - The developer is responsible for designing a system
satisfying the requirements; is responsible for creating prototypes, as
necessary, for feasibility studies; is responsible for creating and
changing all source files in accordance with the change and control
process; is responsible for documenting the source files for
maintenance purposes.
TESTER
CUSTOMER REPRESENTATIVE - The customer is responsible for
defining and approving all requirements, and all modification to
requirements.
PRODUCT MANAGER - The product manager is responsible for
periodically reviewing the content, organization and style of the system
ATM Management system-Biometric ATM , a Proposal - 10 -

Performance Reporting
The project will report performance to plan with the following metrics:
Earned Value
• Budgeted Cost of Work Scheduled (BCWS) vs. Budgeted Cost of
Work
• Performed (BWCP)
• Schedule Variance (CV)
• Budgeted Cost of Work Performed (BCWP) vs. Actual Cost of
Work
• Performance (ACWP)
• Cost Variance (CV)
• Cost Performance Index (CPI)
• Schedule Performance Index (SPI)
Critical Ratio (CR)
• Estimated Cost at Completion (ECAC)
• Estimated Time at Completion (ETAC)
Requirements
• Requirements change count
Configuration
• Configuration churn
Quality
• Open defects vs. closed defects over time
• Lines of code (LOC)
• Comment percentage
• Defects per LOC

Risks
• Risk exposure
• Top 10 risks
• Weekly risk changes
Methods, Tools, and Techniques
Development methodology
• The project shall use the waterfall software development

methodology to deliver the software products, with work
activities organized according to a tailored version of those
provided by the IEEE Standard for Developing Software Life
Cycle Processes (IEEE 1074-1997). The decision to use the
waterfall methodology is due to the following characteristics of
the project:
• the product definition is stable

• requirements and implementation of the product are both very
well-understood
• technical tools and hardware technology are familiar and well-
understood
• waterfall methodology has proven successful for projects of this
nature performed by
• The Software Project Management Plan (SPMP) shall be based on
the IEEE Standard for Software Project Management Plans (IEEE
1058-1998).

Development techniques
The requirement passed down to this project from the larger ATM
project is that the software be based on an open architecture using
a Windows NT-based platform and Windows Open Services
Architecture / eXtensions for Financial Services (WOSA/XFS). This
architecture allows us to use object-oriented methods and tools for
analysis, design, and implementation. We will use Object Modeling
Technique (OMT) for this purpose.
Tools
The following work categories will have their work products satisfied
by the identified tools:
• Team member desktop foundation
• Microsoft Windows 2000 desktop operating system
• VMWare Workstation 4.5 [virtual machine support – one VM
per active project]
• Microsoft Office 2003 productivity application suite
• IBM Lotus Notes R6 [e- mail, calendar]
• MindJet MindManager X5 Pro [information organization,
brainstorming]
• Adobe Acrobat 6.0 [creating/viewing PDF files]
• Project management
• Microsoft Project 2003 [WBS, schedule/cost estimates,
resource planning, project
• control]
• Best Carpe Diem [electronic time sheet]
• Tera metric [internally-developed metrics collection database]

• Document publishing (applies to all documents published by

the project)
• Microsoft Word 2003 [document preparation and revision]
• Configuration Management & Change Management
• IBM Rational Clear Case LT [version control]
• IBM Rational Clear Quest [defect and change tracking]
• Quality
• Terametric [internally-developed metrics collection database]
• Requirements
IBM Rational RequisitePro [requirements tracking]
• Design
IBM Rational Rose Data Modeler [database design]
IBM Rational Rose Technical Developer [use cases, non
database software design]
• Implementation
Microsoft Visual C++ [programming language, development
tools and object code generation]
Windows Software Development Kit (SDK) [programming
support]
• Testing
IBM Rational Robot [automated functional and
regression testing]
• Training
Microsoft PowerPoint 2003 [training presentations]
Online Performance Reporting
Microsoft Windows 2000 Server Standard [server operating
system],
Microsoft Internet Information Services 4.0 [web server

software]
ADDITIONAL FEATURES FOR THE ATM PROPOSAL
BIOMETRIC MEASURE FOR ENHANCING ATM SECURITY
It is important to mention that in parallel to the development of the

industry different modes of fraud have made it necessary to reinforce
the levels of security utilized in ATMs; this leads to the theme of this
investigation: to adapt biometric technology to the ATM networks
Cards with Magnetic Bands

The plastic cards with magnetic bands date back to more than 30
years. The financial sector has used them as a means to making
payments and to offer access to the financial services for clients. The
magnetic band contains unique information for every card allowing for
user identification and providing access to its products through the
various electronic channels. In order to provide access to these
products, cards with magnetic bands are normally associated to a
personal identification number (PIN) which is initially assigned by the
entity issuing the card and, in some cases, the client can then change
it at his/her convenience. The card and the PIN are directly related to
the user identification and allow for the utilization of electronic
channels just like as is the case with the ATMs.

ATM Hardware and Software Characteristics

We may classify the hardware for an ATM in two major categories: the
first one, corresponding to its PC architecture (a microprocessor,
memory, drives, monitor, keyboard, etc.), the second one related to
ATM specific functions such as card reading, cash dispensing, cash
storage, user and operator’s video and keyboard interaction, etc.
Based on the PC architecture, the software included in an ATM is not
very different to that which is found in a personal computer. It has an
operating system (OS/2, or Windows based). The telecommunication
system is today mostly oriented to services based on the TCP/IP
protocols.The application software is most of the time provided by the
manufacturer of the ATM machine. It normally offers an interface
allowing for each financial institution to adapt its own applications.
Transaction Functionality
We have described the various elements that intervene in an ATM
transaction, the card and the ATM components. Figure 1 shows the
sequence of events involved in the authorization process together with
the functionality of the central authorization system to which the ATM
is connected.

Biometric Technology
The term biometrics comes from the word bio (life) and metric
(measurement). Biometric equipment has the capability to measure,
codify, compare, store, transmit, and/or recognize a specific
characteristic of a person with a high level of precision and
trustworthiness. Biometric technology is based on the scientific fact
that there are certain characteristics of living forms that are unique
and not repetitive for each individual; these characteristics represent
the only technically viable alternative to positively identify a person
Without the use of other forms of identification more susceptible to
fraudulent behavior

Biometric identification is utilized to verify a person’s identity by

measuring digitally certain human characteristics and comparing those
measurements with those that have been stored in a template for that
same person. Templates can be stored at the biometric device, the
institution’s database, a user’s smart card, or a Trusted Third Party
(TTP) Service Provider’s database. Where database storage is more
economic than plastic cards, the method tends to lack public
acceptance; however, Polemi (1997) found that TTPs can provide the
confidence that this method is missing by managing the templates in a
trustful way.
There are two major categories of biometric techniques: physiological

(fingerprint verification, iris analysis, hand geometry-vein patterns, ear
recognition, odor detection, DNA pattern analysis and sweat pores
analysis), and behavioral (handwritten signature verification,keystroke
analysis and speech analysis). Deane et al. (1995) found that behavior
based systems were perceived as less acceptable than those based on
physiological characteristics.Of the physiological techniques, the most
commonly utilized is that of fingerprint scanning.
Restricted in the past due to its high cost and lack of social acceptance,
biometric identification is now experiencing a higher level of
acceptance not only in high security applications such as banks and
governmental facilities, but also in health clubs, sports events, office
and industrial sites. Costs have been reduced to a reasonable level and
functionality and reliability of the devices is today satisfactory.
Biometrics is also increasingly included in a wide range of verification

applications in e-commerce, financial electronic transactions, and
health information systems patient data storage and dissemination.
Components of a Biometric System
The processes associated with a biometric methodology: enrollment,

identification/verification, and learning.

Enrollment: Prior to an individual being identified or verified by a

biometric device, we must complete the enrollment process with the
objective of creating a profile of the user. Enrollment is a relatively
short process, taking only take a few minutes and consisting of the
following steps:
1. Sample Capture: the user allows for a minimum of two or three

biometric readings, for example: placing a finger in a fingerprint
reader. The quality of the samples, together with the number of
samples taken, will influence the level of accuracy at the time of
validation. Not all samples are stored; the technology analyzes and
measures various data points unique to each individual. The number of

measured data points varies in accordance to the type of device.
2. Conversion and Encryption: the individual’s measurements and data

points are converted to a mathematical algorithm and encrypted.
These algorithms are extremely complex and cannot be reversed
engineered to obtain the original image. The algorithm may then be
stored as a user’s template in a number of places including servers,
PCs, or portable devices such as PDAs or smart cards. Identification
and Verification. Once the individual has been enrolled in a system,
he/she can start to use biometric technology to have access to
networks, computer centers, buildings, personal accounts, and to
authorize transactions. Biometric technology determines when a
person could have access in one of the two forms be it identification or
verification. Some devices have the ability to do both.
1. Identification: a one-to-many match. The user provides a biometric

sample and the system looks at all user templates in the databa se. If
there is a match, the user is granted access, otherwise, it is declined.
2. Verification: a one-to-one match requiring the user provides
identification such as a PIN or a smart card in addition to the biometric
sample. In other words, the user is establishing who he/she is and the
system simply verifies if this is correct. The biometric sample with the
provided identification is compared to the previously stored information
in the data base. If there is a match, access is provided, otherwise, it
is declined.
Learning. Each time the user utilizes the system the template is
updated through learning processes taking into account gradual

changes due to age and physical growth. These are later utilized by the
system to determine whether to grant or deny access.
Technical Model Development
The integration of the two technologies requires the incorporation of

the fingerprint sensor to the ATM, and the interaction of the biometric
system with the ATMs and the authorizing system. The following steps
outline in more detail the necessary modifications:
1. We start by connecting the biometric system to the same network
utilized by the ATMs and authorization system. The biometric system
needs to be compatible with the communications protocol (most likely
TCP/IP) utilized by the other devices.

2. The biometric system will need software to allow it to “listen” to the

network communications for messages directed to it, and to create
messages for the other devices.
3. The fingerprint sensor is installed on the ATM; it will have the
capability to connect (via the network) to the biometric system. It also
needs to be protected from vandalism and be weather -resistant.
4. Through software changes, the ability to identify a customer

requiring fingerprinting will be incorporated to the ATM. User screens
will be created to guide the client through the process of entering the
fingerprint and receiving notification of fingerprint acceptance or
denial.
5. The authorizing system software needs to identify when a

transaction requires fingerprinting so that it can prompt the ATM to
present the screen(s) requesting the user to place his finger on the
reader, at the same time in which it instructs the biometric system to
read and validate the fingerprint for transaction authorization. The
authorizing system will also be modified to accept the validation results
from the biometric system and enter it into its log. Once the ATM,
authorizing system and biometric system have been interconnected,
the validation database needs to be built through the “enrolment”
process. User information (name, address, telephone number, etc.)
needs to be entered together with a key identifier such as card
number, social sec urity number, voter’s registration number, etc.
After all the information is entered, the application activates the sensor
and fingerprint(s) are read; the program can make multiple readings,
until it ascertains the quality of the sample meets the
pre-established standards for validation. Application software can

register prints for up to 10 fingers per individual. Figure 4 shows the
sequence of events involved in a transaction validation utilizing the
biometrics-equipped ATM system model.
Figure 4. Integrated model transaction validation sequence of events
Business Model Development Today, banks , other financial institutions
and, increasingly, retailers are offering Automatic Teller Machines
(ATMs) as a service , through the utilization of “transaction processing”
service companies who offer the daily management of the network
infrastructure, the authorization systems, and the inter -connection of
ATMs to multiple credit/bank card providers. Banks, other financial
institutions and retailers pay these banking services a fee based on a
fixed subscription cost as well as a variable cost associated with the
volume and types of customers and transactions. The banks then
charge their customers, typically, on a per transaction basis. ATM
service is no longer seeing as a competitive advantage, but as a
necessity to maintain the customer base.


Potential Benefits and Barriers
There are a lot of benefits which can be obtained from the synergistic
effect of offering welfare and pension payments through biometrics-
equipped bank ATM networks:
1. Government could reduce its cost and provide a more efficient and
timely service to its constituents.
2. Banks, other financial institutions and retailers could increase the
volume and reduce their ATM unit transaction costs; increase their
revenues by charging the government agencies for the service; and
expand their potential customer base.
3. Transaction processing services companies would increase their
revenues with a higher volume of transactions and from the
provisioning of biometrics database and verification services.
4. Pension and welfare recipients could receive their benefits faster, in
a more convenient and secure form.
5. The public at large could benefit through a reduction in taxes as a
result of a more efficient government.
There also are a number of barriers to the deployment of such a

system. There are countries where the capture and storage of
fingerprints by other than a government agency may be considered
illegal and/or a form of “big brother” control by the general public; or
where government may not want to outsource public functions to
private industry. There is a segment of the population which fears
computer or machine interface, and/or the natural resistance to
change inherent to most humans.

There are number of means to overcome these barriers

1. Use smart cards to store the biometric templates whenever the
storage of templates in a central database brings discomfort or
hesitation.
2. Educate people on the technologies and the differences between this
application and that of criminal databases.
3. Emphasize the advantages of biometric technologies, particularly
the added security to transactions.
4. Provide awareness of when, how and where people are
authenticated; they should know when and where they are identified
and verified, and which technology is being used.
USECASE DIAGRAM FOR ATM – TRANSACTION

Flows of Events for Individual Use Cases
System Startup Use case

The system is started up when the operator turns the operator switch
to the "on" position. The operator will be asked to enter the amount of
money currently in the cash dispenser, and a connection to the bank
will be established. Then the servicing of customers can begin.
System Shutdown Use Case

The system is shut down when the operator makes sure that no
customer is using the machine, and then turns the operator switch to
the "off" position. The connection to the bank will be shut down. Then
the operator is free to remove deposited envelopes, replenish cash and
paper, etc.

Session Use Case

A session is started when a customer inserts an ATM card into the card
reader slot of the machine. The ATM pulls the card into the machine
and reads it. (If the reader cannot read the card due to improper
insertion or a damaged stripe, the card is ejected, an error screen is
displayed, and the session is aborted.) The customer is asked to enter
his/her PIN, and is then allowed to perform one or more transactions,
choosing from a menu of possible types of transaction in each case.
After each transaction, the customer is asked whether he/she would
like to perform another. When the customer is through performing
transactions, the card is ejected from the machine and the session
ends. If a transaction is aborted due to too many invalid PIN entries,
the session is also aborted, with the card being retained in the
machine.
The customer may abort the session by pressing the Cancel key when
entering a PIN or choosing a transaction type.

Transaction Use Case
Note: Transaction is an abstract generalization. Each specific concrete

type of transaction implements certain operations in the appropriate
way. The flow of events given here describes the behavior common to
all types of transaction. The flows of events for the individual types of
transaction (withdrawal, deposit, transfer, inquiry) give the features
that are specific to that type of transaction.
A transaction use case is started within a session when the customer

chooses a transaction type from a menu of options. The customer will
be asked to furnish appropriate details (e.g. account(s) involved,
amount). The transaction will then be sent to the bank, along with

information from the customer's card and the PIN the customer
entered.
If the bank approves the transaction, any steps needed to complete

the transaction (e.g. dispensing cash or accepting an envelope) will be
performed, and then a receipt will be printed. Then the customer will
be asked whether he/she wishes to do another transaction.
If the bank reports that the customer's PIN is invalid, the Invalid PIN
extension will be performed and then an attempt will be made to
continue the transaction. If the customer's card is retained due to too
many invalid PINs, the transaction will be aborted, and the customer
will not be offered the option of doing another.
If a transaction is cancelled by the customer, or fails for any reason

other than repeated entries of an invalid PIN, a screen will be displayed
informing the customer of the reason for the failure of the transaction,
and then the customer will be offered the opportunity to do another.
The customer may cancel a transaction by pressing the Cancel key as

described for each individual type of transaction below.
All messages to the bank and responses back are recorded in the
ATM's log.

Withdrawal Transaction Use Case
A withdrawal transaction asks the customer to choose a type of

account to withdraw from (e.g. checking) from a menu of possible
accounts, and to choose a dollar amount from a menu of possible
amounts. The system verifies that it has sufficient money on hand to
satisfy the request before sending the transaction to the bank. (If not,
the customer is informed and asked to enter a different amount.) If the
transaction is approved by the bank, the appropriate amount of cash is
dispensed by the machine before it issues a receipt. (The dispensing of
cash is also recorded in the ATM's log.)
A withdrawal transaction can be cancelled by the customer pressing

the Cancel key any time prior to choosing the dollar amount.

Deposit Transaction Use Case
A deposit transaction asks the customer to choose a type of account to

deposit to (e.g. checking) from a menu of possible accounts, and to
type in a dollar amount on the keyboard. The transaction is initially
sent to the bank to verify that the ATM can accept a deposit from this
customer to this account. If the transaction is approved, the machine
accepts an envelope from the customer containing cash and/or checks
before it issues a receipt. Once the envelope has been received, a
second message is sent to the bank, to confirm that the bank can
credit the customer's account - contingent on manual verification of
the deposit envelope contents by an operator later. (The receipt of an

envelope is also recorded in the ATM's log.)
A deposit transaction can be cancelled by the customer pressing the

Cancel key any time prior to inserting the envelope containing the
deposit. The transaction is automatically cancelled if the customer fails
to insert the envelope containing the deposit within a reasonable
period of time after being asked to do so.

Transfer Transaction Use Case
A transfer transaction asks the customer to choose a type of account

to transfer from (e.g. checking) from a menu of possible accounts, to
choose a different account to transfer to, and to type in a dollar
amount on the keyboard. No further action is required once the
transaction is approved by the bank before printing the receipt.
A transfer transaction can be cancelled by the customer pressing the

Cancel key any time prior to entering a dollar amount.

Inquiry Transaction Use Case
An inquiry transaction asks the customer to choose a type of account

to inquire about from a menu of possible accounts. No further action is
required once the transaction is approved by the bank before printing
the receipt.
An inquiry transaction can be cancelled by the customer pressing the

Cancel key any time prior to choosing the account to inquire about.
Invalid PIN Extension
An invalid PIN extension is started from within a transaction when the

bank reports that the customer's transaction is disapproved due to an
invalid PIN. The customer is required to re-enter the PIN and the

original request is sent to the bank again. If the bank now approves
the transaction, or disapproves it for some other reason, the original
use case is continued; otherwise the process of re-entering the PIN is
repeated. Once the PIN is successfully re-entered, it is used for both
the current transaction and all subsequent transactions in the session.
If the customer fails three times to enter the correct PIN, the card is
permanently retained, a screen is displayed informing the customer of
this and suggesting he/she contact the bank, and the entire customer
session is aborted.
If the customer presses Cancel instead of re-entering a PIN, the

original transaction is cancelled.



User Interface Design
A user interface is a friendly means by which users of a system can

interact with the system to process inputs and obtain outputs. It is also
a means of communication between the human user and the system
through the use of input/output devices with supporting software. This
particular ATM application is made up of 6 interfaces, which include;
Login Interface, Enroll Fingerprint Interface, Transaction Type Selection
Interface, Withdrawal Interface, Deposit Interface, and View statement
of Account Interface.

This interface is the very first interface the bank customer interacts
with on the ATM machine. This interface prompts the customer to
insert ATM card and proceeds with the entire authentication processes,
that is, inputting the ID (or card number) and PIN number (see figure
3). If the user enters an invalid card number or PIN number, a
dialogue box appears prompting an invalid PIN or invalid card number
and the system returns enter a valid PIN number. A typical description
of this is shown in figure 4. After validating the customer’s card and
PIN number, the customer is directed to the next phase of the
authentication process via the authentication dialogue box for inputting
the fingerprint. LOGIN INTERFACE

Login interface response to invalid interface
Fingerprint Interface
This is the final interface the customer interacts with in the

authentication process. It requests from the customer the enrollment
of his/her fingerprint to be placed on a Fingerprint reader. The
fingerprint reader accepts the fingerprint and seeks to match the live
sample with the already enrolled templates in the banks database. If
match is confirmed it will finally authenticate customer else it will deny
customer access to his/her bank account.

The fingerprint of an individual is very peculiar to that individual since

no two individuals can have the same fingerprint. The fingerprint
reader captures the fingerprint features of an individual and search for
a match of fingerprint brought up for identification among the stored
fingerprints in the database. . The fingerprints stored are kept along
side the other ID’s (Pin and Card Numbers) and the corresponding
biometric templates are kept in the database. When the fingerprint is
found correct, the customer is taken to the transaction phase where
he/she will choose among the transactions (deposit or withdrawal),
otherwise the customer is denied access and the system brings up a
dialogue box for which the customer can choose Ok, and as soon as
this done the system automatically log off the customer.
Invalid Fingerprint Interface
Withdrawal Interface
This interface enables the customer withdraw money from his/her
account. It shows the customers current balance by subtracting the
amount withdrawn from the previous account balance. After the
customer has completed all his/her withdrawals, a dialogue box pops
up notifying the customer of his/her successful withdrawal transaction.
The interface is shown below.

1. Display all of the available rooms for a certain date
a. An agent requests all rooms for a given date that are available
2. Display all of the available rooms for a certain date with certain criteria
a. Display all rooms with a given number of types of beds

i. Display all with 1-n King Beds
ii. Display all with 1-n Queen Beds
iii. Display all with 1-n Double Beds
iv. Display all non-smoking rooms
v. Display all rooms with window view
vi. Display all rooms with kitchenette
vii. Display any combination of above
3. Purge reservations when agent signs in
a. When agent signs in, all reservations for days passed are purged and the screen
displays the number of reservations purged and their id’s and dates
4. Agent creates new reservation for a certain number of rooms for a certain
number of days
a. Agent receives confirmation number or error message depending upon success
b. Agent enters in details of person making the reservation

5. Agent deletes reservation from system (must remove all days and rooms)
6. Agent edits existing reservation
a. Agent changes one or more of the fields in the reservation
7. Agent creates a room configuration
a. Type of room (Luxury suite, penthouse, and executive suite) is specified
b. Number of beds and types of beds are specified (includes pull out couch)
c. Smoking or non-smoking specified
d. Number of bathrooms (1, 2,)
e. Kitchenette present
8. Agent prints out a bill for the hotel stay
a. A bill should be printed for each room
b. The bill needs to detail the cost of the room, taxes and any fees incurred
9. System files are backed up each time program is run
a. Need for the back up of the files each time you open and save them

USECASE DIAGRAM

7. ENTITY RELATIONSHIP DIAGRAM



8. RISK ANALYSIS AND MITIGATION PLAN
What is Risk?
Risk is defined as "The possibility of suffering harm or loss; danger." Even if we're not
familiar with the formal definition, most of us have an innate sense of risk. We are aware
of the potential dangers that permeate even simple daily activities, from getting injured
when crossing the street to having a heart attack because our cholesterol level is too high.
Although we prefer not to dwell on the myriad of hazards that surround us, these risks
shape many of our behaviors. Experience (or a parent) has taught us to look both ways
before stepping off the curb and most of us at least think twice before ordering a steak.
Indeed, we manage personal risks every day.
8.1 RISK ASSESSMENT
 Making a list of all of the potential dangers that will affect the project
 Assessing the probability of occurrence and potential loss of each item listed
 Ranking the items (from most to least dangerous)
Risks Identified in a Hotel Management Project are as follows:
1. PROPERTY
 Fire and Explosion
 Natural disaster and third party
 Security
 Environment
2. PEOPLE
 Health and safety

 Key personnel
3. OPERATIONAL
 Business interruption
 Project risk
 IT and communications
 Product liability
 Catastrophe recovery
 Regulatory compliance
4. COMMERCIAL
 Legal liability
 Industry risks
 Financial risk
 Political risk
 Exchange rate risk
 Corporate reputation
 Services liability
5. TOP TEN SOFTWARE RISKS IDENTIFIED
 Personnel Shortfalls
 Unrealistic schedules and budgets
 Requirements Mismatch/Gold Plating
 Developing the wrong functions and properties
 Developing the wrong user interface
 Continuing stream of requirements changes
 Shortfalls in externally furnished components
 Shortfalls in externally performed tasks
 Real-time performance shortfalls

 Straining computer-science capabilities

8.2. RISK CONTROL
- Coming up with techniques and strategies to mitigate the highest ordered risks
- Implementing the strategies to resolve the high order risks factors
- Monitoring the effectiveness of the strategies and the changing levels of risk
throughout the project
TOP TEN MITIGATION PLANS IDENTIFIED
1. Risk Identified  Personnel Shortfalls –
 Staffing with top talent;

 key personnel agreements;
 incentives;
 team-building;
 training;
 tailoring process to skill mix;
 peer reviews
2. Risk Identified  Unrealistic schedules and budgets
 Business case analysis;

 design to cost;
 incremental development;
 software reuse;
 requirements descoping;
 adding more budget and schedule
3. Risk Identified  Requirements Mismatch/Gold Plating

 Stakeholder win-win negotiation;

 business case analysis;
 mission analysis;
 ops-concept formulation;
 user surveys;
 prototyping;
 early users’ manual;
 design/develop to cost
4. Risk Identified  Legacy Software
 Design recovery;
 Phase-out options analysis;
 Restructuring
5. Risk Identified  Developing the wrong user interface
 Prototyping;
 scenarios;
 user characterization (functionality, style, workload)
6. Risk Identified  Continuing stream of requirements changes
 High change threshold;

 Incremental development (defer changes to later increments)
7. Risk Identified  Shortfalls in externally furnished components
 Qualification testing;
 benchmarking;
 prototyping;

 reference checking;
 compatibility analysis;
 vendor analysis;
 evolution support analysis
8. Risk Identified  Shortfalls in externally performed tasks
 Reference checking;
 audits;
 award-fee contracts;
 competitive designer prototyping;
 team-building
9. Risk Identified  Real-time performance shortfalls
 Architecture tradeoff analysis and review boards;

 simulation;
 benchmarking;
 modeling;
 prototyping;
 tuning
10. Risk Identified  Straining computer-science capabilities
 Technical analysis;
 cost-benefit analysis;
 prototyping;
 reference checking

9. FEASIBILITY STUDY
9.1 TECHNICAL FEASIBILITY

The necessary resources like hotel receptionist to provide information about the hotel
reservation system, room information’s – types of rooms, process of check-in and
checkout and customer information to develop GUI applications in Visual Basic 6.0 and
MSACCESS environments are available. The required hardware a Pentium machine and
software required i.e. Visual Basic 6.0 and MS-OFFICE is available. Hence there is no
development risk associated with the software.
9.2 OPERATIONAL FEASIBILITY

The “Hotel Management System” will operate in Windows environment on a Pentium
Machine. It will be a reliable package that facilitates management of hotel information of
Hotel. It will provide greater extent of flexibility for user to automate the check-out
billing for the customer. It will calculate the number of days a customer has stayed in the
hotel and charge the customer accordingly. Thus, it will meet all the required
functionality and be operationally feasible.
9.3 ECONOMICAL FEASIBILITY
The “Hotel Management System” project is estimated to be a project to maintain

information for 100 hotel rooms and about 100-150 customers everyday. The system will
be help about 5 receptionists to check the room information and calculate the customer
bills. Considering the hardware requirements, software requirements, manual for users
and training the staff estimated expense on this project is 30,00,000 USD.
9.4 MOTIVATIONAL FEASIBILITY

The “Hotel Management System” software will be used by the receptionists to check-in,
check-out and billing customers, accounts personal and the other employee’s such as the
managers to check the reports. The software fulfills all necessary requirements for such
application. It provides a graphical user interface that makes easier for the staff to use. It
also provides easy to understand menu structure. It’s easy to use nature makes it readily
acceptable to the end users, who need not have much technical knowledge to use it.
9.5 HARDWARE & SOFTWARE FEASIBILITY

Hardware
Server
- Processor:
- Memory:
- Space:
Client
- Processor:
- Memory:
- Space:
Software
Front end: Visual Basic 6.0
Back end: MS_ACCESS
Operating System: Windows
9.6 ASSUMPTIONS & LIMITATIONS
• The data/information entered by the user is assumed to be correct.

• Room information and room rates are assumed to not change.

10. CONCLUSION AND REFERENCES
This project is designed to meet the requirements of Hotel Management System. It has
been developed in visual basic and MS Access keeping in mind the specifications of the
system. The Hotel Management System’s objectives are to provide a system to manage a
hotel that has increased in size to a total of 100 rooms. Without automation the
management of the hotel has become an unwieldy task. The end users’ day-to-day jobs of
managing a hotel will be simplified by a considerable amount through the automated
system. The system will be able to handle many services to take care of all customers in a
quick manner. The system should be user appropriate, easy to use, provide easy recovery
of errors and have an overall end user high subjective satisfaction.
REFERENCES
THE SOFTWARE PROJECT MANAGER’S HANDBOOK - PRINCIPLES THAT

WORK AT WORK – By Dwayne Philips
SOFTWARE PROJECT MANAGEMENT – A PRACTITIONER’S APPROACH – By
E.M.Bennatan
http://www.123eng.com
www.ignoujugaad.com/Project/

Atm Doc

Uploaded by

Copyright:

Available Formats

Atm Doc

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Atm Doc

Uploaded by

Copyright:

Available Formats

UOM IBM MS (Tech) 7th Semester

In this Project we present a a model for the utilization of biometrics

ATM Management system-Biometric ATM , a Proposal -1-

ATM innovation paralleled the growth of the PC and

In the early 90’s, taking advantage of the technological boom in

ATM Management system-Biometric ATM , a Proposal -2-

1.1.1 Purpose, Scope, and Objectives

The purpose of the project is to analyze the requirements of, design,

The objectives of the project are as follows:

• complete the project by the project due date

• complete the project within budget

• fulfill all stated requirements, as in the SRS, of the software product

 central bank customer database modifications

ATM Management system-Biometric ATM , a Proposal -3-

Assumptions and Constraints

The project will be planned with the following assumptions:

• this project is a component of a larger project

• the software products will be Windows NT-based using Windows Open

• the ATM hardware has documentation available suitable for interface

• a documented physical ATM computer network is being created in a

• the ATM hardware is being handled as a separate project and will be

• we will be able to acquire the expertise of two outside consultants from

• this SPMP is submitted as a firm-fixed-price (FFP) bid; the project shall

The project will be planned with the following constraints:

 $3,000,000 (25% of total $12,000,000 budget; software portion only)

ATM Management system-Biometric ATM , a Proposal -5-

• Software program and library binaries

• Installation of software program and library binaries on target

• Software training performed against affected users

 ATM site users (i.e. bank branch staff)

 Software Requirements Specification (SRS)

ATM Management system-Biometric ATM , a Proposal -6-

Evolution of the Plan

The plan is considered to be a dynamic document and will be updated

ATM Management system-Biometric ATM , a Proposal -7-

o When more than one resource is assigned to the activity, their

o Organizational project history data

o Contractor project history data

PROJECT STAFFING PLAN

In terms of domain-specific knowledge as it relates to the

ATM Management system-Biometric ATM , a Proposal -8-

Work activities must be documented. Schedule allocation , Resource

The project shall utilize a combination of Iterative and Waterfall

ATM Management system-Biometric ATM , a Proposal -9-

for applying changes to requirements matrix; is responsible for

RISK MANAGER - The Risk Manager is responsible for identifying the

ATM Management system-Biometric ATM , a Proposal - 10 -

ATM Management system-Biometric ATM , a Proposal - 11 -

Methods, Tools, and Techniques

• The project shall use the waterfall software development

• the product definition is stable

ATM Management system-Biometric ATM , a Proposal - 12 -

ATM Management system-Biometric ATM , a Proposal - 13 -

• Document publishing (applies to all documents published by

Microsoft Internet Information Services 4.0 [web server

ADDITIONAL FEATURES FOR THE ATM PROPOSAL

BIOMETRIC MEASURE FOR ENHANCING ATM SECURITY

It is important to mention that in parallel to the development of the

Cards with Magnetic Bands