Attachment 2 to RFQ MAR-013-G-002-2Detailed Terms of Reference

for Developing the Internal Portal of the Mariupol City Council

Contents1. Background............................................................................................................................4

1.1 Document purpose.........................................................................................................41.2 Purpose of the portal development.............................................................................41.3 Target audience..............................................................................................................41.4 Project boundaries.........................................................................................................4

2. Design requirements............................................................................................................52.1 General design requirements.......................................................................................52.2 Expected results of design development....................................................................5

3. Functional Requirements.....................................................................................................53.1 Users and roles...............................................................................................................53.2 Portal multilingualism.....................................................................................................63.3 Portal structure...............................................................................................................6

3.3.1 Structure of the homepage....................................................................................63.3.2 Structure of sections (menus)...............................................................................63.3.3 Structure of the portal pages...............................................................................11

3.4 The administrative section of portal management..................................................113.4.1 Requirements for managing the portal sections..............................................113.4.2 Content publishing................................................................................................113.4.3 Portal visit statistics..............................................................................................133.4.4 Portal Bin................................................................................................................133.4.5 Event log (optional)...............................................................................................13

3.5 Service modules...........................................................................................................143.5.1 Search.....................................................................................................................143.5.2 Feedback................................................................................................................14

3.6 Directories.....................................................................................................................144. Requirements for the design and implementation project............................................145. Requirements for the Bidder.............................................................................................156. Requirements for portal platform option for additional functionality............................157. Functional requirements for building a user support and user request processing services on the internal portal platform...................................................................................168. Non-functional requirements.............................................................................................18

8.1 Requirements for supported devices........................................................................188.2 Requirements for supported browsers and permissions.......................................188.3 Requirements for documentation...............................................................................188.4 Virtualization requirements.........................................................................................18

2

Annex 1 to the Terms of Reference Examples of homepage information boxes.............18

3

1. Background

At present, the Mariupol City Council does not have an internal portal for employees. An internal portal would significantly improve the interaction of structural units and increase the efficiency of the Mariupol City Council. It would facilitate access to information resources (data systems, skill management systems, etc.), allow process automation and adaptation of new employees.

1.1 Document purposeThese Terms of Reference define the development of the internal portal for the Mariupol City

Council. They contain a set of requirements to develop the portal structure, functionality and commissioning.

As part of the project implementation, the Contractor refines and expands the requirements and writes detailed Terms of Reference.

1.2 Purpose of the portal developmentTo create a new, full-fledged information resource with modern design and advanced functionality

for various groups of employees, which would be in line with modern technologies and trends:

• make the portal the primary source of information for employees in terms of activities of local self-government bodies and municipal utilities;

• create tools for communication and interaction among local government bodies.

Ways to achieve the goal:

updated, visually appealing design, portal structure, providing access to portal sections with minimum number of clicks;

an enhanced news section on the homepage and on the portal;

correct display of portal content on various browsers and devices (see section "Non-functional requirements");

convenient and intuitive portal navigation;

ability to manage content in sections by responsible units of the Mariupol City Council using the content creation, editing and publishing tools;

1.3 Target audience

Employees of local self-government bodies and city municipal utilities.

1.4 Project boundariesThe project scope of work includes the following areas:

Detailed scope of requirements and the structure and functionality description, development of detailed Terms of Reference;

Developing the portal design and page layouts; Desktop publishing; Developing the portal structure and functionality;

4

One-year warranty support services after the portal is launched into operation.

2. Design requirements

2.1 General design requirements Portal type: internal, informational; The portal appearance should be: business-like, informational, stylish, modern; The portal emphasis should be on providing information, usability, easy design; All portal pages should be set for the best 1280 px display. The total height of the

homepage content boxes should not exceed 3072 px. Portal positioning should be centered; Animation and vector graphics are at the designer's own discretion; The portal should be adapted for employees with visual impairments (switching to a

larger font). The Mariupol City Council logo has to be placed on the homepage, in line with the

