D4.1 Functional and technical requirements elicitation...Functional and technical requirements...

D4.1 – Functional and technical requirements elicitation Version 1.0 – Final. Date: 30.05.2018

Project Title: CITADEL Contract No. GA 726755

www.citadel-h2020.eu

of 51

Empowering Citizens to Transform European Public Administrations

Deliverable D4.1

Functional and technical requirements elicitation

Editor(s): Juncal Alonso (TECNALIA) Marisa Escalante (TECNALIA) Leire Orue-Echevarria (TECNALIA)

Responsible Partner: TECNALIA

Status-Version: Final – v1.0

Date: 31/05/2017

Distribution level (CO, PU): PU




of 51

Project Number: GA 726755

Project Title: CITADEL

Title of Deliverable: Functional and technical requirements elicitation

Due Date of Delivery to the EC: 31/05/2018

Workpackage responsible for the Deliverable:

WP4 – ICT Enablers to transform

Editor(s): TECNALIA

Contributor(s):

Juncal Alonso (TECNALIA) Marisa Escalante (TECNALIA) Leire Orue-Echevarria (TECNALIA) Gorka Benguria (TECNALIA) Iñaki Etxaniz (TECNALIA) Alberto Molinuevo (TECNALIA) Gayane Sedrakyan (imec) Diomede Iluzzi (FINCONS)

Reviewer(s): Iñaki Etxaniz (TECNALIA)

Approved by: All Partners

Recommended/mandatory readers:

WP5, WP3, WP2

Abstract: This document includes the complete set of functional and technical requirements that CITADEL solution should have. For the elicitation of these requirements several methods have been used: questionnaires to the use case providers and technical work-packages, benchmarking with existing tools and techniques, etc. Different versions of the requirements have been provided following an incremental approach.

Keyword List: functional requirements; use case requirements, technical requirements.

Licensing information: This work is licensed under Creative Commons Attribution-ShareAlike 3.0 Unported (CC BY-SA 3.0) http://creativecommons.org/licenses/by-sa/3.0/

http://creativecommons.org/licenses/by-sa/3.0/




of 51

Disclaimer This document reflects only the author’s views and neither Agency nor the Commission are responsible for any use that may be made of the information contained therein




of 51

Document Description

Document Revision History

Version Date Modifications Introduced

Modification Reason Modified by

v0.1 04/04/2018 TOC draft version TECNALIA

V0.2 04/05/2018 Section 1, section 2 and section 3 completed,

TECNALIA

V0.3 14/05/2018 Contributions from imec and FINCONS Conclusions

Imec, FINCONS, TECNALIA

V0.4 23/05/2018 Comments from the internal review addressed.

TECNALIA

V1.0 24/05/2018 Version ready for submission TECNALIA




of 51

Table of Contents

Table of Contents .......................................................................................................................... 5

List of Figures ................................................................................................................................ 6

List of Tables .................................................................................................................................. 6

Terms and abbreviations ............................................................................................................... 7

Executive Summary ....................................................................................................................... 8

1 Introduction .......................................................................................................................... 9

1.1 About this deliverable ................................................................................................... 9

1.2 Document structure ...................................................................................................... 9

2 Requirements management in CITADEL ............................................................................. 10

2.1 Methodology for requirements elicitation ................................................................. 10

2.1.1 Requirements gathering and prioritization ......................................................... 10

2.1.2 Requirements documentation ............................................................................ 12

3 CITADEL ecosystem requirements ...................................................................................... 15

3.1 Functional requirements ............................................................................................. 15

3.1.1 Intelligent discovery of public services ............................................................... 17

3.1.2 Digital Maturity Assessment ............................................................................... 19

3.1.3 Co-creation methodology supporting tools ........................................................ 21

3.1.4 KPI Report generation - Visualization and report generation ............................. 22

3.1.5 KPI Report generation – Harvesting and curation............................................... 24

3.1.6 User assessment .................................................................................................. 25

3.1.7 Security management – Access management +encryption ................................ 27

3.1.8 Security management- Anonymization ............................................................... 29

3.1.9 CITADEL ecosystem ............................................................................................. 30

3.2 Use cases requirements .............................................................................................. 31

3.2.1 Intelligent discovery of public services ............................................................... 32

3.2.2 Digital Maturity Assessment ............................................................................... 32

3.2.3 Co-creation methodology supporting tool .......................................................... 33

3.2.4 KPI report generation .......................................................................................... 34

3.2.4.1 Harvesting + curation+ Fusion ......................................................................... 34

3.2.4.2 KPI visualization and report generation .......................................................... 35

3.2.5 User assessment .................................................................................................. 35

3.2.6 Security management ......................................................................................... 36

3.2.7 CITADEL ecosystem ............................................................................................. 37

3.3 Technological requirements ........................................................................................ 37

3.3.1 Technology implications ...................................................................................... 37

3.3.2 Integration requirements .................................................................................... 38




of 51

3.3.3 Legal requirements.............................................................................................. 41

4 Requirements alignment and prioritization ........................................................................ 42

4.1 Functional requirements and KRs alignment matrix ................................................... 42

4.2 Functional and use cases alignment matrix ................................................................ 43

4.3 Requirements prioritization matrix ............................................................................. 46

5 Conclusions ......................................................................................................................... 48

6 References ........................................................................................................................... 49

7 Annex 1 – Prioritization of functionalities by the use cases ............................................... 50

List of Figures

FIGURE 1. CITADEL PROCESS FOR REQUIREMENTS GATHERING AND PRIORITIZATION .................................. 10 FIGURE 2. COLOUR CODE FOR REQUIREMENTS PRIORITIZATION................................................................ 14 FIGURE 3. CITADEL ECOSYSTEM GENERIC ARCHITECTURE ...................................................................... 16 FIGURE 4. CITADEL ECOSYSTEM DEPLOYMENT ARCHITECTURE ............................................................... 17 FIGURE 5. DIFFERENT INTEGRATION LEVELS IN CITADEL USE CASES ......................................................... 40 FIGURE 6. COLOUR CODE FOR REQUIREMENTS PRIORITIZATION................................................................ 47 FIGURE 7. ANALYSIS OF USE CASE NEEDS FOR CITADEL COMPONENTS (SOURCE D5.1 SECT. 5.5 [5]) ............ 50 FIGURE 8. USE CASE SPECIFIC NEEDS - PRIORITIES (SOURCE D5.1 [5]) ....................................................... 50 FIGURE 9. ANTWERP USE CASE SPECIFIC NEEDS - PRIORITIES (SOURCE D5.1) ............................................. 51 FIGURE 10. REGIONE DI PUGLIA USE CASE SPECIFIC NEEDS - PRIORITIES (SOURCE D5.1 [5]) ......................... 51 FIGURE 11. VARAM USE CASE SPECIFIC NEEDS - PRIORITIES (SOURCE D5.1 [5]) ....................................... 51

List of Tables

