Software Requirements Specifications: Submitted by
Software Requirements Specifications: Submitted by
Software Requirements Specifications: Submitted by
Submitted By
Name Registration No.
• Aniket Rathour 12200127
Research Supervisor
1|Page
Contents
1.Introduction………………………………………………………………………………………4
1.1.Purpose…………………………………………………………………………………….....4
1.2.Scope………………………………………………………………………………………....4
1.3.Overview……………………………………………………………………………………..5
2.Overall Description………………………………………………………………………………5
2.1.System Environment………………………………………………………………………...5
2.2.Functional Requirements Specification……………………………………………………..6
2.2.1.Administrator Use Cases…………………………………………………………………..6
Use Case – Create Officer…………………………………………………………………6
2|Page
2.3.Non-Functional Requirement Specification……………………………………………………...10
2.3.1.Graphical User Interface………………………………………………………………...…10
2.3.2.Accessibility & Reliability………………………………………………………………... 10
2.3.3.Performance.……………………………………………………………………………….11
2.3.4.Hardware & Software Requirements.……………………………………………………...11
Hardware Requirements.…………………………………………………………………...11
Software Requirements.……………………………………………………………………11
2.3.5.Security…………………………………………………………………………………….12
2.4.Data Flow Diagram……………………………………………………………………………….12
2.4.1.Data Flow Diagram For Admin…………………………………………………………….13
2.4.2.Data Flow Diagram For Officer…………………………………………………………….14
3|Page
Software Requirements Specifications
1.Introduction-
SRS (Software Requirements Specification) is a document prepared before
developing any software/application with the sole cause providing each and
every detail about the project to be developed, what will be its requirements,
what will be its functionalities and each and every minute details.
Now, there is one question that what is the need of preparing SRS document?
Actually, it gives an overall picture about the project which gives a clarity to the
team about what is exactly is to be made and what will be the step-by-step
process. It is created strictly based on client’s requirements.
1.1. Purpose-
The purpose of this document is to present a detailed description of “White
Card – Manage All Card into One” such as driving license, passport, aadhar
card, ration card etc. It will tell us that how this system will work, what will be
its constraints under which it should operate.
How its user interface will look like, how the end user can operate it and many
more things that will help any software developer to assist in software delivery
lifecycle process (SDLC).
1.2. Scope-
This project “White Card – Manage All Card into One” is to design and develop
the application for India which denotes Indian. It’s a kind of identity document
which can be used to verify aspects of a person’s personal identity. It includes
the details like driving license, pan card, voter id, ration card etc. Most countries
accept passports as a form of identification as well as in some countries driving
license is considered as most effective method of proof of identity
This white card can be used as an all-in-one card with “Universal Product
Code” adoption of identity is supported by law enforcement officials who claim
that it will make surveillance and identification of criminals easier. Every
human being can carry this white card for one’s own personal identification
which can be falsified or discarded.
4|Page
1.3. Overview-
The next chapter, overall document, will give the overall functionality of the
software describing hardware and technical requirements specifications.
The problem statement here is that all the identity proofs can be kept at one
place online so that it can be verified by the officials whenever and wherever, in
case any discrepancy arises.
2.Overall Description-
2.1.System Environment-
Voter ID Officer
RTO Officer
5|Page
The “White Card – Manage All Cards Into One” has total of 6 users who can
operate the system according to their rights. Among these, 5 are the various
officers who can read and update the details of the client.
The other one is the admin who manages the system , he is the one who can
create white cards as well as can create or delete officers and can provide
various rights to them.
In this section, use cases for each of the users are mentioned separately.The use
case is made up of a set of possible sequences of interaction between systems
and users in a particular environment and related to a particular environment.
The officers will have 2 use cases each whereas the admin will have a no. of use
cases as he/she is the controller of the system.
Brief Description –
In this use case, admin can create a new officer in any of the five related
fields in case that position is vacant.
6|Page
Admin will enter all personal details of the officer in “Officer
Registration Form” alongwith the id password which will be provided to
the officer for logging in.
Brief Description –
In this use case, admin can view all details of the existing officers. Either
he can search for an officer by name or on category(department) basis.
Brief Description –
In this use case, admin can create a new white card of a client by entering
all its personal details and a passport size photo. After successful
registration a 4 digit PIN and a QR Code will be generated.
Brief Description –
In this case, admin can see the details of the various white cards by white
card no. or by department category. He/She can also see whether officers
have made any changes in the client’s details.
7|Page
Brief Description –
In this case, voter id officer can view the details of the given white card
no. and can update the details related to it.
For eg. Officer can update that the particular client has given his vote on
given date so that he/she cannot vote again from other booths.
Brief Description –
In this case, RTO officer can view the details of the given white card no.
and can update the details related to it.
For eg. Officer can update that the particular client has violated
rules(penalty) or if the person has met any accident for further reference.
Brief Description –
8|Page
In this case, Ration Card officer can view the details of the given white
card no. and can update the details related to it.
For eg. Officer can view that whether the whitecard holder is eligible for
ration and on which date how much ration he/she has taken.
Brief Description –
In this case, officer can view income tax and pan card details of the client
as well as details of income tax details of that assessment year can be
updated there itself.
Brief Description –
In this case, officer can view the details of the aadhar card as well as
updation in any details of aadhar can be done.
Remember that here only updation can be done. Issuing of aadhar card
9|Page
Can be done by admin only as it is a crucial task to verify details of a new
client first time.
In this section, set of specifications are discussed which better describes the
system’s operation capabilities and constraints and attempt to improve it’s
functionality.
These are basically the requirements highlighting how well our system will
operate including things like speed, security, reliability, data integrity, etc.
• First of all, the graphical user interface must be easy to use and
understanding.
• The system shall display profile image of all its users including
Admin.
10 | P a g e
as it provides 99% uptime and data is replicated automatically.
2.3.3.Performance-
• Hardware Requirements –
RAM – 4 GB
Pendrive – 2/4 GB
• Software Requirements-
2.3.5.Security-
As the system will be hosted on AWS platform it will be secured. But then also
security measures from the user’s side must be performed.
• Other users other than admin should have only read and update access.
• Users should use the software on their systems only and they should
have antivirus installed.
12 | P a g e
Above is the “Data Flow Diagram” for the proposed software. Now, Let’s
understand what is a data flow diagram.
Below is the data flow diagram for administrator which shows overall
functioning of the software in the case of admin alongwith its use cases.
13 | P a g e
2.4.2.Data Flow Diagram For Officer-
Below is the data flow diagram for administrator which shows overall
functioning of the software in the case of officer alongwith its use cases.
14 | P a g e