use case application on banking system

8/22/2019 Use Case Application on Banking System

1/25

1


2/25

2

USE CASE: IntroductionOver the last three years, use cases have become well established as one of the fundamental

techniques of object-oriented analysis. Although initially introduced by Ivar Jacobson to the object

community at the 1987 OOPSLA conference, it was the publication of his book Object-Oriented

Software Engineering: A Use Case Driven Approach in 1992 that marked the true beginning of use

cases meteoric rise in popularity. Possibly in reaction to the previous structured methods, early

object-oriented development methods overemphasized static architecture and partially ignored

dynamic behaviour issues during requirements analysis, especially above the individual class level

where state modelling provides an important technique for dynamic behaviour specification. Use

cases provide a great many benefits in addition to correcting this overemphasis, and most major

object-oriented development methods (including my own) have jumped on the band wagon and addeduse cases during the last few years.

DefinitionsA use case is a methodology used in system analysis to identify, clarify, and organize system

requirements. The use case is made up of a set of possible sequences of interactions between systems

and users in a particular environment and related to a particular goal. It consists of a group of

elements (for example, classes and interfaces) that can be used together in a way that will have an

effect larger than the sum of the separate elements combined. The use case should contain all system

activities that have significance to the users. A use case can be thought of as a collection of possible

scenarios related to a particular goal, indeed, the use case and goal are sometimes considered to be

synonymous.

In software and systems engineering, a use case is a list of steps, typically defining interactions

between a role (known in UML as an "actor") and a system, to achieve a goal. The actor can be a

human or an external system. In systems engineering, use cases are used at a higher level than within

software engineering, often representing missions or stakeholder goals. The detailed requirements

may then be captured in SysML or as contractual statements.

The term use case was introduced by Ivar Jacobson et al. and has been defined in several publications.

A use case is a description of a cohesive set of possible dialogs (i.e., series of interactions) that an

individual actor initiates with a system. An actor is a role played by a user (i.e., an external entity that
http://en.wikipedia.org/wiki/Software_engineeringhttp://en.wikipedia.org/wiki/Systems_engineeringhttp://en.wikipedia.org/wiki/Unified_Modeling_Languagehttp://en.wikipedia.org/wiki/Actor_%28UML%29http://en.wikipedia.org/wiki/Project_stakeholderhttp://en.wikipedia.org/wiki/SysMLhttp://en.wikipedia.org/wiki/SysMLhttp://en.wikipedia.org/wiki/Project_stakeholderhttp://en.wikipedia.org/wiki/Actor_%28UML%29http://en.wikipedia.org/wiki/Unified_Modeling_Languagehttp://en.wikipedia.org/wiki/Systems_engineeringhttp://en.wikipedia.org/wiki/Software_engineering


3/25

3

interacts directly with the system). See Figure 1. A use case is thus a general way of using some part

of the functionality of a system.

Figure 1: The Primary Use Case Notations

A use case is not a single scenario but rather a 'class' that specifies a set of related usage scenarios,

each of which captures a specific course of interactions that take place between one or more actors

and the system. Therefore, the description of an individual use case typically can be divided into a

basic course and zero or more alternative courses. The basic course of a use case is the most common

or important sequence of transactions that satisfy the use case. The basic course is therefore always

developed first. The alternative courses are variants of the basic course and are often used to identify

error handling. Within reason, the more alternative courses identified and described, the more

complete the description of the use case and the more robust the resulting system.

Use cases can be employed during several stages of software development, such as planning system

requirements, validating design, testing software, and creating an outline for online help and user

manuals. A use case is a software and system engineering term that describes how a user uses a

system to accomplish a particular goal. A use case acts as a software modelling technique that defines

the features to be implemented and the resolution of any errors that may be encountered.

Use cases define interactions between external actors and the system to attain particular goals. There

are three basic elements that make up a use case:

Actors: Actors are the type of users that interact with the system. System: Use cases capture functional requirements that specify the intended behaviour of the

system.

