E-PROCUREMENT SYSTEM User Requirements and Technical

`

E-Procurement Implementation

1

USAID | Regional

Intergovernmental Organization

(RIGO) System Strengthening

E-PROCUREMENT SYSTEM

User Requirements and Technical Specifications Document

(URD/TSD)

`


2

Content Page

1.0 Introduction 6

2.0 Public e-Procurement Overview 7

2.1 Expected Operating Environment 7

2.2 Key Modules 8

2.2.1 Portal System 8

2.2.2 e-Registration 8

2.2.3 e-Bidding System 8

2.2.4 e-Contract 8

2.2.5 Contract Management System 9

2.2.6 Reporting and Statistics System 9

2.2.7 Linked Systems (Integration/Interfacing) 9

2.2.8 Systems/User entities 9

3.0 Detailed User/Technical Requirement 10

3.1 Functional Requirements 10

3.1.1 e-Requirements Portal System 10

3.1.2 Platform Graphics User Interface 11

3.1.3 e-Registration 12

3.1.3.1 Authentication 14

3.1.3.2 Authorization 14

3.1.3.4 Management 15

3.1.4 Search 16

3.1.4.1 Configuration 16

3.1.4.2 Organizational Search 17

3.1.4.3 Users Search 17

3.1.4.4 Tenders Search 18

3.1.4.5 Notices Search 18

3.1.4.6 Contracts Search 19

3.1.4.7 Catalogues Search 19

3.1.5 e-Procurement Planning 19

3.1.5.1 Process Management 20

3.1.5.2 Publication 21

3.1.6 e-Publication/Notification 22

3.1.6.1 Tender workspace/workflow set up 22

3.1.6.2 Officer Association 23

3.1.6.3Preparation of bidding documents by CA 25

3.1.6.4Tender Questionnaire 25

3.1.6.5Completion Publication/Activation 26

3.1.7 E-Tendering 29

3.1.7.1Questions/Answers 29

3.1.7.2Creation and Submission of bids 30

`


3

3.1.7.3Securities/Guarantees 32

3.1.8 e-Awarding 33

3.1.8.1 Bid Opening 33

3.1.8.2 Offline Bids 34

3.1.8.3 Bid Evaluation 35

3.1.8.4 Standstill Period/Complaints 36

3.1.8.5 Contract Award 36

3.1.9 e-Reverse Auction 38

3.1.9.1e-Auction event room set up and invitations 38

3.1.9.2 e-Auction event execution and closure 39

3.1.10 Contract Management 40

3.1.10.1 Deliverables 40

3.1.11 e-Prequalification Management 41

3.1.12 Reporting 41

3.1.12.1 Notifications 41

3.1.12.2 Auditing 43

3.1.12.3 Reporting 43

3.1.12.4 Open Contracting Data Standards (OCDS) 44

3.2 Non- Functional Requirements 45

3.2.1 Security 45

3.2.2 Auditability 45

3.2.3 Extendibility 46

3.2.4 Portability 46

3.2.5 Reliability 47

3.2.6 Usability 47

3.2.7 Performance 47

3.2.8 Interoperability 48

4.0 Consultant Responsibilities and Experience 49

4.1 Duties and Responsibilities 49

4.2 Firms Experience 49

4.3 Key Staff Qualifications Requirements 50

`


4

ACRONYMS

AJAX – Asynchronous JavaScript and XML

BE – Bid Evaluation

BO – Bid Opening

CA – Contracting Authority

CPB – Central Purchasing Body

CPV– Common Procurement Vocabulary

CW – Catalogue Workspace

CWM – Catalogue Workspace Manager

CfT – Call for Tender

DDoS – Distributed Denial-of-Service

DOC – Microsoft Word Binary File Format

DoS – Denial-of-Service

EO –economic operator

FAQ – Frequently Asked Questions

GUI – Graphics User Interface

HTML – Hypertext Markup Language

HTTPS – Hypertext Transfer Protocol Secure

HW – Hardware

ID – Identification number

LAN – Local Area Network

MEAT - most economically advantageous tender

MVC – Model View Controller

OCDS – Open Contracting Data Standard

NGO – non-governmental organisation

OCDS – Open Contracting Data Standard

PDF – Adobe Portable Document Format

LPO – Local Purchase Order

PPO – Procurement Office

SOA – Service Oriented Architecture

SKU – Stock Keeping Unit

SQL – Structured Query Language

SW – Software

TE – Tender Evaluation

TC – Tender Coordinator

TO – Tender Opening

TPT – Tender Preparation Tool

TXT – Text File

WB– the World Bank

XLS – Microsoft Excel Binary File Format

XML – Extensible Mark-up Language

XSS – Cross-Site Scripting

`


5

1.0 Introduction

This document describes user requirements and the technical specifications for an online procurement,

e-Procurement, and system for the East African Community to support their procurement function.

The purpose of this document is set out the requirements and technical specifications in detail as basis

for service providers to prepare proposals for consideration. The documents is structured as follows:

Section 2: System overview describes the background to the current operating environment and the

environment after the completion of the project. It also sets out the key components

(modules) of the proposed system.

Section 3: Detailed System Description describes all functional and non-functional components of the

proposed eProcurement System;

Section 4: Experience and Capability sets out the experience that the bidder must demonstrate, and

staff required to perform the assignment.

2.0 Public e-Procurement overview

2.1 Expected Operating environment

The new e-Procurement system will have to ensure alignment with the EAC procedural

requirements and relevant legal norms. Developing e-procurement has the following benefits:

(a) Reduced paperwork;

(b) Increased productivity;

(c) Eliminates paperwork; and

(d) Transparent spending and reduced errors.

Below is a comparison of the current (AS-IS) and the targeted (TO-BE) systems:

`


6

2.2 Key Modules

2.2.1 Portal System

Portal system is an integrated gateway to support smooth business processing and to

provide integrated information of public procurement. The system provides whole

services in single window and unified user environment. Therefore, users can access the

necessary information in one website.

User interface will be designed with multiple language capability, and major information

services are integrated including bid notice, regulations, procurement business information

and administrator’s function.

2.2.2 e-Registration System

E-Registration system provides users registration function (procurement entities, supplier,

and administrators) including their approval or rejection function. It also provides

information to other sub-systems.

2.2.3 e-Bidding System

e-Bidding system is the most effective system among the e-Procurement services. e-

Bidding system is used to prepare e-procurement plans, e-publishing (advertise tenders),

search bid information, e-submission (submit the bid document), e-evaluation, check the

result of open bid and select winner on-line. Procurement officer can notify the bid

information, receive the supplier’s bid documents electronically, open the bid

automatically and select a winner.

PortalSupplier/User Registration

e-Bidding e-Contract

Contract Management

Reporting Audit

Financial/ERP

systems

Asset/Inventory

Management

E-PROCUREMENT SYSTEM MODULES

Suppliers Procuring Entities Administrators

