Annex 4

Terms of Reference
eCitizen
Citizen engagement system for Local communities in
BiH

Contents
Summary........................................................................................................................................... 5
Terms/Acronyms and Definitions.......................................................................................................6
Project description............................................................................................................................. 7
Purpose and structure of the document..........................................................................................7
Disclaimer...................................................................................................................................... 7
Project Scope................................................................................................................................. 7
Qualifications of potential Service Providers...................................................................................8
Project management requirements.................................................................................................8
General notes............................................................................................................................. 8
Bidder's project team.................................................................................................................. 8
Project stages and outputs.........................................................................................................9
Citizen communication platform – basic description.....................................................................10
System Actors.............................................................................................................................. 12
User Roles and Responsibilities / Authority Requirements.......................................................12
Technical and non-functional requirements......................................................................................13
Introduction.................................................................................................................................. 13
Technical requirements................................................................................................................ 13
Technology............................................................................................................................... 13
Architecture............................................................................................................................... 13
Language requirements............................................................................................................ 16
Openness and scalability.......................................................................................................... 16
Delivery form and source code.................................................................................................16
Guarantee................................................................................................................................. 16
Non-functional requirements........................................................................................................ 17
Security and data protection.....................................................................................................17
Data input................................................................................................................................. 17
Monitoring activities.................................................................................................................. 17

1
Functional requirements................................................................................................................... 18
Introduction.................................................................................................................................. 18
Logical structure........................................................................................................................... 19
Landing Page............................................................................................................................... 20
Complaints and comments to service deliveries – Web application..............................................21
Basic structure.......................................................................................................................... 21
Complaint Lifecycle................................................................................................................... 23
A. Public visitors view............................................................................................................... 24
B. Customer / Citizen view........................................................................................................26
C. Administration view.............................................................................................................. 28
D. LG employee view................................................................................................................ 29
Complaints and comments to service deliveries – Mobile application...........................................31
A. Customer / Citizen view........................................................................................................32
B. Common view....................................................................................................................... 37
City council decisions and Questions for Members of the Council................................................38
Public debates and discussions....................................................................................................50
Citizen information desk............................................................................................................... 66
System Administration module.....................................................................................................67
Reporting and analysis module....................................................................................................68
Rest Services and Interoperability................................................................................................69
Notification system....................................................................................................................... 70
Internal notifications system......................................................................................................70
External notification system......................................................................................................70
Other conditions for delivery of the solution.....................................................................................71
Services and products offered by the bidder................................................................................71
System setup and Implementation...............................................................................................72
Local administrators and LG employees training..........................................................................73
Guarantee period......................................................................................................................... 73
Maintenance after expiration of guarantee period........................................................................74

2
Summary

Financed by the Government of Switzerland and implemented by the United Nations Development
Programmed (UNDP), the Municipal Environmental and Economic Governance (MEG) Project is a
12-year intervention in the domain of local governance in Bosnia and Herzegovina. The Project’s
overall goal is defined as follows: Local governments, assigned with appropriate competences and
finances, have improved their democratic governance, apply sound public policy and performance
management systems, and provide public services in an inclusive, effective and efficient manner,
particularly those related to economic and environmental sectors.
The expected concrete improvements the Project will contribute to are clustered in three outcomes,
as follows:
 Outcome 1: Supported local governments apply effective development management
systems characterized by stronger oversight of the legislative and greater accountability
towards the citizens.
 Outcome 2: Citizens and businesses in target localities benefit from good quality services
provided by LGs in the economic and environmental sectors.
 Outcome 3: Improved regulatory framework at higher and local government levels.
The Project’s territorial focus is on the North-West part of the country (including Una-Sana Canton
and Prijedor region) and the North-East region (the wider Doboj-Tuzla area), covering 18 partner
local governments: Bihac, Bosanska Krupa, Cazin, Doboj, Gracanica, Gradacac, Gradiška, Kalesija,
Kostajnica, Kozarska Dubica, Prijedor, Prnjavor, Sanski Most, Tešanj, Teslic, Tuzla, Velika Kladuša
and Žepce.
The Project is implemented in partnership with the Ministry of Foreign Trade and Economic
Relations of Bosnia and Herzegovina, the Ministry of Development, Entrepreneurship and Crafts of
the Federation of Bosnia and Herzegovina (FBiH), the FBiH Ministry of Agriculture, Water
Management and Forestry, the Ministry for Administration and Local Self-Government of Republika
Srpska (RS), the RS Ministry of Agriculture, Forestry and Water Management and both entity
Associations of Municipalities and Cities (AMCs).

As part of the project, UNDP would like to introduce innovative ICT solutions for an effective service
delivery by local governments in Bosnia and Herzegovina. This solution would be based on a cost-
efficient yet effective software solutions (e-tools) for:
- Enhanced communication between individual local administration and its citizens,
- Enhanced communication between municipal councilors and its constituencies, and
- Centralized monitoring system that will track all the communication with the citizens (public
debates, public consultations, and other forms of civic participation).
Implementation of this solutions will enable the MEG project to assist its partner LGs to increase
their performance and should lead to an enhanced experience, i.e. more efficient, effective and
transparent, as well as fully trackable, communication between local administration and citizens, as
well as between municipal/city council and citizens.

Detailed requirements of the software solutions are described in this document.

3
Terms/Acronyms and Definitions

Term/Acronym Definition Description

LG Local Government Local community, Municipality or City
DB Database Database system in the software solution
RDBMS Relational Database System software for managing and
Management System running the Database
GAP Analysis Comparation of  "GAP analysis" has been used as a
required and means of classifying how well a product or
delivered functionality solution meets a targeted need or set of
requirements. In this case, "GAP" can be
used as a ranking of "Good", "Average" or
"Poor"
eCitizen Software solution for Short name for the software product which
citizen is described in this document
communication
Public debate Public debate about Any kind of debate, public meeting,
important discussion forum or similar activity where
projects/activities in citizens can express their opinion about
LG projects and activities in the LG
On-line debate On-line public debate Debate which is open for on-line
discussion and monitoring
Off-line debate Off-line public debate Non-virtual debate which has taken place
as a part of the LG activities. These
debates are entered in a system after
activities are finished.
Local administrator Administrator of the Administrator of the LG subsystem, which
individual LG in the is the part of the platform
system
Central Administrator of the Administrator of complete system which
administrator whole platform includes individual LG subsystems
Bidder Company which Company or organization which sends an
provides an offer offer for implementation of the system
Contractor Company to which Company of organization which is chosen
contract is assigned to implement the system

4
Project description

Purpose and structure of the document

The document „Technical specifications“ is based on an analysis of needs and legal frameworks for
implementation of a Citizen engagement system in the LGs.
This document represents complete terms of reference and serves to define the needs and manner
of implementation of an information system. Created as a universal document, it encompasses all
relevant processes in communication between citizens and LGs.
The document provides a detailed description of system modules and all other required conditions
for a successful implementation of and integral solution.

Disclaimer
Screen mockups and diagrams are only functional definition of the system modules. User interface
(UI) and user experience (UX) is not part of this document and the bidder should propose the most
appropriate interface design based on best experiences and widely accepted standards, making the
complete platform simple and efficient to use.

Reports which are defined in the document are only basic set of reports based on available data.
Bidders can offer some additional reporting functionalities as a part of their offer. During the
implementation process, users can define additional reporting requirements, again based on the
available data and processes.

The defined functional requirements could be extended during the implementation. The scope of
this extended functionality will be limited to reports and analysis dashboards and should not include
any new core functionalities which are not part of this document; however, some minor changes
and additional attributes might be included in these extended requirements.

Project Scope
The scope of the project is Implementation of citizen engagement system in 18 LGs in Bosnia and
Herzegovina, according to the technical specification and requirements defined in this document.

5
Qualifications of potential Service Providers
Apart from standard conditions defined by relevant laws in BiH, bidders should meet the following
minimum requirements:

 Full compliance with all the technical requirements, which are an integral part of this
