Personal Retinal Scan identification All bank ATMs in ...staff.unak.is/andy/Year2 Object Oriented...

27/09/2003 Dr Andy Brooks 1

Object Oriented MethodsLectures 13 and 14

SRS III: Structure of a Software Requirements Specification

ANSI/IEEE Std 830-1984

examples throughout

...Personal Retinal Scan identification.

All bank ATMs in Iceland to be equipped with...


A possible SRS outlineToc1. Introduction… 1.1 Purpose… 1.2 Scope… 1.3 Definitions, Acronyms, Abbreviations.… 1.4 References… 1.5 Overview2. General Description… 2.1 Product Perspective… 2.2 Product Functions… 2.3 User Characteristics… 2.4 General Constraints… 2.5 Assumptions and Dependencies3. Specific Requirements… 3.1 Functional Requirements… 3.2 Performance Requirements… 3.3 Design Constraints… 3.4 Attributes… 3.5 External Interface Requirements… 3.6 Other requirementsAppendicesIndex

Use Cases and UML diagrams can be used for Section 3. Diagrams may optionally be placed in the appendices.


1. Introduction1.1 Purpose

– state purpose of document• This document represents all software requirements for the

new automatic teller machine (ATM) system.

– specify intended audience • This document is intended for the designers, coders, and

testers of the computer software QuickTeller.

1.2 Scope– name software product

• QuickTeller

– explain what it will do, and if necessary, what it will not do• QuickTeller will control operation of the ATM providing prompts

to the user, performing accounting transactions to update the bank´s accounts database, and discharging paper money.

– precisely describe benefits and goals• QuickTeller´s novel approach to customer identification will

eliminate fraud and also mean customer identification can carried out within less than 0.2 seconds.


1.3 Definitions, Acronyms, and Abbreviations– provide definitions of all terms

• SRS: Software Requirement Specification• Withdrawal Limit: the maximum a customer can withdraw

subject to the account balance and the amount already withdrawn on the current date.

• PRS Personal Retinal Scan: the scan associated with the customer ID to identify a legal user.

– use appendices or references to other documents as necessary

1.4 References– a list of all documents referenced by the SRS

• title, report number, date, publisher, source if not public

– reference information may be provided in an appendix1.5 Overview

– what the rest of the SRS contains and its organisation• e.g. a description of table of contents


2. General Description

The General Description section does not state specific requirements: it only makes them easier to understand.


2.1 Product Perspective

• State if product is independent and totally self-contained,

• Or – describe functions of other components and identify interfaces

• QuickTeller can query the status of customers´accounts and the amounts already withdrawn on the current date through its interface with the bank´s accounts database.

• QuickTeller can query the validity of a PRS with the bank´s security database.

• QuickTeller interfaces with the operator, card reader, cash dispenser, display screen, keypad, and the retinal scanner.

• A block diagram can help show major components– blocks may represent hardware or software, at any level of

abstraction


QuickTeller

security database

accounts database

cash dispenser

card reader display screen

key pad

retinal scanner

Figure 1 QuickTeller interfaces.

firewall

Video camera

video databasePRS

operator interface

Block Diagram


2.2 Product Functions• List functions (or Use Case goals)

• verify customer identification• check account balance• transfer funds between accounts• dispense cash

• Block (or Use Case) diagrams may explain functions and relationships but are not meant to dictate a design solution.

27/09/2003 Dr Andy Brooks 9Oops ...


2.3 User Characteristics• Describe general characteristics of the eventual users

– educational level (e.g. High school graduate, Batchelor or Master´s Degree)

– experience– technical expertise

• Specific requirements or design constraints are stated later…

Customers will be from the general public. They should be regarded as occasional users who receive no training in the use of QuickTeller including the retinal scanner.

Bank staff will receive training in both bank-side and customer-side use of a QuickTeller ATM.


2.4 General Constraints(limits developer’s options)

• Types of general constraints:– Regulatory policies

• The Consumer Health Act requires that customers are informed, at the point of use, of the hazards of prolonged exposure to retinal scan beams.

– Hardware limitations• QuickTeller machines will each have 128Mb of RAM.• Data transmission speeds to the accounts and security

databases are governed by annually renewed leasing agreements for lines with HighTelecom plc.