organization's branding. The USAID logo has to be placed on the homepage, separate from the City Council logo,

in line with the organization's branding.

2.2 Expected results of design developmentThe portal has to be designed in a uniform style with the official design of the Mariupol City

Council website and the city branding.

The Contractor is expected to develop and agree with the Client: The homepage layout and menu layout of the portal (a conceptual outline of homepage

elements is provided in Section 3.1.1). Examples of homepage information boxes are provided in Appendix 1)

design layouts of the portal sections with dynamic content design layout of a standard page with static content with page element style sets

o Basic font;o Title (Level 1);o Title (Level 2);o Title (Level 3);o Numbered (including multi-level);o Bulleted;o Hyperlink;o Footnote;o Quoting style;o "Important" style;o Table design style;o Drawing style inside the texto Etc.

3. Functional Requirements

3.1 Users and rolesThere are two groups of users of the Mariupol City Council internal portal:

internal users.

5

city utility companies (with the ability to connect them to the portal functionality in the future)

Internal users include the following user groups: section experts (editors, moderators) - users of this group can be granted the following

rights: content creation, content publishing, creation of additional pages with static content;

administrators - users in this group can have the following rights: content management in all sections, managing the portal structure, menu structure, managing groups and user rights, etc.

The Administrator determines for each internal user the set of the sections, where the user can manage the content based on the portal structure. It should be possible to assign the right of managing specific sections to an individual user or a group of users.

In the administrative section, the administrator has to be able to see information (in a table format) about all users of the system, indicating the sections to which the user has access.

3.2 Portal multilingualismThe system should provide for the use of 2 language versions of the portal: Ukrainian (main) and

Russian (to be hidden if necessary). The Russian version is a clear repeat of the Ukrainian version.

3.3 Portal structure

3.3.1 Structure of the homepage

3.3.2 Structure of sections (menus) The Administrator must be able to manage tree (nodes) of the portal, that is to create, modify,

delete and move sections, subsections. Section moderators have to be able to create subsections in their sections.

6

The Administrator must be able to control the number of items at each level and the menu structure of the portal.

The table provides the primary proposed structure of the portal (as the Contractor details the project requirements, the structure may be adjusted).

Filling in all the above sections has to be done using the portal moderation panel. The moderator panel has to have basic controls for each section: search, filter, delete, modify, add information, and more. When publishing documents in the appropriate sections, the document name to be displayed must be specified additionally.

7

Section Subsection 1 Subsection 2 DescriptionComposition of homepage information boxes

The structure is provided in the attached file

1. Name and logo The name and logo are at the top

2. Box with panoramic image

Banner box. Displays one of the uploaded panoramic images randomly, with the ability to scroll to view other images.Image uploads should be available from the portal's moderator panel.

3. Menu section box

The first page displays menu items of the first level, the second level opens down, the third level to the right and down.

4. Announcement box

Located to the left on the homepage. Always displays the latest 3 to 4 news. On the left there is a list of 3 to 4 recent important news stories (small photo, title, heading and date of publication).There has to be access to the news archive (the news section opens with the ability to switch between columns)

5. Search service Searching for information on the website should be accessible on the portal homepage. The search result should be displayed on a new "Search result" page. When searching on the portal homepage, the search should cover all sections on all information published on the portal, including MS Word documents.

6. Box of important links to internal sections

Located on the right of the homepage of the portal. They are image/title elements with links to various internal or external sections. This list of links focuses the user's attention on a particular portal section (configured by the administrator). The placement of a link to an external resource should not be impossible.

7. Box of professional holidays

Located at the bottom of the homepage of the portal. Displays a list of holidays.

8. Box for new employees

The box is located on the left on the homepage under the box of announcements. It Is an element with the link to the general information page in the Structure section.

1. Structure1 1. Structure of the

City Council1. Structure of executive bodies

The current structure of City Council executive bodies is displayed as an image. Clicking on an image displays it in the full screen view.

1 2. Contacts of employees

