FUNCTIONAL REQUIREMENTS DOCUMENT

DPC: Funds Tracking Software

Collector Office, Palghar

 FUNCTIONAL REQUIREMENTS DOCUMENT

INDEX

1. General

1.1 Project Description

1.2 Points of Contact

1.3 Document References

2. System Overview and Requirements

2.1 Functional Requirements

2.2 Functional Specifications

2.3 Positioning with existing system

3. Operational Requirements

4. Requirements Traceability Matrix

5. Deployment, Training and Support

6. Future Scope

7. Glossary

7.1
 FUNCTIONAL REQUIREMENTS DOCUMENT

1. GENERAL
1.1 Project Description

1.1.1 Background
The District Planning Committee (DPC) comprising of government administration and elected
representatives is empowered to suggest various developmental works for the district. The
committee regularly convenes to discuss and decide the efficient allocation of resources given to
the Palghar district by Maharashtra government. The Member Secretary of DPC is the District
Collector who is authorized to receive the funds. The Member Secretary gives the administrative
approval and directs the District Planning Officer (DPO) of the Planning Department to disburse
the requisite funds to various agencies to carry out these works. The funds are in turn spent by
the agencies to a) direct beneficiaries or via b) contractors who carry out the work.

1.1.2 Purpose
Palghar District receives funds from the Maharashtra Government from 2 separate plans in a
given fiscal year:
A. District Annual Plan (DAP)
B. Tribal Sub-Plan (TSP)
Besides these, every elected representative MP and MLA’s have their own funds, i.e. MPLADS
and MLALADS which are used for district development.
The administrative approval of all these works is given by District Collector.

DPO, Planning
D.A.P
Dept.

PO, Tribal
Development Dept. T.S.P Scrutinising
proposals and
releasing funds

DPO, Planning MLALADS/MP

Dept. LADS
 FUNCTIONAL REQUIREMENTS DOCUMENT

 Due to the existence of these separate plans and the scrutiny of their work proposals by
separate agencies, there exists an incoherency in carrying out developmental works.
Often, the same work (for ex. Building of the same road) is carried out year after year by
both agencies. This results in duplication of work and inefficient allocation of resources.
 Further, there is an absence of a central digital database repository where all works
carried out by district administration can be searched and verified for duplication prior to
accepting a new proposal.
 The administration also lacks a mechanism to track the progress of work to be carried out
from the proposal stage, administrative approval, tender date, work order date, work-in-
progress, percentage/amount of funds transferred to completion with photos.

Therefore, the underlying purpose of the web application is to keep a track of the following:
1. Works undertaken during a fiscal year
2. Plan used to undertake the work
3. Progress of the proposal
4. Progress of the work with photographs
5. Various Reports for customized data mining, trend analysis and data driven decisions

1.1.3 Assumptions and Constraints

It is assumed that all stakeholders in the system viz. Collector’s Office, District Planning Office,
Tribal Development Department and various agencies have atleast one computer and access to
internet connection. Absence of this, may lead to delayed data entry or inability to use the
software.
A limitation of the software is that it would not be an end-to-end paperless solution for
processing work proposals, scrutiny and administrative approval. This feature could be included
in later versions.

1.2 Points of Contact

Following are the major stakeholders for the software:
 District Collector, Palghar
 District Planning Officer (DPO)
 District Informatics Officer, NIC
 Mr. Aditya Bhide, Fellow – Hon’ Chief Minister’s War Room

1.3 Document References

The following references are available:
1. Spreadsheet that enumerates data columns and their inter-dependent relationship
2. User Interface template files
3. Spreadsheet containing master data of Palghar District
 FUNCTIONAL REQUIREMENTS DOCUMENT

2 SYSTEM OVERVIEW & REQUIREMENTS

2.1 Functional Requirements
The software functionalities have been broadly categorized into 3 heads:
1. Create and Store Data
2. Update Data and Transfer Funds
3. Data Representation and Analytics

CREATE
DATA

UPDATE
DATA AND
TRANSFER
FUNDS

DATA-
DRIVEN
DECISIONS

2.1.1 Create and Store Data

The software’s major purpose shall be to function as a data repository. It will be a digital
database for recording developmental works in a given fiscal year.
Data is created and stored by two kinds of users:
A. DPO/PO
B. Agency
C. Citizen

A. DPO/PO:
This is the first step in the lifecycle of a work. After the work proposal on paper is
prepared and scrutinized, the administrative approval is given by the concerned officer.
Post this, the DPO (in case of DAP) or PO (in case of TSP) would create the work in the
software where an automatic ID would be created for the entry. The details entered at this
stage are given below:
1. Financial Year (by default)
2. Plan (dropdown)
 FUNCTIONAL REQUIREMENTS DOCUMENT

