0% found this document useful (0 votes)
125 views19 pages

SRS Document of

This document outlines specifications and requirements for software used by a consumer finance firm. It describes the purpose, intended users, features, and operating environment of the software. The software allows users to compare loans, policies, and banking services online and apply for them digitally.
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
125 views19 pages

SRS Document of

This document outlines specifications and requirements for software used by a consumer finance firm. It describes the purpose, intended users, features, and operating environment of the software. The software allows users to compare loans, policies, and banking services online and apply for them digitally.
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 19

Software Requirements

Specification
For
Bank Bazaar.com

Submitted by:
Name : SUDHANSHU KUMAR
REG. NO. : 12311484
ROLL NO. : 55
SECTION : K23SK

Course Code : CSE320


Under the guidance of
Dr. Kanwal Preet Kour

1|Pa ge
Table of Content
1.INTRODUCTION………………………………………………………………………….3
1.1 Purpose…………………………………………………………………………………….3
1.2 Document Conventions……………………………………………………………………………..3
1.3 Intended Audience and Reading Suggestion………………………………………………………….3
1.4 Definitions, Abbreviation……………………………………………………………………………3
1.5 Project Scope……………………………………………………………………………………….6

2. OVERALL DESCRIPTION………………………………………………………………………6
2.1 Product Perspective………………………………………………………………………..6
2.2 Product Features…………………………………………………………………………...7
2.3 User Class And Perspective Characteristics……………………………………………….8
2.4 Operating Environment……………………………………………………………………8
2.5 Design And Implementation Constraint…………………………………………………...9
2.6 Assumption And Dependencies…………………………………………………………...9

3.SPECIFIC REQUIREMENTS…………………………………………………………..10
3.1 Functional Requirements…………………………………………………………………10

4.EXTERNAL INTERFACE REQUIREMENTS………………………………………..12


4.1 User Interface…………………………………………………………………………….12
4.2 Hardware Interface……………………………………………………………………….13

5.OTHER NON-FUNCTIONAL RRQUIREMENTS……………………………………13


5.1 Performance Requirements………………………………………………………………13
5.2 Safety Requirements……………………………………………………………………..13
5.3 Security Requirements…………………………………………………………………...14
5.4 Software Quality Analysis……………………………………………………………….14

6.OTHER REQUIREMENTS……………………………………………………………..15
6.1 Data Base…………………………………………………………………………………15

7.DATA FLOW DIAGRAM……………………………………………………………….16

8.USE CASE DIAGRAM…………………………………………………………………..18

9.TEST CASE……………………………………………………………………………….19

2|Pa ge
1.Introduction
1.1 Purpose
This paper outlines the specifications and requirements for the
software used by the Consumer Finance firm (Bank
Bazaar.com).

1.2 Document Conventions : font: TNR 11

1.3 Intended Audience and Reading Suggestion


The target audience for this document includes all stakeholders,
including customers and developers (designers, testers,
maintainers). It is assumed that the reader is familiar with the
fundamentals of bank transactions, lending services, and
accounts. It's also necessary to understand and be familiar with
UML diagrams.

1.4 Definitions, Abbreviation

1.4.1 Definitions

• Bank
A financial organisation that maintains client accounts and offers cash
cards that permit ATM network access to accounts.

• Bank computer
The bank's computer that connects to both its own cashier
stations and the ATM network. Although a bank may process
accounts through its own internal network of computers, we are
only interested in the computer that communicates with the
network.

3|Pa ge
• Customer
The owner of one or more bank accounts. A customer may be one or
more individuals or businesses; the nature of the correspondence is
unrelated to the issue at hand. A person who has an account at one
bank but not another is regarded as a separate customer.

• Transaction
A single, comprehensive request for actions related to a single
customer's accounts. All we said was that ATMs have to be able to
dispense cash; we didn't say they couldn't print checks or take cash or
checks. While it's not necessary currently, we might also wish to offer
the option to manage many customers' accounts. The various
operations need to be well balanced.

• Loan
A loan is the act of lending money, property, or other material
commodities to another party in exchange for future repayment of the
principal amount plus interest or other financing charges. A loan is
particularly defined as a quantity of money that is expected to be repaid
with interest.