TABLE 1. TRACEABILITY MATRIX KEY RESULT – REQUIREMENT (EXCERPT) ................................................. 13 TABLE 2. TRACEABILITY MATRIX FUNCTIONAL-USE CASE REQUIREMENTS (EXCERPT) ................................... 13 TABLE 3. REQUIREMENTS PRIORITIZATION MATRIX (EXCERPT) ................................................................. 14 TABLE 4. CITADEL PROCESSES .......................................................................................................... 15 TABLE 5. OVERVIEW OF THE BASELINE TECHNOLOGIES FOR THE CITADEL COMPONENTS. ............................ 38 TABLE 6. INTEGRATION REQUIREMENTS IN THE CITADEL ECOSYSTEM ...................................................... 39 TABLE 7. FUNCTIONAL REQUIREMENTS AND KRS ALIGNMENT MATRIX ...................................................... 42 TABLE 8. FUNCTIONAL AND USE CASE REQUIREMENTS ALIGNMENT .......................................................... 44 TABLE 9. CITADEL ECOSYSTEM FUNCTIONAL REQUIREMENTS PRIORITIZATION. .......................................... 47




of 51

Terms and abbreviations

AN Anonymization

CC Cocreation Methodology Supporting Tool

CE CITADEL Ecosystem

DM Digital Maturity Assessment

DoA Description of the Action

EC European Commission

FR Functional requirement

HC Harvesting and Curation

ICT Information and Communication Technologies

ID Intelligent Discovery of Public Services

KP KPI visualization and report generation

KR Key Result

SC Security Management

UA User Assessment

UC Use Case

UI User Interface

WP Work Package




of 51

Executive Summary

The objective of the present document is to provide an updated version of the functional and technical requirements of the CITADEL Ecosystem and its components. CITADEL Ecosystem, to be developed in the context of WP4-ICT Enablers to transform, will comprise the CITADEL components implemented (KR2, KR4, KR5, KR6 and KR 7) and their integration in the CITADEL ecosystem (KR8). CITADEL ecosystem and the components, along with other results from the other work packages, will be validated in the case studies defined in WP5.

This document is an updated version of the WD 4.1, and incorporates updated information of other deliverables from WP4 (D4.2, D4.3).

This document includes the description of the iterative process followed to acquire the functional and non-functional requirements and the updated version of the functional, use cases and technology elicited requirements. It also includes a set of traceability matrices, where the relationship between the different requirements is shown.

The main results of these document consist on the updated version of the functional and non-functional requirements for the CITADEL ecosystem and the related components.

In this document, the requirements elicitation process is described as an iterative process where both the technology providers and use case providers’ have participated.

All through the deliverable, the different requirements and the process to obtain them are explained. For the functional requirements, the FURPS approach has been followed. For the use cases requirements, an iterative approach (see section 2.1 of the current document) extracting those reflected in D5.2 to align them to the goals of the project was followed. In the case of technological requirements, a distinction between technology implications, integration requirement and legal requirements has been made. For the technology implications the tools and technologies that will be used to develop the different components have been analysed. The integration requirements between the components of the ecosystem with respect to the existing IT systems of the public administrations are described and finally the current legal jurisdiction of data ownership has been considered for the legal requirements.

These requirements will serve for the continuous development and improvement of the CITADEL ecosystem and its components.




of 51

1 Introduction

1.1 About this deliverable

This document presents an updated version of the elicitation of the functional, technological and use cases requirements of the CITADEL ecosystem. It covers both the description of the process followed to gather the requirements and the description of the requirements themselves.

The main objective of the WP4 is to define the CITADEL services required to fulfil the functional and non-functional requirements (which are defined in WP4 too) of the ecosystem, including the design of the overall architecture of the CITADEL ecosystem and the actual implementation of the CITADEL services.

This document is an updated version of WD4.1 [1] where the first version of the requirements for the CITADEL ecosystem were described, D4.2 [2] where the initial methodology for the requirements elicitation was described and the D4.3 [3] where the first version of the CITADEL ecosystem architecture was presented.

1.2 Document structure

The document is structured as follows. Section 2 presents the methodology followed in CITADEL for the elicitation, alignment and prioritization of the different requirements gathered for the design and implementation of the CITADEL ecosystem. In section 3, the current version of the CITADEL ecosystem requirements is presented, including the functional requirements, the use cases requirements, and the technology requirements.

Section 4 describes the alignment performed between the functional requirements of the components included in the CITADEL ecosystem and the KRs described in the DoA [4], and presents a matrix for the prioritization of the different requirements based on both the knowledge/planning of the technology providers in CITADEL and the requirements coming from the use cases. This section includes the alignment between the functional requirements and the use cases requirements too.

The document concludes with the description of the next activities to be performed in the context of WP4.




of 51

2 Requirements management in CITADEL

This section aims to present and update the requirements management methodology described in D4.2.

2.1 Methodology for requirements elicitation

CITADEL follows a top-down and bottom-up approach. That is, on one hand, generic functionalities of the CITADEL ecosystem are described to present the features that CITADEL aims to offer as its value proposition. On the other hand, the use cases expressed their requirements, namely, what they expect from CITADEL as end users of the CITADEL ecosystem. Eventually, these two strands have to merge.

2.1.1 Requirements gathering and prioritization

The next figure depicts the process followed for the gathering of the requirements in CITADEL. Note that this is an updated and improved approach to what was presented in D4.2 [2], and that the requirements gathering process is iterative. This implies that new requirements arise as the project evolves and more understanding is gathered by all stakeholders.

Legend for the next figure is as follows: Activities performed in this work package are marked in blue, while activities marked in green are performed in work package 5 (use case validation).

Figure 1. CITADEL process for requirements gathering and prioritization

The process followed in CITADEL for the elicitation of requirements is described as follows:

1. High-level requirements, that is, what CITADEL aims to offer, are elicited from what it is written in the Description of Action [4]. These requirements involve both functional and non-functional aspects that the CITADEL ecosystem should feature.

2. Definition of the generic CITADEL processes. “Generic processes” is understood as a complete workflow to achieve a goal. It includes also who is responsible of that workflow and if there is a precondition to be fulfilled before the process can be triggered.

3. The result of the activities described beforehand have been decomposed into technical (software) requirements, expressing both functionality needs and non-functionality aspects.




of 51

4. The technical partners aligned the generic requirements elicited in previous steps with the requirements gathered by the use cases [5], and reformulated them, when needed, to end up with a consensus version.

5. Based on the final set of requirements (agreed in the previous step), use cases prioritized them, taking into consideration their major interests. This prioritization is analysed in D5.1 [5] and was presented during the General Assembly in Brussels, February 2018 (for the prioritization and interests of the use cases please see annex 1).

6. In parallel, technical partners prioritized the requirements. This prioritization is needed because even if a requirement does not look like it adds anything to the system, it could actually be a baseline requirement that affect other requirements, and in the event, it was not implemented, the related functionality would not be delivered in a successful manner. Examples of these kind of requirements are, for instance, security requirements.

7. The outcome of both activities 5 and 6 results in a prioritization matrix, that indicates for each release which requirements will be implemented, and will therefore be able to be validated by the use cases.

8. Requirements are then implemented into functionalities. The implementation -in the context of this diagram- has been simplified and it involves the architectural design, the coding, testing (unit and integration) and deployment. During this phase, and especially during the testing activities, new requirements or improved requirements may arise. These new requirements are carefully analysed by the technical partners in order to avoid scope creep, before deciding if they can or cannot be accepted.