specification.
 Successful previous implementation of minimum three different web applications (working
with DB back-end)
 Proven experience in working with Cloud platform
 Proof of relevant competence of an expert team (Including CVs, Copies of diplomas and
Certificates), consisting of a Project Manager, Business Analyst with knowledge of
business processes in LGs and at least 2 developers who are skilled in development and
implementation of solutions on a selected technical platform.
 Provision of timely support: remotely (telephone, emails, etc.) and in person at the clients'
locations

Bidders who meet all these requirements, as well as all the eligibility and qualification criteria as
specified in the Request for proposal, may be invited to present solutions and methodology
described in their proposals.

Project management requirements

General notes
Bidders will ensure regular and timely reporting on the status of implementation of this project in the
agreed time periods. The report will not be limited to software development only, but it will include
and cover all other activities performed by the bidder in relation to the project.
Bidder should ensure regular comprehensive reports as follows:

 Bi-weekly progress reporting up until the Activities 2 (a, b, c, and d) is finalized;

 Monthly progress reporting until Activities 8 a, b, and c are finalized;
 Quarterly reporting until Activity 8 d is finalized;
 Final report.

Bidder's project team

As a part of the proposal Bidder should include a detailed CVs of all the team members including
their experience relevant to this project. Detailed CVs should be delivered for the following team
members:

- Project manager / Team leader

- Business Analyst
- Developers – at least two team members

Individual team members should not be changed by the bidder unless prior approval by the MEG
project is granted in writing. The approval may be granted only based on a well-justified written
request, and provided that the adequate replacement is available and capable to fully take over
without any obstructions to the project.

6
Project stages and outputs

Following are project activities and tasks:

1. Inception report – contractor should conduct detailed assessment of the LG structure
and activities in at least 4 beneficiaries and provide for review:
a. Analysis of the current citizen engagement
b. Basic analysis of customer complaints, public debates and city council sessions
processes
c. Detailed plan of implementation
d. Description of the system with design and UX elements
2. Development of the system modules
a. Development of the system modules according to the requirements
b. Implementation of the developed modules in the Cloud platform
c. Data loading and preparing initial configuration
d. Presentation of the developed modules
3. Testing & Modification
a. Developing test plan
b. Approval of the test plan from the project team
c. Executing tests with loaded initial data and prepared configuration
d. GAP analysis
e. Modification of the system according to the test result
4. Local administrator training
a. Configuring system parameters
b. Reporting and system performance
c. Moderate the system content
5. User training
a. Create detail training plan
b. Execute training for selected user groups (number of users and groups to be arranged
with the beneficiaries)
6. Delivering Technical documentation
a. Module descriptions
b. System documentation – recommended backup procedures
c. System documentation – step-by-step instructions for system integration
7. Delivering User documentation
a. User guide
b. On-line help
8. System testing, acceptance and migration to production
a. User acceptance scripts
b. User acceptance reports
c. System modules and data migrated to production
d. Signing Handover report

7
Citizen communication platform – basic description

Citizen communication platform present unique access point for all communication needs with
regards to community issues. It connects citizens and LG administration through several application
modules which support interactive communication and information sharing.
As a citizen, one visits the LG platform on any device - on the road on the smartphone, in the sofa
on the tablet, or at work desktop. The user arrives on the LG platform and can dive into the listed
information dashboard and complaints that have already been placed. By default, a non-logged-in
user has the rights to view but cannot take action. Following are the basic description of the
application modules:
Landing page / Home page
On the landing page, a background picture of the city is shown to help boost the city’s identity
along with a title and subtitle to explain the purpose of the platform. The navigation bar should
consist of the city logo, menu items with application shortcuts and call-to-action buttons. These
elements are described in the following sections. The main feature of the landing page is to give
the user an overview of the various activities in the City and access to main functions of the
platform. Important components of the landing page are also information sections which can
contain different documents and information for the citizens, and the official documents like
Terms & Conditions, Privacy policy etc.
Registration and Login process
There are two types of login in the system: anonymous login or registered user login.
Citizen who would like to use a system in a completely anonymous way, should log-in only
clicking button ‘Anonymous’.
For the Citizens who would like to create a standard login with profile / registration, option for
new registration will offer them to enter following information:

- Username (Mandatory)
- Password (Mandatory)
- Name and Surname (Mandatory, not verified)
- Phone number (Mandatory, used for account validation)
- E-mail address (Mandatory, used for account validation)
- Choice of account validation (E-mail or SMS)
- Age (Not mandatory)
- Gender (Mandatory)
- Vulnerability group (Not mandatory, from the list of groups)

All these parameters should be configurable in Administration module and set as visible/not
visible, mandatory/not mandatory for each LG.

8
Complaints
Complaint management is one of the central and most important part of the system. This
module should provide citizens with possibility to report a problem / complaint about communal
services of the LG. Employees should be able to comment and answer to these complaints
while local administrator is moderating the complete communications. Complaints are also
visible to the public visitors of the system.
Complaints module should also be implemented as a native mobile application on Android and
IOS platform.
City Council decisions and Questions
City council decisions and Questions should be available in the system and citizens should be
able to comment and vote on council decisions and directly communicate with Members of the
Council. All citizens activities (questions/answers, comments and voting) should be visible to the
visitors of the system. City council members should also be able to comment and access some
statistic reports about citizen activities.
Public debates
Local administrator or authorized employees should be able to initiate public debate in the
system, allowing citizens to comment, vote and create additional documents and proposals
inside the debate space.
All citizens activities should be moderated by the local administrator and seen by the public
visitors. Additional statistical and analytics report should also be available.
There should be additional module for registering Public debates which were held in real
environment in direct communication with the Citizens. System should be able to manage basic
data on debates (Subject, Number of participants (including gender structure), Questions and
Answers, Result and documents) and to give some reporting options for physical debates.
Administration module
Designed as separated module, it should provide basic functionalities to configure the entire
system and to moderate citizen activities inside the system. Local administrator is also
responsible for managing internal users (employees, members of the Council and additional
administrators) and to define their access rights to the application modules and functions.
It should also be possible to configure and manage landing page information dashboard and
some other dashboards which might be defined in the system.
On the system level it should provide interface for Database backup and restore as well as for
the Database export.
Interoperability module
One of the key characteristics of the entire platform is interoperability, in other words possibility
to exchange data with other internal or external application. Interoperability should be
implemented by using worldwide accepted concepts of REST and Web Services and should be
fully configurable by the local administrator.

9
Notification system
Integral part of the platform should be notification system, both internal and external, providing
functionalities to automatically creates notifications about the events in the system (new
complaints, comments, vote, etc.) making users aware of the new information.
External notifications should be implemented in mobile applications, providing LG with options
to notify citizens about different important activities and major events on the city/community
level. Using interoperability module, it should also be possible to read information from external
sources and to create citizen notification based on these information.
All these steps should enable LG to create central notification platform for all institutions who
are willing to share information and to be a part of these activities.

System Actors
User Roles and Responsibilities / Authority Requirements

User/Role Example Frequency Security/Access, Additional

of Use Features Used Notes
Visitor Public visitors Frequent Information view and
who are limited reporting
accessing the
system

Citizen Logged in Frequent Information view, adding

users complaints, comments,
(Anonymous asking questions and
or Registered) basic reporting

Employee Employee of Frequent Information view, respond

the LG to complaints and
comments, full reporting

LG Council Members of Occasional Information view, answer

members the LG council the citizen questions,
limited reporting

Local Local Frequent Configuration of the

Administrator administrators system, moderation of
content, system functions

Technical and non-functional requirements

Introduction
This chapter contains a definition of technical and non-functional requirements for the system.
These requirements will be a mandatory part for the bids to be considered complete.

10
Technical requirements
Technology
The system should be developed as Web-based application in n-tier architecture with a Relational
database management system (RDBMS) as a back-end. Type of the RDBMS is not specified,
however open source solutions are preferred.
Specific modules should be developed as native mobile applications for Android and IOS operating
systems.
There are no specific requirements for development technology, however open source solutions will
have a distinct advantage. Software development language is not specified. The bidders may
propose appropriate architectures and/or additional services to be included, but always fully in line
with this document.
As web-oriented system, solution must be compatible with the most recent W3C standards and
suitable for use by any of the mainstream browsers – Internet Explorer, Chrome, Mozilla and Safari.
Generally, open source technologies for all parts of the system will have a distinct advantage in
selection process.

