Functional requirements for online banking system

Requirements Management & Engineering

everal phases of the requirements project have now been completed; however,

it will be critical to inform the customer of your requirements management practices and plan.

Additionally, the customer must verify that your team did follow the requirements management standards

implemented by Software Engineering Institute Carnegie Mellon.

In a PowerPoint presentation, provide the following to illustrate the actions taken to implement

requirements management:

Title slide

Topics of Discussion slide

Summary of IEEE Standards used during the requirements

management process (i.e., IEEE Std 1233 – 1998; IEEE Std 830-1998, SEI CMMI)

Introduction and Purpose of Requirements Management (REQM) within CMMI

Goals and Practices used during REQM for your project

Identification of at least 1 Requirements Management tool or software,

which would be used in support of your project at a major corporation

(i.e., DOORs, Requisite Pro, CASE Spec, Open Source RM, CORE)

Use of requirements management to produce metrics

Summary slide

Reference slide in APA format

Each major topic presented from the Summary of the IEEE Standards to the Goals and Practices

used during REQM should have 2–3 sentences of explanation or expansion placed in the speaker notes of

each slide. References must be placed either on the slide or in the speaker notes in APA format.

The overall length of the presentation should be 8–11 slides in Power point

Attachment is history of assignment as of this week

SRS for Online Banking

Connie Farris

Colorado Technical University

Software Requirements Engineering

(CS455-1901B-01)

Dr. Debora Elam

Running head: SRS FOR ONLINE BANKING 3

SRS FOR ONLINE BANKING 3

Revision History
Revision

Date

Name

Description

Initial Revision

02/15/2019

Software Requirement Elicitations

Created the original document for week one

Second Revision

02/23/2019

Software Requirement

Elicitations

Converted to single line and add numbering, double space between sections

Third Revision

02/25/2019

Software Requirements Development

Created sections for week two

Fourth Revision

02/26/2019

Software Requirements Development

Added Traceability Matrix

SRS FOR ONLINE BANKING 3

SRS for Online Banking

Table of Contents

Revision History 2

Software Requirements Elicitation 3

1. Introduction 3

2. Requirements 4

3. Technical Preparation Made Before the Kickoff Meeting 4

4. Skills Needed by the Developer 4

5. Requirements Specification 5

1. Introduction 5

2. References: 02/24/2019 6

3. Overall Description 6

4. Specific Requirements/ Functionality 7

5. Usability 8

6. Reliability 8

7. Performance 9

8. Supportability 9

9. Design Constraints 9

10. License 9

11. Requirement Verification 10

12. Requirements Traceability 10

Traceability Matrix 10

Appendix 11

Testing Specification Development 11

Requirement Management and Engineering 12

Software Engineering Process and Methodologies 13

Software Engineering Processes & Methodologies TBD 15

References: 16

Software Requirements Elicitation
1. Introduction
A local bank that has been in business for about 3 years is losing customers to banks that have more up to date services. They have been operating on a traditional banking system where all transactions must be done person to person. They realize in order to get customers back and to gain new customers they will have to incorporate online banking. They researched information about this subject so they would be able to understand what online banking is about. The information found included:

The first online banking service in United States was introduced, in October 1994. (K, 2019)

Online banking with conventional banks permits clients perform all every day transactions and some offer online loan and credit card applications. ("What is Online Banking? definition and importance", 2019) This would include balance checks and money transfers just to mention a few possibilities that are available with online banking.

With account information available 24/7 and viewed from pc or smartphone. With the growth of online banking, consumers can look forward to larger development of services offered by various banks and financial institution. These improvements will enhance the operations and efficiency of business transactions, resulting in better customer services. (Alfred, Cathy, Peter & Vivian, 2019)

2. Requirements
Also known as requirements gathering, this stage in the requirements development stage involves the collection of system requirements from the stakeholders and will include several techniques to successfully collect the requisite requirements for the project. These will include interviews, brainstorming, and facilitated application specification technique (FAST) among others (Olson, 2014).

The clients would like to develop an online banking platform and as such the meeting will be largely geared towards coming up with requirements that will lead to the development of the product. An online banking solution is one that provides banking customers with the capability to access banking services, information and support from a digital device like a smartphone or a computer.

3. Technical Preparation Made Before the Kickoff Meeting
During the kickoff meeting, the client will outline their basic vision for the project, including what they hope it can accomplish once it is done. For this reason, the team will get prepared to create use case diagrams as well as how to quickly develop a basic prototype for an initial user interface for the online banking solution. The kickoff meeting should establish an initial baseline that should lay the ground for the requirements process.