9. Use cases validate the functionalities following the evaluation plan defined in D5.2 [6] . The evaluation will result in new requirements, as well as in updated versions of the current requirements. Updated versions of requirements can include changes of the UI, while new requirements may involve new functionalities. As in step 8, these new requirements are carefully analysed by the technical partners in order to avoid scope creep, before deciding if they will or will not be accepted.

Documenting requirements is a key issue in every software project. In the case of CITADEL, the requirements are defined to provide an understanding of what will CITADEL do, i.e., the functionalities.

Requirements specifications in CITADEL include software requirements (referred as functional requirements in the project), technical requirements, and system requirements (referred as non-functional requirements in the project).

FURPS [7] is the methodology used for the elicitation of the requirements in CITADEL. FURPS stands for Functionality, Usability, Reliability, Performance and Supportability. The ‘F’ in FURPS is aimed to represent the functional requirements while the ‘URPS’ represent the set of non-functional requirements. An explanation of what FURPS means follows:

• Functional: describe the main features of the CITADEL ICT Enablers.

• Usability: concerns the user interface or UI.

• Reliability: concerns aspects such as availability or mean time to recover.

• Performance: concerns aspects such as recovery time, response time, …

• Supportability: characteristics such as extendibility, scalability, localization, and so on.

Reliability requirements in CITADEL are the least critical since it will depend solely on the Service Level Agreements defined internally in the Public Administrations where the CITADEL ecosystem will be installed. The rest of the requirement types are of importance for the development, deployment and maintenance of CITADEL, as well as for its sustainability.




of 51

For the prioritization of the requirements, from the point of view of the technological providers, the MoSCoW method [8] has been followed. The MoSCoW method allows to define clear priority levels while also determining which functionalities will be developed in each of the project iterations. The prioritization levels of MoSCOW can be defined as follows:

• M (Must): mandatory requirements. These requirements will be included definitely in the release.

• S (Should): requirements that should be included in the release or in the final version. The inclusion of these type of requirements must not affect the ‘must’ requirements and they will only be included in the case there is additional time of capacity.

• C (Could): requirements that could be included, because they provide nice-to-have functionalities. These shall only be implemented when the M and S have been successfully implemented.

• W (Won’t have): requirements that will not be included but they could be delivered some time as additional or extended functionalities.

Must and Should requirements are prioritized for the first versions of the components while Could requirements will be added in the final versions of the components.

This prioritization technique has allowed to prioritize the CITADEL requirements taking also into consideration the following constraints:

• Baseline functionalities (requirements prioritized as Must) will be implemented in the initial versions, while more complex functionalities depending on the basic ones will be implemented in subsequent releases.

• Functionalities which are core for the use cases have been prioritized for the initial releases (requirements prioritized as Must and Should), based on the use cases description D5.1 and brainstorming sessions with the use cases. This prioritization of the functionalities will be accordingly updated as the description and needs of the use cases evolve.

• Functionalities with strong dependencies with other tools (i.e. interfaces related functionalities) (requirements prioritized as Must and Should) will be implemented in early stages of the project, so that the integrated framework can be built up and the components can test the dependencies with other components.

2.1.2 Requirements documentation

In CITADEL, requirements are reported in a requirements document (this one) and are described as follows:

• Requirement id: unique identifier of the requirement

• Short title: short description of the requirement

• Description: more detailed description of the requirement. This is especially relevant for the creation of the test cases.

• Status: Proposed / Accepted / Rejected / Implemented / Work in Progress /Finished

• Priority: Must have / Should have / Could have / Won’t have

• Related KR: which CITADEL result is affected by this requirement

Furthermore, several traceability matrixes are maintained.

On one hand, in order to check if all CITADEL Key Results have associated requirements and not to forget any core functionality, the project maintains a traceability matrix between KRs and Requirements. An example of this traceability matrix is presented next. The final traceability matrix is reported in section 4.1.




of 51

Table 1. Traceability Matrix Key Result – Requirement (excerpt)

KR1 KR2 KR3 KR4 KR5 KR6 KR7 KR8

ID.01 ● ●

ID.02 ● ●

ID.03 ● ●

ID.04 ● ●

DM.01 ● ●

DM.02 ● ●

DM.03 ● ●

DM.04 ● ●

CC.01 ● ● ●

HC.01 ● ●

HC.02 ● ●

Another traceability matrix maintained relates the requirements elicited and the ones prioritized by the use cases. An example of this traceability matrix is presented next. The final traceability matrix is reported in section 4.2.

Table 2. Traceability Matrix Functional-Use Case requirements (excerpt)

Funct. Req.

Use case requirements

ID.UC. 01

DM.UC. 01

DM.UC. 02

DM.UC. 03

DM.UC. 04

CC.UC. 01

CC.UC. 02

HC.UC. 01

ID 01 X

ID 02 X

ID 03

ID 04

DM 01 X X

DM 02 X X

DM 03

DM 04 X X

DM 05

CC01 X X

KP01

KP02

The last matrix maintained is the one that relates the requirements with the delivery date, and which allows the developers focus on the core aspects for each of the iterations. A previous version of a prioritization matrix was presented in D4.2 [2] but this has been updated to cover the actual and current needs of the use cases.

The initial prioritization of the CITADEL functional requirements is shown in the next table. The colours code is as follows:




of 51

Figure 2. Colour code for requirements prioritization

Next, an excerpt image is presented. The final prioritization of the requirements is presented in section 4.3.

Table 3. Requirements prioritization matrix (excerpt)

Component and functional requirements

Intelligent Discovery (ID) M15 M30 M33

ID.01 x

ID.02 x

ID.03 x

ID.04 x

Digital Maturity Assessment (DigiMat) M15 M30 M33

DM.01 x

DM.02 x

DM.03 x

DM.04 x

Functional requirement implementation plan




of 51

3 CITADEL ecosystem requirements

This section presents the updated version of the requirements for the CITADEL ecosystem and its components. The requirements have been classified based on their nature:

• Functional requirements: Requirements expressed as needs for the functionalities that each of the components need to support.

• Use cases requirements: Requirements expressed by the use cases for the CITADEL ecosystem and the ICT enablers based on their needs.

• Technology requirements: Requirements imposed by the technologies to be used, including integration and legal requirements.

3.1 Functional requirements

As explained in section 2, the process for the requirements elicitation started with the definition of the main processes that the CITADEL ecosystem needs to fulfil, based on the CITADEL DoA [4].

After discussion between technology providers and use cases partners, the set of processes that a user should be able to perform using the CITADEL ecosystem was agreed, and these processes are:

Table 4. CITADEL processes

Process title Process objective Related CITADEL actors1

Discover public services

To discover the most suitable service for concrete citizens

Citizens (users).

Collect information from Non-Users

The objective if this process is to collect the relevant information obtained from the citizens who are not using digital public services. This information will be gathered from the Open Data portals

Triggered by other processes (or by the CITADEL operator, i.e. a PA servant)

Analysis of information

The objective of this process is to analyse the available relevant information to provide it to the appropriate other processes

Triggered by other processes

Generate recommendations

The objective of this process is to elaborate a set of contextualized recommendations and guidelines for transforming Public policies and processes.

PAs

Generate KPI reports

The objective of this process is to provide to the PAs with KPI reports to help them to improve their policies and processes.

