Swami Keshvanand Institute of Technology,

Management and Gramothan, Jaipur

Unique National Identification Card

Software Requirements Specification

Team Name
TechnoBrates

Team Members
Adamya Kant
Amit Kumar Jain
Deepshikha Jhamb
Mukul Gupta

Project Guide
Dr. Anil Choudhary

1
 Index and Tables

1) Introduction: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1) Overview of project: . . . . . . . . . . . . . . . . . . . . 3
1.2) Objective of project: . . . . . . . . . . . . . . . . . . . . 3
1.3) Scope: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.4) Abbreviations: . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.5) Technologies: . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.6) Users: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.7) References: . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2) Overall Description: . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.1) Detailed Description of project: . . . . . . . . . . . . 8
2.2) Hardware Interface: . . . . . . . . . . . . . . . . . . . . .11
2.3) Software Interface: . . . . . . . . . . . . . . . . . . . . . 12
2.4) Communication Interface: . . . . . . . . . . . . . . . .12
2.5) Functional Requirements: . . . . . . . . . . . . . . . . 13
2.6) Use-Case Model Survey: . . . . . . . . . . . . . . . . .14
2.7) Architecture diagram: . . . . . . . . . . . . . . . . . . . 16
2.8) Database design: . . . . . . . . . . . . . . . . . . . . . . . 17
2.9) Assumptions and Dependencies: . . . . . . . . . . .17

3) Specific Requirements: . . . . . . . . . . . . . . . . . . . . . . . 18
3.1) Use-Case Reports: . . . . . . . . . . . . . . . . . . . . . .18
3.2) Flow charts: . . . . . . . . . . . . . . . . . . . . . . . . . . .35
3.3) Supplementary Requirements: . . . . . . . . . . . . 38
3.4) Legal and Privacy Issues: . . . . . . . . . . . . . . . . 39

2
1) Introduction:

1.1) Overview of Project: The project “Unique National

Identification Card” is the process of identification for
all citizens who are residing/migrate in India through a
card possessing ID information of each individual. The
card will possess the unique ID as well as the biometric
information for authentication of the card holder. The
card can be used in various fields which require
authentication.

1.2) Objective: Objectives of the Project are

• Obviate need for multiple documentary proofs.
• Facilitate easy verification.
• Facilitate easy availing of government and private services.
• Help welfare programs reach intended beneficiaries.
• Serve as basis for e-governance services.

The ID should also serve the following purposes:

• To prepare a National Population Register (NPR)

• To prepare National Register of Indian Citizens(NRIC)
• To prepare National Register of Residency (NRR) – for non-
citizens
• To provide National Identity Number (NIN) to each person.

1.3) Scope of Project:

• Create different system users and assign different roles

with related permission.
• Keeping the track of all the individuals and the related
details.
• Confirmation of end user identity and will verify which
users are authorised to receive the services and support.
• Maintain the details of all the interactions made with the
user.

3
 • Activities like updations, creations done in the system by
the system users will be maintained in the form of logs
for auditing and maintaining the integrity of the system.
• Capture, View and edit all user transactions, including
email, chats, and services calls in a single system.

1.4) Abbreviations:

UID - It will be User Identity Card containing the Unique

National Identity Number and the Biometric sample which
will be given to each and every individual without
duplicity.

Registration Office-Office where process related to UID‘s

generation and maintenance will take place.

Government Agent- It will be the agent involved in

authentication of citizen’s information from the government
side.

Users- These will be the citizens of the country or the

people who will migrate in country, to whom UID will be
issued.

Personnals- They will interface government agent and

offline users.

Public Administrators-They can access the database with

all information and can provide accessibility to database for
other application areas.

Public Manager- It manages the UID after its distribution

to citizen.

Public details- Details related to the authentication

specification.

4

Verification-It is basically Biometric Verification which uses a one-
to-one (1:1) matching scheme. The user is required to state who he or
she is (e.g. by entering an UID). A fingerprint sample is taken from
the user and compared to his or her fingerprint previously stored in the
smart card. If the fingerprints match, the user is "verified" and is
granted access.

Identification- It is basically Biometric Identification which uses a

one-to-many (1: N) matching scheme. The user need not state who he
or she is. A fingerprint sample is taken from the user and compared to
a database of registered fingerprints. When a match is found, the user
is "identified" as the pre-existing user.

