Using the technique suggested here, where natural language descriptions are presented in a standard format, write plausible user requirements for the following functions:
-> An unattended petrol (gas) pump system that includes a credit card reader. The customer swipes the card through the reader then specifies the amount of fuel required. The fuel is delivered and the customer's account debited. (customer = user)
- Alert USER whenever credit card is declined
- Alert USER whenever credit card is not read correctly
- Alert USER if card reader is not working correctly
- Alert USER if amount of gas in the pump system is lower than their specified gas amount
- Stop flow of fuel whenever the USER inputted amount has been reached
- Start pumping fuel whenever USER initiates pumping (mechanism not specified)
- Print out receipt when finished pumping fuel
- Deduct funds from the account of the USER upon finishing pumping
- Alert USER if funds are not sufficient for the purchase
- Report insufficient funds to USER
- Report empty ATM
- Report invalid input for cash retrieval
- Report insufficient amount of specific denominations
- Dispense cash whenever prompted
- Deduct funds from account upon dispensing cash
-> The spelling-check and correcting function in a word processor
- Underline incorrectly spelled words
- Analyze syntactical meaning of sentence with corrected word
- Allow USER input to add new words
- Allow USER input to add new definitions
- Allow USER to override corrections
Suggest how an engineer responsible for drawing up a system requirements specification might keep track of the relationships between functional and non-functional requirements.
Using diagrams can be very helpful in these types of situations. Drawing up UML diagrams, for example, is an extremely fruitful way to go about this. Sequence diagrams, for example, are useful for representing functional requirements as well as some non-functional requirements. Any function that has a lifeline with a sequence diagram would be a functional requirement because that is something that is required by the system itself. That is an explicit, specified method. The time that the function is supposed to hang around could be a potential non-functional requirement. Perhaps there is a requirement that a user be notified within 5 seconds of something occurring; this would be a non-functional requirement. The sequence diagram example is just an example - all types of UML diagrams have their time, place, and meaning.
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.
This is not an exhaustive list of requirements, by any means:
- A USER withdraws a given amount of money
- A USER deposits a given amount of money
- A USER inputs an incorrect pin
- A USER deposits a check that can be read
- A USER deposits a check that cannot be read
- A USER inserts too many bills for a deposit (30+)
- A USER inserts too many checks for a deposit (30+)
- The ATM is out of cash
- The ATM does not have sufficient funds for the USER's withdrawal
- A bank card cannot be read
- A bank card is left in the ATM
- A bank card is invalid
- A bank card is flagged as a potentially stolen card
Use cases stemming from from these requirements can proceed as follows (again, not exhaustive):
1. A user goes to the ATM. The user inserts their bank card into the ATM. The user keys in their pin. The user deposits checks (no more than 30). The user confirms the check totals on the screen. The user finalizes the deposit. The bank card is returned to the user.
2. A user goes to the ATM. The user inserts a fraudulent bank card. The ATM reports that the bank card is invalid. An external company is notified (i.e. the police).
3. A user goes to the ATM. The user inserts their bank card into the ATM. The user keys in their pin. The user attempts to withdraw more cash than the ATM has left. The ATM reports that it does not have sufficient funds.
Music listened to while blogging: J. Cole & STRFKR
No comments:
Post a Comment