Software Requirements Specification

for
ONLINE BANKING Version <X.X>

Prepared by

Group Name: BANKING

Jayagopi J Ruban kumar T Gutam Nagarjun 2009103546 20084293 2009103537

Instructor: Course: Domain: Date:

<Leave blank> <place your course name here> <place your domain here> <place the date of submission here>

Contents
1 INTRODUCTION...........................................................................................................................................................1

Software Requirements Specification for <Project>

Page ii

2 OVERALL DESCRIPTION..........................................................................................................................................4 FOLLOWING IS THE CONTEXT OR ORIGIN OF ONLINE BANKING SYSTEM. COMPARISON B/W THE TRADITION SYSTEM AND THE NEW SYSTEM CAN ALSO BE CLEARED THROUGH THE SYSTEM MODELS.................................................................................................................................................4 IN TRADITIONAL SYSTEM, CUSTOMER SHOULD HAVE TO VISIT THE BANK BRANCH PHYSICALLY FOR THE TRANSACTIONS OR SOME OTHER TASK. ..........................................................4 AFTER IMPLEMENTING THE ONLINE BANKING SYSTEM CUSTOMER WILL BE ABLE TO CONNECT TO HIS ACCOUNT THROUGH THE INTERNET CONNECTION. TIME USAGE WILL BE MINIMIZED, TASK WILL BE DONE FAST INSTEAD OF WAITING SOMEONE OTHER TO COMPLETE HIS TASK...................................................................................................................................................4 3 SPECIFIC REQUIREMENTS.....................................................................................................................................7 4 OTHER NON-FUNCTIONAL REQUIREMENTS...............................................................................................10 5 OTHER REQUIREMENTS.......................................................................................................................................11

Software Requirements Specification for <Project>

Page 1

1 Introduction
1.1 Document Purpose
The p u r p o s e o f t h i s d o c u m e n t i s t o p r e s e n t a d e t a i l e d d e s c r i p t i o n o f t h e Online Banking System. It will explain the purpose and features of the system, the interfaces of the system, what the system will do, the constraints under which it must operate and how the system will react to external stimuli. This document is intended for both the stakeholders and the developers of the system and will be liable for the approval or disapproval of the project by the community of the Bank.

1.2 Product Scope

An online banking system will be applicable everywhere, where banking exists. It will be more efficient and easier way to have a record on systems through w h i c h e v e r y o n e c a n e a s i l y a c c e s s i t a c c o r d i n g t o h i s r i g h t s a s c o m p a r e d t o t h e traditional banking system. Every bank will prefer the online banking system instead of the traditional banking system as it contains many useful features and fastest methods for the transactions

1.3 Intended Audience and Document Overview

<Describe the different types of reader that the document is intended for, such as developers, project managers, marketing staff, users, testers, and documentation writers (In your case it would probably be the client and the professor). Describe what the rest of this SRS contains and how it is organized. Suggest a sequence for reading the document, beginning with the overview sections and proceeding through the sections that are most pertinent to each reader type.>

1.4 Definitions, Acronyms and Abbreviations

SQL server structured query language for database purposes. Used to define procedures to store and retrieve data. User - a lay person who needs the system to do his task efficiently and effectively. An account holder or a banks website visitor. Databasecollection of all the information monitored by the system.

PHP- PHP hypertext pre-processor, a server side scripting language is used to connect the html with the sql databases. Credit cardcredit holding cards, Buy everything and pay from the credit cards. These cards are of each bank and ensure that the person has an account and balance in the specific bank of which he holds the card.

Software Requirements Specification for <Project>

Page 2

Account teller-bank staff that provides information about an account to the user who visits the bank branch physically. Computer systems- computers, which will be used as clients to access the server database according to its right. Visitoranyone visiting the site

Bank features- all the benefits and characteristics that bank provide.These features will be explained to the new corner visiting the website without an account. Administrator- A person that will be responsible for the addition and deletion of the staff members from the general database of the system.. Software requirements specificationA document that completely describes all of the functions of a proposed system and the constraints under which it must operate. Stake holderAny person with an interest in theproject who is not a developer

1.5 Document Conventions

<In general this document follows the IEEE formatting requirements. Use Arial font size 11, or 12 throughout the document for text. Use italics for comments. Document text should be single spaced and maintain the 1 margins found in this template. For Section and Subsection titles please follow the template. TO DO: Describe any standards or typographical conventions that were followed when writing this SRS, such as fonts or highlighting that have special significance. Sometimes, it is useful to divide this section to several sections, e.g., Formatting Conventions, Naming Conventions, etc.>

1.6 References and Acknowledgments

<List any other documents or Web addresses to which this SRS refers. These may include user interface style guides, contracts, standards, system requirements specifications, use case documents, or a vision and scope document. TO DO: Use the standard IEEE citation guide for this section. An example citation guide is posted for you on the website.>

Software Requirements Specification for <Project>

Page 3

Software Requirements Specification for <Project>

Page 4

2 Overall Description
2.1 Product Perspective