HTTP: Hypertext Transfer Protocol is a transaction oriented

client/server protocol between web browser & a Web Server.

HTTPS: Secure Hypertext Transfer Protocol is a HTTP over SSL

(secure socket layer).

TCP/IP- Transmission Control Protocol/Internet Protocol,

the suite of communication protocols used to connect hosts
on the Internet. TCP/IP uses several protocols, the two main
ones being TCP and IP.

1.5) Technologies:

SCOSTA – SCOSTA stands for Smart Card Operating

System for Transport Applications. SCOSTA describes the
minimum support for the application using the Smart Cards.
It provides inter operable command set for interaction
between smart card data and applications. It implements
symmetric key cryptography and has its own security
architecture for the protection of resources such as data and
commands. Along with resource protection, it also allows
the application to perform cryptographic operations such as
encryption, decryption, checksum computation and
verifications etc. It supports multiple applications on a
single smart card. SCOSTA is ISO compliant and

5
 application independent standard. A SCOSTA compliant
operating system will also be compliant to the ISO7816-4, -8 and -9
standards.

HTML- Hypertext Markup Language is a markup language

used to design static web.

DB2- DB2 Database is the database management system

that delivers a flexible and cost effective database platform
to build robust on demand business applications.

J2EE- Java 2 Enterprise Edition is a programming

platform— part of the Java Platform for developing and
running distributed multi tier architecture Java applications
based largely on modular software components running on
an application server.

EJB- Enterprise Java Beans.

WAS- Web sphere application server is an application

server that runs business applications and supports the J2EE
and web services standards.

RAD- Rational application developer is a toolkit which is

designed for the creation of more complex projects,
providing fully dynamic web application utilizing EJB’s.
This consist of EJB tools , CMP ,data mapping tools & a
universal test client that is designed to aid testing of EJB’s.

XML- Extensible Markup Language which is used to

retrieve data from database that will be independent of an y
platform.

HTTP-Hypertext Transfer Protocol is a transaction oriented

client/server protocol between web browser & a Web
Server.

Java Card - Java Card technology adapts the Java platform

for use on smart cards and other devices whose
environments are highly specialized, and whose memor y
and processing constraints are typically more severe than
those of J2ME devices. Smart cards are very useful in the
areas of personal security. They can be used to add
6
authentication and secure access to information systems
that require a high level of security.

The Java Card technology specification consists of three parts:

• The Java Card Virtual Machine specification, which defines a

subset of the Java programming language and a VM for smart
cards.

• The Java Card Runtime Environment specification, which further

defines the runtime behavior for Java based Smart cards.

• The Java Card API specification, which defines the core

framework and extension Java packages and classes for smart card
Applications.

Figure 1: Java Card enabled Smart Card

7
 1.6) Users: The potential users of the system will be:

• Citizens of the Country: Permanent Residents, Non

Resident Indians (NRIs), Immigrants. They may be-

Cyber Users

Non Cyber Users

• Government Agent

• Administrator:

State level Administrators

Central Administrators

1.7) References:
• IEEE SRS Format
• Sample SRS available on TGMC website.
• Unified Modelling Language User Guide, 2 n d Edition by
Grady Booch, James Rumbaugh, Ivar Jacobson.

2) Overall Description:

2.1) Detailed Description of project: Whole project can

be described in four phases-

a) Registration Process
b) Unique ID Generation
c) Card generation & Delivery
d) Updations and Maintenance

We will briefly describe all phases here.

a) Registration Process:

• A website will be maintained for users.

• Cyber user will fill his general information on
registration form available on website and request
for UID.
• An application no. will be generated automatically
and he/she will also be informed about venue and

8
 date for further processing. Application no. will be
in the format- CCCCCCSSSSSS , where CCCCCC is
centre code and SSSSSS is serial number.
• Cyber user will go to nearest registration centre
with necessary documents for biometric enrolment,
photograph capturing and for signature. Registration
centres are generally local bodies.
• Cyber user can check his application status any time
on website.
• Non-cyber user will go to nearest centre, where
government agent will fill all his information and
capture his biometrics.
• Multiple fingerprints will be taken for biometric
enrolment.

