se lab srs templete

7/29/2019 Se Lab Srs Templete

1/17

SoftwareRequirements Specification for Page 1

Software Requirements Specificationfor

Prepared by

Group Name:

Instructor: Course:

Lab Section:

Teaching Assistant:

Date:

Contents

1 INTRODUCTION...........................................................................................................................................................2

2 OVERALL DESCRIPTION...........................................................................................................................................4

3 SPECIFIC REQUIREMENTS.......................................................................................................................................8

4 OTHER NON-FUNCTIONAL REQUIREMENTS..................................................................................................14


2/17


1 Introduction

Document Purpose

ThisDocumentdescribesthesoftwarerequirementsandspecification(SRS)Forand automated teller

machine(ATM)network.TheDocument

is

intended

for

the

customer

and

thedeveloper(designers,testers,maintainers).TheReaderisassumedto havebasicknowledgeof banking

accountsandaccountservicesKnowledgeAnd understandingof UnifiedModelingLanguage(UML)

Diagramsisalsorequired.

Scope:

Thesoftwaresupportsa computerizedbankingnetworkcalledBank24.TheNetwork enablescustomersto

completesimplebankaccountservicesviaautomatedtellermachines(ATMs)Thatmaybelocated

off premiseandthatneednotbeownedandoperatedbythecustomersbank.TheATMIdentifiesa

customerbyacashcardandpassword.It Collectsinformationabout asimpleaccount

transaction(e.g.,deposit,withdrawal,transfer,billpayment),communicatesthetransaction

informationtothecustomersbank, anddispensescash tothecustomer.TheBanksprovidetheirown

softwarefortheirowncomputers.TheBank24Softwarerequiresappropriaterecordkeepingand

securityprovisions.The Softwaremusthandleconcurrentaccessesto thesameaccountcorrectly.

Intended Audience and Document Overview

The Intendedaudienceof this SRSConsistsof:Softwaredesigners

Systems

engineers


3/17


Software

developers

Software

testers

Customer

< Definitions, Acronyms and AbbreviationTERMS

1.ATM

2.C-Requirements

3.D-Requirements

4.Data-flow

5.GBE

6.GUI7.SRS

8.State transition

9.Use-case

DESCRIPTIONS

ATM is an acronym for automated tellermachineCustomer requirements-Requirementsspecified and easily understood by thecustomer.Developer requirements-A detaileddescription of the product requirements assupplied to the developer

A diagram that shows the flow of databetween processing elementsGBE is an acronym for our clients titleGreatest bank everGUI is an acronym for graphical userinterfaceSRS is an acronym for software requirementspecification

A diagram that shows the flow of theprogram from one status to the anotherA diagram used to describe the way acustomer interacts with the system

Document Convention

Account: A Single account at a bank against which transactions can be applied. Accounts May be

of various types with at least checking and savings. A Customer can hold more than one account.

MaxDailyWD: The Maximum amount of cash that a customer can withdraw from an account in a

day (from 00:00 AM To 23:59PM) Via ATMs.,PIN: It Refers To Personal Identification Number. Used

To identify and validate the logic of an ATM user.

References and Acknowledgments

Software Engineering- An Object Oriented Prespective by Eric J.Braude


4/17


2 Overall Description

The application is to be fully-functional bank software. It will consist of a few different modules.The first module is to be a software application that can be used by bank customers as in an ATM.This application will allow the user to deposit funds, withdraw funds, check balance, and transferfunds.The second module is to be a software application that is used within the bank by the bank tellersand managers. This application will allow everything the ATM allows as well as some additionalfeatures. These features include: account creation, account deletion, loan approval, customerrecords, and reports.Both pieces of software will be linked to a central bank server. This server will handle multiplethreads and will therefore allow for simultaneous access of multiple users. It will provide for user

authentication and will store all data

Product PerspectiveThe product is banking software similar in functionality to the software run in most banks. Thereporting feature is also similar to the reports available in Intuit QuickBooks and Quicken.

2.1.1 Concept of Operations


5/17


The bank software will allow for two different methods of operation. The first method of operationwill be through an ATM terminal. This operation is performed by the user. The user will beallowed to deposit funds, withdraw funds, check balance, and transfer funds. It will all be donethrough a simple, easy to use graphic user interface. It will implement the standard buttons foundon a standard ATM machine.The second part of the banking software is the bank operations software. It will run through a PCand will be manipulated by a bank teller or manager via keyboard and mouse. This will allow for aBANK SYSTEM Overall Description Page 5 of 35different type of GUI. Instead of a series of consecutive screens operated by ATM buttons thissoftware will all be organized around a menu bar. All functions will be accessible at any timethrough a menu bar at the top of the screen. These functions include: authenticating, depositingfunds, withdrawing funds, checking balance, requesting account creation, authorizing accountcreation, requesting loans, authorizing loans, and generating reports. The users will be classifiedinto two different categories: Bank managers and bank officers. This classification determineswhat access privileges the user has.

