Software Requirements Specification

Software Requirements Specification For <IMPLEMENTATION OF MOBILE BANKING FOR SYMBIAN OS MOBILE PHONES> Version 1.
0 approved Date created: 14/10/2010
Implementation of mobile banking for symbian O.S mobile phones
Software Requirements Specification
Table of Contents
Introduction....................................................................................................................................1 Overall Description .......................................................................................................................2 Functionality...................................................................................................................................3 External Interface Requirements................................................................................................. 4 Other Nonfunctional Requirements............................................................................................. 5
Revision History
Name Date 14/10/2010 Reason For Changes Version 1.0
Introduction
1.1 Purpose
Facilitation of payments made within an institution or organization by using a mobile phone. This will also prevent loss, theft,misuse of money.
1.2
Intended Audience and Reading Suggestions
This document is intended for people (teachers, classmates and hopefully organizations and institutions in future) who wish to get into the depth information of this project, its advantages and limitations.
1.3
Project Scope
The project has a very broad scope as it will facilitate payments made within an institution or organization by using a mobile phone. It can cover small to medium amount payments which are incurred on irregular as well as regular basis. People will not have to wait in queues. This will also prevent loss, theft, misuse of money, or encountering counterfeit currency. It is secure and any time, any where banking. Considering major corporate telecom service providers and Banks venturing into similar projects it can be said without any doubt that in the future, it will compete and survive in the world of banking services and as mobile banking is widely being adopted by everyone as a secure, convenient mode of payment.
1.4
References
http://www.forum.nokia.com/ http://developer.nokia.com/ www.java.net http://developers.sun.com http://flashflex.com https://hdfcbank.com
Overall Description
1.5 Product Perspective-Check
Student often have to wait in a line to pay their school fees. Sometimes we miss our lectures. Besides the above mentioned hassles there are other problems also like moving manually from bank to office and then various departments in the college, and not to forget loss, theft, misuse of money. Using this Software we can pay our fees anytime from anywhere and without any hassles. Since mobile banking will have more scope in future compared to e-Banking. This project even has a greater scope. Besides the current mobile banking features it is slightly improved as we dont have to safeguard, submit the fee-receipts in various departments. The server will take care of it.
1.6
Product Features
1) Registering of the Software on mobile. This will help in future authentication 2) Secure mode of payment 3) Server side handling the back-office job of passing on the receipts
1.7
User Classes and Characteristics
Currently the system is intended only to facilitate the payment in an institution or organization e.g. a School, College, small company. But the above need can be met using a simple Class User, if the project requires special permission and if requirements increase we can have another class Advanced User meant for teachers or Managers based on greater expertise, security or privilege levels, educational level, or experience.
1.8
Operating Environment
The Software will have two sides The client side The Server side Both will run on Symbian OS mobile phones. This includes all of the latest Nokia Phones (S40 Series).Later it will be ported to previous edition and the 3rd and upwards 1) Nokia-6300 Nokia Series 40, 3rd Edition 2) Nokia-6030 Nokia Series 40, 2nd Edition 3) Nokia-6208 Nokia Series 40, 5th Edition It would require a telecom provider (active SIM) which would be used for communication between client and Server The Software would be packed into a JAR file to be installed onto the phone The Server side would require GPRS. The Software will have to peacefully co-exist with the Inbox of the installed device
1.9
Assumptions and Dependencies
Depending on the reliability of the GSM SIM Messages we will have to modify the project so that a weak link does not reduce the security of the project. Currently we are assuming GSM Sims provide secure communication as numerous banks are using it at a larger scale. We will try to use as many components and Nokia APIs (e.g. Message sending or email sending) Assuming these APIs are available for S40 mobiles also, at the same time we will try to improve the project as much as we can. Some APIs of S40 will be considered deprecated (old) on newer editions so porting to a certain level will also add to the complexity If e-mail is used for informing the various departments we will be depending on public Domains (maybe gmail).The current banking establishments use GSM SIM itself for informing Clients and the fee receipt is not forwarded to any department.
Functionality
Secure mode of payment using mobile banking and automated handling of back-office job of passing on the receipts. Later we may advance.
1.10 Secure Login