b) Unique ID Generation:

• Administrator will process the requests.

• To avoid duplicity Administrator will match the
fingerprints of user with database of fingerprints
with corresponding DOB and gender combination.
If the person already enrolled, then his application
will be rejected.
• A unique ID will be generated for new user.
• Unique ID will be in following format-
CCCCCCCC SSSSSSSS

It is 16 bit number. All bits are alphanumeric. First

6 bits are corresponding to centre code, which user
has chosen. These 6 bits are- 2 bits for state code, 6
bits for Area pin code. Last 8 bits are serial
number.

E.g. Of UID- RJ304024 34431267

c) ID card generation and Delivery of card:

• All biometric information and UID will be stored

in microprocessor chip of smart card, and all
additional information will be printed on smart
card. For this purpose a smart card writer will be
used.
9
 • Security will be implemented in card using
cryptographic technologies.
• Card user will be informed about the card and user
will collect the card from the centre.

Figure 2: Sample Unique ID card.

• A sample ID card is shown in figure 2. This is for

permanent resident of India. For Immigrants and
NRIs card colour will be changed to distinguish
them. For Children, photo, signature and
biometric are optional.

d) Updations and maintenance:

• User can edit his profile and request for

updations.
• Updations request will be sent to administrator,
where it will be verified and accordingly action
will be taken.
• Card will expire after a certain time period
(generally 5 years). After that, card will be
renewed.
• Card may be changed before the time period in
case of updations, card lost or card tempering, etc.
• In case of card reissue, previous card will be
blocked.
• User can get help about all these through website
or help desks on registration centres .

10
2.2) Hardware Interface:

Client side: Computer Machine with following

specification:

- Minimum Pentium II processor at 500 MHz

- Minimum 64 MB RAM.
- Minimum 1 GB of free Disk Space.

Government Agent Side:

• Computer Machine with following
specification:

- Minimum Pentium IV processor at 500

MHz
- Minimum 2 GB RAM.
- Minimum 80 GB of free Disk Space.

• Finger Print Reader (TouchChip) with

following specification:

- FAR: The False Acceptance Rate (FAR,

also called False Match Rate or FMR)
states the percentage of instances that a
non-authorized individual is falsely
accepted by the system.

- FRR: The False Rejection Rate (FRR,

also called False Non-Match Rate or
FNMR) states the percentage of
instances that an authorized individual is
falsely rejected by the system.

FRR and FAR (or FNMR and FMR) are

diametrically opposed. Therefore, raising the
FAR will lower the FRR and vice-versa.
Accordingly, FRRs and FARs can be adjusted
to fit the requirements of the entire securit y
system. TouchChip device provides five
security levels that allow adjusting the FARs
and FRRs to reach desired results.

11

Administrator Side:

• Smart Cards with following specifications:

- Microprocessor based IC cards with

contacts and with a minimum of 16
Kbytes available EEPROM.
- Complaint of SCOSTA and ISO/IEC
7816-1, 2 & 3.
- Supply voltage 3V nominal.
- T=0 and T=1 Transport Protocol.
- Minimum 10 yrs data retention.
- Min 300,000 EEPROM write cycles.
- Operating ambient temperature range -25
to 70 degree Celsius.

2.3) Software Interface:

Client on Internet: Web Browser (any), Operating System

(any)

Government Agent Side: Web Browser (any), Operating

System (any)

Web Server: WAS, Operating System (any)

Data Base Server: DB2, Operating System (any).

Development End: WSAD (J2EE, Java, Java Card, Java

Bean, Servlets, HTML), DB2, OS (Linux), Web Server,
SDK of Hardware devices (TouchChip and Analogic).

2.4) Communication Interface:

• Client on Internet will be using HTTP/HTTPS protocol.

• Administrators on Intranet will be using TCP/IP protocol.

12
2.5) Functional Requirements:
The functional requirements of the project will be:

A website will be maintained which has following

features-
- Home Page (Provide general information
and links).
- Registration form.
- User Accounts(sign in and user profiles)
- Admin accounts
- Guidelines
- Frequently asked questions (FAQs).
- Help, Trouble Shooting and Contact links

Cyber Users can apply for UID online via online

application system.