Goals: Use cases are typically initiated by a user to fulfil goals describing the activities andvariants involved in attaining the goal.


4/25

4

Characteristics of USE CASEUse cases are modelled using unified modelling language and are represented by ovals containing the

names of the use case. Actors are represented using lines with the name of the actor written below the

line. To represent an actor's participation in a system, a line is drawn between the actor and the use

case. Boxes around the use case represent the system boundary.

Characteristics associated with USE CASEs are:

Organizing functional requirements Modelling the goals of system user interactions Recording scenarios from trigger events to ultimate goals Describing the basic course of actions and exceptional flow of events Permitting a user to access the functionality of another event

The steps in designing use cases Identify the users of the system For each category of users, create a user profile. This includes all roles played by the

users relevant to the system.

Identify significant goals associated with each role to support the system. The systemsvalue proposition identifies the significant role.

Create use cases for every goal associated with a use case template and maintain the sameabstraction level throughout the use case. Higher level use case steps are treated as goals

for the lower level.

Structure the use cases

Review and validate the users

ActorsA use case defines the interactions between external actors and the system under consideration to

accomplish a goal. Actors must be able to make decisions, but need not be human: "An actor might be

a person, a company or organization, a computer program, or a computer system hardware,


5/25

5

software, or both."Actors are always stakeholders, but many stakeholders are not actors, since they

"never interact directly with the system, even though they have the right to care how the system

behaves."For example, "the owners of the system, the company's board of directors, and regulatory

bodies such as the Internal Revenue Service and the Department of Insurance" could all be

stakeholders but are unlikely to be actors.

Similarly, a person using a system may be represented as different actors because he is playing

different roles. For example, user "Joe" could be playing the role of a Customer when using an

Automated Teller Machine to withdraw cash from his own account, or playing the role of a Bank

Teller when using the system to restock the cash drawer on behalf of the bank.

Actors are often working on behalf of someone else. Cockburn writes that "These days I write 'sales

rep for the customer' or 'clerk for the marketing department' to capture that the user of the system is

acting for someone else." This tells the project that the "user interface and security clearances" should

be designed for the sales rep and clerk, but that the customer and marketing department are the roles

concerned about the results.

A stakeholder may play both an active and an inactive role: for example, a Consumer is both a "mass-

market purchaser" (not interacting with the system) and a User (an actor, actively interacting with the

purchased product). In turn, a User is both a "normal operator" (an actor using the system for its

intended purpose) and a "functional beneficiary" (a stakeholder who benefits from the use of thesystem). For example, when user "Joe" withdraws cash from his account, he is operating the

Automated Teller Machine and obtaining a result on his own behalf.

Cockburn advises to look for actors among the stakeholders of a system, the primary and supporting

(secondary) actors of a use case, the system under design itself, and finally among the "internal

actors", namely the components of the system under design.

Benefits of USE CASE modellingThe Benefits of Use Cases are:

Use cases have become extremely popular since they have been added to numerousobject-oriented development methods as they offer many important advantages, including

the following:
http://en.wikipedia.org/wiki/Project_stakeholderhttp://en.wikipedia.org/wiki/Project_stakeholder


6/25

6

Use cases focus on the users of the system, not the system itself, thus the real systemneeds are brought to light early on. Since a use case consists mainly of narrative text, it is

easily understandable by all stakeholders, including customers, users and executives, not

just developers and testers.

By including all the stakeholders during the early planning stages of a project, you bringin people who best understand the problems at hand, promote a sense of buy-in from end

users, and eliminate surprises when the system is deployed.

Each use case describes one way the system is used, but one of the big benefits of usecase modelling is that it also describes all of the things that might go wrong. Identifying

exceptions to a successful scenario early in the project saves a lot of time by finding

subtle requirements.

Finally, once a use case model has been developed, it can be used to drive many otheraspects of software development, including project planning (cost, complexity and timing

estimates), object models, test case definitions, and user documentation.

As a user-centred technique, use cases help ensure that the correct system is developed bycapturing the requirements from the user's point of view.