PAs

Provide feedback from users (citizens and governments)

To allow users to provide feedback from a certain digital service

Citizens

1 See D4.3 for CITADEL actors’ description.




of 51

Process title Process objective Related CITADEL actors1

Co-Create To define / change digital public service in a collaborative manner between PAs and Citizens

Citizens (users and non-users)

PAs

Based on this set of services, different versions of the architecture for the CITADEL ecosystem have been proposed (WD4.1 [4], D4.3 [3]).

Here the updated version of the CITADEL ecosystem architecture is presented:

Figure 3. CITADEL ecosystem generic architecture

All these components implement the different processes described beforehand (see D4.3 [3]). The access to these components can be performed through different means:

• Through the CITADEL ecosystem user interface.

• Through the PAs portals.

The CITADEL ecosystem as such is another component, that includes the access to the different CITADEL components through a single access point. In the following picture the deployment architecture of the CITADEL ecosystem and the CITADEL components is shown:




of 51

Figure 4. CITADEL Ecosystem deployment architecture

The approach to be followed is a decentralized approach where each component is deployed separately and accessed through the CITADEL ecosystem or the PA systems (see D4.3 for further explanations). The co-creation supporting tool enables the access to specific tools that can be used to implement some of the activities of the co-creation methodology.

Based on the explained architecture, the functional requirements for each of the components have been elicited in several iterations (WD4.1 [1]). Following, the current version of the requirements for the different components are described. Requirements incorporated from the last version are described as New.

3.1.1 Intelligent discovery of public services

The Intelligent Discovery of Public Services (ID) component will manage the digital public service discovery in the PAs. The discovery of the digital public services will be done in an “intelligent” way so that the discovered services will be the most suitable ones for a concrete user, based on her/his profile.

This component will allow the user (citizen) to customize his/her list of “potentially useful” digital services. This list can be compiled based on the profile of the user or based on a set of requirements provided by the user.

The corresponding functional requirements for ID component are:

Requirement id ID.01

Req. short title ID component will discover the most suitable set of services for a certain user once the user is logged in the system.

Req. description The ID component will access the catalogue of available on-line services for user and, based on the profile (captured from profiles DB), it will provide a sort list of recommended services. This will be “automatically” performed every time the user logs in.

Digimat Co-creationKPI reportgeneration

IntelligentDiscovery

Userassessment

CITADEL Ecosystem

CAS

PAs systems• Co-creation methodology• Legal Vademecum• Vignettes guidelines• …

Sec. tools




of 51

State Implemented

Priority Must have

Relate KR KR5, KR8


Req. short title ID component will discover the most suitable services for a set of requirements provided by a citizen.

Req. description The ID component will capture the requirements from the citizen and access the catalogue of available on-line services. It will provide a sorted list of recommended services which fulfil those requirements. This will be performed on demand.

State Implemented

Priority Must have

Relate KR KR5, KR8


Req. short title ID component will maintain a list of available services and their relevant information for performing the intelligent discovery.

Req. description The ID component will have a registry of the services along with their relevant information. This service related information has to be up to date and aligned with the PAs digital public services registry. The ontology to be used to describe the services will be aligned with relevant standard vocabularies for Public Services.

State Implemented

Priority Must have

Relate KR KR5, KR8





of 51

Req. short title ID component will maintain a profile DB with the information about each user.

Req. description The ID component will maintain a profile DB with the information about each user and hid relevant information to be able to perform the intelligent discovery.

State Implemented

Priority Must have

Relate KR KR5, KR8

3.1.2 Digital Maturity Assessment

The Digital Maturity Assessment (DM) component will perform an assessment on the maturity of a Public Administration with respect to the provision of Digital Services. DM will first capture information mainly through on-line questionnaires (but not discarding other sources if necessary); then, it will analyse this information; and finally, it will provide the result of the assessment in the form of a report including numerical and graphical data.

The corresponding functional requirements for DM component are:

Requirement id DM.01

Req. short title DM component shall compile information about the current situation of the PA with respect to digital maturity.

Req. description DM component will use online questionnaires to gather the required information for the situation of the different relevant areas of the PA for performing the assessment. DM will use structured questionnaires to get key information to evaluate the status of the PA. The questions posed to the PA will be organized in thematic areas covering important aspects of the digital maturity.

State Proposed

Priority Must have

Relate KR KR1, KR8


Req. short title DM component will analyze different characteristics of the PA in order to assess its digital maturity.




of 51

Req. description DM component will analyze the PA against the maturity digital model to identify its digital maturity.

State Implemented

Priority Must have

Relate KR KR1, KR8


Req. short title DM component will provide the result of the assessment in the different relevant perspectives.

Req. description DM component will provide the result of the assessment, showing the punctuation reached for each of the perspectives in a numeric and a graphical way.

State Proposed

Priority Must have

Relate KR KR1, KR8


Req. short title DM component will provide a report with the result of the assessment.

Req. description DM component will provide the result of the assessment, showing the punctuation reached for each of the perspectives in a numeric and a graphical way in a report that can be downloaded.

State Proposed

Priority Must have

Relate KR KR1, KR8

Requirement id DM.05 (New)




of 51

Req. short title DM component will customize the digital maturity assessment based on the profile of the user and the PA profile.

Req. description DM component will provide customized questionnaires based on:

1. The PA profile (national, regional, local) 2. The user profile: Based on the role of the user who

access the Digimat the questionnaire will be customized.

State Proposed

Priority Must have

Relate KR KR1, KR8

Requirement id DM.06 (New)

Req. short title DM component will provide recommendations on how to improve the current maturity in the different areas evaluated

Req. description DM component will provide a set of recommendations, taking into consideration the responses provided by the PA and the maturity level that the PA is characterized for that area and dimension.

State Proposed

Priority Must have

Relate KR KR1, KR8

3.1.3 Co-creation methodology supporting tools

The co-creation methodology to be defined in CITADEL will be supported by an on-line tool, which will support the customization, visualization and automatic workflow execution of this methodology.

The corresponding functional requirement for this component is:

Requirement id CC.01

Req. short title CC component will customize the generic CITADEL co-creation methodology into a specific one for a concrete PA service and a concrete co-creation process.




of 51

Req. description

CC component will gather relevant information about the PA and/or the co-creation context in order to be able to personalize the generic CITADEL co-creation methodology prosing only the tasks/activities relevant for the concrete co-creation process.

State Proposed

Priority Must have

Relate KR KR3, KR4, KR8

Requirement id CC.02

Req. short title CC component will support the ideation and research phase of co-creation.

Req. description CC component will support the activities involved in the ideation and research process of a public service.

State Proposed

Priority Must have


3.1.4 KPI Report generation - Visualization and report generation

The KP (KPI visualization and Report generation) component will generate a report with the selected KPIs for the PAs. These are the possible KPIs envisioned by now (this list will be possibly modified based on the input received from WP2):

• KPIs to co-create: Number and trends

• General KPIs for improving the usage of the current digital services: o Number of users/non- users per service/per year o Data/information of citizens who don’t use the digital services (or one concrete

digital service): i.e. gender, age, demographics, education skills, etc. o Feedback (rating) per service/ per type of service/ per year