Online application system will generate an application
number for cyber user and fix his appointment with the
government agent for further processing.

Government agent will take the related documents and
biometric information of an individual at the registration
office and store it in a centralized database. He will also
perform the identification of the user.

Non-cyber user ma y directly go to registration office,
where government agent will complete all formalities
through his account.

Cyber users can apply for re-issuing of lost/stolen smart
card, request to update his information like present
address etc. through online application system.

The user can search all the registration offices in their
proximity location.

It will provide authentication of an individual to all the
other national services like passport offices, ration cards,
polling etc.

Administrators will also be authenticated before the y
access the database or any other services.

Synchronization of data of all states into one centralized
database.

Backup of central database on other remotel y located
secure servers.

High level of security to the collected biometric
information.

13
2.6) UML Model Survey:

Figure 3: Use Case Diagram

14

Use case diagrams model the functionality of the system using use
cases and actors.

Use cases are the services or functionalities provided by the

system.

Actors are the users of the system.

There are three actors in the diagram:

I. General user or client:

A user is going to perform following functions-

• Request for unique ID and card generation

• Fill up the form which will provide necessary
information about him.
• He can login to his account and can update profile, can
apply to block his lost/stolen card and reissue of the
same.
• Goes to the registration centre for giving his biometric
sample, photograph and other documentary proofs.
• Collect card from government agent on due date.

II. Government Agent:

Government agent will perform the following tasks-

• He will process all type of requests coming from the user

and will verify the records accordingly.
• On the basis of identification result he will reject or
approve forms.
• Information of approved forms will be added to the state
level database and central database.
• On biometric identification centre he will capture and
store biometric information of an individual.
• He will issue card to the individual.

15
III. Administrator:

Administrator will do the following tasks-

• He will provide online account to the user and at the

time of sign in by the user, will verify his records.
• Maintain the server side operations.
• Can fetch or update database.
• Will order for card generation.

2.7) Architecture Diagram:

Figure 4: Architecture Diagram

16
2.8) Database Design:

System
Actor
UID
Administrator User Agent
Password

System User USER_ID

Permission
uses has
First_Name UID
Permission
Middle_Name
_ID
Last_Name Password
Father_name
Nearest_centre
Sys_Card Gender
Biometric_ID
UID
SID
Biometric_ID Centered
System

Registration Lost/Found uses User_Data National State

Level Level
Agent_centre

Figure 5: Entity Relationship Diagram

2.9) Assumptions and Dependencies:

Administrator is created in the system already.

Roles and tasks are predefined.

All fraud cases will be handled by the government.

Non cyber users will be informed manually about the

status of card.

17
3) Specific Requirements:

3.1) Use Case Report:

• User Request Subsystem:

Name of use case: Request for UID

Description: An online website will be maintained for the users. Cyber

users can apply for UID through the web site. On their request a
registration form will be generated. On the successful submission of the
form, cyber users will be allocated particular time slot to go and submit
their biometric sample and other documentary proofs at registration
centre.

Non cyber users (Users that do not have access to the internet) will have
to go to registration centre in order to apply for UID. Government agent
in the office will fill up his/her form and will collect the biometric
samples and other related documents. They will be given an application
number for future reference.

The information for UID of people residing in the rural remote areas
(villages where less than 20 families reside and people of such are
deprived even of the basic facilities) will be collected by Personnals in
the offline mode and will be given to the government agent to be
uploaded in the Database.

18
Pre –condition: Cyber users must have access to the internet and the non
cyber user need to go to the nearby registration centre.

Name of use case: Fill up the form.

Description: After the request for UID, the users will be asked to provide
their details through the registration form available on the website/with
the government agent. They will be required to fill the following fields in
the registration form-

• First Name
• Middle Name
• Last Name
• Father’s Name
• Date of Birth
• Permanent Address
• Password for online account
• Gender
• District
• State
• Code of nearest registration centre.

In addition to the above fields all users need to provide the Photograph
and Biometric sample (fingerprint in this case) at the registration centre in
the presence of the Government agent.

The cyber users will fill the form online on website and an application
number will be generated for them and will be allotted a time slot (date,
registration centre and time) to provide their biometric information and
prove their authenticity.

