TENDER – Software Development & Migration (IBU)

1. Client

Institut Bauen und Umwelt e.V. (IBU)
Hegelplatz 1
10117 Berlin

Represented by the Managing Director: Florian Pronold
Responsible contact person: Amar Salcinovic
Email: salcinovic@ibu-epd.com

2. Objective and subject of the tender

The client intends to award the reimplementation/renewal of the application operated at epd-online.com. The existing solution will be technically replaced (“replacement”) and further developed in terms of functionality.

• Agile software development Iterative collaboration. Requirements may be refined and adjusted during the project (change management, see Section 6).
• Data migration is part of the contract (see Section 7). No 1:1 migration of all data – only business-relevant data will be transferred, in particular taking into account the links with IBU.data.
• No obligation for 100% new development: Existing systems with similar functionality may be introduced or forked and adapted, provided all requirements are met (see Section 10).

The current application at epd-online.com serves as a functional reference. The binding basis is the set of requirements described in the attached requirements specification (“Lastenheft”) and the functional and technical specification (“Pflichtenheft”) to be created in the project on this basis.

3. Scope of services (scope)

1. Requirements analysis in accordance with the requirements specification, initialization of the product backlog.
2. Functional specification (Phase 1) as a functional and technical specification incl. technical concept, architecture and data model sketches.
3. Development of UI/UX concept Creation of the design and user guidance concept, incl. user stories for the key core functions.
4. Agile implementation based on the functional specification.
5. Quality assurance & tests: Unit, integration, system and acceptance tests; test data; test reports.
6. Data migration incl. mapping, ETL processes, test migrations, validation and cutover (details in Section 7).
7. Technical documentation & program description, operations/administration manual, user documentation.
8. Introductory training for administrators and key users.
9. Bug fixing up to successful acceptance (see Section 8).
10. Maintenance & support after acceptance (mandatory component, see Section 11).

Optional services (to be specified in the offer): Hosting/operation, monitoring, CI/CD setup, performance/load tests, accessibility review.

4. Project phases and milestones

1. Phase 0 – Kick-off & setup: Team, tools, repository, definition of ready/done.
2. Phase 1 – Functional specification: Development up to the agreed final version as the basis for implementation and acceptance incl. technical concept.
3. Phase 2 – Development of UI/UX concept Creation of the design and user guidance concept, incl. user stories for the key core functions.
4. Phase 3 – Agile development: Iterative development according to the agreed milestones, ongoing backlog maintenance.
5. Phase 4 – Test & acceptance: System/UAT tests, defect list, acceptance according to criteria (Section 8).
6. Phase 5 – Rollout & data migration: Cutover plan, go-live, hypercare.
7. Phase 6 – Maintenance & support: SLA-based support.

5. Project organisation & communication

• Methodology: Agile model, iterative development with regular feedback cycles, regular coordination meetings, backlog.
• Tools: Collaboration (e.g. MS Teams/Jira/Confluence), code management GitLab (private), CI/CD.
• Communication: Regular meetings (jour fixe), minutes, decision log.
• Transparency: Risk/issue log, regular status reports.

5a. Public GitLab repository for requirements specification, questions & changes

To increase transparency, the client sets up a public GitLab repository (tender/requirements documents only, no source code).

Purpose & usage

• Single source of truth for the requirements specification: docs/Lastenheft.md (source) and docs/Lastenheft.pdf (output).
• Questions exclusively as GitLab issues up to the question deadline (see Section 18). Answers/additions will be documented publicly there.
• Change history via commits, tags/releases (e.g. v0.9, v1.0);
• Bidders subscribe to the repo (watch/release notifications) to stay informed about changes.

Repository structure

• /README.md – Short description, participation information, deadlines, link to the PDF.
• /docs/Lastenheft.md – Source; /docs/Lastenheft.pdf – Output.

Governance & rules of engagement

• No submission of offers via GitLab. Offers are submitted as described in Section 18.
• No confidential information may be posted in issues.
• Clarifications will be made by the client via commit/release and referenced in CHANGELOG.md.
• After contract award, source code development will take place in a private GitLab repository of the client (see Section 9).

6. Agile collaboration & change management

• Changes to the scope of services are introduced in a controlled manner into the product backlog, prioritised and planned.
• In the case of significant scope changes, impacts on time/price must be assessed (change request).
• Acceptance criteria are defined in advance for each user story/function and form the basis for reviews/acceptances.

7. Data migration (part of the contract)

• Objective: Transfer of the business-relevant master data taking into account existing links with IBU.data.
• Scope of services: Data inventory & classification, mapping concept, ETL processes, test migrations, data quality checks, logs, defect lists, cutover plan (incl. downtime windows), fallback strategy.
• Not 1:1: Only necessary data will be migrated; reduction/transformation in accordance with the functional specification.
• Data protection: Implementation in accordance with GDPR/BDSG; pseudonymisation/anonimisation where possible; data processing agreement (DPA) prior to production go-live (see Section 14).
• Acceptance: Formal confirmation of data quality based on defined validation rules/samples.

8. Acceptance, quality assurance & warranty

