HW5: Chapter 4 and Reflections
Today's entry
Excercise Questions
4.5: Using the technique suggested here, where natural language descriptions are presented in a standard format, write plausible user requirements for the following functions:
1) An unattended gas pump system that includes a credit card reader. The customer swipesthe card through the reader, then specifies the amount of fuel required. The fuel is delivered and the customer's account debited.
2) The cash-dispensing function in a bank ATM.
3) In an internet banking system, a facility that allows customers to transfer funds from one account held with the bank to another account with the same bank.
- High-level: The credit card reader shall correctly process credit/debit card payments for a purchase of gas.
More explicit requirements
The system shall accept and verify user's credit/debit card
The system shall provide PIN verification.
The system shall provide an interface to let the user choose the amount of gas.
The system shall charge the user for the purchase of gas.
The system shall print a receipt after a sucessful transaction.
- High-level: The system shall provide an interface for a user to withdraw money from their account.
The system shall accept a user's account/card information
The system shall allow a user to choose available accounts the withdraw from
The system shall let a user entered how much money to withdraw.
The system shall dispensed the money as cash.
- High-level: The system shall provide an interface to connect to and transfer funds between accounts.
Given that a user is already logged in, the system shall let a user start the transfer process.
The system shall allow a user to select an account to withdraw from.
The system shall let a user enter in the account to deposit to.
The system shall let a user enter in how much money to deposit.
The system shall deposit the money upon confirmation.
4.6: Suggest how an engineer responsible for drawing up a system requirements specification might keep track of the relationships between functional and non-functional requirements.
Visually an engineer could keep track of the relationships by using a diagram system. I would recommend mixture of state diagrams for functional components and UML diagrams for non-functional components with specific ID's to establish relationships between state and UML diagrams as they relate to specific pieces of a system. As for determining whether a requirement should be functional or non-functional I would recommend asking the general question of "how?" or "what?". What I mean is when considering the system and a requirement asking if the requirement is answering what a system should do or answering how a system should do something. An example could be pulled from the question above. If we proposed a requirement such as "the system should be able to verify payment in 10 seconds." It is true that this statement is prescribing what a system should do but it is also saying it must do so quickly. It is directly answering how the system should work. So this requirements wording should be rephrased and should be designated as a non-functional requirement. However there are other factors to consider. Sometimes answering the how is directly necessary to the functional requirement of a system. If this is the case, it should then be considered a functional requirement.
4.7: Using your knowledge of how an ATM is used, develop a set of use cases that could serve as a basis for understanding the requirements for an ATM system.
- Withdrawing: User inserts credit/debit card. ATM verifies card. If the card is rejected, ATM notifies user of rejection and returns to home screen. User enters PIN number. If PIN is incorrect, notifies user and returns to home screen ATM verifies PIN. User selects withdraw. User enters amount. ATM verifies amount. If insufficient funds, notifies user and cancels transaction. Else ATM deposits cash. ATM prints recipt. ATM returns card. ATM returns to home screen.
- Depositing: User inserts credit/debit card. ATM verifies card. If the card is rejected, ATM notifies user of rejection and returns to home screen. User enters PIN number. If PIN is incorrect, notifies user and returns to home screen ATM verifies PIN. User selects deposit. User deposits cash. ATM records amount to deposit. User selects finish deposit. ATM credits account with the deposited amount. ATM prints recipt. ATM returns card. ATM returns to home screen