The non cyber users need to go at the nearest registration centre to fill up
the form (government agent will fill up their form) and will provide their
biometric information at the same time. No time slot will generated for
them. After the successful completion of application they will be given an
application number for future reference.

In the case of people residing in the remote located areas the Personnal
will go to their place and will fill their whole information in form in
offline mode and will capture their biometric information on the spot
only. This offline information will be uploaded in the database.

19
Pre-condition: User has already requested for UID.

Normal flow of events:

• Biometric Identification Subsystem

20
Name of Use case: Go to centre.

Description: Cyber users after filling the form successfully

will go to the allotted registration centre on the allotted date
and time for giving their biometric information and prove their
authenticity.

Non cyber users will give their biometric information at the

time of registration only.

Pre-Condition: Users has applied for UID.

Name of Use case: Biometric Identification Centre Processing.

Description: On the arrival of the user in the registration

centre the government agent present their will take the
photograph, signature and the biometric information of the
user. The biometric information taken here will be used for the
identification and authentication purpose of the users.

The biometric information taken here for the identification and

authentication purpose will be the fingerprints of the user.
Fingerprint biometric is chosen over other available
biometrics because of the following reasons-

- It is the oldest and most commonly accepted form of

biometrics ,
- It is widely regarded as a unique human characteristic.
- Fingerprints have been used for verification and
identification purposes for thousands of years. Both the
United States and Europe began documenting the use of
fingerprints for identification and verification over a
hundred years ago.
- The advantage of fingerprint biometrics over other
biometric methods lies in its proven accuracy, reliability,
convenience, user acceptance and familiarity.

Pre-Condition: User has applied for UID.

21
Name of the use case: Capture fingerprint

Description: The government agent present in the registration

centre will capture the fingerprints of the user using the
TouchChip fingerprint sensor. The captured fingerprints will
be converted into the templates using the appropriate
algorithm and will be stored in the main database for the
purpose of identification and verification. These templates
cannot be converted back into the image. The raw image of the
fingerprint will be stored in the separate database with high
level of security and serve the purpose for other government
projects.

The overall process of fingerprint image capturing is

explained below with the help of diagram:

Figure 6: Fingerprint Capturing

When a three-dimensional fingerprint is applied to the sensor window of

a TouchChip fingerprint reader, the fingerprint is scanned, and a gray
scale fingerprint image is captured. All fingerprints contain a number of

22
unique physical characteristics called minutiae, which include certain
visible aspects of fingerprints such as ridges, ridge endings, and
bifurcations (forks in ridges). Minutiae are mostly found in and around
the core of a fingerprint, located about half-way between the fingertip and
the first joint of the finger.

Figure 7: The positions of fingerprint cores on different fingerprints

A user's fingerprint is enrolled, or registered, after a proprietary algorithm

(PerfectMatch algorithm from TouchChip in this case) extracts unique
minutiae points from the fingerprint image (see Fig. 8). The extracted
minutiae are then converted into a unique digital template comparable to
a 60-digit password. This template is then encrypted before being stored
in a database on a computer, a card, or other form of storage.

Figure 8: Example of minutiae

23
The process of enrollment takes at least two samples captured
from the same finger before that finger is considered
registered. When a finger is scanned for matching, the
fingerprint reader captures an image, and that image is
converted it to a template and compared to the registered
fingerprint in a template form. The fingerprint will be enrolled
if and only if it does not match any other fingerprint in the
database.

Pre-Condition: User has applied for the UID. Fingerprint

sensor is working properly.

Normal flow of events:

24
 • Card Collection Subsystem

Name of the use case: Collect card

Description: Once the user has been authenticated through his

biometric information and other documents, the UID card for
the user will be generated. The status of which can be checked
online through the website. Now, he needs to collect that card
from the registration centre by producing his application
number. The user will be verified before handling the card to
him, thus, assuring that right person gets the card.

Pre-condition: Card is generated and is reached the

registration centre.

Name of the use case: Acceptance testing

Description: User on receiving the card will check whether

card is working properly or not by seeking the help of expert
present in the particular individual centre.

Pre-condition: Card must be generated.

Name of the use case: How to use.

Description: The expert present at the particular registration

centre will tell the basic features of card to the user and will

25
teach him how to use the card. He will also tell him the
precautions to be taken while using the card.