`


7

2.2.4 e-Contract System

Procurement entities and suppliers can make contracts using standard electronic

documents without visiting and stamping. e-Contract system provides standard contract

format and user draft contract information without on-line bidding. The institutions and

suppliers can reduce time & expenses and enhance business productivity by e-Contract

system. An e-signature tool such as digital certificate is important to include.

2.2.5 Contract Management System

Contract Management is one of the key stages in the procurement cycle. The e-

Procurement system will allow bidders and contract managers to interact online

transparently to management and easily identify communicate disputes and delays.

2.2.6 Reporting & statistics system

Most automated systems become useful by providing key information to key stakeholders

and decision makers. The intended system will provide these data in real time.

2.2.7 Linked (interface/Integrated) system

The new e-Procurement system will be required to exchange information with other

existing applications – various such as assets and inventory management systems.

3.0 Detailed User Requirements

3.1 Functional Requirements

3.1.1 e-Procurement Portal System

The e-Procurement portal should be transparent to the end users. They should be enabled to

use a graphical user interface that supports all stages of e-Procurement. All the necessary

information should be automatically transferred between the system’s modules.

Through this module, authentication will be conducted by implementing single Sign-On concept

which will in effect seamlessly authenticate to all integrated modules of the system.

In addition, the e-Procurement Portal, should offer key language as English and where necessary

multi-lingual capabilities that enable the use and support of multilingual features of the System.

The module also should support the hosting of multimedia material, which commonly is used for

material for the “self-training” of users (e.g., Computer-based Training material). Such material

forms, but is not limited to:

(a) Multimedia content (audio, video, image, and textual document);

(b) Animation in presentation;

(c) Step-by-step instruction guides.

The module should support digital signatures (e-Signatures) which are used during the electronic

signing of documents with legal value (tender responses/ purchase orders / user agreement /

awarding documents / contracts).

`


8

3.1.2 Platform Graphics User Interface

Important

1. Secondary functionalities should be supported by web interface, such as news,

frequently asked questions (FAQ) and an online help service that comprises a

computer-based training tool, too.

2. The web pages should feature items such as: Static and dynamic HTML;

Background icons; Links and navigation buttons; Various forms; Search engine.

3. The modular structure of the Platform should be transparent for the end users,

enabling them to use web interface which supports all stages of e-Procurement.

This means that all the necessary information is automatically transferred

seamlessly between the e-Procurement modules.

4. The GUI should be implemented as single Sign-On module, which enables users

to seamlessly authenticate to all integrated modules of the platform.

5. The GUI should support the hosting of multimedia material, which is commonly

used for material aiming to facilitate the “self-training” of users (e.g., Computer-

based Training material). Such material forms but is not limited to: Multimedia

content (audio, video, image, and textual document); Animation in presentation;

Step-by-step instruction guides.

6. The GUI features modern and proven client-side implementation technologies,

such as JavaScript and AJAX, utilised to provide real-time interaction with users.

7. The GUI should support digital signatures (e-Signatures) which are used during

the electronic signing of particular documents with legal value (tender responses/

purchase orders / user agreement / awarding documents / contracts, purchase

orders).

8. The Module should support a detailed audit trail log that registers all user login

information and any other activity affecting the database or any action performed

by the user on the system.

9. The email notification mechanism of the Module supports a dedicated notification

being dispatched to the users when specific actions are performed. By the

notification mechanism, the users are kept informed for all competitions,

contracts and catalogues of interest.

3.1.3 e-Registration

E-Registration Module should employ user management and include functions such as registration,

verification, and approval.

A single interface for the registration of stakeholders who intend to use the e-Procurement Portal

must be provided. Suppliers should be able to register themselves in order to participate in tenders.

Every user registered on the e-Procurement Portal should be associated to an EAC organ /Institution

within each organisation/Institutions, different user roles should be supported. Once users have

registered, the information should be saved in the database for further use.

`


9

3.1.4 Registration

Mandatory

1. The system must allow the non-authenticated users to access the registration

page and complete the required details for their company as well as for their user

accounts.

2. The system must use a security mechanism for protection of unwanted

registration e.g., Captcha Code.

3. The system must provide a mechanism for administrator user to validate the

provided details that the user filled in.

4. The system must allow the system administrator users to register, view and edit

user accounts, as well as to register, view and edit contracting Authority

Institution/ organizations and their respective users. All of such events shall be

captured in the audit logs.

5. The system must allow user passwords in line with the password configuration

defined by the System Administrator.

6. The system must enable administrator user to register other users under his

company. Within the same company, multiple access rights for each user must be

supported (multiple user roles).

7. The system shall assign a unique identification number (ID) to each registered

organization/user.

Important

1. The details of the different EAC institutions / Organs should have the following

fields but not limited to these only: EAC Organ/Institution name, Organisation type,

etc.

2. The details of the user account should have the following fields but not limited to

these only: first name, last name, username, password, email address, phone

number, user role, etc.

3. The system should display the appropriate message in case the same

organization/user is already registered within the system.

4. The system should send email notifications to the system administrators upon new

economic operator (EO) registration for validation and/or approval/rejection of the

EO access of the e-Procurement Portal.

5. The system should notify the user through email about his registration

confirmation, including details about the activation of his account.

6. The system should allow administrator user to register other Administrator users.

7. The system should allow administrator user to deactivate organization/user, in

effect forbidding such organization/user to authenticate or participate in e-

Tendering process.

`


10

Desirable

1. The system might accept entry of the details, either with the data entry from

the user or by retrieving the data from the any Supplier Registry system.

2. The system might use usernames in all confirmation and information mails sent

to users.

3. The system might be able to allow Administrator users to define the hierarchy

of Contracting Authority (CA) in any of EAC Institution/ Organ by defining the

parent-child relationship between CAs.

3.1.5 Authentication

Mandatory

1. The system must provide means of user authentication and verification through login

mechanism. All system users (System Administrator, user department/ Unit,

Contracting Authority and other stakeholder users) must provide their username and

password in order to be successfully authenticated and verified.

2. The system must provide Individuals/ Companies not registered on the system ability

to view publicly available information/ Tenders.

3. The system must allow for the System Administrator to release a locked-out user.

Important

1. The system should implement pre-defined session timeout mechanism. This means that

after a period, inactive users will be automatically logged out.

2. The system should feature a safeguard against "password that was forgotten".

Mechanism should be made available to the users to safely unlock their respective

account.

3. The system should allow for definition of the maximum number of unsuccessful log-in

attempts for registered user. If a user exceeds the maximum number of unsuccessful

log-in attempts, system should lock-out the user from the system.

Desirable

1. The system might oblige users to accept a User Agreement / Terms and Conditions

text before granting full access to the system functionalities.