Architecture
The architecture of the eCitizen application should be of the n-tier type, given the flexibility and
advantages offered by this type of architecture All application modules should use integrated
Database for data storage.
Application must be designed to support two modes of implementation: Cloud and Local.

Cloud implementation
Initially, system should be implemented in the Cloud. Every LG must have its own application and
Database space, allowing independent work with the system and separate data access.
Functionality for all application modules and platform itself would be identical to all the LGs.
Each LG should have unique web address to access the application and be able to independently
manage the system configuration and to use administrative part of the system with all available
modules. It should be possible to link this address into the existing LG domain (for example:
www.tuzla.ba/ecitizen)
Citizens who are accessing the system should also have unique access point for accessing the
public interface, being able to use login function or to browse content and use system functions.
Central administrator should be able to manage LGs in Cloud environment, creating new LGs in the
system and administrating other top-level rights.
Each LG, being part of the integrated system, must have full access to its data with options to do full
export of Database with all data which belongs to them, including users, roles and access
privileges.

11
 Picture 1 – Architecture of the Cloud implementation

As shown in the Picture 1, all LGs are sharing the same application system with separated
application modules and same DB. DB is divided into multiple instances/schemas, for each LG.
Each LG should have link to access the system. Application users are using these access links to
work with application modules for specific LG.
System should also support different landing pages for each LG with visual identity and appropriate
menus and actions.

Local implementation
At any point of time, every LG can decide to switch to the Local implementation of the
system. Platform should support full export of application and system data, allowing Local
administrators to implement solution to the LGs data center and infrastructure.

Technical documentation should have a complete description and definition of this process,
including detailed list of system and application software and detailed description of the
complete process of transferring application from Cloud to Local implementation.

All system software which is needed to run the platform should be part of the solution
delivery; every new versions and upgrades of the system components which are
implemented in the Cloud during the warranty period, should also be part of the system
software delivery package.

Users of the system should not be aware of any changes in application functionalities and
performance, provided that local infrastructure is properly chosen and scaled.

12
 Moving the LG from the Cloud to Local implementation automatically removes it from the
Cloud infrastructure and removes complete data from the Cloud service.
Language requirements
The language of the interface must be one of the local languages (Bosnian / Serbian / Croatian) and
it should support both alphabets (Latin and Cyrillic). Language and alphabet settings should be
changed directly in the platform. In addition, registered users should have an option to set preferred
language and alphabet.

Openness and scalability

The system must have characteristics of an open system, which will facilitate future upgrades and
expansions.
The system should be scalable by number of LGs which (will) use it, number of users / citizens and
number of additional modules / data which will be integrated into the existing DB and application
modules.

Delivery form and source code

The software will be delivered in digital form (e.g. USB disk). Delivery should include all system
software which is needed to run the system in the Local implementation option, as previously
defined. Source code of the system will also be included as a part of the software delivery. UNDP
will have a right to take ownership of the source code in some special cases when contractor is not
further able to develop and support the system.

All documentation must be supplied in digital form as a Microsoft Word 2007-2013 document. In
addition, it may also be delivered in pdf and chm formats.
All progress reports and acceptance report, which will be signed, must be delivered in printed form.

Guarantee
The required guarantee period is 24 months from the signing of handover report. During this period,
contractor should provide Cloud services for running the platform for all LGs and will ensure timely
elimination of all the deficiencies and fine tuning of the system without any additional costs. In this
period, the response time must not exceed 24 hours (excluding week-ends) and a support-line will
be provided during the regular working hours.

13
Non-functional requirements

Security and data protection

The application must provide a module for creating and modifying user accounts and their roles in
the system (citizen, employee, member of the council, administrator). Authorization for access and
use of the application and data should be based on Roles.

Access to application and use of data are permitted only to those persons who are authorized and
who have been given the password for accessing the program, or the data. More details on access
rights is defied in the section which describes the Administrator Module.

Data input
To prevent errors when entering data and ensure data integrity, the module should have an entry
control, i.e. it must not allow entering inaccurate data in terms of format, type, data size, etc.
Appropriate checks must be made at the database level or/and at the application level to ensure
maximum data integrity. As a general rule, data should be entered into the database only once.

Monitoring activities
The system must be capable of monitoring users' activities and creating an activity log. Every user
action which is stored in the database should also be registered in the audit log with information of
user, date and time of the specified change.

System should be able to provide report based on audit data with all details about the audited
activity.

14
Functional requirements
Introduction
This chapter defines all functional requirements of the complete solution in detail. Complete system
is divided in individual modules which represent logical group of required functionalities, but bidder
can propose some different well justified or adjusted structure of the system, which will still include
all required options.

Screen mockups and diagrams are functional definition of the system parts. User interface and user
experience (UX) is not part of the document and the bidder should propose the most appropriate
solution based on the world standards, making the complete platform simple and efficient for the
end users.

The defined functional requirements could be extended during the implementation. The scope of
this extended functionality will be limited to reports and analysis dashboards and should not include
any new core functionalities which are not part of this document; however, some minor changes
and additional attributes might be included in these extended requirements.

15
Logical structure
eCitizen should be implemented as modular solution with the following structure:

A. Landing Page (Home page)

B. Complaints and comments to service deliveries
a. Web application
b. Mobile application
C. City council decisions and Questions for Members of the Council
D. Public debates and discussions (On-line and Off-line)
E. Citizen information desk
F. Administration module
G. Reporting and analysis module
H. Interoperability module
I. Notification system

Logical architecture of the system is shown in the following picture:

Picture 2 – Logical architecture of eCitizen System

Following are functional specification for each of the specified modules.

16
Landing Page
Landing page / Home page is the first screen of the application system, displaying images of the
chosen LG, menu system to access system modules and optionally some news and articles
maintained by administrator / authorized employee of the system.
Landing page should have the following sections:

- Main menu
- Info sections
- Action buttons

Each LG in the system should have its own landing page, configurable in administration module.
Menu structure should reflect structure of the system modules:

- Home
- Complaints
- Council sessions
- Questions for Council Members
- On-line Public debates
- Off-line Public debates
- Info Dashboard
- Help
- About

Info sections should display:

- Last 5 complaints
- Last Council sessions with documents / decisions
- My Complaints (For registered users)

Action buttons:

- Login
- New Complaint
- New Question for Member of the Council
- New Public debates comment

There are four groups of the users in the system (these groups correspond to Roles as
described later):

- Citizens
- Employees
- Members of the Council
- Local administrators

Users which belongs to a Citizens group are created using registration form, with additional
validation based either on e-mail either on sms (this option needs to be configurable in the
system administration).
Employees, Members of the Council and Local administrators are system users created in the
Administrator module, with appropriate options set in the interface.

17
Complaints and comments to service deliveries – Web application
Basic structure
As one of the most used modules of the system it should provide different functional views for
system actors (previously defined as visitors, citizens, Employees/Members of the Council and
Local administrators).
Following are functions per each of the views:
A. Public visitors view
This is the default view which is displayed for all visitors of the system who are not logged in.
Following options are available for these users:

- Log-in to the system as anonymous user or registered user

- List of all reported complaints with basic information and status
- View details for selected complaint
- Search in a complaints database using keywords
- Filter complaints per:
o Category
o Status
o Timeframe
o Profile data (where available)
- Statistic reports
o Complaints per category
o Complaints per status
o Complaints per profile data (Age group, Gender, Vulnerability groups etc.)

B. Customer / Citizen view

This view is for the users who are already logged in, either as an anonymous or registered user of
the system. In addition to previously defined options for public visitors, logged users can create or
edit data using following additional options:

- Edit citizen profile / Logout

- Accessing and edit complaint details (for complaints created by the current user)
- Display ‘My complaints’
- Creating a complaint with following information set
o Title
o Description
o Category of the problem
o Pictures
o Location on the map
o Profile data (if available and if user is logged in as registered user)

18
C. Administration view
Additional options for Local administrator are as follows:

- List of all reported complaints

- Check content and make complaints visible
- Edit form with following options
o Create a comment
o Assign the complaint to the relevant department in the LG
o Mark complaint as ‘Not appropriate’

