ATM Software Development System

Advance Requirement & Software Engineering Nasreen Iqbal Msc. Software Engineering [email protected] De Montfort University

1. REQUIREMENT SPECIFICATION & TEMPLATE This section covered requirement number 1 & 2 for the task 1. 1.1. Introduction An analyst who understands the requirement and has the ability to use the tools, that represents the quality slandered in the requirement. “The system shall” is the phrase clearly specified in the requirement that referred the IEEE recommended practice 830. Automated Teller Machine that highly complicated in the implementation, required recommended slandered supportive provisions to cover all the minor or major requirements. The functional and non-functional requirements for the ATM simulation system will discuss in the following recommended framed template. 1.1.1. Purpose This document describes the software requirements for a simulation Automated Teller Machine. It is intended for the developer, designer, stockholder and maintainer of the ATM System. 1.1.2. Scope The functional and nonfunctional specification of the ATM is to support a computerized banking system to cover its basic requirements. 1.1.3. Out of Scope   

Software to communicate between ATM and bank, is not part of the requirement The bank will integrate with the ATM Hardware but later. The Hardware not been yet developed.

1.1.4. Definitions Account A single account in a bank against the transactions can be applied, with at least checking and savings. ATM A terminal that allows customers to enter their own transactions using account number as identification. The ATM interacts with the customer to gather transaction information and forward to the Bank database for validation and dispenses cash to the customer. We assume that an ATM will operate all validations and processing independently because bank trusted and authorized. Bank A financial services group that holding customer accounts and authorizing access to accounts over the ATM machine. Account Number A unique number assigned to a bank customer that authorizing access to accounts using an ATM machine. Customer Customer is the holder of one or more accounts in a bank. One customer holding an account at a different bank is considered a different customer in each bank. Transaction Process a transaction request for operation from the customer. We have only specified that ATM must dispense cash or accepting envelopes. Operator It should be easy to maintain the whole system. The maintainer will only bank authorized person, who allowed for the ATM dispenser refilling, removal of envelop and shut down and restart the ATM.

1 | Page

1.1.5. Abbreviations Throughout this document the following abbreviations are used.    

k is the maximum withdrawal per day and account. m is the maximum withdrawal per transaction n is the minimum cash in the ATM to permit a transaction t is the total fund in the ATM at start of day

1.2. Overview This section does not state specific requirements. Instead, it provides a background for requirements. This section usually consists of six subsections, as follows: 1.2.1. Product Perspective The bank will communicate with the bank computer over an appropriate communication link in the latest stage with the integration of bank software (Not included in the requirement) 1.2.2. Product functions The purpose of the ATM software must support computerized banking database to maintain their accounts and process transactions. ATM communicates with the bank database, interacts with the user to carry out the transaction dispenses cash. All these activities considered using logical database without caring its physical location. 1.2.3. Key Stakeholders 

Customer



Operator



Bank



ATM

1.2.4. Constraints This section will provide a general description of items that limits the developer‟s options.    

The bank will communicate with the ATM through the appropriate communication link. The software should encapsulate the functionality of the hardware devices within software components. The ATM hardware is not developed. The ATM must interact with the banks database.

1.2.5. Assumptions and dependencies . The assumptions and dependencies represent the risk.     

The bank will integrate the software with the ATM‟s hardware at a later time. Bank trusts the ATM to access the information in the database without security measures. ATM Hardware will available at the time of installation. Develop a simulation first version. Absence of bank database connection.

1.2.6. MoSCow Criteria / Requirements Prioritisation The requirements will be prioritized which divides the requirements into the following four categories: Priority Ranking

Description

M – Must Have

Describes a requirement that must be satisfied with the final solution to be considered a success.

S – Should Have

Describes a high-priority item that should be included in the solution if it is possible. This is often a critical requirement but can be satisfied in other ways if required.

C – Could Have

A requirement which is considered desirable but not necessary. This will be included when time and resources permit.

W – Won’t Have

Represents a requirement that stakeholders have agreed but will not be implemented in a given release, may consider for the future.

2 | Page

1.2.7. Intended Audience and Document Overview The intended audience of this document is a developer‟s group or system administrators who would use the library to control ATM system. 1.3. Specific Requirements The specific requirement focused mainly on functional requirements of ATM and bank system. 1.3.1. External Interface Requirement 1.3.1.1. User interfaces The interface of the ATM must represent the ergonomic requirements. We can distinguish this section with the hardware interface, software interface and communication interfaces, but currently we have no hardware and no communication software from the bank, we are running software on the PC therefore only the user interfaces needed. The followings are the possible interface to the ATM.    