3.1.1 3.1.2 Registration Login
The initial registration will require this step. 2nd use and onwards will begin from here. On successful login it will also display the previous login information.
3.1.3
Functional Requirements
A database will be maintained on the clients side also. To store the password either a security Lock or API will be needed or else a security algorithm will be implemented. If there is damage to this database due to unavoidable circumstances or mal-practice, the device may require re-registration. This database can also help in the pulling of Mini Statement REQ-1: The Database must be protected, to avoid trouble in future
1.11 Secure mode of Payment

3.2.1 Selection of type of Fee, Amount
We can select what fee we want to pay, amount, and selecting the right bank and entering the right password. Any wrong information will cancel the transaction
3.2.2
Functional Requirements
A database will be maintained on the server side also to verify the password, balance. REQ-1: The Database must be protected, to avoid trouble in future REQ-2: We will need the active SIM to be able to send messages.
1.12 Server side handling documentation

3.1.1 3.1.2 3.1.3 Verification Balance confirmation Functional Requirements
The authentication will be done here. Subsequently balance will be deducted. Since the server side is passing the Receipt (e-mail or SMS) to the client the above features must be supported and active on the mobile device. REQ-1: We will need to use a public service provider e.g. Airtel or domain like gmail.
External Interface Requirements

1.13 User Interfaces
We intend to have Registration / Logon Screen, Menu Screen, and a view implemented for each item in the menu (e.g. Balance enquiry, Selection of Bank and Amount to be paid).We will try to have standard buttons like exit, help, Text editing feature using APIs to make the product more user friendly. Standard buttons and functions (e.g., help) will appear on every screen, keyboard shortcuts, error message display standards, and so on.
1.14 Hardware Interfaces

Since we are implementing the Software on S40 mobile it will have limited hardware interface. However the use of Standard Nokia APIs will make the Software forward compatible, and features like touch UI may be implemented depending upon the complexity and size of the project.
1.15 Software Interfaces

The software will be using the database on the local machine. It will require the integration of Messaging And or e-mailing maybe using telecom providers like Airtel and public domains like gmail.
1.16 Communications Interfaces

We will be using two modes of communication. The GSM SIM Messages which provide secure communication as numerous banks are using it at a larger scale. To pass on the receipt to other departments we will use Messaging And or e-mail as maybe viable. If e-mail is used for informing the various departments we will be depending on public Domains (maybe gmail).The current banking establishments use GSM SIM itself for informing Clients and the fee receipt is not forwarded to any department.
Implementation of mobile banking for symbian O.S mobile phones 4
Other Nonfunctional Requirements

1.17 Performance Requirements
It would require a telecom provider (active SIM) which would be used for communication between client and Server. The communication depends on the GSM SIM; hence any delay from the telecom service provider will cause a delay. The Server side would require GPRS. To improve performance clients side database should also be safe as it can give trouble only to the user.
1.18 Design and Implementation Constraints

The communication depends on the GSM SIM; hence any delay from the telecom service provider will cause a delay. Getting a vendor ID or Product ID from Nokia requires a lot of resources. Hence it will be difficult for developers to use later hardware like S60 3rd Edition Phones. These phones are expensive too. Since Database on Server will be a problem in the long run. Regular backup is required, however the secondary receipts in the form of e-mails will help and consistency can easily be maintained.
1.19 Help system requirements

The software will be made as user friendly as possible that a common person can understand. Offline help file can be maintained. Online help will not be available however we can have link to the general publicly available help.
1.20 Usability
There should not be any loss, damage, or harm that could result from the use of the product. However if the mobile and password is lost, some one can pay your fees which again will not be a loss but just some trouble to the User and Admin to revert the changes. Keep the mobile and password safe and confidential.
1.21 Reliability
The Databases must be protected, to avoid trouble in future. If any loss of data on the client side, Mini Statement will have to waste a message which is still reliable. However if any tampering on clients side will only disturb the client and not server If any loss of data on servers side, the Server backup can be pulled and last days transactions can be recalculated. Untrusted parties should not have physical access to server mobile. SMS and e-mail from gmail are reliable and are used by big Banks too.
Appendix A: Glossary
Password-password Client -student mobile Server -Bank mobile SMS -Short message service provide by telecom provider

Software Requirements Specification

Uploaded by

Copyright:

Available Formats

Software Requirements Specification

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Software Requirements Specification

Uploaded by

Copyright:

Available Formats

Software Requirements Specification For <IMPLEMENTATION OF MOBILE BANKING FOR SYMBIAN OS MOBILE PHONES> Version 1.

0 approved Date created: 14/10/2010

Implementation of mobile banking for symbian O.S mobile phones