Use cases are a powerful technique for the elicitation and documentation of black boxfunctionalrequirements.

Because they are written in natural language, use cases are easy to understand andprovide an excellent way for communicating with customers and users. Although

computer-aided software engineering (CASE) tools are useful for drawing the

corresponding interaction diagrams, use cases themselves require remarkably little tool

support.

Use cases can help manage the complexity of large projects by decomposing the probleminto major functions (i.e., use cases) and by specifying applications from the users'

perspective.

Because they typically involve the collaboration of multiple objects and classes, use caseshelp provide the rationale for the messages that glue the objects and classes together. Usecases also provide an alternative to the overemphasis of traditional object-oriented

development methods on such static architecture issues as inheritance and the

identification of objects and classes.

Use cases have emphasized the use of lower-level scenarios, thereby indirectly supportingBooch's important concept of mechanisms, a kind of pattern that captures how "objects

collaborate to provide some behaviour that satisfies a requirement of the problem."

Use cases provide a good basis for the verification of the higher-level models (via roleplaying) and for the validation of the functional requirements (via acceptance testing)


7/25

7

Use cases provide an objective means of project tracking in which earned value can bedefined in terms of use cases implemented, tested, and delivered.

Use cases can form the foundation on which to specify end-to-end timing requirementsfor real-time applications.

Use cases provide some very clear benefits to the Analysis Phase. One important benefitof use case driven analysis is that it helps manage complexity, since it focuses on one

specific usage aspect at a time. Use cases start from the very simple viewpoint that a

system is built first and foremost for its users.

Another benefit of use cases is that they provide basic groundwork for the requirementsdocument, user manual and test cases. Use cases also encourage designers to envision

outcomes before attempting to specify outcomes, and thereby they help to make

requirements more proactive in system development.

USE CASES improve the user friendliness of web siteUse cases are utilized in software and web development to describe the different interactions that can

take place between a user and a system or application. Because use cases focus on people and not the

system itself, the system needs are brought to light early on, which opens up a number of benefitsthroughout the product development process.

Product Discovery: Defining use cases early can help ensure that software developmentteams will build the right product. Even before requirements are defined, the process of

developing use cases can uncover problem areas or behaviours that can be addressed with

new software products or enhancements to existing products. Requirements Definition:Use cases are a natural steppingstone to defining functional

requirements. By establishing a common understanding about how a user will interact with

the new product, it becomes much easier to describe how that product must work. For

example, if you were building a new ATM interface, a use case might describe a scenario in

which a Spanish-speaking person will use the ATM to withdraw cash. A requirement to

support that use case would be that the system must display instructions in Spanish. Development: Use cases can help simplify the software development process. When

requirements are aligned with use cases, it becomes easier to organize engineering resources

and minimize complexity, allowing developers to focus on one specific usage at a time.


8/25

8

Testing: Another benefit of use cases is that it helps identify what might go wrong during auser interaction. Because desired outcomes are clearly described in the use cases, it is easier

to establish test criteria. Test cases can be built to match each individual use case, making

them easy to validate. Communications: Whether a use case has been documented using narrative text or a

diagram, it should be easily understood by stakeholders at all levels, including executives,

marketers and the users themselves, not just software engineers. This allows product owners

and project managers to communicate more effectively, include stakeholders early in the

process and get buy-in from key decision-makers. It creates a shared vision of the problem to

be addressed and bridges the gap between those who understand the problem and those who

know how to build the solution.

The Dangers of Misusing USE CASESBecause of their many important advantages and extreme popularity, use cases have become a

fundamental part of object technology and have been incorporated in one form or another into most

major object-oriented development methods. In the rush to jump onto the use case bandwagon, use

cases have been perceived by some as either a panacea or as an end in-and-of themselves.

Unfortunately, this has often led to the uncritical acceptance of use cases without any examination of

their numerous limitations and ample opportunities they offer for misuse. The following provides an

overview of the major risks associated with use cases:

Limitations of Use cases include:

Use cases are not well suited to capturing non-interaction based requirements of a system(such as algorithm or mathematical requirements) or non-functional requirements (such asplatform, performance, timing, or safety-critical aspects). These are better specified

declaratively elsewhere.

Use case templates do not automatically ensure clarity. Clarity depends on the skill of thewriter(s).

Use cases are complex to write and to understand, for both end users and developers. As there are no fully standard definitions of use cases, each project must form its own

interpretation.

Some use case relationships, such as extends, are ambiguous in interpretation and can bedifficult for stakeholders to understand.
http://en.wikipedia.org/wiki/Non-functional_requirementshttp://en.wikipedia.org/wiki/Non-functional_requirements


9/25

9

Use case developers often find it difficult to determine the level of user interface (UI)dependency to incorporate in a use case. While use case theory suggests that UI not be

reflected in use cases, it can be awkward to abstract out this aspect of design, as it makes the

use cases difficult to visualize. In software engineering, this difficulty is resolved by applying

requirements traceability, for example with a traceability matrix.

Use cases can be over-emphasized. Bertrand Meyerdiscusses issues such as driving systemdesign too literally from use cases, and using use cases to the exclusion of other potentially

valuable requirements analysis techniques.

Use cases are a starting point for test design, but since each test needs its own success criteria,use cases may need to be modified to provide separate post conditions for each path.

Use cases are notobject-oriented. Each use case captures a major functional abstraction thatcan cause the numerous problems with functional decomposition that object technology was

to avoid.

The Banking System

Banking systems have been with us for as long as people have been using money. Banks and other

financial institutions provide security for individuals, businesses and governments, alike.

In general, what banks do is pretty easy to figure out. For the average person banks accept deposits,

make loans, provide a safe place for money and valuables, and act as payment agents between

merchant and banks. Banks are quite important to the economy and are involved in such economic

activities as issuing money, settling payments, credit intermediation, maturity transformation and

money creation in the form of fractional reserve banking. To make money, banks use deposits and

whole sale deposits, share equity and fees and interest from debt, loans and consumer lending, such as

credit cards and bank fees. In addition to fees and loans, banks are also involved in various other types

of lending and operations including, buy/hold securities, non-interest income, insurance and leasing

and payment treasury services.

Banks have high expectations of the new applications that are tailor-made for the sector. The use of

appropriate software systems constitutes an important pillar of banking operations. Besides the use of

suitable software, what is critical for banks commercial success is that different applications and

processes should be well integrated, and that users should actually accept and deploy them in practice.

If a bank takes the decision to use a new core banking solution, the question arises as to which

software should be chosen. There is no single answer, since needs and requirements vary from bank to

bank. Therefore, a precise analysis of the banks specific requirements is crucial if the right software

is to be chosen.
http://en.wikipedia.org/wiki/User_interfacehttp://en.wikipedia.org/wiki/Requirements_traceabilityhttp://en.wikipedia.org/wiki/Traceability_matrixhttp://en.wikipedia.org/wiki/Bertrand_Meyerhttp://en.wikipedia.org/wiki/Bertrand_Meyerhttp://en.wikipedia.org/wiki/Traceability_matrixhttp://en.wikipedia.org/wiki/Requirements_traceabilityhttp://en.wikipedia.org/wiki/User_interface


10/25

10

Application of USE CASE in Banking SystemsInteractive Big Data Management for Banking Industry: ChallengesFaced by BanksConsumer-centric companies such as banks have more data about their consumers but relatively very

little intelligence about them. The world is increasingly interconnected, instrumented and intelligent

and in this new world the velocity, volume, and variety of data being created is unprecedented. As the

amount of data created about a consumer is growing the percentage of data that banks can process is

going down fast. Based on their engagement with Amazon or Yelp, consumers have expectations

about similar experiences from the banking applications. Without deep knowhow about their

consumers, banks may not be able to meet these consumer expectations. The result is lost of revenue

opportunities, low coupon redemption rates, lower share of customers wallet and lost competitive