Pre-condition: Card must be generated and should be working

properly.

Normal flow of events:

26
 • User Account Subsystem

Name of use case: Sign in to account.

Description: Cyber u ser can sign in to his online account

provided at the time of registration with his UID as a user ID
and password that he provided at the time of registration. This
account enables him to access the various online services
provided by the UID department.

Pre-condition: User should have UID and password with him.

Name of use case: Check status.

Description: After singing in the account user can check the

status of his UID card. In the case card is issued to him, the
status will be “Issued”. If user has requested to block his card
due to lost/theft then the status displayed will be “Temporary
Blocked” and if the user had been authenticated and his new
card is generated then the status will be “Old card is blocked
and the new card is issued”.

Pre-condition: User should be logged into the account.

27
Name of use case: Update Profile.

Description: In the case user wants to update his/her

information like the change in permanent address etc. then the
cyber users can make these changes by using their online
account. The changes will be made permanent only when the
user will go to the registration centre on the allotted date and
authenticates him. It is an extended use case so behaviour of
this use case is not necessary. Non cyber users will be
required to go to registration centre in order to update their
profile.

Pre-Condition: User should be logged in.

Name of Use case: Reissue Card

Description: If the user’s UID card is lost or stolen then he

can apply for blocking the lost/stolen card and reissue of new
card to him through his online account. When user will apply
for the reissue of the lost/stolen card, initially his card will be
temporarily blocked by transferring the combination of his
UID and Smart Card No. (SID) in to the blacklisted database
and status of his card will be changed to the “Temporarily
Blocked”. The new card with the same UID will be reissued to
him only when he will go to the registration centre on the
allotted date to verify himself. The verification process is
explained below:

Figure 9: Biometric Verification Process

28
In the verification process the biometric image is again
captured. The unique characteristics are extracted from
biometric image to create the user’s “live” biometric template.
This new template is then compared with template previously
stored and numeric matching score is generated, based on the
duplication between live and stored template. On the basis of
this score the user is verified. If this score equates or exceeds
the threshold value (specified by the system designer) then the
user is verified otherwise the user verification fails.

In this case the user’s UID and live biometric image will be
taken and this live template will be matched to the template
stored corresponding to the UID. If it matches then the user is
verified.

Pre-condition: User should be logged in.

Normal flow of events:

29
 • Request Processing Subsystem

Name of use case: Process all requests.

Description: All the requests made by the users whether it is

the registration request or the reissue card request will be
processed by the government agent. He is sole responsible for
taking the biometric information of the user and authenticating
them.

Pre-condition: There is some pending request from user side.

Name of the use case: Verify user entered details.

Description: To process a request, government agent will open

the form filled by the corresponding user and will verify and
validate the details through the documents provided by the
user.

Pre-condition: User has filled up the form.

Name of the use case: Inform customer.

Description: In case of rejection of form, the user will be

informed to fill the form again by correcting the wrongly

30
mentioned things. If the form is approved then also the user
will be informed.

Pre-condition: Form is already verified by the government

agent or system.

Name of the use case: Add record to the database.

Description: Once the system or government agent has

verified and validated the forms and captured all the necessary
information, the information of these records will be uploaded
into the database. Initially, all the information will be added
in the State level database and then it will be synchronized
into the Central database.

Pre-condition: Form is already verified and validated.

Normal flow of events:

31
 • Card Generation Subsystem

Name of the use case: Card generation

Description: After all the information of the user has been

taken and the user been authenticated by the government
agent, the information of the user will be added into the State
level database. Administrator will initiate card generation
process. He will retrieve the UID and biometric template of
the user from this State level database and will write it to the
EEPROM of SCOSTA compliant smart card using the Analogic
Smart Card reader. He will also write a smart card number
(SID) to the smart card.

Pre-condition: Approved requests are in queue.

32
Name of the use case: Access database

Description: While writing the information on the smart card,

administrator will be required to fetch essential personal
details of the user like his UID and biometric template from
the State level database. The administrator needs to
authenticate himself before accessing the database. This
authentication of the administrator is achieved by taking his
biometric sample (fingerprint) as the password and his UID as
the user ID for login. If both things match then the
administrator is allowed to access the database.

Pre-condition: Card generation process is going on and

administrator is verified for database access purpose.