The section shows the search by employee (his/her name) and by section (if known). Then, the full name, photo, position, department, unit, email, contact phone numbers (mobile and landline), address (viewable on the map), birthday (hidden) are displayed in the middle. To be included: the search by name, department, unit. When publishing, the Department and Unit value fields are selected from the list. It should be possible to change the list of values. When a value is renamed in the directory, it has to change as well in all the contact entries associated with it. When searching, the name of the department or unit has to be suggested when entering the first letters in the search box.

1 3. Birthdays The page shows birthdays today + birthdays in the next three days. Information is taken from the directory of employees; name, the date of birth, position, department are displayed.

1 4. For new employees

1. General Information

The page displays information about the working activity in the Mariupol City Council. Documents files (such as: work schedule, salary structure, areas of activity, career) are published in this section. A list of document names is displayed. When a document is published, the document name has to be inserted manually. Clicking on the document has to open it in a browser window.

8

2. Documents 1. Document templates

1. Document flow

The page displays a list of document templates that can be opened and saved.

2 1 2. IT applications

The page displays a list of document templates that can be opened and saved.

2 2. Electronic declarations (filing)

Instructions for using the e-declaration portal, etc.

2 3. Code of Ethics The page displays a pdf document.

3. HR section 1. Vacancies of the City Council

The page displays a link to a website section https://mariupolrada.gov.ua/ru/vacancies

3 2. Vacancies of utility companies

The page displays a link to the website section https://mariupolrada.gov.ua/ru/vacancies-u

3 3. Document templates

The page displays a list of document templates:- application for leave,- registration of sick leave,- vacation without pay with the ability to open and save them.

3 4. Annual staff evaluation

The page displays 3 sections containing the following document files:1. Stages of annual evaluation;2. Evaluation form template. (in the future the section will be automated with the ability of filling in the questionnaire online, saving it to the portal archive, sending it to the manager, evaluating the manager, agreeing with the manager, saving it in the archive).3. Appeal form template.4. Archive of filled evaluation forms (only the employee of the training department can see) The administrator should be able to form establish consolidated evaluation files by the categories of "managers", "employees" by individual structural units and by the Mariupol City Council as a whole, with the ability to automatically track quotas and import reports in Excel format.

3 5. Professional development

The following document files are displayed on the page:- List of courses, workshops, trainings, webinars, lectures (training topics and content, with the ability to complement it with new up-to-date training programs). Placement - in the form of boxes (1 box = 1 competence)- Training application template (to open and save it).- the ability to submit online training applications required for a specific category of workers, with the ability to import them- Training schedules.- Video courses (with the ability to comment and rate the course).All content, including video courses, has to be uploadable and deletable at any box at any time.

3 6. Regulations on bonus payments for the personnel

The page displays a pdf file. Document format

3 7. Feedback Clicking on the "Feedback" section opens a form for sending a message to be filled in by the visitor. It should contain the following fields:• Your Name, Surname and Patronymic (required)• Email (required)• Contact phone number (required)• Message text• Date (automatically)• Time (automatically)

9

• Direction (drop-down list)It should be possible to assign a separate moderator email address for each direction. When a visitor fills in the form and sends it, their information should arrive at the specified moderator's email address as a structured table, which is also stored in the relevant section in the portal moderation panel. The email subject has to contain the "Feedback" word in it. Also, the name of the portal section from which the information was sent.

4. News 1. News Archive The list of the latest 5 to 6 news stories has to be displayed with the ability to switch to earlier news pages. Top news stories are highlighted in the general list. The news list in the section contains the following information: Photo of the news, title, lead, paragraph, heading, date of publication. Sorting by publication date.It should be possible to switch to a specific heading (news filter).The section should have news search available by parameters: keywords, heading, Top News feature, search period.

10

3.3.3 Structure of the portal pages Portal pages displaying the relevant sections - the first, second and third levels - must be set in

