Service Oriented Architecture (SOA) Recommendation for ...

`1‘To-Be’ & Functional Requirement Specification Report

State Mission Mode Project, Uttar Pradesh

Department of Information TechnologyGovernment of India

Department of Information Technology

29 November 2007

‘T0-Be’ & FRS Report – Pilot e-District, U.P.

TABLE OF CONTENTS

Executive summary…………………………………………………………………………………………….3

I Critical Elements – To-Be Process Design………………………………………………………5

II Suggested Enterprise Architecture using SoA approach………………………………6

III Service Components – To-Be Process & FRS………………………………………………24

Information Dissemination Form Availability Application Receipt Payment Verification Rejection Approval Delivery/ Collection Status Monitoring Workflow

o Certificateo Public Distribution System (PDS)o Revenue Courto Grievance

IV Next Deliverable…………………………………………………………………………………………118

Annexure 1. Legends of Cross Functional Process Map

2


Executive Summary

The business process re-engineering requirements report was

submitted to the state government on November 23, 2007. Based on

the framework in the report, TO Be Process Maps and the Functional

Requirements Specifications for four service categories viz. Revenue

Court Services, Certificate, Grievance Redressal and Public Distribution

System have been prepared. This would form the base document for

the implementation partner to work for development of the application.

A overview of the technology architecture has been presented that the

proposed application would be built upon. It about various technology

layers of the application that the user would interact while accessing

the database. The standard technical specifications of the components

that serve as the building block of the architecture have been

provided. During the preparation of application architecture standards

specified in the e District guidelines have been strictly adhered.

The proposed service flows have been explained with the help of TO BE

process maps. These process maps capture the roles of various

stakeholders as well as the flow of information and documents from

one level to another. It also explains how the different components

interact with the system for delivering the requested service in a

timely and an efficient manner. A set of 11 components which were

specified in the BPR report have been used to facilitate the service

delivery.

The components are linked with the ‘To-Be’ processes so as to provide

a consolidated delivery of the services under the e-District Project. The

streamlining of the front end, channels of delivery, service components

and ‘To-Be’ process will provide comprehensive service delivery

3


mechanism for better delivery of services to the citizen / customer.

Further, it will improve upon the internal efficiency of the delivery

(departmental) and at the same time will aid and assist in monitoring

and reporting of the services.

The proposed Functional Requirements Specifications (FRS) in this

document deals with the application’s intended capabilities and

interactions with the users. The proposed FRS also mentions the

functional aspects that the application needs to have to support the

various requests that the users might require from the system. The

FRS takes into account the various scenarios that the application might

have to face during service request reprisal and also it specifies how

the system will integrate with the various components specified in the

BPR report.

The report has been structured in way to cover the architectural

framework to support the e district application, and then it explains the

service components which serve as the building block for defining the

To Be processes. The To Be processes thus helps to identify the various

processes that would be re engineered using the components. The

various To Be services will then help to specify the functional

requirement that would go into the application development.

The To be and FRS report would be prepared in two sections, in the

first part it would cover a total of 4 service categories and the

remaining 6 services would be covered in the consolidated report that

would be submitted on December 12, 2007.

4


Critical Elements – To-Be Process

This report primarily aims at providing the To-Be Process maps for the

selected services and highlighting the major processes improvements

undertaken by using the accepted solutions as mentioned in the BPR

report.

The ‘To-Be’ Processes are based on generic solutions as proposed in

the BPR report. A mention of the same is being provided for general

understanding of the reader as these solutions are used for developing

the process maps for all the identified services –

1. Use of security feature of login ID and password

2. Use of biometric authentication mechanism as additional security

measure

3. Use of online form for making service request

4. Use of digital signature for highly securing approval, rejection

and transfer of documents

5. Use of website as a tool for verification of output against service

request

6. Use of application databases as defined in the services

7. Use of unique ID schema like document ID, CSC ID, etc as per

requirement of the service

5


6

Part I

Suggested Enterprise Architecture for UP e-district


Enterprise Architecture Recommendation for UP e-District

Service Oriented Architecture (SOA) Recommendation for

Overall Architecture

Architecture is preferred to be ‘Service based architecture’. The

granularity of web services is to be determined by the level of

interaction in each of the processes as defined. This architecture is

intended for use during the creation of a technical SOA road map for

UP e-District. It helps in identifying the gaps in the current environment

and the target SOA-based infrastructure. The architecture serves as a

good reference for the projects that require development of reusable

SOA frameworks. Mapping the logical architectural layers to a product

matrix will assist in determining the SOA-related products required for

use in projects.

In order to ensure that the information is correct, current, and securely

accessed, a publish/subscribe architecture is envisaged for eDistrict.

This will permit Publishers to securely make available well defined web

services and message based services by way of a Service Oriented

Architecture (SOA) mechanism which can also be orchestrated and

customized by the publisher.

7


Loosely – coupled: It is highly recommended that the proposed

solution for UP e-District ensures that the Publishers are loosely

coupled to subscribers, and need not even know of their existence.

With the topic being the focus, publishers and subscribers are allowed

to remain ignorant of system topology. Each can continue to operate

normally regardless of the other.

Scalability: It is also recommended to use the Publisher/Subscriber

provides the opportunity for better scalability/granularity than

traditional client-server, through parallel operation, message cashing,

and tree-based routing.

Brower-Based Solution: The proposed solution MUST be a browser-

based solution.

The proposed system is envisaged to have an architecture consisting

of typically, the following layers (or substantially equivalent) layers in

order to cater for the desired business functions stated in this

document.

For explanatory purposes, explanations of the layers of non SOA & SOA

are given below:

Non-SOA-specific layers: Existing layersUP e-District's IT infrastructure has systems built in various

architectures and methodologies. The systems are Web-based,

desktop-based, pure backend systems, or any other kind of

8


application. The entire exiting system infrastructure can be broadly

classified into three tiers: data tier, business tier and presentation tier.

Enterprise data layer: Data tier

The enterprise data layer is the enterprise's datastore. All data

requirements for successful business operations are part of this logical

layer. The data includes database information, file systems,

hierarchical directories, legacy storage systems and all other storage

media. This layer is the data tier of the traditional N-tier architecture.

The data layer of the application provides clustering capabilities for

failover and high availability at data center. The data stored in the

database server can be retrieved as an XML document and the

application can communicate this information with any system

following open standards.

The UP e-District applications shall be hosted at the e-District Data

Centre. It will be accessed by CSCs via the internet.

The solution at the Citizen Service Center should have the capability to

work in both online as well as offline mode ensuring that citizens can

continue with their transactions irrespective of the connectivity with

the datacenter or the connectivity of the datacenter with the

departmental server

Enterprise business layer: Business tier

The enterprise business layer consists of the business applications

(and logic) that exist in the enterprise. It includes applications (and

logic) developed using .Net, Java Enterprise Edition, and various other

technologies. The logic in stored procedures is also part of this layer. In

short, this layer is the enterprise's existing business backbone and the

traditional N-tier architecture's business tier.

The Business Logic of the UP e-District application will be processed by

the Application Server and Integration server deployed at the

Datacenter. The application server processes the transactions

9


submitted by the operators of the centers and appropriately updates

the relevant department databases.

Enterprise front-end apps/channels: Presentation tier

All business front-end applications and channels are part of this third

layer, including the entire desktop and Web-based front ends that work

with the enterprise backbone. The business channels include external

business-to-business interface systems like dealer access systems and

address verification systems. This layer constitutes the presentation

tier of traditional N-tier architectures. Due to an increasing

convergence of standards, such as Web Services for Remote Portlets

Version 2.0 and other technologies, that seek to leverage Web services

at the application interface or presentation level is now being

considered to be within the scope of SOA. It is also important to note

that SOA decouples the user interface from the components, and that

you ultimately need to provide an end-to-end solution from an access

channel to a service or composition of services.

SOA-specific layers: Existing layers

Operational systems layer. This consists of existing custom built

applications, otherwise called legacy systems, packaged applications,

and older object-oriented system implementations, as well as business

intelligence applications. The composite layered architecture of an SOA

can leverage existing systems and integrate them using service-

oriented integration techniques.

Enterprise components layer. This is the layer of enterprise

components that are responsible for realizing functionality and

maintaining the Quality of Service (QoS) of the exposed services.

These special components are a managed, governed set of enterprise

assets that are funded at the enterprise or the business unit level. As

10


enterprise-scale assets, they are responsible for ensuring conformance

to Service Level Agreements (SLAs) through the application of

architectural best practices. This layer typically uses container-based

technologies such as application servers to implement the

components, workload management, high-availability, and load

balancing.

Services layer. The services the business chooses to fund and expose

reside in this layer. They can be discovered or be statically bound and

then invoked, or possibly, choreographed into a composite service.

This service exposure layer also provides for the mechanism to take

enterprise scale components, business unit specific components, and

in some cases, project-specific components, and externalizes a subset

of their interfaces in the form of service descriptions. Thus, the

enterprise components provide service realization at runtime using the

functionality provided by their interfaces. The interfaces get exported

out as service descriptions in this layer, where they are exposed for

use. They can exist in isolation or as a composite service.

Business process composition or choreography layer.

Compositions and choreographies of services exposed in Layer 3 are

defined in this layer. Services are bundled into a flow through

orchestration or choreography, and thus act together as a single

application. These applications support specific use cases and business

processes. Here, visual flow composition tools can be used for the

design of application flow.

Integration (ESB) Layer: This layer enables the integration of

services through the introduction of a reliable set of capabilities, such

as intelligent routing, protocol mediation, and other transformation

mechanisms, often described as the Enterprise Service Bus (ESB). Web

Services Description Language (WSDL) specifies a binding, which

implies a location where the service is provided. On the other hand, an

ESB provides a location independent mechanism for integration.

11


QoS Layer: This layer provides the capabilities required to monitor,

manage, and maintain QoS such as security, performance, and

availability. This is a background process through sense-and-respond

mechanisms and tools that monitor the health of SOA applications,

including the all important standards implementations of WS-

Management and other relevant protocols and standards that

implement quality of service for a SOA.

Recommended Framework for SOA

We proposed UP e-District project team to carry out TOGAF (The Open

Group Architecture Forum) approach which provides a valid framework

for SOA. Using the ADM (Architecture Development Method) approach,

SOA can be implemented.

For the clarification, we are listing down all the phases of ADM:

12


The eight iterative phases are as follows.

Architecture Vision: Creating a summary of the architecture and

what it should achieve, for communication throughout the enterprise

(and to obtain approval and funding). The Architecture Vision phase

will set out the scope of the SOA project within the enterprise, and the

level of SOA to be achieved.

Business Architecture: describing the product and/or service

strategy, and the organizational, functional, process, information,

and geographic aspects of the business environment, based on

business principles, business goals, and strategic drivers. The

Business Architecture phase of an SOA project may, as well as

13


describing specific business operations, describe methods for

developing new ones.

The scope of Business Architecture is as follows:

Information Systems Architectures, comprising:

Data Architecture: defining the major types and sources of

data necessary to support the business. The Data Architecture

part of the Information Systems Architectures phase is

concerned with the Business Information component.

Applications Architecture: defining the major kinds of

application system necessary to process the data and support the

business. The Applications Architecture part of the Information

Systems Architectures phase is concerned with the Software

Services component.

When TOGAF is used to develop solution architecture, this phase may

identify specific application components; but when it is used to develop

14


a high-level enterprise architecture it will often just describe general

application areas.

Technology Architecture: delivering a specification of the

technical solution at the level necessary to support implementation.

Like the Information Systems Architectures phase, the Technology

Architecture phase must also consider how the new services will

interwork with existing applications that will not be converted to

services.

Opportunities and Solutions: generating an overall

implementation and migration strategy by evaluating

implementation options, identifying parameters for change, and

assessing dependencies, costs, and benefits.

Migration Planning: sorting the various implementation projects

into priority order and creating a detailed Implementation Plan and

Migration Plan.

Implementation Governance: developing and operating a

process to ensure conformance with the defined architecture by

implementation projects. SOA Governance is the application of

Enterprise Architecture, IT, and Corporate Governance to Service

Oriented Architecture.3 The SOA Governance processes focus on

governing the service lifecycle, supporting service infrastructure,

and compliance with the service oriented architecture of the

organization

With SOA, it is generally the case that each part of the enterprise

depends on services provided by other parts. This helps to improve

the overall efficiency of the enterprise, and allows for greater

service re-use, and should therefore be encouraged. But it means

that good governance is essential, so that the service users are

15


assured that service provision will be maintained in the manner that

they expect.

Architecture Change Management: establishing a process for

the evolution of the new enterprise architecture in the light of

developments in technology and changes in the business

environment.

Modification of the architecture itself is addressed in the

Architecture Change Management phase. SOA delivers agility.

Changes to services and development of new services should no

longer be regarded as changes to an architecture, when they are

carried out using methods that are part of that architecture. Projects

that in a traditional architectural approach would be subject to

Architecture Change Management may therefore be covered by

Implementation Governance in SOA.

Best Practices & Considerations for implementing SOAThis section attempts to provide a set of concrete practices and

considerations for implementing Service Oriented Architecture. These

are some of the key areas in which practices need to be considered as

part of typical strategic SOA planning efforts:

Service Monitoring

These are few points we can considers:

Availability

a. The active availability of a service is generally defined

within its accompanying service level agreement (SLA).

Common availability considerations and guarantees

include:

i. When will the service be active and available?

ii. Will all dependencies for this service also be

available during the service's scheduled availability?

Logging

16


a. The supporting service infrastructure should store (log)

data about each service's access and usage patterns. This

data is useful for troubleshooting, monitoring, and security

control. Formal review processes may need to be in place

to ensure that logs are routinely checked. This is especially

important to raise awareness of certain usage trends that

may indicate a need for infrastructure changes (usually

associated with scalability and security measures).

Auditing

a. Auditing is the analysis and reporting of logged

information. The data collected at this stage should answer

questions such as:

i. How exactly is a service being used?

ii. Who is using the service?

iii. What do the common request and response

messages look like? (In other words, what are the

most typical content exchange scenarios?)

b. In addition to better understanding how a service is being

used, these reports will also highlight the capabilities of the

service not being utilized.

Performance Metrics

a. Performance metrics and statistics for each Web service

are kept so that services can be monitored to avoid

potential runtime issues, such as performance bottlenecks

and fault counts. It is frequently required (and

recommended) that automated notification mechanisms be

attached to collected statistics so that action can be taken

well before an infrastructure's limitations are tested.

Debugging and Tracing

a. The ability to optimize and track service activity during

development and after deployment is important, especially

for maintenance purposes. This focuses more on the

service hosting platform's ability to provide front-end tools

17


that allow for targeted investigation of specific activities (or

sub-activities) as opposed to common general reporting

features.

Synthetic (Dummy) Transactions

a. The ability to utilize of synthetic (dummy) transactions is

helpful to simulate service usage scenarios during

development, testing, and debugging phases. Synthetic

transaction modules can be configured to send periodic

service requests according to pre-defined settings.

Service Delivery

Methodology

a. A methodology practice (such as Thomas Erl's mainstream

SOA methodology) defines how a service is moved through

lifecycle stages and also establishes any new phases

required specifically in support of SOA. In addition to

shaping service logic in preparation for implementation,

these formal approaches also need to provide governance

processes in support of post-implementation management

and evolution.

Standardized Service delivery Lifecycles

a. Requirements gathering, business analysis, service

modeling, design, and other delivery lifecycle phases need

to be aligned with the service-orientation paradigm. This

does not necessarily supersede object-oriented

approaches, but the service implementation (and

especially its contract) must reflect the design

characteristics required to achieve the strategic goals

behind service-oriented computing

Service Directory

Awareness and Discovery

18


a. The service consumer must have knowledge of the

existence of the service provider and the location of its

contract. This awareness increases the overall reuse

potential within an enterprise. UDDI exposes the required

meta information in an industry standard manner. (Note

that awareness alone does not enable a service consumer

to invoke a service.)

Publish Process

a. Once a Web service is implemented, it will need to be

registered in a local service directory or registry. Formal

processes need to be in place to ensure that the

registration and the documentation of associated metadata

are performed in a consistent manner.

Subscription

a. It is ideal to allow service consumer owners to subscribe to

service directory records. If changes to the service contract

are added or should there be outages or other events

associated with the implemented service (such as a

change to billing rates), consumer program owners can

then be easily notified.

Service Owner Contact Information

a. Service consumer owners or designers of potential service

consumer programs should have the ability to contact the

owner or custodian of a service for questions and

recommendations. Especially in larger organizations, it is

best if this contact information is published alongside the

service directory records.

Documentation

a. The service registry should contain documentation to help

owners of potential service consumers better interpret the

service's capabilities. This information may exist in

separately published documents or as annotations to the

technical service contracts.

19


Rating

a. It can be beneficial for quality assurance purposes to allow

service consumer owners to rate services and provide

feedback. Typically, ratings are in response to guarantees

and promises made in an SLA as measured against a

service's actual runtime performance.

Service Level Agreements

Quality

a. A dedicated practice is often needed to ensure that a

service provider continually meets the quality contract

promised to its consumers. Carrying out this practice may

require a separate "quality assuror" and "quality broker"

role.

Billing

a. Whether a service is consumed within an enterprise or

outside of the organization, a billing structure is often

required to guarantee that the service owner (a

department or the organization itself) is compensated.

Usually, billing is based on a licensing agreement that ties

into a per consumer or even a per usage payment model.

Configuration Management

a. As each service is promoted through various environments

it needs to be configured and tested. As the number of

services increase, managing the overall configuration

management effort can be complex and will likely require

formal processes. Configuration management of services

can be much more challenging than traditional efforts.

Therefore, new practices will likely need to be developed

and configuration management implications may need to

be expressed in the SLA.

20


Exception Management

Error Trapping

a. Runtime errors need to be recorded and reported as

efficiently as possible. For example, the recorded response

times and any logged timeouts need to be monitored to

ensure that the service is kept inline with corresponding

SLA requirements.

Root Cause Analysis

a. It has become widely accepted that SOAP faults are not

that useful. An SOA infrastructure needs to be able to drill

down into the real reasons as to why a service is failing.

Often this reveals issues such as code faults and hardware

failure. With the right tools, a true root cause analysis (one

that goes beyond just the vendor runtime) can be

completed.

Notification Services

a. A services infrastructure should be able to send out

notifications when specific events are triggered. This

notification mechanism needs to be configurable so that it

can apply to individuals and broadcast groups.

Version Management

Data Contracts

a. Web services exchange data using pre-defined data

models based on XML Schema. Changes to a published

schema can therefore break the data contract and

jeopardize all existing service consumers. If data contracts

do need to be changed, a separate version control practice

may need to be in place. This is primarily in consideration

of the fact that an XML data representation architecture

will often need to be maintained and evolved separately

from the service layers that utilize its schemas.

21


Messaging and Operation Contracts

a. Service consumers are tightly coupled to the service

provider through the service interface. However, extending

a service contract without affecting existing service

consumers may still be possible. A formal process is

recommended even when just adding operations to an

established WSDL definition.

Service Endpoint

a. The service consumer is tied to the service endpoint

(address). If the address of the service changes all active

service consumers will be compromised. Therefore, a

separate endpoint or address management practice may

be required.

Policies

a. Given the absence of an industry-wide policy expression

language (cross-vendor implementations of WS-Policy still

seem a distant reality), documenting and attaching policies

to the technical service contract in a standardized manner

can prove difficult. A common approach is to define

policies as part of the accompanying SLA. Though the

policies may be required, the SLA can often just request

that service consumers adhere to policy rules. The

enforcement of this practice sometimes requires that the

service consumer owner sign a contract (or the SLA

document) guaranteeing that all policies will be honored.

Internal Dependencies

a. A service may be implemented using numerous proprietary

components, databases, and other system resources.

Changes to these underlying dependencies can raise all

kinds of runtime exceptions. Therefore, internal practices

may be required to ensure the integrity of each individual

service-level technology architecture.

Security Claims

22


a. The service provider may be secured using a common

identity technology, such as active directory roles and

users. Any security changes in the infrastructure can also

impact all consumers of a service. Changes to established

security management processes and practices therefore

become important considerations and may require formal

reviews by committees.

Service Retirement

a. Services do not live forever. When services are deprecated,

service consumer owners must be notified in time to adapt

their environments. Often this may require a graceful

expiry period during which both old and new versions of a

service contract co-exist for a pre-determined amount of

time (sometimes this period can extend up to six months).

Dependency Analysis

a. Service consumers can be classified as "known" and

"unknown" consumers. Keeping a list of all the consumers

associated with each service can simplify some versioning

issues by allowing for organized notification.

Policy and Security Considerations

Identity Store

a. An identity store is a repository of users, their credentials

and preferences. In order to access a secure service the

service consumer must be validated against these

identities. Various options exist for implementing an

identity store including Active Directory or even a regular

database. Ideally, an identity store is a standardized and

centralized part of the overall infrastructure. Practices

need to be in place to ensure it is consistently used and

maintained.

Authentication and Authorization

23


a. The ability to verify the identity and permissions of service

consumers raises a number of considerations, including

how security claims from service consumers are validated

and processed.

Exchange Policies and Contracts

a. This practice should address how policies and contracts are

exchanged between a service provider, its consumers, and

the owners of its consumers.

Internet Security

a. The issues associated with securing Internet firewalls and

Internet facing servers and ports are amplified when

moving toward a technology environment consisting of a

combination of internal and external Web services.

Practices need to be in place to ensure that acceptable

measures of security are always maintained, but also to

provide a level of adaptability in response to unforeseen

external access requirements that may be raised by newly

published services.

Usage Control and Metering

a. Understanding the usage of a service may be important for

a number of reasons. For example, we may need to bill the

service consumer on a per usage basis or we may want to

study service usage and load patterns.

Transport Security

a. Here we deal with how Web services traffic is secured on

the wire. Of course this usually involves the positioning of

SSL, but several WS-* specifications can also enter the

discussion.

Load Balancing

a. Services with heavy or unpredictable volume loads often

need to be dynamically load balanced across multiple

servers. Various types of load balancing algorithms exist

and services should be assessed individually to ensure that

24


the most appropriate type of load balancing is always

chosen. Sometimes, based on increased reuse or re-

composition, services need to have their load balancing

algorithms "upgraded" in response to new usage demands.

Geo Clustering

a. This consideration addresses issues that can arise from the

physical proximity of clustered services within an

enterprise. For example, service consumers may need to

bind to services that are geographically closest to minimize

server hops and latency issues.

Web Service Interoperability

a. While Web services are designed to interoperate, enforcing

WS-I Basic Profiles is often the only way to guarantee

interoperability, especially across disparate platforms and

organizational boundaries. When building services with

some of the new WS-* technologies and especially within

vendor-diverse enterprises, extensions or custom

variations of the WS-I Basic Profiles may need to be

created (although their usage will likely be limited to

internal, controlled environments).

25


26

Part II

‘To-Be’ Process & Functional Requirement Specification


Information

The information component is envisaged for handling the

dissemination of information only since the lack of information was

found to be a key impediment in availing of services on time and with

minimum effort. It has been observed that lack of information

regarding the processes and the supporting documents that needed to

be submitted along with the application are two of the prime factors

stalling the submission of application. Similarly, lack of awareness

about the defined service levels among the citizens results in no

appropriate action being initiated even in case of deviation.

27

Information Dissemination

Dis

tric

t In

form

atio

n

Offic

er

NIC

DIO

De

pa

rtm

en

t Prepare a document on changes to present

schemes or declaration of new schemes or rules

Send the document to local NIC DIO, and District

Information Officer

Receives the document with required updates

Updates the information on e-District Portal as per

the document

Ensures dissemination of information through various channels like Wall Paintings, Hoardings newspapers etc.

Receives the document with required updates


Figure 0-1

28


Functional Requirements

A. Information Dissemination Component

S.

No.

Functional Requirement Specification

1 E district Application is the application meant for maintaining all the

transactions related to e district services. The Information

Dissemination Component of the e District component deals with

providing information of all the services, schemes, benefits, process

and mechanisms followed by the departments in lieu of a particular

service

2 Should allow only the NIC / Department officials to update information

obtained from the departments

3 Should provide information on the following topics to the user:

Scheme Name

Eligibility Criteria

Nodes of obtaining service

Application Fees

Grievance filing process

Authorities to contact

Forms and documents required

Other modes of obtaining detailed info

4 Should be able to add new components beside the above

5 Should be accessible to citizens, department officials, other

government officials

6 Should update information only after digital signatures of the relevant

authority have been put on the document

7 Should have a ticker at the bottom of the page to record the number

of people hitting the website, this would prove beneficial in capturing

the usefulness of information

8 NIC should update the information within 2 days of receiving it from

the relevant authorities, if this system is not followed an auto

generated escalation grievance from the department should be fired

to DM.

29


Forms availability

Service inputs are accumulated with the aid of various Forms. Forms could be

in physical or non-physical format. Forms in both formats consist of various

fields of required information, which would be the basis for any process to be

initiated. In physical format, form availability becomes an important

consideration as this can depend on a variety of external factors. Lack of

availability of forms would impede the process. Non-physical or electronic

forms would address the lack of availability issue and would standardize the

fields using a system approach.

Form availability would ensure that the services can be accessed. Forms once

available with the appropriate fields will not only form the basis for accessing

any particular service, but would also be used in creating an incremental

database.

The purpose of the element as envisaged in the proposed BPR framework has

been listed below –

1. To make available the relevant form available for making service

request for the selected services

2. To standardize the format for the form pertaining to selected services

30


Application Form Availability

CS

C /

Gov

t. e

dist

rict c

entre

E-D

istri

ct A

pplic

atio

nA

pplic

ant Obtains paper based

form from Dept Office / CSC / e district portal /

Open Market

Fills the paper based application form and

submits it at the e district centre

Receives paper based form the applicant

Requests for department page at

the e district application

Selects application form section

Returns requested page

Return application form section

Fills in the details provided by the

applicant in the paper form online

Registers applicant details online

31


Functional Requirements

B. Application Form Availability

S.No Functional Requirement Specification

1The system should store all the service request form at predefined

location for the selected services

2The system should be able to retrieve service request form from

the predefined location

3The system should allow for service request form to be easily

downloadable both through HTML and word format

4The system should provide for printable version of the service

request form

5The system should give an error message in case it is not able to

retrieve the application from the given location

6The system should have a provision for uploading new version of

the forms as and when it is required to change the version

7The system should maintain the version control for the service

request form

8

The system should have a security feature embedded for

changing the version of the form and should allow only predefined

process owners to change the form version

9The system should maintain log for all version change with the

details of the process owner making version change

10The system should not allow to change the content of the form

and should be in read only version

11

The system should be able to make available service request form

should be through

Online / website

CSC

12The system should allow for easy searching of the service request

form

32


13The system should allow for easy and user friendly layout for

locating the service request form

14The system should be able to export forms in multiple formats so

as to ensure compatibility of forms

15The system should have a life counter feature to keep track of

number of forms being downloaded from the application

33


Application receipt

This Component will handle submission of the application. As the component

exits operation, an acknowledgement would be generated for the applicant

containing a unique reference ID for status tracking, date of application,

department responsible, date of delivery, information about delivery

channels, service fee receipt etc.

The receipt also helps the applicant to track the status of the application with

the help of the unique registration number provided with the receipt besides

enabling the system to uniquely identify each and every application along

with the candidate. According to BPR framework this receipt would be

automatically generated by the system thus minimizing the duplication of

effort and redundancy in the process.

34

Application receipte-

Dis

tric

t A

pplic

atio

nA

pplic

atio

nC

SC

/ S

uvid

ha

Cen

ter

Travels to the CSC / Suvidha

center.

Submits his request to the

Operator

Receives the request and opens

the relevant departments application

Fills up the online form for

the request

Takes out a printout of the completed

application form, and asks the applicant to

verify the details

If all details correct

Signs the form using his digital signature, and

submits it to the e-District application

Issues a copy of submitted

application along with a receipt to

the applicant

Signs or Puts the Thumb impression on

the hard copy and gives it back to

operator along with required fees

Schedules the Hardcopy for daily dispatch

to Tehsil or BDO.

NoReceives a

copy of application and

a receipt

Loads the online application form

Registers the request and sends it to selected authority and generates

a receipt

Proves his Identity using

Biometrics

Operator logs into the

e-District Application

Start


35


C. Application Receipt

S.No Functional Requirement Specification

1 If the citizen is submitting an application for the first time, then the

CSC operator should be able to use the e-District Application (eDA) to

register his details, which include generating his Unique ID, Name,

Address, Age, Photo, and Biometric Identity and save these into the

Citizen Database

2 The citizen should be able to establish his or her identity to the CSC

operator using his Unique ID and biometric details.

3 The CSC Operator should be able to retrieve and load the online

application forms of departments registered with the system, specific

to the request.

4 The eDA should assign an Application Number to each form loaded

and also embed the CSC Operator’s login details onto the form

performa.

5 The CSC Operator should be able to fill up the online form and take a

printout of the completed form.

6 The CSC Operator should be able to digitally sign the form and submit

the same in to the eDA.

7 The eDA should save the application form with filled in details in a

database along with CSC User ID and date and time of submission.

8 The CSC Operator should be able to take a printout of any submitted

application.

9 The Printout of the submitted application should have the Application

Number, CSC User ID, Date and Time of Submission imprinted on it.

10 The eDA should be able to immediately route the application to its

recipient department’s process owner & notify him or her of the

pending new application

36


Payments

Payment element of the proposed framework will define the overall process

of payment for the selected services under the e-district project. It will

account for the flow of funds from the collection points (i.e. CSC) to the

concerned departments where the payment needs to be deposited.



1. Provide secured and trusted process of payment collection and

deposit in the concerned departmental head for the selected services

2. Ensure exact payment by the citizen as defined for the service

37


Payment Mechanism CSC (Privately Owned)

SC

AD

epa

rtm

ent

E D

istr

ict A

ppl

ica

tion

C

SC

Registers transaction

Issues Acknowledgement

Receipt

Prints Acknowledgeme

nt Receipt

Issues receipt to applicant

Receives payment fees from citizen

Issues daily report for the number of

transactions

Receives department wise daily transaction

details

Makes Payment as per number of transaction to the department from

payment account

Receives daily transaction

details

Receives payment against the transaction from the SCA

on daily basis

Makes Transaction

38


Payment Mechanism e District Centre (Government Run Centres) D

epar

tmen

t E

Dis

tric

t App

licat

ion

Cen

tre

Issues receipt to applicant

Makes transaction

Deposits collection charges after reaching a particular amount in

various department heads

Issues daily report for the number of

transactions

Issues Acknowledgement

Receipt

Receives payment against the transaction from the

Govt. Centre

Receives payment fees

from the citizen

Receives daily transaction

details

Prints Acknowledgeme

nt Receipt

Registers transaction

39


D. Payment

S.No. Functional Requirement Specifications

1 The system should provide for and allow financial transaction

functions

2 The system should check for all details of the service request

form before initiating the payment

3 The system should enable the payment option only when all

the fields of service request forms are filled

4 The system should return back and highlight the field which

have inconsistencies / error for user to rectify the error

5 The system should retain all the information of the service

request form besides those having inconsistencies

6 The system should return back after successful checking of

the fields with the prompt of confirmation to open the

payment page

7 The system should open a new page for recording payment

details against the service request

8 The system should allow payment to be registered on the

service application request against the following –

payment against the service

payment against the dues / payments as defined under

service charter of the specific service

9 The system should record and maintain all details of payment

against a unique service application number

10 The system should be able to maintain all the payment

records in a database and retrieve the same as and when

record

11 The system should be able to open a page with declaration on

successful payment output

12 The system should able to record specific payment details on

40


the service request form after successful payment has been

made

13 The system should be such that it should allow for part

payment function

14 The system should be able to retrieve information of first part

payment during the final delivery of service output for final

payment as per the overall payment specified for service

request

Unique application number for requested service

CSC details and unique number for CSC

15 The system should be able follow the payment cycle as

mentioned above for the final payment also

16 The system should be able to maintain all records of part

payments as well as consolidated payment amount against

the service request

Only for utility services (bill payments, etc.)

17 The system should allow transaction through approved

financial instruments

Credit cards

Debit cards

18 On-line payment – The System should support online

payment, including the following fields:

Facilitate payment against dues and recoveries online

through a payment gateway interface with a bank.

Allow the user / customer to make payment only till the

last date of payment has not passed.

Facilitate automatic updation of the information on the

applicant record, upon realization of the submitted money

19 The payment function should be against specific invoice / bills

for the given services

41


20 The system should ask for the final confirmation from user

before initiating payments function

21 The system should allow for user re-verification before

initiating payment function through transaction unique ID

allocated to the user

22 The system should provide for migration to a secure payment

gateways from the portal in a secured manner

23 The system should allow predefined data / information to be

provided to payment gateways

24 The system should be able to generate unique ID codes for

every transaction

25 The system should be able to correlate and confirm

User data / information through unique ID code

generated

Payment gateway data information through Unique ID

code

26 The system should provide for confirmation of transaction to

the user

27 The system should provide for payment receipt against the

payment

28 The system should provide printable version of receipt

29 The system should not store any critical information of the

user provided on the secured payment gateway

30 The system should allow for data / information transfer / flow

to e-district application

31 The system should facilitate automatic updation of the

information on the applicant record on successful payments

made

32 The system should not allow any initiation of payment

function beyond prescribed days limit for transaction

42


The system should be able to provide user friendly

information for such transactions

33 The system should not allow for initiation of payment in case

of non availability of records of invoice / bills against which

payment function is initiated

The system should be able to provide user friendly

information for such transactions

34 The system should provide for database security

35 The system should provide for application security

36 The system should provide user friendly information wherever

required

37 The system should produce alphanumeric code for

confirmation and verification for manual user Vs.

computerized payments

38 The system should follow predefined payment rules and

regulation as defined from time to time in the e-District

application

39 The confirmatory receipt issued should have a unique

registration number against the transaction

40 The system should maintain records of such transaction for

users accounts respectively

41 The system should allow for printable version of the

confirmatory receipt for all such successful transactions.

42 The system should be able to send emails on registry value of

the user account on the payments.

43 The system should maintain all information and records of

user transaction tagged to the user account and also provide

for viewing of such information as and when required by the

user

44 The system should not allow any changes to be made by the

43


user into the following –

Past records

Ongoing transaction once confirmation on initiation of

such a transaction is given by the user

Any values maintained for such transaction

45 The system should be compatible for easy integration with

accounting and financial application either inbuilt at a later

stage into the portal or external with a interface with the

portal

44


Verification

Verification component of the BPR is going to deal with the authentication of

a particular service request. Verification process would ensure that no

counterfeit or frivolous applications are lodged in to the system also it will

help to identify and validate the right beneficiary availing the services.

Verification also helps to establish that the application meets the regulatory

and the service requirements.

The verification components envisaged in the BPR report can be broadly

categorized under two categories:

a. Physical Verification

b. Non Physical Verification

Physical Verification

There are certain cases where documentary proof doesn’t suffices the

requirement of proving an applicant genuine for availing the benefits of a

particular service. In these cases physical verification is the only medium to

prove the genuineness of the individual and to validate the information

supplied by him in the application. Though physical verification is a costly and

time consuming mechanism for proving the genuineness of a particular

individual but it also helps to capture the correct information at the particular

moment of time. Whereas the non physical verification does not guarantees

any change of information from date of last updation.

Non Physical Verification

Non physical verification component is going to deal with all such

components that help to validate applicant’s genuineness and the benefits

accrued by him by presenting the same. This kind of verification facilitates

the non-presence of the applicant at the time of service avail ness. It also

saves applicant time, money and efforts to be present at the location for

physical verification.

45


Non physical verification can be carried out with the help of the following

means:

a. Database

b. Documents proof

Using Database: The non-physical verification can be carried out using

validated databases; these databases can help to validate the applicant by

matching the details provided with the information stored in the database.

These databases eliminate the need of physical verification that was

previously carried out to validate the information provided by the citizen. The

information that would be fed into the database would be validated, cross

checked and entered by the department officials that are managing the

database.

Documents Proof: Authentic documents / copy of authentic documents

signed by authority holding important designations can also work as proofs

against the physical verification. These documents prove that the applicant is

genuine and he is the same person as proved in the documents.

46

Verification

e-D

istr

ict

App

licat

ion

Fie

ld O

ffice

rP

roce

ss O

wne

r

Returns the results of the

query

System notifies the Field Officer of a Pending Inquiry

Checks the details of the applicant in

the relevant databse

Details FoundApproves

the application

Orders a physical verification

Yes

No

Submits the application back with the verified

details

Physically visits and verifies details. Enters these details into the

Department’s Database

Links the Citizen Database with the

Department’s database

Receives the application.

Details Correct?

Rejects the application

Yes

No


Figure 0-2

47


E. Verification

S.No

.

Functional Requirements Specifications

1 The Process Owner should be able to use the e-District Application

(eDA) to query the Departmental Databases using the name or other

details of the applicant

2 The eDA should be able to retrieve various information from the

individual databases and aggregate it before displaying it.

3 The eDA should be able decode the digital signed data and display

the details of the signatory.

4 The eDA should allow forwarding of the application to another user

using digital sign.

5 The eDA should notify the recipient of the application, that a new

application is pending his or her attention.

6 The eDA should log all the electronic movements of the application

with date and time details along with the sender’s and receiver’s

information.

7 The eDA should provide an interface for the authorized Field Officer or

Database owner to create a reference entry in the Citizen Database

and thus linking the Citizen Database with the Department’s Database

8 The eDA should allow the Field Officer to enter his comments about

the verification and forward the application back to the process

owner.

48


Rejection

Rejection element of the proposed BPR framework is envisaged to meet all

the rejection related functions of concerned departments for the selected

services under the e-district project. This element allows rejecting the service

request at the defined designated levels basis predefined requirement being

not meet in the service request or otherwise also as deemed necessary the

designated authority or otherwise also. This element will also act as a

precursor for providing stated reason for rejection to the applicant.

The purpose of the rejection element as envisaged in the proposed BPR

framework has been listed below –

1. Allow designated government official to reject service request in case

prerequisite conditions are not met along with the service request

2. Allow designated government officials to reject service request subject to

their best judgment and interest of the power vested in them by the

government

3. Allow rejecting authority to provide reasons for rejection of the service

request

4. Allow requesting applicant / citizen to have valid reason for rejection of

their service request

49

Rejection

E-D

istri

ct A

pplic

atio

nA

utho

rity

Fiel

d O

ffice

r

Receives the application

Checks the details in the DataBase

Details Incorrect

Rejects the application online using digital sign

Marks the application for verification to Field

officer

YesDetails Found?

No

Yes

System registers the change and notifies

Authority

Physically visits the applicant to verify the

details

Updates the Department Data Base with all the

recorded details.

Receives request from authority to

notify Field Officer for field verification


Returns the Query results


50


F. Rejection

S.No. Functional Requirements Specifications

1 The system should allow defined users to login to the system

for reject the service request based on rejection criteria as

mentioned for the service through a valid user ID and

password

2 The system should show a login failure screen in case the

user name and password are not verified by the e-district

application

3 The system should intimate the users through predefined

channels for pending service request application on a daily

basis

4 The pending service request application should be highlighted

for the predefined process owners on entering the application

5 The pending application should be intimated to the predefined

process owners through SMS

6 The system should have a provision to mark the rejection of

service request

7 The system should have a provision where the predefined

process owner states the reason for rejection of the service

request

8 The system should open a page with marked rejected

application form and text entry provision against all the

rejected application form

9 The system should close the service request once the text

box is filled

10 The system should be able to retrieve the closed rejected

service request on the new page for digitally signing it

11 The system should allow the user the digitally sign all the

51


closed rejected service request at one go

12 The system should open a page for all rejected service

request with a prompt of digital signature in form a button to

initiate the process of digital signing

13 The system should reconfirm from the user for initiating the

digital signing before actually initiating the process

14 The system should allow the user to terminate the rejection

process at any point of time during rejection

15 The system should keep and maintain the data in a data

repository (database) for all the rejection made

16 The system should be able to keep the records of all

transaction performed and link it to the unique code of digital

signature

17 The system should open a page informing the user of

successful completion of rejection function

18 The system should open page at any point of process in case

the process termination with the request to restart the

process

19 The system should not allow the user to initiate the process of

digital signature in case of no selection of pending service

request for rejection

20 The system should not allow the user to modify the rejection

once it has been digitally signed

21 The system should not allow the user to delete any service

request pending for approval at his end

52


Approval

Approval service component of the framework is envisaged to provide for

mechanism for approval of service request. It allows the concerned

responsibility center to approve the service request through a secured

method. The approval will be linked either directly through the database. The

approving authority will use the databases to decide whether the claim made

in the application is correct or not. In case the claim is found to be verified by

the database, the authority would approve the application using his digital

signature.

The purpose of the approval service component are enumerated below –

To allow the responsibility center to approve the service request

To integrate and embed secured process through which approval will

happen

53

Application Approval

E-D

istri

ct A

pplic

atio

nAu

thor

ity

Fiel

d O

ffice

r


Checks the details in the DataBase

Details Correct

Approves the application online using digital sign

Marks the application for verification to Field

officer

YesYesDetails

Found?

No

Yes


Authority

Physically visits the applicant to verify the

details

Updates the Department Data Base with all the

recorded details.

Receives request from authority to

notify Field Officer for field verification




54


G. Approval

S.No. Functional Requirements Specifications

1 The system should allow defined users to login to the system

for approving the service request through a valid user ID and

password

2 The system should show a login failure screen in case the

user name and password are not verified by the application

3 The system should intimate the users through predefined

channels for pending approval on a daily basis

4 The pending approvals should highlighted for the users on

entering the application

5 The pending approvals should be intimated to the users

through SMS

6 The system should have a provision to mark the approval of

service request

7 The system should allow the user the digitally sign all the

selected approved service request at one go

8 The system should open a page for all approved service

request with a prompt of digital signature in form a button to

initiate the process of digital signing

9 The system should reconfirm from the user for initiating the

digital signing before actually initiating the process

10 The system should allow the user to terminate the approval

process at any point of time during approval

11 The system should keep and maintain the data in a data

repository (database) for all the approval made

12 The system should be able to keep the records of all

transaction performed and link it to the unique code of digital

signature

55


13 The system should open a page informing the user of

successful completion of approval

14 The system should open a page at any point of process in

case the process termination with the request to restart the

process

15 The system should not allow the user to initiate the process

of digital signature in case of no selection of pending service

request for approval

16 The system should not allow the user to modify the approval

once it has been digitally signed

17 The system should not allow the user to delete any service

request pending for approval at his end

56


Delivery / collection

The delivery service component of the proposed BPR framework relates to

the delivery / collection of the service output for the service request made by

the applicant. It is envisaged that this component will detail out the specifics

involved for service delivery of the listed service under the e-District project.

This will involve the use of security features like digital signatures,

passwords, etc to be employed for service delivery at the front end where the

citizen receives the output for the service request.



1. To provide output against the service request by the citizen

through a defined and secured process

57


Delivery Mechanism

e-D

istr

ict

App

licat

ion

App

licat

ion

CS

C /

Suv

idha

Cen

ter

Travels to any CSC / Suvidha

center.

Notifies the CSC & applicant that his delivery is

due

Quotes the Receipt Number

and requests delivery of document

Receives notification of

pending delivery

Enters the Receipt No. into

the e-District application

Retrieves the digitally signed

document saved against the Receipt No.

Displays the document along

with the Signatory’s information

Prints out the document and

stamps it with his seal and signs it

Receives the signed and

stamped document

Receives notification of

pending delivery

58


H. Delivery

S.No. Functional Requirement Specifications

1 The system should be able to provide delivery against all

service request made

2 The system should be able to link delivery against specific

service request through unique service application request

number

3 The system should allow delivery only when the service

request has been either approved / rejected

4 The system should allow only validated predefined users to

log into the e-district application for retrieving the delivery

against the service request

5 The system should ask for unique service request number /

unique application number to retrieve specific service delivery

6 The system should ask for the digital verification from the

authenticated predefined users

7 The system should allow downloading of the service delivery

output only after matching the digital verification

8 The system should provide for the printable version of the

service output

9 The system should be able to print the unique kiosk number,

unique application number on the every service output

generated through it

10 The system should be able to print the <url> of the site from

where the content of the service delivery could be verified

11 The system should open new page specifying error in case of

incorrect digital verification

12 The system should be able to maintain the database of the all

the service delivery output in a logical manner to ease the

59


retrieval of the same as and when required

13 The system should have a life counter to keep log of all

delivery made with specific association of unique service

application number and unique CSC number

60


Status

The objective of this component is to keep track of the service levels of the

various processes involved in a given service. This component is solely

related with status tracking from the consumer’s perspective as well as the

department/administration perspective.

Each application by a consumer will be logged against a unique reference

number generated at the time of application submission and given to the

consumer for future references and status tracking.

The purpose of having the status component is to ensure the following facets

of good governance in day to day working of the government services:

To ensure transparency in service processing by the government to the

citizen for the service request made

To establish the validity and sanctity of the well defined service level

To ensure and define responsibility and ownership of the actors

towards service delivery

61

Status Tracking

Hig

her

Aut

horit

ye-

Dis

tric

t App

licat

ion

App

lican

t

Receives notification of Status of his application

Detects changes in status of application

Retrieves the Status information associated with the

Receipt No.

Displays the document along

with the Signatory’s information

Updates the Status information associated with a

Receipt No.

If any mobile or email is registered

Notifies the Applicant about his application’s

status

Accesses the e-District Portal

through internet

Enters the Receipt No. of his application

Receives the Status of his application

Yes

If had registered mobile or email

No

Yes

If specified Service Level

exceeded

Escalates the application to

higher level and notifies him

No

Yes

Takes cognizance of the escalation

and acts as necessary


62


I. Status tracking and auto escalation

The system should have integrated auto status tracking and auto

escalation features embedded in the overall architecture of the

system

The system should keep track of all the service requests from the

citizens along with the respective reference id generated at the

time of the application receipt

The system should be available in public and administrative view

The system should be able to keep track of the status of all the

service requests with the help of the respective reference id

(application id) and map the current status with the pre-defined

service level against each process

The system should be able to highlight and auto escalate any

deviation in the service level against a given reference id

(application id) to the relevant higher authority

The system should be able to detect any change in the status of a

given reference id

In case there is a change in the status of a reference id, the

system should update the status information in the database

The system should have provisions for intimating the applicant

about the current status of his/her application through SMS

and/or Email especially if there is a change in the status with

respect to the final delivery of the service

The system should not provide details about the internal SLAs to

the applicant and only provide update about the status with

respect to the final delivery. This feature should also allow the

system to update the applicant if there is any change in the

service level of the final delivery

The system should also allow the applicant to retrieve update

about his/her service request through the web portal by entering

63


the reference id in the link provided on the portal

The system should display an appropriate message if the system

is unable to retrieve the details due to any reason like

connectivity issues, maintenance issues, etc and also provide

contact details of the system administrator and alternate link (if

available)

The System should have Side Menu on each page so as to reflect

the contents of the containing directory , making it easier to

navigate the site and locate the link for retrieving update against

a given reference id

The system should be adequate security features built in the

architecture of the system to ensure that it cannot be hacked or

manipulated

The system should not allow the users to edit the details of the

application upon retrieving the status update against a given

reference id

The System should allow the end user to print the status update

information if the applicant is retrieving the status through the

portal or email

The System should have provision for Calendar System, which

displays the dates and time of schedule events on a page

formatted as a standard monthly calendar

The system should have additional capability to integrate and

extend portals to support a vast array of mobile devices in

addition to PCs (WAP enabled)

The system should have provisions such that the System

Administrator can add/remove/modify the hierarchy of the

Government officials with adequate authentication mechanism

If there is any modification in the hierarchy of the relevant

authority against a given service (in the system), system should

64


automatically map the escalation levels with the new hierarchy of

Government officials

65


Monitoring (MIS)

Monitoring and reporting element of the proposed BPR framework is

envisaged to meet all the monitoring and reporting requirement of concerned

departments for the selected services under the e-district project. The

element will capture relevant information from service perspective (as

defined in the proposed e-district application) at predefined points of the To-

Be processes in predefined format and consolidate the same across the

district for the defined user to see and take necessary action as deemed

necessary. The monitoring element will have the “drill down” feature to

locate the base information from which it has been consolidated.

The reporting element of the proposed BPR framework will be based on the

departmental requirement. The element will have 2 types of reporting

features –

Physical reporting

Financial reporting

The physical reporting will include reporting on department achievements on

physical units while the financial reporting will include the fund utilization

against the budgeted amount for the service.

The purpose of the monitoring and reporting element as envisaged in the

proposed BPR framework has been listed below –

1. Provide real time information on the all aspect of service – request,

processing, delivery, etc, to the defined actors for the given service

2. Progress tracking of work at defined levels on given time referential

and help identifying any slack in the same.

3. Help to develop mid term correction strategies by brining out

deficiency in any aspect of service delivery

4. Generate required report for concerned departments basis physical

and financial reporting requirement

66


Monitoring – When authorities initiate an event

Aut

horit

ies

regi

ster

ed to

re

ceiv

e re

port

se-

Dis

tric

t App

licat

ion

Search the information according to query

Retrieve information

According to query

Takes cognizance of the reports and acts as

necessary

Print all the information

Aggregates all the information as per Report Generation

rules

Logins to the e-District Application using his user

ID and password

67


Monitoring – Automatic System generated at regular time intervals

Aut

horit

ies

regi

ster

ed

to r

ecei

ve r

epor

tse-

Dis

tric

t App

licat

ion

Retrieves information about

status of applications

Notifies the authorities and

sends the reports on a regular time interval to them

Aggregates all the information as per Report Generation

rules

Takes cognizance of the reports and acts as

necessary

68


J. Monitoring

S.

No.

Functional Requirement Specifications

1 The Process Owner should be able to use the e-District Application

(eDA) to query the Departmental Databases using the name or other

details of the applicant.

2 Should allow the eDA to retrieve various information from the

individual databases and aggregate it.

3 The application should support the monitoring in both the occurrence,

when an event or time driven activity is triggered.

4 Should be able to retrieve all information about the status of the

application form of the citizen.

5 Should be able to automatically generate the following reports to the

concerned authorities at regular time interval.

6 Should be able to generate Service Report on a regular time interval,

this report should include the no of application received, no of

application processed, no of application rejected and the no of

application under process.

7 Should able to generate SLA Report on regular time interval, this

report should give information related to centre wise details of no of

SLA met and centre wise details of no of SLA breached.

8 Should be able to generate Performance Report on regular time

interval, this report should give information related to centre wise

details of no of application processed against the no of application

received.

9 Should be able to generate Payment Report on regular time interval,

this report should give information related to centre wise transaction,

money collected and money deposited along with date and time.

10 Should be able to generate Inventory Report on regular time interval,

this report should give information related to pre-printed stationary

used and issued to each centre.

11 Should be able to generate Attendance Report on regular time

69


interval, this report should give information related to centre wise

attendance.

12 Should provide a search option to the authorised stakeholder so that

he can search the information which should be sorted according to

Date, Department, Service, District, Block and Tehsil.

13 Should allow the stakeholder to review the progress report and give

his comments online.

14 Should provide the facility to print and e-mail the report.

15 Should provide a printer – friendly version automatically for all pages.

70


Workflow

Workflow is the base component of the indicative framework where the ‘As Is

processes’ will be mapped against the ‘To Be envisioning’. Workflow is the

automation of a complex process, in whole or part, during which resources,

information, tasks and data a passed from one participant to another for

action, according to a set of rules.

Workflow management system will link all the components of a given service

and will provide a common platform to work and interact to all the

stakeholders. Workflow management system is a mechanism that defines,

creates and manages the execution of workflow through the use of software,

running on one or more workflow engines, which is able to interpret the

process definition, interact with workflow participants and, where required,

invoke the use of tools and applications. This system will also allow people to

specify and manage working processes, which are distributed in time and

across different domains and actors.

Technologies such as work flow and document management can help cut the

corporate paper mountain down to size while improving the efficiency of

basic operations. The key attraction of such technologies lies in their ability

to help organizations and departments improve their existing working

practices. Some of the key benefits of a good workflow management system

are listed below:

Improved efficiency

Improved productivity

Reduced service levels

Better quality of service

Reduced operational costs

Increased transparency

Significance (Citizen/administration)

71


Workflow will not only ensure smooth and on-time delivery of services but

this will also result in more transparency, responsibility and increased

productivity in the organization.

72

Caste Certificate

E-D

istr

ict

App

licat

ion

E-D

istr

ict

App

licat

ion

Teh

sild

arT

ehsi

ldar

Lekh

pal /

RI

Lekh

pal /

RI

App

lican

tA

pplic

ant

Applicant submits the application and makes

the payment and receives a receipt



System registers the application and

issues a Receipt


issues a Receipt



Checks the details in the Revenue Department’s

Caste certificate DataBase


Caste certificate DataBase

Details Correct?

Details Correct?

On receiving the hard copy of the

application, Approves the

application online using digital sign


application, Approves the


System saves the certificate in a DB and notifies the

applicant


applicant

Applicant receives the certificate


Marks the application for verification to RI /

Lekhpal

Marks the application for verification to RI /

Lekhpal


application, Rejects the application

online using digital sign


application, Rejects the application

online using digital sign

System saves the rejection in a DB and notifies the

applicant


applicant

Applicant receives the reason for

rejection


rejection

Yes

No

Details Found?

Details Found?

No

Yes


Tehsildar


Tehsildar


Revenue Department’s Caste certificate

Database



Database


details


details

System notifies RI / Lekhpal and

provides application details









database



database


Certificate

Caste certificate

73


K. Workflow – Caste Certificate

S.No

.

Functional Requirement Specifications

1 The e-District Application (eDA) should provide information on Caste

certificate as per the Information Dissemination component defined

previously.

2 The eDA should make Application Form for caste certificate available

online as per the Form Availability component defined previously.

3 The eDA should allow the Applicant to submit his application for Caste

certificate as per the Application Receipt component defined

previously.

4 The eDA should record payment transaction against an Application for

Caste Certificate as per the Payment component defined previously.

5 The eDA should notify the Tehsildar of the new Application and this

date and time should be logged

6 The Tehsildar should be able to download the Application from the

eDA.

7 The eDA should enable the Tehsildar to verify the claim in the

Application as per the Verification component defined previously.

8 The eDA should have a facility for forwarding of the application, with

remarks and digital sign of the sender, to any person in District

administration registered with the eDA.

9 The Tehsildar approves or rejects the application and digitally signs

his response as per the Approval and Rejection components defined

74


previously.

10 The eDA should log the Approval or Rejection action.

11 The eDA should save the Digitally signed Caste certificate or rejection

as a soft copy in the Department’s database.

12 The eDA should be able to deliver the document to the Applicant as

per the Delivery Mechanism defined previously.

13 The eDA should log the details of who accessed the online soft copy

and took a printout of the same.

75

Domicile Certificate

E-D

istr

ict

App

licat

ion

S.D

.M /

Teh

sild

arR

I / L

ekhp

alA

pplic

ant




issues a Receipt



Domicile certificate Database

Details Correct?

On receiving the hard copy of

application, SDM Approves the



applicant


Marks the application for verification to Lekhpal / (Field

officer).

On receiving the hard copy of

application, SDM Rejects the



applicant


rejection

Yes

No

Details Found?

No

Yes


SDM / Tesildar

System notifies Lekhpal and




Revenue Department’s Domicile certificate

Database


Revenue Department’s Domicile certificate

database



details


Domicile Certificate

76


Functional Requirements for Workflow – Domicile Certificate

1 The e-District Application (eDA) should provide information on

Domicile certificate as per the Information Dissemination component

defined previously.

2 The eDA should make Application Form for Domicile certificate

available online as per the Form Availability component defined

previously.

3 The eDA should allow the Applicant to submit his application for

Domicile certificate as per the Application Receipt component defined

previously.


Domicile Certificate as per the Payment component defined

previously.




eDA.






9 The Tehsildar approves or rejects the application and digitally signs

his response as per the Approval and Rejection components defined

previously.

77


10 The eDA should log the Approval or Rejection action.

11 The eDA should save the Digitally signed Domicile certificate or

rejection as a soft copy in the Department’s database.





78

Income Certificate

RI /

Lek

hpal

RI /

Lek

hpal

E-D

istri

ct

Appl

icat

ion

Tehs

ildar

Appl

ican

t

Application is submitted along with documents as available and makes the

payment online

Application is submitted along with documents as available and makes the

payment online


issues a Receipt


issues a Receipt


Receives the application On receiving the hard

copy of the application, Mentions the Income

on certificate and authenticates using

digital sign

On receiving the hard copy of the application, Mentions the Income


digital sign



System registers the certificate in a DB and notifies

the applicant

System registers the certificate in a DB and notifies the applicant

Conducts subjective evaluation based on documents submitted and /

or orders Physical Verification.

Conducts subjective evaluation based on documents submitted and /

or orders Physical Verification.

If Original Salary bank account statement or Letter from Gram Pradhan

provided

If Original Salary bank account statement or Letter from Gram Pradhan

provided

Yes

YesIf Access available to IT

Database

If Access available to IT

DatabaseVerifies the income details in the IT DB

Verifies the income details in the IT DB

Establishes income of the applicant

Establishes income of the applicant

List of Documents:Form 16 Salary Bank Acct statementAttested Salary slipSigned KhatauniLetter by Gram Pradhan

List of Documents:Form 16 Salary Bank Acct statementAttested Salary slipSigned KhatauniLetter by Gram Pradhan

No

No


details


detailsReceives the application.



Revenue Department’s Income certificate

database


Revenue Department’s Income certificate

database

Physically visits and verifies details. Enters these details

into the Revenue Department’s Income certificate Database

Physically visits and verifies details. Enters these details

into the Revenue Department’s Income certificate Database






Income Certificate

79


Functional Requirements for Workflow – Income Certificate

1 The e-District Application (eDA) should provide information on Income

certificate as per the Information Dissemination component defined

previously.

2 The eDA should make Application Form for Income certificate

available online as per the Form Availability component defined

previously.

3 The eDA should allow the Applicant to submit his application for

Income certificate as per the Application Receipt component defined

previously.


Income Certificate as per the Payment component defined previously.




eDA.






9 The eDA should enable the Tehsildar to mention the established

Income on the certificate and digitally signs it as per the Approval

component defined previously.

10 The eDA should log the above action of Approval of Application.

80


11 The eDA should save the Digitally signed Income certificate as a soft

copy in the Department’s database.





81


Birth Certificate

Birth Certificate -within 1 year - Urban

Reg

istr

arE

-Dis

tric

t A

pplic

atio

nA

pplic

ant

Yes

YesYes

No

No

NoInformation

within 21 days of birth?

Information within 1 year of

birth?

Information regarding the birth is given by the applicant and if available a certificate from a doctor or medical institution

On receiving of Hardcopy Mentions the Birth Date on certificate and authenticates using

digital sign

Pays a late fee of Rs. 5

Registrar receives the application

Conducts subjective evaluation based on other documents like Driving License,

Passport, High school certificate etc and physical verification report supplied by field officer when documents were not presented


issues a Receipt


System registers the certificate in a Database and

notifies the applicant

If convinced about authenticity

of MC

Is Medical Certificate provided

82


Birth Certificate -within 1 year - RuralR

egis

trar

E-D

istr

ict

App

licat

ion

App

lican

t

Yes

Yes

No

No

No

No

Yes

No

Yes

Yes

On receiving of hardcopy Mentions the Birth Date on certificate and authenticates using

digital sign

Updates the Database with the Birth date using

digital sign

Conducts subjective evaluation based on physical verification by a

Field Officer


Details found?Registrar receives

the application



Details correct?


of MC


issues a Receipt



Information within 21 days

of birth?


birth?



Checks Details in the Database

83


Birth Certificate -beyond 1 year - UrbanA

dditi

onal

Reg

istr

arE

-Dis

tric

t A

pplic

atio

nA

pplic

ant

YesYes

No

No

Information regarding the birth is given by the applicant and if available a certificate

from a doctor or medical institution

System registers the certificate in a

Database and notifies the applicant


issues a Receipt


of MC

SDM receives the application

Conducts subjective evaluation based on other documents like Driving License,

Passport, High school certificate etc and physical verification report supplied by field officer when documents were not

presented


Pays Rs. 10 as late fee

On receiving of hardcopy Mentions the Birth Date on certificate and authenticates using

digital sign


84


Birth Certificate -beyond 1 year - RuralE

-Dis

tric

t A

pplic

atio

nA

dditi

onal

Reg

istr

arA

pplic

ant



issues a Receipt


On receiving of Hardcopy Mentions the Birth Date on certificate and authenticates using

digital sign


System registers the certificate in a Database and notifies the applicant


of MCYes

No

Conducts subjective evaluation based on physical verification by a

Field Officer or other documents like Driving License, Passport, High school certificate, Voter ID etc.


No


Details found?Checks Details in

the DatabaseDetails correct?

No

Yes

No

Updates the Database with the Birth date using

digital sign

Yes

Yes


85


S.

No.

Functional Requirements – Birth Certificate

1

E district Application is the application meant for maintaining all the

transactions related to e district services. In the case of issuing Birth

Certificate it deals right from birth registration to issuing certificate to

the applicant.

2 Should be able to identify the user logging into the system using the

login component.

3 Should be able to provide information to the citizens about details

related to Birth Certificate as per the information dissemination

component.

4 Should allow the operator to fill in the online application on behalf of

citizen form availing the service.

5 Should be able to generate a unique registration number during

registering an applicant with the application.

6 Should be able to identify the applicant uniquely based on this

registration number.

7 Should be able to issue an acknowledgement receipt once the

applicant is registered with the system using the receipt component

mechanism.

8 Should be able to map the payment details of the transaction with

the kiosk

9 as per the guidelines specified under the payment mechanism

10 Should be able to mark the application to the Additional Registrar /

Registrar.

11 Should allow the registered users to search the database on pre set

query set.

12 Should maintain records of all the people those were born in the

district.

13 Should be able to help the various authorities (CMO, Registrar, and

Additional Registrar) to enter into the database and check for

particular applications in the case of non physical verification of the

86


applicant.

14 Should allow the stakeholders to track the application status at

different stages

15 Should allow the authorities to either accept / reject the application in

both the cases the applicant would be informed about the decision as

per the Approval / Rejection component of the application.

16 Should allow the authorities to update the result of physical

verification of applicant in the Birth Registration Database of Health

Department as per the physical verification component of the

system.

17 Should allow the authorities to digitally sign the birth certificates

stating the sex, birth date, religion, parents’ name, location of birth.

18 Should be able to store soft copy of Birth certificate in database and

generate trigger for CSC / Applicant that the certificate has been

prepared and he can take a printout of the same.

19 Should be able to auto generate grievance to higher authorities in

case specified SLAs are not met by the officials.

20 Should generate monitoring reports on specified time intervals and

send it to relevant authorities

21 Should provide access to authorities to monitor Application Status /

Performance / SLAs for a particular period by logging onto the system

22 Should allow the user to take a print out of the soft copy of the Birth

certificate

23 Should allow the field officers to update their field verification report

in the database

24 Should allow higher authorities to notify the field officers

87


Death Certificate

Death Certificate -beyond 1 year - Urban

Add

ition

al R

egis

trar

E-D

istri

ct

App

licat

ion

App

lican

t

Yes

No

No

Yes

Conducts subjective evaluation based on physical verification by any Field Officer or other documents like

Cemetery certificate etc.

If convinced about authenticity of

MC or witness letters

Is Medical Certificate provided and 2 witness letters

provided?


Information regarding the Death is given by the applicant and if available a certificate from a doctor or medical institution

along with two witness letters duly signed


issues a Receipt


On receiving of Hardcopy, Mentions the Death Date

on certificate and authenticates using digital

sign




88


Death Certificate -within 1 year - RuralR

egis

trar

E-D

istr

ict

App

licat

ion

App

lican

t


On receiving of Hardcopy Mentions the Death Date


digital sign

Registrar receives the application

Yes


Death?



Details found?

No

No

No




YesIf convinced

about authenticity of MC or witness

letters

No

System registers the certificate in a DB and notifies the applicant


provided?

Yes

Checks Details in the Database

Yes

No

Details correct?

YesUpdates the

Database with the Death date using

digital sign


issues a Receipt


Information within 21 days

of Death?

89


Death Certificate -beyond 1 year - UrbanA

dditi

onal

Reg

istr

arE

-Dis

tric

t A

pplic

atio

nA

pplic

ant

Yes

No

No

Yes






provided?





issues a Receipt


On receiving of Hardcopy, Mentions the Death Date

on certificate and authenticates using digital

sign




90


Death Certificate -beyond 1 year - RuralE

-Dis

tric

t A

pplic

atio

nA

dditi

onal

Reg

istr

arA

pplic

ant


issues a Receipt


On receiving of Hardcopy, Mentions the Death Date on certificate and authenticates

using digital sign





Details found?Checks Details in

the DatabaseDetails correct?

No

Yes

No

Updates the Database with the Death date using

digital sign

Yes



Yes

No

No




provided?



Yes


91


S.

No.

Functional Requirements – Death Certificate

1


transactions related to e district services. In the case of issuing Death

Certificate it deals right from Death registration to issuing certificate

to the applicant.

2 Should be able to identify the user logging into the system using the

login component.


related to Death Certificate as per the information dissemination

component.




registering an applicant with the application.

6 Should be able to identify the applicant uniquely based on this

registration number.


applicant is registered with the system using the receipt component

mechanism.


the kiosk

9 as per the guidelines specified under the payment mechanism.

10 Should be able to mark the application to the Additional Registrar /

Registrar.

11 Should allow the registered users to search the database on pre set

query set.

12 Should maintain records of all the people who died in the district.

13 Should be able to help the various authorities (CMO, Registrar, and

Additional Registrar) to enter into the database and check for

particular applications in the case of non physical verification of the

92


applicant.


different stages.

15 Should allow the authorities to either accept / reject the application in

both the cases the applicant would be informed about the decision as

per the Approval / Rejection component of the application.

16 Should allow the authorities to update the result of physical

verification of applicant in the Death Registration Database of Health

Department as per the physical verification component of the

system.

17 Should allow the authorities to digitally sign the Death certificates

stating the details of the deceased.

18 Should be able to store soft copy of Death certificate in database and

generate trigger for CSC / Applicant that the certificate has been



case specified SLAs are not met by the officials as per the auto

escalation mechanism of monitoring.


send it to relevant authorities as per the monitoring component.

21 Should provide access to authorities and applicant to monitor

Application Status / Performance / SLAs for a particular period by

logging onto the system

22 Should allow the user to take a print out of the soft copy of the Death

certificate in cases of approval.

23 Should allow the field officers to update their field verification report

in the database

24 Should allow higher authorities to notify the field officers

25 Should notify the applicant through SMS or other mechanism in case

end SLAs are missing as per the application status component

93


Handicap Certificate

Handicapped Certificate

CM

O O

ffice

E

-Dis

trict

App

licat

ion

App

lican

t

CMO digitally signs the certificate and updates Database

Marks the application for

physical verification

Medical panel examines the applicant and

ascertains the disability percentage

Updates database about the disability

percentage of applicant

Applicant fills in the application

form and receives ack. Receipt

System registers the application, issues a

Receipt and forwards to CMO

Receives application

Checks the details in the

DataBaseYesYes

Details Correct?


Details Found?


applicant

Approves the application online using digital sign

No


applicant

Rejects the application online using digital sign


rejection

No

RID is updated about the applicants

disability percentage

94


S. No. Functional Requirements – Handicapped Certificate

1


transactions related to e district services. In the case of issuing

handicapped certificate it deals right from applicant registration to

issue of handicapped certificate stating the percentage of disability.

2 Should be able to identify the user login into the system s per the

login component.


related to handicapped certificate as per the information

dissemination component.


citizen form availing the service as per form submission component.


registering an applicant with the application. Should be able to

identify the applicant uniquely based on this registration number.


applicant is registered with the system as per receipt component.


the kiosk as per payment component. (If any fixed by government in

case of social services)

8 Should be able to forward the application to the Chief Medical Office.

9 Should allow the user to search the database on pre set query set.

10 Should maintain records of all the handicapped people in the district

along with their disability percentage in the database.

11 Should be able to help the CMO to enter into the database and check

for particular applications in the case of non physical verification of

the applicant as per the details showcased in non physical verification

component.


different stages

13 Should allow the CMO to either accept / reject the application as per

95


the approval component

14 Should allow the CMO to update the result of physical verification of

applicant in the Handicapped Database of Health Department

15 Should allow the CMO to digitally sign the handicapped certificates

stating the disability percentage as per the physical verification

component.

16 Should be able to store soft copy of handicapped certificate in

database and generate trigger for CSC / Applicant that the certificate

has been prepared and he can take a printout of the same.



escalation mechanism of status tracking component.


send it to relevant authorities as per the Monitoring component



as per the monitoring component.

20 Should allow the user to take a print out of the soft copy of the

handicapped certificate

21 Should guide the user how to browse the page by providing a site

map on the first page

22 Should be able to send SMS to applicant in case of missing of final

SLAs and status tracking.

96

New Ration Card – BPL in Rural

GVP

AE-

Dist

rict

Appl

icat

ion

BDO

/ AD

OAp

plic

ant

Applicant submits the application form and

receives a receipt

Logs into the system and checks for

particular ration card application

No

Marks the application to GVPA for issuance of

ration card to the applicant

Details Found?


BPL Database / Anumodan List

On receiving of Hard copy, updates the

database and issue a Ration Card

Applicant receives the Ration card

Is Quota Available?

Yes Yes

No

Application rejected


rejection

Application entered in queue in the

waiting list databse


issues a ReceiptDetails checked

Check citizen has any Ration Card issued to him?

No

Yes

Database is updated

Database is updated


Ration Card

New Ration Card

97


New Ration Card – BPL in Urban S

ID

SO

/ A

RO

E-D

istr

ict

App

licat

ion

App

lican

t

No

Yes Yes

No



Marks the application to SI for issuance of ration

card to the applicant

Is Quota Available?


issues a Receipt

Application rejected



BPL DataBase

Applicant submits application form and

receives a receipt


rejection

Details Found?

Application entered in queue in the

waiting list databse

Details checked

Check citizen has any Ration Card issued to him?

No

Yes

Database is updated

Database is updated

On receiving of Hard copy, updates the

database and issue a Ration Card

98


S. No. Functional Requirements : New Ration Card - APL

1


transactions related to e district services. In the case of issuing New

APL Ration Card it deals right from applicant registration to issue of

New Ration Card.

2 Should be able to identify the user login into the system as defined

by the login component.


related to New Ration Card.







applicant is registered with the system.


the kiosk.

8 Should be able to mark the application to the BDO/ADO and GVPA in

Rural and DSO/ ARO and SI in Urban areas.


10 Should maintain records of all the Ration Card Holders in the district

along with their complete details, whether issued in Urban or Rural

areas in the database.

11 Should be able to help the DSO/BDO to enter into the database and

check for particular applications in the case of non physical

verification of the applicant.


different stages

13 Should allow the DSO/BDO to either accept / reject the application.

14 Should allow the SI/GVPA to enter/update the result of physical

99


verification of applicant in the Ration Card Database of Public

Distribution Supply Department.

15 Should allow the DSO/BDO to update the result of physical


Distribution Supply Department

16 Should allow the DSO/BDO and SI/GVPA to digitally sign the New

Ration Card.

17 Should be able to store soft copy of New Ration Card in database and

generate trigger for CSC / Applicant that the Ration Card has been





send it to relevant authorities.



21 Should allow the user to take a print out of the soft copy of the New

Ration Card.

100


S. No. Functional Requirements : New Ration Card - BPL

1


transactions related to e district services. In the case of issuing New

BPL Ration Card it deals right from applicant registration to issue of

New Ration Card.




related to New Ration Card Process and requirement.


related to BPL List.









the kiosk.

9 Should be able to mark the application to the DSO/ARO and SI in

Rural and BDO/ ADO and SI in Urban areas.





12 Should maintain the village wise record of BPL Database and

Anumodan List Database.


related to BPL Database and Anumodan List.

14 Should provide access to the authorised stakeholder to create/modify

101


Anumodan List.

15 Should check before issuing a New BPL Ration Card whether quota

limit does not exceed.

16 Should maintain a waiting list of applicant, if the quota is full/ not

available.

17 Should facilitate the authorised stakeholder to set the quota limit.





different stages.

20 Should allow the DSO/BDO to either accept / reject the application




22 Should allow the DSO/BDO and SI/GVPA to digitally sign the New

Ration Card.

23 Should be able to store soft copy of New Ration Card in database and

generate trigger for CSC / Applicant that the Ration Card has been









Ration Card.

102


Duplicate Ration Card

Duplicate Ration Card – Rural

DS

O /

SI

E-D

istr

ict

App

licat

ion

App

lican

t

No

Yes


receives a receipt

On receiving of Hardcopy issue digitally signed

Duplicate Ration Card to the applicant

Details checked



Database is updated for issuance of duplicate

Ration Card

System registers the application and issues a

Receipt

Applicant receives the duplicate Ration Card


DataBase

Database gets updated

Details Found?

Physically Verifies the applicant details

He entries the applicant details in the Database

103


S. No. Functional Requirements : Duplicate Ration Card

1



Duplicate Ration Card it deals right from applicant registration to

issue of Duplicate Ration Card.




related to Duplicate Ration Card.









the kiosk.

8 Should be able to mark the application to the BDO/ ADO and GVPA in

Rural and DSO and SI in Urban areas.









different stages

13 Should allow the DSO/BDO to either accept / reject the application


104







16 Should allow the DSO/BDO and SI/GVPA to digitally sign the Duplicate

Ration Card.

17 Should be able to store soft copy of Duplicate Ration Card in

database and generate trigger for CSC / Applicant that the Duplicate

Ration Card has been prepared and he can take a printout of the

same.







21 Should allow the user to take a print out of the soft copy of the

Duplicate Ration Card.

105


Modification of Ration Card

Modification of Ration Card – Rural

GV

PA

E-D

istr

ict

Ap

plic

atio

n /

D

ata

base

BD

O/

AD

OA

pp

lican

t


receives a receipt


issues a Receipt



Marks the application for verification of details to

GVPA


Marks the application to / GVPA to make

modification in database

Details Found?


DataBase

Yes

GVPA modifies the Database

Applicant receives the modified Ration Card

Updates the Database about the applicants

modified details

The existing record of the Ration Card is replaced by the new modified Ration

Card in the RID

Database is updated about physically

verification details Details checked

Database is updated about the modified

details and generates modified ration card

No

106


Modification of Ration Card – Urban D

SO

/ S

I E

-Dis

tric

t A

pplic

atio

n /

Da

tab

ase

App

lican

t

YesChecks the details in the

DataBase

Details checked

Details Found?


particular ration card

application

Applicant receives the

modified Ration Card

System registers the application and issues a Receipt

Database is updated about physically

verification details

Applicant submits application form

online and receives a receipt

On receiving of the hardcopy, modified

Ration Card is issued


Updates the Database about the applicants modified

details

No

107


S. No. Functional Requirements : Modification of Ration Card

1



Modified Ration Card it deals right from applicant registration to issue

of Modified Ration Card.




related to Modification in the Ration Card.









the kiosk.

8 Should be able to mark the application to the BDO/ADO and GVPA in

Rural and DSO and SI in Urban areas.









different stages

13 Should allow the DSO/BDO to either accept / reject the application.


108







16 Should allow the DSO/BDO and SI/GVPA to digitally sign the Modify

Ration Card.

17 Should be able to store soft copy of Modified Ration Card in database

and generate trigger for CSC / Applicant that the Modified Ration

Card has been prepared and he can take a printout of the same.

18 Should mention modification date on New Ration Card, after

modifying the details.








Ration Card.

109

Surrender Certificate – Rural

BD

O/

AD

OE

-Dis

tric

t Ap

plic

atio

n /

Da

tab

ase

App

lican

t


issue a receipt


DataBase

Applicant submits application, req.

documents and ration card

Logs into the system and looks

for particular ration card record

Opens particular record

Cancels particular record

Yes

Particular records gets updated

On receiving of hardcopy, Issues digitally

signed Surrender certificate

Receives surrender certificate

Details found

Updates database for old

information


No


Surrender of Ration Card

110


Surrender Certificate – Urban A

RO

E-D

istr

ict A

pplic

atio

n /

Dat

abas

eA

pplic

ant

Yes

No

Applicant submits application, req.

documents and ration card

Updates database for old

information


DataBase

Receives surrender certificate

On receiving of hardcopy, Issues digitally

signed Surrender certificate



issue a receipt

Logs into the system and looks

for particular ration card record

Particular records gets updated

Details foundOpens particular

record Cancels

particular record

111


S. No. Functional Requirements – Surrender Certificate PDS

1



surrender certificate the application deals right from applicant

registration to issue of surrender certificate.

2 Should be able to identify the user (DSO / BDO) logging into the

system as defined in the login component.


related to obtaining surrender certificate as per the information

dissemination component.








different stages as per the status tracking component.

8 Should be able to cancel old record which should trigger auto

generation of surrender certificate

9 Should allow the DSO to put his digital signature on the approved

surrender certificate as defined in the approval component.

10 Should be able to store soft copy of surrender certificate in

database.






Performance / SLAs for a particular period by logging onto the

system

112


14 Should allow the DSO /BDO to take a print out of the Surrender

Certificate.

15 Should allow storing the soft copy of the certificate in the database

16 Should automatically update all the relative databases associated

with the particular record


SLAs and status tracking

113


Revenue Court Services

Revenue Court – Daily Cause List

Citi

zen

eDis

tric

t ap

plic

atio

nPr

esid

ing

Offi

cer

Pesh

kar

PO accepts the case and assigns a hearing date.

Adjournments declared to continue the case hearing at

another specified date

Makes an entry in the Revenue Court Database

using the eDA

Takes a printout of the Daily Cause generated for the next date and displays outside the

courtroom

The Register has the following details:

1. Applicant2. Defendant3. Section4. Discussion subject

A citizen logs on to the e-District Website and Clicks on link for Revenue Courts

Citizen selects the Court and Enters a date

The eDA displays the Daily Cause List for that date.

System saves the details of the case in the Revenue

Court Database

Generates a dynamic Daily Cause List for prospective

dates

114


Revenue Court – Online Status Tracking

E-Dis

tric

t App

licat

ion

Cit

izen


Citizen selects the Court and Enters the Case

Number

The e-District Application displays the Status of the

case along with a summary.

115


Revenue Court – Copy of Final Ordere-

Dis

tric

t App

licat

ion

Cit

izen


Citizen selects the Court and Enters the Case

Number

The eDistrict Application displays the Final Order

PDF, which may be downloaded.

116


S.No. Revenue Court Cases

1 The system should be available in administrative view

2 The System should have provision for record creation and

updation based on predefined access rights for the same

3 Administrative view of the system should contain Content

Management tools like:

Editing tools – for creating, editing, moving and

deleting pages.

Upload tools – for uploading and reviewing image

files and other special files.

Checking tools – for checking spelling errors and for

broken lines

Publishing tools – for making the updated content for

Administrative view

4 The e-District Application (eDA) should provide Information on Revenue

Courts as per the Information Dissemination component defined

previously

5 The eDA should make Application Form for filing and application of a

case available online as per the Form Availability component defined

previously.

6 The eDA should be able to generate dynamic Daily Cause Lists

7 The eDA should enable the Peshkar of the revenue court to take a Printout

of the specified date’s Cause List.

8 The System should provide a printer-friendly version

automatically for all pages

9 The System should have provision for Calendar System,

which displays the dates and time of schedule revenue

cases on a standard monthly calendar.

117


10 Under Court Case Status System:

Select Court from Multilayered Menu (District Name -

> List of Revenue Courts)

Provision for accepting Case number from user

Retrieval of Court case status with summary

Option for searching Court case with help of name of

“Vaadi or prativadi”

11 Under Copy of Final Order system should provide the

following information:

Select of Court from Multilayered Menu (District

Name -> List of Revenue Courts)

Provision for accepting Case number from user

Retrieval and Downloading of Copy of final Order of

Court Case

Option for searching Court case with help of name of

“Vaadi or prativadi”

Option for uploading scanned/Digitally signed soft

copy of Final Order of court case.

The Copy of the Final Order must be Non-Editable.

12 Under Cause List system should generate the following

information:

Select of Court from Multilayered Menu (District

Name -> List of Revenue Courts)

Provision for Registering Case by Presiding Officer

with following details,

118


Applicant (Vadi)

Defendant (Prativadi)

Section

Discussion subject

Presiding officer should able to assign hearing date

on FCFS basis

Presiding officer should able to assign next hearing

date

Date wise list of cases should be available for view

and print out

Option for viewing list of cases on given date

119

Grievance Redressal System

Lokv

ani

grie

vanc

e re

dres

sal

syst

em

Dep

artm

ent

DM

Offi

ceLo

kvan

i Cen

treC

lient

/ C

itize

n

NO Yes

Comes on the prescribed date to the

Lokvani Kendra

Officer login and checks complaints assigned to

him

Citizen provides Grievance Number

and pays Rs 5

Receives Status of

Grievance

Assigns officer for redressal of complaints with deadline and instruction on same day

Is grievance redressed

Officer resolves the complaint in 15 days

Kiosk Operator enters grievance in the grievance

redressal system

Receives the printed Action Taken Report

Check Status of Complaint online

Receives citizen at lokwani kendra and lodges grievance

receives a predefined fees

Citizen faces problem

Registers grievance issues grievance registration number and generates trigger for DM

Logs in to the grievance redressal and downloads all

the logged grievances

Receives grievance registration number

Provides registration number and date of re-

coming to Lokvani kendra

Logs in to system and finds status

Visits Lokwani Kendra

ATR is updated and trigger is generated for

the applicant

Officer fills Action taken report using his login ID


Grievances

120


S. No. Functional Requirements – Grievance Filing

1


transactions related to e district services. With regard to filing

grievance the application i.e. the Lokvani Grievance Redressal

System deals right from grievance filing to obtaining Action Taken

Report by the applicant.

2 Should be able to identify the user logging into the system as per the

login component


related to grievance filing.







the kiosk

7 Should be able to mark the application to the District Magistrate for

grievance redressal

8 Should maintain records of all the grievances filed through the

Lokvani Kendras for a particular period of time.

9 Should allow the DM to reject any frivolous grievances using the

rejection component.

10 Should be able to help the District Magistrate to assign officials to

take action on the filed grievance


different stages as per the status tracking component.

12 Should allow the assigned officer the Action Taken Report over the

system duly digitally signed by him

13 Should be able to store soft copy of Action Taken Report (ATR) in

database and generate trigger for CSC / Applicant that the certificate


has been prepared and he can take a printout of the same.



escalation mechanism of monitoring component.





17 Should allow the user to take a print out of the soft copy of the Action

Taken Report as per the delivery component

18 Should provide a site map at the opening page of the application

19 Should be able to deliver the output (ATR – Printout) from any of the

registered centres


SLAs and status tracking.

122


Next Deliverable

The next deliverable to this report will be To-Be Process Maps and Functional

Specification requirement for remaining 6 services as mentioned below will be

submitted on 12th December 2007:

Pension

Police

Electoral services

Utility services

Employment

RTI

Along with the above mentioned services, this report will also provide the portal

requirement for the proposed e-District Application.

Once the Functional Requirement Specifications (FRS) is finalized in discussion

with the state NIC unit, the final report comprising of Business Process Re-

engineering requirements, To Be Processes for all the selected services along

with the Functional Requirement Specifications (FRS) will be submitted on 22nd

December 2007. This consolidated report will also contain technological

requirement and portal specifications for the e-District Application.

123


Annexure 1: Legend of Cross Functional Process MapsThe following table shows the symbol used in preparation of cross functional process maps

S.NO Symbol Used Description

1 Activity performed in process

2 Decision box

3 Pre-defined/Existing document

6 Functions responsible for performing the activity

7 Workflow of Activity

Fun

ctio

n

124

Service Oriented Architecture (SOA) Recommendation for ...

Documents

Transcript of Service Oriented Architecture (SOA) Recommendation for ...