Uml Diagram For Banking System 576t1m

Requirements Document for the Banking System Software Engineering UBIT

1

Requirements Document • The requirements document is a formal document used to communicate the requirements to customers, engineers and managers • It is also known as software requirements specifications or SRS 2

Requirements Document • The services and functions which the system should provide • The constraints under which the system must operate • Overall properties of the system i.e., constraints on the system’s emergent properties

3

Today’s Topics • In this lecture, we’ll discuss the requirements document of the Banking system that we have been talking about in this course • Let’s develop a template based on the IEEE standard 4

SRS for the Banking System • • • • •

Preface Introduction Glossary Specific requirements Appendices – Use-case model – Object model – Data-flow model 5

SRS for the Banking System • Preface – This should define the expected readership of the document and describe its version history including a rationale for creation of a new version and a summary of the changes made in each version

• Introduction – This should define the product in which the software is embedded, its expected usage and present an overview of the functionality of the control software

6

SRS for the Banking System • Glossary – This should define all technical and abbreviations used in the document

• Specific requirements – This should define specific requirements for the system using natural language with the help of diagrams, where appropriate

• Appendices – Use-case model – Object model – Data-flow model 7

Software Requirements Specifications for the Banking System

8

1. Preface • This document, Software Requirements Specification (SRS), is created to document the software requirements for the Banking System, as described in section 2, Introduction, of this document 9

1. Preface • This document was created on the request of the ‘XYZ Bank Inc.’ – the ‘Client’. The creator of this document is ‘A Software House Inc.’ – ‘Vendor’. The ‘Client’ has asked the ‘Vendor’ to develop an SRS for the Banking System. The ‘Vendor’ will also be responsible for the development of the software based on this SRS 10

1. Preface – This is the first version of the SRS.

11

2. Introduction • This section documents an overview of the functionality expected from the software for the Banking System • We’ll review the functionality of the software to be developed

12

2. Introduction • A bank has several automated teller machines (ATMs), which are geographically distributed and connected via a wide area network to a central server. Each ATM machine has a card reader, a cash dispenser, a keyboard/display, and a receipt printer. By using the ATM machine, a customer can withdraw cash from either checking or savings , query the balance of an , or transfer funds from one to another. A transaction is initiated when a customer inserts an ATM card into the card reader. Encoded on the magnetic strip on the back of the ATM card are the card number, the start date, and the expiration date. Assuming the card is recognized, the system validates the ATM card to determine that the expiration date has not ed, that the -entered PIN (personal identification number) matches the PIN maintained by the system, and that the card is not lost or stolen. The customer is allowed three attempts to enter the correct PIN; the card is confiscated if the third attempt fails. Cards that have been reported lost or stolen are also confiscated. 13

2. Introduction • If the PIN is validated satisfactorily, the customer is prompted for a withdrawal, query, or transfer transaction. Before withdrawal transaction can be approved, the system determines that sufficient funds exist in the requested , that the maximum daily limit will not be exceeded, and that there are sufficient funds available at the local cash dispenser. If the transaction is approved, the requested amount of cash is dispensed, a receipt is printed containing information about the transaction, and the card is ejected. Before a transfer transaction can be approved, the system determines that the customer has at least two s and that there are sufficient funds in the to be debited. For approved query and transfer requests, a receipt is printed and card ejected. A customer may cancel a transaction at any time; the transaction is terminated and the card is ejected. Customer records, records, and debit card records are all maintained at the server.

14

2. Introduction • An ATM operator may start up and close down the ATM to replenish the ATM cash dispenser and for routine maintenance. It is assumed that functionality to open and close s and to create, update, and delete customer and debit card records is provided by an existing system and is not part of this problem. 15

3. Glossary • ATM: Automated Teller Machine • PIN: Personal Identification Number

16

4. Specific Requirements 1.

The XYZ Bank Inc. can have many automated teller machines (ATMs), and the new software system shall provide functionality on all ATMs.

2.

The system shall enable the customers of XYZ Bank Inc., who have valid ATM cards, to perform three types of transactions; 1) withdrawal of funds, 2) Query of balance, and 3) transfer of funds from one bank to another in the same bank. 17

4. Specific Requirements 3.

An ATM card usage shall be considered valid if it meets the following conditions: a) b) c) d) e)