• Insurance
A contract where in an organisation or the government agrees to
guarantee reimbursement for a specific loss, damage, disease, or death
in exchange for the payment of a predetermined premium.

• Cash Card
A customer-issued card that allows access to accounts through an
ATM. Every card has a number and a bank code that are encoded in
line with national credit and cash card standards. Within the
consortium, the bank is uniquely identified by its bank code. The
accounts that the card can access are determined by the card number.
Not every customer's account can be accessed by a card. Although a
4|Pa ge
single consumer is the owner of each cash card, there may be several
copies of the card, so it is important to take into account the potential
of using the same card from multiple machines at once.

• Mutual Fund
a shareholder-funded investment plan that trades in a variety of
professionally managed equities.

1.4.2 Abbreviation
The following abbreviations are used throughout this
document:

• I/p:- user-provided input at the moment of execution.


• o/p:- output displayed on screen;
• u_ name:- username provided at login;
• u_ pass:- password provided during login
• output is returned in the event of a failure (invalid
username or password) or success (authenticated).
• E:- stands for EMI value;
• P:- for principal value;
• R:- for interest rate;
• T:- for time in months;
• SI:- for simple interest; and
• CI:- for compound interest.

1.5 Project Scope


With the programme, you may compare online loans and policies
from many vendors in the market and get the best results. You can
apply online for any form of loan from any vendor with this feature as
well. It provides you with information on the requirements for
eligibility for each service you wish to apply for. It delivers all bank-

5|Pa ge
related information right to your door. The user name and password
that you receive upon online software registration are used by the
programme to identify its customers. It analyses the user-provided IP,
looks for it, and returns the most pertinent information. The
programme must appropriately maintain the record and manage
several requests from the same user.

2. Overall Description

2.1 Product Perspective


The software operates on its own without assistance from any
public or private vendors. It operates using the fundamentals of
data analysis. The World Wide Web serves as the platform's
operating system. When a user queries, the data from the survey
is retrieved, stored in the database, and returned to them.
Software Interface :
The programme runs on web browsers (Chrome, Firefox, Internet
Explorer 9 or above, etc.) and functions on the World Wide Web.
Hardware Interface :
Any computer with an internet connection and installed browser can
use the software.(Browsers: Web applications are run by this
programme.)

User Interfaces Customer :


The consumer user interface should be so easy to use that 99.9% of
new users can receive all the information they need on their own
without help.

Administrator :
The maintainer is in charge of updating the programme with
new features and managing user accounts that already exist.

6|Pa ge
Regular software updates by a maintainer will improve user
happiness.
2.2 Product Features
For optimal results, the software ought to operate around the clock.
Customers are identified by their login and password in the software.
Here, a username can be anything, such as a social media account or a
mobile number. It gathers data regarding different bank services (such
as loans, policies, insurance, and bill payment), sends the transaction
details to the client's bank, and gives the client cash. For their personal
PCs, the software providers supply their own software. Appropriate
security and record-keeping measures are needed for the software. The
programme needs to be able to manage several search requests from
different users at once and handle simultaneous accesses to the same
account.

With regard to consumer preference, the software offers the ability to


compare bank loans, bank policies, investment schemes, etc. It
analyses online reviews, policies, and initiatives from the general
population. It informs you of the eligibility requirements, terms and
conditions for a certain plan, and all the paperwork needed to apply for
any service. It is software that enables hassle-free banking for people
of various backgrounds, anywhere in the world. Even beginners can
use it to learn about all banking procedures.

2.3 User Class and Perspectives Characteristics :


This software has a variety of applications. Price-comparison
websites appear to be prime examples of capitalism. Astute
customers can utilise them to find the greatest offers on lifetime
policies, loans, and insurance. Businesses who sell these kinds
of goods feel compelled to constantly enhance their products
because they are afraid of losing their clientele. However,
current theory and practice indicate that the situation is actually
7|Pa ge
more complicated: comparison websites support and impede
competition at the same time. There's no need to wait in long
lines for your turn.
Users: are just regular people in the community who lack any
specialised training.

Administrators:
Must possess extensive network administration skills in order
to update new system features.