– Language requirements• The software will be written in Java using JDK 1.4 and

code documentation produced according to Sun´s javadoc guidelines and conventions.


2.4 General Constraints(limits developer’s options)

• Types of general constraints:– Interface protocols

• The firewall and retinal scanner require use of manufacturer communications protocols.

– Audit functions• The Criminal Justice Act requires that the start and end

time of each customer interaction is recorded for not less than seven days.

– Safety and Security• The Consumer Health Act requires that a record be kept

of the number of retinal scan beams a customer has been exposed to.

• Specific requirements or design constraints are stated later…


2.5 Assumptions and Dependencies• The bank´s accounts and security databases will be

accessible in real-time.• The bank´s security database will be modified to identify

legitimate customers on the basis of face recognition data from video capture.

• Firewall and retinal scanner communications protocols are not expected to change.

• QuickTeller machines will never have less than 128Mb RAM.

• The number of fraudulent customers at any ATM on any day is not expected to exceed five.


Section 3(the specific requirements)

• Typically the largest and most important section of the SRS.

• Cross-reference each specific requirement to any related discussion elsewhere in document.

• State each requirement so that it can be objectively verified by a prescribed method in a finite amount of time.

All baggage at claim area after 35 minutes...


Classifying requirements

• One way to classify– functional– performance– design constraints– attributes– external interface requirements

A Use Case can capture these requirements.


3.1 Functional Requirements

(1) Introduction• verify customer identification

– This function verifies that the customer is authorised to use the ATM.

(2) Inputs (3) Processing

– define all operations on input data and intermediate parameters to obtain output

(4) Outputs


Inputs

• Sources of inputs• retinal scan reader provides eye_id• ATM card reader provides account_number

• Valid input range & units of measure• eye_id = 9{numeric character}9• account_number = 9{numeric character}9

• Timing• Both inputs are provided once after an ATM card has been placed

in the machine and the customer has triggered a retinal scan.

Not 1 up to 9 but exactly 9.


Processing• Validity checks on input

• If the account_number is on the lost_reported_stolen_list or is an idle_account_number then retain ATM card and cancel processing.

• If the eye_id is an idle_eye_id then retain ATM card and cancel processing.

• Sequence and timing of events• If the account_number is not on the lost_reported_stolen_list then prompt

the user for retinal scan.• If the eye_id is not available within 10 seconds of the account_number

being read the ATM card is ejected from the ATM card reader.• If the account_number and eye_id and video_image do not represent the

same customer then retain ATM card and cancel processing.• Responses to abnormal situations

• If the account_number is invalid then report ATM card reader failure and advise customer to try another ATM.

• If the eye_id is invalid then report retinal scan reader failure and advise customer to try another ATM.

• Methods (particular algorithms)• None specified.

• Validity checks on output data• Output messages to customer do not exceed available screen space for

text messages.


Outputs• Destination of outputs

• Bank management information system.

• Valid output range and units of measure• customer_verified = true|false

• Timing• This output is provided once at the termination of verify

customer identification.

• Messages• “This card has been retained. Contact your branch.”• “Failure in card reader. Try another ATM.”

Oops, Bank MIS missing from the block diagram.


3.2 Performance Requirements

Static and dynamic numerical requirements.• The time to verify customer identification will be less

than 0.2 seconds.• From the time an amount is selected, the time taken to

discharge paper money will be less than 3 seconds.

Requirements must be objectively verifiable.


3.3 Design Constraints• Legal & standards compliance

• Immediately a retinal scan has been performed, QuickTell software must increment the retinal_scan_count for that customer held in the accounts database.

• Immediately after a card has been returned to the customer a transaction record with details of start and end time must be appended to the transaction list for that customer held in the accounts database.

• Hardware limitations• The ATM machine provides no less than 128Mb RAM. This

implies that all the software required to make QuickTell operatemust never use more than 128Mb at any time.


3.4 Attributes• Availability

• The ATM can be refilled with cash without a system shutdown.• Annual QuickTell software upgrades by a trained bank

operative will involve no more than 2 hours downtime of an ATM.

• In the event of total power failure the ATM can restart without bank-side operator intervention.

• Security• Bank-side operator access should be protected by an 8-digit