D. LG employee view
When user belongs to the role of LG employee, additional options are available:

- List of all complaints for appropriate department

- Edit form with following options
o Add a comment or media files (Pictures, Videos, Documents)
o Answer the question / complaint
 Add an answer with optional additional files
 Mark complaint as ‘Answered’
o Resolve the complaint
 Add a comment with optional additional files
 Mark complaint as ‘Resolved’ and close it
- Dashboard
o List of complaints per timeframe
o Complaints per category and status
o Complaints per profile data
o Time of response
o Filters per department (with access control)

19
Complaint Lifecycle
Lifecycle of the complaint could be described through the following steps:
1. Created
Registered citizen / user enters the new complaint with specified fields and save it to the
database.
o New complaints get the status ‘Created’
o Administrator is notified about the new complaint
o Complaint is visible in Administrators list of complaints

2. Active / Blocked
Administrator edits the complaint in the administrators list.
o Administrator check the content of the complaint
o If the content is not appropriate, complaint changes the status to ‘Not appropriate’. In
this case complaint is visible but the content is not displayed. Instead of the content
system should display text ‘This complaint is not displayed due to the inappropriate
content’
o If the content is relevant and acceptable, administrator makes the complaint visible to
the public visitors and citizens
o Complaint changes status to ‘Active’

3. Assigned (In process)

Complaint is assigned to the appropriate sector and is in the resolving process. Responsible
employee from the sector edits the complaint in the employee interface
o Local administrator assign the complaint to the appropriate sector
o Complaint changes the status to ‘Assigned’
o Complaint is visible in the department complaint list
o Employees of the assigned sector are notified about the new complaint

4. Responded
When the complaint is assigned to the appropriate department, employees edits the
complaint.
o Employee responds to the complaint, with optional documents and comments
o Complaint changes status to ‘Responded
o Complainant Citizen is notified about the respond
o If the complaint does not require any additional action from the LG it stays in status
‘Responded

5. Resolved
When the complaint is responded to, it should stay in the list of complaints for some
predefined period. For Certain number of complaints there will be additional step (as per
complaint lifecycle) until the complaint is finally resolved.
When the required action from the complaint is finished, LG employee enters additional
information about the actions in the complaint and changes the status to ‘Resolved’.
Complainant citizen is notified that the complaint is Resolved

20
A. Public visitors view
1. List of all reported problems with basic information and status
Public visitors can list all reported complaints with basic information and status and view the details
of each individual complaint but could not add comments nor create new complaint.

Picture 3 – List of complaints

As shown on the picture, visitors can scroll through the list of complaints and with a double-click
open a new page with detail information about selected complaint.
On a detailed page registered user can enter a new comment on the selected complaint.
2. Search in a complaints database on keywords and Filter per Category and Status
Using filters on the top of the page, users can filter the complaints per category or status, and
search complaints per any of the keywords defined in the system.

21
3. Statistic reports
Button ‘Statistics’ or Menu option ‘Statistics’ open a new window with the statistical graphs for the
complaints in the database. Some of the graphs could be defined as:
a. Complaints per category
b. Complaints per status
c. Complaints per profile data (Age group, Gender, Vulnerable groups etc.)

Picture 4 – Reports on complaints

Previous picture is for illustration purposes only and does not limit or specifically define number or
type of the required graphs. It is up to the bidder to offer the most effective and visually attractive
interface for the analytics dashboard, which will be one of the key criteria in system evaluation.

22
B. Customer / Citizen view
When a user would like to access additional functions of the system (adding a complaint, comments
etc.) he/she should log in ( as anonymous or as registered user).
1. Log-in to the system as anonymous user or registered user

Picture 5 – Log in screen

Citizen who would like to create a complaint or comment in a completely anonymous way, should
log-in only by clicking button ‘Anonymous’ and should enter only temporary username and continue
to use the system as anonymous with chosen username.
For the Citizens who would like to create a profile / registration, option for new registration will offer
them to enter following information:

- Username (Mandatory)
- Password (Mandatory)
- Name and Surname (Mandatory, not verified)
- Phone number (Mandatory, used for account validation)
- E-mail address (Mandatory, used for account validation)
- Choice of account validation (E-mail or SMS)
- Age (Not mandatory)
- Gender (Not mandatory)
- Vulnerability group (Not mandatory)

All these parameters should be configurable in Administration module and set as mandatory or not
mandatory for each LG.

23
After registration, user will have to validate account using chosen validation method. These options
should also be configurable in Administration module.
When validated, user account become Active and can be used to access the system.
Benefit for citizens who decide to register will be that they will not have to enter login information
every time they want to work with the system. This is especially convenient for the mobile
application when user can login once and use application for an allowed period with no additional
logins.
2. Creating a new complaint
Creating a new complaint function opens a new window with appropriate fields for creating a
complaint, as shown on the following picture:

Picture 6 – New complaint

User should enter the following information:

- Title of the complaint / problem

- Description
- Category of the complaint (selection from the Combo box)
- Optionally user can upload pictures and enter location info.
(Number and size of the pictures which can be uploaded should be configured by Local
administrator)
- Location info should be entered using user friendly visual map tool

24
After saving, complaint is displayed in the Administrators list and notification is sent to complainant
Citizen and Local administrator which should approve complaint, moderate inappropriate content ,
assign it to the appropriate Sector in LG and make the complaint visible.
3. Comments on existing complaints
Logged users can also comment on existing complaints by displaying the complaint details and
creating a new comment.

C. Administration view
Local administrator is responsible for configuring basic parameters of the system and to moderate
user records by means of inappropriate content.
In addition to all previously defined functions, administrator view should provide following
functionalities:
1. Manage the complaints entered by the citizens
Local administrator should have a separate form with a list of new complaints. List of complaints
should be the same as previously defined in section A.1
All complaints in the list should be clearly separated per status and marked per visibility, so that
Local administrator can easily control which complaints need his attention.
Local administrator should be able to edit each complaint, as shown on the following picture:

Picture 7 – Edit complaint - Administrator

Administrator should be able to use the following options:
o Assign the complaint to the relevant department in the LG
o Make complaint Visible to citizens and visitors
o Mark complaint as ‘Not appropriate’

25
 o Create a comment
Each of these actions should automatically change the status of the complaint and send appropriate
notifications to relevant users. Details about Notification system will be defined later in the
document.
When the complaint is marked as ‘Not appropriate’ it should stay in the system and be visible to all
the visitors and users, but the content of the complaint is not displayed. Instead, system should
display text ‘Not displayed due to inappropriate content’. All other elements of the complaint (Date,
Author, Category) should remain visible.

D. LG employee view
Users who belongs to the role ‘LG employees’ should have a specific set of functions related to the
user complaints;
1. Manage complaints assigned to specific departments
When an Local administrator assigns a complaint to the specific department, it should automatically
become available in the Departments complaint list. This list should be the same as previously
defined in section A.1 with predefined filter which displays only complaints assigned to user’s
department, in status ‘Assigned’.
Responsible employee should edit the user complaint using appropriate form, showed in the
following picture:

Picture 8 – Edit complaint - Employee

When employee answers the complaint and Save it, complaint automatically change status to
‘Responded’.

26
Complaints in status ‘’Responded’ can be edited and change to status ‘Resolved’, with the
appropriate explanation or comment.
Employee should also be able to add different multimedia documents to the complaint
(images, videos) which proof the status of the complaint.
2. Reports ( Department level)
Each user (Employee) in the LG belongs to certain department which is responsible for responding
and managing user complaints.
Employees should be able to access reports displaying data at the users Department level. Local
administrator should be able to extend users rights to other departments in the LG (or to all
departments).
Basic list of analytical reports and charts is as follows:
o List of complaints per timeframe
o List of complaints by due date
o Complaints per category and status
o Complaints per profile data
o Time of response (Average, Maximum, Minimum)
o Filters per department (with access control)

27
Complaints and comments to service deliveries – Mobile application

Mobile application should be developed as native application for Android and IOS platform,
communicating with the central Database using server-side REST services.
Bidders offer should contain separated applications for Android and IOS with prices for development
and support in warranty period.
Structure of the mobile application should be the same for both platforms, containing the following
functions:
A. Customer / Citizen view