`


11

3.1.6 Authorization

Mandatory

1. System must be built to follow a Role-based-access-control (RBAC) architecture.

RBAC is a policy neutral access control mechanism defined around roles and privileges.

2. The system must assign each user access privileges in the form of roles with each role

describing a position within the functions of the e-Procurement. A user, who has more

than one role, will have the rights of all those roles. Each role shall be defined with

adequate privileges to carry out the responsibilities assigned to that role. Role

privileges determine how data is accessed (via workflow, task and/or service), and the

operations, which can be carried out.

3. The system must apply restrictions compliant to user roles (e.g., a user cannot change

the password of another user with higher ranking role.)

4. The system must restrict user to perform task only through the system service to

which he/she has access.

Desirable

1. The system might support creation of a consolidated task-list for authenticated user,

generated by capturing all the tasks pending for the logged in user in various modules.

3.1.7 Management

Mandatory

1. The system must allow possibility for administrator user to review and approve/reject

registration requests; also, administrator user must be able to change status at any

time. This mechanism ensures that only approved can submit bids.

2. The system must allow users to be able to modify specific information of their profile.

Some critical information (e.g., role) should only be managed by authorized personnel

(e.g. administrator users or system Administrator).

3. The system must allow administrator users (system administrator or organization

administrators) to modify role of the registered user.

4. The system must allow administrator users (system administrator or organization

administrators) to be able to modify specific information in a registered user profile.

5. The system must allow for both registered and unregistered users to have an access to

CA profile details.

6. The system must allow System Administrator and CA users to view others details.

3.1.4 Search

The web GUI should provide search functionality in each of the registries in two basic forms:

(a) A quick search mode, providing just a basic list of search fields for each target entity;

(b) An advanced search mode, providing the full range of supported search fields.

This approach will help the users to find their results in a faster way and also to use specific

criteria for their results.

`


12

The search results list should display relevant information for each result, and the results should

be clickable to allow the user to navigate to the respective component responsible of managing

the full data. For example, when searching for users, a user should be able to click on one of

the search results of their query and then to navigate to the relevant user profile to view/edit

the full details of the profile they clicked on. The relevant actions of the logged user should be

dependent to the level of his access. Therefore, some actions should be prohibited according to

user’s role (e.g., edit profile).

3.1.4.1 Configuration

Mandatory

1. The system must allow both authenticated and non-authenticated users to have an

option to use quick or advanced search.

2. The system must prohibit actions according to Access Level Control rules defined

for authenticated user.

Important

1. The system should allow users to export search results in commonly used file

formats (e.g. CSV, spreadsheet). Operation could limit the number of search

results that can be exported.

2. The search results list should display relevant information for each result, and the

results should be clickable to allow the user to navigate to the respective item.

Desirable

1. The system could enable authenticated users to configure the number of results per page.

2. The system could allow authenticated users to save their favourite searches.

3.1.4.2 Organizations Search

Mandatory

1. The search engine must accept various search criteria including:

a. For CA search: name, address.

b. For EO search: name, address, CPV, geographical coverage,

national/international vendor, preferred supplier status.

2. The allowed search actions of the users must be dependent to the level of their access:

a. System Administrator and CA users must be able to search for EO and CA

organisations.

b. EO users must be able to search for CA organs/ Institutions.

3. The system must enable administrator users to search EOs based on different criteria

(e.g., performance).

Important

`


13

1. The system must enable non authenticated users to search for CAs. Typical search

parameters include name, address.

3.1.4.3 Users Search

Mandatory

1. The search engine will accept various search criteria including:

a. Name, Surname, username, email, organisation, country.

2. The allowed users search actions must be dependent to the level of their access:

a. System Administrator and CA users must be able to search for CA users.

b. The users must be able to search for their organ/institution users as well as for

CA users.

c. Non-authenticated users must not be allowed to search for users.

d. There must be controls for CA users for enabling the search/view only

designated "contact point" users of CA rather than the full set of users.

3.1.4.4 Tenders Search

Mandatory


a. Name, tender reference number, Common Procurement Vocabulary (CPV), CA,

procedure, status.

2. The allowed search actions of the users should depend on the level of their access:

a. System Administrator users must be enabled to search for all tenders.

b. CA and non-authenticated users must be enabled to search for published tenders.

c. CA users must be enabled to search for draft/restricted tenders that they are

associated with.

d. Economic Operator (EO) users must be enabled to search for restricted tenders

that they are associated with.

3.1.4.5 Notices Search

Mandatory


a. Notice type, CA, publication date, CPV.

2. All types of users should be able to search for Notices.

3.1.4.6 Contracts Search

Mandatory


`


14

a. Notice type, CA, publication date, CPV.

2. The allowed search actions of the users should depend on the level of their access:

a. System Administrator users must be enabled to search for all contracts.

b. CA and EO users must be enabled to search for Contracts they are associated

with.

c. Non-authenticated users must be enabled to search only for publicly available

contracts.

3.1.4.7 Catalogues Search

Mandatory

1. The search engine will accept various search criteria including:

a. Workspace name, workspace reference number, expiration date, CPV.

2. The system must enable authenticated users to search for Catalogues they have access

to and view their details. Typical search parameters include workspace reference

number, catalogue name, catalogue ID, EO name.

3. The system must enable authenticated users to search for Catalogue items they have

access to and view their details. Typical search parameters include workspace

reference number, catalogue ID, EO name, Stock Keeping Unit, item name,

manufacturer.

3.1.5 e-Procurement Planning

This module should support creation, amendment and publishing annual Procurement plans of the

CAs, to enable concerned EOs to plan their involvement in CAs future tenders.

3.1.5.1 Process Management

Mandatory

1. The system must support a periodic process of procurement planning. Registered CAs

must annually initiate a process of creating and publishing of procurement plans.

2. The system must allow the administrator user to issue a request for procurement plan

to be created to all registered CAs. This request will be in a form of a task which

appears in a CA Procurement administrator’s workspace.

3. The system must provide option to define a deadline for the submission of the CA

plans. This option will be available when administrator user creates request for

procurement plan.

4. The system must allow CA procurement administrator to download the available

Procurement Plan templates to create plans for their CA.

5. The Procurement Plan template that is provided by system must allow CA users to

describe all necessary aspects of each Item which will be procured. These aspects can

be procurement type (Supplies, Works or Services), Name, CPV, Reference number,

Description, Quantity in unit, Measurement unit, Estimated Budget, Procurement

`


15

method, estimated dates of procurement publication, envisaged start and award dates,

Comments, etc.

6. The system must allow CA users to upload a created Procurement Plan based on the

provided template.

7. The system must validate the structure and content of an uploaded Procurement plan

to ensure that created plan contains valid and relevant data. It must be possible to

programmatically check the format of Procurement plan. The system could inform the

CA user of any identified errors in the form of an Error Report.

8. The system must allow CA users to upload newer versions of a procurement plan

before the defined deadline. Previous versions could be overwritten.

9. System must record the date and time of the Procurement plan submission and the

CA user that performed it. All of such events shall be recorded in the audit log.

Important

1. The system should present Procurement Plan template in a user-friendly and human-

readable format (e.g. spreadsheet).

2. The Procurement Plan template should be created in a way that it clearly marks the

minimum information required to be accepted as a valid plan by the System, upon its

submission.

3.1.5.2 Publication

Mandatory

1. The system must support the final Procurement plan publication by the CA. A

Procurement plan will be publicly available after this action.

Important

1. The system should support that the EAC portal for procurement –

(https://www.eac.int/opportunities/procurement-procedures), in accordance

with current and future law receives via e-Mail or through developed

integration Web Service, published Procurement Plan.

https://www.eac.int/opportunities/procurement-procedures

`


