4.5 Gas pump
- Function: Dispense gas for customer
- Description: Customer swipes credit card and enters desired amount of fuel. The pump then dispenses the fuel and charges the card.
- Inputs: Payment card and desired amount of fuel
- Source: Card swiper and keypad
- Outputs: Fuel
- Destination: Main control loop
- Action: Control loops checks that sufficient funds are available on the payment card and that sufficient fuel is available to fulfill request. System then dispenses fuel, checks that fuel dispensed was equal to fuel desired, and finally charges the card and checks that charge was successful.
- Requires: Communication with card bank system for funds check and with storage tank for fuel check.
- Precondition: Sufficient funds and fuel available.
- Postcondition: Correct amount of fuel dispensed, card successfully charged.
- Side effects: Fuel inventory reduced.
ATM withdrawal
- Function: Customer withdrawal of funds from ATM
- Description: Customer inserts card, enters PIN, and requests cash from ATM. ATM performs security checks, checks funds available, dispenses cash, checks correct cash output, and returns card.
- Inputs: ATM card, PIN, desired funds
- Source: Card reader, keypad
- Outputs: Cash
- Destination: Main control loop
- Action: Card reader reads inserted card and validates PIN. Machine accesses bank account and asks user how much cash is desired. Machine checks that funds are available, checks that it has the cash available, and dispenses cash. Machine checks that correct amount of cash was dispensed and correct amount of money was debited from account and returns card.
- Requires: Secure communication with bank, cash on hand
- Precondition: Functional card, correct PIN, available funds, sufficient cash
- Postcondition: Correct amount of cash was dispensed and correct amount of funds were debited.
- Side effects: Cash inventory reduced. Perhaps perform some type of security review after transaction to check for tampering.
Online bank transfer
- Function: Online intrabank funds transfer
- Description: Customer uses online bank system to transfer funds from one account to another within the same bank.
- Inputs: Account info, security credentials, fromAccount, toAccount, Amount
- Source: Secure web browser interface
- Outputs: new account balances of fromAccount and toAccount
- Destination: Bank control system
- Action: User enters account identity and security credentials. The web interface performs the security check and connects to the bank account. The user selects what account the funds are coming from and to what account they are being transferred and then finally how much money should be transferred. The system checks that the fromAccount has sufficient funds, executes the transfer, and then checks that the new account balances are correct before reporting a successful transfer.
- Requires: Secure connection to the banking system.
- Precondition: Correct user credentials, sufficient funds in fromAccount
- Postcondition: Funds in fromAccount and toAccount are correct
- Side effects: User receives 7 annoying satisfaction surveys.
4.6
Functional requirements, what the system does, and nonfunctional requirements, how the system is affected by external contraints and activities, are distinct but very much related. It is important to keep track of functional and nonfunctional requirements separately but also consider how they affect one another, so an engineer should follow a process that ensures their individual attributes and connections are thoroughly considered.
One practical way to track these complex interactions between functional and nonfunctional requirements might be to draw up a diagram that clearly distinguishes between the two categories, perhaps functional requirements listed on the left side and nonfunctional on the right, and then draw lines connecting those connections that affect one another. So you would end up with a map of interactions. Then, the engineer might index the list in such a way that a change in a particular functional requirement would create an alert that all of its connected nonfunctional requirements should be revisited. Using this sort of connection map would allow me to see these categories as distinct but also track all of their interations.
4.7
Case 1 Bank customer with ATM card attempts to withdraw funds from account with sufficient funds. ATM card is inserted, PIN is entered correctly, and funds are withdrawn.
Case 2 Bank customer with ATM card attempts to withdraw funds from account without sufficient funds. ATM card is inserted, PIN is entered correctly, and customer is rcommended to go get a job.
Case 3 Bank customer with ATM card attempts to withdraw funds from account but forgets PIN. Customer is told to go away.
Case 4 Bank customer with ATM card attempts to withdraw $200, but this is Greece and the banks have all shut down withdrawals. Too bad, sucker!
Case 5 Interloper attaches a keypad and/or card reader of his own to the ATM. A customer then comes to withdraw funds, but thankfully the ATM has already performed a routine security check, noticed the tampering, and shut itself down with a friendly but intentionally vague error message to try again later.