- Home page of the application

- Log-in to the system as anonymous or registered user
- Accessing the complaint reporting page using Mobile interface
- Creating a complaint with following information set
o Category
o Description
o Pictures
o Location on the map
o Profile data (if available and if user is logged in as registered user)
B. Common view

- List of all reported complaints with basic information and status

- Search in a problem database on keywords
- Filter complaints per:
o Category
o Status
o Timeframe
o Profile data (where available)
- Push notifications
- Statistic reports
o Problems per category
o Problems per status
o Problems per profile data (Age group, Sex, Vulnerability groups etc.)

Administration of the mobile application will be integral part of the Administration application
module.
Mobile application should be created in a way that during the installation process appropriate back-
end layer of the platform is selected, by choosing one of the LGs which already exists in the
database.

28
A. Customer / Citizen view

Home Page
Home page of the mobile application
should contain two main sections:

- Main menu
- Notifications

Main menu should provide access to the

application modules and options, as
shown in the picture.
Each single menu button should open a
new form / screen with appropriate
functionality.

Notifications section displays push

notifications which are sent to the
application users by the central system.
Notifications are generated or entered in
the administration part of the platform,
and mobile application should only
display list of notifications, display
notification details (when user click on
specific notification in the list) and
optionally remove notifications from the
list.
Initially, push notifications will be
received by all users who install the
application, but can be turned off using
application settings.

Picture 9 – Mobile app Home page

29
Log-in to the system as anonymous user or registered user

Login screen is like the previously

defined screen in Web application, with
the same functionality.
To perform registration or logging in,
mobile application should already be
connected to back-end layer of the
platform and communicate with
Database on the server.

Picture 10 – Mobile app User login

30
List of complaints / My complaints

List of complaints should display list

of all reported complaints for the
current LG, order by newest at the
top.
Users should be able to search or
filter the list in the same or similar
way as in the Web application.
Selecting / Clicking complaint in the
list should display new screen with
complaint details.
Action button ‘New complaint’ should
display a new screen for entering
new complaint.

Picture 11 – Mobile app list of complaints

31
View complaint details
Screen for displaying complaint details
should contain detailed information
about the complaint and actions
buttons for adding a new complaint or
adding a comment to the existing
complaint.
Button Home should return user to the
Home page of the application, and
button ‘Back’ to the list of complaints.

Picture 12 – Mobile app View complaint details

32
New Complaint
Form for entering the new complaint
is shown on the picture. User should
enter basic information about the
complaint, optionally add photos and
location info and Save the complaint
by clicking on the button ‘Report
Complaint’

Picture 13 – Mobile app New complaint

33
B. Common view

Common view is used for the users who are not logged in the system and includes basic set of
options. All these options are already defined in the previous section:

- List of complaints
o View complaint details
o Search by keywords or content
o Filter complaints per:
 Category
 Status
 Timeframe
 Profile data (where available)
- Read push notifications (public notifications only, without personalization)
- Statistic reports
o Complaints per category
o Complaints per status
o Complaints per profile data (Age group, Gender, Vulnerability groups etc.)

Statistic reports are the same as previously defined for Web application, for the current LG and
chosen filters.
Bidders should propose the most appropriate functional and design implementation of mobile
report / dashboard pages that will be simple and easy to use but efficient at the same time.

34
City council decisions and Questions for Members of the Council

Module for City council should provide citizen with detailed information about the city council
sessions, documents and decisions. Registered citizens should be able to interact with the council
through the comments and questions for each individual activity of the council.
Citizens should also be able to communicate with Members of the council by asking questions,
directly addressed to them, through appropriate interface. Members of the Council should be
notified about the questions and be able to answer using email or directly through the system.
Here is the list of required functionalities for this module:
A. Administration view
1. Managing data on City Council sessions and documentation
2. Managing access rights for comments and voting on a document level
3. Creating and updating Members of the Council profiles
B. Citizen view
1. Accessing the list of sessions and documents
2. Creating comments to specific documents
3. Voting on specific documents
4. ‘Ask the Members of the Council’
C. Members of the Council view
1. Accessing list of sessions, documents and comments
2. Creating comments
3. Updating Profile info
4. Ask the Council Members
a. Respond to the Citizen questions
5. Statistic reports
a. Comments/Voting per category
b. Comments/Voting per session
c. Questions/Answers per Member of the council
d. Response time per Member of the Council and average time
e. Number of Questions per status (Answered, Not answered)

35
A. Administration view
1. Managing data on City Council sessions and documentation
Local administrator manages data about City council sessions and documentation. This can be also
assigned to some of the employees inside of the LG, depending of the internal organization.

Picture 14 – Council sessions

Each session is described with the basic set of attributes and attached documents, as shown in the
picture 15. Different documents can be attached to a session: Agenda, Documentation for members
of the Council, Information, Reports and final documents after the session is completed (Final
report, Decisions, Meeting minutes etc.).

36
 Picture 15 – Session details with documents and comments

When adding a document, Administrator/Employee defines the basic parameters of the document,
including:

- Document title
- Date
- Description
- Status
- File (Content of the document)

Defining these attributes and uploading the document is basic action which creates a new document
in the system and attached it to the selected session.

37
2. Managing access rights for comments and voting at a document level
Administrator also defines additional information: Privileges, Voting configuration and Comments
configuration. As can be seen on picture 16, these elements can be configured using simple form
for each individual document.
Privileges on a document level could be:

- Public (all visitors and users can see the document)

- Private (only author can see the document)
- Access control (only selected groups can see the document)

Voting on the document level could be allowed or not allowed.

Comments on the document level could be allowed or not allowed.

Picture 16 – Document access control and configuration

Application should provide functionality of ‘predefined’ template for privileges, voting and comments
on the session level, so that every time when new document is created, it automatically fills in these
options with predefined values.

38
3. Creating and updating Members of the Council profiles
Local administrator is responsible for creating and updating profiles for the Members of the Council.
As shown in the following picture, each Member of the Council should have a profile with basic
information and picture. These profiles should be created by the Local administrator and can also
be updated individually by the Members of the Council.

Picture 17: Edit Member of the Council profile form

39
B. Citizen module
1. Accessing the list of sessions and documents
Visitors and logged citizens can browse the list of City council sessions using search and filter
functionality.

Picture 18 – List of sessions

Visitors of the system can see the details of the session, with attached document, and could not
perform any additional actions (comments, voting) until they are logged in.

40
 Picture 19 – Details of the session for visitors
Visitors of the system can see the session details, browse and download the documents. To create
comments and vote they must login to the system.
Registration and login are created in the same way as for the entire system. When logging in, user
can choose to log in as anonymous, when he/she must enter only username (nickname), or to use
full login with registration and user profile.
Allowed or preferred type of login for each of the modules should be defined in system
administration.

41
2. Creating comments to specific documents
When user is logged in, he/she can create new comment and vote for document or decision inside
the session.
Voting could be defined as positive or negative opinion about the specified document or decision
(similar to Facebook functionality ‘Like’ and ‘Do not like’).

Picture 20 – Details of the session for logged in users

Inside the system, all actions are audited with information about username, date and time, IP
address and link to the inserted comment or record.
Also, each of the comments must be moderated by the Local administrator or authorized person
inside of the LG.

42
3. Voting on specific documents
As can be seen on the picture 21, system should provide voting function (For or Against) for specific
document, decision or information.
Voting preferences (is voting allowed or not) can be configured at the level of document and voting
results should be seen in the list of documents inside the session details form, as on picture 19.

Picture 21 – Details of the session for logged in users

43
4. Ask the Member of the Council
Citizens can directly communicate with Members of the Council by asking them questions. Form for
questions is shown in the following picture:

Picture 22 – ‘Ask the Member of the Council’ page

Form displays a list of Members of the Council with picture and basic information. It should be
possible to filter and sort the form data.
For each Member of the council system also shows number of total questions asked and number of
questions answered.
Clicking on the picture or name, users are accessing the detail form, which is shown in picture 23

44
 Picture 23 – Individual Members detailed info with Questions and Answers