16

3.1.6 e-Publication / Notification

The e-Notification module should enable the CAs to create and publish the Calls for Tenders and

contract notices for the interested EOs and general public overview. Additionally, support for easy

electronic access to tender documents and clarifications should be implemented. Once a CA decides

to commence work for a new tender, its users will be able to utilise the module in order to online

prepare all necessary documentation. The principle of pre-population of all known data should exist,

as this reduces workload of the users and minimizes the possible errors. Also, validation functionality

must exist for each tender workflow process. The e-Notification Module should provide template

forms for creating tender documents depending on specific procurement methods. This template forms

should be pre-populated with known data and must be validated for correctness of user entered data.

3.1.6.1 Tender workspace creation and workflow setup

Mandatory

1. The system must present an authorized user with clear process for setting up a

tender in a form of workflow for the necessary actions.

2. The system must allow authorized CA users to be able to create a draft Tender

workspace for a Public Contract or Framework Agreement. In this Tender

workspace a number of tender meta-data which describe the tender must be

defined. This meta-data will be used through the e-Procurement modules.

3. The system must support definition of meta-data for different procurement

methods such as Open bidding, Restricted bidding, Negotiated bidding, etc. in

Tender workspace.

4. The system must support definition of meta-data for tenders evaluation based on

solely financial criteria (i.e. Lowest Price).

5. The system must support definition of meta-data for evaluation of tenders based

on quality-cost combination (i.e. Most Economically Advantageous Tender or

MEAT).

6. The system must support definition of meta-data for time-limit rules (e.g. bid

submission deadline). Setup and modification of such deadlines can be possible only

at specific workflow steps in the Tender lifecycle.

7. The system must allow authorized CA users to edit the details of a Tender

workspace. Some core meta-data (e.g. Procurement type, evaluation method, lots

specification, etc.) must not be possible to be modified. There has to be in place a

warning for the authorized user about core meta-data.

8. The system must allow CA users to be able to activate/deactivate specific system

services (e.g. enable online tendering but disable online evaluation). This

functionality is essential for allowing possibility for paper-based procurement

versus online procurement.

Important

`


17

1. The system should allow a Tender workspace to be able to split into smaller

segments (i.e. Lots). During bid management, the system should allow different

bidders to respond to different lots within the same call for a tender.

2. The system should allow authorized CA users to be able to cancel a call for

tender.

Desirable

1. The system might support definition meta-data for budget thresholds. The

system might support different flows in workflow for above threshold versus

below threshold procurements.

2. The system might allow authorized CA users to be able to copy the details of a

previously published call for tender for the creation of a new Tender

workspace. A number of meta-data information as non-core Tender details,

workflow, associated officers, etc. for example should be copied but the

authorized CA user should be able to modify such information as needed.

3.1.6.2 Officer association

Mandatory

1. The system must allow tender workspace creator user to be able to define the

Tender Coordinator user. The Tender Coordinator (TC) user is responsible for

the Tender workspace management, including workflow definition, evaluation

criteria definition, document/workspace publication, assigning roles for bid

opening/evaluation, etc. to existing CA accounts.

2. The system must enable TC users to be able to define the Bid Opening (BO)

users of the Tender workspace. The BO user is responsible for authorization of

Bid opening.

3. The system must allow the TC user to be able to define the Bid Evaluation (BE)

users of the Tender workspace. The BE user is responsible for evaluation of the

opened bids.

Desirable

1. The system might allow the TC user to be able to assign Auditor users for the

call for tender. The Auditor user is a read-only user who is responsible for

auditing the documentation of a competition thus their access to a tender is

restricted to basic details (e.g. competition type and procedure, deadline for

tender submission etc.), as well as to the data file containing the tender

documentation. This user has a primary role in verifying compliance to the

underlying legal framework.

`


18

3.1.6.3 Preparation of bidding document by CA

Mandatory

1. The system must allow TC user to upload in the Tender workspace the Tender

Documentation, comprising electronic files which are available in a commonly

acceptable format (e.g. TXT, PDF, WORD, EXCEL, XML, etc.).

2. The system must allow TC user to edit/delete Tender Documentation and its

metadata information (e.g. title, description, status, language, etc.) until such time

as the documentation becomes available to EO users.

Desirable

1. The system might support a mechanism for creation and maintenance of Tender

Documentation Template Library. This operation should be conducted by

authorized user. The library should be available to CA users for them to upload

template documents.

2. The system might support an approval review cycle for a Tender Documentation

file. The TC user should provide draft versions of the documentation for the

Approval user for review before delivering the final version of the

documentation to the Approval user for approval.

3.1.6.4 Tender questionnaire

Mandatory

1. The system must allow TC user to setup the Tender Questionnaire (i.e. tender

evaluation criteria). If the evaluation mechanism is based on the most

economically advantageous tender (MEAT), TC is required to define the exact

evaluation criteria to be used, as well as to indicate their weightings. Suppliers

will have to fill in defined evaluation criteria when creating their Bids.

2. The system must utilize validation of the soundness and completeness of the

Tender Questionnaire. This validation must take into account the meta-data for

Tender procedure and meta-data for evaluation method.

Important

1. The system should allow TC user to setup the Tender Questionnaire (i.e. tender

evaluation criteria) in envelopes (qualification, technical, financial). This multiple

envelope mechanism separates the technical proposal (based on and intended to

meet the statement of work) from the financing or cost proposal in the form of

two separate and sealed envelopes. The objective of this mechanism is to ensure

a fair evaluation of the submitted bids.

2. The system should support possibility to construct the Tender Questionnaire in

a manner that allows (semi-)automated evaluation. Criteria in the Tender

`


19

Questionnaire which are subject to evaluation should be constructed with

quantifiable data and hold all metadata necessary for (semi-)automated

evaluation, including weights, thresholds and formula for determining the

pass/fail/score of the response. Controls should be put in place to ensure that

the technical weight is not excessive in relation to the financial weight (i.e. price

must be the most decisive award factor amongst the offers passing the minimum

requirements).

3. The system should allow the TC user to configure the Tender Questionnaire to

mandate the use of EO pre-qualification certificates.

Desirable

1. The system might allow TC user to create a Tender Questionnaire by reusing

(importing) the Questionnaire of a similar Tender workspace. Additionally, the

import process should verify the validity of the Questionnaire being imported.

2. The system might allow TC user to export a Tender Questionnaire of a Tender

workspace in order to reuse it in future Tenders.

3.1.6.5 Competition Publication/Activation

Mandatory

1. The system must implement an option for TC user to create a Contract Notice

for the Call for Tender. The Contract Notice is a standardized form that supplies

information about the commencement of a Tender competition. Procurement

Officers can complete notices online entirely, using web-based forms. The e-

Procurement system and the internal Form Filling Module (FFM) are integrated;

therefore, one may pass information to another. For instance, when creating a

Contract Notice, the FFM module can obtain already pre-defined information

from the Tender workspace, including its name of the Call for Tender, its

description, its estimated value, etc. FFM must validate entered data and

implement complex business rule mechanism which takes into account Tender

meta-data for procurement type, contract type, evaluation type, etc.

2. The system must provide standardized form template which will be filled by a TC

user. Design and layout of the form will be provided by the Procurement Office

(PO).

3. The system must enable a TC user to publish a Contract Notice for the Tender,

simultaneously publishing the Tender workspace. The system must send

notifications on published Call for Tender via email to the registered bidders

based on their areas of preference or in case of short-listed bidders.

4. Upon Tender workspace publication, the system must make the workspace itself

and all associated Tender Documentation files publicly available. This means that

`