4. Skills Needed by the Developer
The requirements elicitation process is a normally fraught process, given how it involves two parties trying to agree on a single thing. While ideally the client’s need to be the primary focus, there are times when the developers will find themselves having to disagree with the client, especially if the client’s vision and suggestions are deemed impractical.

The developers will need to develop great communication skills so as essentially act as the guide to the vision of the client. Whenever situations arise, they find themselves in disagreement, it will be the responsibility of the developer to steer back to the right path.

Some of the software elicitation techniques will need a great deal of teamwork, especially between the developer and the client. Hence, the capabilities and skills of successfully working in a team environment will be necessary. The Facilitated Application Specification Technique (FAST) for example is one requiring a team-oriented approach to coming up with the specifications for the project (Olson, 2014).

5. Requirements Specification
After initial interviews and questionnaires, the development team teamed with the client to come up with a requirement outline. The process involved first identifying all the potential stakeholders for the solution, then listing the requirements intended for the product. Next involved sharpening the list by eliminating redundancies and then grouping them according to their importance in the final solution (Olson, 2014).

Among the requirements that were elicited for the online banking solution include the following.

• The ability of a new customer to open an account from the product.

• The capability of a current bank user to access their account and view details on the account like their transaction history, current balance and even receive a bank statement for a specific period.

• The ability for customers of the bank to make transactions from the online solution, including transferring funds to a different account, making deposits to the account, as well as withdrawal from the account to an authorized virtual wallet.

• The customer should be able to receive regular notifications on activities on their account, like receiving money, withdrawals and so forth, to not only promote convenience but also prevent fraud.

Software Requirements Development

1. Introduction
The online banking system is being developed to provide convenience for the bank’s customers and partners. As such, the scope of the project will be to develop a solution capable of delivering the highest quality online banking experience, with an easy to use interface, speedy performance and enough features to justify its selection by customers. This paper focuses on the development of the SRS document used in online banking software and what the development process should and should not entail. In line with the guidelines of SRS development, this document is divided into sections for ease of understanding.

2. References: 02/24/2019
Aljawarneh, S. A. (2017). Emerging Challenges, Security Issues, and Technologies in Online Banking Systems. Online Banking Security Measures and Data Protection (pp. 90-112). IGI Global.

Dauda, S. Y., & Lee, J. (2015). Technology adoption: A conjoint analysis of consumers׳ preference in future online banking services. Information Systems, 53, 1-15

.

Highsmith, J. (2014). Adaptive software development: a collaborative approach to managing complex systems. Addison-Wesley.

Hussain Chandio, F., Irani, Z., Zeki, A. M., Shah, A., & Shah, S. C. (2017). Online Banking Information Systems Acceptance: An Empirical Examination of System Characteristics and Web Security.

Krishnan, M. S. (2015). Software development risk aspects and success frequency on spiral and agile model. International Journal of Innovative research in computer and communication

Engineering, (3),

Olson, D. (2014). Information systems project management. Business Expert Press.

Montazemi, A. R., & Qahri-Saremi, H. (2015). Factors affecting the adoption of online banking: A meta-analytic structural equation modeling study. Information & Management, 52(2), 210-226.

Systems Engineering Verification Process. (2018)Retrieved from http://acqnotes.com/acqn/careerfields/verification-process

Wilke, G., & Portmann, E. (2016). Granular computing as a basis of human–data interaction: a cognitive city use case. Granular Computing, 1(3), 181-197.

3. Overall Description
The bank has been exploring ways it would improve its customer service and make its products and services much more accessible to its customers. With their fast-paced lives, these customers want to be able to access their bank and be readily provided with a wide array of products and services they would have otherwise had to visit the physical branch to access. The online banking services will enable the client to review real-time account activity after client credentials have been approved at sign in for account. The software requirements specification (SRS) gives an in-depth description of how the desired system should work and the process to be followed on the development process. These specifications are modeled based on business requirements also known as the stakeholder requirements. SRS outlines the various functional and non-functional requirements. This approach may also focus on several use cases which extrapolate user interactions that will be employed in the process of software development and the functionalities to be provided. The SRS makes the foundation for an agreement that is to be set between customers of the software product and the contractors mandated to develop the software or the suppliers looked at to deliver the software (Dauda et.al. 2015).

4. Specific Requirements/ Functionality
The following requirements will be developed for the system

1. There shall be the capability to log into the system using unique credentials.

• The users shall be capable of changing their credentials

• The users shall be capable of accessing different services and products within the system

2. • Users shall be capable of accessing their personal account information