• KPIs of a certain service o Number of users/non- users per service/per year o Data/information of citizens who don’t use the digital services (or one concrete

digital service): i.e. gender, age, demographics, education skills, etc. o Feedback (rating) per service/ per type of service/ per year

The corresponding functional requirements for the KP component are:




of 51

Requirement id KP.01

Req. short title KR component will provide a UI for gathering the purpose of the KPI report requested

Req. description The KP component will collect the objective of a certain KPI generation proposition from the user. Initially the following potential KPIs generation objectives are envisioned:

• KPIs to co-create: Number and trends

• General KPIs for improving the usage of the current digital services

• KPIs of a certain service

State Proposed

Priority Must have

Relate KR KR1, KR8


Req. short title KR component will analyse relevant information for generating specific KPIs.

Req. description The KR component will analyse the information from the treated data (harvesting, curation and fusion)

State Proposed

Priority Must have

Relate KR KR1, KR8


Req. short title KR component will produce a report with the KPIs selected by the end user.

Req. description KR component will produce as a result a (graphical) report with the requested KPIs.

State Proposed

Priority Must have




of 51

Relate KR KR1, KR8


Req. short title KR component will provide means to visualize the generated KPIs and their trends

Req. description KR component will visualize the generated KPIs through a graphical user interface.

State Proposed

Priority Must have

Relate KR KR1, KR8

3.1.5 KPI Report generation – Harvesting and curation

The Harvesting and curation component (HC) will collect, store, fuse and provide data required for the KPI visualization and Report generation (KP) component.

The main functionalities of this component are:

● Harvesting/loading structured file based resources in different formats (like CSV, XLS, JSON, XML, SQL, RDF…) but also databases through SQL or indexes like Elasticsearch and publishing data in different formats (like CSV, JSON, XML, RDF…).

● Filtering resources based on their metadata, for example based on keyword or resource type.

● Linking and fusing data sources by adding semantic context. ● User management: set the visibility of resources for certain resources according to

user/groups. The corresponding functional requirements for ID component are:

Requirement id HC.01

Req. short title HC will access and publish or store the different data sources required for performing the information analysis.

Req. description HC will have access to the different data sources (i.e. open data portals, data coming from the on-line questionnaires, anonymized data, etc.) and store them for further analysis.

State Proposed

Priority Must have





of 51

Requirement id HC.02

Req. short title HC will provide the relevant results to the KP Component.

Req. description DA will analyse the different data sources and provide relevant data to the KP component that has requested the data.

State Proposed

Priority Must have


3.1.6 User assessment

The User Assessment (UA) component will support the functionality of assessing a public digital service by a user of that concrete service. Once a user has used a public digital service through the PA platform, this component will provide the means to assess the service (through a ranking) and a free text comment.

The UA component will also serve the PAs to analyse the assessment of the different services by the users. For that purpose, UA will provide a specific UI for the PAs where to check the punctuation received by each service and the analysis of other sources where the users have expressed their experience with digital public services (i.e. social network).

The corresponding functional requirements for UA component are:

Requirement id UA.01

Req. short title UA component will provide means for users to evaluate a certain public digital service after using it.

Req. description The UA component will provide a ranking mechanism for the user and a free text collector, so that the user can assess his/her experience with the digital service. Upon requests towards the SM component, sensitive information included in the questionnaire will be anonymized / encrypted.

State Implemented

Priority Must have

Relate KR KR6, KR8





of 51

Req. short title UA component will store the assessments/evaluations provided by the users about the different digital public services.

Req. description The UA component will store the different evaluations provided by the users, w.r.t. the digital public services and the info collected from the social networks, so it can be later on accessed by the PAs.

State Implemented

Priority Must have

Relate KR KR6, KR8


Req. short title UA component will provide means to visualize the assessments performed by the users, w.r.t to specific public services.

Req. description The UA component will visualize the assessments of the services and other relevant information reported in social networks.

State Implemented

Priority Must have

Relate KR KR6, KR8


Req. short title UA component will analyse information provided by the users about their experience when using digital public services.

Req. description The UA component will analyse data coming from the comments provided by the users (positive/negative comments) w.r.t to the usage of the digital public services to be shown to the PAs.

State Proposed

Priority Must have

Relate KR KR6, KR8




of 51

3.1.7 Security management – Access management +encryption

The Access Management + Encryption component comprises:

• A set of server components, providing web services that support the security features in terms of exchange of / access to data

• A set of libraries that a generic client (the libraries are available both in Java and JavaScript technology in order to be usable both in web and desktop environments) can use to benefit from the security features provided and interact with the server components.

This component has been designed to implement the following non-functional requirements:

Requirement id SC.01

Req. short title Security / privacy by design support

Req. description The system shall be designed taking into account the security and confidential data management needs; security and privacy protection (i.e., proper management of confidential data) shall be essential elements of the system.

State Proposed

Priority Must have

Relate KR KR7


Req. short title Security / privacy by default support

Req. description The design and default configuration of the system shall ensure a minimum level (which means an acceptable level which can be increased only) of security and privacy (i.e., confidential data management) that:

(1) cannot be lowered (2) is configured by default

State Proposed

Priority Must have

Relate KR KR7




of 51


Req. short title CP-ABE encryption support

Req. description Data encryption / decryption performed in the context of CITADEL information exchange will follow the Ciphertext-Policy Attribute-Based Encryption scheme.

State Proposed

Priority Should have

Relate KR KR7


Req. short title Proof of ownership support

Req. description The user’s authentication shall be performed using a proof of ownership instead of traditional authentication mechanisms (e.g., challenge/response), in order to avoid storing on the service side sensitive data like passwords. At login time, in fact, a certificate holding the user’s private and public keys is passed to the browser and the user is requested to provide her/his password that shall be used, locally within the browser, to decrypt the user’s private key, thing that provides proof of ownership of the certificate stored in the user’s profile.

State Proposed


Relate KR KR7


Req. short title ECDSA support

Req. description When a user registers, the system shall generate a 256-bit ECDSA (Elliptic Curve Digital Signature Algorithm) keys pair according to the US NIST FIPS-186 specification [9]. The private key shall be securely encrypted using the user’s password specified during the registration process and the encrypted private and public keys shall be structured into a kind of certificate and stored in the user’s profile.




of 51

State Proposed


Relate KR KR7


Req. short title LDAP support

Req. description Users’ profiles shall be managed using a LDAP Directory Service, where users’ attributes shall be structured in accordance with X.500 schema.

State Proposed


Relate KR KR7


Req. short title Authorization based on policies and roles

Req. description The user’s role, stored as an attribute within the user profile, shall be the base element to establish what the user is allowed to do. Furthermore, the authorizations on specific actions related to specific items, are defined on the basis of access policies defined as logical combination of user’s attributes and associated to the item.

State Proposed

Priority Must have

Relate KR KR7

3.1.8 Security management- Anonymization

The Anonymization (AN) component will provide the capability of anonymizing the data, when needed, by a PA or by another component in the CITADEL ecosystem.

Requirement id AN.01




of 51

Req. short title AN component will anonymize data under request.

Req. description AN component will anonymize (removing personally identifiable information (PII) from user data or masquerading identifying information (pseudonymization)) when it receives a request for anonymization from any other component in the CITADEL platform or directly from the PA. The AN component will receive the anonymization request and the data to be anonymized. The Anonymization component will provide the anonymized set of data.