20

not only registered users have access to Tender information and all associated

Tender documentation, but that there is no need for visitor of Public

Procurement site of EAC to be registered to view details of a published Tender.

5. The system must enable TC user to select and invite EOs to tender,

simultaneously making the Tender workspace available only to them. This

requirement is necessary to support the cases when a Tender process must be

performed without public announcement (e.g. Negotiated procedure without

Advertisement). Only invited EOs must have access to the Tender workspace and

associated Tender Documentation.

6. The system must implement possibility that after publication, if the need arises,

the TC user must be forced to update the Tender details (metadata,

documentation, etc.) through transparent means. For Tender processes that

require public announcement, updates can be performed through a Corrigendum

Notice. For Tender processes that must be performed without public

announcement, an identical "amendment" notification must be sent to all invited

EOs. Disseminated Tender documentation must not be possible to be changed

instead CAs must be able to disseminate addendum documents (i.e. new Tender

documentation files that correct/update information included in the original

Tender documentation).

Important

1. The system should support the automatic transmission of all types of notices (i.e.

Contract Notices, Contract Award Notices, etc.) to EAC Procurement Portal.

2. In order to coordinate the system and align it with EAC procurement processes

and procedures, the design and layout of the standardized forms should be

compliant with them.

3. The system should support that the EAC procurement Manual in line with current

and future law receives via e-Mail or through developed integration Web Service,

published Procurement Plan. Currently CAs are obliged to do this offline in paper

form.

`


21

3.1.7 e-Tendering

The e-Tendering module should provide EO organisations with functionalities and services which

support automated, transparent and safe preparation and submission of bids for tenders. Depending

on the configuration selected for a particular tender, the EOs may be allowed to upload any file as part

of their submission (offline prepared documents) or the module will support the electronic submission

of structured tenders by the CAs. In such a case, the tender files uploaded are prepared in the tender

preparation component which allows the creation of a structured and encrypted tender package.

According to legal regulations, there has to be a support for all online submitted bids to be digitally

signed. Additionally, functionality for clarifications should exist. In such functionality, EOs will be able

to post clarifications from CAs through the system in electronic manner and to receive answers in

similar manner.

3.1.7.1 Questions/answers

Mandatory

1. The system must allow a TC user to define time period within which EOs may

post their questions with respect of Call for Tender (CfT) that they are

interested in. This mechanism must be implemented using web form within the

e-Procurement application; no external information channels must be used.

2. The system must allow the TC users associated with a Tender to view

requests for clarifications as expressed by EO users. This mechanism must be

implemented using web form within the e-Procurement application; no

external information channels must be used. The associated TC user must

receive notification via e-Mail that the request for clarification is posted, in

order to provide a timely clarification.

3. The system must implement dedicated web form for a TC user associated with

the Tender to edit/answer the clarification request. There has to be an option

for TC to edit the clarification request, in order to remove any Supplier

confidential information which is not supposed to be published.

4. The system must allow EO users associated with the CfT to view clarification

responses, along with this functionality, the associated EO user must receive

notification via e-Mail that the clarification is posted.

5. The system must allow a TC user associated with the CfT to create a

clarification in order to provide information not associated with any particular

request. This enables a TC user to post information if a condition of CfT

changes after the publication, or a circular clarification to associated EO users

is required.

Important

1. The system should allow a TC user to provide a textual clarification and an

optional file attachment to all associated EO users with stipulation that a TC

user might also limit the suppliers to which the clarification will be

`


22

disseminated; in case the TC considers that the information included in the

clarification should become available only to the requesting supplier and not all

suppliers.

2. The system should allow TC users associated with the CfT to enter

clarification requests which have been provided by EO user offline, outside the

context of the system, via external information channels e.g. e-Mail

3.1.7.2 Creation/submission of bids

Mandatory

1. The system must allow EO users associated with the Tender to create their bids

in an electronic form through The Tender Preparation Tool (TPT). TPT is an

online tender preparation environment which allows the EO user to prepare

his/her tender, in full accordance to the CfT specifications defined in Tender

Questionnaire. The tool provides functionality for the Bidder to fill in all the

criteria (mandatory and optional) and validate them.

2. The system must allow EO users associated with a Tender to save

draft/incomplete versions of their Bids.

3. The system must not require transmission by the internet of the Bid which is a

draft/incomplete and hence un-encrypted. This is done to safeguard the

confidential nature of its details. Nevertheless, the tender changes should be

completed on time before the submission deadline is reached, allowing adequate

time to the user to proceed in the packaging and submission process.

4. System must provide mechanisms for EO users to finalize their Bid. This

finalization implies packaging Bid into one or more envelopes depending on

specific Tender Questionnaire, signing it with issued qualified e-Signature and

encrypting it prior to its submission to the system through the Internet.

5.

In case the Tender Questionnaire is setup in envelopes (qualification, technical,

financial) the bids must be encrypted by the system individually per envelope, so

that they can be opened separately.

6. The system must allow EO users associated with the CfT submit their bids

through the system. To maintain a healthy competition, submission of Bids must

be allowed to be conducted offline. In that case, it is TC user’s responsibility to

indicate that the Bid submission was received outside of e-Procurement

application context, through external information channels.

7. The system must inform EO users about the result of the bid submission process

via clear visual indicator (i.e. successful / unsuccessful). For every submission

attempt, an EO user must receive an email notification with core information of

the process (e.g. Tender Id, Bid receipt id, date/time, result, etc.).

`


23

8. The System must automatically revoke the Bid submission, removal, and editing

rights from all EOs at the designated date and time for the specific competition

effectively forbidding EOs to bid. This Bid submission deadline is set during

creation of CfT by authorized TC user.

9. The system must allow, if permitted so by the Tender definition, EO users

associated with the CfT to submit more than one Bid for the Tender.

10. The system must allow EO users associated with the CfT to view the list of their

submitted bids.

11. Before the Bid submission deadline, EO users associated with the Tender must be

able to withdraw a submitted Bid from the system. Once a submitted Bid is

removed, the EO must have an opportunity to upload a new Bid, providing that

the Tender submission deadline has not yet been reached.

3.1.7.3 Securities/guarantees

Important

1. The system should enable EO users, to include scanned copy of the bid security,

the moment they have created their bids.

Desirable

1. The system might enable EO users, when creating their bids, to provide

credentials for the system to automatically fetch the bid security from the

respective bank ICT system if Banks agree. Automated fetching of bank securities

requires integration points with banks which can be very challenging considering

oversees EOs, hence such requirement can be considered for advanced e-

Procurement implementations.

3.1.8 e-Awarding

The e-Awarding module should manage the opening and the evaluation of submitted Bids, considering

legal regulations. Finally, the e-Awarding module will be integrated with the e-Notification module

allowing the generation and publication of contract award notices. The module has two major

functionalities: The Bid Opening (BO) which will provide the automatic decryption of the encrypted

bids, making them available for evaluation. It is imperative to support bids received off-line; The Bid

Evaluation (BE) which will provide functionality to enable the electronic evaluation of the received

offers based on the awarding criteria and the evaluation formula, as defined by the tender. Similarly, to

the BO sub-module, there has to be a possibility to use both online and off-line evaluation (evaluate

paper based received bids and report the outcome).

3.1.8.1 Bid Opening

`