agility. In a nutshell, not being able to gain insights from the goldmine of data means banks allowing

their competition to identify critical business trends and act on those before they can, and losing

business.

Key Banking Use Cases that Drive Business ValueBig Data market is in infancy but is growing exponentially. While banking executives agree that Big

Data has potential to transform their businesses, they are often unsure which use cases they should

consider when implementing a Big Data solution. Here are some key use cases that are leading the

wave and delivering significant business value for banking industry:

Mobile wallet for one-to-one marketing Fraud detection and prevention of false positives Risk management based on unique risk profiles Segmentation, targeting and risk based pricing

Banking & Financial USE CASEApplying the value of intelligenceBanks and financial institutions use Object Video to detect events for ATM loitering, people

counting, data centre security and more. Intelligent video analytics, however, is just one layer


11/25

11

within an overall banking video surveillance system. Integrate that video analytic output with bank

systems and data streams and you create the next generation of intelligent enterprise solutions for

branch safety and financial risk mitigation.

CheckBalances

DepositFunds

WithdrawCash

TransferFund

Maintenance

RepairATM

Technician

Customer

Figure 2: Use Case diagram for Bank ATM subsystem - top level use cases.

Sample OV experience for banks and financial institutions that leverage analytic integration for

maximum value includes:

ATM transaction applications to detect human presence with no transaction started (skimmerinsertion), or suspicious human behaviour after a transaction has started

Bank teller systems to visually verify customer presence for certain withdrawal transactions Access control systems to detect "tailgating" or other unauthorized entry into secure areas

within a bank, data centre, or corporate office

Alarm system to alert employees of vehicles in drive-through lanes Video management and storage systems to enable alert-driven video delivery, storage and

central monitoring


12/25

12

Bank ATM Use CasesAn automated teller machine (ATM) or the automatic banking machine (ABM) is banking subsystem

(subject) that provides bank customers with access to financial transactions in a public space without

the need for a cashier, clerk or bank teller.

Customer(actor) uses bank ATM to check balances of his/her bank accounts, deposit funds, withdraw

cash and/or transfer funds (use cases). ATM Technician provides maintenance and repairs. All these

use cases also involve Bank actor whether it is related to customer transactions or to the ATM

servicing.

welcome

System

Eject card

Inputwithdrawamount

Verify balance

Disburse bills

Verify billsavailability

start

Insert card

Cancel transaction

Correct PIN

Request max

Incorrect PIN

Figure 3: The transition diagram of the ATM behaviour
http://www.uml-diagrams.org/use-case-subject.htmlhttp://www.uml-diagrams.org/use-case-actor.htmlhttp://www.uml-diagrams.org/use-case.htmlhttp://www.uml-diagrams.org/use-case.htmlhttp://www.uml-diagrams.org/use-case-actor.htmlhttp://www.uml-diagrams.org/use-case-subject.html


13/25

13

On most bank ATMs, the customer is authenticated by inserting a plastic ATM card and entering a

personal identification number (PIN). Customer Authentication use case is required for every ATM

transaction so we show it as include relationship. Including this use case as well as transaction

generalizations make the ATM Transaction an abstract use case.

Figure 4: Bank ATM Transactions and Customer Authentication Use Cases Example.

If needed, customer may ask ATM for help. ATM Transaction use case is extended via Menu

extension pointby the ATM Help use case whenever ATM Transaction is at the location specified by

the Menu and the bank customer requests help, e.g. by selecting Help menu item.

Figure 5: Bank ATM Maintenance, Repair, Diagnostics Use Cases Example.
http://www.uml-diagrams.org/use-case-include.htmlhttp://www.uml-diagrams.org/use-case.html#generalizationhttp://www.uml-diagrams.org/use-case.html#abstract-use-casehttp://www.uml-diagrams.org/use-case-extend.htmlhttp://www.uml-diagrams.org/use-case-extend.html#extension-pointhttp://www.uml-diagrams.org/use-case-extend.html#extension-pointhttp://www.uml-diagrams.org/use-case-extend.htmlhttp://www.uml-diagrams.org/use-case.html#abstract-use-casehttp://www.uml-diagrams.org/use-case.html#generalizationhttp://www.uml-diagrams.org/use-case-include.html


