Expression of Interest (EoI) :

Consultancy for API Development for the Extended producer Responsibility Service

Reference Number: 83481280

Date of Publication: 16.01.2025

1 Context

1.1 About GIZ

As a service provider of international cooperation for sustainable development and international education, the Deutsche Gesellschaft für Internationale Zusammenarbeit (GIZ) GmbH is committed to a future worth living for all people worldwide. With more than 50 years of experience in a wide range of fields, from economic and employment promotion to energy and environmental issues to the promotion of peace and security, GIZ applies its expertise as a federal enterprise in around 120 countries with various clients - from the German Federal Government, institutions of the European Union, the United Nations, the private sector, and governments of other countries. GIZ cooperates with companies, civil society actors and scientific institutions. In this way, it contributes to the successful interaction of development policy and other fields of policy and action. The main client of GIZ, which is based in Eschborn, Berlin and Bonn, is the German Federal Ministry for Economic Cooperation and Development (BMZ). 

Gender equality is one of the key values of our company and of the work we do. It is a prerequisite for and driver of sustainable development and a viable future of the Rwandan society. That is why we take a gender-sensitive and wherever needed a gender-differentiated approach within all our programs. GIZ fosters equal rights and opportunities for everyone, regardless of their gender, sexual orientation, and gender identity.

Furthermore, GIZ supports the Government of Rwanda promotes the integration of ICT in all sectors as one of the key solutions addressing the existing challenges in different sectors especially in mining. This aligns with the 7 Years Government Program “National Strategy for Transformation (NST 1), 2017–2024” which defines the priority sectors including energy, agriculture, private sector development, environment and natural resources, urbanization, transport, tourism, manufacturing, and ICT.

1.2 Background

The Deutsche Gesellschaft für Internationale Zusammenarbeit (GIZ) GmbH is a federally owned international cooperation enterprise for sustainable development with worldwide operations. The GIZ Office in Kigali covers GIZ’s portfolio in Rwanda and Burundi. GIZ Rwanda/Burundi implements projects on behalf of the German Federal Ministry for Economic Cooperation and Development, the European Union and other commissioning authorities in the following priority areas: Sustainable Economic Development, Good Governance, Climate, Energy and Sustainable Urban Development, Digitalization and Digital Economy, Mineral Governance, Peace and Security in the Great Lakes Region

The GIZ Rwanda Digital Cluster and the Digital Transformation Center Rwanda 

The Digital transformation and Digital Economy Cluster of GIZ Rwanda is a Rwandan-German initiative to develop impact-driven digital solutions at regional and continental levels in Africa. Therefore, it not only provides advisory services and training for government institutions and local tech companies but also a modern space to boost creativity and collaboration. 

The activities, themes, topics and implementation projects of the cluster are dedicated to delivering impact-driven digital solutions, developing the capacities of the local innovation ecosystem, and replicating and scaling up digital solutions at the regional and continental levels. The implementation of innovation in Rwanda with ICT across several sectors is in collaboration with the Ministry of ICT’s implementing agency, the Rwanda Information Society Authority (RISA). The Digital transformation and Digital Economy Cluster of GIZ Rwanda supports both the public and the private sectors in transferring knowledge and skills and developing organizational, structural, and technological capacities. 

The Digital transformation and Digital Economy Cluster of GIZ Rwanda is now organized in various topics called Verticals for orientation, and proper collaboration with partners and the Rwandan ICT ecosystem and these verticals. Some of these verticals are listed below:

Public sector Innovation 

The Public sector innovation vertical is where the government, civil society and private sector all intersect to work together in developing digital solutions and innovation around the challenges experience in the public sector. In this vertical, the demand is set through a series of collaborations from the government, mainly from the Chief Digital Officers of every sector, The Rwanda Information Society Authority RISA and the Ministry of ICT and Innovation and many other implementing agencies to work together. The solutions developed under the Public Sector innovation vertical revolve around digitization, change management, ICT building blocks, UN Sustainable Development Goals, Smart cities, and efficient delivery of Government services. 

Digital Inclusion & Literacy 

The Digital Cluster is actively involved in capacity-building and digital literacy, targeting people in rural areas, women and people with disabilities, ICT professionals, tech startups and employees of political partner agencies. The Digital Inclusion and Literacy vertical works together with several civil society organizations, The Ministry of ICT and Rwanda Information Society Authority RISA to implement joint programs that bridge the skills gap for both public servants and citizens to create an environment conducive to digital transformation and adoption of digital skills for economic development and improved livelihoods.  

 Startup Ecosystem Support 

The Digital Cluster supports young entrepreneurs and startups through incubator and accelerator programs to build and expand their businesses. These programs provide access to mentorship, funding, and resources to help young entrepreneurs overcome the challenges of starting a business. By fostering collaboration and innovation, these initiatives are helping to create a thriving ecosystem for young entrepreneurs to succeed in today's competitive marketplace. 

Artificial Intelligence Hub (AI Hub) and data 

Most of the digitalization efforts, both private and public, rely on data and insights into that data. The AI hub vertical works around Improving access to training data and AI technologies for local open innovation, strengthening local technical know-how on AI in Rwanda, Develop Policy Frameworks Ready for AI - Ethical AI, Data Protection and Privacy, and one of the biggest topics in AI under the AI hub is Machine translation. 

1.3 GovStack approach

The adoption of GovStack plays an important role during the implementation of this initiative. It builds capacities throughout the Rwandan IT ecosystem – on the governmental as well as non-governmental side and focuses on: 

Awareness building: across public and private stakeholders by trainings, participation on conferences, workshops, especially with:

• Local private implementation partners
• Government clients
• Government institutions

Capacity Building:enabling civil servants to understand and use the GovStack approach for improved service implementation

Operationalizethe adoption of the GovStack approach by establishment of implementation capacity in Rwanda.

Technical support: support of ministries to adopt the GovStack approach by using four building blocks and supporting in the implementation of use cases to create evidence for the rapid adoption rate.

Utilizing the approach described, Govstack adheres to seven core principles during the stages of design, development, and roll-out.

1.3.1 User-Focused

Creating the most effective tools starts with empathetic engagement, comprehending, and crafting solutions that cater to the needs of the end-users. A user-focused technological solution will exhibit characteristics such as:

• User-centric design methodologies.
• Ensuring users have the "Right to be forgotten" by allowing data erasure.

1.3.2 Openness:

Govstack champions the use of open technologies, which can help in lowering costs and preventing dependency on specific vendors. Open technology is characterized by:

• Adherence to open standards.
• Alignment with Digital Development and Digital Investment Principles (available at https://digitalprinciples.org/and https://digitalinvestmentprinciples.org/ ).
• Preference for open-source software whenever feasible.
• Encouragement of open development practices (see https://standard.publiccode.net/).
• Adoption of cloud-native technologies like Docker/Docker Compose/OCI containers where possible.

1.3.3 Sustainability:

Applications should be built sustainably, guaranteeing they continue to receive updates and maintenance. A key aspect of sustainability includes:

• Favoring a microservices architecture over a monolithic approach to enhance interoperability, development speed, deployment speed, and system reliability.

1.3.4 Security:

In deploying any technology, ensuring its security is crucial, with the following security features:

• Development methodologies and standards that emphasize quality and security.
• Various certification levels to indicate compliance with standards.
• Routine security scans and audits.
• Openness to public ratings and reviews.
• Detailed logging and error management.

1.3.5 Accessibility:

Ensuring technology solutions are accessible to everyone is critical. Accessible design features include:

• Availability across multiple platforms: web, mobile, SMS, and/or voice interfaces, with support for assistive technologies like screen readers.
• Single Sign-On (SSO) capabilities for accessing multiple services with one login.
• Open development and deployment methodologies welcoming contributions.
• Community-led development of tools for documentation and support.
• Availability of blueprints, templates, and documentation.

1.3.6 Flexibility:

In embracing the notion that Building Blocks should be adaptable and reusable, supporting various applications with minimal adjustments, Govstack focuses on:

• The reuse of Building Blocks in different scenarios.
• Autonomy of each Building Block.
• Interoperability among Building Blocks through adherence to common standards.
• Ease of setup for Building Blocks.
• Utilization of standardized protocols for configuration and communication among Building Blocks.
• Offering Building Blocks as a service to foster ICT development.

1.3.7 Robustness:

In the implementation of Building Blocks, the following principles should be upheld:

• Operability in environments with limited resources, such as intermittent power, low bandwidth, or unreliable connectivity.
• Scalability to ensure high availability and reliability.
• Use of API-only based approaches for decoupling.
• Preference for asynchronous communication patterns decoupled through brokers to optimize interactions.
• Adoption of eventual consistency models for data management.

For comprehensive specifications and more detailed information about Govstack, please refer to the following link: https://govstack.gitbook.io/specification/

1.4 About Information mediator Building Block

An Information Mediator Building Blocking provides a gateway for exchange of data and services among GovStack Building Blocks through open-API rest-based interfaces to ensure interoperability and implementation of standards. The Information Mediator provides mechanisms for applications/Building Blocks to publish and consume services and event notifications among other GovStack Building Blocks, which is displayed in

Figure 4: Architecture of Information Mediator landscape

Information Mediator services act as a channel through which Building Blocks and external applications can connect to services exposed by other Building Blocks such as the registry services and the other building blocks authentication or digital signature Building Block. The Information Mediator Building Block provides a second service, as a broadcasting channel for notification of events among the connected applications in a Publisher-Subscriber (Pub/Sub) model. And also maintains a log of transactions (e.g., requests, events), as well as handling communication errors between Building Blocks and/or other applications via the Pub/Sub service. This component may employ other core components, such as registries, repositories, etc. by allowing different applications to exchange information, it can act as a mechanism to encourage or enforce best practices, data standards around Pub/Sub, and data-sharing policies in cross-facility workflows among business processes.

Within the GovStack Sandbox there is currently one Information Mediator for multiple external applications installed. It is possible to use and extend the existing Mediator or to create and install a new mediator. This has to be considered together with the GovStack Development team. Also, within the Prototype Sub-Sandbox it is allowed to create multiple Mediators or to route all information through 1 module.

1.5 Context 

The Government of Rwanda (GoR) defines good governance as: "the exercise of political,

economic and administrative authority to manage the nation’s affairs and the complex

mechanisms, processes, relationships and institutions as well as leadership behaviour through which citizens’ groups articulate their interests, explain their complaints/concerns, exercise their rights and obligations and mediate their differences and mediate their differences”.

In the recent national ICT strategy, Smart Rwanda Master Plan envisages the Government's

Digital Transformation. The Governance Sector was among seven key sectors that were

chosen to be at the forefront of this transformation for better and smarter service delivery to

citizens.

The role of IT architecture in this context is to provide a blueprint for the design and integrationof information technology systems and infrastructure within an organization. It involves the identification of key components, the definition of standards and guidelines, and the development of a framework for the organization's technology ecosystem.

IT architecture provides a strategic roadmap for the development, implementation, and

maintenance of information technology systems and services. It enables organizations to align their technology infrastructure with their business objectives, optimize technology investments,and enhance the efficiency, security, and effectiveness of their IT operations.

The Government of Rwanda through the Ministry of information communications technology

MINICT has established various implementation agencies in the field of ICT, digital economy,

digital transformation, and digitalisation of Rwanda as a whole. MINICT has the vision to foster ICT development and diffusion in Rwandan Society and Economy. The following affiliated agencies help the Ministry to achieve its mission through the implementation of policies and programs, The Rwanda Information Society Authority (RISA) is the main ICT implementing agency, Rwanda Utilities Regulatory Authority (RURA) is a regulatory body, and the others like the Rwanda Development Board (RDB) and the National Post Office (NPO) respectively.

The Cluster Digital Transformation and Digital Economy works closely with MINICT and RISA to implement various digitisation efforts through setting up the government of Rwanda’s ICT building blocks and one of the building blocks are the various government software platforms that support the day-to-day business of the various institutions. These platforms are supposed to be interoperable and work efficiently and effectively to reduce costs and increase the productivity and efficiency of government entities.5

As part of the ongoing effort to support digitalization in Rwanda, GIZ seeks proposals from

qualified firms to provide API development services integrated with organizations such as RURA, REMA, RICA, RRA,RDB, PSF involved in the user journey of the extended producer responsibility service (EPR). The API’S should be developped to align with Rwanda's current and future needs and priorities, with a specific focus on enhancing the delivery of Solutionss to citizens, improving data management, increasing cyber security and working closely with the Public Sector Innovation Vertical of the Digital Cluster of the GIZ Digital Transformation Center Rwanda and the Innovation Division of RISA to streamline all software architecture of government platforms both already existing

ones and newly implemented and planned ones.

1.6 Objective of the commission/subject of the procurement

The overall objective is to support the Government of Rwanda and producers (importers, distributors, manufacturers, resellers etc.) of electrical and electronic equipment to implement a legally transparent, digitally supported and appropriately financed EPR system for e-waste management in Rwanda.  

Too often, when EPR regulation comes into place, a brand-new siloed registration system is created for producers and these producers are already using other government services that could instead be piggybacked on in order not to duplicate demands for information from the producers (the users of the service). The Solutions incudes:

• Electrical and electronic producer licensing (and automatic receipt of EPR certificate).
• Automatic producer responsibility organisation membership.
• Registration of electrical and electronic products placed on the Rwandan market.

An integrated service as such brings with it a number of benefits:

• Reduction in administrative cost burden for producers.
• Reduction in transaction time for producers and the authorities.
• Increased transparency and collaboration among the authorities.
• Improved enforcement by the authorities of producer EPR system free riders.

2 Requirements for the IT solution

2.1 General Requirements

2.1.1 Onboarding, architecture validation, testing and QA approach.

The Contractor will be onboarded by GIZ, to understand the context, goals, approach, and results of analysis done already. This will happen in several workshops, possibly with involvement of example users. At the start of the project, the contractor, GIZ and a representative of GIZ clarify the expectations for the cooperation arrangement, the technical platform for cooperation, the relevant responsibilities, and the project schedule. The first meeting also allows substantive questions to be clarified regarding the issues, objectives to be defined, requirements to be established and other contextual information to be presented. All parties will set up the necessary recurring meetings for planning events. In these workshops the vision for the project, a high-level product roadmap and corresponding assumptions dependencies etc. will be shared.

Also, the overall target architecture and resulting technical decision, especially regarding possible dependencies will be shared by the contractor in cooperation with GIZ. The Contractor is expected to lead these efforts and bring deep technical expertise, an independent outside view, and a focus on maintainable and sustainable operation.

The detailed testing approach for the user stories will be defined.

• Report assessing target architecture, including proposed changes (pros, cons, etc)
• Agreed upon final target architecture.
• Shared understanding and formalized product roadmap and vision
• Formalized and agreed upon testing approach.
• Well-groomed backlog with enough content for first sprints (items for sprint 2 can be detailed out in sprint 1, as they would normally).

2.1.2 Development Environment

The Contractor will set up at least the following three environments:

• Development environment on their own IT infrastructure
• Testing, integration, and staging environment on the GIZ IT infrastructure at National Data Centre (NDC) located in Rwanda.
• Production environment on the GIZ IT infrastructure at National Data Centre (NDC) located in Rwanda.

The contractor ensures that at least on the stage of the testing and integration environment installations are done through automated deployments where applicable including a set of automated tests that ensure at least that no broken build is deployed into the stage. The Contractor will help in automatic test data generation, if necessary, always following guidance of GIZ and RISA where applicable.

The Contractor will define and set up respective deployment and integration processes taking into consideration GIZ (with hands-off support by the management consultant assisting GIZ) this pipeline as well as environments need to be transferred or replicated to at the end of the project. The above environments shall have the same set up and configuration.

The implementation concept is drafted together with the contractor, the target group, and any other relevant stakeholders, and includes:

• Development methodology, schedule, and release plan
• Revised and prioritized functional requirements
• (Provisional) system architecture
• Depending on the methodology: description of the areas of application and system specifications or backlog, for instance with user stories
• Visualizations and outlines (e.g., mock-ups, user journeys, process outlines, ER and use case diagram)
• A documented “Definition of Done”
• A documented definition of production readiness
• Implementation concept
• Fully set up system environments
• Documentation about all environments

2.1.3 Code, Test, Deployment and Hand over

• Continuously provide complete source code and other associated application system needed to ease future upgrade based on the major changes made during the implementation mainly on quarterly basis (every 3 months starting from when the continuation of the development of Solutions was initiated).
• Deployment of completed Solutions modules (features) on the testing and production environments at National Data Centre (NDC)
• The Contractor will at an appropriate time help to automate testing, to ensure high quality and efficient delivery.
• Before the end of the contract, and in addition to the continuously prepared and already handed over work products (commented code, documentation, technical specification etc.), a formal hand over phase will be initiated. It might include hand-over or set-up of new development environments and deployment pipelines as well as shadowing, reverse-shadowing of relevant processes and development work. The goal of this dedicated handover is to ensure that another, likely local, company is familiar enough with the platform to not only operate and maintain it (this part is already ensured by continuous capacity building and mini handovers after each iteration), but also to build new functionality.
• Handing over to GIZ, the annotated/commented source codes of Solutions API

2.1.4 Documentation

The contractor must provide the detailed documentation of the functionalities and the source code annotation in good time and in an appropriate manner. The contractor is obligated to make the latest documentation available for inspection at any time.

Work results to be provided by the contractor:

• Documentation preferably based on a conventional standard (e.g., arc42 – arc42 is an example for a documentation standard)
• The documentation must include the following items in particular:
• Software stack and dependencies
• System requirements, system specifications and system architecture
• Diagrams and outlines (e.g., use case, ERD, process outlines, mock-ups)
• Other technical documentation (e.g., interfaces, (clearance of) faults)
• Continuously provide technical documentations which will facilitate the GIZ technical in operating and using Solutions successfully on various phases of Solutions implementation including the deployment, system administration and databases
• Continuously provide user manuals which will facilitate the users in operating and using Solutions successfully on various phases of Solutions implementation.
• Provide frequent technical knowledge sharing with the GIZ technical team in various technical meetings during the implementation of Solutions

2.1.5 Continuous user support and operation 

While the Contractor will not be tasked with operating the IT solution, the contractor will be in close contact with the GIZ support and operations team, which will in turn be assisted by the management consultant assisting GIZ.

The following duties do not involve access to live systems and do not entail any tasks that could be interpreted data processing of personal identifiable production data.

2.1.5.1 User-Support

The Contractor shall help resolve 2^nd and 3^rd level requests, where needed. Over time, the Contractor’s involvement should decrease, with GIZ having the tools, resources, and knowledge in place to run this support without the Contractor involvement, at the end of the contract. Until that point, Contractor personal can also be asked to be part of incident response teams.

• 2nd Level Support: Classify and systematically process requests from 1st level support, contact users directly by phone or in writing, maintain knowledge base on common problems or incidents, forward/ re-classify unsolvable issues to 3rd level support.
• 3rd Level Support: Processing of inquiries regarding IT-administrative or operational errors or malfunctions, high specialization on respective software and hardware, no direct contact with end users

2.1.5.2 Operations

The Contractor will advise on the organizational and technical operation of the platform.

The Contractor will work  together  hand in hand with GIZ Technical Team on the operation of the platform.

This includes  define processes and roles, as well as giving guidance on improving the technical set up (e.g., deployment pipelines, code repositories etc.) – this shall be done in sync with the respective capacity management.

2.2 Functional requirements and Epics

Epics describe aggregated overarching functionality which consists of features and user stories.

2.2.1 Epic 1: Development of the API Integration with RURA

2.2.1.1 RURA Business process

Rwanda Utilities Regulatory Authority (RURA), mandate, among other things, in the Information and Communication Technologies (ICT) sector is to oversee the enforcement of the e-waste management regulations, monitor, enforce license obligations, design and execute the EPR system for EEE. The regulatory and administrative role for RURA under the EPR system in Rwanda is to:

• Spearhead the development of Technical Guidelines for the Implementation of Extended Producer Responsibility on e-waste in Rwanda;
• Provide the framework for the overall implementation of the extended producer responsibility scheme;
• License the collection, transportation, and treatment facilities for e-waste;

2.2.1.2 Scope and Business Background

The scope of this epic covers the following objectives:

• Gather and document functional requirements with RURA regarding the type of information that needs to be shared with external system. This includes understanding the data formats, frequency of updates or any other specific functionalities that needs to be supported.
• Design the API structure including endpoints, data formats, authentication mechanism and any specific protocols that need to be followed.
• Develop and deploy the API following the design specifications. This involves writing the backend code to handle incoming requests, process data from RURA’s systems, and format it appropriately for consumption by the EPR.
• Test the API to ensure it functions as expected. This includes unit testing individual components, integration testing with RURA's systems, and end-to-end testing to simulate real-world usage scenarios. Address any bugs or performance issues that arise during testing.
• Create comprehensive documentation for the API, including details on endpoints, request/response formats, authentication methods, error codes, and usage examples.

2.2.2 Epic 2: Development of the API Integration with REMA

2.2.2.1 REMA Business process

Rwanda Environmental Management Authority (REMA) is the designated government agency responsible for the management and coordination of environmental compliance and regulatory enforcement. REMA’s responsibility under the EPR system, compliments and supports the work of RURA and RICA. However, its mandate is focused on EEE that are subject to Ozone Depleting Substances (ODS) regulations and the transboundary movement of e-waste.

REMA role is therefore to:

• Control, monitor, and carry out regulatory inspections on producers and other actors;
• Identify international standards on e-waste for incorporation into national law;
• Manage the transboundary movement of e-waste;
• Screen and licensing of EEE that are subject to ODS regulations prior to RICA product registration and approval;
• Collect, record, and share e-waste information such as on imports, exports, and licensed OSD operators with MININFRA.

2.2.2.2 Scope and Business Background

The scope of this epic covers the following objectives:

• Gather and document functional requirements with REMA regarding the type of information that needs to be shared with external system. This includes understanding the data formats, frequency of updates or any other specific functionalities that needs to be supported.
• Design the API structure including endpoints, data formats, authentication mechanism and any specific protocols that need to be followed.
• Develop and deploy the API following the design specifications. This involves writing the backend code to handle incoming requests, process data from REMA’s systems, and format it appropriately for consumption by the EPR.
• Test the API to ensure it functions as expected. This includes unit testing individual components, integration testing with REMA's systems, and end-to-end testing to simulate real-world usage scenarios. Address any bugs or performance issues that arise during testing.
• Create comprehensive documentation for the API, including details on endpoints, request/response formats, authentication methods, error codes, and usage examples.

2.2.3 Epic 3: Development of the API Integration with PSF

2.2.3.1 RSB Business process

PSF Business process

The PRO by PSF plays a pivotal role in the in the EPR system for EEE. The PRO acts as an intermediary among producers, regulators, and various stakeholders to ensure the responsible collection, recycling, and disposal of e-waste. In Rwanda, following a wide consultative process, stakeholders agreed that the Producer responsibility organisation for e-waste management will be the Business Research Centre (BRC). The BRC is the research arm of the Private Sector Federation (PSF), which is an umbrella organization aimed at promoting and representing the interests of the business community in Rwanda.

The BRC is legally a company limited by Guarantee that was set up under the law that governs companies in Rwanda. A company limited by guarantee is defined as a company used primarily for non-profit organizations and purposes and having the liability of its members limited to the amount as the members may agree. In terms of structure, BRC is overseen by a Board of Directors that is shown in figure 1.3. BRC has a management team headed by an Executive Director.

2.2.3.2 Scope and Business Background

The scope of this epic covers the following objectives:

• Gather and document functional requirements with PSF through PRO regarding the type of information that needs to be shared with external system. This includes understanding the data formats, frequency of updates or any other specific functionalities that needs to be supported.
• Design the API structure including endpoints, data formats, authentication mechanism and any specific protocols that need to be followed.
• Develop and deploy the API following the design specifications. This involves writing the backend code to handle incoming requests, process data from RSB’s systems, and format it appropriately for consumption by the EPR.
• Test the API to ensure it functions as expected. This includes unit testing individual components, integration testing with RSB's systems, and end-to-end testing to simulate real-world usage scenarios. Address any bugs or performance issues that arise during testing.
• Create comprehensive documentation for the API, including details on endpoints, request/response formats, authentication methods, error codes, and usage examples.

 2.2.4 Epic 4: Development of the API Integration with RRA

2.2.4.1 RRA Business process

The Rwanda Revenue Authority (RRA) is a government revenue collection agency. The RRA is charged with enforcing, assessing, collecting, and accounting for the various taxes imposed in Rwanda. Under the EPR system, RRA is responsible for:

• Evaluating, authorising and releasing all EEE that meets registration and administrative requirements into the country and on to the Rwandan market.
• Conducting spot check inspections on producers of EEE for EPR fee and tax compliance.
• Making available to the PSF, as the PRO, put on the market information for all producers of EEE;
• Undertaking financial audit of the PRO and making such audit reports available to regulatory agencies such as RURA and RICA.

2.2.4.2 Scope and Business Background

The scope of this epic covers the following objectives:

• Gather and document functional requirements with RRA regarding the type of information that needs to be shared with external system. This includes understanding the data formats, frequency of updates or any other specific functionalities that needs to be supported.
• Design the API structure including endpoints, data formats, authentication mechanism and any specific protocols that need to be followed.
• Develop and deploy the API following the design specifications. This involves writing the backend code to handle incoming requests, process data from RRA’s systems, and format it appropriately for consumption by the EPR.
• Test the API to ensure it functions as expected. This includes unit testing individual components, integration testing with RRA's systems, and end-to-end testing to simulate real-world usage scenarios. Address any bugs or performance issues that arise during testing.
• Create comprehensive documentation for the API, including details on endpoints, request/response formats, authentication methods, error codes, and usage examples.

2.2.5 Epic 5: Development of the API Integration with RICA

2.2.5.1 RICA Business process

Rwanda Inspectorate, Competition and Consumer Protection Authority (RICA) ensures that the production and importation of goods under its mandate meant for public use or consumption are conducted in accordance with standards and regulations in force. This is done through the regulation of products and services to protect health and safety of the population, plant and animal health as well as the environment as well as safeguarding health competition among enterprises while ensuring fair trading practices. RICA ensures that products and services on markets are safe and at a competitive price. It also carries out annual inspections, sensitization campaigns and training to increase compliance with relevant laws. The regulatory and administrative role for RICA under the EPR system in Rwanda is to:

• Undertake product registration as a prerequisite for product market placement, which is also directly linked with the payment of EPR fees;
• Conduct market surveillance so as to ensure compliance of Producers with standards, regulations and operator license and registration;
• Carry out industrial inspections to monitor the use of operational licenses or registration certificates for Producers and or compliance with the requirements set;
• Supervise any product withdrawal from the market of a registered product that fails compliance with the law, which is directly linked with the Producer;
• Collect, record and product registration information and share it with MININFRA for the purposes of calculation of the EPR fee by PSF and for audit purposes by RRA.

2.2.5.2 Scope and Business Background

The scope of this epic covers the following objectives:

• Gather and document functional requirements with RICA regarding the type of information that needs to be shared with external system. This includes understanding the data formats, frequency of updates or any other specific functionalities that needs to be supported.
• Design the API structure including endpoints, data formats, authentication mechanism and any specific protocols that need to be followed.
• Develop and deploy the API following the design specifications. This involves writing the backend code to handle incoming requests, process data from RICA’s systems, and format it appropriately for consumption by the EPR.
• Test the API to ensure it functions as expected. This includes unit testing individual components, integration testing with RICA's systems, and end-to-end testing to simulate real-world usage scenarios. Address any bugs or performance issues that arise during testing.
• Create comprehensive documentation for the API, including details on endpoints, request/response formats, authentication methods, error codes, and usage examples.

2.2.6 Epic 6: Development of the API Integration with RDB

2.2.6.1 RDB Business process

Rwanda Development Board (RDB) is a government institution, mandated to accelerate Rwanda’s economic development by enabling private sector growth. RDB was established primarily to create a One Stop Shop for business and investments. RDB’s key services among others include a one stop centre service for business and investment registration, Environmental Impact Assessment (EIA) and tax incentives management.

RDB in the implementation of the EPR system on e-waste is primarily responsible for offering the one stop centre for those intending to enter the business of EEE manufacturing or importation. RDB offers business operator licencing for new businesses as a prerequisite for Product and EPR registration with RICA and BRC respectively.

2.2.6.2 Scope and Business Background

The scope of this epic covers the following objectives:

• Gather and document functional requirements with RDB regarding the type of information that needs to be shared with external system. This includes understanding the data formats, frequency of updates or any other specific functionalities that needs to be supported.
• Design the API structure including endpoints, data formats, authentication mechanism and any specific protocols that need to be followed.
• Develop and deploy the API following the design specifications. This involves writing the backend code to handle incoming requests, process data from RDB’s systems, and format it appropriately for consumption by the EPR.
• Test the API to ensure it functions as expected. This includes unit testing individual components, integration testing with RDB's systems, and end-to-end testing to simulate real-world usage scenarios. Address any bugs or performance issues that arise during testing.
• Create comprehensive documentation for the API, including details on endpoints, request/response formats, authentication methods, error codes, and usage examples

2.3 Non-functional requirements

The following non-functional requirements must be considered by the contractor when implementing the service.The minimum baseline are as follows

• Portability:
• Solutions shall always be able to run on both Linux and/or windows platforms.
• Solutions should run on latest Windows and MacOS systems with similar UI experience.

Security:

• The implemented single-sign-on feature/module for Solutions external will continue to be considered in further development of the system to allow users to log in and be redirected seamlessly to any other applications provided in the future by GIZ.
• Develop Solutions with all the standard security such as Owasp 10 web application standards security which can be in-built features to ensure confidentiality, integrity, and availability of data.
• Ensuring that Solutionshave user access roles through which GIZ technical team especially with administrator’s rights can assign or revoke rights of a specific user to a function, data, element, action, or activity.
• implement measures to protect collected data from unauthorized access, manipulation, or disclosure. This includes encryption of data during transmission and storage, user authentication mechanisms, and adherence to relevant data privacy regulations such as the GIZ data policy and the Rwanda data protection and privacy law

Maintainability: The implemented solutions will easily be updated, modified, or maintained over its lifecycle. It should easily be adapted to changing requirements with minimal effort, reducing downtime and costs associated with updates and enhancements.

Reliability: The implemented solutions should consistently and accurately perform their intended functions without failures or errors. A monitoring system should be put in place to track errors in real time.

Scalability: The implemented solutions should handle the increase in requests without significant loss of performance.

Performance: The implemented solutions should have a fast response time that enables the user to complete tasks quickly.

Reusability: The implemented modules should easily be reused in different part of the other systems or future modules.

Flexibility: Solutions is developed with the mind of REST/JSON or any other API-based approach to enable future integration of Solutions with other systems

Offline Data Collection: Provide functionality for data collectors to capture data even in offline or low-connectivity with mechanism to synchronize data with the national minerals databases once connectivity is restored.

2.4 Use of open-source software (OSS)

The Solutions shall be commissioned by GIZ, must be available to the public free of charge. Digital solutions must be built in such a way as to ensure handover to the partner organisation

• Solutions must lead to the strengthening of local economic power and digital resources
• The solution sets global technical standards; positioning GIZ as an "early adopter" in the field of digital solutions
• Increasing efficiency through collaborative innovation processes
• Solutions have to be build to enable benefiting from international cooperation and alliances.
• Solutions shall be in compliance with the "Principles for Digital Development"  GIZ and Rwanda national ICT policy.
• Solutions shall be in compliance with the BMZ strategy "Digitalisation for Development" and Rwanda national ICT policy

The concept and infrastructure must therefore also be structured in such a way that they can be freely handed over to GIZ and that GIZ can also control support, operation and further development independently. This shall be achieved if the contractor only uses freely available open source components for the development of the application and makes it possible to hand over the infrastructure as an open source-licensed product.

2.5.Hosting

The contractor is responsible for furnishing a dedicated development environment to facilitate all development and testing activities. GIZ will, in turn, supply staging and production environments to accommodate all deployment needs.

2.6 Further specifications/general conditions

Not applicable.

2.7 Other Requirements

Not applicable.

3 .Responsibilities of the contractor

The contractor must deliver the following services and work packages (along with the corresponding milestones). The work packages have no chronological order and can also be implemented on an integrated basis, depending on the development methodology.

3.1 Use of Agile Methodology

This project will be developed, delivered, and sustained in a consulting contract. The target is to go along agile methodology elements using a framework orientating on the agile frameworks. The proposed methodology seems to be appropriate because:

• general scope is pre-defined, but the periodization of requirements is not stable over the whole development process.
• learning about user behaviour and preference should be incorporated quickly into the product design.
• incremental development with integrated testing limits risks associated with large IT implementations and allows to achieve value-add quickly.
• it is a well-known and well described practice framework.

As this is a new way of working for GIZ, the Contractor, together with the GIZ project are expected to act along principles of agile development, while also paying attention to context and organization-specific needs.

Iterative development based on the values of inspection, adaption and transparency will remain key, however if needed there are deviations from pure agile development (e.g., with regards to the stronger need for documentation, or the naming of specific roles).

The following main artefacts/roles will be used.

3.1.1 Sprint

Each sprint is a time boxed development phase which will be used to deliver ready to use products. The intention is, to add small features and user stories in each sprint to deliver an incrementally improved product. Each sprint shall have a two-week time box. The duration of the standard sprints can be adjusted as part of the retrospective.

3.1.2 Iteration/Product Increments (PI) 

Each iteration is a collection of sprints, usually timeboxed with 3-month cycles.

3.1.3 Feature/User Story 

Features and user stories are the artefacts which define the deliverables inside a sprint. They need to be described and documented. The team must agree on the “definition of done” for an agreement of completion of the respective artefacts. The difference between “user story” and feature for GIZ is mainly the distinction between deliverables with a concrete impact on users (resp. user stories) like implementation of a specific dashboard or workflow or deliverables with no specific impact on users (resp. features) like implementation of a core data model.

3.1.4 Backlog

The Backlog covers the list of all features and user stories which are in scope or will be in scope for implementation. It acts as the pipeline for to be implemented artefacts.

3.1.5 Daily Stand-ups

Daily stand-ups are a standard approach as part of the SCRM methodology. The technical working group (TWG) coordinated by the team leader meets at a dedicated fixed and short time slot (usually 15 minutes) and answers one by one the following questions:

• What did I do yesterday?
• What will I do today?
• What are obstacles on my way?

Based on experience we have the DO’s and DON’T’s:

DO’s

• Create and support an open environment and atmosphere.
• Schedule follow ups for identified obstacles.
• Be firm, be brief, be open.

Don't’s

• Don’t use it for individual tracking.
• Don’t expand the timeslot by going too much into the details (rather schedule follow up)
• Don’t blame.

3.1.6.Retrospective, Review & Planning

As the iterations in GIZ are quite short, best practice has been established to combine retrospective, review, and planning session. During this session the following activities are to be performed:

• Review the result of the features planned for the current sprints based on the “definition of done”.
• Assess completion status.
• Review the “definition of done”.
• Review the preparation of features in the backlog.
• Plan features or user stories for the current sprint
• Adjust the approach if necessary.

3.1.7 Scrum team

The scrum team is the team which will deliver the final solution. As per the currently planned (to be revised setup) it consists of members of:

• Implementation team of the consulting team
• Implementation team of GIZ and GoR
• Member(s) of the Technical Working Group (TWG)

3.1.8 Product owner

The GIZ project manager acts as the product owner for this project. He/she will provide priorities for project artefacts and finally accept or reject the implemented features or user stories.

3.1.9 PM-System and collaboration systems

The GIZ and/or GoR uses “OpenProject” for project tracking and planning. This system shall be used for project planning and reporting by the contractor.

3.1.10 CI/CD Environment

The contractor shall use the GIZ Data Cloud to share the source codes. However, depending on the assessment to be conducted prior to resuming the development of solutions, the contractor should use the GoR Gitlab in addition for versioning and CI/CD.

3.1.11 Continuous tasks for each sprint (Definition of Done)

In the planning, the development team agrees on a goal together with GIZ and GIZ. The Sprint Goal is the single objective for the Sprint. Although the Sprint Goal is a commitment by the Developers, it provides flexibility in terms of the exact work needed to achieve it. The Sprint Goal also creates coherence and focus, encouraging the Development Team to work together rather than on separate initiatives. The sprint goal will be documented by the contractor as a user story or feature in the defined project management system and signed off for delivery as part of the sprint planning.

All the work necessary to achieve the product Goal happens within the sprint. In each sprint the following should be done (in addition to the delivery of the respective user stories for this sprint according to best practices):

3.1.11.1 Testing and quality assurance

For each user story there will be in-depth testing by the Contractor, but also by the proxy product owner (or deputy) provided by GIZ. Final sign off will be given by the product owner based on the acceptance criteria and definition of done. While this process will evolve over time, it is expected that security and privacy by design and by default is key in this implementation and a focus of the respecting testing efforts.

3.1.11.2 Documentation

Detailed documentation of the functionalities and commentary of the source code is to be provided by the contractor for all delivered user stories.

Overarching documentation (functional and technical documentation, architecture diagrams) is incrementally updated with each sprint and will be reviewed as part of each sign-off of user stories. It shall always update to reflect current system status.

The client sets up a test environment and, during and after the development process, conducts the relevant recommended tests (e.g., unit, integration, load). Tests are also conducted regularly with future users of the IT solution.

Work results to be provided by the contractor:

• A usable increment deployed at least into the testing and integration environment.
• Test documentation

3.1.11.3 Knowledge Sharing

For each implemented feature the GIZ staff assesses the knowledge which was transferred:

• How to use the use the feature;
• How to do administration of feature;
• How to troubleshoot the feature;
• How to do further adjustments on the feature; and
• How to deploy the system.

3.1.11.4 Iteration Review

Within this review the contractor, GIZ and GIZ will have a look on the status of the product and discuss about next steps and features which are expected from the contractor. In deviation to agile methods, the meeting does not constitute a formal acceptance or confirmation of performance. Nevertheless, results and agreements done within the meeting have to be documented by the contractor and will be assessed in following iteration reviews by the review attendances.

3.1.11.5 Time Reporting

The contractor is obliged to report the delivered hours against the defined user stories and features in the project management system of GIZ. GIZ will review these time sheets and forward them to GIZ for approval. GIZ shall evaluate the performance of the contractor based on the deliverables set in the epics and iterations.

3.2 Continuous project management

The Contractor shall appoint an experienced project manager as a permanent contact person for the performance of the services over the term of the contract. The project manager who shall be responsible for project management on the part of the Contractor, including:

• Regular progress reports, after each sprint (can be exports of project management tool)
• Provide monthly report for the ongoing progress in line with the implementation of solutions to the Technical Working Group (TWG) set by GIZ and recommendation for future solutions functionality improvements.
• Input to high level product planning; feasibility assessments and high-level product design/ vision sessions that will be necessary before actual backlog items/ user stories are defined.
• Mobilizing additional expertise from respective support roles as needed

3.3 Planned Iterations/Product Increments (PI)

Each iteration is timeboxed with a timeline which shall be agreed on with the contractor during the assessment. It is a best practice to aggregate 6 sprints (each 2 weeks) per iteration. As per project management methodology the user stories and features for each iteration will be prioritized at the beginning of each iteration. The following description describes the current plan for the focus in each iteration. This focus can be adjusted as part of the iteration planning.

3.3.1 Iteration 1: 

The following epics will be the key focus for Iteration 1:

• Epic 1: Development of the API Integration with RURA
• Epic 2: Development of the API Integration with REMA

3.3.2 Iteration 2:

The following epics will be the key focus for Iteration 2:

• Epic 3: Development of the API Integration with PSF
• Epic 4: Development of the API Integration with RRA

3.3.3 Iteation 3:

The following epics will be the key focus for Iteration 3:

• Epic 5: Development of the API Integration with RICA
• Epic 6: Development of the API Integration with RDB

4Data protection and information security

4.1 Data Protection

The digital tool developed or upgraded on behalf of a local partner of GIZ must meet the highest data protection standards, especially those relating to data protection by design and by default, as stated in Annex 1. “Data protection standards for developing digital tools meant for GIZ's partners”. The contractor is therefore required to inform GIZ if any applicable national requirement is incompatible with the provisions of this annex. We equally recommend the partner to conclude data protection agreements with the hosting service provider(s) and the maintenance service provider(s), where applicable. The GIZ would be available to support the partner whenever need arises.

 The tasks to be performed by the consultants shall exclusively benefit GIZ as the service recipient of the contract between the consultants and GIZ. Where the execution of the contract involves the processing of personal data by the consultants, such processing shall be done under the responsibility of the consultants or at the instructions of GIZ, as set out in these ToR or as subsequently agreed with GIZ. GIZ does not bear ANY responsibility for such processing.   

Any processing of personal data by the consultants shall comply with applicable data protection laws. These shall also be taken into account by the consultants when developing an IT system which processes personal data.“

4.2 Information security

The following points must be considered by the contractor and if they are not within the contractor's responsibility or scope of work, they must at least be discussed with the partner's project team in order to close any existing security gaps.The Contractor must inform the Client immediately and in an appropriate form about security incidents that may affect the Client. If the Customer has appointed an IT security officer or another person to receive such information, the information must be sent directly to this person. A firewall must be installed upstream of the server (e.g., authorized IP addresses/GEO blocking or address ranges for logging on to the system can be entered here or also excluded for this purpose). Up-to-date anti-virus software must be used on the server and configured accordingly for automatic updates. Network communication between the components of the application should be encrypted.Hard-coded keys (symmetric/asymmetric) should not be included in the application. If this i unavoidable, the handling of the key must be described. The information security risks related to the storage of the key must be evaluated.The transmission of authentication information (especially passwords) must be encrypted. The storage and transmission of sensitive and/or personal data must comply with current encryption standards. Session cookies used for logins must be deleted after logging out from the client.Separation of application and data is to be provided, i.e. an application server and a separate server for the database and file storage is provided, with communication through a firewall.A system log is to be implemented in which at least logins and logouts of all users and actions such as updates, backups, uploads and downloads, changes to account data and authorizations, as well as all security-relevant actions and events are to be logged and documented. The inclusion of further log data is still to be discussed in detail with the project. The system log is to be documented in the operating manual.The error messages generated by the application (especially exception handling/exceptions) must not provide any information that allows conclusions to be drawn about the architecture or software/software versions used.

When configuring the web server, you must pay attention to the following:

• Disable Trace HTTP Request
• Run as a separate User & Group
• Disable signature
• Disable banner
• Restrict access to a specific network or IP
• Use only TLS 1.2
• Disable Directory Listing
• Remove unnecessary DSO modules
• Disable Null and Weak Ciphers
• periodically updates of the system -> stay current!
• periodically checks of the system log files

The system must be hardened against SQL injection. In detail, this concerns the validation,filtering and cleansing of user input. The inputs may only have expected properties and characters and may not contain any unauthorized metacharacters that are passed to the SQL interpreter.When implementing API interfaces, it is essential to harden them against malicious code injection (SQL injection, etc.) via the URL.The system must be protected against Cross Site Scripting (XXS) on the client side. The server(s) must be protected against reflected or persistent cross site scripting by securing the server source code. All data to be processed by the server must be validated befor execution. Whitelists of permitted data can be used for this purpose. General conversion of certain script characters is also a popular method. It is to be prevented that executable metacharacters of the scripts are read by the server. Cookies should only be read by the server (HttpOnly) and not by JavaScript in the browser.

A password policy must be implemented, which should look like this: 

• minimum number of digits e.g. 12
• latin capital letters (A-Z)
• lower case Latin letters (a-z)
• basic digits (0-9)
• non-alphanumeric characters (like !, $, #, -, &)
• your password must not contain the whole or parts of your login name!
• after 5 wrong entries the account should be locked for 3 minutes
• max. password age 90 days

password history, at least 5 different passwords in before a previously used password is accepted again, new passwords that differ only by consecutive numbers should not be accepted.Passwords must not be stored in plain text. Passwords may only be stored as hash values. The hash algorithm must conform to the current recommendations of the BSI (technical guidelines).Hard-coded passwords must not be included in the application. The transmission of authentication information (especially passwords) must be encrypted. 2-factor authentication is to be implemented; Google Authenticator is not to be used for this. 2FA is to be possible via multiple channels (app, SMS or e-mail).

A role and authorization concept must be implemented that includes at least the roles of system admin (full authorization to the entire system), CMS admin (+account management), editor and author (editing content/articles). The application to be developed must be operable with minimal system rights. Only the following user groups may have access to the backend:

Developers and administrators of the Contractor as well as employees for editorial

maintenance of the Contractor.Access to the backend at the operating system level may therefore only be granted to very limited user groups with the appropriate expertise.There must be a documented authorization concept for each application (e.g. in the operating manual).

In order to minimize operating errors (human errors), the ergonomics of the application should be designed safely according to the need for protection. Changes to account data that are required for registration may only be made by the administrators and are to be blocked for the user. For the upload of files, appropriate file filters are to be provided so that no files with executable content (scripts, programs or SQL codes) can be uploaded and executed.The regular backups of the complete system are to be carried out by the Contractor and checked accordingly for usability (restore). The backup can be stored on the server, but a copy must always be stored offline to prevent loss through hacker attacks. The intervals for the backups are to be coordinated with the project.

Important backups always belong offline on another system and must be validated!

The deletion procedure must be proven upon request. Legal retention obligations remain unaffected.

5 Language

In deviation from sections 1.2, 6.1 and 8.1 of the Supplementary Terms of Contract for IT Services – EVB-IT Standard Business Terms for IT Services (EVB-IT-Service-AGB), the services are to be provided in English.

6 Technical-methodological concept

In the conceptual design of the tender (technical-methodological approach, project management, if necessary other requirements), the tenderer is required to take specific objectives and requirements into consideration and describe them, as explained below.

6.1 Requirements for the technical-methodological concept (section 1 of the assessment grid)

In the tender, the tenderer is required to show how the services specified in section 3, where relevant taking account of other specific methodological requirements (section 2), are to be provided (technical, methodological concept).

6.1.1 Assessment of the requirements:

The tenderer must assess the objective and the requirements of the IT solution (see sections 1 and 2) in relation to feasibility and to what particular (non-)technical difficulties must be considered in the IT solution to be developed by the tenderer regarding the objective (section 1.1 of the assessment grid).

6.1.2 Project management and development methodology:

The tenderer should consider the design of the project management process and describe his or her methodology for development/implementation, considering the described requirements (section 2 and 3) and compliance with the milestones (section 3) (section 1.2 of the assessment grid).

6.1.3 Operational plan/personnel assignment plan:

The tenderer must create and explain an operational plan that also includes a personnel assignment plan for all the specialist staff that he or she offers. The operational plan must depict the assignment periods (time and expert days) and describe the necessary work steps and take account of and, where necessary, supplement section 3.3 (section 1.3 of the assessment grid).

6.1.4 Test and documentation concept:

The tenderer must describe the process for testing and documenting the IT solution and the IT security and documentation standards used (section 1.4 of the assessment grid).

6.2.Additional requirements (section 2 of the assessment grid)

Not applicable.

7.Human resources

7.1 Human resources concept

The tenderer is required to provide staff for the positions (‘experts’) referred to and described here in terms of the scope of tasks and qualifications based on corresponding CVs (see section 7).

The qualifications specified below meet the requirements for achieving the highest score in the technical assessment.

Expert 1: Project Manager and Architect (Section 3.1 of the assessment grid)

Tasks of the Expert

• Overall responsibility for the advisory packages of the contractor (quality and deadlines and scope).
• Coordinating and ensuring communication with GIZ, Irembo, RISA, partners and others involved in the project.
• Personnel management, identifying the need for short-term assignments within the available budget, as well as planning and steering assignments and supporting local and international short-term experts.
• IT Architecture for the solution
• Regular reporting in accordance with deadlines; and
• Making himself/herself available when needed by the GIZ, Irembo and RISA as beneficiary.

Qualifications:

Education/training (section 3.1.1 of the assessment grid):	Masters degree in computer science, Computer engineering, or relevant field with skills  in project management (Note: Masters degree equals maximum points)
Language (section 3.1.2 of the assessment grid):	Good business language skills in English
General professional experience (section 3.1.3 of the assessment grid):	7 years of professional experience in the IT sector
Specific professional experience (section 3.1.4 of the assessment grid):	2 years of proven track record of leading the development of Complex systems (Front-end, Back-end, mobile app, integrations with minimum 5 other systems) with the use of open-source software as well as proven track record of experience in business analysis and product management
Leadership/management experience (section 3.1.5 of the assessment grid):	5 years of project management experience as IT project team leader in a company
Development cooperation and regional experience (section 3.1.6 of the assessment grid)	1 year of experience in projects in Africa (region) ,1 year experience working with development cooperation and 1 year of international experience.

Expert pool 1 ‘Software Development Team’ with minimum of 2 to maximum 3 experts Section 3.5 of the assessment grid)

The experts can be exchanged during the contractual period in consultation with the officer responsible for the commission.

A CV for each expert must be added to the tender.

Task of the Expert Pool

• Support team leader in the implementation of the defined tasks

Qualifications:

Education/training (section 3.5.1 of the assessment grid):	All experts with university qualification (Masters or Bachelor or equivalent) in computer science, Computer engineering, or relevant field
Language (section 3.5.2 of the assessment grid):	All experts with good business languaged skills in English
General professional experience (section 3.5.3 of the assessment grid):	All experts with 4 years of professional experience in software development.
Specific professional experience 1 (section 3.5.4 of the assessment grid):	1 expert with a proven track record of 3 years in the development of state of the art API’s development.
Specific professional experience 2 (section 3.5.6. of the assessment grid):	1 expert with a proven track record of 2 years in the testing of state of the art API’s development.

The tenderer must provide a clear overview of all the proposed experts and their individual qualifications.

8.Costing requirementsAssignment of experts

In your tender, please do not deviate from the specification of quantities required in these Terms of Reference under this section (the number of experts and expert days), because this is part of the competitive tender and is used to ensure that the tenders can be compared objectively. There is no entitlement to use the total number of expert days.

The number of expert days corresponds to the working days.

Expert	Total Expert days
Expert 1:(1Expert) Managing software engineer	12
Expert pool 1: Software Development Team (minimum of 2 to maximum 3 experts)	61

9 Requirements on the format of the tender

The structure of the tender must correspond to the structure of the ToR. It must be legible (font size 11 or larger) and clearly formulated. The language in which the tender must be written is English.

The technical-methodological concept of the tender (section 7 of the ToR) is not to exceed 12 pages (not including the cover page, list of abbreviations, table of contents and brief introduction).

The CVs of the staff proposed in accordance with section 0 of the ToR must be in the EU format and not exceed four pages in length. The CVs must clearly show what position the proposed person held, which tasks he or she performed and how many expert days he or she worked during which period in the specified references. The CVs should be submitted in English.

We strongly request that you do not exceed the number of pages specified.

10 Submission of the offer

Technical Proposal

• A cover letter expressing your interest in this assignment
• Technical Proposal (See attached template for technical proposal)
• Self declaration of eligibility form
• Company registration certificate (RDB)
• VAT registration certificate
• Valide Tax clearance certificate
• Up to date CVs of proposed experts

Financial offer:

Financial offer indicates the all-inclusive total contract price, supported by a breakdown of all costs as described in the cost requirements. The costs must be in RWF and VAT excluded.Your EoI has to be submitted in 2 separated emails to RW_Quotation@giz.de until latest 30.01.2025:

• The technical offerhas to be submitted in PDF format and as attachment to the email with the subject: 83481280-Technical offer
•  The financial offerhas to be submitted in PDF format and as attachment to the email with the subject: 83481280-Financial offer 

If the emails exceed the default email size of 30MB, offers can be exceptionally submitted through https://filetransfer.giz.de/ (The subject of file transfer must be edited with the subject above mentioned, otherwise your offer should not be considered).

Offers submitted through any other sharing platform, as google documents or similar will not be considered.

Offers submitted in hard copy will not be considered.

GIZ reserves all rights.