Functional And Non-Functional Requirements For Collin’s ATM

Functional Requirements

The core functional & non-functional requirements of the Collin’s ATM based on the provided details are listed as follows under the following two categories:

Functional Requirements:

The core functional requirements of the system as per the demand has been listed as follows:

Non-active Condition: Under, the scenario an invalid card is inserted, the screen should flash the message in initial display.

System requirement: The core requirement of the system is installation of protocols for information storage and execution process.

Authentication Procedure: In the scenario, when the card is inserted, the ATM card pin should be inserted to validate the card and in the process enter the cash card mode.

Acceptance of card: The system requirement quotes the condition that the card will only be accepted if the serial number & the code of bank are readable in the card. Contrary, if the card is not readable and takes over 5 seconds than the process should be cancelled with an error message flashing on the screen.

Accepting the serial number: The serial number on the card should be identified by the system that it should be stored in core system’s memory. 

Pin request: Successful recognition of the card will generate a screen requesting for the card’s pin and only after its validation can the process.

 Pin processing: In case, wrong pin is entered by the user they will be offered a total of three opportunities to correct their mistake after which the card will be captured by the system. On positive response, the process will proceed.

Transactional queries: After validation of the pin, the user must be enquired about the type of process they wish to proceed with be it withdrawal, deposit or any other.

After transaction: After the desired process of the user is completed, the system will flash a message enquiring about the next step that will ask “whether the user wishes to continue or exit the system”. Finally, whether the user wishes to get a physical receipt will be enquired before completing the process

The non-functional requirements of the system will enquiry about the scalability, durability and other factors that has been listed as follows:

Adaptability: The system should show adaptability that is in dire circumstances (that would not compromise with the security of the system), the system should show adaptability and adopt the change.

Compatibility: The system should be compatible with the already existing infrastructure to avoid any discomfort for the end-user while keeping the purpose understandable. The information collected during the account opening should be compatible with the devised system.

Non-Active Condition

Efficiency: One of the most notable requirement of any system is efficiency and the devised system also demands the same. The system should be capable of fulfilling the end-user demand with suitable output by allowing them to use the available options with ease.

Flexibility: The discussed system should not limit itself to only the transactional operations but also offer other features such as viewing last transactions, mobile accessing, change of pin and others while offering flexibility in the process.

Scalability: The discussed system cannot be changed readily and hence should be capable of standing overloads while fulfilling its purpose. In other words, the system should be capable of delivering its services (such as withdrawal, deposit and others) even, when the traffic for the system is too much to handle.

Security: One of the core requirements of the system is a strong security because, if the system fails in the discussed area it will not only have a short-term side-effect but will also affect the sustainability of the organisation in long-run. Hence, the system should offer reliability and only offer its services when the card is validated through proper authentication.

User interface: The system should offer understandable interface options that is the dialogue boxes & the options should be understandable to the user for execution of the needed command to execute necessary option. The appearance on the screen should also gain the attention of the user instantly so, that they can access the desired option without any hassle.

Usability: As discussed in the section above, the system should offer easy user interface, however that would not be enough as the user would need an easy usability too. The system should be accessible for the users and the outputs must be effective and efficient. The acceptance of card should also be an easy and secure process. A tutorial option should be available for the new users to understand the system.

The following table offers a descriptive detail about the use cases of the proposed system:

Table 1: USE CASE DESCRIPTION

(Source: Created by Author)

Table 2: FULLY DEVELOPED CASE USE

(Source: Created by Author)

The provided diagram is made by making different assumptions. The reason for making assumptions during the development of the class diagram lays on the fact that the offered environment was not sufficient enough. Hence, to proceed with the task in hand assumptions were made which greatly assisted in the creation of the discussed diagram which can be further used to create class diagram of the subject that is the ATM system.

System requirement

The most prominent assumption that was made was regarding to the connection between the ATM and the bank along with the assumption that the bank has the user’s details maintained in their database. The reason for making the discussed assumption lays on the fact that the ATM cannot proceed with its task until and unless it has received the bank details of the user to ensure the validity of the transaction. Hence, to validate the data of the user the discussed assumption about the user data and database along with an electronic connection between the ATM and bank were made.

The following six phases are included in the SDLC (Software development Life Cycle):

