Post on 17-May-2015
`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
‘T0-Be’ & FRS Report – Pilot e-District, U.P.
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
‘T0-Be’ & FRS Report – Pilot e-District, U.P.
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
‘T0-Be’ & FRS Report – Pilot e-District, U.P.
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
‘T0-Be’ & FRS Report – Pilot e-District, U.P.
6
Part I
Suggested Enterprise Architecture for UP e-district
‘T0-Be’ & FRS Report – Pilot e-District, U.P.
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
‘T0-Be’ & FRS Report – Pilot e-District, U.P.
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
‘T0-Be’ & FRS Report – Pilot e-District, U.P.
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
‘T0-Be’ & FRS Report – Pilot e-District, U.P.
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
‘T0-Be’ & FRS Report – Pilot e-District, U.P.
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
‘T0-Be’ & FRS Report – Pilot e-District, U.P.
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
‘T0-Be’ & FRS Report – Pilot e-District, U.P.
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
‘T0-Be’ & FRS Report – Pilot e-District, U.P.
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
‘T0-Be’ & FRS Report – Pilot e-District, U.P.
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
‘T0-Be’ & FRS Report – Pilot e-District, U.P.
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
‘T0-Be’ & FRS Report – Pilot e-District, U.P.
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
‘T0-Be’ & FRS Report – Pilot e-District, U.P.
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
‘T0-Be’ & FRS Report – Pilot e-District, U.P.
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
‘T0-Be’ & FRS Report – Pilot e-District, U.P.
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
‘T0-Be’ & FRS Report – Pilot e-District, U.P.
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
‘T0-Be’ & FRS Report – Pilot e-District, U.P.
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
‘T0-Be’ & FRS Report – Pilot e-District, U.P.
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
‘T0-Be’ & FRS Report – Pilot e-District, U.P.
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
‘T0-Be’ & FRS Report – Pilot e-District, U.P.
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
‘T0-Be’ & FRS Report – Pilot e-District, U.P.
26
Part II
‘To-Be’ Process & Functional Requirement Specification
‘T0-Be’ & FRS Report – Pilot e-District, U.P.
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
‘T0-Be’ & FRS Report – Pilot e-District, U.P.
Figure 0-1
28
‘T0-Be’ & FRS Report – Pilot e-District, U.P.
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
‘T0-Be’ & FRS Report – Pilot e-District, U.P.
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
‘T0-Be’ & FRS Report – Pilot e-District, U.P.
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
‘T0-Be’ & FRS Report – Pilot e-District, U.P.
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
‘T0-Be’ & FRS Report – Pilot e-District, U.P.
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
‘T0-Be’ & FRS Report – Pilot e-District, U.P.
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
‘T0-Be’ & FRS Report – Pilot e-District, U.P.
35
‘T0-Be’ & FRS Report – Pilot e-District, U.P.
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
‘T0-Be’ & FRS Report – Pilot e-District, U.P.
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.
The purpose of the element as envisaged in the proposed BPR framework has
been listed below –
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
‘T0-Be’ & FRS Report – Pilot e-District, U.P.
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
‘T0-Be’ & FRS Report – Pilot e-District, U.P.
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
‘T0-Be’ & FRS Report – Pilot e-District, U.P.
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
‘T0-Be’ & FRS Report – Pilot e-District, U.P.
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
‘T0-Be’ & FRS Report – Pilot e-District, U.P.
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
‘T0-Be’ & FRS Report – Pilot e-District, U.P.
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
‘T0-Be’ & FRS Report – Pilot e-District, U.P.
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
‘T0-Be’ & FRS Report – Pilot e-District, U.P.
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
‘T0-Be’ & FRS Report – Pilot e-District, U.P.
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
‘T0-Be’ & FRS Report – Pilot e-District, U.P.
Figure 0-2
47
‘T0-Be’ & FRS Report – Pilot e-District, U.P.
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
‘T0-Be’ & FRS Report – Pilot e-District, U.P.
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
Receives the application.
Returns the Query results
‘T0-Be’ & FRS Report – Pilot e-District, U.P.
50
‘T0-Be’ & FRS Report – Pilot e-District, U.P.
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
‘T0-Be’ & FRS Report – Pilot e-District, U.P.
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
‘T0-Be’ & FRS Report – Pilot e-District, U.P.
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
Receives the application
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
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
Receives the application.
Returns the Query results
‘T0-Be’ & FRS Report – Pilot e-District, U.P.
54
‘T0-Be’ & FRS Report – Pilot e-District, U.P.
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
‘T0-Be’ & FRS Report – Pilot e-District, U.P.
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
‘T0-Be’ & FRS Report – Pilot e-District, U.P.
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.
The purpose of the element as envisaged in the proposed BPR framework has
been listed below –
1. To provide output against the service request by the citizen
through a defined and secured process
57
‘T0-Be’ & FRS Report – Pilot e-District, U.P.
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
‘T0-Be’ & FRS Report – Pilot e-District, U.P.
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
‘T0-Be’ & FRS Report – Pilot e-District, U.P.
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
‘T0-Be’ & FRS Report – Pilot e-District, U.P.
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
‘T0-Be’ & FRS Report – Pilot e-District, U.P.
62
‘T0-Be’ & FRS Report – Pilot e-District, U.P.
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
‘T0-Be’ & FRS Report – Pilot e-District, U.P.
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
‘T0-Be’ & FRS Report – Pilot e-District, U.P.
automatically map the escalation levels with the new hierarchy of
Government officials
65
‘T0-Be’ & FRS Report – Pilot e-District, U.P.
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
‘T0-Be’ & FRS Report – Pilot e-District, U.P.
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
‘T0-Be’ & FRS Report – Pilot e-District, U.P.
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
‘T0-Be’ & FRS Report – Pilot e-District, U.P.
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
‘T0-Be’ & FRS Report – Pilot e-District, U.P.
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
‘T0-Be’ & FRS Report – Pilot e-District, U.P.
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
‘T0-Be’ & FRS Report – Pilot e-District, U.P.
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
Applicant submits the application and makes
the payment and receives a receipt
System registers the application and
issues a Receipt
System registers the application and
issues a Receipt
Receives the application
Receives the application
Checks the details in the Revenue Department’s
Caste certificate DataBase
Checks the details in the Revenue Department’s
Caste certificate DataBase
Details Correct?
Details Correct?
On receiving the hard copy of the
application, Approves the
application online using digital sign
On receiving the hard copy of the
application, Approves the
application online using digital sign
System saves the certificate in a DB and notifies the
applicant
System saves the certificate in a DB and notifies the
applicant
Applicant receives the certificate
Applicant receives the certificate
Marks the application for verification to RI /
Lekhpal
Marks the application for verification to RI /
Lekhpal
On receiving the hard copy of the
application, Rejects the application
online using digital sign
On receiving the hard copy of the
application, Rejects the application
online using digital sign
System saves the rejection in a DB and notifies the
applicant
System saves the rejection in a DB and notifies the
applicant
Applicant receives the reason for
rejection
Applicant receives the reason for
rejection
Yes
No
Details Found?
Details Found?
No
Yes
System registers the change and notifies
Tehsildar
System registers the change and notifies
Tehsildar
Physically visits and verifies details. Enters these details into the
Revenue Department’s Caste certificate
Database
Physically visits and verifies details. Enters these details into the
Revenue Department’s Caste certificate
Database
Submits the application back with the verified
details
Submits the application back with the verified
details
System notifies RI / Lekhpal and
provides application details
System notifies RI / Lekhpal and
provides application details
Receives the application.
Receives the application.
Returns the Query results
Returns the Query results
Links the Citizen Database with the
Revenue Department’s Caste certificate
database
Links the Citizen Database with the
Revenue Department’s Caste certificate
database
‘T0-Be’ & FRS Report – Pilot e-District, U.P.
Certificate
Caste certificate
73
‘T0-Be’ & FRS Report – Pilot e-District, U.P.
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
‘T0-Be’ & FRS Report – Pilot e-District, U.P.
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
Applicant submits the application and makes
the payment and receives a receipt
System registers the application and
issues a Receipt
Receives the application
Checks the details in the Revenue Department’s
Domicile certificate Database
Details Correct?
On receiving the hard copy of
application, SDM Approves the
application online using digital sign
System saves the certificate in a DB and notifies the
applicant
Applicant receives the certificate
Marks the application for verification to Lekhpal / (Field
officer).
On receiving the hard copy of
application, SDM Rejects the
application online using digital sign
System saves the rejection in a DB and notifies the
applicant
Applicant receives the reason for
rejection
Yes
No
Details Found?
No
Yes
System registers the change and notifies
SDM / Tesildar
System notifies Lekhpal and
provides application details
Returns the Query results
Physically visits and verifies details. Enters these details into the
Revenue Department’s Domicile certificate
Database
Links the Citizen Database with the
Revenue Department’s Domicile certificate
database
Receives the application.
Submits the application back with the verified
details
‘T0-Be’ & FRS Report – Pilot e-District, U.P.
Domicile Certificate
76
‘T0-Be’ & FRS Report – Pilot e-District, U.P.
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.
4 The eDA should record payment transaction against an Application for
Domicile 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
previously.
77
‘T0-Be’ & FRS Report – Pilot e-District, U.P.
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.
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.
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
System registers the application and
issues a Receipt
System registers the application and
issues a Receipt
Receives the application
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
on certificate and authenticates using
digital sign
Applicant receives the certificate
Applicant receives the certificate
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
Submits the application back with the verified
details
Submits the application back with the verified
detailsReceives the application.
Receives the application.
Links the Citizen Database with the
Revenue Department’s Income certificate
database
Links the Citizen Database with the
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
System notifies RI / Lekhpal and
provides application details
System notifies RI / Lekhpal and
provides application details
‘T0-Be’ & FRS Report – Pilot e-District, U.P.
Income Certificate
79
‘T0-Be’ & FRS Report – Pilot e-District, U.P.
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.
4 The eDA should record payment transaction against an Application for
Income 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 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
‘T0-Be’ & FRS Report – Pilot e-District, U.P.
11 The eDA should save the Digitally signed Income certificate 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.
81
‘T0-Be’ & FRS Report – Pilot e-District, U.P.
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
System registers the application and
issues a Receipt
Applicant receives the certificate
System registers the certificate in a Database and
notifies the applicant
If convinced about authenticity
of MC
Is Medical Certificate provided
82
‘T0-Be’ & FRS Report – Pilot e-District, U.P.
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
Pays a late fee of Rs. 5
Details found?Registrar receives
the application
Information regarding the birth is given by the applicant and if available a certificate from a doctor or medical institution
Is Medical Certificate provided
Details correct?
If convinced about authenticity
of MC
System registers the application and
issues a Receipt
Returns the Query results
Applicant receives the certificate
Information within 21 days
of birth?
Information within 1 year of
birth?
System registers the certificate in a Database and
notifies the applicant
Checks Details in the Database
83
‘T0-Be’ & FRS Report – Pilot e-District, U.P.
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
System registers the application and
issues a Receipt
If convinced about authenticity
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
Is Medical Certificate provided
Pays Rs. 10 as late fee
On receiving of hardcopy Mentions the Birth Date on certificate and authenticates using
digital sign
Applicant receives the certificate
84
‘T0-Be’ & FRS Report – Pilot e-District, U.P.
Birth Certificate -beyond 1 year - RuralE
-Dis
tric
t A
pplic
atio
nA
dditi
onal
Reg
istr
arA
pplic
ant
Information regarding the birth is given by the applicant and if available a certificate from a doctor or medical institution
System registers the application and
issues a Receipt
SDM receives the application
On receiving of Hardcopy Mentions the Birth Date on certificate and authenticates using
digital sign
Applicant receives the certificate
System registers the certificate in a Database and notifies the applicant
If convinced about authenticity
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.
Is Medical Certificate provided
No
Pays a late fee of Rs. 20
Details found?Checks Details in
the DatabaseDetails correct?
No
Yes
No
Updates the Database with the Birth date using
digital sign
Yes
Yes
Returns the Query results
85
‘T0-Be’ & FRS Report – Pilot e-District, U.P.
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
‘T0-Be’ & FRS Report – Pilot e-District, U.P.
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
‘T0-Be’ & FRS Report – Pilot e-District, U.P.
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?
Pays a late fee of Rs. 10
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
System registers the application and
issues a Receipt
SDM receives the application
On receiving of Hardcopy, Mentions the Death Date
on certificate and authenticates using digital
sign
Applicant receives the certificate
System registers the certificate in a Database and
notifies the applicant
88
‘T0-Be’ & FRS Report – Pilot e-District, U.P.
Death Certificate -within 1 year - RuralR
egis
trar
E-D
istr
ict
App
licat
ion
App
lican
t
Returns the Query results
On receiving of Hardcopy Mentions the Death Date
on certificate and authenticates using
digital sign
Registrar receives the application
Yes
Information within 1 year of
Death?
Conducts subjective evaluation based on physical verification by any Field Officer or other documents like
Cemetery certificate etc.
Details found?
No
No
No
Pays a late fee of Rs. 5
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
YesIf convinced
about authenticity of MC or witness
letters
No
System registers the certificate in a DB and notifies the applicant
Is Medical Certificate provided and 2 witness letters
provided?
Yes
Checks Details in the Database
Yes
No
Details correct?
YesUpdates the
Database with the Death date using
digital sign
System registers the application and
issues a Receipt
Applicant receives the certificate
Information within 21 days
of Death?
89
‘T0-Be’ & FRS Report – Pilot e-District, U.P.
Death Certificate -beyond 1 year - UrbanA
dditi
onal
Reg
istr
arE
-Dis
tric
t A
pplic
atio
nA
pplic
ant
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?
Pays a late fee of Rs. 10
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
System registers the application and
issues a Receipt
SDM receives the application
On receiving of Hardcopy, Mentions the Death Date
on certificate and authenticates using digital
sign
Applicant receives the certificate
System registers the certificate in a Database and
notifies the applicant
90
‘T0-Be’ & FRS Report – Pilot e-District, U.P.
Death Certificate -beyond 1 year - RuralE
-Dis
tric
t A
pplic
atio
nA
dditi
onal
Reg
istr
arA
pplic
ant
System registers the application and
issues a Receipt
SDM receives the application
On receiving of Hardcopy, Mentions the Death Date on certificate and authenticates
using digital sign
Applicant receives the certificate
System registers the certificate in a Database and
notifies the applicant
Pays a late fee of Rs. 20
Details found?Checks Details in
the DatabaseDetails correct?
No
Yes
No
Updates the Database with the Death date using
digital sign
Yes
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
Yes
No
No
If convinced about authenticity of
MC or witness letters
Is Medical Certificate provided and 2 witness letters
provided?
Conducts subjective evaluation based on physical verification by any Field Officer or other documents like
Cemetery certificate etc.
Yes
Returns the Query results
91
‘T0-Be’ & FRS Report – Pilot e-District, U.P.
S.
No.
Functional Requirements – Death Certificate
1
E district Application is the application meant for maintaining all the
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.
3 Should be able to provide information to the citizens about details
related to Death 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 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
‘T0-Be’ & FRS Report – Pilot e-District, U.P.
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 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
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 as per the auto
escalation mechanism of monitoring.
20 Should generate monitoring reports on specified time intervals and
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
‘T0-Be’ & FRS Report – Pilot e-District, U.P.
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?
Applicant receives the certificate
Details Found?
System saves the certificate in a DB and notifies the
applicant
Approves the application online using digital sign
No
System saves the rejection in a DB and notifies the
applicant
Rejects the application online using digital sign
Applicant receives the reason for
rejection
No
RID is updated about the applicants
disability percentage
94
‘T0-Be’ & FRS Report – Pilot e-District, U.P.
S. No. Functional Requirements – Handicapped Certificate
1
E district Application is the application meant for maintaining all the
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.
3 Should be able to provide information to the citizens about details
related to handicapped 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 as per form submission component.
5 Should be able to generate a unique registration number during
registering an applicant with the application. Should be able to
identify the applicant uniquely based on this registration number.
6 Should be able to issue an acknowledgement receipt once the
applicant is registered with the system as per receipt component.
7 Should be able to map the payment details of the transaction with
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.
12 Should allow the stakeholders to track the application status at
different stages
13 Should allow the CMO to either accept / reject the application as per
95
‘T0-Be’ & FRS Report – Pilot e-District, U.P.
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.
17 Should be able to auto generate grievance to higher authorities in
case specified SLAs are not met by the officials as per the auto
escalation mechanism of status tracking component.
18 Should generate monitoring reports on specified time intervals and
send it to relevant authorities as per the Monitoring component
19 Should provide access to authorities to monitor Application Status /
Performance / SLAs for a particular period by logging onto the system
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?
Checks the details in the
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
Applicant receives the reason for
rejection
Application entered in queue in the
waiting list databse
System registers the application and
issues a ReceiptDetails checked
Check citizen has any Ration Card issued to him?
No
Yes
Database is updated
Database is updated
‘T0-Be’ & FRS Report – Pilot e-District, U.P.
Ration Card
New Ration Card
97
‘T0-Be’ & FRS Report – Pilot e-District, U.P.
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
Logs into the system and checks for
particular ration card application
Marks the application to SI for issuance of ration
card to the applicant
Is Quota Available?
System registers the application and
issues a Receipt
Application rejected
Applicant receives the certificate
Checks the details in the
BPL DataBase
Applicant submits application form and
receives a receipt
Applicant receives the reason for
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
‘T0-Be’ & FRS Report – Pilot e-District, U.P.
S. No. Functional Requirements : New Ration Card - APL
1
E district Application is the application meant for maintaining all the
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.
3 Should be able to provide information to the citizens about details
related to New Ration Card.
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. Should be able to
identify the applicant uniquely based on this registration number.
6 Should be able to issue an acknowledgement receipt once the
applicant is registered with the system.
7 Should be able to map the payment details of the transaction with
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.
9 Should allow the user to search the database on pre set query set.
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.
12 Should allow the stakeholders to track the application status at
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
‘T0-Be’ & FRS Report – Pilot e-District, U.P.
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
verification of applicant in the Ration Card Database of Public
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
prepared and he can take a printout of the same.
18 Should be able to auto generate grievance to higher authorities in
case specified SLAs are not met by the officials.
19 Should generate monitoring reports on specified time intervals and
send it to relevant authorities.
20 Should provide access to authorities to monitor Application Status /
Performance / SLAs for a particular period by logging onto the system
21 Should allow the user to take a print out of the soft copy of the New
Ration Card.
100
‘T0-Be’ & FRS Report – Pilot e-District, U.P.
S. No. Functional Requirements : New Ration Card - BPL
1
E district Application is the application meant for maintaining all the
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.
2 Should be able to identify the user login into the system as defined
by the login component.
3 Should be able to provide information to the citizens about details
related to New Ration Card Process and requirement.
4 Should be able to provide information to the citizens about details
related to BPL List.
5 Should allow the operator to fill in the online application on behalf of
citizen form availing the service.
6 Should be able to generate a unique registration number during
registering an applicant with the application. 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.
8 Should be able to map the payment details of the transaction with
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.
10 Should allow the user to search the database on pre set query set.
11 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.
12 Should maintain the village wise record of BPL Database and
Anumodan List Database.
13 Should be able to provide information to the citizens about details
related to BPL Database and Anumodan List.
14 Should provide access to the authorised stakeholder to create/modify
101
‘T0-Be’ & FRS Report – Pilot e-District, U.P.
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.
18 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.
19 Should allow the stakeholders to track the application status at
different stages.
20 Should allow the DSO/BDO to either accept / reject the application
21 Should allow the DSO/BDO to update the result of physical
verification of applicant in the Ration Card Database of Public
Distribution Supply Department
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
prepared and he can take a printout of the same.
24 Should be able to auto generate grievance to higher authorities in
case specified SLAs are not met by the officials.
25 Should generate monitoring reports on specified time intervals and
send it to relevant authorities.
26 Should provide access to authorities to monitor Application Status /
Performance / SLAs for a particular period by logging onto the system
27 Should allow the user to take a print out of the soft copy of the New
Ration Card.
102
‘T0-Be’ & FRS Report – Pilot e-District, U.P.
Duplicate Ration Card
Duplicate Ration Card – Rural
DS
O /
SI
E-D
istr
ict
App
licat
ion
App
lican
t
No
Yes
Applicant submits application form and
receives a receipt
On receiving of Hardcopy issue digitally signed
Duplicate Ration Card to the applicant
Details checked
Logs into the system and checks for
particular ration card application
Database is updated for issuance of duplicate
Ration Card
System registers the application and issues a
Receipt
Applicant receives the duplicate Ration Card
Checks the details in the
DataBase
Database gets updated
Details Found?
Physically Verifies the applicant details
He entries the applicant details in the Database
103
‘T0-Be’ & FRS Report – Pilot e-District, U.P.
S. No. Functional Requirements : Duplicate Ration Card
1
E district Application is the application meant for maintaining all the
transactions related to e district services. In the case of issuing
Duplicate Ration Card it deals right from applicant registration to
issue of Duplicate Ration Card.
2 Should be able to identify the user login into the system as defined
by the login component.
3 Should be able to provide information to the citizens about details
related to Duplicate Ration Card.
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. Should be able to
identify the applicant uniquely based on this registration number.
6 Should be able to issue an acknowledgement receipt once the
applicant is registered with the system.
7 Should be able to map the payment details of the transaction with
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.
9 Should allow the user to search the database on pre set query set.
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.
12 Should allow the stakeholders to track the application status at
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
104
‘T0-Be’ & FRS Report – Pilot e-District, U.P.
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
verification of applicant in the Ration Card Database of Public
Distribution Supply Department.
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.
18 Should be able to auto generate grievance to higher authorities in
case specified SLAs are not met by the officials.
19 Should generate monitoring reports on specified time intervals and
send it to relevant authorities.
20 Should provide access to authorities to monitor Application Status /
Performance / SLAs for a particular period by logging onto the system
21 Should allow the user to take a print out of the soft copy of the
Duplicate Ration Card.
105
‘T0-Be’ & FRS Report – Pilot e-District, U.P.
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
Applicant submits application form and
receives a receipt
System registers the application and
issues a Receipt
Logs into the system and checks for
particular ration card application
Marks the application for verification of details to
GVPA
Physically Verifies the applicant details
Marks the application to / GVPA to make
modification in database
Details Found?
Checks the details in the
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
‘T0-Be’ & FRS Report – Pilot e-District, U.P.
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?
Logs into the system and checks for
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
Physically Verifies the applicant details
Updates the Database about the applicants modified
details
No
107
‘T0-Be’ & FRS Report – Pilot e-District, U.P.
S. No. Functional Requirements : Modification of Ration Card
1
E district Application is the application meant for maintaining all the
transactions related to e district services. In the case of issuing
Modified Ration Card it deals right from applicant registration to issue
of Modified Ration Card.
2 Should be able to identify the user login into the system as defined
by the login component.
3 Should be able to provide information to the citizens about details
related to Modification in the Ration Card.
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. Should be able to
identify the applicant uniquely based on this registration number.
6 Should be able to issue an acknowledgement receipt once the
applicant is registered with the system.
7 Should be able to map the payment details of the transaction with
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.
9 Should allow the user to search the database on pre set query set.
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.
12 Should allow the stakeholders to track the application status at
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
108
‘T0-Be’ & FRS Report – Pilot e-District, U.P.
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
verification of applicant in the Ration Card Database of Public
Distribution Supply Department
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.
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 New
Ration Card.
109
Surrender Certificate – Rural
BD
O/
AD
OE
-Dis
tric
t Ap
plic
atio
n /
Da
tab
ase
App
lican
t
System registers the application and
issue a receipt
Checks the details in the
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
Cancels particular record
No
‘T0-Be’ & FRS Report – Pilot e-District, U.P.
Surrender of Ration Card
110
‘T0-Be’ & FRS Report – Pilot e-District, U.P.
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
Checks the details in the
DataBase
Receives surrender certificate
On receiving of hardcopy, Issues digitally
signed Surrender certificate
Cancels particular record
System registers the application and
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
‘T0-Be’ & FRS Report – Pilot e-District, U.P.
S. No. Functional Requirements – Surrender Certificate PDS
1
E district Application is the application meant for maintaining all the
transactions related to e district services. In the case of issuing
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.
3 Should be able to provide information to the citizens about details
related to obtaining surrender certificate as per the information
dissemination component.
4 Should be able to generate a unique registration number during
registering an applicant with the application. Should be able to
identify the applicant uniquely based on this registration number.
5 Should be able to issue an acknowledgement receipt once the
applicant is registered with the system.
6 Should allow the user to search the database on pre set query set.
7 Should allow the stakeholders to track the application status at
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.
11 Should be able to auto generate grievance to higher authorities in
case specified SLAs are not met by the officials.
12 Should generate monitoring reports on specified time intervals and
send it to relevant authorities
13 Should provide access to authorities to monitor Application Status /
Performance / SLAs for a particular period by logging onto the
system
112
‘T0-Be’ & FRS Report – Pilot e-District, U.P.
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
17 Should be able to send SMS to applicant in case of missing of final
SLAs and status tracking
113
‘T0-Be’ & FRS Report – Pilot e-District, U.P.
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
‘T0-Be’ & FRS Report – Pilot e-District, U.P.
Revenue Court – Online Status Tracking
E-Dis
tric
t App
licat
ion
Cit
izen
A citizen logs on to the e-District Website and Clicks on link for Revenue Courts
Citizen selects the Court and Enters the Case
Number
The e-District Application displays the Status of the
case along with a summary.
115
‘T0-Be’ & FRS Report – Pilot e-District, U.P.
Revenue Court – Copy of Final Ordere-
Dis
tric
t App
licat
ion
Cit
izen
A citizen logs on to the e-District Website and Clicks on link for Revenue Courts
Citizen selects the Court and Enters the Case
Number
The eDistrict Application displays the Final Order
PDF, which may be downloaded.
116
‘T0-Be’ & FRS Report – Pilot e-District, U.P.
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
‘T0-Be’ & FRS Report – Pilot e-District, U.P.
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
‘T0-Be’ & FRS Report – Pilot e-District, U.P.
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
‘T0-Be’ & FRS Report – Pilot e-District, U.P.
Grievances
120
‘T0-Be’ & FRS Report – Pilot e-District, U.P.
S. No. Functional Requirements – Grievance Filing
1
E district Application is the application meant for maintaining all the
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
3 Should be able to provide information to the citizens about details
related to grievance filing.
4 Should be able to generate a unique registration number during
registering an applicant with the application. Should be able to
identify the applicant uniquely based on this registration number.
5 Should be able to issue an acknowledgement receipt once the
applicant is registered with the system.
6 Should be able to map the payment details of the transaction with
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
11 Should allow the stakeholders to track the application status at
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
‘T0-Be’ & FRS Report – Pilot e-District, U.P.
has been prepared and he can take a printout of the same.
14 Should be able to auto generate grievance to higher authorities in
case specified SLAs are not met by the officials as per the auto
escalation mechanism of monitoring component.
15 Should generate monitoring reports on specified time intervals and
send it to relevant authorities
16 Should provide access to authorities to monitor Application Status /
Performance / SLAs for a particular period by logging onto the system
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
20 Should be able to send SMS to applicant in case of missing of final
SLAs and status tracking.
122
‘T0-Be’ & FRS Report – Pilot e-District, U.P.
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
‘T0-Be’ & FRS Report – Pilot e-District, U.P.
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