2.4 Operating Environment


The technology, software, and hardware employed ought to
meet the following requirements:

• Maintaining confidentiality
• Differentiating currencies
• Validating users
• Providing search results quickly
• Not being distracting
• Not containing irrelevant content
• Being user-friendly
• Updating frequently
• Being the most secure
• Ensuring that all users have equal access to resources
• Not sharing credentials, and
• Not disclosing search information are all necessary.

2.5 Design and Implementation Constraints

• Login
• Details / Account Session

8|Pa ge
Validate User Account

Verify that the username is typed correctly and that it exists


in the database first. Verify that the username and password
are both genuine and consistent. Verify that they are not
blank.

Validate Account Info

• Check to see whether the account has expired.


• Keep verifying the user's session.

2.6 Assumptions and Dependencies


• Software is impenetrable;
• Hardware is unbreakable;
• Daily transactions are limited (enough paper for receipts);
• Daily comparisons are limited (enough data)
• have sufficient details to allow for product comparisons.

3 . Specific Requirements

3.1 Functional Requirements


This software's functional needs are arranged in a very
straightforward and user-friendly manner. At run time, the
value must be passed. Every procedure is carried out
dynamically.
Functional Requirements 1

>Synopsis: First Screen (Home Screen)


>Input: Choose the parameters from drop-down lists, then

9|Pa ge
search (no login required).
>Processing: Send a request to the backend.
>Result: Show the outcome.
>Lack of authorisation

Functional Requirements 2

>Synopsis: First Screen (Home Screen)


>Input: Type u_pass and u_name.
>Processing: Verify that the password and username you
supplied are correct. If valid, then success; if not, then failure
>Result: Show the outcome.
>Authorization: begins following the customer's entry of the
information

Functional Requirements 3

>Synopsis: Should the outcome be failure


>Result: An error prompt on the home screen.

Functional Requirements 4

>Synopsis: Should the outcome be successful


>Result: Show the user's home screen

Functional Requirements 5

>Synopsis: User interface


>Input: Select the appropriate option by clicking on the
Loans menu (for example, Education loan).
>Result: Related window.

Functional Requirements 6
10 | P a g e
>Screenshot of the Education Loan
>Processing: The user will see all the details based on the
filled-out input after a query is sent at the backend.
>Input: Enter degree, country, course duration, college name,
etc.
>Result: The user receives the loan vendor response.
>Authorization: Verify that all of the fields have been filled
out correctly. If not, ask the user to fill out the form again.

Functional Requirements 7

>Description: Loan screen for two wheels


>Processing: The user will see all the details based on the
filled-in data after a query is launched at the backend.
>Output: The consumer receives a brief explanation of the
two-wheeler loan as well as user reviews. The remaining
characteristics are the same as those of a two-wheeler loan.
The window displays results pertaining to eligibility
requirements, loan comparisons, user details, interest rates,
and public debates about the loan schemes. Home loans, auto
loans, loans for old cars, personal loans, etc.

Functional Requirements 8

>Description: Select Health Insurance after clicking on


Insurance.
>The screen for health insurance will appear.

Functional Requirements 9

>Description: Window for the health screen


>Input: Please enter the members to insure, age, and
11 | P a g e
eligibility check.
>Processing: the query will be examined;
>Output: the outcome will be shown to you.
>Authorization: Every field needs to be filled out.

Functional Requirements 10

>Input: Enter age, nationality, annual income, and


employed/not employed;
>Processing: inquiry will be processed;
>Description: Fixed Deposit screen
>Output: A display of the results of all comparisons will
occur.
>Authorization: Every field needs to be completed.

4. External Interface Requirements

4.1 User Interface


In the event that the system fails, there needs to be an
emergency data backup. Almost all new users should be able to
finish their analysis without any help if the customer user
interface is designed to be intuitive.

• Constant power supply;


• User-friendly;
• Capable of differentiating between currencies;
• Connecting to a bank-end database;
• Capable of receiving input from the user;
• Capable of validating the user

4.2 Hardware Interface

• such as extremes of temperature, etc.;


12 | P a g e
• uninterrupted connections;
• fast data transfer rate