Detail form is showing all information about the Member and list of asked and answered questions.
User can scroll through the list of questions or search per specific content.
By clicking the button ‘Ask the Question?’ users should be able to create a new question, accessing
the new form with only one text field for question text and buttons for ‘Submit’ or ‘Cancel’ the
question.

45
C. Members of the Council module
As other registered users in the system, Members of the LG council can perform following
functionalities:
1. Access list of sessions, with details documents and comments
2. Creating additional comments and answers
These functions could be defined in the same way as for Citizens.
3. Member Profile
Members of the Council should have access to their profiles and should be able to update profile
information.
They should use the same form as Local administrator (Picture 16). The only difference between
Members of the Council and Local administrator is that Local administrator should have access
rights to the profiles of all Members, while individual Members should access and edit only their own
profiles.
4. Respond to Citizens questions
When new questions are entered into the system, Member of the Council should automatically
receive notifications about it.
Notifications should be implemented using SMS, eMail and internal messaging.
Members should have two options to answer the question:
1. Direct reply to the notification eMail should automatically create and publish answer in the
system, while there might be an option for Local administrator to confirm and submit the
answer.
2. Logging into the system, Member should enter his profile and see a list of questions, then
use appropriate option to directly answer specific question.
In both cases there should be an additional option which requires Local administrator to confirm the
answer, and this option should be configurable in Administration module.

5. Statistic reports

Members of the council should be able to list some of the analytical reports about the sessions
and Questions and Answers as well.

Basic reports on sessions and Questions and Answers should be:

a. Comments/Voting per category

b. Comments/Voting per session
c. Questions/Answers per Member of the council
d. Response time per Member of the Council and average time
e. Number of Questions per status (Answered, Not answered)

During the process of assessment and initial implementation, additional reports will be defined.

46
Public debates and discussions
This part of the platform should include working with on-line and off-line public debates.
On-line debates module should provide functionalities of citizen engagement in processes of
discussing new proposals, initiatives, ideas, city projects, decisions or any other kind of activity
which can benefit from the citizen engagement and opinion.
Off-line debates module should include information about Public debates which were held in real
environment in direct communication with the Citizens. System should be able to manage basic
data on debates (Subject, Number of participants, Questions and Answers, Result and documents)
and reports for off-line debates.

Module should provide following functionalities:

A. Administration module
On-line debates
1. Creating new on-line public debate
a. Adding new debate
b. Defining basic characteristics of the debate
i. Title
ii. Subject
iii. Description
iv. Start
v. End
vi. Search keywords
vii. Type (Open, Closed, Public)
viii. Type of user access (Registered, Anonymous)
ix. Attached documents
x. Responsible persons
xi. Contact persons
c. Make the Debate Active
2. Creating Links between debates and:
a. City council’s sessions and decisions
b. Reported problems and comments from Citizens
3. Managing Access rights for specific debates
4. Moderating the content of the debate including comments and discussions

47
Off-line debates
1. Create a new off-line debate
a. Adding new debate
b. Defining basic characteristics of the debate
i. Title
ii. Description
iii. Start date
iv. End date
v. Search keywords
vi. Type (Open, Closed, Public)
vii. Responsible persons
viii. Contact persons
ix. Attached documents

2. Adding sessions to off-line debate

c. Sessions held for the debate
i. Start Date and time
ii. End Date and time
iii. Location
iv. Authorized employees from LG
v. Number of participants
vi. Discussions
vii. Results of the session (Documents)
3. Sessions Final report

B. Citizen module
1. Accessing the list of on-line public debates
a. Search on keywords
b. Register to enter to debate or anonymously enter the debate (depending on the
configuration option)
c. Creating comments and participate in discussions
2. Accessing the list of off-line debates
a. Search on keywords
b. View the debate details

48
C. Employee module
1. Accessing the list of on-line public debates
2. Creating comments and participate in discussions
3. Search in a Debate module on keywords
4. Filter citizen comments per:
a. Category
b. Status
c. Timeframe
d. Profile data (where available)
5. Statistic reports
a. Comments per category
b. Comments per status
c. Comments per profile data (Age group, Gender, Vulnerability groups etc.)
6. Accessing the list of off-line debates
a. Search on keywords
b. View the debate details
7. Statistic reports on off-line debates
a. Debates per period and type
b. Debates per sector
c. Sessions per debates with number of participants
d. Overview of documents per document type
e. Number of participants per locations
f. Overview of discussions and final comments

49
A. Administration module
1. Creating new on-line public debate
Administrator or authorized employee should have an option to enter the list of debates and to
create new debate or edit the existing one.

Picture 24 – List of public debates in the LG

List of debates displays all public debates with predefined statuses, allowing visitors ( also citizens ,
employees and administrators) to browse through the Database of debates, using search and filter
criteria to find specific debates.
For visitors, no additional options are available. To see the details and to participate in the
discussions, users need to login to the system (either as anonymous or as registered user).

50
 Picture 25 – Public debate Edit
As can be seen on picture 25, adding a new debate form contain following attributes/fields:
i. Title
ii. Date
iii. Description
iv. Status
v. Start
vi. End
vii. Search keywords
viii. Type (Open, Closed, Public)
ix. Type of user access (Registered, Anonymous, All)
x. Attached documents
xi. Responsible persons
xii. Contact persons

Entering / or editing debate data also allows administrator/employee to make the Debate Active in
the system, meaning that users can start adding comments to the debate.

51
2. Creating Links
Links are specific relations between debates and other information in the system. It is defined that
public debates can be linked to City council sessions ad decisions, and that various complaints can
also be linked to the public debates.
Using links, it should be able to follow the process of decision making inside the LG, and to be
informed about the projects, decisions and complaints which are related to the specific debates.
Links can also be used for reporting and analytics, providing employees of the LG with valuable
information about processes of citizen engagement, performance measurement and result oriented
management.
3. Managing Access rights for specific debates

Picture 26 – Access control for a Public debate

As shown in picture 26, Local administrator can define Debate as public, private or access control
(when additional information about access control needs to be entered)

52
4. Moderating the content of the debate (including comments and discussions)
Each public debate has a separated section ‘Discussions’. Discussions are predefined themes for
citizen and employee comments and participating in the debate.

Picture 27 – Creating Discussions and moderate content

Members of the discussion can only add comments into the existing discussions, while the
discussions are created by the administrator or authorized employee.
Administrator or authorized employee also moderate each comment for inappropriate content,
handling it in the same way as already defined in the Complaints module.
It is important that moderated records are not deleted or hidden, inappropriate content is replaced
with the text ‘This comment is not displayed due to the inappropriate content’. Actual text of the
comment should be kept in the database, and only visible to Local administrator.

53
Off-line debates
1. Creating new off-line public debate
Administrator or authorized employee should have an option to enter the list of off-line debates and
to create new debate or edit the existing one.

Picture 28 – List off-line debates in the LG

List of debates displays all off-line public debates with predefined statuses, allowing visitors (also
citizens, employees and administrators) to browse through the Database of debates, using search
and filter criteria to find specific debates.

54
 Picture 29 – Off-line Public Debate Edit
As can be seen on picture 29, adding a new off-line debate form contains following attributes/fields:
i. Title
ii. Description
iii. Start Date
iv. End Date
v. Search keywords
vi. Type (Open, Closed, Public)
vii. Category (Public discussion, Meeting, Debate etc.)
viii. Responsible persons
ix. Contact persons
x. Attached documents

55
2. Adding sessions to off-line debate
Each off-line debate could have multiple physical sessions (meetings, public discussions, etc.).
System should provide possibility to enter detailed information about each session.
Adding the off-line sessions is done by Local administrator or authorized employee.

Picture 30 – Off-line debate Sessions and Documents

56
As can be seen on the picture 26, each Debate can have multiple sessions with attached set of
documents. Local administrator can add a new session using button ‘New Session’ or edit existing
session by clicking on the row in the Sessions table.
When adding a new session, Local administrator (or authorized Employee) enters following
information:
 Start Date and time
 End Date and time
 Description of the session
 Location
 Session type (Open session, Meeting, Round table etc.)
 Number of participants
 Gender information: number of Male and Female participants
 Results of the session (Documents and discussions)