24

Mandatory

1. The system must support that, when the tenders opening date/time has been

reached for a CfT, the Bid Opening sub-module offers functionalities to retrieve

and decrypt submitted Bid responses from Interested EOs.

2. System must decrypt the bids only if the decision of the BO users which bids to

open is unanimous. In other words all associated BO users must reach a

consensus on the list of bids to be opened.

3. The system must conform to the Tender Questionnaire definition of envelopes

(qualification, technical, financial). The system must open the envelopes

separately (i.e. split the opening stages of the eligibility, technical and financial

envelopes, for which the opening and evaluation is performed in a sequential

manner). Once the technical evaluation has been completed, the module allows

the opening of the financial envelope in order for it to be evaluated.

Important

1. The system should support association of a user with Bid Opening role to the

CfT, in order to initiate the Opening process. This association must be

completed before the opening date/time has been reached. The users must be

members of the organisation issuing the CfT, and additionally to ensure

transparency in the proceedings, the selected users cannot have role of TC, or

users with role of Tender Evaluator.

2. If the system should feature multi-currency capabilities, the exchange rates can

be pre-defined in the Tender documents, or be obtained automatically from

external systems with help of finance. This allows for the management of the

supported currencies and the proper management of the exchange rates to the

“base currency” of the system. Such information is utilised to compare the

suppliers’ bids and provide common evaluation grounds for their evaluation.

Desirable

1. The system might support that one associated BO user can suggest a list of bids

to be opened.

2. The system might support that remaining associated BO users could confirm the

suggested list in order to proceed with the bids' decryption.

3. In line with functionality 2.7.1.Mandatory.2, in case that one of the remaining BO

users rejects the list of bids to be opened, system might allow a new list to be

defined.

4. The system might be able to perform validation of submitted bids and notify the

BO and BE users in case the submitted bids are in unexpected format as an

extra security measure ensuring the proper information of the supplier on the

performed submission.

`


25

5. The system might produce an opening report that could include the date/time of

opening, the online/offline submitted bids, the bids opened, the bids not opened,

the responsible personnel, etc.

3.1.8.2 Offline bids

Mandatory

1. The system must allow the BO users to upload into the System bids received

offline, outside the context of the system. This action should be performed

before the opening of electronically submitted bids.

Important

1. The system should have an option to update the list of electronically submitted

bids with the (offline) bids added by the CAs.

3.1.8.4 Bid evaluation

Mandatory

1. The system must allow users associated with the CfT which have the role of

Bid Evaluator to view the opened bids.

2. The system must allow the BE users associated with the CfT to provide the

evaluation results for the opened bids against the evaluation criteria.

3. The system must calculate and display the overall score of the evaluated bids.

4. The system must allow, during the evaluation process, BE users associated with

the CfT to request clarifications on the opened Bids (e.g. clarify a clerical error

or a miscalculation in a price element). The mechanism of notifications via e-

Mail must be in place to facilitate effectiveness of evaluation process.

5. The system must allow, during the evaluation process, EO users to respond to

clarification requests.

6. The system must allow the evaluation to be approved by all BE users

associated with CfT, the TC and (if relevant) by other approval bodies outside

the CA (e.g. tender board). If that is not the case, the system must be able to

support the re-evaluation of bids. Re-evaluation of bids implies that the flow is

reverted back to the bid opening process, so that potentially previously

discarded bids are taken into account and vice-versa, before re-performing

evaluation.

Important

1. The system should, In case of offline evaluation, allow the BE users associated

with the CfT to provide the final, consensus evaluation score for each evaluation

criterion and each bid.

`


26

Desirable

1. The system might allow BE users associated with the CfT to justify their provided

scores. To improve the transparency of the evaluation process, any amendments

performed by the evaluators during the evaluation phase in a form of textual

comments can be provided by the BE user for justifying any decision.

2. The system might, In case of offline evaluation, allow the BE users associated with

CfT to provide final ranking per bid, instead of providing consensus scoring per

criterion and Bid.

3.1.8.4 Standstill period/complaints

Important

1. The system should allow EO users to submit complaints for a CfT to the CA.

The Complaint functionality must not necessarily follow the timeline of the

Tender cycle. I.e. the Complaint functionality can become operational prior to

award and remain operational until it is resolved prior to the award.

2. The system should allow the TC users associated with the CfT to view and

answer to the complaints submitted by EOs. The Complaint functionality must

not necessarily follow the timeline of the Tender cycle. I.e. the Complaint

functionality can become operational prior to award and remain operational

until it is resolved prior to the award.

3.1.8.5 Contract award

Mandatory

1. The system must allow the TC user associated with the CfT to award the

contract to the appropriate EOs.

2. The system must enable TC user associated with CfT, after the acceptance of

the contract award, to create and publish the Contract Award Notice. Same

business rules apply as for Contract Notice 2.5.5. Mandatory.1.

Important

1. The system should allow the TC user to announce the results of the evaluation

procedure to the EOs who participated in the CfT.

Desirable

1. The system might allow awarded EO users to accept or decline the award.

2. The system might allow the TC user associated with the CfT to re-award the contract in case

of award's rejection.

