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

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 implemented. The final package shall be submitted only after comments have been addressed and all major open issues have either been closed or clearly escalated/recorded according to the Change Request or NC/CAPA mechanism, where applicable. The Consultant may be requested to support the Client during the validation of the final requirements, including clarifications necessary for approval/validation by MIRD/OEAPM/PIU within the review period following final submission (indicatively by 30.04.2027, subject to the Week-0 anchor under DR-1).. Consultations conducted under the assignment shall follow the principles of the Project Stakeholder Engagement Plan (SEP), ensuring inclusive participation, transparent communication and appropriate documentation of stakeholder feedback. Data governance, privacy and security requirements The Consultant shall prepare a dedicated data-governance chapter of the requirements package, covering at minimum the following, in implementation-neutral terms: • Data ownership: all data collected through the future solution, the configured system, its documentation and derived datasets shall be the property of the Government of the Republic of Moldova, administered by MIRD or a designated subordinate institution; • Hosting: an options analysis with indicative cost and responsibility implications for at least two hosting arrangements — (i) the MCloud government cloud platform / e-Government infrastructure, and (ii) dedicated infrastructure administered by MIRD or a designated institution — without prescribing the final choice, which is institutional; • Personal-data protection (Law No. 133/2011): purpose limitation and data minimization (no personal data of residents/owners beyond what GD 334/2025 strictly requires); field guidance for photo capture so that identifiable persons, vehicle plates and private interiors are avoided where practicable; access restriction to personal-data fields; retention and anonymization/aggregation rules for publication-oriented outputs; and identification of the need for a data-protection impact assessment as an institutional responsibility; • The technical specification shall include appropriate safeguards for future field data collection, including respectful interaction with building occupants, protection of personal information, and clear information on available Project GRM channels for submitting feedback or complaints • Security: role-based authentication and least-privilege administration, encryption of data in transit and of the central data store, audit logging, separation of test and production environments, and basic vulnerability-management and incident-handling obligations for the developer; • Backup and continuity: minimum backup frequency, retention, restoration testing and assignment of responsibility between the operator and the developer during warranty; • Source code and intellectual property: full transfer to the Client of source code, build and deployment instructions, configuration and documentation upon acceptance (or an equivalent escrow arrangement where a justified exception is accepted by the Client); • Maintenance and sustainability: a maintenance and support skeleton (warranty period, defect severity response categories, update responsibilities) and identification of the institutional operator, required capacity and indicative recurrent resources for operating the solution beyond project completion Limited field validation — form walkthrough and tabletop simulation Before finalizing the specification, the Consultant shall validate the draft data-collection form and field workflow through a limited, low-cost exercise that does not require any software development: a structured form walkthrough and tabletop simulation using the draft data dictionary in paper form and/or configured in a generic, freely available survey tool used solely as a mock-up. • Scope: indicatively 5–15 buildings in at least two localities (one urban, one rural), covering the predominant building typologies; • Participants: Key Expert 2 (and Key Expert 4 for workflow/usability observations), together with Client-designated future evaluators where feasible; • Focus: completeness and clarity of fields, controlled lists and evaluator instructions; realistic time per building; photo and GPS practicality; ambiguity and friction points; supervisor/validation steps simulated on the collected sample; • Output: a Field Walkthrough and Tabletop Simulation Report (Deliverable D3a) documenting findings and the resulting changes to the data dictionary, forms, workflow and functional requirements, each traceable in the Requirements Traceability Matrix. For clarity, this exercise is a specification-validation instrument. It is not a statistical screening pilot and does not replace the supervised field pilot of the developed application, which is defined as Stage 2 of acceptance under Section 3.6 and in the subsequent-stage schedule of Section 5.1. Cross-ToR coordination and Common Data Standard The Consultant shall participate in the cross-ToR coordination mechanism of Subcomponent 3.1: (i) a joint inception workshop with the consultants of ToRs 1a, 1c and 1d (as mobilized), organized by OEAPM/PIU; (ii) the adoption, within the first 8 weeks, of a common data protocol implementing the Common Data Standard below; and (iii) review gates at Deliverables D3 and D5, to which the consultants of ToRs 1a and 1c shall be invited as reviewers of interoperability aspects. Common Data Standard (defaults, shared with ToR 1a): coordinate reference system MOLDREF99 (EPSG:4026) for national datasets, with geographic coordinates (WGS84) for GPS capture and conversion rules documented; administrative-unit coding based on CUATM with stable unique building identifiers; controlled building-typology vocabulary compatible with the Activity 1c exposure model; file formats GeoPackage/GeoJSON for spatial data and CSV/XLSX for tabular data; metadata per ISO 19115; and a data-privacy line under Law No. 133/2011 for any building-level data containing personal or sensitive attributes. Indicative dependencies and handoffs (inputs/outputs, non-blocking): ID | From → To | Content | Timing / nature H1 | ToR 1a → ToR 1b | Administrative-unit seismic hazard zoning values (preliminary) | Input for scoring-context mapping and calibration-readiness (Section 3.1); indicative — if not yet available, the Consultant proceeds with the current normative zoning and documents the assumption H2 | ToR 1b → ToR 1c | RVS data model and data dictionary (exposure/vulnerability attribute structure) | Key output handoff at D3 (draft) and D5 (final); reviewed at the D3/D5 review gates H3 | ToR 1b → application-development service provider | Procurement-ready ToR, technical specification and QA/UAT package | Final handoff at D5, through the Client Quality Assurance and Technical Requirements The Consultant shall implement a structured Quality Assurance and Quality Control process for all deliverables prepared under this assignment. The purpose of this process is to ensure that the functional requirements, technical requirements, data model, UAT framework and procurement-ready specification are complete, technically correct, traceable, internally consistent and suitable for review, validation and later use in subsequent application development procurement. Compatibility with RVS methodology, GD 334 and related Subcomponent 3.1 outputs The Consultant shall demonstrate that the requirements package is compatible with the RVS methodology described in GD 334 of 05-06-2025 and with the QAP requirements applicable to the RVS mobile application, RVS pilot/field launch and data/GIS deliverables. The requirements shall also be coherent with the future use of RVS data for exposure and vulnerability components of seismic risk analysis. The Consultant shall prepare a Compatibility Matrix showing the link between the RVS methodology, application functions, data fields, validation rules, export outputs and testing/UAT evidence, including compliance with the Common Data Standard (Section 3.12). This matrix shall be used to confirm that the future application covers all necessary functions and does not create gaps between methodology, field collection and later data processing. Requirements traceability and data model control Each requirement shall be traceable from source to specification and from specification to acceptance evidence. The Consultant shall maintain a Requirements Traceability Matrix showing, at minimum: requirement ID, source/rationale, requirement text, priority, related data field or function, test scenario, acceptance criterion and status. The data model shall be controlled as a formal project output. Any change to field names, data types, domains, mandatory status, validation rules or export structure shall be recorded in the Version Log and, where it affects scope or interpretation, in the Change Log / Change Request. Internal QA/QC The Consultant shall carry out internal QA/QC before each official submission. No draft, revised or final deliverable shall be submitted to the Client without prior internal verification by the Consultant. Internal QA/QC shall cover, at minimum: completeness of the deliverable, consistency of terminology, consistency between requirements and data dictionary, completeness of acceptance criteria, clarity of test scenarios, consistency of user roles and workflow, absence of contradictions between functional and technical requirements, version control and inclusion of all annexes and registers. The Consultant shall submit an Internal QA/QC Checklist with each major deliverable package. The checklist shall indicate, for each verification item, whether it was checked, by whom, on what date, what issue was identified and how it was resolved. Peer-review and domain validation If the Client requires peer-review, the Consultant shall provide all editable requirements documents, matrices, data dictionary, workflow diagrams and test/UAT templates necessary for verification. The Consultant shall address peer-review comments through the Comment Log. Version Log, Comment Log, Data Register, Test/UAT and NC/CAPA records The Consultant shall maintain a Version Log for all official submissions. Each submitted version shall have a unique code, version number, date and status. The minimum versioning structure shall include Draft v0.1, Revised/Consolidated v0.2 or higher and Final v1.0. The Consultant shall maintain a Comment Log for all comments received from MIRD, OEAPM/PIU, the World Bank or other designated reviewers. Comments classified as major shall be closed before the deliverable is proposed as final, unless the Client explicitly agrees otherwise. The Consultant shall maintain a Data Register / Data Dictionary Register for all datasets, forms, fields and export structures defined by the assignment. The Consultant shall also prepare Test/UAT Register templates and an NC/CAPA Register template for future use during application development and acceptance. Acceptance of deliverables by the Beneficiary A deliverable shall be eligible for acceptance only if it meets the scope requirements, is complete, technically clear, traceable, internally consistent and delivered in the required format. For this assignment, acceptance shall require at least the following: main report/specification in DOCX and PDF; Requirements Traceability Matrix; functional requirements; technical requirements; data dictionary; workflow diagrams; QA/UAT framework; test scenarios; acceptance criteria; Version Log; Comment Log; internal QA/QC checklist; and, where applicable, peer-review/domain validation evidence. A submission shall be considered incomplete if it does not include the supporting annexes, matrices, data dictionary, acceptance criteria, QA records or editable files required for review. Major non-conformities shall block final acceptance. Minor non-conformities may allow “accepted with conditions” only if the condition, responsible party and deadline for closure are recorded in the Comment Log or NC/CAPA Register. Final acceptance shall be confirmed only in writing by the Client or Beneficiary, through e-mail, minute, handover note or acceptance form, and shall explicitly indicate the accepted version number and date. Submission of a deliverable alone shall not be considered acceptance. Deliverables and Timeline The Consultant shall prepare and submit the deliverables listed below. The indicative deadlines are calculated from the contract signing date No. | Deliverable | Indicative deadline D1 | Inception Report and Detailed Work Plan (incl. joint inception workshop and common data protocol inputs) | within 4 weeks from contract signing D2 | RVS Methodology, QAP and Field Workflow Review Report (incl. Requirements Source Matrix and the GD 334 typology/seismicity mapping and calibration-readiness framework) | within 7 weeks from contract signing D3 | Draft Functional and Technical Requirements, Data Model and UAT Framework (incl. administration portal, backend, data-governance and security requirements) | within 13 weeks from contract signing D3a | Field Walkthrough and Tabletop Simulation Report (Section 3.11) | within 15 weeks from contract signing D4 | Draft Procurement-Ready ToR and Technical Specification for Application Development Services | within 17 weeks from contract signing D5 | Final Requirements Package, Procurement-Ready ToR, Data Dictionary, QA/UAT Package and Handover Package (incl. Specification Reading Guide and handover session) | within 20 weeks from contract signing Note: The review periods of the Client/Beneficiary (indicatively 10 working days for short deliverables and 15 working days for major deliverables, per Section 8.4) are not counted within the Consultant's execution weeks; deadlines above are therefore net of review time. One consolidation round per deliverable (review → revision → resubmission) is included in the timeline; if the Client requires a second full review iteration for a deliverable, the corresponding time shall be added through the Change Request mechanism without penalty to the Consultant. D1. Inception Report and Detailed Work Plan The Inception Report shall confirm the Consultant’s understanding of the assignment, proposed methodology, work plan, team organization, consultation approach, key risks and proposed structure of the final requirements package. It shall also include a detailed schedule showing all steps from document review to final delivery within the relative timeline above (final package within 20 weeks from contract start), together with the Consultant's inputs to the common data protocol (Section 3.12). D2. RVS Methodology, QAP and Field Workflow Review Report This deliverable shall include the review of GD 334 of 05-06-2025, QAP requirements, existing RVS forms/guidelines, expected field workflow, user roles, data quality needs and dependencies with subsequent project activities. It shall include the initial Requirements Source Matrix and a draft list of application modules and data groups, together with the GD 334 typology/seismicity mapping and the calibration-readiness framework (Section 3.1). D3. Draft Functional and Technical Requirements, Data Model and UAT Framework This deliverable shall include the first complete draft of functional requirements, technical requirements, user roles, workflow diagrams, data model, data dictionary, validation rules, export requirements, QA/QC logic, test scenarios and UAT acceptance framework, , explicitly covering the administration portal functions, data storage and hosting options, backend database requirements, synchronization re-validation, access control and backup/recovery (Sections 3.4 and 3.10). D3a. Field Walkthrough and Tabletop Simulation Report This deliverable shall document the exercise defined in Section 3.11: sample and localities, participants, findings on form completeness, clarity, timing, photo/GPS practicality and workflow friction points, and the resulting traceable changes to the data dictionary, forms and requirements. D4. Draft Procurement-Ready ToR and Technical Specification for Application Development Services This deliverable shall include a procurement-ready draft ToR and technical specification for the subsequent acquisition of application development services for the digital data-collection solution. It shall include scope, application modules, required deliverables, implementation timeline, testing/UAT requirements, field-pilot obligations, hosting options and data-governance obligations, handover requirements and acceptance criteria for the application development service provider and shall incorporate the findings of D3a. D5. Final Requirements Package, Procurement-Ready ToR, Data Dictionary, QA/UAT Package and Handover Package This deliverable shall include the final consolidated package after Client and Beneficiary comments. The final package shall include the functional and technical requirements, procurement-ready ToR/technical specification, Requirements Traceability Matrix, data dictionary, validation rules, workflow diagrams, Test/UAT Register template, QA/QC checklist, Version Log, Comment Log, Change Log/NC-CAPA templates, the Specification Reading Guide, editable files and PDF versionsIndicative dependency timeline for subsequent Activity 1b stages The Consultant shall take into account the subsequent implementation stages shown in the Activity 1b implementation chart. These stages are not part of the Consultant’s core deliverables under this assignment, but the requirements package must be suitable to support them. The periods below are indicative, are owned by the Client, derive from the Week-0, and have been resequenced so that each stage follows the outputs it depends on. Subsequent stage | Responsible | Approval / verification Approval/validation of functional and technical requirements | OEAPM/MIRD | MIRD Acquisition of application development services (on the basis of the validated specification) | Client (procurement entity to be designated)t | MIRD Application development and testing (incl. Stage 1 functional UAT) | Application development service provider | MIRD Supervised field pilot on a limited building sample (Stage 2 of acceptance, Section 3.6) | Developer + Client-designated certified evaluators User training for data collection | Developer / designated trainers (training-of-trainers materials per Section 3.8) | MIRD Data collection / building screening | Engineers, architects and certified technical experts | MIRD Data validation, cleaning, checking and consistency control | Designated data/QC team | MIRD Reporting and Format of Deliverables Language of deliverables, reporting process and final submission package Deliverables shall be prepared in English. In addition, the following shall be delivered in Romanian: the procurement-ready ToR and technical specification (main document), the data dictionary controlled vocabularies and all evaluator-facing/user-facing texts, the Specification Reading Guide, and executive summaries of D2 and D3. . Each deliverable shall be submitted in three stages, where applicable: Draft, Revised/Consolidated and Final. Each submitted version shall include a clear document title, deliverable code, version number, date of issue, author/organization and status. Each official submission shall be accompanied by a short transmittal note listing all files included in the package and identifying the main document to be reviewed. The Consultant shall maintain an updated Version Log and Comment Log throughout the assignment. Required formats The final submission package shall include, as applicable: • main report / requirements specification in DOCX and PDF; • procurement-ready ToR and technical specification for application development services in DOCX and PDF; • Requirements Traceability Matrix in XLSX and/or DOCX; • Data Dictionary / Data Model in XLSX and/or DOCX; • Workflow diagrams in editable format and PDF/PNG; • Field Walkthrough and Tabletop Simulation Report (D3a) in DOCX and PDF; • Test/UAT Register template and test scenarios in XLSX and/or DOCX; • QA/QC checklist, Version Log, Comment Log, Change Log and NC/CAPA templates; • README file explaining the folder structure, file purpose, version and use restrictions, if any. Where GIS export requirements are defined, sample attribute structures, field lists and metadata templates shall be provided in reusable tabular format, aligned with the Common Data Standard (Section 3.12). No final GIS production dataset is expected under this preparatory assignment unless explicitly requested by the Client. Key Qualification Requirements The Consultant shall propose a team capable of 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. The proposed team shall include at least four Key Experts. The Key Experts shall reflect the main technical risk of the assignment: correct definition of RVS field data, vulnerability/exposure indicators, validation logic and data structures for seismic risk analysis - and the correct translation of these into a feasible, consistent and implementable IT specification. Although the assignment does not include software development or coding, its main output is a procurement-ready specification for a future IT application; the preparation of functional and technical requirements, system workflows, data models, testing procedures and acceptance criteria therefore requires dedicated, evaluated IT expertise within the core team. Additional IT input (e.g. UX/UI, cybersecurity/data protection, database design) may still be mobilized as non-key or short-term support. The methodological weight of the evaluation remains with the seismic/RVS and GIS/data experts (Section 9).. Key Expert 1 — Team Leader / RVS Methodology and Seismic Risk Specialist The Team Leader shall be responsible for the overall technical direction of the assignment, methodological coherence, coordination with MIRD/OEAPM/PIU, quality of deliverables and final integration of requirements. Minimum requirements: • demonstrated knowledge of building typologies, vulnerability indicators, seismic risk concepts and field assessment/screening methods is a must; • degree in civil engineering, structural engineering, earthquake engineering, disaster risk management or a related field; • at least 7 years of relevant professional experience in structural/seismic engineering, seismic risk assessment, vulnerability assessment, RVS or technical methodologies for buildings; • experience in preparing or coordinating technical methodologies, guidelines, Terms of Reference, technical specifications or institutional reports; • ability to translate methodological requirements into practical field data collection requirements and acceptance criteria. • attestation as certified technical expert in constructions in the Republic of Moldova, or a designer certificate in the relevant field, shall be considered an advantage. Key Expert 2 — Building Screening / Seismic Vulnerability Assessment Specialist The Building Screening / Seismic Vulnerability Assessment Specialist shall be responsible for translating the RVS methodology into practical field screening requirements, building data fields, vulnerability and exposure indicators, evaluator instructions, validation logic and acceptance criteria, and shall lead the form walkthrough and tabletop simulation (Section 3.11). Minimum requirements: • degree in civil engineering, structural engineering, earthquake engineering, architecture, disaster risk management or a related field; • at least 5 years of professional experience in building assessment, structural/seismic vulnerability assessment, building typology assessment or disaster risk reduction related to buildings; • demonstrated knowledge of building typologies, structural systems, visible vulnerability indicators, non-structural risk-relevant observations, occupancy/exposure information and practical field screening constraints; • ability to convert methodology provisions into field forms, data collection instructions, controlled answer options, validation rules, quality flags and evaluator guidance; • experience with RVS methodologies, building inventory surveys, GIS-linked field data collection, technical guidelines or methodological reports shall be considered an advantage. • attestation as certified technical expert in constructions in the Republic of Moldova, or a designer certificate in the relevant field, shall be considered an advantage Key Expert 3 — GIS, Spatial Data and Data Management Specialist The GIS, Spatial Data and Data Management Specialist shall be responsible for the data model, spatial attributes, export requirements, metadata, identifiers, data quality controls and interoperability with GIS/seismic risk analysis workflows, including compliance with the Common Data Standard (Section 3.12). Minimum requirements: • degree in GIS, geoinformatics, geography, civil engineering, data science, computer science or a related field; • at least 5 years of professional experience in GIS, spatial data management, database design, geospatial datasets or field data collection systems; • demonstrated experience with data dictionaries, metadata, coordinate reference systems, GIS-compatible formats such as GeoPackage/GeoJSON and tabular exports such as XLSX/CSV; • ability to define validation rules, unique identifiers, attribute structures and export packages suitable for quality control and later integration into risk analysis; • experience with building inventory, infrastructure datasets or disaster risk data shall be considered an advantage. Key Expert 4 — IT Business Analyst / Digital Data Collection Specialist The IT Business Analyst / Digital Data Collection Specialist shall be responsible for the feasibility, consistency and implementability of the specification as an IT product: structuring the functional and technical requirements, system workflows, backend/portal requirements, testability of acceptance criteria and coherence between the data model and the future implementation. Minimum requirements: • degree in computer science, software engineering, information systems, business informatics or a related field; • at least 5 years of professional experience in business analysis or requirements engineering for software systems, digital data-collection solutions or information systems for public or institutional clients; • demonstrated experience in preparing functional and technical specifications, data models, workflow definitions, test/UAT frameworks or acceptance criteria for software procurement or development; • experience with mobile/offline field data-collection platforms or survey/inventory systems shall be considered an advantage; • experience with IT procurement under World Bank or other IFI/public-sector procurement frameworks shall be considered an advantage. Non-Key Experts / Optional Specialists The Consultant may propose non-key experts as needed, including a UX/UI specialist, cybersecurity/data protection specialist, database developer, mobile application developer,, QA/UAT specialist, procurement/ToR drafting specialist, training specialist or field data collection specialist. These experts may support specific parts of the assignment, particularly the formulation of implementation-neutral technical requirements, test scenarios, user roles, data security, deployment assumptions and handover requirements. They shall not be considered Key Experts for evaluation purposes, but their involvement may be assessed as part of the Consultant’s organization, methodology and ability to deliver a complete and implementable package. The Consultant may also demonstrate that members of the proposed technical team have practical experience with digital survey tools, mobile data collection, GIS-linked forms or database exports. This is acceptable, provided that the final requirements package remains clear enough for a future application developer to implement and for MIRD/OEAPM/PIU to test and accept. Client’s Inputs and Institutional Coordination Available documents The Client shall provide, to the extent available, the relevant project documents and inputs necessary for the assignment, including: QAP for Subcomponent 3.1, implementation chart for Activity 1b, RVS methodology described in GD 334 of 05-06-2025, existing RVS forms or guidelines, relevant seismic risk map methodology inputs, data/GIS requirements, institutional comments and any other documents needed for preparing the requirements package, as well as the preliminary administrative-unit hazard values from Activity 1a as they become available (handoff H1, Section 3.12). Coordination with MIRD and OEAPM/PIU OEAPM/PIU shall act as the main operational and contractual coordination point. MIRD shall act as the main Beneficiary for technical review, institutional validation and acceptance. The Consultant shall coordinate all official submissions through the channels indicated by OEAPM/PIU. Access to stakeholders and users The Client shall facilitate, where feasible, consultations with future users or institutional stakeholders, including potential field evaluators, data validators, GIS users and MIRD/OEAPM/PIU reviewers and shall facilitate access to the localities and building samples for the form walkthrough under Section 3.11. The Consultant shall prepare the materials for these consultations and record decisions, comments and follow-up actions. Comments on deliverables Comments shall be transmitted in writing, preferably in consolidated form, within the review period agreed in the work plan. For planning purposes, the ToR may assume 10 working days for review of short deliverables and 15 working days for review of major deliverables, unless otherwise agreed. These review periods are subject to the clock-stop rule in Section 5. The Consultant shall respond to all comments through the Comment Log. Comments classified as major shall be closed before the deliverable is submitted as final, unless the Client explicitly agrees otherwise. If comments require changes to scope, requirements logic, data model, deadlines or procurement assumptions, the issue shall be recorded as a Change Request, where applicable. Technical meetings and consultations As a minimum, the assignment should include: one inception meeting (combined with the joint inception workshop under Section 3.12 where practicable), one RVS methodology and workflow review meeting, one requirements/data model review meeting, one draft technical specification review meeting and one final validation/presentation meeting (combined with the handover session under Section 3.8). Additional meetings may be organized if required by the complexity of comments or by the need to resolve technical issues. After each meeting, the Consultant shall record the main conclusions, decisions, actions, responsible parties and deadlines. These records shall support the traceability of decisions and revisions made during the assignment.