HIGH-LEVEL REQUIREMENT IDENTIFICATION
The basis of architecture definition is built on an analysis of requirements, as this provides the necessary context and scope for the system to be built, including its desired functionality, as well as its main quality attributes. For complex projects such as data spaces, requirement elicitation is an iterative process performed in stages, with a gradually increasing level of detail. The initial set of requirements identified typically corresponds with high-level functionality at the core of the system, without which it cannot achieve its purpose.
These, albeit high-level and often not fully precise requirements, tend to be Architecturally Significant Requirements (ASRs), defined as those that have a profound impact on the final design, for example, that data spaces should support data transfer and exchange between participant infrastructures. Once identified, top-level requirements are further broken down into more, for example, which interfaces and standards to follow, building a hierarchical requirement tree gradually through the design lifecycle, often iterating between architecture definition, implementation, and further requirement elicitation steps
In this documentation we are mostly concerned with top-level requirements. Two effective ways to identify these are stakeholder interviews as well as the analysis of the business goals of the system. Data spaces are a European policy initiative, with a clearly defined objective to increase the availability of data within the economic fabric of the European Union, supporting its competitiveness and digital sovereignty. This is fully reflected in policy documents such as the aforementioned Staff Working Document (SWD) on the Data Spaces as well as the DIGITAL work programme.
ARCHITECTURE DEFINITION
The first stage of architecture definition should effectively transition from high-level requirements known at the start of the project to an initial implementable design that satisfies key stakeholder concerns, in this case those from data spaces participants.
- They should provide functionality for a wide range of stakeholders, at societal scale. These include not only policy-makers and public administrations, but also private sector organisations of all sizes, the scientific community, and the public at large. While being a brand new initiative, Data Spaces cannot be considered to be a fully greenfield project to be built from scratch. Indeed, many public and industry-led initiatives have started to build and pilot data sharing ecosystems, and there is an expectation that the know-how —and even the software building blocks— these projects produced could be reused for the European Data Spaces.
Since the EU policy documents and programmes are themselves based on extensive stakeholder consultation, the requirements extracted from these sources are already informed by the needs of data spaces users across all sectors of interest. We therefore scanned relevant policy documents in order to extract requirements of data spaces and we further classified these into functional and non-functional categories. While functional requirements define what data spaces must provide, i.e. they explain the concrete components of data spaces, non-functional requirements define how data spaces should work, i.e. their quality attributes.
For this reason, requirement elicitation is performed at two different levels, including within the data spaces themselves, as well as at the level of the data spaces.
POLICY PROVISIONS ON DATA SPACES
The table below is a collection of policy provisions on data spaces, based on the data spaces policies. Such provisions are translated into groups of functional and non-functional requirements. These could form the basis for more granular requirement elicitation, as well as for an analysis of the functionality provided by existing data sharing initiatives
| Policy provision | Functional requirements | Non-functional requirements |
|---|---|---|
| A secure and privacy-preserving IT infrastructure to pool, access, process, use and share data | Data Transfer and Exchange Data Storage Data Processing and Analytics Data Processing and Analytics Data Pooling & Collaboration | Security Confidentiality |
| Data holders will have the possibility, in the data space, to grant access to or to share certain personal or non-personal data under their control | Identity, Authentication & Access Control Usage Control Policies | Confidentiality |
… promote the development of tools to pool, access, use and share all types of data favouring the development of common open standards and findable, accessible, interoperable and reusable (FAIR) principles... data holders could use these tools to ease the uploading of data into data spaces, to give or revoke their authorisation to data and to change access rights and specify new conditions of how their data can be accessed and reused over time | Data Transfer and Exchange Identity, Authentication & Access Control Usage Control Policies | Interoperability |
| Data that is made available can be reused against compensation, including remuneration, or for free. | Transaction Metering and Billing | |
| Participants […] use the common technical infrastructure and building blocks which will allow the data spaces to be built in an efficient and coordinated manner | Maintainability Variability | |
| The common technical infrastructure will have to […] integrate the cybersecurity-by-design principle | Security |
Suggested Section: Functional Requirements
Learn about what Functional Requirements define a data space or the relevant technical questions about data spaces covered in the Technical ‘How to’ Information sheets.