You are on page 1of 216

INFORMATION TECHNOLOGY, ELECTRONICS &

COMMUNICATIONS DEPARTMENT
GOVERNMENT OF ANDHRA PRADESH
HYDERABAD

REQUEST FOR PROPOSAL


FOR
SELECTION OF SYSTEM INTEGRATOR
OF
TEMPLE MANAGEMENT SYSTEM under e-Pragati IN
ANDHRA PRADESH STATE
Volume I

Andhra Pradesh Technology Services


Limited
4th Floor, B-Block, BRKR Bhavan
Tankbund Road, Hyderabad 500 063.

e-Pragati Requirements Specification Document Temple Management System Page 1 of


216

Proprietary & Confidential


No part of this document can be reproduced in any form or by any means,
disclosed or distributed to any person without the prior consent of APTS
except to the extent required for submitting bid and no more.

e-Pragati Requirements Specification Document Temple Management System Page 2 of


216

RFP Structure

This RFP is meant to invite proposals from interested companies capable


of delivering the services described herein. The content of this RFP has
been documented as a set of three volumes explained below:

Volume I: Functional, Technical and Operational Requirements


Volume I of RFP intends to bring out all the details with respect to solution
and other requirements that ITE&C department deems necessary to share
with the potential bidders. The information set out in this volume has been
broadly categorised as Functional, Technical, and Operational covering
multiple aspects of the requirements.

Volume II: Instructions to Bidders, Scope of Work and Financial


and Bidding Terms& Forms
Volume II of RFP purports to detail out all that may be needed by the
potential bidders to understand the Terms & Conditions, project
implementation approach, commercial terms and bidding process details.

Volume III: Contractual and Legal Specifications


Volume III of RFP is essentially devoted to explain the contractual terms
that ITE&C department wishes to specify at this stage. It also includes a
draft of Master Services Agreement.
Volume is Volume IV
Volume IV of RFP is essentially provides the Technical Specifications of the
Hardware infrastructure proposed to be supplied, installed and
commissioned at various implementation locations in Andhra Pradesh
under the e-Pragati Temple Management System Package.
This document is Volume I
Kindly note that all volumes of the RFP have to be read in conjunction as
there are cross references on sections in these volumes. The selected
System Integrator will be solely responsible for any gaps in scope
coverage caused by not referring to all three volumes.

e-Pragati Requirements Specification Document Temple Management System Page 3 of


216

e-Pragati Requirements Specification Document


Temple Management System [Package Code TM]
Table of Contents
1. E-PRAGATI PROGRAM REQUIREMENTS.....................................................10
1.1.
1.2.
1.3.
1.4.
1.5.
1.6.

OVERVIEW............................................................................................................ 10
VISION.................................................................................................................. 10
VALUE PROPOSITION OF E-PRAGATI........................................................................11
MANDATORY PRINCIPLES OF E-PRAGATI..................................................................12
COMMON MANDATORY STANDARDS OF E-PRAGATI...................................................14
NUMBERING AND NAMING CONVENTIONS................................................................14

2. OVERVIEW OF THE DOMAIN.....................................................................16


2.1. ENDOWMENTS DEPARTMENT..................................................................................16
3. SYSTEM OVERVIEW OF TEMPLE MANAGEMENT SYSTEM............................23
3.1. FACT SHEETS........................................................................................................ 23
3.2. TRANSFORMATIONAL REQUIREMENTS OF TEMPLE MANAGEMENT SYSTEM..................25
3.2.1.............................................................................................. GAME CHANGERS
26
3.2.2......................................................................................... BPR REQUIREMENTS
28
3.2.3.................................................. IMPORTANT COMMON PROCESSES RE-ENGINEERED
28
3.2.4......................................................................................... DEPLOYMENT MODEL
28
3.3. NETWORK ARCHITECTURE VIEW FOR CLOUD DEVELOPMENT OF GREENFIELD
APPLICATIONS VS INTEGRATION OF LEGACY APPLICATIONS................................................31
3.4. IMPLEMENTATION MODEL & REVENUE MODEL.........................................................33
3.4.4............................................................... ASSUMPTIONS ON THE REVENUE MODEL
34
3.4.5............................................................................................. INCENTIVE MODEL
35
4. SCOPE OF WORK OF SI SELECTED FOR TEMPLE MANAGEMENT SYSTEM.....37
4.1. SYSTEM REQUIREMENTS STUDY,............................................................................37
4.2. SOLUTION ANALYSIS, ARCHITECTURE AND DESIGN..................................................37
4.3. IMPACT ANALYSIS..................................................................................................38
4.4. PROCESS RE-ENGINEERING.....................................................................................38
4.5. FORMS RE-ENGINEERING........................................................................................38
4.7. APPLICATION DEVELOPMENT..................................................................................39
4.8. SOFTWARE APPLICATION TESTING & QUALITY ASSURANCE......................................40
4.9. SOLUTION DOCUMENTATION...................................................................................41
4.10. DEPLOYMENT, COMMISSIONING AND GO-LIVE.........................................................41
4.11. USER TRAINING (TRAIN THE TRAINERS)..................................................................42
4.12. IMPLEMENTATION STRATEGY...................................................................................42
4.13. PILOT IMPLEMENTATION SMART TEMPLE PILOT........................................................42
4.15. GO-LIVE AND OPERATIONS & MAINTENANCE..........................................................42
e-Pragati Requirements Specification Document Temple Management System Page 4 of
216

4.16. OPERATIONS & MAINTENANCE...............................................................................43


4.16.1.................................................. OVERVIEW OF POST IMPLEMENTATION SERVICES
44
4.16.2........................................................................... ANNUAL TECHNICAL SUPPORT
45
4.16.3....................... TECHNICAL HELPDESK AND TROUBLE TICKET MANAGEMENT SYSTEM
45
4.16.4...................................................................... HEALTH MONITORING OF SYSTEM
46
4.17. DELIVERABLES....................................................................................................... 48
4.18. IT SERVICE DELIVERY............................................................................................ 53
5. APPLICATION ARCHITECTURE..................................................................54
5.1. APPLICATIONS, MODULES, SUB-MODULES...............................................................54
5.2. ARCHITECTURE OVERVIEW.....................................................................................60
5.2.1........................................................................................ PRESENTATION LAYER
61
5.2.2...................................................................................... BUSINESS LOGIC LAYER
62
5.2.3......................................................................................... DATA ACCESS LAYER
63
5.2.4........................................................................... COMMON TECHNICAL SERVICES
63
5.2.5............................................................................. TEMPLE PACKAGE DATABASES
64
5.2.6............................................................................. COMMON SECURITY SERVICES
64
6. BUSINESS ARCHITECTURE.......................................................................65
6.1. FUNCTIONAL REQUIREMENTS..................................................................................68
6.2. SERVICE PORTFOLIO OF TM PACKAGE....................................................................69
6.3. E-PRAGATI INDICATORS (E-PIS)..............................................................................77
7. DATA ARCHITECTURE & REQUIREMENTS...................................................78
7.1.
7.2.
7.3.
7.4.
7.5.
7.6.

DATA ARCHITECTURE.............................................................................................78
CONCEPTUAL DATA MODELS..................................................................................78
DATA INTEGRATION VIEW.......................................................................................80
MASTER DATA....................................................................................................... 81
DATA ARCHITECTURE COMPLIANCE REQUIREMENTS..................................................81
DATA ARCHITECTURE COMPLIANCE REQUIREMENTS..................................................83

8. TECHNOLOGY ARCHITECTURE..................................................................86
8.1
8.2
8.3
8.4
8.5

HIGH-LEVEL TECHNOLOGY ARCHITECTURE...............................................................86


LOGICAL TECHNOLOGY ARCHITECTURE....................................................................86
SIZING REQUIREMENTS.......................................................................................... 88
SECURITY ARCHITECTURE.......................................................................................89
ACCESS CONTROL MECHANISM OF ENDOWMENTS PACKAGE.....................................91

9. TRAINING & CHANGE MANAGEMENT........................................................94


9.1
9.2
9.3

INDICATIVE TRAINING REQUIREMENTS.....................................................................94


TRAINING DELIVERABLES.......................................................................................95
TRAINING RESPONSIBILITY & DURATION.................................................................95

e-Pragati Requirements Specification Document Temple Management System Page 5 of


216

9.4
9.5

TRAINING NEED..................................................................................................... 95
CHANGE MANAGEMENT.......................................................................................... 96

e-Pragati Requirements Specification Document Temple Management System Page 6 of


216

Annexures
ANNEXURE 1 - INTEGRATION ARCHITECTURE..............................................................................97
ANNEXURE 2 - EXISTING TEMPLE MANAGEMENT SYSTEM APPLICATIONS.........................................104
ANNEXURE 3 - TO-BE PROCESSES RECOMMENDED FOR SELECTED FUNCTIONS OF TMS (INDICATIVE
PROCESS RE-ENGINEERING)........................................................................................... 108
ANNEXURE 4 - FUNCTIONAL REQUIREMENTS OF COMMON COMPONENTS OF E-PRAGATI CONSUMED BY
TMS.......................................................................................................................... 115
ANNEXURE 5 - FUNCTIONAL REQUIREMENTS OF COMMON MODULES AND SUB-MODULES OF TEMPLE
MANAGEMENT SYSTEM.................................................................................................. 123
ANNEXURE 6 - FORMS RE-ENGINEERING REQUIREMENTS OF COMMON MODULES & SUB-MODULES OF
TMS.......................................................................................................................... 154
ANNEXURE 7 - AS-IS SAMPLE FORMS....................................................................................158
ANNEXURE 8 - MIS REPORTING REQUIREMENTS.......................................................................160
ANNEXURE 9 - EPI & KPI REQUIREMENTS...............................................................................163
ANNEXURE 10 - NON-FUNCTIONAL REQUIREMENTS OF TEMPLE MANAGEMENT SYSTEM....................164
ANNEXURE 11 - LIST OF SCHEMES IN ENDOWMENTS DEPARTMENT/ INSTITUTION.............................167
ANNEXURE 12 - LIST OF TEMPLES UNDER ENDOWMENTS DEPARTMENT.........................................168
ANNEXURE 13 SOFTWARE APPLICATION TESTING & QUALITY ASSURANCE...................................170
ANNEXURE 14 - BOM FOR PILOT IMPLEMENTATION OF TEMPLE MANAGEMENT SYSTEM.....................173
ANNEXURE 15 - GLOSSARY.................................................................................................. 181

e-Pragati Requirements Specification Document Temple Management System Page 7 of


216

List of Figures
FIGURE
FIGURE
FIGURE
FIGURE
FIGURE
FIGURE
FIGURE
FIGURE
FIGURE
FIGURE
FIGURE
FIGURE
FIGURE
FIGURE
FIGURE
FIGURE
FIGURE
FIGURE
FIGURE
FIGURE
FIGURE
FIGURE
FIGURE
FIGURE
FIGURE

1: INTEGRATED VIEW OF REVENUE GROUP DEPARTMENTS....................................................18


2: DEPLOYMENT MODEL...............................................................................................30
3: HOLISTIC VIEW OF TEMPLE MANAGEMENT PACKAGE........................................................55
4: DEPARTMENT SPECIFIC MODULES & SUBMODULES..........................................................59
5: TEMPLE APPLICATION ARCHITECTURE OVERVIEW.............................................................60
6: BIG PICTURE OF PILGRIM SERVICES LIFE CYCLE.............................................................65
7: BIG PICTURE OF TEMPLE MANAGEMENT SYSTEM............................................................66
8: INFORMATION-SERVICE HARMONISATION FRAMEWORK.....................................................67
9: E-PI FRAMEWORK.................................................................................................... 77
10: CONCEPTUAL DATA MODEL FOR TMS.......................................................................79
11: TMS DATA INTEGRATION MODEL..............................................................................80
12: E-PRAGATI SECURITY ARCHITECTURE FRAMEWORK OVERVIEW.........................................89
13: ACCESS CONTROL MECHANISM OF TMS.....................................................................92
14: INTER-PACKAGE INTEGRATION VIEW...........................................................................97
15: AS-IS ASSESSMENT OF ASSESSABLE INCOME.............................................................108
16: TO-BE ASSESSMENT OF ASSESSABLE INCOME............................................................109
17: AS-IS ASSESSMENT OF GOOD FUND MANAGEMENT.....................................................111
18: TO-BE ASSESSMENT OF GOOD FUND MANAGEMENT....................................................111
19: AS-IS PROCESS OF MANUAL ACCOMMODATION BOOKING.............................................113
20: TO-BE PROCESS OF ACCOMMODATION BOOKING IN TMS............................................113
21: AS-IS ROOM BOOKING APPLICATION FORM................................................................155
22: TO-BE ROOM BOOKING APPLICATION FORM...............................................................157
23: AS-IS SUBSCRIPTION FOR TEMPLES MAGAZINE FORM...................................................158
24: AS-IS DONATION TO TEMPLES FORM........................................................................158
25: AS-IS SRI DURGA MALLESWARA SWAMY SEVAS AND ACCOMMODATION FORM..................159

List of Tables
e-Pragati Requirements Specification Document Temple Management System Page 8 of
216

1: PRINCIPLES OF E-PRAGATI.......................................................................................... 13
2: E-PRAGATI COMMON MANDATORY STANDARDS................................................................14
TABLE 3: E-PRAGATI OBJECT CODE TABLE...................................................................................15
TABLE 4: CLASSIFICATION OF INSTITUTIONS................................................................................16
TABLE 5: NAMES OF TMS USER DEPARTMENTS / INSTITUTIONS.......................................................16
TABLE 6: WEBSITES OF TMS USER DEPARTMENTS/TEMPLES...........................................................17
TABLE 7: KEY OBJECTIVES OF TEMPLE MANAGEMENT SYSTEM.........................................................22
TABLE 8: FACT SHEET........................................................................................................... 23
TABLE 9: DETAILED FACTSHEET...............................................................................................24
TABLE 10: PILGRIMS VOLUME.................................................................................................. 25
TABLE 11: INDICATIVE TRANSACTION SCOPE...............................................................................25
TABLE 12: DEPLOYMENT MODEL COMPONENTS............................................................................31
TABLE 13: TEMPLE MANAGEMENT SYSTEM CLOUD COMPONENTS...................................................32
TABLE 14: REVENUE MODEL OF THE ENDOWMENTS PACKAGE DEPARTMENT.......................................34
TABLE 15: DEPLOYMENT, COMMISSIONING AND GO-LIVE................................................................41
TABLE 16: OPERATIONS & MAINTENANCE...................................................................................47
TABLE 17: TMS PACKAGE DELIVERABLES.................................................................................53
TABLE 18: VIEWS OF TEMPLE APPLICATION.................................................................................62
TABLE 19: COMMON TECHNICAL SERVICES.................................................................................63
TABLE 20: LIST OF COMMON PILGRIM FACING SERVICES OF TEMPLE MANAGEMENT SYSTEM.................74
TABLE 21: LIST OF INTERNAL SERVICES OF TEMPLE MANAGEMENT SYSTEM......................................76
TABLE 22: TEMPLE MANAGEMENT SYSTEM KEY PERFORMANCE INDICATORS.....................................77
TABLE 23: TMS INTEGRATION REQUIREMENTS............................................................................81
TABLE 24: DATA ARCHITECTURE COMPLIANCE REQUIREMENTS........................................................82
TABLE 25: DATA ARCHITECTURE COMPLIANCE REQUIREMENTS.........................................................85
TABLE 26: COMPONENTS OF THE TECHNOLOGY...........................................................................87
TABLE 27: E-PRAGATI SECURITY ARCHITECTURE FRAMEWORK COMPONENTS......................................91
TABLE 28: INDICATIVE TRAINING REQUIREMENTS..........................................................................94
TABLE 29: TRAINING DELIVERABLES..........................................................................................95
TABLE 30: TRAINING MODULES AND TARGETED AUDIENCE.............................................................96
TABLE 31: CHANGE MANAGEMENT REQUIREMENTS.......................................................................96
TABLE 32: CHANGE MANAGEMENT SPECIAL CONSIDERATIONS.......................................................96
TABLE33: APPLICATIONS INTEGRATION MODES..........................................................................98
TABLE 34: INTRA-PACKAGE APPLICATION REQUIREMENTS.............................................................103
TABLE 35: APPLICATION CATEGORIES.......................................................................................104
TABLE 36: EXISTING APPLICATIONS STATUS IN TMS..................................................................104
TABLE 37: EXISTING SERVICES STATUS IN TEMPLES/INSTITUTIONS..................................................107
TABLE 38: ASSESSABLE INCOME BENEFITS TO SYSTEM................................................................110
TABLE 39: ASSESSABLE INCOME PROCESS DESCRIPTION AND RESPONSIBILITY..................................110
TABLE 40: GOOD FUND MANAGEMENT BENEFITS TO SYSTEM........................................................112
TABLE 41: GOOD FUND MANAGEMENT PROCESS DESCRIPTION AND RESPONSIBILITY..........................112
TABLE 42: TMS ACCOMMODATION BOOKING BENEFITS..............................................................114
TABLE 43: TMS ACCOMMODATION BOOKING PROCESS DESCRIPTION AND RESPONSIBILITY.................114
TABLE 44: EPIS OF TMS...................................................................................................... 163
TABLE 45: SCALABILITY PROVISIONS.......................................................................................164
TABLE 46: PERFORMANCE PROVISIONS....................................................................................164
TABLE 47: AVAILABILITY PROVISIONS.......................................................................................165
TABLE 48: RELIABILITY PROVISIONS......................................................................................... 165
TABLE 49: MANAGEABILITY PROVISIONS...................................................................................165
TABLE 50: USABILITY PROVISIONS..........................................................................................166
TABLE 51: LIST OF SCHEMES IN TMS PACKAGE DEPARTMENT.......................................................167
TABLE 52: LIST OF TEMPLES UNDER ENDOWMENTS DEPARTMENT..................................................169
TABLE
TABLE

e-Pragati Requirements Specification Document Temple Management System Page 9 of


216

TABLE
TABLE
TABLE
TABLE
TABLE
TABLE
TABLE
TABLE
TABLE
TABLE
TABLE
TABLE

53:
54:
55:
56:
57:
58:
59:
60:
61:
62:
63:
64:

HARDWARE COMPONENTS FOR DEPARTMENT..............................................................173


ALL IN ONE DESKTOPS COMPUTER SPECIFICATIONS.......................................................174

HAND HELD COMPUTER SPECIFICATIONS................................................................174

COMPACT BILL PRINTERS SPECIFICATIONS...................................................................175

MFP LASER JET PRINTERS SPECIFICATIONS.................................................................175


INK-JET MFP PRINTERS SPECIFICATIONS.....................................................................176
MINIMUM 8 TABLET WITH SIM SPECIFICATIONS..........................................................176
WI-FI ACCESS POINTS SPECIFICATIONS......................................................................177
SPECIFICATIONS FOR BIOMETRIC DEVICES FOR VARIOUS COUNTERS.................................178
SPECIFICATIONS FOR BIOMETRIC DEVICES FOR STAFF ATTENDANCE SYSTEM......................178
PC BASED TICKET VENDING MACHINE SPECIFICATIONS...................................................179
5 KV UPS WITH 2 HOURS BACK-UP SPECIFICATIONS....................................................180

e-Pragati Requirements Specification Document Temple Management System


of 216

Page

1. e-Pragati Program Requirements


1.1. Overview
Use of information technology to automate and digitise government activities
and services is not new to India. The Digital India program launched by the
Government of India aims to propel the country to the next level of eGovernance maturity. Envisaged to be a programme to transform India into a
digitally empowered society and knowledge economy, it sets the long term
direction. Similarly, states have their respective e-governance initiatives.
Collectively, there is no dearth of programmes and projects to implement this
vision. The question that emerges is with so many things happening, what should
bind them together in a holistic approach, such that there is convergence and
coherence.
e-Pragati, the Andhra Pradesh State Enterprise Architecture, is this new
paradigm. It is a Whole-of-Government framework and adopts a missioncentric approach to implementation. e-Pragati seeks to help realise the vision of
Sunrise AP 2022 by supporting the 7 development Missions launched by the
Government in the areas of Temple Management System, Social Empowerment,
Skill Development, Urban Development, Infrastructure, Industrial Development
and the Services Sector.

1.2. Vision
e-Pragati is not a project. It is large Program, with a long term vision for creating
a sustainable eco-system of e-Governance. The Vision of e-Pragati is stated
below:
"e-Pragati is a new paradigm in governance based on a Wholeof-Government framework, transcending the departmental
boundaries. It adopts a Mission-centric approach in its design
and implementation and seeks to realise the Vision of Sunrise
AP 2022, by delivering citizen-centric services in a coordinated,
integrated efficient and equitable manner."
e-Pragati is a framework to provide integrated services to citizens through a free
flow of information, and to usher in an era of good governance, characterised by
efficiency, effectiveness, transparency, and foresight. The different dimensions of
the vision of e-Pragati are described below:
Developmental
1. e-Pragati will be a catalyst for enhancing the effectiveness of
implementing various developmental projects and welfare schemes
undertaken by the government.
2. Planning and monitoring of public sector schemes and projects shall take
advantage of IT, GIS and satellite imaging technologies.
Aspirational
1. e-Pragati shall be an effective tool in realising the vision of Sunrise Andhra
Pradesh.
2. e-Pragati shall be rated among the best in the world and help Andhra
Pradesh achieve a high rank in global e-Governance Development Index.
e-Pragati Requirements Specification Document Temple Management System
of 216

Page

3. Andhra Pradesh will focus on quality of life of its citizens with a special
emphasis on quality of Endowments, healthcare, skill development,
agriculture, infrastructure, and services.
Citizen-Centric
1. Citizens and businesses will have a seamless and smooth interface with
government.
2. Departments and government agencies interoperate with ease and
provide integrated services to citizens and businesses.
3. The medium of paper will be minimised in all G2C, C2G, G2B, B2G, and
G2G interactions.

e-Pragati Requirements Specification Document Temple Management System


of 216

Page

Inclusive
1. Digital divide will be adequately addressed, especially leveraging the
mobile technologies.
2. e-Pragati will
governance.

enhance

3. Citizen engagement
effectiveness.

will

realisation
be

of

participative

accomplished

with

and

ease

inclusive
and

cost

Technological
1. Government and citizens will be enabled to take advantage of cuttingedge technologies like SMAC and IoT.
2. Principles of open data, open standards and open APIs will be ingrained in
the designs of all information systems.
3. e-Pragati will ensure the right balance between information security and
privacy of personal data.
4. SI should propose suitable technical solution based on requirements.

1.3. Value Proposition of e-Pragati


In line with its Vision, e-Pragati seeks to move away from the existing systems of
Governance (Government 1.0) towards establishing Government 2.0. The siloed
and hierarchical systems will be replaced by an integrated and collaborative
operating model. The single-channel, 'one-size-fits-all' models of service delivery
will give way to personalised services delivered through multiple channels. The
output-driven processes will be replaced by transparent, outcome-driven
procedures. The citizens will no longer be passive spectators of governance and
mere recipients of services, but will be empowered to be active participants in
the governance process.
All these aspirations will be achieved through establishment of a common and
shared digital infrastructure and applications, delivering a set of integrated and
cross-cutting services based on common standards and Enterprise Principles.
Value to Government:
1. The effectiveness of implementation various development projects and
welfare schemes undertaken by the Government will be enhanced,
through extensive use of Enterprise Project/Program/Scheme
Management Systems.
2. Planning and/or monitoring of public sector schemes and projects shall be
more effective.
3. There would be considerable savings to the exchequer, through a better
targeting of beneficiaries, through a better control on project and scheme
costs, and, from the IT spend perspective, through consolidation of IT
Assets, like hardware, system software and applications.

e-Pragati Requirements Specification Document Temple Management System


of 216

Page

4. An all-round development of the State through alignment of e-Pragati with


the goals of Sunrise AP and a clear focus on e-Pragati Indicators in each
of the 7 missions.
5. The coordination between the government departments would
significantly increase due to free exchange of information via the eHighway.
6. e-Pragati envisages extensive use of Data Analytics tools that would not
only throw up trends, patterns, gaps and areas of improvement in various
Government schemes, but also provide useful suggestions and ideas for
the future actions (preventive and accelerative) through predictive
analytics.
Value to Citizens and Businesses
1. Citizen-centric services provided
convenience and transparency.

by

e-Pragati

would

enhance

the

2. e-Pragati will make the concept of single-window real and enhance the
ease of transacting with the Government.
3. The Certificate-Less Governance System (CLGS) will reduce significant
burden, both on the citizens and the Government departments, by
reducing/eliminating unproductive work.
4. Programs like e-Health, e-Endowments, e-Agriculture and e-Market shall
enhance quality of life and productivity as well as income of the citizens.
5. Direct Benefits Transfer will ensure hassle-free availability of the various
benefit programs of the Government.
6. Widespread use of e-Office and other productivity tools will enhance
transparency of public agencies.
Value to Society:
1. The implementation of e-Pragati will unleash a lot of potential in the
software, hardware, electronics and networking sectors. This will have a
significant extent of multiplier effect to the tune of 4 X.
2. e-Pragati, being based on open technologies, will open up new windows for
innovation and create IT and non-IT employment in various sectors.
3. The economic development of the State will be spurred by increased
productivity in all the 7 major sectors comprising the Sunrise AP Mission.
4. The successful implementation of e-Pragati is likely to motivate several
such initiatives across the country, as witnessed in respect of the CARD
and e-Seva projects pioneered by AP, and would lead to speedier national
development.

1.4. Mandatory principles of e-Pragati

e-Pragati Requirements Specification Document Temple Management System


of 216

Page

A large and complex program like e-Pragati cannot make a radical impact
unless certain fundamental principles of Enterprise Architecture are adopted by
all the stakeholders, namely, the Government, the System Integrators and the
users. These are stated below. It is the responsibility of the System
Integrator selected for the implementation of the Temple Management
System, to meticulously observe and / or promote the observance of
these principles by the other stakeholders.
Principle #1: Uphold the Primacy of these Principles
These principles of information management apply to all organisations
within the Government.
Principle #2: Maximise benefit to the Government as a whole
All decisions relating to information management are made to provide
maximum benefit to the Government as a whole. Some organisations may
have to concede their own preferences for the greater benefit of the entire
Government. Applications and components should be shared across
organisational boundaries.
Principle #3: Information Management is Everybodys Business.
All organisations in the Government participate in information
management decisions needed to accomplish business objectives, and
implement such decisions with full commitment, devoting the right and
adequate resources. Respective Domain Owners and Managers shall
develop their own sub-architectures following these principles, and
federate the same to APSEA.
Principle #4: Government is a Data Trustee
Each data element has a trustee accountable for data quality. Only the
data trustee makes decisions about the content of data, and authorises its
modification. Information should be captured electronically once and
immediately validated as close to the source as possible. Quality control
measures must be implemented to ensure the integrity of the data
Principle #5: Establish Common Vocabulary and Data Definitions
Data is defined consistently throughout Government, and the definitions
are understandable and available to all users. Defining Metadata and Data
Standards (MDDS) within each domain assumes great significance.
Principle #6: Data is Shared
Data is shared across enterprise functions and organisations. It is less
costly to maintain timely, accurate data in a single application, and then
share it, than it is to maintain duplicative data in multiple applications.
Shared data will result in faster and improved decisions.
Principle #7: Data is an Asset.
Data is an asset that has a specific and measurable value to the
Government and is to be managed accordingly.

e-Pragati Requirements Specification Document Temple Management System


of 216

Page

Principle #8: Build Once, Use Many Times


Applications which have functionality used in all or several departments
should be built once and used commonly by all, to reduce cost and
complexity.
Principle #9: Enterprise Architecture is Technology Independent
Applications are independent of specific technology choices and therefore
can operate on a variety of technology platforms.
Principle #10: Adopt Service Oriented Architecture
The enterprise architecture is based on a design of services which mirror
real-world activities required to conduct the business of Government.
Open Standards-based Service Oriented Architecture shall be adopted in
all implementations to realise interoperability and location transparency.
Principle #11: Interoperability
Software and hardware should conform to defined standards that promote
interoperability for data, applications, and technology.
Principle #12: Data Security
Data is protected from unauthorised use and disclosure. This includes, but
is not limited to protection of pre-decisional, sensitive, source selectionsensitive, personal and proprietary information. Data standards applicable
to GoI are identified and listed out in standards document.
TABLE

1:

PRINCIPLES OF E -P RAGATI

e-Pragati Requirements Specification Document Temple Management System


of 216

Page

1.5. Common Mandatory Standards of e-Pragati


A set of Common Mandatory Standards is prescribed for strict compliance
by all the System Integrators selected for implementing different
packages of e-Pragati, so as to ensure interoperability, maintainability and
uniformity of user experience across the entire landscape of e-Pragati.
These relate to the areas listed below:
Standard
Code
SD01
SD02
SD03
SD04
SD05
SD06
SD07
SD08
SD09
SD10
SD11
SD12
SD13
SD14
SD15
SD16
SD17
TABLE

2: E-PRAGATI

Standard
Interoperability
Software Engineering
Documentation
Testing
Usability
IT Services
Mobility
Security
Document Management
Imaging
GIS
Localisation
Metadata
Master Data
Data Definition
Data
&Information
Exchange
Access, Presentation and
Style
COMMON MANDATORY STANDARDS

The technical specifications of the above standards can be accessed at the URL
http://e-pragati.ap.gov.in/bestpractices.html.
It shall also be the responsibility of the SI to upgrade the systems to the relevant
standards, whenever the standards are revised, during the currency of the
contract. It's part of the SIs responsibility to follow/specify the relevant
standards for upgradation of system.

1.6. Numbering and Naming Conventions


The following numbering and naming conventions have been followed by the
GoAP, while preparing the ePRS documents relating to the e-Pragati. To the
extent required, all the SIs shall adopt the same in their documentation and
coding as the case may be, for cross-referencing and interoperability between
various packages and modules. Since Integration of various functionalities,
modules, services and applications across e-Pragati is the essential
requirement of the Program, it is absolutely necessary for everyone to follow
the discipline in adopting the naming and numbering convention for all
bespoke solutions for e-Pragati.
e-Pragati Requirements Specification Document Temple Management System
of 216

Page

The following guidelines may be noted in this regard:


i.
ii.

iii.

iv.

Sl.
No.
1.

A comprehensive table called Object Code Table has to be


eventually prepared listing out the name/numbers (codes) for all the
e-Pragati Objects described in the Table 2 below.
The aforesaid Object Code Table will be hosted in the e-Pragati
Portal for reference by all developers. The Object Codes will be
developed in a progressive manner and the Object Code table will
be updated from time-to-time.
The SI will have to develop the e-Pragati Objects as Web Services
discoverable by the e-Pragati Object Codes. The Web Services shall
be hosted on the e-Highway platform using the applicable Web
Services Standards, such that they can be consumed by the other
applications of e-Pragati, or by external applications and Apps as
required.
COTS products have usually their own Object Codes or Transaction
Codes to handle such situation within the Product. This is especially
true for all ERP products. It is necessary for the SI using a COTS
product as a part of the solution for any package, to create a Table
that maps the e-Pragati Object Codes to the Object Codes of that
COTS product. Usage of COTS / industry proven solutions are
encouraged as long as they adhere to the principles of e-Pragati.

2.

e-Pragati
Object
Package/
System
Module

3.

Sub-module

4.

Functional
Requirement

5.

Interface

6.

UML Diagram

7.

Report

8.

Services

Illustration / Comment
TM is for Temple Management System
TM01 for Pilgrim Service Applications in Temple
Management System
TM0101 for Pilgrim Verification Sub-Module in Temple
Management System

GoAP will publish the naming and numbering


conventions for these objects at the appropriate time
and notify in the e-Pragati Portal.

TABLE

3: E-PRAGATI

OBJECT CODE TABLE

e-Pragati Requirements Specification Document Temple Management System


of 216

Page

e-Pragati Requirements Specification Document Temple Management System


of 216

Page

2. Overview of the domain


2.1. Endowments Department
Endowments Department for the purpose of administration of Religious and
Charitable institutions
The Endowments Act 30/87 and other amendments provide adequate degree
of supervision and control over the working of the Hindu Religious and Charitable
Institutions. Such control is sought to be achieved in a variety of ways,
which include:
a) Compulsory registration of all the Institutions with the Department.
b) Appointment of Trustees for managing the Institutions.
c) Appointment of Government Officers as Executive Officers, such appointment
being compulsory in the case of institutions with an income above the
specified limit for the purpose of the day-to-day administration of the
Institutions.
d) Compulsory prior approval of the Budgets of the institutions by competent
authorities.
e) Annual audit of the accounts and pre-audit of the institutions through the
Local Fund Audit.

The classification of institutions have been published under section 6 of the


Endowments Act, as detailed below:
Sl.
No.
1.
2.
3.
4.
5.

Section

classification

6(a) institutions
6(b) institutions
6(c) institutions
6(d) institutions
6(e) institutions

Annual Income above Rs.25 Lakhs


Annual Income Between Rs.2 Lakhs to Rs.25 Lakhs
Annual Income Below Rs.2 Lakhs
All the Mutts irrespective of the income
All Dharmadayams irrespective of the income

TABLE

4:

CLASSIFICATION OF INSTITUTIONS

The Temple Management System serves the following departments, institutions


and agencies:
Sl.
No.
1.
2.
3.
4.
5.

Name of the Department/ Agency


Secretariat
Hindu Dharmika Parishad
Endowments Department
Temples
Mutts/Peetams

Nature**
(SD/HoD/Trust/Socie
ty)
SD
Governing Body
HoD
Trust
Trust

e-Pragati Requirements Specification Document Temple Management System


of 216

Page

Sl.
No.
6.

Name of the Department/ Agency

Nature**
(SD/HoD/Trust/Socie
ty)
HoD

State Institute of Temple Administration


( SITA )

** SD-Secretariat Department; HoD-Head of Department


TABLE

5:

NAMES OF

TMS

USER DEPARTMENTS

INSTITUTIONS

The functional scope of the SI extends to all Temples, Charitable Trusts,


Institutions, Mutts and Peetams.
Exhaustive information on the Departments and Agencies falling in the Temple
Management System can be found in the websites of major temples, shown in
Table 6 below.

Sl.
No.
1.

Name of the Department/


Organisation
Endowments Department

Web site
http://www.apendowments.gov.in

2.

Sri
Varahalakshmi
Narasimha
Swamy
Vari
Devasthanam,
Simhachalam

http://simhachalamdevasthanam.net/

3.

Sri Brahmaramba Mallikarjuna


Swamy Devasthanam, Srisailam

http://www.apendowments.gov.in/srisa
ilam/

4.

Sri Veeravenkata Satyanarayana


Swamy Vari Devasthanam ,
Annavaram

http://www.annavaramdevasthanam.ni
c.in/

5.

Sri Durga Malleswara Swamy


Varla Devasthanam, Vijayawada

http://www.durgamma.com/

TABLE

6:

WEBSITES OF

TMS

USER DEPARTMENTS / TEMPLES

The exhaustive list of temples, having annual assessable incomes above 1


crores, is in Annexure 12.

e-Pragati Requirements Specification Document Temple Management System


of 216

Page

At a broader level Endowments Department comes under Revenue Group


Departments. The integrated view of the Revenue Group Departments stems
from the Whole of Government concept wherein there is dependency of the
primary domain department on secondary domain department to deliver its
services efficiently. This is shown in the below Figure:

FIGURE

1:

INTEGRATED VIEW OF REVENUE GROUP DEPARTMENTS

Further the integrated view of the Endowments Department stems from the
Whole of Government concept wherein there exist direct dependencies between
the primary domain departments and secondary domain departments to deliver
its services efficiently. This is shown in the below Figure:

e-Pragati Requirements Specification Document Temple Management System


of 216

Page

FIGURE

2:

INTEGRATED VIEW OF ENDOWMENTS DEPARTMENT

Given below are the key objectives of the Temple Management System
departments.

e-Pragati Requirements Specification Document Temple Management System


of 216

Page

Sl.
No
.

Departm
ent/
Agency
Objectives
1. Endowm
ents
1.
Departm
ent
2.

3.
4.
5.

6.

7.
8.

2. Hindu
Dharmik
a
Parishad

3. State
Institute
of
Temple
Administ
ration
(SITA )
4. Institutio
ns/Templ
es
/
Mutts/ot
hers

Key Objectives
of different bodies of Endowments Department
To administer Hindu Temples, Mutts, Peetams and other
Charitable Institutions and Endowments
To ensure proper administration of these institutions and
apportioning
their revenue for which they were
established. Control, supervision and administration of
temples and charitable institutions.
To protect the properties of Hindu temples and other
charitable institutions.
Maintain 3-tier system of administration for temples and
Charitable Institutions
Temples with an annual revenue of less than Rs.2 Lakhs
are under the administrative control of Assistant
Commissioner.
Temples with an annual revenue of more than Rs.2 Lakhs
but below Rs.25 Lakhs are under the administrative
control of Deputy Commissioner.
Temples with an annual revenue of more than Rs.25 Lakhs
are under the administrative control of the Commissioner.
In the case of Mutts and Dharmadayams, the
Commissioner has administrative control irrespective of
their revenue.

1. To

ensure proper administration of Hindu religious


Institutions like Temples, Mutts and Peetams in the state
2. To supervise, guide and regulate the functioning of the
Endowments Department
3. To advise the Government on all matters pertaining to the
administration of Hindu temples and charitable trusts
1. To provide training all the employees of the Endowments

Department on Religious, Administrative, Engineering &


Sculpture matters.
2. Ensure
capacity building, skill development and
professional updating in job related functions and for
improvement in the quality of the Temples related
functions.
1. To
2.
3.
4.
5.
6.

forecast, plan and execute day-to-day activities


performed in temples
To provide pilgrim centric services like accommodation,
Darshanam / seva tickets, donations.
To ensure Temples management activities like basic
infrastructure, proper sanitation, drinking water facilities.
To manage security aspects of temples, Queue
management, Rapid response team in case of emergency.
To keep account of Incomes and expenditures of temples
& work management
To plan and manage procurement and auction activities of
temples
To enable investment management

7.
e-Pragati Requirements Specification Document Temple Management System
of 216

Page

Objectives of the departments with Endowments department


