EN20CS304014 ARCHIT JAIN OBJECT ORIENTED ANALYSIS & DESIGN

Experiment 1
EN20CS304014 ARCHIT JAIN OBJECT ORIENTED ANALYSIS & DESIGN

Experiment 2
What Is Requirements Analysis?
Requirements analysis or requirements engineering is a process used to determine the needs
and expectations of a new product. It involves frequent communication with
the stakeholders and end-users of the product to define expectations, resolve conflicts, and
document all the key requirements.

One of the greatest challenges faced by any organization is to share the vision of the final
product with the customers. Hence, a business requirements analysis involves a team effort of
all the key stakeholders, software developers, end-users, and customer managers to achieve a
shared understanding of what the product should do. This is always done in the early phase of
any project to ensure that the final product conforms to all the requirements.

Requirements Analysis Process

A requirements analysis process involves the following steps:

Step 1: Identify Key Stakeholders and End-Users

The first step of the requirements analysis process is to identify key stakeholders who are the
main sponsors of the project. They will have the final say on what should be included in
the scope of the project. 

Next, identify the end-users of the product. Since the product is intended to satisfy their
needs, their inputs are equally important. 

Step 2: Capture Requirements

Ask each of the stakeholders and end-users their requirements for the new product. Here are
some requirements analysis techniques that you can use to capture requirements:

1. Hold One-on-One Interviews

Interview each stakeholder and end-user individually. This technique will help you gather
specific requirements.

2. Use Focus Groups

Conduct group interviews or group workshops to understand the flow of information between
different stakeholders and end-users. This technique will ensure that there will be no conflict
of interest later on during the project.
EN20CS304014 ARCHIT JAIN OBJECT ORIENTED ANALYSIS & DESIGN

3. Utilize Use Cases

Use cases provide a walkthrough of the entire product through the eyes of the end-user. This
technique will help visualize how the product will actually work.

4. Build Prototypes

A prototype provides users a sample look and feel of the final product. This technique will
help address feasibility issues and identify problems ahead of time.

Step 3: Categorize Requirements

Since requirements can be of various types, they should be grouped to avoid confusion.
Requirements are usually divided into four categories:

 Functional Requirements - Functions the product is required to perform.

 Technical Requirements - Technical issues to be considered for the successful

 Transitional Requirements - Steps required to implement a new product smoothly.

 Operational Requirements - Operations to be carried out in the backend for proper

Step 4: Interpret and Record Requirements

Once the requirements are categorized, determine which requirements are actually achievable
and document each one of them. Here are some techniques to analyze and interpret
requirements:

Define Requirements Precisely

Ensure that the requirements are clearly worded, sufficiently detailed, and related to business
needs.

Prioritize Requirements

Prioritize requirements and list them out based on which ones are the “most critical” and
which ones are just “nice-to-have”.

Carry Out an Impact Analysis

Carry out an impact analysis to make sure that you fully understand the consequences of the
requirements.
EN20CS304014 ARCHIT JAIN OBJECT ORIENTED ANALYSIS & DESIGN

Resolve Conflicts

Arrange a meeting with key stakeholders and resolve conflicting requirements. You can also
perform a scenario analysis to explore how the requirements would work for different
possible scenarios.

Analyze Feasibility

Perform a detailed analysis of the product based on the requirements gathered to determine its
reliability and to identify any major problems.

Once all the requirements are analysed , create a detailed written document and circulate it
among the key stakeholders, end-users and development teams.

Step 5: Sign off

Once a final decision is made on the requirements, ensure that you get a signed agreement
from the key stakeholders. This is done to ensure that there are no changes or uncontrolled
growth in the scope of the project.

SRS DOCUMENT OF BANKING MANAGEMENT SYSTEM

1. INTRODUCTION

This document gives detailed functional and non functional requirements for the bank
management system. This product will support online banking transaction. The purpose of
this document is that the requirements mentioned in it should be utilized by software
developer to implement the system.

1.1 Purpose

Online banking system provides is specifically developed for internet banking for Balance
Enquiry, Funds Transfer to another account in the same bank, Request for cheque
book/change of address/stop payment of cheques, Mini statements (Viewing Monthly and
annual statements).The Traditional way of maintaining details of a user in a bank was to enter
the details and record them. Every time the user need to perform some transactions he has to
go to bank and perform the necessary actions, which may not be so feasible all the time. It
may be a hard-hitting task for the users and the bankers too. The project gives real life
understanding of Internet banking and activities performed by various roles in the supply
chain. Here, we provide an automation for banking system through Internet. Internet banking
EN20CS304014 ARCHIT JAIN OBJECT ORIENTED ANALYSIS & DESIGN

system project captures activities performed by different roles in real life banking which
provides enhanced techniques for maintaining the required information up-to-date, which
results in efficiency. The project gives real life understanding of Internet banking and
activities performed by various roles in the supply chain.

1.2 Scope

This Product will automate of banking transaction process. This Project investigates the entry
threshold for providing a new transaction service channel via the real options approach,
where the entry there hold is established by using an Internet banking system designed for the
use of normal users(individuals), Industrialists, Entrepreneurs, Educational
Institutions(Financial sections),Organizations and Academicians under transaction rate
uncertainty.

2.General description
2.1 Product Perspective:

The client will have client interface in which he can interact with the banking sys- tem. It is a
web based interface which will be the web page of the banking application. Starting a page is
displayed asking the type of customer he is whether ordinary or a corporate customer. Then
the page is redirected to login page where the user can enter the login details. If the login
particulars are valid then the user is taken to a home page where he has the entire transaction
list that he can perform with the bank. All the above activities come under the client interface.
The administrator will have an administrative interface which is a GUI so that he can view
the entire system. He will also have a login page where he can enter the login particulars so
that he can perform all his actions. This administrative interface provides

different environment such that he can maintain data- base & provide backups for the
information in the database. He can register the users by providing them with username,
password & by creating account in the database. He can view the cheque book request &
perform action to issue the cheque books to the clients.

2.2 Software Interface

Front End Client: The system is a web based application clients are requiring using modern
web browser such as Mozilla Firefox 1.5, PHP.

Web Server: The web application will be hosted on one of the apache server.

Back End: We use backend as MY SQL.

3. Functional Specifications

This section provides the functional overview of the product. The project will require the
PHP as a front end and at the back end the database MYSQL will be running. Various
functional modules that can be implemented by the product will be

1. Login
EN20CS304014 ARCHIT JAIN OBJECT ORIENTED ANALYSIS & DESIGN

2. Validation

3. Get balance information

4. Withdrawal of money

5. Transfer Money

6. Customer info.

3.1 Login:

Customer logins by entering customer name & a login pin.

3.2 Validation:

When a customer enters the ATM card, its validity must be ensured. Then customer is
allowed to enter the valid PIN. The validation can before following conditions

Validation for lost or stolen card When card is already reported as lost or stolen then the
message “Lost/Stolen card!!!”.

Validation for card’s expiry date If the card inserted by the customer has crossed the expiry
date then the system will prompt “Expired Card”.

Validation for PIN After validating the card, the validity of PIN must be ensured. If he/she
fails to enter valid code for three times then the card will not be returned to him. That means
the account can be locked. The counter for number of logins must be maintained Get balance
information. This system must be networked to the bank’s computer. The updated database of
every customer is maintained with bank. Hence the balance information of every account is
available in the database and can be displayed to the customer.

3.3 Payment of Money:

A customer is allowed to enter the amount which he/she wishes to withdraw. If the entered
amount is less than the available balance and if after withdraw if the minimum required
balance is maintained then allow the transaction.

3.4 Transfer of Money:

The customer can deposit or transfer the desired amount of money.

3.5 Transaction Report:

The bank statement showing credit and debit information of corresponding account must be
printed by the machine.

3.6 Technical Issues

This product will work on client-server architecture. It will require an internet server and
which will be able to run PHP applications. The product should support some commonly
used browsers such as Internet Explorer, Mozilla Firefox.

4. Interface Requirements
4.1 GUI

This is interface must be highly intuitive or interactive because there will not be an assistance
for the user who is operating the System. At most of the places help desk should be provided
for users convenience. The screens appearing should be designed in such a manner that it can
draw User attaraction towards the new plans for the customers. Also the pin and password
confidentiality should be maintained, This can be done by using asterisks at the password
panel. Proper security messages should be displayed at most of the places.

4.2 Hardware Interface

Various interfaces for the product could be1. Touch screen/Monitor 2. Keypad3. Continuous
battery backup4. Printer which can produce the hard copy.5. Interface that connects the
device to bank’s computer.6. An interface that can count currency notes.

4.3 Software Interface

1. Any windows operating system.

2. The PHP must be installed. For the database handling MYSQL must be installed. These
products are open source products.

3. The final application must be packaged in a set up program, so that the products can be
easily installed on machines. This application must be networked to corresponding banks.

5. Performance Requirements
The system should be compatible enough to hold the general traffic. It should not get hang or
show some other problems arising out due to large no of concurrent users. The system should
be fast enough to meet the customer The high and low temperature should not affect the
performance of the device. An uninterrupted transaction must be performed.

6. Constraints
* The information of all the users must be stored in a database that is accessible by the Online
Banking System.

* The Online Banking System is connected to the computer and is running all 24hours a day.

* The users access the Online Banking System from any computer that has Internet browsing
capabilities and an Internet connection.
EN20CS304014 ARCHIT JAIN OBJECT ORIENTED ANALYSIS & DESIGN

*The users must have their correct usernames and passwords to enter into the Online Banking
System.

Design Constraints:

* Software Language Used

The languages that shall be used for coding Online Banking System are c ,c++ , java , and
HTML. For working on the coding phase of the Online job portal System Web Sphere
Application Server/WebSphere Application Server CE Server needs to be installed.

*Database design

In our database design, we give names to data flows, processes and data stores. Although the
names are descriptive of data, they do not give details .So following DFD, our interest is to
build some details of the contents of data flows, processes and data store. A data dictionary is
a structured repository of data about data .It is a set of rigorous definitions of all DFD data
elements and data structures .

7. Performance
7.1 Security

The banking system must be fully accessible to only authentic user. It should require pin for
entry to a new environment.

7.2 Reliability

The application should be highly reliable and it should generate all the updated information in
correct order.

7.3 Availability

Any information about the account should be quickly available from any computer to the
authorized user. The previously visited customer’s data must not be cleared.

7.4 Maintainability

The application should be maintainable in such a manner that if any new requirement occurs
then it should be easily incorporated in an individual module.

7.5 Portability

The application should be portable on any windows based system. It should not be machine
specific
EN20CS304014 ARCHIT JAIN OBJECT ORIENTED ANALYSIS & DESIGN