Name of the use case: Biometric Processing

Description: Administrator will process biometric data to

write it on the card and will apply encryption and other
security features on it before writing it to the smart card. After
applying the sufficient security measures, administrator will
write the processed information on the smart card.

Pre-condition: Biometric data is available and card generation

process is going on.

Name of the use case: UID Generation

Description: Administrator will fetch the Unique ID of the

user from the database and will apply various security
measures like encryption and others on it. After all this
processing, administrator will write UID on the smart card.

Pre-condition: User is already authenticated and there is a

request pending in the database.

Name of the use case: Write on the card

Description: Administrator will write all the essential data on

the smart card using the Analogic Smart Card Reader. Various
security measures will be applied to the smart card in order to

33
make it tamper proof like freezing of memory locations, three
pass authentication etc.

Pre-condition: All the essential data is generated in the card

generation process.

Normal flow of events:

34
 • Maintenance of the system

Name of the use case: Maintain database

Description: Administrator will maintain the database in the

case of any updations and deletions. He will take care of
synchronizing the state database to the central database and
will be responsible for the security of the database.
Administrator will also maintain the Server and will take care
of the traffic on the server.

Pre-condition: None

3.2) Flow Charts:

I.) For Users:

1. Non cyber users can directly interact with

personnals who just take away information from
citizen and just update information through user
agent in registration office.

2. Cyber users can search through website about

registration office and can apply for UID.

3. The information gathered at registration office

about citizens is firstly processed to identify the
duplicate issue of UID. If there is any duplicity,

35
 then user is informed through e-mail or personnals.
If not, then continuation of process is there.

4. The information is authenticated manually. If it is

authenticated information, then step 5 is processed
else citizen is informed.

5. The application is then processed so that UID is

generated.

36
II.) For User Agent:

1. User Agent finds out online application from citizens.

2. Authentication of information from user should be

there manually.

3. If authentication fails, inform citizen about it else

process step 4.

4. Make formal appointment of citizen, ask them for

biometric information.

5. Generate UID for the citizen of same application

number.

37
 III.) For Administrator:

1. Application for lost/updation is registered in database

by users.

2. Search for UID takes place. If no UID is there reject

the application.

3. If the UID is correct, then appropriate process for

authentication of this application takes place. If
authenticated then changes takes place else user is
informed about rejection.

3.3) Supplementary Requirements:

Have hours of operation that are 24x7 - Because system

can be an automated process, so it can stay open for 24
hours a day. If the base is now the entire world, staying
open 24 hours a day becomes critical. System is required
to be available 24X7 so UPS support must be on server
site for at least 8 hours in case of power failure. System
will remain inaccessible to users at 2:00 to 4:00 am for
backup and maintenance purpose.

Reduce the cost of a Searching - To the extent that one

can automate the search process through this system, one
can start to reduce the cost of that searching.

Make the existing Website more dynamic in nature -

Many early Web implementations consisted of static
HTML pages. This becomes very difficult to manage if
the number of pages gets too large. An effective system
should be largely dynamic taking advantage of
technology that automates this process rather than
relying on manual processes. Application should serve
dynamic user based customized web pages to its clients
from server.

38

Tie the existing Web site into existing enterprise
systems – Any existing Web site that relies on the
manual duplication of data from another system is one
that can be improved. Most of the business data in the
world today exists in enterprise servers that can be
connected to the Web servers to make this process far
more effective.

Provide good performance and the ability to scale the

server – The Web Application Server should provide
good performance and the ability to manage performance
with techniques, such as support for caching, clustering,
and load balancing.

Providing session management capability - Web

application developers should not spend valuable time
worrying about how to maintain sessions within the
application. The Web Application Server should provide
these services.

3.4) Legal and Privacy issues:

Privacy is a key concern as all of an individual’s personal

information will be stored in one database where the possibility of
corruption and exploitation of data is far greater than when having
the information disbursed.

Risks that arise from this centralization include possible errors in

the collection of information, recording of inaccurate data,
corruption of data from anonymous sources, and unauthorized
access to or disclosure of personal information.

It should not violate fundamental right of privacy on a broad level.

Although somewhat it may be compromised as it is the matter of
national security.

It should not violate any other international or domestic laws.

39