Revision work.
HelloWorld123
SRS-IEEE830-MAllibalogun8.docxSoftware Requirements and Design Specification for online banking system Page 15
Software Requirements Specification
for
Online Banking System
Version 1.0
Prepared by Mohammed Allibalogun
The Solution Software Company
March 28th, 2020
Template only ©1999 by Karl E. Wiegers. Permission is granted to use, modify, and distribute this document. (SRS sections); ©1994-1997 by Bradford D. Appleton. Permission is hereby granted to make and distribute verbatim copies of this document provided the copyright notice and this permission notice are preserved on all copies (SDS sections); Further modified by Drs. Renata Rand McFadden and Sheldon Linker.
Table of Contents
Table of Contents ii
Revision History ii
1. Introduction 1
1.1 Purpose 1
1.2 Document Conventions 1
1.3 Intended Audience and Reading Suggestions 1
1.4 Product Scope 2
1.5 References 2
2. Overall Description 3
2.1 Product Perspective 3
2.2 Product Features 3
2.3 User Classes and Characteristics 3
2.4 Operating Environment 4
2.5.1 Performance Constraints 5
3. System Features 5
3.1 User can trasnfer funds: 5
3.2 View balance 5
4. External Interface Requirements 5
4.1 User Interfaces Overview 5
4.2 Hardware Interfaces 6
4.3 Software Interfaces 6
4.3.1 Validate the User account 6
4.3.2 Account Balance 7
4.3.3 Funds Transfer 8
5. System Features/Modules 9
5.1 Validate User Account: 9
5.1.1 Description and Priority 10
5.2 Able to add beneficiary for funds transfer 10
5.3 Validate Minimum balance for Doing the Transaction 11
5.4 Validate Funds Transfer 12
6. Nonfunctional Requirements 12
6.1 Performance 12
6.2 Security 12
6.3 Adaptability 13
Revision History Comment by Sheldon Linker: Generally, this table should appear on one page if possible. So, put a page break before this.
|
Name |
Date |
Reason for Changes |
Version |
|
Mohammed Allibalogun |
March 29, 2020 |
Initial draft |
1.0 |
|
Mohammed Allibalogun |
April 3, 2020 |
Second draft |
1.1 |
|
Mohammed Allibalogun |
April 7, 2020 |
Third draft |
1.2 |
|
Mohammed Allibalogun |
April 10, 2020 |
Fourth draft |
1.3 |
Software Requirements and Design Specification for <Project> Page iii
Template only ©1999 by Karl E. Wiegers. Permission is granted to use, modify, and distribute this document.(SRS sections); ©1994-1997 by Bradford D. Appleton. Permission is hereby granted to make and distribute verbatim copies of this document provided the copyright notice and this permission notice are preserved on all copies (SDS sections); Further modified by Drs. Renata Rand McFadden and Sheldon Linker.
Introduction
Purpose
The main purpose of this document is to present the extensive details about the online banking system. It will explain the complete description of the system, how the system will work, what will be the features of the system, how the interface of the system would be, what constraints will the system have, and most importantly how the system will deal with the external affairs and stimuli. This document is valid and intended for both the stakeholders and the developers of the system as well. The approval or disapproval authority of this project will be liable by the community of the bank.
Document Conventions
The detailed version of the online banking system is available under the scope and vision document. The other section of the report will include scope and release information of the system.
The document convention is as follows:
· Bold is used as the heading
Intended Audience and Reading Suggestions
The main objective is to prepare a software application which will maintain the data online, provide a user-friendly interface for its users, update and retrieve customer details with 100% accuracy. As the system is a computerized process so it will not consume more time like the traditional system does and helps to cut down the cost for keeping the record.
Product Scope
The scope of the project is to build the online banking system, to enhance the customer experience, the use of technology is one of the most important parts to consider. it helps the customers to manage the transactions online without visiting the bank physically. The online system helps to keep the record of the transactions. The traditional banking method is the old and legacy, it needs to be replaced with the new system to ensure the efficiency and accuracy of the system. The most important thing to be considered is that the system should be quick and reliable.
References
Carte, T. A., Jasperson, J., & Cornelius, M. E. (2006). Integrating ERD and UML Concepts When Teaching Data Modeling. Journal of Information Systems Education, 17(1), 55-64. Retrieved from https://jise.org/Volume17/n1/JISEv17n1p55.html
Coronel, C. (n.d.). Database Systems Design, Implementation and Management. CENGAGE Learning.
M, A. (n.d.). Principles of Effective Visual Communication for Graphical User Interface Design. Science Direct.
Martin Fowler, C. K. (n.d.). UML Distilled: A Brief Guide to the Standard Object Modeling Language. Amazon.
Petrie, H. (n.d.). Tension, what tension? Website accessibility and visual design. ACM.
Toby J. Teorey, D. Y. (n.d.). A logical design methodology for relational databases using the extended entity-relationship model. ACM.
Wang, M. (n.d.). USING UML FOR OBJECT-RELATIONAL DATABASE SYSTEMS DEVELOPMENT: A FRAMEWORK.
Yu, E. (n.d.). Carte, T. A. (n.d.). Integrating ERD and UML Concepts When Teaching Data Modeling. Journal of Information Systems Education. IEEE Xplorer.
“IEEE 830 Template 2.” (n.d.). UMGC. Retrieved on March 29, 2020, from https://learn.umgc.edu/d2l/le/content/444081/viewContent/17941543/View
“IEEE 830 Project Description (Project 2).” (n.d.). UMGC. Retrieved on March 29, 2020, from https://learn.umgc.edu/d2l/le/content/444081/viewContent/17941540/View
Overall Description
Product Perspective
A complete understanding between the traditional banking and online banking system can be understood with the detailed product perspective. The following diagram represents how online banking conducts its daily business activities.
Product Features
The major features of the online banking system are as follows:
· View account Status
· View account Balance
· Transfer Funds
· Request for the account Statement
User Classes and Characteristics
Following are the users who intend to operate the system:
· Customer
· Call Center Staff
· Banking Staff
Customer:
Customer is the one who wants to enable their online banking due to the number of reasons. The customer visits the bank to get the e-banking login details.
Banking Staff:
Banking staff after the necessary verification provides the user with the unique login username and password, the customer will able to access the account using their account based on it. The URL has been provided to the staff to access the system.
Call Center Staff:
The customer wants to get some information regarding the transaction, or about the account, the call center staff has the details of the user account, after the successful verification overcall, the call canter staff will guide the customer about the issue, or how to use the banking online facility.
Operating Environment
The system will be able to operate on the following browsers:
· Microsoft Internet Explorer 10
· Mozilla Firefox
· Google Chrome
· Safari
The system will be hosted over the Linux server, enabled with the Apache webserver. All the firewalls need to be done accordingly.
To access the online banking system, stable internet connection with minimum 3Mbps speed required to access the application and do the needed operation.
Design and Implementation Constraints
Performance constraints:
The system shall fulfill the following constraints:
1. Coding Standards
a. The implementation of predetermining guidelines, best practices and programming style that developers will follow when building the application.
2. Naming Conventions
a. The purpose of implementing a naming convention when coding is to allow any developer to comprehend and understand the source code's scope.
3. Model-View-Controller Structure
a. The architectural pattern that separates an application into three main logical components
4. The response of application within 10 seconds of Input.
a. This is an adequate amount of time to ensure user engagement is persistent.
System Features
User can transfer Funds Comment by Sheldon Linker: This list should parallel the list in §5.
User has the option to send funds to any other accounts by sampling having the other account number.
View Balance
The user has the option to view his bank account balance.
Withdraw Funds
User has the option to withdraw money based on the available balance.
Pay Bills
User has the option to pay bills that are linked to the online bank software.
3.5 Appy for a Loan
Users may be able to instantly apply for a loan.
Login
The system has an interactive user interface that enables the user to log in to the system.
Validate funds transfer
The user can affirm that the transaction being made are authentic.
Report error issue
Add beneficiary feature
This enables the account owner to add beneficiaries of her/his account in the event of his/her demise.
Report error issue
This feature enables the customer to quickly seek help in the event of a fault while interacting with the system
External Interface Requirements
User Interfaces Overview
he system shall be graphical based, the number of the user personas and culture has been kept in mind while designing the user interface of the application. The buttons and clicks have been used to access the interface of the application. The web application will be responsive to number of the screens.
The image depicts that system will be responsive to a number of the screens.
Hardware Interfaces
The ability of the required hardware is as follows:
1. Ability to create the connection
2. Continuous power supply
3. Continuous and stable internet connection
4. Ability to authenticate the users
Software Interfaces
Validate the User Account
SI-1.1: The user will transmit the data along with credentials.
SI-1.2: System validates the user account.
SI-1.3: The customer has been login successful or an error has been identified.
Account Balance
SI-2.1: The user account balance will be displayed after authentication.
SI-2.2: System displays the option of funds Transfer.
SI-2.3: The bank options have been displayed.
Funds Transfer
SI-3.1: Enter the beneficiary account number.
SI-3.2: the system will display the name of the account holder.
SI-3.3: The user enters about the amount to be transferred.
SI-3.4: System will check the balance in the account
SI-3.5: System will transfer the amount of balance available.
System Features/Modules
The primary feature that will be implemented by the application are: Comment by Sheldon Linker: These 3 lines are unneeded, because all of this was handled in §3.
· User Module
· Account Summary Module
Funds Transfer Module Validate User Account: Comment by Sheldon Linker: This appears to be "Validate User Account" and not "Funds Transfer Module".
5.1.1 Description and Priority Comment by Sheldon Linker: You left out the description and priority, showing only what might be a requisite.
The user must have a valid banking account and credentials as well.
5.1.2 Stimulus/Response Sequences
|
Stimulus |
User will need a valid URL address to open the online banking system Comment by Sheldon Linker: "use" or "enter" Comment by Sheldon Linker: Each sentence should get a period. |
|
Response |
The application will display the login page. |
|
Stimulus |
The user will enter valid credentials to log in. |
|
Response |
The application will check for the user credential and the following response can occur: Comment by Sheldon Linker: Each paragraph in this column should have similar formatting. a. The credential provided by the users is verified by the software, which will grant him access. b. The credential does not match and the software will prompt the user to re-enter the right credential. The user will get 3 attempts. If the software can’t validate the user’s information to be correct, it will lock the user out. |
Functional Requirements
REQ-1.1: User runs the URL in the browser, upon doing this the system prompts the user to enter credentials. This includes the name and password. Comment by Sheldon Linker: To make these all line up right, use a tab after the colon instead of spaces. Each requirement should match a stimulus and a response in an S/R pair. If your pairs have alternate paths, that will typically mean alternate requirements. Typically each is in this form: "Upon «some event or user action», the «some component or the system» shall «some responsive action».". DO THIS HERE AND THROUGHOUT.
REQ-1.2: The user then enters both the name and the password and prompts the system to run once again.
REQ-1.3 The system upon the credentials matching the ones in the database, gives users access to the system.
REQ-1.4 If the credentials provided by the user do not match those in the system’s database. The user is prompted once more to try again. This record is logged and store in the database, if the user enters incorrect credentials thrice s/he will be required to provide more details for the system to work.
Able to add beneficiary for funds transfer Comment by Sheldon Linker: This, and much of what follows, seems to be Part I of a monetary transfer. The entire monetary transfer should all be one function.
5.2.1 Description and Priority
To add the beneficiary, it is necessary to have the beneficiary account number
5.2.2 Stimulus/Response Sequences
|
Stimulus |
The user should enter a Valid Account number Comment by Sheldon Linker: This is not where this flow starts. Somehow, the user needs to indicate that we're doing a transfer. This needs to not just be entering a beneficiary, but doing an entire funds transfer sequence. Don't just cover what the user sees, but also what has to happen behind the scenes, such as actually transferring the money. Note that transferring the money will follow one sequence if the other user has an account at the same bank, and a different sequence if the recipient has an account at another bank. Hint: Look up "NACHA". Make this pure stimulus and response. One stimulus should elicit one response. DO THIS HERE AND THROUGHOUT. Each Stimulus needs a Response. |
|
Response |
A) The system will acknowledge the account holder's name. B) the system will prompt the user to enter a valid account number if this first trial did not work. This attempt is only three. |
|
Stimulus |
The user enters invalid account number three times |
|
Response |
The user is requested to provide more details about the account. |
|
Stimulus |
Upon validating the account number, the user is prompted to certify the transfer of money into the beneficiaries account |
|
response Comment by Sheldon Linker: Response |
The user authenticates the transfer of money into the beneficiary’s account. |
|
Stimulus |
The system gives back a message for a successful transfer of funds. b) the system returns an error message with a help feature advising on what step the user should take.
|
5.2.3 Functional Requirements
A valid account number is required.
REQ-2.1: Valid Account#.
Validate Minimum balance for Doing the Transaction
The customer needs to maintain the minimum balance limit for doing the transaction.
5.3.1 Description and Priority
After the successful login, the user needs to do the same transaction or check the balance only, as soon as the welcome page displayed, the balance has been there as a dashboard. If the user wants to do the transaction, he or she needs the balance in their account to do the successful transaction.
5.3.2 Stimulus/Response Sequences
Stimulus: Welcome to Dashboard
Response: The account balance has been displayed
Stimulus: the user selects the beneficial to do the transaction of the utility bills
Response: The bill amount has been displayed
Stimulus: the button with the option pay bill has been displayed if the minimum balance requirement of the user has been met
Response: The bill has been paid.
|
Stimulus |
Welcome to Dashboard |
|
Response |
The user account balance has been displayed |
|
Stimulus |
The user selects the benefits to do the transaction for the utility bills. |
|
Response |
The bill amount has been displayed |
|
Stimulus |
The button with the caption Pay bill has been displayed |
|
Response |
The bill paid if and only if the minimum balance requirement is completed. |
5.3.3 Functional Requirements
The major functional requirement is to do the transaction, for doing the transaction it is necessary that the minimum balance requirement.
REQ-3.1: The user must be log in and the dashboard has been displayed
REQ-3.2: The user must have a minimum balance
REQ-3.3: The user will confirm the payment
Validate Funds Transfer
5.4.1 Description and Priority
After the successful verification of the account holder name, and balance requirement, the system will initiate the process of fund transfer if required.
5.4.2 Stimulus/Response Sequences
|
Stimulus |
Welcome to Dashboard |
|
Response |
The user account balance has been displayed |
|
Stimulus |
Select the Beneficiary |
|
Response |
The bill amount has been displayed |
|
Stimulus |
Enter the amount to transfer |
|
Response |
Funds have been transferred successfully. |
5.4.3 Functional Requirements Comment by Sheldon Linker: There's something wrong with the formatting here.
The major functional requirement is to do the transaction, for doing the transaction it is necessary that the minimum balance requirement.
REQ-3.1: The user must be log in and the dashboard has been displayed
REQ-3.2: The user must have a minimum balance
REQ-3.3: The user will confirm the payment
6. Nonfunctional Requirements
6.1 Performance
NF-1.2: The system shall response to any event within 10 seconds.
6.2 Security
NF-2.1: The system shall not be accessed without authentication
6.3 Adaptability
NF-3.1: The system shall be accessible on chrome and Firefox browser, smart cellular device enabled with the internet
NF-3.2: The system shall check the compatibility before the welcome page displayed. Comment by Sheldon Linker: So what you're talking about is programming errors? Programming errors are not allowed to go into production. You can just drop this requirement.
In the case of incompatibility, this could happen due to designing so much with the styling languages such as CSS leading to incompatibility, major incompatibilities are caused by incorrect scripting. In case of incompatibility, the system needs to be troubleshooted the entire system
Template only ©1999 by Karl E. Wiegers. Permission is granted to use, modify, and distribute this document. (SRS sections); ©1994-1997 by Bradford D. Appleton. Permission is hereby granted to make and distribute verbatim copies of this document provided the copyright notice and this permission notice are preserved on all copies (SDS sections); Further modified by Drs. Renata Rand McFadden and Sheldon Linker.
