Software Requirements Specification
Software Requirements Specification
Software Requirements Specification
SPECIFICATION (SRS)
ON
PROJECT OVERVIEW
The project is an authentication system that validates user for
accessing the system only when they have input correct password. The
project involves multi-levels of user authentication. There are varieties
of password systems available, many of which have failed due to bot
attacks while few have sustained it but to a limit. In short, almost all the
passwords available today can be broken to a limit. Hence this project is
aimed to achieve the highest security in authenticating users.
Assumptions
In this paper, proposed multifactor authentication scheme
which is the combination of existing authentication
techniques/methods. There is text-based password, pattern
based password and one time password. In this paper, I will
compare those existing approaches and find the best
approaches to be apply in this multi-level authentication
scheme.
Constraints
System design phase is one of the most important phase in
development. This phase will tell how the system would look
like and how it works. During this phase, the software’s overall
structure is defined and logical system of the product is
developed in this phase. It helps in specifying hardware and
application requirements and also helps in defining overall
application architecture. It describes desired features and
operations in detail and may include use case diagram,
architecture model or other documentation to know more
details about the flow of the system
3. Requirements
The primary goal of this phase is to identify the project's goal and
how the overall system for three level authentication will work. This
stage involves evaluating the user's requirements. Additionally, this
phase aims to determine the size of the present system, observations
are made on the users and the system. During this stage, a requirement
specification is created and contains all potential system needs.
3.2.2 Reliability
• The database information should be kept by the system all the time.
• The system should not fail on the application side. To avoid losing
information, there should be recovery mechanisms in case of a
database
error so that the information is not lost.
• System should be available at least in all the work hours.
• The system should be able to display an informational message when
a system component is not working properly.
3.2.3 Performance
• The system should sustain the load and not stall all of the user’s
system
memory when it is in use.
• Any network connection speed will do, but at least a 128Kbit
connection
is recommended
• A new user with no experience with the system should be able to
master
the system's capabilities within an hour.
3.3 Maintainability
3.3.1 Maintenance
The Changes made after the product has been delivered to the user
must not affect the primary operation of the system. Therefore,
applications should be developed to adapt to changes over time. Not all
problems are seen directly, but they emerge over time like any
other problem that needs to be solved
3.6 Security
3.6.1 Protection
Security considerations should be part of the system to maximize
its potential. These issues also include access control, administration,
information storage, data integrity and reliability. Most security issues
are fairly common in the systems. Confidentiality is not necessary in
most situations, but can be useful in other cases. This action meets all
security requirements regardless of context. Any unauthorized user
should be prevented from accessing the system.
The Databases are strongly secured with password and all the
sensitive data are encoded using the latest MD5 protocol.
All data will be verified in the database whether it is accurate and
functions as per requirements. Also validate whether data is not
modified, or corrupted unexpectedly while accessing the Database.
Tests are done regularly to ensure stored data is unchanged and to
search for new bugs which may alter the files present in the Database.
4. User Scenarios / Use Cases
4.1Use Case diagram
4.2 DFD
Appendix A.
References
[7] Weining Yang, Ninghui Li, Omar Chowdhury, Aiping Xiong, Robert W. Proctor; 2016; An
Empirical Study of Mnemonic Sentence-based Password Generation
Strategies
[8] Lalu Varghese, Nadiya Mathew, Sumy Saju, Vishnu K Prasad, 2014, 3-Level Password
Authentication System
[9] Blonder G. (1996) In Lucent Technologies, Inc., Murray Hill, NJ, United States Patent
5559961
[11] Dr. Swapna Borde, Gauri Satish Tambe, Suchita Ramdas Tambade; 2016; Two Level
Password Authentication System
[12] Ahmad Almulhem Computer Engineering Department King Fahd University of
Petroleum and Minerals Dhahran, Saudi Arabia, A Graphical Password Authentication
System.
[13] Sayli Chavan, Shardul Gaikwad, Prathama Parab, Govind Wakure; 2015; Graphical
Password Authentication System
[14]Chiasson, S., van Oorschot, P.C., Biddle, R. Graphical Password Authentication Using
Cued Click-points. ESORICS 2007.
Appendix B
Req Req desc Testcase status
. id
no
1 login Tc01,TC0 TC01:pass,TC02:pa
2 ss
2 authenticatio AT10,AT2 AT10:fail,AT20:pas
n 0 s