Following is the context or origin of online banking system. Comparison b/w the Tradition system and the new system can also be cleared through the system models.

In traditional system, customer should have to visit the Bank branch physically for the transactions or some other task.

After implementing the online banking system customer will be able to connect to his account through the internet connection. Time usage will be minimized, task will be done fast instead of waiting someone other to complete his task.

2.2 Product Functionality

This software will have following functionalities 1) Online balance check and transaction information: Customer will be able to check his balance online while sitting at home by accessing the database of the bank using his/her username and pin-code allotted him by the bank. 2) Save or view up to 1 year past history of transaction: I t w i l l b e e a s y f o r t h e c u s t o m e r t o v i e w o r s a v e h i s h i s t o r y transactions up to past 1year transactions. It will provide him the opportunity to maintain his bank balance and needs. 3) Balance transfer: This system will provide a path to the customer of the bank tot r a n s f e r h i s balance to other account in easy steps. A small transfer fee will b e applicable for this transaction. 4) Online record Entry: Bank staff will input and maintain their record online. It will beeasy and efficient for them to serve more and more people in less time 5) Online record search:

Software Requirements Specification for <Project>

Page 5

Bank staff will easily search a record and update it if needed.Transactions will be faster even physically from the branch because it will be verye a s y f o r t h e b a n k s t a f f t o c h e c k t h e b a l a n c e o f a s p e c i f i c p e r s o n a n d u p d a t e i t s record if necessary. 6) Online Billing Option: Customers will be able to shop online and pay the bills fromtheir account. A secure way will be provided for the billing. Online shopping willprovide them the easiest way to buy and sell their items. 7) Check book Allotment: If the customers checks have been completed, a new checkbook will be allotted to him

2.3 Users and Characteristics 2.4 Operating Environment

<Describe the environment in which the software will operate, including the hardware platform, operating system and versions, and any other software components or applications with which it must peacefully coexist. In this part, make sure to include a simple diagram that shows the major components of the overall system, subsystem interconnections, and external interface TO DO: As stated above, in at least one paragraph, describe the environment your system will have to operate in. Make sure to include the minimum platform requirements for your system. >

2.5 Design and Implementation Constraints

Generals Constraints: Some general constraints should be defined which willhave a great part in the overall succession of the online banking project. a) Hardware Requirements: As this system is an online Web-based application so a client server will be the most suitable Organizational style for this system.Computer systems will be needed by each of the actor as well as that usermust be connected to the internet.So, concisely following hardware will be needed.1) Computer systems2) Internet availability b) Safety and Security: This Project must be safe and secure because customers will directly contact their account through the internet. Software will have to identify the valid customer according to his/her bank details and password. So it is a difficult task to prevent the system by major disasters bypreventing the unauthorized access to the system. Performance constraints:

Software Requirements Specification for <Project>

Page 6

This system must be fit according to the performance wise. It should use less memory and will be easily accessible by the user. Memory management should be done wisely so that none of the memory part goes wasted. Hardware limitations: It should be designed in such a way that cheap hardware must be installed to access and use it effectively. It should be platform independent. There s h o u l d be no hardware limitations. In should be designed to work with the low specification hardware so that it could easily work with the high specifica t i o n hardware. Maintainable: Each of the modules should be designed in such a way that a newmodule can easily be integrated with it.

2.6 User Documentation

<List the user documentation components (such as user manuals, on-line help, and tutorials) that will be delivered along with the software. Identify any known user documentation delivery formats or standards. TO DO: You will not actually develop any user-manuals, but you need to describe what kind of manuals and what kind of help is needed for the software you will be developing. One paragraph should be sufficient for this section.>

2.7 Assumptions and Dependencies

Following are the assumptions and dependencies which are related to this online banking project. 1)This project is a stand-alone project so it will not affect t h e system where it will be embedded. 2 ) T h i s p r o j e c t i s a w e b - b a s e d p r o j e c t w h i l e t h e s t a f f w a s addict of using traditional method s o f d a t a s t o r a g e a n d retrieval so they will be trained a bit to jump to it. 3)This system will not depend on any other module. It will b e a web-based so every one will independently contact it. 4)It is will not affect the environment at all. 5 ) B a n k s w i l l f e e l f r e e t o a d o p t i t b e c a u s e i t w i l l n o t b e s o much expensive. 6)As this project contains valuable and new features so it willp r o b a b l y r e m o v e t h e p r e v i o u s o n l i n e b a n k i n g s y s t e m s embedded in some banks.

Software Requirements Specification for <Project>

Page 7

3 Specific Requirements
3.1 External Interface Requirements
3.1.1 User Interfaces
<Describe the logical characteristics of each interface between the software product and the users. This may include sample screen images, any GUI standards or product family style guides that are to be followed, screen layout constraints, standard buttons and functions (e.g., Cancel) that will appear on every screen, error message display standards, and so on. Define the software components for which a user interface is needed. TO DO: The least you can do for this section is to describe in words the different User Interfaces and the different screens that will be available to the user. Those who will be able to provide optional Graphical User Interface screenshots, will be rewarded by extra marks.>

