Chapter #4
Requirements engineering
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:
- 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.
- The system shall ask the user to swipe their credit card
- The system shall ask user to enter the five digit zip code associated with said credit card. (Zip code is required as a security check.)
- The system shall ask the user to enter the amount of fuel required
- The system shall ask the user to place pump nozzle in tank hole. (There shall be an option for pushing "full tank" that relies on a sensor in the nozzle gas pump. The tank shall not be over filled if customer over estimates fuel needs. A sensor alert shall go off if this occurs, alerting the gas pump, and effectively stopping the gas.)
- The system shall display the amount the account will be debited and then ask if a receipt is desired for transaction.
- The system shall tell the user to have a "nice day".
- The cash-dispensing function in a bank ATM.
- The system shall ask the user to insert a debit card
- The system shall ask user to insert PIN number. (PIN number is required as a security check.)
- The system shall ask the amount desired of the machine to dispense.
- The system shall check against the user's balance and check to see if this withdrawal is an overdraft.
- If there is an overdraft, the system should alert the user and ask if user would like to proceed.
- The system dispenses the desired amount of cash.
- The spell-checking and correcting function in a word processor.
- The system shall identify words (with a red underline) that are not in system's dictionary.
- The system shall offer user options regarding word:
- Offer to replace word. (There shall be a list of five similar words to choose from).
- Offer to ignore word and all instances of word. (So as not to pester user with redundant alerts).
- Offer to add to dictionary. (So in the future, user will not be pestered with redundant alerts).
- The red underline shall disappear once user has chosen desired option.
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.
Functional requirements: describe what the system should do. Cover general requirements to very specific requirements
Examples: the system's inputs and outputs, exceptions, etc.
Non-functional requirements: requirements that are not directly concerned with the specific services delivered by the system to its users. More critical than individual functional requirements.
Examples: performance, security, availability
For more of a visual approach, I suggest making a table with two columns, one for functional and one for non-functional. For each functional requirement, make a list of non-functional requirements that need to be kept in mind while implementing the functional requirement. You will have a lot of redundancy in these lists, but that's ok, just make the association so it's in the back of the programmers' mind.
Functional requirements: describe what the system should do. Cover general requirements to very specific requirements
Examples: the system's inputs and outputs, exceptions, etc.
Non-functional requirements: requirements that are not directly concerned with the specific services delivered by the system to its users. More critical than individual functional requirements.
Examples: performance, security, availability
For more of a visual approach, I suggest making a table with two columns, one for functional and one for non-functional. For each functional requirement, make a list of non-functional requirements that need to be kept in mind while implementing the functional requirement. You will have a lot of redundancy in these lists, but that's ok, just make the association so it's in the back of the programmers' mind.
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.
Use cases: a requirements discovery technique that were first introduced in the Objectory method. It identifies the actors involved in an interaction and names the type of interaction.
I'll be covering the 2 ways in which I use an ATM which are to withdraw money and cash a check
Use Case for ATM:
Interaction between ATM and user allows user to withdraw money, cash a check, and/or view balance. The user interacts with the ATM machine via touch screen and keyboard. There is also a slot to insert cash/checks and a slot to insert debit card. User initiates the ATM transaction by pushing desired language from display screen offering an "English" button and an "Other" button. The "Other" option leads to another screen displaying a drop down menu offering a list of other languages. Once language has been established, the display asks user to insert debit card. The display should have a moving image of the correct way to insert debit card. Once debit card is inserted, the user has the option of pushing a button for "Money withdrawal" or "Cash a check".
If the user pushes the "Money withdrawal" button, the display shows the user balance and various dollar amounts displayed in buttons that the user can choose from or the user can physically input the amount desired via keyboard. The ATM then follows through with the transaction and outputs the money. The ATM then asks if user would like to have a receipt. The receipt has the option to be printed from the ATM machine or sent via e-mail. These options are displayed on buttons.
If the user pushes the "Cash a check" button, the display asks user to input the number of checks to be cashed using the keyboard. Then a moving image shows user how to insert checks. Once checks have been inserted, the amount on the checks are totaled. The total is displayed and the user can confirm that the amount is correct. Once confirmed, user balance is adjusted and displayed. The user can then withdraw or end session.
When the "end session" button is pushed, the machine beeps to remind the user to take debit card and then outputs the debit card.
Use cases: a requirements discovery technique that were first introduced in the Objectory method. It identifies the actors involved in an interaction and names the type of interaction.
I'll be covering the 2 ways in which I use an ATM which are to withdraw money and cash a check
Use Case for ATM:
Interaction between ATM and user allows user to withdraw money, cash a check, and/or view balance. The user interacts with the ATM machine via touch screen and keyboard. There is also a slot to insert cash/checks and a slot to insert debit card. User initiates the ATM transaction by pushing desired language from display screen offering an "English" button and an "Other" button. The "Other" option leads to another screen displaying a drop down menu offering a list of other languages. Once language has been established, the display asks user to insert debit card. The display should have a moving image of the correct way to insert debit card. Once debit card is inserted, the user has the option of pushing a button for "Money withdrawal" or "Cash a check".
If the user pushes the "Money withdrawal" button, the display shows the user balance and various dollar amounts displayed in buttons that the user can choose from or the user can physically input the amount desired via keyboard. The ATM then follows through with the transaction and outputs the money. The ATM then asks if user would like to have a receipt. The receipt has the option to be printed from the ATM machine or sent via e-mail. These options are displayed on buttons.
If the user pushes the "Cash a check" button, the display asks user to input the number of checks to be cashed using the keyboard. Then a moving image shows user how to insert checks. Once checks have been inserted, the amount on the checks are totaled. The total is displayed and the user can confirm that the amount is correct. Once confirmed, user balance is adjusted and displayed. The user can then withdraw or end session.
When the "end session" button is pushed, the machine beeps to remind the user to take debit card and then outputs the debit card.
No comments:
Post a Comment