The card was issued by an authorized bank. The card is used after the start date, i.e., the date when the card was issued. The card is used before the expiration date, i.e., the date when the card expires. The card has not been reported lost or stolen by the customer, who had been issued that card. The customer provides correct personal identification number (PIN), which matches the PIN maintained by the system. 18

4. Specific Requirements 4. The system shall confiscate the ATM card if it detects that a lost or stolen card has been inserted by a customer. The system shall also display an apology to the customer. 5. The system shall allow the customer to enter the correct PIN in no more three attempts. The failure to provide correct PIN in three attempts shall result in the confiscation of the ATM card. 19

4. Specific Requirements 6. The system shall ask for the transaction type after satisfactory validation of the customer PIN. The customer shall be given three options: withdrawal transaction, or query transaction, or transfer transaction. 7. If a customer selects withdrawal transaction, the system shall prompt the customer to enter number and amount to be dispensed. 20

4. Specific Requirements 8. For a withdrawal transaction, the system shall determine that sufficient funds exist in the requested , that the maximum daily limit has not be exceeded, and that there are sufficient funds available at the local cash dispenser. 21

4. Specific Requirements 9. If a withdrawal transaction is approved, the requested amount of cash shall be dispensed, a receipt shall be printed containing information about the transaction, and the card shall be ejected. The information printed on the receipt includes transaction number, transaction type, amount withdrawn, and balance. 22

4. Specific Requirements 10. If a customer selects query transaction, the system shall prompt the customer to enter number. 11. If a query transaction is approved, the system shall print a receipt and eject the card. The information contained on the receipt includes transaction number, transaction type, and balance. 23

4. Specific Requirements 12. If a customer selects transfer transaction, the system shall prompt the customer to enter from number, to number, and amount to be transferred. 13. The system shall check if there are enough funds available in the from , which are being requested for transfer to the to . 24

4. Specific Requirements 14. If the transfer transaction is approved, a receipt shall be printed and card shall be ejected. The information printed on the receipt includes transaction number, transaction type, amount transferred, and balance. 15. The system shall cancel any transaction if it has not been completed if the customer presses the Cancel button 25

4. Specific Requirements 16. The customer records, records, and debit card records will all be maintained at the server and shall not be the responsibility of the system. 17. The system shall enable an ATM operator to shutdown or start up an ATM for routine maintenance. 26

4. Specific Requirements 18. The system shall enable an ATM operator to add cash to the cash dispenser. 19. The system shall not be responsible for opening or closing of s, and to create, update, and delete customer and debit card records. These tasks are performed elsewhere by a bank. 27

4. Specific Requirements 20. The system shall be linked with the bank server through communication systems, which are beyond the scope of the current system. It is assumed that this facility is always available. 21. The system shall not be responsible for the maintenance of the hardware devices of the ATM or network facilities. 28

5. Appendices • 5.1 Use-case model • 5.2 Object model • 5.3 Functional model – 5.3.1 Data-flow model – 5.3.2 SADT model

• 5.4 Dynamic model – 5.4.1 Statecharts – 5.4.2 Interaction diagrams 29

Use Case Model

30

Uses Case Diagram for ATM Customer Withdraw funds ATM Customer

Query

«include»

«include»

Validate PIN

«include» Transfer funds 31

Use Case Diagram for ATM Operator Add cash

Startup Operator Shutdown

32

Use Case Diagram for ATM Withdraw funds ATM Customer

Query

«include»

«include»

Validate PIN

«include»

Transfer funds

Add cash

Startup Operator Shutdown 33

Object Model

34

Conceptual Static Model for Problem Domain: Physical Classes Maintains ATM

Operator 1

1

ATMCustomer

1

1

CardReader 1 1

1

Reads

ATMCard

1

CashDispenser 1 1

Dispenses

ATMCash

ReceiptPrinter 1 1

Prints

Receipt 35

Conceptual Static Model for Problem Domain: Entity Classes 1

Maintains

Bank 1

1 Manages

Owns 1..*

DebitCard

Provides 0..1 access to 1..*

1

ATMInfo

Has 1..*

1

Customer

Identifies

1..* Owns 1..*

*

Modifies

ATMTransaction 1,2

Card

*

36

Banking System Context Class Diagram 1

Operator

CardReader

1..* 1

1

ReceiptPrinter

1..*

1

1

1 1

1