2.1.2 Major User Interfaces

A screen-flow diagram shows the flow of screens as the user interacts with the system. For theATM screen-flow diagram please see Appendix A. For the teller software please see appendix C.

2.1.2.1 Example Screenshot and description

Screenshots are provided to demonstrate what screens the user will see. Rough diagrams of theATM screens can be seen in Appendix B. Rough diagrams for the teller software can be seen inAppendix D.

2.1.3 Hardware InterfacesThe ATM system will operate using the standard hardware available in an ATM. This includes ascreen, card reader, receipt printer, keypad, and a few simple input buttons.The Teller software will operate using the standard I/O hardware available in a desktop PC.Hardware will run through the keyboard, mouse, monitor, and printer.

2.1.4 Software Interfaces// example: CGI-URL or function signatures etc (OMIT for now).

2.1.5 Communication Interfaces// example: modem etc (OMIT for now)

2.1.6 Memory Constraints// RAM, and other storage constraints (OMIT for now)BANK SYSTEM Overall Description Page 6 of 35

2.1.7 Operations// special operations (if any) (OMIT for now)

2.18 Site Adaptation Requirements: //ex: Japanese language etc (OMIT for now)

Product Functionality


6/17


The software should support a computerized banking network. Each bank provides its owncomputer to maintain its own accounts and process transactions againstthemAutomatic teller machines communicate with the banks computers.Anautomatic teller machine accepts a cash card interacts with the usercommunicates with the bank computer to carry out the transaction dispenses cashand prints receipts. The system requires appropriate record keeping and security

provisions. The system must handle concurrent access to the same accountCorrectly. The banks will provide their own software for their own computers. Thecost of the shared system will be apportioned to the banks according to the numberof customers with cash cards.

Users and Characteristics

The typical bank customer will be a person, from the age of 10 and up. There will more than likelybe a fairly equal distribution of males and females. The typical customer will probably use theATM a couple of times a week. The typical custom er might not know anything about computers,so their system needs to be very simple and easy to use. The typically customer will probably be abusy person; therefore, they will need to do their transactions as quickly and efficiently as possible.The other user is a bank employee. The bank employee will be a different type of user. The bank

employee is a fairly educated user, who is willing to sacrifice simplicity for functionality. Theywill use the software daily, for every transaction. This could quite possibly be 30-60 transactionsper hour per employee. Due to this frequency of usage stability and speed of this software is

incredibly important.

Operating Environment

The hardware,software and technology used should have following specifications:

1. The ability to read the ATM card.

2. Ability to count the currency notes.

3. Touch screen for convenience

4. Keypad(in case touch fails) .

5. Continous power supply

6. Ability to connect to banks network.

7. Ability to take input from user.

8. Ability to validate user.

Design and Implementation Constraints

LoginValidate Bank CardValidate for Card Expiration DateValidate that the card's expiration date is later than today's date

If card is expired, prompt error message "Card is expired"Validate for Stolen or Lost CardValidate that the card is not reported lost or stolenIf card is lost, prompt error message, "Card has been reported lost"If card is stolen, prompt error message, "Card has been reported stolen"Validate for Disabled CardValidate that the card is not disabledIf card is disabled, prompt error message, "Card has been disabled as of "Validate for Locked Account


7/17


Validate that the account is not lockedIf account is locked, prompt error message "Account is locked"Validate PINValidate that the password is not blankIf PIN is blank, prompt error message "Please provide PIN"Validate that the password entered matches the password on fileIf password does not match, prompt error message "Password isIncorrect"Lock AccountIf number of consecutive unsuccessful logins exceeds three attempts, lockaccountMaintain Consecutive Unsuccessful Login CounterIncrement Login Counter

User Documentation

Assumptions and Dependencies

// hardware and software assumptions and dependencies...


8/17


3 Specific Requirements

3.1 External Interface Requirements

3.1.1 User Interfaces

Hardware Interface

The ATM network has to provide hardware interfaces tovarious printersvarious ATM machines There are several companies producing the ATMmachines__several types of networks The exact speci_cation of the hardware interfaces is notpartof this document

Software Interfaces

The ATM network has to provide software interfaces to