the same style and contain a number of homepage elements, navigation elements by sections, as well as additional boxes of elements unique to the specific page (section).

Homepage Elements - items inherited from the homepage: Name and logo Menu section box The portal footer.

The line of the current portal section is the line, which is a hyperlink that reflects the current section of the portal which the user is browsing.

3.4 The administrative section of portal managementThe portal administrative section should only be accessible for portal administrators and moderators. Each portal moderator has to have access to only those sections that are defined in his/her access rights. It should be possible to assign the rights to moderate specific sections to individual moderators.

3.4.1 Requirements for managing the portal sectionsThe following features must be provided to manage the portal sections:

displaying the structure of the portal sections; creating a 1st level subsection; creating 2nd (and further) level subsections; creating and editing page content

o for standard pages - using a built-in text editor;o for pages where the content is published in special publication forms - using such forms;

deleting a section; moving a section up in the list; moving a section down in the list; "show" or "hide" options of the page in the client version of the portal; displaying the list of units of a selected level; managing the portal menu structure.

3.4.2 Content publishingThe portal content that is published in various sections can be static and dynamic.

Static content includes individual formatted articles (pages) containing text, graphics and other information.

Dynamic content is created on the basis of parameterized queries to specialized lists, tables of databases.

When publishing, modifying portal pages, including news, etc., the following data has to be registered automatically:

date and time of the last change; the user account that made the latest change.

The portal / portal section settings should have settings for limiting the size of files uploaded to the portal.

11

3.4.2.1 Publication of static contentA standard static content page is a static information page (text, photos, spreadsheets, attached

document links, and external links). The information location is determined in the process of adding the content using the built-in graphical content editor.

The portal should have the functionality to develop the portal content, which should be a multiline text editor, supporting styles, insertion of various graphic elements, tables, graphs, links. Also, the system should provide a preview of the prepared content before publishing it on the portal.

The text editor has to have preconfigured text and graphic elements that match the overall design of the portal. These ar, at least, the styles of the following elements:

Body text; Title (Level 1); Title (Level 2); Title (Level 3); Numbered text (including multi-level); Marked text; Hyperlink; Footnote; Quoting style; "Important" style; Several table styles; Styles of drawings to be embedded in the text

The user should be able to adjust the layout style (font, size, color, alignment, indentation, etc.) , if necessary.

It should be possible to add links to documents inside the text as well as insert graphic images by uploading them from the PC.

In addition, HTML content must be editable.

In its general view, the embedded graphics editor toolbar might look like this:

The publishing process consists of the following steps:

Preparing a new page (editing an existing one) by the section owner; Preview and saving of the page; Publishing content on the portal. The publishing process consists of the following steps:

3.4.2.2 Dynamic content publishingThe portal should ensure publishing of the content generated by queries for the lists and system

database.This functionality has to allow filling the portal pages (sections) with content in a dynamic manner,

without editing the entire pages.The portal has to provide a tool to handle the list data: adding, modifying, and deleting data on

the lists.The lists are filled by section owners and content managers.The results of content queries must be set and formatted to meet design requirements.The structure of sections with dynamic content is described in "Structure of sections (menu) of the

portal". Sections with dynamic content should be created on the basis of developed templates. At the 12

same time, tools should be envisaged and developed that will allow the Client to create new sections independently based on the existing section templates with dynamic content.

It is important that dynamic content pages retain the function of adding static content in the appropriate editor before and after the dynamic content box.

3.4.2.3 Publication of photo materialsThe portal must provide a tool for uploading and publishing photo materials.

The upload tool must allow uploading any number at a time, with the tag being specified once for all images.

When publishing photo reports, the relevant information fields provided in the section are also filled in.

3.4.2.4 Publishing of video materialsThe portal must provide a functionality to publish videos from Youtube.

It should be possible to place an uploaded photo as a preview.

When publishing videos in the relevant section, the information fields provided by the section are also filled in.

3.4.3 Portal visit statisticsUsers who have certain access rights (defined by the System Administrator) should be able to

