Consulting Services for the Preparation of Functional and Technical Requirements and Procurement-Ready Technical Specification for the RVS Mobile Application and Data Collection Workflow — Strengthening Moldova's Disaster Risk Management an

REQUEST FOR EXPRESSIONS OF INTEREST

(CONSULTING SERVICES - FIRMS SELECTION)

Republic of Moldova

Strengthening Moldova’s Disaster Risk Management and Resilience Project

Loan No.: 9720-MD

Assignment Title: Consulting Services for the Preparation of Functional and Technical Requirements and Procurement-Ready Technical Specification for the RVS Mobile Application and Data Collection Workflow

Reference No. (as per Procurement Plan): MD-OEAPM-578959-CS-CQS

The Government of the Republic of Moldova has received financing from the World Bank toward the cost of the Strengthening Moldova’s Disaster Risk Management and Resilience Project, and intends to apply part of the proceeds for consulting services.

The consulting services ("the Services") include the consultancy services for the Preparation of Functional and Technical Requirements and Procurement-Ready Technical Specification for the RVS Mobile Application and Data Collection Workflow.

The Terms of Reference (TOR) for the primary procurement stage for the assignment are attached to this request for expressions of interest.

The Ministry of Infrastructure and Regional Development (MIRD) and the P.I. "Office for External Assistance Programs Management" (OEAPM) Project Implementation Unit (PIU) now invites eligible consulting firms ("Consultants") to indicate their interest in providing the Services. Interested Consultants should provide information demonstrating that they have the required qualifications and relevant experience to perform the Services. The shortlisting criteria is:

At least 5 (five) years of experience in

combining seismic/RVS methodology knowledge, building screening and vulnerability assessment, GIS/spatial data modelling, data quality control and QA/UAT design , together with IT business analysis for digital data-collection systems.

Only the firm’s relevant experience and qualifications will be assessed at the shortlisting stage. Key Experts are not required to be proposed and will not be evaluated at this stage.

The attention of interested Consultants is drawn to Section III, paragraphs, 3.14, 3.16, and 3.17 of the World Bank’s "Procurement Regulations for IPF Borrowers" September 2023 ("Procurement Regulations"), setting forth the World Bank’s policy on conflict of interest.

Consultants may associate with other firms to enhance their qualifications, but should indicate clearly whether the association is in the form of a joint venture and/or a sub-consultancy. In the case of a joint venture, all the partners in the joint venture shall be jointly and severally liable for the entire contract, if selected.

A Consultant will be selected in accordance with the „Consultant’s Qualification-based Selection" described in the Procurement Regulations and to be specifically set out in the Request for Proposals.