Screen that display Messages Withdrawal screen Deposit Screen Operator screen

1.3.1.2. Hardware interfaces Not Applicable 1.3.1.3. Software interfaces Not Applicable 1.3.1.4. Communications interfaces Not Applicable. 1.3.2. Functional Requirement The functional requirements are organized in two sections: First requirements of the ATM and second requirements of the bank. Please note there are some requirements not specified in the coursework, but we tried to target because of quality system development. 1.3.2.1. Requirements of the ATM The requirements for the automated teller machine are organized in the following way. General requirements, requirements for authorization, requirements of the bank database and function requirement. 1.3.2.1.1. General Functional Requirement ID

FR01

Priority

M

Requirement Description

Initialize parameters t,k,m,n

Input

ATM is initialized with t Pounds. K,m,n are entered.

Processing

Loading the parameters

Output

Parameters are set.

Functional Requirement ID

FR02

Priority

S


ATM should display Welcome Screen.


FR03

3 | Page

Priority

S


If the ATM is running out of money.

Output

Display an error message and No Welcome Screen display

1.3.2.1.2. Authorization: The authorization starts after a customer has entered his card in the ATM. Functional Requirement ID

FR04

Priority

M


Screen displays Main message and prompt to enter 5 digit account number.

Input

Customer enter 5 digit account number

Processing

The ATM verifies the account number with the bank database.

Output

ATM Accept or reject authorization after verification from the bank database


FR05

Priority

S


If the Account number is valid, then ATM should prompt the PIN number.

Input

Enter 5 digits PIN Number

Processing

ATM do PIN verified with the bank database.

Output

Authentication accept or reject


FR06

Priority

S


The Account number should be logged for record tracing.

Input

Account number entered by the user

Processing

Log the number in the log-file, stored in the system

Output

Update the log file.


FR07

Priority

M


Different negative answers from an ATM while doing an authorized activity from the bank computer for authorization dialog.

Input

Response from bank database or authorization dialog: Bad account number: if the account number was wrong. Bad PIN Number: if the PIN number was wrong.

Processing

ATM gets any of these errors from the bank database; the user will get the 4 | Page

appropriate message. Output

Message display and return to main menu (FR02).


FR08

Priority

S


If Account number and PIN number is ok, then authorization process is finished.

Input

The ATM gets acceptance from the bank database for the authorization process.

Processing

Finishing authorization

Output

Start a transaction dialog. Screen display main menu (FR10)


FR09

Priority

C


If the account number or PIN Number entered more than 3 times and each time both the numbers are invalidated. A message will be displayed that the customer should call the bank.

Input

Entering a wrong Account / PIN number more than 3 times in a session.

Processing

Verified and check the counter (infinite loop used here)

Output

Display error message that „the customer should call the bank‟.

1.3.2.1.3. Functions These are the requirements for the different functions the ATM should provide after authorization. Functional Requirement ID

FR10

Priority

M


After Authentication, ATM will display the main menu contained 4 options

Input

Authorization successfully completed. An ATM display withdrawal menu containing the withdrawal amount 1- View balance 2- Withdraw cash 3- Deposit fund 4- Exit

Processing

ATM will process transactions from the following above options, exit if customer chooses 4.


FR11

Priority

M


The kind of transactions the ATM offers is: Withdrawal.

5 | Page

Input

Authorization successfully completed. An ATM display withdrawal menu containing the withdrawal amount 20 (Option 1), 40 (Option 2), 60 (Option 3), 100 (Option 4), 200 (Option 5), 6 (Cancel)

Processing

ATM will begin transaction process or cancel the session

Output

Transaction accepted or rejected based on selection.


FR12

Priority

M


The kind of transactions the ATM offers is: Deposit.

Input

Authorization successfully completed. Screen prompts to type deposit amount Type 0 – Cancel The user must enter the number of pens, no decimal accepted

Processing

Start Deposit processed, or the user chooses Exit typing 0

Output

ATM Ask for the envelop or display welcome menu (FR02)

1.3.2.1.4. Withdrawal Function The withdrawal requirement is based on the Simulated ATM system; there will be no physical interaction with the cash dispenser. The function will ask user to collect money and user will press ok to complete the transaction. Functional Requirement ID

FR13

Priority

M



Input

Authorization successfully completed. Customer inputs a menu (FR10) selection using Keypad.