State Proposed

Priority Must have

Relate KR KR7, KR8

Requirement id AN.02

Req. short title AN component will store the anonymized data.

Req. description AN component will store the anonymized/ pseudoanonymized for further analysis.

State Proposed

Priority Must have

Relate KR KR7, KR8

3.1.9 CITADEL ecosystem

CITADEL ecosystem (CE) will provide a way of accessing the different CITADEL components, providing access control and single sign-on functionalities.

Requirement id CE.01 (New)

Req. short title CE will provide a UI with the access to the different CITADEL ICT enablers: Intelligent discovery of public services, Digital Maturity Assessment, Co-creation methodology supporting tool, KPI report generation, User Assessment and Security Management.

Req. description CE will provide a UI where all the ICT enablers access are included.




of 51

State Implemented

Priority Must have

Relate KR KR8


Req. short title CE will provide access control functionalities.

Req. description CE will provide a mechanism to define roles and permissions to access the required components in the CITADEL ecosystem depending on the user profile/characteristics,

State Implemented

Priority Must have

Relate KR KR8


Req. short title CE will support SSO.

Req. description CE will support the integration with SSO technology so that the user doesn’t need to log in each component of the ecosystem. For this the components need to support SSO too.

State Implemented


Relate KR KR8

3.2 Use cases requirements

The following section details the requirements of the use case providers based on the analysis they did of the CITADEL processes and the first version of the functional requirements [5].

These requirements add some specific functionalities to the requirements defined in the previous section for each component. An overview of the relationship of the functional requirements and Use case requirements is shown in section 4.2.




of 51

3.2.1 Intelligent discovery of public services

Requirement id ID.UC. 01

Req. short title The intelligent service discovery component should be linked with the catalogue of services of each PA.

Req. description This component should be linked with the catalogue of services available or the platform that collects all the service information. These catalogues or platforms could include both services that are available also digitally, and those who are available only in person. The discovery criteria should be very precise so that the outcome (list of suitable services) corresponds to the user profile and requirements.

Source VARAM; ANTWERPEN

State Proposed

Priority Must

3.2.2 Digital Maturity Assessment

Requirement id DM.UC. 01

Req. short title Questions of the DMA must be clear and concise.

Req. description The assessment for digital maturity should not include questions that are vague and open to interpretation, or questions that are very hard to answer properly. It should be taken into account that PA’s often are organised in a complex way and not all e-services are managed the same way.

Source ANTWERPEN; Regione Puglia; VARAM

State Proposed

Priority Must

Requirement id DM.UC.02

Req. short title Results must include comprehensive explanation of the evaluation.

Req. description End-users from different PAs with different levels of Digital Maturity might use this service, so comprehensive explanation of the result of its evaluations should be provided with emphasis on problematic areas. Also, the explanation of




of 51

methodology and questions used in evaluation should be available to user.

Source VARAM

State Proposed

Priority Must


Req. short title Recommendations for legislation awareness could include comprehensive view on EU legislation.

Req. description Recommendation in the Legal dimension should contain clear steps to understand the EU Legislation and the matches with the national ones

Source VARAM

State Proposed

Priority Could


Req. short title The recommendations regarding legal aspects could consider the Italian and Latvian laws

Req. description Recommendations in the Legal dimension could consider laws from the countries of the use cases

Source VARAM; Regione Puglia

State Proposed

Priority Could

3.2.3 Co-creation methodology supporting tool

Requirement id CC.UC. 01

Req. short title This component should include the results of the academic and theoretical findings.




of 51

Req. description It would be useful if academic and theoretical findings from this methodology would be supported by practical tools, methods and advices offered to end-users.

Source VARAM

State Proposed

Priority Would

Requirement id CC.UC. 02

Req. short title This component should provide the appropriate steps and methods to co-create based on the context of the service and the PA

Req. description To have a complete list of phases, methods and tools to be used when a PA faces a co-creation process is very useful.

Source VARAM; Regione Puglia

State Proposed

Priority Would

3.2.4 KPI report generation

3.2.4.1 Harvesting + curation+ Fusion

Requirement id HC.UC. 01

Req. short title Source data could be compatible with the data sets available in the PA

Req. description In the case of the City of Antwerp the data is obtained from different databases and is linked to the digital service use of the e-Desk application. In the case of Regione di Puglia the data will be provided by DBAs or downloaded from the OpenData Puglia website and, in the case of VARAM, latvija.lv includes various sets of data sources.

Source City of Antwerp, Regione Puglia; VARAM

State Proposed

Priority Must




of 51

3.2.4.2 KPI visualization and report generation

Requirement id KP.UC. 01

Req. short title Smart KPI report for the services

Req. description PA receives comprehensive and usable list of KPIs. This information must be shown in a graphical way to facilitate the understandability of the information.

Source Regione Puglia; VARAM

State Proposed

Priority Must

The list of general KPIs is currently being refined to include the relevant subsets of KPIs, priorities of use case, as well as corresponding data sources. The component is being adapted and extended in accordance with the use case specific needs as well as with the mechanisms for obtaining the data (such as the use of open data that will allow PAs to publish the data for reuse by the KPI component, use of data stored locally in various databases, etc.), in the context of D5.2. Currently a set of open source tools and their compatibilities with the final integrated environment is being explored. Among the possibilities, third party tools such as OpenRefine, front-/backend libraries such as Google charts, JFreeChart, Chart4j, Chart.js, etc. are under consideration. The report visualizations may include graphical representations of KPIs, dashboards, and/or benchmarking views.

3.2.5 User assessment

Requirement id UA.UC. 01

Req. short title The evaluation must give the user the opportunity to add a comment

Req. description If the user rates certain service, there also should be an option for him/her to explain this evaluation.

Source VARAM

State Proposed

Priority Must




of 51

3.2.6 Security management

Requirement id SM.UC. 01

Req. short title Data should be maintained in the Use cases premises

Req. description Data from the different use cases should be always in the Use case provider´s network. Fake data could be provided with testing purposes

Source Antwerpen; VARAM

State Proposed

Priority Must

Requirement id SM.UC. 02

Req. short title Encryption mechanism could be required

Req. description Encryption and decryption mechanism could be useful for the use case to secure the data flows on the local network.

Source Antwerpen

State Proposed

Priority Could

Requirement id SM.UC.03

Req. short title Data must be sent by a safe channel to not allow “data sniffing” of personal data

Req. description The transfer of personal data must be performed by a component that ensures the anonymization of data in order to avoid privacy violations

Source Regione Puglia

State Proposed

Priority Must




of 51

Requirement id SM.UC.03

Req. short title Data must be sent and stored by a safe channel to not allow “data sniffing” of personal data

Req. description The transfer and store of personal data must be performed by a component that ensures the anonymization of data in order to avoid privacy violations

Source Regione Puglia

State Proposed

Priority Must

3.2.7 CITADEL ecosystem

Requirement id OA.UC.01

Req. short title CITADEL ICT components can be plugged in PA platform

Req. description In CITADEL Ecosystem there should be IT-tools provided that facilitate the implementation of the use case on PA´s platform with a minimal effort. The ecosystem provides an easily accessible toolbox that encourages PA’s to further develop their e-services in a user-centric way.