The Expression of Interest shall clearly state the name of the Consultant (individual Firm, Joint Venture or sub-consultancy). The Consultant shall provide relevant references (assignment name, Client, time frame, the role of the firm (main Consultant/Partner in JV/sub-consultant, contract amount, tasks performed etc.) to confirm its experience and qualifications.

Further information can be obtained at the address below during office hours 08:30 to 17:30 hours.

Expressions of interest must be delivered in a written form to the address below (by e-mail) by

17:30 local time, November 16, 2026.

Attn: Ms. Raia CANTEMIR

Director, Office for External Assistance Programs Management / PIU

57/1 Mitropolitul Banulescu Bodoni str., office 306, MD-2005, Chisinau, Republic of Moldova

Tel: 373 22 23 29 63, 373 23 82 48

E-mail: achizitii.proiecte@ogpae.gov.md

www.ogpae.gov.md

TERMS OF REFERENCE

for Consulting Services for the Preparation of Functional and Technical Requirements and Procurement-Ready Technical Specification for the RVS Mobile Application and Data Collection Workflow

Contents

Background and Rationale. 6

Role and scope of the RVS mobile application. 6

Justification and need. 6

Boundaries of this assignment 7

Legal and regulatory framework. 7

Objective of the Assignment 8

Specific objectives. 8

Document all decisions, assumptions, comments and revisions through controlled Version Log, Comment Log, Data Register and, where applicable, Change Log and NC/CAPA Register, in line with the QAP.Scope of Services. 9

Review of the RVS methodology, GD 334 and QAP requirements. 9

Assessment of the RVS field workflow and user requirements. 10

Definition of functional requirements for the mobile application. 10

Definition of technical requirements and system architecture constraints. 11

Development of the data model, data dictionary and validation rules. 11

Definition of QA/QC, testing, UAT and acceptance framework. 12

Preparation of the procurement-ready ToR and technical specification for subsequent application development services. 12

Inputs for training, field data collection and post-collection validation. 13

Consultations with MIRD/OEAPM/PIU and revision based on comments. 13

Data governance, privacy and security requirements. 13

Limited field validation — form walkthrough and tabletop simulation. 14

Cross-ToR coordination and Common Data Standard. 14

Quality Assurance and Technical Requirements. 15

Compatibility with RVS methodology, GD 334 and related Subcomponent 3.1 outputs. 15

Requirements traceability and data model control 15

Internal QA/QC.. 15

Peer-review and domain validation. 16

Version Log, Comment Log, Data Register, Test/UAT and NC/CAPA records. 16

Acceptance of deliverables by the Beneficiary. 16

Deliverables and Timeline. 16

Reporting and Format of Deliverables. 18

Language of deliverables, reporting process and final submission package. 18

Required formats. 18

Key Qualification Requirements. 19

Key Expert 1 — Team Leader / RVS Methodology and Seismic Risk Specialist 19

Key Expert 2 — Building Screening / Seismic Vulnerability Assessment Specialist 19

Key Expert 3 — GIS, Spatial Data and Data Management Specialist 20

Key Expert 4 — IT Business Analyst / Digital Data Collection Specialist 20

Non-Key Experts / Optional Specialists. 21

Client’s Inputs and Institutional Coordination. 21

Available documents. 21

Coordination with MIRD and OEAPM/PIU.. 21

Access to stakeholders and users. 21

Comments on deliverables. 21

Technical meetings and consultations. 21

Background and Rationale

The Government of the Republic of Moldova is implementing the Strengthening Moldova's Disaster Risk Management and Resilience Project (SMORE), financed by the World Bank. The Project aims to strengthen the country's preparedness and resilience to natural hazards and climate-related shocks, including through improved policy, regulatory and technical instruments for disaster risk reduction.

This assignment is part of Subcomponent 3.1 - Policy, Regulatory, and Feasibility Study Support to Reduce Seismic Risk. Within this Subcomponent, the Rapid Visual Screening (RVS) of buildings represents one of the foundational mechanisms for collecting standardized exposure and vulnerability information at building level. RVS data feed directly into the seismic risk assessment chain — combined with the seismic hazard outputs developed under Activity 1a and with the seismic risk map methodology developed under Activity 1c — and constitute a primary input for prioritization of risk reduction interventions, retrofit feasibility studies, public-investment planning and emergency preparedness.

The Republic of Moldova is exposed to significant seismic hazard, primarily generated by the Vrancea intermediate-depth seismic source (Romania), which has historically affected the entire territory of the country. The 1940 (M 7.4) and 1977 (M 7.2) earthquakes demonstrated the vulnerability of the existing building stock and underlined the need for a systematic, standardized and traceable building inventory and screening process. In this context, RVS is recognized internationally — through methodologies such as FEMA P-154/P-155, EMS-98 vulnerability classification and EU national approaches — as a cost-effective first-tier tool for building-level screening prior to detailed engineering assessment.

Role and scope of the RVS mobile application

The RVS mobile application is, by design, an operational tool for standardized field data collection, executed in accordance with the RVS methodology described in Government Decision No. 334 of 05.06.2025 and with the quality-assurance requirements applicable under the Project. Together with the web-based administration and data-management portal defined in Section 3.4, it forms a single digital data-collection solution operating on one controlled backend database. The application shall ensure that building-level exposure and vulnerability information is collected in a uniform, controlled and traceable manner, so that the resulting dataset is fit-for-purpose for seismic risk assessment, GIS integration, prioritization and future regulatory or investment decisions.

The mobile application shall not, however, be treated as the primary technical substance of this assignment. The critical quality risk under Activity 1b is not the coding of a mobile application as such, but the correct translation of seismic risk principles, RVS methodology, building typology, vulnerability indicators, field screening logic, scoring rules, data validation and GIS/export requirements into a clear, complete, testable and procurement-ready functional and technical specification. The future software solution is expected to implement standard mobile data-collection functions — structured forms, role-based access, mandatory fields, photo and GPS capture, offline operation, synchronization, review/validation status, export and audit trail — and is not expected to perform complex seismic modelling or scientific hazard calculations within the application itself.

Justification and need

The Republic of Moldova currently lacks a unified, digital building inventory aligned with modern RVS practice and with the requirements of GD 334/2025. Existing building data are fragmented across cadastral, statistical and sectoral sources, are not structured around vulnerability/exposure indicators, do not follow a controlled data dictionary, and are not directly usable as input for seismic risk analysis. A procurement-ready specification for an RVS mobile application and the underlying data-collection workflow is therefore a precondition for:

the practical operationalization of the RVS methodology established by GD 334/2025;

the production of a building-level dataset compatible with the seismic risk map methodology developed under Activity 1c;

the integration of exposure and vulnerability data with the seismic hazard zoning produced under Activity 1a;

the prioritization of buildings for detailed seismic assessment, retrofit feasibility studies and/or public-investment decisions;

the alignment of national practice with EU and international RVS methodologies (FEMA P-154/P-155, EMS-98, GNDT and equivalent);

the preparation of a defensible, technology-neutral procurement of the future application development service, in line with World Bank Procurement Regulations.

Accordingly, this assignment is required to translate the RVS methodology, institutional needs and QAP requirements into a clear, procurement-ready functional and technical specification for digital data-collection solution (mobile application and administration portal)and the associated data-collection workflow. The output shall enable the Client to procure application development services on a technically sound and competitive basis and shall ensure that the future application, once developed, can be tested, accepted and deployed for field data collection in a traceable and verifiable manner.

Boundaries of this assignment

This assignment is preparatory and specification-oriented in nature. It explicitly covers the preparation of functional and technical requirements, the data model, validation rules, RVS scoring/classification logic, QA and User Acceptance Testing (UAT) framework and procurement-ready technical specification for the future digital data-collection solution. It explicitly does not include actual software development, source code production, database deployment, large-scale field screening, or final database cleaning and validation, all of which are planned as subsequent activities under Activity 1b and shall be procured under separate contracts.

For full clarity on packaging and sequencing (responding to the reviewers' request to state explicitly where application development and pilot implementation sit): (i) the development of the application and portal shall be procured as a separate application-development services contract, on the basis of the procurement-ready specification produced under this assignment; (ii) the pilot field screening referred to in the Project Appraisal Document is a subsequent Activity 1b stage — under the proposed default in Section 5.1 and DR-5, a supervised field pilot on a limited building sample is embedded in the acceptance process of the future application-development contract, with screening performed by Client-designated certified evaluators; and (iii) this assignment includes only a limited, low-cost form walkthrough and tabletop simulation (Section 3.11), which validates the draft forms and workflow before the specification is finalized and does not replace the pilot screening.

In line with the principle of fit-for-purpose expertise, the Key Experts required under this Terms of Reference combine seismic risk, RVS methodology, building typology and vulnerability assessment, GIS/data management and — following the reviewers' recommendation — dedicated IT business-analysis expertise (Key Expert 4, Section 7.4), so that the feasibility, consistency and implementability of the specification are assured within the core team. Additional IT input (e.g. UX/UI, cybersecurity, database design) may still be mobilized as non-key or short-term support, including through subcontracting. .

Legal and regulatory framework

The services to be carried out under this Terms of Reference shall comply with, but not be limited to, the following legal and regulatory references:

Code of Urbanism and Construction No. 434/2023 (Codul Urbanismului i Construciilor) and subsequent implementing acts;

Government Decision No. 334 of 05.06.2025 on the Regulation for Rapid Visual Screening (RVS) of existing buildings;

NCM A.07.02 — Quality assurance in design and execution of constructions;

EN 1998-1:2004 + A1:2013 — Eurocode 8: Design of structures for earthquake resistance — Part 1: General rules, seismic actions and rules for buildings;

EN 1998-3:2005 — Eurocode 8 — Part 3: Assessment and retrofitting of buildings;

FEMA P-154 and FEMA P-155 — Rapid Visual Screening of Buildings for Potential Seismic Hazards (reference international methodology);

EMS-98 — European Macroseismic Scale, vulnerability classification framework (reference);

ISO 19115 — Geographic information — Metadata; INSPIRE Directive principles for spatial data interoperability;

Law No. 133/2011 on the protection of personal data, with subsequent amendments;

The national legal and regulatory framework applicable to state-owned information systems and government electronic services, including the regulations governing the MCloud government cloud platform, as relevant to the hosting and data-governance requirements in Section 3.10

World Bank Procurement Regulations for IPF Borrowers (current edition);

World Bank Environmental and Social Framework (ESF) — relevant Environmental and Social Standards;

Quality Assurance Plan (QAP) of Subcomponent 3.1 — current approved version.

Objective of the Assignment

The general objective of the assignment is to prepare a complete, technically sound and procurement-ready Terms of Reference and functional and technical requirements package for the RVS digital data-collection solution — comprising a mobile field application and a web-based administration and data-management portal (Section 3.4) and related data collection workflow, in accordance with the RVS methodology described in GD 334 of 05-06-2025, the Project implementation framework and the Quality Assurance Plan applicable to Subcomponent 3.1. The package shall be methodologically driven by seismic risk and RVS requirements, while being sufficiently clear and structured for subsequent application development procurement and implementation.

The specific objective is to define, in a clear and verifiable manner, what the future mobile application must do from the perspective of RVS field screening and seismic risk data collection: what building data it must collect, how evaluators shall record observations, how vulnerability and exposure indicators shall be structured, how data shall be validated, stored, exported and documented, and how the application shall be tested and accepted before field use. The Consultant shall ensure that the resulting specification is suitable for subsequent application development procurement and implementation, while remaining primarily aligned with the seismic risk, building screening, GIS/data and institutional requirements of the Project.

Specific objectives

In addition to the general objective stated above, the Consultant shall achieve, in particular, the following specific objectives:

Translate the RVS methodology established by GD 334/2025 into a structured set of building-level data fields, controlled vocabularies, vulnerability and exposure indicators, validation rules and scoring logic suitable for digital field data collection;

Document the mapping of the GD 334/2025 scoring and classification parameters to the predominant Moldovan building typologies and to the seismic zoning of the national territory (using Activity 1a outputs as they become available), identify the parameters that will require future calibration, and define the data fields, metadata and procedure needed to make such calibration possible once screening datasets exist (calibration-readiness, Section 3.1);

Prepare a complete data model and data dictionary for the RVS solution, including field IDs, data types, mandatory/optional status, allowed values, units, validation rules, dependencies, export attributes and GIS relevance;

Define the field-screening workflow, user roles (field evaluator, supervisor, data validator, GIS/data manager, administrator, MIRD/OEAPM/PIU reviewer) and the corresponding access permissions, workflow states and audit-trail requirements;

Define the functional requirements for the mobile application and the web-based administration and data-management portal, including form-driven data entry, photo and GPS capture, offline operation, synchronization, supervisor review, correction workflow, user and role management, workflow supervision, data validation and quality control, reporting, export and reporting functions;

Define the technical requirements and minimum architectural constraints in an implementation-neutral manner, sufficient for objective procurement and acceptance testing, but without locking the future Client into a specific technology stack unless explicitly justified;

Validate the draft data-collection form and field workflow through a limited form walkthrough and tabletop simulation (Section 3.11), and incorporate the documented lessons learned into the final specification

Prepare the QA/QC, testing and User Acceptance Testing (UAT) framework, including test scenarios, defect severity levels, acceptance conditions and Test/UAT register templates;

Prepare a procurement-ready Terms of Reference and technical specification for the subsequent acquisition of application-development services, fully consistent with World Bank Procurement Regulations;

Define the minimum content of user and administrator documentation to be produced by the future application-development service provider, in support of training, field deployment and post-collection validation;

Define the data-governance, privacy, security, hosting, source-code ownership and maintenance requirements applicable to the future solution (Section 3.10);

Ensure full requirements traceability through a Requirements Traceability Matrix linking each requirement to a methodological source, data field, test scenario and acceptance criterion;

Document all decisions, assumptions, comments and revisions through controlled Version Log, Comment Log, Data Register and, where applicable, Change Log and NC/CAPA Register, in line with the QAP.Scope of Services

The Consultant shall provide all services necessary for the preparation of a complete requirements and technical specification package for the RVS digital data-collection solution and data collection workflow. The core services shall cover methodological translation of RVS requirements, assessment of field screening workflow, definition of functional requirements, preparation of the data model and validation rules, definition of GIS/export and metadata requirements, preparation of the QA/UAT framework, a limited form walkthrough and tabletop simulation, definition of data-governance and security requirements, cross-ToR coordination under the Common Data Standard, and preparation of the procurement-ready ToR and technical specification for the subsequent application development services contract.

All services shall be carried out in a transparent, traceable and verifiable manner. Each requirement shall be linked to a source, rationale or project need, including the RVS methodology, QAP, institutional requirements, field workflow, data quality requirements or future use of the data in seismic risk analysis. Requirements related to software architecture or technology shall be limited to what is necessary for reliability, usability, data protection, interoperability and acceptance testing, and shall avoid unnecessarily restrictive technological choices.

The Consultant shall comply with the applicable requirements of the World Bank Environmental and Social Framework (ESF) and relevant Project instruments, including the Environmental and Social Commitment Plan (ESCP), Labor Management Procedures (LMP), Stakeholder Engagement Plan (SEP), and Grievance Redress Mechanism (GRM). All personnel engaged under the assignment shall adhere to the Project Code of Conduct, including provisions on the prevention of Sexual Exploitation and Abuse and Sexual Harassment (SEA/SH).

Review of the RVS methodology, GD 334 and QAP requirements

The Consultant shall review the RVS methodology described in GD 334 of 05-06-2025 and all available project documents relevant to Activity 1b, including the QAP, implementation chart, existing RVS forms/guidelines, risk map methodology requirements, data/GIS requirements and any other documentation made available by the Client.

The review shall identify the minimum data that must be collected through the mobile application, the logic of the RVS scoring/assessment process, the building typologies and vulnerability indicators to be recorded, the relationship between hazard, exposure and vulnerability data, and the quality control rules needed to make the collected dataset usable for subsequent analysis.

As part of this review, the Consultant shall map the scoring and classification parameters of GD 334/2025 against: (i) the predominant Moldovan building typologies (including precast large-panel, masonry, reinforced-concrete frame and mixed systems of the relevant construction periods); and (ii) the seismic zoning of the territory, using the administrative-unit hazard values produced under Activity 1a as they become available. The Consultant shall identify and document the parameters that would require future calibration, the evidence needed for such calibration, the applicable limitations, and the data fields and metadata that the future solution must capture so that calibration can be performed once the first screening datasets and the Activity 1a/1c outputs exist. The Consultant shall not modify the scoring rules established by GD 334/2025.

The Consultant shall prepare a Requirements Source Matrix showing the origin of each requirement.

Assessment of the RVS field workflow and user requirements

The Consultant shall analyse the practical workflow for field screening and data collection. This shall include the identification of user groups, field roles, data collection steps, review/validation steps, synchronization needs, supervisor functions and institutional review requirements.

At minimum, the analysis shall consider the following user groups: field evaluator, field team leader/supervisor, data validator, GIS/data manager, application administrator, OEAPM/PIU reviewer and MIRD reviewer. The Consultant shall describe the expected rights, responsibilities and access permissions for each user group.

The Consultant shall prepare workflow diagrams and/or process descriptions covering the full chain from assignment of buildings/areas, field visit, data entry, photo/geolocation capture, completeness checks, synchronization, supervisor review, correction/rejection, data export and final handover for further QC and integration.

Definition of functional requirements for the mobile application

The Consultant shall define the functional requirements for the future solution. The requirements shall be precise enough to be used in subsequent application development procurement and later testing. Each requirement shall have an identifier, description, priority, acceptance criterion and, where applicable, a reference to the RVS methodology or QAP requirement.

As a minimum, the functional requirements shall address the following components:

creation, assignment and management of field screening tasks and investigated areas;

RVS data collection form structured according to GD 334 of 05-06-2025 and the approved RVS methodology;

building identification and location capture, including address, administrative unit, coordinates and, where available, cadastral/building reference fields;

recording of building use, occupancy, structural typology, approximate age, number of storeys, structural and non-structural vulnerability indicators, visible deficiencies, exposure information and other required RVS fields;

photo capture and attachment to building records, with metadata such as date, time, user and coordinates where technically feasible;

automatic and manual validation rules, including mandatory fields, controlled lists, ranges, cross-field consistency checks and duplicate detection;

RVS scoring or classification logic, if required by the approved methodology, with transparent formulas/logic and traceable outputs;

offline-first field operation and subsequent synchronization when internet access is available;

record status workflow: draft, submitted, returned for correction, validated, exported and archived;

supervisor review, comments and correction workflow;

web-based administration and data-management functions: user and role management, task assignment and monitoring, workflow supervision, data validation and quality-control queues, dashboards and progress reporting, configuration of controlled lists where permitted, and system administration;

export of datasets in reusable formats for GIS and tabular processing;

generation of basic record summaries, field reports or export packages, where required;

audit trail for creation, modification, validation and export actions.

The Consultant shall distinguish mandatory, recommended and optional requirements. Optional features shall not obscure the minimum functional core required for field data collection and data quality control.

Definition of technical requirements and system architecture constraints

The Consultant shall define the minimum technical requirements for the future application in a way that is clear for application development service providers, but not unnecessarily restrictive with regard to implementation technology unless required by the Client. The technical requirements shall remain implementation-neutral and shall be derived from the RVS field workflow, data quality, security/access, interoperability and acceptance needs.

The Consultant shall not be required to design the full software architecture, write code, select a specific programming language or deliver a working application under this assignment. The expected technical specification shall describe the required functions, data structures, validation logic, export formats, user roles, testing evidence and acceptance conditions, so that a future application development service provider can develop the application competitively and objectively.

The future solution shall comprise, at minimum: (i) a mobile application for offline-first field data collection; and (ii) a web-based administration and data-management portal accessible from standard desktop environments (including Windows), supporting user and role management, task assignment, workflow supervision, data validation and quality control, reporting, export functions and system administration. Both components shall operate on a single controlled backend database with a common data model, access-control scheme and audit trail.

The technical requirements shall cover, as a minimum: mobile device compatibility, offline operation, synchronization, database structure, administrator functions, data storage, backup, performance, stability, security, access control, logging, interoperability, data export, deployment, maintenance and handover requirements.

The requirements shall specify that the application must support field use on common mobile devices used by field evaluators. At minimum, Android compatibility shall be addressed; iOS or cross-platform compatibility may be included where justified by the Client’s needs and budget. The Consultant shall propose clear minimum device and operating system requirements, taking into account field usability, camera/GPS availability and expected deployment conditions.

In particular (responding to reviewer questions on the backend), the technical specification shall explicitly define, in implementation-neutral terms: (i) where and how field-collected data shall be stored, including the hosting options analysed in Section 3.10; (ii) the minimum backend database requirements (controlled data model, referential integrity, unique identifiers, spatial attributes, transaction logging); (iii) how records shall be validated upon synchronization (server-side re-validation, conflict handling, duplicate detection, rejection/return workflow); (iv) how access shall be controlled (role-based access, authentication, session management, least-privilege administration); and (v) how data shall be backed up and restored (backup frequency, retention, recovery testing, responsibility).

The Consultant shall define requirements for a sustainable and maintainable solution, including documentation, configuration, administrator access, avoidance of vendor lock-in where possible, use of open/reusable export formats, and transfer of ownership of deliverables, source files, documentation and configuration materials as required by the Client, in accordance with the data-governance requirements of Section 3.10.

Development of the data model, data dictionary and validation rules

The Consultant shall prepare a complete data model and data dictionary for the RVS solution. The data dictionary shall translate the RVS methodology into a structured set of application fields, controlled vocabularies, field types, validation rules and export attributes.

For each field, the data dictionary shall include at least: field ID, field name, description, data type, mandatory/optional status, allowed values or domain, units where applicable, source or rationale, validation rule, dependency on other fields, export name, GIS relevance and notes/limitations.

The data model shall apply the Common Data Standard of Subcomponent 3.1 (Section 3.12): stable unique building identifiers, administrative-unit coding based on CUATM, the agreed coordinate reference system(s), and controlled building-typology vocabularies compatible with the exposure model of the seismic risk map methodology (Activity 1c). The data model shall also include the calibration-readiness fields defined under Section 3.1.

The Consultant shall define validation and consistency checks for field data. As a minimum, these shall include mandatory field checks, coordinate validity, duplicate building detection logic, consistency between number of storeys and building type, valid domains for structural typologies, photo completeness checks, date/time/user checks and logical checks required by the RVS methodology.

The Consultant shall also define the required export formats and attribute structure. At minimum, the future application shall be capable of exporting clean datasets in CSV/XLSX and GIS-compatible formats such as GeoPackage and/or GeoJSON, with stable unique identifiers and complete metadata. Where API or database export is required, the Consultant shall define the minimum expected structure and documentation.

Definition of QA/QC, testing, UAT and acceptance framework

The Consultant shall prepare the QA/QC and testing framework to be used during future application development and acceptance. The framework shall follow the QAP logic for application/IT deliverables and shall include the minimum evidence required for the application to be accepted before field use.

The Consultant shall define test scenarios covering at least: installation/login, role-based access, creation of tasks, offline data entry, photo/geolocation capture, validation rules, synchronization, correction workflow, supervisor validation, export, import/opening of exported files in GIS/table tools, audit trail and administrative functions, including the functions of the web-based administration portal, backup/restore evidence and server-side re-validation upon synchronization.

The Consultant shall prepare a draft Test/UAT Register template, including test ID, scenario, precondition, steps, expected result, actual result, pass/fail status, defects, severity, retest status, UAT decision and approval/confirmation fields. The framework shall also define defect severity levels and conditions under which the application can be accepted, accepted with conditions or rejected.

The acceptance framework shall define a two-stage acceptance for the future solution: Stage 1 — functional UAT in a controlled environment against the test scenarios; Stage 2 — a supervised field pilot on a limited building sample, performed with Client-designated certified evaluators, verifying the complete chain (task assignment → field collection → synchronization → validation → export) under real conditions before final acceptance. The obligations of the future application-development service provider in the field pilot shall be defined in the procurement-ready specification (Section 3.7).

The Consultant shall specify that final acceptance of the future solution will require an accepted UAT decision for the exact release/version, a test report, defect register, release notes, installation/export package, user/admin documentation and confirmation that the fields, functions and exports are correct and usable for RVS data collection and further processing, together with the accepted field-pilot report under Stage 2.

Preparation of the procurement-ready ToR and technical specification for subsequent application development services

The Consultant shall prepare a procurement-ready Terms of Reference and technical specification for the subsequent acquisition of application development services for the digital data-collection solution. This document shall be sufficiently detailed to allow qualified software developers or application development service providers to understand the scope, submit comparable offers and deliver a product that can be objectively tested and accepted.

The procurement-ready technical specification shall include, at minimum: background and objective, scope of subsequent application development services, required application modules, functional requirements, minimum technical requirements, data model, export requirements, security and access requirements, testing and UAT requirements, field-pilot obligations (Stage 2 acceptance), hosting and deployment options with their implications, data-governance obligations (data ownership, source-code and IP transfer, documentation and build/deployment instructions), warranty and post-acceptance support requirements (indicatively a minimum 12-month warranty and defect-correction period), deliverables, implementation timeline, support/warranty requirements, documentation requirements, handover requirements, acceptance criteria and evaluation inputs for procurement, if requested by the Client.

The specification shall be written in a way that reduces ambiguity and procurement risk. Requirements shall be measurable, testable and traceable. The Consultant shall avoid vague formulations such as "user-friendly" without defining the expected functionality, usability condition or acceptance evidence.

Inputs for training, field data collection and post-collection validation

Although the actual user training, building screening and data validation are subsequent activities, the Consultant shall prepare the application requirements in a manner that supports these activities. The requirements shall specify the minimum documentation and support materials that the application development service provider shall deliver for user training and field deployment.

The Consultant shall define the minimum content of user and administrator documentation, including quick-start guidance for field evaluators, administrator manual, data export procedure, troubleshooting notes, synchronization rules and basic data quality instructions, as well as training-of-trainers materials enabling MIRD/OEAPM-PIU and designated institutions to train future evaluators without dependence on the developer.

The Consultant shall additionally deliver, as part of the final package, a concise Specification Reading Guide (indicatively 10-15 pages) explaining to MIRD/OEAPM-PIU how the requirements package is structured, how to use it during the procurement and acceptance of the application-development services, and how to manage changes through the Change Request mechanism, and shall present it in a dedicated handover session

The Consultant shall also define how the future application shall support post-collection validation, cleaning, checking and consistency analysis. This shall include export of record status, validator comments, modification history, mandatory metadata and quality flags needed for the future building inventory database in the investigated area.

Consultations with MIRD/OEAPM/PIU and revision based on comments

The Consultant shall work in close coordination with MIRD and OEAPM/PIU throughout the assignment. The Consultant shall organize or participate in technical meetings to confirm the methodological basis, field workflow, data model, functional requirements, technical requirements and draft procurement-ready specification.

The Consultant shall maintain a Comment Log for all comments received from MIRD, OEAPM/PIU, the World Bank or other designated reviewers. The Comment Log shall include at least: comment ID, source of comment, document/page/section reference, comment text, Consultant’s response, action taken, status and version in which the change was

Related documents

• Switzerland – IT services: consulting, software development, Internet and support – (25112) 609 IKT-Dienstleistungen für individuelle Softwarelösungen — Office fédéral des constructions et de la logistique OFCL (CHE)#605963
• Switzerland – IT services: consulting, software development, Internet and support – (25112) 609 IKT-Dienstleistungen für individuelle Softwarelösungen — Office fédéral des constructions et de la logistique OFCL (CHE)#605960
• Poland – IT services: consulting, software development, Internet and support – Wsparcie i rozwój Zintegrowanego Informatycznego Systemu Zarządzania Przedsiębiorstwem oraz utrzymanie licencji ATiK Orac — Polskie Porty Lotnicze S.A. (POL) · 6#655870
• Consultancy Services for Procurement of Software Development, Update, and Maintenance Support Services for the Infectious Disease Surveillance and Early Warning System (İzci) Web and Mobile Applicatio — Türkiye Preparedness for Public Healt#606527
• Risk Management Software — Cumberland Council — Ideagen ConvergePoint#1571318