5.
Revenue
1. To protect temples related Lands
2. To maintain temples related Land records
3. To assess and collect commercial taxes
4. To enable registration of records
5. To collect revenue under Excise act
6.
Municipal
1. To collect taxes, execute project and civic works
Administrati 2. To provide amenities like water, roads, street
on
lighting and sanitation facilities at Temples under
ULBs purview
3. Identification of Temples and provide information
services
7.
Police
1. To provide law & order enforcement services,
preventive and investigative
2. To provide security during fairs and festivals
8.
Town and
1. To plan and develop urban area including Temples
country
areas
planning
2. To prepare Master Plans including temples details
3. Provide technical remarks to the Government in
the matters like change of land use proposals,
alienation of lands and any relaxation of rules for
Endowments lands
9.
Roads &
1. To provide and maintain a road network connecting
Buildings
to the Temples area
2. To
construct and maintain accommodation
facilities/guest houses near temples towns/areas
10.
Tourism
1. To promote religious tourism in the state.
2. To promote a steady and sustained growth phase
of the travel and tourism sector in and around
temples towns/areas
3. To attract tourists/pilgrims, inland and foreigners
by promoting pilgrim places/temples
4. To use more publicity to promote tourism
destinations including the facilities and amenities
available at temples
5. To promote eco-friendly and responsible tourism
including a profit share to the local temples
11.
Education
1. To provide access to primary education for all
including staff of endowments department
2. To Provide support Vidyadanam program running
under Endowments Department
3. To Provide support for schools running under
Endowments Department
12.
Health
1. To
plan,
implement,
facilitate,
coordinate,
supervise and monitor all activities relating to
sanitation in all temples
2. To provide emergency medical facilities in Temples
13.
Archaeology 1. To protect and preserve historical monuments and
& Museums
sites of religious importance
2. To explore and excavate sites of religious
importance
3. Epigraphical survey and Publications
4. To establishment and upgrade Museums at
religious locations.
14.
Law
1. To issue statutory rules, notifications or orders
2. To sanction statutory power, the issue of any rule,
byelaw, notification or order by a subordinate
e-Pragati Requirements Specification
Document Temple Management System
Page
authority
of
216
3. To submit any drafts for statutory rules,
notifications or orders
4. To constitute statutes, Acts, Regulations and

TABLE

7:

KEY OBJECTIVES OF

TEMPLE M ANAGEMENT S YSTEM

* The System Integrator should take the responsibility to propose suitable


solutions to fulfil the key objectives of the department through Temple
Management System of e-Pragati keeping in view the Whole of Government
approach and e-Pragati eco-system.

3. System Overview of Temple Management System


3.1. Fact Sheets
The basic facts of the Temple Management System are provided as under:
The number of institutions registered under section 6 with Endowments
department, as detailed in Table 8A, of Andhra Pradesh (district-wise):
Sl.
No
.
1
2
3
4
5
6
7
8
9
10
11
12
13

District
Srikakulam
Vizianagaram
Visakhapatna
m
East
Godavari
West
Godavari
Krishna
Guntur
Prakasam
Nellore
Kadapa
Kurnool
Anantapur
Chittoor

Total

6(a
)
(i)
0
1

6(a)
(ii)

6(b)
(i)

6(b)
(ii)

6(c)
(ii)

6(c)
(i)

6(
d)

6(
e)

TOTA
L

1
2

1
0

19
11

24
47

758
503

18
4

1
0

822
568

42

40

917

1013

16

52

129

149

1379

1740

13

14

138

230

1318

1716

1
1
0
1
0
0
1
0

14
11
6
9
4
6
5
7

12
12
9
6
0
7
11
1

69
72
39
42
22
37
12
31

102

131

663

1216
1581
1270
1126
1840
3701
1975
3315
2089
9

7
6
12
7
8
21
4
38
13
5
6(
d)
13
5

1
0
0
0
0
0
0
0

13

106
424
297
116
8
116
67
265
188
9

1426
2107
1633
1307
1882
3888
2075
3657
2383
4

6(a)

6(b)

6(c)

115

794

22788

Total No. of
Institutions

2
6(
e)
2

2383
4

23834
TABLE

8: FACT S HEET

e-Pragati Requirements Specification Document Temple Management System


of 216

Page

The details of Endowments Departments (district-wise) Offices and institutions is


detailed in below table:
Sl.
No.
1.
2.
3.

4.

7.

9.

11.

14.
15.
16.
17.
18.

20.

District
Name

Name of
Mutts/Trust/Temples/P
eetams

Head Office

Endowments Department

Srikakulam

DC/AC Office

Vizianagara
m

DC/AC Office

Visakhapatn
am

East
Godavari

West
Godavari

Krishna

DC/AC Office
Sri Varaha
Lakshminarasimha
Swamy Devesthanam
Sri Kanaka Mahalaxmi
Ammavari Temples,
Burujupet
DC/AC Office
Sri Veera Venkata
Satyanarayana Swamy
Devesthanam,
Annavaram
DC/AC Office
Sri Venkateswara Swamy
Devasthanam Dwaraka
Tirumala
DC/AC Office
Sri Durga Malleswara
Swamy Devesthanam
Sri Tirupathamma
Ammavari Devasthanam,
Penuganchiprolu

Guntur

DC/AC Office

Nellore

DC/AC Office

Prakasam

DC/AC Office

Kadapa

DC/AC Office

Kurnool

Ananthapur

22. Chittoor

DC/AC Office
Sri Bhramaramba
Mallikarjuna Swamy
Devasthanam, Srisailam
DC/AC Office
Sri Nettikanti Anjaneya
Swamy Devasthanam,
Kasapuram
DC/AC Office

Number of Officials/Staffs
Perman
Total
Tempora
ent
Staff
ry Staff
Staff
41
0/0
41
19
0/0
19
17
0/0
17
31
0/0
31
305

275

30

68
48

58
48

10
0/0

536
24

307
24

229
0/0

259
26

121
26

138
0/0

418

306

112

88

60

28
0/0

30

30

24

24

26

26

24
50

24
50

0/0

700
22

236
22

464
0/0

108
20

44
20

64
0/0

0/0
0/0
0/0

e-Pragati Requirements Specification Document Temple Management System


of 216

Page

Sri Kalahastheeswara
Swamy Devasthanam ,
Srikalahasthi
Sri Varasiddi Vinayaka
Swamy Devasthanam,
Kanipakam
TABLE

449

166

283

287

75

212

9: D ETAILED FACTSHEET

*Note:
0/0- Not Applicable
Online facilities provided through MeeSeva is not taken in account as it is not
in sync on real time basis.
Transaction Volume
Sl.
No.
1.
2.
3.
4.
5.

No. of
Institutions

Section

Total Pilgrims
Volume (Per day)
2,00,000 (25,000*8)

6(a) institutions

6(b) institutions

51

6(c) institutions

Not applicable

Not applicable

6(d) institutions

Not applicable

Not applicable

6(e) institutions

Not applicable

Not applicable

3,00,000 (6,000*50)

Total pilgrims
TABLE

5,00,000

10: PILGRIMS VOLUME

Indicative Transaction Scope


Sl.
No.
1.
2.
3.

Type of
Transaction
Seva/Darshana
m

Volume (per day)

Accommodation
Peak Load

TABLE

11: INDICATIVE TRANSACTION

5,00,000
2000
9,00,000
SCOPE

*Note:
YoY growth of expected transactions is 10%. SI should design the system to meet
the requirements in the above indicative transactions peak load per day, as
mentioned in the table, and SI should meet the performance requirements
mentioned in the RFP

3.2. Transformational Requirements of Temple Management


System

The Endowments is one of the important departments which provide citizen


centric services. A few reforms were undertaken by some temples in recent

e-Pragati Requirements Specification Document Temple Management System


of 216

Page

years to facilitate the pilgrims. The Hindu religion and its institutions need to
be maintained and managed properly to provide world class facilities to
pilgrims. The development of Temple Management System is expected to
play a key role in the enhancing the pilgrim satisfaction and make the institutions
more efficient and transparent..

Andhra Pradesh has set its target to become one of the top three high
performing states in India by 2022 and achieve the status of the best state in
the country by 2029, and realise the vision of the Sunrise State of Andhra
Pradesh. Vision2029 hopes to impact the lives of every citizen in the State,
enriching and transforming it through well-coordinated small, large and mega
scale development programmes, executed as its seven development focused
missions. The endowments department aims to make Andhra Pradesh as a
preferred choice of pilgrims, creating an integrated and well managed /
maintained temples within the State. This is guided by the Honourable Chief
Minister's vision to:

Provide facilities to pilgrims of international standards


Adopt best practices from other states in India and other countries
Create an atmosphere of best service and management
Integrate technology to the greatest extent possible
Bring about administrative reforms through e-governance

Against this background it is imperative to use the Temple Management


System to bring about transformational changes in endowments department
to make a significant impact on tourist inflow and indirectly to the state
economy by ensuring high accessibility, uninterrupted, real-time and
affordable system for the pilgrims anywhere anytime. The responsibility of
the SI is to design the Temple Management System in such a manner as to
realise the above vision through introduction of a variety of Game Changers
and Process Re-engineering initiatives as described below, but not limited to
the same.
3.2.1.
Game Changers
Game Changers make a qualitative difference to the way activities are
carried out currently and/ or introduce new technologies or processes that
enhance the outcomes significantly. The following game changers are
suggested and the SI shall incorporate them in the solution to be designed
for the Temple Management System.
a. Electronic Ticket Vending machine (Fully automated): To increase
the self-service approach to cater services to pilgrim ticket vending
machine will play an important role by providing following facilities:
i.
To provide information w.r.t. available seva, Darshanam
ii.
Sale of tickets
iii.
Cash Management
iv.
Integration with e-payment module
b. Digital Experience: The user interface or UI has to follow the latest
gamification trends in the industry for the all the functionalities and
screens exclusively used by the pilgrims. The gamification strategy
increases the engagement levels of pilgrims with the Temple Management
System with appropriate facilitation, socialisation programmes such as
e-Pragati Requirements Specification Document Temple Management System
of 216

Page

online Darshanam /Puja, if permissible as per religious principles followed by


each temple, detailed information about upcoming special events,
to
provide Information Dissemination
through digital boards, Kiosks.
Responsive web architecture and single page applications are the need of
the hour in the digital and mobile world to provide citizen services
applications by vital stakeholders through a multitude of access devices,
especially mobile phones.
c. Smart Temple (Pilot Implementation): The Smart Temple envisions
connecting pilgrims with respective temples, administrators and
grievance redressal officials of temples through all available technologies.
It provides various services of the Temples to the stakeholders which
makes the visit to the Temples easier, secure, comfortable and enriching.
These services are not just for darshanam & seva of the respective
temples but also for socialising (satsang), sharing events, providing all
services on finger tips.
i.
ii.
iii.

Real time advanced queue management


Temples Monitoring
Online darshanam / Live streaming, where permissible

A Smart Temple provides a better experience to the pilgrim by facilitating


access and interaction with the temple administration. The complete
information about temples & services can be accessed from any part of
the world. In order to provide seamless connectivity and access to
stakeholders of the Temples in a secured manner, several hardware
technologies, software technologies and electronic devices are required.
The services in a Smart Temple leverages electronic devices /IT to provide
various services.

The proposed "Smart Temple" solution will be implemented on pilot basis


at Sri Durga Malleswara Swamy Varla Devasthanam, Vijayawada.
This shall effectively lower operating cost, reduce waiting time, provide
more access to bookings, facilitate managers' supervisory efforts and
improve the quality of temples by giving pleasant experience by
convergence of various applications and technologies. In addition to the
above, the following advanced technology solutions shall be provided at
the pilot facility.
i.
Wi-Fi and wired Internet facility
ii.
Real time access of booking any services /sevas/ darshanam
iii.
Real time information boards (Display systems) for pilgrims
iv.
Interactive sessions to pilgrims for providing information on
various seva/ Darshanam/ events
v.
High speed access to Temple Management System
vi.
Mobile App
vii.
Biometric authentication based access
viii.
Real time Pilgrim tracking
ix.
Integrated services to the pilgrims on an end-to-end basis,
covering travel plan, booking seva/ special darshanam, booking
accommodation at Vijayawada, purchase of prasadam, booking
of parking slots and online payment system.
e-Pragati Requirements Specification Document Temple Management System
of 216

Page

*The detailed BOM for the Pilot Implementation is provided in


Annexure 14.
d. Dedicated Mobile Apps: Pilgrims are increasingly choosing to consume
services through smart devices. The smartphone adoption rates have
surpassed that of any customer technology in history, including social
networking. With the increasing availability of network infrastructures and
the growing number of smartphone and tablet users, the mobile app
market is becoming an important part of accessibility. Booking of seva,
darshanam, accommodation, donation, publication, prasadam through
interactive and highly customised mobile application shall be new norm in
TMS.
e. Big Data Analytics: Big Data Analytics shall be used by the
Endowments department to conduct not only trend analysis & root cause
analysis of problems on hand, but also predictive analytics to give
forecast for the next six months to an year, to enable them to make the
right interventions in time and to take informed decisions while
implementing / planning the various events. The following scenarios
are prescribed as an initial set to be designed by the SI and
implemented using the DataLytics platform, which is being
established as part of e-Pragati eco-system. It may be noted that
the establishment of the DataLytics Platform is the responsibility of GoAP.
The responsibility of the SI for TMS is to design the different use cases,
coordinate with the SI implementing DataLytics solution, generate the
analytical reports and provide to the Endowments department to take
timely and appropriate decisions or make interventions. The use cases
mentioned below are indicative. The SI shall improve upon the same
and/or replace some and add more useful use cases, during the system
study phase.

3.2.2.

i.

Analysis of trends of pilgrim visiting a temple over the last five


years and predict the increase in percentage of foot falls in
temples/ institutions.

ii.

Real-time analysis to leverage analytic solutions to increase


pilgrims, doners and staff productivity, better manage
finances, streamline operations, and ensure service level.

iii.

The analytics is to provide the holistic view to the


Government/Department to do proper financial planning for
new/existing schemes. To do better Budget management and real
time monitoring.

iv.

Predictive and Prescriptive analysis for policy formulation in the


Endowments Department for increasing the pilgrims, followers
and increased employability.
BPR Requirements

No major e-Governance initiative will produce desired impact unless it is


accompanied by process re-engineering. The following areas have been
e-Pragati Requirements Specification Document Temple Management System
of 216

Page

identified as top candidates for process re-engineering so as to simplify


and eliminate processes and to integrate the service delivery. Process reengineering and forms re-engineering is the responsibility of the selected
SI. The selected SI has to undertake these activities as part of the Systems
Study phase and submit the updated FRS and get the same approved by
PMU.
a. Redesign the systems in a pilgrim-centric way: The services that
the pilgrims need shall be presented in a pilgrim-centric way. The
usability shall be designed keeping in view the literacy levels of the
pilgrims also.
b. Forms re-engineering: The forms used by the stakeholders shall be
re-designed keeping in view the following principles:
i.
As the pilgrims identity can be established through use of
People Hub unique ID or pilgrim ID generated at the time of onetime registration at the Portal, the online forms should not ask
for the other details like address, mobile number. The mobile
application should have the capability to capture the citizen
details by capturing QR code and real time validation from
People Hub Server.
ii.
All the pilgrim-facing forms shall be re-designed with Telugu and
English Interface.
iii.
Forms which are no longer necessary in the context of CLGS
(Certificate-less Governance System) should be abolished.
c. Common Modules: The functionality of several activities and services
of the institutions under Temple Management System are similar. This is
brought out in Section 2.1. Common application modules shall be
designed for all these, as explained in Annexure 4. This follows the
principle of re-usability.
3.2.3.

Important Common Processes Re-engineered

Keeping in view the importance of process re-engineering, some selected


processes have been re-engineered. The indicative TO BE Processes are
shown in Annexure 3.

3.2.4.
Deployment Model
Considering the following factors, it is required that the Temple
Management System is deployed on a public cloud:
a. Elasticity of Demand: The load of Temple Management System will
be quite heavy in specific week days, Hindu festival season and
especially on sanctified days. It would taper down towards the rest of
year, as most of the services are related to the Temple Management
System.
b. Need for mobile access: The applications would be accessed by
Pilgrims/ Management staff of Temples and field department workers,
mostly on mobiles and tablets.
c. Need for cost-effectiveness: By its very nature, services in the
Endowments and allied sectors need to be less expensive to be
e-Pragati Requirements Specification Document Temple Management System
of 216

Page

affordable, where charged. Cloud-based services would be costeffective in volumes. Therefore, cloud deployment model is suitable
and recommended for Temple Management System.
d. The nature of data: The nature of data handled in the Temple
Management System is not confidential or sensitive.
The SI shall implement a highly cost-optimised cloud-based solution, with
the following
requirements:
i.
ii.
iii.
iv.
v.
vi.

Standards of security and privacy shall be complied with GoAP


standards
There shall be strict prohibition of sharing the data with any other
organisation without proper authentication/authorisation and
sharing mechanism
The application and data shall be hosted in a cloud data centre
located within India and shall meet the prescribed SLAs by GoAP
Considering the criticality of the Temple Management System, it
shall be deployed in minimum Tier 3 Cloud Data Centre
The SI is responsible for delivering SLAs with detailed BCP
RTO should be 8 hours, RTP should be 4 hours

e-Pragati Requirements Specification Document Temple Management System


of 216

Page

The following implementation plan is suggested:

FIGURE

Sl.
No
.
1.

Component
VPC & Network
Connectivity

2.

Security
Configurations

3.

Backup Operation

4.

Temple
Management
System
Deployment
VPC and BGP
Tunnels

5.

6.

Elastic Compute &


Block Store

7.

APIs for Legacy


Apps
Snapshot and
Backup Process

8.

2:

DEPLOYMENT MODEL

Comment
SI has to build a network layer for connecting
existing legacy application hosted in
SDC and
department access
SI has to study the existing security configuration to
integrate the new applications with GoAP Security
components
SI has to propose the backup strategy for service
availability and cloud access
SI has to start Temple Management System
development in consultation with Endowments
department
SI has to build secure tunnels between SDC and
Cloud provider for legacy application integration and
connectivity
with
APSWAN/AP
FiberNet
for
departmental access
SI has to coordinate with Cloud provider for
preparation of Compute and Storage block for
Endowments Package deployment. The required
compute and storage shall be elastic in nature
SI has to work with legacy application SI with help of
PMU to get the required APIs for integration, if any
Snapshot and Data Backup policy and data
availability shall be ensured and proof shall be
submitted with PMU

e-Pragati Requirements Specification Document Temple Management System


of 216

Page

Sl.
No
.
9.
10.

11.

Component

Comment

Directory Services
and OS Client

This shall ensure the connectivity of Temple


Management System to integrate with Directory and
IAM server for SSO enablement
Temple Management System applications shall be
deployed on cloud and it shall be made available for
all types of users.

Temple
Management
System
applications
Monitoring
Applications
TABLE

Application and Resources Monitoring shall be


defined and reports shall be submitted to PMU by
the SI
12:

DEPLOYMENT MODEL COMPONENTS

3.3. Network Architecture view for cloud Development of


Greenfield Applications Vs Integration of Legacy Applications

SI has to develop portfolio of applications, which do not exist currently with


the Endowments department in accordance to the guidelines of e-Pragati.
New applications could be added depending on the requirements. Design and
development of the Temple Management System applications should be as
per the BPR, FRS and approved SRS.
SI shall integrate existing legacy applications with Temple Management
System applications. SI should validate list of all the applications to be
integrated with Temple Management System mentioned in the RFP. An
explanatory note on Integration/Mapping of existing applications is provided
under Annexure 1. The Endowments Package applications shall be deployed
on public cloud. These have to be integrated with existing APSWAN/AP
FiberNet network and accessible by departmental users and integrate with
required existing applications. The applications deployed in cloud will
communicate with applications deployed in SDC through dedicated link
between SDC and Cloud provider which needs to be procured and planed by
System Integrator (SI).
The SI shall conduct due diligence on the identified applications to ensure
that each of those can be integrated with the Temple Management System
applications, with or without appropriate modifications/customisation. The
following factors in this regard may be considered:
The application must be developed on a web-based architecture, using
SOA, with centralised databases.
The application must be certified from security and functionality
perspective.
The development environment used for the application is compatible with
the target environment of e-Pragati.
Annexure 2 describes the status of legacy applications. They are grouped
into three categories

A (To be retained)
B (To be enhanced)

e-Pragati Requirements Specification Document Temple Management System


of 216

Page

C (To be retired)

The existing SI shall provide required SOA interfaces for the applications
required to be retained / integrated into Healthcare Package framework
which includes support personnel, training and user manuals on these SOAs.
All green field Temple Management System applications shall be deployed on
public cloud. These have to be integrated with existing legacy applications
which were deployed in SDC. The applications deployed in cloud will
communicate with applications deployed in SDC through an aggregation
layer. Eventually, after the existing servers and storage hardware attains EOL
(End of Life), the hosted legacy applications may be migrated to cloud. SI
may propose an appropriate model for cloud migration (PaaS, IaaS). After the
PMU approves the model, the SI may raise a change request to perform the
migration. The access to State Data Centre (SDC) and applications will be
provided to System Integrator (SI) on need-basis.

F IGURE 5: NETWORK A RCHITECTURE VIEW

Sl.
No
.
1

Component
Cloud
Endowments
Package
Applications
APSWAN

Comment
Endowments Package Applications need to be
deployed on cloud and a dedicated 10 Mbps VPN link
should be commissioned to integrate existing SDC
components. This link should be scalable as per the
demand.
The connectivity to all the existing centres, offices,

e-Pragati Requirements Specification Document Temple Management System


of 216

Page

Sl.
No
.

Component

Trust/
Agencies/Society

AP FiberNet

Disaster
Recovery
TABLE

Comment
and to the Internet will be made via existing APSWAN
network. After the implementation of AP FiberNet, it
will be available up to the panchayat level.
As a part of AP FiberNet project, all big Templets and
Trust offices will be connected through 10 to 100
Mbps bandwidth. All the end points like Trusts,
Agencies and Society will get connectivity to the cloud
through FiberNet to access Endowments Package
applications.
AP FiberNet shall be a highly scalable network
infrastructure to provide on demand, affordable and
end-to-end broadband connectivity of 10 to 20 Mbps
for all households and 1 to 10 Gbps for all institutions
under endowments department.
The SI should provide the BCP plan to meet the SLAs.

13: T EMPLE MANAGEMENT S YSTEM CLOUD COMPONENTS

3.4. Implementation Model & Revenue Model


3.4.1.Implementation Model: The Temple Management System will be
implemented on a substantially bought out model. The SI will be
required to develop and/or customise the package as a mix of
components or products (COTS) readily available in the market or
those developed by the SI or one of the members of the bidding
consortium AND components which are natively developed for the
Temple Management System. The SI will execute the entire scope of
the project at its cost and investment. The SI Shall also be responsible
for maintaining the application during the prescribed O&M period. The
SI will be compensated as per the Terms of Payment outlined in the
next sub-section, but detailed in the Volume III of the RFP relating to
Commercial Terms and Conditions. The SI will get incentives for
launching the Temple Management System ahead of the scheduled
implementation time. SI has to implement the TMS for all the 6A & 6B
Institutions in the state
3.4.2.Terms of Payment: The Temple Management System consists of
five components, namely, (1) the Pilgrim Service Applications, (2)
Temple Management System Front Office Support, (3) Integrated
Application, (4) Departmental Process and (5) MIS reports. The
System will be implemented on a public-cloud-based model. Hence,
the CapEx is expected to be low, on account of the minimal IT
Infrastructure requirements at the participating institutions /
department. The SI will be required to quote CapEx and OpEx for all
the five components separately. The SI will be compensated as per
the following terms:
e-Pragati Requirements Specification Document Temple Management System
of 216

Page

1. The CapEx quoted shall not exceed 50% of the total cost of the
Package quoted by the bidder.
2. 100% of the CapEx will be paid component-wise, linked to the
milestones and deliverables and subject to satisfactory UAT at
each stage.
3. The OpEx, which is all-inclusive (license fee, cost of development
of the package, acceptance testing, commissioning, user training
and O&M during the project period) will be paid as per schedule VI
of Volume III of this RFP post-go live.
4. The OpEx will be linked to the SLAs to be defined for each of the
components.
5. There would be rewards and penalties defined in terms of timely
completion and performance against SLAs.
3.4.3.Revenue Model: Temple Management System is a societally
important project. Therefore as a basic state responsibility, the
expenditure is to be borne by the Government. However, it is
desirable to introduce a commercial element in some of the
components of the project for delivering premium services. Therefore,
the SI shall provide a Billing Module to measure and charge the
premium services consumed by each stakeholder through the TM
Package. The revenue model is specified in the Table 14 below:
Therefore, SI shall consider the following revenue models for
multitenant application design, application performance and
customisation requirements of Temple Management System - while
adhering to data privacy and protection standards in the global IT
industry. Please note that the revenues shall go to the department
and not to the SI, excluding incentives if any as mentioned in the
subsequent sections.

Sl.
No.
1.

Name of the
Project/Compo
nent
Sevas

2.

Description of
Revenue Model

No of
Subscribers

Tariff

Online booking of
seva tickets

All major temples


will use this
service

Rs.5 per
transaction

Darshanam

Online booking of
Darshanam tickets

Rs.5 per
transaction

3.

Accommodation

Online booking of
Accommodation

4.

Temple
Management
System Front
Office Support
Module

Fully automated
temple
management,
Queue
management,
procurement,
auctions.

All major temples


will use this
service
All major temples
will use this
service
All major temples
will use this
service

Rs.5 per
transaction
Fixed cost per
year. 6(a)
institutions-5%
6(d) institutions5%
6(e) institutions5%

e-Pragati Requirements Specification Document Temple Management System


of 216

Page

Sl.
No.

Name of the
Project/Compo
nent

Description of
Revenue Model

No of
Subscribers

Tariff

5.

Temple
Management
System
Integrated
Application
Module

Fully automated
accounting and
fund management,
facility
management,
Inventory
management.

All major temples


will use this
service

Fixed cost per


year.
6(a) institutions5%
6(d) institutions5%
6(e) institutions5%

6.

Departmental
services

Registration
process, DC
module, ePayments and
others

All officials of
Endowments
department will
use it.

Fixed
convenience
yearly charges of
10 Lakhs

TABLE

14:

REVENUE MODEL OF THE

ENDOWMENTS

PACKAGE DEPARTMENT

3.4.4.Assumptions on the Revenue Model


a) The e-Pragati portal shall offer the bouquet of high quality services
which are commercially categorised as free services, subsidised
services, and premium services. The stakeholders shall use the
payment gateway in the e-Pragati framework for the payment
related transactions.
b) The e-Pragati portal facilitates the Third Party Service Providers
(TPA) (If any) to offer their services at the rates and SLAs approved
by the Endowments department. The Endowments department
shall enter into contracts with the Third Party Service Providers on
need basis.
c) The SI shall enter into agreements with the TPAs for the services
with the approval of Endowments department and offer the TPA
services through the e-Pragati portal.
d) Temple Management services through e-Pragati
chargeable and are purely at the discretion of users.

portal

are

e) The users who consume the chargeable services through the ePragati portal must agree to the terms and conditions set by the SI
in consultation with the Endowments Department. The Endowments
Department shall be the sole regulator of the Temple Management
System Services through the e-Pragati portal.
f) The users may consume the services directly from the TPAs viz.
tickets, bookings, content, materials and/or services (without using
the e-Pragati portal, by directly subscribing with the TPAs). In such
case, the SI or Endowments department has no role either in the
pricing and/or SLAs of TPA services.

e-Pragati Requirements Specification Document Temple Management System


of 216

Page

3.4.5.Incentive Model
In addition for developing the system, the system shall provide the
services specified in the service portfolio, the bidder is encouraged to
propose and develop additional revenue generating services for the
Temple Management System. These additional revenue generating
services in their proposed solution along with the projected number of
users/subscriptions/transactions that these services are expected to
attract as well as a tariff that shall be levied by GoAP. The service
charges collected will be deposited in the e-Pragati account. The
definition of revenue generated by the portal includes, but is not
limited to various charges levied on transactions conducted through
the Temple Management System and premium services offered by the
portal. The following is an indicative list of the same.
a. User convenience fees (for example, additional charges
levied for online payment transactions)
b. Registration fees
c. MIS and Analytics (for external (public) users)
d. Licensing fees for applications for private institutions
e. Advertising revenue
f. Subscription fees
The incentives will be paid to the selected System Integrator as per
the details given below:
A. Incentives for the existing services: The selected SI will earn
up to a maximum of 15% of the total contract value as incentives
of the net revenue generated from the revenue generating
services on achieving the threshold targets for the services
mentioned in Section 3.4.3. The incentive if any eligible, payments
will be computed and made at the end of each financial year.
B. Incentives for Premium Services: Revenue generated through
the premium services (Additional services which are not part of the
scope of the project) offered by the SI through Temple
Management System. These Incentives will be 20% of the total
revenue generated through premium services offered for the
entire duration of contract. For the eligible incentive if any,
payments will be computed and made at the end of each financial
year. The total incentive amount payable to the System Integrator
in any financial year shall not exceed more than 10% of the
contract value subject to maximum ceiling mentioned above.
The implications for the SI in terms of the development effort is
as follows:
1. Revenue Metering for Temple Management System shall be
developed by SI as specified below:
a) A Digital/Mobile Wallet (eWallet) facility shall be provided at the
portal level. The application shall use the Payment Gateway
application under e-Pragati framework.
b) The above eWallet shall be topped up by the users either online by
using net banking or debit/credit card services or through MeeSeva
centres.
e-Pragati Requirements Specification Document Temple Management System
of 216

Page

c) Whenever the users consume the paid services, the Temple


Management System shall automatically deduct the respective
amount from the eWallet. When the eWallet amount depletes to the
pre-defined minimum limit, an automatic SMS/email alert is to be
sent to the user for additional top-up, if user desires.
d) User wise and/or Account wise service consumption metering and
billing facility.
e) Users can avail or cancel existing services under the paid model.
f) Allow user billing administrators to initiate payment instructions to
users.
g) Allow users to make payment online via the payment gateways
under the e-Pragati framework.
h) Allow users and billing team to generate MIS reports on usage,
payments made/outstanding and so on.
2. During the O&M period, the SI must assist the respective
department/ management to monitor the collection of
revenue.

3.

Project period: All the three applications/components of the


Healthcare Package shall be implemented, including successful UAT, in
a period of 12 months from the date of signing the contract. The O&M
period shall be 5 years from the date of GO Live.

e-Pragati Requirements Specification Document Temple Management System


of 216

Page

4. Scope of Work of SI selected for Temple Management


System
The Scope of work of the SI selected for the implementation of the Temple
Management System has been defined in different sections of the RFP. However,
a high-level specification of the same is given in this section.
4.1.
i.
ii.

iii.

iv.
v.
vi.

vii.
viii.

ix.

4.2.
i.

ii.

System Requirements Study,


The SI shall perform a detailed assessment of the functional and
technical requirements of the TMS.
The SI shall review and confirm the list of services provided in this
document, and if necessary make changes. The shall actively engage
departments in this activity
Based on the assessment, the SI shall submit an inception report and
detailed Project Work Plan for the complete TMS project life cycle
including COTS product, procurement & deployment, and operations &
maintenance. These artefacts shall be approved by the PMU.
SI shall perform analysis, and identify all applications that would
integrate with TMS
The SI should preferably follow the latest version of the IEEE Standard
830 & 1233 for drafting the SRS/Blueprint.
The SRS/Blueprint document should be accompanied with a detailed
use case document covering all functions of the TMS, and in line with
the minimum requirements specified in the FRS (Refer Application
specific sections of this Volume).
SI to submit all documents in both hard and soft copy to the PMU.
The SI shall also prepare a Requirements Traceability Matrix (RTM)
mapping the requirements specified in the FRS with the sections
dealing with those in the SRS/Blueprint. The template for preparing the
SRS/Blueprint has to be approved by the PMU before it is used to
document the SRS/Blueprint.
A formal sign-off should be obtained from the PMU, before proceeding
with the Design, Development, Customisation and Implementation of
the System. The documents to be presented for sign-off should include
the SRS/Blueprint as well as the RTM.
Solution Analysis, Architecture and Design
The SI shall prepare technical solution architecture and design in line
with logical architecture, service and functional requirements provided
in various sections of this volume, as well as specifications provided in
the approved SRS/Blueprint document.
The Solution Architecture document should highlight the major
components of the solution, and map them to the requirements
identified in the SRS/Blueprint. It should also provide the rationale of
hardware and software sizing.

e-Pragati Requirements Specification Document Temple Management System


of 216

Page

iii.

iv.

v.

vi.

vii.
viii.

ix.

4.3.

The detailed design document should describe complete low level


details of various components identified in solution architecture. This
document covering all the modules and sub-modules of the TMS shall
be prepared using industry standard practices. If required, the
document may include UML class diagrams, interfaces, application
control, database schema and GUI. Traceability between application
design, and solution architecture requirements shall be documented.
The SI shall plan well in advance for managing increasing volume of
data during a period of 5 years from the date of go-live. Accordingly,
the SI should provision for hardware and software improvements.
The SI shall update the RTM by mapping the functional requirements
specified as part of this RFP with the related sections in the solution
architecture and design documents.
The system should be based on open standards. The objective of the
designing exercise should be to identify all possible mechanisms of IT
implementation within the current business context, identify reuse of
existing components (both software and hardware) and remove
redundancies within the system.
SI shall carry out a comprehensive training needs analysis and
accordingly design the training program in consultation with the PMU.
Creation of logical Security Plans for Application, Data, Networks and
Desktops (subject to the existing policies and guidelines of SDC, AP
SWAN/FiberNet)
The SI shall submit the solution architecture and design documents to
the PMU and obtain a sign off on these documents before commencing
the development of the COTS product
Impact Analysis

The SI shall carry out impact analysis to determine the following:


i.

ii.
iii.
iv.
4.4.

Impact on existing application databases (referential integrity, indices,


structure of tables, etc.) because of moving master attributes to the
hub from application databases
Impact on applications, queries, scripts and other software elements
due to relocation of master elements
Impacted stakeholders, departments, and business processes
Category of the change impact Low, Medium, High
Process Re-engineering

The e-Pragati Program attaches a very high importance to the process reengineering. The re-engineering shall adopt the approach provided in the ePragati portal. The result of BPR already done for identified processes is
provided in Annexure 3. In addition to the same, the SI may, during the
course of the designing SRS, identify all other areas needing BPR, especially
the customer-facing processes, and reform the same, in consultation with the
departments. Process re-engineering and forms re-engineering is
responsibility of the selected SI. The selected SI has to undertake these
activities as part of System Study phase and submit the FRS and get the
same approved by PMU.
e-Pragati Requirements Specification Document Temple Management System
of 216

Page

4.5.

Forms Re-engineering

Forms re-engineering shall be executed as specified in Annexure 6. All the


forms, whether used by the external or internal stakeholders, whether they
are statutory or non-statutory, shall be examined in relation to the functions
of all the departments that figure in the top 80% of the services of the
departments (internal or external services). The following alternatives shall be
invariably examined w.r.t each form:
a. Whether the form can be eliminated?
b. Whether the form can be integrated with any other form?
c. Whether a common form can be introduced across several
departments?
d. Whether a form standardised/optimised in any other department/State
can be adopted?
4.6.
Test Plan: Once the SRS is approved and design is started, the SI
shall prepare all necessary Test Plans (including test cases), i.e., plans for
Acceptance Testing. Test cases for Initial and Final User Acceptance
Testing shall be developed in collaboration with domain experts identified
at the state nodal agency. Initial and Final User Acceptance Testing shall
involve Test Case development, Unit Testing, Integration and System
Testing, Functional testing of Application, Performance testing of the
Application including measurement of all Service Levels as mentioned in
this RFP and finally SI shall also carry out Load/ Stress testing. The SI will
submit the test plans and test result reports to the state nodal agency for
comprehensive verification and approval. SI can suggest a suitable
approach and own the License.
4.7.
Application Development
The application development shall extend to the full functionality to
deliver all the services, to internal and external stakeholders. Where a
standard product is being proposed for deployment, the effort should
include configuration and customisation to meet the full requirement.
Development of all interfaces for integration between Temple
Management System applications, e-Pragati Applications (Tier-I) and ePragati Components (Tier-II), shall form part of the scope.
It shall be the responsibility of the SI to prepare a Reverse Traceability
Matrix (RTM) covering all the requirements defined in the SRS document,
signed off by the GoAP. PMU will be created for each package with a SME
(department person) and PMU will be responsible for the sign-off of
deliverables.
The e-Pragati Temple Management System PMU shall assist the SI in
obtaining the approval of the deliverables in consultation with the
Endowments department and ITE&C department wherever necessary
within 15 days from the date of receipt of the deliverables from the
service provider.
In case any external application or component on which the Temple
Management System is dependent, has not been developed by the
concerned SI, GoAP may require the SI of the Temple Management
System to develop the same, to the extent it is essentially required for
effective deployment of the Temple Management System. The SI shall
e-Pragati Requirements Specification Document Temple Management System
of 216

Page

propose the same as a Change Request and the same shall be handled by
adopting the Change Request process defined in the Terms and
Conditions of the RFP for the project. SI is responsible for provision of
licensed software to run the applications.
i.

ii.
iii.

iv.

v.

vi.

vii.
viii.

ix.
x.

xi.
xii.

xiii.

Since a majority of services will be delivered as re-usable services, the


SI shall develop APIs, and publish the services to e-Highway service
registry
It is the responsibility of the SI to ensure that the service published is
discoverable to service consumers.
The SI shall make sure that APIs/interfaces are available so that service
requestor, upon registration, may invoke services using different types
of Applications Mobile, Native, Web.
Where a standard product is being proposed for deployment, the effort
should include configuration and customisation to meet all the
requirements.
Development of all interfaces for integration between TMS applications
and other e-Pragati Applications, and components shall form part of the
scope.
The SI shall provide/develop and install COTS product(s) package
(including development /customisation)/bespoke application and
related software licenses, based on the functional & system
requirement specifications and solution design finalized. The
development/configuration/customisation process should ensure that
the standards specified during the design phase are adhered to during
the entire cycle.
A standard methodology shall be adopted for Software Engineering,
covering the entire SDLC (Software Development Life Cycle)
The SI shall update the Requirement Traceability Matrix (RTM) mapping
the software components developed/ customized with the requirements
specified as part of the FRS.
The SI shall consult the PMU while developing the user interfaces and
design the interfaces as per the PMUs requirements.
SI to ensure that the applications should be accessible through legacy
applications and should be able to take input from heterogeneous
environment.
The information should be shared with other stakeholders in a secured
manner through digital mechanism and in an encrypted manner.
The protocol for communication including data formats and the exact
mechanism of data transfer with participating entities/ stakeholders
has not been explicitly defined in this RFP and the SI should capture
these during the requirements gathering phase and ensure that all of
these are documented as part of the SRS/Blueprint document.
All licenses offered
1. Should be of full use, enterprise licenses, unrestricted and
irreversible. This includes licenses for the COTS Products, Database,

e-Pragati Requirements Specification Document Temple Management System


of 216

Page

xiv.

xv.

Application Server and any of their components or any other


software required to run the application successfully.
2. Should in no way restrict the users of the department in terms of
view/write/modify rights.
3. For any system, sub-system or product as part of TMS solution shall
be perpetual in nature.
Developed/Customized Solution (COTS products) should
1. Comply with the latest statutory and regulatory requirements.
Enhancements should be provided by the vendor to comply with the
latest regulations as and when they are released.
2. Accommodate process changes as and when required without
coding efforts.
3. Ensure data security and data integrity.
4. Support delegated administration or creation of local administrators
for user management.
5. Should work on a browser client without installing any software on
the client.
6. Should in no way restrict the users in terms of view/write/modify
rights. All licenses quoted should provide the complete rights to all
the users.
SI shall prepare and submit application readiness report to PMU.

