Software Requirements

Specification
Civil Registry

by
Gaurav Pawar (153)
Mustufa Merchant(156)
Balaji Kole(1)

Table of Contents
Table of Contents.........................................................................................................................................2
List of figures..............................................................................................................................................3
1. Introduction...........................................................................................................................................4
1.1 Purpose...........................................................................................................................................4
1.2 Document Conventions...................................................................................................................4
1.3 Intended Audience and Reading Suggestions..................................................................................4
1.4 Product Scope.................................................................................................................................5
1.5 References......................................................................................................................................5
2. Overall Description...............................................................................................................................6
2.1 Product Perspective.........................................................................................................................6
2.2 Product Functions...........................................................................................................................6
2.3 User Classes and Characteristics.....................................................................................................6
2.4 Operating Environment...................................................................................................................7
2.5 Design and Implementation Constraints.........................................................................................7
2.6 User Documentation.......................................................................................................................7
2.7 Assumptions and Dependencies......................................................................................................7
3. External Interface Requirements...........................................................................................................8
3.1 User Interfaces................................................................................................................................8
3.2 Hardware Interfaces........................................................................................................................8
3.3 Software Interfaces.........................................................................................................................8
4. System Features....................................................................................................................................9
4.1 Functional Requirements................................................................................................................9
5. Other Nonfunctional Requirements.....................................................................................................14
5.1 Performance Requirements...........................................................................................................14
5.2 Safety Requirements.....................................................................................................................14
5.3 Security Requirements..................................................................................................................14
6. Key Milestones....................................................................................................................................15
7. Other Requirements.............................................................................................................................16

List of figures
Figure 1 - System Environment......................................................................................................6
Figure 2 User Interfaces...............................................................................................................8

1. Introduction

1.1 Purpose

The primary objective of this web site is to give awareness about the government or legal
documents and its registration details as well as to help to register or apply for those documents.
This also acts as a consultancy agency to assist the public. The main purpose of the web site is to
reduce the effort by the candidate and save his time and avoid unwanted rushes at the
government offices and assure a smooth working schedule at government offices.

1.2 Document Conventions

This document features some terminology which readers may be unfamiliar with. See
Appendix A (Glossary) for a list of these terms and their definitions.
1.3 Intended Audience and Reading Suggestions
This document is intended for all individuals participating in and/or supervising
the Civil Registry project. Readers interested in a brief overview of the product should focus on
the rest of Part 1 (Introduction), as well as Part 2 of the document (Overall Description),
which provide a brief overview of each aspect of the project as a whole. These readers may
also be interested in Part 6 (Key Milestones) which lays out a concise timeline of the project.
Readers who wish to explore the features of Civil Registry in more detail should read on to Part
4(System Features), which expands upon the information laid out in the main overview. Part 3
(External Interface Requirements) offers further technical details, including information on the
user interface as well as the hardware and software platforms on which the application will run.
Readers interested in the non-technical aspects of the project should read Part 5, which covers
performance, safety, security, and various other attributes that will be important to users.
Readers who have not found the information they are looking for should check Part 8 (Other
Requirements), which includes any additional information which does not fit logically into the
other sections.

1.4 Product Scope

Civil Registry is the online system or agency to help the Indian citizens to apply for there
government records like passport, driving license, voters ID card, PAN card etc... And register
certificates like birth, death, marriage etc.
The primary objective of this web site is to give awareness about the government or legal
documents and its registration details as well as to help to register or apply for those documents.
This also acts as a consultancy agency to assist the public.
1.5 References
1. Software Engineering A practitioners approach, Roger S. Pressman
2. Wikipedia

3. Overall Description
2.1 Product Perspective
This system is providing online facility to apply for different official documents together which
were not present before. This will increase the popularity of the system and it will reach to a
large mob. This will provide a way to attract citizens so that it will be easy for them to register or
apply for those documents anytime as well as any where according to their availability. Here
anyone can register and apply for government records.

Fig. System Environment

2.2 Product Function
Civil Registry is a consultancy agency portal which will provide the assistance to apply and
enquire about the legal activities and different applications such as Marriage Registration, Death
Registration, Ration Card, Voters ID card Registration, Divorce, Electricity Registration, Water
Tap Registration etc etc.

2.3 User Classes and Characteristics

User: They will be provided with the login with the help of which they will apply for different
official documents online.

Administrator: They will have total access of the system; will do verification and approval of
users request as well as controls official documents.
Visitors: They can give there feedback or can enquire for requirement regarding any official
document

2.4 Operating Environment

VB.NET is

a server-side Web

application

framework designed

for Web

development to

produce dynamic Web pages. VB .NET is built on the Common Language Runtime (CLR),
allowing programmers to write VB.NET code using any supported .NET language. The
VB.NETextension framework allows VB.NET components to process SOAP messages. This is a
web application so platform will not be a barrier for this system.

2.5 Design and Implementation Constraints

The computers must be equipped with web browsers such as Internet explorer

A general knowledge of basic computer skills is required to use the product.

This system is not only accessible to limited peoples rather it can be used by students
also.

2.6 User Documentation

Website which is used presently for online application will be the documentation which will be
provided for the system.
2.7 Assumptions and Dependencies
We assumed that this website will help peoples to register and apply for the official document
very easily. Since any user can create account; anyone can apply or register for the same.

3. External Interface Requirements

3.1 User Interfaces

Fig. User Interface

3.2 Hardware Interfaces
Hardware Interface will be the computer which will be used by end user. Other hardware
interface is not required.

3.3 Software Interfaces

.NET Framework's Base Class Library provides user interface, data access, database
connectivity, cryptography, web application development, numeric algorithms, and network
communications. Programmers produce software by combining their own source code with .NET
Framework and other libraries. .NET Framework is intended to be used by most new
applications created for the Windows platform.

