Requirements
Asses the list of requirements that guide Simpl-Open development.
The requirements define the functionalities and capabilities that guide the development and evolution of Simpl-Open.
This page presents the Business Processes (BP), Supporting Activities (SA), and Non-Functional Requirements (NFR) that structure the Simpl-Open requirements framework.
The requirements evolve continuously and are open for discussion. Each section provides information on newly introduced or updated requirements.
Your input is essential to help shape the future of Simpl-Open. Explore the requirements, provide feedback, and contribute to ongoing discussions. Contribution guidelines are available to help ensure submissions meet the Programme's standards and expectations.
Business processes
Business processes define how participants can share, discover, access, and use resources within a federated ecosystem. They also define how trust, governance, and operations are managed to enable secure collaboration between participants.
Non-functional requirements
The non-functional requirements define the qualities that make Simpl-Open a trustworthy and effective platform. They ensure that it is secure, interoperable, scalable, reliable, usable, and open. Together, these requirements define how Simpl-Open should behave, perform, evolve, and integrate across federated ecosystems.
Supporting activities
Supporting activities describe the capabilities required to enable and sustain the operation of a Simpl-Open data space. They provide the foundation needed to support the effective delivery, management, and operation of Simpl services and capabilities.
Requirement definitions
The requirements are organised and grouped by two levels of detail:
High-level requirements
L1 requirements describe high-level functional or non-functional capabilities and expected outcomes. They define what Simpl-Open must support without prescribing implementation details.
Example:
Users must be able to discover datasets available within a data space.
Detailed requirements
L2 requirements provide the detailed functional and technical specifications needed to implement a L1 requirement.
Example:
The system shall allow users to search datasets using keywords and metadata, filter search results, and view dataset details prior to requesting access.
Acceptance criteria
Each requirement includes acceptance criteria that define when it is considered complete. These criteria ensure clarity, testability, and alignment with Simpl-Open goals. They typically describe:
- The context in which the requirement applies (GIVEN)
- The action or event that triggers it (WHEN)
- The expected outcome (THEN)
Acceptance criteria help maintain consistency and quality across all requirements.
How are requirement contributions processed?
- Input can be submitted through comments on this website, forum, code.europa.eu
or by email 
, but are also gathered via the Simpl-Live feasibility studies that identify common requirements. - Next, contributions are routed to the relevant teams for review.
- They are then evaluated for feasibility and alignment with Simpl programme goals, and a decision is made on whether to include them in the roadmap and how to prioritise implementation.
- Finally, the outcome is communicated back to the contributor and/or the community.
Simpl-Open development status
Curious about the ongoing expansion of Simpl-Open Capabilities? Visit the development status page and discover everything that Simpl-Open can do.
Simpl-Open architecture
Learn more about Simpl-Open’s technical choices.