view portal visit statistics for any period of time. Each of the reports should be in the form of a graph and a diagram. The following reports should be generated by the system:

General Statistics - General information about the number of visitors daily; Daily Visits - Displays the number of visitors every day and the number of views or pages; Hourly visits - Displays the number of hourly visits; Monthly Visits - Displays the total number of visitors and the number of pages viewed by them; Popular pages - Displays the dynamics of browsing on individual portal pages;

3.4.4 Portal BinAll deleted data, pages should be placed in the "Portal Bin", indicating the date, time of deletion and the account that did the deletion. The Bin must provide the data storage for at least 3 months.

3.4.5 Event log (optional)The system should track changes to all system components run by administrators, content

managers, and section experts, namely:

Audit of changes to user rights; Audit of portal structure changes; Audit of page layout changes; Audit of page changes; Audit of document changes;

Viewing the change logs has to be available in the administrative section of the portal to system users, based on their access rights.

13

3.5 Service modules

3.5.1 SearchSearching for information on the website should be accessible on the homepage of the portal.

The search result should be displayed on a new "Search result" page. When searching on the portal homepage, the search must be carried out in all sections.

The portal must have an advanced search functionality by individual criteria or details, as well as full-text search in the contents of documents. It should be possible to sort and filter search results and download them as a CSV file.

3.5.2 FeedbackIt should be possible to add a "Feedback" item in any portal section; clicking on it has to open a

form for writing and sending a feedback message. The form has to have the following fields:

Your Name, Surname and Patronymic (required)

Email (required)

Contact phone number (required)

Message body

Date (automatically)

Time (automatically)

Direction (drop-down list)

It should be possible to assign a separate moderator email address for each area. When a visitor fills in the form and sends it, their information should arrive at the specified moderator's email address as a structured table, which is also stored in the relevant section in the portal moderation panel. The email subject has to contain the "Feedback" word in it. It has to be followed by the portal section name from which the information is sent. The feedback data sent from all the sections have to accumulate in ONE portal table in the administrative section with the ability to filter them by date and by section name.

3.6 Directories

As part of the project, the Contractor has to specify the composition of directories.

4. Requirements for the design and implementation projectThe Contractor shall ensure a complete turnkey solution, including:

1. Appointing a project manager on the Contractor's side for planning and coordinating the works as well as communicating with the Client.

2. Developing and agreeing with the Client a detailed plan for the portal development and implementation.

3. Developing detailed Terms of Reference and agreeing them with the Client.4. Customizing the software and developing the functionality required.5. Demonstrating the developed functionality to the Client, as well as testing and resolving the

issues found.6. Developing and agreeing with the Client a project documentation package, which would contain

at least the following:

7. Providing video instructions for using the system's functionality at the request of the Client;8. Providing support for the system and support for the Client's project team during commissioning.