1. Collecting And Analysing The Requirements: The discussed phase includes identification and collection of the requirements followed by analysing them to reach a suitable conclusion.
2. Designing: The discussed phase involves identification of the design that satisfies the requirements and is also compatible with the system it is to be installed in.
3. Implementation: The discussed phase involves actualisation of the proposed design that needs to be installed in the subject system and proceed accordingly with the implementation of the design.
4. Testing: In the deemed phase the testing of the designed tool is done to ensure its suitability with the subject system. The testing can be done in a prototype or even in a simulation tool rather than using an actual system for testing.
5. Deployment: After successful testing of the proposed tool, it is installed in the system in the discussed phase.
6. Maintenance: After the tool is installed in the system, periodical maintenance should be done to ensure proper operation of the system and even avoid lagging or faults in the system during overload or any other dire situation.

ATMs (Automated teller machine also goes by the name of alternative delivery channel because it offers alternative of banking process while delivering a pre-designated set of services and acting as a channel for the user and the banking services offered by the bank.

The proposed application would contain a front end that would be connected to the internet for collecting data of the user from the internet because the ATMs does not contain any database to store the information of the user rather it collects it from bank when needed.

It is one of the crucial factors as UI (user interface) decides the comfortability that the user will enjoy while using the system. Hence, the UI should be designed appropriately so that the user can perform system operations efficiently and in the process receive effective response from the system.

As stated above, the system does not contain any database and collects data from the bank via internet when needed.

The software method should be easy and secure to offer comfortability and security at the same instance.

Bahill, A. T., & Madni, A. M. (2017). Discovering system requirements. In Tradeoff Decisions in System Design (pp. 373-457). Springer, Cham.

Bernardi, S., Flammini, F., Marrone, S., Mazzocca, N., Merseguer, J., Nardone, R., & Vittorini, V. (2013). Enabling the usage of UML in the verification of railway systems: the DAM-rail approach. Reliability Engineering & System Safety, 120, 112-126.

Cabot, J., Clarisó, R., & Riera, D. (2014). On the verification of UML/OCL class diagrams using constraint programming. Journal of Systems and Software, 93, 1-23.

Cunha, A., Garis, A., & Riesco, D. (2015). Translating between Alloy specifications and UML class diagrams annotated with OCL. Software & Systems Modeling, 14(1), 5-25.

De Gramatica, M., Labunets, K., Massacci, F., Paci, F., & Tedeschi, A. (2015, March). The role of catalogues of threats and security controls in security risk assessment: an empirical study with ATM professionals. In International Working Conference on Requirements Engineering: Foundation for Software Quality (pp. 98-114). Springer, Cham.

Dennis, A., Wixom, B. H., & Tegarden, D. (2015). Systems analysis and design: An object-oriented approach with UML. John wiley & sons.

Halim, A. (2013, November). Predict fault-prone classes using the complexity of UML class diagram. In Computer, Control, Informatics and Its Applications (IC3INA), 2013 International Conference on (pp. 289-294). IEEE.

Johnston, S. K., & Nally, M. P. (2015). U.S. Patent No. 9,122,422. Washington, DC: U.S. Patent and Trademark Office.

Karasneh, B., & Chaudron, M. R. (2013, October). Online Img2UML Repository: An Online Repository for UML Models. In [email protected] MoDELS (pp. 61-66).

Khan, P. M., & Beg, M. M. (2014). Measuring Cost of Quality (CoQ) on SDLC Projects is indispensible for effective software quality assurance. arXiv preprint arXiv:1405.4824.

Kumar, N., Zadgaonkar, A. S., & Shukla, A. (2013). Evolving a new software development life cycle model SDLC-2013 with client satisfaction. International Journal of Soft Computing and Engineering (IJSCE), 3(1), 2231-2307.

Mahalakshmi, M., & Sundararajan, M. (2013). Traditional SDLC Vs Scrum Methodology–A Comparative Study. International Journal of Emerging Technology and Advanced Engineering, 3(6), 192-196.

Montefusco, P., Casar, R., Stelkens-Kobsch, T. H., & Koelle, R. (2016). Addressing security in the ATM environment.

Sagar, V. B. R. V., & Abirami, S. (2014). Conceptual modeling of natural language functional requirements. Journal of Systems and Software, 88, 25-41.

Stikkolorum, D. R., Ho-Quang, T., & Chaudron, M. R. (2015, August). Revealing Students’ UML Class Diagram Modelling Strategies with WebUML and LogViz. In Software Engineering and Advanced Applications (SEAA), 2015 41st Euromicro Conference on (pp. 275-279). IEEE.

Störrle, H. (2013). Towards clone detection in UML domain models. Software & Systems Modeling, 12(2), 307-329.

Order an Essay Now & Get These Features For Free:

Turnitin Report

Formatting

Title Page

Citation

Outline

Place an Order