14/25

14

THE TH

ATM Technician maintains or repairs Bank ATM. Maintenance use case includes Replenishing ATM

with cash, ink or printer paper, Upgrades of hardware, firmware or software, and remote or on-site

Diagnostics. Diagnostics is also included in (shared with) Repair use case.

An Use Case Example for ATM System

Figure 6: ATM Systems

Here are the flows of Events for Individual Use Cases
http://www.uml-diagrams.org/use-case-include.htmlhttp://www.uml-diagrams.org/use-case-include.html


15/25

15

System Startup Use Case: The system is started up when the operator turns theoperator 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 surethat 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 cardreader 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: A transaction use case is started within a session when thecustomer 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


16/25

16

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 tochoose 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 tochoosing the dollar amount.

Deposit Transaction Use Case: A deposit transaction asks the customer to choose atype 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 atype 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.


17/25

17

Inquiry Transaction Use Case: An inquiry transaction asks the customer to choose atype 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 transactionwhen 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.

Credit Card Processing System Use CasesIn the case of credit card processing system, Credit Card Processing System (Credit Card Payment

Gateway) is a subject, i.e. system under design or consideration. Primary actorof the system is the

Merchants Credit Card Processing System. The merchant submits a credit card transaction request

to the credit card payment gateway on behalf of a customer. Bank which issued customer's credit card

is actor which could approve or reject the transaction. If transaction is approved, funds will be

transferred to merchant's bank account.
http://www.uml-diagrams.org/use-case-subject.htmlhttp://www.uml-diagrams.org/use-case-actor.htmlhttp://www.uml-diagrams.org/use-case-actor.htmlhttp://www.uml-diagrams.org/use-case-subject.html


18/25

18

Figure: 7

Authorize and Capture use case is the most common type of credit card transaction. The requested

amount of money should be first authorized by Customer's Credit Card Bank, and if approved, is

further submitted for settlement. During the settlement funds approved for the credit card transaction

are deposited into the Merchant's Bankaccount.

In some cases, only authorization is requested and the transaction will not be sent for settlement. In

this case, usually if no further action is taken within some number of days, the authorization expires.

Merchants can submit this request if they want to verify the availability of funds on the customers

credit card, if item is not currently in stock, or if merchant wants to review orders before shipping.

Capture (request to capture funds that were previously authorized) use case describes several

scenarios when merchant needs to complete some previously authorized transaction - either submitted

through the payment gateway or requested without using the system, e.g. using voice authorization.


19/25

19

AUTHORIZE andCAPTURE

AUTHORIZE

CAPTURE

CREDITE

VERIFY

VOID

Merchants Credit cardProcess system

Credit Card

Payment Gateway

Merchants

Bank

CustomerCredit card

Bank

Figure 8: Credit Card Processing System Use Case Modelling

Credit use case describes situations when customer should receive a refund for a transaction that was

either successfully processed or settled through the system or for some transaction that was not

originally submitted through the payment gateway.

Void use case describes cases when it is needed to cancel one or several related transactions that were

not yet settled. If possible, the transactions will not be sent for settlement. If the Void transaction fails,

the original transaction is likely already settled.


20/25

20

Verify use case describes zero or small amount verification transactions which could also include

verification of some client's data such as address.

Credit Card Application Use Case The user selects an option from the main menu to obtain a credit card. The system attempts to obtain the financial parametric data from the customer credit history. If the system cannot find enough information, the "Request Financial Information" dialog is

executed.

When the financial information is obtained, the system selects all the credit cards for whichthe customer is qualified.

The system presents a page with the list of credit cards that allows the user to select one ofthem. A "cancel" action is available to end the operation. The user selects a credit card.

The system presents a confirmation page, which includes a summary of the operation that theuser wants to perform and information about the credit card selected by the customer. A