3. Sector (dropdown)
4. Subsector (dropdown)
5. Scheme (dropdown)
6. Member (if applicable-dropdown)
7. Location (District/Taluka/Village-dropdown)
8. Agency to be assigned (dropdown)
9. Work Name (textbox)
10. Work Type (dropdown)
11. Remarks (textbox)
12. Technical Sanction (Officer/Date-dropdown)
13. Administrative Approval (Officer/Date-dropdown)
14. Estimated Cost (numeric)

Sample Screenshots have been attached.

 FUNCTIONAL REQUIREMENTS DOCUMENT

B. Agency:
After the agency is assigned the work. The agency would have 3 tabs:
a. Assigned Works
This tab would contain a list of all works that the agency is assigned by the
DPO/PO but details are yet to be filled in. After selecting the relevant work, the
agency would fill in the following details:
1. Tender call date (dropdown)
2. Tender opened date (dropdown)
3. Tender selected date (dropdown)
4. Tender value (numeric)
5. Work order date (dropdown)
6. Work remarks (textbox)
7. Work Status – Yet to Start/ In Progress/ Completed*
8. Work Photos (if application)
9. Release Funds (numeric, if applicable)
On clicking save, the work would now automatically migrate from “Assigned
Works” tab to the “Works in Progress” tab.
If work status is chosen as “completed”, then the work would migrate to
“Completed Works” tab.
b. Works-In-Progress
The Works-In-Progress tab contains the list of works that have been assigned and
filled in by the agency. Subsequent data updation in the form of work photos,
status and funds transfer is done by clicking on the works.
c. Completed Works:
This tab contains a list of all works that the agency has completed.
 FUNCTIONAL REQUIREMENTS DOCUMENT

C. Citizen:
The Citizen is the third entity that plays a role in adding data into the database. The
citizen user is authorized to give suggestion for works.
A sample screenshot has been attached:

2.1.2 Update Data and Transfer Funds

Once a work is created, it may take considerable amount of time (few days to a few months).
During this period, the developments of the work can be continuously updated into the work
sheet. These can be tender details, work order details, status etc. It is also mandatory to upload 3
photos (before, in-progress, completed) of construction works.

The funds are disbursed to the contractors during the period of this work. This can be lump sum
payment or in stages. Therefore, the agencies need the flexibility to log in and enter the funds to
be released for a particular work. The software would need to record the timestamp of such
releases as well. Following is the physical flow of funds that needs to be accounted for in the
software:

DPO/PO AGENCY
CONTRACTOR
Budgeted Allocation Funds Received

Funds Released Funds Spent

Funds Pending Funds Pending

 FUNCTIONAL REQUIREMENTS DOCUMENT

Sample Screenshots have been attached:

2.1.3 Data Representation and Analytics

The third major functionality of the software shall be to use this rich repository of data to enable
the DPC (District Planning Committee) to make better administrative decisions.
This module forms the crux of the software and is the underlying purpose of putting this system
in place. This module can be broken down into 2 components:
A. Dashboard
B. Reports

A. Dashboard
The Dashboard would be the first page that any user (Admin, System Admin, Elected
Member, DPO/PO, and Citizen) would view on login. It would contain various kinds of
data representation tools such as Bar charts, Pie Diagrams etc. which would give the
user an overall picture of the status of works, funds and performance of the
administration.
 FUNCTIONAL REQUIREMENTS DOCUMENT

Following are a few sample charts that should be used to illustrate data:

Agency-wise Fund Performance

140

120

100

80

60

40

20

0
PWD Agri cul ture Forest Dept Heal th Dept
Al l ocated Approved Transferred Spent

Plan-wise Fund Performance

TSP

DAP

0 20 40 60 80 100 120
Spent Rel ea s ed Approved Al l ocated
 FUNCTIONAL REQUIREMENTS DOCUMENT

Google Maps feature should be used to zoom in and view work details in any location of the
district. This could be zoomed in at districts, talukas and villages.

Created Works MLA/MP Funds

30.00%

70.00%

Works yet to sta rt Work In Progres s

Works Compl eted Funds Us ed Funds Remai ni ng

Following attached is a sample screenshot:

 FUNCTIONAL REQUIREMENTS DOCUMENT

The Dashboard should be customized to each user’s primary requirement from the
software. Building data visualization charts would be an iterative process since
requirements would keep arising once the software is deployed, implemented and used.

B. Reports
The reports section would be the second arm of making data driven decisions. As
compared to the Dashboard which would give the scenario in a nutshell, the reports
page should offer a detailed list of all works. The ability to query works by means of
using filters is crucial.
Following are the filters:
 Financial Year
 Taluka, Village, Hamlet (Pada)
 Plan, Sector, Sub-Sector, Scheme
 Agency
 Member (if applicable)
 Cost (cost brackets can be created)
 FUNCTIONAL REQUIREMENTS DOCUMENT

 Time (from: date to: date)

A sample screenshot has been attached:

On clicking on a particular work, another tab should open which would show detailed sheet of
the work. Milestones could be assigned (10%, 20%, 30%, 50 %,…) with a bar showing progress
at a glimpse.