Processing

The withdrawal amount entered is greater than the user‟s account balance

Output

ATM Display message stating problem and the system prompt to enter smaller amount. System Return to withdrawal menu (FR10)


FR14

Priority

C


Customer selected Cancel option from the withdrawal menu.

Input

Customer selected 6 as cancel from the withdrawal menu (FR10)

Processing

ATM terminates the withdrawal menu.

Output

The System display Thank you message and returned to Welcome Screen (FR02)


FR15

6 | Page

Priority

M



Input

The customer selects a choice from the menu (FR10) for the withdrawal

Processing

Selected withdrawal amount is less than or equal to the user‟s account balance

Output

The system accepted transaction and begin process to check the cash dispense for the selected amount.


FR16

Priority

M


Dispense slot contained greater than the selecting withdrawal amount.

Processing

ATM debit withdrawal amount from the users‟ account from the bank database.

Output

The Cash Dispenser dispensed the desired amount, Display message, reminding user to collect amounts from the Cash Dispenser.


FR17

Priority

M


Cash Dispense contained not enough value.

Processing

The system checks the cash dispenser for the available balance and prompts to select lesser amount.

Output

A message displays indicating the problem and prompt to select, the less amount; System return to the withdrawal menu (FR10).


FR18

Priority

C


If the money is dispensed, the amount is logged.

Input

The number of 20£ bills requested is dispensed to the customer.

Processing

Entered the details against the account number in the log.txt file stored in the system.

Output

Details logged along with the account number, the response sent to the bank.

1.3.2.1.5. Deposit Function The Deposit slot here texture as a real ATM process, in the real hardware the slot might send the signal to ATM indicating that envelope deposited, the ATM, then sends messages to the bank indicating that envelope deposited and the bank will credit the amount, to simulate this operation into the ATM, included deposit slot in the development. If the customer fails to deposit the envelope within the timeout period, or presses cancel instead, the deposit will not be credited to the customer. Functional Requirement ID

FR19

7 | Page

Priority

C



Input

Authorization successfully completed. Customer Entered the amount to deposit

Processing

Verified entered amount, System rejected the real number

Output

The Message appeared to remember that “Enter amount in pens only”, return to FR13 and wait


FR20

Priority

M



Input

Customer entered amount in the pens to deposit

Processing

Verified the entered amount value, the system calculates the amount divided by 100 to obtain a number representing pound (e.g. 125/100=1.25)

Output

The screen displayed a message to the user to insert a deposit envelope into the deposit slot.


FR21

Priority

M


Deposit Slot Receive the Envelop

Input

Prompt to insert Envelop into deposit slot

Processing

If the envelope received within 2 minutes, then ATM credited the deposited amount to the user‟s account.

Output

The screen displays a Thank You Message, return to the main menu and wait for additional transaction or choose exit.


FR22

Priority

M


Deposit Slot Not Receive the Envelop in the specific period of time.

Input

Customer not insert Envelop into the deposit slot

Processing

ATM waits for 2 minutes, deposit slot not received envelop.

Output

The screen displays a message that the system has cancelled the transaction, display main menu (FR10) and wait for user input.


FR23

Priority

S


The Customer chooses to cancel

8 | Page

Input

Customer Entered 0 (Zero) to exit.

Processing

ATM cancels the transaction

Output

The screen return to main menu (FR02)

1.3.2.1.6. View Balance Functional Requirement ID

FR24

Priority

M


Process balance inquiry

Input

Entered view balance option from the main menu FR10

Processing

ATM retrieves balance from the bank account

Output

The screen displays the user‟s account balance, return to the main menu (FR10) and wait for another input.

1.3.3. Requirements of the Bank Database for the ATM 1.3.3.1. Authorization: The bank gets a request from the ATM to verify an account. If the bank database determines that the customer's account number / PIN is invalid, the customer will be required to re-enter the details. The bank will check If the customer is unable to successfully enter the account number / PIN after three tries, the bank will send a message to the customer stated to contact the bank. Functional Requirement ID

FR25

Priority

S


If it is not a valid bank Account number, the ATM will send a message to the Customer

Input

Invalid bank Account number.

Processing

The ATM, check from the bank database, if the bank account is invalid. A bank account is valid if the account number available in the database.

Output

The ATM displays the message “Invalid Bank Account”


FR26

Priority

S


The ATM, checks the bank database if the PIN invalid.

Input

Invalid PIN

Processing