5.Other Non-Functional Requirements

5.1 Performance Requirements

• It must be able to function continuously in challenging


circumstances, such as extreme heat or cold.
• Broken connections
Rapid data transfer rate

5.2 Safety Requirements

>Data needs to be reliable.


>Information needs to be protected from physical threats
such as theft and other crimes.
>The database must adhere to AAA security guidelines.
>Integrity needs to be upheld.
>In the event of a system breakdown, there needs to be
an emergency data backup.
>The database needs to be split up into pieces.
>To prevent hacking, all open protocols and ports need
to be kept closed.
>Redirections shouldn't cause it to react.
>It has to have cache.
>Prevent accidents in the traffic.
>Platform swapping is not permitted.
>The load balancer ought to be present.
>Layered with SSL security.
>Must adhere to the HTTP protocol.
>Web crawlers need to be available for forecasts.
13 | P a g e
>The database needs to be set up correctly.
>Insignificant SQL Injections must not be responded to
by the database.
5.3 Security Requirements

• Users' accessibility is criticised in every manner;


• they are recommended to change their passwords on their
first usage;
• they are encouraged not to share their passwords with
anybody;
• There will be a limit of three attempts to enter the
password.

5.4 Software Quality Analysis


• Availability
• Security
• Maintainability

5.4.1 Availability: The user has to always have access to the


software and all of its resources.

5.4.2Security: The programme needs to be sufficiently safe to


protect user information.

5.4.3 Maintainability: Proper maintenance of the programme


is necessary to prevent user discomfort.

14 | P a g e
6 . Other Requirements

6.1 Data Base


According to the data formats offered by the databases of
various banks, the programme must be able to employ a
variety of data formats. All four characteristics of a database
transaction—atomicity, consistency, isolation, and
durability—should be present in a transaction.

Atomicity
According to this criterion, a transaction must be handled as an
atomic unit, meaning that either all of its operations are carried
out or none at all. A database cannot have a state where a
transaction is left unfinished. States ought to be established
either prior to the transaction's execution or following its
completion, cancellation, or failure.

Consistency
Following any transaction, the database has to stay consistent.
There shouldn't be any negative impact from any transaction on
the database's data. The database must continue to be consistent
even after a transaction has been executed if it was consistent
prior to the transaction's execution.

Durability
Even in the event of a system failure or restart, the database
should be strong enough to retain all of its most recent updates.
The database will include the updated data if a transaction
modifies some data and commits it. The data will be updated
when the system restarts itself if a transaction is committed but
the system crashes before the data can be stored to the disc.

15 | P a g e
Isolation
The property of isolation specifies that every transaction in a
database system that has several concurrent and parallel
executions will be carried out and executed as if it's the only
one in the system. The occurrence of one transaction will not
impact the existence of another.

7.Data Flow Diagram

16 | P a g e
17 | P a g e
8.Use Case Diagram

18 | P a g e
9.Test Case

Project Name: Bank Bazzar


Test Case
Test Case ID: 12311484 Test Designed by: Sudhanshu
Test Priority (Low/Medium/High): Med Test Designed date: 9/04/24
Module Name: login screen Test Executed by: Sudhanshu
Test Title: Verify login with valid username and password Test Execution date: 10/04/24
Description: Testing the Bank Bazzar login module

Pre-conditions: User has valid username and password

Step Test Steps Test Data Expected Result Actual Result Status(Pass/Fail)

1 Entering User- Pop up to enter An error with a message to pass


invaild mails 893.243a correct email again. enter correct email address.

2 Entering User- Should not show error A message to enter their password. pass
vaild mails [email protected] and asks for password.

3 Entering Pass- abc123 Password don’t A message for entering a password pass
Passwords get accepted. more than 8 characters.
Less than 8
characters

4 Entering a Pass- Pop up to enter An error message of password pass


Invalid/ abc@1234 correct password. don’t match for the given user.
wrong
Passwords
5 Entering a user- Display Home Page Redirects the user to the home page. pass
Correct user [email protected]
Name and pass-
Passwords abc@123#

Post-conditions:
User is validated with database and successfully login to account.

19 | P a g e

You might also like