"cancel" action is available to cancel the operation, and a "back" action is available to return

to the page that presents the list of credit cards. An "OK" action is available to accept the

terms and conditions. The user presses the "OK" action. The system presents a page informing the user that the operation has been executed

successfully. The user presses the "OK" action.

The system presents the home page, which presents the main operations menu.

Use Case Application on E-Signatures in BankingAn important and necessary part of any technology evaluation is seeing the solution in action, in a

context that closely matches your requirements. This not only provides you with the reassurance that a

solution can deliver the functionality listed on a datasheet, it often helps prompt additional questions

and a better sense of whether a solution is the right fit for ones needs. The demonstrations are based

on the most common e-signature use case scenarios that arise in banking processes such as:

Online, self-service Email invitation


21/25

21

ID & Password authentication Online document review Click to sign Secure download of e-Records

In-branch Integrated portal link Paper document review Tablet signing

Review of electronic evidence for audit or legal purposesThe flexibility of e-Sign Enterprise to address such a variety of use cases will give financial

institutions confidence that true enterprise e-signature options are available that address the unique

requirements of all distribution channels.

Banking industrys BI Use CasesThere are many industries able to extract considerable value from business intelligence, each in a

unique way. The recent FiNtech Lab Demo Day provided a chance to consider the place of BI and big

data analytics in finance and banking, where the high speed of operations and focus on numerical data

has made analytics a popular area.

Information is the lifeblood of financial services" said software executive Bob Gach. "As we enter a

new age ofbig data and the proliferation of social and mobile networks, banks will need to leverage

emerging analytical technologies and learn from the critical lessons of other industries, such as

intelligence and defence."

The ideas presented by the event's experts described several possible future directions that data

analytics could take in finance. Information insights could address risk management and fraud

prevention, as well as advanced ways for banks to organize their own data. Bank-specific mobile BI

also received attention. Compliance Week recently reported that the complex process of making sure

financial institutions meet industry regulations has become a hotbed of big data analytics interest. The

source stated that banks are currently party to a wide variety of new risks that can be managed

through data use.
http://www.jaspersoft.com/bigdatahttp://www.jaspersoft.com/bigdatahttp://www.jaspersoft.com/bigdatahttp://www.jaspersoft.com/mobile-bihttp://www.jaspersoft.com/mobile-bihttp://www.jaspersoft.com/bigdatahttp://www.jaspersoft.com/bigdatahttp://www.jaspersoft.com/bigdata


22/25

22

Process of creating an Use-Case model for Online BankingSystem

Identifying the use casesAt first bank need to identify the significant use cases in online banking system. The use cases

describe the functional tasks that the Bank application performs. The use cases define the most basic

functional tasks that the users of the application perform. In the online banking system, customers can

display the balance of their accounts and transfer money from one account to another. Only a teller

can cash a check; and the system must first verify that the transaction is valid. Use cases are related to

banking activities in the functional area called Account Operations.

Identifying actorsAfter identifying the use cases, bank need to identify the actors of the system. The Account

Operations use-case diagram identifies the key actors and the roles that they perform in the system.

Bank must identify all the actors before creating the diagram. One should understand who the users of

the system are before you begin to model it. In a use-case diagram, users of the system are depicted as

actors. Each actor performs a specific role in the system, which is called a use-case. More than one

actor can perform a single use-case. An actor can be a person, such as a customer, or a computer, such

as a database system or server. The Account Operations use-case diagram contains detailed

information about the Banks online banking system, the system's users, relationships between the

system and the users, and the required behaviour of the system.

Creating the Account Operations use-case diagramThen one needs to create the Account Operations use-case diagram by modelling the relationships

between the actors of the system and the use cases. Now Bank can model the interactions between the

users and the system by creating the relationships between the actors and the use cases.

Creating the Display Balance activity diagramAfter Creating the Account Operations use-case diagram the Display Balance activity diagram need to

be created, this shows the events that occur when a customer or teller requests to display the balance