CashDispenser 1

Banking System

1

1..*

Operator

1..*

ATMCustomer

ATM Customer

1

Interacts with

1

1..*

37

Banking System: Major Subsystems 1

ReceiptPrinter 1

Operator

Banking System 1

CardReader

1

1 1

1

ATMClient Subsystem

1..*

1

BankServer Subsystem

1

CashDispenser

1

1

ATMCustomer 38

Banking System External Classes and Interfaces Classes Banking System 1

1

1

CardReader 1

ReceiptPrinter

1

1

1

CardReader Interface

Receipt Printer Interface

Operator Interface

1

1

Operator 1

1

1

1

ATMCustomer

ATM Customer

1

CashDispenser 1

1

ATMCustomer Interface

CashDispenser Interface

1

Operator 39

ATM Client Subsystem Classes ATMClientSubsystem

CardReader Interface

ATMControl

Customer Interface

ATMTransaction

ReceiptPrinter

ATMCard CashDispenser Interface

Operator Interface

ATMCash 40

Data Flow Diagrams

41

System Context Diagram Inputs from Customer

ATM Customer

Bank Requests

Cash Outputs to Customer

Receipt Operator Instructions

ATM Operator

0 ATM System

Bank Bank Responses

Operator Responses

42

Data Flow Diagram – Level 1 Inputs from Customer Cash

ATM Card and Transactions

2

Receipt Outputs to Customer

Interface with Customer

Messages from Customer Interface

Messages to Customer Interface

ATM Cash Operator Instructions

Messages to Bank Interface

1 Control ATM Messages from Operator Interface

Messages to Operator Interface

Bank Requests

4 Interface with Bank Messages from Bank Interface

Bank Responses

3 Interface with Operator

Operator Responses

43

Level 2 DFD: Interface with Customer Card Info Eject Card

2.1 Read and Validate Card

Confiscate Card

ATM Card and Transactions

1 Control ATM

Cash

Dispense Cash

Card Inserted Transaction Input Info Read Cancelled PIN Cancel

2.2 Process Inputs and Display

2.3 Dispense Cash

ATM Cash Print Receipt

Display Message

Display Messages

2.4 Print Receipt

Receipt

44

Level 2 DFD: Interface with Operator Shutdown ATM Shutdown/Startup Started

3.1 Restart ATM

Process Operator Inputs

1 Control ATM

Cash to be Replenished

Cash Details

Display Messages

Replenish Cash

3.3 Cash Amount

3.2

Update ATM Cash DB

Display Messages

Operator Responses

ATM Cash 45

Level 2 DFD: Interface with Bank Confiscate Card

Eject Card Dispense Cash

Transaction Rejected

ATM Card and Transactions

1 Control ATM

4.2 Process Transaction Transaction Request

Transaction Approved

Validate Card Card Valid

4.1

Card Validation Request

Validate Card

Invalid Card

Card Validation Response

Card Inserted Transaction Response

Lost/Stolen Card 46

Statecharts

47

Statechart for ATM Control: Validate PIN Use Case Waiting for PIN

1.2: Card Inserted / 1.3: Get PIN

Idle Entry / Display Welcome

2.4: PIN Entered / 2.5: Validate PIN

Validating PIN 2.6: Valid PIN / 2.7: Display Menu, 2.7a: Update Status

Waiting for Customer Choice

48

Statechart for ATM Control: Withdraw Funds Use Case Idle

Terminating

Entry / Display Welcome

3.18: Card Ejected / 3.19: Display Ejected

Ejecting

Waiting for Customer Choice

3.15: Receipt Printed / 3.16: Eject

Printing 3.3: Withdrawal Selected / 3.4: Request Withdrawal, 3.4a: Display Wait

Processing Withdrawal

3.5: Withdrawal OK / 3.6: Dispense Cash, 3.6a: Update Status

3.10: Cash Dispensed / 3.11: Print Receipt, 3.11a: Display Cash Dispensed, 3.11b: ACK Cash Dispensed

Dispensing

49

ATM Control Statechart: Processing Customer Input Superstate 1.2: Card Inserted / 1.3: Get PIN

Waiting for PIN

Processing Customer 2.4: PIN Entered / Input 2.5: Validate PIN

Invalid PIN / Invalid PIN Prompt, Update Status

