info tech corporation of goa ltd (a government of goa ... · rfp for selection of system integrator...

Info Tech Corporation of Goa Ltd

(A Government of Goa undertaking)

(An ISO 9001-2008 Certified Company)

Above Alcon Hyundai Showroom, 3rd

floor, NH 17, Porvorim – Bardez, Goa.

NOTICE INVITING TENDER

(Electronic Mode Only)

RFP No : ITG-IT/RFP/e-District/2013/01 dated : 7th

January 2014

Info Tech Corporation of Goa Ltd (ITG), ( A Government of Goa Undertaking) , on behalf of

Department of Information Technology, Government of Goa , invites e-tenders from well

established and reputed bidders for “IMPLEMENTATION E-DISTRICT MMP IN THE

STATE OF GOA”

RFP details consisting of three volumes namely VOL I , VOL II and VOL III and terms and

conditions and tender form containing all the details can be obtained (downloaded) from the e-

tender site.

Other Important Details

Sr No

Item

Particulars

1 Description of the work IMPLEMENTATION OF E-DISTRICT MMP

IN THE STATE OF GOA

2 Mode of Tendering E-Tendering

3 E-Tendering Website www.etender.goa.gov.in or

www.tenderwizard.com/GOA

4 Tender Document Fee Rs 8000/- Rupees Eight thousand only (Non-

Refundable)

5 Tender Processing Fee Rs 2000/- Rupees Two thousand only (Non-

Refundable)

http://www.etender.goa.gov.in/

http://www.tenderwizard.com/GOA

6 Mode of Tender Document

& Processing Fees

Demand Draft drawn in favour of Info Tech

Corporation of Goa Limited, payable at Panaji

7 Earnest Money Deposit

(E.M.D.)

Rs. 25 Lakhs (Rupees Twenty Five Lakhs) in

the form of Demand draft from nationalized or

scheduled bank payable to Info Tech Corporation

of Goa Ltd at Panaji OR in the form of Bank

Guarantee from the nationalized or scheduled bank

in appropriate format.

8 Date and Time for request

of Online Tender

Document

Upto 31-01-2014 upto 3pm

9 Last Date and Time for

Online submission of bids

31-01-2014 upto 4 pm

10 Last date of submission of

pre bid queries

15-01-2014 upto 4 pm

Email : [email protected]

11 Reply to pre bid queries 17-01-2014 by 4 pm through email

12 Date , time and venue of

pre bid meeting

16-01-2014 at 3 pm

Venue: Department of Information Technology,

2nd

floor, Above Alcon Hyundai showroom,

Porvorim – Bardez – Goa

13 Date and Time for opening

of Eligibility & Technical

bids and Venue

31-01-2014 at 4.30 pm

Venue: Department of Information Technology,

2nd

floor, Above Alcon Hyundai showroom,

Porvorim – Bardez – Goa.

14 Date and Time for opening

of commercial bids

Shall be intimated to the successful technical

bidders in due course of time.

15 Contact details Address

Managing Director


Above Alcon Hyundai Showroom,

3rd

Floor, NH 17, Porvorim, Bardez

Goa –403 501

Telephone : (0832) 2416024 / 2415192

Tenders not conforming to the requirements mentioned above and as laid down in the terms and

conditions or not accompanied by EMD in the form prescribed at the time of opening of the

technical bid are liable to be summarily rejected. The decision of The Managing Director, Info

Tech Corporation of Goa Ltd, for purpose of Eligibility & Technical Qualification / Commercial

Bid shall be final and binding to all the tenderers / bidders.

Bidders who wishes to participate in this RFP should have valid digital signature ( Class III) and

should register on the e-tendering portal for participation in the RFP if not registered yet.

For any of the assistance regarding participation in the e-Tender contact on 8888636107 ,

8975223717, 8600651553, 8554878738, 9657381294, 9096891274, 9686115323 , 9890693964

and 9049600090 or email: [email protected]

For and on behalf of Info Tech Corporation of Goa Ltd

Sd/-

Managing Director

mailto:[email protected]

RFP for Selection of System Integrator for State-wide roll-out of eDistrict MMP – Goa – Volume I

State-wide rollout of the eDistrict MMP 1 | P a g e


On behalf

Of

Department of Information Technology

Government of Goa

REQUEST FOR PROPOSAL

FOR

SELECTION OF SYSTEM INTEGRATOR

FOR

ROLL-OUT OF e- DISTRICT MMP - GOA

VOLUME I

Ref No: ITG-IT/RFP/e-District/2013/01 dated 7th January 2014


A Govt. of Goa Undertaking

(An ISO 9001:2008 certified company)

4th Floor, Above Alcon Hyundai Showroom,

Porvorim, Bardez, Goa – 403501



Table of Contents 1 Introduction .......................................................................................................................................... 6

2 Schedule of Bid Process ....................................................................................................................... 7

3 Structure of the RFP ........................................................................................................................... 10

4 Background Information ................................................................................................................... 11

4.1 Project Background ......................................................................................................................... 11

4.2 State Information ............................................................................................................................. 11

4.3 Key Information .............................................................................................................................. 16

4.4 About Info Tech Corporation of Goa (ITG) ................................................................................. 18

5 Instructions to the Bidders ................................................................................................................ 20

5.1 General .............................................................................................................................................. 20

5.2 Compliant Proposals / Completeness of Response ................................................................... 20

5.3 Pre-Bid Meeting & Clarifications .................................................................................................. 20

5.4 Key Requirements of the Bid ......................................................................................................... 22

5.5 Preparation and Submission of Proposal .................................................................................... 23

5.6 Evaluation Process .......................................................................................................................... 24

6 Criteria for Evaluation ....................................................................................................................... 25

6.1 Pre-Qualification Criteria ............................................................................................................... 26

6.2 Technical Qualification Criteria .................................................................................................... 30

6.3 Commercial Bid Evaluation ........................................................................................................... 38

7 Appointment of System Integrator .................................................................................................. 39

7.1 Award Criteria ................................................................................................................................. 39

7.2 Right to Accept Any Proposal and To Reject Any or All Proposal(s) ..................................... 39

7.3 Notification of Award .................................................................................................................... 39

7.4 Contract Finalization and Award ................................................................................................. 39

7.5 Performance Guarantee .................................................................................................................. 39

7.6 Signing of Contract ......................................................................................................................... 40

7.7 Failure to Agree with the Terms and Conditions of the RFP .................................................... 40

8 Project Plan.......................................................................................................................................... 40

9 Payment Schedule .............................................................................................................................. 40



10 Annexure ............................................................................................................................................. 41

Annexure I: TECHNICAL BID TEMPLATES ......................................................................................... 41

Form 1: Undertaking on Total Responsibility ......................................................................................... 42

Form 2: Particulars of the Bidder .............................................................................................................. 43

Form 3: Bank Guarantee for Earnest Money Deposit ........................................................................... 44

Form 4A: Compliance Sheet for Pre-Qualification Proposal ................................................................ 46

Form 4B: Compliance Sheet for Technical Proposal ............................................................................... 50

Form 5: Letter of Proposal .......................................................................................................................... 54

Form 6: Project Citation Format ................................................................................................................ 55

Form 7: Proposed Solution ......................................................................................................................... 56

Form 8: Proposed Work Plan ..................................................................................................................... 57

Form 9: Team Composition ....................................................................................................................... 57

Form 10: Curriculum Vitae (CV) of Key Personnel ................................................................................ 58

Form 11: Deployment of Personnel .......................................................................................................... 60

Form 12: Manufacturers'/Producers‟ Authorization Form .................................................................. 61

Form 13: Declaration on Source Code and Intellectual Property Rights ............................................. 63

Form 14: Undertaking on Patent Rights ................................................................................................... 64

Form 15: Undertaking on Compliance and Sizing of Infrastructure ................................................... 65

Form 16: Undertaking on Service Level Compliance ............................................................................. 66

Form 17: Undertaking on Deliverables .................................................................................................... 67

Form 18: Undertaking on Support to Third Party Solution acceptance and certification ................ 68

Form 19: Declaration of activities sub-contracted .................................................................................. 69

Form 20: Undertaking on Exit Management and Transition ................................................................ 70

Form 21: Declaration that the bidder has not been blacklisted............................................................. 71

Form 22: Particulars of the Bid Cover Letter ........................................................................................... 72

Form 23: Undertaking on Conflict of Interest ......................................................................................... 74

Form 24: Non-Malicious Code Certificate ............................................................................................... 75

Form 25: Undertaking on Clarifications sent to ITG .............................................................................. 76

Form 26: Undertaking on Training the Users .......................................................................................... 77

Form 27: Undertaking on Support to Certification ................................................................................ 78

Form 28: Undertaking on Changes to the contract clauses ................................................................... 79



Form 29: Self Declaration ........................................................................................................................... 80

ANNEXURE II: FINANCIAL PROPOSAL TEMPLATE ....................................................................... 81

Form 1: Covering Letter ............................................................................................................................. 81

Financial Proposal to be submitted through online mode only ........................................................... 83

Details of Financial Bid ............................................................................................................................... 84

ANNEXURE III: TEMPLATE FOR PBG .................................................................................................. 89

Form 1: Performance Bank Guarantee ..................................................................................................... 89

ANNEXURE IV: TEMPLATE FOR CCN ................................................................................................. 91

Form 1: Change Control Notice (CCN) Format ...................................................................................... 91

ANNEXURE V: Details of horizontal connectivity through GBBN. .................................................... 93

ANNEXURE VI: Functional Requirement Specifications...................................................................... 99



List of Abbreviation

Abbreviation Description

AMC Annual Maintenance Contract

CDAC Centre for Development of Advanced Computing

CFC Citizen facilitation Centers

CMS Content Management System

CSP Content Service Provider

DD Demand Draft

DeitY Department of Electronics and Information Technology

DoIT/DOIT Department of Information Technology, Goa

DOP Directorate of Panchayat

EC Empowered Committee

EMD Earnest Money Deposit

ESO Extended Service outlets

GBBN Goa Broad Band Network

GoI/GOI Government of India

ITG Info Tech Corporation of Goa Limited

MCIT Ministry of Communication and Information Technology

MMP Mission Mode Project

NeGP National e-Governance Plan

NIC National Informatics Centre

NPI National Portal of India

PoP Point of Presence

RFP Request for Proposal

SDC State Data Centre

SeMT State e-Governance Mission Team

SI System Integrator

SLA Service Level Agreement

SPF State Portal Framework

SSDG State Services Delivery Gateway

SWAN State Wide Area Network

UT Union Territory



1 Introduction

I. Under the eDistrict MMP National Roll-out, System Integrator will be responsible

for providing a comprehensive solution towards Supply, Installation,

Development, Integration, Commissioning, Management & Maintenance of

Application and Computing Infrastructure pertaining to eDistrict in various States

as per DeitY Guidelines.

II. Info Tech Corporation of Goa Ltd (ITG) is appointed as SDA for this project and

ITG on behalf of Department of Information Technology, Goa invites the eligible

parties (hereafter referred as “Bidder / SI”) for appointment as System Integrator

for Goa and provide the comprehensive solutions for implementation of eDistrict

MMP.

III. Bidders are advised to study this RFP document carefully before submitting their

proposals in response to this notice. Submission of a proposal in response to this

notice shall be deemed to have been done after careful study and examination of

this document with full understanding of its terms, conditions and implications.

Failure to furnish all information required as mentioned in the RFP documents or

submission of a proposal not substantially responsive to the RFP documents in

every respect will be at the bidder's risk and may result in rejection of the proposal.

IV. All proposals submitted in response to the RFP document must be accompanied by

an EMD of Rs. 25 Lakhs only in the form of a bank guarantee/Demand draft from

nationalized or scheduled banks

V. Bids submitted without adequate EMD will be rejected summarily.



2 Schedule of Bid Process

S. No Information Details

1. RFP No. and Date RFP No.: ITG-IT/RFP/eDistrict/2013/01 Date: 7th January 2013

2. Last date & time for

submission of written queries

for clarifications through email

Date: 15-01-2014

Time: upto 4 pm

Email : [email protected]

3. Date, place & time of pre-bid

conference

Date: 16-01-2014

Time: 3 pm

Place: Conference hall, 2nd floor Dept. of

Information Technology, Above Alcon Hyundai ,

Porvorim, Bardez, Goa

4. Release of response to

clarifications by email

Date: 17-01-2014

Time: by 4 pm through email

5. Bid validity period 180 days from the date of submission of the tender

6. Last date, time & place for

submission of bids

Date: 31-01-2014

Time: before 4 pm

Place: Info Tech Corporation of Goa Ltd. , 4nd floor, Above Alcon Hyundai , Porvorim, Bardez, Goa

7. Date, time & place of opening

of technical bid

Date: 31-01-2014

Time: 4.30 pm

Place: Conference hall, 2nd floor Dept. of Information Technology, Above Alcon Hyundai , Porvorim, Bardez, Goa

8. Date, time & place of technical

presentation by the bidder

Shall be intimated to the bidders satisfying the

prequalification criterias.

Place: Conference hall, 2nd floor Dept. of

Information Technology, Above Alcon Hyundai ,

Porvorim, Bardez, Goa

9. Place, Time and Date of

opening of Financial bid

Shall be intimated to technically qualified bidder

10. Contact person for queries Umakant S Naik

Manager ( IT)

Phone: 0832- 2416024

Email: [email protected]

11. Addressee and address at

which proposal in response to

RFP notice is to be submitted:

Mr. Nilesh Fal Dessai

Managing Director

Info Tech Corporation of Goa Ltd. , 4nd floor,



Above Alcon Hyundai , Porvorim, Bardez, Goa

12. Tender document fees

Rs 8000/- (eight thousand only) in the form of

demand draft from nationalized/ scheduled banks

in favour of Info Tech Corporation of Goa Ltd.

Payable at Panaji , Goa

13. Tender processing fees Rs 2000/- (two thousand only) in the form of

demand draft from nationalized/ scheduled banks

in favour of Info Tech Corporation of Goa Ltd.

Payable at Panaji, Goa

14. Availability of Tender Documents

Tender documents can be downloaded from For the detailed tender notice, please visit our website

http://www.etender.goa.gov.in or http://www.tenderwizard.com/goa

The bidders are expected to examine all instructions, forms, terms, project requirements and other information in the RFP documents. Failure to furnish all information required as mentioned in the RFP documents or submission of a proposal not substantially responsive to the RFP documents in every respect will be at the bidder's risk and may result in rejection of the proposal and forfeiture of the bid

15. Registration of vendors The bidders are required to get registered with

http://www.etender.goa.gov.in (if not registered). The intending bidder must have valid digital signature to submit the bid.

16. EMD Earnest money deposit of Rs. 25,00,000/- (Twenty

Five Lakhs Only) in the form of Demand Draft OR Bank Guarantee (in the format specified in Form 3 issued by any scheduled bank/ nationalized bank in favour of the Info Tech Corporation of Goa Ltd payable at Panaji, Goa

Copies of DD or bank guarantee shall be scanned and uploaded to the e-tendering website within the period of tender application submission and the originals to be deposited in the office of the Info tech Corporation of Goa Ltd on or before the tender submission date along with technical bid in a sealed envelope.

Note :

All the three demand drafts towards EMD, Cost of Tender Document and the Tender processing fee

shall be placed in single envelope superscripted as ‘Earnest Money cost of tender documents and cost


http://www.tenderwizard.com/goa




of tender processing fee’ with the name of Project and the due date of opening of the bid mentioned

and to be submitted to the office of Info Tech Corporation of Goa Ltd, Porvorim on or before the

tender submission date along with hard copy of technical bid.

Note : The training on e-tender software shall be held on 20/01/2014 at 3pm at the conference hall of Department of Information Technology , 2nd floor, Above Alcon Hyundai showroom, Porvorim, Bardez – Goa. Interested bidders should submit their names through email to [email protected] before 17/01/2014 for the e-tendering training.

mailto:[email protected]



3 Structure of RFP

I. Info Tech Corporation of Goa Ltd. (ITG), Goa (hereafter referred as “ITG”) invites

bids from eligible parties (hereafter referred as “Bidder”) for appointment as System

Integrator for Goa on behalf of Dept. of Information Technology for implementation

of eDistrict MMP for Govt. of Goa.

RFP Consists of 3 Volumes

A. Volume I: Instructions on the Bid process for the purpose of responding to

this RFP. This broadly covers:

General instructions for bidding process

Bid evaluation process including the parameters for Technical

evaluation and commercial evaluation to facilitate ITG in

determining bidder‟s suitability as the implementation partner

Payment schedule

Commercial bid and other formats

B. Volume II: Functional and Technical Requirements of the project. The

contents of the document broadly cover the following areas:

About the project and its objectives

Scope of work for the SI

Functional and Technical requirements

The bidder is expected to respond to the requirements as completely and in

as much relevant detail as possible, and focus on demonstrating bidder‟s

suitability to become the SI of ITG.

C. Volume III: Master Service Agreement (MSA), Service Level Agreement

(SLA) and Non-Disclosure Agreement (NDA).

Project Plan /Schedule

Service levels for the implementation partner

The bidders are expected to examine all instructions, forms, terms, Project requirements

and other information in the RFP documents. Failure to furnish all information required as

mentioned in the RFP documents or submission of a proposal not substantially responsive

to the RFP documents in every respect will be at the bidder's risk and may result in

rejection of the proposal.



4 Background Information

4.1 Project Background

I. NeGP was approved by the Government of India in May 2006, with the following

vision:

“Make all Government Services accessible to the common man in his locality,

through common service delivery outlets and ensure efficiency, transparency

and reliability of such services at affordable costs to realise the basic needs of the

common man”.

II. To realize this vision, 31 Central, State and Integrated Mission Mode projects

(MMPs) along with 8 support components were identified and approved under

NeGP. States have been given flexibility to identify up to 5 additional state-specific

projects, which are particularly relevant for the economic development of the State.

NeGP also envisages creation of the core IT infrastructure in the form of SWAN,

SDC and one lakh front ends namely CSCs in rural areas across the country to

deliver public services electronically.

III. EDistrict is one of the 31 MMPs under NeGP, with the Department of Electronics

and Information Technology (DeitY), Government of India (GoI) as the nodal

department, to be implemented by State Government or their designated agencies.

This MMP aims at electronic delivery of identified high volume citizen centric

services, at district and sub-district level. To achieve these objectives service levels

and outcomes for each of these services will be clearly laid down by the State

concerned, with a view to improving the efficiency and effectiveness of the service

delivery. The MMP envisages leveraging and utilizing the four pillars of e-

infrastructure namely, State Data Centers (SDCs), State Wide Area Network

(SWANs), State Service Delivery Gateways (SSDGs) and Common Service Centers

(CSCs), optimally to deliver public services electronically to citizens at their door

steps. Initially only those high volume citizen-centric services will be taken up for

implementation which have high priority for the State. New services will be added

to the portfolio subsequently, once the demand for the initial set of e-enabled

services increases.

IV. Detailed scope of work is provided in volume II of this RFP.

4.2 State Information

Goa, a tiny emerald land on the west coast of India, and the 25th State in the Union of India,

was liberated from Portuguese rule in 1961. It was part of the Union Territory of Goa, Daman &

Diu till 30th May 1987 when it was carved out to form a separate State. Goa, for the purpose of

revenue administration is divided into two districts viz. North and South Goa with

headquarters at Panaji and Margao respectively.



The State comprises of 12 Talukas and for the purpose of implementation of development

programmes the State is divided into 12 community development blocks. The district of North

Goa comprising six Talukas has a total area of 1,736 sq. km., and South Goa comprising six

Talukas has an area of 1,966 sq. km. In all, there are 383 villages of which 233 are in North Goa

and 150 in South Goa. There are also a total of 14 Municipalities and 190 Panchayats in Goa.

There are 86 Government departments in Goa and e-Governance projects have been initiated in

most of these departments with application software hosted centrally in the State Data Centre.

IT infrastructure has been setup in most departmental offices and connected through the Goa

Broad Band Network (GBBN) to the State Data Centre (SDC). Department of IT has also

initiated multiple e-Governance projects and MMPs in the State to further strengthen its

commitment to take Goa ahead in the path of e-Governance.

The Government of Goa envisages the eDistrict project as an important milestone in the State‟s

e-Governance implementation programme, in which majority of the G2C and G2G services

would be delivered by the District Administration leveraging Information & Communication

Technology through a single service delivery window. It is proposed that the Extended Service

Outlets/Common Service Centres (ESO/CSC) in Goa would deliver the eDistrict services

integrated with the State portal and SSDG project which is operational in the State.

The State Government has identified 26 services for implementation across two districts viz.,

South Goa and North Goa for eDistrict rollout. The project shall be implemented under the

supervision of ITG, the State Designated Agency in coordination with the DeGS constituted in

both districts and DoIT.

4.2.1 Stakeholder identification

The key stakeholders identified who would be having direct as well as indirect influence in the

State wide roll out and subsequent O&M of the eDistrict project in Goa has been presented here.

S.No Stakeholder Group Level of Influence

1. Department of Information Technology ,

Govt. of Goa

High

2. Government of Goa High

3. ITG - State Designated Agency High

4. District Administrations Medium

5. District e-Governance Societies (DeGS) Medium

6. National Informatics Centre (NIC) Medium

7. State PMU High



S.No Stakeholder Group Level of Influence

8. STQC Medium

9. National PMU Medium

10. Line departments Medium

11. Extended Service Outlet (ESO/CSC) Medium

12. Citizens / Beneficiaries Medium

4.2.2 Following are the services selected by the State in Phase –I of eDistrict rollout:



Sr.

No

.

Category Name of Service Remark

1 Certificates Issuance of Income certificate

Issuance of Domicile certificate

Issuance of Residence certificate

Issuance of Divergence certificate

Issuance of Caste/Community certificate

Issuance of Matriz certificate

Issuance of Form I & XIV (Record of Right)

Issuance of Birth/Death certificate

Application for Marriage Registration certificate & Issuuance of Marriage Registration certificate.

Covered under DC Suite Dir. of Settlement & Land records Panchayat/Municipality Registration Dept.

2 Relief – Natural calamity

Application for Relief for victims of Natural Calamity Covered under DC Suite

3 Revenue Court

Revenue court cases-Case listing/adjournment/stay/ Final/Status

Covered under DC Suite

4 RTI Services RTI filing and status services Goa State Info. Commission

5 Arms License Application/Renewal of Arms License Covered under DC Suite

6 Sound permission

Application for Sound permission Covered under DC Suite

7 Transport

Application for grant of subsidy for Yellow/ Black Motor Cycle, Auto Rickshaw, Taxi scheme 2003

Application for grant of subsidy for replacement of Buses/Mini Buses above 15 years old

Transport Dept.

8 Fisheries Application for Registration /Renewal of Fishing Nets Fisheries Dept.

9 Certificate Registration of New water sports activities Tourism Dept.

10 Registration/Renewal of Inland Vessels

Registration/Renewal of Water Sports

Captain of Ports Dept.

11 Registration of Schools for participation in Games

Application for Sportsmen certificate

Registration/Application for entry into State Youth Festival

Application for grant-in-aid for various Educational Institutes

Sports Dept.

12 Generic forms

Recruitment form for non-gazette post of various Depts. across State

Form for Scheme management



4.2.3 State Specific e-Governance Initiatives

4.2.3.1 SDC: Location of SDC (State Data Centre)

A State Data Centre has been setup in Goa which is commissioned at the Department of

Information Technology premises in Porvorim, North Goa as a State funded initiative and

caters to the needs of all the State Government departments. However, a state of the art SDC

under NeGP is also proposed for implementation in Goa which has been approved by DeitY,

GOI.

The State Data Centre is located at 2nd floor, Department of Information Technology, Alcon

Construction, Above Alcon Hyundai Showroom, Porvorim, Bardez, Goa, India. The Current

dimension area of State data Centre is 10.96m X 9.81m with Server Farm Area, Manager Cabin,

NOC/ Console Room, Reception area, Staging area and UPS/ Electrical Room , etc.

The table below provides further details about the existing State Data Centre in Goa:

Status of SDC Adequate space and IT Resources for eDistrict

project

Operational Available

4.2.3.2 ESO/CSC (Extended Service Outlets)

Directorate of Panchayats (DOP) will establish and identify the site for ESO/CSC in

Panchayats in coordination with Department of Information Technology, Goa. Further,

the Panchayats will in-turn identifies the staff to run ESO/CSC. The necessary training

to the Staff will be provided by the System Integrator for the eDistrict services.

Currently, various services of Departments are available online and can be rolled out

through ESO/CSC. Based on the nature of the services, they are divided into various

types, such as Information Service, Transaction Service, Certificate Service and Payment

Service, etc.

4.2.3.3 GBBN (Goa Broad Band Network)

The SWAN project in Goa is called the Goa Broad Band Network (GBBN) and henceforth would

be called GBBN. The GBBN project has been designed to build a converged Wide Area Network

that connects the State Headquarters and District Headquarters with all 12 Talukas, Village

Panchayats, Households and institutions across the State. The details of GBBN connectivity is

provided in Annexure V.



4.2.3.4 SSDG (State Service Delivery Gateway), State Portal & eForms - Goa

Status of SSDG in the State Operational

Status of State Portal Operational - www.goa.gov.in

Services under e-Forms for each

district

Services already

implemented by

SI(SSDG)

Services still to

be implemented

by SI(eDistrict)

Services

implemented by

NIC

Status of SSDG 46 14* 12

* There are a total of 26 services considered as part of the initial eDistrict Goa initiative.

It is to be noted that 12 services out of 26 are already developed and managed by NIC. SI

(eDistrict) has to develop end to end solutions for 14 services and has to develop web services

for the 12 services implemented by NIC of the 26 services. All the services shall be accessed

through SSDG.

However the system integrator has to develop the web services to interface the e-Services

provided through DC suite deployed by NIC

4.3 Key Information

The objectives of the eDistrict Mission Mode Project are to ensure the following:

I. Providing easy, anywhere and anytime access to government services (both

information & transactional) to ensure reliability, efficiency, transparency and

accountability.

II. Delivery of all public services at district/ sub district level in electronic form

through state portals through SSDG.

III. Reducing number of visits of citizens to a government office / department for

availing the services and thereby eliminating harassment.

IV. Reducing administrative burden and service fulfillment time and costs for the

government, citizens & businesses.

V. Reducing direct interaction of citizen with the government and encourage „e‟-

interaction and efficient communication through portal.

VI. Enhancing perception & image of the Government and its constituent Departments.

VII. Undertake backend computerization of District and Taluka level offices to ensure

electronic delivery of high volume citizen centric services at the district level.

VIII. Efficient delivery of services with improved service levels by undertaking extensive

Business Process Re-engineering (BPR) of identified services.

IX. Delivery of services through Extended Service Outlets (ESO/CSC) and Citizen

Facilitation Centers (CFC) by leveraging the common infrastructure of GBBN, SDC,

and SSDG.

http://www.goa.gov.in/



X. Development of applications to be hosted at SDC for delivery of services.

XI. Extensive capacity building and training of field level functionaries to ensure

smooth migration to electronic delivery of eDistrict services and phasing out

manual delivery of services.



The key stakeholders of the project are illustrated below:

4.4 About Info Tech Corporation of Goa (ITG)

Info Tech Corporation of Goa Limited (ITG) formerly known as the Electronics Corporation of

Goa Ltd. (ECGL) has been set up by the Government of Goa to promote overall growth of the

state's economy through the use of Information Technology. ITG is state designated agency for

the eDistrict MMP and in the administrative control of Dept. of Information technology

Objectives

Creation of IT Infrastructure for promotion of IT Industry in the state of Goa by establishing, IT / Cyber Cities, Parks, Townships, including infrastructure and communication faculties such as development of Land, Plots, Construction of Roads, Water supply facility, Electricity supply, Drainage, Telephone etc.

To support and assist the Government in development of e-Governance applications required to be developed to serve citizens and business.

To undertake software development projects selected by the Government.

To undertake the activities of providing required hardware to various Government departments as directed by the Government.

To undertake the activities of local area network and UPS connectivity required to connect IT hardware and UPS etc. in various Government departments as directed by the Government.

Help and promote IT and IT Enabled Service Industries in the state of Goa. Key Functions



As a State agency monitoring the project, role of ITG in the successful implementation of the

proposed system includes discharging the following responsibilities:

To identify and nominate the District e-Governance teams/societies (IT/ revenue

department) at the District level and ensuring complete involvement of the project

champion from start to finish of the project

To ensure that all the participating districts take active part in project

To identify key points of contacts who would be able to dedicate quality time with the

Implementation Partner throughout the roll out

To review the installation, commissioning and maintenance activities

To conduct review meetings at regular intervals to monitor the overall progress of the

project

Workforce and Location

ITG Resources serves the state of Goa and is located at 4th Floor, Alcon Construction, Above

Alcon Hyundai Showroom, Porvorim, Bardez, Goa-403501.

Organization structure



5 Instructions to the Bidders

5.1 General

I. While every effort has been made to provide comprehensive and accurate background

information and requirements and specifications, bidders must form their own

conclusions about the solution needed to meet the requirements. Bidders and recipients

of this RFP may wish to consult their own legal advisers in relation to this RFP.

All information supplied by Bidders may be treated as contractually binding on the

Bidders, on successful award of the assignment by the ITG on the basis of this RFP.

II. No commitment of any kind, contractual or otherwise shall exist unless and until a

formal written contract has been executed by or on behalf of the ITG. Any notification of

preferred bidder status by the ITG shall not give rise to any enforceable rights by the

bidder. The ITG may cancel this public procurement at any time prior to a formal

written contract being executed by or on behalf of the ITG.

III. This RFP supersedes and replaces any previous public documentation &

communications, and Bidders should place no reliance on such communications.

IV. SDA shall constitute technical evaluation committee to evaluate progress of the work

and for the recommendation of the payment to the bidder

5.2 Compliant Proposals / Completeness of Response

I. Bidders are advised to study all instructions, forms, terms, requirements and other

information in the RFP documents carefully. Submission of the bid shall be deemed to

have been done after careful study and examination of the RFP document with full

understanding of its implications.

II. Failure to comply with the requirements of this paragraph may render the Proposal non-

compliant and the Proposal may be rejected. Bidders must:

A. Include all documentation specified in this RFP;

B. Follow the format of this RFP and respond to each element in the order as set out

in this RFP

C. Comply with all requirements as set out within this RFP.

5.3 Pre-Bid Meeting & Clarifications

5.3.1 Pre-bid Conference

I. ITG shall hold a pre-bid meeting with the prospective bidders on 16-01-2014 at 3:00 PM

at conference hall of Dept. of Information Technology. 2nd floor, Above Alcon Hyundai

Showroom, Porvorim, Bardez, Goa - 403501

II. The bidders should ensure that their queries for Pre-Bid queries should be sent by e-mail

on or before the due date & time as said in this RFP in word format only.



III. ITG shall not be responsible for ensuring that the bidders‟ queries have been received by

them. Any requests for clarifications after the indicated date and time may not be

entertained by the ITG.

IV. The queries should necessarily be submitted in the following format (in word 2010

format only ):

Name of the bidder:

Address:

Name of the contact person:

Contact No:

e-mail Id:

5.3.2 Responses to Pre-Bid Queries and Issue of Corrigendum

I. The Nodal Officer notified by the ITG will endeavor to provide timely response to all

queries. However, ITG makes no representation or warranty as to the completeness or

accuracy of any response; neither response nor does ITG undertake to answer all the

queries that have been posed by the bidders. The responses to the queries from all

bidders will be distributed to all.

II. At any time prior to the last date for receipt of bids, ITG may, for any reason, whether at

its own initiative or in response to a clarification requested by a prospective Bidder,

modify the RFP Document by a corrigendum.

III. The corrigendum (if any) will be posted at www.etender.goa.gov.in or

www.tenderwizard.com/GOA & clarifications shall be emailed to respective bidders

IV. Any such corrigendum shall be deemed to be incorporated into this RFP.

V. In order to provide prospective bidders reasonable time for taking the corrigendum into

account, ITG may, at its discretion, extend the last date for the receipt of Proposals.

S.

No.

Vol. No. RFP Document

Reference(s) (Section &

Page Number(s))

Content of RFP requiring

Clarification(s)

Points of

clarification

1.

2.

3.

4.

5.

6.





5.4 Key Requirements of the Bid

5.4.1 Right to Terminate the Process

I. ITG may terminate the RFP process at any time and without assigning any reason. ITG

makes no commitments, express or implied, that this process will result in a business

transaction with anyone.

II. This RFP does not constitute an offer by ITG. The bidder's participation in this process

may result ITG selecting the bidder to engage towards execution of the contract.

5.4.2 RFP Document Fees

a) RFP document can be downloaded from www.etender.goa.gov.in or

www.tenderwizard.com/GOA

In such case, the demand draft of RFP document fees and tender processing fees should be

submitted along with proposal in a technical bid. Proposals received without or with

inadequate RFP Document fees and tender processing fees shall be rejected.

Earnest Money Deposit (EMD)

a) Bidders shall submit, along with their Bids, EMD of Rs 25 lakhs only, in the form of a

Demand Draft OR Bank Guarantee (in the format specified in Form 3) issued by any

scheduled bank/ nationalized bank in favor of Info Tech Corporation of Goa Limited

payable at Panaji, Goa and should be valid for 6 months from the date of issue of the

RFP.

b) EMD of all unsuccessful bidders would be refunded by ITG within 120 days on

finalization of the System Integrator. The EMD, for the amount mentioned above, of

successful bidder would be returned upon submission of Performance Bank Guarantee.

c) The EMD amount is interest free and will be refundable to the unsuccessful bidders

without any accrued interest on it.

d) The bid / proposal submitted without EMD, mentioned above, will be summarily

rejected.

e) The EMD may be forfeited:

A. If a bidder withdraws its bid during the period of bid validity.

B. In case of a successful bidder, if the bidder fails to sign the contract in accordance

with this RFP.

5.4.3 Submission of Proposals

a) The bidders should submit their responses as per the format given in this RFP in the

following manner

A. Pre-Qualification Proposal - ( Original + CD) in first envelope

B. Technical Proposal - (Original + CD) in second envelope

C. Commercial Proposal through online mode only





b) The response to Pre-Qualification Proposal, Technical Proposal (as mentioned above)

should be covered in separate sealed envelopes super-scribing, ”Pre-Qualification

Proposal” and “Technical Proposal” respectively. Each copy of each bid should also be

marked as "Original”.

c) Please note that prices should not be indicated in the Technical Proposal but should only

be indicated in the Commercial Proposal.

d) The two envelopes containing copies of Pre-Qualification Proposal and Technical

Proposal should be put in another single larger sealed envelope clearly marked

“Response to RFP for e-District Goa < RFP Reference Number> and the wordings NOT

OPEN BEFORE <Date and Time>”.

e) The outer envelope thus prepared should also indicate clearly the name, address,

telephone number, E-mail ID and fax number of the bidder to enable the bid to be

returned unopened in case it is declared "Late".

f) All the pages of the proposal must be sequentially numbered & signed by the authorized

person and must contain the list of contents with page numbers. Any deficiency in the

documentation may result in the rejection of the bid.

g) The original proposal/bid shall be prepared in indelible ink. It shall contain no

interlineations or overwriting, except as necessary to correct errors made by the bidder

itself. Any such corrections must be initialed by the person (or persons) who sign(s) the

proposals.

h) All pages of the bid shall be initialed and stamped by the person or persons who is

authorized to sign the bid.

i) In case of any discrepancy observed by ITG in the contents of the submitted original

paper bid documents with respective copies, the information furnished on original

paper bid document will prevail over others.

j) Bidder must ensure that the information furnished by bidders in respective CDs is

identical to that submitted in the original paper bid document. In case of any

discrepancy observed by ITG in the contents of the CDs and original paper bid

documents, the information furnished on original paper bid document will prevail over

the soft copy. CD should be submitted in technical bid envelop .

5.4.4 Authentication of Bids

The Proposal should be accompanied by a power-of-attorney in the name of the signatory of the

Proposal.

5.5 Preparation and Submission of Proposal

5.5.1 Proposal Preparation Costs

a) The bidder shall be responsible for all costs incurred in connection with participation in

the RFP process, including, but not limited to, costs incurred in conduct of informative

and other diligence activities, participation in meetings/discussions/presentations,



preparation of proposal, in providing any additional information required by ITG to

facilitate the evaluation process, and in negotiating a definitive contract or all such

activities related to the bid process.

b) ITG will in no case be responsible or liable for those costs, regardless of the conduct or

outcome of the bidding process.

5.5.2 Language

a) The Proposal should be filled by the bidder in English language only. If any supporting

documents submitted are in any language other than English, translation of the same in

English language is to be duly attested by the Bidders. For purposes of interpretation of

the proposal, the English translation shall govern.

5.5.3 Venue & Deadline for Submission of Proposals

a) Proposals, in its complete form in all respects as specified in the RFP, must be submitted

to Managing Director, Info Tech Corporation of Goa Limited, 4th floor, Above Alcon

Hyundai Showroom, Porvorim, Bardez, Goa.

5.5.4 Late Bids

a) Bids received after the due date and the specified time (including the extended period if

any) for any reason whatsoever, shall not be entertained and shall be returned

unopened.

b) The bids submitted by telex/telegram/fax/e-mail etc. shall not be considered. No

correspondence will be entertained on this matter.

c) ITG shall not be responsible for any postal delay or non-receipt/ non-delivery of the

documents. No further correspondence on the subject will be entertained.

d) ITG reserves the right to modify and amend any of the above-stipulated

condition/criterion depending upon project priorities vis-à-vis urgent commitments.

5.6 Evaluation Process

a) ITG will constitute a Technical Evaluation Committee to evaluate the responses of the

bidders

b) The Technical Evaluation Committee constituted by the ITG shall evaluate the

responses to the RFP and all supporting documents / documentary evidence. Inability

to submit requisite supporting documents / documentary evidence, may lead to

rejection of the bidder.

c) The decision of the Technical Evaluation Committee in the evaluation of responses to

the RFP shall be final. No correspondence will be entertained outside the process of

negotiation/ discussion with the Committee.

d) The Technical Evaluation Committee may invite for meetings with the bidders to seek

clarifications on their proposals



e) The Technical Evaluation Committee reserves the right to reject any or all proposals on

the basis of any deviations.

f) Each of the responses shall be evaluated as per the criterions and requirements specified

in this RFP.

5.6.1 Tender Opening

I. The proposals submitted by the bidder shall be opened in the presence of the

representative of the bidder who may be present at the time of the opening of the bid

II. The representatives of the bidders should be advised to carry the identity card or a letter

of authority from the tendering firms to identify their bonafides for attending the

opening of the proposal.

5.6.2 Tender Validity

The offer submitted by the bidders should be valid for minimum period of 180 days from the

date of submission of tender.

5.6.3 Tender Evaluation

I. Initial bid scrutiny will be held and incomplete details as given below will be treated as

non-responsive, if proposals :

1. Are not submitted in as specified in the RFP document

2. Received without the Letter of Authorization (Power of Attorney)

3. Are found with suppression of details

4. With incomplete information, subjective, conditional offers and partial offers

submitted

5. Submitted without the documents requested in the checklist

6. Have non-compliance of any of the clauses stipulated in the RFP

7. With lesser validity period

II. All responsive bids will be considered for further processing as below.

1. ITG will prepare a list of responsive bidders, who comply with all the Terms and

Conditions of the RFP. All eligible bids will be considered for further evaluation by a

Committee according to the evaluation process defines in this RFP document. The

decision of the Committee will be final in this regard.

6 Criteria for Evaluation

I. The overall objective of this evaluation process is to select a capable and qualified firm in

the business domain of developing and rolling out a Portal, e-District Application,

related hardware and other infrastructure, providing associated capacity building,

training & handholding support as well as associated managed services and who will

provide a comprehensive solution towards Supply, Installation, Integration,



Commissioning, Development, Deployment, Operation & Management of e-District

Application and hardware provisioning in the Goa state.

II. First the Pre-Qualification Proposal will be evaluated and only those bidders who

qualify the requirements will be eligible for next set of evaluations. Technical Proposal

of bidders who does not meet the Pre-Qualification criteria will be returned without

opening.

III. ITG shall call the pre-qualified bidders for technical presentation.

IV. The technical score of all the bidders would be calculated as per the criteria mentioned

below. All the bidders who achieve at least 70 marks in the technical evaluation would

be eligible for the next stage, i.e. Financial bid opening.

V. Proposals of Companies would be evaluated as per Technical Evaluation Criteria.

Agencies / firms should clearly indicate, giving explicit supporting documentary

evidence, with respect to the above, in absence of which their proposals will be rejected

summarily at the qualification stage itself.

VI. ITG shall negotiate with L1 bidder if required

VII. L1 shall be considered for the award of contract.

6.1 Pre-Qualification Criteria

Sr.

No

Qualification Criteria Documents/Information to be provided

in the submitted proposal

1. The responding firm / agency

(a) Should have made a payment of Tender

document fees of Rs. 8000.00 (eight

thousand only) In the form of demand draft

from nationalized/ scheduled banks in

favour of Info Tech Corporation of Goa Ltd.


Tender processing fees of Rs. 2000.00 (two

thousand only) In the form of demand draft

from nationalized/ scheduled banks in

favour of Info Tech Corporation of Goa Ltd.

Payable at Panaji , Goa for the RFP document

(b) Should have submitted a EMD of Rs.

25,00,000.00 (Twenty five lakhs only)

a. (DD or bank guarantee for Rs.

25,00,000.0 ( Twenty five lakhs

only)

b. (DD for Rs. 8,000.00 ( eight

thousand lacks only)

c. (DD for Rs. 2,000.00 ( Two thousand

only)

d. The original bank guarantee must

be furnished in the format

prescribed

2. Legal Entity

Company should be registered under

Companies Act, 1956

Should have been operating for the last

five years

Certificate of Incorporation

Registration Certificate

Article of association or

Memorandum & Articles of Association

and the any other document indicating



Sr.

No



that the company is in operation for the

last 5 years as on date of issue of this

RFP

3. The Firm / Company should be in the

business as System Integrator for at least 3

years as of as on date of issue of this RFP

Work orders confirming year and Area

of activity should be attached

4. The bidder must have a positive net worth as

on 31st March 2013

Certificate by Chartered accountant or

Certificate from the statutory auditor of

the bidder

5. Bidder must be an Information Technology

company

Article of association & its registration

details

6. The responding firm shall not be under a

declaration of ineligibility for corrupt or

fraudulent practices.

A self-certified letter by the designated

official of the responding firm

7. The responding firm should be minimum

CMMi Level 3.

Relevant certificate needs to be attached

which is valid on date of submission.

8. Average Annual Sales Turnover generated

from services related to System Integration

(SI) during the last three (3) financial years

(FY 12-13, FY 11-12 and FY 10-11) as per the

last published balance sheets should be

minimum of Rs. 50 Crore or more

Extracts from the audited Balance sheet

and Profit & Loss; OR

Certificate from the statutory auditor.

9. Company experience in implementation of

integrated turnkey projects around

application development as a System

Integrator in India.

One Project worth 7.5 Crore

OR

Two Project of 5 Crore each.

OR

Three project of 4 Crore each.

(Specifically each project should have

Work order/ agreement and Project

completion certificates from client to be

enclosed

Other details of the project experience

may be provided as per Form 6.



Sr.

No



components of Hardware, Networking,

Software development, Helpdesk and

Application related training necessarily for

this project).

Number of such Assignments of value (as

specified for tiers) which have gone live in

the past 5 years (FY 12-13, FY 11-12, FY 10-11,

FY 09-10, and FY 08-09)

10. The responding firm must have a minimum

number of 50 technically qualified IT

professionals as on 31st Aug 2013 on its own

pay roll.

Certificate from HR Department for

number of technically qualified

professionals employed by the company

to be furnished.

11. The bidder must have company registration

certificate, Valid sales tax/ VAT registration

certificate, valid service tax registration

certificate and PAN card.

Copies of the certificates to be attached

12. The bidder should submit undertaking

stating that the bidder is not black listed by

central Govt./any state or UT

Gov./PSU/Organized sector and there

should not be any black listing pending case

against the bidder

Undertaking by the bidder

13. Bidder needs to have an office in Goa or

provide a undertaking to open an office in

Goa within 30 days of receiving of letter of

intent

Supporting Documents/ Undertaking

by the bidder

14. OEM for Hardware

a. In the last five financial years, the OEM must have supplied similar kind of enterprise level products in at least two projects of similar nature in Government / PSU in India

b. The OEM of offered products must have their own Technical Assistance Center (TAC) support in India

a. Relevant documentary evidences like PO Copy etc.

b. Relevant documentary evidence c. Relevant documentary evidence d. Audited financial statements or

auditors certification e. Relevant documentary evidence



Sr.

No



c. The OEM (s) should be an established industry player in offered technology product and should form a part of the Industry standard leader /challenger‟s quadrant on the likes of Gartner, Forrester, and IDC etc.

d. The OEM of offered products should have a turnover of at least Rs. 100 Crores from the sale of its own manufactured ICT products in India, in each of the last three financial years.

e. The OEM of offered products should have the ISO 9001:2000, ISO 14001 and ISO 17001 certification



6.2 Technical Qualification Criteria

I. Technical proposal of the bidders will be opened and evaluated who meets all the prequalification criteria.

II. The evaluation committee will evaluate the Technical Proposals on the basis of the technical evaluation criterion as provided

below.

III. Value of each project is in Indian Rupees.

S. No Criteria Max Criteria/ Sub Criteria Marks

1 Past Experience of the bidder 30

2 Solution proposed for the e-District Project by the bidder 40

3 Work Plan approach and proposed methodology 10

4 Adequacy and Quality of Resources proposed for Deployment 20

Total Points 100

Sr.

No.

Criteria/Sub

Criteria

Description Point System Max Criteria/

Sub Criteria

Points

Supporting

Documents

1 Past Experience of the bidder 30

a. System

Integration

projects

At least two projects with client

references for implementation of

an integrated turnkey project

around a) network solution and

b) software development c)

Hardware commissioning and

d) O&M phase for maintaining

For each project the marks

would be based on the

following :

>INR 7.5 Crore = 10 points;

>INR 6 Crore but less than

10

Enclosed

corresponding

work orders,

Agreements &

completion

Certifications



Sr.

No.

Criteria/Sub

Criteria


Sub Criteria

Points

Supporting

Documents

all of the above.

INR 7.5 Crore=7 points;


INR 6 Crore=5 points;


INR 5 Crore=3 points,

Else 0

b. Software

Solutions

At least two projects completed

/ ongoing software development

projects each having a minimum

value of INR 1.50 Crore – for

software development

component only). The project

should have some or all of the

following components :

– Portal

– Web based Application

Server

– Electronic Forms

5 Projects – 10 points;

4 Projects - 8 points;

3 Projects - 5 points;

Else 0.

10 Enclosed

corresponding

work orders,

Agreements &

completion

Certifications, or

certificate from

client indicating

the on going

project details

c. Maintenance

Services and

Helpdesk in any

State/UT

Providing Maintenance Services

/ Helpdesk services in the field

of IT services with a minimum

order size of INR 2 Crore in the

State for any of the project

In case of any one project

done for the following

locations :

a) covers <provide nos.

which covers more than 80%

of the districts in any

State/UT> districts – 5

5 Supporting documentary evidence to be

provided by the

bidder



Sr.

No.

Criteria/Sub

Criteria


Sub Criteria

Points

Supporting

Documents

points

b) covers <provide nos.

which are more than 50% of

the districts in any


points

c) covers <provide nos.

which covers are more than

25% of the districts in any


points

else; 0

d. Other Projects

SI Projects involving in at least 6

different locations with a value

of more than INR 2 Crore per

project

> =3 Projects – 5 points;

2 projects - 3 point

1 Project - 1 points;

else 0

However if any one of the

projects undertaken has a

value more than INR 20

Crore – 5 points

5 Enclosed

corresponding

work orders,

Agreements &

completion

Certifications

along with the

details of the

locations where

the project is

executed



Sr.

No.

Criteria/Sub

Criteria


Sub Criteria

Points

Supporting

Documents

Note : For all the above, kindly provide work orders / agreements and the Completion Certificate of the projects completed from the client indicating also the value of the project

2 Solution proposed 40

a. Proposed

solution

Requirements addressed as

mentioned in different parts of

the RFP and the quality of the

solution

Evaluation Committee will

evaluate whether all the

points/ requirements

mentioned in the RFQ are

addressed well and award

points accordingly, the

important parameters

being:-

– Solution architecture

conceptualized for this

project. This should

include integration of e-

District application with

legacy application (NIC

etc.), Also integration with

the SSDG framework. – 2

points

– Security architecture- 1

points

– Detailed plan for using

GBBN as connectivity - 1

10 To be

provided

by the

bidder in

Form 7



Sr.

No.

Criteria/Sub

Criteria


Sub Criteria

Points

Supporting

Documents

points

– Application deployment

and testing Strategy -2

points

– Quality Control

Procedures suggested by

responding firm - 2 points

– Comprehensiveness of Bill

of material of all the

components (e.g. software,

hardware, etc.) along with

their quantities – 2 points

b. Proposed

Approach and

methodology

Evaluation Committee will

evaluate whether the

implementation methodology is

in line with the requirement. The

important parameters being:-

- Plan for meeting the SLA

norms.

- Redundancy and failover

options.

- Spare equipment availability

plans

In this section, the

responding firm should:

– Explain the understanding

of the project

requirements, highlight the

expected support from the

State, approach to the

services, SLA management

methodology,

methodology for carrying

out the activities for

expected output - 2 points

– Highlight the associated

risks / problems and plans

10 To be

provided

by the

bidder



Sr.

No.

Criteria/Sub

Criteria


Sub Criteria

Points

Supporting

Documents

for mitigation and explain

the technical approach it

would adopt to address

them – 2 points

– Explain the plan to create

BPR for creating SRS for

the services under e-

District(FRS has already

been created) -3 points

– Explain the methodologies

the responding firm

proposes to adopt and

highlight the compatibility

of those methodologies

with the proposed

approach - 1 points

– Planning and Building

Infrastructure (assessment,

design, integration /

migration of existing

Portal infrastructure) – 2

points

c Training Proposed Training and Change

Management plan description to

be looked into

The Evaluation will be

based on:

– Proposed Training

Schedule – 1 point

10 To be

provided

by the

bidder as



Sr.

No.

Criteria/Sub

Criteria


Sub Criteria

Points

Supporting

Documents

– Plan to develop Training

Manuals – 1 point

– Areas/domains covered –

1 point

– Number & Quality of

personnel to be deployed

for training at the site of

Implementation of the

Project.- 2 points

– Certificate from client that

bidder has trained more

than 100 employees-5

points

the part

of the

proposal

d Formation/Locati

on of Helpdesk

& other

manpower

support

Proposed methodology of

formation of the manpower

support team.

Operating and Maintaining

Infrastructure

The Evaluation will be

based on

– Proposed Staff details

– Areas/domains covered

10 As a part of the

proposal

3 Proposed Approach & Methodology 10

a. Project

Management

The overall approach to be

looked into

The overall project

management approach

adopted by the responding

firm to implement the

project to meet the timelines.

5 To be provided

by the bidder



Sr.

No.

Criteria/Sub

Criteria


Sub Criteria

Points

Supporting

Documents

b. Detailed Work

Plan

The description and quality of

the work plan to be looked into.

Evaluation will be based on

the detailed Project Plan

including day wise, week

wise activities with Work

Breakdown Structures,

Project estimates, milestones

etc.

5 To be provided

by the bidder in

Form 8

4 Resource Deployment 20

A Quality of CV

for the full time

Project Manager

proposed for the

project

Minimum of 5 CVs who would

be working full time on project

along with deployment plan

Qualification/relevant

certification of the People

Involved

10 To be provided

by the bidder in

Form 10 & Form

11

B Quality of CV for

the Technical

Managers

proposed at

District level

Maximum of 10 illustrative CVs

who would be working at

District level as Technical

eDistrict manager along with

deployment plan

Education Qualification/

relevant certification of the

people involved

10 To be provided

by the bidder in

Forms 10 &

Form 11

Total Points 100

Bidder is expected to provide details of the project cited as per form six



6.3 Commercial Bid Evaluation

I. The Financial bids of technically qualified bidders (i.e. 70 and above marks) will be opened

on the prescribed date in the presence of bidder representatives if any.

II. The bid price will include all taxes and levies and shall be in Indian Rupees and mentioned

separately as indicated in the financial bid.

III. Any conditional bid would be rejected without assigning any reasons.

IV. Errors & Rectification: Arithmetical errors will be rectified on the following basis: “If there

is a discrepancy between the unit price and the total price that is obtained by multiplying

the unit price and quantity, the unit price shall prevail and the total price shall be

corrected. If there is a discrepancy between words and figures, the amount in words will

prevail”.

V. If there is no price quoted for certain material or service, the bid shall be declared as

disqualified.

VI. In the event that there are 2 or more bidders having the same value in the financial bid, the

bidder securing the highest technical score will be adjudicated as the “Best responsive bid”

for award of the Project.



7 Appointment of System Integrator

7.1 Award Criteria

ITG will award the Contract to the successful bidder whose financial proposal is the lowest (L1) and

would consider it as substantially responsive as per the process outlined above.

7.2 Right to Accept Any Proposal and To Reject Any or All Proposal(s)

ITG reserves the right to accept or reject any proposal, and to annul the tendering process / Public

procurement process and reject all proposals at any time prior to award of contract, without thereby

incurring any liability to the affected bidder or bidders or any obligation to inform the affected bidder

or bidders of the grounds for ITG action.

7.3 Notification of Award

I. Prior to the expiration of the validity period, ITG will notify the successful bidder in writing or

by fax or email, that its proposal has been accepted. In case the tendering process / public

procurement process has not been completed within the stipulated period, ITG may like to

request the bidders to extend the validity period of the bid.

II. The notification of award will constitute the formation of the contract. Upon the successful

bidder's furnishing of Performance Bank Guarantee, ITG will notify each unsuccessful bidder

and return their EMD.

7.4 Contract Finalization and Award

I. The ITG shall reserve the right to negotiate with the L1 bidder whose proposal has been most

responsive. On this basis the draft contract agreement would be finalized for award & signing.

II. ITG may reduce or increase the quantity of any item in the Scope of Work defined in the RFP.

Accordingly total contract value may change on the basis of the rates defined in the financial

proposal.

7.5 Performance Guarantee

I. The selected bidder shall provide a Performance Bank Guarantee, within 15 days from the

Notification of award, for a value equivalent to 10% of the total cost of the project to ITG. The

Performance Guarantee shall be kept valid till completion of the project and Warranty period.

The Performance Guarantee shall contain a claim period of three months from the last date of

validity. The selected bidder shall be responsible for extending the validity date and claim

period of the Performance Guarantee as and when it is due on account of non-completion of

the project and Warranty period. In case the selected bidder fails to submit performance

guarantee within the time stipulated, the ITG at its discretion may cancel the order placed on

the selected bidder without giving any notice. ITG shall invoke the performance guarantee in

case the selected bidder fails to discharge their contractual obligations during the period or

ITG incurs any loss due to bidder‟s negligence in carrying out the project implementation as

per the agreed terms & conditions.



7.6 Signing of Contract

I. After the ITG notifies the successful bidder that its proposal has been accepted, ITG shall enter

into a contract, incorporating all clauses, pre-bid clarifications and the proposal of the bidder

etc. between ITG and the successful bidder. The Draft Legal Agreement is provided as a

separate document as a template.

7.7 Failure to Agree with the Terms and Conditions of the RFP

I. Failure of the successful bidder to agree with the Draft Legal Agreement and Terms &

Conditions of the RFP shall constitute sufficient grounds for the annulment of the award, in

which event ITG may award the contract to the next best value bidder or call for new

proposals from the interested bidders.

II. In such a case, the ITG shall forfeit the EMD of the most responsive bidder.

8 Project Plan

Refer to RFP Volume III

Definition of Go-Live

Refer to Volume III

9 Payment Schedule

Refer to Volume III



10 Annexure

Annexure I: TECHNICAL BID TEMPLATES

The bidders are expected to respond to the RFP using the forms given in this section and all

documents supporting Technical Evaluation Criteria.

Technical Proposal shall comprise of following forms:

Forms to be used in Technical Proposal

Form 1: Undertaking on Total Responsibility

Form 2: Particulars of the Bidder

Form 3: Bank Guarantee for Earnest Money Deposit

Form 4: Compliance Sheet for Technical Proposal

Form 5: Letter of Proposal

Form 6: Project Citation Format

Form 7: Proposed Solution

Form 8: Proposed Work Plan

Form 9: Team Composition

Form 10: Curriculum Vitae (CV) of Key Personnel

Form 11: Deployment of Personnel

Form 12: Manufacturers Authorisation Form

Form 13: Declaration on Source Code and Intellectual Property Rights

Form 14: Undertaking on Patent Rights

Form 15: Undertaking on Compliance and Sizing of Infrastructure

Form 16: Undertaking on Service Level Compliance

Form 17: Undertaking on Deliverables

Form 18: Undertaking on Support to Third Party Solution acceptance and certification

Form 19: Declaration of Activities sub-contracted

Form 20: Undertaking on Exit Management and Transition

Form 21: Declaration that the bidder has not been blacklisted

Form 22: Particulars of the Bid Cover Letter

Form 23: Undertaking on Conflict of Interest

Form 24: Non-Malicious Code Certificate

Form 25: Undertaking on Clarifications sent to ITG

Form 26: Undertaking on Training the Users

Form 27: Undertaking on Support to Certification

Form 28: Undertaking on Changes to the contract clauses

Form 29: Self-declaration

All the above and undertakings has to be uploaded on e-tendering portal along with technical & commercial bid.



Form 1: Undertaking on Total Responsibility

Ref. No. Date:

To:

Dear Sir,

Sub: Self certificate regarding Total Responsibility

This is to certify that we undertake total responsibility for the successful and defect free operation of

the proposed Project solution, as per the requirements of this RFP for e-District Project.

Thanking you,

Yours faithfully

(Signature of the Authorized signatory of the Bidding Organisation)

Name :

Designation :

Date :

Time :

Seal :

Business Address:



Form 2: Particulars of the Bidder

S.No. Information Sought Details to be Furnished

1. Name and address of the

bidding Company

2. Incorporation status of the firm

(public limited / private

limited, etc.)

3. Year of Establishment

4. Date of registration

5. Registration certificate

reference No.

6. Details of company registration

7. Details of registration with

appropriate authorities for

service tax

8. Name, Address, email, Phone

nos. and Mobile Number of

Contact Person



Form 3: Bank Guarantee for Earnest Money Deposit

To,

<Name>

<Designation>

<Address>

<Phone Nos.>

<Fax Nos.>

<Email id>

Whereas <Name of the bidder> (hereinafter called 'the Bidder') has submitted the bid for Submission

of RFP # <RFP Number> dated <Date> for <Name of the assignment> (hereinafter called "the Bid") to

ITG

Know all Men by these presents that we < > having our office at <Address> (hereinafter called "the

Bank") are bound unto the ITG (hereinafter called "the Purchaser") in the sum of Rs. <Amount in

figures> (Rupees <Amount in words> only) for which payment well and truly to be made to the said

Purchaser, the Bank binds itself, its successors and assigns by these presents. Sealed with the Common

Seal of the said Bank this <Date>

The conditions of this obligation are:

1. If the Bidder having its bid withdrawn during the period of bid validity specified by the Bidder on

the Bid Form; or

2. If the Bidder, having been notified of the acceptance of its bid by the Purchaser during the period

of validity of bid

(a) Withdraws his participation from the bid during the period of validity of bid document; or

(b) Fails or refuses to participate in the subsequent Tender process after having been short

listed;

We undertake to pay to the Purchaser up to the above amount upon receipt of its first written

demand, without the Purchaser having to substantiate its demand, provided that in its demand the

Purchaser will note that the amount claimed by it is due to it owing to the occurrence of one or both of

the two conditions, specifying the occurred condition or conditions.



This guarantee will remain in force up to <insert date> and including <extra time over and above

mandated in the RFP> from the last date of submission and any demand in respect thereof should

reach the Bank not later than the above date.

NOTHWITHSTANDING ANYTHING CONTAINED HEREIN:

I. Our liability under this Bank Guarantee shall not exceed Rs. <Amount in figures> (Rupees

<Amount in words> only)

II. This Bank Guarantee shall be valid up to <insert date>)

III. It is condition of our liability for payment of the guaranteed amount or any part thereof arising

under this Bank Guarantee that we receive a valid written claim or demand for payment under

this Bank Guarantee on or before <insert date>) failing which our liability under the guarantee

will automatically cease.

(Authorized Signatory of the Bank)

Seal:

Date:



Form 4A: Compliance Sheet for Pre-Qualification Proposal

Sr.

No

Qualification Criteria Documents/Information to

be provided in the

submitted proposal

Compliance Reference & Page

Number

1. The responding firm /

agency

(a) Should have made a

payment of Tender document

fees of Rs. 8000.00 (eight

thousand only) In the form

of demand draft from

nationalized/ scheduled

banks in favour of Info Tech

Corporation of Goa Ltd.


Tender processing fees of Rs.

2000.00 (two thousand only)

In the form of demand draft

from nationalized/

scheduled banks in favour of

Info Tech Corporation of Goa

Ltd. Payable at Panaji , Goa

for the RFP document

(b) Should have submitted a

EMD of Rs. 25,00,000.00

(Twenty five lakhs only)

e. (DD or bank guarantee

for Rs. 25,00,000.0 (

Twenty five lakhs only)

f. (DD for Rs. 8,000.00 (

eight thousand lacks

only)

g. (DD for Rs. 2,000.00 (

Two thousand only)

h. The original bank

guarantee must be

furnished in the format

prescribed

Yes/No

2. Legal Entity

- Company should be

registered under Companies

Act, 1956

- Registered with the Service

Tax Authorities

- Should have been operating

for the last five years

Certificate of Incorporation

Registration Certificate

Yes/No

3. The Firm / Company should

be in the business as System

Integrator for at least 3 years

as of 31st Aug 2013

Details of Responding Firm

&

Memorandum & Articles of

Association should be

attached, and Work orders

Yes/No



Sr.

No


be provided in the

submitted proposal


Number

confirming year and Area of

activity must be furnished

4. The responding firm shall not

be under a declaration of

ineligibility for corrupt or

fraudulent practices.

A self-certified letter by the

designated official of the

responding firm

Yes/No

5. The Net Worth of the

responding firm must be

positive as per the last

audited Balance Sheet.

Chartered Accountant

Certificate for Net worth

Yes/No

6. The responding firm should

be minimum CMMi Level 3.

Relevant certificate needs to

be attached which is valid on

date of submission.

Yes/No

7. Average Annual Sales

Turnover generated from

services related to System

Integration (SI) during the

last three (3) financial years

(FY 12-13, FY 11-12 and FY

10-11) as per the last

published balance sheets

Extracts from the audited

Balance sheet and Profit &

Loss; OR

Certificate from the statutory

auditor.

Yes/No

8. Company experience in

implementation of integrated

turnkey projects around

application development as a

System Integrator in India.

(Specifically each project

should have components of

Hardware, Networking,

Helpdesk and Application

related training necessarily

for this project). Refer to the

Important Note below for

more details.

Number of such Assignments

of value (as specified for

tiers) which have gone live in

the past 5 years (FY 12-13, FY

Details of Experience of

responding firm/Project

Citation for 2 projects

supported with Work order

Yes/No



Sr.

No


be provided in the

submitted proposal


Number

11-12, FY 10-11, FY 09-10, and

FY 08-09)

9. The responding firm must

have a minimum number of

IT Staff of technically

qualified personnel in the

domain of systems

integration, as on 31st Aug,

2013 on its roll.

Certificate from HR

Department for number of

technically qualified

professionals employed by

the company

Yes/No

10. The bidder must have

company registration

certificate, Valid sales tax/

VAT registration certificate,

valid service tax registration


Copies of the certificates to

be attached

Yes/No

11. The bidder should submit

undertaking stating that the

bidder is not black listed by

central Govt./any state or

UT Gov./PSU/Organized

sector and there should not

be any black listing pending

case against the bidder

Undertaking by the bidder Yes/No

12. Bidder needs to have an

office in Goa or provide a

undertaking to open an office

in Goa within 30 days of

receiving of letter of intent

Supporting Documents/

Undertaking by the bidder

Yes/No

13. The bidder must have

company registration

certificate, Valid sales tax/

VAT registration certificate,

valid service tax registration


Copies of the certificates to

be attached

Yes/No

14. OEM for Hardware a. In the last five financial

years, the OEM must have supplied similar kind of

a. Relevant documentary evidences like PO Copy etc.

b. Relevant documentary

Yes/No



Sr.

No


be provided in the

submitted proposal


Number

enterprise level products in at least two projects of similar nature in Government / PSU in India

b. The OEM of offered products must have their own Technical Assistance Center (TAC) support in India

c. The OEM (s) should be an established industry player in offered technology product and should form a part of the Industry standard leader /challenger‟s quadrant on the likes of Gartner, Forrester, and IDC etc.

d. The OEM of offered products should have a turnover of at least Rs. 100 Crores from the sale of its own manufactured ICT products in India, in each of the last three financial years.

e. The OEM of offered products should have the ISO 9001:2000, ISO 14001 and ISO 17001 certification

evidence c. Relevant documentary

evidence d. Audited financial

statements or auditors certification

e. Relevant documentary evidence



Form 4B: Compliance Sheet for Technical Proposal

(The Technical proposal should comprise of the following basic requirements. The documents

mentioned in this compliance sheet along with this form, needs to be a part of the Technical proposal)

For Technical Evaluation

S.

No.

Specific Requirements Documents Required Compliance

(Yes/ No)

Reference &

Page Number

1 Covering Letter for Technical

Proposal

To be provided by the

bidder

2 Proposed Solution

– Solution architecture

conceptualized for this project.

This should include integration

of e-District application with

legacy application (NIC etc.),

Also integration with the SSDG

framework

– Security architecture

– Detailed plan for using GBBN

as connectivity

– Application deployment and

testing Strategy

– Quality Control Procedures

suggested by responding firm

Comprehensiveness of Bill of

material of all the components

(e.g. software, hardware, etc.)

along with their quantities


bidder

3 Proposed Approach and

methodology

– Explain the understanding of

the project requirements,

highlight the expected support

from the State, approach to the

services, SLA management

methodology, methodology for

carrying out the activities for

expected output

– Highlight the associated risks /


bidder



S.

No.


(Yes/ No)

Reference &

Page Number

problems and plans for

mitigation and explain the

technical approach it would

adopt to address them

– Explain the plan to create BPR

for creating SRS for the services

under e-District(FRS has

already been created)

– Explain the methodologies the

responding firm proposes to

adopt and highlight the

compatibility of those

methodologies with the

proposed approach

Planning and Building

Infrastructure (assessment,

design, integration / migration

of existing Portal infrastructure)

4 Training

– Proposed Training Schedule

– Plan to develop Training

Manuals

– Areas/domains covered

– Number & Quality of

personnel to be deployed for

training at the site of

Implementation of the Project.


bidder

5 Formation/Location of

Helpdesk & other manpower

support

-Proposed Staff details

-Areas/ Domain Covered


bidder

6 Project Management

The overall project management

approach by the responding firm

to be implemented for the project

to meet the timelines


bidder

7 Detailed work plan

The description and quality of

the work plan to be looked into


bidder



S.

No.


(Yes/ No)

Reference &

Page Number

8 Profile of proposed team

members:

( Quality of CV for the full time

project manager proposed for the

project)

CVs who would be working full

time on project along with

deployment plan


bidder

9 Quality of technical managers

to be deployed at district level

CVs who would be working full

time on project as a technical

manager


bidder

10 System Integration Projects At least two projects with client

references for implementation of

an integrated turnkey project

around

a) network solution and

b) software development

c) Hardware commissioning

d) O&M phase for maintaining

Supporting documents to

be provided by the bidder

11 Software Solutions At least two projects completed / on-going software development projects each having a minimum value of INR 1.50 Crore – for software development component only). The project should have some or all of the following components : – Portal – Web based Application Server – Electronic Forms



12 Maintenance Services and Helpdesk in the State Providing Maintenance Services / Helpdesk services in the field of IT services with a minimum order size of INR 2 Crore in the State for any of the project



13 Other Projects Supporting documents to Yes/No



S.

No.


(Yes/ No)

Reference &

Page Number

SI Projects involving at least 6 different locations with a value of more than INR 2 Crore per project




Form 5: Letter of Proposal

Ref. No

To:

<Location, Date>

<Name>

<Designation>

<Address>

<Phone Nos.>

<Fax Nos.>

<Email id>

Subject: Submission of the Technical bid for <Name of the Systems Implementation assignment>

Dear Sir/Madam,

We, the undersigned, offer to provide Systems Implementation solutions to the ITG on <Name of the

Systems Implementation engagement> with your Request for Proposal dated <insert date> and our

Proposal. We are hereby submitting our Proposal, which includes this Technical bid and the Financial

bid.

We hereby declare that all the information and statements made in this Technical bid are true and

accept that any misinterpretation contained in it may lead to our disqualification.

We undertake, if our Proposal is accepted, to initiate the Implementation services related to the

assignment not later than the date indicated in Fact Sheet.

We agree to abide by all the terms and conditions of the RFP document. We would hold the terms of

our bid valid for 180 days as stipulated in the RFP document.

We hereby declare that we are not insolvent, in receivership, bankrupt or being wound up, our affairs

are not being administered by a court or a judicial officer, our business activities have not been

suspended and we are not the subject of legal proceedings for any of the foregoing.

We understand you are not bound to accept any Proposal you receive.

Yours sincerely,

Authorized Signature [In full and initials]:

Name and Title of Signatory:

Name of Firm:

Address:

Location: _____________________________________Date: ___________________________

_____________________________________________________________________________



Form 6: Project Citation Format

Relevant IT project experience

General Information

Name of the project

Client for which the project was executed

Name and contact details of the client

Project Details

Description of the project

Scope of services

Service levels being offered/ Quality of

service (QOS)

Technologies used

Outcomes of the project

Other Details

Total cost of the project

Total cost of the services provided by the

respondent

Duration of the project (no. of months, start

date, completion date, current status)

Other Relevant Information

Letter from the client to indicate the

successful completion of the projects

Copy of Work Order



Form 7: Proposed Solution

Technical approach, methodology and work plan are key components of the Technical Proposal. You

are suggested to present Approach and Methodology divided into the following sections:

a) Solution Proposed

b) Understanding of the project (how the solution proposed is relevant to the understanding)

c) Technical Approach and Methodology

Sr.No. Proposed Solution

(Provide the

Product Name or

fill Custom Built, in

case of a new

development)

Version & Year

of Release

OEM Features &

Functionalities

O&M Support

(Warranty/ATS/:

as required as per

RFP)

1.

2.

3.

4.

5.

6.



Form 8: Proposed Work Plan

No Activity1 Calendar Months

1 2 3 4 5 6 7 8 9 10 11 12 N

1

2

3

4

5

N

Note: Indicate all main activities of the assignment for the completion of the project

Form 9: Team Composition

Name of Staff with

qualification and

experience

Area of Expertise Position

Assigned

Task

Assigned

Time

committed

for the

engagement



Form 10: Curriculum Vitae (CV) of Key Personnel

General Information

Name of the person

Current Designation / Job Title

Current job responsibilities

Proposed Role in the Project

Proposed Responsibilities in the Project

Academic Qualifications:

Degree

Academic institution graduated from

Year of graduation

Specialization (if any)

Key achievements and other relevant

information (if any)

Professional Certifications (if any)

Total number of years of experience

Number of years with the current company

Summary of the Professional / Domain

Experience

Number of complete life cycle

implementations carried out

The names of customers (Please provide the

relevant names)

Past assignment details (For each assignment

provide details regarding name of

organizations worked for, designation,

responsibilities, tenure)

Prior Professional Experience covering:

Organizations worked for in the past

o Organization name

o Duration and dates of entry and

exit

o Designation Location(s)

o Key responsibilities

Prior project experience

o Project name

o Client

o Key project features in brief

o Location of the project



o Designation

o Role

o Responsibilities and activities

o Duration of the project

Please provide only relevant projects.

Proficient in languages (Against each

language listed indicate if

speak/read/write)



Form 11: Deployment of Personnel

No Name of Staff Staff input in Months (in the form of a bar chart)2

Total staff

man-

months

proposed

1 2 3 4 5 6 7 8 9 10 11 12 n Total

1

2

3

N

Total

1. Professional Staff the input should be indicated individually; for Support Staff it should be

indicated by category

2 Months are counted from the start of the assignment.

Full time input Part time input



Form 12: Manufacturers'/Producers’ Authorization Form

(This form has to be provided by the OEMs of the products proposed)

No. Date:

To:

OEM Authorization Letter

Dear Sir:

Ref: Your RFP Ref: [*] dated [*]

We who are established and reputable manufacturers / producers of ________________________

having factories / development facilities at (address of factory / facility) do hereby authorize M/s

___________________ (Name and address of Agent) to submit a Bid, and sign the contract with you

against the above bid invitation.

We hereby extend our full guarantee and warranty for the Solution, Products and services offered by

the above firm against this Bid Invitation.

We hereby declare that we are not insolvent, in receivership, bankrupt or being wound up, our affairs

are not being administered by a court or a judicial officer, our business activities have not been

suspended and we are not the subject of legal proceedings for any of the foregoing.

We also undertake to provide any or all of the following materials, notifications, and information

pertaining to the Products manufactured or distributed by the Supplier:

a. Such Products as the SI may opt to purchase from the Supplier, provided, that this option shall

not relieve the Supplier of any warranty obligations under the Contract; and

b. in the event of termination of production of such Products:

i. advance notification to the SI of the pending termination, in sufficient time to permit

the SI to procure needed requirements; and

ii. Following such termination, furnishing at no cost to the SI, the blueprints, design

documents, operations manuals, standards, source codes and specifications of the

Products, if requested.

We duly authorize the said firm to act on our behalf in fulfilling all installations, Technical support

and maintenance obligations required by the contract.

Yours faithfully,



(Name)

(Name of Producers)

Note: This letter of authority should be on the letterhead of the manufacturer and should be signed by

a person competent and having the power of attorney to bind the manufacturer.



Form 13: Declaration on Source Code and Intellectual Property Rights

Ref. No. Date:

To:

Dear Sir,

Sub: Self-certificate regarding the source code and Intellectual property rights under this Project

I, authorized representative of _________________________, hereby solemnly affirm to the IPR and

Source Code rights of this software shall be with the Department of Information Technology Goa.

In the event of any deviation from the factual information/ declaration, ITG reserves the right to

terminate the Contract without any compensation to the System Integrator.

Thanking you,

Yours faithfully

(Signature of the Authorized signatory of the bidding Organisation)

Name :

Designation :

Date :

Time :

Seal :

Business Address:



Form 14: Undertaking on Patent Rights

Ref. No. Date:

To:

Dear Sir,

Sub: Undertaking on Patent Rights

1. I/We as System Integrator (SI) do hereby undertake that none of the deliverables

being provided by us is infringing on any patent or intellectual and industrial property rights as

per the applicable laws of relevant jurisdictions having requisite competence.

2. I/We also confirm that there shall be no infringement of any patent or intellectual and

industrial property rights as per the applicable laws of relevant jurisdictions having requisite

competence, in respect of the equipment‟s, systems or any part thereof to be supplied by us. We

shall indemnify ITG against all cost/claims/legal claims/liabilities arising from third party claim in

this regard at any time on account of the infringement or unauthorized use of patent or

intellectual and industrial property rights of any such parties, whether such claims arise in

respect of manufacture or use. Without prejudice to the aforesaid indemnity, the SI shall be

responsible for the completion of the supplies including spares and uninterrupted use of the

equipment and/or system or any part thereof to ITG and persons authorized by ITG, irrespective

of the fact of claims of infringement of any or all the rights mentioned above.

3. If it is found that it does infringe on patent rights, I/We absolve ITG of any legal

action.

Yours faithfully,

(Signature of the Authorized signatory of the bidding Organisation)

Name :

Designation :

Date :

Time :

Seal :

Business Address:



Form 15: Undertaking on Compliance and Sizing of Infrastructure

Ref. No. Date:

To:

Dear Sir,

Sub: Undertaking on Compliance and Sizing of Infrastructure

1. I/We as System Integrator do hereby undertake that we have proposed and sized the

hardware and all software (including perennial and enterprise wide licenses, unless

stated otherwise) based on information provided by ITG in its RFP document and in

accordance with the service level requirements and minimum specifications provided

and assure ITG that the sizing is for all the functionality envisaged in the RFP document.

2. Any augmentation of the proposed solution or sizing of any of the proposed solutions

(including software and hardware) in order to meet the minimum RFP requirements

and/or the requisite service level requirements given by ITG will be carried out at

no additional cost to ITG during the entire period of Contract.

Yours faithfully,

(Signature of the Authorized signatory of the Bidding Organisation)

Name :

Designation :

Date :

Time :

Seal :

Business Address:



Form 16: Undertaking on Service Level Compliance

Ref. No. Date:

To:

Dear Sir,

Sub: Undertaking on Service Level Compliance

1. I/We as System Integrator do hereby undertake that we shall monitor, maintain, and

comply with the service levels stated in the RFP to provide quality service to ITG.

2. However, if the proposed Resources and infrastructure are found to be insufficient in

meeting the RFP and/or the service level requirements given by ITG, then we will

augment the same without any additional cost to ITG.

Yours faithfully,

(Signature of the Authorized signatory of the bidding organisation)

Name :

Designation :

Date :

Time :

Seal :

Business Address:



Form 17: Undertaking on Deliverables

Ref. No. Date:

To:

Dear Sir,

Sub: Undertaking on Deliverables

1. I/We as System Integrator do hereby undertake that processes, deliverables/artefacts

submitted to ITG will adhere to the quality and standards specified in this RFP.

2. We also recognize and undertake that the deliverables/artefacts shall be presented

and explained to ITG and other key stakeholders (identified by ITG), and also take the

responsibility to provide clarifications as requested by ITG .

3. We agree to abide by the procedures laid down for acceptance and review of deliverables /

artefacts by the Department as stated in this RFP or as communicated to us from time-to-time.

4. We also understand that the acceptance, approval and sign-off of the deliverables by ITG

will be done on the advice of Department and any other agency appointed by the Department

for the same. We understand that while all efforts shall be made to accept and convey the

acceptance of each deliverable in accordance with the Project schedule, no deliverable will be

considered accepted until a specific written communication to that effect is made by ITG.

Yours faithfully,


Name :

Designation :

Date :

Time :

Seal :

Business Address:



Form 18: Undertaking on Support to Third Party Solution acceptance and certification

Ref. No. Date:

To:

Dear Sir,

Sub: Undertaking on Support to Third Party Solution Acceptance and Certification

1. I/We understand that the System (including the application and the

associated IT systems) may be assessed and certified by a 3rd party agency

(to be identified by ITG) before the system is commissioned.

2. I/We understand that while the certification expenses will be borne by

System Integrator

3. System Integrator is responsible for successful completion & acceptance of the

certification of the job completion

4. I/We hereby undertake that we shall do all that is required of the

System Integrator to ensure that system will meet all the conditions

required for successful acceptance and certification.

Yours faithfully,


Name :

Designation :

Date :

Time :

Seal :

Business Address:



Form 19: Declaration of activities sub-contracted

Ref. No. Date:

To:

Dear Sir,

Sub: Declaration on Sub-contracting

I/ We hereby declare the following list of activities which we would be sub-contracted.

S. No. Activity

1

2

3

4

I/ We would be responsible for ensuring that the sub-contracted work meets the requirements of the

Department.

Thanking you,

Yours faithfully


Name :

Designation :

Date :

Time :

Seal :

Business Address:



Form 20: Undertaking on Exit Management and Transition

Ref. No. Date:

To:

Dear Sir,

Sub: Undertaking on Exit Management and Transition

1. I/We hereby undertake that at the time of completion of o u r engagement with the ITG,

either at the End of Contract or termination of Contract before planned Contract Period for

any reason, we shall successfully carry out the exit management and transition of this Project

to the ITG or to an agency identified by ITG to the satisfaction of the Department. I/We

further undertake to complete the following as part of the Exit management and transition:

a. We undertake to complete the updating of all Project documents and other

artefacts and handover the same to ITG before transition.

b. We undertake to design standard operating procedures to manage system

(including application and IT systems), document the same and train ITG

personnel on the same.

c. If ITG decides to take over the operations and maintenance of the Project on its

own or identifies or selects any other agency for providing operations &

maintenance services on this Project, then we shall provide necessary

handholding and transition support, which shall include but not be limited to,

conducting detailed walkthrough and demonstrations for the IT Infrastructure,

handing over all relevant documentation, addressing the queries/clarifications

of the new agency with respect to the working / performance levels of the

infrastructure, conducting Training sessions etc.

3. I/We also understand that the Exit management and transition will be considered

complete on the basis of approval from ITG.

Yours faithfully,

(Signature of the authorized signatory of the bidding organisation)

Name :

Designation :

Date :

Time :

Seal :

Business Address:



Form 21: Declaration that the bidder has not been blacklisted

(To be submitted on the Letterhead of the responding agency)

{Place}

{Date}

To,

Ref: RFP Notification no <xxxx> dated <dd/mm/yy>

Subject: Self Declaration of not been blacklisted in response to the RFP for Selection of System

Integrator for Statewide Roll-out of e-District MMP File No <xxx>>.

Dear Sir,

We confirm that our company, ____________, is not blacklisted in any manner whatsoever by any of

the State/UT and/or central government in India on any ground including but not limited to

indulgence in corrupt practice, fraudulent practice, coercive practice, undesirable practice or

restrictive practice.

Place:

Date:

Bidder‟s Company Seal:

Authorized Signatory‟s Signature:

Authorized Signatory‟s Name and Designation:

Note: The Bidder shall necessarily provide a copy of „Power of Attorney‟ authorizing the signatory for

signing the Bid on behalf of the Bidder in its Pre-Qualification Bid.



Form 22: Particulars of the Bid Cover Letter

[Cover Letter]

To

[Date]

The Managing Director,

Info Tech Corporation of Goa Ltd,

Porvorim, Goa.

Dear Sir,

Ref: RFP for e-District MMP

Having examined the RFP, the receipt of which is hereby duly acknowledged, we, the

undersigned, offer to provide the professional services as required and outlined in the RFP for

the e-District MMP Project. We attach hereto the technical response as required by the RFP,

which constitutes our proposal. We confirm that the information contained in this response or

any part thereof, including its exhibits, and other documents and instruments delivered or to be

delivered to State is true, accurate, verifiable and complete. This response includes all

information necessary to ensure that the statements therein do not in whole or in part mislead

the department in its short-listing process.

We fully understand and agree to comply that on verification, if any of the information provided

here is found to be misleading the short listing process, we are liable to be dismissed from the

selection process or termination of the contract during the project, if selected to do so.

We agree for unconditional acceptance of all the terms and conditions set out in the RFP

document and also agree to abide by this tender response for a period of <<SIX MONTHS>>

from the date fixed for bid opening.

We hereby declare that in case the contract is awarded to us, we shall submit the contract

performance guarantee bond.

We agree that you are not bound to accept any tender response you may receive. We also agree

that you reserve the right in absolute sense to reject all or any of the products/ services specified

in the tender response.

It is hereby confirmed that I/We are entitled to act on behalf of our company/ corporation/ firm/

organization and empowered to sign this document as well as such other documents, which may

be required in this connection.



Dated this Day of 2013

(Signature)

(In the capacity of)

(Name)

Duly authorized to sign the Tender Response for and on behalf of:

(Name and Address of Company) Seal/Stamp of bidder

Witness Signature:

Witness Name:

Witness Address:

CERTIFICATE AS TO AUTHORISED SIGNATORIES

I,,……………………………, the < Designation of the person> of …….…………………,

certify that ……………………………………………………………… who signed the above

bid is authorized to do so and bind the company by authority of its board/ governing body.

Date:

Signature:

(Company Seal)

(Name)



Form 23: Undertaking on Conflict of Interest

[Company letterhead]

[Date]

To,



Porvorim, Goa.

Sub: Undertaking on Conflict of Interest

Sir,

I/We as Bidder do hereby undertake that there is absence of, actual or potential conflict of

interest on the part of the Bidder or any prospective subcontractor due to prior, current, or

proposed contracts, engagements, or affiliations with State.

I/We also confirm that there are no potential elements (time frame for service delivery,

Resource, financial or other) that would adversely impact the ability of the Bidder to complete

the requirements as given in the RFP.

We undertake and agree to indemnify and hold State harmless against all claims, losses,

damages, costs, expenses, proceeding fees of legal advisors (on a reimbursement basis) and fees

of other professionals incurred (in the case of legal fees & fees of professionals, reasonably) by

State and/or its representatives, if any such conflict arises later.

Yours faithfully,

Authorized Signatory

Designation



Form 24: Non-Malicious Code Certificate


To, [Date]



Porvorim, Goa.

Sub: Non-Malicious Code Certificate

Sir,

1. I/We hereby certify that the software being offered / developed as part of the contract does

not and will not contain any kind of malicious code that would activate procedures to:

A. Inhibit the desired and the designed function of the equipment / solution.

B. Cause damage to the user or his equipment / solution during the operational exploitation of

the equipment / solution.

C. Tap information regarding network, network users and information stored on the network

that is classified and / or relating to National Security, thereby contravening Official Secrets Act

1923. There are / will be no Trojans, Viruses, Worms, Spy wares or any malicious software on

the system and in the software offered or software that will be developed. Without prejudice to

any other rights and remedies available to State , we are liable under Information Technology

Act, 2000 and Indian Penal Code 1860 in case of physical damage, loss of information and

those relating to copyright and Intellectual Property rights (IPRs), caused due to activation of

any such malicious code in offered / developed software.

Yours faithfully,


Designation



Form 25: Undertaking on Clarifications sent to ITG


[Date]

To,



Porvorim, Goa.

Sub: Undertaking on Clarifications sent to ITG

Sir,

I/We do hereby undertake that Commercial Proposal submitted by us is inclusive of all the

items in the technical proposal and is inclusive of all the clarifications provided/may be

provided by us on the technical proposal during the evaluation of the technical offer. We

understand and agree that our Commercial Proposal is firm and final and that any clarifications

sought by you and provided by us would not have any impact on the Commercial Proposal

submitted by us.

Yours faithfully,


Designation



Form 26: Undertaking on Training the Users


To [Date]



Porvorim, Goa.

Sub: Undertaking on Training the Users

Sir,

1. I/We hereby undertake to train users (to be identified by State) as per State’s requirements

stated in the Request for Proposal (RFP). We further undertake that:

i. We shall carry out a comprehensive training needs analysis and accordingly design the

training program

ii. Our training program would include, at the minimum, classroom training followed by

supervised work sessions

iii. We shall prepare all necessary training materials and deliver the training.

Yours faithfully,

Authorized Signatory & Designation



Form 27: Undertaking on Support to Certification


To, [Date]



Porvorim, Goa.

Sub: Undertaking on Support to Certification

Sir,

1. I/We understand that application (including the application and the associated IT systems)

have to be certified by a 3rd party agency (to be identified by State) before the system is

commissioned.

2. I/We understand that the certification expenses will be borne by bidder and so also

responsibility to ensure successful certification lies with the bidder.

3. I/We hereby undertake that we shall do all that is required of the bidder to ensure that system

will meet all the conditions required for successful certification.

Yours faithfully,


Designation



Form 28: Undertaking on Changes to the contract clauses


To, [Date]



Porvorim, Goa.

Undertaking on Changes to Contract Clauses

Sir,

1. I/We as bidder do hereby acknowledge that we understand that the request for changes to

contract clauses and any other terms and conditions in the RFP, submitted in our proposal as per

the RFP are just suggestions for change.

2. We understand that it is neither guaranteed that these requests for changes will be accepted in

the final contract nor this process will be construed as any commitment from State to consider

those suggestions.

Yours faithfully,

Authorized Signatory and Designation



Form 29: Self Declaration


To, [Date]



Porvorim, Goa.

Self Declaration

Sir,

I,,……………………………, the < Designation of the person> of …….…………………,

certify that ……………………………………………………………… who signed the above

bid is authorized to do so and bind the company by authority that the information furnished/

provided by me/us is true to my/our knowledge and are fully responsible for the same.

Date:

Signature:

(Company Seal)

(Name)



ANNEXURE II: FINANCIAL PROPOSAL TEMPLATE

Form 1: Covering Letter

To:

<Location, Date>

<Name>

<Designation>

<Address>

<Phone Nos.>

<Fax Nos.>

<Email id>

Subject: Submission of the Financial bid for <Provide Name of the Implementation Assignment>

Dear Sir/Madam,

We, the undersigned, offer to provide the Implementation services for <Title of Implementation

Services> in accordance with your Request for Proposal dated <Date> and our Proposal (Technical and

Financial Proposals). Our attached Financial Proposal is for the sum of <Amount in words and figures>.

This amount is inclusive of the local taxes.

1. PRICE AND Validity

All the prices mentioned in our Tender are in accordance with the terms as specified in the

RFP documents. All the prices and other terms and conditions of this Bid are valid for a period

of <days> calendar days from the date of opening of the Bid.

We hereby confirm that our prices include all taxes. However, all the taxes are quoted

separately under relevant sections.

We understand that the actual payment would be made as per the existing indirect tax rates

during the time of payment.

2. UNIT RATES

We have indicated in the relevant forms enclosed, the unit rates for the purpose of on account of

payment as well as for price adjustment in case of any increase to / decrease from the scope of work

under the contract.

3. DEVIATIONS

We declare that all the services shall be performed strictly in accordance with the Tender documents

except for the variations and deviations, all of which have been detailed out exhaustively in the

following statement, irrespective of whatever has been stated to the contrary anywhere else in our

bid.

Further we agree that additional conditions, if any, found in the Tender documents, other than those

stated in deviation schedule, shall not be given effect to.

4. TENDER PRICING

We further confirm that the prices stated in our bid are in accordance with your Instruction to

Bidders included in Tender documents.

5. QUALIFYING DATA



We confirm having submitted the information as required by you in your Instruction to Bidders. In

case you require any other further information/documentary proof in this regard before evaluation

of our Tender, we agree to furnish the same in time to your satisfaction.

6. BID PRICE

We declare that our Bid Price is for the entire scope of the work as specified in the <Refer Section

No.>. These prices are indicated Commercial Bid attached with our Tender as part of the Tender.

7. PERFORMANCE BANK GUARANTEE

We hereby declare that in case the contract is awarded to us, we shall submit the Performance Bank

Guarantee as specified in the <Annexure III> of this RFP document.

Our Financial Proposal shall be binding upon us subject to the modifications resulting from

Contract negotiations, up to expiration of the validity period of the Proposal, i.e., [Date].

We understand you are not bound to accept any Proposal you receive.

We hereby declare that our Tender is made in good faith, without collusion or fraud and the

information contained in the Tender is true and correct to the best of our knowledge and belief.

We understand that our Tender is binding on us and that you are not bound to accept a Tender you

receive.

Thanking you,

We remain,

Yours sincerely,

Authorized Signature:

Name and Title of Signatory:

Name of Firm:

Address:



Financial Proposal to be submitted through online mode only

Rates quoted by SI/bidder shall be in Indian Rupees only

Summary

S.

No. Item

Total Price

inclusive of

all the taxes

4xcept VAT

and State

Entry taxes

VAT State Entry

Tax (If any) Total cost

a)

Hardware related costs with

onsite comprehensive warranty

for the period of 5 years from

the date of installation (A)

b) Networking related costs (B)

c)

Application Customization /

Development and database

creation cost (C)

d)

Operations and Maintenance

Costs (Quarterly Expenses

(software) for 3 years of

contract after „”Go-Live”) (D)

e) Data Digitization (E)

f)

Deployment and operation &

maintenance of requisite

infrastructure for period of 5

years from date of installation at

State Data centre & IT Disaster

Recovery(F)

Total Cost

Total cost in figures:



Details of Financial Bid

S.

No. Category

Component No of

Compone

nts / Units

of Service

Rate per

unit

(including

all taxes

except VAT

& state

entry tax)

VAT

State

Entry Tax

(If any)

Total Cost

A. Hardware Related Costs with the Comprehensive onsite warranty of 5 years from date of

installation

1.

Infrastruc

ture /

Hardwar

e

Desktop/

Computer 369

Laptop 1

Digital Web

camera 10

Scanners (A4 size) 9

Scanners (A3 size) 3

Heavy Duty Laser

Printer (A4 size) 108

Laser Printer (A3

size) 2

Passbook Printers 2

UPS (1 KVA,

Online) 178

2.

Infrastruc

ture

Installatio

n and

Testing /

Miscellan

eous

Charges

Others

Total A:

B. Networking Related Costs

1.

Network

Related

Infrastruc

ture &

Routers

8 Port Switch 1

16 Port Switch 1

24 Port Switch 1



S.

No. Category

Component No of

Compone

nts / Units

of Service

Rate per

unit

(including

all taxes

except VAT

& state

entry tax)

VAT

State

Entry Tax

(If any)

Total Cost

Horizonta

l

connectiv

ity costs

LAN Cabling

(including

IO,CAT 6 cable ,

Casing Capping

Crimping)

400

network

points

2.

UPS

points &

electrical

cabling

15/5 AMP

socket with

switch and

wiring with

casing &

capping

500 UPS

electrical

points

Total B:

C. Application Development & Database Creation

1. e-District Application

a

Develop

ment of e-

District

Services

(as per

the scope

defined)

Including

training,

hand

holding

cost and

helpdesk

support

Total C:

D : Operations and Maintenance Costs (Quarterly Expenses (Software) for <3> years of contract after

„”Go-Live”) (D)

1.

Applicati

on

Maintena

nce &



S.

No. Category

Component No of

Compone

nts / Units

of Service

Rate per

unit

(including

all taxes

except VAT

& state

entry tax)

VAT

State

Entry Tax

(If any)

Total Cost

Operation

of e-

District

applicatio

ns

Total D:

E. Data Digitization

1. Scanning of A4 size For 100000

pages

2. Scanning of A3 size For 50000

pages

3. Scanning of legal size For 75000

pages

4. Cost of data entry

For 200000

records

(to be

quoted on

the basis

of 1000

characters

)

Total E:

Note: The figures indicated for data digitization are indicative only

F. Deployment and Operation & maintenance of requisite infrastructure for period of 5 years from

date of installation at State Data centre & IT Disaster Recovery

For Details of BOM. Please

refer volume II

1. Database Server 2

2. Application Server 2

3. Web Server 2

4. Backup and Reporting

Server

2

5. Development Server 2

6. Application Load Balancer 2



7. 10U Blade enclosure 1

8. KVM Switch 1

9. L3 network switch 1

10. Laptops 2

11. 5TB SAN Box 1

2 System Software

1. Server OS 10

2. RDBMS 2

3. Application server 2

4. Systems Management

software

2

5. Development environment 2

6. Virtualization software 1

7. Anti-Virus software 10

Total F:

Additional information to be provided by the bidder [ It is mandatory for bidder to provide this

information which will not be a part of financial bid evaluation. Failing to provide this information

will result into rejection of bid]

a. Cost of e-District Application software AMC for additional 2 years [after initial 3 years,

however it will be the State‟s call whether to give extended service contract for AMC to the e-

District SI or not, which will be informed to SI/bidder 3 months prior to completion of initial 3

years warranty . On award of AMC contract for next 2 years, the e-District SI/bidder must

provide AMC support. Any refusal/denial by SI/bidder for AMC support will be treated as

violation of the contract and will lead to blacklisting of the SI/bidder by the State and further

encashment of the performance bank guarantee]

b. Support Manpower

Support Manpower

S.No Support Manpower Rate/Month (inclusive of

service tax) Total

1. Project Manager

2. System/ Network Administrator

3. Solution Architect

4. Database Administrator

5. Software Programmer and Business Analyst

6. District Manager

7. District Technical Support

8. Helpdesk Executive

….

Total



c. Total Training Cost in Rs………

Training

Training Cost Per Person

Nos. Resources

to be trained

Rate (

Inclusive of

service tax)

Total

1. Basic computer skills 100

2. Advanced training on the Application modules 50

Total

d. Web Services

Web Services

Development of Web Services

Nos. Web

Services

Total Value

Inclusive of

service tax

1. Development of End to End Services 14

2. Development of Web Services (of NIC) 12

3. Development of interface for data from various departments

for selected services under e-District.

26

Total



ANNEXURE III: TEMPLATE FOR PBG

Form 1: Performance Bank Guarantee

PERFORMANCE SECURITY:

<Name>

<Designation>

<Address>

<Phone Nos.>

<Fax Nos.>

<Email id>

Whereas, <name of the supplier and address> (hereinafter called “the bidder”) has undertaken, in

pursuance of contract no. <Insert Contract No.> dated. <Date> to provide Implementation services for

<name of the assignment> to ITG (hereinafter called “the beneficiary”)

And whereas it has been stipulated by in the said contract that the bidder shall furnish you with a

bank guarantee by a recognized bank for the sum specified therein as security for compliance with its

obligations in accordance with the contract;

And whereas we, <Name of Bank> a banking company incorporated and having its head /registered

office at <Address of Registered Office> and having one of its office at <Address of Local Office> have

agreed to give the supplier such a bank guarantee.

Now, therefore, we hereby affirm that we are guarantors and responsible to you, on behalf of the

supplier, up to a total of Rs.<Insert Value> (Rupees <Insert Value in Words> only) and we

undertake to pay you, upon your first written demand declaring the supplier to be in default under

the contract and without cavil or argument, any sum or sums within the limits of Rs. <Insert Value>

(Rupees <Insert Value in Words> only) as aforesaid, without your needing to prove or to show

grounds or reasons for your demand or the sum specified therein.

We hereby waive the necessity of your demanding the said debt from the bidder before presenting us

with the demand.

We further agree that no change or addition to or other modification of the terms of the contract to be

performed there under or of any of the contract documents which may be made between you and the

Bidder shall in any way release us from any liability under this guarantee and we hereby waive notice

of any such change, addition or modification.

This Guarantee shall be valid until <Insert Date>)



Notwithstanding anything contained herein:

I. Our liability under this bank guarantee shall not exceed Rs. <Insert Value> (Rupees <Insert

Value in Words> only).

II. This bank guarantee shall be valid up to <Insert Expiry Date>)

III. It is condition of our liability for payment of the guaranteed amount or any part thereof arising

under this bank guarantee that we receive a valid written claim or demand for payment under

this bank guarantee on or before <Insert Expiry Date>) failing which our liability under the

guarantee will automatically cease.



ANNEXURE IV: TEMPLATE FOR CCN

Form 1: Change Control Notice (CCN) Format

Change Control Note CCN Number:

Part A: Initiation

Title:

Originator:

Sponsor:

Date of Initiation:

Details of Proposed Change

(To include reason for change and appropriate details/specifications. Identify any attachments as A1,

A2, and A3 etc.)

Authorized by : Date:

Name:

Signature:

Received by the IP

Date:

Name:

Signature:

Change Control Note

CCN Number:

Part B : Evaluation

(Identify any attachments as B1, B2, and B3 etc.)

Changes to Services, charging structure, payment profile, documentation, training, service levels and

component working arrangements and any other contractual issue.

Brief Description of Solution:

Impact:



Deliverables:

Timetable:

Charges for Implementation:

(including a schedule of payments)

Other Relevant Information:

(including value-added and acceptance criteria)

Authorized by the Implementation

Partner

Date:

Name: -

Signature:



ANNEXURE V: Details of horizontal connectivity through GBBN.



e-District MMP - Goa

ANNEXURE VI: Functional Requirement Specifications

(High Level)



Table of Contents

Glossary ...................................................................................................................................................... 102

List of Services Covered ............................................................................................................................103

General Functional Requirements for all services .................................................................................104

I. Collectorate Office .........................................................................................................................119

1. Issuance of Income certificate ......................................................................................................119

2. Issuance of Domicile Certificate ..................................................................................................121

3. Issuance of cast community certificate .......................................................................................123

4. Issuance of residence certificate ...................................................................................................126

5. Issuance of divergence certificate ................................................................................................128

6. Issuance of matriz certificate ........................................................................................................131

7. Revenue Court- case listing/adjournment/stay/final/status ................................................133

8. Arms License - Application for New/ Renewal of License .....................................................135

9. Issuance of Sound Permission .....................................................................................................138

10. Application for relief for victims of natural calamity ...............................................................141

II. Department of Settlement & Land Records ...............................................................................144

11. Issuance of Form I & XIV (Record of Right) ..............................................................................144

III. Goa State Information Commission ............................................................................................147

1. RTI Filing & Status Services .........................................................................................................147

IV. Panchayat/Municipality ...............................................................................................................150

13. Issuance of Birth/Death Certificate ............................................................................................150

V. Transport Department ..................................................................................................................153

14. Application for grant of subsidy for Yellow/Black Motor Cycle/Auto Rickshaw, Taxi

Scheme 2003 ................................................................................................................................................153

15. Application for grant of subsidy for replacement of buses/mini buses above 15 years .....155

VI. Fisheries Department ....................................................................................................................158

16. Application for Registration/ Renewal of Fishing Nets ..........................................................158

VII. Tourism Department .....................................................................................................................161

17. Registration of New Water Sports Activities .............................................................................161

VIII. Registration Department ..............................................................................................................164

18. Application for marriage registration certificate .......................................................................164

IX. Captain of Ports .............................................................................................................................167

19. Registration/Renewal of Inland Vessels ....................................................................................167



20. Registration/Renewal of Water Sport Vessels ..........................................................................169

X. Department of Sports & Youth Affairs .......................................................................................172

21. Registration of schools for participation in games ....................................................................172

22. Application for sportsperson certificate .....................................................................................174

23. Registration/Application for entry into state youth festival ...................................................176

24. Application for grant in aid for various educational institutes ..............................................178

XI. All Departments in state of Goa ..................................................................................................181

25. Recruitment form for non-gazette post of various Depts. across State ..................................181

26. Form for scheme management ....................................................................................................184



Glossary

S. No. Term Definition

1. APEO Assistant Physical Education Officer

2. APIO Assistant Public Information Officer

3. APL Above Poverty Line

4. BPL Below Poverty Line

5. CFC Common Facilitation Counter

6. COP Captain of Ports

7. CSC Common Service Centres

8. ESO Extended Service Outlets

9. GBBN Goa Broad Band Network

10. LAN Local Area Network

11. LSK Lok Seva Kendra

12. MMP Mission Mode Project

13. NIC National Informatics Centre

14. PIO Public Information Officer

15. SDC State Data Centre

16. Service Request Id The number that uniquely identifies an applicant

17. SPIO State Public Information Officer

18. SSDG State Service Delivery Gateway

19. TAT Turn Around Time



List of Services Covered

Sr.No Department Category Services

1. Collectorate Office

Certificates Issuance of Income Certificate

2. Certificates Issuance of Domicile Certificate

3. Certificates Issuance of Caste/ Community Certificate

4. Certificates Issuance of Resident Certificate

5. Certificates Issuance of Divergence Certificate

6. Certificates Issuance of Maritz Certificate

7. Revenue Court

Revenue Court –Case listing/adjournment/stay/Final/Status

8. Arms License Application / Renewal of Arms License

9. Tourism Application of Sound Service

10. Relief – Natural calamity

Applications for relief for victims of Natural Calamity

11. Department of Settlement & Land Records

Certificates Issuance of Form I & XVI (Record of right)

12. Goa State Information Commission

RTI Services RTI filling and status services

13. Panchayat/ Municipality

Certificates Issuance of Birth/Death Certificate

14. Transport Department

Transport Application for grant of subsidy for Yellow/Black Motorcycle ,Auto Rickshaw, Taxi Scheme 2003

15. Transport Application for grant of subsidy for replacement of buses/mini buses above 15 years old

16. Fisheries Department

Fisheries Application for Registration/ Renewal of Fishing Nets

17. Tourism Department

Others Registration of New water sports activity

18. Registration Department

Certificate Application for Marriage Registration certificate

19. Captain of Ports

Certificate Registration/Renewal of Inland Vessel

20. Registration/Renewal of Water Sport Vessel

21. Department of Sports

Certificate Registration of Schools for participation in Games

22. Application for Sportsmen certificate

23. Registration/Application for entry into State Youth Festival

24. Application for grant-in-aid for various Educational Institutes

25. Generic Forms Generic Recruitment form for non-gazette post of various Depts. across State

26. Form for Scheme management



General Functional Requirements for all services

All services - General Requirements

Requirement ID

Description

GEN.1

Since the user base can include people with disabilities, system must ensure that standards with respect to accessibility and usability of websites for people with disabilities are adhered to. For e.g.

- Web Content Accessibility Guidelines ver. 2.0

- User Agent Accessibility Guidelines ver. 2.0

- Web Accessibility Initiative guidelines

- Other latest W3C guidelines etc.

GEN.2 System shall be designed for interoperability and ease of integration through use of web services.

GEN.3 System shall ensure that every transaction by service seeker is audit trailed. Audit trail shall have timestamp, user id/name and type of change.

GEN.4 All forms that are accessible from the public website shall be scanner capable.

GEN.5 The online web application and the state portal shall be available in English and the state local language (Marathi & Konkani) with the capability to switch between the two

GEN.6 Digital images and text extracted from digital images shall be saved in non-proprietary file formats, such as ASCII for text or TIFF for images

GEN.7 System shall provide compatible interfaces, metadata and indexing support for exchange of electronic documents with Scanner APIs, digital imaging Programs and document management software

GEN.8 All forms shall be created on standard A4 paper (as defined by standard ISO 216: 2007)

GEN.9 All kinds of notifications whether internal or external through channels such as email, SMS and letter shall be recorded.

GEN.10 All kinds of notifications shall be assigned a designated user to whom response will be communicated.

GEN.11 All documents scanned shall be indexed, identifier provided and stored for easy retrieval. Shall be linked to related service seeker record in database

GEN.12 System shall provide for expunging, redaction and encryption support for the scanned forms and documents.

GEN.13 All activities of user shall be logged in System. The log among other shall include the user id, access date and time, transaction and type of accesses made

GEN.14 System shall maintain a log of all user activities related to access. The log, among other details, shall include the user id, access date and time, and type of accesses made. The log shall be linked to the application record and available for access

GEN.15 System shall provide a facility to save the data provided in all kinds of forms available in the web application or the state web portal for a pre-defined interval even if the form in only partially complete. System shall allow filling of the form

GEN.16 All forms shall be accompanied by a well-written set of instructions - in English, Marathi & Konkani and the State official language - on how to fill up the form and the mode of submission

GEN.17 All notifications / alerts / reminders shall be as per as a standard format/ template that is configurable

GEN.18 System shall display the date and time of last login when the user logs in



GEN.19

System shall checks for duplicate numbers prior to accepting new e.g.:

-Application Number

-ESO/CSCs Center ID

-Service Request No

GEN.20

System shall have a fail-proof online modification submission process. System shall have performed the commit of the return data to the database only once if the transaction has gone through successfully. In case the transaction has not been fully com

GEN.21 System shall ensure virus check for all files that are uploaded in System e.g. detect malicious executable

GEN.22 For all kinds of online forms, system shall allow downloading of an electronic form and uploading of the filled-in form at a later stage

GEN.23 Where ever documents are involved, system shall allow the user to assign a note/annotation to a document image

GEN.24

Where ever workflow systems are involved, Workflow systems shall be designed in such a manner that introduction of additional workflow requirements or changes to existing workflow can be implemented without underlying architectural or programming changes

GEN.25 System shall allow all offices and sub offices of concerned department to be inter connected internally within departments through SSDG interface to work together

GEN.26 System shall allow all other concerned department offices and sub offices of to be connected through SSDG interface if required

GEN.27 System shall provide consistent look & feel to the users and the standards defined for content, structure and presentation of the portal shall be applied and followed throughout the portal

GEN.28 System shall allow to accept unique ID as proof of document which can be verified internally within departments through SSDG interface

GEN.29 The solution shall provide Metadata directories or indexes of data related to the data available within the application to facilitate search

GEN.30

External Interface: System shall support external interface (interfaces outside application boundary). For e.g. sending, receiving, or exchanging data with other organizations or individuals, and does not include any processing beyond data exchange

GEN.31 Facility: System shall support facility requirements that describe physical aspects a particular system must have

GEN.32 Functional: System shall support functional requirements that for functioning of a software system or its component

GEN.33 General: System shall support general requirements that apply to all processes and sub-processes.

GEN.34 Internal Interface: System shall support internal interface requirements within the application boundary.

GEN.35 Manageability:



System shall support manageability requirements for ease of management of a system

GEN.36 Performance: System shall support performance requirements that constitute response time and throughput requirements

GEN.37 Reliability: System shall support reliability requirements for the consistency of an IT system

GEN.38 Standards: System shall support standards specified where the design or implementation is necessitated to follow a published standard

GEN.39 Usability: System shall support usability requirements that describe ease of use of system by end user

GEN.40 Security: System shall have adequate security features built in the architecture of the system to ensure that it cannot be hacked or manipulated

All services - General Login Requirements

Requirement ID

Description

LOG.1

Shall display the login page as the first page when the user / new user enters the e-District application with online tutorials, "How To", FAQs, etc. that can be used on their own to familiarize themselves with keying-in the registration data and the login process

Shall allow only the authentic users (ESO/CSCs/CFC Centre Operators, Department Officials and citizen) to login to System through the use of: -Bio metric device using the thumb impression -User id and Password combination -Both

LOG.2

(Thumb Impression Based Biometric Device) -System shall map the thumb impression of all the users to the application database and only these users shall be allowed to enter the e District application. In case of any irregularities the combination of thumb impression and digital signature put on the document would be used to mark responsibility.

LOG.3 System shall allow new user to create log in Id. & Password

LOG.4 System shall give a welcome message once the user is able to successfully login to the e district application

LOG.5 System shall give an error message once the user provides wrong login Information and ask the user to re log in.

All services - General User Id. Requirements

Requirement ID

Description

UID.1

System shall allow registration of user to create user. Id for future login and ease (registration not mandatory) with online tutorials, "How To", FAQs, etc. that can be used on their own to familiarize themselves with keying-in the registration data for user. Id/ retrieval of user Id



UID.2 System shall perform data validation checks on the input and in case of data being duplicated, System shall display the existing User Id for registered use.

UID.3 The user-name for Government employees must mandatorily to be the Permanent Employee Number (PEN) or any Unique Identification No. issued by Department or Govt. of Goa.

UID.4 The user name shall have a minimum set of characters

UID.5 System shall not create duplicate user ids and shall not allow same user id and password for a single entity in System.

UID.7 System shall not allow blank spaces while setting user id and shall notify the user in case the Caps Lock or Num. Lock is on while entering the Username.

UID.8 System shall allow a user who forgets the user id to access the user retrieval mechanism via e-mail/ sms.

UID.9 System shall support multilingual interface (minimum Konkani, Marathi and English) as per localization and language technology standards defined in e-District guidelines

Log-In User Id. For Govt. employees & ESO/CSC/CFC, operators shall be provided by DoIT, ITG & Concerned departments -which will expired/blocked on successful complete-ion or termination of working tenure of concerned employee in concerned department)

All services - General Password Requirements

Requirement ID

Description

PAS.1

System shall allow registration of user to create password for future login and ease (registration not mandatory ) with online tutorials, "How To", FAQs, etc. that can be used on their own to familiarize themselves with keying-in the registration data for setting password/ retrieval of password )

PAS.2

System shall only allow user to choose the password which must be a combination of following: -Alphabets, Symbols & Numeric. -Weak Password shall not be allowed to be chosen by user

PAS.3 System shall allow password having a minimum of set of characters, preferably 8 and shall not allow the user to have the same password for more than 90 days

PAS.4 System shall generate alerts for password expiry at regular intervals five days prior to actual expiry and prompt user to change password

PAS.5 System shall not allow blank spaces while setting password

PAS.6 System shall notify the user in case the Caps Lock or Num. Lock is on

PAS.7 System shall allow a user who forgets the password to access the password retrieval mechanism., maybe via answering to a selected question or mailing the password to the given e-mail id provided at time of registering.

PAS.8 System shall allow user on Log-in failure to click on the “Forgot Username/ Password” link and request for a fresh username password from the Administrator

PAS.9 System shall allow a user who forgets the password to access the password retrieval mechanism via e-mail/ sms with a notification for the same to the user & administrator

PAS.10 System shall prompt the user to change the password in case of first login at the client side i.e. after imaging



PAS.11 System Shall prompt the user to change the password in case of first login at the client side i.e. after imaging

PAS.12 System Shall give an error message once the user provides wrong login information and ask the user to re log in.

PAS.13 System shall block the user to enter into the e district application if he puts in wrong login info continuously thrice.

PAS.14 System shall support multilingual interface (Marathi, Konkani and English) as per Localization and Language Technology Standards for National e-Governance Plan defined in e-District guidelines

User Password for Govt. employees & ESO/CSC/CFC, operators shall be provided by DoIT, ITG & Concerned departments - Which has to be changed in within first 30 days of use with personal password -which will expired/blocked on successful complete-ion or termination of working tenure of concerned employee in concerned department

All services - Information Requirements

Requirement ID

Description

INF.1 System shall allow authorized user to update information obtained from department with online tutorials, "How To", FAQs, etc.

INF.2 System shall allow user to add/ update new/existing information document as required

INF.3 System shall allow only the department authorized official to make changes in the updated information hosted over the e district application on receiving his/her digital signature after each updating

INF.4

System shall provide detailed information on the following to the user as per requested service: e.g. Eligibility Criteria(if any),Nodes of obtaining service, Application Fees, Grievance filing procedure (if any), Authorities to contact, Forms and documents required, Service Levels ,other locations for obtaining detailed information etc.

INF.5 System shall allow citizens, department officials, other government officials, ESO/CSC/CFC operators etc. to access the information

INF.6 System shall not allow any un authorized user to upload information besides authorized officials/ user for related content

INF.7 System shall have different presentation layer for each set of users i.e. Information seekers, updaters, approvers etc.

INF.8 System shall notify the authorized administrator for any suspicious uploaded/published information

INF.9 System shall the concerned department head for any information updated over the state/ department portal

INF.10 System shall have a counter at the bottom of the page to record the number of people hitting the website, this would prove beneficial in capturing the usefulness of information

INF.11 System shall auto generate logs in case of authorized official for not performing against their set SLAs

INF.12 System shall support multi-lingual interface (Marathi, Konkani and English) as per localization and language technology standards (Unicode) for National e-Governance plan defined in the e-District guidelines



INF.13 System Shall prompt the user to change the password in case of first login at the client side i.e. after imaging

All services – Payment Requirements

Requirement ID

Description

PAY.1

System shall allow to trigger payment process when the applicant/ citizen requires to make a payment for the service delivery (with online tutorials, "How To", FAQs, etc. that can be used on their own to familiarize themselves with the payment process)

PAY.2 System shall provide for and allow financial transaction functions and shall check for all details of the service request form before initiating the payment

PAY.3 (System shall enable the payment option only when all the fields of service request forms are filled and shall return back and highlight the field which have inconsistencies / error for user to rectify the error

PAY.4

System shall retain all the information of the service request form besides those having inconsistencies and Shall return back after successful checking of the fields with the prompt of confirmation to open the payment page

PAY.5

System shall open a new page for recording payment details against the service request and Shall allow payment to be registered on the service application request against the following –

a. Payment against the service b. Payment against the dues / payments as defined under service charter

of the specific service

PAY.6 System shall record and maintain all details of payment against a unique service application number and system shall be able to maintain all the payment records in a database and retrieve the same as and when required

PAY.7 System shall be able to open a page with declaration on successful payment output and system Shall able to record specific payment details on the service request form after successful payment has been made.

PAY.8

System shall be such that it Shall allow for part payment function and shall be able to retrieve information of first part payment during the final delivery of service output for final payment as per the overall payment specified for service request

a. Unique application number for requested service b. ESO/CSC centre details and unique number for these centres

PAY.9 System shall be able follow the payment cycle as mentioned above for the final payment also and system Shall be able to maintain all records of part payments as well as consolidated payment amount against the service request

PAY.10 System shall support multi-lingual interface (Marathi, Konkani and English) as per localization and language technology standards for National e-Governance plan defined in the e-District guidelines

PAY.11 System shall give a welcome message once the user is able to successfully login to the e district application

PAY.12 System shall give an error message once the user provides wrong login Information and ask the user to re log in.



All services – Form Availability Requirements

Requirement ID

Description

FAR.1 System shall be able to make available service request form should be through -Online / website -ESO/CSC/CFC Centre

FAR.2 The system shall allow easy searching of the service request form and user friendly layout for locating the service request form

FAR.3 System shall allow authorized user to update forms obtained from department with online tutorials, "How To", FAQs, etc.

FAR.4 System shall be able to export forms in multiple formats so as to ensure compatibility of forms

FAR.5 System shall have a life counter feature to keep track of number of forms being downloaded from the state/department portal using e-District application

FAR.6 System shall allow user to add/ update new/existing forms as required and shall have provision of uploading new version of the forms as and when it is required to change the version

FAR.7 System shall have a security feature embedded for changing the version of the form and should allow only authorized process owners to change the form version

FAR.8 System shall allow only the department authorized official to make changes in the updated forms hosted over the e district application on receiving his/her digital signature after each updating

FAR.9

System shall provide detailed information on the following to the user as per requested service: e.g. Eligibility Criteria(if any),Nodes of obtaining service, Application Fees, Grievance filing procedure (if any), Authorities to contact, Forms and documents required, Service Levels ,other locations for obtaining detailed information etc.

FAR.10 System shall allow citizens, department officials, other government officials, ESO/CSC/CFC operators etc. to access the information

FAR.11 System shall store all the service request form at predefined location for the finalized services

FAR.12 System shall be able to retrieve service request form from the predefined location.

FAR.13 System shall allow user to download form as per service request easily downloadable both through .pdf, HTML and word format & provide printable version of the service request form

FAR.9 System shall give an error message in case it is not able to retrieve the application from the given location

FAR.10 System shall have a provision to maintain the version control for the service request form

FAR.11 System shall maintain log for all version change with the details of the process owner making version change

FAR.12 System shall not allow to change the content of the form and content should be in read only version

FAR.13 System shall support multi-lingual interface (Marathi, Konkani and English) as per localization and language technology standards (Unicode) for National e-Governance plan defined in the e-District guidelines



All services - Verification Requirements

Requirement ID

Description

VER.1 System shall allow the concerned authority / official or process owner in process to enter query to search in any Database connected with the System

VER.2 System shall query the specified database and return the result of the same to the concerned authority / official or process owner

VER.3 System shall be able to retrieve information from the individual databases and aggregate it before displaying it

VER.4 System shall display the details of the applicant in a table prompting the field/verifying officer “check” “OK” or “NOT OK” against each based on his/her verification.

VER.5 System shall prompt the field/verifying officer to enter the details of the means of verification and enter specifics of the same (like if physical verification: date etc. and in case online verification: database etc.)

VER.6 System shall allow the field/verifying officer to modify the database as per the access rights defined for every service (by department) and modification to the database will be based on field inputs to be keyed in by field/verifying officer

VER.7 System shall decode the digital signed data and display the details of the signatory (when required)

VER.8 System shall allow the field/verifying officer to electronically forward the application back to the concerned authority / official or process owner after the details in the database have been updated

VER.9 System shall notify the concerned authority / official or process owner after the field officer has marked the application back to him/her

VER.10 System shall allow the concerned authority / official or process owner to either approve or reject the application as per the approval or rejection component, using his/her digital signature.

VER.11 System shall ensure that a reason for rejection is entered by the concerned authority / official or process owner if he/she selects to reject an application before submitting the rejection.

VER.12 System shall log all the electronic movements of the application with date and time details along with the sender‟s and receiver‟s information

VER.13

System shall support digital signatures of any of the certifying authorities registered under the controller of certifying authorities, and must be modifiable as per the changes made by the respective Certifying Authorities on the structure of the Digital Signatures issued by them.

VER.14 The Digital Signatures used and the e-District Application must provide the Time Stamping of the act of Digitally Signing a document as mandated by the IT Act 2000.

VER.15 System shall support multi-lingual interface (Marathi, Konkani and English) as per localization and language technology standards (Unicode) for National e-Governance plan defined in the e-District guidelines

VER.16 System shall be able to provide date and time stamping for all transactions done with digital signature

VER.17 System shall be able escalate the application as per the process work flow hierarchy, by notifying the next level of authority and sending him a copy of the application and system shall also flag the database which was found inconsistent



based on his/her verifications and intimate the concerned database owner

All services - Status Requirements

Requirement ID

Description

STA.1 System shall display the link for requested service on state/department portal from where the applicant can retrieve the status information by entering the unique application reference id

STA.2 System shall also allow the applicant to retrieve update about his/her service request through the web portal by entering the reference id in the link provided on the portal

STA.3 System shall display the number from where the applicant can retrieve the status information by sending SMS along-with the unique application reference id

STA.4 System shall have Side Menu on each page so as to reflect the contents of the containing directory, making it easier to navigate the site and locate the link for retrieving update against a given reference id

STA.5 System shall have integrated auto status tracking features in the system that shall keep track of all the service requests from the citizens along with the respective unique application reference id generated at the time of the application receipt

STA.6 System shall be able to keep track of the status of all the service requests with the help of the respective unique application reference id (application id) and map the current status with the pre-defined service level against each process

STA.7 System shall be available in public and administrative view

STA.8

System shall be able to detect any change in the status of a given unique application reference id - In case there is a change in the status of a unique application reference id , the system shall update the status information in the database

STA.9 System shall have provisions for intimating the applicant about the current status of his/her application through SMS and/or Email especially if there is a change in the status with respect to the final delivery of the service

STA.10

System shall not provide details about the internal SLAs to the applicant and only provide update about the status with respect to the final delivery. -This feature should also allow the system to update the applicant if there is any change in the service level of the final delivery

STA.11 System shall allow the applicant to retrieve update about his/her service request by sending a SMS containing the unique application reference id

STA.12 System shall display an appropriate message if the system is unable to retrieve the details due to any reason like connectivity issues, maintenance issues, etc. and also provide contact details of the system administrator and alternate link (if available)

STA.13 System shall have adequate security features built in the architecture of the system to ensure that it cannot be hacked or manipulated

STA.14 System shall not allow the users to edit the details of the application upon retrieving the status update against a given reference id

STA.15 System shall allow the end user to print the status update information if the applicant is retrieving the status through the portal or email

STA.16 System should have provision for Calendar System, which displays the dates and time of schedule events on a page formatted as a standard monthly calendar



STA.17 System shall have provisions such that the System Administrator can add/remove/modify the hierarchy of the Government officials with adequate authentication mechanism

STA.18 If there is any modification in the hierarchy of the relevant authority against a given service (in the system), system shall automatically map the escalation levels with the new hierarchy of Government officials

STA.19 System shall have additional capability to integrate and extend portals to support a vast array of mobile devices in addition to PCs (WAP enabled)

STA.20 The points in process where status would be updated has to be marked in the service status process map as well system shall be able to generate MIS reports

STA.21 System shall allow the end user to print the status update information if the applicant is retrieving the status through the portal or email

STA.22 The System shall support provision for IVRS/ Call centre/SMS/online option for status checking

STA.23 System shall support multi-lingual interface (Marathi, Konkani and English) as per localization and language technology standards (Unicode) for National e-Governance plan defined in the e-District guidelines

All services – Approval Requirements

Requirement ID

Description

APRV.1

System shall show & intimate the users through predefined channels for pending approval on a daily basis as soon as service owner login to the system - The pending approvals should highlighted for the users on entering the Application - The pending approvals should be intimated to the users through SMS on predefined intervals until the same is addressed and closed by the respective process owner

APRV.2 System shall have a provision to mark the approval of service request and also allow the user to digitally sign the documents one by one

APRV.3 System shall allow the user the digitally sign all the selected approved service request at one go

APRV.4 Upon digitally signing the document, digitally signed document should be saved in the given repository for future references and a hard copy of the same document will be provided to the applicant

APRV.5 System shall open a page for all approved service request with a prompt of digital signature in form a button to initiate the process of digital signing

APRV.6 System shall reconfirm from the user for initiating the digital signing before actually initiating the process

APRV.7 System shall provide a link to the page where the user can enter the unique encrypted key/code printed on the hard copy of the document to check for the authenticity of the document

APRV.9 On clicking the link, system should display the fields as described in the section Document retrieval form such that the user can retrieve the required information

APRV.10

System shall print the unique encrypted key/code on the hard copy of the digitally signed document such that the same printed unique encrypted key/code can be used to check the authenticity of the document. The unique encrypted key/code will be information of the authority who digitally signed the document in the



encoded form

APRV.11 System shall retrieve and display the digitally signed document on the user screen once the user enters the unique encrypted key/code printed on the document

APRV.12 System shall not allow the user to make any alteration in the digitally signed document or access the database on entering the unique encrypted key/code

APRV.13 System shall display an appropriate message in case of retrieval failure or any other communication failure or in case the document could not be found due to any reason

APRV.14 System should allow the user to terminate the approval process at any point of time during approval

APRV.15 System shall keep and maintain the data in a data repository (database): -For all the approval made -All transaction performed and link it to the unique code of digital signature

APRV.16 System shall open a page informing the user of successful completion of approval

APRV.17 System shall open a page at any point of process in case the process termination with the request to restart the process

APRV.18 System shall not allow the user to initiate the process of digital signature in case of no selection of pending service request for approval

APRV.19 System shall not allow the user to modify the approval once it has been digitally signed

APRV.20 System shall not allow the user to delete any service request pending for approval at his end

APRV.21 System shall open a page at any point of process in case the process termination with the request to restart the process

APRV.22 System shall not allow the user to initiate the process of digital signature in case of no selection of pending service request for approval

APRV.23 System shall not allow the user to modify the approval once it has been digitally signed

APRV.24 System shall not allow the user to delete any service request pending for approval at his end

APRV.25 System shall support multi-lingual interface (minimum Marathi, Konkani and English) as per localization and language technology standards for National e-Governance plan defined in the e-District guidelines

All services – Rejection Requirements

Requirement ID

Description

RCJT.1

System shall highlight & intimate the users for pending service request application on a daily basis as soon as service owner login to the system - The pending approvals/rejections should be intimated to the users through SMS on predefined intervals until the same is addressed and closed by the respective process owner



RCJT.2 System shall have a provision to mark the approval/rejection of service request and system shall allow the user to digitally sign the documents one by one.

RCJT.3 System shall also allow the user the digitally sign all the rejected service request at one go

RCJT.4 System Shall be able to maintain the database of the all the service delivery output in a logical manner to ease the retrieval of the same as and when required

RCJT.5 System shall open a page with marked rejected application form and text entry provision against all the rejected application form

RCJT.6 System shall have allow process owner to state the reason for rejection of the service request

RCJT.7 system shall close the service request only and only once the reason text box is filled

RCJT.9 System shall allow downloading of the service delivery output only after matching the digital verification and system shall provide for the printable version of the service output

RCJT.10 System shall open a page for all rejected service request with a prompt of digital signature in form a button to initiate the process of digital signing & reconfirm from the user for initiating the digital signing before actually initiating the process

RCJT.11 Upon digitally signing the document, digitally signed document should be saved in the given repository for future references and a hard copy of the same document will be provided to the applicant

RCJT.12

System shall print the unique encrypted key/code on the hard copy of the digitally signed document such that the same printed unique encrypted key/code can be used to check the authenticity of the document. The unique encrypted key/code will be information of the authority who digitally signed the document in the encoded form

RCJT.13 System shall provide a link to the page where the user can enter the unique encrypted key/code printed on the hard copy of the document to check for the authenticity of the document

RCJT.14 On clicking the link, system shall display the fields as described in the section Document retrieval form such that the user can retrieve the required information

RCJT.15 System shall retrieve and display the digitally signed document on the user screen once the user enters the unique encrypted key/code printed on the document

RCJT.16 System shall not allow the user to make any alteration in the digitally signed document or access the database on entering the unique encrypted key/code

RCJT.17 System shall display an appropriate message in case of retrieval failure or any other communication failure or in case the document could not be found due to any reason

RCJT.18 System shall allow the user to terminate the rejection process at any point of time during rejection & system shall keep and maintain the data in a data repository (database) for all the rejection made

RCJT.19 System shall be able to keep the records of all transaction performed and link it to the unique code of digital signature & system shall open a page informing the user of successful completion of approval

RCJT.20 System shall open a page at any point of process in case the process termination with the request to restart the process

RCJT.21 System shall not allow the user to initiate the process of digital signature in case of no selection of pending service request for approval/rejection



RCJT.22 System shall not allow the user to modify the rejection once it has been digitally signed

RCJT.23 System shall not allow the user to delete any service request pending for rejection at his end

RCJT.24 System shall support multi-lingual interface (minimum Marathi, Konkani and English) as per localization and language technology standards for National e-Governance plan defined in the e-District guidelines

All services – Delivery Requirements

Requirement ID

Description

DLVR.1

System Shall be able to provide citizen/applicant/ESO/CSC Operator to select option of delivery for his her selected service against all service request made and system Shall be able to link delivery against specific service request through unique service application request number.

DLVR.2 System Shall be able to provide delivery against all service request made The system Shall be able to link delivery against specific service request through unique service application request number

DLVR.3

The system Shall allow delivery only when the service request has been either approved / rejected and also system Shall allow only validated predefined users to log into the e-District application for retrieving the delivery against the service request

DLVR.4 The system Shall ask for unique service request number / unique application number to retrieve specific service delivery

DLVR.5 The system Shall ask for the digital verification from the authenticated predefined users

DLVR.6

The system Shall support multi-lingual interface (minimum Marathi, Konkani and English) as per localization and language technology standards for National e- Governance plan defined in the e-District guidelines The output for all services from e-District Shall be uniform in fonts. For this pdf. output may be considered.

DLVR.8 The system Shall open new page specifying error in case of incorrect digital verification

DLVR.9 The system Shall be able to maintain the database of the all the service delivery output in a logical manner to ease the retrieval of the same as and when required

DLVR.10 The system Shall have a life counter to keep log of all delivery made with specific association of unique service application number and unique ESO/CSC centre number

DLVR.11 The system Shall allow downloading of the service delivery output only after matching the digital verification and system Shall provide for the printable version of the service output

DLVR.12 The system Shall send automated response to applicant via SMS, e-Mail etc. regarding final output being ready for a particular service request.

All services – Monitoring Requirements

Requirement ID

Description



MNT.1

System shall display the link for requested service on state/department portal

from where the applicant can retrieve the information by entering the unique

application reference id

MNT.2

System shall have side menu on each page so as to reflect the contents of the

containing directory, making it easier to navigate the site and locate the link for

retrieving update against a given reference id

MNT.3 System shall allow process owner to use the e-District Application (eDA) to query

the departmental databases using the name or other details of the applicant.

MNT.4 System shall allow service owner to retrieve display information with the unique

application reference id from the individual databases and aggregate it.

MNT.5 System shall support the monitoring in both the occurrence, when an event or time driven activity is triggered.

MNT.6 System shall be able to retrieve all information about the status of the application form of the citizen.

MNT.7 System shall be able to keep track of the status of all the service requests with the help of the respective unique application reference id (application id) and map the current status with the pre-defined service level against each process

MNT.8 System shall be able to automatically generate the MIS reports to the concerned

authorities at regular time interval. (as required by department)

MNT.9 System shall allow generating Service Report on a regular time interval; these reports should include the no of application received, no of application processed, no of application rejected and the no of application under process.

MNT.10 System shall allow generating SLA Report on regular time interval; these reports should give information related to centre wise details of no of SLA met and centre wise details of no of SLA breached.

MNT.11 System shall allow generating Performance Report on regular time interval; this report should give information related to centre wise details of no of application processed against the no of application received.

MNT.12

System should be able to generate Payment Report (as commanded by process

owner) on regular time interval, this report should give information related to

centre wise transaction, money collected and money deposited along with date

and time.

MNT.13

System shall allow to generate Inventory Report on regular time interval, this

report should give information related to pre-printed stationary used and issued to

each centre

MNT.14 System shall be able to generate Attendance Report on regular time interval; this report should give information related to centre wise attendance.

MNT.15

System shall provide a search option to the authorized stakeholder so that he can

search the information which should be sorted according to Date, Department,

Service, District, Taluka and Village

MNT.16 Should allow the stakeholder to review the progress report and give his/her

comments online

MNT.17 System shall provide the facility to print and e-mail the report.

- For printing – System shall provide friendly version automatically for all pages.



MNT.18 System should have provision for Calendar System, which displays the dates and time of schedule events on a page formatted as a standard monthly calendar

MNT.19 System shall support multi-lingual interface (Marathi, Konkani and English) as per localization and language technology standards (Unicode) for National e-Governance plan defined in the e-District guidelines



I. Collectorate Office

Requirement Specifications

Collectorate Office

1. Issuance of Income certificate

Requirement ID

Description

CER.IIC.1 System shall allow applicant/ESO/CSC/CFC operator to select Collectorate Office from the Home page of the State Portal

CER.IIC.2 System shall allow registration of applicant for future login and ease (registration not mandatory)

CER.IIC.3 System shall allow applicant to select application for Income certificate on the Collectorate office page of the state portal

CER.IIC. 4 System shall accept application of new applicants

CER.IIC.5

System shall be able to capture the applicants details through an electronic form such as: 1)Name 2)Contact Details 3)PIN 4)Age 5)Details as required in application form used 6)Unique Identification (UID) 7)E-mail id (if any) 8)Mobile No. (if any)

CER.IIC.6 System shall require entries from the user for certain important information items entered twice. For example email id needs to be captured correctly if email is the preferred mode of communication

CER.IIC.7 System shall provide adequate aid to the user in the form of online tutorials, "How To", FAQs, etc. that can be used on their own to familiarize themselves with keying-in the registration data and the registration process

CER.IIC.8 System shall allow the applicant to preview the application form

CER.IIC.9 System shall apply spam control measures during registration to avoid spurious details being automatically submitted and ensure that data is not submitted by non-humans

CER.IIC.10 System Shall allow add/ delete/ editing before submission

CER.IIC.11 System shall perform data validation checks on the input. In case of data being duplicated, System shall display the existing service request id.

CER.IIC.12 System Shall allow save and print facility of the acknowledgement slip

CER.IIC.13 Validation for file type that shall be allowed to be uploaded, include only formats such as .pdf/.doc.tiff/.rtf. It Shall not allow .executable files.

CER.IIC.14 System shall allow to accept unique ID as proof of document which can be verified internally within departments through e-District interface

CER.IIC.15 System shall display the respective communication address and turnaround time to submit documents in case the applicant selects the option to submit physical documents

CER.IIC.16 System shall as a part of application establish challenge and responses mechanisms for session validation for future online sessions.



CER.IIC.17 System shall perform data validation checks on the completeness of the form in terms of mandatory fields, checking for file type and size of files uploaded, etc. In case of any validation failure, System shall display an appropriate error message.

CER.IIC.18 System shall time out the session if it is idle for more than fifteen minutes.

CER.IIC.19 The system should return to main menu after print out of the receipt has been taken

CER.IIC.20 System shall apply spam control measures during registration to avoid spurious details being automatically submitted and ensure that data is not submitted by non-humans

CER.IIC.21 System shall allow the user to visit the secured payment gateway in case the user selects the option to make the payment through net banking, debit card or credit card

CER.IIC.22 System shall display the respective communication address/ drop box and turnaround time to make payment in case the applicant selects the option to make payment through bearer cheque

CER.IIC.23 System shall be able to provide unique 'Service Id Request' acknowledgement to the user along with expected TAT

CER.IIC.24 System shall allow user to save and print the acknowledgement for enquiry and grievance purposes

CER.IIC.25

System shall allow user to track the status of the application request along with remarks to the user such as: 1. Pending confirmation 2. Application accepted 3. Application declined

CER.IIC.26 User shall be able to print and save the notification for easy retrieval of information for future reference

CER.IIC.27 System shall allow the user to rectify the error (in case of application declined) and re-submit the same application

CER.IIC.28 System shall allow only authorized users to access the scanned supporting documentation and verify with other departments if required

CER.IIC.29 System shall allow the user to re- submit the application only after validating the authenticity of the user through challenges and response

CER.IIC.30 System shall send an activation URL to the email id of the respective official responsible to accept the application

CER.IIC.31 System shall allow the concerned authority to enter query parameters for the Database and then display the results for the query to the respective authority

CER.IIC.32 System shall log all changes to the document (Forwarding, approval, rejection) with date and time of the action.

CER.IIC.33 System shall save the digitally signed copy of the Certificate issued as a softcopy in a Database

CER.IIC.34 System shall log the details of who accessed the online soft copy and took a printout of the same.

CER.IIC.35 System shall allow the Village Officer to create or update the certificate details in Database.

CER.IIC.36 System shall send an automated escalation mail to the next level of authority in case the respective official does not attend the application URL within TAT



CER.IIC.37 System shall allow and accept the digital signature from respective officials for processing the application and issue of certificate for the users

CER.IIC.38 System shall allow the respective official to update the status of the application request as per proceedings along with the remarks

CER.IIC.39 Any change to the application record shall generate a change log with details like name of the user making the changes, timestamp of transaction, etc.

CER.IIC.40 System shall allow to intimate citizen for issuance of income certificate or rejection of income certificate (with reason/remark)

CER.IIC.41 System shall allow to upload the scanned/ PDF copy of certificate in the State portal where citizen can take the print of it

CER.IIC.42 System shall be PKI enabled to accept digital signatures certificate for digital signing of the documents.

CER.IIC.43 System shall consider the list of holidays for tracking the timelines of various

CER.IIC.44 System shall support multilingual interface (minimum Konkani , Marathi and English) as per Localization and Language Technology Standards for National e-Governance Plan defined in e-District guidelines

CER.IIC.45

Income Certificate module of DC Suite/ Taluka Suite/e-District application should be linked to general all service component appropriately as per department requirement – e.g. Information component, Form availability component etc.

2. Issuance of Domicile Certificate

Requirement ID

Description

CER.IDC.1 System shall allow applicant/ESO/CSC/CFC operator to select Collectorate Office from the Home page of the State Portal

CER.IDC.2 System shall allow applicant to select application for Domicile certificate on the Collectorate office page of the state portal

CER.IDC.3 System shall allow registration of applicant for future login and ease (registration not mandatory)

CER.IDC.4 System shall accept application of new applicants

CER.IDC.5

System shall be able to capture the applicants details through an electronic form such as: 1)Name 2)Contact Details 3)PIN 4)Age 5)Details as required in application form used 6)Unique Identification (UID) 7)E-mail id (if any) 8)Mobile No. (if any)

CER.IDC.6 System shall require entries from the user for certain important information items entered twice. For example email id needs to be captured correctly if email is the preferred mode of communication

CER.IDC.7 System shall provide adequate aid to the user in the form of online tutorials, "How To", FAQs, etc. that can be used on their own to familiarize themselves with keying-in the registration data and the registration process

CER.IDC.8 System shall allow the applicant to preview the application form



CER.IDC.9 System shall apply spam control measures during registration to avoid spurious details being automatically submitted and ensure that data is not submitted by non-humans

CER.IDC.10 System Shall allow add/ delete/ editing before submission

CER.IDC.11 System shall perform data validation checks on the input. In case of data being duplicated, System shall display the existing service request id.

CER.IDC.12 System Shall allow save and print facility of the acknowledgement slip

CER.IDC.13 Validation for file type that shall be allowed to be uploaded, include only formats such as .pdf/.doc.tiff/.rtf. It Shall not allow .executable files.

CER.IDC.14 System shall allow to accept unique ID as proof of document which can be verified internally within departments through e-District interface

CER.IDC.15 System shall display the respective communication address and turnaround time to submit documents in case the applicant selects the option to submit physical documents

CER.IDC.16 System shall as a part of application establish challenge and responses mechanisms for session validation for future online sessions.

CER.IDC.17 System shall perform data validation checks on the completeness of the form in terms of mandatory fields, checking for file type and size of files uploaded, etc. In case of any validation failure, System shall display an appropriate error message.

CER.IDC.18 System shall time out the session if it is idle for more than fifteen minutes.

CER.IDC.19 The system should return to main menu after print out of the receipt has been taken


CER.IDC.21 System shall allow the user to visit the secured payment gateway in case the user selects the option to make the payment through net banking, debit card or credit card

CER.IDC.22 System shall display the respective communication address/ drop box and turnaround time to make payment in case the applicant selects the option to make payment through bearer cheque.

CER.IDC.23

System shall allow user to track the status of the application request along with remarks to the user such as: -Application accepted -Application declined -Pending confirmation

CER.IDC.24 System shall be able to provide unique 'Service Id Request' acknowledgement to the user along with expected TAT

CER.IDC.25 System shall allow user to save and print the acknowledgement for enquiry and grievance purposes

CER.IDC.26 User shall be able to print and save the notification for easy retrieval of information for future reference

CER.IDC.27 System shall allow the user to rectify the error (in case of application declined) and re-submit the same application

CER.IDC.28 System shall allow only authorized users to access the scanned supporting documentation and verify with other departments if required



CER.IDC.29 System shall allow the user to re- submit the application only after validating the authenticity of the user through challenges and response

CER.IDC.30 System shall send an activation URL to the email id of the respective official responsible to accept the application

CER.IDC.31 System shall allow the concerned authority to enter query parameters for the database and then display the results for the query to the respective authority

CER.IDC.32 System shall log all changes to the document (Forwarding, approval, rejection) with date and time of the action.

CER.IDC.33 System shall save the digitally signed copy of the domicile certificate issued as a softcopy in a database

CER.IDC.34 System shall log the details of who accessed the online soft copy and took a printout of the same.

CER.IDC.35 System shall allow the authorized official to create or update the certificate details in Database.

CER.IDC.36 System shall send an automated escalation mail to the next level of authority in case the respective official does not attend the application URL within TAT

CER.IDC.37 System shall allow and accept the digital signature from respective officials for processing the application and issue of certificate for the users

CER.IDC.38 System shall allow the respective official to update the status of the application request as per proceedings along with the remarks

CER.IDC.39 Any change to the application record shall generate a change log with details like name of the user making the changes, timestamp of transaction, etc.

CER.IDC.40 System shall allow to intimate citizen for issuance of Domicile certificate or rejection of Domicile certificate (with reason/remark)

CER.IDC.41 System shall allow to upload the scanned/ PDF copy of certificate in the State portal where citizen can take the print of it

CER.IDC.42 System shall be PKI enabled to accept digital signatures certificate for digital signing of the documents.

CER.IDC.43 System shall consider the list of holidays for tracking the timelines of various

CER.IDC.44 System shall support multilingual interface (minimum Konkani , Marathi and English) as per Localization and Language Technology Standards for National e-Governance Plan defined in e-District guidelines

CER.IDC.45

Domicile Certificate module of DC Suite/ Taluka Suite/e-District application should be linked to general all service component appropriately as per department requirement – e.g. Information component, Form availability component etc.

3. Issuance of cast community certificate

Requirement ID

Description

CER.ICC.1 System shall allow applicant/ESO/CSC/CFC operator to select Collectorate Office from the Home page of the State Portal

CER.ICC.2 System shall allow applicant to select application for Cast community certificate on the Collectorate office page of the state portal

CER.ICC.3 System shall allow registration of applicant for future login and ease (registration not mandatory)

CER.ICC.4 System shall accept application of new applicants



CER.ICC.5

System shall be able to capture the applicants details through an electronic form such as: 1. Name 2. Contact Details 3. PIN 4. Age 5. Details as required in application form used 6. Certificate from Samaj concerned 7. Father‟s Caste Certificate issued by the prescribed Authority. 8. An affidavit in the prescribed form. 9. Applicant‟s Birth Certificate 10. Migration proof on or before19th feb 1968 with father‟s or/and grandfathers

birth certificate as required by department 11. Unique Identification (UID) 12. E-mail id (if any) 13. Mobile No. (if any)

CER.ICC.6 System shall require entries from the user for certain important information items entered twice. For example email id needs to be captured correctly if email is the preferred mode of communication

CER.ICC.7 System shall provide adequate aid to the user in the form of online tutorials, "How To", FAQs, etc. that can be used on their own to familiarize themselves with keying-in the registration data and the registration process

CER.ICC.8 System shall allow the applicant to preview the application form

CER.ICC.9 System shall apply spam control measures during registration to avoid spurious details being automatically submitted and ensure that data is not submitted by non-humans

CER.ICC.10 System Shall allow add/ delete/ editing before submission

CER.ICC.11 System shall perform data validation checks on the input. In case of data being duplicated, System shall display the existing service request id.

CER.ICC.12 System Shall allow save and print facility of the acknowledgement slip

CER.ICC.13 Validation for file type that shall be allowed to be uploaded, include only formats such as .pdf/.doc.tiff/.rtf. It Shall not allow .executable files.

CER.ICC.14 System shall allow to accept unique ID as proof of document which can be verified internally within departments through e-District interface

CER.ICC.15 System shall display the respective communication address and turnaround time to submit documents in case the applicant selects the option to submit physical documents

CER.ICC.16 System shall as a part of application establish challenge and responses mechanisms for session validation for future online sessions.

CER.ICC.17 System shall perform data validation checks on the completeness of the form in terms of mandatory fields, checking for file type and size of files uploaded, etc. In case of any validation failure, System shall display an appropriate error message.

CER.ICC.18 System shall time out the session if it is idle for more than fifteen minutes.

CER.ICC.19 The system should return to main menu after print out of the receipt has been taken

CER.ICC.20 System shall apply spam control measures during registration to avoid spurious details being automatically submitted and ensure that data is not submitted by



non-humans

CER.ICC.21 System shall allow the user to visit the secured payment gateway in case the user selects the option to make the payment through net banking, debit card or credit card

CER.ICC.22 System shall display the respective communication address/ drop box and turnaround time to make payment in case the applicant selects the option to make payment through bearer cheque.

CER.ICC.23


CER.ICC.24 System shall be able to provide unique 'Service Id Request' acknowledgement to the user along with expected TAT

CER.ICC.25 System shall allow user to save and print the acknowledgement for enquiry and grievance purposes

CER.ICC.26 User shall be able to print and save the notification for easy retrieval of information for future reference

CER.ICC.27 System shall allow the user to rectify the error (in case of application declined) and re-submit the same application

CER.ICC.28 System shall allow only authorized users to access the scanned supporting documentation and verify with other departments if required

CER.ICC.29 System shall allow the user to re- submit the application only after validating the authenticity of the user through challenges and response

CER.ICC.30 System shall send an activation URL to the email id of the respective official responsible to accept the application

CER.ICC.31 System shall allow the concerned authority to enter query parameters for the database and then display the results for the query to the respective authority

CER.ICC.32 System shall log all changes to the document (Forwarding, approval, rejection) with date and time of the action.

CER.ICC.33 System shall save the digitally signed copy of the cast community certificate issued as a softcopy in a database

CER.ICC.34 System shall log the details of who accessed the online soft copy and took a printout of the same.

CER.ICC.35 System shall allow the authorized official to create or update the certificate details in Database.

CER.ICC.36 System shall allow the authorized official to create or update the certificate details in Database for issuance of provisional cast community certificate. (if required)

CER.ICC.37 System shall send an automated escalation mail to the next level of authority in case the respective official does not attend the application URL within TAT

CER.ICC.38 System shall allow and accept the digital signature from respective officials for processing the application and issue of certificate for the users

CER.ICC.39 System shall allow the respective official to update the status of the application request as per proceedings along with the remarks

CER.ICC.40 Any change to the application record shall generate a change log with details like name of the user making the changes, timestamp of transaction, etc.



CER.ICC.41 System shall allow to intimate citizen for issuance of Cast community certificate or rejection of Cast community certificate (with reason/remark)

CER.ICC.42 System shall allow to upload the scanned/ PDF copy of certificate in the State portal where citizen can take the print of it

CER.ICC.43 System shall be PKI enabled to accept digital signatures certificate for digital signing of the documents.

CER.ICC.44 System shall consider the list of holidays for tracking the timelines of various

CER.ICC.45

Cast community Certificate module of DC Suite/ Taluka Suite/e-District application should be linked to general all service component appropriately as per department requirement – e.g. Information component, Form availability component etc.

CER.ICC.46 System shall support multilingual interface (minimum Konkani , Marathi and English) as per Localization and Language Technology Standards for National e-Governance Plan defined in e-District guidelines

CER.ICC.47 System shall allow applicant/ESO/CSC/CFC operator to select Collectorate Office from the Home page of the State Portal

4. Issuance of residence certificate

Requirement ID

Description

CER.IRC.1 System shall allow applicant/ESO/CSC/CFC operator to select Collectorate Office from the Home page of the State Portal

CER.IRC.2 System shall allow applicant to select application for Residence certificate on the Collectorate office page of the state portal

CER.IRC.3 System shall allow registration of applicant for future login and ease (registration not mandatory)

CER.IRC.4 System shall accept application of new applicants

CER.IRC.5

System shall be able to capture the applicants details through an electronic form such as: 1. Attested Photocopy of Birth Certificate 2. Ration Card 3. Any other proof of residence. 4. 2 passport size photographs 5. Affidavit for civil registration (marriage) 6. Other details as per used format and required by department

CER.IRC.6 System shall require entries from the user for certain important information items entered twice. For example email id needs to be captured correctly if email is the preferred mode of communication

CER.IRC.7 System shall provide adequate aid to the user in the form of online tutorials, "How To", FAQs, etc. that can be used on their own to familiarize themselves with keying-in the registration data and the registration process

CER.IRC.8 System shall allow the applicant to preview the application form

CER.IRC.9 System shall apply spam control measures during registration to avoid spurious details being automatically submitted and ensure that data is not submitted by non-humans

CER.IRC.10 System Shall allow add/ delete/ editing before submission



CER.IRC.11 System shall perform data validation checks on the input. In case of data being duplicated, System shall display the existing service request id.

CER.IRC.12 System Shall allow save and print facility of the acknowledgement slip

CER.IRC.13 Validation for file type that shall be allowed to be uploaded, include only formats such as .pdf/.doc.tiff/.rtf. It Shall not allow .executable files.

CER.IRC.14 System shall allow to accept unique ID as proof of document which can be verified internally within departments through e-District interface

CER.IRC.15 System shall display the respective communication address and turnaround time to submit documents in case the applicant selects the option to submit physical documents

CER.IRC.16 System shall as a part of application establish challenge and responses mechanisms for session validation for future online sessions.

CER.IRC.17 System shall perform data validation checks on the completeness of the form in terms of mandatory fields, checking for file type and size of files uploaded, etc. In case of any validation failure, System shall display an appropriate error message.

CER.IRC.18 System shall time out the session if it is idle for more than fifteen minutes.

CER.IRC.19 The system should return to main menu after print out of the receipt has been taken

CER.IRC.20 System shall apply spam control measures during registration to avoid spurious details being automatically submitted and ensure that data is not submitted by non-humans

CER.IRC.21 System shall allow the user to visit the secured payment gateway in case the user selects the option to make the payment through net banking, debit card or credit card

CER.IRC.22 System shall display the respective communication address/ drop box and turnaround time to make payment in case the applicant selects the option to make payment through bearer cheque.

CER.IRC.23


CER.IRC.24 System shall be able to provide unique 'Service Id Request' acknowledgement to the user along with expected TAT

CER.IRC.25 System shall allow user to save and print the acknowledgement for enquiry and grievance purposes

CER.IRC.26 User shall be able to print and save the notification for easy retrieval of information for future reference

CER.IRC.27 System shall allow the user to rectify the error (in case of application declined) and re-submit the same application

CER.IRC.28 System shall allow only authorized users to access the scanned supporting documentation and verify with other departments if required

CER.IRC.29 System shall allow the user to re- submit the application only after validating the authenticity of the user through challenges and response

CER.IRC.30 System shall send an activation URL to the email id of the respective official responsible to accept the application

CER.IRC.31 System shall allow the concerned authority to enter query parameters for the



database and then display the results for the query to the respective authority

CER.IRC.32 System shall log all changes to the document (Forwarding, approval, rejection) with date and time of the action.

CER.IRC.33 System shall save the digitally signed copy of the residence certificate issued as a softcopy in a database

CER.IRC.34 System shall log the details of who accessed the online soft copy and took a printout of the same.

CER.IRC.35 System shall allow the authorized official to create or update the certificate details in Database.

CER.IRC.36 System shall allow the authorized official to create or update the certificate details in Database for issuance of provisional residence certificate. (if required)

CER.IRC.37 System shall send an automated escalation mail to the next level of authority in case the respective official does not attend the application URL within TAT

CER.IRC.38 System shall allow and accept the digital signature from respective officials for processing the application and issue of certificate for the users

CER.IRC.39 System shall allow the respective official to update the status of the application request as per proceedings along with the remarks

CER.IRC.40 Any change to the application record shall generate a change log with details like name of the user making the changes, timestamp of transaction, etc.

CER.IRC.41 System shall allow to intimate citizen for issuance of Residence certificate or rejection of Residence certificate (with reason/remark)

CER.IRC.42 System shall allow to upload the scanned/ PDF copy of certificate in the State portal where citizen can take the print of it

CER.IRC.43 System shall be PKI enabled to accept digital signatures certificate for digital signing of the documents.

CER.IRC.44 System shall consider the list of holidays for tracking the timelines of various

CER.IRC.45 System shall support multilingual interface (minimum Konkani , Marathi and English) as per Localization and Language Technology Standards for National e-Governance Plan defined in e-District guidelines

CER.IRC.46

Residence Certificate module of DC Suite/ Taluka Suite/e-District application should be linked to general all service component appropriately as per department requirement – e.g. Information component, Form availability component etc.

5. Issuance of divergence certificate

Requirement ID

Description

CER.IDC.1 System shall allow applicant/ESO/CSC/CFC operator to select Collectorate Office from the Home page of the State Portal

CER.IDC.2 System shall allow applicant to select application for Divergence certificate on the Collectorate office page of the state portal

CER.IDC.3 System shall allow registration of applicant for future login and ease (registration not mandatory)

CER.IDC.4 System shall accept application of new applicants



CER.IDC.5

System shall be able to capture the applicants details through an electronic form such as:

1. Affidavit in prescribed form 2. Birth Certificate 3. Documentary evidence where Divergence have been occurred

CER.IDC.6 System shall require entries from the user for certain important information items entered twice. For example email id needs to be captured correctly if email is the preferred mode of communication

CER.IDC.7 System shall provide adequate aid to the user in the form of online tutorials, "How To", FAQs, etc. that can be used on their own to familiarize themselves with keying-in the registration data and the registration process

CER.IDC.8 System shall allow the applicant to preview the application form


CER.IDC.10 System Shall allow add/ delete/ editing before submission

CER.IDC.11 System shall perform data validation checks on the input. In case of data being duplicated, System shall display the existing service request id.

CER.IDC.12 System Shall allow save and print facility of the acknowledgement slip

CER.IDC.13 Validation for file type that shall be allowed to be uploaded, include only formats such as .pdf/.doc.tiff/.rtf. It Shall not allow .executable files.

CER.IDC.14 System shall allow to accept unique ID as proof of document which can be verified internally within departments through e-District interface

CER.IDC.15 System shall display the respective communication address and turnaround time to submit documents in case the applicant selects the option to submit physical documents

CER.IDC.16 System shall as a part of application establish challenge and responses mechanisms for session validation for future online sessions.

CER.IDC.17 System shall perform data validation checks on the completeness of the form in terms of mandatory fields, checking for file type and size of files uploaded, etc. In case of any validation failure, System shall display an appropriate error message.

CER.IDC.18 System shall time out the session if it is idle for more than fifteen minutes.

CER.IDC.19 The system should return to main menu after print out of the receipt has been taken


CER.IDC.21 System shall allow the user to visit the secured payment gateway in case the user selects the option to make the payment through net banking, debit card or credit card

CER.IDC.22 System shall display the respective communication address/ drop box and turnaround time to make payment in case the applicant selects the option to make payment through bearer cheque.

CER.IDC.23

System shall allow user to track the status of the application request along with remarks to the user such as: -Application accepted -Application declined



-Pending confirmation

CER.IDC.24 System shall be able to provide unique 'Service Id Request' acknowledgement to the user along with expected TAT

CER.IDC.25 System shall allow user to save and print the acknowledgement for enquiry and grievance purposes

CER.IDC.26 User shall be able to print and save the notification for easy retrieval of information for future reference

CER.IDC.27 System shall allow the user to rectify the error (in case of application declined) and re-submit the same application

CER.IDC.28 System shall allow only authorized users to access the scanned supporting documentation and verify with other departments if required

CER.IDC.29 System shall allow the user to re- submit the application only after validating the authenticity of the user through challenges and response

CER.IDC.30 System shall send an activation URL to the email id of the respective official responsible to accept the application

CER.IDC.31 System shall allow the concerned authority to enter query parameters for the database and then display the results for the query to the respective authority

CER.IDC.32 System shall log all changes to the document (Forwarding, approval, rejection) with date and time of the action.

CER.IDC.33 System shall save the digitally signed copy of the divergence certificate issued as a softcopy in a database

CER.IDC.34 System shall log the details of who accessed the online soft copy and took a printout of the same.

CER.IDC.35 System shall allow the authorized official to create or update the certificate details in Database.

CER.IDC.36 System shall allow the authorized official to create or update the certificate details in Database for issuance of provisional divergence certificate. (if required)

CER.IDC.37 System shall send an automated escalation mail to the next level of authority in case the respective official does not attend the application URL within TAT

CER.IDC.38 System shall allow and accept the digital signature from respective officials for processing the application and issue of certificate for the users

CER.IDC.39 System shall allow the respective official to update the status of the application request as per proceedings along with the remarks

CER.IDC.40 Any change to the application record shall generate a change log with details like name of the user making the changes, timestamp of transaction, etc.

CER.IDC.41 System shall allow to intimate citizen for issuance of Divergence certificate or rejection of Divergence certificate (with reason/remark)

CER.IDC.42 System shall allow to upload the scanned/ PDF copy of certificate in the State portal where citizen can take the print of it

CER.IDC.43 System shall be PKI enabled to accept digital signatures certificate for digital signing of the documents.

CER.IDC.44 System shall consider the list of holidays for tracking the timelines of various

CER.IDC.45 System shall support multilingual interface (minimum Konkani , Marathi and English) as per Localization and Language Technology Standards for National e-Governance Plan defined in e-District guidelines

CER.IDC.46 Divergence Certificate module of DC Suite/ Taluka Suite/e-District application should be linked to general all service component appropriately as per department



requirement – e.g. Information component, Form availability component etc.

6. Issuance of matriz certificate

Requirement ID

Description

CER.IMC.1 System shall allow applicant/ESO/CSC/CFC operator to select Collectorate Office from the Home page of the State Portal

CER.IMC.2 System shall allow applicant to select application for Matriz certificate on the Collectorate office page of the state portal

CER.IMC.3 System shall allow registration of applicant for future login and ease (registration not mandatory)

CER.IMC.4 System shall accept application of new applicants

CER.IMC.5

System shall be able to capture the applicants details through an electronic form such as: 1. Application to be addressed to the Mamlatdar and Head of Taluka Revenue

Office. 2. Details of land (as required by department)

3. Other supporting documents required by department

CER.IMC.6 System shall require entries from the user for certain important information items entered twice. For example email id needs to be captured correctly if email is the preferred mode of communication

CER.IMC.7 System shall provide adequate aid to the user in the form of online tutorials, "How To", FAQs, etc. that can be used on their own to familiarize themselves with keying-in the registration data and the registration process

CER.IMC.8 System shall allow the applicant to preview the application form

CER.IMC.9 System shall apply spam control measures during registration to avoid spurious details being automatically submitted and ensure that data is not submitted by non-humans

CER.IMC.10 System Shall allow add/ delete/ editing before submission

CER.IMC.11 System shall perform data validation checks on the input. In case of data being duplicated, System shall display the existing service request id.

CER.IMC.12 System Shall allow save and print facility of the acknowledgement slip

CER.IMC.13 Validation for file type that shall be allowed to be uploaded, include only formats such as .pdf/.doc.tiff/.rtf. It Shall not allow .executable files.

CER.IMC.14 System shall allow to accept unique ID as proof of document which can be verified internally within departments through e-District interface

CER.IMC.15 System shall display the respective communication address and turnaround time to submit documents in case the applicant selects the option to submit physical documents

CER.IMC.16 System shall as a part of application establish challenge and responses mechanisms for session validation for future online sessions.

CER.IMC.17 System shall perform data validation checks on the completeness of the form in terms of mandatory fields, checking for file type and size of files uploaded, etc. In case of any validation failure, System shall display an appropriate error message.



CER.IMC.18 System shall time out the session if it is idle for more than fifteen minutes.

CER.IMC.19 The system should return to main menu after print out of the receipt has been taken

CER.IMC.20 System shall apply spam control measures during registration to avoid spurious details being automatically submitted and ensure that data is not submitted by non-humans

CER.IMC.21 System shall allow the user to visit the secured payment gateway in case the user selects the option to make the payment through net banking, debit card or credit card

CER.IMC.22 System shall display the respective communication address/ drop box and turnaround time to make payment in case the applicant selects the option to make payment through bearer cheque.

CER.IMC.23


CER.IMC.24 System shall be able to provide unique 'Service Id Request' acknowledgement to the user along with expected TAT

CER.IMC.25 System shall allow user to save and print the acknowledgement for enquiry and grievance purposes

CER.IMC.26 User shall be able to print and save the notification for easy retrieval of information for future reference

CER.IMC.27 System shall allow the user to rectify the error (in case of application declined) and re-submit the same application

CER.IMC.28 System shall allow only authorized users to access the scanned supporting documentation and verify with other departments if required

CER.IMC.29 System shall allow the user to re- submit the application only after validating the authenticity of the user through challenges and response

CER.IMC.30 System shall send an activation URL to the email id of the respective official responsible to accept the application

CER.IMC.31 System shall allow the concerned authority to enter query parameters for the database and then display the results for the query to the respective authority

CER.IMC.32 System shall log all changes to the document (Forwarding, approval, rejection) with date and time of the action.

CER.IMC.33 System shall save the digitally signed copy of the matriz certificate issued as a softcopy in a database

CER.IMC.34 System shall log the details of who accessed the online soft copy and took a printout of the same.

CER.IMC.35 System shall allow the authorized official to create or update the certificate details in Database.

CER.IMC.36 System shall allow the authorized official to create or update the certificate details in Database for issuance of provisional matriz certificate. (if required)

CER.IMC.37 System shall send an automated escalation mail to the next level of authority in case the respective official does not attend the application URL within TAT

CER.IMC.38 System shall allow and accept the digital signature from respective officials for processing the application and issue of matriz certificate for the users



CER.IMC.39 System shall allow the respective official to update the status of the application request as per proceedings along with the remarks

CER.IMC.40 Any change to the application record shall generate a change log with details like name of the user making the changes, timestamp of transaction, etc.

CER.IMC.41 System shall allow to intimate citizen for issuance of Matriz certificate or rejection of Matriz certificate (with reason/remark)

CER.IMC.42 System shall allow to upload the scanned/ PDF copy of certificate in the State portal where citizen can take the print of it

CER.IMC.43 System shall be PKI enabled to accept digital signatures certificate for digital signing of the documents.

CER.IMC.44 System shall consider the list of holidays for tracking the timelines of various

CER.IMC.45 System shall support multilingual interface (minimum Konkani , Marathi and English) as per Localization and Language Technology Standards for National e-Governance Plan defined in e-District guidelines

CER.IMC.46

Matriz Certificate module of DC Suite/ Taluka Suite/e-District application should be linked to general all service component appropriately as per department requirement – e.g. Information component, Form availability component etc.

7. Revenue Court- case listing/adjournment/stay/final/status

Requirement ID

Description

RCC.LASFS.1

System shall allow Applicant/ESO/CSC/CFC operator to select revenue case related page (Collectorate office) from the Home page of the state/department portal or through multiple routes e.g. Service links, Information links, District links, etc.

RCC.LASFS.2 System shall allow applicant to select Revenue Court Application from the above listed sources

RCC.LASFS.3 System shall provide Information on Revenue Cases as per the Information Dissemination component defined previously

RCC.LASFS.4 System shall make Application Form for filing and application of a case available online as per the Form Availability component defined previously.

RCC.LASFS.5 System shall allow the Collector, Dy. Collector, Mamlatdar, SDO, BDM , ,Talathi ,Village Officer and the section clerks to Log into the Application and access the Revenue Case section.

RCC.LASFS.6 System shall enable Collector, Dy. Collector, Mamlatdar, SDO, BDM , ,Talathi ,Village Officer and the section clerks to enter the case details as per the Form details given in the Service Request Form section.

RCC.LASFS.7 System shall allow to accept Case number with year and party details ( non-mandatory) which can be verified internally within departments through e-District interface

RCC.LASFS.8 System shall be able to generate & display daily case lists & status

RCC.LASFS.9 System shall display next date of case listing or the status of case (if not listed)

RCC.LASFS.10 System shall allow uploading the scanned/ PDF copy of Application in



the State portal where citizen can take the print of it.

RCC.LASFS.11 Validations for file type that shall be allowed to be uploaded include only formats such as above. It shall not allow .executable files.

RCC.LASFS.12 System shall enable a printer-friendly version automatically for all pages so that applicant/citizen or the Dealing/Section Clerks of the revenue case can take a Printout of the specified date‟s Case List.

RCC.LASFS.13 System shall have provision for calendar system, which displays the dates and time of schedule revenue cases on a standard monthly calendar.

RCC.LASFS.14 System shall be able to generate a reminder for a case before seven days from the hearing date. It should also be able to send the reminder to the concerned officials and the respondent.

RCC.LASFS.15 System shall be able to generate notification to the concerned official whenever any action from that person is asked for.

RCC.LASFS.12

For court Case Status System: a. Select Court from Multilayered Menu (District Name -> List of

Revenue Cases) b. Provision for accepting Case number from user c. Retrieval of case status with summary d. Option for searching case

RCC.LASFS.11

For copy of Final Order system shall provide the following information: a. Select of Court from Multilayered Menu (District Name -> List of

Revenue Courts) b. Provision for accepting Case number from user c. Retrieval and Downloading of Copy of final Order of Court Case d. Option for uploading scanned/Digitally signed soft copy of Final

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

System shall support multilingual interface ( Konkani, Marathi and English) as per Localization and Language Technology Standards for National e-Governance Plan defined in e-District guidelines.

RCC.LASFS.12 System shall facilitate the ESO/CSC/CFC center operator to enter the necessary details mentioned in the Record view or as prescribed by department for the logged in officer table.

RCC.LASFS.13

System shall also be able to generate MIS related to case summary w.r.t. the cases handled by a particular post of the government official. E.g. System shall give the option of viewing all the cases handled by a Mamlatdar/BDO/SDO and their respective status should also be reflected in the MIS report.

RCC.LASFS.14 System shall allow the section clerks and the Ordering authority to upload the pdf format of the final order.

RCC.LASFS.15 System shall allow proper interface with Taluka Suite, DC Suite and eDA so that these applications could exchange necessary information among themselves

RCC.LASFS.16 System shall be able to generate reminders for the appellate authority every day after seven days of application regarding issuance of first hearing Notice within fifteen days of application.

RCC.LASFS.17 System shall allow the authorized officials to put remarks for all the actions taken by them.



RCC.LASFS.18 System shall allow to upload the scanned/ PDF copy of judgments & actions taken in the requested process.

RCC.LASFS.19 System shall be PKI enabled to accept digital signatures for digital signing of the documents of revenue court.

RCC.LASFS.20 System shall consider the list of holidays for tracking the timelines of various activities.

RCC.LASFS.21

Revenue court module of DC Suite/ Taluka Suite/e-District application should be linked to general all service component appropriately as per department requirement – e.g. Information component, Form availability component etc.

RCC.LASFS.21 System shall support multilingual interface (minimum Konkani , Marathi and English) as per Localization and Language Technology Standards for National e-Governance Plan defined in e-District guidelines

It is desired to understand if any party(s) can be registered against any case or not. Same facility is not available in regular courts. Hence, Leaving the registration module for revenue courts

It is desired to understand how system will display the documents required by court is to be submitted by litigants

8. Arms License - Application for New/ Renewal of License

Requirement ID

Description

ARM.NRL.1 System shall allow applicant/ESO/CSC/CFC operator to select Collectorate Office from the Home page of the State Portal

ARM.NRL.2 System shall allow applicant to select application for Arms license on the Collectorate office page of the state portal

ARM.NRL.3 System shall allow registration of applicant for future login and ease (registration not mandatory)

ARM.NRL.4 System shall accept application of new applicants

ARM.NRL.5


1. Passport size photograph 2. Copy of Ration Card 3. Unique Identification No. (Aadhaar) 4. Crop Cultivation Document, if any, i.e. Form I and XIV 5. Information to be furnished as per current form. 6. Supporting documents/details as per department requirement.

ARM.NRL.6 System shall require entries from the user for certain important information items entered twice. For example email id needs to be captured correctly if email is the preferred mode of communication

ARM.NRL.7

System shall provide adequate aid to the user in the form of online tutorials, "How To", FAQs, etc. that can be used on their own to familiarize themselves with keying-in the registration data and the registration process

ARM.NRL.8 System shall allow the applicant to preview the application form

ARM.NRL.9 System shall apply spam control measures during registration to avoid spurious details being automatically submitted and ensure that data is not



submitted by non-humans

ARM.NRL.10 System Shall allow add/ delete/ editing before submission

ARM.NRL.11 System shall perform data validation checks on the input. In case of data being duplicated, System shall display the existing service request id.

ARM.NRL.12 System Shall allow save and print facility of the acknowledgement slip

ARM.NRL.13 Validation for file type that shall be allowed to be uploaded, include only formats such as .pdf/.doc.tiff/.rtf. It Shall not allow .executable files.

ARM.NRL.14 System shall allow to accept unique ID as proof of document which can be verified internally within departments through e-District interface

ARM.NRL.15 System shall display the respective communication address and turnaround time to submit documents in case the applicant selects the option to submit physical documents

ARM.NRL.16 System shall as a part of application establish challenge and responses mechanisms for session validation for future online sessions.

ARM.NRL.17

System shall perform data validation checks on the completeness of the form in terms of mandatory fields, checking for file type and size of files uploaded, etc. In case of any validation failure, System shall display an appropriate error message.

ARM.NRL.18 System shall time out the session if it is idle for more than fifteen minutes.

ARM.NRL.19 The system should return to main menu after print out of the receipt has been taken

ARM.NRL.20 System shall apply spam control measures during registration to avoid spurious details being automatically submitted and ensure that data is not submitted by non-humans

ARM.NRL.21 System shall allow the user to visit the secured payment gateway in case the user selects the option to make the payment through net banking, debit card or credit card

ARM.NRL.22 System shall display the respective communication address/ drop box and turnaround time to make payment in case the applicant selects the option to make payment through bearer cheque.

ARM.NRL.23


ARM.NRL.24 System shall be able to provide unique 'Service Id Request' acknowledgement to the user along with expected TAT

ARM.NRL.25 System shall allow user to save and print the acknowledgement for enquiry and grievance purposes

ARM.NRL.26 User shall be able to print and save the notification for easy retrieval of information for future reference

ARM.NRL.27 System shall allow the user to rectify the error (in case of application declined) and re-submit the same application

ARM.NRL.28 System shall allow only authorized users to access the scanned supporting documentation and verify with other departments if required



ARM.NRL.29 System shall allow the user to re- submit the application only after validating the authenticity of the user through challenges and response

ARM.NRL.30 System shall send an activation URL to the email id of the respective official responsible to accept the application

ARM.NRL.31 System shall allow the concerned authority to enter query parameters for the database and then display the results for the query to the respective authority

ARM.NRL.32 System shall log all changes to the document (Forwarding, approval, rejection) with date and time of the action.

ARM.NRL.33 System shall save the digitally signed copy of the arms license issued as a softcopy in a database

ARM.NRL.34 System shall log the details of who accessed the online soft copy and took a printout of the same.

ARM.NRL.35 System shall allow the authorized official to create or update the arms license details in Database.

ARM.NRL.36 System shall allow authorized official to crosscheck/verify report of enquiry done by the Superintendent of Police Office (if required)

ARM.NRL.37 System shall allow authorized official to crosscheck/verify report of medical done by the Authorized Govt. Hospital‟s (if required)

ARM.NRL.38 System shall allow the authorized official to create or update the arm license details in database for issuance/renewal of arms license

ARM.NRL.39 System shall send an automated escalation mail to the next level of authority in case the respective official does not attend the application URL within TAT

ARM.NRL.40 System shall allow and accept the digital signature from respective officials for processing the application and issue of arms license for the users

ARM.NRL.41 System shall allow the respective official to update the status of the application request as per proceedings along with the remarks

ARM.NRL.42 For Any change to the application record system shall generate a change log with details like name of the user making the changes, timestamp of transaction, etc.

ARM.NRL.43 System shall allow to intimate citizen for issuance of Arms license or rejection of Arms license (with reason/remark)

ARM.NRL.44 System shall allow to upload the scanned/ PDF copy of arms license in the State portal where citizen can take the print of it

ARM.NRL.45 System shall be PKI enabled to accept digital signatures for arms license for digital signing of the documents.

ARM.NRL.46 System shall consider the list of holidays for tracking the timelines of various activities.

ARM.NRL.47 System shall support multilingual interface (minimum Konkani , Marathi and English) as per Localization and Language Technology Standards for National e-Governance Plan defined in e-District guidelines

ARM.NRL.48 Arms license module of DC Suite/ Taluka Suite/e-District application should be linked to general all service component appropriately as per department requirement – e.g. Information component, Form availability component etc.



9. Issuance of Sound Permission

Requirement ID

Description

PRM.SND.1 System shall allow applicant/ESO/CSC/CFC operator to select Collectorate Office from the Home page of the State Portal

PRM. SND.2 System shall allow applicant to select application for sound permission on the collectorate office page of the state/department portal

PRM.SND.3 System shall allow registration of applicant for future login and ease (registration not mandatory)

PRM.SND.4 System shall accept application of new applicants

PRM.SND.5


1. Place 2. Timing 3. Period 4. Permission upto 10:00 PM or beyond 10:00 PM 5. Other details as required by department

PRM.SND.6 System shall require entries from the user for certain important information items entered twice. For example email id needs to be captured correctly if email is the preferred mode of communication

PRM.SND.7 System shall provide adequate aid to the user in the form of online tutorials, "How To", FAQs, etc. that can be used on their own to familiarize themselves with keying-in the registration data and the registration process

PRM.SND.8 System shall allow the applicant to preview the application form

PRM.SND.9 System shall apply spam control measures during registration to avoid spurious details being automatically submitted and ensure that data is not submitted by non-humans

PRM.SND.10 System Shall allow add/ delete/ editing before submission

PRM.SND.11 System shall perform data validation checks on the input. In case of data being duplicated, System shall display the existing service request id.

PRM.SND.12 System Shall allow save and print facility of the acknowledgement slip

PRM.SND.13 Validation for file type that shall be allowed to be uploaded, include only formats such as .pdf/.doc.tiff/.rtf. It Shall not allow .executable files.

PRM.SND.14 System shall allow to accept unique ID as proof of document which can be verified internally within departments through e-District interface

PRM.SND.15 System shall display the respective communication address and turnaround time to submit documents in case the applicant selects the option to submit physical documents

PRM.SND.16 System shall as a part of application establish challenge and responses mechanisms for session validation for future online sessions.

PRM.SND.17


PRM.SND.18 System shall time out the session if it is idle for more than fifteen minutes.



PRM.SND.19 The system should return to main menu after print out of the receipt has been taken

PRM.SND.20 System shall apply spam control measures during registration to avoid spurious details being automatically submitted and ensure that data is not submitted by non-humans

PRM.SND.21 System shall allow the user to visit the secured payment gateway in case the user selects the option to make the payment through net banking, debit card or credit card (if required)

PRM.SND.22 System shall display the respective communication address/ drop box and turnaround time to make payment in case the applicant selects the option to make payment through bearer cheque. (if required)

PRM.SND.23


PRM.SND.24 System shall be able to provide unique 'Service Id Request' acknowledgement to the user along with expected TAT

PRM.SND.25 System shall allow user to save and print the acknowledgement for enquiry and grievance purposes

PRM.SND.26 User shall be able to print and save the notification for easy retrieval of information for future reference

PRM.SND.27 System shall allow the user to rectify the error (in case of application declined) and re-submit the same application

PRM.SND.28 System shall allow only authorized users to access the scanned supporting documentation and verify with other departments ( if required )

PRM.SND.29 System shall allow the user to re- submit the application only after validating the authenticity of the user through challenges and response

PRM.SND.30 System shall send an activation URL to the email id of the respective official responsible to accept the application

PRM.SND.31 System shall allow the concerned authority to enter query parameters for the database and then display the results for the query to the respective authority

PRM.SND.32 System shall log all changes to the document (Forwarding, approval, rejection) with date and time of the action.

PRM.SND.33 System shall save the digitally signed copy of the sound permission issued as a softcopy in a database

PRM.SND.34 System shall log the details of who accessed the online soft copy and took a printout of the same.

PRM.SND.35 System shall allow the authorized official to create or update the sound permission details in database.

PRM.SND.36 System shall allow authorized official to crosscheck/verify report of enquiry done by the Superintendent of Police Office (if required)

PRM.SND.37 System shall allow the authorized official to create or update the sound permission details in database for approval / rejection of sound permission

PRM.SND.38 System shall send an automated escalation mail to the next level of authority in case the respective official does not attend the application URL within TAT



PRM.SND.39 System shall allow and accept the digital signature from respective officials for processing the application and issue of sound permission for the users

PRM.SND.40 System shall allow the respective official to update the status of the application request as per proceedings along with the remarks

PRM.SND.41 For Any change to the application record system shall generate a change log with details like name of the user making the changes, timestamp of transaction, etc.

PRM.SND.42 System shall allow to intimate citizen for issuance of Sound permission or rejection of Sound permission(with reason/remark)

PRM.SND.43 System shall allow to upload the scanned/ PDF copy of sound permission in the State portal where citizen can take the print of it

PRM.SND.44 System shall be PKI enabled to accept digital signatures for sound permission for digital signing of the documents.

PRM.SND.45 System shall consider the list of holidays for tracking the timelines of various activities.

PRM.SND.46 System shall support multilingual interface (minimum Konkani , Marathi and English) as per Localization and Language Technology Standards for National e-Governance Plan defined in e-District guidelines

PRM.SND.47 Sound permission module of DC Suite/ Taluka Suite/e-District application should be linked to general all service component appropriately as per department requirement – e.g. Information component, Form availability component etc.



10. Application for relief for victims of natural calamity

Requirement ID

Description

RFV.NC1 System shall allow applicant/ESO/CSC/CFC operator to select Collectorate Office from the Home page of the State Portal

RFV.NC.2 System shall allow applicant to select application for relief for victims of natural calamity on the collectorate office page of the state/department portal

RFV.NC.3 System shall allow registration of applicant for future login and ease (registration not mandatory)

RFV.NC.4 System shall accept application of new applicants

RFV.NC.5


1. Name 2. Place/Address 3. Details ad prescribed in form available (as per department

requirement) 4. Unique Identification No. e.g. Aadhaar

RFV.NC.6

System shall require entries from the user for certain important information items entered twice. For example email id/mobile no. needs to be captured correctly if email / mobile no. is the preferred mode of communication

RFV.NC.7 System shall provide adequate aid to the user in the form of online tutorials, "How To", FAQs, etc. that can be used on their own to familiarize themselves with keying-in the registration data and the registration process

RFV.NC.8 System shall allow the applicant to preview the application form

RFV.NC.9 System shall apply spam control measures during registration to avoid spurious details being automatically submitted and ensure that data is not submitted by non-humans

RFV.NC.10 System Shall allow add/ delete/ editing before submission

RFV.NC.11 System shall perform data validation checks on the input. In case of data being duplicated, System shall display the existing service request id.

RFV.NC.12 System Shall allow save and print facility of the acknowledgement slip

RFV.NC.13 Validation for file type that shall be allowed to be uploaded, include only formats such as .pdf/.doc.tiff/.rtf. It Shall not allow .executable files.

RFV.NC.14 System shall allow to accept unique ID as proof of document which can be verified internally within departments through e-District interface

RFV.NC.15 System shall display the respective communication address and turnaround time to submit documents in case the applicant selects the option to submit physical documents

RFV.NC.16 System shall as a part of application establish challenge and responses mechanisms for session validation for future online sessions.

RFV.NC.17




RFV.NC.18 System shall time out the session if it is idle for more than fifteen minutes.

RFV.NC.19 The system should return to main menu after print out of the receipt has been taken

RFV.NC.20 System shall apply spam control measures during registration to avoid spurious details being automatically submitted and ensure that data is not submitted by non-humans

RFV.NC.21 System shall display the respective communication address/ drop box and turnaround time to make payment in case the applicant selects the option to make payment through bearer cheque. (if required)

RFV.NC.22


RFV.NC.23 System shall be able to provide unique 'Service Id Request' acknowledgement to the user along with expected TAT

RFV.NC.24 System shall allow user to save and print the acknowledgement for enquiry and grievance purposes

RFV.NC.25 User shall be able to print and save the notification for easy retrieval of information for future reference

RFV.NC.26 System shall allow the user to rectify the error (in case of application declined) and re-submit the same application

RFV.NC.27 System shall allow only authorized users to access the scanned supporting documentation and verify with other departments ( if required )

RFV.NC.28 System shall allow the user to re- submit the application only after validating the authenticity of the user through challenges and response

RFV.NC.29 System shall send an activation URL to the email id of the respective official responsible to accept the application

RFV.NC.30 System shall allow the concerned authority to enter query parameters for the database and then display the results for the query to the respective authority

RFV.NC.31 System shall log all changes to the document (Forwarding, approval, rejection) with date and time of the action.

RFV.NC.32 System shall save the digitally signed copy of the natural calamity issued as a softcopy in a database

RFV.NC.33 System shall log the details of who accessed the online soft copy and took a printout of the same.

RFV.NC.34 System shall allow the authorized official to create or update the natural calamity details in database. e.g. verification/inspecting details etc.

RFV.NC.35 System shall allow authorized official to crosscheck/verify report of enquiry done by the authorized verifying/inspecting officer e.g. talathi (if required)

RFV.NC.36 System shall allow the authorized official to create or update the natural calamity details in database for approval / rejection of natural calamity

RFV.NC.37 System shall send an automated escalation mail to the next level of authority in case the respective official does not attend the application URL within TAT



RFV.NC.38 System shall allow and accept the digital signature from respective officials for processing the application and issue of natural calamity for the users

RFV.NC.39 System shall allow the respective official to update the status of the application request as per proceedings along with the remarks

RFV.NC.40 For Any change to the application record system shall generate a change log with details like name of the user making the changes, timestamp of transaction, etc.

RFV.NC.41 System shall allow to intimate citizen for issuance of support for relief from natural calamity or rejection of relief benefits for natural calamity(with reason/remark)

RFV.NC.42

System shall allow the authorized user to credit/deposit relief amount (if any ) through the secured payment gateway in account of victim/ applicant in case department selects the option to make the payment through net banking/on-line transfer (if required)

RFV.NC.43 System shall allow to upload the details of dispersed amount or report of support provided for the victims of natural calamity on the state portal where citizen can take the print of it

RFV.NC.44

System shall allow senior most authorized official to check & verify the status report for support provided to victims of natural calamity and verify the same with facts & figures with the department or other concerned offices (if any)

RFV.NC.45 System shall be PKI enabled to accept digital signatures for natural calamity for digital signing of the documents.

RFV.NC.46 System shall consider the list of holidays for tracking the timelines of various activities.

RFV.NC.47 System shall support multilingual interface (minimum Konkani , Marathi and English) as per Localization and Language Technology Standards for National e-Governance Plan defined in e-District guidelines

RFV.NC.48

Relief for victims of natural calamity module of DC Suite/ Taluka Suite/e-District application should be linked to general all service component appropriately as per department requirement – e.g. Information component, Form availability component etc.



II. Department of Settlement & Land Records


Certificate

11. Issuance of Form I & XIV (Record of Right)

Requirement ID

Description

CER.ROR.1 System shall allow applicant/ESO/CSC/CFC operator to select Department of Settlement & Land records from the home page of the State/department Portal

CER.ROR.2 System shall allow service seeker to select Issuance of form I & XIV form the department page of the State/e-District portal

CER.ROR.3 System shall allow registration of applicant for future login and ease (registration not mandatory)

CER.ROR.4 System shall allow applicant to fill/edit e-Form/Application online and accept the same

CER.ROR.5

System shall be able to capture the applicants details through an electronic form such as: 1. Name 2. Contact Details 3. Taluka Name 4. Village Name 5. Survey Number 6. Sub Divisional. 7. Unique Identification (UID) 8. E-mail id (if any) 9. Mobile No. (if any)

CER.ROR.6

System shall require entries from the user for certain important information items entered twice. For example email id needs to be captured correctly if email is the preferred mode of communication

CER.ROR.7

System shall provide adequate aid to the user in the form of online tutorials, "How To", FAQs, etc. that can be used on their own to familiarize themselves with keying-in the registration data and the registration process

CER.ROR.8 System shall allow the applicant to preview the application form

CER.ROR.9 System shall apply spam control measures during registration to avoid spurious details being automatically submitted

CER.ROR.10 System shall allow add/ delete/ editing before submission

CER.ROR.11 System shall allow uploading of scanned copies of supporting documents/ attachments as required (if any)

CER.ROR.12 Validations for file type that shall be allowed to be uploaded include only formats such as .pdf/.doc.tiff/.rtf. It shall not allow .executable files.

CER.ROR.13 System shall allow to accept unique ID as proof of document which can be verified internally within departments through e-District interface (if required)

CER.ROR.14 System shall display the respective communication address and turnaround time required for processing of application



CER.ROR.15 System shall perform data validation checks on the input. In case of data being duplicated, System shall display the existing service request id.

CER.ROR.16 System shall allow save and print facility of the acknowledgement slip

CER.ROR.17 System shall display the respective communication address and turnaround time required for processing of application.

CER.ROR.18 System shall as a part of application establish challenge and responses mechanisms for session validation for future online sessions.

CER.ROR.19

System shall perform data validation checks on the completeness of the form in terms of mandatory fields, checking for file type and size of files uploaded, etc. In case of any validation failure, and shall display an appropriate error message.

CER.ROR.20 System shall apply spam control measures during registration to avoid spurious details being automatically submitted

CER.ROR.21 System shall allow the user to visit the secured payment gateway in case the user selects the option to make the payment through net banking, debit card or credit card (if required)

CER.ROR.22

System shall display the respective communication address/ drop box and turnaround time to make payment in case the applicant selects the option to make payment through bearer Cheque or cash at (ESO/CSC/CFC)

CER.ROR.23

System shall be able to provide unique 'Service Id Request' acknowledgement to the user along with expected TAT

CER.ROR.24 System shall allow user to save and print the acknowledgement for enquiry and grievance purposes

CER.ROR.25 System shall allow user to track the status of the application request along with remarks to the user such as: 1. Pending confirmation 2. Application accepted 3. Application declined

CER.ROR.26 System shall allow user be able to print and save the notification for easy retrieval of information for future reference

CER.ROR.27

System shall allow the user to rectify the error (in case of application declined) and notify applicant/citizen/ESO/CSC/CFC operator re-submit the same application

CER.ROR.28 System shall allow only authorized users to access the requested service & scanned supporting documentation (if any) and verify with other departments (if required)

CER.ROR.29 System shall allow the user to re- submit the application only after validating the authenticity of the user through challenges and response

CER.ROR.30 System shall send an activation link to the email id of the respective official responsible to accept the application

CER.ROR.31 System shall allow official to select make changes as per the application selected by applicant for Issuance of Form I & XIV

CER.ROR.32 System shall allow officials to work as per mandatory workflow set by the concerned department to be followed to complete the selected service for a valid output.

CER.ROR.33 System shall send an automated escalation mail to the next level of authority in case the respective official does not attend the application



link within TAT

CER.ROR.34 System shall allow and accept the digital signature from respective officials for processing the application and issue a valid Form I & XIV for the users

CER.ROR.35 System shall allow the respective official to update the status of the application request as per proceedings along with the remarks and shall allow generating MIS reports as required by authorized user.

CER.ROR.36 Any change to the application record shall generate a change log with details like name of the user making the changes, timestamp of transaction, etc.

CER.ROR.37 System shall allow official to intimate citizen/applicant for rejection / approval for Issuance of Form I & XIV on his/her request through sms, email etc.

CER.ROR.38 System shall allow citizen through State/department portal to confirm status of his/her application/service request for Issuance of Form I & XIV

CER.ROR.39 System shall allow to generate Form I & XIV in pdf, tiff ,etc. format from state/department portal where citizen can take the print of it

CER.ROR.40 System shall allow the respective official to update the status of the application request as per proceedings along with the remarks

CER.ROR.41 System shall be PKI enabled to accept digital signatures for digitally signing documents for Issuance of form I & XIV

CER.ROR.42 System shall consider the list of holidays for tracking the timelines of various activities.

CER.ROR.43

System shall support multilingual interface (minimum Konkani , Marathi and English) as per Localization and Language Technology Standards for National e-Governance Plan defined in e-District guidelines

CER.ROR.44

Issuance of Form I & XIV module of e-District application should be linked to general all service component appropriately as per department requirement – e.g. Information component, Form availability component etc.



III. Goa State Information Commission


RTI Services

1. RTI Filing & Status Services

Requirement ID

Description

RTI.FSS1 System shall allow Applicant/ESO/CSC/CFC operator to select State Information commission records from the home page of the State/department portal

RTI.FSS2 System shall allow service seeker to select RTI filing & status provided on the department page of the State/department portal

RTI.FSS3 System shall allow registration of applicant for future login and ease (registration mandatory)

RTI.FSS4 System shall be able to identify user login into System as defined by the security guidelines

RTI.FSS5

System shall be able to provide information to the citizens about RTI related services both in public as well as restricted domain as per the Information component 1. Web access to information content in public domain 2. e-District application access to information content

RTI.FSS6

System shall prompt the user to mention whether it is a fresh RTI filing/status or an escalation of the existing RTI filing / status. If it is an escalation of the existing RTI filing & status it shall prompt the user to mention the old RTI filing & status registration number along the RTI filing & status details. As soon as applicant/ESO/CSC/CFC operator provides the registration number of the old RTI filing & status all the related fields in the RTI filing & status registration form shall be auto filled with the help of entries made in the database.

RTI.FSS7 System shall provide all services under RTI filing & status

RTI.FSS8 System shall be able to retrieve relevant service request

RTI.FSS10 System shall allow the applicant to fill in the online application and if required allow operator to fill application form on behalf of citizen availing the service as per the application receipt component

RTI.FSS11 System shall be able to generate a unique registration number during registering an applicant

RTI.FSS12 System shall be able to issue an acknowledgement receipt once the applicant is registered with System as per application receipt component

RTI.FSS13 System shall be able to identify the applicant uniquely based on this registration number for all future references

RTI.FSS14 System shall be able to come up with final confirmation screen indicating successful submission of service request

RTI.FSS15 System shall be able to allow service fees payments for the RTI service as per the Payment Component

RTI.FSS16 System shall be able to route the service request to concerned officer (State



Public Information Officer – SPIO, Public Information Officer – PIO & APIO) at the following levels 1. Block 2. Sub-division 3. District 4. Department

RTI.FSS18 System shall have the functionality to accept service request even if the service request is not directed to block, sub-division or department under others categories

RTI.FSS19 System shall be able to route such application to State Information office for further re-routing

RTI.FSS20 System shall allow state information officer to allocate service request to concerned PIO for service request under other categories

RTI.FSS21 System shall be allow state public information officer-SPIO to allocate service request to concerned PIO/APIO for service request under other categories

RTI.FSS22 System shall auto generate notification of pending service delivery request to concerned PIO on successful submission of service request

RTI.FSS23 System shall allow the concerned PIO to accept / reject the service request as per the guidelines of the RTI act

RTI.FSS24 In case of rejection, System shall allow the concerned PIO to state the reason of rejection

RTI.FSS25 In case of acceptance, System shall open a new page with all the accepted service request by the concerned PIO

RTI.FSS26 System shall allow the PIO to allocate service request to APIO for required information

RTI.FSS27 System shall save the acceptance / rejection only on digital signature of the PIO

RTI.FSS28 System shall auto generate notification to concerned department/ information officer about service request allocation by the PIO

RTI.FSS29 System shall allow concerned department/ information officer to view service request as assigned by the PIO

RTI.FSS30 System shall allow concerned department/ information officer to print the individual service request 1. System shall be allow printer friendly version of service request

RTI.FSS31 System shall allow the concerned department/ information officer to submit report on the service request on defined values as given in the process description

RTI.FSS32 System shall submit the report only when it is digitally signed by the concerned department/ information officer

RTI.FSS33 System shall auto generate email to concerned PIO about the report submission against the service request by the concerned department/ information officer

RTI.FSS34 System shall open a page for PIO to fill in specific details on documents pertaining to the service request as defined in the process description

RTI.FSS35 System shall ask for digital signature of PIO for submission of the final delivery against the service request



RTI.FSS36 System shall ask for re-confirmation of PIO before actually submitting final delivery

RTI.FSS37 System shall show a successful submission screen on completion of the submission

RTI.FSS38 System shall be able to support the status tracking component as defined in the process map for status tracking

RTI.FSS39 System shall be able to generate notification to applicant for any payment to be deposited for requested service

RTI.FSS40 System shall be able to generate notification to concerned department / information officer for any payment received from applicant for requested service

RTI.FSS41 System shall allow concerned department / information officer to deliver requested service output after received payment is updated in system

RTI.FSS42 System shall be able to support the monitoring and reporting component as defined in the process map for monitoring and reporting

RTI.FSS43 System shall be able to auto escalate the service request to higher authority in state information commission if the service request is not processed

RTI.FSS44 System shall allow to intimate citizen through State portal to collect requested service output downloading online, collecting personally from dept. office, ESO/CSC or by post

RTI.FSS45 System shall send delivery report to the respective official whenever the citizen collects service output through state portal

RTI.FSS46 System shall be able to maintain all records for the login sessions with date and time

RTI.FSS47 System shall be able to provide date and time stamping for all transactions done with digital signature



IV. Panchayat/Municipality


Certificate

13. Issuance of Birth/Death Certificate

Requirement ID

Description

CER.BDC.1 The system shall be able to display birth/death certificate related page through multiple routes e.g. state portal, information link etc.

CER.BDC.2 System shall allow applicant/ESO/CSC operator to select Panchayat /Municipality from the Home page of the State Portal

CER.BDC.3 System shall allow applicant to select application for birth/death certificate on Panchayat or Municipality office page of the state portal

CER.BDC.4 System shall allow registration of applicant for future login and ease (registration mandatory) and shall be able to identify the user logging into the system using the login component

CER.BDC.5 System shall accept application of new applicants

CER.BDC.6

System shall be able to capture the applicants details through an electronic form such as: Name Contact Details Date of Birth/ Death Place of Birth/ Death Age (for Death) Details as required in application form used Unique Identification (UID) E-mail id (if any) Mobile No. (if any)

CER.BDC.7 System shall require entries from the user for certain important information items entered twice. For example email id needs to be captured correctly if email is the preferred mode of communication

CER.BDC.8 System shall provide adequate aid to the user in the form of online tutorials, "How To", FAQs, etc. that can be used on their own to familiarize themselves with keying-in the registration data and the registration process

CER.BDC.9 System shall allow the applicant to preview the application form

CER.BDC.10 System shall apply spam control measures during registration to avoid spurious details being automatically submitted and ensure that data is not submitted by non-humans

CER.BDC.11 System shall allow add/ delete/ editing before submission

CER.BDC.12 System shall perform data validation checks on the input. In case of data being duplicated System shall display the existing service request id and other records if any.

CER.BDC.13 System shall allow save and print facility of the acknowledgement slip

CER.BDC.14 The system should be able to channel as per the process map or as defined by the department and description for the service

CER.BDC.15 The System should make available the latest copy of the Application Form online (24x7) as per the Form Availability component.

CER.BDC.16 The system should allow the operator to fill in the online application on behalf



of citizen availing the service as per the „application receipt‟ component

CER.BDC.17 The System should be able to generate a unique registration number during registering an applicant with the application

CER.BDC.18 The System should be able to identify the applicant uniquely based on this registration number.

CER.BDC.19 The System should be able to record the payment made by the applicant against the Application as per the Payment Component

CER.BDC.20

The System should be able to notify the Registrar/Sub-registrar and Village panchayat secretary about the new application and this date and time must be logged.– through e-District application through SMS or through e-mail

CER.BDC.21 Should be able to route the application to the Registrar/Sub-registrar and Village panchayat secretary

CER.BDC.22 The system should allow concerned authorized officials to view the service request on authenticated login

CER.BDC.23

The system should allow Registrar/Sub-registrar and Village panchayat secretary to accept or reject any service request application

CER.BDC.24 The system should request Registrar/Sub-registrar and Village panchayat secretary to provide comments in case of rejection

CER.BDC.25 The system should save the acceptance / rejection only after digital signature of the Registrar/Sub-registrar and Village panchayat secretary

CER.BDC.26

The system should show service request to concerned Registrar/Sub-registrar and Village panchayat secretary as pending for approval till it is marked for further action - by default the system should be able to auto escalate within the service level as per the escalation matrix defined by department

CER.BDC.27 The system should load a page to enable Registrar/Sub-registrar and Village panchayat secretary to assign verification responsibility to concerned authority urban service request

CER.BDC.28 The system should allow the concerned officer to view the service request after authentication of username and password

CER.BDC.29 The system should allow officer to print the details of service request application form to have a hard copy of the same

CER.BDC.30 The System should allow the officer to update the verification details in relevant database (Birth Certificate Database).

CER.BDC.31 The System should allow the officer to electronically forward the application to the Registrar/Sub-registrar and Village panchayat secretary using his digital signature

CER.BDC.32 The system should allow concerned Registrar/Sub-registrar and Village panchayat secretary to view changes made in the database by the officer

CER.BDC.33

The system should be able to auto generate MIS reports for the following officials -District Registrar -Registrar/Sub-Registrar -Village Panchayat Secretary

CER.BDC.34 The system should be able to support the status tracking component as defined in the process map for status tracking

CER.BDC.35 The system should be able to support the monitoring and reporting component



as defined in the process map for monitoring and reporting

CER.BDC.36 The System should be able to detect changes in status and send status updates to the citizen as per the Status Tracking component.

CER.BDC.37 The System should be able escalate the application as per the Auto Escalation matrix defined in Auto Escalation Matrix table or by department, by notifying the next level of authority and sending him a copy of the application

CER.BDC.38 The system should be able to maintain all records for the login sessions with date and time

CER.BDC.39 The system should be able to provide date and time stamping for all transactions done with digital signature

CER.BDC.40 The System should have a facility for forwarding of the application, with remarks and digital sign of the sender, to any person in District administration registered with the System.

CER.BDC.41 The system should support multilingual interface (minimum Konkani, Marathi and English) as per Localization and Language Technology Standards for National e- Governance Plan defined in e-District guidelines.

CER.BDC.42

The e-District Application must support Digital Signatures of any of the Certifying Authorities authorized by the state/department and, and must be modifiable as per the changes made by the respective Certifying Authorities on the structure of the Digital Signatures issued by them.

CER.BDC.43 The Digital Signatures used and the e-District Application must provide the Time Stamping of the act of Digitally Signing a document



V. Transport Department


Transport

14. Application for grant of subsidy for Yellow/Black Motor Cycle/Auto Rickshaw, Taxi

Scheme 2003

Requirement ID

Description

TRS.SUB.1 System shall allow applicant/ESO/CSC/CFC operator to select Transport Department from the Home page of the State Portal

TRS.SUB.2 System shall allow applicant to select application for grant of subsidy for yellow/black motorcycle/auto rickshaw, Taxi Scheme 2003 on the department page of the state portal

TRS.SUB.3 System shall allow registration of applicant for future login and ease (registration mandatory)

TRS.SUB.4 System shall accept application of new applicants

TRS.SUB.5 System shall allow the applicant to opt for a suitable choice of subsidy before filling in the application for grant

TRS.SUB.6


1)Name

2)Contact Details

3)PIN

4)Age

5)Area of residence

6) Type of Vehicle

7)Details as required in application form used at present

8)Unique Identification (UID)

9)E-mail id (if any)

10) Mobile No. (if any)

TRS.SUB.14 System shall require entries from the user for certain important information items entered twice. For example email id needs to be captured correctly if email is the preferred mode of communication

TRS.SUB.15 System shall provide adequate aid to the user in the form of online tutorials, "How To", FAQs, etc. that can be used on their own to familiarize themselves with keying-in the registration data and the registration process

TRS.SUB.16 System shall allow the applicant to preview the registration

TRS.SUB.17 System shall apply spam control measures during registration to avoid spurious details being automatically submitted and ensure that data is not submitted by non-humans

TRS.SUB.18 System shall allow editing before submission

TRS.SUB.19

System shall allow upload of passport size photographs(high resolution) in addition to :

1) Income Certificate

2)Age Proof

3)Vehicle Information



4)Documents required at present

TRS.SUB.20 System shall perform data validation checks on the input. In case of data being duplicated, System shall display the existing service request id & existing record if any.

TRS.SUB.21 System shall allow save and print facility of the acknowledgement slip

TRS.SUB.22 Validations for file type that shall be allowed to be uploaded include only formats such as .pdf/.doc/.tiff/.rtf. It shall not allow .executable files.

TRS.SUB.23 System shall allow to accept unique ID as proof of document which can be verified internally within departments through SSDG interface

TRS.SUB.24 System shall display the respective communication address and turnaround time to submit documents in case the applicant selects the option to submit physical documents

TRS.SUB.25 System shall as a part of application establish challenge and responses mechanisms for session validation for future online sessions.

TRS.SUB.26


TRS.SUB.27 System shall apply spam control measures during registration to avoid spurious details being automatically submitted and ensure that data is not submitted by non-humans

TRS.SUB.28 System shall allow the user to visit the secured payment gateway in case the user selects the option to make the payment through net banking, debit card or credit card

TRS.SUB.29 System shall display the respective communication address/ drop box and turnaround time to make payment in case the applicant selects the option to make payment through bearer cheque

TRS.SUB.30 System shall be able to provide unique 'Service Id Request' acknowledgement to the user along with expected TAT

TRS.SUB.31 System shall allow user to save and print the acknowledgement for enquiry and grievance purposes

TRS.SUB.32 System shall allow user to track the status of the application request along with remarks to the user such as:

TRS.SUB.33 1. Pending confirmation

TRS.SUB.34 2. Application accepted

TRS.SUB.35 3. Application declined

TRS.SUB.36 User shall be able to print and save the notification for easy retrieval of information for future reference

TRS.SUB.37 System shall allow the user to rectify the error (in case of application declined) and re-submit the same application

TRS.SUB.38 System shall allow only authorized users to access the scanned supporting documentation and verify if they are correct

TRS.SUB.39 System shall allow the user to re- submit the application only after validating the authenticity of the user through challenges and response

TRS.SUB.40 System shall send an activation URL to the email id of the respective official responsible to accept the application

TRS.SUB.41 System shall send an automated escalation mail to the next level of authority in case the respective official does not attend the application URL within TAT



TRS.SUB.42 System shall allow only authorized users to access the scanned supporting documentation and verify with other departments if required

TRS.SUB.43 System shall allow and accept the digital signature from respective officials for processing the application and issue of certificate for the users

TRS.SUB.44 System shall allow the respective official to update the status of the application request as per proceedings along with the remarks

TRS.SUB.45 Any change to the application record shall generate a change log with details like name of the user making the changes, timestamp of transaction, etc.

TRS.SUB.46 System shall allow to intimate citizen through State portal to collect certificate of approval/rejection manually or by post

TRS.SUB.47 System shall allow to upload the scanned/ PDF copy of certificate in the State portal where citizen can take the print of it

TRS.SUB.48 System shall send delivery report to the respective official whenever the citizen collects the certificate of approval/rejection through state portal


Transport

15. Application for grant of subsidy for replacement of buses/mini buses above 15 years

Requirement ID

Description

TRS.OLD.1 System shall allow applicant/ESO/CSC/CFC operator to select Transport Department from the Home page of the State Portal

TRS.OLD.2 System shall allow applicant to select application for grant of subsidy for yellow/black motorcycle/auto rickshaw, Taxi Scheme 2003 on the department page of the state portal

TRS.OLD.3 System shall allow registration of applicant for future login and ease (registration not mandatory)

TRS.OLD.4 System shall accept application of new applicants

TRS.OLD.5 System shall allow the applicant to opt for a suitable choice of subsidy before filling in the application for grant

TRS.OLD.6


1)Name

2)Contact Details

3)PIN

4)Age

5)Area of residence

6) Type of Vehicle





TRS.OLD.14 System shall require entries from the user for certain important information items entered twice. For example email id needs to be captured correctly if email is the preferred mode of communication

TRS.OLD.15 System shall provide adequate aid to the user in the form of online tutorials,



"How To", FAQs, etc. that can be used on their own to familiarize themselves with keying-in the registration data and the registration process

TRS.OLD.16 System shall allow the applicant to preview the registration

TRS.OLD.17 System shall apply spam control measures during registration to avoid spurious details being automatically submitted and ensure that data is not submitted by non-humans

TRS.OLD.18 System shall allow editing before submission

TRS.OLD.19



2)Age Proof

3) Vehicle Information


TRS.OLD.20 System shall perform data validation checks on the input. In case of data being duplicated, System shall display the existing service request id & existing record if any.

TRS.OLD.21 System shall allow save and print facility of the acknowledgement slip

TRS.OLD.22 Validations for file type that shall be allowed to be uploaded include only formats such as above. It shall not allow .executable files.

TRS.OLD.23 System shall allow to accept unique ID as proof of document which can be verified internally within departments through SSDG interface

TRS.OLD.24 System shall display the respective communication address and turnaround time to submit documents in case the applicant selects the option to submit physical documents

TRS.OLD.25 System shall as a part of application establish challenge and responses mechanisms for session validation for future online sessions.

TRS.OLD.26



TRS.OLD.28 System shall allow the user to visit the secured payment gateway in case the user selects the option to make the payment through net banking, debit card or credit card

TRS.OLD.29 System shall display the respective communication address/ drop box and turnaround time to make payment in case the applicant selects the option to make payment through bearer cheque

TRS.OLD.30 System shall be able to provide unique 'Service Id Request' acknowledgement to the user along with expected TAT

TRS.OLD.31 System shall allow user to save and print the acknowledgement for enquiry and grievance purposes

TRS.OLD.32 System shall allow user to track the status of the application request along with remarks to the user such as:

TRS.OLD.33 1. Pending confirmation

TRS.OLD.34 2. Application accepted

TRS.OLD.35 3. Application declined



TRS.OLD.36 User shall be able to print and save the notification for easy retrieval of information for future reference

TRS.OLD.37 System shall allow the user to rectify the error (in case of application declined) and re-submit the same application

TRS.OLD.38 System shall allow only authorized users to access the scanned supporting documentation and verify with other departments if required

TRS.OLD.39 System shall allow the user to re- submit the application only after validating the authenticity of the user through challenges and response

TRS.OLD.40 System shall send an activation URL to the email id of the respective official responsible to accept the application

TRS.OLD.41 System shall send an automated escalation mail to the next level of authority in case the respective official does not attend the application URL within TAT

TRS.OLD.42 System shall allow only authorized users to access the scanned supporting documentation and verify if they are correct

TRS.OLD.43 System shall allow and accept the digital signature from respective officials for processing the application and issue of certificate for the users

TRS.OLD.44 System shall allow the respective official to update the status of the application request as per proceedings along with the remarks

TRS.OLD.45 Any change to the application record shall generate a change log with details like name of the user making the changes, timestamp of transaction, etc.

TRS.OLD.46 System shall allow to intimate citizen through State portal to collect certificate of approval/rejection manually or by post

TRS.OLD.47 System shall allow to upload the scanned/ PDF copy of certificate in the State portal where citizen can take the print of it

TRS.OLD.48 System shall send delivery report to the respective official whenever the citizen collects the certificate of approval/rejection through state portal



VI. Fisheries Department


Fisheries

16. Application for Registration/ Renewal of Fishing Nets

Requirement ID

Description

FSH.RFN.1 System shall allow applicant to select Fisheries Department from the Home page of the Portal

FSH.RFN.2 System shall allow applicant to select registration/renewal of fishing net application provided on the department page of the portal

FSH.RFN.3 System shall allow registration of applicant for future login and ease (registration mandatory)

FSH.RFN.4 System shall accept application of new and registered applicants

FSH.RFN.5 System shall be able to capture the applicants details through an electronic form such as: 1. Name 2. Contact Details 3. PIN 4. Age 5. Details as required in application form used 6. Formal declaration on the accuracy and responsibility of the information

provided in the form etc. 7. Unique Identification (UID) 8. E-mail id (if any) 9. Mobile No. (if any) 10. If registered then existing registration Id

FSH.RFN.6 System shall require entries from the user for certain important information items entered twice. For example email id needs to be captured correctly if email is the preferred mode of communication

FSH.RFN.7 System shall provide adequate aid to the user in the form of online tutorials, "How To", FAQs, etc. that can be used on their own to familiarize themselves with keying-in the registration data and the registration process

FSH.RFN.8 System shall allow the applicant to preview the registration

FSH.RFN.9 System shall apply spam control measures during registration to avoid spurious details being automatically submitted and ensure that data is not submitted by non-humans

FSH.RFN.10 System shall allow editing before submission

FSH.RFN.11 System shall perform data validation checks on the input. In case of data being duplicated, System shall display the existing service request id.

FSH.RFN.12 System shall allow save and print facility of the acknowledgement slip

FSH.RFN.13 Validations for file type that shall be allowed to be uploaded include only formats such as above. It shall not allow .executable files.

FSH.RFN.14 System shall allow to accept unique ID as proof of document which can be verified internally within departments through e-District interface

FSH.RFN.15 System shall display the respective communication address and turnaround time to submit documents in case the applicant selects the option to submit physical



documents

FSH.RFN.16 System shall as a part of application establish challenge and responses mechanisms for session validation for future online sessions.

FSH.RFN.17 System shall perform data validation checks on the completeness of the form in terms of mandatory fields, checking for file type and size of files uploaded, etc. In case of any validation failure, System shall display an appropriate error message.

FSH.RFN.18 System shall apply spam control measures during registration to avoid spurious details being automatically submitted and ensure that data is not submitted by non-humans

FSH.RFN.19 System shall allow the user to visit the secured payment gateway in case the user selects the option to make the payment through net banking, debit card or credit card

FSH.RFN.20 System shall display the respective communication address/ drop box and turnaround time to make payment in case the applicant selects the option to make payment through bearer cheque

FSH.RFN.21 System shall be able to provide unique 'Service Id Request' acknowledgement to the user along with expected TAT

FSH.RFN.22 System shall allow user to save and print the acknowledgement for enquiry and grievance purposes

FSH.RFN.23 System shall allow user to track the status of the application request along with remarks to the user such as: 1. Pending confirmation 2. Application declined 3. Application accepted

FSH.RFN.24 User shall be able to print and save the notification for easy retrieval of information for future reference

FSH.RFN.25 System shall allow the user to rectify the error (in case of application declined) and re-submit the same application

FSH.RFN.26 System shall allow only authorized users to access the scanned supporting documents and verify the same with concerned departments (if required)

FSH.RFN.27 System shall allow only authorized users to add verification report/appropriate remark (if required) to the application for processing

FSH.RFN.28 System shall allow the user to re- submit the application only after validating the authenticity of the user through challenges and response

FSH.RFN.29 System shall send an activation URL to the email id of the respective official responsible to accept the application

FSH.RFN.30 System shall send an automated escalation mail to the next level of authority in case the respective official does not attend the application URL within TAT

FSH.RFN.31 System shall be PKI enabled to accept digital signatures for digitally signing documents for registration/renewal of fishing nets

FSH.RFN.32 System shall allow and accept the digital signature from authorized/concerned officials for processing the application and approval /rejection of registration / renewal of fishing net for the users

FSH.RFN.33 System shall allow the authorized/concerned official to update the status of the application request as per proceedings along with the remarks

FSH.RFN.34 Any change to the application record shall generate a change log with details like name of the user making the changes, timestamp of transaction, etc.



FSH.RFN.35 System shall allow to intimate citizen to collect registration/renewal of fishing net approval/rejection

FSH.RFN.36 System shall allow to authorized authority to generate or upload scanned / PDF approved/rejected copy of registration/renewal of fishing net to be available through state/department portal where citizen/ESO/CSC operator can take the print of it

FSH.RFN.37 System shall allow citizen/ESO/CSC operator to download approved/rejected copy of registration/renewal of fishing net available through state/department portal with unique document no.

FSH.RFN.38 System shall consider the list of holidays for tracking the timelines of various activities.

FSH.RFN.39 System shall support multilingual interface (minimum Konkani , Marathi and English) as per Localization and Language Technology Standards for National e-Governance Plan defined in e-District guidelines

FSH.RFN.40 Registration/Renewal of fishing nets module of e-District application should be linked to general all service component appropriately as per department requirement –e.g. Information component, Form availability component etc.



VII. Tourism Department


Others

17. Registration of New Water Sports Activities

Requirement ID

Description

NWS.TD.1 System shall allow applicant/ESO/CSC/CFC operator to select Tourism Department from the Home page of the State Portal

NWS.TD 2 System shall allow applicant to select application for registration of new water sport activity on the department page of the state portal

NWS.TD.3 System shall allow registration of applicant for future login and ease (registration not mandatory)

NWS.TD.4 System shall allow applicant to fill/edit e-Form/Application online

NWS.TD.5 System shall accept filled e-Form/application of new applicants

NWS.TD.6


1)Name

2)Contact Details

3)PIN

4)Age

5)Area of residence

6) Type of water activity





NWS.TD.7 System shall require entries from the user for certain important information items entered twice. For example email id needs to be captured correctly if email is the preferred mode of communication

NWS.TD.7 System shall provide adequate aid to the user in the form of online tutorials, "How To", FAQs, etc. that can be used on their own to familiarize themselves with keying-in the registration data and the registration process

NWS.TD.8 System shall allow the applicant to preview the registration

NWS.TD.9 System shall apply spam control measures during registration to avoid spurious details being automatically submitted and ensure that data is not submitted by non-humans

NWS.TD.10 System shall allow editing before submission

NWS.TD.11



2)Age Proof

3) Water Sport Activity Information




NWS.TD.12 System shall perform data validation checks on the input. In case of data being duplicated, System shall display the existing service request id & existing record if any.

NWS.TD.13 System shall allow save and print facility of the acknowledgement slip

NWS.TD.14 Validations for file type that shall be allowed to be uploaded include only formats such as above. It shall not allow .executable files.

NWS.TD.15 System shall allow to accept unique ID as proof of document which can be verified internally within departments through SSDG interface

NWS.TD.16 System shall display the respective communication address and turnaround time to submit documents in case the applicant selects the option to submit physical documents

NWS.TD.17 System shall as a part of application establish challenge and responses mechanisms for session validation for future online sessions.

NWS.TD.18 System shall perform data validation checks on the completeness of the form in terms of mandatory fields, checking for file type and size of files uploaded, etc. In case of any validation failure, System shall display an appropriate error message.

NWS.TD.19 System shall apply spam control measures during registration to avoid spurious details being automatically submitted and ensure that data is not submitted by non-humans

NWS.TD.20 System shall allow the user to visit the secured payment gateway in case the user selects the option to make the payment through net banking, debit card or credit card

NWS.TD.21 System shall display the respective communication address/ drop box and turnaround time to make payment in case the applicant selects the option to make payment through bearer cheque

NWS.TD.22 System shall be able to provide unique 'Service Id Request' acknowledgement to the user along with expected TAT

NWS.TD.23 System shall allow user to save and print the acknowledgement for enquiry and grievance purposes

NWS.TD.24 System shall allow user to track the status of the application request along with remarks to the user such as:

NWS.TD.26 1. Pending confirmation

NWS.TD.27 2. Application accepted

NWS.TD.28 3. Application declined

NWS.TD.29 User shall be able to print and save the notification for easy retrieval of information for future reference

NWS.TD.30 System shall allow the user to rectify the error (in case of application declined) and re-submit the same application

NWS.TD.31 System shall allow only authorized users to access the scanned supporting documentation and verify if they are correct

NWS.TD.32 System shall allow the user to re- submit the application only after validating the authenticity of the user through challenges and response

NWS.TD.33 System shall send an activation URL to the email id of the respective official responsible to accept the application

NWS.TD.34 System shall send an automated escalation mail to the next level of authority in case the respective official does not attend the application URL within TAT

NWS.TD.35 System shall allow only authorized users to access the scanned supporting documentation and verify with other departments if required



NWS.TD.36 System shall allow and accept the digital signature from respective officials for processing the application and issue of certificate for the users

NWS.TD.37 System shall allow the respective official to update the status of the application request as per proceedings along with the remarks

NWS.TD.38 Any change to the application record shall generate a change log with details like name of the user making the changes, timestamp of transaction, etc.

NWS.TD.39 System shall allow to intimate citizen through State portal to collect certificate of approval/rejection manually or by post

NWS.TD.40 System shall allow to upload the scanned/ PDF copy of certificate in the State portal where citizen can take the print of it

NWS.TD.41 System shall send delivery report to the respective official whenever the citizen collects the new water sport activity certificate.



VIII. Registration Department


Certificate

18. Application for marriage registration certificate

Requirement ID

Description

MRC.RED.1 System shall allow applicant/ESO/CSC/CFC operator to select Registration Department from the Home page of the State Portal

MRC.RED.2 System shall allow applicant to select application for Application for marriage registration certificate on the department page of the state portal

MRC.RED.3 System shall allow registration of applicant for future login and ease

MRC.RED.4 System shall allow applicant to fill/edit e-Form/Application online

MRC.RED.5 System shall accept filled e-Form/application of new applicants

MRC.RED.6


1. Name (Bride & Groom)

2. Contact Details

3. PIN

4. Age

5. Area of residence

6. Details as required in application form used at present

7. Unique Identification (UID)

8. E-mail id (if any)

9. Mobile No. (if any)

MRC.RED.7 System is able to identify the user logging into System using the login component.

MRC.RED.7

System shall be able to provide information to the citizens about Marriage services both in public as well as private domain as per the „Information component‟ -Web access to information content in public domain - E-District application access to information content

MRC.RED.8 System shall be able to channel as per the process map and description for the service

MRC.RED.9 System shall make available the latest copy of the Application Form online (24x7) as per the Form Availability component.

MRC.RED.10 System shall allow the operator to fill in the online application on behalf of citizen availing the service as per the „application receipt‟ component

MRC.RED.11 System shall be able to generate a unique registration number during registering an applicant with the application.

MRC.RED.12 System shall be able to identify the applicant uniquely based on this registration number.

MRC.RED.13 System shall be able to record the payment made by the applicant against the Application as per the Payment Component

MRC.RED.14 System shall display a message regarding successful or unsuccessful



completion of any transaction.

MRC.RED.15 System shall refresh the page in case of failure in submission of service request

MRC.RED.16 System shall be able to notify the Registrar/Sub Registrar about the new application and the date and time must be logged & Should be able to route the application to the Registrar/Sub Registrar.

MRC.RED.17 System shall allow concerned officials to view the service request on authenticated login

MRC.RED.18 System shall allow Registrar/Sub Registrar to accept or reject any service request application

MRC.RED.19 System shall request Registrar/Sub Registrar to provide comments in case of rejection

MRC.RED.20 System shall save the acceptance / rejection only after digital signature of the Registrar/Sub Registrar

MRC.RED.21

System shall show service request to concerned Registrar/Sub Registrar as pending for approval till it is marked for further action -by default System shall be able to auto escalate within the service level as per the escalation matrix defined

MRC.RED.22 System shall load a page to enable Registrar/Sub Registrar to assign verification responsibility to concerned authority

MRC.RED.23 System shall auto generate notification to concerned official once the Registrar/Sub Registrar has assigned officer for physical verification

MRC.RED.24 System shall allow the concerned officer to view the service request after authentication of username and password

MRC.RED.26 System shall allow officer to print the details of service request application form to have a hard copy of the same

MRC.RED.27 System shall allow the officer to update the verification details in relevant database (Marriage Database).

MRC.RED.28

System shall be able to auto generate MIS reports for the following officials -State Registrar -District Registrar - Civil Registrar/Sub Registrar

MRC.RED.29 System shall allow the officer to electronically forward the application to the Registrar/Sub Registrar using his digital signature

MRC.RED.30 System shall allow concerned Registrar/Sub Registrar to view changes made in the database by the officer

MRC.RED.31 System shall be able to support the status tracking component as defined in the process map for status tracking

MRC.RED.32 System shall be able to support the monitoring and reporting component as defined in the process map for monitoring and reporting

MRC.RED.33 System shall be able to detect changes in status and send status updates to the citizen as per the Status Tracking component

MRC.RED.34 System shall be able escalate the application as per the Auto Escalation matrix defined in Auto Escalation Matrix table, by notifying the next level of authority and sending him a copy of the application

MRC.RED.35 System shall be able to maintain all records for the login sessions with date and time

MRC.RED.36 System shall be PKI enabled to accept digital signatures for digitally signing



documents for marriage registration certificate.

MRC.RED.37 System shall have a facility for forwarding of the application, with remarks and digital sign of the sender, to any person in District administration registered with System

MRC.RED.38 System shall be able to provide date and time stamping for all transactions done with digital signature

MRC.RED.39 System shall consider the list of holidays for tracking the timelines of various activities.

MRC.RED.40 System shall support multilingual interface (minimum Konkani , Marathi and English as per Localization and Language Technology Standards for National e-Governance Plan defined in e-District guidelines

MRC.RED.41 Registration/Renewal of fishing nets module of e-District application should be linked to general all service component appropriately as per department requirement –e.g. Information component, Form availability component etc.

MRC.RED.42 System shall save the acceptance / rejection only after digital signature of the Registrar/Sub Registrar



IX. Captain of Ports


Certificate

19. Registration/Renewal of Inland Vessels

Requirement ID

Description

RIV.COP.1 System shall allow applicant/ESO/CSC/CFC operator to select Captain of Ports from the Home page of the State Portal

RIV.COP 2 System shall allow applicant to select application for registration/renewal of Inland vessel on the Captain of ports department page of the state portal

RIV.COP.3 System shall allow registration of applicant for future login and ease

RIV.COP.4 System shall allow applicant to fill/edit e-Form/Application online

RIV.COP.5 System shall accept filled e-Form/application of new applicants

RIV.COP.6


1. Name

2. Contact Details

3. PIN

4. Age


6. Type of vessel





RIV.COP.7 System shall require entries from the user for certain important information items entered twice. For example email id needs to be captured correctly if email is the preferred mode of communication

RIV.COP.7 System shall provide adequate aid to the user in the form of online tutorials, "How To", FAQs, etc. that can be used on their own to familiarize themselves with keying-in the registration data and the registration process

RIV.COP.8 System shall allow the applicant to preview the registration


RIV.COP.10 System shall allow editing before submission

RIV.COP.11


1. Copy of registration of vessel if registered

2. Valid Id. Proof

3. Other supporting documents if required at present

RIV.COP.12 System shall perform data validation checks on the input. In case of data being duplicated, System shall display the existing service request id & existing record if any.

RIV.COP.13 System shall allow save and print facility of the acknowledgement slip



RIV.COP.14 Validations for file type that shall be allowed to be uploaded include only formats such as above. It shall not allow .executable files.

RIV.COP.15 System shall allow to accept unique ID as proof of document which can be verified internally within departments through SSDG interface

RIV.COP.16 System shall display the respective communication address and turnaround time to submit documents in case the applicant selects the option to submit physical documents

RIV.COP.17 System shall as a part of application establish challenge and responses mechanisms for session validation for future online sessions.

RIV.COP.18


RIV.COP.19 System shall apply spam control measures during registration to avoid spurious details being automatically submitted and ensure that data is not submitted by non-humans

RIV.COP.20 System shall allow the user to visit the secured payment gateway in case the user selects the option to make the payment through net banking, debit card or credit card

RIV.COP.21 System shall display the respective communication address/ drop box and turnaround time to make payment in case the applicant selects the option to make payment through bearer cheque

RIV.COP.22 System shall be able to provide unique 'Service Id Request' acknowledgement to the user along with expected TAT

RIV.COP.23 System shall allow user to save and print the acknowledgement for enquiry and grievance purposes

RIV.COP.24 System shall allow user to track the status of the application request along with remarks to the user such as:

RIV.COP.26 1. Pending confirmation

RIV.COP.27 2. Application accepted

RIV.COP.28 3. Application declined

RIV.COP.29 User shall be able to print and save the notification for easy retrieval of information for future reference

RIV.COP.30 System shall allow the user to rectify the error (in case of application declined) and re-submit the same application

RIV.COP.31 System shall allow only authorized users to access the scanned supporting documentation and verify if they are correct

RIV.COP.32 System shall allow the user to re- submit the application only after validating the authenticity of the user through challenges and response

RIV.COP.33 System shall send an activation URL to the email id of the respective official responsible to accept the application

RIV.COP.34 System shall send an automated escalation mail to the next level of authority in case the respective official does not attend the application URL within TAT

RIV.COP.35 System shall allow only authorized users to access the scanned supporting documentation and verify if they are correct with other departments

RIV.COP.36 System shall allow and accept the digital signature from respective officials for processing the application for registration / renewal of Inland vessel for the users



RIV.COP.37 System shall allow the respective official to update the status of the application request as per proceedings along with the remarks

RIV.COP.38 Any change to the application record shall generate a change log with details like name of the user making the changes, timestamp of transaction, etc.

RIV.COP.39 System shall allow to intimate citizen through State portal to collect certificate of approval/rejection manually or by post

RIV.COP.40 System shall allow to upload the scanned/ PDF copy of certificate in the State portal where citizen can take the print of it

RIV.COP.41 System shall send delivery report to the respective official whenever the citizen collects valid registration/renewal certificate for Inland Vessel

20. Registration/Renewal of Water Sport Vessels

Requirement ID

Description

WSV.COP.1 System shall allow applicant/ESO/CSC/CFC operator to select Captain of Ports from the Home page of the State Portal

WSV.COP 2 System shall allow applicant to select application for registration/ renewal of water sport vessel on the Captain of ports department page of the state portal

WSV.COP.3 System shall allow registration of applicant for future login and ease

WSV.COP.4 System shall allow applicant to fill/edit e-Form/Application online

WSV.COP.5 System shall accept filled e-Form/application of new applicants

WSV.COP.6


1. Name

2. Contact Details

3. PIN

4. Age


6. Type of vessel





WSV.COP.7 System shall require entries from the user for certain important information items entered twice. For example email id needs to be captured correctly if email is the preferred mode of communication

WSV.COP.7 System shall provide adequate aid to the user in the form of online tutorials, "How To", FAQs, etc. that can be used on their own to familiarize themselves with keying-in the registration data and the registration process

WSV.COP.8 System shall allow the applicant to preview the registration

WSV.COP.9 System shall apply spam control measures during registration to avoid spurious details being automatically submitted and ensure that data is not submitted by non-humans

WSV.COP.10 System shall allow editing before submission

WSV.COP.11 System shall allow upload of passport size photographs(high resolution) in addition to :

1. Copy of registration of vessel if registered



2. Valid Id. Proof


WSV.COP.12 System shall perform data validation checks on the input. In case of data being duplicated, System shall display the existing service request id & existing record if any.

WSV.COP.13 System shall allow save and print facility of the acknowledgement slip

WSV.COP.14 Validations for file type that shall be allowed to be uploaded include only formats such as above. It shall not allow executable files.

WSV.COP.15 System shall allow to accept unique ID as proof of document which can be verified internally within departments through SSDG interface

WSV.COP.16 System shall display the respective communication address and turnaround time to submit documents in case the applicant selects the option to submit physical documents

WSV.COP.17 System shall as a part of application establish challenge and responses mechanisms for session validation for future online sessions.

WSV.COP.18


WSV.COP.19 System shall apply spam control measures during registration to avoid spurious details being automatically submitted and ensure that data is not submitted by non-humans

WSV.COP.20 System shall allow the user to visit the secured payment gateway in case the user selects the option to make the payment through net banking, debit card or credit card

WSV.COP.21 System shall display the respective communication address/ drop box and turnaround time to make payment in case the applicant selects the option to make payment through bearer cheque

WSV.COP.22 System shall be able to provide unique 'Service Id Request' acknowledgement to the user along with expected TAT

WSV.COP.23 System shall allow user to save and print the acknowledgement for enquiry and grievance purposes

WSV.COP.24 System shall allow user to track the status of the application request along with remarks to the user such as:

WSV.COP.26 1. Pending confirmation

WSV.COP.27 2. Application accepted

WSV.COP.28 3. Application declined

WSV.COP.29 User shall be able to print and save the notification for easy retrieval of information for future reference

WSV.COP.30 System shall allow the user to rectify the error (in case of application declined) and re-submit the same application

WSV.COP.31 System shall allow only authorized users to access the scanned supporting documentation and verify if they are correct

WSV.COP.32 System shall allow the user to re- submit the application only after validating the authenticity of the user through challenges and response

WSV.COP.33 System shall send an activation URL to the email id of the respective official responsible to accept the application



WSV.COP.34 System shall send an automated escalation mail to the next level of authority in case the respective official does not attend the application URL within TAT

WSV.COP.35 System shall allow only authorized users to access the scanned supporting documentation and verify if they are correct with other departments

WSV.COP.36 System shall allow and accept the digital signature from respective officials for processing the application of registration & renewal of water sports vessel for the users

WSV.COP.37 System shall allow the respective official to update the status of the application request as per proceedings along with the remarks

WSV.COP.38 Any change to the application record shall generate a change log with details like name of the user making the changes, timestamp of transaction, etc.

WSV.COP.39 System shall allow to intimate citizen through State portal to collect certificate of approval/rejection manually or by post

WSV.COP.40 System shall allow to upload the scanned/ PDF copy of certificate in the State portal where citizen can take the print of it

WSV.COP.41 System shall send delivery report to the respective official whenever the citizen collects valid registration/renewal certificate for water sport vessel



X. Department of Sports & Youth Affairs


Certificate

21. Registration of schools for participation in games

Requirement ID

Description

SYA.SPG.1 System shall allow applicant/ESO/CSC/CFC operator to select Department of sports & youth affairs from the home page of the State Portal

SYA.SPG 2 System shall allow applicant to select application for registration of schools for participation in games on the Department of sports & youth affairs page of the state portal

SYA.SPG.3 System shall allow registration of applicant/school for future login and ease

SYA.SPG.4 System shall allow applicant to fill/edit e-Form/Application online

SYA.SPG.5 System shall accept filled e-Form/application of new applicants

SYA.SPG.6


1. Name

2. Contact Details

3. PIN

4. Age


6. Type of School (Girls/Boys)


8. School Registration No. (Re. No.))


10. Contact No. if any

SYA.SPG.7 System shall require entries from the user for certain important information items entered twice. For example email id needs to be captured correctly if email is the preferred mode of communication

SYA.SPG.7 System shall provide adequate aid to the user in the form of online tutorials, "How To", FAQs, etc. that can be used on their own to familiarize themselves with keying-in the registration data and the registration process

SYA.SPG.8 System shall allow the applicant/school to preview the registration


SYA.SPG.10 System shall allow editing before submission

SYA.SPG.11

System shall allow upload:

1. Copy of registration of school

2. Valid Id. Proof of user


SYA.SPG.12 System shall perform data validation checks on the input. In case of data being duplicated, System shall display the existing service request id & existing record if any.

SYA.SPG.13 System shall allow save and print facility of the acknowledgement slip



SYA.SPG.14 Validations for file type that shall be allowed to be uploaded include only formats such as above. It shall not allow .executable files.

SYA.SPG.15 System shall allow to accept unique ID as proof of document which can be verified internally within departments through SSDG interface

SYA.SPG.16 System shall display the respective communication address and turnaround time to submit documents in case the applicant selects the option to submit physical documents

SYA.SPG.17 System shall as a part of application establish challenge and responses mechanisms for session validation for future online sessions.

SYA.SPG.18


SYA.SPG.19 System shall apply spam control measures during registration to avoid spurious details being automatically submitted and ensure that data is not submitted by non-humans

SYA.SPG.20 System shall allow the user to visit the secured payment gateway in case the user selects the option to make the payment through net banking, debit card or credit card

SYA.SPG.21 System shall display the respective communication address/ drop box and turnaround time to make payment in case the applicant selects the option to make payment through bearer cheque

SYA.SPG.22 System shall be able to provide unique 'Service Id Request' acknowledgement to the user along with expected TAT

SYA.SPG.23 System shall allow user to save and print the acknowledgement for enquiry and grievance purposes

SYA.SPG.24 System shall allow user to track the status of the application request along with remarks to the user such as:

SYA.SPG.26 1. Pending confirmation

SYA.SPG.27 2. Application accepted

SYA.SPG.28 3. Application declined

SYA.SPG.29 User shall be able to print and save the notification for easy retrieval of information for future reference

SYA.SPG.30 System shall allow the user to rectify the error (in case of application declined) and re-submit the same application

SYA.SPG.31 System shall allow only authorized users to access the scanned supporting documentation and verify if they are correct

SYA.SPG.32 System shall allow the user to re- submit the application only after validating the authenticity of the user through challenges and response

SYA.SPG.33 System shall send an activation URL to the email id of the respective official responsible to accept the application

SYA.SPG.34 System shall send an automated escalation mail to the next level of authority in case the respective official does not attend the application URL within TAT

SYA.SPG.35 System shall allow only authorized users to access the scanned supporting documentation and verify if they are correct with other departments

SYA.SPG.36 System shall allow and accept the digital signature from respective officials for processing the application of registration of schools for participation in games for the users/schools



SYA.SPG.37 System shall allow the respective official to update the status of the application request as per proceedings along with the remarks

SYA.SPG.38 Any change to the application record shall generate a change log with details like name of the user making the changes, timestamp of transaction, etc.

SYA.SPG.39 System shall allow to intimate schools through State portal to collect final fixture for sports activates with registration of approval/rejection manually or by post

SYA.SPG.40 System shall allow to upload the scanned/ PDF copy of final fixture for games in the State portal where applicant/ school can take the print of it

SYA.SPG.41 System shall send delivery report to the respective official whenever the applicant /school staff collects valid registration for games with final fixture

22. Application for sportsperson certificate

Requirement ID

Description

SYA.SPC.1 System shall allow applicant/ESO/CSC/CFC operator to select Department of sports & youth affairs from the home page of the State Portal

SYA.SPC 2 System shall allow applicant to select application for sportsperson certificate on the department of sports & youth affairs department page of the state portal

SYA.SPC.3 System shall allow registration of applicant for future login and ease

SYA.SPC.4 System shall allow applicant to fill/edit e-Form/Application online

SYA.SPC.5 System shall accept filled e-Form/application of new applicants

SYA.SPC.6


1. Name

2. Contact Details

3. PIN

4. Age


6. Participation Certificate /Form 2 (SAG)





SYA.SPC.7 System shall require entries from the user for certain important information items entered twice. For example email id needs to be captured correctly if email is the preferred mode of communication

SYA.SPC.7 System shall provide adequate aid to the user in the form of online tutorials, "How To", FAQs, etc. that can be used on their own to familiarize themselves with keying-in the registration data and the registration process

SYA.SPC.8 System shall allow the applicant to preview the registration


SYA.SPC.10 System shall allow editing before submission

SYA.SPC.11 System shall allow upload of passport size photographs(high resolution) in



addition to :

4. Copy of games merit/participation certificate / Form 2 ( from SAG)

5. Valid Id. Proof


SYA.SPC.12 System shall perform data validation checks on the input. In case of data being duplicated, System shall display the existing service request id & existing record if any.

SYA.SPC.13 System shall allow save and print facility of the acknowledgement slip

SYA.SPC.14 Validations for file type that shall be allowed to be uploaded include only formats such as above. It shall not allow .executable files.

SYA.SPC.15 System shall allow to accept unique ID as proof of document which can be verified internally within departments through SSDG interface

SYA.SPC.16 System shall display the respective communication address and turnaround time to submit documents in case the applicant selects the option to submit physical documents

SYA.SPC.17 System shall as a part of application establish challenge and responses mechanisms for session validation for future online sessions.

SYA.SPC.18


SYA.SPC.19 System shall apply spam control measures during registration to avoid spurious details being automatically submitted and ensure that data is not submitted by non-humans

SYA.SPC.20 System shall allow the user to visit the secured payment gateway in case the user selects the option to make the payment through net banking, debit card or credit card

SYA.SPC.21 System shall display the respective communication address/ drop box and turnaround time to make payment in case the applicant selects the option to make payment through bearer cheque

SYA.SPC.22 System shall be able to provide unique 'Service Id Request' acknowledgement to the user along with expected TAT

SYA.SPC.23 System shall allow user to save and print the acknowledgement for enquiry and grievance purposes

SYA.SPC.24 System shall allow user to track the status of the application request along with remarks to the user such as:

SYA.SPC.26 1. Pending confirmation

SYA.SPC.27 2. Application accepted

SYA.SPC.28 3. Application declined

SYA.SPC.29 User shall be able to print and save the notification for easy retrieval of information for future reference

SYA.SPC.30 System shall allow the user to rectify the error (in case of application declined) and re-submit the same application

SYA.SPC.31 System shall allow only authorized users to access the scanned supporting documentation and verify if they are correct

SYA.SPC.32 System shall allow the user to re- submit the application only after validating the authenticity of the user through challenges and response

SYA.SPC.33 System shall send an activation URL to the email id of the respective official



responsible to accept the application

SYA.SPC.34 System shall send an automated escalation mail to the next level of authority in case the respective official does not attend the application URL within TAT

SYA.SPC.35 System shall allow only authorized users to access the scanned supporting documentation and verify if they are correct with other departments

SYA.SPC.36 System shall allow and accept the digital signature from respective officials for processing the application of sportsperson certificate for the users

SYA.SPC.37 System shall allow the respective official to update the status of the application request as per proceedings along with the remarks

SYA.SPC.38 Any change to the application record shall generate a change log with details like name of the user making the changes, timestamp of transaction, etc.

SYA.SPC.39 System shall allow to intimate applicant/citizen through State portal to collect sports person certificate of approval/rejection manually or by post

SYA.SPC.40 System shall allow to upload the scanned/ PDF copy of sports person certificate in the State portal where applicant/citizen can take the print of it

SYA.SPC.41 System shall send delivery report to the respective official whenever the citizen collects valid sports person certificate


Certificate

23. Registration/Application for entry into state youth festival

Requirement ID

Description

SYA.PYF.1 System shall allow applicant/ESO/CSC/CFC operator to select Department of sports & youth affairs from the home page of the State Portal

SYA.PYF 2 System shall allow applicant to select application for registration/application for entry into state youth festival on the department of sports & youth affairs page of the state portal

SYA.PYF.3 System shall allow registration of applicant/school for future login and ease

SYA.PYF.4 System shall allow applicant to fill/edit e-Form/Application online

SYA.PYF.5 System shall accept filled e-Form/application of new applicants

SYA.PYF.6


1. Name

2. Contact Details

3. PIN

4. Age


6. Type of School (Girls/Boys)

7. School/College Registration No. (Re. No.))


9. If individual then any UID (Unique Identification)



SYA.PYF.7 System shall require entries from the user for certain important information items entered twice. For example email id needs to be captured correctly if email is the preferred mode of communication



SYA.PYF.7 System shall provide adequate aid to the user in the form of online tutorials, "How To", FAQs, etc. that can be used on their own to familiarize themselves with keying-in the registration data and the registration process

SYA.PYF.8 System shall allow the applicant/school to preview the registration


SYA.PYF.10 System shall allow editing before submission

SYA.PYF.11


1. Copy of registration of school/ college

2. Valid Id/Age. Proof of user


SYA.PYF.12 System shall perform data validation checks on the input. In case of data being duplicated, System shall display the existing service request id & existing record if any.

SYA.PYF.13 System shall allow save and print facility of the acknowledgement slip

SYA.PYF.14 Validations for file type that shall be allowed to be uploaded include only formats such as above. It shall not allow .executable files.

SYA.PYF.15 System shall allow to accept unique ID as proof of document which can be verified internally within departments through SSDG interface

SYA.PYF.16 System shall display the respective communication address and turnaround time to submit documents in case the applicant selects the option to submit physical documents

SYA.PYF.17 System shall as a part of application establish challenge and responses mechanisms for session validation for future online sessions.

SYA.PYF.18


SYA.PYF.19 System shall apply spam control measures during registration to avoid spurious details being automatically submitted and ensure that data is not submitted by non-humans

SYA.PYF.20 System shall allow the user to visit the secured payment gateway in case the user selects the option to make the payment through net banking, debit card or credit card

SYA.PYF.21 System shall display the respective communication address/ drop box and turnaround time to make payment in case the applicant selects the option to make payment through bearer cheque

SYA.PYF.22 System shall be able to provide unique 'Service Id Request' acknowledgement to the user along with expected TAT

SYA.PYF.23 System shall allow user to save and print the acknowledgement for enquiry and grievance purposes

SYA.PYF.24 System shall allow user to track the status of the application request along with remarks to the user such as:

SYA.PYF.26 1. Pending confirmation

SYA.PYF.27 2. Application accepted

SYA.PYF.28 3. Application declined

SYA.PYF.29 User shall be able to print and save the notification for easy retrieval of



information for future reference

SYA.PYF.30 System shall allow the user to rectify the error (in case of application declined) and re-submit the same application

SYA.PYF.31 System shall allow only authorized users to access the scanned supporting documentation and verify if they are correct

SYA.PYF.32 System shall allow the user to re- submit the application only after validating the authenticity of the user through challenges and response

SYA.PYF.33 System shall send an activation URL to the email id of the respective official responsible to accept the application

SYA.PYF.34 System shall send an automated escalation mail to the next level of authority in case the respective official does not attend the application URL within TAT

SYA.PYF.35 System shall allow only authorized users to access the scanned supporting documentation and verify if they are correct with other departments

SYA.PYF.36 System shall allow and accept the digital signature from respective officials for processing the application of registration/application for entry into state youth festival

SYA.PYF.37 System shall allow the respective official to update the status of the application request as per proceedings along with the remarks

SYA.PYF.38 Any change to the application record shall generate a change log with details like name of the user making the changes, timestamp of transaction, etc.

SYA.PYF.39 System shall allow to intimate individual/schools/college through State portal to collect registration for entry into state youth festival of approval/rejection with event venue & schedule manually or by post

SYA.PYF.40 System shall allow to upload the scanned/ PDF copy of registration for entry into state youth festival of approval/rejection with event venue & schedule in the state portal where applicant/ school/college can take the print of it

SYA.PYF.41 System shall send delivery report to the respective official whenever the applicant /school /college staff collects valid registration for participation in youth festival


Certificate

24. Application for grant in aid for various educational institutes

Requirement ID

Description

SYA.EGA.1 System shall allow applicant/ESO/CSC/CFC operator to select Department of sports & youth affairs from the home page of the State Portal

SYA.EGA 2 System shall allow applicant to select application for grant in aid for various educational institutes on the department of sports & youth affairs page of the state portal

SYA.EGA.3 System shall allow registration of applicant/registered educational institutes for future login and ease

SYA.EGA.4 System shall allow applicant to fill/edit e-Form/Application online

SYA.EGA.5 System shall accept filled e-Form/application of new applicants

SYA.EGA.6 System shall be able to capture the applicants details through an electronic form such as:

1. Name



2. Contact Details

3. PIN

4. Age


6. Registration No. of educational institute




SYA.EGA.7 System shall require entries from the user for certain important information items entered twice. For example email id needs to be captured correctly if email is the preferred mode of communication

SYA.EGA.7 System shall provide adequate aid to the user in the form of online tutorials, "How To", FAQs, etc. that can be used on their own to familiarize themselves with keying-in the registration data and the registration process

SYA.EGA.8 System shall allow the applicant/school to preview the registration

SYA.EGA.9 System shall apply spam control measures during registration to avoid spurious details being automatically submitted and ensure that data is not submitted by non-humans

SYA.EGA.10 System shall allow editing before submission

SYA.EGA.11


4. Copy of registration of education institute

5. Valid Id. Proof of user


SYA.EGA.12 System shall perform data validation checks on the input. In case of data being duplicated, System shall display the existing service request id & existing record if any.

SYA.EGA.13 System shall allow save and print facility of the acknowledgement slip

SYA.EGA.14 Validations for file type that shall be allowed to be uploaded include only formats such as above. It shall not allow .executable files.

SYA.EGA.15 System shall allow to accept unique ID as proof of document which can be verified internally within departments through SSDG interface

SYA.EGA.16 System shall display the respective communication address and turnaround time to submit documents in case the applicant selects the option to submit physical documents

SYA.EGA.17 System shall as a part of application establish challenge and responses mechanisms for session validation for future online sessions.

SYA.EGA.18


SYA.EGA.19 System shall apply spam control measures during registration to avoid spurious details being automatically submitted and ensure that data is not submitted by non-humans

SYA.EGA.20 System shall allow the user to visit the secured payment gateway in case the user selects the option to make the payment through net banking, debit card or credit card

SYA.EGA.21 System shall display the respective communication address/ drop box and



turnaround time to make payment in case the applicant selects the option to make payment through bearer cheque

SYA.EGA.22 System shall be able to provide unique 'Service Id Request' acknowledgement to the user along with expected TAT

SYA.EGA.23 System shall allow user to save and print the acknowledgement for enquiry and grievance purposes

SYA.EGA.24 System shall allow user to track the status of the application request along with remarks to the user such as:

SYA.EGA.26 1. Pending confirmation

SYA.EGA.27 2. Application accepted

SYA.EGA.28 3. Application declined

SYA.EGA.29 User shall be able to print and save the notification for easy retrieval of information for future reference

SYA.EGA.30 System shall allow the user to rectify the error (in case of application declined) and re-submit the same application

SYA.EGA.31 System shall allow only authorized users to access the scanned supporting documentation and verify if they are correct

SYA.EGA.32 System shall allow the user to re- submit the application only after validating the authenticity of the user through challenges and response

SYA.EGA.33 System shall send an activation URL to the email id of the respective official responsible to accept the application

SYA.EGA.34 System shall send an automated escalation mail to the next level of authority in case the respective official does not attend the application URL within TAT

SYA.EGA.35 System shall allow only authorized users to access the scanned supporting documentation and verify if they are correct with other departments

SYA.EGA.36 System shall allow and accept the digital signature from respective officials for processing the application of grant aid for registered educational institutes

SYA.EGA.37 System shall allow the respective official to update the status of the application request as per proceedings along with the remarks

SYA.EGA.38 Any change to the application record shall generate a change log with details like name of the user making the changes, timestamp of transaction, etc.

SYA.EGA.39 System shall allow to intimate educational institutes through State portal to collect approval/rejection of grant aid manually or by post

SYA.EGA.40 System shall allow to upload the scanned/ PDF copy of final approval/rejection in state portal where educational institutes can take the print of it

SYA.EGA.41 System shall send delivery report to the respective official whenever the education institutes collect valid grant aid.



XI. All Departments in state of Goa


Generic Form

25. Recruitment form for non-gazette post of various Depts. across State

Requirement ID

Description

GEN.NGP.1 System shall allow concerned department authorized authority to select new requirement form available in e-District application for concerned department internal use from the home page of the concerned department web Portal

GEN.NGP 2 System shall allow concerned department authorized authority to select application form for recruitment of non- gazette post

GEN.NGP.3 System shall allow registration of concerned department authorized authority for future login and ease

GEN.NGP.4 System shall allow concerned department authorized authority to create/fill/edit e-Form/Application as required by department

GEN.NGP.5 System shall accept addition / updating /creation filled e-Form/application of concerned department authorized

GEN.NGP.6

System shall be able to capture concerned department authorized authorities details through an electronic form before giving authorized access/login for first time for the service such as:

1. Name 2. Contact Details 3. PIN 4. Age 5. Employee Id 6. Name of Department/ Section 7. Details as to be required in application form suggested by concerned

department 8. Approval from authorized senior authority official for service 9. Official E-mail id (if any)

10. Contact No. if any 11. Other documents/details required by department.

GEN.NGP.7 System shall require entries from the user for certain important information items entered twice. For example email id needs to be captured correctly if email is the preferred mode of communication

GEN.NGP.8 System shall provide adequate aid to the user in the form of online tutorials, "How To", FAQs, etc that can be used on their own to familiarize themselves with keying-in the registration data and the registration process

GEN.NGP.9 System shall allow the concerned department authorized authority to preview the registration

GEN.NGP.10 System shall apply spam control measures during registration to avoid spurious details being automatically submitted and ensure that data is not submitted by non-humans

GEN.NGP.11 System shall allow editing before submission



GEN.NGP.12

System shall allow upload: 7. Copy of department approval for service 8. Valid Employee Id. Proof with office & working section details 9. Other supporting documents if required (to be decided by concerned

official)

GEN.NGP.13 System shall perform data validation checks on the input. In case of data being duplicated, System shall display the existing service request id & existing record if any.

GEN.NGP.14 System shall allow save and print facility of the acknowledgement slip

GEN.NGP.15 Validations for file type that shall be allowed to be uploaded include only formats such as above. It shall not allow .executable files.

GEN.NGP.16 System shall allow to accept unique ID as proof of document which can be verified internally within concerned departments through SSDG interface

GEN.NGP.17

System shall allow authorized department official to help build, manage, simulate, change or create human to human workflows in a graphical manner by drag and drop without having to write program code. Just simply by dragging and dropping objects

GEN.NGP.18 System shall display the standard templates to be used with options to edit same as per requirement as authorized by senior authority

GEN.NGP.19 System shall as a part of application establish challenge and responses mechanisms for session validation for future online sessions.

GEN.NGP.20


GEN.NGP.21 System shall apply spam control measures during registration to avoid spurious details being automatically submitted and ensure that data is not submitted by non-humans

GEN.NGP.22

System shall allow the user to visit the secured fields setting up dates of enabling & disabling of accepting online applications & payment gateway in case of there is option to given for submitting fee through net banking, debit card or credit card using payment gateway

GEN.NGP.23

System shall display the all respective fields to be added such as Applicant name ,educational qualification communication address , etc as required and last date & time to apply and make payment in case the concerned department authorized authority selects the option to make new form or edit existing as required

GEN.NGP.24 System shall be able to provide unique 'Service Id Request' acknowledgement to the user along with notification message to concerned department officials for any access or work done on form application



GEN.NGP.25

System shall be able to capture the applicants details through an electronic form such as: 1. Name 2. Contact Details 3. PIN 4. Age 5. Gender 6. Permanent/Temporary Address 7. Educational qualification details 8. Details required in application form as per post requirement 9. E-mail id (if any) 10. Contact No. if any 11. Name of non-gazette post applied for:

GEN.NGP.26 System shall allow user to save and print the acknowledgement for further use if required

GEN.NGP.27

System shall allow user to track the status of the online received filled application for the concerned request for non-gazette post along with remarks to the applicant : a. Pending confirmation b. Application accepted c. Application declined

GEN.NGP.28 Applicant applying for non-gazette post shall be able to print and save the notification for easy retrieval of information for future reference

GEN.NGP.29

System shall allow department people to sort applications with predefined criteria updated in e-District application with using pre- existing selections options as per all required actions from adding/editing of a form till final selection of a candidate for the selected post

GEN.NGP.30 User shall be able to print and save the notification for easy retrieval of information for future reference

GEN.NGP.31 System shall allow the user to rectify the error (in case of application declined) and re-submit the same application

GEN.NGP.32 System shall allow only authorized users to access the scanned supporting documentation and verify if they are correct

GEN.NGP.33 System shall allow the user to re- submit the application only after validating the authenticity of the user through challenges and response

GEN.NGP.34 System shall send an activation URL to the email id of the respective authorized official responsible to accept/reject updating of the application

GEN.NGP.35 System shall allow department authorized user to generate Reports, MIS and

dashboards: to manage the services in a timely fashion without having to write extensive programs

GEN.NGP.36 System shall send an automated escalation mail to the next level of authority in case the respective official does not attend the application URL within TAT

GEN.NGP.37 System shall allow only authorized users to access the scanned supporting documentation and verify if they are correct with other concerned departments

GEN.NGP.38 System shall allow and accept the digital signature from respective officials for processing the application of recruitment form for non-gazette post



GEN.NGP.39 System shall allow the respective official to update the status of the application request as per proceedings along with the remarks

GEN.NGP.40 Any change to the application record shall generate a change log with details like name of the user making the changes, timestamp of transaction, etc.

GEN.NGP.41

System shall allow to update intimation on any such non-gazette position recruitment on State/department portal for citizens / applicants to apply for the same as soon as it gets approved and uploaded by department authorized officials with command to display/publish same on state/department portal or in any new papers

GEN.NGP.42 System shall allow to upload the scanned/ PDF copy of final filled copy application for non-gazette post in the State/department portal where concerned department authorized authority/ applicant can take the print of it

GEN.NGP.43 System shall send delivery report to the respective official whenever the concerned department authorized authority /applicants collects valid service requests or applications

GEN.NGP.44 System shall be able to maintain all records for the login sessions with date and time

GEN.NGP.45 System shall be PKI enabled to accept digital signatures for digitally signing documents for recruitment of non-gazetted post

GEN.NGP.46 System shall have a facility for forwarding of the application, with remarks and digital sign of the sender, to any person in District administration registered with System

GEN.NGP.47 System shall be able to provide date and time stamping for all transactions done with digital signature

GEN.NGP.48 System shall consider the list of holidays for tracking the timelines of various activities.

GEN.NGP.49 System shall support multilingual interface (minimum Konkani, Marathi and English as per Localization and Language Technology Standards for National e-Governance Plan defined in eDistrict guidelines

GEN.NGP.50 Recruitment for non-gazette post module of eDistrict application should be linked to general all service component appropriately as per department requirement –e.g. Information component, Form availability component etc.


Generic Form

26. Form for scheme management

Requirement ID

Description

GEN.FSM.1 System shall allow concerned department authorized authority to select new requirement form available in eDistrict application for concerned department internal use from the home page of the concerned department web Portal

GEN.NGP 2 System shall allow concerned department authorized authority to select form for scheme management

GEN.FSM.3 System shall allow registration of concerned department authorized authority for future login and ease

GEN.FSM.4 System shall allow concerned department authorized authority to



create/fill/edit e-Form/Application as required by department

GEN.FSM.5 System shall accept addition / updating /creation filled e-Form/application of concerned department authorized

GEN.FSM.6

System shall be able to capture concerned department authorized authorities details through an electronic form before giving authorized access/login for first time for the service such as:

1. Name 2. Contact Details 3. PIN 4. Age 5. Employee Id 6. Name of Department/ Section 7. Details as to be required in application form suggested by concerned

department 8. Approval from authorized senior authority official for service 9. Official E-mail id (if any) 10. Contact No. if any

GEN.FSM.7 System shall require entries from the user for certain important information items entered twice. For example email id needs to be captured correctly if email is the preferred mode of communication

GEN.FSM.8 System shall provide adequate aid to the user in the form of online tutorials, "How To", FAQs, etc. that can be used on their own to familiarize themselves with keying-in the registration data and the registration process

GEN.FSM.9 System shall allow the concerned department authorized authority to preview the registration

GEN.FSM.10 System shall apply spam control measures during registration to avoid spurious details being automatically submitted and ensure that data is not submitted by non-humans

GEN.FSM.11 System shall allow editing before submission

GEN.FSM.12

System shall allow upload: 1. Copy of department approval for service 2. Valid Employee Id. Proof with office & working section details 3. Other supporting documents if required (to be decided by concerned

official)

GEN.FSM.13 System shall perform data validation checks on the input. In case of data being duplicated, System shall display the existing service request id & existing record if any.

GEN.FSM.14 System shall allow save and print facility of the acknowledgement slip

GEN.FSM.15 Validations for file type that shall be allowed to be uploaded include only formats such as above. It shall not allow .executable files.

GEN.FSM.16 System shall allow to accept unique ID as proof of document which can be verified internally within concerned departments through SSDG interface

GEN.FSM.17 System shall display the standard templates to be used with options to edit same as per requirement as authorized by senior authority

GEN.FSM.18 System shall as a part of application establish challenge and responses mechanisms for session validation for future online sessions.



GEN.FSM.19


GEN.FSM.20 System shall apply spam control measures during registration to avoid spurious details being automatically submitted and ensure that data is not submitted by non-humans

GEN.FSM.21

System shall allow the user to visit the secured fields setting up dates of enabling & disabling of accepting online applications & payment gateway in case of there is option to given for submitting fee through net banking, debit card or credit card using payment gateway

GEN.FSM.22

System shall display the all respective fields to be added such as Applicant name , communication address , etc. as required and last date & time to apply for scheme and make payment in case the concerned department authorized authority selects the option to make new form or edit existing as required

GEN.FSM.23 System shall be able to provide unique 'Service Id Request' acknowledgement to the user along with notification message to concerned department officials for any access or work done on form application

GEN.FSM.24

System shall be able to capture the applicants details through an electronic form such as: Name Contact Details PIN Age Area of residence Name of scheme applied for Details as required in application form used at present E-mail id (if any) Contact No. if any

GEN.FSM.25 System shall allow user to save and print the acknowledgement for further use if required

GEN.FSM.26

System shall allow user to track the status of the online received filled application for the concerned request for non-gazette post along with remarks to the applicant : 1. Pending confirmation 2. Application accepted 3. Application declined

GEN.FSM.27 Applicant applying for scheme shall be able to print and save the notification for easy retrieval of information for future reference

GEN.FSM.28

System shall allow department people to sort applications with pre-defined criteria updated in eDistrict application with using pre-existing selections options as per all required actions from adding/editing of a form till final selection of a candidate for the selected post

GEN.FSM.29 System shall allow the respective official to update the status of the application request as per proceedings along with the remarks

GEN.FSM.30 User shall be able to print and save the notification for easy retrieval of information for future reference

GEN.FSM.31 System shall allow the user to rectify the error (in case of application declined)



and re-submit the same application

GEN.FSM.32 System shall allow only authorized users to access the scanned supporting documentation and verify if they are correct

GEN.FSM.33 System shall allow the user to re- submit the application only after validating the authenticity of the user through challenges and response

GEN.FSM.34 System shall send an activation URL to the email id of the respective authorized official responsible to accept/reject the application

GEN.FSM.35 System shall send an automated escalation mail to the next level of authority in case the respective official does not attend the application URL within TAT

GEN.FSM.36 System shall allow only authorized users to access the scanned supporting documentation and verify if they are correct with other concerned departments

GEN.FSM.37 System shall allow and accept the digital signature from respective officials for processing the application of recruitment form for non-gazette post

GEN.FSM.38 System shall allow the respective official to update the status of the application request as per proceedings along with the remarks

GEN.FSM.39 Any change to the application record shall generate a change log with details like name of the user making the changes, timestamp of transaction, etc.

GEN.FSM.40

System shall allow to update intimation on any such scheme on State/department portal for citizens / applicants to apply for the same as soon as it gets approved and uploaded by department authorized officials with command to display/publish same on state/department portal or in any new papers

GEN.FSM.41 System shall allow to upload the scanned/ PDF copy of final filled copy application for non-gazette post in the State/department portal where concerned department authorized authority/ applicant can take the print of it

GEN.FSM.42 For Any change to the application record system shall generate a change log with details like name of the user making the changes, timestamp of transaction, etc.

GEN.FSM.43

System shall allow the authorized user to credit/deposit money (if any) through the secured payment gateway in account of beneficiary in case department selects the option to make the payment through net banking/on-line transfer (if required)

GEN.FSM.44 System shall allow to upload the details of dispersed amount or report of scheme provided for the beneficiary/applicant on the state portal where citizen can take the print of it

GEN.FSM.45 System shall be PKI enabled to accept digital signatures for digital signing of the documents of scheme management.

GEN.FSM.46 System shall consider the list of holidays for tracking the timelines of various activities.

GEN.FSM.47 System shall support multilingual interface (minimum Konkani , Marathi and English) as per Localization and Language Technology Standards for National e-Governance Plan defined in eDistrict guidelines

GEN.FSM.48 Recruitment for non-gazette post module of eDistrict application should be linked to general all service component appropriately as per department requirement –e.g. Information component, Form availability component etc.

RFP for Selection of System Integrator for State-wide roll-out of eDistrict MMP in Goa – Volume II


On behalf

Of


Government of Goa


FOR


FOR

ROLL-OUT OF e-District MMP - GOA

VOLUME II





4th Floor, Above Alcon Hyundai Showroom,


RFP for Selection of System Integrator for State-wide Roll-out of eDistrict MMP in Goa – Volume II

State-wide rollout of the eDistrict MMP in Goa 2 | P a g e

Table of Contents

1 Introduction ........................................................................................................................................ 5

2 Implementation Framework ............................................................................................................. 6

3 Scope of the Project .......................................................................................................................... 10

3.1 Introduction ...................................................................................................................................... 10

4.1.1 State Specific Requirements ............................................................................................................. 11

I. Integration & Interfacing Requirement (Integration with NIC, portal and SSDG) ....................... 11

Responsibility Matrix ................................................................................................................................. 12

II. Customisation Requirement (Integration with NIC, portal and SSDG) ........................................ 13

III. Key Configuration Requirement (Integration with NIC, portal and SSDG) ................................ 13

IV. Additional Application Development ............................................................................................... 13

3.2 Solution & Technology Architecture ............................................................................................. 14

3.2.1 Overview ........................................................................................................................................... 14

3.2.2 eDistrict Application Structure ....................................................................................................... 15

3.3 Scope of Services – Project Implementation Phase ...................................................................... 17

3.3.1 Solution Design ................................................................................................................................. 17

3.3.2 Network Connectivity ..................................................................................................................... 46

3.3.3 Data Digitisation ............................................................................................................................... 47

3.3.4 Site Preparation ................................................................................................................................ 53

3.3.5 Supply / Procurement of IT Infrastructure at SDC ..................................................................... 54

3.3.6 Hardware Commissioning at Field Offices .................................................................................. 55

3.3.7 Migration to New Infrastructure Facility ...................................................................................... 56

3.3.8 Licenses .............................................................................................................................................. 57

3.3.9 Capacity Building / Training ......................................................................................................... 57

3.3.10 Manpower requirements ................................................................................................................. 60

3.3.11 Business Continuity Planning ........................................................................................................ 60

3.3.12 Others.. ............................................................................................................................................... 61

3.3.13 Project Management ........................................................................................................................ 65

3.4 Scope of Services - Operation and Maintenance Phase .............................................................. 67

3.4.1 Overview of Post Implementation Services ................................................................................. 67

3.4.2 Warranty Support ............................................................................................................................ 68

3.4.3 Technical Support (TS) .................................................................................................................... 69

3.4.4 Help Desk and Trouble ticket management system.................................................................... 70

3.5 General Requirements ..................................................................................................................... 72



3.6 Exit Management.............................................................................................................................. 74

4 Detailed Implementation and Roll-out Plan ................................................................................ 78

5 Annexures ......................................................................................................................................... 79

5.1 Template for Capturing Office Wise Requirements .................................................................... 79

5.2 Template for Capturing Network Connectivity Requirement .................................................. 82

5.3 Tentative Hardware Requirement ................................................................................................. 84

5.4 Template for Capturing Site Preparation Requirement (If Any) ............................................... 84

5.5 Template for Data Entry .................................................................................................................. 85

5.6 Template for Preparing FRS and Process Maps (with illustrative data) .................................. 92

Tracking Status of Marriage registration certificate .............................................................................. 95

5.7 Template for Bill of Material ......................................................................................................... 103

Form A: Bill of Material (Software at SDC)........................................................................................... 103

Form B: Bill of Material (Hardware at SDC) ......................................................................................... 103

Form C: Bill of Material (Infrastructure at Field Offices) .................................................................... 109

6 Annexure: ........................................................................................................................................ 127

6.1 List of existing Hardware components, SLA management tool and licences at SDC, Goa . 127

6.2 Non-Functional Requirements ..................................................................................................... 128



GLOSSARY OF TERMS

The definitions of various terms that have been used in this RFP are as follows:

“Request for Proposal (RFP)” means all three Volumes and its annexures and any other

documents provided along with this RFP or issued during the course of the selection of

bidder, seeking a set of solution(s), services(s), materials and/or any combination of them.

“Contract / Agreement / Contract Agreement / Master Service Agreement” means the

Agreement to be signed between the successful bidder and SDA, including all attachments,

appendices, all documents incorporated by reference thereto together with any subsequent

modifications, the RFP, the bid offer, the acceptance and all related correspondences,

clarifications, presentations.

“Bidder” means any firm offering the solution(s), service(s) and /or materials as required in

the RFP. The word bidder when used in the pre-award period shall be synonymous with

parties bidding against this RFP, and when used after award of the Contract shall mean the

successful party with whom the agreement is signed for rendering of services for

implementation of this project.

“Proposal / Bid” means the Pre-Qualification, Technical and Commercial bids including

clarifications, submitted for this project against this RFP.



1 Introduction

NeGP was approved by the Government of India in May 2006, with the following vision:

“Make all Government Services accessible to the common man in his locality, through

common service delivery outlets and ensure efficiency, transparency and reliability of such

services at affordable costs to realise the basic needs of the common man”

To realize this vision, 31 Central, State and Integrated Mission Mode projects (MMPs) along

with 8 support components were identified and approved under NeGP. States have been

given flexibility to identify up to 5 additional state-specific projects, which are particularly

relevant for the economic development of the State. NeGP also envisages creation of the core

IT infrastructure in the form of SWANs, SDCs and CSC‟s in rural areas across the country to

deliver public services electronically in local language.

eDistrict is one of the 31 MMPs under NeGP, with the Department of Information Technology

(DoIT), Government of India (GoI) as the nodal department, to be implemented by State

Government or their designated agencies. This MMP aims at electronic delivery of identified

high volume citizen centric services, at district and sub-district level, those are not part of any

other MMP. To achieve these objectives service levels and outcomes for each of these services

will be clearly laid down by the State concerned, with a view to improving the efficiency and

effectiveness of the service delivery. The MMP envisages leveraging and utilizing the four

pillars of e-infrastructure namely, State Data Centres (SDCs), State Wide Area Network

(SWANs), State Service Delivery Gateways (SSDGs) and Common Service Centres (CSCs),

optimally to deliver public services electronically to citizens at their door steps. Initially only

those high volume citizen-centric services will be taken up for implementation which have

high priority for the State. New services will be added to the portfolio subsequently, once the

demand for the initial set of e-enabled services increases.



2 Implementation Framework

I. eDistrict project shall be implemented in a way where the districts will play a major role.

eDistrict shall be implemented in alignment with the NeGP principle of “centralized

planning and decentralized implementation”. State IT Department/ Nodal Agency shall play

a key role in planning and implementation of the program in collaboration with the district.

II. The role of the DeitY, GoI focuses primarily in planning of national level roll out, issuing

guidelines, funding support to the states, monitor and support the state in implementation of

the project. States shall drive the implementation at the state/district level. The diagram

illustrating the key stakeholders and their role in implementation and for managing the

eDistrict MMP is shown below:

III. eDistrict MMP aims at electronic delivery of all public services at district / sub district level,

progressively. Initially 26 services of identified high volume citizen centric public services at

district and sub-district level will be taken up for implementation.

Services are classified into 3 basic categories:

Type 1 services are typically those services for which an accurate digital database is

available. For e.g. Land Records have been digitized and several land-related

services are now available across the counter. Similarly, once birth and death are

registered, stored in secured database and digitally signed; birth and death

certificate (bilingual) can be issued on demand across the counter.



Type 2 services are those services which can migrate to Type 1 services with due

data digitization and onetime physical verification. For e.g. Issue of Caste

Certificate. Till such time as the centralized, digitally signed databases are created,

Type 2 services are delivered within a pre-defined period, say 2 weeks.

Type 3 services require physical presence / verification and cannot be delivered

across the counter, like Issue of Arms Licenses.

Prioritization of Services shall be done on the basis of categories under which the Services

shall fall.

IV. An Integrated Service Delivery Framework has been designed by DeitY in July 2012, and

communicated to all the States. It can be accessed at (URL:

http://deity.gov.in/content/eDistrict-guidelines). This framework envisages a centralized

architecture for each major e-Governance application at the State level. The application

software will be hosted in the State Data Centre. Integration across States shall be enabled,

through mandatory adherence to technical specifications and e-Governance standards,

besides use of the SSDG. Compliance to latest Unicode standard (current version is 6.0) for

local language content/data encoding is also mandatory. The Integrated Framework shall be

treated as part of this RFP and shall be followed with appropriate modifications, required by

the State.

V. Two key aspects of the Scheme are Business Process Re-engineering (BPR) and creation of

databases based on e-Governance standards for the purposes of ensuring interoperability.

BPR is intended to enable process simplification and significant value addition to citizens.

VI. The solution architecture of the eDistrict project envisages a centralised application and

database and will leverage the core e-infrastructure of State Wide Area Network, State Data

Centre and State Service Delivery Gateway.

http://deity.gov.in/content/e-district-guidelines



ESO/CSCS – Extended Service Outlet are service delivery centres which are proposed to be

established in Goa at the Panchayats to provide various G2C and G2B services including

services included in the eDistrict Project.

CFC – Citizen Facilitation Centre are delivery centres which are established in Goa at

Collectorate offices to deliver services.

SDC - State Data Centre is the central Data centre of Goa which houses the infrastructure to

host eDistrict project.

e-Forms – Electronic Forms are forms which are available on Goa state portal for citizens to

apply for various services.

Payment Gateway – A payment gateway facilitates and performs variety of tasks between a

payment portal and eDistrict Project to process payment related transactions.

SSDG: SSDG (State e-Governance Services Delivery Gateway) is a messaging services

initiative taken by the Department of Information & Technology, Government of India at the

State level. At the central level it is referred to as the NSDG (National e-Governance Services

Delivery Gateway).

VII. SSDG is standard based Messaging and routing switch which provides seamless

interoperability and exchange of data across multiple government departments.

VIII. Further eDistrict service will be integrated with a mobile service delivery gateway and

Aadhaar numbers of the Unique Identification Authority of India. Localisation of the

application will be carried out as per the requirement of the state in terms of local language

and other needs. According to this, States selects System Integrator (bidder) who shall be

responsible to implement the project in the state as per the DeitY, GoI guidelines. Integration

of existing applications being used in the state shall not be possible unless the legacy data in

Service Delivery

ESO

ESO



the local language is compliant to Unicode version 6.0 or above. In some cases, this legacy

data therefore will need to be converted to Unicode 6.0 (or latest version).

The eDistrict MMP envisages centralised architecture at the state level with common

application software for each of the identified services for the 2 districts of the state. The

application software will be hosted in the SDC. In Goa however, 12 services developed and

managed by NIC will be hosted in NIC data centre which are part of the „DC Suite, Info-

Gram & Dharni. All the 26 services envisioned in the eDistrict will be accessed through a

state portal. All future services added to the eDistrict will be accessed through this portal.

Citizen accesses the services by directly going to the state portal which is available on the

internet or through CFC‟s/ESO/CSCS‟s. CFC‟s (Citizen Facilitation centres) are at

Collectorate and ESO/CSCS‟S (Extended service outlets) are at Panchayat level. In addition

they can also go directly to line departments and their sub-offices to avail these services.

IX. Integration shall be enabled, through mandatory adherence to technical specifications, e-

Governance and localisation standards. The detailed guidelines in this regard have been

issued by Department of Electronics and Information Technology (DeitY) Government of

India.



3 Scope of the Project

3.1 Introduction

The eDistrict MMP is to be implemented in State of Goa. The implementation of the scheme

will be completed in ONE year commencing from the date of award to the bidder and will be

followed by 3 years for software from date of Go live and 5 years for hardware (including

comprehensive warranty) .

South Goa

Note: Total No. of talukas: 6



North Goa

4.1.1 State Specific Requirements

I. Integration & Interfacing Requirement (Integration with NIC, portal and SSDG)

1. There are a total of 26 services considered as part of the initial eDistrict Goa initiative.

2. It is to be noted that 12 services out of 26 are available and managed by NIC. eDistrict

application should be integrated with application developed by NIC through SSDG

3. End to End applications need to be developed for 14 services .

4. SSDG acts like a switching gateway. Currently SSDG and State portal are maintained by a

single vendor. Integration is one of the key elements in the Goa eDistrict initiative.

5. Integration needs to be done from state portal to SSDG and then from SSDG to the

applications managed & developed by NIC and newly developed application (for 14

services).

6. Payment gateway and Mobile gateway also need to be connected through SSDG.

Integration and other responsibilities for bidder (eDistrict), bidder (SSDG) and NIC are tabulated

below:

Note: Total No. of talukas: 6



Responsibility Matrix

Sr. No Responsibility bidder

(eDistrict) bidder (SSDG) NIC

1. Service Development Ownership 14 of 26 Services NA 12 of 26 Services

2. State portal & SSDG Maintenance NA YES NA

3.

Development & deployment of connectors at both ends, i.e. from eDistrict services to SSDG and SSDG to backend applications

YES (in consultation & support with NIC & SSDG)

NA NA

4. Applications links on the state portal remain active and live at all times

NA YES NA

5. Payment Gateway Integration YES YES YES

6. Knowledge transfer to the eDistrict bidder regarding the technology of the SSDG layer being implemented

NA YES NA

7. Sharing of concept for mobile gateway connectors for SSDG services with eDistrict bidder

NA YES NA

8.

Design, development and maintenance of the e-Forms, using X-form based technology (configurable tool)

YES NA NA

9. Display of data for 12 NIC services NA NA YES

10. Testing for integration in conjunction with bidder (SSDG) and NIC

YES YES YES

11. Application enhancements of 12 services under NIC

NA NA YES

12. Maintenance of eDistrict servers hosted at SDC

YES NA NA

13. Maintenance of eDistrict servers hosted at NIC Data centre

NA NA YES (12 of 26

Services)

14.

Localization of the data is in the purview of eDistrict initiative complaint to Unicode Version 6.0 (in consultation with DeitY)

YES YES YES

15. Training /capacity building

Yes (Training to be conducted for e- District)

NA

Knowledge transfer for 12

services will be done to bidder

(eDistrict)

16. Procurement of digital signature for service delivery

Yes NA NA



17. Implementation of digital signatures

Yes (14 of 26 services)

NA Yes (12 of 26

services)

18. Development of Verification & Validation module of DSC

YES NA NA

19. Integration with eTaal YES NA NA

20. Single sign on (SSO) management NIC will enable single sign on for the services

YES Will enable single sign on services

NIC will enable single sign on for the 12 of 26

services

21. Status w.r.t to services provided to bidder eDistrict to be displayed in frontend

Yes (14 of 26 services),

updated by bidder eDistrict

in frontend

NA

Yes (12 of 26 services),

updated by NIC eDistrict in

frontend

22. Notify regarding the maximum transactions that can be executed on SSDG and gaps if any

NA YES NA

23. Handling of generic services posting done on the State portal

YES ( In consultation to

DoIT Nodal officers)

YES NA

24. UID/ Aadhaar integration


NA Yes (12 of 26

services)

25. FAQ/Manual related to the service on the portal.

Yes (26 services in consultation with SSDG and

NIC)

Provide support to enable it on the

portal.


Note: NIC developed & managed applications include DC suite, Taluka suite, Info-gram, Municipality Administrative Software & Dharni

II. Customisation Requirement (Integration with NIC, portal and SSDG)

Refer to above responsibility matrix

III. Key Configuration Requirement (Integration with NIC, portal and SSDG)

Refer to above responsibility matrix

IV. Additional Application Development

Sr.

No

Application Layer Description

1. UI layer Refer 4.3.2.2 –Point IV

2. Application layer Refer 4.3.2.2 –Point II

3. Business Process / Service Layer Refer 4.3.2.2 –Point V

4. Database layer Open Source & Portable Database Software



3.2 Solution & Technology Architecture

3.2.1 Overview

I. A centralized architecture (servers and processing at single and central location) has

been proposed for the e-District project. All requests from internal and external

users will be sent to this system, located in a central place for processing. All users

will access the application through local or remote terminals using a browser

(through internet for external users and through intranet for internal department

users).

II. The overall technology solution shall be based upon most relevant and suitable

architecture standards including standards for Service Oriented Architecture (SOA),

XML services & necessary protocols for internet applications, Data Centre

standards, Localization (Unicode, Inscript, etc.) standards, W3C (WCAG for

accessibility, etc.) standards & GIGW guidelines, etc. etc.

III. The design should include integration with existing IT infrastructure created under

SDC, GBBN, ESO/CSCS‟S & CFC‟S, State Portal, SSDG and any other MMP for the

implementation of e-District Project.

IV. e-District Application developed should be integrated with all the 5 mandated

modules as described by DietY [ the details should be updated in the FRS, SRS and

design by SI/bidder ]

V. Currently SDC is located at the DoIT office at Povorim, Bardez. Goa intends to take

up an alternate infrastructure facility to locate the current SDC. If the location and

site preparation for the new infrastructure facility is finalized during the course of

the implementation of e-District project, selected bidder shall be responsible for

server migration and related services to the new infrastructure facility.

VI. The indicative structure is as below :



3.2.2 e-District Application Structure



VII. In Goa, State Portal/SSDG has been developed. The e-District architecture should

be compatible with it and should get integrated with SSDG.

VIII. Centralized architecture is suggested for states so that in case the central servers,

storage, link or due to any reason go down despite building redundancy/high

availability capabilities. The selected bidder shall ensure an uptime of 99.95% for e-

District application on a quarterly basis.

IX. Bidders should clearly understand that the desire of the department is not to create

a mere IT Solution but an information infrastructure that will expand, integrate and

enhance the functional needs of the department concerned, citizens and other

stakeholders. It is in this spirit that the core design and functional requirements are

elaborated in the forthcoming sections.



X. The reference architectures provided in the Integrated Framework for Delivery of e-

Services (URL: http://deity.gov.in/content/e-District-guidelines) shall be necessarily

followed.

XI. The bidder shall be responsible for shifting all the e-District hardware from existing

SDC to New SDC that shall be made available in future course

3.3 Scope of Services – Project Implementation Phase

The Selected bidder (System Integrator) will implement the project by bundling the entire

scope of services. The Selected bidder shall roll out e-District first at South Goa and

subsequently in North Goa. Primarily scope of services will include:

The following will be the activities to be carried out by the selected Bidder:

1. Project Planning and Management

2. System Study and Design

3. Updating of Business Process Reengineering (To Be Process & FRS) for the

selected applications/ services

4. Development of e-District Application

5. Network Connectivity

6. Digitization of data in English and the local language

7. Site Preparation

8. Hardware Procurement & Commissioning

9. STQC Certification and C-DAC/TDIL Certification (for localization).

10. UAT & Go live

11. Capacity Building / Training

12. Operation & Maintenance (O&M) of e-District Application and SDC

13. Help Desk Support

3.3.1 Solution Design

4.3.2.1 System Study and Design

I. The FRS (High Level) developed by the SPMU (Consultant) and is available along with

this RFP. The selected bidder shall carry out a detailed systems study to prepare/ refine

the Functional Requirements Specifications and formulate the System and Software

Requirements Specifications documents incorporating the functional specifications and

standards provided by the DeitY, GoI and the DoIT requirements.

II. The selected bidder should prepare a detailed document on the implementation of e-

District Application with respect to configuration, customization, extension and

integration as per the requirement of State. The selected bidder shall also prepare a

change/reference document based on changes or deviations from the base version of

http://deity.gov.in/content/e-district-guidelines



the e-District Application with appropriate references to all the artefacts /documents

provided by DeitY, GoI / DoIT, Government of Goa.

III. As part of the System Study, the selected bidder shall be responsible for Preparation of

a comprehensive System Study document by studying the legislation, business

processes and organization design of the Goa.

IV. The selected bidder shall perform the detailed assessment of the functional

requirements and MIS requirements including localisation framework and prepare a

new FRS report, as part of the System Study document incorporating list of additional

features that shall result in further improvement in the overall application performance

for consideration of the SDA.

V. In case an existing pilot application is being customized / configured to meet the needs

of the state, the selected bidder will provide a comparative report as part of System

Study document, on the extent of functionality currently available in the pilot

application and the final FRS.

A. Requirements Traceability Matrix: The selected bidder shall ensure that developed e-

District application is fully compliant with the requirements and specifications

provided in the RFP such as functional, non-functional and technical requirements. For

ensuring this, the bidder shall prepare a Requirements Traceability Matrix on the basis

of Functional Requirements Specifications (FRS), Non Functional Requirements

Specification, and Technical Requirements provided by State (updated, expanded and

fine-tuned by the bidder).

B. Project Documentation: The selected bidder shall create and maintain all project

documents that shall be passed on to the State as deliverables as per the agreed project

timelines. The documents created by the selected bidder will be reviewed and

approved by the SPMU & Info Tech Corporation of Goa Ltd. (ITG).

Project documents include but are not limited to the following:

1. Detailed Project Plan

a. Detailed System Study Report

b. List of services, Service Definitions, Service Levels

c. Updated/vetted FRS

d. SRS document

e. HLD documents

2. e-District Application architecture documents.

3. ER diagrams and other data modelling documents.



4. Logical and physical database design.

5. Data dictionary and data definitions.

6. Application component design including component deployment views, control

flows, etc.

a. LLD documents

7. Application flows and logic.

8. GUI design (screen design, navigation, etc.).

a. All Test Plans

9. Requirements Traceability Matrix

10. Change Management and Capacity Building Plans.

11. SLA and Performance Monitoring Plan.

12. Design of real-time tools for monitoring e-Transaction volumes and for

generating real-time MIS

13. Training and Knowledge Transfer Plans.

14. Issue Logs.

The selected bidder shall submit a list of deliverables that they shall be based on the

methodology they propose. The selected bidder shall prepare the formats/templates for

each of the deliverables upfront based upon industry standards and the same will be

approved by Info Tech Corporation of Goa Ltd. (ITG) prior to its use for deliverables.

All project documents are to be kept up-to-date during the course of the project. The

selected bidder shall maintain a log of the internal review of all the deliverables

submitted. Soft copy of logs shall be submitted to State Nodal Officer on regular basis.

4.3.2.1.1 Preparation of Software Requirements Specifications (SRS)

As part of the preparation of SRS the selected bidder shall be responsible for preparing and

submitting detailed requirement specification documents as per IEEE or equivalent standards

which meets all the Business, Functional and Technical including localization requirements of the

departments concerned. The selected bidder shall prepare the SRS documents and have it

reviewed and approved by the Info Tech Corporation of Goa Ltd. (ITG). The State Nodal Agency

will sign off on the SRS documents on the advice of SPMU.

The indicative details to be incorporated in the SRS are:

System Overview

Domain Model

Use Case Requirements

Business Rules

Non-Functional Requirements

Interface Requirements

Data Conversion Requirements

Load Requirements



Development Efforts

The selected bidder is required to update the FRS / SRS as and when any enhancements /

modifications are made to the e-District application till the duration of the Contract

4.3.2.1.2 Preparation of e-District Project Plan

The selected bidder shall prepare a comprehensive e-District implementation and deployment

plan in consultation with Info Tech Corporation of Goa Ltd. (ITG). This implementation document

shall also comprise of

I. Current State Assessment Plan & Methodology

II. e-District Application Development Methodology

III. Provisioning of network connectivity both for GBBN and LAN where-ever

required.

IV. Site preparation, etc.

V. Data Digitization

VI. Procurement, Deployment and commissioning of required hardware and software

VII. Trainings to be provided to the departmental officials at different stages of the

project

VIII. Roll-out of e-District Application

IX. Handholding of officials to facilitate smooth transition from manual workflows to

automated workflows through e-District Application

Further, selected bidder will also prepare detailed work plan and estimate the timelines and

resources required for configuration, customization, extension, integration, and commissioning of

the e-District software as per the DeitY, GoI / State requirements. During the duration of the

contract bidder shall seek approvals from Info Tech Corporation of Goa Ltd. (ITG) on all the plans

and frameworks prepared by them.

4.3.2.1.3 Preparation of e-District Application Design

Detailed Design documents shall include:

I. Technical Architecture Document (Application, Network, and Security)

II. The available IT infrastructure available at state shall be a part of the document.

III. Gap infrastructure

IV. High Level and Low Level Design.

V. Database architecture, including defining data structure, data dictionary as per

requirements of data storage in English and the local language with compliance to

standards defined by DeitY, GoI/ Goa Government.

VI. Use Case Diagram

4.3.2.1.4 Sign off Deliverable/ Exit Criteria

I. Detailed Project Plan

II. Detailed System Study Report



III. Updated/vetted FRS

IV. SRS document

V. HLD documents

VI. e-District Application architecture documents.

VII. ER diagrams and other data modelling documents.

VIII. Logical and physical database design.

IX. Data dictionary and data definitions.

X. Application component design including component deployment views, control

flows, etc.

a) LLD documents (including but not limited to)

XI. Application flows and logic.

XII. GUI design (screen design, navigation, etc.).

a) All Test Plans ( including test case documents)

XIII. Requirements Traceability Matrix

XIV. Change Management and Capacity Building Plans.

XV. Design of real-time tools for monitoring e-Transaction volumes and for generating

real-time MIS

XVI. SLA and Performance Monitoring Plan.

XVII. Training and Knowledge Transfer Plans.

XVIII. Issue Logs.

4.3.2.1.5 Software development/Customization

e-District Application

ITG, Goa has decided to develop an integrated solution for e-District considering the scope

and requirements to be covered. The proposed solution should conform to the following

requirements:-

I. The application should be developed on a Service Oriented Architecture with

centralized databases

II. The application to be developed should support customization and configuration of

application modules as per service requirements.

III. The application to be developed should conform to inter-operability standards for e-

Governance applications, be multi-tenant and cloud ready.

IV. The application to be developed shall be integrated with State Portal and Legacy

application (12 services developed by NIC) using SSDG.

V. The application is certified from the localization perspective.

VI. Each service offered through the e-District application will have a hyperlink on the

state Portal. Each service should also have a FAQ/Manual related to the service on

the portal which should include details on eligibility, cost of availing the service,

documents required etc.



VII. UID integration and validation will be part of the application. This will be done in

consultation with NIC.

VIII. E-Forms should be available offline for Form-filling & submission with ability for

replication.

IX. The following points may be noted while designing the Application Architecture

a. It is absolutely essential to take the appropriate decision in consultation with the concerned line department of the State and Central Govt. as the case may be.

b. Despite the facility of borrowing the application, the spadework relating to creation of master data and of data digitization, training etc. rests with State, before the services can be launched.

X. The IPR of the application developed rests with the State Government.

4.3.2.2 e-District Functional Modules

e-District MMP aims at electronic delivery of all public services at district / sub district

level, progressively. Initially 26 services of identified high volume citizen centric public

services at district and sub-district level will be taken up for implementation. While doing

so, the four pillars of e-infrastructure i.e. GBBN, SDC, SSDG and CFCs/ ESO/CSCSs ( will

be leveraged ) and no new infrastructure would be created. Later on, new services could be

added depending on the requirements and the felt needs. It is to be noted that 12 services

out of 26 are available and managed by NIC. e-District application should be integrated

with application developed by NIC through SSDG by developing suitable web services.

Services are classified into 3 basic categories:

a. Type 1 services are typically those services for which an accurate digital database is available and data stored in secured database and digitally signed which can be issued on demand across the counter.

b. Type 2 services are those services which can migrate to Type 1 services with due data digitization and onetime physical verification. For e.g. issue of Caste Certificate. Till such time as the centralized, digitally signed databases are created, Type 2 services are delivered within a pre-defined period, say 2 weeks.

c. Type 3 services require physical presence / verification and cannot be delivered across counter, like issues of arm license.

Category of Service

Name of the Service

Type of Service

Department

End to End Development / Developed by

NIC

Integration to be done with NIC

application (Yes/ No)

Data Migration

from legacy

Application

(Yes/ No)

Certificates

1. Issuance of Income

certificate

Type 2

Collectorate Developed by

NIC Yes No

2. Issuance of Domicile certificate

Type 2



3. Issuance of Residence certificate

Type 2

4. Issuance of Divergence certificate

Type 2

5. Issuance of Caste/Com

munity certificate

Type 2

6. Issuance of

Matriz

certificate

Type 2

7. A) Issuance of

Birth/Death certificate

Type 2 Panchayat

Developed by

NIC Yes No

8. B) Issuance of

Birth/Death certificate

Type 2 Municipality Developed by

NIC Yes No

Linking with other

e-government projects

9. Issuance of Form I &

XIV

Type 3 Dir. of

Settlement & Land records

Developed by NIC

Yes No

Revenue Court

10. Revenue court cases-

Case listing/adjournment/stay

/ Final/Status

Type 3


NIC Yes No

License

11. Application/Renewal of

Arms License

Type 3


NIC Yes No

Subsidy/ Social Welfare

Schemes

12. Application and

Disbursement of Relief for

victims of Natural

Calamity

Type 3


NIC Yes No

Miscellaneous 13. Application

for Sound permission

Type 2 Collectorate

Developed by NIC

Yes No

RTI Services 14. RTI filling

and status services

Type 2 Goa state information commission

End to End Development

No No



and all other concerned

departments

Transport

15. Application for grant of subsidy for

Yellow/Black Motorcycle

,Auto Rickshaw,

Taxi Scheme 2003

Type 3

Transport Department


No No

16. Application for grant of subsidy for replacement

of buses/mini buses above 15 years old

Type 3

No No

Fisheries

17. Application for

Registration/ Renewal of Fishing Nets

Type 3

Fisheries Department


No No

Certificates

18. Registration of New

water sports activity

Type 2 Tourism

Department End to End

Development No No

19. Application for Marriage Registration

certificate

Type 3 Registration Department


No No

Certificates

20. Registration/Renewal of

Inland Vessel

Type 3

Captain of Ports


No

No 21. Registration

/Renewal of Water Sport

Vessel

Type 3

No

Certificates

22. Registration of Schools

for participation

in Games

Type 2

Department of Sports


No

No

23. Application for

Sportsmen certificate

Type 2

24. Registration/Application

Type 2



for entry into State Youth

Festival

25. Application for grant-in-

aid for various

Educational Institutes

Type 3

No No

Generic

26. Recruitment form for

non-gazette post of various

Depts. across State

Type 2

Generic Forms


No No

27. Form for Scheme

management

Type 2 No No

The application for e-District is the most critical component for e-District project. The Integrated

Service Delivery Framework released by DeitY shall be leveraged for developing the application

architecture for the State. The details on final reference architecture for the state have been

provided in this section in addition to generic requirements.

I. Design and development of the e-District Application as per the FRS and SRS

finalized by all stakeholders (SDA, State DoIT, SPMU, etc.).

II. e-District Application should ensure availability of all services, mandatory and

optional, in accordance with the BPR done by the SPMU and shall have the following

components

a. Develop the UI for processing of applications received in electronic form

b. All the forms will be initiated and integrated via State Portal and routed to

e-District Application through SSDG.

c. Development of a role based departmental workflow management system to

process the application received from the citizens. The said workflow shall

be a detailed one with focus on the specific requirements of departmental

processing.

d. Back end for the printing, status update and centralized MIS application.

e. Providing automatic acknowledgement with automated date and time

stamping to confirm acceptance of application in e-District Application and

share unique acknowledgement ID to applicant through State Portal.

f. Enabling tracking of the status of the application from any authorized office

through a unique application ID

III. Development of Role based, workflow driven Web based Content Management

System (CMS) for contribution of any type of Content to the e-District Application

including the metadata as specified in SRS.



IV. The user should be given a choice to interact with the system in Konkani & Marathi in

addition to English. The application should provision for uniform user experience

across the multi lingual functionality covering following aspects:

a. Front end web portal in Konkani, Marathi & English.

b. E-forms (Labels & Data entry in Marathi, Konkani, & English).Data entry

should be provided preferably using the Enhanced Inscript standard (based

on Unicode version 6.0 or later) keyboard layout with option for floating

keyboard.

c. Storage of entered data in English, Konkani & Marathi using UNICODE

(version 6.0 or later) encoding standard.

d. Retrieval & display in English, Konkani & Marathi across all user interfaces,

forms and reports with all browsers compliant with Unicode version 6.0 and

above.

e. Sakal Bharti font (compliant to UNICODE version 6.0) to be used for local

language data and content. Latest version of the font is available on

www.ildc.in

V. Application should have a generic workflow engine. This generic workflow engine

will allow easy creation of workflow for new services with minimum technical

programming support and thus enable the State government to create new services as

and when required by the various Departments without creating a change request. At

the minimum, the workflow engine should have the following features :

a. Feature to use the master data for the auto-populating the forms and

dropdowns specifically with reference to :

i. Name of District, Talukas, Blocks & Villages

ii. Designation of officials involved in the processing of the application

b. Creation of application form, by “drag & drop” feature using meta data

standards

c. Defining the workflow for the approval of the form, by providing various

options like :

i. First in First out

ii. Defining a citizen charter/delivery of service in a time bound manner

d. Creation of the “output” of the service, i.e. Certificate, Order etc.

e. Automatic reports

i. of compliance to citizen charter on delivery of services

ii. delay reports

VI. The application should have a module for management of digital signature including

issuance, renewal and suspension of digital signatures based on the administrative

decisions taken by the State. In case of any change (transfer, promotion, leave,

suspension, termination, superannuation etc.) of the officials under e-District Project,



a copy of order should be marked to the State Level digital signature management

team for assigning and revoking of the access rights.

VII. Using Digital signatures to authenticate existing databases: The e-District project

plans to use digitally signed databases and verification reports based upon field

visits. Hence, there needs to be a clearly defined mechanism to undertake cleaning of

existing databases and digitally signing the entire database to enable delivery of

across the counter services. It is also possible that the data in such digitally signed

databases would undergo periodic revision and updating. Hence, selected bidder in

consultation with ITG must provision for designing an appropriate set of tools for:

Digitally signing different databases used in different applications by

appropriate authorities,

Effecting changes in digitally signed documents

Tracking of database records which are digitally signed and which are not so

signed

Posting of appropriate notifications to the users in case of demand for

service in respect of which the relevant data record has not been digitally

signed by the competent authority

Verification of digital certificates (e.g. a website to authenticate a particular

certificate on the basis of certificate details or barcode)

Integration of Digital Signatures with e-District Application: The e-District

portal should be made accessible to government official users / registered

users over internet and to ESO/CSCS‟S & CFC‟S users through secure user

id and password. The biometric/digital signatures need to be integrated for

enabling authenticity of the approving authority.

VIII. Capacity Building and Institutional strengthening to manage Digital Signature:

As it is envisaged that the users of digital signatures will be significant in

numbers, the selected bidder in consultation with SDA should plan the

process and the agency for institutionalizing the management (issuance/

renewal/ revocation) of digital certificates.

Identification of Officials authorized for delivering services/ authenticating

the electronic records.

Designing policies and procedures for management of digital signatures.

Procurement of Digital Certificates for the authorized officials.

IX. Training on use of Digital Signatures:

As the e-District project would entail significant amount of field verification and relevant updating of records, digital signatures have to be used by various levels of officials. These officials may also keep on changing due to transfers/ superannuation, etc., hence the RFP should entail:

A one-time training to all the concerned officials in the usage of digital

signatures



As and when required training / on-demand web based training for the new

officials taking charge of e-District service provisioning.

X. Preparatory steps for digital signing of databases

a. Identification & planning

Identifying registers and data to be digitized

Fixing cut-off date for data digitization

Determining logistics of data digitization (whether at office level, district

level or State level)

Selecting database to be used for data digitization

Assessment of volume of data to be digitized for delivering the services

Codifying process for continuous verification and correction of the digitized

data

b. Plan to establishing ownership of digitized data with State Government

Fixing the ownership of the department and timeline for completion of

digitization

Instituting logical checks for checking the accuracy of data

c. Selection of Agencies for data digitization

Identification of appropriate organization for data digitization

d. Digitization of data (Data entry of existing records) and digitally signing

Digitization of data

Defining process for quality check of data and ownership transfer of data

Verifying and correcting the digitized data

Porting of the digitized data to State Data Centre (SDC) and making it

available for e-District and other MMPs.

Application for bulk data signing

Digitally signing of the digitized data by the authorized official

e. Ensuring dynamic updating of data during processing of each service request

Process for continuous addition, verification and correction of the digitized

data - Service / Solution workflow should ensure dynamic updating of data.

XI. Asset Management:: There is a requirement to have an asset management module

to be implemented under e-District project, to monitor the assets used for e-District

project at various offices.

XII. e-Transaction & SLA Monitoring Tools

(1) The Info Tech Corporation of Goa Ltd. (ITG) should be able to measure and monitor

the performance of the deployed infrastructure at SDC and at Department offices

and all SLAs set out in this RFP. More importantly, the SDA should be able to

monitor in REALTIME, the number of citizens touched through e-Services each day,

month and year, through appropriate tools and MIS reports.



(2) The Enterprise Monitoring System available at SDC may be used by the bidder to

monitor the infrastructure hosted at the SDC. The details of the SDC will be

provided to the bidder.

(3) For monitoring of uptime and performance of infrastructure deployed at

Department Offices, the selected bidder shall have to provision for monitoring and

measurement tools, licenses, etc. required for this purpose.

X. e-District application should have roadmap to integrate with key initiatives of DeitY

namely Portal Services, Citizen Contact Centre, Mobile Platform/ Gateway Services /

State Service Delivery Gateway (SSDG), e-Taal [ for transactions monitoring ] ,

National Service Directory, Payment Gateway, Language Switch, Open Data, E-

authentication including Aadhaar, Geographical Information System/ Global

Positioning System, E-Gov. Application Store, Document Repository, Certifying

Authority etc.

XI. Complete mobile enablement of the e-District applications and services including all

appropriate channels such as SMS / USSD / IVRS and development of corresponding

mobile applications to the e-District applications and services leveraging the Mobile

Service Delivery Gateway (MSDG) and the Mobile App Store developed by DeitY

XII. The status delivery should be through email if appropriate email available.

XIII. Operation and Maintenance of e-District Application including the suggested changes

as for 3 years from the date of Go-Live.

XIV. The bidder is expected to handover the well documented source code to ITG as and

when demanded by ITG, and after project GO LIVE and at the end of the project

operation and maintenance state . ITG shall verify the authenticity of this source code.

XV. Implement / add any additional forms of State Departments as and when the

departments are ready for delivering.

XVI. The IPR and the Source Code of this e-District Application shall be with the State

Government.

XVII. The bidder shall indicate the type of services to be made available using IVRS, SMS,

and Helpdesk.

XVIII. Detailed User and Operational Manual to be provided to each department, whose

services will be hosted on e-District Application.

XIX. The application should have a web interface and should publish online transaction

volume data for each service for each district & ESO/CSCS‟S & CFC‟S.

XX. Bidder can outsource work of data digitization & site preparation only.

Bidder shall develop following modules for delivery of identified service under e-District project.

I. Workflow Module:

Application should have a detailed workflow engine to cater to the complex workflow

requirements including cross departmental workflows also. This workflow engine will



allow easy creation of workflow for new services with minimum technical

programming support and thus enable the State government to create new services as

and when required by the various Departments without creating a change request. At

the minimum, the workflow engine should have the following features:

1. Feature to use the master data for the auto-populating the forms and dropdowns

specifically with reference to :

a. Name of District, Talukas & Villages

b. Office and officer in receipt of the application based on user location

c. Designation of officials involved in the processing of the application

d. Any other details for which a database is already available with the

department or database created by digitization of physical records.

2. Creation of application form, by “drag & drop” feature using meta-data standards

3. Defining the workflow for the approval of the form, by providing various options

like:

a. First in First out

b. Defining a citizen charter/delivery of service in a time bound manner

c. Creation of the “output” of the service, i.e. Certificate, Order etc.

d. Automatic reports of compliance to citizen charter on delivery of services

delay reports

II. MIS Reports

III. Transaction Report & Accounting module:

1. The e-District services are proposed to be delivered through Online State Portal,

ESO/CSCSs, CFCs or any other physical delivery outlet.

2. The proposed module shall account for managing count of

transactions/application made through each individual source along with

varied options to generate reports:

a. Service-wise

b. District/Taluka/Village-wise

c. Physical Delivery Outlet-wise (ESO/CSCSs/CFCs)

d. Any other as may be required

3. The said module should also account for managing the payment receipts with

respect to each of the individual physical delivery centres and reconciliation of

same with the respective department

4. Given requirement of revenue sharing the said module should also account for

calculating the revenue share between Government and Service Delivery Outlet

Operator as per prescribed rates which may be subject to modification on

regular intervals.

IV. Digital Signature Management Module

1. The application should have a module for management of digital signature

where in all the processes related to issuance, renewal and suspension of digital



signatures based on the administrative decisions taken by the State are

monitored.

2. All the new requisitions for digital signature shall be routed through this

module.

3. In case of any change (transfer, promotion, leave, suspension, termination,

superannuation etc.) of the officials under e-District Project, a copy of order

should be marked to the State Level digital signature management team for

assigning and revoking of the access rights.

4. Using Digital signatures to authenticate existing databases: The e-District project

plans to use digitally signed databases and verification reports based upon field

visits. Hence, there needs to be a clearly defined mechanism to undertake

cleaning of existing databases and digitally signing the entire database to enable

delivery of across the counter services. It is also possible that the data in such

digitally signed databases would undergo periodic revision and updating.

Hence, the software module should also provision for:

a. digitally signing different databases used in different applications by

appropriate authorities,

b. effecting changes in digitally signed documents,

c. tracking of database records which are digitally signed and which are

not signed

d. posting of appropriate notifications to the users in case of demand for

service in respect of which the relevant data record has not been digitally

signed by the competent authority

e. verification of digital certificates (e.g. a website to authenticate a

particular certificate on the basis of certificate details)

5. Integration of Digital Signatures with e-District Application:

The digital signatures shall be used to enable the authenticity of approving

authority as well as digitally signing of documents approved and databases

generated through the e-District Application.

V. Management System for Digitized Databases and Documents

1. The application should have a module for management of digitized databases and

documents which have been validated for its authenticity and accuracy by

authorized officials.

2. It should account for details of the data being digitized, details of authorizing

authority, tracking of any changes/Updating being made to the digitized data and

documents.

3. Appropriate indexing mechanism for effectively retrieving and managing the same.

VI. User and Role Management System: The permissions to perform certain operations

are assigned to specific roles. Members or other system users are assigned particular

roles, and through those role assignments acquire the permissions to perform particular

system functions. Since users are not assigned permissions directly, but only acquire

them through their role (or roles), management of individual user rights becomes a



matter of simply assigning appropriate roles to the user's account; this simplifies

common operations, such as adding a user, or changing a user's department.

Three primary rules are:

Role assignment: A subject can exercise permission only if the subject has selected

or been assigned a role.

Role authorization: A subject's active role must be authorized for the subject. With

above rule, this rule ensures that users can take on only roles for which they are

authorized.

Permission authorization: A subject can exercise permission only if the permission

is authorized for the subject's active role. With above rule this rule ensures that

users can exercise only permissions for which they are authorized.

Additional constraints may be applied as well, and roles can be combined in a

hierarchy where higher-level roles subsume permissions owned by sub-roles.

VII. Service Delivery Centre Management Module:

This module shall account to register all the service delivery centres i.e. CFC and

ESO/CSCS and any other service delivery outlets. It shall keep a track of the services

being delivered across departments through these centres. All MIS reports and

accounting of fees being charged from the citizens

VIII. Queuing System for Service Delivery Centres

This module shall account for a system generated token number based on FIFO to the

citizens at highly crowded centres to facilitate service delivery to the citizens. It shall

also provide MIS reports defining average waiting time per citizen, average time to

service one request etc.

IX. Data Export & Import Facility to heterogeneous platforms

The bidder shall have to develop a data interchange utility for heterogeneous platforms

which shall enable the administrator exchange data on request of specific departments.

X. Printed Stationary Management & Docket Management Module

This module shall account for the inventory of pre-printed stationary at each of the

service delivery centre. It shall also provide for an option for raising demand for

additional stationary and payments if any for the same.

XI. Citizen Document Repository: The bidder would need to create an application

that will act as a repository for all the documents uploaded by the citizen while

applying for any services on the state portal.

It will have the following properties:

1) The document repository application will be a module of e-District

application.

http://en.wikipedia.org/wiki/Hierarchy



2) It will be built on SOA architecture and present all its services via SSDG.

Any existing or future applications including e-District application may

utilize the dr.

3) Document Repository needs to be integrated with the state portal using

SSDG to provide the following services:

a. Automatic saving of all documents uploaded by the citizen in the

Document Repository.

b. While applying for any services, the citizen should be able to retrieve a

list of all documents uploaded by him before and select the ones required

for application

4) The bidder would need to create a comprehensive analysis and

documentation as follows:

a. Standardization of all certificates, etc. issued by any the department that

decided to use the Document Repository.

b. Mapping of specific documents as inputs to a service/outputs to a

service.

c. Metadata definitions that is required for the Document Repository to

function. Standards defined by deity should be followed strictly.

XII. Certificate Repository

All the certificates issued through e-District Application shall be stored in a centralized

certificate repository which shall than be used by various departments/services as

authentic source to validate information provided by the citizen when availing other

services. This repository shall facilitate Across the Counter Service Delivery for the

citizen.

XIII. Asset Management Module

1. The proposed module shall have the provision to manage all the information

related to all the assets including hardware, software, data – digitized content,

documents, and people both internal and external.

2. The said module will be managed at the District level by DeGS/ e-District

Project Manager and account for monitoring of the assets used for e-District

project at various offices and procured under various Schemes.

XIV. e-Transaction & SLA Monitoring Tools

1. ITG should be able to measure and monitor the performance of the deployed

infrastructure at SDC and at Department offices and all SLAs set out in this RFP.

More importantly, ITG should be able to monitor in REALTIME, the number of

citizens touched through e-Services each day, month and year, through

appropriate tools and MIS reports.

2. The bidder is expected to use Enterprise Monitoring System (EMS) deployed at

SDC for e-District Project.



3. For monitoring of uptime and performance of infrastructure deployed at

Department Offices, the selected bidder shall have to provision for monitoring

and measurement tools, licenses, etc. required for this purpose.

4. The application should have a web interface and should publish online

transaction volume data for each service for each district & ESO/CSCS‟S &

CFC‟S.

5. Applications of all 26 services provided under e-District should be integrated

with the e-taal portal for central monitoring by Diety

XV. It is also further envisaged that the e-District application to be deployed should have

roadmap to integrate with key initiatives of DeitY namely Portal Services, Citizen

Contact Centre, Mobile Platform/ Gateway Services / State Service Delivery Gateway

(SSDG), National Service Directory, Payment Gateway, Language Switch, Open Data,

E-authentication including Aadhaar, Geographical Information System/ Global

Positioning System, E-Gov. Application Store, Document Repository, Certifying

Authority etc.

XVI. Complete mobile enablement of the e-District applications and services including all

appropriate channels such as SMS / USSD / IVRS and development of corresponding

mobile applications to the e-District applications and services leveraging the Mobile

Service Delivery Gateway (MSDG) and the Mobile App Store developed by DeitY

XVII. Operation and Maintenance of e-District Application including the suggested changes

as indicated by the states for 3 years for software from date of Go live and 5 years for

hardware from date of installation

XVIII. Implement / add any additional forms of State Departments as and when the

departments are ready for delivering.

XIX. The IPR and the Source Code of the e-District Application shall be with the State

Government.

XX. The bidder shall indicate the type of services to be made available using IVRS, SMS,

and Helpdesk.

XXI. Detailed User and Operational Manual to be provided to each department, whose

services will be hosted on e-District Application.

XXII. The application should have a web interface and should publish online transaction

volume data for each service for each district & ESO/CSCS‟S & CFC‟S.

Offline Service Capabilities:

XXIII. It is suggested that offline server capabilities on one Counter at each Block/Taluka

should be built and used judiciously so that during failures, the services can be

provided to citizens from here.

XXIV. When the services at SDC get resumed, the work done at offline server machine should

be synchronized with central servers immediately and the offline server machines start

functioning under the control of central server.



XXV. As long as the services are running from state data centre, the offline server machine

will not function independently; these will run under control of state servers like any

other browser based client.

4.2.2.2 Single-Sign On

The application should enable single-sign-on so that any user once authenticated and authorized

by system is not required to be re-authorized for completing any of the services in the same

session. These services would be both developed by bidder e-District and that developed by NIC.

For employees of the department concerned, the browser based application accessed on the

intranet, through single-sign-on mechanism, will provide access to all the services of the

departments concerned (based on their roles and responsibilities), Help module, basic and

advanced reporting etc. Similarly, for external users (citizens, etc.), based on their profile and

registration, the system shall enable single-sign on facility to apply for various services, make

payments, submit queries /complaints and check status of their applications. LDAP could be used

to achieve Single Sign On which allows a user to access multiple applications after logging in once.

4.2.2.3 Support for PKI based Authentication and Authorization

The solution shall support PKI based Authentication and Authorization, in accordance with IT Act

2000, using the Digital Certificates issued by the Certifying Authorities (CA) such as MTNL or

NIC. In particular, 3 factor authentications (login id & password, biometric and digital signature)

shall be implemented by the selected Bidder for officials/employees involved in processing citizen

services as per the Functional requirement specification of the e-District services.

4.2.2.4 Interoperability Standards

Keeping in view the evolving needs of interoperability, especially the possibility that the solution

shall become the focal point of delivery of services, and may also involve cross-functionality with

the e-Government projects of other departments/businesses in future, the solution should be built

on Open Standards. The bidder shall ensure that the application developed is easily integrated

with the existing applications.

Every care shall be taken to ensure that the code does not build a dependency on any proprietary

software, particularly, through the use of proprietary „stored procedures‟ belonging to a specific

database product.

4.2.2.5 Scalability

One of the fundamental requirements of the proposed application is its scalability. The architecture

should be proven to be scalable (cater to increasing load of internal and external users and their

transactions) and capable of delivering high performance for at-least four years from the date of

deployment. In this context, it is required that the application and deployment architecture should



provide for Scale-Up and Scale out on the Application and Web Servers, Database Servers and all

other solution components.

4.2.2.6 Security

The systems implemented for project should be highly secure, considering that it is intended to

handle sensitive data relating to the citizens of the state. The overarching security considerations

are described below.

I. The security services used to protect the solution shall include: Identification,

Authentication, Access Control, Administration and Audit and support for industry

standard protocols.

II. The solution shall support advanced user authentication mechanisms including digital

certificates and biometric authentication.

III. Security design should provide for a well-designed identity management system,

security of physical and digital assets, data and network security, backup and recovery

and disaster recovery system.

IV. The solution should provide for maintaining an audit trail of all the transactions and

should also ensure the non-repudiation of audit trail without impacting the overall

performance of the system.

V. The overarching requirement is the need to comply with ISO 27001 standards of

security.

VI. The application design and development should comply with OWASP top 10 principles

4.2.2.7 Application Architecture

I. It has been proposed that the applications designed and developed for the departments

concerned must follow some best practice and industry standards. In order to achieve

the high level of stability and robustness of the application, the system development life

cycle must be carried out using the industry standard best practices and adopting the

security constraints for access and control rights. The various modules / application

should have a common Exception Manager to handle any kind of exception arising due

to internal/ external factors.

II. Similarly the modules of the application are to be supported by the Session and

Transaction Manager for the completeness of the request and response of the client

request. The system should have a module exclusively to record the activities/ create

the log of activities happening within the system / application to avoid any kind of

irregularities within the system by any User / Application.

4.2.2.8 Proposed Application Architecture

A centralized architecture (servers and processing at single and central location) has

been proposed for the e-District project. All requests from internal and external users



will be sent to this system, located at SDC. All users will access the application through

local or remote terminals using a browser (through internet for external users and

through intranet).

The overall technology solution shall be based upon most relevant and suitable

architecture standards including standards for Service Oriented Architecture (SOA),

XML services & necessary protocols for internet applications, Data Centre standards etc.

and it should be compliant to Central & State IT policy, Cert-In and e-Gov standards.

The design should include integration with existing IT infrastructure created under

SDC, GBBN, ESO/CSCS‟S & CFC‟S, State Portal, SSDG and any other MMP for the

implementation of e-District Project. e-District Application developed should be

integrated with State Portal and SSDG. Requirement for these should be included in the

FRS, SRS and Design. Though selected citizen services are being provided by various

department of GoG and further these departments have been working in silo, but State

has envisaged providing single interface through a Service Oriented Architecture (SOA)

to simplify the complexity and reduce associated costs.

An indicative 3-tier architecture (also referred to as multi-tier or N-tier architecture) has

been proposed for the Application Solution.

The entire processing should take place in N-tier architecture:

Front-end software (client tier) - responsible for the presentation of information

This Web portal – Goa state portal has already been implemented and is

managed by bidder (SSDG). All services developed under the e-District solution

will be hosted on the state portal. It will be in the scope of work of bidder to

integrate services developed under the e-District solution from state portal to

SSDG.

Business Process / Service Layer - In the long SSDG may be used, as specified in

the Integrated Framework for delivery of Services for the e-District MMP.

Application Layer - The Business logic for all the services pertaining to e-District

application should be strictly part of the application layer.[Business object

framework]

Database Layer – Database for the services developed by bidder will be hosted in

SDC and the database for services managed by NIC will be hosted at NIC‟s own

data centre.

The proposed application will use components for security, operational management,

and communication to authorize users to perform certain tasks, and to communicate

with other services and applications. The application should have integration with SMS

Gateway for status reporting/tracking and other queries of the citizens. SMS Gateway

will be utilized by the government departments for sending service delivery related

status updates to the citizens.

4.2.2.9 High Level Design (HLD)



Once the SRS are approved, the bidder shall complete the High Level Designing and all HLD

documents of all the functionalities, integration with existing application and external application.

The bidder shall prepare the HLD and have it reviewed and approved by the DoIT, Goa. DoIT,

Goa will sign off on the HLD documents based on the advice of SPMU.

4.2.2.10 Detailed (Low Level) Design (LLD)

The LLD shall interpret the approved HLD to help application development and shall include

detailed service descriptions and specifications, application logic (including “pseudo code”) and

UI design (screen design and navigation). The preparation of test cases will also be completed

during this stage. The bidder shall have the design documents reviewed and approved by the state

IT. ITG and DoIT will sign off on the LLD documents based on the advice of SPMU.

4.2.2.11 Test Plan

Once the SRS is approved and design is started, the bidder 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 DoIT.

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

bidder shall also carryout Load/ Stress testing. The bidder will submit the test plans, test cases

and test result reports to the DoIT for comprehensive verification and approval.

4.2.2.12 Requirement on Adherence to Standards

e-District application must be designed following open standards, to the extent feasible and in line

with overall system requirements set out in this RFP, in order to provide for good inter-operability

with multiple platforms and avoid any technology or technology provider lock-in.

4.2.2.13 Compliance with Industry Standards

In addition to above, the proposed solution has to be based on and compliant with industry

standards (their latest versions as on date) wherever applicable. This will apply to all the aspects of

solution including but not limited to design, development, security, installation, and testing. There

are many standards that are summarised below. However the list below is just for reference and is

not to be treated as exhaustive.

I. Portal development W3C specifications

II. Information access/transfer protocols SOAP, HTTP/HTTPS

III. e-District ,DeitY, GoI guidelines.

IV. Photograph JPEG (minimum resolution of 640 x 480 pixels)

V. Scanned documents TIFF (Resolution of 600 X 600 dpi)

VI. Biometric framework Bio API 2.0 (ISO/IEC 19784-1:2005)

VII. Latest HTML standards



VIII. Technical Standards for Interoperability Framework for e-Governance (IFEG) in India

Version 1.0 and any other relevant egov standards

IX. Egovstandards (http://egovstandards.gov.in/)

X. Guidelines for Indian Government Websites (http://web.guidelines.gov.in/#&panel1-

2)

4.2.2.14 Specification

I. Finger print scanning IAFIS specifications

II. Digital signature RSA standards

III. Document encryption PKCS specifications

IV. Information Security to be ISO 27001 compliant

V. Operational integrity & security management to be ISO 17799 compliant

VI. IT Infrastructure management ITIL / EITM specifications

VII. Service Management ISO 20000 specifications

VIII. Project Documentation IEEE/ISO specifications for documentation

IX. The bidder shall adhere to all the standards published by the Department of Electronics

and Information Technology, Government of India.

4.2.2.15 Sign-off Deliverables / Exit Criteria

I. System Requirement Specification (SRS)

II. Functional Requirement Specification (FRS) (if, updated)

III. High Level and Low Level Design

IV. Functional and non-functional testing

V. Fully functional e-District Application

VI. User and Operational Manual for e-District Application

VII. Final Source Code

VIII. Data Dictionary

IX. Test Cases

X. Test Plans

4.3.2.3 Obtain STQC and C-DAC/ TDIL (for localization) Certification for e-District Application

The bidder will be responsible for engaging STQC and C-DAC/ TDIL (for localization) to conduct

the assessment / review for the system before “Go Live”. The SPMU shall have the right to audit

and inspect all the procedures and systems relating to the provisioning of the services. If there is

any change / addition in the application‟s functionality then the bidder will have to obtain the

STQC Certification for the changes / additions. (As per Advisory for STQC Certification of

Application for e-District Pilot/ National Rollout Scheme prepared by DeitY)

[For reference on STQC Testing procedures, a Standard Operating (SoP)) has been published by

STQC, DietY. on 5th July]

http://egovstandards.gov.in/



C-DAC/TDIL testing shall include functionality w.r.t. user interface, input/output, storage and

printing of local language data and compliance to localization standards.

Bidder shall ensure the following points are duly addressed for successful completion of STQC

Certification:

I. Successful completion of Application Audit. Application audit will include:

A. Functionality audit that will map the functionality delivered to the FRS agreed upon

during development phase.

B. Identify the nature and type of transactions being processed by the application

systems.

C. Determine systematic measures implemented to control and secure access to the

application programs and data including password controls, user authentications,

roles and responsibilities, audit trails and reporting, configuration and interface

controls, etc.

D. Review of database structure including:

1. Classification of data in terms of sensitivity & levels of access

2. Security measures over database installation, password policies and

user roles and privileges

3. Access control on database objects – tables, views, triggers,

synonyms, etc.

4. Database restoration and recoverability

5. Audit trails configuration and monitoring process

6. Network connections to database

E. Review of Network and Website will include:

1. Penetration and vulnerability testing

2. Security exposures to internal and external stakeholders

F. Definition and Implementation of Security Policies and Controls will include:

1. Define and implement backup process, including schedule, storage,

archival and decommissioning of media

2. Define physical access controls review (over DC and other critical

area)

3. Define IT Change Management process, Incident Management

process – covering identification, response, escalation mechanisms

4. Define and implement Anti-virus (malware) controls – patching,

virus definition file update

4.3.3.2.1 Sign-off Deliverables / Exit Criteria

I. Sign off from Info Tech Corporation of Goa Ltd. (ITG).

II. STQC and C-DAC/ TDIL (for localization) Certification



4.3.2.4 Alignment with Integrated Framework

The e-District application should integrate with SSDG and provide access to citizens for e-District

services through State Portal. It is envisaged that over a period of time all the existing state

applications which have their own independent database and workflow and are identical to e-

District should be made available on State Portal through the SSDG.

The key functionalities required are as follows.

• The SAP and SP Connectors will need to connect the e-District Business Layer. This would

help in routing requests and responses to back-end departments within a stipulated time

period.

• Design and implement an accounting module to keep track of all the transactions service

category wise, department wise and break down of transactions SCA, VLE, DeGS wise.

• MIS of number of transactions including name of service and category of service on time and

geographical scale should be published on e-District portal.

• Use e-authentication (including Aadhaar for citizens), e-payment, Digital signature and

Mobile gateway.



• The bidder is expected to coordinate with the agencies like CDAC for localization and

requirement of connectors.

4.3.3.3.1 SSDG

I. The Integrated Service Delivery Framework envisages centralized architecture for each MMP

at the State level. The application software will be hosted in the State Data Centre. Integration

across States shall be enabled, through mandatory adherence to technical specifications and e

Governance standards.

II. The solution architecture of the e-District project envisages a centralised application and

database and will leverage the core e-infrastructure of State Wide Area Network, State Data

Centre and State Service Delivery Gateway.

III. The e-District MMP envisages centralized architecture at the state level with common

application software for each of the identified services for all the districts of the state. The

application software will be hosted in the SDC.

IV. Integration across states shall be enabled, through mandatory adherence to technical

specifications and e Governance standards. The detailed guidelines in this regard will be

issued by Department of Electronics and Information Technology (DeitY) Government of

India separately.

SSDG Architecture



4.3.3.3.2 Payment and SMS Gateway

V. Provisioning of a payment gateway, SMS gateway and any other components required to

meet the functional and Quality-of-Service requirements of the RFP is also within the scope

of work of the bidder.

VI. Payment Gateway should allow net banking and debit card payments through at least 20

banks in the country (including all leading banks), besides payments through credit cards

(VISA, MasterCard).

VII. Any one-time charges such as those for tie-ups, development of interfaces, registration,

commissioning etc. of the gateway and any fixed recurring charges such as monthly rentals,

etc. will have to be borne by the selected bidder for the Contract period and may be budgeted

for in the Total Contract Value of this Project.

VIII. Any applicable transaction charges for making electronic payments or using SMS based

services shall however be payable by the citizen and SDA respectively and need not be

accounted for in the Total Contract value of this Project. Any transaction charges should be

payable in Indian Rupees only.

IX. The contracts that the selected bidder does with the Payment Gateway provider and SMS

gateway provider should be structured in a manner to allow the transaction charges to be

paid directly by the citizen / SDA. However if the contract with payment gateway / SMS

gateway provider require any transactional charges to be paid by the selected bidder , the

same will be reimbursed to the bidder by the SDA every month on an actual basis. The

systems deployed by the bidder should be able to provide logs of the transactions done and

charges paid. The SDA will however reserve the right to negotiate and examine the rate

contracts of the selected bidder with the gateway providers.

X. Payment gateway should enable receipt of all payments such as Tax, interest, penalty, arrear

and fee etc. and crediting the same to the SDA/ Department account. The payment gateway

should also allow credit of any refund amount to Kiosk/ESO/CSCS‟S & CFC‟S‟s account. It

should be possible to make electronic payments through a 3G / GPRS enabled mobile phone

as well.

4.3.3.4 Application Support for Existing Services

The selected bidder is required to provide minimum 15 resource persons as mentioned below for

the same:

Sr. No Position Number of Resources

1 Project Manager 1

2 System/ Network Administrator 1

3 Solution Architect 1

4 Database Administrator 1

5 Software Programmer and Business Analyst 7

6 District Manager 1

7 District Technical Support 1



8 Helpdesk Executive 2

An indicative list of activities to be performed by the deployed resources for existing system support is:

I. Project Manager shall be the Source point of contact (SPoC ) to the SDA/SPMU/

Department for the implementation of the project.

II. The other staff shall function based on the scope of work of the RFP and contract

signed between bidder and SDA.

III. If required bidder shall provide additional manpower to complete the work/task

within timelines. While during the tenure of the project the SDA can instruct bidder

to change the manpower at any location as per the requirements of

SDA/Department.

IV. Bidder will provide the list of actual deployed manpower on monthly basis.

V. The resources will be deployed based on the phase of the project as and when

required.

VI. The qualification and experience requirements of these resource persons are

mentioned below-

S.No Name of Resource

State Data Centre/ District for which proposed

Qualification (Minimum)

No. of Years of Experience

No. of Years with responding firm

Certification Domain Knowledge

1. Project Manager

State Level B.E.(Computer /E&C)/ MCA + MBA

7 Years 3 Years PMP/Prince 2 Working in projects related to implementation of IT with an experience of 5 years or more in at least two software implementation projects in project management role leading a team of 10 or more members. Should have overall experience of 2 or more years in Government projects


State Headquarter

B.E.(Computer /E&C)/ MCA

5 years 1 Year Technical certification in Data Base Administration in SQL Server or Oracle.

Experience in administering production data bases and worked in Oracle 9i, 10g, DB2, MS-SQL etc. Knowledge in PL/SQL Programming with experience in handling standby databases preferred.

3. Software Programmer

State Headquarter


5 Years 1 Year Any Professional Software Development Certification

Experience in the following packages: Visual Studio 2012, ASP.Net (2.0 - 4.5), C#, SQL Server 2008/2012 etc.


State Headquarter


7 Years 1 Year Any Professional Software Development Certification

Experience in the following packages: Visual Studio 2012, ASP.Net (2.0 - 4.5), C#, SQL Server 2008/2012 etc. Experience designing an enterprise application, database design, contract management, enterprise workflow, business process integration, and perhaps asset management components Experience with Service



S.No Name of Resource






Oriented Architecture (SOA) 5. System

Administrator/ Network Support Staff

State Headquarter

B.E. (Computer/E&C)/MCA

5 years 1 Year Technical certifications on Microsoft products etc. are must. Certification like CCNA/CCNP/PIX/CCSA

Experience in sys admin of RDMB data (MS-SQL, Oracle etc.), sysadmin windows-2008/2012 etc. server, programmer of .NET, SQL,PL/SQL, etc. Candidate should be well versed with Routing and Switching devices and technologies like ATM, Frame Relay, MPLS, Wireless, Broadband and Protocol Analysis Tools. Must have beginner to intermediate skills in Information Security technologies like Anti-virus, Firewalls, 2 & 3 factor Authentication, IDS, IPS, Content Filtering, Encryption, VPN, Threat Management and be familiar with Information Security Audit parameters.


District Diploma/B.E. (Computer/E&C)

2-3 years Technical certification like CCNA etc.

Experience in technical support services/ operations, IT Infrastructure, managing & updating customer database with pleasing personality and good communication skills.


State Level Graduate 1 Year - Good communication skills and knowledge of local language

VII. The selected bidder will ensure that all the resources deployed at any location are

easily approachable over mobile phones. Selected bidder will provide the contact

details of the manpower at the time of commencement of operations. Selected

bidder will also ensure that the proposed resources will not be changed during

project implementation without explicit approval of the SDA.

VIII. The SDA reserves the right to evaluate the performance of the resource persons

deployed on the project by bidder and ask for a suitable replacement in case of

unsatisfactory performance by any of the resource persons deployed to support the

project.

4.3.2.5 UAT and Go-Live Report

I. Selected bidder will assist in successful completion of User Acceptance Testing (UAT)

and audit of the system on the completion of the roll out of e-District and will submit a

Go-Live Report.

II. The State IT Department may decide to carry out the pilot in 1 district before carrying

out the state wide roll-out. In such a case, the SPMU and selected bidder has to co-



ordinate the phasing of training, data digitisation, hardware procurement, site

preparation, etc. in such a manner which synchronises with such a plan.

4.3.3.5.1 Sign-off Deliverables / Exit Criteria

I. Go-Live report for state and district level

II. UAT Report signed off from Info Tech Corporation of Goa Ltd. (ITG) and SPMU

3.3.2 Network Connectivity

The SWAN project in Goa is called the Goa Broad Band Network (GBBN). The GBBN project has

been designed to build a converged Wide Area Network (OFC) that connects the State

Headquarters and District Headquarters with all 12 Talukas, Village Panchayat, Households and

institutions across the State.

Status Name of

District

Name of

Taluka

Total

Number of

PoPs

No of POPs

not found

feasible

No of POPs

already

connected

Operational North Goa Tiswadi 78 - All

Bardez 64 - All

Pernem 28 - All

Bicholim 30 - All

Sattari 20 - All

Ponda 39 - All

Operational South Goa Salcette 62 - All

Quepem 28 - All

Sanguem 23 - All

Vasco 27 - All

Canacona 15 - All

Dharbandora 2 - All

NA – Not Available

4.3.2.1 Status of Horizontal Connectivity

S.No Name of

District

No. of offices

(approx.)

No. of offices

Connected (approx.)

No. of offices To Be

Connected (approx.)

1. North Goa &

South Goa

297 282 15

For Goa, the selected Bidder will undertake the following: I. With implementation of GBBN across all the States with 2 Mbps vertical connectivity

up to block level, PoPs (Point of Presence) are operational; the district administration is

connected to the nearest GBBN PoPs. The selected Bidder shall ensure last mile



connectivity from the nearest GBBN PoP to the Department offices processing the

services requests.

II. In cases where GBBN is not available, the DoIT shall procure the connectivity from a

service provider and the selected Bidder is expected to setup the last mile connectivity

to the Department offices processing the services requests.

III. LAN within all department offices including but not limited to IP addressing scheme,

physical cabling, router/switch configuration, V-LAN configuration, load balancing

configuration, and fail over mechanism. The selected bidder should coordinate with the

local department offices while designing and installing the LAN.

IV. All networking equipment required providing the LAN / WAN connectivity to meet

the requirements of the Project is also to be provided by the selected Bidder as part of

this RFP.


Network Connectivity report signed off by SPMU / ITG stating SDC, Line departments and sub

offices, Collectorate and sub-offices and all ESO/CSCSs have been connected and GBBN, wherever

applicable, has been leveraged to provide connectivity.

3.3.3 Data Digitisation

4.3.2.1 Introduction

The vendor will be required to digitize the data at district. The rates for backlog data entry must be

quoted separately in the commercial bid. The volume of data to be digitized will be assessed /

analysed by bidder which would be verified by e-District manager & approved by DeGS. The

digitization of backlog data of the entire State must be completed within 1 Year of signing the

contract.

All the equipment‟s like computer hardware, printer, scanners, UPS etc. required for the data entry

and digitalization will be the sole responsibility of the vendor. The vendor will be responsible for

the LAN connectivity at the location of the data entry. The vendor would be responsible to provide

all necessary consumables including stationery for print outs for verification. The Government

through its district administration will only provide space (premises) with appropriate ventilation,

normal electricity and water connections for the data entry purpose. However, the successful

agency would require arranging for back-up power including generator to avoid work disruptions

due to power shortage. It should be noted that the successful porting of verified data will be the

responsibility of the bidder and the data entry task will be deemed to be completed only after the

authorized official certifies that the backlog data that has been entered is successfully brought

online.

The agencies undertaking the digitization work may need to be trained on local language data

entry through use of applications/tools that have full compliance to the latest Unicode (version 6.0

or above) for character encoding and use of enhanced Inscript keyboard layout.



4.3.2.2 Under e-District project, “across the counter” services would be provided using

digitally signed records. Workflow for data entry

I. At each district/block/department, the Mamlatdar/Talati/SDO/Authorized authority

would prepare physical copy of the data in the format provided by the SPMU.

II. This form along with the records will be handed over to the data entry and scanning

operator.

III. Using these forms, the data entry operator would upload the data and scanned

documents into the software. Upon completion of digitization, the respective

Mamlatdar/Talati/SDO/HOD/ Authorized Authority would verify and digitally sign

the data.

4.3.2.3 Summarized Scope of Digitization:

The Scope of work has been primarily divided into the following main stages:

I. Digitization and Computerization of Legacy Records, bidder shall digitize all

historical data at the implementation sites of States (covering the last 5 years) and

may vary from case to case.

II. Bidder shall formulate the Data Digitization Strategy which will also include

internal quality assurance mechanism. This will be reviewed and signed-off by

SDA and SPMU prior to commencement of data digitization.

III. Bidder may coordinate with pilot states for getting the learning with the help from

SPMU and Nodal Officer.

IV. Bidder shall incorporate all comments and suggestions of SDA and SPMU in the

Data Digitization Strategy.

V. Bidder shall ensure complete data cleaning and validation for all data digitized and

loaded on to e-District Application.

VI. Bidder shall enter the readable/available data into the database in Multilanguage

i.e. in English, Konkani and Marathi.

VII. Bidder shall incorporate the amendments/corrections into the database suggested

by the Officials.

VIII. Bidder shall incorporate the final corrections into the database and replace the

pages bearing incorrect records.

IX. Bidder shall deliver the final registers and soft copy of the data to the department.

X. Bidder will use his own infrastructure like Hardware, Manpower etc., However

office space and electricity can be provided, if required.

XI. The bidder will also ensure safety and safe return of the documents. Any leakage of

the secret data of the department in general public may result in strict department

action by the authority against the bidder.

XII. Bidder shall validate the data before uploading the same to the production

environment.

XIII. Bidder shall generate appropriate control reports before and after digitisation to

ensure accuracy and completeness of the data.



XIV. Bidder shall conduct the acceptance testing and verify the completeness and

accuracy of the data Digitized to e-District Application.

XV. SDA and SPMU may, at its will, verify the test results provided by bidder.

XVI. Bidder can outsource data digitization work.

4.3.2.4 Software for data entry

I. Data Digitization does not refer to performing scan/ OCR of the records and

storing them in the database. It refers to data entry of citizen records in specified

formats for a defined period of time. The bidder has to develop the data entry

software keeping in mind the above workflow for digitally signing the data.

II. The software should have features to count number of key strokes used by data

entry operator for each login session user wise. This count will be used for payment

of data entry work. Payment of data entry should be based on 1000 characters

including enter key & excluding “delete” & “backspace” keys.

III. Each record will be verified by the Mamlatdar / Talathi / Department official and

then digitally signed by him/her.

4.3.2.5 The bidder would be responsible for the following activities

I. Preparation of the data entry software according to the above specification.

II. The data should be stored in the database in the same language in which it already

exists.

III. quality check

a. The bidder should ensure 98% data accuracy.

b. Complete checking will be conducted before digitally signing the data.

IV. location of work

a. Centralized – All district administrations/departments will provide space

for setting up temporary working office in districts/departments for project

duration. Bidder has to arrange all necessary facilities not limited to

electricity, power back up, water, cleaner, computers & other hardware at

his own.

V. loss of data

b. Bidder should take good care of all government records and will be

responsible for security of the record from time of receipt to time of

delivery.

c. Penalty for per record will be charged against the loss or damage of record.

d. The bidder should not accept illegible record. Non-readable record at the

time of returning of the data will be considered as damaged record.

VI. The bidder shall work during office hrs.

VII. Bidder shall do the pagination of each file before starting scanning. It shall be part

of scanning work. No extra charge for the same will be given to the bidder.

VIII. Unbinding of bounded volumes will not be permitted.

IX. Bidder shall have to scan documents and upload the same.



X. The bidder will be handed over the documents in a batch and he will cross-check

this information and will prepare a list containing discrepancies, if any.

XI. The bidder shall scan all the documents and will carry out quality checks in order

to ensure that the scanning quality is good and the pages are perfectly scanned.

XII. The bidder should not be allowed to unstapled/untie for the purpose of scanning.

XIII. Bidder shall not allow for using camera for scanning of records. only scanners shall

be used for scanning of documents.

XIV. The pages shall be scanned with minimum resolution300 dpi.

XV. Scanned images (preferably in .jpg, .gif, .tiff format) of these documents will have to

be converted into .pdf files.

XVI. All the documents are very important. The documents may have different size.

Proper care should also be taken while scanning for every document. the bidder

have to provide security measures while preparing CDs that no one can change the

content of the documents.

4.3.2.6 Sign off Deliverables / Exit Criteria

I. Data Digitisation Strategy Document

II. Approval by SDA / SPMU and concerned line department on successful

digitisation of data

4.3.2.7 Document Management System (DMS)

3.3.3.7.1 Scope of Work

I. Bidder shall prepare Document Management System (DMS). This system should be

able to store scanned documents, index these documents (by attaching multilingual

metadata tags to each of them), retrieve and display the stored scanned documents

upon searching for the relevant metadata tags.

II. A full maintenance for the DMS, software and hardware components supplied

would be required during the implementation period and also for a period of 5

years beginning from the time the entire scanning and indexing has been

completed and the system is up for use for the District users.

III. The clearance of application security Audit & Vulnerability audit of the application

through STQC will be carried out by the bidder.

IV. The scope pertaining to the Document Management System can be found below:

a. General

i. The bidder shall add/replace poor quality scanned

images/documents on its own, for which it shall not be entitled to

get any extra payment.

ii. It is the absolute responsibility of the bidder to ensure that the

contents of the digitized documents shall be an exact replica of the

original paper document maintained as part of the records in the

books. This will be a mandatory condition for the bidder.

iii. The files / documents will not be allowed to be removed from

premises allocated to bidder.



iv. Under no circumstances shall the documents be changed, mutilated,

destroyed or replaced by some other documents.

v. The DMS proposed will be part of e-District application & should be

able to integrate with any other department specific application or

other e-Governance initiatives.

vi. The firm shall at its own cost provide the necessary consumables,

including paper, ink and spares required for maintaining and

operating its machinery/equipment smooth execution of

scanning/digitization of records. The firm shall make its own

arrangements for safety/security of the equipment‟s and also keep

them incurred against theft, fire and damages.

b. Pre-scanning

i. Documents are kept at various locations in District including the

individual departments and record store rooms. The selected bidder

is required to collect these documents carefully. While collection, the

following details are to be entered into the log register.

a. No. of documents collected

b. No. of pages collected

c. Date of collection

d. Expected date of return

e. Actual date of return

f. Collected from

g. Collected by and Signature

h. Returned to and Signature

i. Returned by

ii. The log register would have to be maintained by the selected bidder.

iii. Documents that are very old and are not in good physical condition

would have to be repaired and prepared before they can be scanned.

iv. The selected bidder is required to take necessary precautions while

handling the documents.

v. The documents are to be maintained in an orderly manner without

disturbing the chronology of the documents and without mixing

pages between different documents.

c. Scanning

i. The documents shall be scanned on a minimum 600 DPI resolution,

black and white.

ii. The scanned documents shall be converted into PDF/TIFF files for

storage.

iii. The selected bidder shall perform the following Image

Enhancement Activities



a. Bidder should ensure that quality of scanned imaged are

enhanced up to the optimum level and required image

enhancement activities like De-skew (to make the images

straight), contrast ratio setting etc. have to be done on the

documents.

b. The bidder must carry out cropping and cleaning of images like

removing black noises around the text, de-spackle (removing

small dots between the texts) and provide equal margins all

around the text.

c. In case the documents are not legible, it will be the bidder‟s

responsibility to scan the documents on high resolution i.e. 600

dpi or higher.

d. In case the content of the documents are not visible then

document scanning shall be done in Grey Scale. No extra

payment shall be made for the same.

e. Documents/pages identified by the competent authority of

individual department of District or which are either torn or not

in a proper condition or illegible should be converted in to

machine readable text format (ASCII or Text mode) by OCR

(Optical Character Reorganization) Process.

iv. The bidder will ensure that all documents are digitized.

v. No page/document shall be digitized more than once.

d. Retrieval

i. The scanned documents should be retrievable through search. The

documents would be searched for the metadata tags that were used

to index the document.

ii. These metadata tags should include (at the least)

a. Subject of the document

b. File No.

c. Date of document

d. Department

e. Authority

iii. More metadata tags shall be required to be added to the above list.

The same shall be discussed and finalized with the bidder before the

commencement of work.

iv. The metadata tags should be alphanumeric, in Unicode and should

also include provision for typing in English and Konkani & Marathi

v. The document should be retrievable by searching for any of the

metadata tags mentioned above.

vi. Retrieval through search criteria in English, Konkani & Marathi

should also be possible

vii. Access Control - There shall be an access control that shall be

imposed on each of the scanned documents. The access control



would be at the document level. Only users at a particular level on

the hierarchy should have access to certain documents.

e. Post scanning

i. After scanning, the physical document would have to be pinned

together/tagged in the same form as it was given for scanning by the

individual departments.

ii. The scanned data shall be stored on the server.

iii. The backup of incremental data shall be taken on a Hard Disk Drive

daily at the end of the day.

iv. Each page of a document shall be serially numbered and shall be

counted while giving the documents back.

f. Reports

i. The selected bidder shall also provide tools for checking the

scanning progress. This shall include the daily, weekly, monthly and

overall progress (number of images/pages scanned, percentage

scanned etc.). The tool should also display department-wise and

record room wise progress. The tool should be able to provide

reports on the status of scanning on a periodic basis.

ii. The selected bidder will maintain a register that will serve a purpose

of evidence for the number of documents and pages entered by the

bidder on each day. The details of this register would have to be

entered into the tool mentioned on a daily basis.

iii. The format, content, periodicity and other information related to

reports shall be discussed and finalized with selected the bidder

before the commencement of the project.

4.3.4.2.1 Sign off Deliverables / Exit Criteria

I. Data Digitisation Strategy Document

II. Approval by SDA / SPMU and concerned line department on successful digitisation of

data

III. District-wise Monthly Digitization report authorized by e-District Project Management and DeGS

3.3.4 Site Preparation

I. The selected bidder is expected to prepare the client sites for setting up the necessary client site infrastructure.

II. Site preparation at all required client offices will include electrical fittings and LAN cabling along with conduit.

III. The selected bidder will have to ensure that Collectorate and sub offices, line departments and their sub offices are equipped to offer services through e-District Application.



IV. Any gap in infrastructure required for providing services using e-District Application shall be provided by the selected bidder.

V. The details of number of offices for site preparation prepared by bidder will be confirmed by SDA.

VI. Maintenance of the computing and connectivity infrastructure for 5 years and training support to be imparted to the end user.

A sample template for scope of work for Networking is provided in this .


I. List of offices for site preparation. II. Site Preparation Completion Report.

3.3.5 Supply / Procurement of IT Infrastructure at SDC

The bidders are required to carefully assess the requirements of this RFP and size the

infrastructure accordingly. Bidders are free to propose any higher / additional infrastructure that

may be required as per their proposed solution to meet the project requirements, its scope of work

and SLAs as listed in this RFP.

I. Bids / proposals which do not meet the minimum IT infrastructure specifications given in

this RFP will be summarily rejected. The minimum technical specifications for the IT

Infrastructure are provided in Bill of Material (Infrastructure at SDC) in this volume and

note that these are the minimum requirements only. The Bill of Material (BoM) is indicative

for the project and shall be changed based on the BPR study done by the selected bidder.

II. The Bidder will be responsible for sizing the hardware to support the scalability and

performance requirements of the e-District application. The Bidder shall ensure that the

servers are sized adequately and redundancy is built into the architecture required to meet

the service levels mentioned in the RFP.

III. None of the IT Infrastructure proposed is declared “End-of-Sale” by the respective OEM in

next 3 years as on date of submission of Bid.

IV. The IT Infrastructure proposed should be purchased within last 2 months from the date of

deployment and documentary proof for warranty and proof of purchase should be

produced at the time of deployment of infrastructure.

V. The IT Infrastructure proposed should be compatible with infrastructure at SDC, SSDG,

GBBN, State Portal, etc.

VI. The bidder should provide requisite licenses for all the system software required for

servers including, but not limited to industry standard operating system, enterprise class

database software, application server software, web server software, OS hardening, and all

other required software with sufficient number of licenses.

VII. The Bidder will be responsible for providing all the details of the Bill of Material (BoM) and

specifications of the IT Infrastructure proposed, licenses of the system software, all other



equipment proposed as part of its Technical Proposal. The financial quote submitted by the

Bidder should include costs for these.

3.3.6 Hardware Commissioning at Field Offices

4.3.2.1 Design, Supply, Installation, Commissioning, Operations & Maintenance of IT

Infrastructure

This shall consist of

I. Supply / Procurement of IT Infrastructure at Department Offices (DHQ, Taluka, Block)

II. Installation and Commissioning of IT Infrastructure will be done by bidder.

III. The steps to be followed for assessment, review, approval, and procurement of IT

infrastructure at Department Offices (DHQ, Taluka, Block) will be the following:

a. The bidder shall analyse the gap in requirements of the IT infrastructure at

the Taluka offices and corresponding District Office based upon the total

requirements calculated for the field office and the existing infrastructure.

b. The bidder is required to perform a final verification study of gap

infrastructure at various department offices (DHQ, and Block) in each

District based upon the gaps identified in all the Taluka offices and the

corresponding District office. (Ref. Vol. I Annexure)

c. The gap in requirements will be validated by each e-District Project

Manager after verifying the entire available infrastructure in the various sub

offices, etc.

d. The actual requirements of new IT infrastructure will then be approved by

the District e-Governance Society.

e. The DeGS will send this gap in IT infrastructure to the SDA.

f. The SDA will consolidate the requirements for the state.

g. The SDA will then place the final order.

4.3.2.2 Supply / Procurement of IT Infrastructure at Department Offices (DHQ, Taluka

and Block)

The bidders are required to carefully assess the requirements of this RFP and propose the IT

Infrastructure required at Department Offices. The following hardware and peripherals need to be

installed in different districts, blocks and Talukas offices spread across the State processing the

service requests submitted by the citizens:

I. PC / Desktop

II. Laptop

III. Digital Web Camera

IV. Scanners

V. Network Printers

VI. Laser Printers

VII. Other Printers



VIII. UPS (1 KVA)

Bidders are free to propose any higher / additional infrastructure that may be required as per their

proposed solution to meet the project requirements, its scope of work and SLAs as listed in this

RFP.

I. Bids / proposals which do not meet the minimum IT infrastructure specifications given in

this RFP will be summarily rejected. The minimum technical specifications for the IT

Infrastructure are provided in Bill of Material (Infrastructure at Field Offices) and note

that these are the minimum requirements only.

II. None of the IT Infrastructure proposed is declared “End-of-Sale” by the respective OEM in

next 3 years as on date of submission of Bid.

III. The IT Infrastructure proposed should be purchased within last 2 months from the date of

deployment and documentary proof for warranty and proof of purchase should be

produced at the time of deployment of infrastructure.

IV. The IT Infrastructure proposed should be compatible with infrastructure at SDC, SSDG,

GBBN, State Portal, etc.

V. The bidder will be responsible for providing all the details of the Bill of Material (BoM) and

specifications of the IT Infrastructure proposed, licenses of the system software, all other

equipment proposed as part of its Technical Proposal. The financial quote submitted by the

Bidder should include costs for these.

4.3.4.4.4 Installation and Commissioning of IT Infrastructure

The selected Bidder is responsible for installation and configuration of the entire infrastructure set-

up, including but not limited to the following:

I. All IT Infrastructure including operating systems and any other system software required

for making the infrastructure operational and tuned for satisfactory performance.

II. The IT Infrastructure will be installed and configured in accordance with the IT Policies of

the Goa.

The selected Bidder will ensure that the reports for monitoring of SLAs such as system uptime,

performance, etc. are generated automatically from the system and the applicable penalties are

calculated as indicated in the RFP.

3.3.7 Migration to New Infrastructure Facility

A state of the art SDC under NeGP is also proposed for implementation in Goa which has been

approved by DoIT, GOI. The Department of Information Technology, Goa intends to take up an

alternate infrastructure facility to locate the current SDC. If the location and site preparation for the

new infrastructure facility is finalized during the course of the implementation of e-District project,

selected bidder shall be responsible for server migration and related services to the new



infrastructure facility. The Selected bidder will also be responsible to connect the new SDC location

to SDC disaster recovery (DR) site in based in Hyderabad.

Selected Bidder shall give various types of services depending upon the requirements. These

services would contain application / database migration, application enhancement, database

tuning, database / application administration, etc.

Following are the services shall be given by the Selected Bidder in case of migration of servers in

future:

I. Migration Assessment:

Develop migration strategy and migration roadmap and discuss with the department to finalize it.

o Prepare application porting plan to port the application to a new Infrastructure Facility.

II. Carry out Data Migration: Schema translation, data migration, data cleansing.

III. Carry out Technology Migration: Language migration, OS migration, database migration, user interface migration

IV. Maintain all the documentation such as project plan for migration, migration roadmap, SRS, SDD, migration documents and testing related documents.

3.3.8 Licenses

I. The system software licenses mentioned in the Bill of Materials shall be genuine, perpetual,

full use and should provide upgrades, patches, fixes, security patches and updates directly

from the OEM. All the licenses and support (updates, patches, bug fixes, etc.) should be in

the name of DoIT.

II. The bidder shall provide with a full use database license. All the licenses and support

(updates, patches, bug fixes, etc.) should be in the name of DoIT. Bidder shall provide a

comprehensive warranty that covers all components after the issuance of the final

acceptance by DoIT & Info Tech Corporation of Goa Ltd. (ITG). The warranty should cover

all materials, licenses, services, and support for both hardware and software. Bidder shall

administer warranties with serial number and warranty period. Bidder shall transfer all the

warranties to DoIT at no additional charge at the time of termination of the project. All

warranty documentation (no expiry) will be delivered to DoIT.

III. The selected bidder shall review the licenses requirements with the SPMU and Nodal

Officer. The SPMU with the help of Nodal Officer shall clarify on the licenses requirements

to be brought by the selected bidder and availability at SDC.

3.3.9 Capacity Building / Training

Capacity building will include the following:



I. Imparting training in Information Technology (IT), Business Process Reengineering (BPR)

and Change Management.

a. Such trainings and skills will be imparted to all levels of government

employees involved in the processes pertaining to the selected services.

b. These would range from senior officers such as the State Department

Secretaries up to the officials working in the districts and sub districts such

as Gram-Sevak/Talati/Panchayat Secretaries etc.

II. DoIT shall act as the nodal department to oversee the training and capacity building

requirements for the e-District Project and District e-Governance Societies (DeGS) shall be

responsible for facilitating the rollout of trainings proposed for each district.

III. DeGS shall identify the list of personnel in various departmental offices across State,

Districts, Talukas/ Blocks and Gram Panchayat who are responsible for ensuring service

delivery under the e-District Project for training and ensure that all the stakeholders

become efficiently trained on the system and processes which shall form the basis of service

delivery under the e-District Project.

IV. The bidder would be responsible to define and prepare a state-wide e-District Project

rollout and training plan along with the training content e.g. presentation, user manual and

operational manual and submit the same to DoIT/ITG for approval.

V. The bidder would be required to prepare a detailed training plan covering the training

approach, details of the target audience, location, dates for training, duration and training

content. The bidder would be responsible to coordinate with the DeGS and e-District

Project Manager for finalization of the training plan.

VI. Selected bidder shall prepare and organize training programs to facilitate the service

delivery departments/offices in the efficient usage of the new system.

VII. Selected bidder shall provide district level classroom training using audio-visual

equipment and material at the trainer‟s disposal with mandatory hands on through live

example. The bidder would have to arrive at a training program which at the minimum

should contain the following:

a. Computer Basics

b. Business Process/ Application based Training

c. Specialized Technology Training (for System administration and troubleshooting)

d. Project management (for District Project Managers on general project management

and on usage of PMIS)

e. Digital Certificate Usage Training (including refresher course)

VIII. The proposed training module is expected to help the Government functionary to

undertake their revised roles and responsibilities with ease and without any difficulty and

apprehension. The training modules will impart the required skill set and capacity for

performance of defined roles and responsibilities.



IX. Training shall also encompass orientation & the knowledge of basic functionalities of e-

District Application, Guidelines and other revised backend processes.

X. Selected bidder shall provide training to 20% of department‟s manpower or to 4 officials

per service per Taluka (whichever is less) through “Train the trainer methodology”. There

would be also one more round of training iteration for all these “Trainers” 3 months later

first training. Rest 80% of department manpower would be trained by the “Trainers”

where-in bidder ‟s role would be limited to supporting user department in identifying

“Trainer” & ensuring resolution of queries/challenges faced by the “Trainers”.

XI. Selected bidder will have to bear the expenses related to training such as training material,

trainer, laptop, projector & logistics arrangement of the trainer. However, bidder shall not

be responsible for training infrastructure such as Training Rooms, Sitting arrangement,

food for trainees, lodging and boarding expenses for trainees.

XII. Bidder shall coordinate with pilot states for getting the learning with the help from SPMU

and Nodal Officer. Selected bidder shall include the learning from pilot states and update

the necessary changes in the training.

XIII. Training shall also be provided for teaching the basic trouble shooting activities in case of

problems. The bidder should also cover the general problems and its resolution

mechanism in the operational manual

XIV. The Selected bidder provides training to officials in batches with a recommended batch size

of 30 participants. Moreover minimum 20 participants are required for conducting the

training session and the same should not exceed 40 participants.

XV. The trainers imparting the training should be well versed in Local language and English

language.

XVI. Training shall be imparted in Local language and English language as per the requirement

of the trainees. The printed manuals and training manuals should also be available in Local

language and English Language.

XVII. The selected bidder shall provide multimedia resources (Video, PPTs, e-Leaning

modules/simulations & e-Quiz) permanently accessible for all govt. officials through

GBBN. All the training content created out of this project shall be the copyright of

DoIT/Government of Goa.



XVIII. State has the flexibility of engaging more than one training partner for providing the

training programs in case performance of bidder training program is not satisfactory. In

such case, bidder would be charged 5% penalty directly of the total project cost. SPMU will

define the criteria of training effectiveness criteria once application is ready to roll-out.

XIX. Trainings shall be provided to all the new employees as and when joining the department

through “train the trainer” methodology.

4.3.6.2.1 Sign off Deliverables / Exit Criteria

I. Capacity Building Plan

II. Change Management Plan

III. Training Plan

IV. Training Content including user manual, operational Manuals and computer based

tool kits, PPTs and videos to promote self-learning

V. Completion report of training and change management activities

3.3.10 Manpower requirements

Bidder shall provide dedicated centralized helpdesk team of 2 resources post deployment

to resolve any operational issues in application through phone/e-mail/live chat.

S.No. Name of Resource






North Goa

South Goa

1.

2.

3.3.11 Business Continuity Planning

The selected bidder is expected to develop a Business Continuity Plan (BCP) and Disaster

Recovery Plan (DRP) for the operations carried out by the selected Bidder. An indicative list of

activities to be performed by the selected Bidder is mentioned below:

I. Designing and implementing adequate data backup, business continuity and

restoration procedures for the e-District application data (including but not limited to

the database, attachments and all other data elements created in and generated by the

system and users)

II. Ensuring data backup till the last transaction occurring in the system to ensure

enhanced service levels and following RPO and RTO objectives:

A. Peak hours: Zero RPO and Zero RTO

B. Non-Peak Hours: Zero RPO and RTO <= 60 minutes

III. Any storage space / media required to maintain backups and other requirements of the

RFP should be provisioned for by the selected bidder in his Bid.

IV. Designing and implementing data synchronization procedures for the DR Site. Periodic

testing may be done to ensure that all replication and data synchronization procedures

are in place all the time. Replication between Data Centre and DR Site as well as



change-over during disaster should be automatic and real-time for minimal impact on

user experience.

3.3.12 Others

4.3.2.1 Information Security Management

Security of Application and the data contained therein is paramount for the success of this Project.

Hence, the selected Bidder should take adequate security measures to ensure confidentiality,

integrity and availability of the information.

Security Requirements

Overall Solution

1. The proposed solution should include design and implementation of a comprehensive IS

security policy in line with ISO 27001 standards to comply with the security requirements

mentioned in this section. All the necessary procedures / infrastructure / technology

required to ensure compliance with IS security policy should be established by the selected

Bidder and should be approved by the Info Tech Corporation of Goa Ltd. (ITG) before they

are implemented. The IS Policy shall include all aspects such as physical and

environmental security, human resources security, backup and recovery, access control,

incident management, business continuity management etc.

2. The designed IS policy is not in conflict with the security policy of the State Data Centre

where the infrastructure would be hosted.

3. The proposed solution should ensure proper logical access security of all the information

Assets

4. The proposed solution should be able to classify information assets according to criticality

of the information asset.

5. The proposed solution should provide security including identification, authentication,

authorization, access control, administration and audit and support for industry standard

protocols

6. The proposed solution should have a security architecture which adheres to the security

standards and guidelines such as

ISO 27001

Information security standards framework and guidelines standards under e-

Governance standards (http://egovstandards.gov.in)

Information security guidelines as published by Data Security Council of India

(DSCI)

http://egovstandards.gov.in/




Guidelines for Web Server Security, Security IIS 6.00 Web-Server, Auditing and

Logging as recommended by CERT-In (www.cert-in.org.in)

System shall comply with IT (Amendment) Act 2008.

7. The proposed solution should support the below Integration security standards:

Authentication

Authorization

Encryption

Secure Conversation

Non-repudiation

XML Firewalls

Security standards support

WS-Security 1.0

WS-Trust 1.2

WS-Secure Conversations 1.2

WS-Basic Security Profile

8. The proposed solution should a multi-layered detailed security system covering the overall

solution needs having the following features:

i. Layers of firewall

ii. Network IPS

iii. Enterprise-wide Antivirus solution

iv. Information and incident management solution for complete DoIT or Info Tech

Corporation of Goa Ltd. (ITG) landscape

v. Two factor authentication for all administrators i.e. system administrators, network

administrators, database administrators.

vi. Audit Log Analysis

Selected Bidder must ensure that the security solution provided must integrate with

the overall system architecture proposed

9. The proposed solution should be monitored by periodic information security audits /

assessments performed by DoIT or Info Tech Corporation of Goa Ltd. (ITG). The scope of

these audits / assessments may include, but are not limited to, a review of: access and

authorization procedures, physical security controls, backup and recovery procedures, and

program change controls.




To the extent that the Info Tech Corporation of Goa Ltd. (ITG) deems it necessary to carry

out a program of inspection and audit / assessment to safeguard against threats and

hazards to the confidentiality, integrity, and availability of data, the Selected Bidder shall

provide the DoIT or Info Tech Corporation of Goa Ltd. (ITG) representatives access to its

facilities, installations, technical resources, operations, documentation, records, databases

and personnel. The Selected Bidder must provide DoIT or Info Tech Corporation of Goa

Ltd. (ITG) access to various monitoring and performance measurement systems (both

manual and automated). DoIT or Info Tech Corporation of Goa Ltd. (ITG)has the right to

get the monitoring and performance measurement systems (both manual and automated)

audited / assessed without prior approval / notice to the Selected Bidder

10. The proposed solution should facilitate system audit for all the information assets to

establish detective controls. The selected Bidder is required to facilitate this by producing

and maintaining system audit logs for a period agreed to with Info Tech Corporation of

Goa Ltd. (ITG).

11. The proposed solution should ensure that data, especially those to pertaining to

registration process, transaction process as well as the data that is stored at various points

is appropriately secured as per minimum standard 128 Bit AES/3DES encryption.

12. The proposed solution should provide database security mechanism at core level of the

database, so that the options and additions to the database confirm the security policy of

the DoIT or Info Tech Corporation of Goa Ltd. (ITG) without changing the application

code.

13. The proposed solution should support native optional database level encryption on the

table columns, table spaces or backups.

14. The database of the proposed solution should provide option for secured data storage for

historic data changes for compliance and tracking the changes.

15. The proposed solution should be able to ensure the integrity of the system from accidental

or malicious damage to data

16. The proposed solution should be able to check the authenticity of the data entering the

system

17. The proposed solution should be able to generate a report on all “Authorization Failure”

messages per user ID

18. The proposed solution should be able to monitor the IP address of the system from where

a request is received.




19. The proposed solution should be able to differentiate between the systems of the DoIT or

Info Tech Corporation of Goa Ltd. (ITG) network and other external systems

20. Retention periods, archival policies and read-only restrictions must be strictly enforceable

on all logs maintained in the system

21. The proposed solution should provide ability to monitor, proactively identify and

shutdown the following types of incidents through different modes of communication

(email, SMS, phone call, dashboard etc.):

i. Pharming

ii. Trojan

iii. Domains (old/new) similar to “DoIT / Info Tech

Corporation of Goa Ltd. (ITG), Government of Goa”

22. The proposed solution should be able to monitor security and intrusions into the system

and take necessary preventive and corrective actions.

23. The proposed solution should have the option to be configured to generate audit-trails in

and detailed auditing reports

24. The proposed solution must provide ACL objects and a security model that can be

configured for enforcement of user rights

25. The proposed solution should be designed to provide for a well-designed security of

physical and digital assets, data and network security, backup and recovery and disaster

recovery system.

26. The proposed solution should have tamper proof data storage to prevent unauthorised

data tampering

27. The proposed solution should have a Business Continuity Plan and a Disaster Recovery

Plan prepared and implemented by the selected Bidder before commencement of the

operations. Robust backup procedures to be established for the same.

Password Requirement

1. The proposed solution should allow DoIT & Info Tech Corporation of Goa Ltd. (ITG) to

define password policies. The minimum password policies to be defined are:

i. Minimum/ Maximum password length

ii. Alpha numeric combination of password

iii. Compulsory use of special characters

iv. Minimum password age

v. Password expiry period




vi. Repeat passwords etc.

2. The proposed solution should be able to automatically check the passwords with the

password policy, which can be customized by the DoIT or Info Tech Corporation of Goa

Ltd. (ITG)

3. The proposed solution should enforce changing of the default password set by the system

(at the time of creation of user ID) when the user first logs on to the system. The proposed

solution should enforce all password policies as defined at the time of first change and

thereafter.

4. The proposed solution should store User ID's and passwords in an encrypted format.

Passwords must be encrypted using MD5 hash algorithm or equivalent(selected Bidder

must provide details)

5. The proposed solution should be capable of encrypting the password / other sensitive data

during data transmission

6. The proposed solution should ensure that the user web access shall be through SSL (https)

only for all level of communication for providing higher level of security.

3.3.13 Project Management

4.3.2.1 Project Planning and Management

e-District Mission Mode Project is a geographically spread initiative involving multiple

stakeholders. Successful implementation and national roll out of the project ultimately depends on

all its stakeholders, the role of bidder is very critical. Hence bidder is required to design and

implement a comprehensive and effective project planning and management methodology

together with efficient and reliable tools.

Project planning exercise shall essentially commence with the start of the project, however, project

management exercise shall commence at the start of the project and shall continue till the O&M

Phase of the project.

To have an effective project management system in place, it is necessary for the selected bidder to

use a Project Management Information System (PMIS) to monitor the Project Progress. The bidder

shall address at the minimum the following using PMIS:

I. Create an organized set of activities for the project.

II. Coordinate and collaborate with various stakeholders including the Departments

concerned.

III. Nodal Agency, State IT Department, NIC, SPMU, NPMU, DeitY, GoI.



IV. Establish and measure resource assignments and responsibilities.

V. Construct a project plan schedule including milestones.

VI. Measure project deadlines, budget figures, and performance objectives.

VII. Communicate the project plan to stakeholders with meaningful reports.

VIII. Provide facility for detecting problems and inconsistencies in the plan

During the project implementation the bidder shall report to the State Nodal Officer/SPMU, on

following items:

I. Results accomplished during the period;

II. Cumulative deviations to date from schedule of progress on milestones as specified in

this RFP read with the agreed and finalized Project Plan;

III. Corrective actions to be taken to return to planned schedule of progress;

IV. Proposed revision to planned schedule provided such revision is necessitated by

reasons beyond the control of the bidder ;

V. Other issues and outstanding problems, and actions proposed to be taken;

VI. Interventions which the bidder expects to be made by the State Nodal Officer and / or

actions to be taken by the State Nodal Officer before the next reporting period. Progress

reports would be prepared by bidder on a fortnightly basis. These reports may be

required to be shared with either the SDA or the SPMU, as the case may be.

VII. Project quality Assurance

VIII. Change Control mechanism

IX. Project Management activities

X. Issue Management to help identify and track the issues that need attention and

resolution from the State.

XI. Scope Management to manage the scope and changes through a formal management

and approval process.

XII. Risk Management to identify and manage the risks that can hinder the project progress.

Bidder will closely work with SPMU and send the reports to the SPMU. SPMU will assist Nodal

Officer in acceptance of the report/ document and suggest the action plan to the Nodal Officer.

The Project plan prepared by the bidder at the initial stage of the project shall be reviewed by the

SDA on the advice of the State Mission Team and SPMU and then submit it to the Apex /

Empowered Committee for approval.

The bidder shall update and maintain the Project Plan throughout the duration of the engagement.

All changes are to be reviewed and approved by the SDA or SPMU.

4.3.2.1 Sign off Deliverable/ Exit Criteria

I. PMIS data update & functioning.

II. Periodic Reports on on-going basis



3.4 Scope of Services - Operation and Maintenance Phase

The selected bidder is responsible for the day to day maintenance of the software system for the

entire period of Contract (This includes 3 years for software from date of Go live and 5 years for

hardware from date of installation). For the IT Infrastructure procured as part of this RFP, the

selected Bidder will be responsible for smooth Operations and Maintenance Services for the period

covering onsite support for 5 year of comprehensive warranty from the date of commissioning of

the IT Infrastructure covering the following:

I. Onsite comprehensive warranty support for 5 years

II. Technical Support for all the licensed software (in hardware) for 5 years from date of

installation and 3 years of O&M for e-District application software.

III. Providing help desk support with Escalation matrix for registration of complaints

related to the IT Infrastructure, system software, networking, UPS points & e-District

software maintenance & up-gradation.

IV. Helpdesk support has to be provided by the bidder from the date of Go-Live from post

of 1st 10 services till the end of project

3.4.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 and Non-IT infrastructure deployed

by the selected Bidder for the Project including Server Infrastructure at SDC,

Departmental locations, networking equipment‟s & connectivity, 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.

B. Repair or replace infrastructure deployed for this Project, either directly or through

a third party warranty provider depending on the case

C. Replace component due to technical, functional, manufacturing or any other

problem with a component of the same make and configuration. In case the

component of same make and configuration is not available, the replacement shall

conform to open standards and shall be of a higher configuration and shall be

approved by the Department

D. Perform system administration tasks such as managing the user access, creating and

managing users, taking backups etc.

E. Performance tuning of the system to ensure adherence to SLAs and performance

requirements as indicated in the RFP.

II. Network Administration and Trouble Shooting

A. Coordinate with the network service providers to maintain smooth network

operations and ensure uptime and performance requirements of the IT



infrastructure as indicated in the RFP are met. The selected Bidder will be totally

responsible for all networking equipment‟s installed by him.

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 utilization including regular database backup

and periodical testing of backup data, conducting configuration review to tune

database, maintaining the necessary documentation and managing schemes to

database schema, disk space, user roles, and storage.

IV. Overall

A. Undertake preventive maintenance (any maintenance activity that is required

before the occurrence of an incident with an attempt to prevent any incidents) and

carry out the necessary repairs and replacement of parts wherever needed to keep

the performance levels of the hardware and equipment in tune with the

requirements of the SLA. Such preventive maintenance shall not be attended during

working hours of the State Departments, unless inevitable and approved by the Info

Tech Corporation of Goa Ltd. (ITG).

B. Undertake reactive maintenance (any corrective action, maintenance activity that is

required post the occurrence of an incident) that is intended to troubleshoot the

system with sufficient teams

C. Escalate and co-ordinate with its OEMs for problem resolution wherever required

D. The selected bidder will be required to comply with various policies relating to

monitoring and management of infrastructure such as IS Policy, backup and

archival policy, system software update policy etc. of the Goa.

3.4.2 Warranty Support

As part of the warranty services bidder shall provide:

I. Selected bidder shall provide on-site comprehensive warranty for 5 years from the date

of commissioning of all IT infrastructures and other equipment (if any) for providing

warranty support to SDA.

II. Selected bidder shall provide the comprehensive manufacturer's warranty and support

in respect of proper design, quality and workmanship of all hardware, equipment,

accessories etc. covered by the RFP.

III. Selected bidder must warrant all hardware, equipment, accessories, spare parts,

software, etc. procured and implemented as per this RFP against any manufacturing

defects during the warranty period.

IV. Selected bidder shall provide the performance warranty in respect of performance of

the installed hardware and software to meet the performance requirements and service

levels in the RFP.

V. Selected bidder is responsible for sizing and procuring the necessary hardware and

software licenses as per the performance requirements provided in the RFP. During the

warranty period bidder shall replace or augment or procure higher-level new



equipment or additional licenses at no additional cost to the DoIT or Info Tech

Corporation of Goa Ltd. (ITG) in case the procured hardware or software is not

adequate to meet the service levels.

VI. Mean Time between Failures (MTBF): If during contract period, any equipment has a

hardware failure on four or more occasions in a period of less than three months; it

shall be replaced by equivalent or higher-level new equipment by the bidder at no cost

to Info Tech Corporation of Goa Ltd. (ITG).

VII. However, if the new equipment supplied is priced lower than the price at which the

original support services for all system software, DBMS (Database Management

System), EMS (Enterprise Management System), other products deployed as part of this

project will require proper arrangements of bidder with OEM.

VIII. During the warranty period bidder shall maintain the systems and repair / replace at

the installed site, at no charge to Info Tech Corporation of Goa Ltd. (ITG), all defective

components that are brought to the bidder‟s notice.

IX. Warranty should not become void, if Info Tech Corporation of Goa Ltd. (ITG) buys, any

other supplemental hardware from a third party and installs it within these machines

under intimation to the bidder. However, the warranty will not apply to such

supplemental hardware items installed.

X. The bidder shall carry out Preventive Maintenance (PM), including cleaning of interior

and exterior, of all hardware and testing for virus, if any, and should maintain proper

records at each site for such PM. Failure to carry out such PM will be a breach of

warranty and the warranty period will be extended by the period of delay in PM.

XI. Bidder shall use the antivirus which is available at state. However in case there is a

requirement to procure the license for anti-virus, bidder shall in consultation with

SPMU and Nodal Officer procures the anti-virus Licenses and maintains the service

part.

XII. Bidder shall monitor warranties to check adherence to preventive and repair

maintenance terms and conditions.

XIII. The bidder shall ensure that the warranty complies with the agreed Technical

Standards, Security Requirements, Operating Procedures, and Recovery Procedures.

XIV. Any component that is reported to be down on a given date should be either fully

repaired or replaced by temporary substitute (of equivalent configuration) within the

time frame indicated in the Service Level Agreement (SLA).

XV. The bidder shall develop and maintain an inventory database to include the registered

hardware warranties.

3.4.3 Technical Support (TS)

As part of the TS services bidder shall provide:

I. Bidder shall maintain data regarding entitlement for software upgrades, enhancements,

refreshes, replacements and maintenance.



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

III. Bidder should carry out any requisite adjustments / changes in the configuration for

implementing different versions of Application Software.

IV. Updates / Upgrades / New releases / new versions / Patches / Bug fixes: The bidder

shall provide from time to time the Updates / Upgrades / New releases / new versions

/ Patches / Bug fixes of the software, operating systems, etc. as required. The bidder

should provide free Updates / Upgrades / New releases / new versions / Patches /

Bug fixes of the software and tools to SDA as and when released by OEM.

V. Software License Management. The bidder shall provide software license management

and control. Bidder shall maintain data regarding entitlement for software upgrades,

enhancements, refreshes, replacements, and maintenance.

VI. Bidder shall have complete manufacturer‟s technical support for all the licensed

software problems and/or questions, technical guidance, defect and non-defect related

issues. Bidder shall provide a single-point-of-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.

3.4.4 Help Desk and Trouble ticket management system

I. The selected Bidder as part of provisioning support for Department users at each

location and the SDC will setup centralized helpdesk and coordinate with the

respective OEMs of the IT Infrastructure deployed at SDC and the Department offices.

For the Goa, the selected Bidder will undertake the following:

a. Provide Help Desk services to track and route requests for service and to assist

department users in answering questions and resolving problems related to the

IT Infrastructure installed at Data Centre and at all the Department Offices .

b. Become 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)

c. Shall provide a first level of support for application and technical support at e-

District implementation locations across the State where the software,

hardware, and other infrastructure will be rolled out.

d. Provide the following integrated customer support by establishing 12 hrs. X 6

Days (8 AM to 8 PM) Help Desk facility for reporting issues/ problems with

the software, hardware and other infrastructure.

II. This shall be an online system deployed centrally and shall be used by the selected

Bidder extensively for management of network support activity and handling calls

from citizen, departmental staff, any other stakeholders. Service desk is an application



that facilitates the end-to-end service support. The proposed system should include

required hardware and software.

III. This proposed software system is expected to facilitate the following:

A. User Interface: - The proposed system should have an easy to use user interface

(preferably a browser based), so that users across the State can lodge any

complaints and service requests. The solution shall have a reporting interface with a

consolidated view of the network status. All users (departmental and external) of

the system should be able to log a request in the system using any of the following

channels:

1. Telephonic call on the Toll-free Helpline

2. email

3. Online chat on the departmental web-portal

4. Through intranet for departmental users or web-portal for external users

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

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

for a specified period of time.



All relevant infrastructure and supporting system software required for the

deployment and operation of the help desk is to be provided by the selected Bidder.

The system deployed by the bidder shall be complied with ITIL and ISO 20000

service specifications.

3.5 General Requirements

I. Licensing Requirements

A. All system software, licenses, etc. have to be procured in the name of the DoIT, Goa.

B. The licenses should be perpetual and enterprise wide for the core application and

other software unless otherwise stated. The software licenses shall not be restricted

based on location and the DoIT should have the flexibility to use the software

licenses for other requirements, if required

C. All system software licenses have to be for 5 years.

II. Asset Management

The selected Bidder will perform the following asset management functions with respect to

the infrastructure deployed at various locations:

A. Take periodic stock of, review physical inventory and maintain stock registers of

hardware at all locations covered under this Project. The selected Bidder would

maintain stock registers as per format agreed with the Info Tech Corporation of Goa

Ltd. (ITG).

B. Maintain documentation of the hardware assets, maintain asset Information for all

Project locations, on parameters to be mutually agreed between the Info Tech

Corporation of Goa Ltd. (ITG) and the selected Bidder, which shall include details like

1. Product type, model number, version number

2. Manufacturer

3. Office location

4. Maintenance status, etc.

C. Update or correct the asset information following any new installations, movement,

addition, or change performed by the selected Bidder.

D. Produce periodic reports and machine readable files in agreed upon format

pertaining to some or all of the asset information.

E. Restrict movement of server/equipment/items in or out of SDC or any other

location under the Project without prior permission from the Info Tech Corporation of

Goa Ltd. (ITG).

III. Warranty and Support

a. The selected Bidder shall warrant that the IT Infrastructure supplied to the Goa for

this Project shall have no defects arising from design or workmanship or any act or

omission of the selected Bidder. The warranty shall remain valid for the Contract

period on all the items supplied as per the Contract.



b. The selected Bidder shall replace any parts/ components of the IT infrastructure

supplied for the Project if the components are defective and during the entire

warranty period the selected Bidder shall apply latest upgrades for all the hardware

components after appropriate testing. The Info Tech Corporation of Goa Ltd. (ITG) will

not pay any additional costs separately for warranty and the overall IT

infrastructure cost quoted by the selected Bidder shall include the same.

IV. Since the Project aims to reuse the common infrastructure created under SDC, GBBN,

ESO/CSCS‟S & CFC‟S ; the selected Bidder will also be required to coordinate with SDC,

GBBN, SSDG, ESO/CSCS‟S & CFC‟S teams to ensure that uptime and performance

requirements of the RFP are met. However, the selected Bidder shall be held solely

responsible for performance and service levels of any infrastructure deployed by the

selected Bidder as part of this Contract.

V. Knowledge Transfer

a. At the end of the Contract period, the selected Bidder will be required to provide

necessary handholding and transition support to designated staff or any other

agency that is selected for maintaining the system post the Contract with the

selected Bidder. The handholding support will include but not be limited to,

conducting detailed walkthrough and demonstrations for the IT Infrastructure,

handing over all relevant documentation, addressing the queries/clarifications of

the new agency with respect to the working / performance levels of the

infrastructure, conducting training sessions etc.

b. Knowledge Transfer is an integral part of the scope of work of the selected Bidder.

This will have to be done even in case the Contract with the Bidder ends or is

terminated before the planned timelines.

Please note that this is only an indicative list. Any other activity, over and above these, as may be

deemed necessary by the selected Bidder to meet the service levels and requirements specified in

this Contract are also required to be performed by the selected Bidder at no additional cost.



3.6 Exit Management

4.6.1 Purpose

I. This sets out the provisions, which will apply on expiry or termination of the MSA, the

Project Implementation, Operation and Management SLA.

II. In the case of termination of the Project Implementation and/or Operation and

Management, the Parties shall agree at that time whether, and if so during what period, the

provisions of this Schedule shall apply.

III. The Parties shall ensure that their respective associated entities carry out their respective

obligations set out in this Exit Management Schedule.

4.6.2 Transfer of Assets

I. Info Tech Corporation of Goa Ltd. (ITG) shall be entitled to serve notice in writing on the

bidder at any time during the exit management period as detailed hereinabove requiring

the bidder and/or its sub-contractors to provide the Info Tech Corporation of Goa Ltd. (ITG)

with a complete and up to date list of the Assets within 30 days of such notice. Info Tech

Corporation of Goa Ltd. (ITG) shall then be entitled to serve notice in writing on the bidder at

any time prior to the date that is 30 days prior to the end of the exit management period

requiring the bidder to sell the Assets, if any, to be transferred to Info Tech Corporation of

Goa Ltd. (ITG) or its nominated agencies at book value as determined as of the date of such

notice in accordance with the provisions of relevant laws.

II. In case of contract being terminated by Info Tech Corporation of Goa Ltd. (ITG), Info Tech

Corporation of Goa Ltd. (ITG) reserves the right to ask bidder to continue running the project

operations for a period of 6 months after termination orders are issued.

III. Upon service of a notice under this Article the following provisions shall apply:

A. in the event, if the Assets to be transferred are mortgaged to any financial

institutions by the bidder , the bidder shall ensure that all such liens and liabilities

have been cleared beyond doubt, prior to such transfer. All documents regarding

the discharge of such lien and liabilities shall be furnished to the Info Tech Corporation of

Goa Ltd. (ITG).

B. All risk in and title to the Assets to be transferred / to be purchased by the Info Tech

Corporation of Goa Ltd. (ITG) pursuant to this Article shall be transferred to Info Tech

Corporation of Goa Ltd. (ITG), on the last day of the exit management period.

C. Info Tech Corporation of Goa Ltd. (ITG) shall pay to the bidder on the last day of the

exit management period such sum representing the Net Block (procurement price

less depreciation as per provisions of Companies Act) of the Assets to be transferred

as stated in the Terms of Payment Schedule.

D. Payment to the outgoing bidder shall be made to the tune of last set of completed

services / deliverables, subject to SLA requirements.

E. The outgoing bidder will pass on to Info Tech Corporation of Goa Ltd. (ITG) and/or to

the Replacement bidder , the subsisting rights in any leased properties/ licensed



products on terms not less favourable to Info Tech Corporation of Goa Ltd. (ITG)/

Replacement bidder , than that enjoyed by the outgoing bidder .

4.6.3 Cooperation and Provision of Information

During the exit management period:

I. The bidder will allow the Info Tech Corporation of Goa Ltd. (ITG) or its nominated

agency access to information reasonably required to define the then current mode of

operation associated with the provision of the services to enable the Info Tech

Corporation of Goa Ltd. (ITG) to assess the existing services being delivered;

II. promptly on reasonable request by the Info Tech Corporation of Goa Ltd. (ITG), the

bidder shall provide access to and copies of all information held or controlled by

them which they have prepared or maintained in accordance with this agreement

relating to any material aspect of the services (whether provided by the bidder or

sub-contractors appointed by the bidder). The Info Tech Corporation of Goa Ltd. (ITG)

shall be entitled to copy of all such information. Such information shall include

details pertaining to the services rendered and other performance data. The bidder

shall permit the Info Tech Corporation of Goa Ltd. (ITG) or its nominated agencies to

have reasonable access to its employees and facilities as reasonably required by the

Chairman, PIU to understand the methods of delivery of the services employed by the

bidder and to assist appropriate knowledge transfer.

4.6.4 Confidential Information, Security and Data

I. The System integrator will promptly on the commencement of the exit

management period supply to the Info Tech Corporation of Goa Ltd. (ITG) or its

nominated agency the following:

A. information relating to the current services rendered and customer and

performance data relating to the performance of sub-contractors in relation to

the services;

B. documentation relating to Computerization Project‟s Intellectual Property Rights;

C. documentation relating to sub-contractors;

D. all current and updated data as is reasonably required for purposes of Info

Tech Corporation of Goa Ltd. (ITG) or its nominated agencies transitioning the

services to its Replacement bidder in a readily available format nominated by

the Info Tech Corporation of Goa Ltd. (ITG), its nominated agency;

E. all other information (including but not limited to documents, records and

agreements) relating to the services reasonably necessary to enable Info Tech

Corporation of Goa Ltd. (ITG) or its nominated agencies, or its Replacement

bidder to carry out due diligence in order to transition the provision of the

Services to Info Tech Corporation of Goa Ltd. (ITG) or its nominated agencies, or

its Replacement bidder (as the case may be).



II. Before the expiry of the exit management period, the bidder shall deliver to the Info

Tech Corporation of Goa Ltd. (ITG) or its nominated agency all new or up-dated

materials from the categories set out in Schedule above and shall not retain any

copies thereof, except that the bidder shall be permitted to retain one copy of such

materials for archival purposes only.

III. Before the expiry of the exit management period, unless otherwise provided under

the MSA, the Info Tech Corporation of Goa Ltd. (ITG) or its nominated agency shall

deliver to the bidder all forms of bidder confidential information, which is in the

possession or control of Chairperson, PIU or its users.

4.6.5 Employees

I. Promptly on reasonable request at any time during the exit management period, the

bidder shall, subject to applicable laws, restraints and regulations (including in

particular those relating to privacy) provide to the Info Tech Corporation of Goa Ltd.

(ITG) or its nominated agency a list of all employees (with job titles) of the bidder

dedicated to providing the services at the commencement of the exit management

period.

II. Where any national, regional law or regulation relating to the mandatory or

automatic transfer of the contracts of employment from the bidder to the Info Tech

Corporation of Goa Ltd. (ITG) or its nominated agency, or a Replacement bidder

("Transfer Regulation") applies to any or all of the employees of the bidder, then the

Parties shall comply with their respective obligations under such Transfer

Regulations.

III. To the extent that any Transfer Regulation does not apply to any employee of the bidder,

department, or its Replacement bidder may make an offer of employment or contract for

services to such employee of the bidder and the bidder shall not enforce or impose any

contractual provision that would prevent any such employee from being hired by the

Chairperson, PIU or any Replacement bidder.

4.6.6 Transfer of Certain Agreements

On request by the Info Tech Corporation of Goa Ltd. (ITG) or its nominated agency the bidder shall

effect such assignments, transfers, licences and sub-licences as the Chairperson, PIU may require in

favour of the Chairperson, PIU, or its Replacement bidder in relation to any equipment lease,

maintenance or service provision agreement between bidder and third party lessors, vendors, and

which are related to the services and reasonably necessary for the carrying out of replacement services by

the Info Tech Corporation of Goa Ltd. (ITG) or its nominated agency or its Replacement bidder.

4.6.7 Rights of Access to Premises

I. At any time during the exit management period, where Assets are located at the bidder's

premises, the bidder will be obliged to give reasonable rights of access to (or, in the case of

Assets located on a third party's premises, procure reasonable rights of access to) the Info



Tech Corporation of Goa Ltd. (ITG) or its nominated agency and/or any Replacement bidder

in order to make an inventory of the Assets.

II. The bidder shall also give the Info Tech Corporation of Goa Ltd. (ITG) or its nominated agency

or its nominated agencies, or any Replacement bidder right of reasonable access to the

Implementation Partner's premises and shall procure the Info Tech Corporation of Goa

Ltd. (ITG) or its nominated agency or its nominated agencies and any Replacement bidder

rights of access to relevant third party premises during the exit management period and for

such period of time following termination or expiry of the MSA as is reasonably necessary

to migrate the services to the Info Tech Corporation of Goa Ltd. (ITG) or its nominated agency,

or a Replacement bidder.

4.6.8 General Obligations of the bidder

I. The bidder shall provide all such information as may reasonably be necessary to effect as

seamless a handover as practicable in the circumstances to the Info Tech Corporation of Goa

Ltd. (ITG) or its nominated agency or its Replacement bidder and which the bidder has in its

possession or control at any time during the exit management period.

II. For the purposes of this Schedule, anything in the possession or control of any bidder,

associated entity, or sub-contractor is deemed to be in the possession or control of the

bidder.

III. The bidder shall commit adequate resources to comply with its obligations under this Exit

Management Schedule.

4.6.9 Exit Management Plan

I. The bidder shall provide the Info Tech Corporation of Goa Ltd. (ITG) or its nominated agency

with a recommended exit management plan ("Exit Management Plan") which shall deal with at

least the following aspects of exit management in relation to the MSA as a whole and in relation to

the Project Implementation, and the Operation and Management SLA.

A. A detailed program of the transfer process that could be used in conjunction with a

Replacement bidder including details of the means to be used to ensure continuing

provision of the services throughout the transfer process or until the cessation of the

services and of the management structure to be used during the transfer;

B. plans for the communication with such of the bidder's sub-contractors, staff,

suppliers, customers and any related third party as are necessary to avoid any

material detrimental impact on the Info Tech Corporation of Goa Ltd. (ITG)‟s

operations as a result of undertaking the transfer;

C. (if applicable) proposed arrangements for the segregation of the bidder's networks

from the networks employed by Info Tech Corporation of Goa Ltd. (ITG) and

identification of specific security tasks necessary at termination;

D. Plans for provision of contingent support to Info Tech Corporation of Goa Ltd. (ITG),

and Replacement bidder for a reasonable period after transfer.



II. The bidder shall re-draft the Exit Management Plan annually thereafter to ensure that it is

kept relevant and up to date.

III. Each Exit Management Plan shall be presented by the bidder to and approved by the Info

Tech Corporation of Goa Ltd. (ITG) or its nominated agencies.

IV. The terms of payment as stated in the Terms of Payment Schedule include the costs of the

bidder complying with its obligations under this Schedule.

V. In the event of termination or expiry of MSA, and Project Implementation, each Party shall

comply with the Exit Management Plan.

VI. During the exit management period, the bidder shall use its best efforts to deliver the

services.

VII. Payments during the Exit Management period shall be made in accordance with the Terms

of Payment Schedule.

VIII. This Exit Management plan shall be furnished in writing to the Info Tech Corporation of Goa

Ltd. (ITG) or its nominated agencies within 90 days from the Effective Date of this

Agreement.

4 Detailed Implementation and Roll-out Plan

I. Bidder shall prepare a detailed roll-out plan for each of the districts in the phase and get the

same approved by the Info Tech Corporation of Goa Ltd. (ITG). Bidder is also responsible for

conducting workshops for the key officers (Info Tech Corporation of Goa Ltd. (ITG), DoIT,

District Core Team, NIC, SPMU, SeMT and NPMU) of the Districts / State for presenting

the District-Wise roll-out plan and gets the approval of the same.

II. Before getting the final approval of the State Nodal Officer, the bidder shall also provide

the necessary assistance for the key stakeholder of the Districts / State during the design

and implementation of e-District project in the Goa. A detailed rollout checklist should be

maintained for migrating application to production as well as for location readiness.

III. One of the important factors that would determine the success of the e-District

implementation in the state of Goa is the continuous availability of domain experts like

Project Manager, Database Administrator, Change Management Expert, Technical

Assistance, to the implementation team which would be selected with the approval of SDA.

Bidder shall put together a team of domain experts with a minimum of 10 years of

experience in the State Departments who will work on this project on a full time basis

during the entire duration of the project.



5 Annexures

5.1 Template for Capturing Office Wise Requirements

S.

No

District Office Name Office ID Office Address e-District

Service

being

delivered

from this

office

Approx

. No. of

Users

Level of

Office

(Distric

t / Block

/

Taluka/

Others)

Network

Availability

?

(Yes/ No)

Additional

H/W

Required?

(Yes/ No)

Site

Preparation

Required?

(Yes/ No)

1. NORTH

GOA

/SOUTH

GOA

Collectorate

Office

(North/South

)

COLLECT

ORATE

South Collectorate,

Margao, Goa

North Collectorate

Panaji,Goa

10 84 26 YES YES NO

2. NORTH

GOA

/SOUTH

GOA

Dept. of

settlement

and land

records

DSLR Collectorate

Building, Swami

Vivekanand Road,

Panaji. 403001

1 24 6 YES YES NO

3. NORTH

GOA

/SOUTH

GOA

State

Information

Commission

SIC SIC, Shrama Shakti

Bhavan, Ground

Floor, Patto,

Panaji, Goa -

403001.

1 7 1 YES YES YES (1

Office)

4. NORTH

GOA

/SOUTH

Municipality MUN North Goa:- H.NO.

238, Salcho wado

Assonora Bardez

1 36 13 YES YES NO



GOA Goa;

South Goa:-

Curchorem-Cacora

Municipal Council,

Curchorem, Goa

5. NORTH

GOA

/SOUTH

GOA

Directorate of

Panchayat

PYT Directorate of

Panchayats, Junta

House, 3rd Floor,

Panaji, Tiswadi,

Goa-4o3001

1 210 205 YES YES NO

6. NORTH

GOA

/SOUTH

GOA

Dept. of

Transport

TRANS Directorate of

Transport, Junta

House, 1st Floor,

Panaji-Goa

2 40 13 YES YES NO

7. NORTH

GOA

/SOUTH

GOA

Dept. of

Fisheries

FISH Directorate of

Fisheries, Govt.of

Goa,Dayanand

Bandokar Marg

Panaji - Goa.

1 15 6 YES

(Required in

4 sub offices)

YES YES ( 4

offices)

8. NORTH

GOA

/SOUTH

GOA

Dept. of

Tourism

TOUR Department of

Tourism

Government of Goa

Purshottam

Bhagwan Building

Dr. Atmaram

Borkar Road, Opp.

Hotel Nova Goa,

1 13 7 YES

(Required in

1 sub offices)

YES YES (2

offices)



Panaji, Goa- 403 001

9. NORTH

GOA

/SOUTH

GOA

Captain of

Ports

COP Captain of Ports,

Dayanand

Bandodkar Road,

Near Old

Secretariat,

Panaji, Goa –

403001

2 9 2 YES YES NO

10. NORTH

GOA

/SOUTH

GOA

Registration

Dept.

REGMR Shrama Shakti

Bhavan,, Patto,

Panaji, Goa -

403001.

1 24 15 YES YES YES (1

office)

11. NORTH

GOA

/SOUTH

GOA

Dept. of

Sports

SPORT Directorate of

Sports and Youth

Affairs,

Campal, Panaji -

Goa

4 20 13 YES

(required in

10 offices)

YES YES (10

offices)



5.2 Template for Capturing Network Connectivity Requirement

S.

No

Office ID GBBN

Available?

(Yes / No)

GBBN Available GBBN Not Available

Type of

connectivity

Existing

service

provider

Service level

/ baseline

(Up to PoP)

Distance

from

nearest

GBBN

POP

Bandwidth

required

Type of

Technology

to be used

Equipment

(Router,

Switches,

OFC, etc.)

required

1. COLL. OFF YES Optical Fibre

Cable

UTL (United

Technologies

Limited)

2 Mbps 500 mtr.

Approx.

- - -

2. DSLR YES Optical Fibre

Cable

UTL (United

Technologies

Limited)

2 Mbps 500 mtr.

Approx.

- - -

3. SIC YES Optical Fibre

Cable

UTL (United

Technologies

Limited)

2 Mbps 500 mtr.

Approx.

2 Mbps - -

4. MUN YES Optical Fibre

Cable

UTL (United

Technologies

Limited)

2 Mbps 500 mtr.

Approx.

- - -

5. PYT YES Optical Fibre

Cable

UTL (United

Technologies

Limited)

2 Mbps 500 mtr.

Approx.

- - -

6. TRANS YES Optical Fibre UTL (United 2 Mbps 500 mtr. - - -



Cable Technologies

Limited)

Approx.

7. FISH YES

(Required in

4 Sub Offices)

Optical Fibre

Cable

UTL (United

Technologies

Limited)

2 Mbps 500 mtr.

Approx.

2 Mbps - -

8. TOUR YES

(Required in

1 office)

Optical Fibre

Cable

UTL (United

Technologies

Limited)

2 Mbps 500 mtr.

Approx.

2 Mbps - -

9. COP YES Optical Fibre

Cable

UTL (United

Technologies

Limited)

2 Mbps 500 mtr.

Approx.

- - -

10. REGMR YES Optical Fibre

Cable

UTL (United

Technologies

Limited)

2 Mbps 500 mtr.

Approx.

- - -

11. SPORT YES

(required in

10 offices)

Optical Fibre

Cable

UTL (United

Technologies

Limited)

2 Mbps 500 mtr.

Approx.

2 Mbps - -

Note: This is a sample table – to be modified based on the actual requirements of the proposed solution by SI’

Type of Technology to be used has to be updated based upon proposed solution by bidder and approved by DoIT & ITG.

Equipment (Router, Switches, OFC, etc.) required has to be updated based upon proposed solution by bidder/SI and approved by DoIT & ITG



5.3 Tentative Hardware Requirement

e-District Goa

S. No Hardware Type Hardware to be procured

1. Desktop/ Computer 369

2. Laptop 1

3. Digital Web camera 10

4. Heavy Duty Scanners (A4 size) 9

5. Heavy Duty Scanners (A3 size) 3

6. Heavy Duty Laser Printer (A4 size) 108


8. Passbook Printers 2

9. UPS (1 KVA, Online) 178

10. Networking Points 400

11. UPS Electrical Points 500 Note: This is a reference table – to be modified based on the actual requirements of the proposed solution by the bidder

5.4 Template for Capturing Site Preparation Requirement (If Any)

S. No Office ID Site Preparation Required to

be done?

(Yes / No)

If Yes, then details of Site Preparation requirement

1. GOA. COLLECTORATE NORTH NO

2. GOA. COLLECTORATE SOUTH NO

3. GOA.DSLR NO

4. GOA.SIC YES (1 Office) LAN, Networking & Electrical work (if any)



5. GOA.MUN NO

6. GOA.PYT NO

7. GOA.TRANS YES ( 4 offices) LAN, Networking & Electrical work (if any)

8. GOA.FISH YES (2 offices) LAN, Networking & Electrical work (if any)

9. GOA.TOUR NO

10. GOA.COP NO

11. GOA.REGMR NO

12. GOA.SPORT YES (10 offices) LAN, Networking & Electrical work (if any)

Note: This is a reference table – to be modified based on the actual requirements of the proposed solution by the bidder

Details of site preparation requirement has to be updated based upon proposed solution by bidder and approved by DoIT & ITG

5.5 Template for Data Entry

I. The bidder has to deploy suitable sets of workable set of computers and data entry operator for completing the data entry

assigned to them with in timeline.

II. Among all system there should be one server system.

III. The data entry will be done on the provided software.

IV. Quality Check

o The bidder should ensure 98% data accuracy.

o Random checking will be conducted by the officer/agency appointed by the data digitization committee.

V. Location of work



o Centralized – District Administration North & South District and other line departments will provide space for setting

up temporary working office in District for project duration.

VI. Loss of data

o Bidder should take good care of all Government records and will be responsible for security of the record from time of

receipt to time of delivery.

o Penalty for per record will be charged against the loss or damage of record.

o The bidder should not accept illegible record. Non-readable record at the time of returning of the data will be

considered as damaged record.

VII. Selected bidder/SI shall conduct a ground study service wise to bring out the exact Data Digitization Requirement for the

services selected for e-District Roll-Out. The approximate nos. of records for Data Entry is already specified table below.

S.No Department

Name

Service Name Job description Estimated Quantity (approx.) Location of

the database

where it is

placed

Approx.

Transactions

(Approx.) / per

office (Monthly)

No Of

offices

Total Units

(Approx.)

1

Collectorate

Office (North

Goa /South

Goa)

Issuance of Income

certificate

Digitization of

filled

application form

& Output 400

26

10400

Refer to

Annexure of

RFP Vol. I for

office details



2

Issuance of Domicile

certificate

Digitization of

filled

application form

& Output 100 2600

3

Issuance of Residence

certificate

Digitization of

filled

application form

& Output 7355 191230

4

Issuance of Divergence

certificate

Digitization of

filled

application form

& Output 415 10790

5

Issuance of

Caste/Community

certificate

Digitization of

filled

application form

& Output 1933 50258

6

Issuance of Matriz

certificate - 50 1300

7

Revenue court cases-Case

listing/adjournment/stay/

Final/Status

Digitization of

filled

application form

& Output 846 21996

8

Application/Renewal of

Arms License

Digitization of

filled

application form

& Output 40 1040



9

Application for Sound

permission

Digitization of

filled

application form

& Output 23 598

10

Application and

Disbursement of Relief for

victims of Natural

Calamity

Digitization of

filled

application form

& Output 15 390

11

Dept. of

settlement

and land

records Issuance of Form I & XIV - -

6

-

12

State

Information

Commission RTI filling and status

services

Digitization of

filled

application form

& Output NA

1 + 8 ( other

concerned

departments

covered

under e-

District) NA

13

Municipality Issuance of Birth/Death

certificate

Digitization of

filled

application form

& Output 50000

3

150000

14

Directorate of

Panchayat Issuance of Birth/Death

certificate

Digitization of

filled

application form 487

205

99835



& Output

15 Dept. of

Transport

Application for grant of

subsidy for replacement of

buses/mini buses above 15

years old

Digitization of

filled

application form

& Output TBD

13

TBD

16

Application for grant of

subsidy for Yellow/Black

Motorcycle ,Auto

Rickshaw, Taxi Scheme

2003

Digitization of

filled

application form

& Output TBD TBD

17

Dept. of

Fisheries Application for

Registration/ Renewal of

Fishing Nets

Digitization of

filled

application form

& Output 200

6

1200

18

Dept. of

Tourism Registration of New water

sports activity

Digitization of

filled

application form

& Output TBD

7

TBD

19

Captain of

Ports Registration/Renewal of

Inland Vessel

Digitization of

filled

application form

& Output 20

2

40



20

Registration/Renewal of

Water Sport Vessel

Digitization of

filled

application form

& Output 900 1800

21

Registration

Dept. Application for Marriage

Registration certificate

Digitization of

filled

application form

& Output 4500

15

67500

22

Dept. of

Sports

Registration of Schools for

participation in Games

Digitization of

filled

application form

& Output 400

13

4800

23

Application for Sportsmen

certificate

Digitization of

filled

application form

& Output 60 720

24

Registration/Application

for entry into State Youth

Festival

Digitization of

filled

application form

& Output 100 1200

25

Application for grant-in-

aid for various Educational

Institutes

Digitization of

filled

application form

& Output 150 1800



26 All

Departments

Recruitment form for non-

gazette post of various

Depts. across State

Digitization of

filled

application form

& Output

-

27

Form for Scheme

management

Digitization of

filled

application form

& Output

-

Total 633897 Refer to Annexure in As Is Process for sample of form & fields to be digitized.

Digitization & Scanning has to be done in consultation with concerned department as per requirement and may vary from case to case.

The figures in this table are for reference purpose only and need to be modified on the actual requirement.



5.6 Template for Preparing FRS and Process Maps (with illustrative data)

Sample Process and FRS



Registration DepartmentR

egis

trar

/Su

b R

egis

trar

Dea

ling

/Reg

istr

atio

n

Cle

rkE

-Dis

tric

t A

pp

licat

ion

Ap

plic

ant

(E

SO

)

Marriage registration certificate

Yes

On receiving

signature from

applicant marks

dealing/

registration clerk

for publication of

notice

Conducts

verification (if

required) & finvites

bride & groom for

signature

Start

Form Availability

Component

System update

database &

notifies

Registrar/Sub

registrar &

applicant

Receives

application

Verifies bride &

groom and witness

Identification

Applicant apply

online or in ESO

Updates marriage

registration

certificate &

Notifies

Signs to

validate

Payment

Component

System updates

database &

notifies

concerned

officials &

applicant for

publication & 10

day date as per

notice

Application Receipt

Component

System

Updates

database

Receives notification &

copy of marriage

registration certificate

(hard or soft copy)

with unique no

System logs the application

assigns unique number &

Notifies registrar/Sub registrar

END

Verifies

documents &

application

No

Invites bride &

groom for signature

& marks copy to

dealing/registration

clerk for

verification ( if

required)

Information

Availability

Component

System Gives

service related

information/

Notification

System Updates

database

Applicants comes

to Registrar Office

and signs marriage

register in person

Bride & groom with

two witnesses

appears in registrar

office after 10 days

of notice

Take signature from

applicant & witnesses on

edistrict application with

biometric identifications

& registers the marriage

marks dealing/

registration clerk for

Issue of marriage

registration certificate

Receives

intimation

Uploads /

publishes on

state/department

portal with FAQ

Yes

No

Generates

online

marriage

registration

certificate

with unique

No.

after

collecting

fee if any

Updates data

base with issue

of certificate to

applicant

(printed copy or

soft copy by

mail)

Receives

intimation

RFP for Selection of System Integrator for State-wide roll-out of eDistrict MMP in Goa – Volume II

To-Be Process for Marriage registration certificate

S.No. Responsibility Process Details

1. Citizen Apply for issue of Marriage registration certificate at ESO/CSCS Centre or Login to state/e-District portal and on successful submission of requested service receives the application receipt/ acknowledgement no.

2. ESO/CSCS Operator

ESO/CSCS operator logs into the e-District application through user name and password security. ESO/CSCS operator authenticates the system login through the same. Biometrics feature can be used for log In

3. After getting satisfied ESO/CSCS operator submits the service request and provides applicant a unique service request number/acknowledgement and prospective date of delivery.

4. Registrar/Sub Registrar

Receive a notification from the e-District application for Marriage registration certificate Verifies received application and documents And forwards to dealing /registration clerk for processes-sing of the application and to conduct verification (if required)

5. Dealing Registration/Clerk

Conducts verification (if required)

6. Invites Bride & Groom for signature

7. Applicant Visits registration department on the date as mentioned in the notice for appearance from registration department online through email, SMS, and through ESO/CSCS

8. ESO/CSCS Operator

Intimates applicant to appear on the date as mentioned on appearance notice

9. Civil registrar/ Sub registrar

Sends notification (through e-District Application) to applicant to be present on the date as mentioned or suggest if applicant require some other date (with reason)

10. Marks application for publication of notice after obtaing the signatures of Bride & Groom and forwards to dealing/ registration clerk

11. Dealing/ Section Clerk

Publishes notice as required through e-District application for a period of 10 working days

12. Citizen/ Applicant

Bride-groom, Bride and 2 witnesses [ (Parents ( if required) , additional witnesses of Interpreter, etc., if advised) ] appears in registration office after 10 working days

13. Civil Registrar Captures signatures and biometric identifications of bride & groom and of 2 witnesses on the marriage registration certificate e-District application and registers marriage. Forwards application to the concerned Dealing/Registration clerk for processing & verification of marriage registration certificate

14. Dealing/ Section Clerk

Provides a printed or a soft PDF copy of the marriage certificate with unique Certificate no. digitally signed by the Registrar to the applicant and updates e-District application for the same after collecting fee (if any)

15. Citizen/ Applicant

Receives printed or a soft PDF copy of the marriage certificate and a notification through email or sms or through ESO/CSCS

16. e-District Notifies & Generate a predefined standard text message of



application confirmation on successful registration of service request and information on the department where the application file has been sent Intimates citizen through SMS or email to collect service related output/notice whenever available with FAQ

17. -District application checks the application request and does the following. Does not accept application submission if the application does not fill mandatory fields for eligibility Sorts & scrutinize application as per different categories set by department (if any). Generates unique acknowledgement no. for every submitted application Perform data validation checks on the input. In case of data being duplicated, display the existing service request id & existing record if any

18. Notifies to authorized authority and concerned official for every activity performed regarding service request on e-District application

Tracking Status of Marriage registration certificate

The Status tracking component is the new feature which is being proposed through e-District application to the applicant. This feature would provide a „Window‟ to applicant to know the status of their application during execution of orders. The status tracking component allows the following medium to provide the information – ESO/CSCS Centre - Applicant visits any ESO/CSCs centre and provides the acknowledgement number. The operator would retrieve the information from the e- District application and provide the information to applicant Mobile Service – If applicant have provided the mobile number during registration process of the service, then the system generated SMS would be send to the applicant updating the status of the service. E-mail Service – If applicant has provided the email Id. during registration process of the service, then the system generated e-mail would be send to the applicant updating the status of the service. State/Department Web Portal: The applicant can also know the status of the application through logging onto the e-District web portal. By entering the acknowledgement number the applicant would be provided with the status details of the application Call Center: The applicant can dial in to a call center and know the status of the application by quoting his application number.

Tracking Status

S.No. Responsibility Process Details


e-District application would generate a predefined standard text message or updated of confirmation on successful registration of service request and information on the department where the file has been sent.


e-District application would generate a predefined/customized standard text message or message updated by department regarding the rejection of the application


e-District application would generate a predefined standard text message mentioning the application is undergoing official



verification. Applicant can also make request through SMS / ESO/CSCS center/ Call center for status


e-District application would generate a predefined/customized standard text message or message updated by department of the physical verification date of the application and the availability of the notice. Applicant can also make request through SMS / ESO/CSCS/ Call center for status


e-District application would generate a predefined/customized standard text message or message updated by department mentioning the rejection and the reason for rejection. Applicant can also make request through SMS / ESO/CSCS/ Call center for status


e-District application would generate a predefined/customized standard text message of the availability of Marriage registration certificate that can be either downloaded from e-District Application. Applicant can also make request through SMS / ESO/CSCS/ Call center for status

Data Base Required (Marriage registration certificate) Marriage registration certificate database will contain details like: 1. Name of Bride & Groom 2. Application Number 3. Birth Certificate of Bride and groom 4. Domicile/residence Cert. (Continuous residence) issued by Mamlatdar/ Sarpanch of

Taluka/Village 5. NOC from the Civil Registrar of other taluka if one of the party resides in that taluka (for final

registration) 6. Fee (as prescribed by department) 7. Age 8. Address 9. Requested information details 10. Details of witness 11. Declaration of Marriage form with supporting documents

The database would also maintain an application summary, Information report from Concerned department official and copy of initial permission if any (if required) The database for Marriage registration certificate of all the running applications after go live will be maintained incrementally. This digitized database would be referred to as authenticated database for issuing digitized copy of Marriage registration certificate to applicant. All the data in the e-District database would be archived every six month The following are the indicative fields of the proposed database: S. No. Databases Needed for Online Validation

1. Name of Bride-groom & Bride

2. Address of Bride-groom & Bride Village Taluka District

3. Information of Marriage registration certificate application

4. Parents name of bride & groom



5. Office filed at

6. Approval/Rejecting Authority

7. Validation Concerned department official

8. Allotted application number

9. Contact details (e.g. mobile no. , email Id, etc.)

10. Date & Time of filling the marriage registration application

11. Date & Time of issue of marriage registration certificate

12. Date & Time of issuing/rejecting for Issuance of marriage registration certificate

13. Status of Application

14. Details of witness

15. Remarks

16. Any other records ( as required by department)

Digital Record e-District Application All transactional records pertaining to the issuance of marriage registration certificate applications service request should be maintained in the State/e-District database. Date and time stamping on all the action taken on any given service request by the involved actors should be maintained. State/e-District database should maintain the approved and closed service request separately tagged with the unique „Document Serial Number‟ generated for the documents.

Designation Create Read Update Delete

Registrar Yes Yes Yes No

Sub- Registrar Yes Yes Yes No

Dealing/ Registration Clerk Yes Yes Yes No

General Anonymous Access

No Yes No No

Record View for Logged In User Login View would be made for all the users of the application would be common Records view for a Logged in Civil Registrar/Sub Registrar, Dealing/Registration Clerk and any Department official in the e-District application

Sr.No Fields Description of the view

1. Marriage registration certificate section of Registration Department Details

2. Application Number

3. File No:

4. Date of applying for Marriage registration certificate

5. Date of service summaries or date of intimation of application

6. Name of the Bride & Groom (s)

7. Name of validating Civil Registrar/Sub Registrar

8. Name of the Dealing /Registration Clerk(s)

9. Issuance of Marriage registration certificate Sought for

10. Section(s) under Issuance of Marriage registration certificate is issued

11. Name of witnesses

12. Whether Marriage registration certificate issued or not?

13. Specify if the reason for rejection (if rejected)

14. Date of Issue of Marriage registration certificate

15. Remarks / Summary of the application

16. Status of the Application (Registered, under progress/Approved/Rejected)

17. Supporting documents



The fields required in uploading a Final copy of Marriage registration certificates are as follows:


1. Issuance of Marriage registration certificate fields

2. Option to add remarks & uploads

3. Date of application request

4. Application request no.

5. Proposed date of delivery

6. Option to verify from Database

7. Action option to lead to next Record View

Concerned department official Record View Concerned department official view related service request allocated


1. Marriage registration certificate fields

2. Remarks (if any)

3. Option to add remarks & update

4. Option to verify from database

5. System generated application no.

6. Date of service request

7. Proposed date of delivery

8. Approval option / Rejection option

9. Save / Submit option

Digital Signature Requirement The following table specifies the designations that need to receive the Digital Signatures or the number of digital signatures required: Digital Signatures Required: Certificate

Sr.No Designation Digital Signature Requirement (Nos.) for both Districts

1. Civil Registrar ...(South Goa) + ……(North Goa)

2. Sub Registrar …(South Goa) + ………(North Goa)

3. Other authorized department official ( if any)

…(South Goa) + ………(North Goa)

Management Information System (MIS) The e-District application should meet the information requirement of district administration and should be able to generate required reports on a defined frequency. The e-District application should generate the following reports – Standard Reports MIS Report 1: Overall Marriage registration certificate Data – Daily/Weekly/Monthly/Yearly Reports

S. No Name of the Registration Department Office , Dept. / Issuing section

Number of Applications received

Number of Marriage registration certificate Issued

Number of Applications Pending

Amount of application fees collected

1.



2.

3.

4.

5.

Customized Reports The e-District application should be able to generate customized report on demand of the user. The authority to generate customized report would be with the State Registrar, District Registrar, and Registrar/Sub Registrar, Dealing /Registration clerk and Concerned department official Any officer senior to Civil Registrar of Registration Department would also have the rights to generate customized report. The e-District application should be able to generate the customized report on the following parameters – 1. Between defined periods - “From- date” to “To-Date” 2. Pendency report - Date wise MIS Report 2: Between defined periods - “From- date” to “To-Date”

Sr.No.

Date (descending order)

Unique Service Request number

DSN Number

Sub service requested (Marriage registration certificate)

Applicant Name Status

1

MIS Report 3: Pendency Report – Date Wise

Sr.No

Date (descending order)

Unique Service Request number

Sub service requested (Certificate)

Application Status

Proposed date of service delivery

Actual date of delivery/ Status

1

MIS Report 4

Sr.No.

Name / Designation of the Officer

Applications Completed within defined SLAs

Number of Application exceeding SLAs

Current owner of the application after escalation

1

2 3 4

MIS Report 5

Sr. No.

Name of the Registration Department office & Issuing Section

Application requiring Concerned department official validation

Total number of Application received

%age of the application requiring Concerned department official validation

1

2

3

4



Service Level

S. No Activity

Service Level in

days

Service Level

from day of

Application

1. Application Receipt and Forward to

Registrar/Sub Registrar.

1 day 1st day

2. Registrar/Sub Registrar checks details in

the Database

1 day 2nd day

3. Registrar/ Sub Registrar Approves or

Rejects the application using his digital sign:

- If approves then order for publication of notice (10 days statutory waiting period) after taking signature of applicant

- Orders for verification if required

1 day

2nd day

4. Registrar/Sub Registrar officially takes

signature of bride & groom supporting two

witness

1 day 12th day

5. Issues Marriage Registration Certificate to

bride & groom

1 day 12th day

Auto Escalation Matrix

Auto Escalation Matrix: Marriage Registration Certificate

S.No Activity Activity

Owner

Service

Level

L1 L2 L3

Design

ation

Tim

e

Design

ation

Tim

e

Design

ation

Time

1. Registrar checks details in the Database and either approves/rejects the application or forwards for verification

Registrar/Sub Registrar

1 day Registrar/Sub Registrar

2days

District Registrar

2 days

State Registrar

2day

2. Processing of Marriage registration certificate for publication

Dealing/ Registration Clerk

1day Registrar/Sub Registrar

2day Registrar/Sub Registrar

1 day

District registrar

1day

3. Validation & Issuance of Marriage registration certificate

Registrar/Sub Registrar

1 day Registrar/Sub Registrar

1days

District registrar

2days

State registrar

1day



Functional Requirement Specification – (Marriage Registration)

Sr. No Description

1. System shall allow applicant/ESO/CSCS/CFC operator to select Registration Department from the Home page of the State Portal

2. System shall allow applicant to select application for Application for marriage registration certificate on the department page of the state portal

3. System shall allow registration of applicant for future login and ease

4. System shall allow applicant to fill/edit e-Form/Application online & offline

5. System shall accept filled e-Form/application of new applicants

6.


1. Name (Bride & Groom) 2. Contact Details 3. PIN 4. Age 5. Area of residence 6. Details as required in application form used at present 7. Unique Identification (UID) 8. E-mail id (if any) 9. Mobile No. (if any)

7. System shall be able to identify the user logging into system using the login component.

8.

System shall be able to provide information to the citizens about Marriage services both in public as well as private domain as per the „Information component‟ -Web access to information content in public domain - e-District application access to information content

9. System shall be able to channel as per the process map and description for the service

10. System shall make available the latest copy of the Application Form online (24x7) as per the Form Availability component.

11. System shall allow the operator to fill in the online application on behalf of citizen availing the service as per the „application receipt‟ component

12. System shall be able to generate a unique registration number during registering an applicant with the application.

13. System shall be able to identify the applicant uniquely based on this registration number.

14. System shall be able to record the payment made by the applicant against the Application as per the Payment Component

15. System shall display a message regarding successful or unsuccessful completion of any transaction.

16. System shall refresh the page in case of failure in submission of service request

17. System shall be able to notify the Registrar/Sub Registrar about the new application and the date and time must be logged & Should be able to route the application to the Registrar/Sub Registrar.

18. System shall allow concerned officials to view the service request on authenticated login

19. System shall allow Registrar/Sub Registrar to accept or reject any service request application



20. System shall request Registrar/Sub Registrar to provide comments in case of rejection

21. System shall save the acceptance / rejection only after digital signature of the Registrar/Sub Registrar

22.

System shall show service request to concerned Registrar/Sub Registrar as pending for approval till it is marked for further action -by default System shall be able to auto escalate within the service level as per the escalation matrix defined

23. System shall load a page to enable Registrar/Sub Registrar to assign verification responsibility to concerned authority

24. System shall auto generate notification to concerned official once the Registrar/Sub Registrar has assigned officer for physical verification

25. System shall allow the concerned officer to view the service request after authentication of username and password

26. System shall allow officer to print the details of service request application form to have a hard copy of the same

27. System shall allow the officer to update the verification details in relevant database (Marriage Database).

28.

System shall be able to auto generate MIS reports for the following officials -State Registrar -District Registrar - Civil Registrar/Sub Registrar

29. System shall allow the officer to electronically forward the application to the Registrar/Sub Registrar using his digital signature

30. System shall allow concerned Registrar/Sub Registrar to view changes made in the database by the officer

31. System shall be able to support the status tracking component as defined in the process map for status tracking

32. System shall be able to support the monitoring and reporting component as defined in the process map for monitoring and reporting

33. System shall be able to detect changes in status and send status updates to the citizen as per the Status Tracking component

34. System shall be able escalate the application as per the Auto Escalation matrix defined in Auto Escalation Matrix table, by notifying the next level of authority and sending him a copy of the application

35. System shall be able to maintain all records for the login sessions with date and time

36. System shall be PKI enabled to accept digital signatures for digitally signing documents for marriage registration certificate.

37. System shall have a facility for forwarding of the application, with remarks and digital sign of the sender, to any person in District administration registered with System

38. System shall be able to provide date and time stamping for all transactions done with digital signature

39. System shall consider the list of holidays for tracking the timelines of various activities.

40. System shall support multilingual interface (minimum Konkani, Marathi and English as per Localization and Language Technology Standards for National e-Governance Plan defined in e-District guidelines

41. Registration/Renewal of fishing nets module of e-District application should be linked to general all service component appropriately as per department requirement –e.g. Information component, Form availability component etc.



5.7 Template for Bill of Material

Form A: Bill of Material (Software at SDC)

System Software

Server OS 10

RDBMS 2

Virtualization software 1

Anti-Virus software 10

Form B: Bill of Material (Hardware at SDC)

Sl.

No

Description of Item Quantity (DC Site) Quantity (DR Site)

1. Database Server 2 1

2. Application Server 2 1

3. Web Server 2 1

4. Backup and Reporting Server

2 1

5. Development Server 2 1

6. Application Load Balancer 2 1

7. 10U Blade enclosure(Chassis)

1 1

8. L3 networking switch 1 NA

9. Tape Library 1 NA

10. Laptops 2 NA

11. 5TB SAN Box 1 NA

Note: 1. Procurement for DR site shall be done as and when required 2. SI is free to suggest alternate number of systems and their usability which best suits their proposed

application.

For hardware mentioned above, provide the following information in a table

(i) Reference of the server/storage information in the Submitted Proposal (Please provide

page number/section number/ volume)

(ii) Services proposed to be hosted on the Server



(iii) Quantity

(iv) Make and Model

(v) Year of Introduction

(vi) Operating System along with version (if applicable)

(vii) Processor and Number of Cores Offered (if applicable)

(viii) Architecture (RISC/EPIC/CISC) (if applicable)

(ix) RAM/HDD/LAN Ports/ HBA (as relevant)

(x) Additional Information as required to indicate the compliance to the requirements in the

RFP (ex, Capacity, Disk Space) (if applicable)

1 Web Servers

S.No. Item Description of Requirement ( Minimum)

Specifications offered

Compliance (Yes / No)

Deviations, if any

1

Processor Latest Generation x86-64

Bit Minimum Hexa-Core

Processor with Minimum

1.86Ghz Clock Speed and

12MB Cache with QPI

Technology or above

2

Number of

Processors

Offered Server should be

configured with 4 (Four)

Processors

3

Memory 64 GB DDR3 Memory Per

Server

4

Memory

Scalability

Memory Should be

Scalable up to 256 GB

5

PCI-Express Slots Server Should Have

Minimum 4 * PCI Express

Slots

6

Network

Interface Ports

Minimum 2, 10 gbps sfp

card

The NIC Ports should

support FCoE & iSCbidder

7

FC-HBA Ports Minimum 2, 8 Gb/s FC-

HBA Cards

8

Internal RAID Internal RAID Controller

should be able to do RAID

1,0



9

Internal /

External HDD

(For OS only)

Minimum 2* 50 GB SSD

10

Pre-Failure

Warranty

Critical Components like

CPU, Memory, SSD & PCI

Slots should be covered

under Pre-Failure

Warranty

11

Warranty

Coverage

Comprehensive onsite

warranty for 5 years.

12

OS &

Virtualization

Infrastructure

Support

MS Windows, RHEL,

SLES, OEL, Oracle Solaris,

VMWare Vsphere &

Microsoft HyperV

13

I/O & Power

Supply

Redundancy

Server Should have

redundant power supply

and redundant I/O

14 From Factor Blade

Database Servers

S.No. Item Description of Requirement ( Minimum)

Specifications offered


Deviations, if any

1

Processor Latest Generation x86-64

Bit Minimum Hexa-Core

Processor with Minimum

1.86Ghz Clock Speed and

12MB Cache with QPI

Technology or above

2

Number of

Processors

Offered Server should be

configured with 4 (Four)

Processors

3

Memory 64 GB DDR3 Memory Per

Server

4

Memory

Scalability

Memory Should be

Scalable up to 256 GB

5

PCI-Express Slots Server Should Have

Minimum 4 * PCI Express

Slots



6

Network

Interface Ports

Minimum 2, 10 gbps sfp

card

The NIC Ports should

support FCoE & iSCbidder

7

FC-HBA Ports Minimum 2, 8 Gb/s FC-

HBA Cards

8

Internal RAID Internal RAID Controller

should be able to do RAID

1,0

9

Internal /

External HDD

(For OS only)

Minimum 4 * 50 GB SSD

10

Pre-Failure

Warranty

Critical Components like

CPU, Memory, SSD & PCI

Slots should be covered

under Pre-Failure

Warranty

11

Warranty

Coverage

Comprehensive onsite

warranty for 5 years.

12

OS &

Virtualization

Infrastructure

Support

Should support the

following - MS Windows,

RHEL, SLES, OEL, Oracle

Solaris, VMWare Vsphere

& Microsoft HyperV

13

I/O & Power

Supply

Redundancy

Server Should have

redundant power supply

and redundant I/O

14 From Factor Blade

Blade Chassis

S.No. Item Description of Requirement Specifications offered


Deviations, if any

1

Blade Chassis Solution to house the

required number of blade

servers in smallest number

of enclosure



Same enclosure should

support Intel Xeon, AMD

Opteron or RISC/EPIC

blades. Enclosure should

also support Unix, Linux

and Windows Operating

environment.

Should have Hot Pluggable

& Redundant Management

Modules.

Should provide a highly

reliable and high

performance redundant

mid-plane/back-plane

design in the blade

enclosure. Should provide

detailed technical

information.

Should be able to

accommodate and

compatible with the OEM

blade servers specified.

Support simultaneous

remote access for different

servers in the enclosure.

2

LAN

Interconnect

Two or Four network ports

from each of the servers in

the enclosure should be

available on 10 Gigabit

LAN switch / Link

Aggregation Module / Pass-

through to connect to

external network devices...

3

Fibre Channel

Interconnects

Redundant 8GB Fibre

Channel Pass thru

Interconnect modules to

direct HBA cards to SAN

Switch/Storage.



4

MAC Address &

WWN

Management

Blade Enclosure should

preferably support

management & deployment

of MAC Addresses of NIC

Adapters and WWN No of

FC adapters at the chassis

level so that replacement of

a server blade does not

involve Network & SAN

configuration effort at the

blade level

5

Power Supply The enclosure should be

populated fully with power

supplies of the highest

capacity & energy

efficiency available with

the vendor. Power supplies

should support N+N as

well as N+1 redundancy

configuration, where N is

greater than 1.

Guaranteeing complete

availability even on failure

of any 2 power supplies

across the enclosure

6

Cooling Each blade enclosure

should have a cooling

subsystem consisting of

redundant hot pluggable

fans or blowers enabled

with technologies for

improved power

consumption and acoustics

7

Redundancy The Midplane/Backplane,

all interconnect switches

the power bus running

across the chassis should be

in redundant configuration

8

System Software Management/controlling

software have to be from

the same OEM



9

Remote

Management

Must provide a remote

management functionality

to operate the server in both

in-band and out-of-band.

Must be part of the server

without the need to install

any additional hardware or

software

Must have Real-time

Virtual KVM functionality

and be able to perform a

remote Power sequence.

Must provide both Java &

Java-free browsing options.

10

Power

Management

Must be able to show the

actual power usage and

actual thermal

measurement data of the

servers.

Form C: Bill of Material (Infrastructure at Field Offices)

S.

No

Description of Item Total Quantity

1. Desktop/ Computer 369

2. Laptop 1

3. Digital Web camera 10

4. Scanners (A4 size) 9

5. Scanner (A3 size) 3



8. Passbook Printers 2

9. UPS (1 KVA, Online) 178

10. Networking Points 400

11. UPS Electrical Points 500

Important Note for bidders:

(i) It is mandatory to furnish complete technical specifications of the hardware & peripherals

being offered, strictly as per the format, provided here. Correct technical information of

the product being offered must be filled in.



(ii) Filling the technical specifications/ information in the format using terms such as „OK‟,

„Accepted‟, „Noted‟, „As given in Brochure/ Manual‟, „Complied‟ is not acceptable. The

offers not adhering to these guidelines are liable to be rejected.

(iii) All relevant product information such as user manuals, technical specifications sheet etc.

should be submitted along with the offer. Failure to submit this information along with

the offer could result in disqualification of the bid.

(iv) In case any technical variance is offered, the same must be specified under the "Deviation, if

any" column.

(v) For each item listed below, the bidders should propose only one product.

(vi) These specifications should be considered as the minimum to be fulfilled.

1 A. Desktops /Personal Computer

S. No.

Items Specifications Specifications offered

Compliance (Yes /

No) if any

Deviations, if any

1.

Processor Intel core I5 3rd

generation or AMD

equivalent, 64bit x86

Processor @ 3.2 GHz or

more, 4MB L3 cache or

better, Memory support

DDR3 or better

specifications

2.

Motherboard

& Chipset

OEM Motherboard

3.

Video Integrated Graphic

controller

4.

Network Integrated 10/100/1000

Gigabit Ethernet

controller

5.

Ports 1 HDMI port

(Preferable), 2x USB 2.0

and 2 x USB 3.0

(Preferable) , 1xKeyboard

port, 1xMouse port , 4 in 1

Media Card Reader



(Preferable), Built in

microphone ,Stereo jack

6.

HDD

Controller

Integrated dual port

SATA-II controller

7.

Memory 4 GB DDR III 1333MHz

or higher expandable up

to 8 GB or more

8.

Storage 500GB sata II HDD 7200

RPM

9.

Optical Drive 22X DVD writer or

higher

10.

Monitor 18.5” TFT or more (4:3

aspect ratio) LCD

Monitor 1280 x 1024

resolution with 5 ms

response time or better

specifications, TCO 05

certified

11.

Keyboard Spill-resistant keyboard

(minimum 86 keys) with

bi-lingual keys ( English ,

Konkani and Marathi)

compliant to Enhanced

Inscript Keyboard based

on Unicode version 6.0 or

later.

12.

Mouse USB Optical Scroll

Mouse with anti-static

mouse pad resolution of

Optical 1000 cpi,

Complying to CE and

FCC norms

13.

Out Of Band

Management

Out-of-band management

preferable

14.

Power

Management

and DMI

System with Power

management features &

Desktop Management

Interface implementation

15. System Desktop with wired



Chassis keyboard and wired

mouse

16.

OS Support &

Certification

Windows 7

17.

Preloaded

Software

Above configuration

preloaded with Operating

system with English,

Konkani and Marathi

language packs, Business

productivity suit with

English, Konkani and

Marathi unicode fonts ,

Antivirus with all

necessary Plugns/ utilities

and driver software

including bundled in

DVD Media [ Antivirus

licence for 5 years

support and upgradation]

18.

Warranty

Coverage

Comprehensive warranty

for 5 years .( Onsite)

19. Power input 100 -240V AC

20.

- All in one PC preferable

for Field offices

1 A. LAPTOPS

S. No.

Features Specifications Specifications offered

Compliance (Yes / No) if

any

Deviations, if

any

1

Processor Intel Core i5 or higher or

AMD equivalent

2 Speed 3.0 GHz or Higher

3 Cache 3 MB Smart Cache or more

4 System Bus/QPI 2.0 GT/sec or higher

5 Mother Board Original OEM manufactured

6 Memory 4 GB DDR-III RAM (1066



MHz) or higher expandable

upto 8GB

7

Hard disk Drive 500 GB SATA (7200 RPM) or

higher capacity

8

Display 14.0" or above LED Wide

Screen Display

9 Resolution 1280 x 768 WXGA or higher

10 Video Graphics Integrated HD Graphics

11 Web Camera Integrated Web Camera

12

Wireless

Connectivity

Integrated Wireless 802.11

a/b/g/n, Integrated Bluetooth

2.0 or higher

13

Optical Drive Integrated 8X or higher DVD

Writer

14 Sound System Integrated Stereo Speaker

15

Keyboard Standard Keyboard with

Touchpad

16

Ports Minimum 3 USB Ports 3.0 or

higher, 10/100/1000 Ethernet

Card, RGB/S-Video/VGA,

HDMI, Microphone, Stereo

Head Phone, Media Card

Reader and other Standard

Ports

17

Battery Backup 6 cell Li-ion battery with re-

chargeable pack for around 6

hrs.

18

Certification Laptop manufactured in ISO

9001:2000, ISO 14001 plant

and DMI, FCC, UL, CE

compliance

19 Weight Less than 3 kg

20 Carry Case Good quality Carry Case

21

Warranty Minimum 5 Years on-site

Comprehensive on Laptop

and 3 year on battery

22

OS Support &

Certification

Windows 7



2 Scanner( A4 Size)

S.No. Feature Specification Specifications

offered

Compliance

(Yes / No)

Deviations,

if any

1 Make Must be specified NA

2 Model All the relevant

product brochures

and manuals must

be submitted.

NA

3 Scanner type Legal Size Flatbed

4 Scan

technology

Charge Coupled

Device (CCD)

5 scan speed min 20 PPM

6 ADF capacity 50 sheets

7 Duty cycle Min 800 pages per

day

8 Scan

resolution:

Min 600 dpi

9 Output

resolution

dpi settings

300, 600

10 Color bit

depth

24-bit

11 Grayscale

levels

256

12 Double-feed

detection

Yes

13 File formats BMP, JPG, TIFF,

TIFF (compressed),

multi-page TIFF,

PNG, PDF, RTF,

TXT, UNICODE,

HTM, DOC

14 Connectivity Hi-Speed USB 2.0

15 Software Ibidder S and



S.No. Feature Specification Specifications

offered

Compliance

(Yes / No)

Deviations,

if any

Twain drivers

16 Compatible

operating

systems

Windows XP,

Windows Vista,

Windows 7, MAC

OS 9.0, MAC OS X,

Linux Kernel 2.4 or

later

3 Laser Printers (A4 size, heavy duty & network)

S.

No

Feature Specification Specifications

offered

Compliance

(Yes / No)

Deviations,

if any



product brochures

and manuals must be

submitted.

NA

3 Speed (min.) min 20 PPM (A4)

4 Memory(min.) min 8 MB

5 Resolution 600x600 dpi

6 Interface

USB, Ethernet (UTP)

with respective cables

7 Monthly Duty

Cycle

min 10000 Pages

8 Drivers Windows XP,

Windows Vista,

Windows 7, MAC OS

9.0, MAC OS X,

Linux Kernel 2.4 or

later

9 Duplex Automatic Duplex

4 Other Printers (A3, heavy duty & network)



S.

No


offered

Compliance

(Yes / No)

Deviations,

if any



product brochures

and manuals must be

submitted.

NA

3 Speed (min.) ISO / IEC 24734

min 12 PPM - Black

(A4)

4 Memory(min.) min 8 MB

5 Resolution 600x600 dpi

6 Interface

USB, Ethernet (UTP)

with respective cables

7 Monthly Duty

Cycle

min 10000 Pages


Windows Vista,

Windows 7, MAC OS

X, Linux Kernel 2.4

or later

9 Duplex Automatic Duplex

5 UPS – 1 KVA online UPS

S.

No.


offered

Compliance

(Yes / No)

Deviations,

if any



product brochures

and manuals must

be submitted.

NA

3 Power Rating 1 kVA/ 700 W with

30 min backup

4 Technology True On-Line

Double Conversion

Architecture



S.

No.


offered

Compliance

(Yes / No)

Deviations,

if any

5 Nominal input

voltage (VAC)

220/230/240 VAC

6 Input voltage

Range

160-300 VAC

7 Operating

Frequency

50Hz

8 Nominal output

Voltage

230 VAC

9 Output voltage

Regulation

+/-1.5%

10 Overload

Capacity

Up to 110 % for 30

sec, 111-150% for

200ms

11 Efficiency Min. 85% (On-Line

mode)

12 Load Crest Factor 3 : 1

13 LED LCD Display having

complete

information about

the Input and

Output data

14 Standard

Communication

ports

RS232

15 Form Factor Floor Mounted type

16 Battery Type Sealed Maintenance

Free

17 Battery Runtime For 30 Min. backup

minimum VAH

should be 900.

Total number of

batteries offered

should be clearly

mentioned.

Voltage of each



S.

No.


offered

Compliance

(Yes / No)

Deviations,

if any

battery offered

should be clearly

mentioned Ampere-

Hour rating of each

battery offered

should be clearly

mentioned. Total

Volt-Ampere-Hour

rating of the Battery

Bank Offered should

be clearly

mentioned

18 Start-On-Battery Should allow

startup of UPS

without utility input

19 Operating Temp. 0°C - +40°C

20 Storage Temp Recommended 0°C -

+40°C

21 Audible Noise <50 dB battery mode

22 RoHS

Compliance

Should be EU RoHS

/ WEEE Compliant

23 Markings CE

24 Safety IEC 60950

25 EMC EN 50091-2

/equivalent

6 As an when required the bidder is expected to procure 8, 16 & 24 Port Switch with the

following specifications

8, 16 & 24 Port Switch

S.

No.


offered

Compliance

(Yes / No)

Deviations

, if any



product brochures and

manuals must be

submitted.

NA



S.

No.


offered

Compliance

(Yes / No)

Deviations

, if any

3 Standards 1. IEEE 802.1D

2. IEEE 802.1p

3. IEEE 802.1Q

4. IEEE 802.1s

5. IEEE 802.1w

6. IEEE 802.1x

7. IEEE 802.1ab

8. IEEE 802.1ad

9. IEEE 802.3

10.IEEE 802.3u

11.IEEE 802.3ab

12.IEEE 802.3z

13.RFC 854

14.RFC 951

15.RFC 1305 / RFC2030

4 Protocol CSMA/CD

5 Throughput Min 8 Gbps

6 Data Transfer

Rates

Non-Blocking

Architecture

7 Network

Cables

10BASE-T: UTP Cat. 3,

4, 5 (100 m) EIA/TIA-

586 100-ohm STP (100

m)

100BASE-TX: UTP Cat.

5 (100 m) EIA/TIA-568

100-ohm STP (100m

max.)

8 Number of

Ports

10/100Mbps port x 24

9 Twisted-pair

Rx

Reverse

Polarity

Auto-correction for

each port

10 MAC

Address

Automatic update



S.

No.


offered

Compliance

(Yes / No)

Deviations

, if any

Learning

11 RAM 64 MB

12 Power

Supply

100 - 240 VAC, 50/60

Hz

13 Security Should support

a) 802.1x

b) AAA

c) SSH v1, v2

d) SSL

e) Host to Host and

Switch to Switch

authentication

14 Management Should have

a. IPv6 management

capability

b. SNMP v1, v2, v3

c. RMON

d. RADIUS

e. CLI via console

f. Web interface

g. Provision of

software and firmware

upgrades with latest

version releases

through admin login

15 Uplink Ports Switch should have 2

dual-purpose uplink

ports (10/100/1000 or

SFP)

7 A3 Scanner Heavy Duty

S.

No.


offered

Compliance

(Yes / No)

Deviations, if

any



S.

No.


offered

Compliance

(Yes / No)

Deviations, if

any

1. Make Must be specified NA

2. Model Must be specified NA

3. Scanner type:

Sheet-fed

4. Scan resolution, optical

Up to 600 dpi

5. Duty cycle (daily):

1000 pages

6. Bit depth 48-bit (internal), 24-bit

(external)

7. Levels of grayscale

256

8. Multi-feed detection

Yes, ultrasonic

9. Task speed A4, colour scan in 3

seconds

10. Media types

Paper (plain, inkjet),

envelopes, labels,

checks, cards

(business, plastic ID)

11. Scan file format

PDF Searchable, PDF

Image Only, PDF/A,

JPEG, TIF single page,

TIF multi page,

DOCX, RTF, TXT,

BMP

12. Scanner advanced features

Duplex scanning;

ultrasonic double feed

detection, auto colour

detection, page size

detection, crop, desk-

ew, rotation, blank

page removal, scan to

Share-point and scan

to cloud features

among many other



S.

No.


offered

Compliance

(Yes / No)

Deviations, if

any

scan-to destinations.

13. Power AC 200 – 240V

8 L3 Switch

S.

No.


offered

Compliance

(Yes / No)

Deviations, if

any

1. Make Must be specified NA

2. Model Must be specified NA

3. Port density in each switch

Minimum of 48 ports

of 10/100/1000 Base-T

RJ45 with auto polarity

& auto speed support

with 2 combo

10/100/1000-T or

1000Base-X ports

Should have dedicated

stacking ports of 40

GBPS or more

bandwidth

Switch should have 2

or more 10 G ports

All Ports should

support 802.3atPoE+

standard

4. Memory and processor Module

ARM @ 333 MHz, 128

MB flash, 128 MB

RAM; packet buffer

size: 512 KB

5. Mounting Mounts in an EIA-

standard 19 in. telco

rack or equipment

cabinet (hardware

included)

6. Performance 100 Mb Latency < 5 µs

1000 Mb Latency < 5

µs

Throughput up to 77.4



S.

No.


offered

Compliance

(Yes / No)

Deviations, if

any

million pps

Routing/Switching

capacity 104 Gbps

Routing table size 32

entries

7. Electrical characteristics

Voltage 100-240 VAC

Maximum power rating

59.8 W

Frequency 50/60 Hz

8. Safety UL 60950; IEC 60950-

1; EN 60950-1;

CAN/CSA-C22.2 No.

60950-1-03

9. Management IMC - Intelligent Management Center; limited command-line interface; Web browser; SNMP Manager; IEEE 802.3 Ethernet MIB

9 Tape Library

Description Specification

Tape drives 4 x LTO 4 FC drives scalable to 10

Interface Fiber Channel Interface

Should have sufficient speed backup to Tape Library in High Availability for backing up

data from the SAN without any user intervention.

Should be able to back up the entire production landscape in 8 hours window.

Should support LTO-4 or latest technology based library with at least 4 LTO-4 tape drives

(>=4), rack mountable with redundant power supplies.

Cartridges should have physical capacity up to 200 GB per cartridge compressed; 100 GB

native.

At least 50 LTO 4 Media Cartridges with 2 Cleaning Cartridges, Barcode labels shall also be

provided

10 Passbook Printer



S.

No


offered

Compliance

(Yes / No)

Deviations,

if any



product brochures

and manuals must be

submitted.

NA

3 Speed (min.) a. V.H.S.D : 480 cps

or better

b. H.S.D. : 400 cps

or better

c. Draft : 300 cps or

better @10cpi

d. N.L.Q. : 150 cps

or better

e. L.Q. : 100 cps or

bette

4 Input Buffer Min 64 Kb

5 Passbook

handling

Horizontal & Vertical

6 Interface

IEEE 1284 parallel +

RS 232 Serial + USB

2.0

7 Print head life 400 million strokes/

wire

8 MSRW head 1.6 million strokes


Windows Vista,

Windows 7, MAC OS

9.0, MAC OS X,

Linux Kernel 2.4 or

later

10 Type 24 pin dot matrix

11 Paper Path Manual Insertion;

Front in, Front out /

Front in, Rear out

12 Bar code

printing

PR2: EAN-13, EAN-8,

Interleaved 2 of 5,



S.

No


offered

Compliance

(Yes / No)

Deviations,

if any

UPC-A, Code 39,

Coda bar (NW-

7),Industrial 2 of 5,

UPC-E ESC/P: EAN-

13, EAN-8,

Interleaved 2 of 5,

UPC-A, UPC-E, Code

39, Code 128,

POSTNET

11 Digital Web Camera

S.

No


offered

Compliance

(Yes / No)

Deviations,

if any



product brochures

and manuals must be

submitted.

NA

3 Connectivity

Technology

Wired

4 Optical sensor

type

CMOS

5 Interface USB 2.0 compatibility ,

Skype compatible

6 Type Color

7 Max Digital

Video

Resolution

640 x 480

8 Video Capture 640 x 480

9 Drivers Microsoft Windows 8,

Microsoft Windows 7,

Microsoft Windows

Vista,

Microsoft Windows XP

SP2 or later

10 Min Processor

Type

1GHz, 1 GHz



S.

No


offered

Compliance

(Yes / No)

Deviations,

if any

11 Peripheral /

Interface

Devices

Sound card,

USB port,

Speakers,

CD-ROM,

Internet connection



6 Annexure:

6.1 List of existing Hardware components, SLA management tool and licences at SDC,

Goa

List of existing hardware components at SDC Goa

State Portal Servers

Sr.No.

Server Purpose

Make / Model

Rack / Slot No OS

SP/SSDG Installed S/W

1 Load Balancer Dell / M610 1/1

RHEL 5.6 x86_64 SP

Apache-2.2.3, JDK-1.6u23

2 Load Balancer Dell / M610 1/2

RHEL 5.6 x86_64 SP


3 Web Server Dell / M610 1/5

RHEL 5.6 x86_64 SP


4 Web Server Dell / M610 1/6

RHEL 5.6 x86_64 SP


5 App Server Dell / M610 1/7

RHEL 5.6 x86_64 SP

JDK 1.6 u23, JBoss SOA, Eclipse-3.6 Helios

6 App Server Dell / M610 1/8

RHEL 5.6 x86_64 SP

JDK 1.6 u23, JBoss SOA

7 Database Server

Dell / R910

1/ Rack Mount

RHEL 5.6 x86_64 SP PostgreSQL-8.4.5

8 Database Server

Dell / R910

1/ Rack Mount

RHEL 5.6 x86_64 SP PostgreSQL-8.4.5

9 Staging Server Dell / M610 1/3

RHEL 5.6 x86_64 SP

Apache-2.2.14, JDK 1.6 u23, JBoss SOA, PostgreSQL-8.4.5, Alfresco-3.4.0 JMeter-2.4, VNC is configured, Ant-1.8.2, soapui-3.6-beta1 (by CDAC on 7th Jul)

10 Dev/CMS Server

Dell / M610 1/4

RHEL 5.6 x86_64 SP

Apache-2.2.14, JDK 1.6 u23, JBoss SOA, PostgreSQL-8.4.5, Alfresco-3.4.0, JMeter-2.4, Eclipse-3.6 Helios, Ant-1.8.2, VNC is configured



SSDG Servers

1 Web Server Dell / M610 2/7 Cent OS 5.5 SSDG

Website component

2 Web Server Dell / M610 2/8 Cent OS 5.5 SSDG

Website component

3 Messaging Part-1

Dell / M610 2/3 Cent OS 5.5 SSDG Messaging Part-1

4 Messaging Part-2

Dell / M610 2/5 Cent OS 5.5 SSDG Messaging Part-2

5 Database Component

Dell / M610 2/1 Cent OS 5.5 SSDG

Database Component

6 Database Component


Database Component

7 Monitoring server


Monitoring server

8 App Server Dell / M610 2/4 Cent OS 5.5 SSDG Messaging Part-1

9 App Server Dell / R710

2/Rack Mount Cent OS 5.5 SSDG Java and Postgres

6.2 Non-Functional Requirements

The non-functional requirements relating to performance, availability, deployment,

implementation, operations and others are listed in the subsequent subsection. Based on the

assessment of the requirements listed below, bidder shall prepare System Requirement

Specifications (SRS) and obtain a formal sign-off before proceeding with the design and

implementation of the solution.

# Non-functional Requirements

a) Technical Solution Architecture Requirements

1. The e-District solution needs to be architected using robust and proven software and hardware technologies like Service-Oriented Architecture (SOA) and open industry standards.

2. The solution architecture should be built on sound architectural principles enabling fault-tolerance, high-performance, and scalability both on the software and hardware levels.

b) Software Architecture Requirements

1. Software architecture must support web services standards including XML, SOAP, UDDI and WSDL

2. Software architecture must support appropriate load balancing for scalability and performance

3. Software architecture must support flexibility in adding functionalities or applications.

4. Software architecture components should utilize the high availability, clustering, and load balancing features available in the proposed hardware architecture to increase system performance and scalability features.

5. Software architecture must support trace logging, error notification, issue resolutionand exception handling.

c) Hardware Architecture Requirements

1. Hardware architecture at SDC must provide redundancy and high availability capabilities at the hardware level; this includes servers, etc. However, the hardware infrastructure for the DRC can be as per the SDC specifications.



2. All servers and systems must be configured with no single point of failure.

3. Hardware architecture should be capable of consolidating several applications / workloads in a number of servers as required.

4. Servers must be placed within proper security infrastructure for the Solution.

5. Hardware architecture must support existing Storage Area Network (SAN) if available & backup solution (at SDC)

6. The technical solution architecture for e-District should be sound and complete with high performance, redundancy, and scalability.

d) Development, Testing, Staging, and Production Requirements

1. Appropriate development, test, and staging hardware environments should be provided and explained how they are related to production environment. This must be supported by explanations on how the development, test, and staging environment support the implementation activities of e-District Solution.

2. Development and test environment should include configuration management capabilities and tools for system configuration, versioning scheme, documentation, change control processes and procedures to manage deployment of solution deployment.

3. The test, development, and staging environment should include required workstations, desktops, and tools appropriate to support development, testing, and staging, and deployment tasks.

4. The development, test, and staging hardware environments must include similar operating systems, software components, products, and tools to those of production environment.

5. The development, test, and staging environments should be independent logically and physically from the production environment and of each other.

6. The development environment should be used for development and should be configured to allow access for developers‟ workstations.

7. The staging environment should be used for functional and user acceptance testing, stress testing, and performance benchmarking.

The test environment should be used as a testing environment of e-District Solution and its software components and products. The test environment should be a scaled-down configuration of the production environment.

e) Security Requirements

1.1.1. A secure solution should be provided at the hardware infrastructure level, software level, and access level.

1. Authentication, Authorization & Access Control 3 factors (User ID & Password, Biometric, and Digital Signature) security mechanisms should be implemented to enable secure login and authorized access to portal information and services.

2. Encryption Confidentiality of sensitive information and data of users and portal information should be ensured.

3. Appropriate mechanisms, protocols, and algorithms necessary to protect sensitive and confirmation data and information both during communication and storage should be implemented.



f) Monitoring and Management Requirements

4. The e-District Solution should provide monitoring and management of the entire Solution including all software components and application.

5. The monitoring and management should monitor health of software and hardware infrastructure running the e-District Solution covering operating system, database, software components, applications, servers, and other related software and hardware components. It should provide proactive monitoring, alerting and reporting.

g) Performance and Scalability Requirements

1. The design of the e-District Solution should be scalable to handle increasing number of users.

2. e-District Solution should provide measurable and acceptable performance requirements for users, for different connectivity bandwidths.

3. The e-District solution should provide optimal and high performance Portal Solution satisfying response time for slow Internet connections and different browsers.

h) Implementation Requirements

1. The bidder will be required to deploy manpower and other project resources as per the terms & conditions of the Contract

2. The bidder will be required to work closely with the SDA and perform detailed functional requirements and analysis of e-District Solution to confirm and document functional / system requirement specifications for the portal and its applications to fulfil its objectives.

3. The bidder will be expected to carry the complete implementation and deployment of the e-District within the timelines specified in the RFP.

4. The bidder is expected to develop, test, stage, and deploy all functional modules of the e-District software and any hardware components of technical & functional requirements

i) Project Management



1. Selected bidder is required to provide an implementation plan illustrating all functional analysis, development, testing, staging, and deployment activities.

2. Selected bidder is required to specify and describe the different phases and activities of the project. It is very important for the SDA that the Selected bidder provide a quality implementation plan covering all aspects of the project. The plan shall clearly specify the start and end dates (relative to contract signing) of each of the project phases specifying key milestones allowing visibility of project progress.

3. Selected bidder is required to use standard project management tools such as precedence diagrams, critical path charts, etc. to create and manage implementation plan and schedule. The table below shows the minimum stages and deliverables:

Stage Activities Deliverables

Functional & Requirements Analysis

Define Functional Requirements

Requirements management

Prototyping

Documentation

Data Migration Preparation

Software Requirements and Specifications Document

Detailed Scope of Work

Work Breakdown Structure

Detailed Project Schedule

Data Migration Plan

Design

Detailed Software Solution Architecture design

Detailed Hardware Solution Architecture Design

Data Schema design

User Interface Design

Integration & Interfaces Design

Prototyping design Validation

Documentation

Design Specifications Documents of Software solutions

Design Specifications Documents of Hardware solutions

User Interface Design Specifications

Integration Design Specifications

Data design and migration

Development Software installation, configuration, and customization

Hardware installation and configuration

Development

Unit Testing

Documentation

Development Plan

Updated Design Document

Installed software and hardware

Functional modules & Portal Solution

Problem reporting



Testing System Testing

Integration Testing

Stress Testing

User Acceptance Test Results

Completed Test Cases

Data Migration tests

Documentation

Complete Test Cases

Test Plan

User Acceptance Criteria

Problem reporting

Problem resolutiontesting

Data Migration Testing

Deployment Training courses and sessions

Operations Planning

User Manual

Operations Manuals

Knowledge Transfer and training plan

Operations Plan

Operations Policies and Procedures



4. Selected bidder is required to describe in detail project management processes, methodologies and procedures.

5. Describe what SDA resources will be necessary for the project to succeed.

6. Describe how SDA management will receive up-to-date reports on project status.

7. Describe the change management procedures to handle such things as “out-of-scope” requests or changing business needs of SDA while the project is underway.

8. Describe what procedures will be used to keep the project on track, and what escalation procedures will be employed to address any problems with project progress.

9. Describe what quality assurance processes, procedures, formal reviews, etc. will be in place.

10. Describe the proposed conflict resolution/ escalation process between the Bidder and SDA to handle project or contractual disputes.

11. Selected bidder is required to describe the proposed project structure identifying all project individuals including project manager, business analysts, software developers, QA engineers, hardware / network engineers, administrators, Change Management experts, and others.

12. Selected bidder shall provide a comprehensive warranty that covers all components after the issuance of the final acceptance of e-District. The warranty should cover all materials, licenses, services, and support for both hardware and software. Selected bidder shall administer warranties with serial number and warranty period. Upon final acceptance of the SDA, all OEM warranties will be transferred to the SDA at no additional charge. All warranty documentation (whether expired or not) will be delivered to SDA at the issuance of the final acceptance certificate.

13. Selected bidder is required to provide Premium Level warranty and support through the vendor for all hardware and software used for e-District. Selected bidder‟ warranty must cover all equipment and work activities contained in the contract against all design, manufacturing, and environment faults until the issuance of the final acceptance.

14. Selected bidder is required to commit to the following warranty terms:

SI/bidder shall provide on-site comprehensive warranty for 5 years from the date of commissioning of all IT infrastructures and other equipment (if any) for providing warranty support to SDA

The warranty shall include the repair or replacement of the products / components / parts during the warranty period by the bidder. The replacement products / components shall meet the related specifications

In case of off the shelf software warranty and license, the SI is responsible to update latest patches and renewal of licenses whenever applicable with no extra cost to the State

Selected bidder shall be liable for all costs including, but not limited to, the costs of material, labour, travel, transport and living expenses associated with the collection and return of the units covered by the warranty.

The date of manufacture or assembly of any equipment, parts or consumables, shall not be more than six months before delivery.

Selected bidder shall state the location of his repair Centre(s) for all items not being repaired onsite.

SDA has the right to require a replacement if the repair is deemed to be impractical.

Selected bidder ensures that replacement components shall be available for any failed component during the warranty period.

Selected bidder shall guarantee the availability of spare parts and technical assistance for all components (or appropriate alternatives) to ensure the equipment would run for at least five (5) years, without major changes, at the completion of final acceptance. Six months advance notice is required on any discontinued part(s) with a suggestion for alternatives.



Selected bidder need to define the process & methodology in their proposal, for achieving the response time of engineers to respond to an incident and also for resolving such incidents as per the SLA.

Selected bidder is required to provide additional training if the satisfaction levels/ learning does not reach 80% in evaluation/feedback from trainees, and expected to provide additional training, if required.

The e-District application & infrastructure being provisioned by the bidder shall be insured. The Goods supplied under the Contract shall be fully insured against loss or damage incidental to manufacture or acquisition, transportation, storage and delivery for the entire project term.

Selected bidder is required to explain their warranty, maintenance procedures, and support to meet the terms and requirements outlined above.

j) Operations Requirements

15. The selected bidder is expected to provide the following in support of e-District operations:

Selected bidder shall provide procedure documentation for all operations procedures, and SLA‟s (based on ITIL best practices) for all the hardware and applications provided including backup procedures, system update procedures, security procedures, failure recovery procedures, upgrade procedures, remote access procedures, user manual, SOP‟s, etc.

All such procedures and documents must be submitted for review and approval by the SDA prior to adoption. Such documentation shall be updated by the during the project term by the bidder as and when required along with the necessary approval.

Selected bidder will be required to provide SDA with weekly statistics reports on the various services provided to users a mechanism as well as track and log all related statistical reports on the various delivery channels and access patterns.

Selected bidder will be required to provide SDA with weekly portal performance reports showing health of system operations.

Selected bidder will be required to provide SDA with Helpdesk for recording all the day to day problems and other technical incidents occur during the O&M phase. This shall also record the resolution of such incidents & problems.

Selected bidder will be required to commit to Service Level Agreements (SLAs) that show, among other metrics, appropriate escalation procedures and guarantee corrective actions within a pre-determined time. Selected bidder is required to respond to required levels of accuracy, quality, completeness, timeliness, responsiveness, cost-effectiveness, productivity and user satisfaction that are equal to or higher than the SLA system requirements.

k) Quality Assurance & Acceptance Requirements



16. Selected bidder is required to develop and implement quality assurance processes and procedures

to ensure that the e-District development and operations are performed to meet the quality

standards that are relevant to each area in all project phases.

17. Selected bidder is required to use various tools and techniques that can make tests run easily and

the results are automatically measured. In this way, testing tools provide a more cost-effective

and efficient solution than their manual counterparts. Plus, they minimize the risk of human

error during testing.

18. In order to ensure that such a QA mechanism is effective and acceptance of e-District, the

following tests are required for acceptance:

Unit Testing: Basic validation of developed components by developers.

Functional / Internal Integration Testing: Validation of developed components against functional

requirements and design specifications.

System Testing: Validation of both functional and technical requirements for the integrated

Solution. This could include external integration if required or it can be separated into testing

phases.

UAT: User Acceptance Testing (UAT) validation of the Portal Solution and assurance that it

meets both functional and technical requirements

Stress and Performance Testing: Load testing enabling understanding of performance and

behaviour of Portal Solution under large number of users and high-load conditions.

19. Selected bidder is required to describe their QA and testing approaches and procedures as well as

testing tools for conducting various tests in support of the acceptance of the Portal Solution.

20. Furthermore, Selected bidder to describe their documentation standards e.g. Documentation

description, documentation identification, content, nomenclature etc. as well.

Sample documents to be enclosed as part of the technical proposal.

RFP for Selection of System Integrator for State-wide roll-out of e-district MMP – Goa – Volume III

Statewide rollout of the eDistrict MMP 1 | P a g e


On behalf

Of


Government of Goa


FOR


FOR

ROLL-OUT OF e-DISTRICT MMP - GOA

VOLUME III





4th Floor,Above Alcon Hyundai Showroom,




CONTRACT AGREEMENT FOR SELECTION OF <<‟SYSTEM INTEGRATORS’/’ IMPLEMENTATION AGENCIES’>>

MASTER SERVICES AGREEMENT ............................................................................................................. 4 1 Definitions and Interpretation ................................................................................................................... 4 2 Scope of the Project .................................................................................................................................. 6 4 Conditions Precedent & Effective Date .................................................................................................... 7 5 Obligations under the SLA ....................................................................................................................... 8 6 Representations and Warranties ................................................................................................................ 9 7 Obligations of ITG or its Nominated Agencies ...................................................................................... 12 8 Obligations of the Implentation Partner .................................................................................................. 12 9 Approvals and required consents ............................................................................................................ 12 10 Use of assets by the Bidder ..................................................................................................................... 13 11 Access to ITG or its Nominated Agencies Locations ............................................................................. 13 12 Management Phase ................................................................................................................................. 15 13 Financial Matters .................................................................................................................................... 16 14 Termination ............................................................................................................................................. 18 15 Indemnification & Limitation of Liability .............................................................................................. 20 16 Force Majeure ......................................................................................................................................... 22 17 Confidentiality ........................................................................................................................................ 25 18 Audit, Access and Reporting .................................................................................................................. 26 19 Intellectual Property Rights .................................................................................................................... 26 20 Warranty ................................................................................................................................................. 27 21 Liquidated Damages ............................................................................................................................... 28 22 Escrow Agreement .................................................................................................................................. 28 23 Insurance Cover ...................................................................................................................................... 29 24 Miscellaneous ......................................................................................................................................... 30 25 Governing Law and Dispute Resolution ................................................................................................. 34 26 Schedules ................................................................................................................................................ 36 27 Annexures ............................................................................................................................................... 55 NON-DISCLOSURE AGREEMENT ............................................................................................................. 67 1 Definitions and Interpretation ................................................................................................................. 68 2 Term ........................................................................................................................................................ 69 3 Scope of the Agreement .......................................................................................................................... 69 4 Obligations of the Receiving Party ......................................................................................................... 69 5 Exceptions to Confidential Information.................................................................................................. 70 6 Ownership of the Confidential Information ............................................................................................ 71 7 Dispute Resolution .................................................................................................................................. 71 8 Variation ................................................................................................................................................. 72 9 Waiver ..................................................................................................................................................... 72 10 Exclusion of Implied Warranties ............................................................................................................ 73 11 Entire Agreement .................................................................................................................................... 73 12 Severability ............................................................................................................................................. 73 13 No Partnership ........................................................................................................................................ 73 14 Third Parties ............................................................................................................................................ 73 15 Successors and Assigns .......................................................................................................................... 73 16 Notices .................................................................................................................................................... 73 17 Language ................................................................................................................................................. 74 18 Counterparts ............................................................................................................................................ 74 19 Mitigation ............................................................................................................................................... 74 20 Removal of Difficulties .......................................................................................................................... 74 SERVICE LEVEL AGREEMENT ................................................................................................................. 76 1 Definitions and Interpretation ................................................................................................................. 76 2 Structure .................................................................................................................................................. 77 3 Objectives of this SLA ............................................................................................................................ 78



4 Scope of SLA .......................................................................................................................................... 78 5 Agreement Owners ................................................................................................................................. 79 6 Contact List ............................................................................................................................................. 79 7 Principal Contacts ................................................................................................................................... 79 8 Commencement and Duration of this Agreement................................................................................... 79 9 Exclusions to the Agreement .................................................................................................................. 79 10 Terms of Payment and Penalties ............................................................................................................. 80 11 Updating of this Agreement .................................................................................................................... 80 12 Document History ................................................................................................................................... 81 13 Scope of Services .................................................................................................................................... 81 14 Performance Review ............................................................................................................................... 81 15 Representations and Warranties of Buyer ............................................................................................... 81 16 Representations and Warranties of the Bidder ........................................................................................ 82 17 Indemnities ............................................................................................................................................. 83 18 Dispute Resolution .................................................................................................................................. 83 19 Miscellaneous ......................................................................................................................................... 84 20 ANNEXURE A – Definitions ................................................................................................................. 89 21 ANNEXURE B – Service Levels ........................................................................................................... 90 1 Purpose: .................................................................................................................................................. 90 2 Definitions: ............................................................................................................................................. 90 3 Interpretations: ........................................................................................................................................ 91 4 Service Level Agreements (SLAs) ......................................................................................................... 92



MASTER SERVICES AGREEMENT

THIS MASTER SERVICE AGREEMENT (“Agreement”) is made on this the <<‟Day‟>> day of

<<Month>> 2013 at Porvorim, Bardez, Goa, India.

BETWEEN

Info Tech Corporation of Goa Ltd., Government of Goa having its office at 4th Floor, Alcon

Construction, Above Alcon Hyundai Showroom, Porvorim, Bardez, Goa, India hereinafter

referred to as Info Tech Corporation of Goa Ltd (hereinafter called ITG, which expression shall,

unless the context otherwise requires, include its permitted successors and assigns);

AND

<<‟Implementing Agency full name‟>>, a Company incorporated under the Companies Act, 1956,

having its registered office at <<‟Regd Location‟>> (hereinafter referred to as <<„the System

integrator/SI’>> which expression shall, unless the context otherwise requires, include its permitted

successors and assigns).

Each of the parties mentioned above are collectively referred to as the „Parties‟ and individually as

a „Party‟.

WHEREAS:

1. ITG is desirous to implement the project of e-District for Goa.

2. In furtherance of the same, ITG undertook the selection of a suitable System integrator

through a competitive bidding process for implementing the Project and in this behalf

issued Request for Proposal (RFP) dated <<‟Date‟>> .

3. The successful bidder has been selected as the System integrator on the basis of the bid

response set out as Annexure D of this Agreement, to undertake the Project of the

development and implementation of the solution, its roll out and sustained operations.

NOW THEREFORE, in consideration of the mutual covenants, promises, assurances,

representations and provisions set forth herein, the Parties hereto agree as follows:

1 Definitions and Interpretation

1.1 Definitions

[Terms and expressions used in this Agreement (including the Introduction) shall have the

meanings set out in Schedule I.]



1.2 Interpretation

[In this Agreement, unless otherwise specified:]

I. references to Clauses, Sub-Clauses, Paragraphs, Schedules and Annexures are to

clauses, sub-clauses, paragraphs, schedules and annexures to this Agreement;

II. use of any gender includes the other genders;

III. references to a „company‟ shall be construed so as to include any company,

corporation or other body corporate, wherever and however incorporated or

established;

IV. references to a „person‟ shall be construed so as to include any individual, firm,

company, government, state or agency of a state, local or municipal authority or

government body or any joint venture, association or partnership (whether or not

having separate legal personality);

V. a reference to any statute or statutory provision shall be construed as a reference to

the same as it may have been, or may from time to time be, amended, modified or

re-enacted;

VI. any reference to a „day‟ (including within the phrase „business day‟) shall mean a

period of 24 hours running from midnight to midnight;

VII. references to a „business day‟ shall be construed as a reference to a day (other than

a sunday) on which banks in the State of Goa are generally open for business;

VIII. references to times are to Indian Standard Time;

IX. a reference to any other document referred to in this Agreement is a reference to

that other document as amended, varied, novated or supplemented at any time; and

X. all headings and titles are inserted for convenience only. They are to be ignored in

the interpretation of this Agreement.

XI. “System integrator (SI)” or “System integrator (SI)” has been used for the same entity

i.e. bidder selected for the project.

1.3 Measurements and Arithmetic Conventions

[All measurements and calculations shall be in the metric system and calculations done to 2 (two)

decimal places, with the third digit of 5 (five) or above being rounded up and below 5 (five) being

rounded down except in money calculations where such amounts shall be rounded off to the

nearest INR.]

1.4 Ambiguities within Agreement

[In case of ambiguities or discrepancies within this Agreement, the following principles shall

apply:]

I. as between two Clauses of this Agreement, the provisions of a specific Clause

relevant to the issue under consideration shall prevail over those in a general

Clause;

II. as between the provisions of this Agreement and the Schedules/Annexures, the



Agreement shall prevail, save and except as expressly provided otherwise in the

Agreement or the Schedules/Annexures; and

III. as between any value written in numerals and that in words, the value in words

shall prevail.

1.5 Priority of documents

[This Agreement, including its Schedules and Annexures, represents the entire agreement between

the Parties as noted in this Clause. If in the event of a dispute as to the interpretation or meaning of

this Agreement it should be necessary for the Parties to refer to documents forming part of the

bidding process leading to this Agreement, then such documents shall be relied upon and

interpreted in the following descending order of priority: ]

I. This Agreement along with the SLA agreement, NDA agreement, Schedules and

Annexures;

II. Request for Proposal and Addendum / Corrigendum to the Request for Proposal (if

any).

For the avoidance of doubt, it is expressly clarified that in the event of a conflict between this

Agreement, Annexures / Schedules or the contents of the RFP, the terms of this Agreement shall

prevail over the Annexures / Schedules and Annexures / Schedules shall prevail over the contents

and specifications of the RFP.

2 Scope of the Project

The scope of work for the SI will be as per the scope defined in the Volume II of the RFP.

Scope will include following activities to be carried out by the selected Bidder:



3. Business Process Reengineering for the selected applications/ services




7. Site Preparation



10. UAT & Go live


12. Operation & Maintenance (O&M) of e-District Application and SDC

The roles and responsibilities of the Parties under this Agreement have been set out in detail as

Annexure F of this Agreement. – To be put from Volume 1 after the same has been finalized and

approved at the time of signing the agreement.



For the avoidance of doubt, it is expressly clarified that this Agreement shall govern the provision

of the contracted professional services under the SLA to ITG and its nominated agencies. It is

anticipated that new or renewal agreements may be undertaken by creating a separate SLA, with

schedules and annexures as required, under this Agreement for each additional engagement.

3 Term and Duration of the Agreement

This Agreement shall come into effect on <<‟Date‟>> 20--- (hereinafter the „Effective Date‟) and

shall continue till operation and maintenance completion date which shall be the date of the

completion of the operation and maintenance to ITG or its nominated agencies.

4 Conditions Precedent & Effective Date

4.1 Provisions to take effect upon fulfillment of Conditions Precedent

Subject to express terms to the contrary, the rights and obligations under this Agreement shall take

effect only upon fulfillment of all the Conditions Precedent set out below. However, ITG or its

nominated agencies may at any time at its sole discretion waive fully or partially any of the

Conditions Precedent for the bidder

4.2 a. Conditions Precedent of the Bidder

The bidder shall be required to fulfill the Conditions Precedent in which is as follows:

I. to provide a Performance Security/Guarantee and other guarantees/ payments as

and when required to ITG or its nominated agencies; and

II. to provide ITG or its nominated agencies certified true copies of its constitutional

documents and board resolutions authorizing the execution, delivery and

performance of this Agreement by the bidder

4.2 b. Conditions Precedent of ITG

ITG shall be required to fulfill the Conditions Precedent which is as follows:

I. Allocation of space at the SDC, District Level and Taluka Level for hardware

installation.

II. Necessary clearances from DeITy for proceeding with the project and its financial

implications.

III. Approval of the Project by a Competent Authority, etc.

For the avoidance of doubt, it is expressly clarified that the obligations of the Parties except the

financial obligations of ITG or its nominated agencies under this Agreement shall commence from

the fulfillment of the Conditions Precedent as set forth above.

4.3 Extension of time for fulfillment of Conditions Precedent



[The Parties may, by mutual agreement extend the time for fulfilling the Conditions Precedent and

the Term of this Agreement.

For the avoidance of doubt, it is expressly clarified that any such extension of time shall be subject

to imposition of penalties on the bidder linked to the delay in fulfilling the Conditions Precedent.]

4.4 Non-fulfillment of the bidder‟s Conditions Precedent

I. In the event that any of the Conditions Precedent of the bidder have not been

fulfilled within 15 days of signing of this Agreement and the same have not been

waived fully or partially by ITG or its nominated agencies, this Agreement shall

cease to exist;

II. In the event that the Agreement fails to come into effect on account of non

fulfillment of the bidder‟s Conditions Precedent, ITG or its nominated agencies

shall not be liable in any manner whatsoever to the bidder and ITG shall forthwith

forfeit the Performance Guarantee.

III. In the event that possession of any of ITG‟s or its nominated agencies facilities has

been delivered to the bidder prior to the fulfillment of the Conditions Precedent,

upon the termination of this Agreement such shall immediately revert to ITG or its

nominated agencies, free and clear from any encumbrances or claims.

5 Obligations under the SLA

5.1 The SLA shall be a separate contract in respect of this Agreement and shall be entered into

concurrently with this Agreement between ITG and bidder

5.2 In relation to any future SLA entered into between the Parties; each of the Parties shall

observe and perform the obligations set out herein.

5.3 Change of Control

I. In the event of a change of control of the bidder during the Term, the bidder shall

promptly notify ITG and/or its nominated agencies of the same in the format set

out as Annexure A of this Agreement.

II. In the event that the net worth of the surviving entity is less than that of bidder

prior to the change of control, ITG or its nominated agencies may within 30 days of

becoming aware of such change in control, require a replacement of existing

Performance Guarantee furnished by the bidder from a guarantor acceptable to ITG

or its nominated agencies (which shall not be bidder or any of its associated

entities).

III. If such a guarantee is not furnished within 30 days of ITG or its nominated agencies

requiring the replacement, ITG may exercise its right to terminate the SLA and/ or

this Agreement within a further 30 days by written notice, to become effective as

specified in such notice.



IV. Pursuant to termination, the effects of termination as set out in Clause 14.2 of this

Agreement shall follow.

For the avoidance of doubt, it is expressly clarified that the internal reorganization of the bidder

shall not be deemed an event of a change of control for purposes of this Clause unless the

surviving entity is of less net worth than the predecessor entity.

5.4 Final testing and certification

The Project shall be governed by the mechanism of final acceptance testing and certification to be

put into place by ITG and bidder as under:

I. Final testing and certification criteria will lay down a set of guidelines following

internationally accepted norms and standards for testing and certification for all

aspects of project development and implementation covering software, hardware

and networking including the processes relating to the design of solution

architecture, design of systems and sub-systems, systems requirements

specification, coding, testing, documentation, version control, change management,

security, service oriented architecture, performance in relation to compliance with

SLA metrics, interoperability, scalability, availability and compliance with all the

technical and functional requirements of the RFP and this Agreement;

II. Final testing and certification criteria will be finalized from the development stage

to ensure that the guidelines are being followed and to avoid large scale

modifications pursuant to testing done after the application is fully developed;

III. Final testing and certification criteria will consider conducting specific tests on the

software, hardware, networking, security and all other aspects;

IV. Final testing and certification criteria will establish appropriate processes for

notifying the bidder of any deviations from the norms, standards or guidelines at

the earliest instance after taking cognizance of the same to enable the bidder to take

corrective action; etc.

5.5 The Parties shall each ensure that the range of the Services under the SLA shall not be

varied, reduced or increased except with the prior written agreement between ITG and

„<<System integrator>>‟ in accordance with the Change Control Schedule set out in

Schedule II of this Agreement. Save for the express terms of the Terms of Payment

Schedule set out as Schedule VI of this Agreement, ITG or its nominated agencies and its

users may purchase any particular category of Services that may become necessary as per

the Change Control Schedule set out in Schedule II of this Agreement, without the need to

go for a separate procurement process.

6 Representations and Warranties

6.1 Representations and warranties of the bidder

The bidder represents and warrants to ITG or its nominated agencies that:



I. it is duly organized and validly existing under the laws of India, and has full power

and authority to execute and perform its obligations under this Agreement and

other agreements and to carry out the transactions contemplated hereby;

II. it is a competent provider of a variety of information technology and business

process management services;

III. it has taken all necessary corporate and other actions under laws applicable to its

business to authorize the execution and delivery of this Agreement and to validly

exercise its rights and perform its obligations under this Agreement;

IV. from the Effective Date, it will have the financial standing and capacity to undertake

the Project in accordance with the terms of this Agreement;

V. in providing the Services, it shall use reasonable endeavours not to cause any

unnecessary disruption to ITG‟s normal business operations

VI. this Agreement has been duly executed by it and constitutes a legal, valid and

binding obligation, enforceable against it in accordance with the terms hereof, and

its obligations under this Agreement shall be legally valid, binding and enforceable

against it in accordance with the terms hereof;

VII. the information furnished in the tender documents and as updated on or before the

date of this Agreement is to the best of its knowledge and belief true and accurate in

all material respects as at the date of this Agreement;

VIII. the execution, delivery and performance of this Agreement shall not conflict with,

result in the breach of, constitute a default by any of the terms of its Memorandum

and Articles of Association or any Applicable Laws or any covenant, contract,

agreement, arrangement, understanding, decree or order to which it is a party or by

which it or any of its properties or assets is bound or affected;

IX. there are no material actions, suits, proceedings, or investigations pending or, to its

knowledge, threatened against it at law or in equity before any court or before any

other judicial, quasi-judicial or other authority, the outcome of which may result in

the breach of this Agreement or which individually or in the aggregate may result

in any material impairment of its ability to perform any of its material obligations

under this Agreement;

X. it has no knowledge of any violation or default with respect to any order, writ,

injunction or decree of any court or any legally binding order of any Government

Instrumentality which may result in any Adverse Effect on its ability to perform its

obligations under this Agreement and no fact or circumstance exists which may

give rise to such proceedings that would adversely affect the performance of its

obligations under this Agreement;

XI. it has complied with Applicable Laws in all material respects and has not been

subject to any fines, penalties, injunctive relief or any other civil or criminal

liabilities which in the aggregate have or may have an Adverse Effect on its ability

to perform its obligations under this Agreement;



XII. no representation or warranty by it contained herein or in any other document

furnished by it to ITG or its nominated agencies in relation to the Required

Consents contains or shall contain any untrue or misleading statement of material

fact or omits or shall omit to state a material fact necessary to make such

representation or warranty not misleading; and

XIII. no sums, in cash or kind, have been paid or shall be paid, by it or on its behalf, to

any person by way of fees, commission or otherwise for entering into this

Agreement or for influencing or attempting to influence any officer or employee of

ITG or its nominated agencies in connection therewith.

6.2 Representations and warranties of ITG or its nominated agencies

I. it has full power and authority to execute, deliver and perform its obligations under

this Agreement and to carry out the transactions contemplated herein and that it

has taken all actions necessary to execute this Agreement, exercise its rights and

perform its obligations, under this Agreement and carry out the transactions

contemplated hereby;

II. it has taken all necessary actions under Applicable Laws to authorize the execution,

delivery and performance of this Agreement and to validly exercise its rights and

perform its obligations under this Agreement;

III. it has the financial standing and capacity to perform its obligations under the

Agreement;

IV. it is subject to the laws of India, and hereby expressly and irrevocably waives any

immunity in any jurisdiction in respect of this Agreement or matters arising

thereunder including any obligation, liability or responsibility hereunder;

V. this Agreement has been duly executed by it and constitutes a legal, valid and

binding obligation enforceable against it in accordance with the terms hereof and its

obligations under this Agreement shall be legally valid, binding and enforceable

against it in accordance with the terms thereof;

VI. the execution, delivery and performance of this Agreement shall not conflict with,

result in the breach of, constitute a default under, or accelerate performance

required by any of the Applicable Laws or any covenant, contract, agreement,

arrangement, understanding, decree or order to which it is a party or by which it or

any of its properties or assets is bound or affected;

VII. there are no actions, suits or proceedings pending or, to its knowledge, threatened

against it at law or in equity before any court or before any other judicial, quasi-

judicial or other authority, the outcome of which may result in the default or breach

of this Agreement or which individually or in the aggregate may result in any

material impairment of its ability to perform its material (including any payment)


VIII. it has no knowledge of any violation or default with respect to any order, writ,



injunction or any decree of any court or any legally binding order of any

Government Instrumentality which may result in any Adverse Effect on ITG or its

nominated agencies ability to perform its obligations under this Agreement and no

fact or circumstance exists which may give rise to such proceedings that would

adversely affect the performance of its obligations under this Agreement;

IX. it has complied with Applicable Laws in all material respects;

X. all information provided by it in the RFP in connection with the Project is, to the

best of its knowledge and belief, true and accurate in all material respects; and

XI. upon the bidder performing the covenants herein, it shall not at any time during the

term hereof, interfere with peaceful exercise of the rights and discharge of the

obligations by the bidder , in accordance with this Agreement.

7 Obligations of ITG or its Nominated Agencies

I. To provide any support through personnel to test the system during the Term;

II. To provide any support through personnel and/or test data during development,

rollout, steady state operation, as well as, for any changes/enhancements in the

system whenever required due to scope change that may arise due to business,

delivery or statutory/regulatory reasons;

III. ITG shall provide the data (including in electronic form wherever available) to be

migrated.

IV. To authorize the bidder to interact for implementation of the Project with external

entities such as the state treasury, authorized banks, trademark database etc.

8 Obligations of the Implentation Partner

8.1 It shall provide to ITG or its nominated agencies, the Deliverables as set out in Annexure C

of this Agreement.

8.2 It shall perform the Services as set out in Section 2 of this Agreement and in a good and

workmanlike manner commensurate with industry and technical standards which are

generally in effect for international projects and innovations pursuant thereon similar to

those contemplated by this Agreement, and so as to comply with the applicable Service

Levels set out with this Agreement.

8.3 It shall ensure that the Services are being provided as per the Project Timelines set out as

Annexure C to this Agreement.

9 Approvals and required consents

9.1 The Parties shall cooperate to procure, maintain and observe all relevant and regulatory

and governmental licenses, clearances and applicable approvals (hereinafter the “Required

Consents”) necessary for the bidder to provide the Services. The costs of such Approvals

shall be borne by the Party normally responsible for such costs according to local custom

and practice in the locations where the Services are to be provided.[This responsibility of



taking Governmental licenses, clearances and applicable approvals requires to be explicitly worded in

the Scope of work in the RFP, only then this clause in its current shape would hold]

9.2 ITG or its nominated agencies shall use reasonable endeavours to assist bidder to obtain the

Required Consents [or vice versa, depending on the Scope of work defined in the RFP]. In the

event that any Required Consent is not obtained, the bidder and ITG or its nominated

agencies will co-operate with each other in achieving a reasonable alternative arrangement

as soon as reasonably practicable for ITG or its nominated agencies to continue to process

its work with as minimal interruption to its business operations as is commercially

reasonable until such Required Consent is obtained, provided that the bidder shall not be

relieved of its obligations to provide the Services and to achieve the Service Levels until the

Required Consents are obtained if and to the extent that the bidder’s obligations are not

dependent upon such Required Consents.

10 Use of assets by the Bidder

10.1 During the Term the bidder shall:

I. take all reasonable and proper care of the entire hardware and software, network or

any other information technology infrastructure components used for the Project

and other facilities leased / owned / operated by the bidder exclusively in terms of

ensuring their usability for the delivery of the Services as per this Agreement

(hereinafter the “Assets”) in proportion to their use and control of such Assets; and

II. keep all the tangible Assets in as good and serviceable condition (reasonable wear

and tear excepted) as at the date the bidder takes control of and/or first uses the

Assets and during the entire Term of the Agreement.

III. ensure that any instructions or manuals supplied by the manufacturer of the Assets

for use of the Assets and which are provided to the bidder will be followed by the

bidder and any person who will be responsible for the use of the Assets;

IV. take such steps as may be properly recommended by the manufacturer of the Assets

and notified to the bidder or as may, in the reasonable opinion of the System

integrator, be necessary to use the Assets in a safe manner;

V. ensure that the Assets that are under the control of the bidder , are kept suitably

housed and in conformity with Applicable Law;

VI. procure permission from ITG or its nominated agencies and any persons duly

authorized by them to enter any land or premises on which the Assets are for the

time being sited so as to inspect the same, subject to any reasonable third party

requirements;

VII. not, knowingly or negligently use or permit any of the Assets to be used in

contravention of any statutory provisions or regulation or in any way contrary to

Applicable Law.

11 Access to ITG or its Nominated Agencies Locations

11.1 For so long as the bidder provides services to ITG or its nominated agencies location, as the



case may be, on a non-permanent basis and to the extent necessary, ITG as the case may be

or its nominated agencies shall, subject to compliance by the bidder with any safety and

security guidelines which may be provided by the ITG as the case may be or its nominated

agencies and notified to the bidder in writing, provide the bidder with:

I. reasonable access, in the same manner granted to the ITG or its nominated agencies

employees, to the ITG location as the case may be, twenty-four hours a day, seven

days a week;

II. reasonable work space, access to office equipment as mutually agreed and other

related support services in such location and at such other ITG location as the case

may be, if any, as may be reasonably necessary for the bidder to perform its

obligations hereunder and under the SLA.

11.2 Access to locations, office equipments and services shall be made available to the bidder on

an “as is, where is” basis by ITG as the case may be or its nominated agencies. The bidder

agrees to ensure that its employees, agents and contractors shall not use the location,

services and equipment referred to in RFP for the following purposes:

I. for the transmission of any material which is defamatory, offensive or abusive or of

an obscene or menacing character; or

II. in a manner which constitutes a violation or infringement of the rights of any

person, firm or company (including but not limited to rights of copyright or

confidentiality).



12 Management Phase

12.1 Governance

The review and management process of this Agreement shall be carried out in accordance

with the Governance Schedule set out in Schedule V of this Agreement and shall cover all

the management aspects of the Project.

12.2 Use of Services

I. ITG as the case may be or its nominated agencies, will undertake and use the

Services in accordance with any instructions or procedures as per the acceptance

criteria as set out in the SLA or this Agreement or any agreement that may be

entered into between the Parties from time to time;

II. ITG as the case may be or its nominated agencies shall be responsible for the

operation and use of the Deliverables resulting from the Services.

12.3 Changes

Unless expressly dealt with elsewhere in this Agreement, any changes under or to this

Agreement or under or to the SLA shall be dealt with in accordance with the Change

Control Schedule set out in Schedule II of this Agreement.

12.4 Security and Safety

I. The bidder shall comply with the technical requirements of the relevant security,

safety and other requirements specified in the Information Technology Act or

Telegraph Act including the regulations issued by dept. of telecom (wherever

applicable), IT Security Manual of ITG as specifically stated in the RFP and follow

the industry standards related to safety and security (including those as stated in

the RFP), insofar as it applies to the provision of the Services.

II. Each Party to the SLA/Agreement shall also comply with ITG or the Government of

India, and Government of Goa security standards and policies in force from time to

time at each location of which ITG or its nominated agencies make the bidder aware

in writing insofar as the same apply to the provision of the Services.

III. The Parties to the SLA/Agreement shall use reasonable endeavours to report

forthwith in writing to each other all identified attempts (whether successful or not)

by unauthorized persons (including unauthorized persons who are employees of

any Party) either to gain access to or interfere with ITG as the case may be or any of

their nominees data, facilities or Confidential Information.

IV. The bidder shall upon reasonable request by ITG as the case may be or their

nominee(s) participate in regular meetings when safety and information technology

security matters are reviewed.

V. As per the provisions of the SLA or this Agreement, the bidder shall promptly report



in writing to ITG or its nominated agencies, any act or omission which they are

aware that could have an adverse effect on the proper conduct of safety and

information technology security at the facilities of ITG as the case may be.

12.5 Cooperation

Except as otherwise provided elsewhere in this Agreement or the SLA, each Party

(“Providing Party”) to this Agreement or to the SLA undertakes promptly to provide the

other Party (“Receiving Party”) with all such information and co-operation which the

Receiving Party reasonably requests, provided that such information and co-operation:

I. does not require material expenditure by the Providing Party to provide the same;

II. is reasonably required by the Receiving Party in order for it to comply with its

obligations under this Agreement or the SLA;

III. cannot be construed to be Confidential Information; and

IV. is capable of being provided by the Providing Party.

Further, each Party agrees to co-operate with the contractors and subcontractors of the

other Party as reasonably requested in order to accomplish the purposes of this Agreement.

13 Financial Matters

13.1 Terms of Payment and Service Credits and Debits

I. In consideration of the Services and subject to the provisions of this Agreement and

of the SLA, ITG shall pay the bidder for the Services rendered in pursuance of this

agreement, in accordance with the Terms of Payment Schedule set out as Schedule

VI of this Agreement.

II. All payments are subject to the application of service credits and debits as may be

provided for in the SLA. For the avoidance of doubt, it is expressly clarified that

ITG will pay the service credits as stated in accordance with the Schedule VI of this

Agreement and ITG may also calculate a financial sum and debit the same against

the terms of payment as set out in Schedule VI of this Agreement as a result of the

failure of the bidder to meet the Service Level as defined in SLA. ITG (on request

from successful bidders) can look at having a separate mechanism for settling

penalties/service credits rather than the set off against the invoice as this could

revenue recognition issues. However, the successful bidder has to ensure that such

settlement happens within a stipulated timeframe]

III. Save and except as otherwise provided for herein or as agreed between the Parties

in writing, ITG shall not be required to make any payments in respect of the

Services (or, without limitation to the foregoing, in respect of the bidder

performance of any obligations under this Agreement or the SLA) other than those

covered in Schedule VI of this Agreement. For the avoidance of doubt, it is

expressly clarified that the payments shall be deemed to include all ancillary and

incidental costs and charges arising in the course of delivery of the Services



including consultancy charges, infrastructure costs, project costs, implementation

and management charges and all other related costs including taxes which are

addressed in this Clause.

13.2 Invoicing and Settlement

I. Subject to the specific terms of the SLA, the bidder shall submit its invoices in

accordance with the following principles:

A. ITG shall be invoiced by the bidder for the Services. Generally and unless

otherwise agreed in writing between the Parties or expressly set out in the

SLA, the bidder shall raise an invoice as per Schedule VI of this Agreement;

and

B. Any invoice presented in accordance with this Article shall be in a form

agreed with ITG.

II. The bidder alone shall invoice all payments after receiving due approval from the

competent authority. Such invoices shall be accurate and all adjustments to or

changes in the terms of payment as stated in Schedule VI of this Agreement. The

bidder shall waive any charge for a Service that is not invoiced within six months

after the end of the month in which the change relating to such Service is (i)

authorized or (ii) incurred, whichever is later.

III. Payment shall be made within 30 working days of the receipt of invoice along with

supporting documents by ITG subject to penalties. The penalties are imposed on the

vendor as per the SLA criteria specified in the SLA.

IV. ITG shall be entitled to delay or withhold payment of any invoice or part of it

delivered by the bidder under Schedule VI of this Agreement where ITG

disputes/witholds such invoice or part of it provided that such dispute is bona fide.

The withheld amount shall be limited to that which is in dispute. The disputed /

witheld amount shall be settled in accordance with the escalation procedure as set

out in Schedule V of this Agreement. Any exercise by ITG under this Clause shall

not entitle the bidder to delay or withhold provision of the Services.

V. ITG shall be entitled to delay or withhold part of the payment of any invoice which

is under a dispute. The withheld amount shall be limited to that which is the

disputed amount. The disputed amount shall be referred to the escalation

procedure as set out in Schedule V of this Agreement. Any exercise by ITG under

this Clause shall not entitle the bidder to delay or withhold provision of the

Services.

VI. The bidder shall be solely responsible to make payment to its sub-contractors.

13.3 Tax

I. ITG or its nominated agencies shall be responsible for withholding taxes from the

amounts due and payable to the bidder wherever applicable. The bidder shall pay

for all other taxes in connection with this Agreement, SLA, scope of work and any



other engagement required to be undertaken as a part of this Agreement, including,

but not limited to, property, sales, use, excise, value-added, goods and services,

consumption and other similar taxes or duties.

II. ITG or its nominated agencies shall provide bidder with the original tax receipt of

any withholding taxes paid by ITG or its nominated agencies on payments under

this Agreement. The bidder agrees to reimburse and hold ITG or its nominated

agencies harmless from any deficiency including penalties and interest relating to

taxes that are its responsibility under this paragraph. For purposes of this

Agreement, taxes shall include taxes incurred on transactions between and among

ITG or its nominated agencies, the bidder and third party subcontractors.

III. If, after the date of this Agreement, there is any change of rate of levy under the

existing applicable laws of India with respect to taxes and duties, which are directly

payable by ITG for providing the services i.e. service tax or any such other

applicable tax from time to time, which increase or decreases the cost incurred by

the SI in performing the Services, then the remuneration and reimbursable expense

otherwise payable to ITG under this Agreement shall be increased or decreased

accordingly by correspondence between the Parties hereto, and corresponding

adjustments shall be made to the ceiling amounts specified in Schedule VI.

However, in case of any new or fresh tax or levy imposed after submission of the

proposal the bidder shall be entitled to reimbursement on submission of proof of

payment of such tax or levy.

IV. The Parties shall cooperate to enable each Party to accurately determine its own tax

liability and to minimize such liability to the extent legally permissible. In

connection therewith, the Parties shall provide each other with the following:

A. any resale certificates;

B. any relevant information regarding out-of-state or use of materials,

equipment or services; and

C. any direct pay permits, exemption certificates or information reasonably

requested by the other Party.

14 Termination

14.1 Material Breach

I. In the event that either Party believes that the other Party is in Material Breach of its

obligations under this Agreement, such aggrieved Party may terminate this

Agreement upon giving a one month‟s notice for curing the Material Breach to the

other Party. In case the Material Breach continues, after the notice period, ITG or

bidder , as the case may be will have the option to terminate the Agreement. Any

notice served pursuant to this Clause shall give reasonable details of the Material

Breach, which could include the following events and the termination will become

effective:



A. If the bidder is not able to deliver the services as per the SLAs defined in RFP

which translates into Material Breach, then ITG may serve a 30 days written

notice for curing this Material Breach. In case the Material Breach continues,

after the expiry of such notice period, ITG will have the option to terminate this

Agreement. Further, ITG may after affording a reasonable opportunity to the

bidder to explain the circumstances leading to such a breach.

B. If there is a Material Breach by ITG or its nominated agencies which results in

not providing support for effecting data migration or not providing the

certification of User Acceptance, and / or failing to make payment of

undisputed amount within 30 days from the date of submission of invoice, then

the bidder will give a one month‟s notice for curing the Material Breach to ITG.

After the expiry of such notice period, the bidder will have the option to

terminate the Agreement

II. ITG may, by giving a one month‟s written notice, terminate this Agreement if a

change of control of the bidder has taken place. For the purposes of this Clause, in

the case of bidder , change of control shall mean the events stated in Clause 5.3, and

such notice shall become effective at the end of the notice period as set out in Clause

5.3 (c).

III. In the event that bidder undergoes such a change of control, ITG may, as an

alternative to termination, require a full Performance Guarantee for the obligations

of bidder by a guarantor acceptable to ITG or its nominated agencies. If such a

guarantee is not furnished within 30 days of ITG‟s demand, ITG may exercise its

right to terminate this Agreement in accordance with this Clause by giving 15 days

further written notice to the bidder

IV. The termination provisions set out in this Clause shall apply mutatis mutandis to

the SLA.

14.2 Effects of termination

I. In the event that ITG terminates this Agreement pursuant to failure on the part of

the bidder to comply with the conditions as contained in this Clause and depending

on the event of default, Performance Guarantee furnished by bidder may be

forfeited.

II. Upon termination of this Agreement, the Parties will comply with the Exit

Management Schedule set out as Schedule III of this Agreement.

III. In the event that ITG or the bidder terminates this Agreement, the compensation will

be decided in accordance with the Terms of Payment Schedule set out as Schedule

VI of this Agreement.

IV. ITG agrees to pay bidder for i) all charges for Services bidder provides and any

Deliverables and/or system (or part thereof) bidder delivers through termination,

and ii) reimbursable expenses bidder incurs through termination. If ITG terminates



without cause, ITG also agrees to pay any applicable adjustment expenses bidder

incurs as a result of such termination (which bidder will take reasonable steps to

mitigate).

14.3 Termination of this Agreement due to bankruptcy of Bidder

ITG may serve written notice on bidder at any time to terminate this Agreement with

immediate effect in the event that the bidder reporting an apprehension of bankruptcy to

ITG or its nominated agencies

15 Indemnification & Limitation of Liability

15.1 Subject to Clause 15.2 below, bidder (the "Indemnifying Party") undertakes to indemnify

ITG (the "Indemnified Party") from and against all Losses on account of bodily injury, death or

damage to tangible personal property arising in favour of any person, corporation or other entity

(including the Indemnified Party) attributable to the Indemnifying Party's negligence or willful

default in performance or non-performance under this Agreement. If the Indemnified Party

promptly notifies Indemnifying Party in writing of a third party claim against Indemnified Party

that any Service provided by the Indemnifying Party infringes a copyright, trade secret or patents

incorporated in India of any third party, Indemnifying Party will defend such claim at its expense

and will pay any costs or damages that may be finally awarded against Indemnified Party.

Indemnifying Party will not indemnify the Indemnified Party, however, if the claim of

infringement is caused by (a) Indemnified Party‟s misuse or modification of the Service;

(b) Indemnified Party‟s failure to use corrections or enhancements made available by the

Indemnifying Party; (c) Indemnified Party‟s use of the Service in combination with any product or

information not owned or developed by Indemnifying Party; (d) Indemnified Party‟s distribution,

marketing or use for the benefit of third parties of the Service; or (e) information, direction,

specification or materials provided by Indemnified Party or any third party contracted to it. If any

Service is or likely to be held to be infringing, Indemnifying Party shall at its expense and option

either (i) procure the right for Indemnified Party to continue using it, (ii) replace it with a

noninfringing equivalent, (iii) modify it to make it noninfringing. The foregoing remedies

constitute Indemnified Party‟s sole and exclusive remedies and Indemnifying Party‟s entire

liability with respect to infringement.

15.2 The indemnities set out in Clause 15.1 shall be subject to the following conditions:

I. the Indemnified Party as promptly as practicable informs the Indemnifying

Party in writing of the claim or proceedings and provides all relevant

evidence, documentary or otherwise;

II. the Indemnified Party shall, at the cost of the Indemnifying Party, give the

Indemnifying Party all reasonable assistance in the Defense of such claim

including reasonable access to all relevant information, documentation and

personnel provided that the Indemnified Party may, at its sole cost and

expense, reasonably participate, through its attorneys or otherwise, in such

Defense;



III. if the Indemnifying Party does not assume full control over the Defense of a

claim as provided in this Article, the Indemnifying Party may participate in

such Defense at its sole cost and expense, and the Indemnified Party will

have the right to defend the claim in such manner as it may deem

appropriate, and the cost and expense of the Indemnified Party will be

included in Losses;

IV. the Indemnified Party shall not prejudice, pay or accept any proceedings or

claim, or compromise any proceedings or claim, without the written consent

of the Indemnifying Party;

V. all settlements of claims subject to indemnification under this Clause will:

A. be entered into only with the consent of the Indemnified Party,

which consent will not be unreasonably withheld and include an

unconditional release to the Indemnified Party from the claimant

or plaintiff for all liability in respect of such claim; and

B. include any appropriate confidentiality agreement prohibiting

disclosure of the terms of such settlement;

VI. the Indemnified Party shall account to the Indemnifying Party for all

awards, settlements, damages and costs (if any) finally awarded in favour of

the Indemnified Party which are to be paid to it in connection with any such

claim or proceedings;

VII. the Indemnified Party shall take steps that the Indemnifying Party may

reasonably require to mitigate or reduce its loss as a result of such a claim or

proceedings;

VIII. in the event that the Indemnifying Party is obligated to indemnify an

Indemnified Party pursuant to this Article, the Indemnifying Party will,

upon payment of such indemnity in full, be subrogated to all rights and

defenses of the Indemnified Party with respect to the claims to which such

indemnification relates; and

IX. if a Party makes a claim under the indemnity set out under Clause 15.1

above in respect of any particular Loss or Losses, then that Party shall not be

entitled to make any further claim in respect of that Loss or Losses

(including any claim for damages).

15.3 The liability of bidder (whether in contract, tort, negligence, strict liability in tort, by statute

or otherwise) for any claim in any manner related to this Agreement, including the work,

deliverables or Services covered by this Agreement, shall be the payment of direct damages only

which shall in no event in the aggregate exceed the amount specified in the contract. The liability

cap given under this Clause 15.3 shall not be applicable to the indemnification obligations set out

in Clause 15.1 and breach of Clause 12.4 and 17.



15.4 In no event shall either party be liable for any consequential, incidental, indirect, special or

punitive damage, loss or expenses (including but not limited to business interruption, lost

business, lost profits, or lost savings) nor for any third party claims (other than those set-forth in

Clause 15.1) even if it has been advised of their possible existence.

15.5 The allocations of liability in this Section 15 represent the agreed and bargained-for

understanding of the parties and compensation for the Services reflects such allocations. Each

Party has a duty to mitigate the damages and any amounts payable under an indemnity that

would otherwise be recoverable from the other Party pursuant to this Agreement by taking

appropriate and commercially reasonable actions to reduce or limit the amount of such damages

or amounts.

16 Force Majeure

[16.1 Definition of Force Majeure

The bidder or ITG as the case may be, shall be entitled to suspend or excuse performance of its

respective obligations under this Agreement to the extent that such performance is impeded by an

event of force majeure („Force Majeure‟).]

16.2 Force Majeure events

[A Force Majeure event means any event or circumstance or a combination of events and

circumstances referred to in this Clause, which:]

I. is beyond the reasonable control of the affected Party;

II. such Party could not have prevented or reasonably overcome with the exercise of

reasonable skill and care;

III. does not result from the negligence of such Party or the failure of such Party to


IV. is of an incapacitating nature and prevents or causes a delay or impediment in

performance; and

V. may be classified as all or any of the following events:

Such events include:

Non-Political Events

(A) act of God, including earthquake, flood, inundation, landslide,

exceptionally adverse weather conditions, storm, tempest, hurricane,

cyclone, lightning, thunder, volcanic eruption, fire or other extreme

atmospheric conditions;

(B) radioactive contamination or ionizing radiation or biological

contamination except as may be attributable to the bidder’s use of

radiation or radio-activity or biologically contaminating material;

(C) strikes, lockouts, boycotts, labour disruptions or any other industrial



disturbances as the case may be not arising on account of the acts or

omissions of the bidder and which affect the timely implementation

and continued operation of the Project; or

(D) any event or circumstances of a nature analogous to any of the

foregoing.

Political Events

(E) Change in Law, other than any Change in Law for which relief is

provided under this Agreement;

(F) expropriation or compulsory acquisition by ITG or any of their

nominated agencies of any material assets or rights of the bidder

(G) unlawful or unauthorised revocation of, or refusal by ITG or any of

their nominated agencies, GoI or any of its agencies to renew or grant

any clearance or Required Consents required by the bidder to perform

its obligations without valid cause, provided that such delay,

modification, denial, refusal or revocation did not result from the

bidder’s inability or failure to comply with any condition relating to

grant, maintenance or renewal of such Required Consents applied on

a non-discriminatory basis;

(H) any judgment or order of any court of competent jurisdiction or

statutory authority in India made against the bidder in any

proceedings for reasons other than failure of the bidder to comply

with Applicable Laws or Required Consents or on account of breach

thereof, or of any contract, or enforcement of this Agreement or

exercise of any of its rights under this Agreement;

(I) expropriation or compulsory acquisition by ITG or any of their

nominated agencies of any material assets or rights of the bidder

(J) unlawful or unauthorized revocation of, or refusal by any authority

other than ITG or any of their nominated agencies to renew or grant

any Required Consents required by the bidder to perform its

obligations without valid cause, provided that such delay,

modification, denial, refusal or revocation did not result from the

bidder’s inability or failure to comply with any condition relating to

grant, maintenance or renewal of such Required Consents applied on

a non-discriminatory basis;

(K) any requisition of the Project by any other authority; or

(L) any requisition of the Project by ITG or any of their nominated

agencies.

(M) For the avoidance of doubt, suspension of the Project in accordance

with the provisions of this Agreement shall not be considered a

requisition for the purposes of Force Majeure event.



Other Events

(N) an act of war (whether declared or undeclared), hostilities, invasion,

armed conflict or act of foreign enemy, blockade, embargo,

prolonged riot, insurrection, terrorist or military action, civil

commotion or politically motivated sabotage, for a continuous period

exceeding seven (7) days.

For the avoidance of doubt, it is expressly clarified that the failure on the part of the bidder under

this Agreement or the SLA to implement any disaster contingency planning and back-up and

other data safeguards in accordance with the terms of this Agreement or the SLA against natural

disaster, fire, sabotage or other similar occurrence shall not be deemed to be a Force Majeure event.

For the avoidance of doubt, it is further clarified that any negligence in performance of Services

which directly causes any breach of security like hacking aren‟t the forces of nature and hence

wouldn‟t be qualified under the definition of “Force Majeure”. In so far as applicable to the

performance of Services, Service Provider will be solely responsible to complete the risk assessment and

ensure implementation of adequate security hygiene, best practices, processes and technology to prevent

any breach of security and any resulting liability therefrom (wherever applicable).

16.3 Notification procedure for Force Majeure

(a) The affected Party shall notify the other Party of a Force Majeure event within seven

(7) days of occurrence of such event. If the other Party disputes the claim for relief

under Force Majeure it shall give the claiming Party written notice of such dispute

within thirty (30) days of such notice. Such dispute shall be dealt with in accordance

with the dispute resolution mechanism in accordance with Clause

(b) Upon cessation of the situation which led the Party claiming Force Majeure, the

claiming Party shall within seven (7) days hereof notify the other Party in writing of

the cessation and the Parties shall as soon as practicable thereafter continue

performance of all obligations under this Agreement.

16.4 Allocation of costs arising out of Force Majeure

(a) Upon the occurrence of any Force Majeure Event prior to the Effective Date, the

Parties shall bear their respective costs and no Party shall be required to pay to the

other Party any costs thereof.

Upon occurrence of a Force Majeure Event after the Effective Date, the costs incurred and

attributable to such event and directly relating to the Project („Force Majeure Costs‟) shall be

allocated and paid as follows:

upon occurrence of a Non-Political Event, the Parties shall bear their respective

Force Majeure Costs and neither Party shall be required to pay to the other Party

any costs thereof.

upon occurrence of an Other Event of Force Majeure, all Force Majeure Costs

attributable to such Other Event, and not exceeding the Insurance Cover for such



Other Event, shall be borne by the bidder and to the extent Force Majeure costs

exceed such Insurance Cover, one half of such excess amount shall be reimbursed

by ITG to the bidder (optional clause – to be used, if relevant.)

upon occurrence of a Political Event, all Force Majeure Costs attributable to such

Political Event shall be reimbursed by ITG to the bidder

For the avoidance of doubt, Force Majeure Costs may include interest payments on

debt, operation and maintenance expenses, any increase in the cost of the Services

on account of inflation and all other costs directly attributable to the Force Majeure

Event.

Save and except as expressly provided in this Clause, neither Party shall be liable in

any manner whatsoever to the other Party in respect of any loss, damage, costs,

expense, claims, demands and proceedings relating to or arising out of occurrence

or existence of any Force Majeure Event or exercise of any right pursuant hereof.

16.5 Consultation and duty to mitigate

I. Except as otherwise provided in this Clause, the affected Party shall, at its own cost,

take all steps reasonably required to remedy and mitigate the effects of the Force

Majeure event and restore its ability to perform its obligations under this

Agreement as soon as reasonably practicable. The Parties shall consult with each

other to determine the reasonable measures to be implemented to minimize the

losses of each Party resulting from the Force Majeure event. The affected Party shall

keep the other Parties informed of its efforts to remedy the effect of the Force

Majeure event and shall make reasonable efforts to mitigate such event on a

continuous basis and shall provide written notice of the resumption of performance

hereunder.

17 Confidentiality

17.1 ITG or its nominated agencies shall allow the bidder to review and utilize highly

confidential public records and the bidder shall maintain the highest level of secrecy,

confidentiality and privacy with regard thereto.

17.2 Additionally, the bidder shall keep confidential all the details and information with regard

to the Project, including systems, facilities, operations, management and maintenance of the

systems/facilities.

17.3 ITG or its nominated agencies shall retain all rights to prevent, stop and if required take the

necessary punitive action against the bidder regarding any forbidden disclosure.

17.4 The bidder shall ensure that all its employees, agents and sub-contractors execute individual

non disclosure agreements, which have been duly approved by ITG with respect to this

Project.(Optional)

For the avoidance of doubt, it is expressly clarified that the aforesaid provisions shall not

apply to the following information:



(a) information already available in the public domain;

(b) information which has been developed independently by the bidder

(c) information which has been received from a third party who had the right to

disclose the aforesaid information;

(d) Information which has been disclosed to the public pursuant to a court order.

17.5 To the extent the bidder shares its confidential or propriteray information with ITG for

effective performance of the Services, the provisions of the Clause 17.1 to 17.3 shall apply

mutatis mutandis on ITG or its nominated agencies.

18 Audit, Access and Reporting

The bidder shall allow access to ITG or its nominated agencies to all information which is in the

possession or control of the bidder and which relates to the provision of the Services as set out in

the Audit, Access and Reporting Schedule and which is reasonably required by ITG to comply

with the terms of the Audit, Access and Reporting Schedule set out as Schedule IV of this

Agreement.

19 Intellectual Property Rights

19.1 Products and fixes: All products and related solutions and fixes provided pursuant to this

work order shall be licensed according to the terms of the license agreement packaged with or

otherwise applicable to such product. bidder would be responsible for arranging any licenses

associated with products. “Product” means any computer code, web-based services, or materials

comprising commercially released, pre-release or beta products (whether licensed for a fee or no

charge) and any derivatives of the foregoing which are made available to ITG for license which is

published by product owner or its affiliates, or a third party. “Fixes” means product fixes that are

either released generally (such as commercial product service packs) or that are provided to you

when performing services (such as workarounds, patches, bug fixes, beta fixes and beta builds)

and any derivatives of the foregoing.

19.2 Bespoke development: Subject to the provisions of Clause 19.3 and 19.4 below, upon

payment, the IPR rights for any bespoke development done during the implementation of the

project will lie with ITG. Bidder shall be entitled to a broad license back in the bespoke

development for its internal usage and other e-governance projects.

19.3 Pre-existing work: All IPR including the source code and materials developed or otherwise

obtained independently of the efforts of a party under this Agreement (“pre-existing work”)

including any enhancement or mdofification thereto shall remain the sole property of that party.

During the performance of the services for this agreement, each party grants to the other party

(and their sub-contractors as necessary) a non-exclusive license to use, reproduce and modify any

of its pre-existing work provided to the other party solely for the performance of such services for

duration of the Term of this Agreement. Except as may be otherwise explicitly agreed to in a

statement of services, upon payment in full, the bidder should grant ITG a non-exclusive, perpetual,



fully paid-up license to use the pre-existing work in the form delivered to ITG as part of the service

or deliverables only for its internal business operations. Under such license, either of parties will

have no right to sell the pre-existing work of the other party to a Third Party. ITG‟s license to

pre-existing work is conditioned upon its compliance with the terms of this Agreement and the

perpetual license applies solely to the pre-existing work that bidder leaves with ITG at the

conclusion of performance of the services.

19.4 Residuals: In no event shall bidder be precluded from independently developing for itself, or

for others, anything, whether in tangible or non-tangible form, which is competitive with, or

similar to, the deliverables, set-out in this Agreement or Annexure. In addition, subject to the

confidentiality obligations, bidder shall be free to use its general knowledge, skills and experience,

and any ideas, concepts, know-how, and techniques that are acquired or used in the course of

providing the Services.

20 Warranty

20.1 Standard: The bidder warrants that the Project, including all the system(s) and other Services

provided, shall be free from any defect or deficiency in the material, design, engineering, and

performance/workmanship that prevent the Project and/or any of its systems(s) from fulfilling

the technical requirements or that limit in a material fashion the performance, reliability, or

extensibility of the Project and/or any of its system(s) as per the performance guarantee /

warranty period defined in the Schedule. If during the warranty period any defect or deficiency is

found in the material, design and performance/workmanship of the Project and other Services

provided by the bidder, the bidder shall promptly, in consultation and agreement with ITG, and at

the bidder’s sole cost repair, replace, or otherwise make good (as the bidder shall, at its discretion,

determine) such default, defect or deficiency as well as any damage to the Project caused by such

default, defect or deficiency. Any defective system that has been replaced by the bidder shall

remain the property of the bidder If the Project or any of its System cannot be used by reason of

such default, defect or deficiency and/or making good of such default, defect or deficiency, the

warranty period for the Project shall be extended by a period equal to the period during which the

Project or any of its system could not be used by ITG because of such defect and/or making good

of such default, defect or deficiency.

20.2 Implied Warranty: The warranties provided herein are in lieu of all other warranties, both

express and implied, and all other warranties, including without limitation that of merchantability

or fitness for intended purpose is specifically disclaimed.

20.3 The bidder shall have no liability in the case of breach of this warranty due to (i) use of the

deliverables on any environment (hardware or software) other than the environment

recommended or approved by the bidder , (ii) the combination, operation, or use of some or all of

the deliverables with information, software, specifications, instructions, data, or materials not



approved by the bidder (iii) the deliverables having been tampered with, altered or modified by

ITG without the written permission of the bidder , or (iv) use of the deliverables otherwise than in

terms of the relevant documentation.

21 Liquidated Damages

Time is the essence of the Agreement and the delivery dates are binding on the bidder In the event

of delay or any gross negligence, for causes attributable to the System integrator, in meeting the

deliverables, ITG shall be entitled at its option to recover from the bidder as agreed, liquidated

damages, a sum of 0.5% of the value of the deliverable which suffered delay or gross negligence

for each completed week or part thereof subject to a limit of 5% of the relevant deliverable value.

22 Software Escrow Agreement

22.1 The bidder shall comply with the provisions below for all Public Material and Proprietary

Vendor Material (including subcontractor-owned materials and other Third Party Material

incorporated in bidder’s Proprietary Material), except to the extent bidder demonstrates to the

satisfaction of ITG that compliance is not permitted by the nature of bidder’s limited rights in

such material.

22.2 Within ninety (90) days after ITG‟s acceptance of the Solution, the Parties shall enter into a

software escrow agreement (“Escrow Agreement”) with a reputable, independent, third party

that provides software escrow services among its principal business offerings (“Escrow

Agent”). The Escrow Agreement shall provide for the regular deposit into escrow of all source

code (including without limitation all make files, configurational files, data tables upon which

execution is dependent, and the like, collectively the “Source Code”), object code, and

documentation with respect to all Public Material and bidder’s Proprietary Material (and

cumulative updates thereof), together with (a) continually updated instructions as to the

compilation, installation, configuration, deployment, and use of the Source Code, and (b) a list

of all non-deposited third party software used in conjunction with the Source Code to provide

the full functionality of the deposited materials. In the event of the termination or expiration of

the initial Escrow Agreement or any successor agreement, with minimal delay the Parties shall

enter into a substantially equivalent agreement with a successor provider of software escrow

services (who shall then be known as the “Escrow Agent”). The bidder has to handover source

code to ITG on completion of the Go-Liveof the project and thereafter every 6 monts

depending on the changes made in the eDistrict application.

22.3 Bidder will make its initial deposit of Source Code within fifteen (15) days after the effective

date of the Escrow Agreement.

22.4 Bidder shall periodically update the escrow deposit as the Parties shall agree in the Escrow

Agreement. In addition to other usual and customary terms, the Escrow Agreement shall

provide that ITG shall be entitled to obtain the deposited materials from escrow upon ITG‟s



making a proper claim for release from escrow in the event that (c) proper written notice is

given to the Escrow Agent that release of the copy of the deposited materials is pursuant to

applicable Central or ITG bankruptcy, insolvency, reorganization, or liquidation statute; (d)

bidder files articles of dissolution (but not if bidder is consolidated or merged into another

entity); (e) the Contract expires or terminates for Material Breach of bidder

22.5 The release of deposited materials from escrow shall not confer upon ITG any right of

ownership in the deposited materials or the underlying intellectual property embodied therein.

In the event of the release of deposited materials to ITG from escrow, ITG shall use the

deposited materials solely for the benefit of ITG and its constituents, consistently with the

grants of license set forth in Clause 19.2 of this Agreement.

22.6 The release of materials from escrow, without more, shall not cause any further amounts to

accrue as payable to bidder by ITG, and the term of ITG‟s possessory and usage rights with

respect to the released materials shall be perpetual.

22.7 The Escrow Agreement shall provide for its automatic termination upon the earlier of five

(5) years after the expiration or termination of this Contract, or, release of all Source Code to

ITG and ITG‟s subsequent confirmation of compliance with the terms of the Escrow

Agreement. bidder shall pay the escrow costs, as well as all costs associated with causing its

subcontractors and other third parties to abide by the Escrow Agreement.

23 Insurance Cover

23.1 Obligation to maintain insurance

In connection with the provision of the Services, the Service Provider must have and

maintain:

(a) for the Agreement Period, valid and enforceable insurance coverage for:

(i) public liability;

(ii) either professional indemnity or errors and omissions;

(iii) product liability;

(iv) workers‟ compensation as required by law; and

(v) any additional types specified in Schedule I; and

(b) for <three> years following the expiry or termination of the Agreement, valid and

enforceable insurance policies (if relevant),

in the amount not less than the Insurance Cover specified in Schedule I.

23.2 Certificates of currency

The bidder must, on request by ITG, provide current relevant confirmation of insurance

documentation from its insurance brokers certifying that it has insurance as required by this

Clause 23.The Service Provider agrees to replace any coverage prior to the date of



expiry/cancellation.

23.3 Non-compliance

ITG or its nominated agencies may, at its election, terminate this Agreement upon the failure of

bidder , or notification of such failure, to maintain the required insurance coverage. Inadequate

insurance coverage for any reason shall not relieve bidder of its obligations under this Agreement.

24 Miscellaneous

[24.1 Personnel

(a) The personnel assigned by bidder to perform the Services shall be employees of bidder or

its subcontractor(s), and under no circumstances shall such personnel be considered employees of

ITG or its nominated agencies. The bidder shall have the sole responsibility for the supervision and

control of the personnel deployed in the Project and for payment of such personnel‟s

compensation, including salary, withholding of income taxes and social security taxes, worker‟s

compensation, employee and disability benefits and the like and shall be responsible for all

obligations of an employer subject to Applicable Law.

(b) The bidder shall use its best efforts to ensure that sufficient bidder personnel are assigned

to perform the Services and that such personnel have appropriate qualifications to perform the

Services. After discussion with bidder , ITG or its nominated agencies shall have the right to

require the removal or replacement of any bidder personnel performing work under this

Agreement based on bonafide reasons. In the event that ITG or its nominated agencies requests

that any bidder personnel be replaced, the substitution of such personnel shall be accomplished

pursuant to a mutually agreed upon schedule.

(d) In the event that ITG and bidder identify any personnel of bidder as “Key Personnel”, then

the bidder shall not remove such personnel from the Project without the prior written consent of

ITG or its nominated agencies unless such removal is the result of an unavoidable circumstance

including but not limited to resignation, termination, medical leave, etc.

(e) Except as stated in this Clause, nothing in this Agreement or the SLA will limit the ability

of bidder to freely assign or reassign its employees; provided that bidder shall be responsible, at its

expense, for transferring all appropriate knowledge from personnel being replaced to their

replacements. ITG or its nominated agencies shall have the right to review and approve bidder‟s

plan for any such knowledge transfer. bidder shall maintain the same or higher standards for skills

and professionalism among replacement personnel as in personnel being replaced.

(f) Each Party shall be responsible for the performance of all its obligations under this

Agreement or the SLA as the case may be and shall be liable for the acts and omissions of its

employees and agents in connection therewith.

(g) Neither Party will solicit for employment or knowingly hire an employee of the other Party

with whom such Party has contact pursuant to project engagements under this Agreement. This

restriction shall not apply to employees of either Party responding to advertisements in job fairs or

news media circulated to the general public.



24.2 Independent Contractor

Nothing in this Agreement or the SLA shall be construed as establishing or implying any

partnership or joint venture between the Parties to this Agreement or the SLA and, except as

expressly stated in this Agreement or the SLA, nothing in this Agreement or the SLA shall be

deemed to constitute any Parties as the agent of any other Party or authorizes either Party to:

(a) incur any expenses on behalf of the other Party;

(b) enter into any engagement or make any representation or warranty on behalf of the other

Party;

(c) pledge the credit of or otherwise bind or oblige the other Party; or

(d) commit the other Party in any way whatsoever without in each case obtaining the other

Party‟s prior written consent.]

24.3 Sub-contractors

[bidder shall not subcontract any work except <site preparation > without ITG‟s prior written

consent. However the bidder shall provide the list of all the other services planned to be sub

contracted, within 15 days of signing the Agreement. It is clarified that the bidder shall be the

principal employer for all claims arising from the liabilities statutory or otherwise, concerning the

sub-contractors. The bidder undertakes to indemnify ITG or its nominated agencies from any

claims on the grounds stated hereinabove.]

24.4 Assignment

(a) All terms and provisions of this Agreement shall be binding on and shall inure to

the benefit of ITG and their respective successors and permitted assigns.

(b) Subject to Clause 5.3, the bidder shall not be permitted to assign its rights and

obligations under this Agreement to any third party.

(c) ITG may assign or novate all or any part of this Agreement and

Schedules/Annexures, and the bidder shall be a party to such novation, to any third

party contracted to provide outsourced services to ITG or any of its nominees.

24.5 Trademarks, Publicity

Neither Party may use the trademarks of the other Party without the prior written consent of the

other Party except that bidder may, upon completion, use the Project as a reference for credential

purpose. Except as required by law or the rules and regulations of each stock exchange upon

which the securities of one of the Parties is listed, neither Party shall publish or permit to be

published either along or in conjunction with any other person any press release, information,

article, photograph, illustration or any other material of whatever kind relating to this Agreement,

the SLA or the business of the Parties without prior reference to and approval in writing from the

other Party, such approval not to be unreasonably withheld or delayed provided however that

bidder may include ITG or its client lists for reference to third parties subject to the prior written

consent of ITG not to be unreasonably withheld or delayed. Such approval shall apply to each



specific case and relate only to that case.

24.6 Notices

(a) Any notice or other document which may be given by either Party under this

Agreement or under the SLA shall be given in writing in person or by pre-paid

recorded delivery post, email or by facsimile transmission.

(b) In relation to a notice given under this Agreement, any such notice or other

document shall be addressed to the other Party‟s principal or registered office

address as set out below:

<Insert Address>

Tel:

Fax:

Email:

Contact:

With a copy to:

Bidder

Tel:

Fax:

Email:

Contact:

[In relation to a notice given under the MSA / SLA, a Party shall specify the Parties‟ address for

service of notices, any such notice to be copied to the Parties at the addresses set out in this Clause]

(d) Any such notice or other document shall be deemed to have been given to the other Party

(or, if relevant, its relevant associated company) when delivered (if delivered in person) if

delivered between the hours of 9.00 am and 5.00 pm at the address of the other Party set forth

above or if sent by fax, provided the copy fax is accompanied by a confirmation of transmission, or

on the next working day thereafter if delivered outside such hours, and 7 days from the date of

posting (if by letter).

(e) Either Party to this Agreement or to the SLA may change its address, telephone number,

facsimile number and nominated contact for notification purposes by giving the other reasonable

prior written notice of the new information and its effective date.

24.7 Variations and Further Assurance

(a) No amendment, variation or other change to this Agreement or the SLA shall be valid

unless authorised in accordance with the change control procedure as set out in the Change

Control Schedule set out in Schedule II of this Agreement. Such amendment shall be made in

writing and signed by the duly authorised representatives of the Parties to this Agreement or the

SLA.



(b) Each Party to this Agreement or the SLA agrees to enter into or execute, without limitation,

whatever other agreement, document, consent and waiver and to do all other things which shall or

may be reasonably required to complete and deliver the obligations set out in this Agreement or

the SLA.

24.8 Severability and Waiver

(a) If any provision of this Agreement or the SLA, or any part thereof, shall be found by any

court or administrative body of competent jurisdiction to be illegal, invalid or unenforceable the

illegality, invalidity or unenforceability of such provision or part provision shall not affect the

other provisions of this Agreement or the SLA or the remainder of the provisions in question

which shall remain in full force and effect. The relevant Parties shall negotiate in good faith in

order to agree to substitute for any illegal, invalid or unenforceable provision a valid and

enforceable provision which achieves to the greatest extent possible the economic, legal and

commercial objectives of the illegal, invalid or unenforceable provision or part provision.

(b) No failure to exercise or enforce and no delay in exercising or enforcing on the part of

either Party to this Agreement or the SLA of any right, remedy or provision of this Agreement or

the SLA shall operate as a waiver of such right, remedy or provision in any future application nor

shall any single or partial exercise or enforcement of any right, remedy or provision preclude any

other or further exercise or enforcement of such right, remedy or provision or the exercise or

enforcement of any other right, remedy or provision.

24.9 Compliance with Applicable Law

Each Party to this Agreement accepts that its individual conduct shall (to the extent applicable to

its business like the Implementtaion Agency as an information technology service provider) at all

times comply with all laws, rules and regulations of government and other bodies having

jurisdiction over the area in which the Services are undertaken provided that changes in such laws,

rules and regulations which result in a change to the Services shall be dealt with in accordance

with the Change Control Schedule set out in Schedule II of this Agreement.

24.10 Professional Fees

All expenses incurred by or on behalf of each Party to this Agreement and the SLA, including all

fees of agents, legal advisors, accountants and actuaries employed by either of the Parties in

connection with the negotiation, preparation and execution of this Agreement or the SLA shall be

borne solely by the Party which incurred them.

24.11 Ethics

The bidder represents, warrants and covenants that it has given no commitments, payments, gifts,

kickbacks, lavish or expensive entertainment, or other things of value to any employee or agent of

ITG or its nominated agencies in connection with this agreement and acknowledges that the giving

of any such payment, gifts, entertainment, or other things of value is strictly in violation of ITG

standard policies and may result in cancellation of this Agreement, or the SLA.

24.12 Entire Agreement



This Agreement and the SLA with all schedules & annexures appended thereto and the contents

and specifications of the RFP constitute the entire agreement between the Parties with respect to

their subject matter, and as to all other representations, understandings or agreements which are

not fully expressed herein, provided that nothing in this Clause shall be interpreted so as to

exclude any liability in respect of fraudulent misrepresentation.]

24.13 Amendment

Any amendment to this Agreement shall be made in accordance with the Change Control

Schedule set out in Schedule II of this Agreement by mutual written consent of all the Parties.

25 Governing Law and Dispute Resolution

25.1 This Agreement shall be governed by and construed in accordance with the laws of India,

without giving effect to conflict of law rules. The parties expressly agree to exclude the

application of the U.N. Convention on Contracts for the International Sale of Goods (1980)

to this Agreement and the performance of the parties contemplated under this Agreement,

to the extent that such convention might otherwise be applicable.

25.2 Any dispute arising out of or in connection with this Agreement or the SLA shall in the first

instance be dealt with in accordance with the escalation procedure as set out in the

Governance Schedule set out as Schedule V of this Agreement.

25.3 In case the escalations do not help in resolution of the problem within 3 weeks of

escalation, both the parties should agree on a mediator for communication between the two

parties. The process of the mediation would be as follows:

Aggrieved party should refer the dispute to the identified mediator in writing, with a copy

to the other party. Such a reference should contain a description of the nature of the

dispute, the quantum in dispute (if any) and the relief or remedy sought suitable.

The mediator shall use his best endeavours to conclude the mediation within a certain

number of days of his appointment.

If no resolution can be reached through mutual discussion or mediation within 30 days

then the matter should be referred to Experts for advising on the issue.

25.4 In case the mediation does not help in resolution and it requires expertise to understand an

issue, a neutral panel of 3 experts, agreeable to both parties should be consitituted. The

process of the expert advisory would be as follows:

Aggrieved party should write to the other party on the failure of previous alternate dispute

resolution processes within the timeframe and requesting for expert advisory. This is to be

sent with a copy to the mediator.

Both parties should thereafter agree on the panel of experts who are well conversant with

the issue under dispute

The expert panel shall use his best endeavours to provide a neutral position on the issue.

If no resolution can be reached through the above means within 30 days then the matter

should be referred to Arbitration.



25.5 Any dispute or difference whatsoever arising between the parties to this Contract out of or

relating to the construction, meaning, scope, operation or effect of this Contract or the

validity of the breach thereof shall be referred to a sole Arbitrator to be appointed by

mutual consent of both the parties herein. If the parties cannot agree on the appointment of

the Arbitrator within a period of one month from the notification by one party to the other

of existence of such dispute, then the Arbitrator shall be appointed by the High Court

Bombay at Goa/Panji Goa , India. The provisions of the Arbitration and Conciliation Act,

1996 will be applicable and the award made there under shall be final and binding upon

the parties hereto, subject to legal remedies available under the law. Such differences shall

be deemed to be a submission to arbitration under the Indian Arbitration and Conciliation

Act, 1996, or of any modifications, Rules or re-enactments thereof. The Arbitration

proceedings will be held at Goa, India. Any legal dispute will come under the sole

jurisdicition of Panaji-Goa, India.

25.6 Compliance with laws: Each party will comply with all applicable export and import laws

and regulations.

25.7 Risk of Loss: For each hardware item, bidder bears the risk of loss or damage up to the time

it is delivered to the Implementation/ITG-designated carrier for shipment to ITG or ITG‟s

designated location.

25.8 Third party components: bidder will provide all third party components solely on a pass-

through basis in accordance with the relevant third party terms and conditions.

IN WITNESS WHEREOF the Parties have by duly authorized

Representatives set their respective hands and seal on the date first above

Written in the presence of:

WITNESSES:

Signed by:

(Name and designation) For and on behalf of ITG

(FIRST PARTY)

Signed by:

(Name and designation)

Bidder

(SECOND PARTY)

(Name and designation) For and on behalf of Bidder

Signed by:



26 Schedules

SCHEDULE – I – DEFINITIONS

Adverse Effect means material adverse effect on

(a) the ability of the bidder to exercise any of its rights or perform/discharge

any of its duties/obligations under and in accordance with the provisions

of this Agreement and/or

(b) the legal validity, binding nature or enforceability of this Agreement;

Agreement means this Master Services Agreement, Service Level Agreement and Non-

Disclosure Agreement together with all Articles, Annexures, Schedules and

the contents and specifications of the RFP;

Applicable Law(s) means any statute, law, ordinance, notification, rule, regulation, judgment,

order, decree, bye-law, approval, directive, guideline, policy, requirement

or other governmental restriction or any similar form of decision applicable

to the relevant party and as may be in effect on the date of the execution of

this Agreement and during the subsistence thereof, applicable to the

Project;

Assets shall have the same meaning ascribed to it in Clause 10.1 (a)

Software means the software designed, developed / customized, tested and

deployed by the bidder for the purposes of the Project and includes the

source code (in case of Bespoke development) along with associated

documentation, which is the work product of the development efforts

involved in the Project and the improvements and enhancements effected

during the term of the Project, but does not include the third party software

products (including the COTS products used for thr product), proprietary

software components and tools deployed by the bidder

Business Hours shall mean the working time for ITG users which is 9:30 AM to 6:30 PM.

Again for Web Server and other components which enable successful usage

of web portals of ITG the working time should be considered as 24 hours

for all the days of the week. It is desired that IT maintenance, other batch

processes (like backup) etc. should be planned so that such backend

activities have minimum effect on the performance;

Certificate(s) of

Compliance

shall have the same meaning ascribed to it in Clause 5.4.;

Confidential

Information

means all information including ITG Data (whether in written, oral,

electronic or other format) which relates to the technical, financial and

business affairs, dealers, suppliers, products, developments, operations,

processes, data, trade secrets, design rights, know-how, plans, budgets and

personnel of each Party and its affiliates which is disclosed to or otherwise



learned by the other Party in the course of or in connection with this

Agreement (including without limitation such information received during

negotiations, location visits and meetings in connection with this

Agreement);

Control means, in relation to any business entity, the power of a person to secure (i)

by means of the holding of shares or the possession of voting power in or

in relation to that or any other business entity, or

(ii) by virtue of any powers conferred by the articles of association or other

document regulating that or any other business entity, that the affairs of the

first mentioned business entity are conducted in accordance with that

person‟s wishes and in relation to a partnership, means the right to a share

of more than one half of the assets, or of more than one half of the income,

of the partnership;

Deliverables means the products, infrastructure and services agreed to be delivered by

the bidder in pursuance of the agreement as defined more elaborately in the

RFP, Implementation and the Maintenance phases and includes all

documents related to the user manual, technical manual, design, process

and operating manuals, service mechanisms, policies and guidelines (such

as security related, data migration related), inter alia payment and/or

process related etc., source code and all its modifications;

Proprietary

Information

shall have the same meaning ascribed to it in Clause 19.1

Effective Date shall have the same meaning ascribed to it in Clause 3.2;

ITG Data means all proprietary data of the department or its nominated agencies

generated out of operations and transactions, documents all taxpayers data

and related information including but not restricted to user data which the

bidder obtains, possesses or processes in the context of providing the

Services to the users pursuant to this Agreement;

Final Acceptance

Test

shall be conducted on completion of the following:

1) ITG Data Center operational,

2) Deployment & operational hardware and networking at requisite

locations,

3) UAT of the overall integrated solution and portal.

Final Testing and

Certification

Agency

shall have the same meaning ascribed to it in Clause 5.4;

Force Majeure shall have the same meaning ascribed to it in Clause 16.1;

Force Majeure Costs shall have the same meaning ascribed to it in Clause 16.4 (b);

GoI means the Government of India;

Indemnifying Party shall have the same meaning ascribed to it in Clause 15.1;



Indemnified Party shall have the same meaning ascribed to it in Clause 15.1;

Intellectual

Property Rights

means all rights in written designs and copyrights, moral rights, rights in

databases and Bespoke Software / Pre-existing work including its up-

gradation systems and compilation rights (whether or not any of these are

registered and including application for registration);

Escrow Agreement - An agreement that pursuant to Clause 22 provides for the

regular deposit into escrow of all source code, object code, and

documentation with respect to all public material and Service

Provider‟s proprietary material (and cumulative updates

thereof), together with (a) continually updated instructions as to

the compilation,installation, configuration, deployment and use

of the Source Code, and (b) a list of all non-deposited third party

software used in conjunction with the Source Code to provide

the full functionality of the deposited materials.

Insurance Cover - Public liability insurance for an insured amount of [INR insert

amount] per occurrence and not less than [INR insert amount] in

aggregate

- Either professional indemnity or errors and omissions insurance for

an insured amount of [INR insert amount] per occurrence and not

less than [INR insert amount] in aggregate.

- Product liability for an insured amount of [INR insert amount] per

occurrence and not less than [INR insert amount] in aggregate.

- Workers compensation as required by law

Material Breach means a breach by either Party (ITG or Bidder ) of any of its obligations

under this Agreement which has or is likely to have an Adverse Effect on

the Project which such Party shall have failed to cure;

Required

Deliverables

shall have the same meaning ascribed to it in Annexure C of this

Agreement;

Parties means ITG and bidder for the purposes of this Agreement and “Party” shall

be interpreted accordingly;

Performance

Guarantee

Means the guarantee provided by a Nationalized Bank in favour of the

bidder The amount of Performance Security shall be 10% of the overall cost

of the project. This performance security shall be valid till six months after

the completion of the project i.e. ---- years from the date of signing of

contract or for such time as is required under this Agreement;

Planned

Application

Downtime

means the unavailability of the application services due to maintenance

activities such as configuration changes, upgradation or changes to any

supporting infrastructure wherein prior intimation (at least two working



days in advance) of such planned outage shall be given and approval

sought from ITG as applicable;

Planned network

outage

means the unavailability of the network services due to infrastructure

maintenance activities such as configuration changes, upgradation or

changes to any supporting infrastructure. Prior intimation of such planned

outage shall be given and approval sought from ITG as applicable and shall

be notified at least two working days;

Project means Pilot, Project Implementation (roll out) and Maintenance in terms of

the Agreement;

Project

Implementation

means Project Implementation as per the testing standards and acceptance

criteria prescribed by ITG or its nominated agencies;

Project

Implementation

Phase

shall be from the Effective Date of the Agreement to the date of final

acceptance testing & certification as set out in Clause 5.4 of this Agreement;

Project

Implementation

Unit (PIU)

shall be constituted by ITG to monitor the activities, deliverables and

progress of the Project. PIU will comprise of the staff members of ITG,

other officials from concerned department and external experts (as defined

in the RFP);

Project Timelines shall have the same meaning ascribed to in Annexure C;

Providing Party shall have the same meaning ascribed to it in Clause 12.5;

Receiving Party shall have the same meaning ascribed to it in Clause 12.5;

Replacement bidder means any third party that ITG or its nominated agencies appoint to

replace bidder upon expiry of the Term or termination of this Agreement to

undertake the Services or part thereof;

Required Consents means the consents, waivers, clearances and licenses to use ITG's

Intellectual Property Rights, rights and other authorizations as may be

required to be obtained for the software and other items that ITG or their

nominated agencies are required to make available to bidder pursuant to

this Agreement;

Services means the services delivered to the Stakeholders of ITG or its nominated

agencies, employees of ITG or its nominated agencies, and to professionals,

using the tangible and intangible assets created, procured, installed,

managed and operated by the bidder including the tools of information and

communications technology and includes but is not limited to the list of

services specified in Annexure B;

Service Level means the level of service and other performance criteria which will apply

to the Services delivered by the bidder

SLA means the Performance and Maintenance SLA executed as part of this

Master Service Agreement;



Stakeholders means the students, Franchisee‟s, Investors, Citizens, ITG or its nominated

agencies, ITG, employees and the Departments of State Government;

Term shall have the same meaning ascribed to it in Clause 3.1;

Third Party Systems means systems (or any part thereof) in which the Intellectual Property

Rights are not owned by ITG or bidder and to which bidder has been granted

a license to use and which are used in the provision of Services;

Unplanned

Application

Downtime

means the total time for all the instances where services in the software

requirement specification document prepared by the bidder are not

available for more than 5 consecutive minutes;

Network in ITG users refers to all the IT assets installed by the bidder as part of the

Project for networking;

Unplanned network

outage

means the total time for all the instances where services in the software

requirement specification document prepared by the bidder are not

available for more than 5 consecutive minutes;

Application means the software application developed as a part of scope of work set

out in Clause 2.1(a)

Application

Downtime

means the time for which user/s is not able to access the application.

However, in calculating downtime, scheduled downtime (for example,

backup time, batch processing time, routine maintenance time) would not

be considered;

Network Uptime Uptime refers to network availability between ITG‟s Head Quarters to Data

center. “%Uptime” means ratio of „up time‟ (in minutes) in a month to

Total time in the month (in minutes) multiplied by 100;

Warranty 3 years for software from date of Go live and 5 years for hardware from

date of installation



SCHEDULE – II – Change Control Schedule

This Schedule describes the procedure to be followed in the event of any proposed change to the

Master Service Agreement (“MSA”), Project Implementation Phase, SLA and Scope of Work and

Functional Requirement Specifications. Such change shall include, but shall not be limited to,

changes in the scope of services provided by the bidder and changes to the terms of payment as

stated in the Terms of Payment Schedule.

ITG and SI recognize that frequent change is an inevitable part of delivering services and that a

significant element of this change can be accomplished by re-organizing processes and

responsibilities without a material effect on the cost. The SI will endeavour, wherever reasonably

practicable, to effect change without an increase in the terms of payment as stated in the Terms of

Payment Schedule and ITG or its nominated agencies will work with the bidder to ensure that all

changes are discussed and managed in a constructive manner. This Change Control Schedule sets

out the provisions which will apply to all the changes to this agreement and other documents

except for the changes in SLAs for which a separate process has been laid out in Clause 11 of the

SLA.

This Change Control Schedule sets out the provisions which will apply to changes to the MSA.

CHANGE MANAGEMENT PROCESS

a. CHANGE CONTROL NOTE ("CCN")

i. Change requests in respect of the MSA, the Project Implementation, the operation, the

SLA or Scope of work and Functional Requirement specifications will emanate from the

Parties' respective Project Manager who will be responsible for obtaining approval for

the change and who will act as its sponsor throughout the Change Control Process and

will complete Part A of the CCN attached as Annexure A hereto. CCNs will be

presented to the other Party's Project Manager who will acknowledge receipt by

signature of the CCN.

ii. The SI and ITG or its nominated agencies, during the Project Implementation Phase and

ITG or its nominated agencies during the Operations and Management Phase and

while preparing the CCN, shall consider the change in the context of the following

parameter, namely whether the change is beyond the scope of Services including

ancillary and concomitant services required and as detailed in the RFP and is

suggested and applicable only after the testing, commissioning and certification of the

Pilot Phase and the Project Implementation Phase as set out in this Agreement.

iii. It is hereby also clarified here that any change of control suggested beyond 25 % of the

value of this Project will be beyond the scope of the change control process and will be

considered as the subject matter for a separate bid process and a separate contract. It is

hereby clarified that the 25% of the value of the Project as stated in herein above is



calculated on the basis of bid value submitted by the bidder and accepted by ITG or its

nominated agencies or as decided and approved by ITG or it Nominated Agencies. For

arriving at the cost / rate for change upto 25% of the project value, the payment terms

and relevant rates as specified in Annexure D shall apply.

b. Quotation

i. The SI shall assess the CCN and complete Part B of the CCN, in completing the Part B

of the CCN the SI shall provide as a minimum:

1. a description of the change

2. a list of deliverables required for implementing the change;

3. a time table for implementation;

4. an estimate of any proposed change

5. any relevant acceptance criteria

6. an assessment of the value of the proposed change;

6. material evidence to prove that the proposed change is not already covered

within the Agreement and the scope of work

ii. Prior to submission of the completed CCN to ITG, or its nominated agencies, the

Service Provider will undertake its own internal review of the proposal and obtain all

necessary internal approvals. As a part of this internal review process, the SI shall

consider the materiality of the proposed change in the context of the MSA and the

Project Implementation affected by the change and the total effect that may arise from

implementation of the change.

c. Costs

Each Party shall be responsible for its own costs incurred in the quotation, preparation of

CCNs and in the completion of its obligations described in this process provided the SI

meets the obligations as set in the CCN. In the event the SI is unable to meet the obligations

as defined in the CCN then the cost of getting it done by third party will be borne by the SI.

d. Obligations

The SI shall be obliged to implement any proposed changes once approval in accordance

with above provisions has been given, with effect from the date agreed for implementation

and within an agreed timeframe. SI will not be obligated to work on a change until the

parties agree in writing upon its scope, price and/or schedule impact.

SCHEDULE – III - EXIT MANAGEMENT SCHEDULE

1 PURPOSE

1.1 This Schedule sets out the provisions, which will apply on expiry or termination of the

MSA, the Project Implementation, Operation and Management SLA.

1.2 In the case of termination of the Project Implementation and/or Operation and

Management, the Parties shall agree at that time whether, and if so during what period, the

provisions of this Schedule shall apply.

1.3 The Parties shall ensure that their respective associated entities carry out their respective



obligations set out in this Exit Management Schedule.

2 TRANSFER OF ASSETS

2.1 ITG shall be entitled to serve notice in writing on the SI at any time during the exit

management period as detailed hereinabove requiring the SI and/or its sub contractors to

provide ITG with a complete and up to date list of the Assets within 30 days of such notice.

ITG shall then be entitled to serve notice in writing on the SI at any time prior to the date

that is 30 days prior to the end of the exit management period requiring the SI to sell the

Assets, if any, to be transferred to ITG or its nominated agencies at book value as

determined as of the date of such notice in accordance with the provisions of relevant laws.

2.2 In case of contract being terminated by ITG, ITG reserves the right to ask SI to continue

running the project operations for a period of 6 months after termination orders are issued.

2.3 Upon service of a notice under this Article the following provisions shall apply:

(i) in the event, if the Assets to be transferred are mortgaged to any financial

institutions by the SI, the SI shall ensure that all such liens and liabilities have been

cleared beyond doubt, prior to such transfer. All documents regarding the discharge

of such lien and liabilities shall be furnished to ITG.

(ii) All risk in and title to the Assets to be transferred / to be purchased by ITG

pursuant to this Article shall be transferred to ITG, on the last day of the exit

management period.

(iii) ITG shall pay to the SI on the last day of the exit management period such sum

representing the Net Block (procurement price less depreciation as per provisions of

Companies Act) of the Assets to be transferred as stated in the Terms of Payment

Schedule.

(iv) Payment to the outgoing SI shall be made to the tune of last set of completed

services / deliverables, subject to SLA requirements.

(v) The outgoing SI will pass on to ITG and/or to the Replacement SI, the subsisting

rights in any leased properties/ licensed products on terms not less favorable to

ITG/Replacement SI, than that enjoyed by the outgoing SI.

3 COOPERATION AND PROVISION OF INFORMATION

3.1 During the exit management period:

(i) The bidder will allow ITG or its nominated agency access to information reasonably

required to define the then current mode of operation associated with the provision

of the services to enable ITG to assess the existing services being delivered;

(ii) promptly on reasonable request by ITG, the SI shall provide access to and copies of

all information held or controlled by them which they have prepared or maintained

in accordance with this agreement relating to any material aspect of the services

(whether provided by the bidder or sub contractors appointed by the Bidder ). ITG

shall be entitled to copy of all such information. Such information shall include



details pertaining to the services rendered and other performance data. The bidder

shall permit ITG or its nominated agencies to have reasonable access to its

employees and facilities as reasonably required by the Chairman, PIU to

understand the methods of delivery of the services employed by the bidder and to

assist appropriate knowledge transfer.

4 CONFIDENTIAL INFORMATION, SECURITY AND DATA

4.1 The bidder will promptly on the commencement of the exit management period supply to

ITG or its nominated agency the following:

(i) information relating to the current services rendered and customer and performance

data relating to the performance of sub contractors in relation to the services;

(ii) documentation relating to Computerization Project‟s Intellectual Property Rights;

(iii) documentation relating to sub-contractors;

(iv) all current and updated data as is reasonably required for purposes of ITG or its

nominated agencies transitioning the services to its Replacement bidder in a readily

available format nominated by ITG, its nominated agency;

(v) all other information (including but not limited to documents, records and

agreements) relating to the services reasonably necessary to enable ITG or its

nominated agencies, or its Replacement bidder to carry out due diligence in order to

transition the provision of the Services to ITG or its nominated agencies, or its

Replacement bidder (as the case may be).

4.2 Before the expiry of the exit management period, the bidder shall deliver to ITG or its

nominated agency all new or up-dated materials from the categories set out in Schedule

above and shall not retain any copies thereof, except that the bidder shall be permitted to

retain one copy of such materials for archival purposes only.

4.3 Before the expiry of the exit management period, unless otherwise provided under the

MSA, ITG or its nominated agency shall deliver to the bidder all forms of bidder confidential

information, which is in the possession or control of Chairperson, PIU or its users.

5 EMPLOYEES

5.1 Promptly on reasonable request at any time during the exit management period, the bidder

shall, subject to applicable laws, restraints and regulations (including in particular those

relating to privacy) provide to ITG or its nominated agency a list of all employees (with job

titles) of the bidder dedicated to providing the services at the commencement of the exit

management period.

5.2 Where any national, regional law or regulation relating to the mandatory or automatic

transfer of the contracts of employment from the bidder to ITG or its nominated agency, or a

Replacement bidder ("Transfer Regulation") applies to any or all of the employees of the

bidder , then the Parties shall comply with their respective obligations under such Transfer



Regulations.

5.3 To the extent that any Transfer Regulation does not apply to any employee of the bidder ,

department, or its Replacement bidder may make an offer of employment or contract for

services to such employee of the bidder and the bidder shall not enforce or impose any

contractual provision that would prevent any such employee from being hired by the

Chairperson, PIU or any Replacement bidder

6 TRANSFER OF CERTAIN AGREEMENTS

On request by ITG or its nominated agency the bidder shall effect such assignments, transfers,

licences and sub-licences as the Chairperson, PIU may require in favour of the Chairperson, PIU,

or its Replacement bidder in relation to any equipment lease, maintenance or service provision

agreement between bidder and third party lessors, vendors, and which are related to the services

and reasonably necessary for the carrying out of replacement services by ITG or its nominated

agency or its Replacement bidder

7 RIGHTS OF ACCESS TO PREMISES

7.1 At any time during the exit management period, where Assets are located at the Bidder 's

premises, the bidder will be obliged to give reasonable rights of access to (or, in the case of

Assets located on a third party's premises, procure reasonable rights of access to) ITG or its

nominated agency and/or any Replacement bidder in order to make an inventory of the

Assets.

7.2 The bidder shall also give ITG or its nominated agency or its nominated agencies, or any

Replacement bidder right of reasonable access to the Implementation Partner's premises

and shall procure ITG or its nominated agency or its nominated agencies and any

Replacement bidder rights of access to relevant third party premises during the exit

management period and for such period of time following termination or expiry of the

MSA as is reasonably necessary to migrate the services to ITG or its nominated agency, or a

Replacement bidder

8 GENERAL OBLIGATIONS OF THE Bidder

8.1 The bidder shall provide all such information as may reasonably be necessary to effect as

seamless a handover as practicable in the circumstances to ITG or its nominated agency or

its Replacement bidder and which the bidder has in its possession or control at any time

during the exit management period.

8.2 For the purposes of this Schedule, anything in the possession or control of any bidder ,

associated entity, or sub contractor is deemed to be in the possession or control of the bidder

8.3 The bidder shall commit adequate resources to comply with its obligations under this Exit

Management Schedule.

9 EXIT MANAGEMENT PLAN



9.1 The bidder shall provide ITG or its nominated agency with a recommended exit

management plan ("Exit Management Plan") which shall deal with at least the following

aspects of exit management in relation to the MSA as a whole and in relation to the Project

Implementation, and the Operation and Management SLA.

(i) A detailed program of the transfer process that could be used in conjunction with a

Replacement bidder including details of the means to be used to ensure continuing

provision of the services throughout the transfer process or until the cessation of the

services and of the management structure to be used during the transfer;

(ii) plans for the communication with such of the Bidder 's sub contractors, staff,

suppliers, customers and any related third party as are necessary to avoid any

material detrimental impact on ITG‟s operations as a result of undertaking the

transfer;

(iii) (if applicable) proposed arrangements for the segregation of the Bidder 's networks

from the networks employed by ITG and identification of specific security tasks

necessary at termination;

(iv) Plans for provision of contingent support to ITG, and Replacement bidder for a

reasonable period after transfer.

9.2 The bidder shall re-draft the Exit Management Plan annually thereafter to ensure that it is

kept relevant and up to date.

9.3 Each Exit Management Plan shall be presented by the bidder to and approved by ITG or its

nominated agencies.

9.4 The terms of payment as stated in the Terms of Payment Schedule include the costs of the

bidder complying with its obligations under this Schedule.

9.5 In the event of termination or expiry of MSA, and Project Implementation, each Party shall

comply with the Exit Management Plan.

9.6 During the exit management period, the bidder shall use its best efforts to deliver the

services.

9.7 Payments during the Exit Management period shall be made in accordance with the Terms

of Payment Schedule.

9.8 This Exit Management plan shall be furnished in writing to ITG or its nominated agencies

within 90 days from the Effective Date of this Agreement.



SCHEDULE – IV - AUDIT, ACCESS AND REPORTING

1 PURPOSE

This Schedule details the audit, access and reporting rights and obligations of ITG or its nominated

agency and the Bidder

.

2 AUDIT NOTICE AND TIMING

2.1 As soon as reasonably practicable after the Effective Date, the Parties shall use their best

endeavours to agree to a timetable for routine audits during the Project Implementation

Phase and the Operation and Management Phase. Such timetable during the

Implementation Phase, ITG or its nominated agency and thereafter during the operation

Phase, ITG or its nominated agency shall conduct routine audits in accordance with such

agreed timetable and shall not be required to give the bidder any further notice of carrying

out such audits.

2.2 ITG or its nominated agency may conduct non-timetabled audits at his/ her own discretion

if it reasonably believes that such non-timetabled audits are necessary as a result of an act of

fraud by the bidder , a security violation, or breach of confidentiality obligations by the

bidder , provided that the requirement for such an audit is notified in writing to the bidder a

reasonable period time prior to the audit (taking into account the circumstances giving rise

to the reasonable belief) stating in a reasonable level of detail the reasons for the

requirement and the alleged facts on which the requirement is based. If the bidder considers

that the non-timetabled audit was not appropriate, the matter shall be referred to the

escalation procedure as set out in the Governance Schedule.

2.3 The frequency of audits shall be a (maximum) half yearly, provided always that ITG or its

nominated agency shall endeavour to conduct such audits with the lowest levels of

inconvenience and disturbance practicable being caused to the bidder Any such audit shall

be conducted by with adequate notice of 2 weeks to the bidder

2.4 ITG will ensure that any 3rd party agencies (except CAG) appointed to conduct the audit

will not be the competitor of bidder and will be bound by confidentiality obligations.

3 ACCESS

The bidder shall provide to ITG or its nominated agency reasonable access to employees,

subcontractors, suppliers, agents and third party facilities as detailed in the RFP, documents,

records and systems reasonably required for audit and shall provide all such persons with routine

assistance in connection with the audits and inspections. The Chairperson, PIU / Steering

Committee shall have the right to copy and retain copies of any relevant records. The bidder shall

make every reasonable effort to co-operate with them.

4 AUDIT RIGHTS

4.1 ITG or its nominated agency shall have the right to audit and inspect suppliers, agents and

third party facilities (as detailed in the RFP), data centres, documents, records, procedures



and systems relating to the provision of the services, but only to the extent that they relate

to the provision of the services, as shall be reasonably necessary to verify:

(i) The security, integrity and availability of all data processed, held or conveyed by

the Partner on behalf of ITG and documentation related thereto;

(ii) That the actual level of performance of the services is the same as specified in the

SLA;

(iii) That the bidder has complied with the relevant technical standards, and has

adequate internal controls in place; and

(iv) The compliance of the bidder with any other obligation under the MSA and SLA.

(v) Security audit and implementation audit of the system shall be done once each year,

the cost of which shall be borne by the bidder

(vi) For the avoidance of doubt the audit rights under this Schedule shall not include

access to the Bidder 's profit margins or overheads, any confidential information

relating to the Bidder ‟ employees, or (iii) minutes of its internal Board or Board

committee meetings including internal audit, or (iv) such other information of

commercial-in-confidence nature which are not relevant to the Services associated

with any obligation under the MSA.

5 AUDIT RIGHTS OF SUB-CONTRACTORS, SUPPLIERS AND AGENTS

5.1 The bidder shall use reasonable endeavours to achieve the same audit and access provisions

as defined in this Schedule with sub-contractors, suppliers and agents who supply labour,

services, equipment or materials in respect of the services. The bidder shall inform ITG or its

nominated agency prior to concluding any sub-contract or supply agreement of any failure

to achieve the same rights of audit or access.

5.2 REPORTING: The bidder will provide quarterly reports to the Chairperson, PIU / Steering

committee regarding any specific aspects of the Project and in context of the audit and

access information as required by ITG or its nominated agency.

6 ACTION AND REVIEW

6.1 Any change or amendment to the systems and procedures of the bidder , or sub-contractors,

where applicable arising from the audit report shall be agreed within thirty (30) calendar

days from the submission of the said report.

6.2 Any discrepancies identified by any audit pursuant to this Schedule shall be immediately

notified to ITG or its nominated agency and the bidder Project Manager who shall

determine what action should be taken in respect of such discrepancies in accordance with

the terms of the MSA.

7 TERMS OF PAYMENT

ITG shall bear the cost of any audits and inspections. The terms of payment are exclusive of any

costs of the bidder and the sub-contractor, for all reasonable assistance and information provided



under the MSA, the Project Implementation, Operation and Management SLA by the bidder

pursuant to this Schedule.

8 RECORDS AND INFORMATION

For the purposes of audit in accordance with this Schedule, the bidder shall maintain true and

accurate records in connection with the provision of the services and the bidder shall handover all

the relevant records and documents upon the termination or expiry of the MSA.



SCHEDULE – V - GOVERNANCE SCHEDULE

1 PURPOSE

The purpose of this Schedule is to:

(i) establish and maintain the formal and informal processes for managing the

relationship between ITG and the bidder (including the outputs from other

Schedules to this Agreement;

(ii) define the principles that both Parties wish to follow to ensure the delivery of the

Services;

(iii) ensure the continued alignment of the interests of the Parties;

(iv) ensure that the relationship is maintained at the correct level within each Party;

(v) create the flexibility to revise and maintain the relationship and this Agreement

during the Term;

(vi) set out the procedure for escalating disagreements; and

(vii) enable contract administration and performance management.

2 GOVERNANCE STRUCTURE

1. Project Managers: The relationship under this Agreement will be managed by the

Project Managers appointed by each Party, who will provide the interface between

the executive management of the respective Parties.

2. Project Implementation Unit (PIU): Within 7 days following the Effective Date, ITG

or its nominated agencies and the bidder shall each appoint a Project Manager. In the

event that either Party wishes to substitute its Project Manager it will do so in

manner in which the original appointment is made and notify the other Party of

such substitution as soon as reasonably practicable but at the latest within 7 days of

the substitution.

3. The Project Managers shall have responsibility for maintaining the interface and

communication between the Parties.

4. The PIU will meet formally on a fortnightly / monthly / quarterly, as required,

basis at a time and location to be agreed between them. These meetings will cover, as

a minimum, the following agenda items: (i) consideration of Quarterly Performance

Reports; (ii) consideration of matters arising out of the Change Control Schedule;

(iii) issues escalated in accordance with the escalation procedure as set out in the

Governance Schedule; (iv) matters to be brought before the PIU in accordance with

the MSA and the Schedules; (v) any matter brought before the PIU by the bidder

under this Article; and (vi) any other issue which either Party wishes to add to the

agenda.

5. In the event that there is any material factor which affects the delivery of the

Services or the terms of payment as stated in the Terms of Payment Schedule, the

Parties agree to discuss in the PIU any appropriate amendment to the Agreement or



any Service Level Agreements or Statement of Works including any variation to the

terms of payment as stated in the Terms of Payment Schedule. Any variation so

agreed shall be implemented through the change control procedure as set out in the

Change Control Schedule.



3 GOVERNANCE PROCEDURES

3.1 The bidder shall document the agreed structures in a procedures manual.

3.2 The agenda for each meeting of the PIU shall be set to reflect the discussion items referred

to above and extraordinary items may be added either with the agreement of the Parties or

at the request of either Party. Copies of the agenda for meetings of the PIU, along with

relevant pre-reading material, shall be distributed at least one week in advance of the

relevant meeting.

3.3 All meetings and proceedings will be documented such documents to be distributed to the

Parties and copies shall be kept as a record. All actions, responsibilities and accountabilities

arising out of any meeting shall be tracked and managed.

3.4 The Parties shall ensure as far as reasonably practicable that the PIU shall resolve the issues

and resolve the objectives placed before them and that members representing that Party are

empowered to make relevant decisions or have easy access to empowered individuals for

decisions to be made to achieve this.

3.5 In order to formally submit a Disputed Matter to the aforesaid for a, one Party ("Claimant")

shall give a written notice ("Dispute Notice") to the other Party. The Dispute Notice shall be

accompanied by (a) a statement by the Claimant describing the Disputed Matter in

reasonable detail and (b) documentation, if any, supporting the Claimant's position on the

Disputed Matter.

3.6 The other Party ("Respondent") shall have the right to respond to the Dispute Notice within

7 days after receipt of the Dispute Notice. In the event that the parties are unable to resolve

the Disputed Matter within a further period of 7 days, it shall refer the Disputed Matter to

next level of the dispute resolution for action as per the process mentioned in article 9.1

3.7 All negotiations, statements and / or documentation pursuant to these Articles shall be

without prejudice and confidential (unless mutually agreed otherwise).

3.8 If the Disputed Matter is having a material effect on the operation of the Services (or any of

them or part of them) the Parties will use all their respective reasonable endeavours to

reduce the elapsed time in reaching a resolution of the Disputed Matter.



SCHEDULE – VI - TERMS OF PAYMENT SCHEDULE

The following schedule would be followed for payment during the Project implementation:

S. No.

Payment Milestone % of Total Fee

Basis of Approval

1. Deployment of necessary hardware at SDC establishment and submission of assessment report.

5 Approval of the DeGS and ITG/DoIT. The payment will be disbursed on the basis of district - wise readiness.

2. Successful District Readiness for all offices, i.e. Completion of all activities/commissioning of all hardware & networking equipment‟s in a district; i.e. Hardware Network Training (w.r.t. 26 Services) Data Digitization (w.r.t 26

Services) Placement of Technical Support in

the district

15

3. “Go-Live” of first set of 10 Services in State of Goa

15 Definition of “Go-Live” is appended below, Copy of STQC certification

4. “Go-Live” of remaining set of 16 Services in State of Goa

15 Definition of “Go-Live” is appended below, Copy of STQC certification

5. Operations and Maintenance Phase (3 years for software from date of Go live and 5 years for hardware from date of installation )

40 To be paid quarterly (3.33 % per quarter) for 36 (12 Quarters)

6. Successful Exit Management 10 Minutes of meeting of the Apex Committee

Total 100

Key note: 1. Payment will only be released to the System Integrator (SI) after all the compliance as per Go-Live

definition has been met by the System Integrator (SI) 2. Payment of hardware procurement & data digitization shall be based on actuals

Definition of Go-Live Go-live of e-district project in a district as fulfillment of all the following categories: Go-Live of the services includes successful District Readiness for all offices, i.e. Completion of all



activities like Placement of all the Associate Project Manager (Division), Technical Support Leads (District), Site preparation, Networking, Commissioning of all Hardware, Training, Data Digitization in all the district and “Successful delivery of targeted transactions” as explained below:- Successful Delivery of Targeted Transactions 1. Go -live of 26 services as provided in the RFP are made live. Go-live for these 26 services

would imply there would be at least the following number of transactions per month for a

period of 3 consecutive months for that service based on the population of the district as

following:

a. Districts with population <5 Lakhs –at least 10 transactions per month for each service

b. Districts with population <10 Lakhs- at least 20 transactions per month for each service

c. Districts with population >10 Lakhs- at least 30 transactions per month for each service

a. Among the services listed in the RFP, at least 10 services should attain high volume of

transactions for three consecutive months in that district. High volume of transactions are

defined as:Districts with population <5 Lakhs –High volume services would be those

defined as at least 50 transactions per month per service for the entire district

b. Districts with population <10 Lakhs but >5 Lakhs – High volume services would be those

defined as at least 100 transactions per month per service for the entire district

c. Districts with population >10 Lakhs. High volume services would be those defined as at

least 150 transactions per month per service for the entire district

2. At least three of the “High Volume services” as defined above in Sl no. (2) Should be

amenable to delivery across the counter,

3. The aggregate transactions for all services for all services (including High Volume

services)made live, out of the services included in the RFP, reach the following levels for at

least three consecutive months in that district

a. Districts with population <5 Lakhs –at least 750 transactions per month for the entire

district

b. Districts with population <10 Lakhs but >5 Lakhs –at least 1500 transactions per month for

the entire district

c. Districts with population >10 Lakhs –at least 2500 transactions per month for the entire

district Note: Transaction would be defined a complete service being delivered to the citizen which may include submission of an application by the citizen, back end processing and service delivery. Across the counter service delivery will also count as a transaction.



27 Annexures

ANNEXURE – A – FORMAT FOR CHANGE COTROL NOTICE

Change Control Note CCN Number:

Part A: Initiation

Title:

Originator:

Sponsor:

Date of Initiation:

Details of Proposed Change

(To include reason for change and appropriate details/specifications. Identify any attachments as

A1, A2, and A3 etc.)

Authorised by ITG Date:

Name:

Signature:

Received by the SI

Date:

Name:

Signature:

Change Control Note

CCN Number:

Part B : Evaluation

(Identify any attachments as B1, B2, and B3 etc.)

Changes to Services, charging structure, payment profile, documentation, training, service levels

and component working arrangements and any other contractual issue.

Brief Description of Solution:

Impact:



Deliverables:

Timetable:

Charges for Implementation:

(including a schedule of payments)

Other Relevant Information:

(including value-added and acceptance criteria)

Authorised by the Bidder Date:

Name:

Signature:

Change Control Note CCN Number :

Part C : Authority to Proceed

Implementation of this CCN as submitted in Part A,

in accordance with Part B is: (tick as appropriate)

Approved

Rejected

Requires Further Information (as follows, or as

Attachment 1 etc.)

For ITG and its nominated agencies For the Bidder

Signature Signature

Name Name

Title Title

Date Date



ANNEXURE – B - LIST OF SERVICES PROVIDED BY THE BIDDER

Various services to be offered by the bidder will consist of:



3. Business Process Reengineering for the selected applications/ services






9. UAT & Go live


11. Operation & Maintenance (O&M)

Note:

ITG will sign the end user license agreement for the software brought from any 3rd party for

the purpose of this Project however Impelementation Agency shall be solely responsible to

make payment for the cost of software to such third party software vendor.



ANNEXURE – C –PROJECT PLAN & DELIVERABLES

The project implementation plans along with indicative timelines as anticipated by the Purchaser for e-District Goa Project are:

Sr. Activity Sub Activity Timelines (In

Months)

1 Signing of Contract with SI T

2 Current State Assessment Report

Field visit & submission of updated assessment report of District/ Taluka / Gram level provided by SPMU and validated by DeGS comprising of :

T + 1

Requirement of all activities for commissioning at all sites; i.e.

Hardware

Networking

Training

Placement of Technical Support in the district

Documents for digitization

Site preparation

3 System Requirement Specification

Submission of SRS document along with all relevant design documents including but not limited to:

T+2

Detailed System Study Report

Updated and approved FRS

SRS document

HLD documents

e-District Application architecture documents.

ER diagrams and other data modelling documents.

Logical and physical database design.

Data dictionary and data definitions.

Application component design including component deployment views, control flows, etc.

a. LLD documents (including but not limited to)

Application flows and logic.

GUI design (screen design, navigation, etc.).

a. All Test Plans

Requirements Traceability Matrix

3 Deployment of SDC hardware. Deployment of necessary hardware at SDC establishment including Final Acceptance Test

T + 6

4 Completion of Application Development T + 6

5 Completion of User Acceptance Testing – For first set of 10 services T + 7

6 “Go-Live” of first 10 Services in the State of Goa.

IT Infrastructure deployment and testing for one district w.r.t. first set of 10 services

T + 8

Training & capacity building for both the districts w.r.t. first set of 10 services



Sr. Activity Sub Activity Timelines (In

Months)

Data Digitization and Migration of concerned records to centralized database after approval and digitally signing by authorized government officials w.r.t. first set of 10 services

Any other Activity required for the Go- live of these 10 services

STQC approval of Software Modules

Go-Live of services

Completion of User Acceptance Testing – For remaining set of 16 services

T + 10

7 “Go-Live” of remaining 16 Services in the State of Goa.

IT Infrastructure deployment and testing for both the districts w.r.t. remaining set of 16 services

T + 11

Training & capacity building for both the districts w.r.t. remaining set of 16 services

Data Digitization and Migration of concerned records to centralized database after approval and digitally signing by authorized government officials w.r.t. remaining set of 16 services

STQC approval of Software Modules

Go-Live of services

8 Operations and Maintenance Phase

3 years for software from date of Go live and 5 years for hardware from date of installation

T + 47

9 Successful Exit Management T+ 47

Note: Assessment activities has to be updated by SI



ANNEXURE – D - BID

Summary of Cost Components

S.

No. Item Total Price VAT

State Entry Tax (If any)

Total cost

(total price +

taxes)

a)

Hardware related costs with

onsite comprehensive

warranty for the period of 5

years from the date of

installation (A)

b) Networking related costs (B)

c)

Application Customization /

Development and database

creation cost (C)

d)

Operations and Maintenance

Costs (Quarterly Expenses

(software) for 3 years for

software from date of Go

live and 5 years for

hardware from date of

installation (D)

e) Data Digitization (E)

f)

Deployment & operation &

maintenance of requisite

infrastructure for period of 5

years from date of installation

at State Data centre & IT

Disaster Recovery(F)

Total Cost

Total cost in figures:

Details of Cost Component

S. No.

Category

Component No of Compone

nts / Units of Service

Rate per unit

(including all taxes except VAT &

state entry tax)

VAT State

Entry Tax (If any)

Total Cost

A. Hardware Related Costs with the Comprehensive onsite warranty of 5 years from date of installation



S. No.

Category



Rate per unit


state entry tax)

VAT State

Entry Tax (If any)

Total Cost

1.

Infrastructure / Hardware

Desktop/ Computer

369

Laptop 1 Digital Web camera

10

Scanners (A4 size)

9

Scanners (A3 size)

3

Heavy Duty Laser Printer (A4 size)

108

Laser Printer (A3 size)

2

Passbook Printers

2

UPS (1 KVA, Online)

178

2.

Infrastructure Installation and Testing / Miscellaneous Charges

Others

Total A:

B. Networking Related Costs

1.

Network Related Infrastructure & Horizontal connectivity costs

Routers

8 Port Switch 1

16 Port Switch 1

24 Port Switch 1

LAN Cabling (including

IO,CAT 6 cable , Casing Capping

Crimping)

400 network points

2. UPS electrical cabling

15/5 AMP socket with switch and wiring with

500 UPS electrical points



S. No.

Category



Rate per unit


state entry tax)

VAT State

Entry Tax (If any)

Total Cost

casing & capping

Total B:

C. Application Development & Database Creation


a

Development of eDistrict Services (as per the scope defined) Including training, hand holding cost and helpdesk support

Total C:

D : Operations and Maintenance Costs (Quarterly Expenses (Software) for <3> years of contract after „”Go-Live”) (D)

1.

Application Maintenance & Operation of eDistrict applications

Total D:

E. Data Digitization

For details of effort, please refer Volume II.

1. Scanning of A4 size For 100000 pages

2. Scanning of A3 size For 50000 pages

3. Scanning of legal size For 75000

pages

4. Cost of data entry For 200000



S. No.

Category



Rate per unit


state entry tax)

VAT State

Entry Tax (If any)

Total Cost

records (to be quoted on the basis of 1000 characters )

Total E:

Note: The figures indicated for data digitization are indicative only

F. Deployment and Operation & maintenance of requisite infrastructure for period of 5 years from date of installation at State Data centre & IT Disaster Recovery

For Details of BOM. Please

refer volume II

1. Database Server 2

2. Application Server 2

3. Web Server 2

4. Backup and Reporting

Server 2

5. Development Server 2

6. Application Load Balancer 2

7. 10U Blade enclosure 1

8. KVM Switch 1

9. L3 network switch 1

10. Laptops 2

11. 5TB SAN Box 1

2 System Software

1. Server OS 10

2. RDBMS 2

3. Application server 2

4. Systems Management

software 2

5. Development environment 2

6. Virtualization software 1

7. Anti-Virus software 10

Total F:

Additional information to be provided by the bidder [ It is mandatory for bidder to provide this information which will not be a part of financial bid evaluation. Failing to provide this information will result into rejection of bid]

a. Cost of eDistrict Application software AMC for additional 2 years [after initial 3 years,

however it will be the State‟s call whether to give extended service contract for AMC to the



eDistrict SI or not, which will be informed to SI/bidder 3 months prior to completion of

initial 3 years warranty . On award of AMC contract for next 2 years, the eDistrict

SI/bidder must provide AMC support. Any refusal/denial by SI/bidder for AMC support

will be treated as violation of the contract and will lead to blacklisting of the SI/bidder by

the State and further encashment of the performance bank guarantee]

b. Support Manpower

Support Manpower

S.No Support Manpower Rate/Month (inclusive of service tax)

Total

1. Project Manager

2. System/ Network Administrator



5. Software Programmer and Business Analyst

6. District Manager



….

Total

c. Total Training Cost in Rs………

Training

Training Cost Per Person Nos. resources to be trained

Rate ( Inclusive of service tax)

Total

1. Basic computer skills 100

2. Advanced training on the Application modules

50

Total

d. Web Services

Web Services

Development of Web Services Nos. Web Services

Total Value Inclusive of service tax

1. Development of End to End Services 14

2. Development of Web Services (of NIC) 12

3. Development of interface for data from various departments

for selected services under e-District.

26

Total



ANNEXURE – F – ROLES AND RESPONSIBILITIES OF THE PARTIES

Roles and Responsibilities of Bidder

1. Preparation of Detailed Project Plan in line with the overall plan provided in the RFP. The

same should be prepared in consultation with ITG.

2. Procure, install, commission, operate and maintain:

a. Requisite hardware & system software at ITG‟s HQ, Data Center and other locations

as per the requirements mentioned in this RFP

b. Networking equipments, connectivity and LAN as per the requirements mentioned in

this RFP,

c. Meet the defined SLAs for the performance of the system.

3. Addressing technology obsolescence by appropriate upgradation, replacement and / or

replenishment of systems deployed at various locations (data center, HQ and other

locations).

4. Insure the entire hardware against the infrastructure deployed at various locations for the

entire duration of the contract against vandalism, theft, fire and lightening.

5. Keep all system software i.e. OS, antivirus, office applications etc., for Servers, PCs etc. at

Data Centre and various locations, up to date by installing regular upgrades / patches.

6. Rectification of system software problems due to crashing or malfunctioning of the OS,

RDBMS or front end within the time limits to meet the SLAs as defined in RFP.

7. Develop / customize, deploy and maintain the requisite Software Solution as per the

requirements of the Corporation at appropriate locations.

8. Provide necessary support for the resolution of bugs, patches & upgrades of the software

solution.

9. Provide necessary manpower for managing the Change Requests.

10. Design various manuals like User manual, Trouble Shooting manual etc. for the system.

11. Provide computer basic skills training and advanced training on application modules to the

staff members and stakeholders of the Corporation.

12. Maintain the business continuity.

13. Deploy requisite manpower and infrastructure for the digitization of the existing data.

14. Deploy the required manpower to manage the operations.

15. Ensuring the SLAs for downtime of system, software development / customization,

procurement and delivery of hardware & networking equipments, errors in data entry as

defined in RFP Voulme 1 are met.

16. Management and quality control of all services and infrastructure.

17. Any other services which is required for the successful execution of the project.

18. Regular Backup as per the schedule and Disaster Recovery.

19. Generation of MIS reports as per the requirements of ITG.

20. Generation of the report for the monitoring of SLAs.



21. Meet the defined Technical Specifications for the IT Infrastructure including Hardware and

networking equipments keeping in mind the application and future requirements of the

Corporation.

Roles and Responsibilities of ITG

1. Provide adequate space at ITG‟s HQ for setting up of infrastructure, software development and

other activities to be carried out by the Bidder.

2. Coordination between all the divisions for providing necessary information for the study and

development / customization of the necessary solution.

3. Co-ordination with DIT, PAWAN (?) operator and other state agencies to assist the selected

bidder in execution of the project.

4. Coordinate with Bidder for conducting workshops for the Stakeholder departments.

5. Provide the data available in the form of physical files or existing databases to the selected

bidder for digitization purposes.

6. Deployment of staff members of the – organization for verification of the digitized data within

the defined timelines.

7. Ensure that Data Backups are being taken regularly by bidder as per the schedule agreed upon.

8. Ensure that the hardware and other infrastructure deployed at HQ, DC etc. meets the

specifications as mentioned in RFP and is maintained properly to meet the SLAs as defined in

RFP.

9. Monitoring of overall timelines, SLAs and calculation of penalties accordingly.

10. Issuing the Acceptance Certificate on successful deployment of the software application,

hardware deployed, digitized data and for other components of the Scope of Work (wherever

required).

11. Any other requirements that could arise during operations for effective governance and to

meet any administrative requirement.

12. To create internal capacity now for execution of the project after takeover from the bidder.

13. Ensuring the staff members and other stakeholders attend the training programs as per the

schedule defined by the bidder and agreed upon by ITG.

14. Provide sign off on the deliverables of the project including SRS, design documents etc.



NON-DISCLOSURE AGREEMENT

THIS AGREEMENT is made on this the <<‟Day‟>> day of <<‟Month‟>> 20--- at <<‟Location‟>>,

India.

BETWEEN

Info Tech Corporation of Goa Ltd, Government of Goa, having its office at 4th Floor, Alcon

Construction, Above Alcon Hyundai Showroom, Porvorim,Bardez, Goa,India, hereinafter referred

to as „ITG‟ or „ITG’, which expression shall, unless the context otherwise requires, include its

permitted successors and assigns);

AND

<<‟Implementing Agency Full Name’>>, a Company incorporated under the Companies Act, 1956,

having its registered office at <<‟Implementing Agency Regd Office‟>> (hereinafter referred to as „the

Bidder /SI’ which expression shall, unless the context otherwise requires, include its permitted

successors and assigns).


a „Party‟.

WHEREAS:

1. ITG is desirous to implement the project of e-District Mission Mode Project - Goa.

2. ITG and bidder have entered into a Master Services Agreement dated <<‟Date‟>> (the

“MSA”) as well as a Service Level Agreement dated <<‟Date‟>> (the “SLA”) in furtherance

of the Project.

3. Whereas in pursuing the Project (the “Business Purpose”), a Party (“Disclosing Party)

recognizes that they will disclose certain Confidential Information (as defined hereinafter) to

the other Party (“Receiving Party”).

4. Whereas such Confidential Information (as defined hereinafter) belongs to Receiving Party as

the case may be and is being transferred to the Disclosing Party to be used only for the

Business Purpose and hence there is a need to protect such information from unauthorized

use and disclosure.






1.1 Definitions

[Terms and expressions used in this Agreement (including the Introduction) shall have the same

meanings set out in Schedule I of MSA.]

1.2 Interpretation

In this Agreement, unless otherwise specified:

(a) references to Clauses, Sub-Clauses, Paragraphs and Schedules are to clauses, sub-

clauses, paragraphs of and schedules to this Agreement;

use of any gender includes the other genders;

references to a „company‟ shall be construed so as to include any company, corporation or other

body corporate, wherever and however incorporated or established;

references to a „person‟ shall be construed so as to include any individual, firm, company,

government, state or agency of a state, local or municipal authority or government body or any

joint venture, association or partnership (whether or not having separate legal personality);

a reference to any statute or statutory provision shall be construed as a reference to the same as it

may have been, or may from time to time be, amended, modified or re-enacted;

any reference to a „day‟ (including within the phrase „business day‟) shall mean a period of 24

hours running from midnight to midnight;

references to a „business day‟ shall be construed as a reference to a day (other than a Sunday) on

which banks in the state of <<‟State‟>> are generally open for business;

references to times are to Indian standard time;

a reference to any other document referred to in this Agreement is a reference to that other

document as amended, varied, novated or supplemented at any time; and

all headings and titles are inserted for convenience only. They are to be ignored in the

interpretation of this Agreement.


All measurements and calculations shall be in the metric system and calculations done to 2 (two)



nearest INR


In case of ambiguities or discrepancies within this Agreement, the following principles shall apply:

(a) as between two Clauses of this Agreement, the provisions of a specific Clause


Clause;

as between the provisions of this Agreement and the Schedules, the Agreement shall prevail, save

and except as expressly provided otherwise in the Agreement or the Schedules; andas between any



value written in numerals and that in words, the value in words shall prevail.

1.5 Priority of agreements

The Parties hereby expressly agree that for the purpose of giving full and proper effect to this

Agreement, the MSA and this Agreement shall be read together and construed harmoniously. In

the event of any conflict between the MSA and this Agreement, the provisions contained in the MSA

shall prevail over this Agreement.

2 Term

This Agreement will remain in effect for five years from the date of the last disclosure of

Confidential Information (“Term”), at which time it will terminate, unless extended by the

disclosing party in writing.

3 Scope of the Agreement

(a) This Agreement shall apply to all confidential and proprietary information

disclosed by Disclosing Party to the Receiving Party and other information which

the disclosing party identifies in writing or otherwise as confidential before or

within (30) thirty days after disclosure to the Receiving Party (“Confidential

Information”). Such Confidential Information consists of certain specifications,

documents, software, prototypes and/or technical information, and all copies and

derivatives containing such Information that may be disclosed to the Disclosing

Party for and during the Business Purpose, which a party considers proprietary or

confidential.

(b) Such Confidential Information may be in any form or medium, tangible or

intangible, and may be communicated/disclosed in writing, orally, or through

visual observation or by any other means to the Receiving Party.

4 Obligations of the Receiving Party

The Receiving Party shall:

(a) use the Confidential Information only for the Business Purpose and shall hold the

Confidential Information in confidence using the same degree of care as it normally

exercises to protect its own proprietary information, taking into account the nature

of the Confidential Information, and grant access to Confidential Information only

to its employees on a „need to know basis‟ and restrict such access as and when not

necessary to carry out the Business Purpose.

cause its employees to comply with the provisions of this Agreement;

Reproduce Confidential Information only to the extent essential to fulfilling the Business Purpose,

and prevent disclosure of Confidential Information to third parties; disclose the Confidential



Information to its consultants/contractors on a need to know basis; provided that by doing so, the

Receiving Party agrees to bind such consultants/ contractors to terms at least as restrictive as those

stated herein. The Receiving Party upon making a disclosure under this Clause shall:

I. Advise the consultants/contractors of the confidentiality obligations imposed on

them by this Clause.

II. upon the Disclosing Party's request, the Receiving Party shall either return to the

disclosing party all Confidential Information or shall certify to the disclosing party

that all media containing Confidential Information have been destroyed.

III. Provided, however, that an archival copy of the Confidential Information may be

retained in the files of the Receiving Party's counsel, solely for the purpose of

proving the contents of the Confidential Information.

IV. not to remove any of the other Party‟s Confidential Information from the premises

of the Disclosing Party without prior written approval.

V. exercise extreme care in protecting the confidentiality of any Confidential

Information which is removed, only with the Disclosing Party‟s prior written

approval, from the Disclosing Party‟s premises. Each Party agrees to comply with

any and all terms and conditions the disclosing party may impose upon any such

approved removal, such as conditions that the removed Confidential Information

and all copies must be returned by a certain date, and that no copies are to be made

off of the premises.

VI. Upon the Disclosing Party‟s request, the Receving Party shall promptly return to

the Disclosing Party all tangible items containing or consisting of the disclosing

party‟s Confidential Information all copies thereof.

5 Exceptions to Confidential Information

The foregoing restrictions on each party's use or disclosure of Confidential Information shall not

apply to the Confidential Information if the Receiving Party can demonstrate that such

Confidential Information:

was independently developed by or for the Receiving Party without reference to the Information,

or was received without restrictions; or

has become generally available to the public without breach of confidentiality obligations of the

Receiving Party; or

I. was in the Receiving Party's possession without restriction or was known by the

Receiving Party without restriction at the time of disclosure; or

II. is the subject of a subpoena or other legal or administrative demand for disclosure;

provided, however, that the Receiving Party has given the disclosing party prompt

notice of such demand for disclosure and the Receiving Party reasonably cooperates

with the disclosing party's efforts to secure an appropriate protective order; or

III. is disclosed with the prior consent of the disclosing party; or



IV. was in its possession or known to it by being in its use or being recorded in its files

or computers or other recording media prior to receipt from the disclosing party

and was not previously acquired by the Receiving Party from the disclosing party

under an obligation of confidence; or

V. the Receiving Party obtains or has available from a source other than the disclosing

party without breach by the Receiving Party or such source of any obligation of

confidentiality or non-use towards the disclosing party.

6 Ownership of the Confidential Information

I. Each Party recognizes and agrees that all of the disclosing Party‟s Confidential

Information is owned solely by the Disclosing Party (or its licensors) and that the

unauthorized disclosure or use of such Confidential Information would cause

irreparable harm and significant injury, the degree of which may be difficult to

ascertain.

II. By disclosing the Confidential Information or executing this Agreement, Disclosing

Party does not grant any license, explicitly or implicitly, under any trademark,

patent, copyright, mask work protection right, trade secret or any other intellectual

property right. The Disclosing Party disclaims all warranties regarding the

information, including all warranties with respect to infringement of intellectual

property rights and all warranties as to the accuracy or utility of such information.

III. Access to Confidential Information hereunder shall not preclude an individual who

has seen such Confidential Information for the purposes of this Agreement from

working on future projects for the Disclosing Party which relate to similar subject

matters, provided that such individual does not make reference to the Confidential

Information and does not copy the substance of the Confidential Information

during the Term. Furthermore, nothing contained herein shall be construed as

imposing any restriction on the Receving Party's disclosure or use of any general

learning, skills or know-how developed by the Receving Party's personnel under

this Agreement.

IV. Execution of this Agreement and the disclosure of Confidential Information

pursuant to this Agreement do not constitute or imply any commitment, promise,

or inducement by either Party to make any purchase or sale, or to enter into any

additional agreement of any kind.

7 Dispute Resolution

I. If a dispute arises in relation to the conduct of this Contract (Dispute), a party must

comply with this clause 7 before starting arbitration or court proceedings (except

proceedings for urgent interlocutory relief). After a party has sought or obtained

any urgent interlocutory relief that party must follow this clause 7.



II. A party claiming a Dispute has arisen must give the other parties to the Dispute

notice setting out details of the Dispute.

III. During the 14 days after a notice is given under clause 7(b) (or longer period if the

parties to the Dispute agree in writing), each party to the Dispute must use its

reasonable efforts through a meeting of Senior Executive (or their nominees) to

resolve the Dispute. If the parties cannot resolve the Dispute within that period

then any such dispute or difference whatsoever arising between the parties to this

Contract out of or relating to the construction, meaning, scope, operation or effect of

this Contract or the validity of the breach thereof shall be referred to a sole

arbitrator to be appointed by mutual consent of both the parties herein. If the

parties cannot agree on the appointment of the arbitrator within a period of one

month from the notification by one party to the other of existence of such dispute,

then the Arbitrator shall be appointed by the High Court of the jurisdiction

specified in this agreement. The provisions of the Arbitration and Conciliation Act,

1996 will be applicable and the award made there under shall be final and binding

upon the parties hereto, subject to legal remedies available under the law. Such

differences shall be deemed to be a submission to arbitration under the Indian

Arbitration and Conciliation Act, 1996, or of any modifications, Rules or re-

enactments thereof. The Arbitration proceedings will be held at the jurisdiction

specified in Item 27. Any legal dispute will come under the sole jurisdiction

specified in Item 27.

IV. The Receving Party agrees that the Disclosing Party shall have the right to obtain an

immediate injunction enjoining any breach of this Agreement, as well as the right to

pursue any and all other rights and remedies available at law or in equity for such a

breach.

8 Variation

This Agreement may only be varied in writing and signed by both Parties.

9 Waiver

Waiver including partial or conditional waiver, by either Party of any default by the other Party in

the observance and performance of any provision of or obligations under this Agreement:-

I. shall be in writing

II. shall not operate or be construed as a waiver of any other or subsequent default hereof or

of other provisions of or obligations under this Agreement;

III. shall be executed by a duly authorized representative of the Party; and

IV. shall not affect the validity or enforceability of this Agreement in any manner.



10 Exclusion of Implied Warranties

This Agreement expressly excludes any warranty, condition or other undertaking implied at law

or by custom or otherwise arising out of any other agreement between the Parties or any

representation by either Party not contained in a binding legal agreement executed by both Parties.

11 Entire Agreement

This Agreement and the Annexure together constitute a complete and exclusive statement of the

terms of the agreement between the Parties on the subject hereof, and no amendment or

modification hereto shall be valid and effective unless such modification or amendment is agreed

to in writing by the Parties and duly executed by persons especially empowered in this behalf by

the respective Parties. All prior written or oral understandings, offers or other communications of

every kind pertaining to this Agreement are abrogated and withdrawn.

12 Severability

If for any reason whatever, any provision of this Agreement is or becomes invalid, illegal or

unenforceable or is declared by any court of competent jurisdiction or any other instrumentality to

be invalid, illegal or unenforceable, the validity, legality or enforceability of the remaining

provisions shall not be affected in any manner, and the Parties shall negotiate in good faith with a

view to agreeing to one or more provisions which may be substituted for such invalid,

unenforceable or illegal provisions, as nearly as is practicable to such invalid, illegal or

unenforceable provision. Failure to agree upon any such provisions shall not be subject to the

dispute resolution procedure set forth under this Agreement or otherwise.

13 No Partnership

This Agreement shall not be interpreted or construed to create an association, joint venture or

partnership between the Parties, or to impose any partnership obligation or liability upon either

Party, and neither Party shall have any right, power or authority to enter into any agreement or

undertaking for, or act on behalf of, or to act as or be an agent or representative of, or to otherwise

bind, the other Party except as expressly provided under the terms of this Agreement.

14 Third Parties

This Agreement is intended solely for the benefit of the Parties and their respective successors and

permitted assigns, and nothing in this Agreement shall be construed to create any duty to,

standard of care with reference to, or any liability to, any person not a Party to this Agreement.

15 Successors and Assigns

The Agreement shall be binding on and shall inure to the benefit of the Parties and their respective

successors and permitted assigns.

16 Notices

Any notice or other communication to be given by any Party to the other Party under or in

connection with the matters contemplated by this Agreement shall be in writing and shall be given

by hand delivery, recognized courier, registered post, email or facsimile transmission and

delivered or transmitted to the Parties at their respective addresses set forth below:



If to ITG:

Attn: <***>

Tel:

Fax:

Email:

Contact:

With a copy to:

If to the Bidder :

Attn. <***>

Phone: <<‟SI Telephone‟>>

Fax No. <<‟SI Fax‟>>

17 Language

All notices required to be given by one Party to the other Party and all other communications,

documentation and proceedings which are in any way relevant to this Agreement shall be in

writing and in the English language.

18 Counterparts

This Agreement may be executed in counterparts, each of which, when executed and delivered,

shall constitute an original of this Agreement.

19 Mitigation

Without prejudice to any express provisions of this Agreement on any mitigation obligations of the

Parties, each of ITG and the bidder shall at all times take all reasonable steps to minimize and

mitigate any loss for which the relevant Party is entitled to bring a claim against the other Party

pursuant to this Agreement.

20 Removal of Difficulties

The Parties acknowledge that it is conceivable that the Parties may encounter difficulties or

problems in the course of implementation of the Project and the transactions envisaged under this

Agreement. The Parties agree and covenant that they shall mutually discuss such difficulties and

problems in good faith and take all reasonable steps necessary for removal or resolution of such

difficulties or problems.

IN WITNESS WHEREOF THE PARTIES HAVE EXECUTED AND DELIVERED THIS

AGREEMENT AS OF THE DATE FIRST ABOVE WRITTEN.



SIGNED, SEALED AND DELIVERED

For and on behalf of the bidder by:


For and on behalf of ITG by:

(Signature)

(Name)

(Designation)

(Address)

(Fax No.)

(Signature)

(Name)

(Designation)

(Address)

(Fax No.)

In the presence of:

1.

2.


SERVICE LEVEL AGREEMENT

THIS AGREEMENT is made on this the <<‟Day‟>> day of <<‟Month‟>> 20---- at <<‟Location‟>>,

India.

BETWEEN

Info Tech Corporation of Goa Ltd, Government of Goa, having its office at 4th Floor, Alcon

Construction, Above Alcon Hyundai Showroom, Porvorim,Bardez, Goa, India, hereinafter

referred to as „ITG‟ or „Buyer‟, which expression shall, unless the context otherwise requires,

include its permitted successors and assigns);

AND

<<‟Implementing Agency Full Name‟>>, a Company incorporated under the Companies Act, 1956,

having its registered office at <<‟Location‟>> (hereinafter referred to as „the Bidder /SI’ which

expression shall, unless the context otherwise requires, include its permitted successors and

assigns).


a „Party‟.

WHEREAS:

1. ITG is desirous to implement the project of eDistrict in <<‟State’>>.

2. The Buyer and bidder have entered into a Master Services Agreement dated <<‟‟Date‟>>

(the “MSA”).




1.1 Definitions

[Terms and expressions used in this Agreement (including the Introduction) shall have the

meanings set out in Annexure A.]

1.2 Interpretation

In this Agreement, unless otherwise specified:

references to Clauses, Sub-Clauses, Paragraphs and Schedules are to clauses, sub-clauses,

paragraphs of and schedules to this Agreement;

use of any gender includes the other genders;

references to a „company‟ shall be construed so as to include any company, corporation or other

body corporate, wherever and however incorporated or established;


references to a „person‟ shall be construed so as to include any individual, firm, company,

government, state or agency of a state, local or municipal authority or government body or any

joint venture, association or partnership (whether or not having separate legal personality);

a reference to any statute or statutory provision shall be construed as a reference to the same as it

may have been, or may from time to time be, amended, modified or re-enacted;

any reference to a „day‟ (including within the phrase „business day‟) shall mean a period of 24

hours running from midnight to midnight;

references to a „business day‟ shall be construed as a reference to a day (other than a Sunday) on

which banks in the state of<<‟State‟>> are generally open for business;

references to times are to Indian Standard Time;

a reference to any other document referred to in this Agreement is a reference to that other

document as amended, varied, novated or supplemented at any time; and

all headings and titles are inserted for convenience only. They are to be ignored in the

interpretation of this Agreement.


[All measurements and calculations shall be in the metric system and calculations done to 2 (two)



nearest INR.]


In case of ambiguities or discrepancies within this Agreement, the following principles shall apply:

(a) as between two Clauses of this Agreement, the provisions of a specific Clause


Clause;

as between the provisions of this Agreement and the Schedules, the Agreement shall prevail, save

and except as expressly provided otherwise in the Agreement or the Schedules; and

as between any value written in numerals and that in words, the value in words shall prevail.

1.5 Priority of agreements

The Parties hereby expressly agree that for the purpose of giving full and proper effect to this

Agreement, the MSA and this Agreement shall be read together and construed harmoniously. In

the event of any conflict between the MSA and this Agreement, the provisions contained in the MSA

shall prevail over this Agreement.

2 Structure

This SLA shall operate as a legally binding services agreement specifying terms which apply to the

Parties in relation to the provision of the Services by the bidder to the Buyer and its nominated

agencies under this Agreement and the MSA.


3 Objectives of this SLA

The bidder shall be required to ensure that the Service Levels which shall ensure the following:

Improving the efficiency of operations for the citizen services providing departments in the state of

Goa.

Leveraging the benefits in new system in order to:

I. Reduce of manual records and replace with computerized standardized documents.

II. Infuse transparency in operations by enabling the stakeholders to have easy access to the

records and provision of login ids and digital signatures to infuse accountability in

operations

III. Enable faster request processing in delivery of services with better turn around time.

IV. Facilitate automated data transfer with state-wide connectivity to prevent unnecessary

duplication & simplify preparation of registers and reports.

V. Generate meaningful MIS from the system.

VI. Provide inbuilt mechanism of security and quality control for critical personal data.

To meet the aforementioned objectives the bidder will provide the Service Levels in accordance

with the performance metrics as set out in detail in this Agreement. Further this Agreement shall

govern the provision of the contracted professional services of the bidder to ITG and its nominated

agencies after the Effective Date.

4 Scope of SLA

This Agreement has been executed in relation to the outsourcing portion of the Project between the

Parties. The detailed Service Levels have been set out in Annexure B to this Agreement.

This Agreement shall ensure the following:

Establishment of mutual responsibilities and accountability of the Parties;

Definition each Party‟s expectations in terms of services provided;

Establishment of the relevant performance measurement criteria;

Definition of the availability expectations;

Definition of the escalation process;

Establishment of trouble reporting single point of contact; and

Establishment of the framework for SLA change management

The following parties are obligated to follow the procedures as specified by this Agreement:

I. Buyer

II. Bidder


5 Agreement Owners

The following personnel shall be notified to discuss the Agreement and take into consideration any

proposed SLA change requests:

Title Telephone Email

Buyer Authorized

Representative, ITG

<<‟Telephone

ITG‟>>

<<‟email

ITG‟>>

Bidder Authorized

Representative, Bidder

<<‟Telephone SI‟>>

<<‟email

SI‟>>

6 Contact List

In the event that there is any change in the listed contacts, the same shall be communicated and

updated prior to such change occurring. The Single Point of Contact (“POC”) for the bidder shall be

<<‟POC Name‟>> and will be available 24X7.

Name Title Location Telephone

Buyer Authorised

Representative, ITG

<<‟Location ITG‟>> <<‟Telephone

ITG‟>>

Bidder Authorized

Representative, Bidder

<<‟Location SI‟>> <<‟Telephone

SI‟>>

7 Principal Contacts

The Buyer and the bidder will nominate a senior staff member to be the principal contact regarding

operation of this Agreement. At the date of signing of this Agreement, the nominated principal

contacts are:

Buyer principal contact: _________________________

Bidder principal contact: _________________________

8 Commencement and Duration of this Agreement

Agreement shall commence on the date on which it is executed by the Buyer and the System

integrator (hereinafter the “Effective Date”) and shall, unless terminated earlier in accordance with

its terms or unless otherwise agreed by the Parties, expire on the date on which this Agreement

expires or terminates, which shall be a period of four years starting from the date of the Final

Acceptance Test.

9 Exclusions to the Agreement

This Agreement shall not govern the following services:

I. Consulting services; and


II. System integrator‟s business processes not related to the Project.

10 Terms of Payment and Penalties

I. In consideration of the Services and subject to the provisions of the MSA and this

Agreement, the Buyer shall pay the amounts in accordance with the Terms of

Payment Schedule of the MSA.

II. For the avoidance of doubt, it is expressly clarified that the Buyer and/or its

nominated agencies may also calculate a financial sum and debit the same against

the terms of payment as defined in the Terms of Payment Schedule of the MSA as a

result of the failure of the System integrator to meet the Service Levels set out as

Annexure B of this Agreement, such sum being determined in accordance with the

terms of the set out as Annexure B of this Agreement.

11 Updating of this Agreement

I. The Parties anticipate that this Agreement shall need to be re-evaluated and

modified to account for changes in work environment and technology from time to

time. Hence they herby agree to revise the terms of the Agreement on an annual

basis.

II. The Parties hereby agree upon the following procedure for revising this Agreement:

A. Any and all changes to this Agreement will be initiated in writing between

the Buyer and the System integrator, The service levels in this Agreement

shall be considered to be standard for the Buyer and shall only be modified

if both Parties agree to an appended set of terms and conditions;

B. Only the Buyer or the System integrator may initiate a revision to this

Agreement;

C. A notice of the proposed revision (“SLA Change Request”) shall be served to

the Buyer or the System integrator as the case may be;

D. The SLA Change request would be deemed to be denied in case it is not

approved within a period of <<‟Days‟>> days;

E. In the event that Buyer/System integrator approves of the suggested change

the change shall be communicated to all the Parties and the SLA Change

request would be appended to the Agreement;

F. The Buyer shall update and republish the text of Agreement annually to

include all the SLA Change Requests that have been appended to the

Agreement during the course of the year. Such republished Agreement shall

be circulated to all the Parties within <<‟Days‟>> days of such change taking

place.


12 Document History

All revisions made to this Agreement shall be listed in chronological order as per the format set

out below and a copy of the same shall be provided to the Parties:

Version Date Description of changes

<<‟Version‟>> <<‟Date‟>> <<‟Desc‟>>

13 Scope of Services

I. The bidder shall ensure that Services are available at various locations as per the

requirements of the project;

II. The bidder shall provide support services for addressing problems related to the

provision of services of the selected bidder through the POC. Such POC shall be

available over telephone on <<‟Telephone SI‟>> number 24 hours a day, 7 days a

week

III. The bidder guarantees that he shall achieve the Service Levels for the Project;

IV. The bidder shall be liable to penalties in case of failure to comply with the Service

Levels. However any delay not attributable to the bidder shall not be taken into

account while computing adherence to the Service Levels.

14 Performance Review

The POC‟s of both the Buyer and the bidder shall meet on a quarterly basis to discuss priorities,

service levels and system performance. Additional meetings may be held at the request of either

the bidder or the Buyer. The agenda for these meetings shall be as follows:

I. Service performance;

II. Review of specific problems/exceptions and priorities; and

III. Review of the operation of this Agreement and determine corrective action to

overcome deficiencies.

15 Representations and Warranties of Buyer

The Buyer hereby represents and warrants to the bidder as follows:

I. it has full power and authority to execute, deliver and perform its obligations under

this Agreement and to carry out the transactions contemplated herein and that it

has taken all actions necessary to execute this Agreement, exercise its rights and

perform its obligations, under this Agreement and carry out the transactions

contemplated hereby;

II. it has taken all necessary actions under Applicable Law to authorize the execution,

delivery and performance of this Agreement and to validly exercise its rights and


III. it has the financial standing and capacity to perform its obligations under the


Agreement;

IV. this Agreement has been duly executed by it and constitutes a legal, valid and

binding obligation enforceable against it in accordance with the terms hereof and its

obligations under this Agreement shall be legally valid, binding and enforceable

obligations against it in accordance with the terms thereof;

V. the execution, delivery and performance of this Agreement shall not conflict with,


required by any of the Applicable Laws or any covenant, contract, agreement,

arrangement, understanding, decree or order to which it is a party or by which it or

any of its properties or assets is bound or affected;

VI. there are no actions, suits or proceedings pending or, to its knowledge, threatened

against it at law or in equity before any court or before any other judicial, quasi-

judicial or other authority, the outcome of which may result in the default or breach

of this Agreement or which individually or in the aggregate may result in any

material impairment of its ability to perform its material (including any payment)


VII. it has no knowledge of any violation or default with respect to any order, writ,

injunction or any decree of any court or any legally binding order of any

Government Instrumentality which may result in any material adverse effect on the

bidder‟s ability to perform its obligations under this Agreement and no fact or

circumstance exists which may give rise to such proceedings that would adversely

affect the performance of its obligations under this Agreement.

16 Representations and Warranties of the Bidder

The bidder hereby represents and warrants to the Buyer as follows:

I. it is duly organized and validly existing under the laws of India, and has full power

and authority to execute and perform its obligations under this Agreement and to

carry out the transactions contemplated hereby;

II. it has taken all necessary corporate and other actions under Applicable Laws to

authorize the execution and delivery of this Agreement and to validly exercise its

rights and perform its obligations under this Agreement;

III. this Agreement has been duly executed by it and constitutes its legal, valid and

binding obligation, enforceable against it in accordance with the terms hereof, and

its obligations under this Agreement shall be legally valid, binding and enforceable

obligations against it in accordance with the terms hereof;

IV. the execution, delivery and performance of this Agreement shall not conflict with,


required by any of the terms of its Memorandum and Articles of Association or any

Applicable Laws or any covenant, contract, agreement, arrangement,

understanding, decree or order to which it is a party or by which it or any of its


properties or assets is bound or affected;

V. there are no actions, suits, proceedings, or investigations pending or, to its

knowledge, threatened against it at law or in equity before any court or before any

other judicial, quasi-judicial or other authority, the outcome of which may result in

the breach of this Agreement or which individually or in the aggregate may result

in any material impairment of its ability to perform any of its material obligations

under this Agreement;

VI. it has no knowledge of any violation or default with respect to any order, writ,

injunction or decree of any court or any legally binding order of any government

instrumentality which may result in any material adverse effect on its ability to

perform its obligations under this Agreement and no fact or circumstance exists

which may give rise to such proceedings that would adversely affect the

performance of its obligations under this Agreement;

VII. it has complied with Applicable Law in all material respects and has not been

subject to any fines, penalties, injunctive relief or any other civil or criminal

liabilities which in the aggregate have or may have a material adverse effect on its

ability to perform its obligations under this Agreement;

VIII. no representation or warranty by it contained herein or in any other document

furnished by it to the Buyer or to any government instrumentality in relation to the

Required Consents contains or shall contain any untrue or misleading statement of

material fact or omits or shall omit to state a material fact necessary to make such

representation or warranty not misleading; and

IX. no sums, in cash or kind, have been paid or shall be paid, by it or on its behalf, to

any person by way of fees, commission or otherwise for entering into this

Agreement or for influencing or attempting to influence any officer or employee of

the Buyer in connection therewith.

17 Indemnities

The Parties agree to indemnify each other under this Agreement in accordance with the terms and

principles set out in the MSA.

18 Dispute Resolution

Any dispute, difference or claim arising out of or in connection with the Agreement which is not

resolved amicably shall be decided in accordance with the dispute resolution procedure as set out

in the MSA.


19 Miscellaneous

I. Assignment and charges

This Agreement shall be binding on and enure for the benefit of each Party‟s successors in title. No

Party shall assign, or declare any trust in favour of a third party over, all or any part of the benefit

of, or its rights or benefits under, this Agreement.

II. Governing law and jurisdiction

This Agreement shall be construed and interpreted in accordance with and governed by the laws

of India, and the courts at the State of <<‟State‟>> shall have jurisdiction over matters arising out

of or relating to this Agreement.

III. Waiver of sovereign immunity

The Parties unconditionally and irrevocably:

A. agree that the execution, delivery and performance by them of the Agreement

constitute commercial acts done and performed for commercial purpose;

B. agree that, should any proceedings be brought against a Party or its assets, property or

revenues in any jurisdiction in relation to the Agreement or any transaction

contemplated by the Agreement, no immunity (whether by reason of sovereignty or

otherwise) from such proceedings shall be claimed by or on behalf of such Party with

respect to its assets;

C. waive any right of immunity which it or its assets, property or revenues now has, may

acquire in the future or which may be attributed to it in any jurisdiction; and

D. consent generally to the enforcement of any judgment or award against it in any such

proceedings to the giving of any relief or the issue of any process in any jurisdiction in

connection with such proceedings (including the making, enforcement or execution

against it or in respect of any assets, property or revenues whatsoever irrespective of

their use or intended use of any order or judgment that may be made or given in

connection therewith).

IV. Variation

This Agreement may only be varied in writing and signed by both Parties.

V. Waiver

A. Waiver including partial or conditional waiver, by either Party of any default by the

other Party in the observance and performance of any provision of or obligations under

this Agreement:-

1. shall be in writing

2. shall not operate or be construed as a waiver of any other or subsequent default

hereof or of other provisions of or obligations under this Agreement;

3. shall not be effective unless it is in writing and executed by a duly authorized


representative of the Party; and

4. shall not affect the validity or enforceability of this Agreement in any manner.

VI. Exclusion of implied warranties

[This Agreement expressly excludes any warranty, condition or other undertaking implied at law

or by custom or otherwise arising out of any other agreement between the Parties or any

representation by either Party not contained in a binding legal agreement executed by both

Parties.]

VII. Survival

A. Termination or expiration of the Term shall:

1. not relieve the bidder or the Buyer, as the case may be, of any obligations

hereunder which expressly or by implication survive hereof; and

2. except as otherwise provided in any provision of this Agreement expressly

limiting the liability of either Party, not relieve either Party of any obligations or

liabilities for loss or damage to the other Party arising out of, or caused by, acts

or omissions of such Party prior to the effectiveness of such termination or

expiration or arising out of such termination or expiration.

B. All obligations surviving termination or expiration of the Term shall cease on

termination or expiration of the Term. [In case the obligations have to survive for

some period after closure of the project, the same may be mentioned]

(h) Entire Agreement

[This Agreement and the Annexure together constitute a complete and exclusive statement of the

terms of the agreement between the Parties on the subject hereof, and no amendment or

modification hereto shall be valid and effective unless such modification or amendment is agreed

to in writing by the Parties and duly executed by persons especially empowered in this behalf by

the respective Parties. All prior written or oral understandings, offers or other communications of

every kind pertaining to this Agreement are abrogated and withdrawn.]

(i) Severability

[If for any reason whatever, any provision of this Agreement is or becomes invalid, illegal or

unenforceable or is declared by any court of competent jurisdiction or any other instrumentality to

be invalid, illegal or unenforceable, the validity, legality or enforceability of the remaining

provisions shall not be affected in any manner, and the Parties shall negotiate in good faith with a

view to agreeing to one or more provisions which may be substituted for such invalid,

unenforceable or illegal provisions, as nearly as is practicable to such invalid, illegal or

unenforceable provision. Failure to agree upon any such provisions shall not be subject to the

dispute resolution procedure set forth under this Agreement or otherwise.]

(j) No partnership

[This Agreement shall not be interpreted or construed to create an association, joint venture or

partnership between the Parties, or to impose any partnership obligation or liability upon either


Party, and neither Party shall have any right, power or authority to enter into any agreement or

undertaking for, or act on behalf of, or to act as or be an agent or representative of, or to otherwise

bind, the other Party except as expressly provided under the terms of this Agreement. ]

(k) Third parties

[This Agreement is intended solely for the benefit of the Parties and their respective successors and

permitted assigns, and nothing in this Agreement shall be construed to create any duty to,

standard of care with reference to, or any liability to, any person not a Party to this Agreement.]

(l) Notices

[Any notice or other communication to be given by any Party to the other Party under or in

connection with the matters contemplated by this Agreement shall be in writing and shall be given

by hand delivery, recognized courier, registered post, email or facsimile transmission and

delivered or transmitted to the Parties at their respective addresses set forth below: ]

If to ITG:

Attn: <***>

Tel:

Fax:

Email:

Contact:

With a copy to:

If to the Bidder :

Attn. <***>

Phone: <<‟Telephone SI‟>>

Fax No. <<‟Fax SI‟>>

(m) Language

[All notices required to be given by one Party to the other Party and all other communications,

documentation and proceedings which are in any way relevant to this Agreement shall be in

writing and in the English language.]

(n) Counterparts

[This Agreement may be executed in two counterparts, each of which, when executed and

delivered, shall constitute an original of this Agreement.]

(o) Mitigation

[Without prejudice to any express provisions of this Agreement on any mitigation obligations of

the Parties, each of the Buyer and the bidder shall at all times take all reasonable steps to minimize


and mitigate any loss for which the relevant Party is entitled to bring a claim against the other

Party pursuant to this Agreement.]

(p) Removal of Difficulties

The Parties acknowledge that it is conceivable that the Parties may encounter difficulties or

problems in the course of implementation of the Project and the transactions envisaged under this

Agreement. The Parties agree and covenant that they shall mutually discuss such difficulties and

problems in good faith and take all reasonable steps necessary for removal or resolution of such

difficulties or problems.


IN WITNESS WHEREOF THE PARTIES HAVE EXECUTED AND DELIVERED THIS

AGREEMENT AS OF THE DATE FIRST ABOVE WRITTEN.


For and on behalf of the bidder by:


For and on behalf of the ITG by:

(Signature)

(Name)

(Designation)

(Address)

(Fax No.)

(Signature)

(Name)

(Designation)

(Address)

(Fax No.)

In the presence of:

1.

2.


20 ANNEXURE A – Definitions

Agreement means this Service Level agreement together with all Articles,

Annexures, Schedules and the contents and specifications of the RFP;

Applicable Law(s) means any statute, law, ordinance, notification, rule, regulation,

judgment, order, decree, bye-law, approval, directive, guideline,

policy, requirement or other governmental restriction or any similar

form of decision of, or determination by, or any interpretation or

administration of ITG as may be in effect on the date of the execution

of this Agreement and during the subsistence thereof, applicable to

the Project;

Business Hours shall mean the working time for ITG users which is 9:30 AM to 6:30

PM daily. Again for Web Server and other components which enable

successful usage of web portals of, ITG, the working time should be

considered as 24 hours for all the days of the week. It is desired that

IT maintenance, other batch processes (like backup) etc. should be

planned so that such backend activities have minimum effect on the

performance;

Effective Date shall have the same meaning ascribed to it in Clause 8;

MSA shall have the same meaning ascribed to it in Recital 2;

Parties means the Buyer and System integrator for the purposes of this

Agreement; “Party” shall be interpreted accordingly;

POC shall have the same meaning ascribed to it in Clause 6

Project shall have the same meaning ascribed to it in Recital 1;

SLA Change

Request

shall have the same meaning ascribed to it in Clause 11 (b) (iii);

Service Level means the level of service and other performance criteria which will

apply to the Services as set out in the SLA parameters effective

during the Term of this Agreement;

Term or

Agreement Period

Means the duration of this Agreement as set out in Clause 8 of this

Agreement.

Application

Response Time

Defined as time the system takes to fetch requested (a form or a

report) from the server.


21 ANNEXURE B – Service Levels

1 Purpose:

This document describes the service levels to be established for the Services offered by the SI to the State. The SI shall monitor and

maintain the stated service levels to provide quality service.

2 Definitions:

(a) “Scheduled Maintenance Time” shall mean the time that the System is not in service due to a scheduled activity as defined in this

SLA. The scheduled maintenance time would not be during 16X6 timeframe. Further, scheduled maintenance time is planned

downtime with the prior permission.

(b) “Scheduled operation time” means the scheduled operating hours of the System for the month. All scheduled maintenance time

on the system would be deducted from the total operation time for the month to give the scheduled operation time. The total

operation time for the systems and applications within the Primary DC, DRC and critical client site infrastructure will be 12 hrs X

7 days X 12 months. The total operation time for the client site systems shall be 12 hours.

(c) “System or Application downtime” means accumulated time during which the System is totally inoperable within the Scheduled

Operation Time but outside the scheduled maintenance time and measured from the State Government employees log a call with

the SI team of the failure or the failure is known to the SI from the availability measurement tools to the time when the System is

returned to proper operation.

(d) “Availability” means the time for which the services and facilities are available for conducting operations on the State

Government system including application and associated infrastructure. Availability is defined as:

{(Scheduled Operation Time – System Downtime) / (Scheduled Operation Time)} * 100%

(e) “Helpdesk Support” shall mean the 12 (hours) x 6(days) basis support centre which shall handleFault reporting, Trouble

Ticketing and related enquiries during this contract.

(f) “Incident” refers to any event / abnormalities in the functioning of the Data Centre Equipment / Services that may lead to

disruption in normal operations of the Data Centre, System or Application services.

(g) “Error” in data digitization or data migration exercise, refers to the mistakes made intentional/ unintentional by SI which may or

may not change the actual meaning of the subject.


3 Interpretations:

(a) The business hours are 9:30 AM to 6:30 PM on all working days (Mon-Sat) excluding Public Holidays or any other Holidays

observed by the State. The SI however recognizes the fact that the State Government offices will require to work beyond the

business hours on need basis.

(b) "Non-Business Hours" shall mean hours excluding “Business Hours”.

(c) 12X7 shall mean hours between 8:30AM -8.30 PM on all days of the week.

(d) The availability for a cluster will be the average of availability computed across all the servers in a cluster, rather than on individual

servers. However, non compliance with performance parameters for infrastructure and system / service degradation will be

considered for downtime calculation.

(e) The SLA parameters shall be monitored on a monthly basis as per the individual SLA parameter requirements. However, if the

performance of the system/services is degraded significantly at any given point in time during the contract and if the immediate

measures are not implemented and issues are not rectified to the complete satisfaction of the State Government, then the State

Government will have the right to take appropriate disciplinary actions including termination of the contract.

(f) A Service Level violation will occur if the SI fails to meet Minimum Service Levels, as measured on a half yearly basis, for a

particular Service Level. Overall Availability and Performance Measurements will be on a monthly basis for the purpose of Service

Level reporting. An “Availability and Performance Report” will be provided by the SI on monthly basis in the suggested format

and a review shall be conducted based on this report. A monthly Availability and Performance Report shall be provided to at the

end of every month containing the summary of all incidents reported and associated SI performance measurement for that period.

The monthly Availability and Performance Report will be deemed to be accepted by the State Government upon review and signoff

by both SI and the State Government. Where required, some of the Service Levels will be assessed through audits or reports e.g.

utilization reports, measurements reports, etc., as appropriate to be provided by the SI on a monthly basis, in the formats as

required by audit will need to be provided by the SI. Audits will normally be done on regular basis or as required by the State

Government and will be performed by the State Government or the State Government appointed third party agencies.

(g) EMS system as specified in this RFP shall play a critical role in monitoring the SLA compliance and hence will have to be

customized accordingly. The 3rd party testing and audit of the system shall put sufficient emphasis on ensuring the capability of

EMS system to capture SLA compliance correctly and as specified in this RFP. The selected System Integrator (SI) must deploy EMS

tool and develop additional scripts (if required) for capturing the required data for SLA report generation in automated way. This

tool should generate the SLA Monitoring report in the end of every month which is to be shared with the State Government on a

monthly basis. The tool should also be capable of generating SLA reports for a half-year. The State Government will audit the tool

and the scripts on a regular basis. SPMC shall assess the EMS requirements and include the same in the RFP.


(h) The Post Implementation SLAs will prevail from the start of the Operations and Maintenance Phase. However, SLAs will be subject

to being redefined, to the extent necessitated by field experience and the developments of technology practices globally. The SLAs

may be reviewed on an annual/bi-annual basis as the State Government decides after taking the advice of the SI and other agencies.

All the changes would be made by the State Government in consultation with the SI.

(i) The SI is expected to provide the following service levels. In case these service levels cannot be achieved at service levels defined in

the tables below, it shall result in a breach of contract and invoke the penalty clause. Payments to the SI are linked to the compliance

with the SLA metrics laid down in the tables below. The penalties will be computed and calculated as per the computation

explained in this Annexure. During the contract period, it is envisaged that there could be changes to the SLA, in terms of addition,

alteration or deletion of certain parameters, based on mutual consent of both the parties i.e. the State Government and SI.

(j) Following tables outlines the key service level requirements for the system, which needs be ensured by the SI during the operations

and maintenance period. These requirements shall be strictly imposed and either the State Government or a third party

audit/certification agency shall be deployed for certifying the performance of the SI against the target performance metrics as

outlined in the tables below.

4 Service Level Agreements (SLAs)

4.1 The SLAs for various components of the project are given below.Data Digitization Activities

S. No. SLA Terms Description

1. % Accuracy ITG officials and concerned line department officials will physically verify the digitized

records submitted by the SI vendor against the original records and will identify the

erroneous fields in each record. The % accuracy for each batch will be calculated as follows:

Total no. of erroneous fields in the batch - X

Total no. of records in the batch - Y

Field per record - N

Accuracy per batch (%) = (X*100)/(Y*N)

2. Digitization Cost Digitization cost = A*Y, where “A” is the rate per record digitized and Y is the total no. of

records in the batch.


Service

Category

Service

Level

Title /

Objective

Definition Data

Capture

Measureme

nt Interval

Reporting

Period

Hours

of

Suppor

t

Target

Service

Level

Minimu

m

Service

Level

Service

Level

Dependency

Increase

d Impact

Severity

Weight

Data

Accuracy

Accuracy

of the data

digitized

by the SI

vendor

when

compared

against the

original

records

The ratio

between

the total

no. error

free of

records in

a batch of

data that

were

successfull

y digitized

to the total

no. of

records in

that batch

of data

ITG‟s

appointed

shall take

physical

count of

data that

was

migrated

successfull

y into the

new

system as

compared

to that

which

existed in

the old

legacy

source

Weekly Fortnightl

y

56x2 > 90% > 80% Completenes

s and

integrity of

source data

To be

base

lined for

first 2

weeks

using

time and

motion

study on

the effort

made.

50% of

Data

Digitizatio

n Cost.

Data Entry

Completio

n Time

Timeliness

for

completio

n of data

entry

Actual No.

of pages of

A4 size

documents

keyed into

the system

vis-à-vis

Average

Number of

pages

actually

keyed into

the system

by the

Fortnightly Fortnightl

y

NA

(Data

capture

at the

end of

each

day for

12 pages

per

operator

hour

with an

average

of 40%

8 pages

per

operator

hour

Up time of

Data entry

systems.

To be

baseline

d for

first two

months

for a

steady

20% of

Data

Digitizatio

n Cost for

per page

fall in data

entry


Service

Category

Service

Level

Title /

Objective

Definition Data

Capture

Measureme

nt Interval

Reporting

Period

Hours

of

Suppor

t

Target

Service

Level

Minimu

m

Service

Level

Service

Level

Dependency

Increase

d Impact

Severity

Weight

the agreed

rate of data

entry

group of

data entry

operators

per

manhour

of data

entry

operation.

number

of

operato

r hours

in the

day.

data

density

per

page.

team of

oeprator

s to

arrive at

the

average

operator

hour

data

entry

speed.

speed

below 8

pages per

operator

hour

averaged

over three

months

period.

Data

Digitizatio

n

Completio

n Time

Timeliness

for

completio

n of data

digitizatio

n

Actual No.

of pages of

documents

scanned

into the

system vis-

à-vis the

agreed rate

of page

scanning

per

operator

hour

Average

Number of

pages

actually

scanned

into the

system by

the group

of data

scanning

operators

per

manhour

of data

scanning

operation.


y

NA

(Data

capture

at the

end of

each

day for

number

of

operato

r hours

in the

day.

55 pages

per

operator

hour

with an

average

of 40%

data

density

per

page.

40 pages

per

operator

hour

Up time of

Data

scanning

systems.

To be

baseline

d for

first two

months

for a

steady

team of

oeprator

s to

arrive at

the

average

operator

hour

data

20% of

Data

Digitizatio

n Cost for

per page

fall in data

entry

speed

below 40

pages per

operator

hour

averaged

over three

months

period.


Service

Category

Service

Level

Title /

Objective

Definition Data

Capture

Measureme

nt Interval

Reporting

Period

Hours

of

Suppor

t

Target

Service

Level

Minimu

m

Service

Level

Service

Level

Dependency

Increase

d Impact

Severity

Weight

scanning

speed.

Data

Migration

Completio

n Time

Timeliness

for

completio

n of data

migration

into the e-

District

database.

Actual No.

of

Megabytes

of data

migrated

into the

system vis-

à-vis the

agreed rate

of data

migration

per

operator

hour

Average

Number of

pages

actually

migrated

into the

system by

the group

of data

migration

operators

per

manhour

of data

migration

operation.


y

NA

(Data

capture

at the

end of

each

day for

number

of

operato

r hours

in the

day.

5 GB of

data

migrate

d per

operator

hour..

2 GB of

data per

operator

hour

Up time of

Data

Migration

systems.

To be

baseline

d for

first two

months

for a

steady

team of

oeprator

s to

arrive at

the

average

operator

hour

data

migratio

n speed.

20% of

Data

Digitizatio

n Cost for

per GB fall

in data

migration

speed

below 5

GB per

operator

hour

averaged

over three

months

period.

Please note:

The maximum penality under this shall be to the extent of the 15% of the contract value

Accuracy of less than 90% will be considered as the Breach of the Agreement and ITG reserves the Right to terminate the agreement.

In all such cases, where the accuracy is below 100%, the SI will be responsible to carry out corrections with no additional cost to ITG.


4.2 Supply, Installation & Commissioning Phase

Service

Category

Service

Level Title

/ Objective

Definition Data

Capture

Measurem

ent

Interval

Reporting

Period

Hour

s of

Supp

ort

Target

Service

Level

Minimum

Service

Level

Service

Level

Dependen

cy

Increas

ed

Impact

Severity

Weight

Supply,

installation

and

Commissio

ning of

hardware –

SDC

Supply,

installation

and

Commissio

ning of

hardware –

SDC

The

bidder is

required

to

supply,

install &

commissi

on the

hardwar

e at SDC

Sign-off

by ITG or

its

appointed

representa

tive.

On the

scheduled

date of

commissio

ning.

At the end

of the

scheduled

date of

commissio

ning.

NA As per

agreed

commissio

ning

schedule.

One day

delay

permitted

per INR 1

crore of

value of

hardware

to be

commissio

ned.

Availabi

lity of

SDC

Necessar

y

approval

from the

State

Govern

ment

NA

INR

100,000 per

INR 1

crore of

value of

hardware

to be

commissio

ned, for

every

week‟s

delay

beyond the

agreed

commissio

ning

schedule.

Supply,

installation

and

Commissio

Supply,

installation

and

Commissio

The

bidder is

required

to

Sign-off

by ITG or

its

appointed

On the

scheduled

date of

commissio

At the end

of the

scheduled

date of

NA As per

agreed

commissio

ning

Two days

delay

permitted

per INR 1

Readines

s of Field

Office

for

NA INR 5,000

per INR

500,000 of

value of


Service

Category

Service

Level Title

/ Objective

Definition Data

Capture

Measurem

ent

Interval

Reporting

Period

Hour

s of

Supp

ort

Target

Service

Level

Minimum

Service

Level

Service

Level

Dependen

cy

Increas

ed

Impact

Severity

Weight

ning of

hardware –

Field

Offices

ning of all

identified

hardware

at each of

the Field

Offices

supply,

install &

commissi

on all the

identified

hardware

at each

designate

d field

office

locations.

representa

tive.

ning. commissio

ning.

schedule. crore of

value of

hardware

to be

commissio

ned.

installati

on and

commiss

ioning of

hardwar

e.

Necessar

y

approval

from the

State

Govern

ment

hardware

to be

commissio

ned, for

every

fortnight‟s

delay for

every field

office

location

beyond the

agreed

commissio

ning

schedule

for that

field office

location.

All the

identified

hardware

for the

designated

office

location

should be


Service

Category

Service

Level Title

/ Objective

Definition Data

Capture

Measurem

ent

Interval

Reporting

Period

Hour

s of

Supp

ort

Target

Service

Level

Minimum

Service

Level

Service

Level

Dependen

cy

Increas

ed

Impact

Severity

Weight

commissio

ned. The

penalty

will be

levied even

if one of

the

identified

hardware

item is not

commissio

ned at the

designated

field office

location.

Supply,

installation

and

Commissio

ning of

Network

connectivit

y including

LAN –

Field

Offices

Supply,

installation

and

Commissio

ning of

Network

Connectivit

y including

LAN at

each of the

Field

Offices

The

bidder is

required

to

supply,

install &

commissi

on the

network

connectiv

ity

between

Sign-off

by ITG or

its

appointed

representa

tive.

On the

scheduled

date of

commissio

ning.

At the end

of the

scheduled

date of

commissio

ning.

NA As per

agreed

commissio

ning

schedule.

Two days

delay

permitted

per INR

50,000 of

value of

contract

for

network

connectivit

y for the

entire

Availabi

lity of

network

PoP to

connect

to SDC

Necessar

y

approval

from the

State

Govern

NA INR 10,000

per INR

500,000 of

value of

hardware

to be

commissio

ned, for

every

fortnight‟s

delay for

every field


Service

Category

Service

Level Title

/ Objective

Definition Data

Capture

Measurem

ent

Interval

Reporting

Period

Hour

s of

Supp

ort

Target

Service

Level

Minimum

Service

Level

Service

Level

Dependen

cy

Increas

ed

Impact

Severity

Weight

the

designate

d office

location

and the

nearest

SWAN

PoP as

well as

supply,

installati

on and

commissi

oning of

LAN at

each

designate

d field

office

locations.

district. ment

office

location

beyond the

agreed

commissio

ning

schedule

for

network

connectivit

y with

nearest

SWAN

PoP.

INR 10,000

per INR

500,000 of

value of

hardware

to be

commissio

ned, for

every

fortnight‟s

delay for

every field


Service

Category

Service

Level Title

/ Objective

Definition Data

Capture

Measurem

ent

Interval

Reporting

Period

Hour

s of

Supp

ort

Target

Service

Level

Minimum

Service

Level

Service

Level

Dependen

cy

Increas

ed

Impact

Severity

Weight

office

location

beyond the

agreed

commissio

ning

schedule

for LAN.

4.3 Operation and Maintenance (O&M) Support

S.

No. SLA Terms Description

1. System Uptime - Time for which user is able to access the applications, website and other

components of the IT solution during the working hours. The system

can be down due to any of the reasons including failure of hardware,

network, system software, application etc.

- Scheduled downtime for example, backup time, batch processing time,

routine maintenance time will not be considered while evaluating the

system uptime. However, the selected SI will be required to schedule

such downtime with prior approval of ITG. The selected SI will plan

scheduled downtime outside working time. In exceptional

circumstances, ITG may allow the SI to plan scheduled downtime in the

working hours.

2. Bugs / Issues in the Application Software / Critical bugs / issues – Bugs / issues affecting more than one division


S.

No. SLA Terms Description

Hardware device / Network Equipment or more than one user in a division,

Non-critical bugs / issues – Bugs / issues affecting at most one user in a

division.

Service

Category

Service

Level Title

/

Objective

Definition Data

Capture

Measureme

nt Interval

Reportin

g Period

Hours

of

Suppo

rt

Target

Service

Level

Minimu

m

Service

Level

Service

Level

Dependen

cy

Increase

d

Impact

Severity

Weight

System

Uptime

and

Performan

ce - SDC

System

uptime

and

performan

ce of the

system -

SDC

Time for

which user

is able to

access the

applicatio

ns, website

and other

componen

ts of the IT

solution

during the

working

hours. The

system can

be down

due to any

of the

reasons

including

failure of

hardware,

No. of

recorded

hours on

server logs

of

uninterrupt

ed usage of

the system

by users

during total

working

hours for

the week.

Weekly Weekly 24x7 99.9% 99% Power

Backup

Upgrade

s

System

Restores

To be

base

lined for

first 6

months

INR 300,000

per month

for every

drop in

percentage

point of

uptime

below 99.5 %

[The non

availability

for

application

service,

website

measured on

monthly

basis and

excluding

the

scheduled


Service

Category

Service

Level Title

/

Objective

Definition Data

Capture

Measureme

nt Interval

Reportin

g Period

Hours

of

Suppo

rt

Target

Service

Level

Minimu

m

Service

Level

Service

Level

Dependen

cy

Increase

d

Impact

Severity

Weight

network,

system

software,

applicatio

n etc.

Scheduled

downtime

for

example,

backup

time, batch

processing

time,

routine

maintenan

ce time

will not be

considered

while

evaluating

the system

uptime.

However,

the

selected SI

will be

maintenance

shutdown.

Performance

of system

refers to the

proper and

timely

functioning

of the

system‟s

functionaliti

es. The

applications

should be

available

and

performing

as per

functionaliti

es]


Service

Category

Service

Level Title

/

Objective

Definition Data

Capture

Measureme

nt Interval

Reportin

g Period

Hours

of

Suppo

rt

Target

Service

Level

Minimu

m

Service

Level

Service

Level

Dependen

cy

Increase

d

Impact

Severity

Weight

required to

schedule

such

downtime

with prior

approval

of ITG.

The

selected SI

vendor

will plan

scheduled

downtime

outside

working

time. In

exceptiona

l

circumstan

ces, ITG

may allow

the SI

vendor to

plan

scheduled

downtime

in the


Service

Category

Service

Level Title

/

Objective

Definition Data

Capture

Measureme

nt Interval

Reportin

g Period

Hours

of

Suppo

rt

Target

Service

Level

Minimu

m

Service

Level

Service

Level

Dependen

cy

Increase

d

Impact

Severity

Weight

working

hours.

System

Uptime

and

Performan

ce – Field

Offices

System

uptime

and

performan

ce of the

system –

Field

Offices

Availability

of each

hardware &

peripheral

at each of

the

designated

field office

location

No. of

recorded

hours on

server logs

of

uninterrupt

ed usage of

the

department

specific

systems by

user

department

s during

total

working

hours for

the week.

Monthly Monthly 12 hrs

x 6

days

(8 AM

to 8

PM)

>96% >92% Power

Backup

To be

base

lined for

first 6

months

INR 1500 per

instance of

violation for

a drop in

uptime

between

<92% and

>=90%.

Additional

INR 1500

per instance

of violation

for every 5%

drop in

percentage

point of

uptime

below 90%.

Network

Availabilit

y

Average

Network

Availabilit

y between

each of the

designated

The total

number of

hours the

network

was

available

Recording

the no. of

hours of

network

outage

during

Monthly Monthly 12 hrs

x 6

days

(8 AM

to 8

PM)

> 99% > 95% Telepho

ne

Exchang

e Line

GBBN

To be

base

lined for

first 6

months

INR 50,000

per month

for every

drop in

percentage

point of


Service

Category

Service

Level Title

/

Objective

Definition Data

Capture

Measureme

nt Interval

Reportin

g Period

Hours

of

Suppo

rt

Target

Service

Level

Minimu

m

Service

Level

Service

Level

Dependen

cy

Increase

d

Impact

Severity

Weight

office

location

and the

nearest

GBBN

PoP.

during the

working

hours.

working

hours.

uptime

below 98%

Issue

Resolution

Efficiency

– Severity

1 Issues

Resolution

time for

bugs /

issues in

the

application

Complete

System

Down/No

Application

available at

data centre

Issue Sev-1

Response

Time,

Issue Sev-1

Resolution

Time

Response

Time –

From the

time of

reporting of

Sev-1 Issue,

Resolution

Time –

From Time

of

Reporting

of Sev-1

Issue

As and

when

Issue

comes

up.

24x7 Response

Time =

15

minutes,

Resolutio

n Time =

1 hour

Response

Time =

30

minutes,

Resolutio

n Time =

120

minutes

Nil To be

base-

lined

during

the first

year of

operatio

n.

INR 50,000

per 30

minutes

delay in

response

time.

INR 50,000

per 30

minutes

delay in

resolution

time.

Issue

Resolution

Efficiency

– Severity

2 Issues

Resolution

time for

bugs /

issues in

the

application

s

System is

not

operating at

full capacity

but is still

operational.

Issue Sev-2

Response

Time,

Issue Sev-2

Resolution

Time

Response

Time –

From the

time of

reporting of

Sev-2 Issue,

Resolution

Time –

As and

when

Issue

comes

up.

24x7 Response

Time =

30

minutes,

Resolutio

n Time =

2 hour

Response

Time =

30

minutes,

Resolutio

n Time =

4 hours

Nil To be

base-

lined

during

the first

year of

operatio

n.

INR 1

5,000 per 30

minutes

delay in

response

time.

INR 5,000

per 30


Service

Category

Service

Level Title

/

Objective

Definition Data

Capture

Measureme

nt Interval

Reportin

g Period

Hours

of

Suppo

rt

Target

Service

Level

Minimu

m

Service

Level

Service

Level

Dependen

cy

Increase

d

Impact

Severity

Weight

From Time

of

Reporting

of Sev-2

Issue

minutes

delay in

resolution

time.

Issue

Resolution

Efficiency

– Severity

3 Issues

Resolution

time for

bugs /

issues in

the

application

System

Operation is

normal but

needs

improveme

nt.

Issue Sev-3

Response

Time,

Issue Sev-3

Resolution

Time

Response

Time –

From the

time of

reporting of

Sev-3 Issue,

Resolution

Time –

From Time

of

Reporting

of Sev-2

Issue

As and

when

Issue

comes

up.

24x7 Response

Time = 3

hours,

Resolutio

n Time =

6 hours

Response

Time = 6

hours,

Resolutio

n Time =

12 hours

Nil To be

base-

lined

during

the first

year of

operatio

n.

INR 1,000

per hour

delay in for

response

time.

INR 1,000

per hour

delay in

resolution

time.

Please note:

Following conditions will be considered as the Breach of the Agreement in case of O&M Phase and in any of the following conditions ITG

reserves the Right to terminate the agreement

o System uptime at SDC of less than 98% continuously for a quarter;

o More than 3 incidents of not resolving the bugs / issues within the defined time limits in a quarter;

o Average page loading time for application & reports to be more than 20 seconds evaluated for a quarter;


The SLA measurement tool designed & developed by Bidder shall be tested and certified for its accuracy, reliability and

completeness by a 3rd Party before it is deployed.

4.4 Training and Change Management

Service

Category

Service

Level Title

/ Objective

Definitio

n

Data

Capture

Measureme

nt Interval

Reportin

g Period

Hours

of

Support

Target

Service

Level

Minimu

m

Service

Level

Service Level

Dependency

Increased

Impact

Severit

y

Weight

Training

Satisfactio

n

Satisfaction

level of the

training

sessions

conducted

by vendor

for staff

members

&

stakeholde

rs

The

feedback

shall be

received

by the

officials

of ITG

after each

training

session.

ITG may

decide to

use the

SLA in

case

insufficie

nt

training

sessions

are

conducte

d by the

Feedback

ratings

received

from

Training

participant

s, no. of

participant

s and no.

of

Trainings

delivered

Monthly Monthly No. of

Training

hours

delivere

d

Feedbac

k

ratings

> 8

Feedback

ratings >

7

Participant

attendance/turn

out

Availability of

ITG committed

Training facility

> 10

trained

participan

ts being

able to

trained

other

members

of staff in

a period of

1 month

20% of

the per

person

cost for

that

type of

trainin

g.


Service

Category

Service

Level Title

/ Objective

Definitio

n

Data

Capture

Measureme

nt Interval

Reportin

g Period

Hours

of

Support

Target

Service

Level

Minimu

m

Service

Level

Service Level

Dependency

Increased

Impact

Severit

y

Weight

SI

vendor.

Please Note:

Feedback rating of less than 6 by 25% of the trainees of a batch will be considered as the Breach of the Agreement and ITG reserves the Right to

terminate the agreement

The bidder will be solely responsible for conducting additional training sessions for the staff members providing the rating less than 6.

4.5 Calculating Penalties as Service Credits

4.5.1 Service Credits and Amount at Risk

Service Credits are calculated as provided below, but the aggregate amount of such Service Credits paid or credited for any given month

will not exceed the following limitations (“Amount at Risk”):

For Service Level Failures and Service Credits within a Service Category, twelve percent (12%) of Fees for Services (excluding pass-

through expenses and other expense reimbursements, if any) within that Service Category during the relevant month.

For Service Level Failures in all Service Categories, ten percent (10%) of Fees for Services (excluding pass-through expenses and

other expense reimbursements, if any) within all Service Categories during the relevant month.

Service Credit amounts in excess of the foregoing limitations do not carry forward into subsequent months or measurement periods.

Service Credits will be applied to the invoice in the month immediately following the Service Level Failure(s) or paid in cash for the final

month when the Agreement expires or terminates.


4.5.1.1 Reporting of Service Levels and Credits

Service Level performance and (if applicable) Service Credits are measured and reported monthly (or at other mutually agreed intervals) in

Service Provider‟s regular reports. The monthly reports shall also describe all failures to achieve Service Levels for the month, reasons for

any excused failures, results of root cause analyses, and corrective action proposed and taken to prevent recurrence of failures to meet

Service Levels.

4.5.1.2 Calculation of Service Credits

Service Credits are calculated as follows: the Amount at Risk for the relevant Service Category times the relevant Severity Weight. Service

Credits for Increased Impact Failures shall be two hundred percent (200%) of the amount otherwise payable for less severe Failures.

Example

Minimum Service Level Failure

Assume that:

Service Provider misses the Minimum Service Level Application uptime.

Failure is unexcused.

Monthly Fees for the relevant Service Category total INR 100,000 (in case there is a consolidated monthly fee payable to the vendor,

then the entire fee has to be broken up into various elements and divided for each SLA, without exceeding 100%)

Amount at Risk for Service Category is INR 12,000.

Severity Weight is 30%.

Credit Calculation:

Service Credit = Amount at Risk times Severity Weight

INR 3,600 = INR 12,000 x 30%

Increased Impact Failure


Same assumptions as above, except

Performance below “Increased Impact” level.

Credit Calculation:

Increased Impact Service Credit = Amount at Risk times Severity Weight times 200%

INR 7,200 = [INR 12,000 x 30%] x 2

4.5.2 Unacceptable Service

The following Service Level Failures or combinations of Service Level Failures constitute Unacceptable Service, and grounds for

termination of the Agreement, in whole or in part, if Service Provider becomes obligated to pay the following amounts of Service Credits

(whether or not such Credits are actually collected):

One Hundred Percent (100%) of the Amount at Risk for any two Service Categories within any rolling period of twelve (12) months

or less; or

Seventy-five percent (75%) of the Amount at Risk for the Agreement as a whole within any rolling period of twelve (12) months or

less

Identification of the foregoing circumstances as Unacceptable Service (and subsequent identification of any other circumstances as

Unacceptable Service) are without prejudice to contentions that other or different circumstances, individual Service Level Failures, or

combinations of Service Level Failures may also, by themselves or in combination with other facts or circumstances, constitute material

breach of the Agreement, and grounds for termination.

4.5.3 Continuous Improvement

Minimum Service Levels and Increased Impact Service Levels will be modified at twelve (12) month intervals for each Service Category

promptly following the anniversary of the date related Service Levels were first effective. Upon Government entity/department‟s request,

(i) Minimum Service Levels may be increased to the average figure for the preceding six (6) months; and Increased Impact Service Levels


may be increased to the second lowest measurement within the preceding six (6) months, provided that neither increase shall exceed five

percent (5%) of the difference between one hundred percent (100%) and the relevant Minimum or Increased Impact Service Level then in

effect.

4.5.4 General Provisions

4.5.4.1 Maximum Service Credits

The maximum amount payable as Service Credits for any single month shall not exceed the Amounts at Risk (but this limitation does not

limit Government entity/department‟s right to recover damages for material breach, or other remedies, subject to the notice, cure periods,

limitations of liability and other applicable provisions of the Agreement).

4.5.4.2 Waivers

Government entity/department may waive any Service Level Failure or Service Credit, but no such waiver shall be binding or effective

unless given in writing, and no such waiver shall constitute a continuing waiver of similar or other such Service Level Failures or other

breaches of the Agreement. Government entity/department may at any time direct future compliance with any waived requirement.