ePRS TMS V9.2 30042016

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.

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.

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
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

216
9.4
9.5
TRAINING NEED..................................................................................................... 95
CHANGE MANAGEMENT.......................................................................................... 96

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

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
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

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.
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.

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.

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

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.

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

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.
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

of 216
Page

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

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
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.

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:

of 216
Page
FIGURE
2:
INTEGRATED VIEW OF ENDOWMENTS DEPARTMENT
Given below are the key objectives of the Temple Management System
departments.

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
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.
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
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

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
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

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

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
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.
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
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
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

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

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)

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,

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:
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%

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.

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.
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.

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.

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.
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
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,

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.

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

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

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

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

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,

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.

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.

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
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

of 216
Page
Sl.
No
.
Phase
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

of 216
Page
Sl.
No
.
Phase
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
of 216
Page
Sl.
No
.
Phase
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

of 216
Page
Sl.
No
.
Phase
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
of 216
Page
Sl.
No
.
Phase
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.

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.

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.

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.
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
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.

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

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.
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

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.

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

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

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

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

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.

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.

of 216
Page

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)

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.
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
be done.
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
and Darshanam,
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
and Darshan,
Kalyankatta,
be done.
Annadanam, Pilgrim
Information
management, Pilgrim
tracking, Call centre,
Complaints
management
Information services
Accommodation module
8
Type of rooms and
TMS008
Accommodation
amenities provided
module,
l
information within 5
minutes.
9
Room Allotted /
TMS009
Accommodation
Location
module,
l/
Transactional information within 5
minutes.
10
Confirmation for the
TMS010
Accommodation module Informationa Registered User should be
Caution Deposit
l/
Refund
Transactional
minutes.
minutes.
minutes.
minutes.
minutes.
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

minutes.
Tonsuring
17
Tonsurer allotted
TMS017
Kalyankatta module
Informationa
l/
Transactional

minutes.
TMS018
Transport Management
Informationa
l/

15
Transport
18
Tour Packages Places covered,
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
minutes.
minutes.
minutes.
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

minutes.
TMS022
Finance and Accounts
Informationa
l

minutes.
TMS023
Transactional

minutes. Donation must be
done
TMS024
Queue Management
Informationa
l
TMS025
Queue Management
Informationa
l
TMS026
Queue Management
Informationa
l

minutes.
minutes.
minutes.
TMS027
Accommodation
module,
Informationa
l/

Room management
module
Transactional
minutes.
Services for Privileged donors

28
Account
TMS028
management for
Donors for the
services availed per
year
29
Booking for a
TMS029
Darshanam
Transaction
al
Transaction
al
TMS030
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
Transaction
al
33
Purchase of Laddu
Coupon
TMS033
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
be done.
be done.
be done.
be done.
be done.
be done.
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.
minutes.

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.
on real-time basis.
the Information instantly on
real-time basis
User should be able to access
on real-time basis.
the information in the Portal
4
5
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

the required information in
portal and transact within 3
minutes.
portal within 3 minutes.
portal within 3 minutes.
portal on real-time basis
portal within 3 minutes
and allocate the slots
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
the required information and
process in portal within 3
minutes
the required information and
apply in portal within 3
minutes
and get the required
information and apply in
and get the required
information in portal within
1 minutes
TEMPLE M ANAGEMENT S YSTEM
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

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/).

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.

216
FIGURE
10: Conceptual Data Model for TMS
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

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.

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

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

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.

216
7.6.
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)
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.
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
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
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.
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
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.
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
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:

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

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

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

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:

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

216
Sl.
No.
3.
Security
Layer
Infrastructur
e
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.

216
Sl.
No.
Security
Layer
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:

216
FIGURE
13:
ACCESS CONTROL MECHANISM OF
TMS
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.

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.

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

216
cost shall be borne by SI.

TABLE
28:
INDICATIVE TRAINING REQUIREMENTS

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
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

216
Sl.
No.
Training Modules
Training - Front Office

Support Module
System Applications
Training- Integrated
Application Module
System Applications
Training- Departmental
process Module
System Applications
Training- MIS Reports
Target Audiences

Department - 50