4.8.
Software Application Testing & Quality Assurance
The SI shall conduct unit testing and integration testing adopting the Use
Cases and testing methodology to be agreed upon as a part of the user
sign-off for the SRS. GoAP shall engage a panel of TPAs for conducting the
Acceptance Testing for each application. A detailed Testing and Quality
Assurance methodology to be followed by SI is given in Annexure 13.

e-Pragati Requirements Specification Document Temple Management System


of 216

Page

4.9.

Solution Documentation
The SI shall prepare/update the documents including the following
minimal set of Project Documentation:
1.
2.
3.
4.
5.

4.10.

User Manual
Training Manual
Operations Manual
Maintenance Manual
Administrator Manual

Deployment, Commissioning and GO-Live

The SI shall provide Services to Temple Management System, conforming


to the specified Service Levels, which will ensure:
Sl.
No.
1.
2.
3.

Details
Delivery of speedy and efficient services to the pilgrims, departmental
users and related agencies in relation to all the related services
Train the existing department users/employees (Train the Trainers) to
assist them discharge their duties effectively and efficiently
Encourage and help to improve the adoption rate for the usage of the
Temple Management System services, by employing traditional as well as
innovative techniques. To that end, implement measures:
For making it convenient for pilgrims, departmental users and related
agencies to utilise the services,
Educating the users in the relevant procedures
Use of Telugu & English in all interfaces with pilgrims
TABLE

15:

DEPLOYMENT , COMMISSIONING AND GO - LIVE

To meet the aforesaid objectives the SI will provide the Service Levels in
accordance with the performance metrics as more particularly described
in Nonfunctional requirements performance section in Annexure 8.
SI should develop the Standard Operating Procedures (SOPs), in
accordance with the ISMS, ISO 27005 & ITIL standards, for Temple
Management System. These SOPs shall cover all the aspects including
Infrastructure installation, monitoring, management, data backup &
restoration, security policy, business continuity & disaster recovery,
operational procedures. The System Integrator shall obtain sign-offs on the
SOPs from the department and shall make necessary changes, as and
when required, to the fullest satisfaction of GoAP. GoAP IT & IT related
polices and security policy shall be adhered.
SI shall deploy the TMS solution on a secured public cloud as per the
details given in section 3.2.4 meeting the requirements of TMS solution

e-Pragati Requirements Specification Document Temple Management System


of 216

Page

4.11.

User Training (Train the Trainers)

Training need analysis of all key stakeholders must be performed and the
SI must develop the training plan in line with overall project plan. Section
9 provides detailed training and change management description .
4.12.
Implementation Strategy
The SI shall adopt a robust implementation model. In this regard, SI has to
implement the solution initially in all the 6A category temples and after
successful implementation SI has to implement in all 6B category temples.
SI has to implement the solution in 59 temples, which are classified in 6A
&6B temples
4.13.

Pilot Implementation Smart Temple Pilot

The Smart Temple Pilot envisions connecting pilgrims with administrators


and grievance redressal officials of respective temples through all
available technologies. It provides various services of the Temples to the
stakeholders which makes the Temple visit easier, secure, comfortable
and enriching. These services are not just for darshanam & seva of the
respective temples but also for socialising (satsang), sharing events,
providing all services on finger tips.
i.
ii.
iii.

Real time advanced queue management


Temples Monitoring
Online darshanam / Live streaming

BOM required for pilot is given in Annexure 14. SI is not responsible for
the provision of Internet Bandwidth. However, SI is responsible for
providing Wi-Fi access points. SI should provide comprehensive
warranty services for all the BOM components as specified in Annexure
14
4.14.
Data Migration: Testing of data migrated shall be carried by the SI
in coordination and supervision of PMU. Agreed defects identified during
testing shall be fixed by the SI prior to Go-live. As part of the Go-live,
Master data across all modules shall be successfully migrated. As regards
transaction data all open records as on go-live date to be migrated and all
legacy records for last 3 years prior to the go-live date and currently
25GB of data available with legacy application which needs to migrate
into new TMS application. Solution for data cleansing is also responsible
for SI for the data existing with the legacy applications
4.15.

Go-Live and Operations & Maintenance

As other e-Pragati packages may not be ready for integration by the time
TMS is ready for Go-Live, a well-defined criteria shall be in place to define
Go-Live event of TMS.
The PMU shall define different user scenarios in detail covering individual
applications and overall integrated scope of TMS application. Operational
Acceptance for the full TMS application shall be awarded by the PMU only

e-Pragati Requirements Specification Document Temple Management System


of 216

Page

if at least 98% of user scenarios are met by the SI ensuring the full
functionality.
In order to ensure effective completion/accomplishment of the above, the
PMU, in association with SI, shall carry out all the necessary operational
acceptance tests including but not limited to:
1.
2.
3.
4.
5.
6.
7.
8.

Functionality Test
Database Test
Integration Testing
Unit Test
System Test
Security Compliance
Stress test
Performance test

The PMU may accept and sign off on the TMS application only when it
deems that results of all tests are satisfactory, and that all requirements of
TMS application have been met with. The operational acceptance of the
system may be provided only when the proposed system has been
installed and configured at all sites as agreed upon during the design
phase, and detailed procedures of operating them have been carried out
by the SI in the presence of PMU staff.
SI should submit a report for obtaining OPERATIONAL ACCEPTANCE
after the Go-Live phase. The report should include the following:
1. All required activities for the TMS application project delivered by
the SI and accepted by the PMU
2. All required system functionalities of the TMS project delivered
by the SI and accepted by PMU
3. All required documentation for the TMS project prepared by the
SI and accepted by PMU
4. All required training for the TMS project imparted by the SI and
accepted by PMU
5. All identified shortcomings/defects in the Systems have been
addressed to PMUs complete satisfaction
6. All the required Project Documents (For example: manuals, SOP)
have been submitted and accepted by the PMU
7. No. of user that have access to the System and are using the
System for the respective functional areas
8. Any other work which is required to be complied with by the SI.
The application has to be free from any security threat and the SI
shall have to produce the third party audit certification for the
same.
Based on the above and only after being completely satisfied that at least
a minimum percentage of all the users of internal stakeholders have
access to the System and are using the System for the respective

e-Pragati Requirements Specification Document Temple Management System


of 216

Page

functional areas, the PMU shall issue such OPERATIONAL ACCEPTANCE of


TMS.
4.16.

Operations & Maintenance

The System Integrator shall be required to provide operational and


maintenance services for Temple Management System including, all the
connected software and integrated components. This section discusses
the Operations & Maintenance services to be provided by System
Integrator with respect to Application Software & supporting IT
Infrastructure Management.

The System Integrator shall be required to provide operational and


maintenance services for Temple Management System including, all the
connected software and integrated components. This section discusses
the Operations & Maintenance services to be provided by System
Integrator with respect to Application Software & supporting IT
Infrastructure Management.

4.16.1.

Overview of Post Implementation Services

An indicative list of activities and nature of support to be provided is


mentioned below:
I.

System Administration and Trouble Shooting


A. Overall monitoring and management of all IT system software,
application, database, and all other services associated with these
facilities to ensure service levels, performance and availability
requirements as prescribed in the RFP are met. SI is responsible for
providing EMS. The SI is responsible for meeting SLAs and should
provide a single point console to PMU to monitor SLAs. EMS based
console should be made available to PMU.
B. Perform system administration tasks such as managing the user
access, creating and managing users, taking backups.
C. Performance tuning of the system to ensure adherence to SLAs and
performance requirements as indicated in the RFP.

II.

Co-ordination with Network Administration Team


A. Coordinate with the network service providers to maintain and
ensure uptime and performance requirements of the e-Pragati
Temple Management System Application. (More details are provided
in Volume-1 of RFP under Non Functional requirements in Annexure
10).

III.

Database Administration and Trouble Shooting


A. Undertake end-to-end management of database on an on-going
basis to facilitate smooth functioning and optimum utilisation
including regular database backup and periodical testing of backup
data, conducting configuration review to tune database,
maintaining the necessary documentation and managing schemes

e-Pragati Requirements Specification Document Temple Management System


of 216

Page

to database schema, disk space, user roles, and storage. SI has to


define the backup policy.
IV.

V.

Cloud related services


A. Cloud related services to maintain required provisioning, ensure
uptime and performance requirements of the e-Pragati Temple
Management System Application.
B. Generate the Infrastructure usage graphs and ensure alerts upon
thresholds to the concerned entities through an EMS tool provided
by the Cloud service provider.
Exit Management
Si has to submit the Updated Project Exit Management Plan and at the
last quarter of Operation and Management phase SI needs to submit
the Project Exit report along with the broad activities to be undertaken
by the SI during the operation and maintenance phase
4.16.2.

Annual Technical Support

The following activities are to be carried out as a part of Annual Technical


Support
I.
II.
III.
IV.

V.

VI.

SI shall maintain data regarding entitlement for software upgrades,


enhancements, refreshes, replacements and maintenance.
If the Operating System or additional copies of Operating System
are required to be installed/ reinstalled/ de-installed, the same
should be done as part of ATS.
SI should carry out any requisite adjustments/ changes in the
configuration for implementing different versions of Application
Software.
Updates/ Upgrades/ New releases/ New versions/ Patches/ Bug fixes:
The SI shall provide from time to time the Updates/ Upgrades/ New
releases/ New versions/ Patches/ Bug fixes of the software,
operating systems, as required. The SI should provide free Updates/
Upgrades/ New releases/ New versions/ Patches/ Bug fixes of the
software and tools to APTS/ITE&C/Endowments department as and
when released by OEM.
Software License Management. The SI shall provide software license
management and control. SI shall maintain data regarding
entitlement for software upgrades, enhancements, refreshes,
replacements, and maintenance.
SI shall have complete manufacturers technical support for all the
licensed software problems and/or questions, technical guidance,
defect and non-defect related issues. SI shall provide a single-pointof-contact for software support and provide licensed software
support including but not limited to problem tracking, problem
source identification, problem impact (severity) determination,
bypass and recovery support, problem resolution, and management
reporting.

Since the Project aims to reuse the common infrastructure created under
AP FiberNet, APSDC, APSWAN, MeeSeva, the selected SI System
Integrator will also be required to coordinate with AP FiberNet, AP SDC,

e-Pragati Requirements Specification Document Temple Management System


of 216

Page

AP SWAN, MeeSeva, teams to ensure that uptime and performance


requirements.
However, the selected SI shall be held solely responsible for
performance and service levels of any infrastructure deployed as part of
this RFP. SI is responsible for diagnosing critical hardware failures or
warnings reports to PMU. Application related issues should be viewed
through Admin console made available to PMU. Alerting mechanism
should be implemented by the SI to provide a single console to enable
access to PMU, to monitor and review all service related information.

Technical Helpdesk and Trouble Ticket


Management System

4.16.3.

The bidder shall setup a centralised Helpdesk facility to provide support


for the applications provided under Temple Management System. The
centralised helpdesk needs to be set up for the cloud and application
related issues only. IVRS is not mandatory. Integration of third party
application with Helpdesk software should be decided by the SI only. SI
has to propose escalation mechanism as part of solution. SI has to
decide based on SLA requirements pertaining to Helpdesk solution in DC,
DR and HA.
The selected SI will undertake the following
1. Provide technical helpdesk services to track and route requests for
service and to assist department users to answer questions and
resolve problems associated to healthcare applications deployed at
cloud with the respective OEMs.
2. To act as the central collection point for contact and control of the
problem, change, and service management processes (This includes
both incident management and service request management).
3. Shall provide a first level of support for application and technical
support at e-Pragati Temple Management System implementation
locations across the State where the software, hardware, and other
infrastructure will be rolled out.
4. Provide the following integrated customer support by establishing <9
hrs X 6 days> support at the Helpdesk facility created for reporting
Temple Management System related issues/ problems with the
software, hardware and other infrastructure.
5. The helpdesk support shall support English and Telugu languages.
The helpdesk shall be setup in Andhra Pradesh State.
Complete incident and problem management: - Service desk should
address both Incident Management and Problem Management. The
application should maintain a classification system that will distinguish the
single occurrence trouble tickets or incidents needing immediate
resolution from in-depth root cause analyses that may require longer term
to resolve a problem.
The flow of events at the call centre should be:
1. Event is triggered and forwarded to service desk.
2. Service desk submits and updates the trouble ticket.

e-Pragati Requirements Specification Document Temple Management System


of 216

Page

Tasks expected:
1. Ticket mapping and allocation: According to the severity, the ticket
should be given the priority level. Also it should map the ticket to the
appropriate personnel for the resolution.
2. Updating the status: Update the status of ticket.
3. It should be able to log and escalate user interactions and requests.
4. It should have an updateable knowledge base for technical analysis
and further help end-users to search solutions for previously solved
issues.
5. Status of registered calls with interface for Call centre, using which call
centre can inform the status to users over phone.
6. Historical report indicating number of calls, time to resolve, status for a
specified period of time.
All relevant infrastructure and supporting system software required for the
deployment and operation of the helpdesk is to be provided by the
selected Bidder.
All relevant infrastructure and supporting system software required for the
deployment and operation of the helpdesk is to be provided by the
selected Bidder as per the specifications given below. The system
deployed by the SI shall comply with ITIL and ISO 27005 service
specifications.
4.16.4.

Health Monitoring of System

e-Transaction & SLA Monitoring Tools:


The Endowments Department, the State Nodal Agency should be able to
measure and monitor the performance in REAL-TIME, the number of citizens
availing e-Services each day, month and year, through appropriate tools and
MIS reports.
The application should have a web interface and should publish online
transaction volume data for each service of each department & district and
provide a drilled down view to the lowest level of the department. SI shall
propose any industry approved product to meet the requirements.

Sl.
No.
1.
2.
3.

Details
SI shall implement and manage the Temple Management System in
accordance with the service level metrics defined for the project in SLA.
SI shall coordinate and provide complete support to the department
SPOC and/or the nominated agency in conducting the solution
acceptance testing and certification.
SI shall provide operational support and maintenance services for a
period of 5 Years from the Go-Live date of the complete roll-out for
overall operations and maintenance at Temple Management System
stabilisation,
software
solution
maintenance,
IT
infrastructure
management, system administration, security administration, database
administration, network administration and end-user problem resolution.
The operational support will have to ensure that the Temple
Management System is functioning as intended and meeting all the
desired outcomes and service levels.

e-Pragati Requirements Specification Document Temple Management System


of 216

Page

Sl.
No.
4.

5.

6.

7.
8.

9.
10.
11.

12.

13.

14.

Details
SI is required to train the identified staff (Train the Trainers) who will be
associated with the Temple Management System, that includes all the
personnel (Private & Government) and those identified Endowments
department. SI shall also be responsible for re-training the staff
whenever changes are made in the system and/or personnel.
SI shall be responsible for preparation of documents including User
Manuals, Operations Manual, Maintenance Manuals, Administration
Manual, Security Manual, and others (if any) as per acceptable
standards.
The SI shall provide warranty for the entire Temple Management System
including all the items supplied as part of the contract, for a period of
five years commencing from the date when the system is declared Golive. The terms of warranty should include that the solution supplied
under this Contract shall have no defect arising from design or
workmanship or from any act of omission or commission of the SI or that
may develop under normal use of the supplied solution.
SI shall provide a staging environment for testing of changes/ updates/
patches before applying them on production environment
SI shall give suitable access to IT&C Department Administrators, and/or
support System Integrator designated by Endowments Department, to
tools implemented/ utilised by SI for monitoring infrastructure
components (Server, Network, SAN.), and their operations, system
related events, and SLA measurement/ monitoring.
Diagnostic reports and software programming should be available
remotely (via a browser and VPN).
The SI shall include the equipment, software, and training required,
along with a description of the software used, for administration.
The routine maintenance procedures, troubleshooting, loading hardware
and software revisions, patches shall be performed without taking the
system(s) out of service by SI. Routine maintenance functions must be
performed without causing any downtime for the system users.
The core system(s) should use self-diagnosing software for detecting and
logging of component failures. It should have the ability to initiate an
alarm that can be sent to the support System Integrator and the Temple
Management System operational technical personnel by SMS and email.
The SI is expected to up to date on changing policies, new funding
streams, innovations and best practices. In, addition, the SI can describe
any other value-added services it can provide in addition to those
specified within the RFP. It is the SIs responsibility to inform the State,
and enrolled providers if appropriate.
The system management solution must include a mechanism to monitor,
measure, and troubleshoot system and generate system performance
reports
TABLE

4.17.

16:

OPERATIONS

&

MAINTENANCE

Deliverables

The following outlines detailed deliverables expected from the SI, including
timelines. PMU will be created for each package with a Subject Matter Expert
(SME) from the Endowments Department and PMU will be made responsible
e-Pragati Requirements Specification Document Temple Management System
of 216

Page

for the sign-off of deliverables. The deliverable time lines are defined in the
Volume III.
Sl.
No
.

Phase

Deliverable Description

Planning and Inception Phase


Signing
of
the a. Performance Bank Guarantee as per Volume
Contract
III of this RFP
2.
Project Planning and b. Detailed Project Plan for Design, Development
Analysis
& Implementation of Temple Management
System (within 2 weeks from award of
contract). The plan should clearly identify all
the milestones and deliverables together with
the tasks and time & resource allocation.
c. Comprehensive project risk management
plan.
d. Data Assessment Report which should include
Data Quality, availability of all Data elements
required for TMS Package Applications.
e. Data Access Requirements Report which will
specify what level of access is required for
which users on which data elements.
f. Data Security Requirements Report which will
describe how Data Security Standards and
Requirements will be met.
g. Data Migration Strategy/Plan, total volume of
data to be migrated is SIs responsibility. The
volume of data to be migrated is specified in
section 4.14
h. Data Cleansing and Standardization Strategy.
i. Data and Application Integration Strategy
(shall be SOA based).
j. Identification and listing of all Sources of
Data.
k. Legacy Application and Data management
Strategy.
l. Application decommissioning or retirement
Strategy (if applicable).
m. Change Management Strategy.
n. Change Communication Strategy.
o. Training Plan including Target Audience,
Training material, proposed date, and
location.
p. Impact Analysis Report This shall include
impact on Key Stakeholders, existing business
processes,
applications,
data,
and
infrastructure due to the proposed changes.
1.

The above mentioned list shall be comprehensive


in terms of its coverage and scope. It shall
identify all data elements, sources, and
applications that are relevant to Temple

e-Pragati Requirements Specification Document Temple Management System


of 216

Page

Sl.
No
.

Phase

Deliverable Description
Management System.

3.

Systems Study, Architecture and Design Phase


Solution Architecture a System Requirement Specifications
and Design
Document for the complete solution
b
c

f
g
h
i
j
k

(SRS)

Functional Requirements Traceability Report


Data Assessment Report which should include
Data quality, availability of all Data elements
required for TMS Applications
Data Access Requirements Report which will
specify what level of access is required for
which users on which data elements.
Data Security Requirements Report which will
describe how Data Security Standards and
Requirements will be met.
Data Migration Strategy
Data Cleansing and Standardization Strategy
Data and Application Integration Strategy
(shall be SOA based)
Identification and listing of all Sources of Data
Legacy Application and Data management
Strategy
Change Management and Capacity Building
Strategy

4.

Submission
Solution
Architecture
Documents

of

5.

Submission
of
Solution
Design Documents

Change Communication Strategy and Impact


Analysis Report
m Quality Assurance Plan
Detailed Software Architecture document
describing various stakeholder concerns,
architecture views addressing the concerns,
architecture styles and patterns, design decisions
and strategies addressing key quality attributes
(non-functional requirements).
a. Design documents for all application modules
and sub-modules for TMS Applications
b. Technical
/
System
Design
Document
including but not limited to:
i.
High level modules and sub modules
structure,
including
detailed
specifications for interfaces at method
and attribute levels
ii.

Class Diagrams, Collaboration diagrams


in UML notations

iii.

Component and Deployment views of

e-Pragati Requirements Specification Document Temple Management System


of 216

Page

Sl.
No
.

Phase

Deliverable Description
the Application
iv.

Detailed specification of workflow logic


for modules and sub-modules

v.

Updated Conceptual Data models

vi.

Logical and Physical Data models

vii.

Data Dictionary

viii.

Updated metadata and reference data

ix.

Database structures including ER, Data


Dictionaries and DFD diagrams

x.

Security design

b. Detailed interface design specifications to


integrate data and applications within TMS
and
with
other
e-Pragati
packages
applications and external systems
c. Document on Testing Approach and Strategy
for TMS applications, along with the test cases
and test results including but not limited to:
i.
Type
of
inputs
(Functional
/
Performance / Stress / Acceptance /
Structural), including Test Coverage /
Boundary conditions
ii.

Machine Configuration

iii.

Test Assumptions

iv.

Exact test stimuli as applicable

v.

Response Time / Execution Time /


Throughput

d. Design of Wireframes and User Interface


Screens in consultation with end users and
stakeholders
e. Design documents for all Atomic and
Compound
Services
relevant
to
TMS
Applications.
f. Security architecture & policies (subject to
SDC, APSWANs policies or any other IT policy
by GoAP)
g. Network architecture covering various user
locations, deployment locations, bandwidth
requirements,
software
and
hardware
e-Pragati Requirements Specification Document Temple Management System
of 216

Page

Sl.
No
.

Phase

Deliverable Description
components
h. Deployment architecture covering Network,
Servers, Storage, System Software
i. Data backup & recovery strategy
j. Integration approach with e-mail, Helpdesk
services of GoAP
k. Software/
Hardware
Configuration
Management Plan
Database Backup and Management Policies

Implementation Phase
6.
Submission
of
Implementation Plan

7.

Completion of TMS
Development

Automated testing and automated test case


generation are recommended to ensure complete
and appropriate test cases are generated,
reducing waste and enhancing application
quality. The scope and coverage of test cases
and their results are to be verified and signed off
by PMU.
Development, Testing, and Deployment Plan
which should at minimum contain the following
a. Breaking the total scope into phases or
iterations.
b. Phase or Iteration-wise Identification of
requirements for Software development.
c. Phase-wise Testing and Deployment Strategy.
d. Phase-wise User Sign-off Strategy.
At the end of software development phase, the
following artefacts shall be delivered:
a. Updated Test Plans and Test Results of
i.

Unit Testing

ii.

Integration Testing

iii.

System Testing

b. Pseudo code for Application Development


c. Source code, library files, DLLs, Programs and
other relevant software components. Please
refer Volume III of this RFP for more details
d. Updated & Final System Requirements and
Design Documents
e. Fully functional Software Applications
f.

Updated Requirement Traceability indicating

e-Pragati Requirements Specification Document Temple Management System


of 216

Page

Sl.
No
.

Phase

Deliverable Description
fulfilled requirement
g. Application Readiness Report, Development
completion
report
including
minimum
following:
i.
Source code (soft copy)
ii.
Report formats (soft copy)
iii.
Test scripts (soft copy)
iv.
Databases (soft copy)
v.
Data digitized and Migrated (soft copy)
vi.
Executable files (soft copy)
vii.
Product CDs
viii.
Other relevant documents deemed
necessary
h. Configuration management strategy

8.

Completion
Migration
cleansing

of

Data
and

9.

Completion of User
Acceptance
Testing
and Third Party Audit

Technical documentation to explain source code,


solution design maintenance manuals for Data
Centre, Software, Networks, Servers and other
hardware.
a. Data migration and cleansing strategy report.
Report on data migration including the extent of
data to be migrated, methodology for data
cleaning.
a. UAT Reports including
i.
Various Tests performed
ii.
Test results
iii.
Resolution reports for the issues
identified during Testing
b. PMU Sign-off of UAT
Application Audit Compliance and Security
Certification from Third Party Agency

Change Management and Capacity Building


10. Enterprise
Change a. Change Management Workshops including
Management
presentation
materials
and
related
documents.
b. Updated Legacy Application Retirement
strategy
for
existing
application
(if
applicable).
c. Change
Communication
Strategy

Expectations
from
various
Temple
Management System stakeholders, how the
change impacts them.
11. User Training
a. Updated Training Plan.
Sensitization training
e-Pragati Requirements Specification Document Temple Management System
of 216

Page

Sl.
No
.

Phase

Deliverable Description
Basic computer awareness
Application administration training
Functional user training
b. Training manuals and schedules.
c. Training Feedback forms (Post Training
sessions).
d. Training effectiveness score (based on
feedback from participants).

Deployment Phase
12. Delivery
&
deployment of the
required IT equipment
(including
software,
hardware & network
devices)

Software Deployment Plan.


Updated Risk assessment Plan.
Software Application Certification Plan.
Deployment Checklist.
Post-deployment system monitoring and
certification requirements.
f. Deployment Sign off.
g. Fully tested, certified, and functional Temple
Management System Application Software.
h. Fully
tested,
certified,
and
functional
Database Management System with updated
databases where applicable.
i. Fully updated Master Data Repository.
j. Fully updated Metadata Repository.
k. Configuration Management System.
l. Documentation
13. Go-Live
m. Go-Live Certificate
Operations and Maintenance
14. Post-Deployment
a. Post Implementation Support to Temple
Management System / Department.
b. Call Log & Resolution Reports for Helpdesk.
c. Daily/Weekly/for-nightly/monthly Performance
Monitoring
Reports
for
the
Temple
Management System.
d. Operational Document on Strategic Control of
Temple Management System / Department
over the Project.
TABLE

4.18.

a.
b.
c.
d.
e.

17: TMS

PACKAGE DELIVERABLES

IT Service Delivery

e-Pragati program is user-centric and aims at providing better government


services to the end user. The goal is to build a common vision of success
amongst all stakeholders and ensure the institutional and implementation
arrangements support strategy.
a. The SI shall ensure that the IT Service Delivery shall be in compliance
complied with the SLA set in this RFP and adhere to global best
practises and principles of e-Pragati.

e-Pragati Requirements Specification Document Temple Management System


of 216

Page

b. The SI should ensure that the service delivery mechanism is improved


through e-Pragati, achieve better information management &
transparency and ensure utmost citizens involvement in participative
governance.
c. The pilgrim-facing services shall all be delivered through multiple
delivery channels, like the web, mobile and citizen service centres.
d. Discrete and independent pilgrim services shall be delivered through
Apps, to be hosted on the APP Store, which is part of e-Pragati.

e-Pragati Requirements Specification Document Temple Management System


of 216

Page

5. Application Architecture
5.1.

Applications, Modules, Sub-modules

The following are the design principles that have been considered while
conceptualising the Temple Management Package solution:
1. Design applications, modules, and components for REUSE
2. Develop once, use many times
3. Design customer-centric views of services
4. Design to scale
5. Develop interfaces for integration by using SOA principles
6. Use the database schemas of e-Pragati core hubs
7. Ensure maintainability of ALL Interfaces
Figure 4 illustrates a holistic view of various applications that are to be
developed, designed, and integrated for the Temple Management Package.
Note: The list of services, modules depicted in the picture is not a
complete list. Please refer to Annexure 1 Inter Package View for
complete list of Application services, and Annexure 4 for Functional
Requirements of Modules and Sub-Module.

e-Pragati Requirements Specification Document Temple Management System


of 216

Page

FIGURE

3:

HOLISTIC VIEW OF TEMPLE MANAGEMENT PACKAGE

SI shall develop only the modules identified under Tier 3 of the e-Pragati
Temple Management package (Temple Management System). The SI also
needs to develop web services/interfaces to connect and share data with
Tier 1 and Tier 2 applications as necessary.
The Logical View of Temple Management System is explained as below:
1. The Views are designed to consist of a number of customer-centric
views that interact with the 3 tiers through appropriate Service
Orchestration. The SI Selected for the Temple Management System has
to design and develop these views. Please refer Table 18 for more
details on the various views.
2. Tier I: The Tier I represents a set of 15 Applications in the Portfolio of
e-Pragati that are required to be accessed by the users of Temple
Management System in their day-to-day operations. These e-Pragati
Applications fall in different packages of e-Pragati, assigned to different
SIs for implementation. The following requirements are specified in this
regard.
a. The responsibility of the SI selected for the Temple Management
System is to configure each of the applications to suit the
requirements of the users of Temple Management System. Refer
Table -18 for more details on the various Views.
b. The users can be internal to Government, who need to, access
applications like CFMS, HRMS, Scheme Management (e-Pathakam),
DataLytics OR can be Citizens/Pilgrims, who need to access
applications like Dial.AP, Mana Rashtram and MeeSeva, OR
Businesses, who need to access applications like Works
Management.
The integration requirements are listed under Annexure 1.
c. There is a dependency of the SI of Temple Management System on
the SIs of the other packages. GoAP shall facilitate a close
coordination and sequencing of the various implementations to
avoid any issues arising out of such dependencies.
3. Tier-II: Tier-II consists of components / functionality of Temple
Management System that needs to converge with e-Pragati Portal so that
the user can access the Temple Management System Application through
the single-one-stop user interface which is the e-Pragati Portal using
Single-Sign on.
About e-Pragati Portal: e-Pragati Portal is envisaged to serve as a first
stop to discover all Government services/data and shall be an information
gateway to citizens & residents, government officials, businesses and nonresidents. It shall also serve as a repository of enterprise architecture
artefacts (State Enterprise Architecture).
The citizen shall be able to navigate to various applications such as
Temple Management System from the options available under
Government Menu of e-Pragati Portal.
Below are the components that need to converge with e-Pragati Portal and
the envisaged approach for the same.
e-Pragati Requirements Specification Document Temple Management System
of 216

Page

User Management
i.
All the users registered in Temple Management System
Application/Portal such as pilgrim, trustees, staff and management
users of temples and so on shall converge into e-Pragati Portal user
management to facilitate Single-Sign on.
ii.
Green Field Applications - The Green field (new) applications that
are being developed as part of this Temple Management System
shall use the Global Identity and Access Management (IAM) for
authentication. This shall be made available as part of e-Pragati
Portal to the SI.
e.g. When the user registers in the respective Temple Management
System application, the application shall create the user in the
Global IAM with the user credentials, user role (pilgrim, trustee),
application
name/repository
(Temple
Management
System,
Knowledge Management, Skills Management) using the IAM APIs in
a secured manner. The same shall be used for authenticating the
user either in e-Pragati Portal or in the Temple Management System
applications. (This includes centralised APIs for updating the
passwords as well.)
iii.
Single-Sign-On needs to be configured between the e-Pragati Portal
and the Temple Management System Applications to enable the
users to navigate from e-Pragati Portal to Temple Management
System Applications without re-login.
iv.
However, the control of the pages, resources and services that are
to be rendered/served within the Temple Management System
applications will reside in the individual Temple Management
System applications/portals.
v.
The individual applications can further have granular user sub
groups defined in the application if needed for role-based access to
pages.
vi.
Brown Field Applications - For Brown Field (existing) applications,
the feasibility has to be checked if the single-sign-on can be
configured between the global IAM and the current authentication
mechanism used in the existing application. In case of infeasibility,
the existing users have to be reconciled and perhaps a
wrapper/filter has to be developed at the existing application to
facilitate, interpreting the SSO token with the processing logic to
identify/map to the right user within the existing application, so that
the user need not re-login.
(The SSO token is an encrypted token that has sufficient data to
identity the logged in user details. This is shared in the request by
the originating application).
Notifications & Alerts
i.
The critical Notifications & Alerts pertaining to Temple Management
System which are relevant to wider audience such as citizens needs
to be published in e-Pragati Portal in addition to Temple
Management System Portals.
ii.
A user interface from e-Pragati Portal or perhaps a service contract
(web service) shall be made available to the SI for publishing the
notifications/alerts. The notifications/alerts are moderated by ePragati Portal admin before publishing the same.
Services Dashboard
e-Pragati Requirements Specification Document Temple Management System
of 216

Page

i.
ii.
iii.
iv.

The Temple Management System applications shall provide a


service (web service) publishing the services usage (e-transactions)
of the services provided by Temple Management System
applications. Refer Section 6.2 Service Portfolio of Temple
Management Package. The information shall be:
Total Transaction count
Total Transaction count against each District (Group by District).
Total Transaction count against each Department within the District
(Group by District, Department)
Transaction
count
of
each
service
irrespective
of
Department/District
All the above shall also include the last updated date. The Total
Transaction count shall be published to e-Pragati Portal every 3
seconds (via. Push model). The remaining services are consumed by
e-Pragati Portal when the user navigates to the granular views of
Services Dashboard within the e-Pragati Portal.

e-Pragati Requirements Specification Document Temple Management System


of 216

Page

Search
The search keywords pertaining to Temple Management System
applications shall be published as a service which shall be used by
e-Pragati Portal to direct the user to relevant Temple Management
System Application at a high level. The granular search can still be
embedded in the Temple Management System Applications.
4. Tier-III: Department-specific Modules & Sub-modules These are the
Modules specific to respective Departments. Figure 4 depicts the
Department Modules and its Sub-Module.
The Functional Requirements of the Department Specific Modules and submodules of Temple Management System are described in Annexure 5.
Refer Service Portfolio in Table 20 for the complete list of services and
their descriptions/definitions. It is the responsibility of the SI to design,
develop and deliver all these services, duly complying with the defined
service levels.

FIGURE

5.2.

4:

DEPARTMENT SPECIFIC MODULES

&

SUBMODULES

Architecture Overview

e-Pragati Requirements Specification Document Temple Management System


of 216

Page

Figure 5 illustrates the suggested system design for the development of all new
applications.
However, considering the futuristic vision of e-Pragati and the array of new
cutting edge technologies which will be leveraged the department SI can propose
suitable technical solution based on the requirements. Usages of COTS / industry
proven solutions are encouraged as long as they adhere to the principles &
standards of e-Pragati.

FIGURE

5:

TEMPLE APPLICATION ARCHITECTURE OVERVIEW

The system must accommodate the following features:


i.
The Portal Web application shall cater to the various Pilgrim Information
modules, Services, Administration and Management modules.
ii.
Certain Pilgrim Services such as Registration, Seva Booking, Darshanam
Booking, Accommodation Management and Donation shall be available in
both web and mobile version.
e-Pragati Requirements Specification Document Temple Management System
of 216

Page

iii.

iv.

v.

vi.
vii.
viii.
ix.

The services offered via mobile shall be made available via. Mobile app
say mTemple
Services that shall be hosted in AP p Store. The APp
Store will be made available to the SI for configuration and integration of
the same.
The various modules / sub modules in Business Logic Layers shall be
developed as APIs. The API has to be designed at the granular submodule/functionality level i.e. fine grained and need not be at the module
level. The API shall operate on specific domain objects and shall not
depend on request/response objects of Presentation Layer. (E.g.
Accommodation Booking API shall accept the inputs in the form of Person
object and Accommodation object). It should be possible to easily expose
this re-usable APIs as services when required.
The APIs shall be
orchestrated as needed for Presentation Layer to form a Business Service
that is course-grained.
The APIs in the Business Logic Layer shall be re-used by the UI in mobile
apps. The APIs shall be perhaps exposed as REST APIs (supported by json)
for consumption by Mobile Apps Presentation/UI Interface. E.g. Pilgrim
Registration API shall be used by the Temple Services Mobile App for
Registration purpose.
It is suggested that the web portal be developed using responsive design
concepts and keeping in view the Mobile First Strategy.
PDAs (Hand Held devices) will be used by the staff of Temples for ticketing
and booking purpose.
An MADP (Mobile Application Development Platform) shall be used to
create cross platform mobile apps that are portable across iOS, Android
and Windows.
The Temple Application shall integrate with other e-Pragati applications
via. e-Highway for certain functionalities. Refer Annexure -1 Inter
Package Integration View for more details on the Integration View and
type of Integration.
The following section provides a brief description and suggested
guidelines for the above logical layers. SI can propose suitable technical
solution based on the requirements as per industry standards and formats.
5.2.1.
i.

ii.
iii.
iv.
v.

Presentation Layer
The presentation layer acts as the user interface layer and serves as
a single point entry to the underlying business application. It
consists of various views/pages that are accessible to various
users.
The portal shall be accessible from multiple access channels namely
desktops, smart phones, tablets and kiosks and shall support unified
electronic accessibility.
Based on the logged in user type and role, appropriate views are
displayed and accessible. This layer handles session management.
There are views common to all users and few specific based on the
user type. Role based access shall be configured to facilitate the
same.
The various categories of users (stakeholders) shall be able to
access the common services for that category or premium (paid)
services, directly from the home page of the view, through
appropriate, user-friendly navigation.
The SI in consultation with the line departments shall identify the
various premium paid services that can be offered during the SRS

e-Pragati Requirements Specification Document Temple Management System


of 216

Page

vi.

vii.
viii.

phase and the same will be approved by the PMU. The tariff or the
services charges levied for these services will be determined by the
government (line departments).
Usability - The Portal/UI shall have very good user experience
enabling smooth usability, customer journey and use of lean web
technologies. The users shall be able to customise their views based
on personal attributes and needs, for better organising workspace
and display of information if required.
The search shall be supported with advance search options. The
various search options shall be obtained and detailed as part of SRS
for the necessary implementation.
Localisation All citizen/pilgrim facing interfaces in the application
shall provision for bilingual support (Telugu and English).

Below is the indicative list of views in each of the Portals based on user
type.
Category
Common Views
Citizens
Pilgrims

Patashala Users
Trustees
Staff of Temples
Vendors
Department
Users

Senior
Management

Administrator

Indicative List of Views


Views related to Login, Registration, Profile Mgmt (includes
change/reset password).
These are prospective Pilgrims. This consists of Views
related to Pilgrim Services such as Seva, Darshanam
Booking,
Accommodation
Booking,
Donation
and
Annadanam Views.
Views related to Trainings, Knowledge management,
Rituals
Views related to Asset Management, Production planning,
Room management, Views related to supervision of
Temples, Mutts and Peetams.
Views related to Room management, Queue management,
Rituals Planning.
Views related to Procurement, Auction
Views related to administration and supervision of
Temples, Mutts and Peetams.
Views related to Predictive Analysis, Asset Management,
Production Planning, Auction, Procurement, Finance and
Accounting, Payroll.
Views pertaining to the above Department views.
They shall also have access to Dashboard views and
reports pertaining to the status/outcome of the ePIs. The
views shall be geography wise, functionary wise and
department wise.
Refer Annexure 9 - EPI & KPI Requirements for the list of
ePIs that are to be measured/derived.
Views related to General Administration, enabling role
based access to protected pages and resources.
TABLE

18:

VIEWS OF TEMPLE APPLICATION

5.2.2. Business Logic Layer


i.
This is a Service Layer that defines an application's boundary along
with the set of available operations pertaining to it, from the
perspective of interfacing client layers.

e-Pragati Requirements Specification Document Temple Management System


of 216

Page

ii.

It encapsulates the application's business logic, controls transactions


and coordinates responses in the implementation of its operations.
The business logic should be loosely coupled.
The business logic will also include the workflow for approvals required
to deliver the application.
The business logic for Temple Package Common modules, Department
specific modules and sub-modules shall be designed as coarse-grained
services based on SOA principles and API based. This enables the
services to be re-used across modules and also by external systems.
SI shall ensure that these APIs are inter operable in nature