4. System Features
4.1 Functional requirements
System provides user login, admin login, Registration, feedback, mailer. These features form the
body of the application and include any features that are essential to the functionality of the web
portal. These features must be implemented in order to have a fully-functioning application.
Additional features, however, are not required for the portal to function. They include any
features which, if time permits, will be added to the application in order to provide extra
functionality.
Consider the following use cases.
1) User login
Use Case Id :

01

Use Case Name :

User login

Brief Description :

The user enters username and password to login

Actor :

User

Precondition :

User should fill username and password and click on login

option

Basic Flow:

1. User selects login option

2.If already a user then:
i)Enter username
ii)Enter password
iii)System validates username and password
iv) If correct, proceed to access website.
3. If new user then load registration form. User fills all

Alternative Flow :

information and then performs login.

No

Exception Flow :

If username and password incorrect then re-enter correct

username and password.

Post Condition :

User can proceed to access the website.

2) Admin login
Use Case Id :

02

Use Case Name :

Admin login

Brief Description :

The faculty enters username and password to login

Actor :

Admin

Precondition :

Admin should fill username and password and click on login

option

Basic Flow:

1. Admin selects admin login option

2.If already a user then:
i)Enter username
ii)Enter password
iii)System validates username and password
iv) If correct, proceed to manage website data.
3. If new user then load registration form. User fills all

Alternative Flow :

information and then performs login.

No

Exception Flow :

If username and password incorrect then re-enter correct

username and password.

Post Condition :

Admin can proceed to access the website.

3) display options
Use Case Id :

03

Use Case Name :

Display Options

Brief Description :

Various options are displayed.

Actor :

User,Admin

Precondition :

User or Admin should have opened the website.

Basic Flow:

1 User or admin member opened website.

2.System displays various option
i) Home
ii) Services
iii) Feedback
iv) Mail
v)Contact Us

Alternative Flow :

No

Exception Flow :

If user or admin member clicks on Back option then load

the previous page.

Post Condition :

User or admin member may choose any option from the

displayed option. The webpage should be displayed until
user is done with selection.

4) Registration
Use Case Id :

04

Use Case Name :

Registration

Brief Description :

Registration for various official document is provided

Actor :

User, Admin

Precondition :

User or Admin should have login to the website.

Basic Flow:

1. User or admin member logins.

2.System displays various choices
3. Select one of them
4.Fill necessary details required

Alternative Flow :

5.Register
No

Exception Flow :

If the information submitted by user is not complete reject

the registration
Post Condition :

User logouts the system

5) Feedback
Use case Id :
Use case name :
Brief description :

5
Feedback
User can give his/her feedback about the services provided

Pre-condition :
Basic flow :

by Civil Registry system.

User should be a registered user.
1. User selects feedback option.
2.System loads feedback form
3. User gives feedback.

Alternate flow :
Exceptional flow :

4. Clicks on submit option.

None
If user is unregistered user then display message Only

Output :
Post conditions :

registered users can give feedback.

Feedback is saved.
Homepage should be displayed.

6) Contact us
Use case Id :
Use case name :
Brief description :
Pre-condition :
Basic flow :

6
Contact us
Third party/visitors can obtain contact information.
Third party/visitors should click on contact us.
1. User selects contact us.
2.System displays contact details such as:
i) Address of main office
ii) Contact no.

Alternate flow :
Exceptional flow :
Output :
Post conditions :

iii) Email id.

None
None
Contact info webpage is displayed
User may contact Registry office using the info.

5. Other Nonfunctional Requirements

5.1 Performance Requirements
The Online System will be on a server with high speed Internet capability. The physical machine
to be used will be determined by the User. The software developed here assumes the use of a tool
such as Tomcat for connection between the Web pages and the database. The speed of the
Readers connection will depend on the hardware used rather than characteristics of this system.

5.2 Safety Requirements

Safety can also be defined to be the control of recognized hazards to achieve an acceptable level
of risk. This can take the form of being protected from the event or from exposure to something
that causes it can include protection of people or of possessions.
5.3 Security Requirements
Registered user can apply for a document only once. Take regular back-ups of the information on
your computer system and keep them in a separate place so that if you lose your computers, you

dont lose the information. The design addresses some of the vulnerabilities, such as buffer
overflows, which have been exploited by malicious software. Additionally, .NET provides a
common security model for all applications.
.NET has its own security mechanism with two general features: Code Access Security (CAS),
and validation and verification. Code Access Security is based on evidence that is associated
with a specific assembly. Typically the evidence is the source of the assembly (whether it is
installed on the local machine or has been downloaded from the intranet or Internet). Code
Access Security uses evidence to determine the permissions granted to the code. Other code can
demand that calling code is granted a specified permission. The demand causes the CLR to
perform a call stack walk: every assembly of each method in the call stack is checked for the
required permission; if any assembly is not granted the permission a security exception is
thrown.

6. Key Milestones
Milestone
SRS document

Deadline
24/01

Comments
Abstract done by Dec 24, so a presentation can be

06/02

created
Designs should be done a week in advance of

Interface Design
Finalized

10/02

abstract for Revisions.

Designs should be done a week in advance of

Algorithm Design
SDD document

15/02

abstract because of bugs

Abstract done by Feb 04 so a presentation can be

Server Setup

18/02

created
This should be done in the beginning of the

Interface &

04/03

implementation phase to sync with other features

This should be completed two weeks in advance of

Finalized

Algorithm
Implementation
Software Festival

complete project so website can be thoroughly

18/03

tested and bugs fixed

Completion of project

7. Other Requirements
Necessary details required for issuing official documents are required.