`


27

3.1.9 e-Reverse Auction

The e-Auction module should provide the additional openness and transparency in the procurement

process. This will be achieved by allowing CA user to enable an e-Auction event that will be based on

the Tender’s evaluation method ("Lowest Price" or "Most Economically Advantageous Tender”).

Electronic invitation to the successful EOs will be supported, upon invitations acceptance, auction room

will be created. All submitted auction bids should be validated by the system against the predefined

requirements for the tender. EOs will be able to easily identify their ranking position, and be able to

rapidly adjust their bids to improve their ranking. Authorised EO users will be able to access details of

an e-Auction event, after it has closed, such as bids of each EO, final ranking for all EOs, etc.

3.1.9.1 e-Auction event room setup and invitations

Mandatory

1. The system must enable TC user to have the option to create an e-Reverse

Auction workspace. This option is typically found when CT creates CfT and uses

the mechanism of tasks in the user workspace.

2. If the CfT is created with lots and if TC user associated with CfT enabled e-

Reverse Auction, then, the system must mandate the creation of an e-Reverse

Auction workspace for each Lot.

3. The system must allow TC user associated with CfT to have the option to

configure the parameters of a round-based e-Reverse Auction. Setup parameters

include number of rounds, round duration, and the interval between rounds.

4. The system must allow TC user associated with CfT to have the option to

configure the parameters of a time-based e-Reverse Auction. Setup parameters

include duration, number of automated extensions in case a bid is received at the

closing minutes of the auction, and extension period.

5. The system must allow TC user to have the option to define the minimum "step"

for financial elements (i.e. minimum difference of a valid, new Bid in relation to the

best-placed Bid).

6. The system must allow TC user to schedule the e-Reverse Auction event and invite

EOs. It could be possible, also, to reschedule e-Reverse Auction event could be re-

scheduled. It is implied that the participating user, weather EOs or TC user must

be notified via e-Mail.

7. CA users must be able to cancel an e-Reverse Auction event. This is important in

following cases: all EOs are disqualified, only one EO is successful, none of the

invited EOs accepted the e-Reverse Auction invitation, etc.

Important

1. The system should enable TC user to have the option to provide instructions for

the e-Reverse Auction event. These instructions can be attached or defined in the

invitation to participate in e-Reverse Auction.

Desirable

1. The system might enable TC user to have the option to set up visibility parameters

in categories (e.g. Sealed, Limited, Full or Manual). Visibility parameters define the

`


28

data that will be made available to EO users, including previous bid, best current

bid, minimum next possible bid, relative ranking, best bid, etc.

2. The system might allow TC user to define quantitative technical elements as

subjects for the auction. This is important, in case the evaluation mechanism

selected for a CfT is MEAT, the TC user can select technical criteria the CA would

like to receive an improved offer.

3.1.9.2 e-Auction event execution and closure

Mandatory

1. The system must control the period during which EO users are permitted to submit

Bids. This is used to quickly identify connectivity issues. In case an issue is detected,

the system automatically notifies the TC user in order to decide whether further

actions are needed (i.e. e-Auction cancellation, etc.).

2. The system must immediately validate submitted Bids upon submission and inform in

a real-time manner the EO user in case a Bid is invalid.

3. The system must immediately evaluate a new, valid Bid and calculate automatically

the new ranking of received Bids. The Bid is automatically evaluated according to the

evaluation mechanism (Lowest Price or Most Economically Advantageous Tender)

and the supplier ranking is also automatically updated.

4. The system must constantly keep participating EOs informed of the proceedings

(round, time, best price, relative ranking, etc.) as per the pre-configured visibility

parameters.

5. The system must allow EO users to submit a Bid.

6. The system must conclude the e-Reverse Auction proceedings once completion

criteria are met. These criteria could be reaching final round or reaching end date

and time including any extensions.

Important

1. The system should enable TC user to be in a position, during the execution of an e-

Auction, to intervene in this process, by communication with the EOs via the text

messaging board in order to promptly and transparently address any concerns.

Desirable

1. The system might allow each EO to reply to an invitation by the task mechanism, in

order to indicate the acceptance or the denial to participate in the e-Auction event.

Only Eos which accepted the invitation may participate in the e-Reverse Auction.

3.1.10 Contract Management

This module should support contract workspace management; CAs must be able to upload electronic

form of awarded and validated contracts in order for all interested parties to be able to have them as

publicly available information.

`


29

3.1.10.1 Deliverables

Mandatory

1. The system must support upload of electronic form of an offline signed. e-Awarding

and e-Invoice. Those uploaded contracts must be available to both registered and

public users.

3.1.11 e-Pre-qualification Management

This modules’ purpose should be to check the eligibility of EO to participate in published tender since

this is currently obligation of CA to perform it. In East African Community.

(https://www.eac.int/opportunities/procurement-procedures) which creates, manages and follows-up

supplier pre-qualification information. This information is maintained in a centralised Supplier

information database, where supplier data can be re-utilised across different call for tenders and by

different Procuring Entities.

3.1.12 Reporting

The report functionality should support the comprehensive search and download of conclusions and

resolutions of the complaints submitted by Economic Operators to Complaint Body. These documents

will be uploaded by Complaint committee entity in the portal. Also, similarly, the support for search

and preview of reports of contracted public procurement predefined lists should exist. Current

predefined lists are:

(a) Contracted high value procurement

(b) Contracted low value procurement

(c) Reasons for procedure cancelation

(d) Outcome of conducted public procurements

(e) Exempt public procurements

(f) Contracted public high value procurement of ( previous portal)

(g) Contracted public low value procurement of previous portal)

The Web GUI should support a detailed audit log that registers all user login information and any other

activity affecting the database or any action performed by the user on the system. In addition to this

detailed auditing mechanism, the system should also log the audit other key actions that may not affect

the database, but that facilitate the user's day to day analysis of procurement activities.

3.1.12.1 Notifications

Mandatory

1. The system must send notifications via e-Mail to CA users upon their association

with / disassociation from a tender workspace.

2. The system must send notifications via e-Mail to associated TC user upon CfT

publication.

3. The system must send notifications via e-Mail to TC user and interested EO

users upon addition/modification of CfT documentation.

https://www.eac.int/opportunities/procurement-procedures

`


30

4. The system must send notifications via e-Mail to interested EO users upon

modification of CfT details.

5. The system must send notifications via e-Mail to the successful EOs upon award

of the tender.

Important

1. The system should send notifications via e-Mail to TC user upon CfT creation or

modification of tender details.

2. The system should send notifications via e-Mail to an EO upon CfT publication,

when the CfT CPV codes match the CPVs of interest to the EO.

3. The system should send notifications via e-Mail to the TC user upon request for

clarification by an EO user.

4. The system should send notifications via e-Mail to EO users when a clarification

regarding a tender of interest is published.

5. The system should send notifications via e-Mail to the EO users upon the

submission of their bid, as a proof of submission.

6. The system should send notifications via e-Mail to the BO users when reaching

the Bid Opening date.

7. The system should send notifications via e-Mail to the EO users when of the bid

evaluation results are announced.

8. The system should send notifications via e-Mail to the TC/BE users when

complaints are sent by EOs.

9. The system should notify invited CAs to respond to procurement plan requests

by providing their CA-specific procurement plan.

Desirable

1. The system might send notifications via e-Mail to TC user upon submission of a

bid by an EO.

2. The system might send notifications via e-Mail to EO users when a clarification

request during evaluation is expressed by the BE users.

3. The system might send notifications via e-Mail to the BE users once a clarification

request during evaluation has been answered by the respective EO user.

4. The system might send notifications via e-Mail to the EOs upon deadline of the

standstill period.

3.1.12.2 Auditing

Mandatory

1. The system must support an implementation of auditing/monitoring all actions

performed by the system users.

Important

1. The system should support the generation of reports through the auditing facility,

and their export and download in user-friendly formats e.g. spreadsheet.