Each session is saved into the system and can be used for different reports and analysis.

57
3. Sessions Final Report
It should be possible to create Final report for every session. As shown on picture 31, final report
consists of detailed description of the session and number of Questions and Answers. Each
‘Question and Answer’ record should have following information :

- Question
- Answer
- eMail from the LG Employee who answered the question
- Contact information of citizen who asked a question ( Name and eMails )

Picture 31 – Final report for the Off-line Session

When detailed description and all questions and answers are inserted, Local administrator has an
option to prepare and send Final report to all participants of the session.

58
Button ‘Send Report’ should do the following :

- Create pdf report from the session, including basic elements of the Debate and of the
session, Final report description and all questions and answers
- Send the final report pdf document to following recipients :
o LG Employees who are defined as contacts for the Debate
o Citizens who are defined as authors of the questions
o Additional eMail addresses who can be added by Local administrator

59
B. Citizen module
Citizens (registered users) can use this module in the following way:
1. Accessing the list of on-line public debates and search for keywords
Visitors and registered users can access the list of on-line public debates (Picture 24), browse and
search for a specific content.
After logging in, user can view debate with all the available details (Picture 25) and participate in its
work by adding comments.
2. Creating comments and participate in discussions
Citizens can enter the debate and create new comments in some of the predefined discussions.
They can also attach documents and media files to the comment.
All comments are moderated by the Local administrator for inappropriate content, in the same way
as already defined for Complaints module.

Picture 32 – Creating Comments in selected discussion

60
3. Accessing the list of off-line debates with search functionality
Visitors and registered users can access the list of off-line public debates, browse and search for a
specific content.

Picture 33 – List of Off-line debates

C. Employee module
In addition to all the functionalities defined for Citizens, employees / Internal users should have
access to statistical reports on selected debates or documents.
They can also access the overview of the comments and discussions, using some of the predefined
filters and groupings:
a. Category
b. Status
c. Timeframe
d. Profile data (where available)
Some of the statistic reports which can be derived from the available data, as shown in picture 34
are:
a. Comments per category
b. Comments per status
c. Comments per profile data (Age group, Gender, Vulnerability groups etc.)

61
 Picture 34 – Analytic reports and charts for public debates
Employees should also have access to list of off-line debates with overview of the details and
sessions.
Users should be able to use predefined filters, which automatically refresh and displays new data.
For Off-line debates there should be several reports based on off-line debates data:
a. Debates per period and type
b. Debates per sector
c. Debates per category
d. Sessions per debates with number of participants
e. Sessions per type
f. Overview of documents per document type
g. Number of participants per locations, category, type
h. Overview of discussions and final comments

These Reports are only basic set of reports based on available data. Bidders can offer some
additional reporting functionalities as a part of their offer. During the implementation process, users
can define additional reporting requirements, again based on the available data and processes.

62
Citizen information desk
Citizen information desk should be created as integral part of the platform and implemented as
Content Management System (CMS).
Basic functionality of this module could be derived from the standard CMS solutions, with limited set
of options by means of structure, layout and design, and focus on information management and
wide set of options for creating citizen dashboards for accessing the most important information in
LG.
Required functionalities could be defined in the following way:
A. Administration module
1. Creating Citizen Dashboard
a. Defining Dashboard navigation menu with all available options
b. Adding new information section
c. Define section characteristics
i. Title
ii. Type (News, Documents, Single page information)
iii. Description
iv. Priority
v. Position in the navigation menu
vi. Responsible Sector / User
vii. Contact user
d. Make the Section active
2. Managing Access rights for dashboards elements
3. Managing notifications for citizens
B. Citizen and Visitors module
1. Displaying citizen dashboard
2. Configuration of the dashboard (for registered users)
3. Subscribe for a mailing list / Information flows
4. Search on keywords
C. Employee module
1. Accessing the dashboards elements
2. Editing dashboards content (Documents, News, Articles)

63
System Administration module
Complete administration of the system should be defined in two levels:

- Top level Cloud administration

- Local administration

Top level cloud administration module should provide main Cloud administrator with
functionalities for managing top level access rights and application properties for each individual LG.
A. Administration module
1. Adding new LG to the system
a. Define basic LG attributes
b. Define application modules and access rights
c. Define administrator users
d. Create DB user and prepare DB structure
2. Monitoring LG and citizen activities
3. Creating system reports and audit information
4. Managing notifications on application level
Within the Local administration module, local administrators should be provided with the following
functionalities:
1. Configuration of the system parameters
2. Creation of the backup copies of the Database
3. Creating users, roles and access control rules
A. Configuration of the system parameters
Local administrator should be able to configure system parameters according to the specific needs
and requirements on the LG level.
The configuration settings should provide (but are not limited to) the following options:

- Mandatory registration fields for user registration

- User registration preferences (Only registered users, Only anonymous users, Both options)
- Elements of Landing page
- Settings of the Notification system
o Define notification groups
o Define notification group members
o Define notification actions and rules
o Define notification content and templates

B. Creation of the backup copies of the Database

Local administrator should be able to manage complete content of the Database owned by the
specific LG. This functionality includes following options:

- Database backup (Manual or Automated Full Database backup to local storage)

- Database restore (Manual restore of the Database content from the desired backup file)
- Database export
o Full export of the DB in the form which allows data access using some of the
standard tools (Microsoft Access, Microsoft Excel, etc.)

64
C. Creation of users, roles and access control rules
eCitizen system should use RBAC (Role Based Access Control) method for authorization of the
users and controlling the access to the specific application modules and functionalities.

Local administrator should register new users and attached them to predefined roles (Citizens,
Employees, Members of the Council, Local administrators). Registration for the Citizens could
also be performed directly from the application, as already described.

Predefined roles provide Local administrator with options to control application access for each
of the Roles. Access control should be implemented on the options level, for each item of type:
Menu item, Action Button, Report). Using this option, Local administrator should be able to fine
grant access to the application functionality for each of the roles.

Reporting and analysis module

Reporting part of the system is distributed inside the various modules and available to user at the
certain levels, with access rights control.
Common requirements for all the reports could be defined in the following way:

- Reports should be started from the menu or action button

- Report parameters should be entered before the report execution and optionally after the
execution
- Reports should support grouping, sorting and aggregation functions
- Each report should be visible on the screen and printed to the available printer
- It should be possible to export report in all standard file formats (pdf, excel, word, html)
- Dashboards and charts should be configurable by means of order and basic characteristics
of the individual components
Reporting and analysis module should integrate all reports and charts which exists in the other
modules of the system. Reports should be grouped by logical sections – modules and provide the
same functionality as all previously defined reports.

65
Rest Services and Interoperability
Interoperability is characteristic of a product or system, whose interfaces are completely
understood, to work with other products or systems, present or future, in either implementation or
access, without any restrictions.
Syntactic interoperability comprises the ability of different systems to work together, exchange
data using defined data format and communication protocols.
Semantic interoperability defines the ability to automatically interpret the information exchanged
meaningfully and accurately to produce useful results as defined by the end users of both systems.

RESTful web services are built to work best on the Web. Representational State Transfer (REST)
is an architectural style that specifies constraints, such as the uniform interface, that if applied to a
web service induce desirable properties, such as performance, scalability, and modifiability, that
enable services to work best on the Web. In the REST architectural style, data and functionality are
considered resources and are accessed using Uniform Resource Identifiers (URIs), typically links
on the Web. The resources are acted upon by using a set of simple, well-defined operations. The
REST architectural style constrains an architecture to a client/server architecture and is designed to
use a stateless communication protocol, typically HTTP. In the REST architecture style, clients and
servers exchange representations of resources by using a standardized interface and protocol.

The following principles encourage RESTful applications to be simple, lightweight, and fast:

 Resource identification through URI: A RESTful web service exposes a set of resources that
identify the targets of the interaction with its clients. Resources are identified by URIs, which
provide a global addressing space for resource and service discovery.
 Uniform interface: Resources are manipulated using a fixed set of four create, read, update,
delete operations: PUT, GET, POST, and DELETE. PUT creates a new resource, which can be
then deleted by using DELETE. GET retrieves the current state of a resource in some
representation. POST transfers a new state onto a resource.
 Self-descriptive messages: Resources are decoupled from their representation so that their