Validating PIN 2.6: Valid PIN / 2.7: Display Menu, 2.7a: Update Status

Waiting for Customer Choice

Cancel / Eject, Display Cancel

Idle Entry / Display Welcome

Third Invalid, Stolen / Confiscate, Update Status Transfer Selected / Request Transfer, Display Wait Query Selected / Request Query, Display Wait 3.3: Withdrawal Selected / 3.4: Request Withdrawal, 3.4a: Display Wait

50

ATM Control Statechart: Processing Transaction Superstate Processing Transaction

Rejected / Eject, Display Apology

Transfer Selected / Request Transfer, Display Wait

Processing Transfer

Transfer OK / Print Receipt, Update Status

Query Selected / Request Query, Display Wait

Processing Query

Query OK / Print Receipt, Update Status

3.3: Withdrawal Selected / 3.4: Request Withdrawal, 3.4a: Display Wait

Processing Withdrawal

3.5: Withdrawal OK / 3.6: Dispense Cash, 3.6a: Update Status 51

ATM Control Statechart: Terminating Idle Transaction SuperstateAfter (Elapsed Time)

Closed Down

After (Elapsed Time) [Closedown Was Requested]

Entry / Display System Down Cancel / Eject, Display Cancel

[Closedown Not Requested]

Terminating Terminating Transaction Card Confiscated / 3.18: Card Ejected / Display Confiscate

Third Invalid, Stolen / Confiscate, Update Status

3.19: Display Ejected

Ejecting Confiscating

Rejected / Eject, Display Apology Transfer OK / Print Receipt, Update Status

Query OK / Print Receipt, Update Status 3.5: Withdrawal OK / 3.6: Dispense Cash, 3.6a: Update Status Insufficient Cash / Eject

3.15: Receipt Printed / 3.16: Eject

Printing 3.10: Cash Dispensed / 3.11: Print Receipt, 3.11a: Display Cash Dispensed, 3.11b: ACK Cash Dispensed

Dispensing

52

Collaboration Diagrams

53

Collaboration Diagram: ATM Client Validate PIN Use Case :BankServer 1: Card Reader Input :CardReader Interface

:CardReader

1.2: Card Inserted

2.5: Validate PIN (Customer Info)

1.1: Card Input Data

:ATMCard

:ATM Control

2.4: PIN Entered (Customer Info) 1.3: Get PIN

2.2: Card Data 1.4: PIN Prompt 2.8: Selection Menu 2: PIN Input

2.1: Card Request

2.6: [Valid] Valid PIN

2.7a: Update Status

2.7: Display Menu

:Customer Interface

:ATM Transaction 2.3: Customer Info

54

Collaboration Diagram: ATM Client Withdraw Funds Use Case

55

Consolidated Collaboration Diagram for ATM Client Subsystem

56

Sequence Diagram

57

Sequence Diagram: ATM Client Validate PIN Use Case - 1 :ATM Customer

:CardReader Interface

:ATMCard

:ATMControl

:Customer Interface

:ATM Transaction

:BankServer

1: Card Reader Input

1.1: Card Input Data 1.2: Card Inserted 1.3: Get PIN 1.4: PIN Prompt

58

Sequence Diagram: ATM Client Validate PIN Use Case - 2 :ATM Customer

:CardReader Interface

:ATMCard

:ATMControl

:Customer Interface

:ATM Transaction

:BankServer

2: PIN Input

2.1: Card Request 2.2: Card Data 2.3: Customer Info 2.4: PIN Entered 2.5: Validate

PIN

2.6: [Valid]:

Valid PIN 59

Sequence Diagram: ATM Client Validate PIN Use Case - 3 :ATM Customer

:CardReader Interface

:ATMCard

:ATMControl

:Customer Interface

2.7:

Display Menu

2.7a:

Update Status

:ATM Transaction

:BankServer

2.8: Selection Menu

60

Sequence Diagram: ATM Client Withdraw Funds Use Case

61

Summary • Up till now we have completed the analysis, requirements modeling, and specification of requirements for the banking system case study • We have formally completed the requirements document for the case study 62

References • ‘Requirements Engineering: Processes and Techniques’ by G. Kotonya and I. Sommerville, John Wiley & Sons, 1998 • ‘Deg Concurrent, Distributed, and Real-Time Applications with UML’ by H. Gomaa, Addison-Wesley, 2000

63