iii.
iv.
v.

vi.

Please refer the functional requirements of the Common Modules and


Department Specific Modules in Annexure 4.
Refer best practices at
http://e-pragati.ap.gov.in/bestpractices.html for the recommended IT
Standards and Architecture compliance.

5.2.3. Data Access Layer


i.
This is the persistence layer and consists of Data Access
Components/APIs that interact with the underlying database for
CRUD (Create/Read/Update/Delete) operations.
ii.
A Data Access Layer encapsulates the code that is used to connect
to the database and perform these operations and it actually works
as a link between the business entities in the Business Layer and the
actual data storage layer.
5.2.4. Common Technical Services
The Infrastructure components like logging, exception handling, caching is
to be designed as framework components that can be pluggable. The
application shall have the ability to capture the necessary metrics required
for Analytics.
Below is the list of common technical services components:
Sl.
No
.
1.

2.
3.
4.

5.

Components

Description

Configuration

This provides a framework to pick the configurable


values from say property file/database specific to
environment on which the application is deployed. This
framework should also have the capability to also
configure the variables that may change on a time-totime basis based on situations.
Logging
& This provides a framework to log debug, info and error
Traceability
messages in a pre-defined format so that it is traceable.
Exception
This provides a framework for handling business and as
Handling
well as application exceptions.
Email
This provides APIs for sending email notifications. These
APIs integrate with E-mail Server for performing the
necessary operations. E-mail server shall be facilitated
by the Department.
SMS
This provides APIs for pushing SMS notifications. These
APIs integrate with SMS Gateway for performing the
necessary operations. SMS server will be facilitated by

e-Pragati Requirements Specification Document Temple Management System


of 216

Page

Sl.
No
.

Components

6.

Caching

7.

Tagging
Metrics

8.

Personalisatio
n

&

Description
the Department.
The master/reference data should be cached during
startup of the server for better performance. This
framework component should provide APIs to put objects
in
cache,
remove
objects
from
cache
and
invalidate/refresh the cache (without the need of server
restart). SI shall propose suitable technical solution
based on the requirements.
This framework component should provide APIs to enable
the developer to invoke the necessary analytic product
APIs.
The user shall be able to personalise the site by selecting
the information and services that are of their interests
and organise the presentation in their personal
workspace.

TABLE

19:

COMMON TECHNICAL SERVICES

e-Pragati Requirements Specification Document Temple Management System


of 216

Page

5.2.5.

Temple Package Databases


This consists of the various databases used to store the information
pertaining to new and existing Health applications. Refer Data
Architecture in Section 7 Data Integration View for more specifics on
the various Databases involved.

5.2.6.

Common Security Services


In addition to the authentication and authorisation services, the
following needs to be adhered during development of new
applications.
1. Secure Design and coding practices shall be adopted to ensure
the software is developed and implemented securely.
2. The portal shall be implemented with proper validations and
checks to ensure the following known vulnerabilities are handled
properly in the application system.
i.
Non-validated input (i.e. input fields shall conform to the
desired formats and values).
ii.
Broken access control.
iii.
Broken authentication and session management (i.e.
use of account credentials and session cookie).
iv.
Cross-site scripting ("XSS").
v.
Buffer overflows.
vi.
Injection vulnerability flaws (e.g. SQL injection,
command injection.)
vii.
Improper error/exception handling.
viii.
Insecure storage.
ix.
Denial of service.
x.
Insecure configuration management.
xi.
The Portal shall not disclose to users more information
than necessary when a failure or error occurs
xii.
Password shall not be hard-coded into any software or
programs.
The system shall have the facility for deletion of the access rights of
the user who have resigned/retired from services in a timely basis to
prevent unauthorised access in the portal

e-Pragati Requirements Specification Document Temple Management System


of 216

Page

6. Business Architecture
The state of Andhra Pradesh attaches great significance to the Endowments
Sector. The Temple Management System consists of multiple applications which
work across a score of external e-Pragati applications to deliver value to the
stakeholders in the Endowment Sector. The core stakeholders are the pilgrims
and staff of temples who are supported by the endowment institutions,
Endowment department and other departments. The end value derived to the
pilgrims is amply demonstrated by the diagram below:
Below Figure 6 illustrates the life cycle of a pilgrim who avails services of Temple
Management System:

FIGURE

6:

BIG PICTURE OF PILGRIM

S ERVICES LIFE C YCLE

e-Pragati Requirements Specification Document Temple Management System


of 216

Page

Below Figure 7 illustrates the life cycle of a Temple Management System:

FIGURE

7:

BIG PICTURE OF

TEMPLE MANAGEMENT S YSTEM

Planners and administrators desire a reliable set of cross-disciplinary data related


to pilgrims, Archaks, System Integrators, donations, employment opportunities
and levels of pilgrims enrolment for long-term planning and proper
management. The stakeholders are desirous of trust-worthy advice and
information related to managing and improving the quality of pilgrim services
from a common platform. When juxtaposed with the tremendous leaps that
technology has taken, and its ability to reach a wide section of population, this
presents a compelling opportunity for the emergence of a synthesizing platform
that could orchestrate structured generation of data, analytics, information,
cognitive models and knowledge flow to the demand points. This is sought to be
achieved through the integration of applications under the Temple Management
System with Datalytics (the Big Data reporting tool) under the e-Pragati
framework.

e-Pragati Requirements Specification Document Temple Management System


of 216

Page

The multiple applications in the Temple Management System such as Pilgrim


service Management System, Temple Management System and Accounting
management system follows the service orchestration framework shown in
Figure 8 to deliver the end results to the stakeholders who uses the Temple
Management System.

FIGURE

8:

INFORMATION - SERVICE HARMONISATION FRAMEWORK

As shown in the above Figure, as part of Temple Management System the


information synthesises conceptualised with the following objectives:

Cross-departmental data exchanges - with unique and specific data


acquisition on critical parameters - between endowment and allied
departments, to foster a sense of shared ownership, accuracy and
authenticity.

Interoperate with a dependable analytics platform (DataLytics Project,


which is a component of the CORE Package of e-Pragati) that - over time, and
based on long term data accumulation, could offer derived information
products that offers compelling value creation to the stakeholders in the
Endowments value chain.

e-Pragati Requirements Specification Document Temple Management System


of 216

Page

e-Pragati Requirements Specification Document Temple Management System


of 216

Page

6.1.

Functional Requirements

The selected SI shall coordinate with the stakeholders for detailed system study
and interact with users of the departments, who uses Temple Management
System, for the preparation of functional and system related requirement
documents. The SI has to understand that the functional requirement
specifications stated in this document are the minimum module requirements
and wherever further functionalities are required, it shall be addressed in
consultation with the stakeholders involved. Therefore, the SI shall develop
requirements and system design documents after studying the G.Os, processes,
procedures, existing forms and templates. To independently design and
implement the Temple Management System for Endowments Department- in
concurrence with the Departments that uses the Temple Management System.
The minimum functional requirements are given in the annexures as follows:
1. Functional Requirements of Common modules of e-Pragati consumed by
Temple Management System - (Annexure 4)
2. Functional Requirements of Common Modules & Sub-modules of Temple
Management System - (Annexure 5)
3. Forms Re-engineering Requirements of Common Modules & Sub-modules
of Temple Management System - (Annexure 6)
4. MIS Reporting Requirements - (Annexure 8)

e-Pragati Requirements Specification Document Temple Management System


of 216

Page

6.2.

Service Portfolio of TM Package

The essence of e-Pragati and the Temple Management System is to deliver services to pilgrims efficiently and
conveniently. It is necessary to design all the systems and sub-systems around the services. The list of services
currently targeted, as common to all institutions of this department, or and Service Levels are given in Table 20. It is
the responsibility of the SI to design, develop and deliver all these services, duly complying with the defined service
levels.
Given below is the list of Common Services of Temple Management System, Service type and Service Levels
(mapped to Modules & sub-modules).
Sl.
Pilgrim Service
No.
Pilgrim Registration
1
Submission of
application form and
other details for
Unique ID
(Pilgrims/Donors/
NGOs)
2
Activation of "Unique
ID"(Pilgrims/Donors/
NGOs) for online
registration
Availability for tickets
3
Seva

Service
Code

Module

Type of
Service

Service Level

TMS001

Pilgrim Information
Management

Transactional
(Without
payment)

User should be able to enrol in


the Portal within 5 minutes.

TMS002

Pilgrim Information
Management

Transactional
(Without
payment)

User should be able to get the


unique ID instantly on realtime basis

TMS003

Seva and Darshanam

Informationa
l/
Transactional

TMS004

Seva and Darshanam

Informationa
l/
Transactional

Registered User should be


able to access the required
information in portal and
apply for within 3 minutes.
The booking should be done.
Registered User should be
able to access the required
information in portal within 5
minutes. The booking should
be done.

Darshanam

e-Pragati Requirements Specification Document Temple Management System Page 78 of 216

Sl.
No.
5

Pilgrim Service
Accommodation

Service
Code
TMS005

Module
Accommodation

Type of
Service
Informationa
l/
Transactional

Service Level
Registered User should be
able to access the required
information in portal within 3
minutes. The booking should
be done.

e-Pragati Requirements Specification Document Temple Management System Page 79 of 216

Booking for Individual or Package of services - Arjitha Seva, Darshanam, Accommodation, Tonsuring
and Annadanam
6
Advance booking
TMS006
All Pilgrim facing
Information/T Registered User should be
modules ransactional able to access the required
Accommodation , Seva
information in portal within 5
and Darshanam,
minutes. The booking should
Kalyankatta,
be done.
Annadanam, Pilgrim
Information
management, Pilgrim
tracking, Call centre,
Complaints
management
7
Current booking
TMS007
All Pilgrim facing
Informationa Registered User should be
modules l/Transaction able to access the required
Accommodation, Seva
al
information in portal within 5
and Darshan,
minutes. The booking should
Kalyankatta,
be done.
Annadanam, Pilgrim
Information
management, Pilgrim
tracking, Call centre,
Complaints
management
Information services
Accommodation module
8
Type of rooms and
TMS008
Accommodation
Informationa Registered User should be
amenities provided
module,
l
able to access the required
information within 5
minutes.
9
Room Allotted /
TMS009
Accommodation
Informationa Registered User should be
Location
module,
l/
able to access the required
Transactional information within 5
minutes.
10
Confirmation for the
TMS010
Accommodation module Informationa Registered User should be
Caution Deposit
l/
able to access the required
e-Pragati Requirements Specification Document Temple Management System Page 80 of 216

Refund

Transactional

information within 5
minutes.
Registered User should be
able to access the required
information within 5
minutes.
Registered User should be
able to access the required
information within 3
minutes.
Registered User should be
able to access the required
information within 3
minutes.
Registered User should be
able to access the required
information within 3
minutes.
Registered User should be
able to access the required
information within 3
minutes.

Seva and Darshanam


11
Sevas performed in
upcoming days

TMS011

Seva and Darshanam


module

Informationa
l/Transaction
al

12

Time period for


booking a Seva /
Darshanam

TMS012

Seva and Darshanam


module

Informationa
l

13

Privileges along with


Seva booking

TMS013

Seva and Darshanam


module

Informationa
l

14

Reporting time for


Seva and the
location for
performing the Seva
Pre-requisites for
performing a Seva

TMS014

Seva and Darshanam


module

Informationa
l

TMS015

Seva and Darshanam


module

Informationa
l

Annadanam
16
Slot allotted

TMS016

Annadanam module

Informationa
l

Registered User should be


able to access the required
information within 3
minutes.

Tonsuring
17
Tonsurer allotted

TMS017

Kalyankatta module

Informationa
l/
Transactional

Registered User should be


able to access the required
information within 3
minutes.

TMS018

Transport Management

Informationa
l/

Registered User should be


able to access the required

15

Transport
18
Tour Packages Places covered,

e-Pragati Requirements Specification Document Temple Management System Page 81 of 216

Timing and Cost


19

Free bus - timings


and stops

Books
20
List of
books/calendar/
Diary and associated
articles available in
different languages
and cost

Transactional
TMS019

Transport Management

Informationa
l

TMS020

Sales and Distribution


Module

Informationa
l/
Transactional

information within 5
minutes.
Registered User should be
able to access the required
information within 3
minutes.
Registered User should be
able to access the required
information within 5
minutes.

e-Pragati Requirements Specification Document Temple Management System Page 82 of 216

Laddu Coupons
21
Coupon validity for
laddu collection,
details of cost of the
Coupon, No. of
Laddu Offered,
Donors
22
Total services availed
in a year along with
details of people
accompanying
Donation Services
23
Donation by Donors

Queue management
24
Darshanam/ Waiting
time before entering
the VQC
25

26

Release time of the


compartment

Information on the
pilgrim inflow / total
pilgrim arrival for
Darshanam, Seva,
Accommodation,
Annadanam and
Kalyankatta
Caution Deposit refund
27
At Seva counter Based on validity

TMS021

Potu & Laddu


Distribution Module

Informationa
l/
Transactional

Registered User should be


able to access the required
information within 5
minutes.

TMS022

Finance and Accounts

Informationa
l

Registered User should be


able to access the required
information within 3
minutes.

TMS023

Finance and Accounts

Transactional

Registered User should be


able to access the required
information in portal within 5
minutes. Donation must be
done

TMS024

Queue Management

Informationa
l

TMS025

Queue Management

Informationa
l

TMS026

Queue Management

Informationa
l

Registered User should be


able to access the required
information within 3
minutes.
Registered User should be
able to access the required
information within 3
minutes.
Registered User should be
able to access the required
information within 3
minutes.

TMS027

Accommodation
module,

Informationa
l/

Registered User should be


able to access the required

e-Pragati Requirements Specification Document Temple Management System Page 83 of 216

Room management
module

Transactional

information within 5
minutes.

e-Pragati Requirements Specification Document Temple Management System Page 84 of 216

Services for Privileged donors


28
Account
TMS028
management for
Donors for the
services availed per
year
29
Booking for a
TMS029
Darshanam

Finance and Accounts

Transaction
al

Finance and Accounts

Transaction
al

TMS030

Finance and Accounts

Transaction
al

Rituals and Inventory


31
Information on Gold
and Silver Dollars

TMS031

Ritual and Inventory

Transaction
al

32

Purchase of Gold and


Silver Dollars

TMS032

Ritual and Inventory

Transaction
al

33

Purchase of Laddu
Coupon

TMS033

Ritual and Inventory

Transaction
al

TMS034

Complaint
Management

Transaction
al
(Without

30

Booking for
accommodation

Complaints / Grievance
34
Lodging a
Complaint /
grievance

Registered User should be able


to access the required
information in portal within 5
minutes. The booking should
be done.
Registered User should be able
to access the required
information in portal within 5
minutes. The booking should
be done.
Registered User should be able
to access the required
information in portal within 3
minutes. The booking should
be done.
Registered User should be able
to access the required
information in portal within 5
minutes. The booking should
be done.
Registered User should be able
to access the required
information in portal within 5
minutes. The booking should
be done.
Registered User should be able
to access the required
information in portal within 5
minutes. The booking should
be done.
Registered User should be able
to access the required
information in portal within 5

e-Pragati Requirements Specification Document Temple Management System Page 85 of 216

35

36

System generated
acknowledgment
number for the
complaint registered,
to track the status of
the complaint on
internet
Update for the action
taken

TABLE

20:

TMS035

Complaint
Management

payment)
Information
al

TMS036

Complaint
Management

Information
al

LIST OF COMMON

PILGRIM FACING S ERVICES

OF

minutes.
Registered User should be able
to access the required
information in portal within 3
minutes.

Registered User should be able


to access the required
information in portal within 3
minutes.

TEMPLE MANAGEMENT S YSTEM

In addition to the above Pilgrim facing services, the following internal services of Temple Management System shall
be delivered by the SI as part of the solution.
Sl.
Service
Service
No.
Code
Temple Lands Management
1
Information on
TMS037
Temple Lands

Module

Type of
Service

Service Level

Temples profile &


property Management

Informational

Estimation of Land
Value

TMS038

Temples profile &


property Management

Informational

Verification of Land
assigned for Lease
holder
Collection of Lease
amount for Leased
Lands
Allotment of Land for
Lease holders

TMS039

Temples profile &


property Management

Informational

TMS040

Temples profile &


property Management

Transactional
(payment)

TMS041

Temples profile &


property Management

Transactional
(payment)

User should be able to get


the Information in the Portal
on real-time basis.
User should be able to get
the Information in the Portal
on real-time basis.
User should be able to get
the Information instantly on
real-time basis
User should be able to access
the Information in the Portal
on real-time basis.
User should be able to access
the information in the Portal

4
5

e-Pragati Requirements Specification Document Temple Management System Page 86 of 216

Sl.
No.

Service

Service
Code

Module

Type of
Service

Service Level
within 3 minutes.

Temple Assets Management


3
Allotment of Shops
TMS042

Assets & Fund


Management

Informational
/
Transactional

Collection of amount
from Shops

TMS043

Assets & Fund


Management

Informational

Verification of
allotted shops

TMS044

Assets & Fund


Management

Informational

Information of shops TMS045


(Allotted & not
allotted)
Temple Financial Management
7
Information on Hundi TMS046

Assets & Fund


Management

Informational

Assets & Fund


Management

Informational

Time Slots for


counting of Hundi
amount

TMS047

Assets & Fund


Management

Informational
/transactiona
l

Information of
Temple Revenue

TMS048

Assets & Fund


Management

Informational

10

Information on
TMS049
Assets & Fund
Revenue
Management
expenditure
Temple Human Resources Management
11
Recruitment of
TMS050
Human Resources
Temporary staff
Management

Informational

Transactional

User should be able to access


the required information in
portal and transact within 3
minutes.
User should be able to access
the required information in
portal within 3 minutes.
User should be able to access
the required information in
portal within 3 minutes.
User should be able to access
the required information in
portal on real-time basis
User should be able to access
the required information in
portal on real-time basis
User should be able to access
the required information in
portal within 3 minutes
and allocate the slots
User should be able to access
the required information in
portal on real-time basis
User should be able to access
the required information in
portal on real-time basis
User should be able to access
the required information in
portal within 5 minutes

e-Pragati Requirements Specification Document Temple Management System Page 87 of 216

Sl.
No.

Service

Service
Code

Module

Type of
Service

12

Application for
Provide training for
Archakas

TMS051

Human Resources
Management

Transactional
(Nonpayment)

13

Supply of material to
staff

TMS052

Human Resources
Management

14

Application for
schemes (Archakas
welfare fund)

TMS053

Human Resources
Management

Transactional
(Nonpayment)
Transactional
(Nonpayment)

15

Application for
transfer of temple
for archakas

TMS054

Human Resources
Management

Transactional
(Nonpayment)

16

Application for leave

TMS055

Human Resources
Management

Transactional
(Nonpayment)

TABLE

21:

LIST OF

INTERNAL S ERVICES

OF

Service Level
and apply
User should be able to access
the required information and
process in portal within 3
minutes
User should be able to access
the required information in
portal within 3 minutes
User should be able to access
the required information and
apply in portal within 3
minutes
User should be able to access
and get the required
information and apply in
portal within 3 minutes
User should be able to access
and get the required
information in portal within
1 minutes

TEMPLE M ANAGEMENT S YSTEM

e-Pragati Requirements Specification Document Temple Management System Page 88 of 216

6.3.

e-Pragati Indicators (e-PIs)

The success of Sunrise Andhra Pradesh vision depends on its articulation,


communication and meticulous execution to realise the intended benefits.
Therefore, the execution of seven missions needs to be monitored and measured
periodically. To continuously measure the progress of the missions and the
benefits delivered to various stakeholders, each mission have to be evaluated
periodically. For this purpose, the Key Performance Indicators (KPIs) are defined
at mission level and measurable outcomes under the e-Pragati ecosystem are
classified as e-Pragati Indicators (e-PIs).

FIGURE

9: E -PI

FRAMEWORK

The e-PIs are outcome oriented whereas the KPIs are process and output oriented.
SI may use balanced scorecard or any other framework to achieve the service
delivery measurement. The following table gives the list of top 6 e-PIs for the
Temple Management System:
The following table gives the list of KPIs of the Temple Management System:
Sl. No.
1.
2.
3.
4.
5.
6.

Name of the
Department
Endowments
Department

TABLE

KPIs
Pilgrim Amenities
Web pilgrim Services
Facility Management(sanitation) Services
Annadanam
Aarogyadanam
Vidyadanam

22: TEMPLE MANAGEMENT S YSTEM

KEY PERFORMANCE INDICATORS

e-Pragati Requirements Specification Document Temple Management System Page 89 of


216

The detailed methodology for computing the KPIs and e-PIs will be provided on the
e-Pragati web site (http://e-Pragati.ap.gov.in/).

e-Pragati Requirements Specification Document Temple Management System Page 90 of


216

7. Data Architecture & Requirements


7.1.

Data Architecture

Data Architecture describes how data is captured, persisted, arranged, and


integrated across system in a secure and consistent manner so that quality and
integrity of data is maintained. And while doing so, Data Architecture will ensure
that Enterprise level principles, policies, rules, and standards are applied
7.2.

Conceptual Data Models

Exhibits below capture conceptual data models for Temple Management System).
Conceptual model captures key data entities, concepts, and relationships in Temple
Management System. This model will inform development of detail level data
models Logical and Physical Data Models.

e-Pragati Requirements Specification Document Temple Management System Page 91 of


216

FIGURE

10: Conceptual Data Model for TMS

e-Pragati Requirements Specification Document Temple Management System Page 92 of 216

7.3.

Data Integration View

Data integration is realised by Batch, ETL, and near real-time methods (event-driven
architecture). e-Highway will facilitate near real-time integration. The system will
adapt Service Oriented Architecture concepts and provide Data Services for
frequently used queries and updates.

FIGURE

Integration
Databases
Land Hub + GIS Hub
Temple
Management System

11: TMS

Integrati
on
Method
Web
service

DATA INTEGRATION MODEL

Integration Scenario (Indicative list)

Temple Management System will consume


Temples land information Service
Land information service for Temples will
contain GIS layers from GIS hub

e-Pragati Requirements Specification Document Temple Management System Page 93 of


216

Integration
Databases
People Hub
Temple Management
System
DataLytics
Temple Management
System
Health Department
Database and Other
Department-level
Databases

Integrati
on
Method
Web
service

ETL

Web
service

TABLE 23: TMS

7.4.

Integration Scenario (Indicative list)


Temple Management System will retrieve
devotee, donor, employee, trustee, and
other people related information from
People Hub
Data from Temple Management System to
DataLytics for Analysis
On need basis, Endowments department
Applications may use services from other
departments E.g.: Temple Management
System may consume biometric services
from PDS.

INTEGRATION REQUIREMENTS

Master Data

Master data represents the business objects which are agreed on and shared across
enterprises. Department level master data includes objects that are shared between
different applications within a department. State-wide master data are objects that
are shared across departments.
Common master elements will be captured and made available on Data Hubs.
Department specific master data will be captured in department databases. Temple
Management System related master data has been identified and listed in a
separate document. This document will be made available to the System Integrator.
7.5.

Data Architecture Compliance Requirements

The table below lists Data Architecture Compliance Requirements


Sl.
No.
1.
2.
3.
4.
5.
6.
7.

Data Architecture Compliance Requirements


Standard schemas shall be published for all data entities and accessible
through standard SOA services.
Access to a data entity shall be restricted only through a designated singlepoint-of-contact interface.
Data access requirements shall be defined clearly based on role,
responsibilities and need to access data.
Providers and consumers for each data entity shall be defined clearly.
Metadata and Data Standards (MDDS) shall be followed. At each domain level,
metadata and reference data standards shall be used if available, otherwise
they shall be defined.
Target Application shall use core data only from e-Pragati data hubs.
Data quality controls shall be established by ensuring incoming data is of good
quality. Invalid data shall be prevented through strict semantic and syntactic

e-Pragati Requirements Specification Document Temple Management System Page 94 of


216

Sl.
No.
8.
9.
10.
11.
12.

Data Architecture Compliance Requirements


checks at run time.
Batch and real-time data integration mechanisms shall be available.
Data lifecycle management plan shall be in place and implemented.
Databases shall be scalable in terms of total space, number of tables, views
and users.
Data integration shall be maintained between related entities by defining
primary keys and secondary keys relationships.
The Target Application shall ensure that all relevant data specific reference
architectures, architecture patterns, best practices and standards from national
and global level are followed, wherever they are applicable.
TABLE 24:

DATA ARCHITECTURE COMPLIANCE REQUIREMENTS

* SI can propose technical solution based on requirements.

e-Pragati Requirements Specification Document Temple Management System Page 95 of


216

7.6.

Data Architecture Compliance Requirements

Table 24 below gives Data Architecture compliance requirements and roles and responsibilities of GoAP and SI.
Please note that the term GoAP encompasses departments, existing SIs, and e-Pragati enterprise architecture
team.
Sl.
No
.
1.

Data Architecture
Compliance
Requirements
Standard schemas
shall be published for
all data entities.

2.

Data access
requirements shall be
defined clearly based
on roles,
responsibilities, and
need to access data.

3.

Providers and
consumers for each
data entity shall be
defined clearly.

GoAP Responsibilities

SI Responsibilities

1. Allow access to existing application


databases so that SI can conduct ASIS database study
2. Assist SI in conducting AS-IS study by
allocating dedicated resources
3. Provide high-level conceptual data
models
4. Review
and
approve
artefacts
created by SI
1. Provide
role-wise
data
access
requirements
2. Share
specific
data
security
requirements such as encryption
requirements
3. Review
and
approve
artefacts
created by SI

1. Conduct AS-IS database analysis


2. Develop TO-BE database schema
(logical and physical data models)

1. Share information about producers


and consumers of data
2. Review
and
approve
artefacts
created by SI

1. Develop a strategy for capturing data


access requirements. (A sample
template is provided as part of ePragati Enterprise Data Architecture
document)
2. Work with departments to capture
access requirements for all major
Datasets
1. Study TO-BE application design
2. Identify all data sets and owner
applications
3. Work with departments and existing
SIs to identify data owners
4. Develop a template to capture data
provider and consumer information
( A sample template is provided as
part of e-Pragati Enterprise Data
Architecture document)

e-Pragati Requirements Specification Document Temple Management System Page 96 of 216

Sl.
No
.
4.

5.

6.

7.

8.

Data Architecture
Compliance
Requirements
Metadata and data
standards (MDDS) shall
be followed. At each
domain level,
metadata and
reference data
standards shall be
used if available,
otherwise they shall be
defined.
Target application shall
use core data only
from e-Pragati data
hubs.

GoAP Responsibilities

SI Responsibilities

1. Identify Metadata standards to be


followed by SI
2. Provide
high
level
metadata
requirements
3. Review
and
approve
artefacts
created by SI

1. Ensure compliance of metadata


standards while developing solution
architecture, and design artefacts
2. Identify non-compliance (if any), and
provide
justification
for
noncompliance

1. Identify core data hubs


2. Provide high-level data integration
requirements
3. Review
and
approve
artefacts
created by SI

1. Develop detailed data integration


models
2. Identify all data elements that are
being exchanged
3. Identify
integration
mechanism
(batch/ near real-time, and SLA)
1. Develop data quality metric ( A
recommended template is provided
in e-Pragati Enterprise
Data
Architecture document)
2. Perform data quality assessment
3. Develop data profiling, cleansing, and
standardisation strategies

Data quality controls


shall be established by
ensuring incoming data
is of good quality.
Invalid data shall be
prevented through
strict semantic and
syntactic checks at run
time.
Batch and real-time
data integration
mechanisms shall be
available.

1. Provide inputs for developing data


quality metric
2. Provide access to data and database,
so that SI can conduct data
assessment
3. Support SI in conducting data quality
assessment
4. Review
and
approve
artefacts
created by SI
1. Review and approve integration
strategies

Data lifecycle
management plan shall

1. Provide inputs for developing data


lifecycle management policies (For

1. Identify cases, and datasets for batch


integration
2. Identify cases, and datasets for realtime integration
3. Develop batch and real-time data
integration strategies
1. Gather inputs from departments and
develop data lifecycle management

e-Pragati Requirements Specification Document Temple Management System Page 97 of 216

Sl.
No
.

9.

10.

11.

Data Architecture
Compliance
Requirements
be in place and
implemented.

Databases shall be
scalable in terms of
total space, number of
tables, views and
users.
Data integration shall
be maintained
between related
entities by defining
primary keys and
secondary keys
relationships.
The target application
shall ensure that all
relevant data specific
reference
architectures,
architecture patterns,
best practices and
standards from
national and global
level are followed,
wherever they are
applicable.

GoAP Responsibilities

SI Responsibilities

e.g. data retention requirements,


deletion criteria )
2. Review and approve data lifecycle
management policies

policies
2. Ensure relevant best practices are
incorporated, and standards are met
3. Create
template
for
capturing
lifecycle management requirements (
A template is provided is provided in
e-Pragati
Enterprise
Data
Architecture document)
1. Review
and
validate
scalability
requirements
specified
in
this
document
2. Ensure that the solution meets
scalability requirements
1. Develop Logical and Physical data
models
2. Ensure
referential
integrity
is
maintained between various datasets

None

None

None

1. SI shall ensure best practices, and


standards are taken into account
while
conducting
all
the
aforementioned activities
2. SI shall refer e-Pragati Enterprise
Data Architecture for information on
standards to be followed

* SI can propose technical solution based on requirements.

e-Pragati Requirements Specification Document Temple Management System Page 98 of 216

TABLE

25:

DATA ARCHITECTURE COMPLIANCE REQUIREMENTS

1. Data Capture Methodology: The data capture methodology can be accessed at the following URL - http://epragati.ap.gov.in/projectartifacts.html
2. Data Life Cycle Management: The Data Life Cycle Management document may be referred at the following URL http://e-pragati.ap.gov.in/projectartifacts.html

e-Pragati Requirements Specification Document Temple Management System Page 99 of 216

8. Technology Architecture
8.1

High-level Technology Architecture

Technology Deployment Architecture of TMS Package assembles the assets and


capabilities required for the TMS Package Systems deployment. It defines logical
and physical view of TMS Package Systems identified in Application Architecture.

8.2

Logical Technology Architecture

The logical technology architecture describes logical components that provide


various benefits such as integration of systems using common middleware
component, centralised data store and high availability of business system and
services.

FIGURE

13:

LOGICAL TECHNOLOGY ARCHITECTURE VIEW

The components of the Technology Architecture are described in the below Table:

e-Pragati Requirements Specification Document Temple Management System Page 100 of


216

Technology
Component
External
Security
Layer

Requirement

External Security layer will protect the core system from


unwanted traffic and provides easy and seamless access with
the help of NAC, Load balancer, and reverse proxy and access
gateways.

Temple Management Systems mobile user requests would be


rendered or processed through Gateway

Web layer will enable external and internal user to access


Temple Management System through any web browser from
any location

Web access layer provides various web interfaces for different


types of users like, tablet users, mobile users and standard
browser users

Internal
Security

All internal traffic (department & Dial.AP users) would be


routed through internal security layer which block unwanted
access and attacks

Application
Cluster

Application cluster will contents the business logic and


perform the task required for Temple Management System.

Database
Cluster

Temple Management Systems structured data will be stored


in database and for high availability databases system should
be configured on high availability cluster environment

VNA
Repository
(PACS)

The Vendor Neutral Archive (VNA) Repository shall be used for


storing the medical images required as part of Picture
Archiving and Communication System (PACS) Requirements.

e-Highway

e-Highway will be used by Temple Management System to


connect with all related systems like, People Hub, Land Hub,
and so on

Centralised
Security
System

Proposed solution shall have in Security mechanism as per


industry standard and defined in in Security Architecture

Centralised
Monitoring
System

Centralised Monitoring System would manage and monitor all


enterprise systems and IT Infrastructure components. It would
provide real time alert/notification & dashboard for analysis
and performance management.

Mobile/Tablet
users

Mobile/Table users request would come to NAC and then


routed to a specific web server. Post that request will be
transferred to Channel Enablement Services and Business
Process Service Platform to process user request.

Web Layer

e-Pragati Requirements Specification Document Temple Management System Page 101 of


216

Technology
Component
Data Backup

Requirement

Data Backup shall be responsibility of SI, they have to ensure


the data backup should be in place with 99% backup success
rate, data backup should be as per backup policy decided by
GoAP during the SRS Phase.
TABLE 26:

COMPONENTS OF THE TECHNOLOGY

e-Pragati Requirements Specification Document Temple Management System Page 102 of


216

8.3

Sizing Requirements

Endowments Package shall be deployed on Cloud and SI needs to provide the


complete end to end solution for the same. The proposed cloud based solution shall
be in-line with the details provided on Section 3.2.4 Deployment Model. The
indicative number of users and required bandwidth details are provided below for
designing the solution. The required details are provided as per current and
expected users and the proposed solution shall be designed considering 10% yearon-year growth of users. Solution should shall be designed with consideration of
scalable with respective to accommodate exponential growth on application load.
a Number of users currently using the Endowments Department System:
i.
ii.
iii.
iv.
v.
vi.
vii.

Department Users 7000


Concurrent Users - 400
Expected Transactions by each departmental users is 10 per day
Total number of Pilgrims visiting the listed temples 5 lakhs per annum
Expected transaction on website for all pilgrims - 2 lakhs per annum (40% of
the total pilgrims visiting the listed temples)
Temples based Transactions 5 transactions per Pilgrim per visit
4 SMS alerts needs to be sent to all registered pilgrims for darshanam
confirmation and other details

e-Pragati Requirements Specification Document Temple Management System Page 103 of


216

Indicative Bandwidth Requirements:


Majority of Temples will be connected with AP FiberNet and minimum 10 Mbps
bandwidth will be provided to each Temple at the end point, which would be
sufficient to access Endowments Package functionality. Endowments Package will be
accessed as cloud based model (hub and spoke) from each end point.
The SI need to procure minimum 10 Mbps link initially between the SDC and the
Endowments Package on Cloud, which shall be scalable as per the demand and
utilisation.
A VPN connection for this link shall be established by SI to handle the application
integration load through e-Highway to connect with People Hub, Land Hub and other
e-Pragati applications.

Indicative Storage Requirements: 50 TB cloud based SAN storage is required.


Separate storage needs to be procured for VNA Repository (PACS).

8.4

Security Architecture

e-Pragati security architecture is a broad concept that includes various process


components and technology infrastructure components to serve the security needs
of different stakeholders. At high level, it addresses the concerns on authentication,
authorisation, confidentiality, integrity, availability and non-repudiation that cuts
across various architecture domains, namely business, data, application and
technology architectures.
The following Figure 12 describes e-Pragati security architecture framework at high
level:

e-Pragati Requirements Specification Document Temple Management System Page 104 of


216

FIGURE

12: E -P RAGATI

SECURITY ARCHITECTURE FRAMEWORK OVERVIEW

The following Table 27 describes the above framework briefly and scope of SI w.r.t
the aforementioned framework. In case, the deployment model has been chosen as
public cloud environment, the SI shall ensure that these requirements are met by
leveraging inbuilt security capabilities that shall be provided by the cloud service
provider, and also by procuring any third party tools in case of need at SI own cost.
Sl.
No.

Security
Layer

1.

Foundation

2.

Process

Component Description
a. Security Policies, Standards and Guidelines: These are
the high level guidelines that will govern the systems
design, development and operations that cut across
various domains of the Government. A draft/approved
on GoAP security policies document will be provided,
which needs to be adhered by SI, while implementation
of Endowments package. e-Pragati IT security standards
and guidelines are available at e-Pragati website.
b. Risk Management: This deals with the threats that
exploit the vulnerabilities against the assets possessed
by the Department/Government, by taking counter
measures.
a. ID entity Management: This component deals with
authentication, authorisation and auditing functionality
that is relevant to this package. The common ID entity
and Access Management (IAM) component will be part
of Core Package/e-Pragati Portal implementation.
However, the SI is responsible to implement/customise

e-Pragati Requirements Specification Document Temple Management System Page 105 of


216

Sl.
No.

3.

Security
Layer

Infrastructur
e

Component Description
authentication and authorisation functionality specific to
Endowments Package and integrate the same with Core
Package/e-Pragati Portal IAM component to enable
Single Sign-On (SSO) functionality. The section below on
Access Control describes the IAM integration approach
in detail.
b. Threat Management: This component deals with
viruses, Trojans, warms, malicious hackers, intentional
and unintentional attacks on the system, and force
majeure. The SI need to design a detailed threat model
specific to Endowments Package and deploy all required
tools and processes to address envisaged threats to the
system, namely security monitoring and incident
management, firewalls, cryptography and forensic
analysis tools.
c. Vulnerability
Management:
While
the
threat
management deals with unknown security risks at the
system, the vulnerability management deals with
known risks of the system at various levels. The SI shall
identify all vulnerabilities of the system pertaining to
data, application, host and network, and implement
processes and tools to monitor and mitigate them.
d. Software Development: The SI shall implement security
best practices and patterns across all software
development life cycle (SDLC) phases of this package,
to ensure the defined policies and processes are
implemented in various architectural components of the
system.
The Foundation and Process layer defines logically various
artefacts related to security, they need to be implemented
at physical components level concerned to data,
application, host and network level. The following section
defines these requirements at high level which needs to be
implemented by SI.
a. Data:
i.
Specialised scans to be performed on the
database hosts
ii.
Data access to be provided to only authorised
users/groups
b. Application:
i.
Application code need to be protected from
unauthorised access and modifications
ii.
Static analysis tools to be deployed to scan the
code and identify threats and vulnerabilities
iii.
Access to functional modules/components to be
provided to only authorise users/groups.

e-Pragati Requirements Specification Document Temple Management System Page 106 of


216

Sl.
No.

Security
Layer

Component Description
c. Host:
i.
Host intrusion detection systems to be deployed
to protect servers.
ii.
Integrity monitoring checks to be performed on
the hosts to protect files and programs.
iii.
Baseline scanners to be deployed to ensure that
hosts are in adherence to defined security
policies.
d. Network:
i.
Network intrusion detection devices, anti-virus
detection tools and firewalls to be deployed to
protect the network.
ii.
Logical boundaries of network to be defined and
deploy applications as per access requirements.
Logical boundaries can be defined based on
target
user
access
such
as
DMZ
for
internet/extranet access, protected network zone
for intranet access, and restricted network zone
for few critical business users.

TABLE

8.5

27: E -P RAGATI

SECURITY ARCHITECTURE FRAMEWORK COMPONENTS

Access Control Mechanism of Endowments Package

The following generalised Access Control mechanism will be followed for the ePragati applications:
1. User authentication to be verified against the User Repositories through ID
entity Manager
2. Coarse Grained Authorisation is required to be provided by the Access Manager
3. Fine Grained Authorisation is required to be provided by the respective e-Pragati
application typically at portal server level.
4. e-Pragati application containers can enforce fine-grained authorisations depend
on the category of resource (e.g. Secured application resources). In such cases,
the e-Pragati application container invokes the Policy Decision Point (PDP)
through the Policy Enablement Point (PEP) for authorisation decisions.
The following Figure shows e-Pragati application components and their
interactions when a user attempts to access e-Pragati application:

e-Pragati Requirements Specification Document Temple Management System Page 107 of


216

e-Pragati Requirements Specification Document Temple Management System Page 108 of 216

FIGURE

13:

ACCESS CONTROL MECHANISM OF

TMS

e-Pragati Requirements Specification Document Temple Management System Page 109 of 216

Apart from the Identity & Access Management (IAM) solution, the Access Control
mechanism requires following security components to be configured on the ePragati Application Servers:
1. Access Proxy is required to form the first line of defence for the access control.
Access Proxy must be configured on the DMZ located Web Server for the ePragati application. Access Proxy is required to perform the following actions:
a. Intercept the incoming user requests for the e-Pragati Application
b. Verify the presence of users SSO session context
c. Propagate the ID entity information to the servers to enable user access
to the resources hosted on the server
2. Policy Enforcement Point (PEP): This is required to propagate the access policy
decisions for the user access. PEPs are required to be configured on all the
servers which participate in the solution building. PEPs enable the policy driven
access control.

e-Pragati Requirements Specification Document Temple Management System Page 110 of


216

Access Control Flow: The e-Pragati access control flow is based on the usage
of the Single Sign-On (SSO) enablement and Policy driven authorisation. The
following sequence illustrates the envisioned access control flow:
1. User attempts to access the resources on the e-Pragati application
2. The Access Proxy component intercepts the user request and determines,
whether the User is already is authenticated and has an active SSO Session
Context
3. In case of no Active SSO Session Context exists, the following process takes
place:
a. The Access Proxy component will forward the user request to the
Authenticate & Authorise component for verifying the user credentials &
querying the authorisation details.
b. The user will be prompted to provide the user credentials.
c. The user credentials are collected and validated against the appropriate
user directory. Invalid credentials will result in access denial.
d. Multi Factor Authentication (MFA) is triggered based on the authentication
mechanism associated with the user request. In which case, the user will
be prompted to present additional authentication credentials for
verification. Invalid credentials will result in access denial.
e. The Authorisation component will query the user attributes for the
authenticated users.
f. A secured session context is created and maintained in the authorisation
component.
4. In case of an Active SSO Session Context exists, the following process takes
place:
a. The Access Proxy will forward the user request to the PDP via the PEP on
the Web Server.
b. The PDP determines the applicable access policy for the user by verifying
the policy repository.
c. If user is authorised, the Access Proxy determines how the authenticated
user information need to be communicated to the Protected Resource
(e.g., SAML token, HTTP headers, User name token, RACF pass ticket).
Access Proxy will invoke the Secure Token Services component. The
Secure Token Services component creates the requested token from the
authenticated user information. This enables the user information to be
mapped to account and attribute information the e-Pragati application
recognises based on configured trust services/policies.
5. The user request is then forwarded to the requested resource on the
application server.

e-Pragati Requirements Specification Document Temple Management System Page 111 of


216

9. Training & Change Management


In order to successfully address the capacity requirements of the government
officials at various levels, a training plan has been proposed. The training plan is
designed to capture training requirements of officials in order to successfully handle
the e-Pragati Temple Management System Applications, based on the roles and the
responsibilities assigned to them. The training need requirement, at various levels
has been identified based on the functional changes in the working of government
officials in the new set up.
The trainer need to provide the special training on the e-Pragati Temple
Management System Applications in detail to the training / faculty team of the
department.

9.1
Sl.
No.
1.

2.

3.

4.

5.

6.

7.

Indicative Training Requirements


Description

Stakeholders to be trained on user screens, basic functionalities, navigating


screens and operations of the proposed Temple Management System to
realise the envisaged e-PIs for the same.
In addition to the above, the trainings shall delve into data security and its
relevance in maintaining data confidentiality. The System Administration
training shall be given to the nominated staff from the Endowments
department.
Detailed training plan shall be created, and training material shall be prepared
and distributed to the participants. Training plan shall include all necessary
arrangements shall be made to enable smooth running of sessions.
The medium of instruction and materials shall be in Telugu and English
respectively. The training materials has to be provided to each participant in
soft and hard copy.
All necessary arrangements, including preparation of test materials,
administering tests, and evaluating test reports must be planned and done in
advance. At the end of training sessions the assessments in the form of quiz,
tests, and real-life simulation based on user scenarios and trainee/participant
opinion poll (training effectiveness feedback) shall be conducted online only.
PMU will conduct an online exit test at the end of the training session and
allots grades to the all participants. The grades in terms of marks are defined
below:
i.
A - above 90%
ii.
B - above 70%
iii.
C - above 50%
iv.
D - below 50%
If more than 30% of the participants receive D grade, then the training will
have to be re-conducted for the whole batch.
No training infrastructure will be provided by GoAP and the complete training

e-Pragati Requirements Specification Document Temple Management System Page 112 of


216

cost shall be borne by SI.


TABLE

28:

INDICATIVE TRAINING REQUIREMENTS

e-Pragati Requirements Specification Document Temple Management System Page 113 of


216

9.2

Training Deliverables

Sl.
No.
1.

Details
Training Plan

2.

400 copies of Training Manual

3.

Documented Evidence of Successful User Training.

* The timelines are given in Volume 2 of the RFP.


TABLE

9.3

29:

TRAINING DELIVERABLES

Training Responsibility & Duration

The SI shall prepare training plan and contents in sync with the Endowments
department and the trainings shall be rolled out after the approval from
Commissioner Endowments department. The SI shall provide the training to the
departmental staff and others, if any, as instructed by the Endowments department.
The above trainings shall be conducted at four locations such as Vishakhapatnam,
Vijayawada, Tirupati and Kurnool. The expected duration for the training at each
location will be 10 -15 days and that should cover the suggested target audiences
as indicated in the Table 30 given in the section below.

9.4

Training Need
Table 30 lists the high level requirements of training modules and its target
audience.

Sl.
Training Modules
No.
1. e-Pragati Temple
Management System
Orientation Training
2. Specialised Computer
Training
3. Process Training
4. Temple Management
System Applications
Training - Pilgrim Service
Applications
5. Temple Management
System Applications

Target Audiences

Officials of Endowments Department - 50


Officials & staffs of temples - 300

Selected officials of Endowments


Department - 50
Selected officials & staffs of temples - 350
Officials of Endowments Department - 50
Officials & staffs of temples - 350
Selected officials & staffs of temples - 350

Selected officials & staffs of temples - 350

e-Pragati Requirements Specification Document Temple Management System Page 114 of


216

Sl.
No.

Training Modules

Training - Front Office


Support Module
6. Temple Management
System Applications
Training- Integrated
Application Module
7. Temple Management
System Applications
Training- Departmental
process Module
8. Temple Management
System Applications
Training- MIS Reports

Target Audiences

Selected officials of Endowments


Department - 50
Selected officials & staffs of temples - 350

Officials & staffs of temples - 350

Selected officials of Endowments


Department - 50
Selected officials & staffs of temples - 350

Note:
a) The size of each batch should not be more than 40.
b) It will be department wise training and training manuals need to be provided for each department.
c) Coverage of training of each department will not be same.
TABLE

30:

TRAINING MODULES AND TARGETED AUDIENCE

9.5
Change Management
Change Management initiative shall focus on addressing key aspects of project
including building awareness among stakeholders. Change management shall also
include development and execution of communication strategy for stake holders.
Change Management workshops shall be planned and conducted based on needs of
various stakeholders of Temple Management System. Key considerations for Change
Management Process are given below:
Sl.
Description
No.
1. Impact Assessment In the light of changes, how current functioning, Org
structures, roles and responsibilities are impacted.
2. Assess Change Readiness How ready departments and stakeholders are?
Are there potential blockers? Stakeholder issues and concerns.
3. Design Change Management Approach This is to come up with an optimal
way of implementing Temple Management System System (Phases, Pilot
Groups.) and time frames.
4. Develop Change Plan This includes creating plan, identifying milestones,
developing benefit tracking mechanisms.
5. Define Change Governance Including appropriate decision making and
review structures.
TABLE

31:

CHANGE MANAGEMENT REQUIREMENTS

A special consideration will have to be given to Change communication strategy,


planning and execution given below are recommended steps are listed below:
e-Pragati Requirements Specification Document Temple Management System Page 115 of
216

Sl.
No.
1.

Description

3.

Conduct
a
Baseline
Communication
Assessment
Develop and validate Communications
Strategy
Develop and Validate Communication Plan.

4.

Implement Communications Programs

5.

Measure Results of Communication Plan

6.

Adjust Communications Program

2.

TABLE

32:

CHANGE MANAGEMENT

SPECIAL CONSIDERATIONS

e-Pragati Requirements Specification Document Temple Management System Page 116 of


216

ANNEXURE 1 - INTEGRATION ARCHITECTURE


1. Inter-Package Integration
The below Figure 14 depicts the integration view of Temple Management System
w.r.t. to various other e-Pragati package applications and vice versa.

FIGURE

14:

INTER - PACKAGE INTEGRATION VIEW

The integration per se need not be only through real time services. Other modes
of integration shall also be considered based on the detailed requirements.
Various Integration modes and scope of SI is
Sl.
Integrati
Description
No.
on mode
1. Service
This indicates that the
Level
integration
with
the
Integratio application/package
is
n
via a service. It could be
either a SOAP based
web service, RESTful
service
or
Message
based
service(asynchronous)

indicated as below.
Scope of Temple Package SI
If the TMS application is the
consumer then the scope of the
SI shall be, to co-ordinate with the
respective application SI for the
service contract/specs to use the
same. E.g. People Hub.
If the service is to be provided,
than the SI shall co-ordinate to
arrive at the service contract/specs
as needed by the other SIs. e.g.

e-Pragati Requirements Specification Document Temple Management System Page 117 of


216

Sl.
No.

Integrati
on mode

Description

Scope of Temple Package SI


Datalytics, e-Dashboard.

2.

3.

Applicatio
n Level
Integratio
n

Integratio
n Service

This indicates that the


integration is url based
integration
and
via.
Single-Sign-On.
The
user
of
TMS
package
application
shall be able to navigate
to
the
respective
application from within,
via hyperlink).

This
is
API
based
integration where the SI
is made available with
the APIs for using the
services.

The services should be designed to


include the security landscape in
view and this includes the below
key aspects.
a. Authentication
b. Authorization (or Access
Control)
c. Confidentiality, privacy
d. Integrity, non- repudiation
The scope of the SI is to coordinate with respective SIs to
ensure that the relevant users
have appropriate access to those
applications.
E.g.
Mee-Kosam
(Grievance
Mgmt).
The privileged users should be
able to navigate to Mee-Kosam
application via. TMS application
without re-login and use the
features of Mee-Kosam.
Refer Single-sign on approach
detailed in Section 5.1, Tier 2-User
Management
The scope of the SI shall be to coordinate with the SI of e-Pragati
portal for configuring single-signon and also ensure appropriate
update of User Groups and
Repository attributes for the users
to be eligible to access respective
applications.
This refers to the integration with
Gateways
such
as
Payment
Gateway, SMS Gateway and Email
Gateway. The APIs and approach to
integrate will be made available to
SI for leveraging the same.
Refer to Table 26 for more
information on the Gateways.

TABLE 33: APPLICATIONS INTEGRATION MODES

e-Pragati Requirements Specification Document Temple Management System Page 118 of


216

Availability of vendor resources for integration along with manuals is of


paramount importance during integration. The PMU will ensure timely availability
of resources needed for integration and SLAs as per the baselined plan/schedule
shared by the SI. For all the existing applications if any, the data in as-Is
condition will be shared.
The SI shall be responsible to identify all possible requirements/use cases
pertaining to each of the below integrations during the SRS phase.

Sl.
No.

Application

Temple
Applicati
on Role

Integration
Requirement
This shall be a service level
integration.
It shall be used at all
instances where the user
details need to be prepopulated or validated. E.g.
During the process of
Registration
of
Pilgrim,
Donors etc. the basic
details shall be fetched and
auto-populated.

1.

People
Hub

Consumer

2.

Land Hub

Consumer

The inputs shall be any


acceptable identity proof
says Voter ID, People Hub
ID number etc.
The outputs shall be Basic
details such as name,
address, gender details.
SI should generate Unique
ID
for
the
Temple
Application
stakeholders
keeping in view the People
Hub, which will be made
available during the due
course of time. SI has to
map the IDs generated for
the People Hub. SRDH data
should be considered.
This shall be a service level
integration.
It shall be
used at all instances where
the land details of the
Temple need to be prepopulated based on survey
number.

Module / Sub
Module
Traceability
1. Profile
Management /
User
Profile
Management

1. Institutional
Profile
Management
(Land
Pertaining to
Temple, Muts ,
Peetams,

e-Pragati Requirements Specification Document Temple Management System Page 119 of


216

Sl.
No.

3.

4.

Application

APp Store

Entity Hub

Temple
Applicati
on Role

Consumer

Consumer

Integration
Requirement
The input shall be Survey
number.
The output shall be owner
details and detailed land
details pertaining to survey
number.
The mobile apps pertaining
to Temple Package shall be
hosted in the APp store.
This shall be a service level
integration. This shall host
the Temple Information as
an Entity.
The input shall be the
Temple Information and its
location.

5.

6.

7.

Knowledge
Mgmt

Consumer

DataLytics

Provider

eProcureme
nt

Consumer

This is an application level


integration.
This shall be used as a
collaborative platform by
students of Patashala for
sharing of knowledge, Best
practices, experiences via
Discussions Forums, wikis
and Blogs.
This provides information
for analytics that shall
enable Government and
Department with proper
policy decisions.
The SI shall gather all the
possible use cases that
shall help in decision
making and predictions.
These use cases shall
integrate with DataLytics
for enabling the same.
This is an application level
integration. Uses services
related to Procurement of
raw material & services.
This shall be used as a

Module / Sub
Module
Traceability
Patashala etc.)

NA
1. Profile
Management /
Institutional
Profile
Management
(Registration
of
Temple,
Muts
,
Peetams,
Patashala etc.)
All Modules /
Sub Modules
wherever
applicable.

1. Predictive
Analytics

1. Procurement
module.

e-Pragati Requirements Specification Document Temple Management System Page 120 of


216

Sl.
No.

8.

Application

MeeSeva+
+

Temple
Applicati
on Role

Consumer

Integration
Requirement
platform by Vendors for
procuring
of
goods
(milk/coconut/vegetable)
needed for Temples.
Currently,
the
below
services are served in
MeeSeva
Portal
via.
MeeSeva Centers.

Module / Sub
Module
Traceability

NA

1. Sri Durga Malleswara


Seva Ticket Booking
2. Sri
Kalahasteeswara
Swamy
Vari
Devasthanam
Room
Booking
3. Sri
Kalahasteeswara
Swamy
Vari
Devasthanam
Seva
Booking, Srikalahasti
4. Sri
Varaha
Lakshmi
Narasimha
S.D.,Simhachalam,Visak
hapatnam
5. Sri
Varaha
Lakshmi
Narasimha
S.D.,Simhachalam,Visak
hapatnam
Room
Booking
6. Sri
Veera
Venkata
Satyanarayana
S.D.Annavaram,
E.Godavari Dt
7. Sri
Veera
Venkata
Satyanarayana Swamy
Room Booking
8. Sri
Venkateswara
Swamy
Seva
Ticket
Booking
(Dwaraka
Tirumala,West
Godavari)
9. Sri
Venkateswara
Swamy Temple Room
Booking
(Dwaraka
Tirumala, W.G)
The SI shall further identify
potential services that shall
e-Pragati Requirements Specification Document Temple Management System Page 121 of
216

Sl.
No.

9.

10.

Application

Grievance
Mgmt
(MeeKosam)

Dial.AP

e11. Pathakam
(Scheme
Mgmt)

Temple
Applicati
on Role

Consumer

Consumer

Consumer

Project
Mgmt
(e-Pragati
12. Project
Manageme
nt
Application
)

Consumer

13. Works
Mgmt

Consumer

Integration
Requirement
be facilitated via. MeeSeva
portal.
The PMO shall
ensure the availability of
MeeSeva++ vendor for
facilitating the integration
of
the
same
in
the
MeeSeva++ Portal
This is an application level
integration
rather
than
service integration. MeeKosam shall be used to
address
various
stakeholder grievances of
Temple Staff and Pilgrims.
This is a user level service.
This shall be used for direct
inquiry
or
addressing
grievances
of
Pilgrims,
Visitors etc., by Call Centre
staff.
This is an application level
integration.
The
Department
staff
shall
leverage this e-Pathakam
for defining the various
schemes
pertaining
to
Temples and manage the
same.
This is an application level
integration.
e-Pragati
Project Management shall
be used for planning,
monitoring and tracking
the
projects
executing
under the department. This
shall be used by PMU of ePragati and the scope of
the SI is to share or coordinate with the same for
Project plans and status.
This is an application level
integration. This is used for
planning, monitoring and
tracking the construction
and all engineering works
under the department.

Module / Sub
Module
Traceability

1. Complaint
Management

1. Call Centre

1. Asset & Fund


Mgmt

NA

e-Pragati Requirements Specification Document Temple Management System Page 122 of


216

Sl.
No.

Application

14. CFMS (eNidhi )

15.

HRMS

16. Payment
Gateway

17. SMS
Gateway

18. Email
Gateway

Temple
Applicati
on Role

Consumer

Consumer

Consumer

Consumer

Consumer

Integration
Requirement
This is an application level
integration.
The
Department
staff
shall
leverage
this
CFMS
application for managing
the finance and accounted
related functionality.
This is an application level
integration. This will be
leveraged
for
Payroll,
Transfer
and
Leave
functionality.
This is an integration
platform.
The
payment
gateway (credit card/debit
card/net
banking/mobile
wallet pertaining to ePragati system needs to be
used wherever applicable
in all applications for
payments,
The
Department
shall
facilitate the SI with the
Payment Gateway.
This is an integration
platform.
The
Email
gateway pertaining to ePragati system needs to be
used wherever applicable
in all applications for
sending
SMS
and
notifications
to
the
registered Pilgrims and
who have subscribed for
Alerts.
The Department shall
facilitate the SI with the
SMS Gateway.
This is an integration
platform.
The
Email
gateway pertaining to ePragati system needs to be
used wherever applicable
in all applications for
sending
emails.
The
Department shall facilitate
the SI with the Email

Module / Sub
Module
Traceability
2. Finance
and
Accounting

1. Human
Resource
Management
1. e-Payment
module

All Modules / Sub


Modules
wherever
applicable. (Seva
and
Darshan
Module)

All Modules / Sub


Modules
wherever
applicable. (Seva
and
Darshan
Module)

e-Pragati Requirements Specification Document Temple Management System Page 123 of


216

Sl.
No.

Application

Temple
Applicati
on Role

Integration
Requirement

Module / Sub
Module
Traceability

Gateway.
TABLE

34: INTRA - PACKAGE

APPLICATION REQUIREMENTS

2. Integration with external Apps [hosted on APP Store]


The SI shall provide the available API with respect to TMS applications to get
published in APP Store and further use of open mobile apps developer for citizen
betterment. For external application integration there should be provision of
seeking departmental application owner approval and later get published in AP P
Store for citizen uses. APP Store will be available part of e-Pragati Core Pkg.
All API based integration shall use the e-Pragati security mechanism to pull and
push the required data. There should be a unified API Security layer / platform
through which all the e-Pragati APIs can be exposed / consumed, where global
security policies can be applied.

FIGURE

14: E-PRAGATI

INTEGRATION WITH EXTERNAL APPS

e-Pragati Requirements Specification Document Temple Management System Page 124 of


216

ANNEXURE 2 - EXISTING TEMPLE MANAGEMENT SYSTEM


APPLICATIONS
2a. Existing Applications Technical Details
Each of the applications are classified into 3 broad categories after evaluating them
based on 15 parameters (technical standards) and classification criteria. The
existing service provider retains the source code. The categories, their description
and classification criteria are defined in below Table 35.
Type

Description

Category
A

Application retained as it is or
with minor modifications

Category
B
Category
C

Criteria

Application meets following


Web Service can be enabled
with minimum efforts
Business Process Re-engineered
already
Meet
target
functional
requirements
No replacement by other/
COTS/ Common application
Application retained with major Applications
which
need
modifications [requires changes functionality upgrade or would
in functionality, architecture and need Integration of functionalities.
standards]
Applications cannot be retained Application meets following
due to low volume and non- Can be replaced by Group,
standard development or there
Common or Cross cutting
are existing application (COTS or
applications
custom)
with
better Can be replaced by COTS
functionalities.
application
TABLE

35:

APPLICATION CATEGORIES

The below applications exists as part of Temple Management System:


Sl.
No.
1.
2.
3.
4.
5.

Application Name

Category

Online Financial Accounting System


E-Dispatch System
Employees Database System
Demand Collection Fund
MeeSeva

Category
Category
Category
Category
Category

TABLE

36: EXISTING A PPLICATIONS S TATUS

C
C
C
C
A
IN

System
Integrator
NIC
In house Team
In house Team
In house Team
APOnline
TMS

e-Pragati Requirements Specification Document Temple Management System Page 125 of


216

Existing Application functional details:


Application Name
:
MeeSeva
Functionalities
:
Providing all temple related citizen services such as
Sevas and Accommodation through MeeSeva kiosk centres for
all major temples in
the state and payments are collected
at MeeSeva Kiosk centres
Current Technology Stack
:
Language
:
.net
Database
:
Sql Server
Deployment Site
:
APSDC
Current Integrations
:
Aadhaar and Banks
System Integrator
:
APOnline
*Note:
Only Category C applications need to be migrated.
SI is responsible for evaluating data size and migration.

e-Pragati Requirements Specification Document Temple Management System Page 126 of


216

2b. Existing Temples Online Services Status:

Sl.
No.
1.
2.
3.

4.

7.

9.

11.

District
Name

Name of
Mutt/Trust/Tem
ples

Head Office

Endowments
Department

Srikakulam

DC/AC Office

Vizianagara
m

DC/AC Office

Visakhapatn
am

East
Godavari

West
Godavari

Krishna

14. Guntur

DC/AC Office
Sri Varaha
Lakshminarasim
ha Swamy
Devesthanam
Sri Kanaka
Mahalaxmi
Ammavari
Temples,
Burujupet
DC/AC Office
Sri Veera
Venkata
Satyanarayana
Swamy
Devesthanam,
Annavaram
DC/AC Office
Sri
Venkateswara
Swamy
Devasthanam
Dwaraka
Tirumala
DC/AC Office
Sri Durga
Malleswara
Swamy
Devesthanam
Sri
Tirupathamma
Ammavari
Devasthanam,
Penuganchiprolu
DC/AC Office

Services provided (as M- Manual, OOnline)


Darshan Sev Accommoda Donati
am
a
tion
on
M
O
M O
M
O
M O
NA
NA
NA
NA

Y N

Y N

Y
NA

N Y

N
NA

Y N

Y
NA

N Y

Y N

Y
NA

e-Pragati Requirements Specification Document Temple Management System Page 127 of


216

Sl.
No.

15.
16.
17.

18.

20.

22.

Name of
Mutt/Trust/Tem
ples

District
Name

Nellore

DC/AC Office

Prakasam

DC/AC Office

Kadapa

DC/AC Office

Kurnool

Ananthapur

Chittoor

TABLE

DC/AC Office
Sri
Bhramaramba
Mallikarjuna
Swamy
Devasthanam,
Srisailam
DC/AC Office
Sri Nettikanti
Anjaneya Swamy
Devasthanam,
Kasapuram
DC/AC Office
Sri
Kalahastheeswar
a Swamy
Devasthanam ,
Srikalahasthi
Sri Varasiddi
Vinayaka Swamy
Devasthanam,
Kanipakam

37:

Services provided (as M- Manual, OOnline)


Darshan Sev Accommoda Donati
am
a
tion
on
M
O
M O
M
O
M O
NA
NA
NA
NA

N Y

N
NA

Y N

Y
NA

Y N

Y N

EXISTING SERVICES STATUS IN TEMPLES / INSTITUTIONS

NA - Not Applicable
Y Yes (Available)
N No (Not Available)
Table: Existing Online Services status in Temples/Institutions

e-Pragati Requirements Specification Document Temple Management System Page 128 of


216

ANNEXURE 3 - TO-BE PROCESSES RECOMMENDED FOR


SELECTED FUNCTIONS OF TMS (INDICATIVE PROCESS REENGINEERING)
To simplify and streamline the service delivery in the Temple Management System,
rationalisation of services has been done adopting the principles of BPR. The service
offerings have been clubbed together and a generic process for these has been
drawn where responsibility for receipt of requests/applications, processing of the
applications, and approval/rejection of applications has been fixed separately for
each service offering.
Based on the BPR framework, improved TO-BE processes have been designed for
these rationalised services. The TO-BE endowment processes are discussed by
covering process description, responsibility matrix, service levels and change
requirements. These indicative TO-BE processes rationalises the service requests
and detail out the optimum way by which the service request will be processed and
finally delivered to the service requester.

Process 1: Calculation of Assessable Income:


1.1

As-Is Assessment of Assessable Income:

e-Pragati Requirements Specification Document Temple Management System Page 129 of


216

FIGURE

1.2

15:

AS - IS ASSESSMENT OF ASSESSABLE INCOME

To-Be Assessment of Assessable Income:

e-Pragati Requirements Specification Document Temple Management System Page 130 of


216

FIGURE

1.3

16:

TO - BE ASSESSMENT OF ASSESSABLE INCOME

Process Changes:

The following are the proposed changes for Assessment of seed supply and demand
process:
1. During the Income and Expenditure assessment preparation time itself, the
assessment amount should be captured by the TMS and the user should be
able to send assessment directly to Assistant Commissioner /Commissioner.
This eliminates multiple steps of verification and assessment multiple times.
2. Department should verify through TMS and the updated information,
approval/modification should be communicated using the TMS to the
concerned users.
3. After conformation on budget the admins of Temples pay funds to various
schemes in a single approval .The amount shall be transferred to different
heads of sections
Available fund at various schemes should able to monitor by Commissioner for
monitoring of various schemes and approval of beneficiary under schemes

1.4

Benefits to System:

e-Pragati Requirements Specification Document Temple Management System Page 131 of


216

Sl.
No.
1.

Benefits
to
System
Complete Automation of Fund Management

2.

Preparation budget online.

3.

Proper guidelines for utilisation of funds.

4.

MIS reports to all levels for utilisation of funds.

5.

Dynamic details of funds utilisation and funds status

6.

Integration with bankers for online payments

7.

Data analytics for preparation budget, assessment of fund and allotment of


fund based on the previous years allotment
TABLE

1.5
Sl.
No.
1.

2
3
4

38:

ASSESSABLE INCOME BENEFITS TO SYSTEM

Process Description and Responsibility:


Activity
a. Online Preparation of Budget by using
business recommendation provided by
system
b. Submit the budget to AC/DC
a. Requests and receives requirements
from the temples for providing for CGF
b. Verifies the budget and forward it to the
Government
a. Verifies the budget and generate the CGF
amount automatically by using the defined
system
b. Forwards to committee for approvals
a. Verifies the budget estimation and
assessment of CGF
b. Identifies the temples for CGF based on
the system recommendations
Amount transferred to temples Online
TABLE

39:

Responsibi
lity
Admin of
Temples

Service
Level
Real-time

Admin of
Temples
AC/DC

Real-time

Commission
er

Real-time

Committee

Real-time

Commission
er

Real-time

2 Days

ASSESSABLE INCOME PROCESS DESCRIPTION AND RESPONSIBILITY

e-Pragati Requirements Specification Document Temple Management System Page 132 of


216

Process 2: Common Good Fund Management:

2.1

As-Is Assessment of Good Fund Management:

FIGURE

2.2

17:

AS - IS ASSESSMENT OF GOOD FUND MANAGEMENT

To-Be Assessment of Good Fund Management:

FIGURE

18:

TO - BE ASSESSMENT OF GOOD FUND MANAGEMENT

e-Pragati Requirements Specification Document Temple Management System Page 133 of


216

2.3 Benefits to System:


Sl.
No.

Complete Automation of Fund Management

Prepare budgets online.

Proper guidelines for utilisation of funds.

MIS reports to all levels for utilisation of funds.

Dynamic details of funds utilisation and funds status

Integration with bankers for online payments

Data analytics for preparation budget, assessment of fund and allotment of


fund based on the previous years allotment
TABLE

40: G OOD

FUND MANAGEMENT BENEFITS TO SYSTEM

2.4 Process Description and Responsibility:


Sl.
No.
1.

2
3
4

Activity
a. Preparation of budget Online by using
business recommendation provided by
system
b. Submits the budget to AC/DC
a. Requests and receive requirements from
the temples for providing the CGF
a. Verifies the budget and forward to
Government
a. Verifies the budget and generates the
CGF amount automatically by using defined
system
b. Forwards to committee for approvals
a. Verifies the budget estimation and
assessment of CGF
b. Identifies the temples for CGF based on
the system recommendations
a. Amount transferred to temples Online
TABLE

41: G OOD

Responsibi
lity
Admins of
Temples

Service
Level
Real-time

Admins of
Temples
AC/DC

Real-time

Commission
er

Real-time

Committee

Real-time

Commission
er

Real-time

2 Days

FUND MANAGEMENT PROCESS DESCRIPTION AND RESPONSIBILITY

e-Pragati Requirements Specification Document Temple Management System Page 134 of


216

e-Pragati Requirements Specification Document Temple Management System Page 135 of


216

Process 3: Accommodation Booking:


3.1

As-Is process for Accommodation Booking in Temples:

FIGURE

3.2

19:

AS - IS

PROCESS

OF

MANUAL

ACCOMMODATION

BOOKING

To-Be Process for Accommodation Booking in TMS:

e-Pragati Requirements Specification Document Temple Management System Page 136 of


216

FIGURE

3.3
Sl.
No.

20: TO-B E PROCESS

Sl.
No.
1.
2

BOOKING

IN

TMS

Benefits to System:

Complete automation of accommodation booking with web interface for


direct access to pilgrims
Real-time information on the accommodation availability
Restricts misuse of booking accommodation and enables real-time
consumption of accommodation facilities
MIS reports to all levels for utilisation and availability of accommodation,
including payment collections
TABLE

3.4

OF ACCOMMODATION

42: TMS A CCOMMODATION BOOKING

BENEFITS

Process Description and Responsibility:


Activity
a. The pilgrim logs into TMS with the User
ID and password.
a. The system displays the notifications /
alerts information based on the pilgrims
choice.
b. The pilgrim attends selects his choice of
accommodation and applies for the room
by using Payment Gateway / Net Banking
option.
c. The pilgrim confirm the room booking
and completes the transaction.
a. The pilgrim receives the intimation on
the allotment of accommodation by
Email/SMS.
TABLE

43: TMS A CCOMMODATION BOOKING

Responsibi
lity
Pilgrim

Service
Level
Real-time

Admins of
Temples

Real-time

Admins of
Temples

Real-time

PROCESS DESCRIPTION AND

RESPONSIBILITY

e-Pragati Requirements Specification Document Temple Management System Page 137 of


216

ANNEXURE 4 - FUNCTIONAL REQUIREMENTS OF COMMON


COMPONENTS OF E-PRAGATI CONSUMED BY TMS
Minimum requirements of Common Components of e-Pragati consumed by Temple
Management System
Functional Requirements that shall be developed and converge into ePragati Components for Single-Sign-On (Tier-II of TM Package
Application Architecture)
Component Name : Profile Management
Component Functionality: Profile Management enables registration of
different categories/ groups of stakeholders of e-Pragati as indicated in
the table below and enables their access to the various services offered
across e-Pragati by facilitating user management, identity & access
management and password management. It provides the SSO
functionality. It is based on LDAP protocol.
Sub-Component: User Profile Management
Provision for the users of Temple Management System to register with
one's People Hub ID or the APUID in the absence of Aadhaar ID. SI
should generate Unique ID for the TM stakeholders keeping in view the
1
CLGS, Land hub, People hub which will be made available during the
due course of time. SI has to map the IDs generated for the People hub,
Land hub. SRDH data should be considered. Refer to Annexure 1 for
more integration requirements.
The indicative list of users for the Temple Management System are the
following:
1. Citizens/Pilgrims
2. Patashala students
3. Patashala Faculty
2
4. Departmental Staff
5. Trustees
6. Staff of Temples
7. Vendors
8. MeeSeva operators (behalf of users based on permissions)
9. Others, if any
a)
Pre-populate the demographic data of pilgrims/other users from
people hub while registering for the first time.
b)
For non-resident pilgrims (residing outside AP), the system shall
provide the option to key in permissible personal ID and other the
personal and professional details.
c)
The data correction request/new data w.r.t profile entries shall be
3
communicated to the native application holding the master data
(people hub for demographic/socioeconomic data) for updating as a
batch process.
d)
For further use of any transactions/services, the complete
registration information has to be stored in the temple management
systems databases of the respective departments.

e-Pragati Requirements Specification Document Temple Management System Page 138 of


216

Enable the user to enter the details such as personal, family, interest in
social cause, spiritual interest., which includes, but not limited to the
following:
a) Records and maintains a person's details, ID proofs.
b) Records and maintains a person's interest of engagement with
Endowments Department.
c) Records and maintains a person's visits to the temples.
d) Records and maintains person's donations and contributions.
Ability to retrieve the following information of pilgrims from the Health
Department through the integration with e-Health application.
a)
Blood Group
b)
Identification Marks

Allow to capture the personal communication attributes:


a) Mobile Number
b) Email ID
c) Emergency Contact Details

Allow to verify the communication attributes:


a) Mobile number through OTP
b) Email id by sending an activation email
Sub-Component: Institutional Profile Management

The indicative list of institutions under Temple Management System are


the following:
1. Temples
2. Mutts
3. Peetams
4. Dharmadayams
5. Patashala
6. Businesses
7. NGOs
8. Others, if any
a) The institute administrator logs in with his/her registered User ID
and password and selects the option to register the institution.
b) Pre-populate the data of institutions/businesses/agencies., from
entity hub while registering for the first time.

c) For establishments whose data is not readily available for use, the
system shall provide the option to key in establishment details.
d) The data correction request/new data w.r.t profile entries shall be
communicated to the native application holding the master data (entity
hub for establishment related data) for updating as a batch process.
e)
For further use of any transactions/services, the complete
registration information has to be stored in the temple management
systems databases of the respective departments.

e-Pragati Requirements Specification Document Temple Management System Page 139 of


216

4
5

Provision to capture the following information (if its not readily


available in entity hub):
- Pilgrim Name
- Pilgrim location (state in India)
- Contact e-mail ID
- Contact Address
- Contact telephone
- User Name
- Password
- Serial Number of Govt. ID that would be used for verification
Sub-Component: Identity & Access Management
Create information about users, groups, roles and permissions in order
to allow other applications to make use of common and harmonised
authentication, authorisation, accounting, user management and
provisioning services. The system shall allow the system administrator
to maintain a list of roles and assign, alter or revoke privileges to each
one of them.
Provide single point of administration, consolidated user data storage
and single-sign-on. The system should allow the system administrator
to maintain a list of privileges and assign, alter or revoke rights that
may be view, add/create, edit/alter/update every user interface. SSO is
applicable to all users. The SI shall develop a separate authentication
mechanism for TM Package that will allow the users to access all the
services through a single, active login session. This will later be
mapped to and integrated with e-Pragati Core Package SSO that uses
People Hub. The integration /mapping with the Core Package SSO is the
responsibility of the SI.
Provision for the user to log into the Temple Management System or
any of its components and the common applications and components
of e-Pragati, using his/her User ID and Password, subject to the access
privileges defined for each user. The SI shall develop a separate
authentication mechanism for TM Package that will allow the user to
access all the services through a single, active login session. This will
later be mapped to and integrated with e-Pragati Core Package SSO
that uses People Hub. The integration /mapping with the Core Package
SSO is the responsibility of the SI.
Provide the user to have the security access level that is appropriate to
the role in the system.
Allow the different stakeholders at various levels to log into the portal
and enable them to use functionalities such as user creation, user
access controls and user deletion.

Shall
a)
b)
c)

consist of the following Sub Modules:


Role Management
User Group Management
User Creation and Authentication

Provision for the authorised officers of the department to lock the user
accounts of specific users under specified exceptional conditions.

e-Pragati Requirements Specification Document Temple Management System Page 140 of


216

8
9
10
11

2
3
4
5

Display the list of users and allow each user to be assigned roles,
privileges as well as alter or revoke them.
On successful login into the system, the user shall be displayed the
Pages, Features and Data that the user has the permission to access.
Provision for Logging off from the application accessed and termination
of the session.
Provision to control the user access in environments such as BYOD and
Cloud. Role based access is required for internal as well as external
users.
Sub-Component: Password Management
Provide facility so that the passwords should consist of a minimum of 6
alphanumeric characters and one numeric and one special characters
(no common names or phrases) the actual combination and minimum
and maximum lengths will be site configurable.
Passwords should be changed every 90 days (or other period).The
systems shall enforce password change with an automatic expiration
and prevent repeated or reused passwords.
Provide facility so that; on allocation for the first time as well as reset of
password by the system administrator for lost passwords, the user will
be forced to change the password.
Provide facility so that passwords must be stored in encrypted forms by
the system and these cannot be retrieved by the system administrator
who may only reset the password.
Provide facility so that passwords should be kept private i.e., not
shared, coded into programs, or written down.
Provide facility so that user accounts will be frozen after three failed
login attempts. All erroneous password entries will be recorded in an
audit log for later inspection and action, as necessary. Sessions will be
suspended after 15 minutes (or other specified period) of inactivity and
require the password to be re-entered.
If any user logs in to the system using one machine and then logs in to
the system using another machine, then the data that the user had
already entered will be automatically saved and the user will be logged
out of the system and asked to log in afresh. In the same system the
session time shall be configurable.
Facility of OTP authentication and credential verification should be
provided.
Component Name : Notifications & Alerts
Component Functionality: The notification services are provided on the
digital dashboard of each user whereas the alerts are delivered through
multiple channels. The calendaring ability helps to record dates and
details of sevas/pujas/Darshanam/ donation related events of the
pilgrims, staffs of temples and the other stakeholders involved.
Sub-Component: Notifications & Alerts
Facility to publish various notifications for all the stakeholders and for
general public based on user roles & privileges.

e-Pragati Requirements Specification Document Temple Management System Page 141 of


216

3
4

3
4
5

7
8
9

Facilitate the users to set custom made alerts based on a set of