the software used by different banksdifferent network software

The exact,detailed specifcation of the software interfaces is not part of this document.

.>

Communications Interfaces

There is no restriction of the ATM network to a specifc network protocol as long as theperformance requirements are satisfied.

Functional RequirementsFunctional requirement 1Description

Initialize parameters t,k,m,nInputATM is initialized with t dollars k,m,n are entered

ProcessingStoring the parameters

OutputParameters are set.Functional requirement 2

DescriptionIf no cash card is in the ATM,the system should display initial display.


9/17


Functional requirement 3Description

If the ATM is running out of money, no card should be accepted. An error message isDisplayed.

InputA card is entered.

ProcessingThe amount of cash is less than t.

OutputDisplay an error message. Return cash card.AuthorizationThe authorization starts after a customer has entered his card in the ATM.Functional requirement 3

DescriptionThe ATM has to check if the entered card is a valid cash card.

InputCustomer enters the cash card.

ProcessingCheck if it is a valid cash card. It will be valid if

the information on the card can be read.it is not expiredOutput

Display error message and return cash card if it is invalid.Functional requirement 4

DescriptionIf the cash card is valid, the ATM should read the serial number and bank code.

InputValid cash card.

ProcessingRead the serial number.

OutputInitiate authorization dialogFunctional requirement 6.

DescriptionThe serial number should be logged.

InputSerial number from cash card

ProcessingLog the number.

OutputUpdate to log file.Functional requirement 7

DescriptionAuthorization dialog The user is requested to enter his password.The ATM verifiesthe bank code and password with the bank computer

InputPassword from user, bank code from cash card.

ProcessingSend serial number and password to bank computer ,receive response from bank.

OutputAccept or reject authorization from bank.Functional requirement 8

DescriptionDifferent negative answers from bank computer for authorization dialogue

Input


10/17


Response from bank or authorization dialog_bad password_ if the password was wrong__bad bank code_ if the cash card of the bank is not supported by the ATM__bad account_ if there are problems with the account_Processing

If the ATM gets any of these messages from the bank computer_ the card will be ejectedand the user will get the relevant error message_

OutputCard is ejected and error message is displayed_Functional requirement _

DescriptionIf password and serial number are ok_ the authorization process is _nished_

InputThe ATM gets accept from the bank computer from authorization process_

ProcessingFinishing authorization

_Output

Start transaction dialogFunctional requirement _

DescriptionIf a card was entered more than three times in a row at any ATM and the passwordwas wrong each time_ the card is kept by the ATM_ A message will be displayed thatthe customer should call the bank_

InputEntering a wrong password for the fourth time in succession

ProcessingInitiate authorization process_ Response from bank computer is to keep the card_

OutputDisplay error message that the customer should call the bank_FunctionsThese are the requirements for the di_erent functions the ATM should provide after autho_rization_Functional requirement

DescriptionThe kind of transactions the ATM o_ers is withdrawal

InputAuthorization successfully completed_ Enter the amount to withdraw_

ProcessingAmount entered is compared with m_

OutputAmount of money to be dispensed is displayed_ Begin initial withdrawal sequence_Functional requirement _

DescriptionInitial withdrawal sequence If it is too much withdrawal redo the transaction_

InputCustomer has entered the amount of money_

ProcessingError if the amount is greater than m_

OutputStart transaction or re_initiate transaction dialog if the amount is not within the pre_de_ned transaction policy_

_Functional requirement _

DescriptionPerform transaction_

Input


11/17


Initial withdrawal sequence successfulProcessing

Send request to the bank computer_Output

Wait for response from the bank computer_Functional requirement _

DescriptionIf the transaction is successful_ the money is dispensed_

InputATM gets message _transaction succeeded_ from the bank computer_

ProcessingATM prints receipt_ updates t and ejects the card_ Dialog Customer should take thecard_

OutputAfter the Customer has taken the card the money is dispensed_Functional requirement _

DescriptionIf the money is dispensed_ the amount is logged

InputThe number of ___ bills requested is dispensed to the customer_

ProcessingLog the amount of money against the serial number of the card_

OutputAmount logged together with the serial number_ Response sent to bank for moneydispensed_Functional requirement _

DescriptionIf the transaction is not successful_ an error message should be displayed_ The cardshould be ejected_

InputATM gets message _transaction not successful_ from the bank computer__Processing

ATM displays error message_ Dialog Customer should take the card_Output

Eject card_____ Requirements of the bank computer for the ATM

AuthorizationThe bank computer gets a request from the ATM to verify an account_Functional requirement