• Users shall be capable of reviewing and updating their personal information

3. • Users shall be capable of conducting transactions such as transferring funds to and from their accounts

4. • Users shall be capable of applying for loans from the system as well as check for the progress of the application

5. • Users shall be capable of applying for ATM cards from the system

The system will be simple for the client and will ensure a secure and accurate way to check all accounts at their convenience from any device.

4a. Objectives of the system

1. The development of the online banking software (OBS) will enable the bank to improve its services through the facilitation of the banking process and the tracking of transactions.

2. The online banking software will help the bank to schedule maintenance and accounting processes and it will ensure consistency (Wilke et.al. 2016).

3. This system will also allow the management to analyze their revenues on a daily, weekly and monthly basis. Also, the bank should realize profits by reducing redundancy of work as this system reduces the manual work done by tellers and clerks.

4b. System Context

This software serves as an improvement to the existing manual input methods. As it uses sophisticated software, the program will be fast and reliable to both the customers and the bank. It is easy to use on computers and can be accessed easily from mobile applications by clients from around the globe (Montazemi et.al. 2015).

The online banking software will give the client a chance to interact with the bank through the easy-to-use, intuitive graphical and attractive mobile interfaces. In this project, technology is set to replace the old-fashioned manual methods that have been in use from time immemorial. The software will be developed using the advanced agile software development techniques that require developers to be attentive at every step of development. This is a simplified approach that aims at producing the best software for use by the bank (Krishnan, 2015). The aim of this approach is to have a system that satisfies customers while still making profits for the stakeholders. Upon application of this software, engineers and developers will analyze the functionalities based on customer feedback with an aim of modifying the features and improving the interface.

The tried and true approach is will be applied to state the details of the development. Any arising issues will be addressed in the subsequent meetings. The non-functional requirements should be given priority to enable the proper user-software interaction. All functions will be stored and retrieved from a central database in the bank’s server. The developers should not use real clients in the test, they should instead create virtual clients and apply the various functions in a separate device. This will prevent alteration of the already concealed customer information.

5. Usability
The usability of the online banking system will be determined by how the design team makes choices regarding how easy it will be for the customers to make use of the system. This will include how fast the system responses to requests. The user should be capable of quickly locating whatever service or product they are looking for without much hassle (Olson, 2014). All new users will be required to register by pressing the ‘register’ button on the bank’s main web page. Upon submission of the relevant personal details and account’s details, a profile will be created for the new users. All other features, saving and banking services can be accessed by the registered users in subsequent times by logging into their accounts.

A feature will be developed where a client can make multiple transactions using the ‘open several windows’ button. The buttons should only be available to validated clients with a history of compliance with loan services. Clients will be able to print out their bank statements remotely. The software will be made in a customer friendly approach with easy-to-use interfaces that combine graphical presentations and available reservations

6. Reliability
The mean time between failures (MBTF) is the time that passes between one failure of the system and when the next failure manifests. These metrics indicate how reliable the system is and if it can successfully deliver on functions to its users. To avoid inconveniences to customers who will want to resume access to services as soon as possible, the MTTR will be looked upon to be a maximum of thirty-six hours to accommodate for ample time should it be needed for more complex failures (Highsmith, 2014). The online banking software is a 24 hours service available for the 7 days of the week. All services of the OBS will be provided in real time and information about the state of their account will be rendered when available.

7. Performance
For the system to be useful to the customers, it will need to be capable of high performance, delivering the required speeds to the users of the system. Once a customer has logged into the system, the response time will be about one second from request to fulfilment for navigating the parts of the online banking system to access products and services (Olson, 2014).

8. Supportability
The Admin will have unfettered access to the system, capable of monitoring all activities within the system, and intervene whenever they are needed. They will be responsible for purging users from the system whenever the need arises, analyze the transactions conducted on the system and make regular maintenance tasks. The access granted to the Admin will also allow them to install security and management features that will alert them to security threats as well as management requirements throughout the system (Olson, 2014). The OBS shall have the ability to handle high amounts of data. The system will generate a suitable error message for faulty entries but will not crash. The OBS will have a cloud backup for data recovery purposes (Dauda et.al. 2015).

The online banking software will go a long way into improving business for the bank while ensuring customer satisfaction

9. Design Constraints
1. These constraints will largely appear in users shifting between the use of smartphones to tablets and PC. The change in form factors will mean the loss of some features and system capabilities. As it was initially designed, the system should be best accessible without issues on a PC, with the smaller form factor of smartphones representing the other end of the spectrum.