Department - 50
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:
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

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.

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

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.
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,

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.
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.
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.

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
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
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.
integration.
The
Department
staff
shall
leverage this e-Pathakam
for defining the various
schemes
pertaining
to
Temples and manage the
same.
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.
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

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
integration.
The
Department
staff
shall
leverage
this
CFMS
application for managing
the finance and accounted
related functionality.
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.
platform.
The
Email
gateway pertaining to ePragati system needs to be
sending
SMS
and
notifications
to
the
registered Pilgrims and
who have subscribed for
Alerts.
The Department shall
facilitate the SI with the
SMS Gateway.
platform.
The
Email
gateway pertaining to ePragati system needs to be
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)

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

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

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.

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

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

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:

216
FIGURE
1.2
15:
AS - IS ASSESSMENT OF ASSESSABLE INCOME
To-Be Assessment of Assessable Income:

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:

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

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

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

216

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:

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

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.

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.

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.

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.

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.

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.

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.

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

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.

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

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

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 &

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
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

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

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
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

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

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

216
12

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

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

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

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.

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

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
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

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

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
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

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

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

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

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

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

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

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

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.

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

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

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

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
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

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

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

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.

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.

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

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

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
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

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.

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

216
FIGURE
22:
TO - BE ROOM BOOKING APPLICATION FORM

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

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

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

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

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.

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.
captured during the assessment of temples by
authorities from the temples periodically.
w.r.t. number of pilgrims participated for Annadanam,
donation received for Annadanam.
w.r.t. No. of pilgrims provided health services by the
management of temples or institutions
w.r.t. amount spent on Vidyadanam and other
facilities provided for pathasalas, scholarship given.
TABLE
44:
EPIS OF
TMS

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

216

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

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

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

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)

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

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)

216
Sl.
No.
District
54
Anantapur
55
Chittoor
56
57
Chittoor
Chittoor
58
Chittoor
59
Chittoor
TABLE

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

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
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.

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.
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.

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

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

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

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

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

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
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

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
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

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

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

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

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

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

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

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 ***

216

ePRS TMS V9.2 30042016

Diunggah oleh

Informasi Dokumen

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

ePRS TMS V9.2 30042016

Diunggah oleh

Hak Cipta:

Format Tersedia

INFORMATION TECHNOLOGY, ELECTRONICS &

REQUEST FOR PROPOSAL

Andhra Pradesh Technology Services

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

Proprietary & Confidential

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

This RFP is meant to invite proposals from interested companies capable

Volume I: Functional, Technical and Operational Requirements

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

Volume III: Contractual and Legal Specifications

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

e-Pragati Requirements Specification Document

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

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

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

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

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

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

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

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

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

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

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

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

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

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

e-Pragati Requirements Specification Document Temple Management System

1. e-Pragati Program Requirements

e-Pragati Requirements Specification Document Temple Management System

1.3. Value Proposition of e-Pragati

e-Pragati Requirements Specification Document Temple Management System

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

1.4. Mandatory principles of e-Pragati

e-Pragati Requirements Specification Document Temple Management System

e-Pragati Requirements Specification Document Temple Management System

Principle #8: Build Once, Use Many Times

e-Pragati Requirements Specification Document Temple Management System

1.5. Common Mandatory Standards of e-Pragati

1.6. Numbering and Naming Conventions

The following guidelines may be noted in this regard:

A comprehensive table called Object Code Table has to be

GoAP will publish the naming and numbering

OBJECT CODE TABLE

e-Pragati Requirements Specification Document Temple Management System

e-Pragati Requirements Specification Document Temple Management System

2. Overview of the domain

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

Annual Income above Rs.25 Lakhs

The Temple Management System serves the following departments, institutions

Name of the Department/ Agency

e-Pragati Requirements Specification Document Temple Management System

Name of the Department/ Agency

State Institute of Temple Administration

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

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

Name of the Department/

Sri Brahmaramba Mallikarjuna

Sri Veeravenkata Satyanarayana

Sri Durga Malleswara Swamy

USER DEPARTMENTS / TEMPLES

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

e-Pragati Requirements Specification Document Temple Management System

At a broader level Endowments Department comes under Revenue Group

INTEGRATED VIEW OF REVENUE GROUP DEPARTMENTS