9. Providing one-year warranty support and system maintenance after the system launch (which should include error correction, consulting Client's specialists on changes in the system settings, installing system updates released during the support period).

14

5. Requirements for the Bidder

1. The supplier must have a successful track record of designing and implementing internal or external portals and workflow automation systems. Supporting materials should be provided in the form of references describing such solutions and video materials demonstrating the operation of the automated processes.

2. The bidder has to provide documentary evidence of the working experience with the Open Source platform being offered (a process automation and document processing system built on such a platform should be available, etc.).

6. Requirements for portal platform option for additional functionality

The portal should be developed on the basis of a replicated industrial Open Source platform (indicating the full name of the replicated industrial Open Source platform). The Open Source platform on which the portal is to be built should provide management of documents, records, web server publishing, group work and business processes, and should include:

content repository;

workflow;

ready to use web server portal;

CMS for managing and using standard portal content;

industrial interfaces of interaction with external systems based on SOAP and REST;

CIFS interface that provides compatibility with Microsoft Windows and Unix OS filesystems

over the Internet;

web content management system with the ability to virtualize web server applications and

static websites, etc.

The "Open Source platform" means an industrial replicated open source platform that, at the time of bidding, is distributed on the basis of a free license (e.g. GPL, LGPL, MIT, Apache); there should be an option to download the platform from the Internet free of charge. The proposed Open Source platform under the licensing rules existing at the date of publication of the call for bids should not require any costs to purchase the platform, update the platform versions, change the number of users, etc. Free development tools or individual free components shall not be considered an Open source replicated platform.

The platform should use a free industrial relational database management system: PostgreSQL, MySQL, or an equivalent. The offered free DBMSs should not have functional and software/hardware limitations on the performance and information storage.

The platform should include a functionality (kit) for business process development.

The platform has to ensure displaying of office, text, scanned documents without installing external applications (MS Office, OpenOffice) at client workstations.

The platform has to support the shared editing of electronic documents using the Electronic Digital Signature.

The platform has to support file storage encryption.

The portal should ensure:

user authentication using one of the common procedures and tools (login password, MS Active Directory tools with support for Single Sign On (SSO) technology, EDS) and user accounts;

15

a flexible access control tool and role determination of user access rights to portal documents, functions and items;

document version control (ability to maintain a document version; save all document changes, see changes in participants, return to a previous version of the document)

informing users about the status of documents, assignments and other events on the portal, using user accounts, email, and messengers;

the ability to create, configure and apply document templates;

the ability to scan directly into the document card;

the abillity to create directories based on various features;

complete logging of user actions on the system.

The platform for the portal implementation to be selected by the Contractor has to allow further extension of the portal functionality during the following stages of the project. At least the following functionality is seen as useful, for example:

1. Automation of the Service Desk system and incident management process (implemented at the current stage), functional requirements for which are provided in Section 6.

2. Automation of the annual staff evaluation process. The essence of automation: According to the City Council's structure, each employee conducts a self-assessment of their activity over the past year at the beginning of the new year, using an assessment form with certain criteria and the scale of assessments, and then the assessment is conducted by their manager. As a result, the ratings for each subdivision should be automatically created, and consolidated into ratings according to the vertical organization structure from the bottom upwards, in line with certain structuring algorithms. In certain steps, certain user roles may correct the data. Forms may need to be printed at certain steps of the process.

3. User authorization to run and participate in certain portal processes (integration with Microsoft AD).

4. Creation of a personal employee account (consolidated data on vacations, business trips, salaries, etc.).

7. Functional requirements for building a user support and user request processing services on the internal portal platform

The Service Desk system has to:1. Ensure the functioning of a single end-user contact center and the receipt of IT incidents or changes

to IT systems;2. Support integration with Active Directory in the part of system user data uploading (author of

therequest), division, department, position, email, etc.3. Include functionality for: Incident management and change management in IT systems:

3.1. Receiving and registering user requests using channels:3.1.1.By telephone, with the operator registering the request where:a) User data is pulled up from the Active Directory (at least, full name, position, telephone,

email, unit). If the person does not have an Active Directory account, it should be possible for the operator to enter the person's data manually.

b) It must be possible to change the mobile phone number when registering, if downloaded from AD.

c) The type of request (Incident or change in IT systems) is specified. Different types of requests have different sets of IT services, specialist teams, and resolution times.

d) Manual entering of data: the request name and essence of the incident, and attaches files, if necessary.

e) Assigning a category to the incident according to the list of IT services.

16

f) Resoltion time should be automatically set depending on the selected IT service (changeable). The deadline is set taking into account weekends (Saturday, Sunday) and working hours from 8:00 to 17:00.

g) The group of responsible IT support specialists is automatically set depending on the selected IT service (changeable).

h) It should be possible to view information about the latest requests of the current user from the request form;

i) Number, date and registration time should be registered automaticallyj) After registering, the user automatically receives an email with a notification of his/her

request registration, indicating: the number, the period of resolution. In addition, all messages sent to users include standard contact information for contacting the IT department