The ATM, check from the bank database, if the PIN is invalid. A PIN is invalid if the PIN number (hexadecimal) doesn't match in the database.

Output

Invalid PIN.


FR27

Priority

S

Requirement

The ATM will check the bank database if the PIN valid. 9 | Page

Description Input

Valid PIN

Processing

The ATM, check from the bank database, if the PIN is valid. A PIN is valid if the PIN number (hexadecimal) matches in the database.

Output

Valid PIN Number.


FR28

Priority

M


ATM counts the number of wrong PIN and Account entries

Input

Repeatedly invalid PIN / Account number entered

Processing

Update count for invalid PIN / Account number for the account. If it reached the maximum limit then ATM must cancel the transaction.

Output

The ATM Display the message “Invalid PIN/ account number attempt”, return to main menu (FR02)


FR29

Priority

S


If it is a valid Account and a valid PIN but there are problems with the account.

Input

Valid Account Number and PIN

Processing

The problem occurred in the system, ATM will send a problem message

Output

The ATM Display error message and return to welcome screen


FR30

Priority

S


If it is a valid Account number, a valid PIN and there are no problems with the account

Input

Valid Account/ PIN number.

Processing

Process Message

Output

ATM receives “Account ok” from the database

1.3.3.2. Transaction: The ATM will communicate with the bank in each transaction and obtain verification. The transaction will be considered complete by the bank once it has been approved. If a transaction fails for any other reason rather than an invalid PIN or invalid account number, the ATM will display a description of the problem, and prompt to do another transaction. Functional Requirement ID

FR31

Priority

M


After a request the ATM computer processes the transaction

10 | P a g e

Input

Request to process a transaction on an account and amount „m‟ to withdraw.

Processing

Process a transaction. Update k parameter for a month

Output

If transaction succeeded, the ATM displays the message “Transaction Succeeded”. If not, it will display “Transaction Failed”.


FR32

Priority

M


Update account after the money is dispensed

Input

The response from ATM about money dispensed, deduction from the t parameter

Processing

Updates account by the ATM in the bank database

Output

New account record


FR33

Priority

S


ATM dispenser has a limit „k‟ for each account.

Input

Request to process the transaction

Processing

Check if the amount of money doesn‟t exceed k parameter

Output

If the amount exceeds the limit the transaction will fail and display the message, return to main menu.


FR34

Priority

S


If the deposit slot received the envelope, actually user will press OK button to accept.

Input

Deposit slot

Processing

ATM manipulates with the bank database

Output

The ATM credits the deposit amount to the user‟s account balance.


FR35

Priority

M


If Successfully Execute the Transaction.

Input

Transaction Completed

Processing

Check transaction over

Output

The system will return to the main menu and wait for another transaction.

Functional

FR36 11 | P a g e

Requirement ID Priority

W


If the transaction has encountered with k, m, n constraints abbreviation

Input

The transaction starts

Processing

ATM, check abbreviations with k, m, n and invalidate any of them

Output

Display error message, return to the main menu.

1.3.3.3. Session: Functional Requirement ID

FR37

Priority

M


The ATM session begins

Input

Customer Input the identity

Processing

The authentication verified by the bank database and executing the transaction.

Output

The system will wait for user input using the main menu.


FR38

Priority

S


ATM session Ended or Cancelled by the user

Input

Customer Inputs selection or choose exit.

Processing

The Session completed its transaction or terminated by the user exit selection or other termination occurred, logged the account number in the log file.

Output

„Thank You‟ message display and return to the main menu (FR02)

1.3.4. Bank Operation panel activity The ATM will have operated switch that will allow authorized operator to start and stop the servicing of customers by turning OFF/ON ATM. The operator will be required to remove envelops from the slot and enter the total cash on hand while ATM turned OFF, which in turn not servicing a customer. The Operator required to verify and confirm when the machine turned ON. The Operator is presuming that no physical interaction yet, the simulation only shuts down and start up the PC. Functional Requirement ID

FR39

Priority

M


ATM Operator Panel turns off

Input

The switch Off of the ATM system by the operator.

Processing

The ATM system shutdown.

Output

The Operator removes envelops from the deposit slot and refill the cash dispenser. (Simulate)

12 | P a g e


FR40

Priority

M


ATM Operator Panel turn On

Input

The Switch On by the operator.

Processing

The Operator verified filled dispenser and deposit slot and confirmed before ATM Switch-On.

Output