2. These issues will be solved through continuous improvements made to the system over time (Highsmith, 2014). This OBS has been developed for Microsoft users only. The users of IOS may experience some glitches. The support team is working to make the platform more conversant.

10. License
The setting up of the online platform requires that the international monetary fund and the World Bank as well as the federal Bureau of Financial Regulations among other security and finance agencies such as the Federal Bureau of Investigations be notified. This is in order to monitor and regulate online financial services (Hussain et.al. 2017). The system will be licensing software from various vendors, allowing to access features and requirements that were either too expensive to implement, or required too much focus and attention without being key to the system in a major way.

11. Requirement Verification
Charts, test simulations, and models will be used to discover if the system meets all requirements of the stakeholders and end-users needs. Complete validation must be met before project continues. All customers who wish to subscribe to the online program must be full members of the bank and bearers of a valid account number.

Analysis is the verification of a product or system using models, calculations and testing equipment. Analysis allows someone to make predictive statements about the typical performance of a product or system based on the confirmed test results of a sample set or by combining the outcome of individual tests to conclude something new about the product or system. It is often used to predict the breaking point or failure of a product or system by using nondestructive tests to extrapolate the failure point

12. Requirements Traceability
This process will allocate all requirements for the system and software. They will then be categorized and given codes to distinguish each requirement for easy reference. The software will be simple to use for both the administrator and the users (customers). All transactions will be controlled through a central server that will enable the bounce back for easy local identification and traceability. Some of the major CSCI requirements will be availability, network, transfer speed, hardware, software, interface, server-updates and validation and process.

Traceability Matrix
Code

Functional Requirements

Purpose

3.6

Availability

Accessibility to the framework will be steady contingent upon the system speed of the ISP, and the device being utilized

3.7

Network

This will be the path to the information through the sever of the bank website containing the information.

3.8

Transfer Speed

The exchange speed of the data from the server to the framework to display for the client will be prompt.

3.9

Hardware

The equipment utilized for the framework will be the physical body of the framework and is additionally what will be utilized by the customer to get to the framework from device

3.10

Software

The software in the framework will empower the client to get to various highlights in the framework and the framework by and large. Without both the hardware and programming, the framework won't work

3.11

Interface

The interface will go about as a transport or passage

between the framework and the user for access

3.12

Server-updates

The servers will be refreshed normally to ensure the most recent patches are verified, and new highlights can be actualized

3.13

Validation and Process

The framework won't discharge data until the login qualifications are checked by the server. On the off chance that the qualifications aren't right, the framework will permit 3 attempts before the record is bolted and an email will be sent to confirm the genuine record proprietor was the one making the endeavor to login

Appendix- I will use a casual use case format first and after a fully dressed use case. The casual format is just basic information, while a fully dressed format will address all issues included for this process. Charts and Graphs shall be used to exhibit most of the requirement information, although graphs will be the main source for future references.

Test Specification Development

Testing Specification Development
The system will be under regular testing once it is deployed. These tests are meant to acquire its performance measure, identify errors in the system, identify system security issues, and more in-depth specific functionality tests. The system will be tested on a regular basis to ensure a smooth transition from the old manual method. Additionally, users will be requested to take part in the testing process to help capture the areas that are lacking (Sarah, 2004).

• 1. Accessibility tests- This test for usability, all computer software should be catered for disabled persons, ensure operations are easy to perform (e.g. keyboard shortcuts, visible options for users, smooth navigation etc.).

• 2. Performance testing- Tests conducted to determine the speed at which transactions/ processes are undertaken. Using different devices, the online banking system will be accessed. The optimum speed can be changed when traffic increases gradually.

• 3. Security Testing-This involves several specific testes i.e. penetration testing, risk assessments, ethical hacking, security auditing, and vulnerability scanning. The banking system is especially important software ergo maximum-security frameworks have to be tested on a constant basis.

• 4. System specific testing- With the gradual transition from the old system, the functionalities of the online system will be subjected to specific tests. Components will be closely reviewed e.g. code snippets, departmental task processes, the network of the system, etc. By so doing, the system will be put under constant improvement hence ensuring needs that arise are dealt with.

• 5. Vulnerability tests- The OBS will be subjected to different tests in trying to find out weak points that exist in the system. Reliability of the system will be measured giving the performance level the system should operate at.

It is noteworthy that the system is divided into modules to allow specification testing development. Hereby, the system will allow each specific branch to be isolated from the rest so that interoperability is maintained. The terms for the testing process will be well outlined; system normal average performance will be a standard at any testing period afterward.