password.

• Maintainability• No section of QuickTeller code should have a cyclomatic

complexity measure greater than 10.• The code should be modular and each module cohesive i.e. the

purpose of each module should be summarisable using a single active verb phrase.

Requirements must be objectively verifiable.


3.5 External Interface Requirements• User Interfaces

• Customers will be guided through every step of their use of QuickTeller services with messages of instruction.

• Flesch readability scores for messages must be greater than 60.• Bank customers should be able to use an ATM without any training i.e.

the system should have “walk up and use” capability.• Bank-side operatives should be able to conduct annual maintenance

following half a day´s training.• Interfaces to software packages

• The bank management information system should be able to query the status of the ATM over the bank´s intranet. This status information will include the amount of cash discharged, the amount of cash remaining, and the mechanical status of the ATM.

• Hardware and communication interfaces• Devices and network protocols TBD. Manufacturer documentation is to

be consulted and protocol requirements established by the end ofOctober 2003.


3.6 Other Requirements

• When the video image does not match the retinal scan, QuickTell should send a message to the police computer and conduct a simulated dialogue to allow the police time to apprehend the bogus customer.

Oops, police computer missing from the block diagram.


SRS Organisation

• Purpose of subdividing an SRS is to improve readability of the SRS, and accessibility to individual requirements,not to define the high level design.

Where was the requirement on withdrawal limits?


3.1 Functional Requirements3.1.1 Functional Requirement 1

3.1.1.1 Introduction3.1.1.2 Inputs3.1.1.3 Processing3.1.1.4 Outputs3.1.1.5 Performance Requirements3.1.1.6 Design Constraints3.1.1.7 Attributes3.1.1.8 Other Requirements

3.1.2 Functional Requirement 2

Alternative organisation


Use Case: <number> <the name should be the goal as a short active verb phrase>CHARACTERISTIC INFORMATIONLevel: <one of: Summary, Primary task, Subfunction>Preconditions: <what we expect is already the state of the world>Success End Condition: <the state of the world upon successful completion>Failed End Condition: <the state of the world if goal abandoned>Primary Actor: <a role name for the primary actor, or description>Trigger: <the action upon the system that starts the use case, may be time event>MAIN SUCCESS SCENARIOEXTENSIONSSUB-VARIATIONSRELATED INFORMATION Priority: <how critical to your system / organization>Performance Target: <the amount of time this use case should take>Frequency: <how often it is expected to happen>OPEN ISSUES SCHEDULE

Use Case organisation

Dr Andy Brooks 28

Use Case: <number> <the name should be the goal as a short active verb phrase>CHARACTERISTIC INFORMATIONLevel: <one of: Summary, Primary task, Subfunction>Preconditions: <what we expect is already the state of the world>Success End Condition: <the state of the world upon successful completion>Failed End Condition: <the state of the world if goal abandoned>Primary Actor: <a role name for the primary actor, or description>Trigger: <the action upon the system that starts the use case, may be time event>MAIN SUCCESS SCENARIOEXTENSIONSSUB-VARIATIONSRELATED INFORMATION Priority: <how critical to your system / organization>Performance Target: <the amount of time this use case should take>Frequency: <how often it is expected to happen>Design Constraints:Attributes:External Interface Requirements:Other Requirements:OPEN ISSUES SCHEDULE

Modified Use Case organisation


Supporting information• Table of Contents and Index• Appendices

– Explicitly state whether or not appendices are to be considered part of the requirements.

– Possibilities include:• References.• Definitions of all types of data.

– account_number = 9{numeric character}9– audit_trail = start_time + stop_time + location + account_number– location = 6{alphanumeric character}6

• Any tables or (UML) diagrams referenced by individual requirements.• Cross-reference list of incomplete software requirements which are to

be completed by specified milestones.• Results of customer surveys on the use of retinal scans to replace entry

of a personal identification number when using an ATM.• Any background information that can help the reader of the SRS.


View the SRS as a living document.

Personal Retinal Scan identification All bank ATMs in ...staff.unak.is/andy/Year2 Object Oriented...

Documents

Transcript of Personal Retinal Scan identification All bank ATMs in ...staff.unak.is/andy/Year2 Object Oriented...