DescriptionThe bank computer checks if the the bank code is valid_ A bank code is valid if thecash card was issued by the bank_

InputRequest from the ATM to verify card Serial number and password_

ProcessingCheck if the cash card was issued by the bank_

OutputValid or invalid bank code_Functional requirement _

DescriptionIf it is not a valid bank code_ the bank computer will send a message to the ATM_

InputInvalid bank code

ProcessingProcess message

Output


12/17


The bank computer sends the message _bad bank code_ to the ATM_Functional requirement _

DescriptionThe bank computer checks if the the password is valid for a valid cash card_

InputRequest from the ATM to verify password_

ProcessingCheck password of the customer_

OutputValid or invalid password_

Functional requirement _Description

If it is not a valid password_ the bank computer will send a message to the ATM_Input

Invalid passwordProcessing

Process message_ Update count for invalid password for the account_Output

The bank computer sends the message _bad password_ to the ATM_


If it is a valid cash card and a valid password but there are problems with the account_the bank will send a message to the ATM that there are problems_

InputValid cash card and password

ProcessingProcess message

OutputThe bank sends _bad account_ to the ATM_Functional requirement _

DescriptionIf it is a valid cash card_ a valid password and there are no problems with the accountthe bank computer will send a message to the ATM that everything is ok

InputValid cash card_ password and account

ProcessingProcess message_

OutputSend _account ok_ to the ATM_TransactionThe bank computer gets a request to process a transaction from the ATM__


After a request the bank computer processes the transaction_Input

Request to process a transaction on an account and amount m to withdraw_Processing

Process transaction together with the software of the bank__ Update k for amountOutput

If transaction succeeded_ the bank computer sends the message _transaction succeeded_to the ATM_ If not_ it will send _transaction failed__Functional requirement

DescriptionUpdate account after money is dispensed

Input Response from ATM about money dispensed_


13/17


ProcessingUpdates account

OutputNew account recordFunctional requirement _

DescriptionEach bank has a limit k for each account about the amount of money that is availablevia cash card each day monthly_

InputRequest to process transaction_

ProcessingCheck if the amount of money doesn_t exceed k

OutputIf the amount exceeds the limit_ the transaction will fail_Functional requirement _

Description

3.2 Behaviour Requirements

3.2.1 Use Case View


14/17


4 Other Non-functional Requirements

Performance Requirements

Performance RequirementsPerformance requirement 1

DescriptionError message should be displayed at least 30 sec.Performance Requirement 2

DescriptionIf there is no response from the bank computer after a request within 2 minutes thecard is rejected with an error message.Performance Requirement 3

DescriptionThe ATM dispenses money if and only if the withdrawal from the account is processedand accepted by the bank.Performance Requirement 4

Description

Each bank may be processing transactions from several ATMs at the same time

Safety and Security Requirements

Safety Requirements:

1. Must be safe kept in physical aspects,say in a cabin.

2. Must be bolted to floor to prevent any kind of theft.

3. Must have an emergency phone outside the cabin.

4. The cabin door must have an ATM card swipe out

5. The cabin door will always be locked.which will open only when user swipes his/her ATM

card in the slot and validated as genuine.

Security Requirements

1. Users accessibility is censured in all the ways.2. Users are advised to change there PIN on first use.

3. Users are advised not to tell their PIN to anyone4. The maximum number of attempts to enter PIN will be three

Software Quality Attributes3.5.1 Reliability

3.5.1.1 [Mandatory] The system shall save the data stored in the user data structures once everyfive minutes.

3.5.1.2 [Mandatory] The system shall save the data of an active user whenever that user has justcompleted a deposit transaction.

3.5.1.3 [Mandatory] The system shall save the data of an active user whenever that user has justcompleted a withdraw transaction.

3.5.1.4 [Mandatory] The system shall save the data of an active user whenever that user has justcompleted a transfer funds transaction.

3.5.1.5 [Mandatory] The system shall save the data of an active user whenever a new user iscreated.


15/17


3.5.1.6 [Mandatory] The system shall save the data of an active user whenever a new account iscreated.

3.5.1.7 [Mandatory] The system shall save the data of an active user whenever a user passwordis changed.

3.5.1.8 [Preferred] The system shall not save on a check balance transaction.

3.5.1.9 [Mandatory] The system shall reboot itself automatically if there is a power failure andrestore all saved data to the user accounts.

3.5.2 Availability

OTHER REQUIREMENTS


16/17


Appendix A Data Dictionary


17/17


Appendix B - Group Log

se lab srs templete

Documents