Source Antwerpen

State Proposed

Priority Could

3.3 Technological requirements

3.3.1 Technology implications

The different CITADEL components will be developed based on existing tools (when possible). The analysis of the potential baseline technologies has been performed in WD4.1 [1]. Based on this analysis, the design implications of each of the components have been described in D4.3.

In the following table, an updated overview of the base line technologies for each of the components is presented. Further details for each component are included in D4.3 [3].




of 51

Table 5. Overview of the baseline technologies for the CITADEL components.

CITADEL Component Baseline Technologies

Intelligent discovery of public services JHipster Framework & REST APIs

Digital Maturity Assessment HTML5, BIRT

Co-Creation methodology supporting tool

Camunda BPMN engine / Innovation Platform tool.

KPI report generation - Visualization BIRT for report generation

KPI report generation – Harvesting and Curation

The Data Tank, Virtuoso

User Assessment JHipster Framework & REST APIs

Security Management – Encryption + Access management

Java & Javascript with additional libraries (Web Crypto API, CryptoJS, RESTlet

Security Management – Anonymization ARX tool

CITADEL ecosystem Liferay, Open LDAP, Appereo CAS

3.3.2 Integration requirements

This section describes the possible integration levels of the different CITADEL components, including the CITADEL ecosystem.

As explained in section 3 (table 4), the CITADEL components can be classified depending on the target users of the components. Following this approach, we can find components to be used by both the citizens and the PAs (civil servants) and components to be used only by the PAs.

• Components to be used by the citizens: o Intelligent Discovery of Public Services: The citizen accesses this component

through the PA’s web portal, to get a personalized list of available digital services.

o User Assessment: The citizen accesses this component through the PA’s web portal, to provide feedback about a service that he or she has used.

• Components to be used by the PAs (civil servants): o Intelligent Discovery of Public Services: The PAs can access the component to

endorse/delete/update services into the component. o Digital Maturity Assessment: The PAs access the Digital Maturity Assessment to

get the maturity of the PAs. The Digital Maturity Assessment can be accessed through the CITADEL ecosystem or directly through the PA’s intranet.

o Co-creation methodology supporting tool: The PAs access the Co-creation methodology supporting tool to get a customized co-creation methodology. The Co-creation methodology supporting tool can be accessed through the CITADEL ecosystem or directly through the PA’s intranet.

o KPI report generation: The PAs access the KPI report generation component to get relevant KPIs. The KPI report generation can be accessed through the CITADEL ecosystem or directly through the PA’s intranet.

o User Assessment: The PAs access the User Assessment component to analyze the feedback of the citizens with respect to the digital services.




of 51

o Security Management – Anonymization/Access management: as part from some administration utilities, that will be accessed by the PAs to perform specific operations (e.g. policy definition) and configurations, the access to this component is transparent, because it happens when users access client components that rely on the SM-AM component for the management and protection of the data they handle; end users have no clear perception that SM-AM component is working behind the scene.

o CITADEL ecosystem: CITADEL ecosystem can be accessed by the PAs to access the different CITADEL components. The CITADEL ecosystem UI can be substituted by each PAs intranet. As the CITADEL ecosystem provides different functionalities [6], it also supports different levels of integration. On the one hand, the authentication system can be fully or partially integrated with the authentication system of the PA. On the other hand, the usage or not of the CITADEL Ecosystem UI involves different types of integration (see next table).

In the following table, the different integration requirements for the components and the ecosystem are presented.

Table 6. Integration requirements in the CITADEL ecosystem

CITADEL Component Integration requirements

Intelligent discovery of public services

Integration in the PAs portal through REST API, with the backend component.

Endorse/delete services in the data base through the REST API or the existing component UI.

Digital Maturity Assessment

Access the Digital Maturity Assessment through the PAs intranet or through the CITADEL ecosystem.

Co-Creation methodology supporting tool

Access the digital the Co-Creation methodology supporting tool, as well as the tools linked to it -like the ISP- to support specific steps in the co-creation trajectory, through the PAs intranet or through the CITADEL ecosystem.

KPI report generation – Visualization + Harvesting + curation

Include PAs specific data sources.

Access the KPI Report generation through the PAs intranet or through the CITADEL ecosystem.

User Assessment Integration in the PAs portal through REST API, with the component backend.

Access the analysis of the user assessment through the PAs intranet or through the CITADEL ecosystem.

Security Management – Encryption + Access management

Integration of the provided client libraries in the client components that need to use the security and data protection services offered




of 51

CITADEL Component Integration requirements

Security Management – Anonymization

Integration in other components through a REST API.

CITADEL ecosystem Integration of the authorization and authentication system:

• Level 1: Export Use Case’s organizational Structure (LDAP) and import it in CITADEL Open LDAP Server

• Level 2: Substitute the CITADEL LDAP and SSO Mechanism with the use case’s ones

Integration of the CITADEL ecosystem UI:

• Level 1: The CITADEL ecosystem (backend with the components) is accessed through the CITADEL ecosystem UI.

• Level 2: The access to the CITADEL ecosystem (backend with the components) is included in the PAs intranet. The CITADEL components are accessed directly through the PAs portal/intranet/system.

In the following picture, an example of different deployments with different integration levels is shown:

Figure 5. Different integration levels in CITADEL use cases




of 51

3.3.3 Legal requirements

Due to the nature of the information and data involved in the usage of different components, the components and the CITADEL ecosystem will be deployed in each of the PAs. A CITADEL ecosystem (including their corresponding CITADEL components) will be instantiated for each PA. This approach is further explained in D1.4, the CITADEL Data Management Plan.




of 51

4 Requirements alignment and prioritization

This section presents the alignment between the different types of requirements elicited in previous sections. This alignment is being updated continuously.

4.1 Functional requirements and KRs alignment matrix

In the next table, the updated version of the Functional requirements and KRs alignment matrix is presented. This table shows which of the elicited requirements will contribute to the creation of each of the KRs. It is an updated version of the one presented in D4.2 [2]. Here the list of the KRs:

• KR1: CITADEL Recommendations and guidelines to transform the PAs

• KR2: CITADEL Information monitoring service

• KR3: CITADEL tool-supported methodology for the co-creation of services

• KR4: CITADEL Co-creation collaborative tool

• KR5: CITADEL Discovery service

• KR6: CITADEL Assessment service

• KR7: CITADEL Security toolkit

• KR8: CITADEL Ecosystem

Table 7. Functional requirements and KRs alignment matrix


ID.01 ● ●

ID.02 ● ●

ID.03 ● ●

ID.04 ● ●

DM.01 ● ●

DM.02 ● ●

DM.03 ● ●

DM.04 ● ●

DM.05 ● ●

DM.06 ● ●

CC.01 ● ● ●

CC.02 ● ● ●

HC.01 ● ●

HC.02 ● ●

KP.01 ● ● ●

KP.02 ● ● ●

KP.03 ● ● ●

KP.04 ● ● ●

UA.01 ● ●

UA.02 ● ●

UA.03 ● ●

UA.04 ● ●

SC.01 ● ●

SC0.2 ● ●

SC0.3 ● ●




of 51


SC0.4 ● ●

SC0.5 ● ●

SC0.6 ● ●

SC0.7 ● ●

AN.01 ● ●

AN.02 ● ●

CE.01 ●

CE.02 ●

CE.03 ●

4.2 Functional and use cases alignment matrix

In section 3, both functional requirements and use case requirements have been presented. In this section, the alignment between both of them are introduced.

This table shows how all the requirements identified by the use cases are considered by the functional requirements. Some of the functional requirements are not related to any of the needs of the use cases (use case requirements). These functional requirements, identified by the technical providers provide added functionality to the use case requirements or describe technical requirements which are not considered by the use cases.




of 51

Table 8. Functional and Use Case requirements alignment

Funct. Req.

Use case requirements

ID.UC. 01

DM.UC. 01

DM.UC. 02

DM.UC. 03

DM.UC. 04

CC.UC. 01

CC.UC. 02

HC.UC. 01

KP.UC. 01

UA.UC. 01

SM.UC. 01

SM.UC. 02

SM.UC. 03

SM.UC. 03

EC.UC. 01

ID 01 X

ID 02 X

ID 03

ID 04

DM 01 X

DM 02 X X

DM 03 X

DM 04 X X X

DM 05 X

DM 06 X X

CC01 X X

CC02 X X

KP01

KP02

KP03

KP04 X

HC01 X

HC02

UA01 X

UA02

UA03

UA04




of 51

SC01 X

SC02 X

SC03 X

SC04

SC05

SC06

SC07

AN01 X X

AN02 X X

CE01 X

CE02

CE03




of 51

4.3 Requirements prioritization matrix

As explained in D4.2 [2], a first prioritization of the functional requirements was made considering several aspects (baseline functionalities first, use cases requirements alignment, functionalities enabling integration, etc.).

The initial prioritization of the CITADEL functional requirements [3] has been updated in the current document, and is presented in the following table. The table presents when (in which release of the component) each requirement will be implemented.

• M15: Month 15 release.






of 51

Table 9. CITADEL ecosystem functional requirements prioritization.

Figure 6. Colour code for requirements prioritization

Component and functional requirements

Intelligent Discovery (ID) M15 M30 M33

ID.01 x

ID.02 x

ID.03 x

ID.04 x

Digital Maturity Assessment (DigiMat) M15 M30 M33

DM.01 x

DM.02 x

DM.03 x

DM.04 x

DM.05 x x (Completed)

DM.06 x x (Completed)

Co-creation Methodology supporting tool (CC) M15 M30 M33

CC.01 x x (Completed)

KPI report generation

Harvesting, curation and fusion (HC) M15 M30 M33

HC.01 x

HC.02 x

KPI visualization and report generation (KP) M15 M30 M33

KP.01 x

KP.02 x

KP.03 x x (Completed)

KP.04 x x (Completed)

User Assessment (UA) M15 M30 M33

UA.01 x

UA.02 x

UA.03 x x (Completed)

UA.04 x x (Completed)

Security Management

Access management + encryption M15 M30 M33

SC.01 x

SC.02 x

SC.03 x

SC.04 x

SC.05 x

SC.06 x

SC.07 x

Anonymization (AN) M15 M30 M33

AN.01 x

AN.02 x

CITADEL ecosystem (CE) M15 M30 M33

CE.01 x

CE.02 x

CE.03 x

Functional requirement implementation plan




of 51

5 Conclusions

This document has presented the requirements elicited for the ICT Enablers, as well as the methodology used for its collection and prioritization.

In CITADEL, the requirements elicitation is an iterative process. Moreover, it is the result of a top-down and a bottom-up process, where technology providers’ requirements and use case providers’ requirements come together into a common set of requirements, which are shown in this document.

For this project, requirements have been differentiated into functional requirements, use cases requirements, and technological requirements. For the functional requirements, the FURPS approach has been followed. For the use cases requirements, an iterative approach (see section 2.1 of the current document) extracting those reflected in D5.2 [6] to align them to the goals of the project was followed. In the case of technological requirements, a distinction between technology implications, integration requirement and legal requirements has been made. For the technology implications the tools and technologies that will be used to develop the different components have been analysed. The integration requirements between the components of the ecosystem with respect to the existing IT systems of the public administrations are described and finally the current legal jurisdiction of data ownership has been considered for the legal requirements.

The document finishes with a set of traceability matrices showing: 1) the alignment of the elicited requirements with respect to the CITADEL Key Results; 2) the alignment of which requirement will implement which use case requirement, and finally; 3) the prioritization matrix of requirements, which reflects which requirement will be implemented in which iteration of the CITADEL workplan.