3.1.2 Hardware Interfaces

<Describe the logical and physical characteristics of each interface between the software product and the hardware components of the system. This may include the supported device types, the nature of the data and control interactions between the software and the hardware. You are not required to specify what protocols you will be using to communicate with the hardware, but it will be usually included in this part as well. TO DO: Please provide a short description of the different hardware interfaces. If you will be using some special libraries to communicate with your software mention them here. In case you have more than one hardware interface divide this section into subsections.>

3.1.3 Software Interfaces

<Describe the connections between this product and other specific software components (name and version), including databases, operating systems (Windows? Linux? Etc), tools, libraries, and integrated commercial components. Identify the data items or messages coming into the system and going out and describe the purpose of each. Describe the services needed and the nature of communications. Identify data that will be shared across software components. If the data sharing mechanism must be implemented in a specific way (for example, use of a global data area in a

Software Requirements Specification for <Project>

Page 8

multitasking

operating

system),

specify

this

as

an

implementation

constraint.

TO DO: The previous part illustrates some of the information you would usually include in this part of the SRS document. To make things simpler, you are only required to describe the specific interface with the operating system.>

3.1.4 Communications Interfaces

<Describe the requirements associated with any communications functions required by this product, including e-mail, web browser, network server communications protocols, electronic forms, and so on. Define any pertinent message formatting. Identify any communication standards that will be used, such as FTP or HTTP. Specify any communication security or encryption issues, data transfer rates, and synchronization mechanisms. TO DO: Do not go into too much detail, but provide 1-2 paragraphs were you will outline the major communication standards. For example, if you decide to use encryption there is no need to specify the exact encryption standards, but rather, specify the fact that the data will be encrypted and name what standards you consider using. >

3.2 Functional Requirements

Following are the services which this system will provide. These are the facilities and functions required by the customer. a)Online balance check b)Online shopping opportunity c)Online data entry by the staff d)Updating the data e)Balance transfer f)Check book Allotment

Software Requirements Specification for <Project>

Page 9

3.3 Behaviour Requirements

3.3.1 Use Case View

Software Requirements Specification for <Project>

Page 10

<A use case defines a goal-oriented set of interactions between external actors and the system under consideration. Since sometimes we will not be able to specify completely the behaviour of the system by just State Diagrams, we use use-cases to complete what we have already started in section 3.3.1. TO DO: Provide a use case diagram which will encapsulate the entire system and all possible actors. Do not include detailed use case descriptions (these will be needed when you will be working on the Test Plan), but make sure to include a short description of what every use-case is, who are the actors in your diagram. For more information please refer to your UML guide and the MiniThermostat SRS example file.>

4 Other Non-functional Requirements

4.1 Performance Requirements
<If there are performance requirements for the product under various circumstances, state them here and explain their rationale, to help the developers understand the intent and make suitable design choices. Specify the timing relationships for real time systems. Make such requirements as specific as possible. You may need to state performance requirements for individual functional requirements or features. TODO: Provide at least 5 different performance requirements based on the information you collected from the client. For example you can say 1. Any transaction will not take more than 10 seconds, etc>

4.2 Safety and Security Requirements

This Project must be safe and secure because customers will directly contact their account through the internet. Software will have to identify the valid customer according to his/her bank details and password. So it is a difficult task to prevent the system by major disasters bypreventing the unauthorized access to the system.

Software Requirements Specification for <Project>

Page 11

4.3 Software Quality Attributes

<Specify any additional quality characteristics for the product that will be important to either the customers or the developers. Some to consider are: adaptability, availability, correctness, flexibility, interoperability, maintainability, portability, reliability, reusability, robustness, testability, and usability. Write these to be specific, quantitative, and verifiable when possible. At the least, clarify the relative preferences for various attributes, such as ease of use over ease of learning. TODO: Use subsections (e.g., 4.3.1 Reliability, 4.3.2 Portability, etc) provide requirements related to the different software quality attributes. Base the information you include in these subsections on the material you have learned in the class. Make sure, that you do not just write This software shall be maintainable Indicate how you plan to achieve it, & etcDo not forget to include such attributes as the design for change. Please note that you need to include at least 2 quality attributes, but it is the mere minimum and it will not receive the full marks.>

5 Other Requirements
Hardware limitations: It should be designed in such a way that cheap hardware must be installed to access and use it effectively. It should be platform independent. There s h o u l d be no hardware limitations. In should be designed to work with the lowspecification hardware so that it could easily work with the high speci f i c a t i o n hardware.

Software Requirements Specification for <Project>

Page 12

Appendix A Data Dictionary

<Data dictionary is used to track all the different variables, states and functional requirements that you described in your document. Make sure to include the complete list of all constants, state variables (and their possible states), inputs and outputs in a table. In the table, include the description of these items as well as all related operations and requirements.>

Software Requirements Specification for <Project>

Page 13