ArtsAutosBooksBusinessEducationEntertainmentFamilyFashionFoodGamesGenderHealthHolidaysHomeHubPagesPersonal FinancePetsPoliticsReligionSportsTechnologyTravel

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

Updated on May 16, 2016

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.

Preconditions and Assumptions

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.

High Level Description of Functionality

 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)

Functional Requirements

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.

Data Constraints

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.

Design and Interface Constraints

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.

Quality Requirements

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.

Appendix A: Requirements Gathering

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

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.



    0 of 8192 characters used
    Post Comment
    • profile image


      4 years ago

      could anyone give me an example of a system requirement statement for an atm system?

    • profile image


      6 years ago

      nice article :)

    • profile image


      7 years ago

      good and very nice

    • profile image


      7 years ago

      SRS nicely documented, useful for academic purposes as a sample.

    • profile image


      7 years ago

      check list format for the sample ATM system

    • Dumbledore profile imageAUTHOR

      This Old Guy 

      7 years ago from Somewhere in Ohio

      I did not request an e-mail address, but thanks.

    • Dumbledore profile imageAUTHOR

      This Old Guy 

      7 years ago from Somewhere in Ohio

      I will need to develop the code and I am in the midst of writing assignments for my Ph.D. When I get the chance, I will be happy to work on a little more development.

    • profile image


      7 years ago


    • Dumbledore profile imageAUTHOR

      This Old Guy 

      8 years ago from Somewhere in Ohio

      Thanks to everyone for the comments.

    • profile image


      8 years ago

      very good

    • profile image


      8 years ago

      Good site...

    • Dumbledore profile imageAUTHOR

      This Old Guy 

      8 years ago from Somewhere in Ohio

      What type of "macro" do you propose?

    • profile image


      8 years ago

      Propose a “macro" for ATM


    This website uses cookies

    As a user in the EEA, your approval is needed on a few things. To provide a better website experience, uses cookies (and other similar technologies) and may collect, process, and share personal data. Please choose which areas of our service you consent to our doing so.

    For more information on managing or withdrawing consents and how we handle data, visit our Privacy Policy at:

    Show Details
    HubPages Device IDThis is used to identify particular browsers or devices when the access the service, and is used for security reasons.
    LoginThis is necessary to sign in to the HubPages Service.
    Google RecaptchaThis is used to prevent bots and spam. (Privacy Policy)
    AkismetThis is used to detect comment spam. (Privacy Policy)
    HubPages Google AnalyticsThis is used to provide data on traffic to our website, all personally identifyable data is anonymized. (Privacy Policy)
    HubPages Traffic PixelThis is used to collect data on traffic to articles and other pages on our site. Unless you are signed in to a HubPages account, all personally identifiable information is anonymized.
    Amazon Web ServicesThis is a cloud services platform that we used to host our service. (Privacy Policy)
    CloudflareThis is a cloud CDN service that we use to efficiently deliver files required for our service to operate such as javascript, cascading style sheets, images, and videos. (Privacy Policy)
    Google Hosted LibrariesJavascript software libraries such as jQuery are loaded at endpoints on the or domains, for performance and efficiency reasons. (Privacy Policy)
    Google Custom SearchThis is feature allows you to search the site. (Privacy Policy)
    Google MapsSome articles have Google Maps embedded in them. (Privacy Policy)
    Google ChartsThis is used to display charts and graphs on articles and the author center. (Privacy Policy)
    Google AdSense Host APIThis service allows you to sign up for or associate a Google AdSense account with HubPages, so that you can earn money from ads on your articles. No data is shared unless you engage with this feature. (Privacy Policy)
    Google YouTubeSome articles have YouTube videos embedded in them. (Privacy Policy)
    VimeoSome articles have Vimeo videos embedded in them. (Privacy Policy)
    PaypalThis is used for a registered author who enrolls in the HubPages Earnings program and requests to be paid via PayPal. No data is shared with Paypal unless you engage with this feature. (Privacy Policy)
    Facebook LoginYou can use this to streamline signing up for, or signing in to your Hubpages account. No data is shared with Facebook unless you engage with this feature. (Privacy Policy)
    MavenThis supports the Maven widget and search functionality. (Privacy Policy)
    Google AdSenseThis is an ad network. (Privacy Policy)
    Google DoubleClickGoogle provides ad serving technology and runs an ad network. (Privacy Policy)
    Index ExchangeThis is an ad network. (Privacy Policy)
    SovrnThis is an ad network. (Privacy Policy)
    Facebook AdsThis is an ad network. (Privacy Policy)
    Amazon Unified Ad MarketplaceThis is an ad network. (Privacy Policy)
    AppNexusThis is an ad network. (Privacy Policy)
    OpenxThis is an ad network. (Privacy Policy)
    Rubicon ProjectThis is an ad network. (Privacy Policy)
    TripleLiftThis is an ad network. (Privacy Policy)
    Say MediaWe partner with Say Media to deliver ad campaigns on our sites. (Privacy Policy)
    Remarketing PixelsWe may use remarketing pixels from advertising networks such as Google AdWords, Bing Ads, and Facebook in order to advertise the HubPages Service to people that have visited our sites.
    Conversion Tracking PixelsWe may use conversion tracking pixels from advertising networks such as Google AdWords, Bing Ads, and Facebook in order to identify when an advertisement has successfully resulted in the desired action, such as signing up for the HubPages Service or publishing an article on the HubPages Service.
    Author Google AnalyticsThis is used to provide traffic data and reports to the authors of articles on the HubPages Service. (Privacy Policy)
    ComscoreComScore is a media measurement and analytics company providing marketing data and analytics to enterprises, media and advertising agencies, and publishers. Non-consent will result in ComScore only processing obfuscated personal data. (Privacy Policy)
    Amazon Tracking PixelSome articles display amazon products as part of the Amazon Affiliate program, this pixel provides traffic statistics for those products (Privacy Policy)
    ClickscoThis is a data management platform studying reader behavior (Privacy Policy)