• Quality standards: Clean code, code reviews for system-critical components, automated tests, awareness of OWASP Top 10.
• Acceptance criteria: Fulfilment of the functional specification & agreed acceptance criteria, successful completion of test cases, elimination of major defects (severity definitions in the functional specification).
• Acceptance process: UAT with protocol; partial acceptances where applicable.
• Warranty: Defect rectification within a warranty period (to be specified in the offer; minimum proposal: 12 months from acceptance).

9. Source code, repository & documentation

• Repository: Complete source code in a private GitLab repository owned by the client. Access for the contractor is granted on a project basis.
• Licence & confidentiality: Code is strictly confidential and not public. Disclosure to third parties or use for third parties without prior written consent is prohibited.
• Documentation: Architecture, API specifications, operations manual (runbook), user manual, migration and test documents versioned in the repository.
• CI/CD & quality: Pipeline configurations, IaC (if commissioned), linter/formatter rules, test reports.

Transfer of rights

• Unless otherwise stated in the offer, all rights of use and exploitation to all work results newly created in the project (including source code) shall pass to the client after full payment.
• Pre-existing components of the contractor (including a contributed fork) remain the property of the contractor; the contractor grants the client a perpetual, worldwide, unrestricted, transferable and sublicensable licence to use such components within this solution, including access to source code, modification and operation.
• If, after consultation with the client, fee-based third-party applications or interfaces (e.g. for document generation or similar purposes) are used in the system, the client shall be the licence holder of the respective software and shall bear the costs incurred.
• The contractor warrants that no third-party rights are infringed and that open-source licences (including copyleft) are compatible and documented (SBOM/third-party notice). Copyleft licences that trigger publication obligations must be approved in writing in advance.

10. Permissible reuse / forks

• Bidders may propose existing systems and create a fork in order to meet the requirements of the requirements specification.
• Without the prior written consent of the client, the fork may not be disclosed to third parties, published or used for third-party projects, insofar as project-specific components are concerned.
• The contractor ensures that all contributed components are legally compliant and that the rights of use specified in Section 9 are granted.

11. Maintenance & support (mandatory component)

• Scope: Bug fixing, security updates, minor adjustments, performance tuning.
• Suggested SLA: Response times per priority (P1 critical – e.g. 4h; P2 high – 1 business day; P3 normal – 3 business days), service times (working days xx:xx–xx:xx, time zone Europe/Berlin), communication channels, escalation.
• Release management: Versioning, change log, planned maintenance windows.

12. Content of the offer (mandatory components)

Company-related information

• Company profile
• Evidence of qualifications and professional expertise
• References of own projects and, in general, web applications

Project-related information

• Description of the planned agile approach
• Project organisation & communication structure
• High-level technical concept (desirable but not mandatory)
• Measures for quality assurance & test strategy
• Optional: Hosting/operation concept

Price information

• Complete and comprehensible price information (e.g. fixed-price components, daily rates)
• Presentation of price calculation and assumptions
• Costs for maintenance, support and further development (mandatory, SLA-based)
• Optional services to be shown separately (e.g. hosting, load tests)

Legal information

• Presentation of the licence/right-of-use grant in accordance with Sections 9–10
• Declaration on third-party software/OSS incl. licence list/SBOM
• Sample data processing agreement (DPA) or declaration of willingness to conclude one

13. Award criteria

• Quality & suitability of the high-level technical concept
• Migration approach and risk management
• Traceability & feasibility of the schedule
• Price and transparency of the calculation
• Quality & scope of maintenance/support (SLA)

(Optionally, bidders may be invited to online bidder presentations/demos.)

14. Data protection (GDPR) & information security

• Compliance with EU GDPR and BDSG.
• Conclusion of a data processing agreement (DPA) before go-live.
• Privacy by design/by default, data minimisation, authorisation concepts, logging.
• Information security according to best practice (e.g. OWASP, hardening, protection of trade secrets).

15. Confidentiality (NDA)

All information provided during the tender and project phase is confidential. Disclosure to third parties is prohibited. This obligation continues beyond the end of the contract.

16. Contractual terms and conditions

• The contractual basis is the functional specification jointly confirmed after contract award as well as this tender.
• Any collateral agreements must be in written form.
• Transfer of rights and repository rules in accordance with Sections 9–10.
• Billing and payment terms in accordance with the offer.

17. Procedure

1. Publication/dispatch of the tender documents incl. link to the public GitLab repository
2. Deadline for questions: queries exclusively via GitLab issues in the public repo; answers/clarifications will be published there.
3. Submission of offers (not via GitLab)
4. Review and evaluation of the offers
5. Follow-up questions/bidder presentations (optional)
6. Award decision
7. Contract award and project start

There is no entitlement to the award of the contract.

18. Deadlines

• Deadline for bidders’ questions: 01.12.2025, 18:00
• Submission deadline: 31.01.2025, 18:00
• Desired project start: 01.04.2026

Please understand all deadlines as referring to the Europe/Berlin time zone.

19. Communication

Public GitLab repository (Q&A & changes):
Questions regarding the requirements specification and clarifications are handled exclusively via issues in the public repository. The link is provided with the tender. Answers are visible there to all bidders.

Formal/administrative communication:
Amar Salcinovic
Email: salcinovic@ibu-epd.com
Please do not submit offer documents or confidential content via GitLab.

20. Annexes

• • A1 – Requirements specification (binding)