The ATM System-Up and initialized parameters, display “Welcome Screen”, ready to use.

1.3.5. Non Functional requirement The non-functional quality requirements are little tricks to gather, it included interface requirement, maintenance, time, reliability, survivability, security and operating requirement. In simulation do not much nonfunctional activity recorded, but few are very important as per check list. 1.3.5.1. Performance requirements Functional Requirement ID

FR41

Priority

M


The error message should display at least few second.


FR42

Priority

M


If there is no response from the user within 2 minutes the transaction cancel and return to main menu.


FR43

Priority

M


The ATM dispenses money if and only if the withdrawal from the account is processed and verified by the bank database.


FR44

Priority

M


Cash dispensed shall not exceed £500/- and Cash deposit limit (i.e. £2000/limit)


FR45

Priority

M


The ATM interface should be user friendly. Easy to expand and easily repaired 13 | P a g e

1.3.6. Attributes The attributes included to synchronize the process. 1.3.6.1. Safety and Security Requirements The ATM network should provide maximal security. In order to make that much more transparent there are the following requirements. This security check will come later on. 1.3.6.2. Availability The ATM network has to be available 24 hours (check later on) 1.3.6.3. Maintainability Only maintainers are allowed to Switch On and OFF for the ATM machine, operated by bank staff only. The ATM will maintain an internal log of transactions to resolve ambiguities arising from a failure in the middle of a transaction. All entries will be made in the log when the ATM is started up and shut down, all messages will sent to the Bank in each transaction along with the dispensing of cash, and for the receiving of an envelope. Log entries may contain account number and amount in pounds, but do remember the PIN number never logged for security reason. 1.3.7. Other Requirements 1.3.7.1. Data Base ATM must be able to use several data formats according to the data provided by the databases. As we assume the bank data as logical database and location doesn‟t consider, therefore we recommended the data file for the data manipulation. This will occupy small space in the system and easy to access using ODBC connection.

14 | P a g e

References IEEE Std 830-1998 Recommended Practice for Software Requirements Specifications. IEEE Std 1002-1987 (Reaff 1992), IEEE Standard Taxonomy for Software Engineering Standards. IEEE Std 1016-1998, IEEE Recommended Practice for Software Design Descriptions. „The Art of Requirements Triage‟, Alan Davis, IEEE computer, March 2003 Software Requirements. Karl E. Wieger. Windows Press

15 | P a g e

2. USE CASES UML Use Case Diagrams can be used to describe the functionality of a system, usually referred as behavior diagrams used to describe a set of actions. This session designed the ATM system, including withdrawal, deposit, authenticated user, etc. The UML Model attached to the complete conceptual view. All attached Diagrams can be viewed in the Appendix A at the end of the report. 2.1. ATM System: Represent the overall functionalities of a system in general. ATM System Use Case designed to perform the visual effect of the requirement. The requirement described as: 1. Screen display menu 2. User required to enter a selection 3. Session begins 4. Authentication checks from the bank 5. The transaction starts or cancel 6. The operator performs the ATM operation 7. Wait for the next transaction 2.2. User Authentication System: The system begins with the user authentication process. 1. 2. 3. 4. 5. 6. 7.

Screen display Welcome message and prompt to enter the account number User input 5 digit account number Prompt to enter a PIN User input PIN number in 5 digests. ATM authenticates the user with the bank database. If authenticated, then main menu display for selection. If not authenticated, then error message display and return to step one for the re - authentication process.

2.3. ATM Session: The session begins with the user verification. 1. 2. 3. 4. 5. 6. 7.

Display Menu Customer Input PIN / Account number The session begins Verified inputs from the bank database If verification success, then transaction begins Session completed. If verification unauthorized then session cancels and ATM display menu

2.4. ATM Transaction: The Transaction fulfills the following requirement in the Use Case diagram. 1. 2. 3. 4. 5. 6.

User Inputs using selection The transaction begins by user authentication from the bank database. If verified ok then the transaction completed its process. If authentication not verified then transaction cancel by ATM and display message. The user may cancel the transaction anytime, the ATM will display Thank you message. Log Updated

2.5. Withdrawal System: ATM withdrawal Use case designed, based on requirements, as stated, that cash dispenser has no physical intervention but simulate. 1. Display Menu 2. The customer enters the Account / PIN number 3. User authenticated checked by the bank 4. Session created 5. Customer Enter Amount 6. Verified Amount from the bank 7. If amount > available balance, then ATM display menu to enter less amount 8. If amount