content can be accessed in a variety of formats, such as HTML, XML, plain text, PDF, JPEG,
JSON, and others. Metadata about the resource is available and used, for example, to control
caching, detect transmission errors, negotiate the appropriate representation format, and
perform authentication or access control.
 Stateful interactions through hyperlinks: Every interaction with a resource is stateless; that
is, request messages are self-contained. Stateful interactions are based on the concept of
explicit state transfer. Several techniques exist to exchange state, such as URI rewriting,
cookies, and hidden form fields. State can be embedded in response messages to point to valid
future states of the interaction.

REST services layer in the system should be used as communication layer for mobile applications
which are part of the system, exposing the DB objects as Web Services.
It will also provide great interoperability features in exchanging information with unlimited number of
internal or external applications.

66
Notification system
Internal notifications system

One of the important part of the entire platform is notification system. Internal notification system
should provide all users (citizens, member of the council, employees and administrator) with
messaging platform (email, internal messages, SMS) which can be used for different notifications
about actions and states of objects in the system.
Definition of notification starts with the action which triggers the notification. Examples of these
actions are:
1. Complaint changes the status of ‘Active’ to ‘Assigned’
2. New comment for Session agenda has been entered into system
3. Comment has been added to discussion in Public debate
In all these three cases users of the system must be notified that the action has happened. In first
case it will be complainant user and employee of the sector to which the complaint is assigned. In
second case it would be author of the Agenda document and contact persons for the specified
session. In third case administrator / employee who created a discussion and user to which this
comment refers to also need to get the notifications.
Platform should provide different communications channels for creating notifications:

- Internal messaging system

- email messages
- SMS
- Social networks

All these channels could be used simultaneously to notify users about events in the system.
Administrator should be able to define basic actions / triggers and to create user groups which are
notified about these actions. Bidder may suggest most appropriate design and implementation of
notification system which will be suitable for the platform and include all the rules and events for
notifications.

External notification system

External notification system should be implemented as part of the mobile application using Push
notifications. These notifications should be part of the mobile applications for Citizen complaint and
should provide LGs with opportunity to send different notifications to the citizens.
Notifications should be created in Web application from the Local administrator or authorized
employee and then sent to the mobile devices of the users who are using Complaint mobile
application.
Definition of push notifications in the system should be created in a way that it is possible to include
any data from the Database as a part of the message and to create different queries for creating
push notifications for the client apps.
Notifications can also optionally contain links to further info or other info on LG website or some
other Web location.

67
Other conditions for delivery of the solution

Services and products offered by the bidder

Services and products which must be included in this offer are as follows:
1. Implementation of the complete platform for Citizen engagement with all required
functionalities and in the way which is required by this document

2. Installation of the platform to Cloud infrastructure and migration of all data which is needed
for platform to work

3. Local administrators and user training (Employees and Member of the council)

4. Detailed User documentation (User guide, User manual) and Technical documentation
(System setup, Technical architecture, Configuration manual)

5. Cloud services for running the platform for period of 24 months, including full support

6. Support for migration application and data from the Cloud to the LG infrastructure, after the
initial period of 24 months

Pricing section of the offer should have separated prices for the following items:
1. Module 1a – Complaints and comments to service deliveries Web application
2. Module 1b - Complaints and comments to service deliveries Mobile application (Android and
IOS)
3. Module 2 – City council decisions and Questions for Members of the Council
4. Module 3 – Public debates and discussions (On-line and Off-line)
5. Module 4 - Citizen information desk
6. Supporting Modules
a. Landing Page
b. System Administration
c. Reporting and Analysis Module
d. Interoperability Module (Rest Services)
e. Notification System
7. Installation and user documentation
8. Administrator and End user training
9. Cloud infrastructure for 24 months period – operating and support
10. Migration application services for migrating the solution to LG infrastructure
11. Prices for the system maintenance after the guarantee period1
a. Price of using the Cloud services for a month / year
b. Price of application support for a month / year

1
These prices are only important in evaluation process and not part of the total price of the project
implementation

68
System setup and Implementation

Software solution which is subject of this specification needs to be implemented in Cloud platform
and use from the Cloud for a period of 24 months. Contractor should provide all services and
infrastructure which is needed to provide requested functionality, without any additional costs other
than specified in the Pricing section of the offer.
Open source technologies are preferred. In case that local implementation requires some additional
licensing costs, it should be clearly defined in the pricing section.
After the guarantee period, it should be possible to transfer all application source and data to the
local LGs which will continue to use the platform on their own equipment and infrastructure.
All system software which is needed to run the platform should be part of the solution delivery;
every new versions and upgrade of the system components which are implemented in the Cloud
during the warranty period, should also be part of the system software delivery package.
Technical documentation should have all details about Local Setup of the application system,
including all prerequisites and components. Result of the Local Setup process should be that
platform is functioning in the identical way as on the Cloud.
Estimated number of users which will use a system:

- Number of total citizens using the system (10.000)

- Maximum number of concurrent user in the system (500)
- Number of data record per module (for all LGs)
o Problems in service delivery 3.000 per month
o City council comments and voting 2.000 per month
o Public debates 2.000 per month
o Citizen information desk 1.000 per month

Estimated total number of data in the system is small, although system should handle potentially
large number of media files (images, video, maps, links) which can be handled in different ways.

69
Local administrators and LG employees training

Bidder should provide detailed training plan as part of the offer.

Training for Local administrators should be planned on-site, on one central location, for a group of
10 – 18 people designated to be Local Administrators for LGs. Training should include all relevant
subjects which are part of Local administrator functionalities in the system and should include all
training materials and documentation. Estimated duration of the training is 3 – 5 days.
Training for LG Employees should be planned on-site, for groups of Employees from 2 LG, with
maximum number of 20 people per session. Estimated number of sessions is 5 – 8 with duration of
2 days each (total of 10 – 16 days of training). Training should include all relevant subjects which
are part of the Employee functionalities and include all training materials and documentation.
Other that on-site trainings, bidder should offer option for On-line training (On-line conference
sessions) which could include other potential users of the system, or eventually offer training
content which is adopted for some of the on-line learning platforms.

Guarantee period

The guarantee period for the delivered solution must be a minimum of 24 months from the signing
of the handover report. Handover report should include user acceptance documents and should be
signed by the beneficiaries and UNDP. The obligations of the supplier in the guarantee period are:
- Ensure smooth functioning of the system within the processes and tasks defined in the
document „Specification“ and GAP analysis, as well as in the signed handover report of final
testing and handover of the system.
- Provide regular real time support to users in their daily work, remote access, by telephone,
e-mail or in person if necessary
- Eliminate all the deficiencies in the operation of the system within the framework of existing
functionalities
- Monitor system performance and eliminate all the deficiencies in terms of inadequate
functioning or degradation of performance
- System corrections in case of changes of legislation or regulations
- Delivery of new versions of program modules which are subject to delivery, if the supplier
performs a system upgrade to a new version within the guarantee period
- Ensure a communication plan with a clearly defined method and contact persons who will be
responsible for the maintenance process by the supplier
- Ensure resolution of problems with the work of the system in accordance with the following:
o For all problems reported during the working hours and classified as „urgent“ the
response time should be a maximum of 2 working days from the time of reporting
o For all problems reported and not classified as „urgent“ the response time should be
3 working days

70
Maintenance after expiration of guarantee period

After the expiration of the guarantee period the contractor must provide the Cloud services to all
local LGs which decide to continue using the system from the Cloud. Contractor should clearly
define price of the Cloud services in the following way:
- Price of using the Cloud services for a month / year
- Price of application support for a month / year
These prices should be defined for individual LG which will decide to use the system, meaning that
each LG will pay its own part of using the Cloud and application support.
Within the maintenance contract, the contractor must clearly define the processes of changes and
upgrades on the system. For these processes, the following parameters should be defined:
- Maximum response time for a request to modify the system (response means the time of
submitting a bid)
- Maximum time for inception of work after acceptance of the bid
- Price for works per hour or per day
In the duration of the maintenance contract, the same conditions apply as during the guarantee
period.

71