The purpose of a specialized testing process is due to the environmental factors e.g. different time zones, hardware variations, dependencies on other different technologies. The testing phase will allow ample preparations for several different scenarios for the online banking system (Duboist et al, 2004).

Requirement Management and Engineering
Once the system has been decided upon, there are changes that are bound to emerge. A requirement management process will be able to plan for, and further, accommodate changes that can come about after its launch. The online banking system will be new to the bank users, ergo if new needs come up, they will be addressed by the development team. The requirement management will develop a plan that identifies areas that need change, involves stakeholders (customer suggestions) in the change analysis, and keep track of all the required attributes. The process will depend on a requirement plan that will entail the documented requirements and a tracing process that keeps tabs on the requirements from the start to the end of the project (Thakur, 2019). Thus, the requirement management will ensure the OBS is up to standards together with saving on costs that would have been spent after it is in use. Areas involved in software requirement management are concerned with functional and non-functional requirements; both apply to both the users and the system. These parts of the project are covered under requirement engineering.

Requirement engineering will be based on requirement elicitation, specification, validation, verification, and management. The process will entail capturing the user and system requirements. The functional requirements are the main events performed by the OBS; they are defined by users and represented by the system as processes, inputs, and outputs. Non-functional requirements are constraints about the system. speed, reliability, and security. Requirement engineering ensures all the objectives listed are satisfied together with an optimum system performance measure being achieved (Omar, 2016). Testing will be based upon the data obtained from requirements engineering.

Software Engineering Process and Methodologies
The OBS is meant to make bank transactions faster, more hands-on, accessible, and serve several customer needs. For this t be accomplished, the system development process needs to regularly incorporate the customers. Testing of the project will be done in a controlled manner that minimizes all risk factors. The development process will employ prototyping, a model that will allow a combination of the system modules to test interoperability. The OBS software prototype will be able to elicit and validate the user requirements hence help in developing more precise objectives. Additionally, the process will be able programmers will be able to generate realistic/ real life system designs depending on the changes brought about by the user interaction. User roles in the system development process will be outlined i.e. programmers, customers, and conditions governing them (Omar, 2017).

The process will follow the standard software development life cycle with a major focus being on requirement analysis, development of the software, and testing. Prototyping will allow for the system to be changed in terms of user requirement refining. The testing and maintenance phase will be a continuous process whereby any part of the system that is found with errors is tackled on time. Also, the system will undergo maintenance that will keep the system up to date with continuous upgrades.

Requirements Management & Engineering TBD

Software Engineering Processes & Methodologies TBD
References:
Alfred, C., Cathy, C., Peter, I., & Vivian, L. (2019). E-Commerce and Online Banking: Transaction Processing. Retrieved from https://cs.uwaterloo.ca/~apidduck/CS330/W04/Seminars/chau.pdf

K, S. (2019). History of Internet Banking. [online] WealthHow. Available at: https://wealthhow.com/history-of-internet-banking [Accessed 15 Feb. 2019].

Olson, D. (2014). Information systems project management. Business Expert Press.

What is Online Banking? definition and meaning. (2019). Retrieved from http://www.investorwords.com/3420/online_banking.html

References used in Unit 2:

Aljawarneh, S. A. (2017). Emerging Challenges, Security Issues, and Technologies in Online Banking Systems. Online Banking Security Measures and Data Protection (pp. 90-112). IGI Global.

Dauda, S. Y., & Lee, J. (2015). Technology adoption: A conjoint analysis of consumers׳ preference in future online banking services. Information Systems, 53, 1-15

.

Highsmith, J. (2014). Adaptive software development: a collaborative approach to managing complex systems. Addison-Wesley.

Hussain Chandio, F., Irani, Z., Zeki, A. M., Shah, A., & Shah, S. C. (2017). Online Banking Information Systems Acceptance: An Empirical Examination of System Characteristics and Web Security.

Krishnan, M. S. (2015). Software development risk aspects and success frequency on spiral and agile model. International Journal of Innovative research in computer and communication

Engineering, (3),

Olson, D. (2014). Information systems project management. Business Expert Press.

Montazemi, A. R., & Qahri-Saremi, H. (2015). Factors affecting the adoption of online banking: A meta-analytic structural equation modeling study. Information & Management, 52(2), 210-226.

Systems Engineering Verification Process. (2018).

Retrieved from http://acqnotes.com/acqnote/careerfields/verification-process

Wilke, G., & Portmann, E. (2016). Granular computing as a basis of human–data interaction: a cognitive city use case. Granular Computing, 1(3), 181-197.