parameters. For example, date of special seva or puja/ date of
darshanam / schemes. An automatic SMS / email should go to the
senior officials / staff involved in respective event.
Facilitate the users to set alerts w.r.t any functionality in the system
(inclusive of all modules) based on the parameters that drive the
service / process / function.
Alerts
should
be
in
form of
SMS/Email.
Provision
to
subscribe/unsubscribe vice versa for the users to receive alerts.
Sub-Component: Calendar Management
Provide the ability to record dates and details of seva/rituals/darshanam
related events to the stakeholders.
Provide a flexible calendaring facility by enabling the
department/agency to define all significant periods of time. Provide
digital dash board for each user, designed in accordance to the role
assigned to the user. The system should allow the user to personalise
dashboard menu option. Indicative dashboard items for various roles
are listed below:
Information for Temples
Seva
Darshanam
Accommodation
Event list
Communications
Any other notification, policy related.
Allow to automatically update the user/establishment calendar by
fetching and recording dates and details of seva/rituals/darshanam
related events announced by institutions, agencies, departments.
All the special pujas/ Sevas have to be recorded and updated in the
users calendar.
Allow
to
view
the
calendar
and
mark
any
appointments/notifications/alerts
Each user shall have a customised dashboard view on logging. Key
sections shall include:
Activities pending
Activities assigned
MIS
Email
SMS
Notifications
Link to allowable modules/activities for particular user.
Flexibility to toggle between graphical and tabular view and tile
different windows in the same interface.
Provide feature to change colour scheme, skin of screen, font and
language localisation.
Facility to publish various notifications for all the stakeholders and for
general public based on user roles & privileges.

e-Pragati Requirements Specification Document Temple Management System Page 142 of


216

10

11
12

1
2
3
4
5

1
2
3
4
5
6

Facilitate the users to set custom made alerts based on a set of


parameters. For example, when the due date of the proposals /
schemes are nearing an automatic SMS / email should go to the senior
officials / staff involved.
Facilitate the users to set alerts w.r.t any functionality in the system
(inclusive of all modules) based on the parameters that drive the
service / process / function.
Alerts
should
be
in
form of
SMS/Email.
Provision
to
subscribe/unsubscribe vice versa for the users to receive alerts.
Component Name : Search
Component Functionality: The search functionality gives basic search
and advanced search options to the stakeholders based on their access
privileges. The users shall be able to search based on metadata, for
text and multimedia contents, for admissions, courses, examinations,
scholarships, loans and schemes, for profiles not only in the Temple
Management System but also the contents available in the e-Pragati
ecosystem.
Sub-Component: Simple Search
Provide advanced search facilities to view temples, institutions, mutts,
endowments schemes, veda scholarships with search parameters.
Enable stakeholders to search for document repositories by using key
words and multiple parameters.
Enable stakeholders to search the multimedia contents as well.
Based on access privileges the stakeholders shall be able to search
others users profiles using predefined search strings.
Provide automatic alerts based on the predefined search criteria
regarding seva/rituals/darshanam.
Sub-Component: Advanced Search
Provide advanced search facilities using metadata and content related
tags inclusive of social media. Allow explicit use of Boolean operators
AND, OR, NOT while searching.
Shall be able to search not only in the Temple Management System but
also the contents available in the e-Pragati ecosystem
Provision to save search strings for future usage.
Provision to set automatic alerts by SMS/Email with the dynamic update
of the content/data.
Provision to launch search over the internet as well.
Provision to search the information to the individual needs and
conditions of the stakeholders.SI can propose a suitable solution based
on requirements.

e-Pragati Requirements Specification Document Temple Management System Page 143 of


216

Component Name : System Administration


Component Functionality: It handles the end to end system
administration, policies management. It helps to manage all modules of
the application with suitable user privileges and security layers. This
module
shall
define
the
multi
module
/multi-site/multi
organisational/multi user application requirements with adequate
parameters for the installation of the application at heterogeneous
premises while perusing multiple business models.
Sub-Component: System Administration
Allow the creation of multiple users (normal users, power users, super
users.) with unique User IDs and passwords.

The above users should have different power and access privileges as
per the requirements of system stakeholders.

The master system administrator should be able to create junior


system administers for each of the modules with sufficient privileges.

The admin should be able to create the organogram of the entity


involved and create users and policies accordingly.

5
6
7
8
9
10
11
12
13

14

15
16

Facilitate admin screens / front end screens for creating contexts,


policies and business rules by the administrator at each module.
Maintain the audit trail of all activities in the system, which is
accessible and printable on demand.
Facilitate authorised Department Officials to push notifications /
messages to the dashboards of all users anytime.
Allow to automatically send all the latest updates as emails and SMS
notifications to the users registered with the Temple Management
System.
Provision for email marketing on the schemes/programs of the Temple
Management System to the registered users.
Provision to send the monthly newsletters on the latest and upgraded
schemes/programs information to the registered users of the Temple
Management System.
Provision to take the surveys on the Endowments Sector
schemes/programs from all the stakeholders.
Provision for all the stakeholders to receive the notifications on the
latest and updated schemes/programs of Temple Management System.
Allow to populate the screen functionality as per the user profile and
need basis, by applying sufficient contexts, policies and business rules.
Facilitate the Temple Management System platform/portal that can be
viewed directly on the well-known browsers like Google Chrome,
Firefox, Safari and Internet Explorer for all the standard and latest
versions.
Facilitate the UI that renders in personal computers, Tablets (Windows /
Android / iOS and above) and Smartphone (iOS, Android, Windows
Phone).
Facilitate integration with App Store which helps the stakeholders to
gain access on e-Temple mobile apps.

e-Pragati Requirements Specification Document Temple Management System Page 144 of


216

17

Provide the general common pages like About Us, Privacy Policy, Terms
& Conditions, FAQ, Contact Us, feedback.

18

Provide the basic features like Login, Logout, Forgot Password, Change
Password, Switch Language, My Profile.

19
20

21

22

23
24
25

26

27

28

Allow to communicate with unified channel access to the customer.


These channels may be USSD, IVR.
Allow to integrate with the Social Medias like Face Book, Twitter,
LinkedIn. Detailed requirements will be available in e-Pragati Citizen
Engagement Package RFP.
Allow to integrate and interoperate with various other external entities,
the ability of the system to easily and in a relative seamless manner
integrate with external entities (like SMS Gateway, Payment Gateway,
OTP, e-Sign Server.) and systems effectively with minimum to zero
impact on other services.
Allow to use the Authentication, Authorisation, Accounting & Access
Control factors (User ID & Password, Biometric (if required), and Digital
Signature) security mechanisms should be implemented to enable
secure login and authorised access to application information and
services. SI is responsible to conduct a field study and propose suitable
solution.
Validate the data input by the user where ever possible to prevent
unnecessary communication and server roundtrips.
Provision to integrate with Dial AP application for mobilisation,
counselling support.
Provision for Promotion, Marketing, Advertising, Brand building for
seva/puja programs in temples.
Support both the local language Telugu and English Languages. Even
the user can view and do the data entry in Telugu language. User
should have the provision to choose the language while logging into the
system. It uses the Unicode for capturing and storing the data. Search
engine should have Unicode support for Telugu & English language.
In the system wherever the process is critical, workflow system has
been incorporated so that the required accountability is built in this
system. COTS can be customised based on business rules and
workflows.
Provide the different options as per their user roles as different level of
users will be operating this system.

29

Enable the department employees to access


administration, HR, Finance, Program Management.

30

The services presented to the users should vary based on the category
of the users and the privileges defined for the users in the system.

31
32
33

information

on

Allow to integrate with all the applications whose functionality are


sought by various modules under the e-Pragati framework.
Provide the functionality/ API/ Web Services to fetch data from different
systems.
Provisions for plug-ins to connect with Office 365 or equivalent, Unplug
solutions for staffs of temples, Office Mix with sufficient provision of

e-Pragati Requirements Specification Document Temple Management System Page 145 of


216

APIs in requisite modules.


34

Adhere to Web Content Accessibility Guidelines (WCAG) 2.0 or latest


and the system shall be devoid of OWASP Top 10 vulnerabilities.

35

Adhere to the data privacy, protection and security protocols applicable


to the endowments systems globally.

e-Pragati Requirements Specification Document Temple Management System Page 146 of


216

ANNEXURE 5 - FUNCTIONAL REQUIREMENTS OF COMMON


MODULES AND SUB-MODULES OF TEMPLE MANAGEMENT
SYSTEM
Minimum requirements of Common Modules & Sub-modules of Temple Management
System
Functional Requirements of Common Modules & Sub-modules of Temple
Management System
Modul Module Name: Information on Temples
e
Module Code: TM01
Code / Module Functionality: The module shall facilitate information on
FR
temples such as history of temples, architecture details, nearest
Numbe tourism places. Anyone can access the information from anywhere
r
related to specific temples
TM010
Sub-Module: Information related to Temples
1
1

System module should provide brief about History of the Temples

- Construction of temples,
-Establishment history
Committee of Temples,
- Year of establishment/construction
System module should be able to do Classification of Institutes:

System should capture the List of Institutions

System should capture No. of Temples District wise, Zone wise as the
case may be.

TM0102

Sub-Module: History of Temples

System Should provide updated information about temples

System should provide information regarding the history, founder


information architectural details for the temples.

3
4
5

System should provide information on nearest places to temples and


provide distance between the places
System should provide updated information on transportation details
such as available buses details, train details , vehicle details of temples
and registered private vehicles
System should provide information on schedule wise transportation
details

System should provide information about temples offering services,


accommodation details and ritual details

System should provide information on gallery details , gallery


timings ,available items in gallery

System should provide updated contact details of each temples


management, Helpdesk counters and local contact details

e-Pragati Requirements Specification Document Temple Management System Page 147 of


216

System should provide information on seva timings and charges for


sevas and accommodation

10

System should provide information on number of pilgrims visiting to


the temples and performing sevas details

11

Department portal should provide information on Frequently asked


questions and answers

12

Department portal should support Content Management System (CMS)

13

Department portal should support for both languages :Telugu and


English
Department portal should be integrated with Dial.AP to provide
information and capture grievances
Department portal should support for Helpdesk related information
Calls received by Helpdesk should be updated in web portal for
department
System should provide route map for temples and other related
information about temples
System should provide information on kalyana mandapams available in
temples
System should publish magazines in web portal related to the
individual temple
System should provide information on temple specific guidelines on
rituals
System should provide information on location and other details for all
listed temples/institutions.
System should provide information through public displays at
temples/institution premises, media channels and bus stands/railway
stands
Provision to provide information through social media, news media and
electronic media of events performed by institution
Provision to provide regular updates through all media channels about
history of temples and other events/puja details

14
15
16
17
18
19
20
21
22
23
24
25
Modul
e
Code /
FR
Numbe
r

TM020
1
1

System should provide other department specific information


Module Name: Pilgrim Facing Service
Module Code: TM02
Module Functionality: The Pilgrims information is stored and verified in
this module and its access is regulated by the user access roles and
privileges. This modules facilitates the pilgrims to make online booking
of seva, Darshanam, accommodation, donation, transportation. It
captures and displays information on pilgrims as upcoming visit,
Darshanam timings. Using the search and alert functionalities the users
shall be able to fetch information.
Sub-Module: Pilgrim Information Management Module
System shall maintain pilgrim information such that there is no
duplication of records/data data and referential integrity of data is
maintained across integrated platform

e-Pragati Requirements Specification Document Temple Management System Page 148 of


216

2
3
4
5
6
7
8

10
11

12

13
14
TM020
2
1
2

System shall be scalable to allow processing and storage of biometric


information of pilgrims
System shall maintain time stamp and audit trail for all information
added / updated in the pilgrim profile
System shall allow users amongst the staff of Temples to search for
pilgrim information based on pilgrim ID and/or pilgrim name and
location.
System shall display list of search results with pilgrim profiles that
match criteria entered
System shall enable information from all other modules to be pulled
and displayed to the staff of the Temples. This will give them the
overview of all activities, attendance and other details of pilgrim
through a single 'Pilgrim Status' screen
System shall allow search facility where pilgrim IDs appear as links and
take user to Pilgrim Status screen on clicking a particular pilgrim ID
System shall allow staff of the Temples to attach content objects to any
of the transaction / interaction details. For example, pilgrim ID proof
could be scanned and attached whenever registration is being done.
System shall allow staff of the Temples to add service events such that
they are linked to pilgrim profile. An event shall include at least the
following: - Request for a particular service - Service Offered
(Attendance)
System shall interface with the other Integrated Service Platform
modules (Attendance Management Module, Accommodation
Management Module.) to allow tracking of pilgrim services provided.
System shall enable audit trail on the integrated platform such that all
notifications, attendance, complaints related to a particular pilgrim can
be viewed on a single screen along with time stamp
System shall enable identification of up to 10 family / group members
for every pilgrim. This shall be utilised by the other modules to enable
accommodation arrangements, Annadanam arrangements, bookings,
schedules and travel arrangements to be made for the entire group
together / in close proximity.
System shall provide the details of the profile of pilgrims in defined age
group categories, to assist in planning in Annadanam
System shall provide Search option for the pilgrim booking/
allotment. This shall also provide sorting option for the search criteria
Sub-Module: Pilgrim Verification
The system should provide details of tourist places to pilgrims which are
nearby to the temples.
System should also provide pilgrims with details of other nearby
temples.
System module should brief about History of the Temples. The history
should include the below:
Construction of temples,
Temples Committee,
Construction &

e-Pragati Requirements Specification Document Temple Management System Page 149 of


216

3
4
5
6
7
8
9
TM020
3
1
2
3
4
5

establishment history ,
Year establishment/construction
System shall update the services availed by a pilgrim (such as
Darshanam, Seva, Accommodation, Annadanam, Kalyankatta, Laddu
distribution,.), based on the unique Pilgrim ID and biometric verification
at each touch point
Ability to track the movement of pilgrims family members visiting
along with the pilgrim
The system shall capture pilgrims attendance in the activities opted by
pilgrim during booking
System shall provide interface with the other Pilgrim Service
application modules to allow tracking of internal services provided.
The system shall provide the information to the security in case of any
suspicion for the pilgrim
The system shall track the exact inflow and outflow of pilgrim at each
touch point by capturing the entry, exit and details of movement of
pilgrims
System shall provide Search option for the pilgrim booking/
allotment. This shall also provide sorting option for the search criteria
Sub-Module: Queue Management Module with Predictive
Analytics
The system shall facilitate pilgrim queue management at Pilgrim
Helpdesk counters, outside Annadanam complex, VQC. It should also
provide a system for organised entry and exit of pilgrims.
System shall provide options for pilgrim management and facilitate
with the schedule for gate openings at critical nodes
System shall be configured on the basis of departments business rule
for crowd management. The business rules or scenario would be
different for specific days or month and the software developed should
be able to adapt automatically
System shall provide automatic corrective/preventive measures based
on real time information captured from various cameras
System shall provide clear instructions for identifying which gate/node
should be closed or opened with duration & other relevant details
System shall provide alerts during any emergency and shall respond
and detect the criticality based on calibrated benchmarks or threshold.
e.g. If at a particular node the packing density increases than a
calibrated benchmark then it should provide an alert message to
centralised control room

System shall measure packing density of pilgrims at various nodes

System shall configure itself based on peak or non-peak day

System shall integrate with


1) Communication device
2) Automate gates
3) Counting devices like Display boards, generates with Queue status
4) Automated voice response at various nodes
5) Alerts should be generated to the pilgrims based on their request
6) In case of huge crowd which is beyond the expectation of temples

e-Pragati Requirements Specification Document Temple Management System Page 150 of


216

10

11

management, the pilgrims should get alerts over SMS, Mic


announcements, Display boards.
System shall provide a logical view of information pertaining to queue
line in a simple & graphical manner. Information like pilgrim flow,
packing density at any nodes.
System shall present data using a variety of highly customizable
charts, including vertical and horizontal bar, pie, donut, sub grouped
pie, star and block charts, plots like scatter, line, area bubble, multiple
axis and overlay plots
Management Information System

12
13

14
15
16
17
18
19

20

21

System shall automatically generate reports of MIS, Dashboards in file


formats like HTML, PDF.
System shall provide an alert to decision making authority or
administrator in case of emergency or any unforeseen event. The
communication should be either through phone call/SMS/sending real
time footage
System shall provide routine information & essential statistics
regarding pilgrim inflow, average waiting time. to the Temple
management.
System shall provide real time footage of pilgrim movement at
different nodes to the Temple management
System shall compare the YoY / Day on Day/Month on Month
performance level or service delivery of pilgrim management. Data
generated should be either on the basis of pilgrim handled per hour,
pilgrim inflow rate.
System predict waiting time at each node based on statistics of pilgrim
inflow
System shall predict the probability/chances of disasters such as
stampede based on crowd concentration at each compartment
System shall analyse historical data and identify patterns to develop a
model to forecast pilgrim flow. System shall identify and forecast peak
hours and non-peak hours
System shall identify, train and validate models - Ability to sample or
select some of the data (training data), explore the training data
seeking patterns in it, which satisfy a pre-determined accuracy level.
Ability to test and refine the pattern on data kept aside (test data) and
obtain the result with a satisfying accuracy. In addition to the training
and test sets, ability to use a 'validation' set to estimate generalisation
error and see how well the model performs under conditions of actual
use
Ability to discover new patterns in the dataset (detect untrained
patterns) and identify defined patterns in the dataset (trained patterns)

22

Ability to integrate seamlessly with industry leading RDBMS

23

Ability to facilitate users to perform offline analysis on data extracted


from the database

TM020
4
1

Sub-Module: Token generation and scheduling


Ability for employees of the Temples to check the availability of quota

e-Pragati Requirements Specification Document Temple Management System Page 151 of


216

2
3
4
5
6
7

9
TM020
5
1

2
1
2
3
4
5
TM0206
1

for discretionary bookings - VIP quota, VVIP quota, Protocols,


Management staff of Temples,
System shall have an option of defining business rules for allocating
quota for a category.
List of seva bookings done by pilgrims through website and other
channels such as Pilgrim Helpdesk counters, DD. shall be available
with the Temple management for a comprehensive data/ view
System shall enable the Temple management to allocate seva under
different quotas
System shall enable transfer of quota from one category to other based
on the pre-defined business rules
Transfer of quota from one category to other shall be easy to track and
should be allowed based on adequate approvals from senior
management staff (such as HOD and JEO).
System shall maintain an audit trail, time stamp, details of signatory
transferring the quota, reasons for quota transfer and adequate
approvals for quota transfer
System shall enable interface between different Endowments
department, such as
- Accounts for reconciliation of amount deposited in banks,
- Temples for inventory estimates,
- Accommodation for Room booking
- VGO for Security check / verification at VQC entry
System shall provide Search option for the pilgrim booking/
allotment. This shall also provide sorting option for the search criteria
Sub-Module: Distribution module
The system shall display the following information at the Pilgrim
Helpdesk counters:
Cost of the ticket
No. of tickets a person can purchase
No. of laddus offered on the ticket
System shall automate details such as frequency of procurement of
different types of raw material, types of raw materials to be procured,
quantity to be procured and different departments such as transport,
marketing, involved for procurement
The system shall allow reconciliation of laddu and other prasadam
coupon distribution with total number of pilgrims visiting the temples
The system shall allow end of the day reconciliation with laddu
production, laddu sales and balance laddu remaining.
Procurement at distribution counters and sale of laddu
The system shall capture the details of all the transaction such as
indenting, invoicing, end of the day reconciliation of laddu distribution
with banks.
The system shall enable the reconciliation process of procuring silver
and gold coins and selling them through Pilgrim Helpdesk counters
Sub-Module: Video Surveillance / Analytics
The software shall operate in open architecture for integration with IP

e-Pragati Requirements Specification Document Temple Management System Page 152 of


216

cameras located at key nodes based on open standards.


2
3
4
5

7
8
9

10

11

12
13
14

Digital video surveillance control software shall display and manage


the entire surveillance system. It shall be capable of supporting variety
of devices such as cameras, video encoders, video decoders, PTZ
controller, NVR, NAS boxes/Raid backup device.
The system shall have inbuilt facility to store configuration of encoders
/ decoders
The system shall support flexible 1/2/4 Windows Split screen display
mode or scroll mode on the PC monitor or on preview monitor as per
site requirement.
The system shall control all cameras i.e. PTZ control, Iris control, auto /
manual focus, and colour balance of camera, Selection of presets,
Video tour selection.
The System shall generate reports of stored device configuration. The
control software is required to provide alarm and alarm log. The l og
generated should be printable and displayable using a device filter, a
device group filter and/or a time window.
The TMS shall have user access authority configurable on per device or
per device per group basis. The user shall have the facility to request
the access of any camera and can control the camera for a reservation
period. Control of camera is released after the reservation period.
The system shall provide User activity log (audit trail) with user id, time
stamp, and action performed,.
The administrator shall be able to add, edit & delete users with rights.
It shall be possible to view ability / rights of each user or the cameras
which can be viewed & controlled as per the permission assigned by
the administrator.
The users shall be allocated on a hierarchical basis as assigned by the
administrator. The higher priority person can take control of cameras,
which are already being controlled by a lower priority user. There
should be minimum 3 hierarchical levels of security for providing user
level log in.
System shall have recording modes viz. continuous, manual, or
programmed modes on date, time and camera-wise. All modes should
be disabled and enabled using scheduled configuration. It should also
be possible to search and replay the recorded images on date, time
and camera-wise. It should provide onscreen controls for remote
operation of PTZ cameras. It should have the facility for scheduled
recording. Different recording speeds (fps) and resolution for each
recording mode for each camera shall be possible.
System shall have the ability to track a specific object as it moves
through a detection region and/or crosses a virtual line
System shall have the ability to generate an alert when the direction of
movement and/or location of object meet user defined rules
System shall detect humans/objects moving in the wrong direction
from a predefined direction marked as a virtual line. For example, an
alert should be generated if a person tries to enter from the exit point
and vice versa

e-Pragati Requirements Specification Document Temple Management System Page 153 of


216

15
TM020
7

TM0208

2
3
4
5
6
7
8
9
10
11

System should generate an alert when an object moves in a defined


detection region for more than a defined period of time (loitering
detection)
Sub-Module: Public Display System
The system shall display information on public display for:
Waiting time
Menu
Nutritious value of the food
Batch timing
The system shall display information in the dining area:
List of donors
Number of tickets available for sevas/ accommodation
Missing persons details
Special pujas
Ticket prices
Queue details
Sub-Module: Tonsuring/Kalyankatta Module
Pilgrim shall have an option for online booking for Kalyankatta. A token
shall be issued to the pilgrims for the Kalyankatta booking. Following
details shall be furnished by pilgrim for availing Kalyankatta service:
Name of the pilgrim
Unique Pilgrim ID
Age
Cost of ticket
System shall generate reference / booking number for each of the
pilgrim requiring Kalyankatta service.
Token shall be allocated to the pilgrim based on the package reference
number
System shall enable Dynamic token allocation for the tonsurer , based
on the buzzer system
Ability to track the number of tonsuring done by a tonsurer
Temple Management System shall automatically send the SMS to
pilgrims with the token details for Kalyankatta
Details regarding the attendance for the tonsurers and the shift timings
shall be maintained on the intranet / Temple Management System
portal for access to the Temple Management for shift management and
allocation of token to pilgrims
Updates regarding the current waiting time at Kalyankatta shall be
available at Pilgrim Helpdesk counters and public display systems
Pilgrim shall be updated about the time of reporting at Kalyankatta for
availing the service.
An option for the feedback regarding the quality of services provided
by Temple Management System for Kalyankatta shall be accessible to
citizen on the website, to track the performance of the tonsurers.
Option for providing feedback for the quality of tonsuring service
provided to pilgrim, shall be made available through SMS

e-Pragati Requirements Specification Document Temple Management System Page 154 of


216

12

System shall provide Search option for the pilgrim booking/


allotment. This shall also provide sorting option for the search criteria

13

System shall enable Variable tariff model for payment to tonsurers

14
15

System shall enable tab for maximum number of tonsuring done by a


tonsurer
System shall allow minimum time between two buzzers by same
tonsurer

16

System shall link shift management with the buzzer

17

System shall be linked with the rate master and shall enable approval
for the workflow management

18

System shall enable token reconciliation with the cash collections

19

System shall maintain Wage rate master which shall be linked with
the employee wise daily Wage structure

TM020
9
1

3
4
5
6
7
8
9
10
11

12

Sub-Module: Complaint Management


Pilgrim shall have an access to SMS based Query resolution, based on
the unique reference number for booking and Unique Pilgrim ID
System shall enable resolution of pilgrim queries at information kiosk,
through Call centre, SMS and Pilgrim Helpdesk counters. Pilgrim shall
provide details such as:
Unique pilgrim ID
Reference number for booking
Date of check In and
Date for Check out
System shall record a complaint registered by a pilgrim and generate
the acknowledgement with a complaint number
System shall allow the pilgrim to add, delete and modify the complaint
System shall generate the status of complaint with reference to
complaint number, based on the complaint number
System shall trigger the SMS or mail to communicate the final response
for a complaint to the pilgrim
Ability to classify and document the complaint in complaint repository,
under a defined category
Ability to transfer the complaint to the relevant departments based on
the classification for further action
System shall maintain Complaint Portfolio by documenting (/
attaching a scanned copy.), that may be required to support the
complaint registered by the pilgrim
System shall allow the departments to update the status of complaint
Ability to capture the response from the relevant departments in the
stipulated time period
System shall maintain and manage complaint portfolio by:
Recording the support documents for a complaint
Grouping complaints of similar nature
The solution set put in place by organisation to manage one or
more complaints Portfolios

e-Pragati Requirements Specification Document Temple Management System Page 155 of


216

13
14
15
16
17
18

System shall maintain the life cycle of the complaint till its closure
Ability to manage and deal with all the aspects of complaints such as
solutions / actions taken for the complaint resolution, departments
involved and action taken by each department to resolve the complaint
System shall take innovative measures in handling complaint
successfully in least amount of time.
Ability to generate the report of corrective action taken by the
department to minimise a particular set of complaint.
System shall define the steps / rules that are automatically triggered to
resolve an irrelevant complaint or a frequently occurred complaint
Ability to take all the suitable steps and measures to ensure
transparent handling of the complaint

19

System shall maintain time stamp and audit trail of the complaint

20

System shall provide Search option for the pilgrim booking/


allotment. This shall also provide sorting option for the search criteria

TM021
0

Sub-Module: Transport Management Module


Ability to display following information to one among the nearest best
connected place:
Current position of the scheduled arrival/ departure of available
mode of conveyance
Timing of available modes of conveyance
Frequency of available modes of conveyance
Pick up & drop points
Ability to display following details at public places such as auto stand,
bus stand, railway station:
Local temples covered in the trip
Trip charges
Timing of available modes of conveyance
Pick up & drop point
Time required for the trip

Facility to book conveyance at the time booking seva tickets

Facility to cancel the tickets

e-Pragati Requirements Specification Document Temple Management System Page 156 of


216

Minimum Unique Requirements of Temple Management System for handling


integrated aspects
Module
Code /
FR
Numbe
r

TM030
1

Module Name: Online Services


Module Code: TM03
Module Functionality: The Pilgrims information is stored and verified in
this module and its access is regulated by the user access roles and
privileges. This modules facilitates the pilgrims to make online booking
of seva, Darshanam, accommodation, donation, transportation. It
captures and displays information on pilgrims as upcoming visit,
Darshanam timings. Using the search and alert functionalities the users
shall be able to fetch information.
Sub-Module: Pilgrim registration Module

System should populate the following details of the respective pilgrim


as per the record captured under e-Pragati:
- Pilgrim Name
- Pilgrim location (state in India)
- Contact e-mail ID
- Contact Address
- Contact telephone
- User Name
- Password
- Serial Number of Govt. ID that would be used for verification

System must display unique pilgrim ID for each pilgrim registered

3
4
5
6
7
8
9
10
TM030
2
1

System shall mark online registration details as 'provisional' details and


allow for Temple Management System users to verify the identity of
pilgrim, capture photograph, biometric details (finger prints) and then
confirm identity of the system
System shall enable provisional profiles (that have not confirmed within
stipulated period) to be automatically deleted
System shall allow the staff of the Temples to mark pilgrim profiles as
'On Hold' , for cases where pilgrim has arrived but valid documentation
is yet to be produced for verification of identity of pilgrim
System shall allow pilgrims to be authenticated (by using User name
and Password) from website home page / information kiosk, before
functionality of the functional modules is made available
System shall interface with the biometric devices to capture the
fingerprint data for all pilgrims
System shall generate a Unique Pilgrim ID for each pilgrim who is
registered and verified in the system
System shall provide Search option for the pilgrim booking/ allotment.
This shall also provide sorting option for the search criteria
System shall allow Modify option for the bookings done by the pilgrim
Sub-Module: Seva and Darshanam Module
Pilgrim shall get an update for the availability of seva / Darshanam in
(an upcoming) month(s) / or on a particular day / time from Call centre,
SMS, Pilgrim Helpdesk Counters and Website.

e-Pragati Requirements Specification Document Temple Management System Page 157 of


216

2
3
4
5
6
7
8

10

11
12
13
14

15

16

17

System shall enable pilgrim to book a seva / Darshanam online


System shall automatically generate unique reference number for the
'Seva bookings for processing the request.
System shall enable pilgrim to check, if the request for Seva bookings
shared by him is accepted or rejected
System shall automatically update pilgrim for the Seva booking request
- confirmed, rejected along with a unique reference number.
System shall allow the cash transaction at Pilgrim Helpdesk counter
for confirmed seva booking. A confirmation slip / ticket shall be
generated for the seva booking to provide access to the pilgrim
System shall enable automatic SMS delivery, Online status update and
status update through Call centre for the Seva / Darshanam booking
System shall be able to generate a confirmation slip for the seva /
Darshanam booking done by pilgrim
There should be a defined interval for booking a seva for a particular
date / day for a quota. Such as advance booking for the seva shall start
three months in advance, while current booking shall start 24 hours
prior to date for performing the seva. Option for booking a seva beyond
a particular time limit (such as Half hour prior to start of seva) shall
be not be allowed
Information regarding the upper time limit for booking a seva shall be
available with the call centre to resolve to the pilgrim's query for
booking a seva
Ability for pilgrims to book a Darshanam ticket based on the unique
pilgrim ID. Slot may be assigned to the pilgrim for Darshanam upon
verification at Pilgrim Helpdesk counters (if pilgrim is not registered
with Temple Management System)
Ability for pilgrims to connect to the people hub database for
completing verification process while booking a seva online
Ability to generate a confirmation slip to the pilgrims, based on their
unique booking number / reference number
Pilgrims shall be verified, based on valid ID proofs, at Pilgrim Helpdesk
counters and seva / Darshanam tickets shall be given to the pilgrim
after capturing the biometric details
Details regarding the seva (such as following) shall be shared with the
pilgrims on website, through SMS and through Call centre:
* Privileges attached to seva
* Time and location for the seva
* Reporting time and place for seva
Other specifications / advisory by the institution as per the respective
traditions of the temples.
Ability for pilgrims to get information regarding their queries for seva /
Darshanam Booking / timing from
a)
Call centre
b) Information kiosk
c)
SMS mode
d) Pilgrim Helpdesk counters
Ability to share information regarding the release of quota with the
Pilgrims through

e-Pragati Requirements Specification Document Temple Management System Page 158 of


216

18

19
20
21
TM030
3

a)
Call centre
b) Information kiosk
c)
SMS mode
d) Pilgrim Helpdesk counters
System shall enable pilgrim to access the option for accommodation
booking upon seva confirmation, for all the seva bookings. This shall be
linked with other modules such as Accommodation, Kalyankatta, so that
pilgrim shall have an option for availing a package of services under
single reference number.
For the sevas, pilgrims with privilege of free accommodation, shall have
access to the accommodation module for booking the rooms,
categorised for booking along with seva.
System shall enable pilgrims to access the details of the privileges
provided under different sevas
System shall provide Search option for the pilgrim booking/ allotment.
This shall also provide sorting option for the search criteria
Sub-Module: Hundi Management

Should support for information on all types of collections in hundi

Provide information on location of hundis in temples and number of


hundis in temples/institution

Timely completion of counting Hundi collections to deposit in the bank

Daily recording for the Hundi collection and counting shall be updated
with the Finance and Accounts

5
6
7
TM030
4

2
3

Identify and record types of collections in Hundi


Provide information to pilgrims proceeding to Hundi queue line to offer
their donations and move towards next available counter in case the
selected counter is already full.
This website also accepts the donations. Provision to support for eHundi
Sub-Module: Accommodation module
Details regarding the room types, tariffs, location, amenities available
in the room shall be available through following modes, to enable easy
decision making for pilgrim while selecting the room for booking:
a)
information kiosks,
b) Pilgrim Helpdesk counters,
c)
Call centre
d) SMS
System shall enable real time update for the information on room
availability under particular category on web site, Call centre, Pilgrim
Helpdesk counters and Information kiosk to enable room booking for
the pilgrim
System shall allow pilgrims to book a room upon availability. Following
details shall be provided by pilgrim to book a room:
Unique pilgrim ID
Date for booking

e-Pragati Requirements Specification Document Temple Management System Page 159 of


216

4
5
6
7
8
9
10

11

12

13

14

Number of people accompanying


Details of the people accompanying - Name, Age, Gender,
Relationship
System shall automatically generate unique reference number for the
bookings done by the pilgrim, for future reference during the trip. The
unique reference number shall be linked with the Pilgrim ID
Pilgrim shall have access to call centre to know about status of the
booking or booking reference number.
Payment gateway should be provided for the payment for room booking
done in advance. This shall be linked with the ePayment module
System shall send the confirmation regarding the payment done by
pilgrim for advance room booking
Call centre shall provide an update to the pilgrim for the status of
online payment and the advance booking
System shall generate a confirmation slip with unique reference
number with room booking details and Pilgrim ID, for the online
bookings or bookings done at Pilgrim Helpdesk counters
SMS based confirmation for the room booking, along with the unique
reference number for the booking shall be sent to the pilgrim for easy
reference in future
Interface shall be established with the seva bookings, providing access
to privileged pilgrims (Privileges for donors, as mentioned in Finance
and Accounts module) for providing accommodation along with seva
bookings. Option shall be available for the pilgrim to book for
accommodation along with seva bookings / cancellation /
postponement / waitlist. Room bookings as a privilege along with seva
shall be confirmed only upon confirmation of seva.
Room bookings as a privilege along with seva (for Donors, as
mentioned in Donation and Cash module) shall be confirmed only upon
confirmation of seva. Same shall be updated on the website, Call centre
and Pilgrim Helpdesk counters.
System shall enable Pilgrim Helpdesk counters for room bookings.
Following pilgrim details shall be captured:
Unique pilgrim ID
Date for booking
Number of people accompanying
Details of the people accompanying - Name, Age, Gender,
Relationship
Contact number and Address (If changed after pilgrim
registration)
System shall allow the booking for the guest house/ cottage "Donors".
Donor ID / Unique number shall be the log-In ID for the pilgrim.
Following details shall be provided by the pilgrim for room booking
under "Donor bookings":
Pilgrim Unique ID / Donor card reference number
Date of visit
Number of pilgrim accompanying
Total days for stay

e-Pragati Requirements Specification Document Temple Management System Page 160 of


216

15
16
17
18
19
20
21
22
23
24
25

26
27
28
TM030
5

2
3

System shall enable the room allotment for Donors guest houses based
on the advance bookings done by donors
System shall enable pilgrims to check, if the room booking request
raised by him/her is accepted or rejected
System shall automatically notify pilgrims (through SMS, email) for the
status of room booking request
Confirmation status shall be made available to the pilgrim through call
centre / Information kiosks / Pilgrim Helpdesk counters / SMS
Rooms shall be allotted to pilgrims after verifying the authenticity of the
pilgrim, based on valid ID proofs at Pilgrim Helpdesk counters
Caution Deposit amount to be refunded to the pilgrim on check out
shall be updated to pilgrim through SMS. Instructions regarding the
location / counters to collect refund shall also be shared
System shall provide an option for refunding the Caution deposit
amount online to pilgrims account, if desired by the pilgrim.
Details regarding the amount to be refunded shall be updated on the
Temple Management System portal to be accessible for Pilgrim
Helpdesk operator
System shall enable pilgrims to get the refund for the caution deposit
from any of the Pilgrim Helpdesk counters. System shall update the
same for the Booking reference number of the pilgrim
Pilgrim shall get information regarding their queries for accommodation
- Booking / allotment / check in / checkout from Pilgrim Helpdesk
counters, Call centre and through SMS
System shall capture the room check in and checkout time on real time
basis so that pilgrims are charged on actuals for the total hours for
which room was occupied
List of room bookings done by pilgrims through website and other
channels such as Pilgrim Helpdesk counters, DD. shall be available with
the Temple management for a comprehensive data/ view of the
bookings done
System shall provide Search option for the pilgrim booking/ allotment.
This shall also provide sorting option for the search criteria
The system should block the Sevas and Accommodation. On special
days temples will be closed until they reopen, the sevas will be blocked
and the system wont allow to book the tickets
Sub-Module: Annadanam Module
The system shall display information on public display for:
Waiting time
Menu
Nutritious value of the food
Batch timing
The system shall display information in the dining area:
List of donors
Ability to book a slot for pilgrim in Annadanam, based on his/her other
bookings such as Darshanam and Seva, to reduce the waiting time for
the pilgrim
The system shall have a well-defined seating plan for the pilgrims

e-Pragati Requirements Specification Document Temple Management System Page 161 of


216

based on the estimated pilgrim inflow for each slot


4
5
TM030
6

The system shall capture number of pilgrims attended in Annadanam


per batch,
The system shall allow this count to be updated in Dittam register for
further procurement
Sub-Module: Issuance of Notifications & Alerts

Notifications and alerts to staff of the temples and Pilgrims on change


of status of complaint.

Should generate notification in all modes such as e-mail, SMS

3
4
5
6
7
8
9
10
TM030
7
1

3
4

Issue alerts to subscribers on waiting list at pujas, Annadanam


counters, tonsuring counters
Identifying the bottlenecks at critical nodes of queue line even when
they are building up, timely notification to pilgrims and helping in
prompt remedial action
Issue alerts to subscribers if they are not presented in registered
seva/service before the service expires
System generates an electronic notification to Finance Department of
when department deposits are made
Issue alerts to senior management/ temple administration if the waiting
list is beyond expectations
The module shall enable the procurement unit to send notifications for
requirements from each of the units
Timely notification of donor bookings and advance reservations at the
room allocation counter, to avoid last minute hassles for arranging the
rooms
Generate alerts for subscribers on pilgrims tracking travelling in
temple premises, transportation mode , availing service
Sub-Module: e-Payment module
The system shall provide Payment Gateway including a secure site
page using industry-standard encryption technologies like Secure
Socket Layers (SSL) and a merchant bank account, which will handle
the actual backend communications and transactions, contacting the
bank and reporting back on the results.
The system shall support multiple payment option including the
following:
Debit/credit card (Visa, Visa Electron, MasterCard, Maestro, JCB,
Diners Club), PayPal
Net Banking
wire transfer
on delivery
SMS
The system shall support Instant Payment Notification (cyber receipt)
and each transaction shall be date-time stamped
The system shall allow 24x7 facility to make payments. All payments
effected up to 8 p.m. shall be accounted for the day as that days
receipt. Payments effected after 8 p.m. will be accounted as the next

e-Pragati Requirements Specification Document Temple Management System Page 162 of


216

working days receipt.


5
6
7
8
9
10
11

12
13

14

15
16
TM030
8

