1

USE CASE: Introduction

Over 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 added use cases during the last few years.

Definitions
A 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

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 and variants involved in attaining the goal.

Characteristics of USE CASE

Use 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 systems value proposition identifies the significant role. Create use cases for every goal associated with a use case template and maintain the same abstraction 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

Actors
A 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, 4

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 "massmarket 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 the system). 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 modelling

The Benefits of Use Cases are: Use cases have become extremely popular since they have been added to numerous object-oriented development methods as they offer many important advantages, including the following: 5

 Use cases focus on the users of the system, not the system itself, thus the real system needs 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 bring in 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 use case 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 other aspects 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 by capturing the requirements from the user's point of view. Use cases are a powerful technique for the elicitation and documentation of black box functional requirements. Because they are written in natural language, use cases are easy to understand and provide 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 problem into 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 cases help provide the rationale for the messages that glue the objects and classes together. Use cases 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 supporting Booch'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 role playing) and for the validation of the functional requirements (via acceptance testing)

 Use cases provide an objective means of project tracking in which earned value can be defined in terms of use cases implemented, tested, and delivered. Use cases can form the foundation on which to specify end-to-end timing requirements for real-time applications. Use cases provide some very clear benefits to the Analysis Phase. One important benefit of 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 requirements document, 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 site

Use 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 benefits throughout the product development process. Product Discovery: Defining use cases early can help ensure that software development teams 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.

 Testing: Another benefit of use cases is that it helps identify what might go wrong during a user 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 CASES

Because 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 as platform, 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 the writer(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 be difficult for stakeholders to understand. 8

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 Meyer discusses issues such as driving system design 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 not object-oriented. Each use case captures a major functional abstraction that can 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. 9

Application of USE CASE in Banking Systems

Interactive Big Data Management for Banking Industry: Challenges Faced by Banks
Consumer-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 Value

Big 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 CASE

Applying the value of intelligence
Banks 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 10

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.

Check Balances Deposit Funds Customer Withdraw Cash Transfer Fund Maintenance ATM Technician

Repair

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 (skimmer insertion), 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 11

Bank ATM Use Cases

An 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.

System

start

welcome
Insert card Cancel transaction

Incorrect PIN

Check PIN

Eject card

Correct PIN

Cancel transaction Insufficient bills availability

Request > max

Input withdraw amount

Insufficient fund

Disburse bills

Request < max

Sufficient bills in ATM

Verify balance
Sufficient funds

Verify bills availability

Figure 3: The transition diagram of the ATM behaviour

12

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 point by 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.

13

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

14

 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: 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 15

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.

16

 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.

Credit Card Processing System Use Cases

In 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 actor of 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.

17

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 Bank account. 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.

18

<<Subsystem>> Credit Card Payment Gateway AUTHORIZE and CAPTURE

<<include> >

<<include>>

<<Module>>Merch ants Credit card Process system

AUTHORIZE

CAPTURE

Merchants Bank

CREDITE

VOID Customer Credit card Bank

VERIFY

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. 19

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 which the customer is qualified. The system presents a page with the list of credit cards that allows the user to select one of them. 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 the user 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 Banking

An 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 20

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 purposes The 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 Cases

There 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 of big 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.

21

Process of creating an Use-Case model for Online Banking System

Identifying the use cases At 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 actors After 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 diagram Then 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 diagram After 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

22

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 diagram The 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 diagram The 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.

23

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.

24

REFERENCES
eHow 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

25