of a bank account. Use-case diagrams show behaviours, and identify the actors and functions of a

system, but they do not show temporal information. However, activity diagrams, similar to

flowcharts, show the temporal flow of events that occur in a use case. The Display Balance activity


23/25

23

diagram shows the workflow when either a customer or teller requests the balance for a given bank

account. The Banks actor, which is a system, validates the transaction.

Creating the Transfer Money activity diagramThe Transfer Money activity diagram shows the workflow that occurs when either a customer or teller

clicks Transfer Money on the main menu of the online user interface. The Banks system processes

the transaction to determine whether or not the accounts exist and whether or not the amount of

money is less than 100 dollars, because a limit exists for how much money can be transferred in a

single transaction. The Banks system either completes the transaction or displays a message to state

that the transaction is invalid.

Creating the Cash Check activity diagramThe Cash Check activity diagram shows the flow of events that occurs when the Banks teller cashes a

customer's check. When the teller accepts a check from the customer, the teller inputs the transaction

information into the Banks banking application. The Banks system then processes the transaction to

ensure that the account exists and that sufficient money exists in the account to perform the

transaction.


24/25

24

CONCLUSION

Use cases clearly offer many important benefits and are powerful weapons that probably should be in

the arsenal of all software analysts, designers, and testers. Banks have high expectations of the new

applications that are tailor-made for the sector. The use of appropriate software systems constitutes an

important pillar of banking operations. While banking executives agree that Big Data has potential to

transform their businesses, they are often unsure which use cases they should consider when

implementing a Big Data solution.

Unfortunately however, they are functional rather than object-oriented and can significantly

compromise the benefits of object technology if blindly added at to the object-oriented development

process. Fortunately, the risks associated with use case modelling can be mitigated through

knowledge, training, and avoiding an over enthusiastic acceptance.

Use cases should be only one of several ways of capturing user requirements. The model of objects,

classes, and their semantic relationships should be consistent with, but not totally driven by, the use

cases. Designers should beware of and minimize scattering the features of a use case's objects and

classes, and they should exercise great care to avoid the creation of partial, redundant variants of

classes, especially on large projects involving multiple builds and releases.

The architectural guidelines should be followed to avoid creating excessive functional controller

objects that dictate the behaviour of dumb entity objects. Most importantly, use cases should not be

used as an excuse to revert back to the bad old days of functional decomposition and functionally

decomposed requirements specifications.


25/25

REFERENCESeHow tech. (n.d.). Retrieved March 25, 2013, from www.ehow.com:

http://www.ehow.com/list_7305046_benefits-use-case_.html

IBM. (n.d.). Retrieved March 25, 2013, from pic.dhe.ibm.com:

http://pic.dhe.ibm.com/infocenter/rsahelp/v8/index.jsp?topic=%2Fcom.ibm.xtools.tutorial.piggyban

k%2Ftopics%2Fmodule1%2Fmodule1_creating_usecase_model.html

Knowledge Systems Corporation. (n.d.). Retrieved March 25, 2013, from www.ksc.com:

http://www.ksc.com/articles/usecases.htm

math-cs.gordon. (n.d.). Retrieved March 25, 2013, from www.math-cs.gordon.edu:http://www.math-cs.gordon.edu/courses/cps211/ATMExample/UseCases.html

search software quality. (2013, March 25). Retrieved from searchsoftwarequality.techtarget.com:

http://searchsoftwarequality.techtarget.com/definition/use-case

techopedia. (n.d.). Retrieved March 25, 2013, from www.techopedia.com:

http://www.techopedia.com/definition/25813/use-case

UML Modelling & Design. (n.d.). Retrieved March 25, 2013, from www.uml-diagrams.org:

http://www.uml-diagrams.org/use-case-diagrams-examples.html

wikipedia. (n.d.). Retrieved March 25, 2013, from http://en.wikipedia.org/wiki/Use_case:

http://en.wikipedia.org/wiki/Use_case

use case application on banking system

Documents