The system shall use single merchant identity with multiple transaction
identities to streamline Treasurer processing (e.g., merchant ID, fund
number, budget unit number)
The system shall not allow local storage or transmission of credit cardspecific information. The solution shall follow industry-standard secure
transaction between consumer and e-Payment provider only.
The system shall support automatic filters for suspicious transactions
and shall allow for manual checking of suspicious transactions.
The system shall generate notifications for fraudulent online
transaction attempts.
The system shall have user friendly web based administration Control
Panel
The system shall allow Temple Management System to build a complex
logistic request processing system to fully automate after-payment
operations using IPN.
The system should provide an interface between all bank partners'
system, Treasury and Temple Management Systems finance and
accounts ERP system.
The Payment gateway shall collect payment receipts for various
payments like donations fees, room tariff fees, other charges and fees,.
The payment gateway would collect these receipts and credit the same
to Departments bank account
All receipts shall be credited to the Department account not later than
T+2 days.
The system shall be able to provide the department an MIS to facilitate
reconciliation. A user friendly console has to be shared with
department. The MIS should clearly state
a.
Name of person / organisation money received from
b.
Money received towards (registration fees, penalty, arrear)
c.
Amount received and date
d.
Other information as communicated by the department
The after-payment operations shall include the facility to refund the
payments to the payers bank account as per Departments instructions
The system shall provide users with FAQs with answers to a list of
frequently asked questions on payment and security related issues.
Sub-Module: Donations module

System should register for Donation through all modes(Online/Offline)

System should provide unique ID for donors, provide list of facilities to


donors based on the guidelines

System should accept all types of donations

4
5
6

System should publish the Donors names on the websites of temples


and other department channels based on the guidelines
Should facilitate in providing year /event wise donors list and list of
Donation details
Should facilitate tracking for Donors

e-Pragati Requirements Specification Document Temple Management System Page 163 of


216

Module
Code /
FR
Number
1
2
3
4
5

7
8
9
10
11
12
13

Module Name: Assets & Fund Management


Module Code: TM04
Module Functionality: This module shall support to the integrated
activities as accounting, inventory, procurement, auction, production,
employee management. This shall have the complete details of all
information on Government grant received, G.O.s, disbursed, and
reports for tracking.
Should provide the details and maintenance of category wise assets of
temples
Should provide information on all kinds of assets list at the time of
registration of temples under the endowment act
Support to keep record of the Jewellery adorned by the deity.
Should support for Jewellery management system for managing the
jewellery adorned by the lord, provide information on day wise
jewellery adorned to lord.
Provide information on jewellery purchased to adorn lord by temple
administration
The system shall have capability to capture key asset information like:
Asset type
Asset ownership
Date of installation
Location of installation
Cost of the asset
Life of asset
Salvage value
Maintenance schedule
Due date of maintenance.
The system shall have ability to establish and enter asset categories
and sub-categories such as: land, buildings, leasehold improvements,
equipment, furniture, fixtures, vehicles, capitalised leases, constructionin-progress, infrastructure, improvements (modifications).
Ability to create item templates to define major item attributes
Ability to facilitate hierarchical or functional decomposition of assets till
the last component level
Ability to maintain asset information such as warranty, extended
warranty, maintenance history, class of asset and equipment /
subcomponent relationships information
Ability to specify the location of an asset including area, address, and
building.
Ability to track the equipment warranty in the system in order to
prevent the in-house maintenance of the equipment during the
warranty period given by the supplier
The system shall have capability to provide information & maintenance
of
The number of equipments that are not running
Reason for the equipment not running
Period since when the equipment is not running

e-Pragati Requirements Specification Document Temple Management System Page 164 of


216


TM040
1
1
2
3

5
6
7
8
9
TM040
2
1
2

Purchased date of equipment

Sub-Module: Fund Management Module


The system shall allow Executive Officer of respective institution to do
keep record of revenue earned and expenditures. System should auto
populate the Assessable Income
System should allow the Endowments Department officials to access
the balance sheet of temples
System should provide provision for verification by various level of
Department officials and forward
The system shall calculate the total contributions for each institution as
per the act and norms. It must allow Commissioner office to raise the
final demand of contribution under following head:
- Endowments Administrative Fund
- Common Goods Fund
- Archakas welfare fund
- Audit fee
The system should pass-on the final demand to the respective
institutions on real time basis
System should issue a digitally signed demand notice to the respective
institution
The system should allow the institution to pay the contribution through
e-payment mode
System should do the periodic monitoring of demand and collection
activity and issue required alerts / notices/ advisories.
System should allow reconciliations of all transactions through bank
and Audit General (AG)
Sub-Module: Auction module
Temple Management System application must facilitate the auction
activities for the immovable properties on respective institution like
land, shops, building.
Temple Management System should allow to raise the public auction as
well as online auction
Temple Management System should allow to issue notifications of
auction with necessary information like:
- Date of auction
- List of article / property on auction
- Terms and conditions
- EMD
- person in charge and point of contact

The system should receive online applications

System should track the tentative list of attendees

6
7

System should validate the details of all participants through people


hub and other source of truth
System should facilitate the collection necessary fee /EMDs through epayment module

e-Pragati Requirements Specification Document Temple Management System Page 165 of


216

Issue the invite to all qualified participants

Monitor the auction process

10

Declaration of the results online after due approvals

11

Awarding the contract or office order

12

Refund to unsuccessful participants within the stipulated time frame

TM040
3
1
2
3
4

5
TM0404

Sub-Module: Asset Tracking & Maintenance Module


The system shall maintain a record of the infrastructure / equipment /
machinery available in Potu, Annadanam and other such departments
System shall have the plan for schedule and unscheduled maintenance
of boilers from engineering department and other equipment in
Annadanam kitchen, Laddu Conveyor in Potu and other such equipment
System shall collate an maintain day to day maintenance activities
required in Annadanam
System shall plan the requirement of additional facilities and
infrastructure based on the current capacity and future demand (Land,
building and other equipment as LCDs, Mics, Electronic scanners, TVs,
CCTV cameras) for Annadanam and Potu
The Schedule of (Civil) maintenance for the rooms shall be linked with
the room availability. Rooms shall be closed for allotment and marked
as Under maintenance in the system.
Sub Module : Gold Bond Scheme

System should provide information on number of gold and silver coins


available.

Provide information on rate of gold and silver coins

Online facility for deposit on the gold bond scheme

Provide reports on number of devotees who have availed the scheme

Provide information on price for individual bonds

TM040
5

Sub-Module:

Hundi counting Module

Registers with details of the collections shall be digitised and shall be


accessible to senior management of Temples on real time basis

System shall provide details for the staff deployed for Hundi counting

3
4
5
6
7

System shall enable online attendance management for the staff


deployed in Hundi counting for segregation and counting the collections
System shall generate the report for the regular absentees and
automatically escalate the absentee list to the Services department
System shall enable digitised format for the records maintained in
Hundi counting
System shall enable calculation of per day collections and the bank in
which collections are deposited
System shall provide maintaining and filtering the collections deposited

e-Pragati Requirements Specification Document Temple Management System Page 166 of


216

in a particular bank
Module
Code /
FR
Numbe
r

Module Name: Inventory Management


Module Code: TM05
Module Functionality: This module shall support to the integrated
activities as accounting, inventory, procurement, auction, production,
employee management. This shall have the complete details of all
information on Government grant received, G.O.s, disbursed, and
reports for tracking.

TM050
1

Sub-Module: Stores and Inventory Management Module

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

The system shall maintain Rituals planning inventory online


The system shall maintain the buffer stock of vastram. and sent alert to
the respective department / HOD if the stock falls below the defined
limit
The system shall maintain the original & duplicate donation jewelry
register online to simultaneously update both the registers
The system shall maintain the records of procurement from marketing
department and provision of required materials to Potu for production
The system shall maintain all the records related to supply of required
materials, actual consumption and laddu production in Potu
System shall track the reading of ghee tank in Potu
The system shall enable the process of procurement of raw material
from stores and production of laddu at various points
The system shall facilitate to enter the details of food stock inventory
procured from stores and consumed on a daily basis in Potu and
Annadanam
The system shall provide the information about the status of food stock
inventory for inventory management in Potu
The system shall enable Potu and Annadanam departments to raise the
indent to Marketing department for procurement of food
The system shall provide procurement details of raw materials from the
marketing department against the actual indent raised by Potu and
Annadanam departments
The system shall provide notifications and alerts to staff in Temples for
maintaining a buffer of food stock inventory
The system shall maintain the stock details for raw material in
Annadanam, Potu, flour mill and Godown
The system shall raise the indent to marketing department and invoice
from marketing department
The system shall capture the account of receipts and issues of laddu
and other panyarams from vaga padi
Maintain the data regarding the distribution of laddu and other
panyarams on recommendation, as per the quota allocated to each
official.
The system shall plan the food stock inventory through food stock
consumption analysis in Annadanam
The system shall provide the procurement details of food stock from
marketing department against the actual indent raised

e-Pragati Requirements Specification Document Temple Management System Page 167 of


216

19
20
21
22
23
24
25
26
28
29

30

31
32

33

34
35
36
37

The system shall provide the procurement details of food stock from
stores with reference to number of Dittam planned for the food
preparation in Annadanam
The system shall process indent and invoice for milk procurement in
Annadanam
The system shall maintain the list of vegetable items, requirements for
Annadanam with the options of seasonal vegetables
The system shall maintain the details of other consumables used in
Annadanam, such as number of banana leaves
The system shall maintain the details of vegetable donors with the
frequency of donation
The system shall have an option to trigger the information to other
interrelated departments such as transport for collecting the donated
vegetable from different locations
The system shall maintain the details of procurement of silver & gold
coins from treasury and selling to the Pilgrims
The system shall provide facility for the user to define and change the
minimum and Maximum inventory levels ('min-max levels') for each
inventory material in the module/
The system shall facilitate tracking the inventory levels against minmax levels for all inventory materials
The system shall provide facility for the users to define the re-order
quantities for each inventory material in the module
The system shall manage the availability of first aid kit at various heavy
rush pilgrim points such as:
Auto Stand
Railway stand
Bus stand
VQC Complexes
Darshanam booking counters
Other important points of Pilgrim interface
The system shall send alerts for managing the day to day facilities
requirement on time.
The system shall maintain details of resource requirement for all the
departments online
The system shall maintain all the records of System Integrator
managing additional Potu for laddu production:
Provision from stores
Laddu production
Payment to the System Integrator
Other day to day activities
System shall maintain a master list of the specification of the materials
required by different departments, such as Vastram., for ease in
procurement
System shall maintain a master list of the empanelled System
Integrators for procurement of raw materials., such as Vastram
The system shall compare the rates offered by different System
Integrators to finalise the System Integrator for empanelment
The system shall maintain the details of Vastram supplied by System

e-Pragati Requirements Specification Document Temple Management System Page 168 of


216

Integrator with frequency of supply

38

39
TM050
2
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

System shall maintain a stock of the different types of items / raw


material available in the stores and their minimum buffer stock. System
shall generate an alert for the concerned department head / marketing
head, if the stock falls below the buffer limit defined, so that
procurement for a material can be initiated timely
The system shall maintain the details of raw material procured and
consumed for performing the sevas
Sub-Module: Production Planning Module
The system shall provide details of pilgrim inflow for darshanam to plan
the food production in Annadanam. This should include the number of
pilgrims having darshanam through all the modes (free darshanam,
current & advance booking)
The system shall have details of the defined quantity of Dittam for all
the available items
The system shall provide the details of number of Dittam prepared
versus actual number of pilgrim served in Annadanam and Potu
The system shall perform food stock consumption analysis with
reference to the pilgrim profiling to arrive at daily estimate of
consumption
The system shall provide details of the actual food stock consumption
versus planned calculated consumption
The system shall have a calendar charting out the plan and frequency
of vegetable donation by Annadanam donors
The system shall facilitate serving plan for the items defined in the
Annadanam menu
The system shall maintain the record of food consumed such as trolley
of rice, sambhar, curry, in each batch to arrive at a pattern of
consumption analysis in Annadanam
The system shall maintain the details of food items procured from
kitchen versus food items consumed in Annadanam
The system shall keep a record of the production of free laddu
distributed in Annadanam
The system shall define a batch timing for laddu production based on
the laddu requirement in Annadanam
The system shall maintain a buffer stock of free laddu distributed in
Annadanam
The system shall provide details of the total pilgrim inflow for
darshanam and Seva for the efficient planning of laddu production in
Potu.
The system shall enable the scientific way of planning and estimating
the demand by providing information of pilgrim inflow, production and
consumption in Annadanam and Potu
The system shall enable the production batch planning for laddu
production at all the points such as boondi Godown, inner Potu, laddu
Godown and laddu distribution counters.

e-Pragati Requirements Specification Document Temple Management System Page 169 of


216

16

17
18
19
20
21
22
23
24
25
TM050
3

The system shall manage and maintain details of laddu/prasadam


production cycle such as:
Production batch timing
Shift timing of employees for production
Dittam
No. of items prepared (Laddu, annaprasadam & panyaram)
Quantity defined in Dittam
The system shall maintain details of defined quantity of Dittam for
laddu, panyarams and annaprasadam
The system shall facilitate reconciliation between the laddu production
as per the Dittam & weight of the laddu produced in Potu
The system shall maintain the Dittam and details of Panyaram and
Annaprasadam with reference to the seva calendar and the schedule of
temples respectively
The system shall change the quantity defined in Dittam with
appropriate permission as and when required
The system shall schedule for quality check defining all the parameters
The system shall maintain the records of quality check done on a daily
basis
Ability to maintain the record of laddus and other panyarams
distributed on recommendation
The system shall have the option to maintain the weekly schedule of
annaprasadam
The system shall have the capability to generate material consumption
patterns and analysis during a particular period
Sub-Module: Stock & Consumption Analysis

Should maintain Available Stock & Consumption details

Should generate alerts to Temple Management on available stock


The system shall provide details of estimated stock consumption versus
planned calculated consumption

3
4

System should capture the requirements for stock

Ability to provide itemised stock details alongwith unique ID and


quantity details

e-Pragati Requirements Specification Document Temple Management System Page 170 of


216

Module
Code /
FR
Number
TM0601
1

3
4
5
6
7
8
9
TM0602
1
2
3
4
5
6
TM0603
1

Module Name: Temples profile & property Management


Module Code: TM06
Module Functionality: The module shall facilitate Endowments
Departments activities as registration, demand collection, scheme
management.
Sub-Module: Temples Registration
The system shall allow the users to get the temples/institutions
registered with Endowments Department.
The system should capture all required information w.r.t registration
like:
- Name of Owner
- Details of property/Land
- Type of property
- Other identity of the owner
- List of articles available with the institution
- Revenue of a temple
- List of sevas notified for respective temples/ institutions
The system shall get the validations from people hub and land hub
automatically
The system shall allow the GIS mapping of the respective property
The system shall allow to establish approval process required from
various officials like EO, AC, Commissioner office
The system shall generate the proper alerts and statuses of the
registration process
The system shall prompt the pending applications to the inbox of
respective officials as well as his/her superior
The system shall allow to generate the registration certificate as per
the Endowments Act
The system shall allow to issue digitally signed registration certificate
and also facilitate CLGS
Sub-Module: Temples Land Details
The system should integrate with Land hub system for providing
dynamic update on land details
System should facilitate land lease management details such as lease
holder details, amount paid for lease , no. of years for lease and
purpose of lease
System should facilitate temple wise land details such extent, survey
numbers, details of boundaries, usage of temple lands.
System should facilitate integration with e-Pragati GIS for temples
lands
System should provide dynamic update of land details
System should capture the details source of land to temples and
donor details
Sub Module : Manage Temples Profile
System should provide updated information on the profile of Temples
such as location, constructed year, trustee details , connectivity details
and familiar for the temples

e-Pragati Requirements Specification Document Temple Management System Page 171 of


216

2
3
4
5
TM0604
1
2
3
4
5
6
7
8
9
TM0605
1
2
3
4
5
6
7
8
9
10

System should provide information on architecture details and unique


features of temples
System should provide information on festivals and special feature of
temples
System should provide information on available sevas, rooms and seva
timings of temples
System should integrate with tourism department application to
provide nearest tourism places
Sub Module : Staff Management
System should capture the all staff details in Temples/Institutions
Ability to categorise staff as religious and non-religious staff
System should provide role based access to staff based on the allotted
work
System should assist staff to know the assigned roles
System should provide roles to staff during special events
System should provide best practices to the management of temples
in order to assign roles for staff during events conducting by temples
Should provide workforce management tools to monitor staff on
assigned activities
Provide shift wise staff details
Identify the training needs and train the staff based on the types of
calls currently received
Sub Module : Temples Room Management
System shall provide information on all types of rooms available at
temples
System shall enable Temple Management System to maintain a log of
rooms booked by guest house donors and rooms allotted to the
donors.
System shall generate unique reference number for all the 'Request for
room booking' requests for processing the same.
System shall have an option of defining business rules for allocating
quota for a category.
Rooms shall be allotted to pilgrims after verifying the authenticity of
the pilgrim, based on valid ID proofs at Pilgrim Helpdesk counters
List of room bookings done by pilgrims through website and other
channels such as Pilgrim Helpdesk counters, Internet. shall be
available with Temple management. .
System shall enable the Temple management to allocate rooms under
different quotas in different time intervals
System shall define the time period for booking a room under
particular quota. Such as advance booking may commence 3 months
in advance, while current booking may commence only 24 hours in
advance
System shall enable transfer of quota from one category to other
based on the pre-defined business rules
Transfer of quota from one category to other shall be easy to track and
should be allowed based on adequate approvals from senior

e-Pragati Requirements Specification Document Temple Management System Page 172 of


216

11
12
13
14

15

16
17
18
TM0606
1
2
3
4
TM0607
1
2
3
4
5
6
7
8

management (such as HODs and JEO). An audit trail for quota transfer
shall be maintained in the system
Staff of the(Attender) Temples shall update the details regarding the
room check in and check out through handheld device
Staff of the (Attender) Temples shall be able to update the room status
to "Dirty", to block the room from further allotment.
Temples shall automatically share the status of room (if Dirty), with
the FMS agency, so that agency can deploy people for cleaning the
room
Staff of the(Attender) Temples shall be responsible to update the
status of the room to "Clean" so that room shall be made available for
allotment
System shall enable interface between different Endowments
department, such as
Accounts for reconciliation of amount deposited in banks,
FMS agency for room maintenance
Engineering department for schedule for room maintenance
System shall maintain a log of the rooms cleaned by the FMS agency,
for reference while making payments to the FMS agency.
System shall enable information sharing with Call centre, Information
kiosk, SMS, Pilgrim Helpdesk counters, to share information regarding
the release of quota with Pilgrims
System shall provide Search option for the pilgrim booking/
allotment. This shall also provide sorting option for the search criteria
Sub-Module: Trustee/board Management
System should provide information trustee details
System should provide information on list of facilities available for
trustees/board members such as rooms, special sevas, prasadam
System should provide information about temples/institute to trustees
regarding special pujas and other events
System should display information on trustee details
Sub-Module: Lease Management System
Temple Management System application must facilitate the leasing of
temples assets i.e. Land, Shop, building, temples premises.
Temple Management System should keep track of assets of temples in
sync with financial module
System should accept the records of all lease performed for assets of
the temples.
System should keep all document as ID proofs, legal (agreement, lease
doc.). from people hub
System should allow the process to obtain departmental approval and
Treasury approval
System should track the agreed amount against each lease
System should reconcile the transaction against each lease and
generate the relevant - MIS
- Renewal of lease
- Termination of lease
Release of payment as per the payment term

e-Pragati Requirements Specification Document Temple Management System Page 173 of


216

Module
Code /
FR
Number
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
TM0701
1

Module Name: Human Resource Management


Module Code: TM07
Module Functionality: The module shall facilitate Human Resource
Management for temples
System should able capture all the staff details (Religious , Nonreligious staff)
System should capture staff personal details such as DOB, Blood
group, sex, mobile number, email ID , Address, age
System should capture staff departmental details such as DOJ,
Designation, Salary, experience, skill set
System should support in recruiting staff based on the requirements
System should support for recruitment details such as number of
applicants, selection criteria and eligibility criteria
System should support pay scale structure after selection
System should support for recruitment procedure based on the
requirement for Non-religious, religious temporary staff and permanent
staff
Should support role based access to the Temple Management System
Should provide information on employees w.r.t their allotted duties at
different sections at temples
The system shall manage the shift timing of the cooks, Temple
Management System employees, Serving staff, respective Workers as
per the cooking cycle and align it to the dining and serving time in
Annadanam and production requirement in Potu
The system shall manage the batch timing of employees for regular
shifts of available services
The system shall provide alignment of regular resources & others
resources during peak time
The system shall facilitate the distribution of manpower Cooks,
Temple Management System employees, Serving staff, respective
Workers on the basis of peak and lean pilgrim inflow
The system shall capture the details of employees (permanent,
contract and outsourcing) with facilities and incentives they are
entitled for.
System should support for bio metric attendance system at
temples/Institutions
Should capture the attendance through bio metric devices
Ability to track employees attendance, leave approval and other day to
day activities
System should support performance review of staff based on the
allotted duties
System should support payroll management such as payment details
to staff.
Should support regular payment to staff based on the department
guidelines
Should support leave application in online facility for staff members
Sub-Module: Workflow Management module
The module shall support a web based GUI through which workflows

e-Pragati Requirements Specification Document Temple Management System Page 174 of


216

2
3
4
5
6
7
8
9
10
11

12
13
14
15

16

17
18
19
20
21

can be graphically designed.


The module shall support view for Top-level status diagram (for
business users).
The module shall support view for detailed technical diagram (for
Implementers).
The module shall support drag and drop of workflow components so
that process model can be designed and / or modified by non-technical
users.
The module shall store process models in a structured repository in
draft, final and approved (or equivalent) modes.
The modules workflow engine shall support both Task driven and goal
driven process descriptions.
The module shall support automatic instance creation based on
external data inputs (from other modules) and/or events.
The module shall have provision for generating reports and track
status of workflow instances.
The workflow shall allow multi-step approval routing. Non repudiation
of workflow is to be ensured using digital signature certificates.
The module shall allow workflows to have multiple concurrent statuses
(separate statuses for separate instance).
In cases of exception, the module shall allow for workflows to be rerouted manually. Only privileged user shall be allowed to override
workflow and engine shall generate reports and send e-mail
notifications of exceptions to designated authorities.
The module shall allow workflows to be re-routed and /or activated
based on time. The time thresholds for re-routing should be
configurable.
The module shall allow workflows to be re-routed and /or triggered
based on external events and data inputs for other modules.
The module shall support subsequent workflow steps to be activated
automatically upon completion of previous steps
The module shall support workflow instances to be triggered by
discovery of a content object type instance (in enterprise content
management module)
The module shall support subsequent workflow steps to be activated
manually without requiring completion of previous steps in special
cases. Only privileged user shall be allowed to override workflow and
engine shall generate reports and send e- mail notifications of
exceptions to designated authorities.
The module shall support a system calendar that distinguishes work
days, holidays/vacation, and work day start/end times.
The module shall log all actions of all users in audit trail format.
The module shall log and send notifications through email for any
exception / unavailability of users / error in process step (to privileged
users and designated authorities).
The module shall allow workflows to be designed to have splits and rejoins along the process path.
The module shall allow workflow roles to be configurable and
assignment of roles to use profiles shall be done by Privileged users

e-Pragati Requirements Specification Document Temple Management System Page 175 of


216

22
23
24
25
26
27
28
29
30
31
32

33

34

35
36

(administrators) only. Multiple user roles shall be supported.


The module shall integrate with individual and/or group calendars to
drive participant selection for user roles. It should allow access to user
profile and location values for selection, filter, and update.
The module shall enable workflow steps to access related content
objects (from enterprise content management module).
The module shall allow workflow steps to be assigned a mandatory
or optional status. Optional steps may be skipped by end user in a
particular workflow instance.
The module shall allow workflow payloads to include any object type
defined in the enterprise content management module.
The module shall support attachments that are shared by all workflow
instances in some cases and attachments that are specific to a
workflow instance in some cases.
The module shall assign unique IDs to workflow either automatically or
manually.
The module shall support workflow designs with target dates and
times assigned to individual workflow steps. Target dates and times
can be changed in mid-stream depending on workflow variables and
status.
The module shall support workflow processes for approval and send
out notifications through multiple channels (e-mail and SMS).
The module shall check for sufficient user rights to execute workflow
actions.
The module shall maintain separate to-do and watch lists for each user
and send out notifications through multiple channels (e-mail and SMS).
The module shall support filters and search capabilities for userspecific to-do and watch lists to privileged users and designated
authorities.
The module shall allow users to filter the to-do lists to see the
following sets of tasks:
- All Tasks
- Overdue tasks
- Daily Overdue tasks
- Weekly Overdue tasks
- Monthly Overdue tasks
The module shall allow users to perform the following actions on
workflow instances:
- Users can pause or resume instances
- Users can restart instances
- Users can delete instances
- Users can abort instances
- Privileged Users can manually override instance data
The module shall generate reports of performance on processes that
highlights duration of each workflow step and number of visits to each
workflow step
The module shall generate print-outs of documents such as shipping
advice, travel plan itinerary, pharmacy receipts. on pre-printed
stationery.

e-Pragati Requirements Specification Document Temple Management System Page 176 of


216

Module
Code /
FR
Number
1
2
3
4
5
6
7
TM0801
1
2
3
4
5
Module
Code /
FR
Number
TM09

Module Name : Events Management


Module Code : TM08
Module Functionality: The module shall facilitate the temple
administration plan the events and provide information on events
planned by temples to pilgrims
Regular updates regarding Seva, Darshanam and other religious
events held in temples
Provide regular updates on event timings through all channels to
pilgrims
Should be able to design schedules for performing events by the
temple administration.
Ability to design and plan for performing events and capture the
requirements for an events
Ability to generate alerts to the temple administration and department
officials on the conduct of special events
Provide services on the special events
Provide information to all other relevant departments for conducting of
events such as transport ,municipal, health and power distribution
Sub module : Pushkaram Management
Notify the list of temples covered under the Pushkaram program
Issue necessary advises to temples for making the arrangements
during Pushkaram program
Information should be provided to all stakeholders
Should capture the pilgrims count
Pilgrims should be able to register online for pujas and archakas during
Pushkaram
Module Name : Ritual Planner
Module Code : TM09
Module Functionality: The module shall facilitate the temple
administration to plan the events and provides information on events
planning by temples to pilgrims
Sub-Module: Rituals Planning module
The system shall display the information related to performing the
seva:
Detail of current seva
Seva Timings (start timing & end timing)
Place to perform the seva
No. of people allowed per ticket
Place to collect the Prasadam
The system shall display the details of gold & silver dollar at the dollar
sales counter:
Rate of gold & silver dollar
Types of gold & silver dollar ( 2gm, 3 gm & 10 gm)
Timing of the office
The system shall maintain a master list of the rituals to be performed
and the specific requirement, such as Vastrams, as per Agama,
required for performing each ritual.

e-Pragati Requirements Specification Document Temple Management System Page 177 of


216

4
5
6
Module
Code /
FR
Number
1
2
3
4
TM1001
1
2
3
4
5
TM1002
1
2
3
4
5
6
7
8
9
10
11
12

System shall maintain a list of attendees of the seva and the list of
privileges such as Vastram, laddu, gold / silver dollar to be offered to
the pilgrims performing the seva
System should capture the requirements for ritual inventory planning
System should provide updates on ritual inventory planning
Module Name : Institution Management
Module Code : TM10
Module Functionality: The module shall facilitate Institution profile such
as date of establishment, founder, trustee , asset details , financials
status. The institution can be mutt, Ashramas, charitable trusts and
veda patashalas
Provision to provide role based access to all types of institutions in the
state based on the requirements of the department to authorise the
information
System should capture all types of institution details such as assets,
trustee, location funding source, list of sevas
System should provide updated list of institutions
Provision to integrate with GIS portal to map all the institutions
Sub-Module: Mutts & Peetams Management
Provision for updated information on list of mutts
Should provide facility for access to Mutts based on the identification
of department
Provide updated information on trustee details and trust members
details
Provide updated information of assets for Mutts
Provide updated information on sevas details provided by Mutts
Sub-Module: Patashala Management
System should provide updated information on veda/agama patshalas
in the state sponsoring information about temples
System should facilitate in providing applications for admissions into
schools
System should provide information on no. of seats available in schools
and eligibility and application criteria, course structure, course
duration
System should provide information on assets belongs to schools
System should maintain trained candidates details after completion of
training/study
Provide information on mapped temples to schools
Provision to provide updated course material to students based on the
course structure
Provision to capture accommodation details
Provision to capture attendance details such as number days attended
for course ,total days to complete for course
Provision to provide grades for students after completion of
training/education
Provision to provide updated information on staff and student details
Support for providing the certification after completion of the course

e-Pragati Requirements Specification Document Temple Management System Page 178 of


216

13
TM1003
1
2
3
Mod4ul
e
Code /
FR
Number
1
2
3
4
5
6
TM1101
1
2
3
4
TM1102
1
2
3
4
5
6
7
8

Provide & maintain updated information on allotted budget and


expenditure details for financial year
Sub-Module: charitable trust Management
Provide and maintain updated information on all the charitable trust
notified by department in the state
Provide and maintain information on list of assets w.r.t trusts
Provide information on founder and trustee ,location details
Module Name: Trainings
Module Code: TM11
Module Functionality: The module shall facilitate training facility and
requirements to the system. Under this module the temple
administration can facilitate to provide trainings to the religious/nonreligious staff based on the requirement
System should capture training requirements for religious and nonreligious staff
System should provide facility for temple & Department administration
to raise the requirements to provide training under endowments
department rules
System should provide training material for all relevant staff based on
the requirement
System should provide content for both languages such as Telugu &
English
Provision to provide digitised content in categories such as
instructional design, facilitator handbooks, training material, student
handbook, train the trainer (certification), chants.
Provision to provide materials in audio and video formats
Sub-Module: Trainings & Certifications
System should capture the details of trained candidates under the
vidyadanam program and other programmes performing by respective
temples and departments
System should provide certification to completed trainees
System should provide updated information on trainees
Provision to take the certification exam on the trained course for
religious non-religious staff
Sub-Module: Patashala Course Mgmt & Enrolments
System should provide necessary facilities to capture the requirements
for Vedapatashala under vidyadanam program
System should provide facilities for enrolment and application into
veda patashalas
System should capture temple/institute wise details of the patashalas
System should provide details on staff working in patashalas and
student details who are training in veda patashalas
System should provide admission details of veda patashalas
System should provide course related information for veda patashala
students and staff
System should provide certificates to successful completion of
students under vidyadanam program
System should facilitate application for admissioninto veda patashalas

e-Pragati Requirements Specification Document Temple Management System Page 179 of


216

Module
Code /
FR
Number
TM1201
1
2

only for eligible candidates


Module Name : Support Services
Module Code : TM12
Module Functionality: The module shall track all the miscellaneous
modules of the TM Package
Sub-Module: Support Services
Temple Management System should keep track of Administration of
Dhoopa Dheepa Naivedyam scheme
System module should address Appointment and training' under
Hindu Dharmika Parishad trust

System module should facilitate the Recruitment of Outsource staff

System module should keep track of Publicity related to Pujas and


other programs of temples (Ex: Homams)

System module should facilitate Admission into Veda pathashala

System should maintain and manage Pranadanam activities under the


respective institution

ANNEXURE 6 - FORMS RE-ENGINEERING REQUIREMENTS OF


COMMON MODULES & SUB-MODULES OF TMS
e-Pragati Requirements Specification Document Temple Management System Page 180 of
216

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 standardise 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 BPR has been as listed below:

To make available the relevant form available for making service request for
the selected services
To standardise the format for the form pertaining to selected services
To redesign/eliminate the existing forms as per the service integration and
CLGS traits of the e-Pragati architectural framework.
The following picture portrays the existing Room Booking application form
in the Temples Information Management System

e-Pragati Requirements Specification Document Temple Management System Page 181 of


216

FIGURE

21:

AS - IS ROOM BOOKING APPLICATION FORM

In the To-Be scenario the proposed forms describes in 4 parts which are shall be
approached for all forms to-be reengineered.

e-Pragati Requirements Specification Document Temple Management System Page 182 of


216

Part 1: Describes about pilgrims personal information which can be common for all
services in the TIMS application. Pilgrim has to select the service name Room
Booking option in under the corresponding service portfolio, after logging in to
TIMS application with the state specified unique number [the pilgrim demographic
and socioeconomic data of the pilgrim will be loaded from the People Hub, in case
the updated applicant data is not available in the TIMS databases]. The system
automatically identifies the pilgrim through the unique id and enables the applicant
to key the further details.
Part 2: This section relates to department specific information, application which
requires information as per department business rules. In Room Booking service
applicant has to provide the details for names of the Temples, Date of booking, no.
of Rooms required and room type. Part2 varies based on the service selection by
pilgrim.
Part 4: This section describes about payment details and it is common to all TMS
related services in e-Pragati, applicant has to pay the service charge as per
department business rules, he has select payment mode and has to pay the amount
Part 5: This section describes about self-declaration and digital signature of
applicant it is common for all TIMS related services
The most frequently used forms of the TIMS Package are hosted on the e-Pragati
Portal for reference. The SI is required to re-engineer these forms as part of the
BPR.
The following picture depicts that To-Be form for Room Booking

e-Pragati Requirements Specification Document Temple Management System Page 183 of


216

FIGURE

22:

TO - BE ROOM BOOKING APPLICATION FORM

e-Pragati Requirements Specification Document Temple Management System Page 184 of


216

ANNEXURE 7 - AS-IS SAMPLE FORMS


1. Subscription for temples magazine

FIGURE

23:

AS - IS SUBSCRIPTION FOR TEMPLES MAGAZINE FORM

2. Donation to temples

FIGURE

24:

AS - IS DONATION TO TEMPLES FORM

e-Pragati Requirements Specification Document Temple Management System Page 185 of


216

3. Sri Durga Malleswara Swamy Sevas and accommodation

FIGURE

25:

AS - IS

S RI D URGA M ALLESWARA S WAMY

SEVAS AND ACCOMMODATION FORM

e-Pragati Requirements Specification Document Temple Management System Page 186 of


216

ANNEXURE 8 - MIS REPORTING REQUIREMENTS


Given below are the MIS Reporting Requirements:
MIS Reporting Requirements of e-Pragati Temple Management System
Module Name : MIS Reports
Module Code : TM05
Module
Module Functionality: The MIS functionality helps the user to create
Code /
various predefined reports with different levels of analysis. The users
FR
can save custom MIS Templates for future usage. The simple MIS
Number Reports are generated from the Temple Management System
databases whereas for complex MIS Reports the functionalities of the
DataLytics application under the e-Pragati framework is used.
TM0501 MIS
1

Allow to integrate, generate, preview, download and print the KPI


Progress Report based on Department and Periodicity.

Allow to generate survey reports for specific temples, district and state
level.

Facilitate generation of the predefined reports by the users on different


parameters for generation of customised reports.

Facilitate a query builder facility to the predefined users.

Facilitate the users to save customised report templates for future use.
Facilitate to generate predefined reports with set of parameters on the
following lines anytime online:
a) Enrolment/visits of pilgrims w.r.t seva/puja/accommodations/
region/ demographic background

b) Staffs/Officials Attendance
c)
Pilgrims attended Annadanam and donation received
d) Student/Faculty Ratio in Patashala
e) Occupancy report of rooms available
f)
Pilgrims foot fall analysis for planning and management
g) KPIs and e-PIs

e-Pragati Requirements Specification Document Temple Management System Page 187 of


216

Facilitate to generate various reports on daily, weekly, monthly or for a


specified period w.r.t the following registers:
a) Trust Board Register
b) Dittam register
c) Register of Executive officers
d) Works Register
e) C.Mps Register
f) Budgets register
g) Allotment of funds from CGF and utilisation of CGF
h) Sale of Land register
i) Lease register
j) Encroachment register
k) Appeals and R.Ps register
l) Govt. cash book
m) Non Govt cash book
n) Acquaintance register
o) Permanent advance register
p) Pay bill register
q) Contingent bill register
r) Increment watch/sanction register
s) GPF recovery each register
t) HBA/MCA watch recovery register
u) Marriage advance register
v) Treasury bill register
w) Party cheque register
x) Budget control register
y) TA bill register

The MIS Reports shall have the following general facilities: .


a. Overall Status: State/District/institution level officials shall get to see
the change in different planning/ parameters.
b. Drill down to see individual KPIs specific to context of relevant
events of Temples.
c. Real Time Reports on different levels based on pre-defined severity.

Real time reports related to different schemes for temples.

Reports view for District HQs/State Endowments officials for review,


reporting, planning and decision making regarding:
- Security Surveillance of temples.
- Resource Management and Procurement.
- Human Resource Management.
- Demand and collection management

e-Pragati Requirements Specification Document Temple Management System Page 188 of


216

10

11

12

13

14

Enable the authorised department staff to build policy inputs through


the generation of Reports from the Temple Management System
database and through external online surveys with customisable
parameters and report templates.
Apart from the above, system should be able to accommodate and
provide MIS reports as per the needs of the departments which should
be in a customisable and printable formats. The system shall facilitate
generation of the predefined reports on different parameters. The
reports should support Graphical Reports, Cost Reports & Summary
Reports.
The system shall have facility to generate all statistical Reports and
MIS reports.
Apart from the above, system should be able to accommodate and
provide MIS reports like Asset list, Lease amount for temples, Amount
deposited with Hundi, Service wise revenue details, Total number of
Annadanam performed, rooms available for rent all of which should be
in a customizable and printable formats
Provision to export reports to different formats like excel, pdf.

e-Pragati Requirements Specification Document Temple Management System Page 189 of


216

ANNEXURE 9 - EPI & KPI REQUIREMENTS


The inputs that are required to be used to arrive at the outcome of each ePI is given
in the table 42 below. The detailed methodology for arriving at e-PIs and KPIs will be
described on the e-Pragati portal - http://e-pragati.ap.gov.in/

Sl.
No.

e-PIs of Temple
Management
System

1.

Pilgrim Amenities

2.

Web pilgrim
Services

3.

Facility
Management
(sanitation)
Services

4.

Annadanam

5.

Aarogyadanam

6.

Vidyadanam

Inputs to measure e-PIs


Based on the data captured during periodic
inspection of facilities and amenities provided by the
Management of temples to pilgrims for their better
and safe darshanam/ seva/ visit.
Based on the data from Temple Management System,
captured during the pilgrims service delivery,
facilitation and assessments by temples and
department authorities periodically.
Based on the data from Temple Management System,
captured during the assessment of temples by
authorities from the temples periodically.
Based on the data from Temple Management System,
w.r.t. number of pilgrims participated for Annadanam,
donation received for Annadanam.
Based on the data from Temple Management System,
w.r.t. No. of pilgrims provided health services by the
management of temples or institutions
Based on the data from Temple Management System,
w.r.t. amount spent on Vidyadanam and other
facilities provided for pathasalas, scholarship given.
TABLE