0% 50% 75% 100%

25%

Besides these two sub-modules, viewing citizen suggestions also forms a part of data driven
decision.
A sample screenshot of the page is attached:
 FUNCTIONAL REQUIREMENTS DOCUMENT

Both, the reports sheet and the citizen suggestions should be exportable in Microsoft Excel
format.
 FUNCTIONAL REQUIREMENTS DOCUMENT

2.2 Functional Specifications

2.1.1 UML Diagrams

2.1.1.1 Entity-Relationship Diagram

2.1.1.2 Use Case Diagram

 FUNCTIONAL REQUIREMENTS DOCUMENT

2.1.1.3 Activity Diagram:

 FUNCTIONAL REQUIREMENTS DOCUMENT

DPO/PO AGENCY

2.1.2 User Stories

2.1.2.1 As a District Collector;

User
Story ID I want to.. so that..
approve access of various users in only authorized users can get access to sensitive
1 the software data.
I can gauge administrative performance at any
view funds allocated, released and given time and drive the agencies to improve their
2 spent performance
I can keep a track of progress status, location of
works, cost, time overruns, and duplication in
various works to curtail wasteful expenditure,
view details of various works over improve accountability and transparency and aid in
3 a span of time selecting works for the future.
we can collectively select priority developmental
4 view citizen suggestion works for the district.

2.1.2.2 As an Elected Member;

 FUNCTIONAL REQUIREMENTS DOCUMENT

User
Story ID I want to.. so that..
I can understand the amount spent, remaining and
1 view my fund status act on the information
we can collectively select priority developmental
works for the district and use my funds or
2 view citizen suggestion persuade the administration
I can keep a track of progress status, location of
view details of various works works, cost and decide on works to be undertaken
3 over a span of time in the future.
I can gauge administrative performance at any
view funds allocated, released and given time and drive the agencies to improve
4 spent performance

2.1.2.3 As the DPO, Planning Department;

User
Story ID I want to.. so that..
feed in all work proposals into the I can maintain a repository to refer at any given
1 system time at the click of a button
I can prioritize and fast-track works and make
2 view citizen suggestion suggestions to the District Collector
I can better gauge administrative performance,
view funds allocated, released and drive the agencies to meet their targets and report
3 spent to the District Collector
I can easily filter the data, export and print it for
view details of various works over reporting to the District Collector saving time,
4 a span of time effort and paper otherwise required.

2.1.2.4 As an Agency;

User
Story ID I want to.. so that..
feed in all work proposals in the I can maintain a repository to refer at any given
1 system time at the click of a button.
I can keep a track of my funds, assess my
2 view funds allocated and spent performance and push contractors to execute faster
I can help select works according to location,
3 view empirical data previous history and avoid duplication.

2.1.2.5 As a Citizen;
 FUNCTIONAL REQUIREMENTS DOCUMENT

User
Story ID I want to.. so that..
I can bring to the administration’s attention,
neighborhood/individual problems that require
1 suggest works developmental and financial assistance
view details of various works I am aware of developments and can monitor the
2 carried out in my district performance of the administration.
 FUNCTIONAL REQUIREMENTS DOCUMENT

2.3 Positioning with existing system

 FUNCTIONAL REQUIREMENTS DOCUMENT

3 OPERATIONAL REQUIREMENTS

3.1 Security

3.2 Audit Trail

3.3 Data Currency

3.4 Reliability

3.5 Recoverability

3.6 System Availability

3.7 Fault Tolerance

3.8 Performance

3.9 Capacity

3.10 Data Retention

4 REQUIREMENTS TRACE ABILITY MATRIX

5 DEPLOYMENT, TRAINING AND SUPPORT

 Software deployment would have to be done at all administrative offices.
 Training would have to provided at the time of deployment.
 Post deployment, on-call and in-person support would be required.

6 FUTURE SCOPE
The software would continue to be upgraded as requirements evolve. Initially, these
requirements might be:
 Addition/deletion of form fields to be captured
 Charts, graphs and representational requirements
 Changes in the interface

Based on the success of software, its quality and support, the future scope to be implemented
in phases is as follows:

PHASE 1:
A. DAP, MLA/MP funds could first be tracked at the DPO, Planning Department.
B. TSP funds would be brought under the ambit next at the PO, Tribal Development
Department.

PHASE 2:
Mobile App to check real time figures
 FUNCTIONAL REQUIREMENTS DOCUMENT

PHASE 3:
The following could then be brought online to provide end-to-end digital solution
A. Preparing work proposals
B. Scrutinizing proposals
C. Administrative approval

PHASE 4:
The system could then be taken pan Maharashtra with monitoring at Mantralaya.

7 GLOSSARY
DPC: District Planning Committee
DPO: District Planning Officer
TSP: Tribal Sub-Plan
PO: Project Officer
TDD: Tribal Development Department