3.1.2.By email, with:a) Requests that have been received at the IT support email are automatically entered into the

system.b) User information is taken from the sender's data (if the email is sent from an internal

Exchange server), otherwise only the sender’s email address is filled in.c) The request name is filled in with the email subject, the request essence is filled in with the

email body text (the email is attached to the request)d) Attachments should be automatically pulled from the email attachments

Requests received in this way are stored in the Project status and require additional processing by the operator. After supplementing the request, the operator registers it. During the registration stage, it should be possible to change the contact details of the contacting user. Then the user receives a message on his/her e-mail.

3.1.3.By the internal portal form, at the same time:3.1.3.1. The user fills in the online form (name, essence, files, screenshots)3.1.3.2. Sender’s contact information is automatically generated from the portal data

(name, department, position, e-mail, etc.). The mobile phone number is added in a separate field.

3.1.3.3. After filling in the form, the request arrives in the project support service with the "Project" status. After supplementing the request, the operator registers it. During the registration stage, it should be possible to change the contact details of the contacting user. Then the user receives a message on his/her e-mail.

3.2. Including the tools for processing registered requests:3.2.1.The requests assigned to a responsible group of IT support specialists are visible to all

members of the group.3.2.2.The IT support group can either take on the job by themselves, or they can be appointed by

the group leader.3.2.3.The time of taking on and fulfilling the task has to be automatically recorded by the system.3.2.4.After completion, the IT support specialist has to provide an explanation before closing the

request, briefly describing the nature of the work done.3.2.5.Also, the status of the request has to be indicated: successful (default) or unsuccessful.3.2.6.For change requests, it must be possible to suspend the work on a specific request, with

the deadline being postponed to the suspension period.3.2.7.When working on the request, the IT support specialist provides short explanations for the

solution with an ability to attach a file. When the request is completed, the user receives an email notification indicating the request number and name.

3.2.8.The IT support specialist has to be able to send an email to the user using the request interface; this information should be attached to the request, and the follow-up responses from the user should be automatically attached to the request as well.

3.2.9.Each IT support specialist must be able to sort and filter the requests in the list.3.2.10. It should be possible to search for requests by their number, date, topic, essence, user,

user unit, IT service telephone number, IT support specialist, IT support group. A full-text search on all requests should also be available.

3.2.11. Pre-configured incident and change reports have to be kept with period sampling and possibility of downloading as an Excel file.

3.2.12. Analytics by IT support specialists and IT support groups (number of requests, number of requests resolved in time, number of those overdue, etc.).

3.2.13. Analytics by services (number of requests, number of those resolved in time, number of those overdue, etc.)

3.2.14. Analytics by the stages of request resolution (registered, accepted, completed) and by IT support specialists.

17

3.2.15. It should also be possible to download all data (all fields in the request card) for the requests within a specified period as an Excel file for further analysis

8. Non-functional requirements

8.1 Requirements for supported devices Adequate display of the portal should be supported on mobile devices, such as tablets and

smartphones on iOS, Android 4.0 and higher, Windows Mobile platforms.

When opening on mobile devices with a screen width of less than 1280 pixels, the page should be scaled (adjusted) to the screen width, by reducing the overall scale, with no changes in the relative position of the subject boxes and content.

8.2 Requirements for supported browsers and permissions

The portal should ensure the correct display of data in the following browsers:

Internet Edge (version 42.0 and higher); Mozilla Firefox (version 64.0 and higher); Google Chrome (version 71.0 or higher) Safari (version 8.0 and higher); Mobile clients: IOS (Safari), Nokia, MS Mobile Explorer, Google Chrome.

8.3 Requirements for documentation The system has to be accompanied with the following documentation:

Administrator's System Deployment and Settings Guide; Administrator's System Operation Manual; Content Manager Guide.

8.4 Virtualization requirements When building the solution architecture, a virtualization system should be used to increase the efficient

use of hardware resources.

Annex 1 to the Terms of Reference Examples of homepage information boxes

18

19

20

21