`


31

3.1.12.3 Reporting

Mandatory

1. System must support implementation for the production of various types of

statistical reports, e.g. Quarterly reports of awarded contracts per procurement

procedure. Following reports must be pre-defined: Contracted public procurement

of high value; Contracted public procurement of low value; Reasons for cancelation

of the procedure; Outcome of conducted public procurements; Exempt public

procurements; Contracted public procurement of high value (old portal);

Contracted public procurement of low value (old portal);

Important

1. The system should support the generation, export and downloading of reports in

user-friendly formats e.g. spreadsheet.

2. The system should support, after bid opening, generation of an Opening Report,

documenting details about the Bid Opening Process and Opened Bids. Opening

Report should be available to the BO users.

3. The system should support, after bid evaluation, generation of an Evaluation Report,

documenting details about the Bid Evaluation Process, assigned evaluation results and

award recommendation. Evaluation Report should be available to the BE and TC

users.

4. The system should support, after the completion of an auction event, generation of

an Auction Report, documenting details about the proceedings. Auction report

should include dates/times, invited EOs, bid summaries, ranking, etc.

5. The system should support the generation of reports including details for awarded

contracts. Reports should be generated based on certain criteria e.g. Tender, CA,

Date etc.

6. The system should support the generation of reports for the status of deliverables

for an ongoing contract.

3.1.12.4 Open Contracting Data Standard (OCDS)

Important

1. The system should support, at the moment of creating a Tender Workspace,

publishing of OCDS messages for Planning and Tender.

2. The system should support, at the moment of updating the details of a Tender

Workspace (metadata, documents, questions/answers, etc.), publishing of

OCDS messages for Planning and Tender.

`


32

3. The system should support, at the moment of awarding a Tender, publishing of

an OCDS message for Awards.

4. The system should support, at the moment when the Tender award details are

updated, the option for publishing of an OCDS message for Awards.

3.2 NON-FUNCTIONAL REQUIREMENTS

Non-functional requirement is a requirement that specifies criteria that can be used to judge the

operation of a system, rather than specific behaviours. They are contrasted with functional

requirements that define specific behaviour or functions.

3.2.1 SECURITY

Mandatory

1. All sensitive data stored in the various components of the system must be encrypted

before they are stored.

2. The system must be able to use facility of qualified electronic signature of all

documents uploaded in the system.

3. System must support appropriate security controls, including user roles with pre-

defined access rights which control the data and functionality each user has access to.

4. For all sensitive communications with clients, communication protocols with

encryption (e.g. HTTPS) must be used.

5. System must provide anti-virus protection.

6. System must be protected against known security threats (e.g. SQL injection, DoS,

DDoS, buffer overflows, XSS, etc.).

7. System must be able to guarantee that its data is not disclosed to unauthorized

persons or processes.

Important

1. The qualified electronic signature should be opened to domestic and foreign suppliers

in an indiscriminate way, and should not limit the principle of open and fair competition,

unless it will undermine the benefits of e-Procurement.

3.2.2 AUDITABILITY

Mandatory

1. For critical system events (e.g. tender bid submission, auction bid submission, etc.),

System must support methods with which the sender of data can be provided with

evidence of delivery. Such evidence will be implemented by means of e-Mail.

2. System must be able to audit all system and user actions. System should ensure that

all actions performed on received/stored data are recorded, keeping track of

actors, date/time, input/output data and any other information necessary to allow

specialized personnel to monitor and fully reconstruct a transaction.

`


33

3.2.3 EXTENDABILITY

Mandatory

1. System must be built in a modular approach that will allow the addition of new functional

modules without impacting the overall system functionality. The need for this SW type

of architecture is to allow the development of the system by different SW vendors, to

avoid possible lock-downs or delays in system implementation and deployment cycle.

2. System must be based in an architecture that will allow the addition of extra HW

resources to enhance the systems capabilities (e.g. performance, storage, bandwidth,

etc.).

3.2.4 PORTABILITY

Mandatory

1. System must be designed in a manner that will not be coupled to any hardware specific

technologies.

2. System must be possible to be deployed on different HW and SW infrastructures and not

dependant on the software technology used for implementation. However, it is preferable

to be implemented in one of the major and proven technology.

3.2.5 RELIABILITY

Mandatory

1. System must ensure the integrity of the transmitted data.

3.2.6 USABILITY

Mandatory

1. System should abide to the latest standards for Graphical User Interface design.

2. The e-Procurement software should be capable to support various kinds of output

reports in different formats, like XLS, PDF, TXT, XML, DOC, CSV, HTML etc.

3. System must be accessible over the web through the use of any available web-browser.

System should at a minimum support all versions of the most widely-used web-

browsers that the relevant vendors continue to support.

4. System could be able to operate and it’s content to be accessible in different languages.

3.2.7 PERFORMANCE

Mandatory

1. System must be able to cope with the expected load and traffic.

`


34

2. System's architecture should be able to cover an annual increase of at least an agreed

percentage on the load and traffic without degradation of its performance.

3. System response times (in a LAN environment) should not exceed the agreed number

of seconds for responding to user requests. Agreed number of seconds should be split

per type of functionality such as simple queries, complex queries, reports, etc.

4. The e-Procurement Portal should be designed as a three-tiered MVC application.

5. Data Base model should be relational.

3.2.8 INTEROPERABILITY

Mandatory

1. System must follow state-of-the-art interoperability standards so that its integration or

communication with external systems can be achieved. System should be developed

following Service Oriented Architecture (SOA) and Open standard architecture. System

needs to be developed in a way that will allow the creation and support of ‘Web Services’

to exchange information between the system and external systems. The system should be

fully compatible with:

a. Open Contracting Data Standard –OCDS (http://standard.open-

contracting.org/latest/en).

4.0 Experience and Capability

4.1 Duties and Responsibilities

Responsibilities

1. To internalize and understand the assignment, to go through the given functional and non-

functional requirements and data elements prepared as well as other documents to clearly

understand the task.

2. To design and develop the e-Procurement system as per given functional and non-functional

requirements

3. To integrate e-Procurement with EAC Budget management System (BMS) for the execution of

the procurement plans

4. To integrate e-Procurement with EAC Requisition and Accountability Management System

(RAMS).

5. To integrate e-Procurement with EAC SUN systems.

6. To develop technical documentations and user manuals for the developed e-Procurement system

7. To produce and submit all technical reports, including Inceptions, intermediate and final reports

4.2 Firms Working Expereience

http://standard.open-contracting.org/latest/en

http://standard.open-contracting.org/latest/en

`


35

Working experience

1. Experience of working with regional economic communities or bodies of similar nature

2. Experience in the development and deployment of e-Procurement systems and structures, and

interface with other systems.

3. Experience in the development and deployment of Budget Management System structures and the

interface with the Financial Management Systems

4. Experience in the development and deployment of Requisition and Accountability Management

System structures or systems of similar nature

5. Experience in operationalization of similar systems, including development of system technical

documentations and user manuals.

4.3 Key Staff Qualification Requirements

The proposed team by the Vendor MUST consist of staff with skills in:

(a) Project Management

(b) e-Procurement analysis expertise

(c) Solutions Architecture

(d) Software design and development

(e) Information system testing

Documents

E-PROCUREMENT SYSTEM User Requirements and Technical