Future versions of this document will include a review of these requirements as well as potential new requirements that could arise through the functional validation and the use case validation activities.




of 51

6 References

[1] CITADEL, “WD 4.1 Initial set of functional and technical requirements elicitation,” 2017.

[2] CITADEL, “D4.2 CITADEL DevOps Infrastructure,” 2017.

[3] CITADEL, “D4.3 Initial CITADEL ecosystem architecture,” 2017.

[4] CITADEL, «CITADEL DoA,» 2016.

[5] CITADEL, “D5.1 Definition of the use case scenarios,” 2017.

[6] CITADEL, “D5.2 Initial technical implementation of the use cases development,” 2017.

[7] P. Eeles, “Capturing Architectural Requirements,” IBM DeveloperWorks, 2005. [Online]. Available: https://www.ibm.com/developerworks/rational/library/4706.html#N100A7. [Accessed March 2018].

[8] S. Madsen, “How to Prioritize with the MoSCoW Technique,” October 2017. [Online]. Available: https://www.projectmanager.com/training/prioritize-moscow-technique . [Accessed March 2018].

[9] “Federal Information Processing Standard 186-4, Digital Signature Standard (DSS),2013,” 2013.




of 51

7 Annex 1 – Prioritization of functionalities by the use cases

Figure 7. Analysis of use case needs for CITADEL components (source D5.1 sect. 5.5 [5])2

Figure 8. Use case specific needs - priorities (source D5.1 [5])

2 The requirements referenced in these tables were defined in WD4.1 and they do not correspond to the last updated version included in this document.

00.5

11.5

22.5

33.5

44.5

5Security management

Recommend. reportgeneration

Digital maturityassessment

Digital public servicesmanagement

Legislation management

Data analysisKPI report generation

Managament console

Co-creation

Databases

UI

Use case specific needs

Antwerp Puglia VARAM




of 51

Figure 9. Antwerp Use case specific needs - priorities (source D5.1)

Figure 10. Regione di Puglia Use case specific needs - priorities (source D5.1 [5])

Figure 11. VARAM Use case specific needs - priorities (source D5.1 [5])

0 1 2 3 4 5 6

Security management

Recommend. report generation

Digital maturity assessment

Digital public services management


Data analysis


Managament console

Co-creation

Databases

UIAntwerpAntwerp

0 1 2 3 4 5 6

Security management





Data analysis


Managament console

Co-creation

Databases

UIPugliaPuglia

0 1 2 3 4 5 6

Security management





Data analysis


Managament console

Co-creation

Databases

UIVARAMVARAM

D4.1 Functional and technical requirements elicitation...Functional and technical requirements...

Documents

Transcript of D4.1 Functional and technical requirements elicitation...Functional and technical requirements...