Term Paper: Atomatic Teller Machine (ATM) Project System Functional Requirements Document

One of the necessary skills for successful system development is gathering and developing functional requirements. This particular hub was created based on a term paper developed to fulfill the requirements of a graduate school course in System Development; the scenario for the assignment follows:

Bank customers and credit card holders use ATM machines to perform transactions and check account balances. This functional requirements document is based on a scenario comprising a small bank that is planning the installation of 30 ATMs throughout the region. A description of the requirements gathering process is contained in Appendix A at the end of the paper.

1. The system will only accept ATM cards from participating banks and credit card institutions.

2. The system can interface with participating banks and credit card institutions.

3. All 30 bank ATMs may be used simultaneously.

4. Customers can only make payments to accounts linked to their ATM cards.

5. The system can verify the availability of funds in an account before dispensing cash for withdrawals or cash advances.

 1. A customer must be able to make a cash withdrawal from any suitable account linked to the card, in multiples of $20.00.  Approval must be obtained from the bank before cash is dispensed.

2. A customer must be able to make a deposit to any account linked to the card, consisting of cash and/or checks in an envelope. The customer will enter the amount of the deposit into the ATM, subject to manual verification when the envelope is removed from the machine by an operator.  Approval must be obtained from the bank before physically accepting the envelope.

3. A customer must be able to make a transfer of money between any two accounts linked to the card.

4. A customer must be able to make a balance inquiry of any account linked to the card.

(Bjork, 1998)

1. An ATM machine accepts a card from a user.

2. The user inputs a Personal Identification Number (PIN) to authenticate the user’s identity.

3. The system validates the card and the PIN, then either continues processing or rejects the card.

4. The ATM prompts the validated user for the type of transaction; valid transaction types are as follows:

·        Check account balance

·        Process a deposit

·        Process a withdrawal for an ATM customer or a

·        Process a cash advance for a credit card holder

·        Transfer funds

·        Pay bills

5. The ATM communicates the request to the appropriate financial system

6. The appropriate financial system responds with permission or denial of the request.

7. The ATM asks the user if they want a printed receipt.

8. The ATM acts on the request according to the response received from the financial system. Possible actions for granted requests include the following:

·        reject the request

·        accept a deposit

·        dispense cash

·        display or print an account balance

·        pay a bill

·        perform an Electronic Funds Transfer (EFT)

9. The system updates the bank’s financial system for ATM transactions or sends an EFT to the appropriate financial institution for credit card transactions.

10. The ATM prints a receipt if one is requested.

11. The system prompts the user for another transaction and repeats steps 4 – 10 if yes.

12. The ATM closes the session and waits for another user when done.

1. PINs are four digits in length.

2. Account numbers are contained on the cards used to gain access.

3. Card readers must read embossed characters and magnetic information.

4. The ATM system must format transactions in Electronic Data Interchange format for transmission to other financial institutions.

5. Non-sufficient funds in an account should cause the rejection of a withdrawal request or cash advance transaction.

6. ATM cards may link to more than one account.

7. PINs and account numbers are issued by the appropriate financial institutions.

1. The ATM machines should accept cards in a card reader.

2. The card reader should be the “swipe” type and the machines will not retain cards.

3. The ATM machines must interface with the bank’s existing financial system.

4. The ATM system must be capable of formatting transactions using EDI standards.

5. The ATM system must be capable of performing EFTs.

6. The ATMs must communicate with the bank’s financial system using secure methods.

7. The ATM machines will not communicate with one another.

8. The bank’s financial system will handle the communication with other financial systems.

9. Touch-pads should be used to reduce mechanical failure.

10. ATM machines must be able to withstand inclement weather.

1. The system should respond to requests in less than five seconds. (Pfleeger and Atlee, 2006).

2. The system should be available for communication 97% of the time (Pfleeger and Atlee, 2006) on a 24/7/365 basis.

3. An individual ATM should process requests not involving dispensing funds when the cash hampers are empty.

4. Cash hampers should be regularly serviced to maintain convenience for bank customers.

5. Displays should be easy to read and touch pads easy to use.

A business system developer or analyst needs to know who the responsible parties or stakeholders are for a particular project. Once stakeholders are identified, the methodology for requirements gathering can be identified. For the ATM project, a reasonable start for the requirements gathering process would be to review the IT Service Request (Rosenblatt, 2003) for the forthcoming project. The IT Service Request should list the requesting authority and provide a good resource to identify stakeholders along with the bank’s organizational chart.

Once the stakeholders have been identified, use a three-phase method for requirements elicitation consisting of the following:

1. Send out a survey questionnaire to each of the stakeholders asking the questions listed by Pfleeger and Atlee (2006) on page 150. The answers to those questions would then be used for the next two phases.

2. Conduct interviews with each of the stakeholders and refer to their answers provided in the questioners.

3. Conduct Joint Application Development (JAD) workshops where groups of stakeholders meet along with a facilitator to brainstorm the necessary requirements for the system (Rosenblatt, 2003).

These JAD workshops would also be used to determine the priorities for requirements and to determine which requirements can be removed from the list.

Draft a requirements document using the results from the above activities. This document would not be complete until the document is accepted by all stakeholders and approved for development activities. Although this process may appear to be time consuming, the results are worth the extra time taken in the requirements gathering phase. The requirements document should be as complete and accurate as possible to help ensure the success of the project.

Bjork, R., C. (1998). Requirements for example ATM system. Available from http://www.math.gordon.edu/courses/cs320/ATM_Example/Requirements.html

Pfleeger, S., L., and Atlee, J., M. (2006). Chapter 4: Capturing the requirements. Software Engineering Theory And Practice (3rd ed.). Upper Saddle River, NJ: Pearson Education, Inc.

Rosenblatt, S., C. (2003). Chapter 2: Analyzing the business case [Electronic version]. Systems Analysis and design (5th ed.). Boston, MA: Course Technology.