Sunteți pe pagina 1din 5

Chapter 6 SRS

Chapter Overview
This chapter consists of the data analyses in the previous chapter; the information
gathered from the chapter 2 and identified the requirements for the solution of
Online Banking System. Gathered requirements are classified as functional
requirements and non-functional requirements to identify certain features and
services OBS proposed solution. A use case diagram is used to view the high-level
view of the functionalities in the OBS. Use case descriptions are used to deliver an
in-depth detail about the diagram represents.

Stakeholder Analysis

Functional Requirements
Due to the limitations of time and resources each needs identified in the elicitation
process requirements may not be able to implement what these identified
requirements are prioritized in order of importance level of this requirement.
Functional Requirements are priorities according to the MoSCoW law. The following
table will shows the description of it.

Priority Level
Must have

Description
Defines a requirement that has to be satisfied for the final
solution to be acceptable.

Should have

This is a high-priority requirement that should be included if


possible, within the delivery time frame. Workarounds may
be available for such requirements and they are not usually
considered as time-critical or must-haves.

Could have

This is a desirable or nice-to-have requirement but the


solution will still be accepted if the functionality is not
included

Would have

This represents a requirement that stakeholders want to


have, but have agreed will not be implemented in the
current version of the system. That is, they have decided it
will be postponed till the next round of developments

Functional
Requirem
ent No
FR 1

Functional Requirements Description

The user shall be able to log in to the system by;


1
2

FR2

Priorit
y
M

Entering a valid user name


Entering a valid password

The web site should provide an admin panel for web


administrator to complete the functions of ;

2.1 Add user to the system


2.2 Modify user in the system
2.3 Delete user from the system
Fr3

Administrator shall be able to update user transaction


details of ;

3.1 Newly approved loan amounts,


3.2 Due loan amounts
3.3 Newly approved credit cards limits
FR4

User shall be able to apply through online for;

4.1 Different kind of credit cards


4.2 Different kind of loans
4.3 Open different kind of accounts

FR5

The user must be logged into the system to conduct any


kind of these operations
The system shall allow users to :

5.1 View details of the bank accounts


5.2 View details of the loans modules
5.3 View details of the credit cards

FR6

The user must be logged into the system to continue any


kind of these operations
The system shall allow users to ;
6.1 Upload documents to the system when applying for a
new bank account.

6.2 Upload documents to the system when applying for a


new loan.
6.3 Upload documents to the system when applying for new
credit card.

FR7

FR8

FR9

The user must be logged into the system to continue any


kind of these operations
The system shall allow users to download ;
7.1 Monthly bank account statement or for a specific
period
7.2 All the applications of online banking modules
7.3 The user must be logged into the system to conduct
any kind of these operations
According to the user authorizations system shall be able to
manage the views of the pages.
The system shall allow customers to view and edit details of ;
8.1
8.2
8.3
8.4
8.5

FR10
FR 11

Customer name
Address
e- mail
contact numbers
Passwords

The user must be logged into the system to continue any


kind of these operations
The system shall allow users to connect to a live chat to
solve any problem occurred when engaged in online banking.
The system shall allow users to ;

S
M

11.1 Transfer money within two or more accounts


11.2 Pay utility bills online
11.3 Make requests for pay in future or for a specific period

FR12
FR13

The user must be logged into the system to continue any


kind of these operations
The system shall allow users to cancel future requests
If un-matching usernames and passwords are used for more
than three times, user shall be able to blocked and send an
e-mail for the registered user.

M
C

Non Functional Requirement


Type
Accessibility

NFR No
NFR1

Description
User must be able to login to the system at any
time at 365 days

NFR2

User must be able to login to his/her account in


the system from any country

NFR3

System should take less than 4 seconds to load


any page

NFR4

System should take less than 8 seconds to


process any transaction

NFR5

System should take less than 13 seconds to


generate any report after customer has
requested

NFR6

System should be access to use 1000000 users


at the same time

Database
Requirement

NFR7

When a user request for transaction data all the


data related to the given criteria should be
fetched from the data base

Reliability

NFR8

The system maximum downtime should not be


more than 30 minutes

Security

NFR9

The system should block the user after 3 login


failures

NFR10

System must be take backups in every process


going through the system

Performance

Interface

NFR11

System should be protecting through a firewall


anytime at 365 days

NFR12

The website should be able to fit different screen


size of the device

NFR13

Customer should be able to find contact details


from any of the web page

S-ar putea să vă placă și