44:

EPIS OF

TMS

e-Pragati Requirements Specification Document Temple Management System Page 190 of


216

ANNEXURE 10 - NON-FUNCTIONAL REQUIREMENTS OF


TEMPLE MANAGEMENT SYSTEM
1. Scalability Provisions:
Sl. Description
No
.
1. Sufficient number of ports for addressing the required bandwidth shall be
provided by cloud service provider as per sizing requirements detailed out in
Section 8.3. Scalability shall be planned in accordance with future growth of
11% year on year.
2. Temple Management System shall provide load balancers at various layers
of application deployment, facilitating high availability in the cloud
environment.
3. Temple Management System shall provide horizontal scalability in such a
manner that a new resource can be added (or removed) dynamically, as and
when required in future, without disturbing the normal functioning of
production system.
4. Temple Management System shall support 50 thousand users environment
seamlessly considering the total number of pilgrims, staff, administrative
users and department users. Details are provided in the factsheet of Volume
1, Section 3.
TABLE

45:

SCALABILITY PROVISIONS

2. Performance Provisions:
Sl.
No
.

Description
1.The Temple Management System shall support 7000 users on average by
considering various types of users.
2.Response time shall be on average 3 seconds for 90% of transactions and
remaining transactions shall not exceed response time of 10 seconds.
Response time is defined as the time between when user sends a service
request and when user receives response (output on the screen). Service
Levels are different based on the Services availed.
3.Response time of services shall remain within operational SLA limit even
during peak usage with 2 Mbps link.
4.The users may perform different kinds of activities on the system, including
downloading or uploading large files like images, documents, multimedia.
The system must have acceptable level of performance even during peak
usage.
5.Temple Management System shall respond to user requests within
operational SLA limit. This SLA applicable to MIS and analytical reports as
well.
TABLE

46:

PERFORMANCE PROVISIONS

e-Pragati Requirements Specification Document Temple Management System Page 191 of


216

e-Pragati Requirements Specification Document Temple Management System Page 192 of


216

3. Availability Provisions:
Sl. Description
No
.
1.The network level redundancy shall be achieved through procuring leased
lines from two different service providers, alternate routing paths facilitated
at ISP backbone (MPLS), redundant network devises. Redundant ISP links at
both ends of SDC as well as Cloud Provider shall be provided.
2.Redundancy in security components and load balancers, in high-availability
mode, shall be provided to facilitate alternate paths in LAN including all
supporting systems.
3.Redundancy shall be provided to Temple Management System and all related
critical components of architecture including web, application, and database
layers. The size of each server/instance and total number of
servers/instances in a cluster shall be determined to meet the performance
requirements, even if a particular server/instance is unavailable.
4.The Temple Management System shall be available 24x7 with 99.5% of
uptime on the average and, strictly adhering to defined SLAs.
TABLE

47:

AVAILABILITY PROVISIONS

4. Reliability Provisions:
Sl.
Description
No.
1. The Temple Management System shall be a reliable system with consistent
and repeatable behaviour in terms of quality, availability, scalability, and
performance.
2. The Temple Management System shall be robust and tolerant to certain
level of faulty use. For example: The entire system should not come down if
an user accidently inputs wrong value, or uploads incorrect data.
TABLE

48:

RELIABILITY PROVISIONS

5. Manageability Provisions
Sl.
No.
1
.

Description
The Temple Management System is required to cater to stakeholders
across the country accessing it from multiple points and through multiple
channels like Desktop, Laptop, Mobile and Tablet. Hence the manageability
of this system is essential to ensure effective monitoring and timely
resolution of any issues surrounding performance, availability and security.
TABLE

49:

MANAGEABILITY PROVISIONS

e-Pragati Requirements Specification Document Temple Management System Page 193 of


216

6. Usability Provisions
Sl. Description
No.
1. The Temple Management System shall be made available on all major
browsers &mobile platforms and SI shall propose suitable solution.
2. The Temple Management application itself shall be user friendly and any
new user must be able to easily use functionalities offered by the system.
3. Error messages or pop ups must be helpful to an extent that user can take
next action and does not experience too much discomfort.
4. User interface must be simple yet user-friendly, and the workflow should be
intuitive so that user/Citizen can complete his work with least time and
effort.
5. All the system alerts and error messages shall be available in local
languages for understanding of Citizen,.
TABLE

50:

USABILITY PROVISIONS

e-Pragati Requirements Specification Document Temple Management System Page 194 of


216

ANNEXURE 11 - LIST OF SCHEMES IN ENDOWMENTS


DEPARTMENT/ INSTITUTION
Sl.
No.
1.
2.

Name of the Scheme


Common Goods Funds
Archakas Welfare funds

3.
Dhoopa Deepa Naivedyam
4.
Veda Pathasalas
5.
6.

Agama Pathasalas
Scheme for construction of Ramalayams in Weaker Section Housing
Colonies
TABLE

51:

LIST OF SCHEMES IN

TMS

PACKAGE DEPARTMENT

e-Pragati Requirements Specification Document Temple Management System Page 195 of


216

ANNEXURE 12 - LIST OF TEMPLES UNDER ENDOWMENTS


DEPARTMENT
Sl.
No.
1
2
3

District

Srikakulam
Vizianagaram
Vizianagaram
Visakhapatna
m
Visakhapatna
m
Visakhapatna
m
Visakhapatna
m

8
9
10
11
12
13
14
15

East
East
East
East
East
East
East
East

16

West Godavari

17
18

West Godavari
West Godavari

19

West Godavari

20

West Godavari

21

Krishna

22

Krishna

23
24
25
26
27
28

Krishna
Krishna
Krishna
Guntur
Guntur
Guntur

4
5
6

Godavari
Godavari
Godavari
Godavari
Godavari
Godavari
Godavari
Godavari

Name Of The Institutions


Sri Suryanarayana Swamy Temples
Sri Pydithalli Ammavari Temples
Sri Ramaswamy Temples
Sri Varaha Lakshmi Narasimha
Swamy Devasthanam, Simhachalam,
Sri Kanaka Mahalakshmi Ammavari
Devasthanam, Burujupeta
Sri Nookambica Ammavari
Devasthanam
Sri Sampath Vinayagar Temples,
Asilmetta
Sri Veera Venkata Satyanarayana
Swamy Devastanam
Sri Talupulamma Ammavari Temples
Sri Balabalaji Swamy Temples
Sri Laxminarasimha Swamy Temples
Sri Bhimeswara Swamy Temples
Sri Vigneswara Swamy Temples
Sri Venkateswara Swamy Temples
Sri Veereswara Swamy Temples
Sri Venkateswara Swamy
Devasthanam
Sri Mavulamma Ammavari
Devastahanam
Sri Maddi Anjaneya Swamy Temples
Sri Kotasattemma Ammavari
Devastanam
Sri Ksheera Ramalingeswara Swamy
Temples
Sri Durgamalleswara Swamy Varla
Devatshanam
Sri Tirupatamma Ammavari
Devasthanam
Sri Subrahmanyeswara Swamy
Temples
Sri Venkateswara Swamy Temples
Sri Kondalamma Ammavari Temples
Sri Malleswara Swamy Temples
Sri Trikoteswara Swamy Temples
Sri Panakala Lakshmi Narasimha

Ass.
Income
Cla
14-15 (in
ss
INR)
35896523 a(ii)
27520593 a(ii)
11000722 a(ii)
344861793 a(ii)
57387043 a(ii)
21662830 a(ii)
17721636 a(ii)
416501651
34122881
18541586
16392265
14056366
14013049
13234665
10709571

a(ii)
a(ii)
a(ii)
a(ii)
a(ii)
a(ii)
a(ii)
a(ii)

310542806 a(ii)
33479701 a(ii)
21483463 a(ii)
12311206 a(ii)
10401286 a(ii)
266393212 a(ii)
85828139 a(ii)
26655947
12457761
10800000
42617557
27022780
25155227

a(ii)
a(ii)
a(ii)
a(ii)
a(ii)
a(ii)

e-Pragati Requirements Specification Document Temple Management System Page 196 of


216

Sl.
No.

District

29
30

Guntur
Guntur

31

Guntur

32

Guntur

33

Guntur

34

Prakasam

35

Prakasam

36

Prakasam

37

Prakasam

38

Nellore

39

Nellore

40
41

Nellore
Nellore

42

Nellore

43
44
45
46
47

Nellore
Nellore
Nellore
Cuddapah
Cuddapah

48

Kurnool

49

Kurnool

50

Kurnool

51

Kurnool

52
53

Kurnool
Anantapur

Name Of The Institutions


Swamy Temples
Sri Lakshmi Padmavathi Sametha Sri
Venkateswara Swamy Temples
Sri Amareswara Swamy Temples
Sri Nidanampati Laxmi Ammavari
Temples
Sri Sahasra Lingeswara Swamy
Temples
Sri Jagannadha Anjaneya &
Venkateswara Swamy Temples,
Lalapet
Sri Malyadri Lakshmi Narasima
Swamy Temples, Malakonda
Sri Prasanna Anjaneya Swamy
Temples
Sri Prasanna Chennakesava Swamy
Temples
Sri Valluramma Ammavari Temples,
Valluru (V), Tanguturu (M)
Sri Penusila Lakshmi Narasimha
Swamy Temples H/O Penchalakona
Sri Talpagiri Ranganadha Swamy
Temples
Sri Mallikarjuna Swamy Kamakshi
Tayee Ammavari Temples
Sri Rajarajeswari Ammavari Temples
Sri Vengamamba Perantalu Ammavari
Temples
Sri Chengalamma Parameswari
Ammavari Temples
Sri Muthyalamma Ammavari Temples
Sri Venugopala Swamy Temples
Sri.Veerabhadra Swamy Temples
Sri. Malleswara Swamy Temples
Sri Bramaramba Mallikarjuna Swamy
Devasthanam
Sri Mahanandeeswara Swamy
Devasthanam
Sri Narasimha (Eranna) Swamy
Devasthanam
Sri Maddileti Narasimha Swamy
Temples
Sri Lakshmi Narasimha.Swamy
Temples
Sri Nettikanti Anjaneya Swamy

Ass.
Income
14-15 (in
INR)

Cla
ss

21169245 a(ii)
19588836 a(ii)
11605447 a(ii)
10757773 a(ii)
10091838 a(ii)
42139992 a(ii)
18722299 a(ii)
11072499 a(ii)
10854811 a(ii)
44081102 a(ii)
27393044 a(ii)
20335476 a(ii)
15848663 a(ii)
14868715 a(ii)
13899028
13591635
11976917
12022354
10919455

a(ii)
a(ii)
a(ii)
b(ii)
b(ii)

605024584 a(ii)
77048653 a(ii)
72147108 a(ii)
30091898 a(ii)
19162145 a(ii)
69224572 a(ii)

e-Pragati Requirements Specification Document Temple Management System Page 197 of


216

Sl.
No.

District

54

Anantapur

55

Chittoor

56
57

Chittoor
Chittoor

58

Chittoor

59

Chittoor
TABLE

Name Of The Institutions


Temples
Sri Khadri Lakshmi Narasimha Swamy
Temples
Sri Kalahastheeswara Swamy
Devasthanam
Sri Swayambhu Varasiddi Vinayaka
Swamy Devasthanam
Sri Boyakonda Gangamma Temples
Sri Tataiahgunta Gangamma
Devasthanam
Sri Ardhagiri Veeranjaneya Swamy
Temples
52:

Ass.
Income
14-15 (in
INR)

Cla
ss

50311544 a(ii)
467416345 a(ii)
342998270 a(ii)
47904966 a(ii)
15026767 a(ii)
12974475 a(ii)

LIST OF TEMPLES UNDER ENDOWMENTS DEPARTMENT

e-Pragati Requirements Specification Document Temple Management System Page 198 of


216

ANNEXURE 13 SOFTWARE APPLICATION TESTING &


QUALITY ASSURANCE
Quality Assurance (QA) being termed as several processes across the organisation
for every department and group which are matured to different levels over a period
of time. The Systems Integrator is expected to follow a meticulous Quality
Assurance process as defined by its organisations during all activities and phases of
the complete project duration. However, it is mandatory to check the Government
of Andhra Pradesh policies, standards, guidelines and specifications that are
recommended at all stages always using the latest revisions.
SOFTWARE QUALITY CONTROL (SQC)
The quality control teams should follow a meticulous process for testing. The SQC
leads are expected to participate in bottom up estimates, project planning,
requirements analysis, create test plans and test models, collect test data and run
them in cycles and phases.
The teams are expected to follow a very systematic approach and use appropriate
tools for bidirectional trace-ability including the defect tracking. The tool is expected
to provide end-to-end trace-ability from requirements to defects and vice-versa
(reverse traceability). The traceability has to be achieved at least by mapping the
defects to test cases which in turn are mapped to requirements that are bundled
into sub-modules under modules. As every Business Process is expected to be
achieved by composition of services (Orchestration or Choreography) all such
services have to be mapped to specific requirements. Similarly, it has to be noted
that all non-functional requirements have to be mapped to test cases which in turn
should help to substantiate the SLAs related to Performance, Scalability, Availability,
Security and other criteria as defined in the Section 8.2. Methodology of
development is the decision of the SI. The developed solution should adhere to
industry standards and the principles of e-Pragati.
The quality certification for every intermediate, demo or staging release is expected
to be given based on detailed analysis and necessary reports substantiating the
relevant criterion. Passing or failing requirements based on traceability is
mandatory. Every business process, service, module and sub-module has to be
certified not only based on the requirements that are passed or failed but also the
test cases and the defects still pending. All the senior managers from development,
quality assurance, project management, technical managers and GoAP would
decide whether a version is fit to release based on the reports. TPA is only for the
Security Audit and it does not involve testing the application. Any improved quality
control processes and tools beyond the minimal scope stated above is welcome and
the system integrator will be given further attention during the proposal review.
Different types of testing are anticipated like user interface testing, functional
testing, compliance testing, acceptance testing, smoke testing, integration testing,
systems integration testing, operational readiness testing, performance testing,
load testing, stress testing, pre-production and production testing. All Services and
e-Pragati Requirements Specification Document Temple Management System Page 199 of
216

Business Processes have to be tested in a standalone mode. A brief description of


different types of testing presumed is given below in this section. Please note that in
all such testing defects are raised and they are fixed. However, in production
applications tickets are raised which are addressed in the support mode. Industry
accepted best practices should be used for testing.
Products, Applications (Desktop, Browser or Mobile) and Portals have to be tested
for all the user interface requirements in addition to the functional and nonfunctional requirements as applicable. In all stages and different kinds of testing
wherever possible it is required to use appropriate tools.
User Interface Testing
Graphics harmony, usability, navigation and functionality have to be tested using
the same traceability approach for the appropriate requirements. For repeated
testing of user interface recording, scripts and other techniques and tools are
advised. Standards and policies for graphical design have to be followed and the
same are expected to be tested.
Functional Testing
As a part of the functional testing all the services (granular web services), business
services and business processes are expected to be tested independently in
standalone mode using appropriate tools. All messages (request/response) have to
be tested for requirements including the compliance, security, performance and
other criteria. The products, applications and portals have to be tested for the
functional and non-functional requirements.
Integration Testing
The integration testing is the functional testing for integration requirements. All
requirements for integration between sub-modules, modules, intra-package and
inter-package that are identified during the requirements documentation have to be
tested in this phase.
Systems Integration Testing
The systems that are alien to the developed by the system integrator are to be
tested in this phase. The systems could be other products like CRM, CMS, ERP,
business processes, payment gateways, other government products and other
packages in e-Pragati. All such requirements have to identified/tagged in the
requirements document.
Compliance Testing
All requirements that are cross mapped to specific clauses in a specification, policy
or standard have to be tested in this phase. This testing is expected for all the
clauses that are relevant in a specification, standard or policy for the services,
processes, products, applications and portals. A report on the clauses of the
specification with pass or fail results for compliance is mandatory.

e-Pragati Requirements Specification Document Temple Management System Page 200 of


216

Performance Testing
Performance Testing includes but not limited to load, stress, scalability and
availability testing requirements and related criteria. To meet specific SLAs or
requirements necessary testing tools have to be used to confirm that the results
meet the defined criterion.
Security Testing
At different levels from services to products and applications, security has to be
tested. Services are to be tested not only for licensing, access, authorisation and
other aspects but also for penetration and injections for web, application and
information tiers. User interfaces have to be tested specific security requirements
like URL rewriting, bots and others. Not only the access, authorisation, auditing,
validating, confidentiality, integrity, availability aspects of an application, service,
process, product or portal but also appropriate specifications referred or listed in the
requirements document. All security protocols (SSL, HTTPS), encryptions and other
requirements have to be tested in this phase.
Acceptance Testing
This otherwise called User Acceptance Testing is the testing of the product
owners/stakeholders who validate all functionalities as per the business. Such a
subject matter expert team can also review requirements and can pass or fail using
the User Acceptance Test cases that are usually end to end in nature.
Smoke Testing
The application or services are tested after deployment in its environment to ensure
the application sanctity. Some basic test cases are identified and run to check this.
Operational Readiness Testing
The production ready infrastructure and the environments are tested for its
capacity, size, licenses, upgrades, versions and all other aspects for compatibility
including other systems for integration. All scalability, availability in terms of
redundancy, performance and all such requirements are ensured. In a cloud the
servers and environment procured initially also has to be tested to ensure the
requirements compatibility. Necessary loads may have to be generated using tools
for Scalability testing in a cloud environment.
Pre-Production Testing
This is otherwise called limited user testing. Before taking a release version to
production limited users are identified and rolled out to them to monitor the product
or application. Any fixes required are applied before taking to products.
Production Testing
A full release version is tested with full loads by end users for a limited period. This
is otherwise called the warranty state or stabilisation period.
e-Pragati Requirements Specification Document Temple Management System Page 201 of
216

It is recommend for a solution for automated testing and automated test case
generation. This ensures complete and appropriate test cases are generated,
reducing waste and enhancing application quality, as long as the scope and
coverage of test cases and their results are verified and signed off by PMU.

e-Pragati Requirements Specification Document Temple Management System Page 202 of


216

ANNEXURE 14 - BOM FOR PILOT IMPLEMENTATION OF


TEMPLE MANAGEMENT SYSTEM
The proposed "Smart Temple" solution will be implemented at Sri Durga
Malleswara Swamy Varla Devasthanam, Vijayawada. This will be on pilot
basis. The Hardware has to be delivered at the pilot location in consultation with
the Endowments Department.
A. Bill of material (BOM) for pilot implementation:
Sl.
No.
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.

Item Details

Quantity

All in One Desktops Computer for Ticketing/Billing


Counters
All in One Desktops Computer for Prasadam Counters
All in One Desktops Computer for Accounts
All in One Desktops Computer for Back-end
Administration
All in One Desktops Computer for Hundi Collection
Counter
All in One Desktops Computer for Annadanam
All in One Desktops Computer for Accommodation
Hand-Held Computer for Ticketing
Hand-Held Computer for Accommodation
Compact Bill Printer (Dot Matrix Printer) for Billing
MFP Laser-Jet Printers for Office Use
Ink-Jet MFP Printer for Office Use
Ink-Jet MFP Printer for Hundi Counter
Tablet Computer for Executive Officer
Wi-Fi Access Points to connect PCs, Tablet Computers
& Hand-Held Devices
Biometric System for Ticketing/Billing, Prasadam &
Accommodation counters
Biometric Device for Staff Attendance System
PC Based Ticket Vending Machine for Ticketing/Billing
Counters
5 KV UPS with 2 Hours Back-up for Power backup

TABLE

53:

5
2
8
1
1
1
5
2
5
1
1
1
1
5
11
5
5
1

HARDWARE COMPONENTS FOR DEPARTMENT

B. Specification for Bill of material (BOM) for pilot implementation:


1. All in One Desktops Computer (23 numbers) - For Ticketing/Billing
Counters, Prasadam Counters, Accounts, Back-end Administration,
Hundi Collection Counter, Annadanam & Accommodation
Sl.
No.
1.

Features

Specifications

General Specifications

e-Pragati Requirements Specification Document Temple Management System Page 203 of


216

Sl.
No.

Features
Processor

2.
3.
4.
5.
7.
8.
9.
10.
11.

Specifications
Latest X86 or equivalent, 64-bit based Multi core
processor, with Speck CPU 2006 rating in the
range 140 or above

Memory
RAM
8 GB RAM or Higher
Storage
Hard Disk
500 GB HDD or Higher
Capacity
Platform
Operating System Windows 8.1 Professional or latest
Display
Display
19LED Colour Monitor or Higher
Input Device
Pointer Device
USB Optical Mouse
Keyboard
USB Entry Keyboard
Communication
Ethernet
10/100/1000 Gigabit or Higher
Wireless LAN
Yes
Ports/Slots
4 USB Ports with 2.0 or above , 1 HDMA Port, All other ports are as per
the Industry Norms
Certification
For OEM: ISO 9001:2000 For PC MS Windows and Linux certified.
Certification to be closed EPEAT Gold/ EPEAT India, FCC, ROHS.
Warranty
Comprehensive on-site support during the contract period
TABLE

54:

ALL IN ONE DESKTOPS COMPUTER SPECIFICATIONS

2. Hand-Held Computer (07 numbers) - For Ticketing, & Accommodation


Sl.
No.
1.

Item Details
Processor

2.
3.
4.

Memory
Power
Battery Life

5.

Display

6.

Keyboard

7.
8.
9.
10.

Program Memory
Data Memory
PC Interface
Host System

Specifications
32-bit processor operating at 100MHz or
equivalent
8 MB RAM or higher
Li-Ion, rechargeable battery
Approx. 500 charge-recharge cycles
Charger
Portable, compact AC adaptor
7-inch VGA (video graphics adapter)
128 * 64 Graphical LCD with backlight or higher
30 Key, Alphanumeric, Tactile, 10 million operable
or equivalent
512kb Flash or higher
8 MB(Expandable up to 8 GB)
USB Slave Port
All Standard OS like Windows, Unix, Linux

e-Pragati Requirements Specification Document Temple Management System Page 204 of


216

Sl.
No.
11.
12.
13.
14.

Item Details

Specifications

Size
Printer
Paper Width
Paper Roll
Dimension
Paper Loading
Optional Features

15.
16.
17.

Approx. 24 x 4 x 7.5 cm
24 Col Dot Matrix Printer or higher
Approx. 32/24 characters in a line
Approx. 12 14 meters
Easy Loading
Biometric Module, GPRS Module, Smartcard
Module
0C to 55C

Operating
Temperature
TABLE

55: 8

HAND HELD COMPUTER SPECIFICATIONS

3. Compact Bill Dot Matrix Printer (05 numbers) For Ticketing/Billing


Counters
Sl.
No.
1.
2.

Features

Specifications

Pins
Print Speed (cps)

3.
4.

Input Buffer
Paper Handling

5.

Paper Path

6.
7.

Printer Fonts
Interfaces

8.

MTBF (hrs at 25% duty


cycle)
Copy Capability
Black
Ribbon
Life
(million characters)

9.
10.

TABLE

56:

24
High speed draft 10 / 12
cpi: 300 / 360 cps Draft 10 / 12 / 15 or
equivalent
64 KB or equivalent
Standard Fraction Feed Rear,
Push Tractor Feed Rear
Optional Feeder Rear push tractor and Roll
paper holder
Tractor Rear in, Top out Roll Paper Rear in, Top
out
Bit Map, Indian, Scalable, Bar Code
Bi-directional parallel interface (IEEE-1284
nibble mode supported) USB (ver 2.0 Full
Speed) interface
10000 POH (25% Duty) or equivalent
Original + 2 copies
Minimum 3 million characters (LQ 10 cpi, 48
dots/character)

COMPACT BILL PRINTERS SPECIFICATIONS

4. MFP Laser-Jet Printers (01 numbers) For Office use

e-Pragati Requirements Specification Document Temple Management System Page 205 of


216

Sl.
No.
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.

Features
Functions
Print speed black
Print technology
Print quality black
Paper Size
Tray capacity
Print languages
Connectivity
Compatible
systems
Memory

operating

TABLE

Specification
Print, Copy, Scan
Minimum 15 ppm or higher
Laser Jet
Up to 600 x 600 dpi or higher
A4
Minimum 100
As per industry standards with Telugu
support
USB
Windows 8 or higher / Other Standard OS
Standard 64MB

57: MFP

LASER JET PRINTERS SPECIFICATIONS

e-Pragati Requirements Specification Document Temple Management System Page 206 of


216

5. Ink-Jet MFP Printer (02 numbers) For Office use & Hundi Counter
Sl.
No.
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.

Features
Functions
Print speed black
Print technology
Print quality black
Print languages
Connectivity
Paper size
Tray capacity
Compatible
operating systems
Memory
Scanner
Specification

12.

Copier
Specification

13.

Power
Operating
Environment
Accessories

14.

Specifications

and

TABLE

Print, copy, scan


15 ppm or higher
Ink Jet Black
Up to 300 x 300 dpi or higher
as per industry standards with Telugu support
USB
A4
Min 100 A4 sheets
Windows 8 or Higher All Standard OS
Standard 32MB
Scanner type - Flatbed
Scan file format - JPG, RAW (BMP), PDF, TIFF, PNG
Scan size (flatbed), maximum216 x 297 mm
Copy speed (normal)
Black: Up to 20 cpm
Copy resolution (black text) - Up to 300 x 300 dpi
Copy resolution (colour text and graphics) - Up to
400 x 600 dpi
As per industry standards
Accessories
installation

58:

INK - JET

MFP

as

per

industry

standards

for

PRINTERS SPECIFICATIONS

6. Minimum 8 Tablet Computer with minimum single SIM slot (01


numbers) For Executive officers
Sl.
No.
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.

Features
NETWORK Technology
SIM
DISPLAY Type
Size
Multi-touch
PLATFORM
CPU
MEMORY Card slot
Memory
CAMERA
CAMERA Features
Loudspeaker
Communications

Specification
GSM, HSPA,LTE
Minimum Single SIM slot
IPS LCD capacitive touchscreen, 16M colours
Minimum 8.0 inches
Yes, up to 5 fingers
Android OS v5.0 (Lollipop) or Higher
Quad-core 1.3 GHz or higher
Micro SD, 32 GB or Higher
Internal 8 GB, 1 GB RAM or higher
Primary
5 MP, autofocus
Geo-tagging
Yes, with stereo speakers
WLAN or Higher

e-Pragati Requirements Specification Document Temple Management System Page 207 of


216

TABLE

59: MINIMUM 8

TABLET WITH SIM SPECIFICATIONS

7. Wi-Fi Access Points (05 numbers) To connect PCs, Tablet Computers &
Hand-held devices
Sl.
No.

Parameters

Specifications

Interfaces

10/100/1000 BASE-T autosensing (RJ45)

Powering
Options

As per industry standards

Frequency

Concurrent band 2.4 GHz up to 5 GHz

Wireless

802.11ac, 3x3 multiple-input multiple-output (MIMO) with 3


spatial streams at 5 GHz
802.11n 2x2 multiple-input multiple-output (MIMO) with 2
spatial streams at 2.4 GHz

Operating
modes

Access point mode, Wireless Domain Services bridging,


client bridge mode
TABLE

60: WI -FI

ACCESS POINTS SPECIFICATIONS

8. Bio Metric Device for Ticketing/Billing, Prasadam & Accommodation


counters (11 numbers):
S
l.
1.
2.

Feature

Sensor Type
Prism
Architecture
3. Resolutions
4. Dynamic
Range
5. Image Area
6. Operating
Temperature
Range
7. Humidity
8. Time for
scanning
Fingerprints
9. Distortion
Rate
10. Flat
Fingerprint
capture

Specifications
Optoelectronic
Single Prism
500 ppi or higher
256 Grey Scale
Min 46mm x 46mm
0 to 55 Degree Centigrade

10-90% non-condensing, splash resistance


0.01 sec
0.1%
Dual flat fingerprint capture

e-Pragati Requirements Specification Document Temple Management System Page 208 of


216

S
Feature
l.
11. Certification
12. Operating
System
Requirement
13. Interface
14. Light
Rejection
15. Image
Quality
16. Automatic
Fingerprint
capture
17. Calibration
18. Quality
Check
19. Automatic
change
to the next
finger
20. Rolled
capture
21. Compliance

TABLE

Specifications
As per industry standards
Windows 8 / Windows 10/ Linux
USB 2.0, USB Powered
Should have Ambient Light Rejection
Complies with Standard Image Quality standards
System should detect & capture fingers Automatically
Factory calibrated and sealed with self-test / diagnostics at
start-up
The system issues a message regarding the quality of rolled
and plain fingerprint images prior to capturing next finger.
If the image quality is good, the system offers to scan the next
finger
Capability to allow the fingers to be rolled in a left to right or
right to left direction when taking the rolled impressions
1. Should be standard industry compliant with appropriately
certified.
2. Full Compliance with Wavelet Scalar
3. Quantisation Grayscale Image Compression Specification.
4. Full Compliance with ANSI Data format for the interchange
of Finger Print
5. Full Compliance with IAFIS Image Quality specification (For
Security)

61: SPECIFICATIONS FOR BIOMETRIC DEVICES FOR VARIOUS COUNTERS

9. Bio Metric Device for Staff Attendance System (05 numbers):


S
l.
1.
2.
3.
4.
5.

Feature
Fingerprint
Capacity
Transaction
Capacity
Hardware
Platform
Sensor
Communication

Specifications
1000 templates
100,000
BioAPI 2.0 (ISO/IEC 19784-1:200 Specification / As per
industry standards
Optical Sensor
RS232/485, TCP/IP,USB-host, USB-client

e-Pragati Requirements Specification Document Temple Management System Page 209 of


216

S
l.
6.
7.
8.
9.
10.
11.
12.
13.

Feature
Standard
Functions
Optional
Functions
Display
Power Supply
Operating
Temperature
Operating
Humidity
Dimension
Gross Weight

TABLE

Specifications
SMS, Workcode, DLST, Scheduled-bell, Self-Service Query,
Automatic Status Switch
ID/Mifare/HID,9 digit user ID
Min 3 inches TFT Screen
5V DC 2A
0 - 45
20%-80%
Approx.181X129X51 mm
Approx. 1.50 kg

62: SPECIFICATIONS FOR BIOMETRIC DEVICES FOR STAFF ATTENDANCE SYSTEM

10.
PC Based Ticket Vending Machine (05 numbers) For
Ticketing/Billing Counters
Sl.
No.
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.

Features
Metal Enclosure
Ticket mode
Cash Acceptance
Coin Acceptance
Cash Dispensing
Cash
Dispenser
capacity
Coin Dispensing
Coin
Dispenser
capacity
User Interface
No
of
ticket
selections
All report logs

Specifications
Approximate 1.6mm MS-Powder Coated
Printed Thermal Paper ( Approximately 3 Inch)
INR Notes of All denominations
INR Coins of All denominations
Any denomination of INR 5, 10, 20, 50 or 100
1000 Notes for single cassette or higher
Any denomination of INR 1, 2, 5 or 10
800 Coins or higher
Touch Screen Monitor
20 configurable through password protected
Admin Menu or higher
Available through password protected Admin
Menu
Approximately 180 W

Power
Consumption
Power Supply
150V to 230V AC, 50Hz
Protocol
RS-232
Interfaces
LAN Port, Bluetooth, WiFi
Battery Back up
UPS
Operating
Ambient
Environment
TABLE 63: PC BASED TICKET VENDING MACHINE SPECIFICATIONS

e-Pragati Requirements Specification Document Temple Management System Page 210 of


216

11.
Sl.
No
.
1
2
a
b
c
d
e
3
a
b
c
d
e
f
g
4
a
b
c
d
e
5
a
b
c
d

5 KV UPS with 2 Hours Back-up (01 numbers)

Parameter
Capacity
Input
Parameters:
Voltage
Voltage Range
Frequency
Power Factor at
rated load
Harmonic
Distortion(THD)
Output
Parameters:
Voltage

Specifications
5 KVA

220 V, 1-phase, 3 wire


160 to 300VAC
50 Hz+/- 5%
>0.99
< 5%

220VAC / 230VAC / 240VAC+/- 1%, 1phase

Frequency
Current Harmonic
Distortion
Overload rating
Output waveform
Crest Factor
Power Factor
Battery
Parameters:
Type

50 Hz
Less than 5%

VAH
Polarity Protection
for
Battery
connection
Battery Rack &
Connectors
Charger

15600 VAH
Should be provided

Other Features:
Display
Communication
Port
Isolation
Transformer
Compatibility

125% for 10 min., 150% for 1 min.


Pure sinewave
3:1 max.
0.8 pf

Sealed Maintenance Free Batteries (Exide Power safe /


Numeric/ Amararaja)

Powder coated battery rack/Stand to be provided


Built-in solid state
automatic boost

float-cum-boost

charger

with

LCD display for status/fault information


RS 232,SNMP
In built Galvanic Isolation transformer
Should be Generator Compatible

e-Pragati Requirements Specification Document Temple Management System Page 211 of


216

Sl.
No
.
e

Parameter
Credential

Protection:

Intelligent
Fan
Operation
Technical
Data
Sheet:
TEST REPORT

h
i

TABLE

Specifications
ISO 9001, ISO 14001 & ISO 18001 & CE Certified.
Should furnish BIS Number
All critical source and sensitive loads should have
protection from transients, Advanced Electronic
Protection for device safety for rectifier and Inverter,
Built-in Overload protection, from short Circuits (OVCD)
Should be provided
Bidders should submit the Technical Data sheet for
proposed model with complete required details.
The bidder should enclose NTH test report and CE
certificate. STQC/BIS, ISO 9001:2000 CERTIFICATIONS
DIS Standard Certifications are ETDC/ SAMEER/
NISC/ISO 90001, ISO 140001, ISO OHSAS18001 enclose.

64: 5 KV

UPS WITH

HOURS BACK - UP SPECIFICATIONS

Note: The batteries should be replaced with the VAH go down below 50% during the
entire contract period and also at the exit management

e-Pragati Requirements Specification Document Temple Management System Page 212 of


216

ANNEXURE 15 - GLOSSARY
Name
AC
AG
API
APTS
AWF
B2G
BCP
BGP
BOM
BPR
BYOD
C2G
CapEx
CCTV
CFMS
CGF
CLGS
CLI
CMS
COTS
CRM
CRUD
DC
DD
DLL
DR
EMD
EMS
EPABX
ePI
ePRS
ERP
ETL
FAQ
FMS
FRS
G.O
G2B

Description
Assistant Commissioner
Audit General
Application Program Interface
Andhra Pradesh Technology Services
Archakas Welfare Fund
Business to Government
Business Continuity Plan
Border Gateway Protocol
Bill of Material
Business Process Re-engineering
Bring Your Own Device
Citizens to Government
Capital Expenditure
Close Circuit Television
Comprehensive Finance Management System
Common Good Fund
Certificate-Less Governance System
Calling Line Identification
Content Management System
Commercial off the Shelf
Customer relationship management
Create/Read/Update/Delete
Deputy Commissioner
Demand Draft
Dynamic Link Library
Disaster Recovery
Earnest Money Deposit
Enterprise Messaging System
Electronic Private Automatic Branch Exchange
e-Pragati Indicators
e-Pragati Requirements Specification
Enterprise Resource Planning
Extraction Transformation and Loading
Frequently Asked Questions
Financial Management System
Functional Requirements Specification
Government Order
Government to Business

e-Pragati Requirements Specification Document Temple Management System Page 213 of


216

Name
G2C
G2G
GIS
GoAP
GPF
GPRS
GSM
GUI
HA
HBA
HDD
HLD
HoD
HQ
HR
HRMS
HSPA
HTML
IA
IAM
IEEE
IoT
IP
IPN
ISMS
ISO
ISP
ITE&C
ITIL
IVRS
JCB
KPI
LAN
LCD
LDAP
LED
LLD
LTE
MADP
MCA
MDDS
MIS

Description
Government to Citizens
Government to Government
Geographic Information System
Government of Andhra Pradesh
General Provident Fund
General Packet Radio Service
Global System for Mobile communication
Graphical User Interface
High Availability
House Building Allowance
Hard Disk Drive
High Level Document
Head of Department
Head Quarter
Human Resources
Human Resources Management System
High Speed Packet Access
Hyper Text Mark-up Language
Implementing Agency
ID entity and Access Management
Institute of Electrical and Electronics Engineers
Internet of Things
Internet Protocol
Instant Payment Notification
Information Security Management System
International Organisation for Standardisation
Internet Service Provider
Information Technology, Electronics & Communications Department
Information Technology Infrastructure Library
Interactive Voice Response System
Japan Credit Bureau
Key Performance Indicators
Local Area Network
Liquid Crystal Display
Lightweight Directory Access Protocol
Light Emitting Diode
Low Level Document
Long Term Evolution
Mobile Application Development Platform
Motor Car Allowance
Metadata and Data Standards
Management Information Systems

e-Pragati Requirements Specification Document Temple Management System Page 214 of


216

Name
MPLS
MTBF
NAC
NAS
NGO
NOFN
NVR
O&M
OEM
OpEx
OTP
OWASP
PDA
PDS
PMU
POC
PTZ
QA
QR
RAM
RDBMS
REST
RFP
RTM
RTO
RTP
SD
SDC
SI
SITA
SLA
SMAC
SME
SOA
SOAP
SOP
SPOC
SQC
SQL
SRDH
SRS
SSO

Description
Multiprotocol Label Switching
Mean Time Between Failures
Network Access Control
Network Attached Storage
Non-Government Organisation
National Optical Fiber Network
Network Video Recorder
Operation and Maintenance
Original Equipment Manufacturer
Operation Expenditure
One Time Password
Open Web Application Security Project
Personal Digital Assistant
Public Display System
Project Management Unit
Proof of Concept
Pan Tilt Zoom
Quality Assurance
Quick Response
Random Access Memory
Relational database management system
Representational State Transfer
Request for Proposal
Reverse Traceability Matrix
Recovery Time Objective
Real Time Transport Protocol
Secretariat Department
State Data centre
System Integrator
State Institute of Temple Administration
Service Level Agreement
Social, Mobile, Analytics and Cloud
Subject Matter Expert
Service Oriented Architecture
Simple Object Access Protocol
Standard Operating Procedures
Single Point of Contact
Software Quality Control
Structured Query Language
State Resident Data Hub
System Requirement Specifications
Single Sign On

e-Pragati Requirements Specification Document Temple Management System Page 215 of


216

Name
SWAN
TA
TM
TMS
UAT
UI
ULB
UML
USB
USSD
VGO
VIP
VPC
VPN
VQC
WCAG
XSS
YoY

Description
State Wide Area Network
Travel Allowance
Temple Management
Temple Management System
User Acceptance Testing
User Interface
Urban Local Body
Unified Modelling Language
Universal Serial Bus
Unstructured Supplementary Service Data
Video Graphics Output
Very Important Person
Amazon Virtual Private Cloud
Virtual Private Network
Visual Quick Code
Web Content Accessibility Guidelines
Cross-site scripting
Year on Year

*** End of document ***

e-Pragati Requirements Specification Document Temple Management System Page 216 of


216