You are on page 1of 9

Devineni Venkata Ramana & Dr.

Hima Sekhar

MIC College of Technology


Kanchikacherla, Krishna District, Pin: 521180. A.P. India. ISO 9001:2008

Software Requirement Specification


Graphical Password Authentication
review No.1

batch no:A11

BATCH MEMBERS :

GUIDE :

DEPARTMENT OF COMPUTER SCIENCE & ENGINEERING

DVR & DR.HS MIC COLLEGE OF TECHNOLOGY

CONTENTS

Introduction Use-Case Model Survey Actor Survey Requirements


Functional Requirements Nonfunctional Requirements

Online User Documentation and Help System Requirements Design Constraints Purchased Components Interfaces

User Interfaces Hardware Interfaces Software Interfaces Communications Interfaces

Licensing Requirements Legal, Copyright, and Other Notices

Introduction
For the vast majority of computer systems, passwords are the method of choice for authenticating users. The most widely and commonly used authentication is traditional

Username and password. For such authentication generally text (alphanumeric) is used. It is well-known, however, that passwords are susceptible to attack as users tend to choose passwords that are easy to remember, and often this means that they are also easy for an attacker to obtain by searching for candidate passwords. On the other hand, if a password is hard, then it is often hard to remember. Keeping these in mind we propose a novel, innovative and more secure way of selecting passwords: Graphical Passwords. Alphanumeric Password is the leading mechanism for verifying the identity of computer users, even though it is well known that people normally choose passwords that are vulnerable to different attacks. However, secure passwords should be random and should be hard to guess, they should be changed frequently. References are http://www.scribd.com/doc/29423055/Graphical-Password-Authentication http://www.scribd.com/doc/27917924/Graphical-Password

Assumptions are although the normal password authentication is not so secure enough for authentications. So Graphical Passwords are the passwords that are based on pictures or images rather than simple alphanumeric strings. Graphical passwords are far better than alphanumeric passwords; the primary reason is that, using images rather than alphanumeric strings. Using images will lead to decrease tendency to choose insecure passwords and also the human beings ability of visual memory is much powerful than the textual memory Dependencies are the about uploading images to the database in a specific order.

Use CaseModel survey

Actor Survey
There are two users for the system Administrator and users The case diagram below shows the overall view. The user can register with general alphanumeric password along with uploading images to the server database with the help of BLOB Field. This makes user to authenticate with the help of images which are uploaded to the server databases. The Admin modules involved in generating a random number [two digit number ] from 10 to 99 and user has to select the image id based on the random number generated. So the authentication is more secure when compare with the existing methodologies.

Requirements
Functional Requirements:

This section is the bulk of the document and precisely states the functions of the system what it should do and what it should not. This section is split into subsections modeled after the real world activities like reserving tickets, rescheduling tickets etc.Freedom from ambiguity and navigability were kept in mind while documentation. A consistent terminology has been followed throughout and the terms are explained in the appendix. The subsections follow a logical sequence that reflects the real world. For example, a customer cannot reschedule a ticket unless he has bought one earlier and cannot buy one unless he has checked its availability.

User Accounts:
1.The user, will be presented with 3 choices by the reservation system. o as the first step in the user will be provided with the list of movies ,he have to choose a specific movie in that. o as the second step the user need to select date in which he want to watch the film, with in the provided options o as the third step the user need to enter no of seats. 2.after following the first step the user need to press a button book now which results in a new window where the seating is given we can click the seats we need to book. 3.after selecting the seats required the bank transaction process takes place

Non-Functional Requirements Usability


This section includes all of those requirements that affect usability. These often include The required training time for normal users with a basic knowledge on computers would be 1 day. where as for power users i.e who are experts in using computers, one presentation is enough to become productive in particular operations.

Reliability
Requirements for system reliability are specified here. * Availability: percent of time available

* Mean time between failures (MTBF): This is usually specified in hours but could also be specified in terms of days, months, or years. T/R = T = total time R = number of failures * Mean time to repair (MTTR): It specifies how long is the system allowed to be out of operation after it has failed? * Accuracy: Precision (resolution) and accuracy (by some known standard) that is required in the system's output. * Maximum bugs or defect rate: Usually expressed in terms of bugs / KLOC (thousands of lines of code) or bugs per function-point. * Bugs or defect rate: Categorized in terms of minor, significant, and critical bugs. The requirement(s) must define what is meant by a "critical" bug (such as complete loss of data or complete inability to use certain parts of the functionality of the system).

Performace
The performance characterstics of the system are outlines here: * Response time for transaction (average, maximum) * Throughput (transactions per second) * Capacity (the number of customers or transactions the system can accomodate)

* Degredation modes (the acceptable mode of operation when the system has been degraded) * Resource utilization (memory, disk, communications)

Supportability
The system is designed to be the cross platform supportable. The system is supported on a wide range of hardware and any software platform which is having JVM built into the system.

Design Constraints
The system need to design base on the HTML code and database using J2EE1.4 , oracle 8i or above and and Struts 1.2.x.. All components follow Model-ViewController pattern.

Purchased Components
* Application server software and version (Tomcat 5 or above) * Database software and version (ORACLE 8i or above) * J2EE (typically because of app server requirements/supportability) * Servlet Specification (typically because of app server requirements/supportability)

Interfaces
User interfaces
All pages of the system are following a consistent theme and clear structure. The occurrence of errors should be minimized through the use of checkboxes, radio buttons and scroll down in order to reduce the amount of text input from user. JavaScript implement in HTML in order to provide a Data Check before submission. HTML Tables to display information to give a clear structure that easy to understand by user. Error message should be located beside the error input which clearly highlight and tell user how to solve it. If system error, it should provide the contact methods. Each level of user will have its own interface and privilege to mange and modify the project

information such as supervisor or admin able to monitor/ manage his users data and user can change his details.

Hardware Interfaces
a. Server Side The web application will be hosted on one of the Linux or Windows servers and connecting to one of the Hostel Oracle Database server. The web server is listening on the web standard port, port 80. b. Client Side The system is a web based application; clients are requiring using a modern web browser such as Mozilla Firebox 1.5, Internet Explorer 6 and Enable Cookies. The computer must have an Internet connection or LAN in order to be able to access the system on any other system with enough credentials.

Software Interfaces
a. Server Side The ORSCM already has the required software to host a Java web application. An Apache Web server will accept all requests from the client and forward ORSCM specific requests to Tomcat 5.5 Servlet Container with J2EE 5.0 and Strut 1.2.8 hosting ORSCM. A development database will be hosted locally (using MySQL or ORACLE); the production database is hosted centrally (using Oracle). b. Client Side An OS is capable of running a modern web browser which supports HTML version 3.2 or higher.

Communication Interfaces
The HTTP protocol will be used to facilitate communications between the client and server.

Licensing Requirements

The Online Reservation System For Cine Malls is a license free product. Once installed, it can used forever without any usage restrictions.