The increased complexity and frequency of regulations provided by the European Union creates a highly dynamic landscape for the organizations based within it. Implementing these regulations is a challenging task, especially in regard to their inherent complexity and specificity. The situation can be improved by Enterprise Modeling, yet, a domain-specific modeling framework cannot be developed before a structured set of requirements has been elicited for the artifact. In this study, a qualitative survey with semi-structured interviews has been conducted, splitting the focus between two specific acts, the DORA and EAA. The collected data have been subjected to thematic analysis, and the results have been used for the elicitation of a set of requirements, presented in the form of a goal model. Examples of the identified goals include regulatory clarity, resource allocation, training, and management support.
The European Union (EU) consistently develops and enforces legislation that its members states are
obliged to adhere to. These laws, commonly known as EU acts, aim to set standards, as a means
to harmonize the operational context and improve fairness for EU-based organizations [
One such discipline that can provide eficient solutions to organizational challenges of high complexity
is Enterprise Modeling (EM) [
CEUR
ceur-ws.org or be optimized for addressing problems of specific types and phenomena. EU act implementation can be perceived as domain-specificity [ 7] for a modeling framework.
From a Design Science Research (DSR) [8] perspective, a domain-specific modeling framework aiming to tackle the above-mentioned challenge is an artifact. Every artifact needs to be developed based on a set of requirements that outline and describe the artifact’s capabilities. For this reason, the goal of this paper is to elicit a set of requirements for a modeling framework that will support the implementation of EU Acts in organizations. Two specific instances of EU act implementations are used, DORA and EAA, and experts have been interviewed to collect data and synthesize a set of goals for a modeling framework artifact.
The rest of the paper is structured as follows. Section 2 provides a brief overview of the related background. Section 3 explains the involved methodological decisions, Section 4 presents the empirical results of the study, Section 5 introduces a set of requirements derived from the results, and Sections 6 and 7 discuss and provide concluding remarks on the study, respectively.
2.1. EU Acts
EU acts is a term commonly used to describe all the types of EU legislation. The EU has systematically
aimed for the standardization and harmonization of laws across its member states. EU legislation is
designed and published to ensure a consistent and fair operational context for EU-based organizations,
while in parallel promoting fairness for the EU citizens as customers of the organizations complying with
the regulations. They are classified into five main categories [ 9], which are (i) Regulations, which are
binding legislative acts that are applied directly to all member states without needing any transposition
or contextualization, (ii) Directives, which are applied to the member states indirectly, in other words,
every member state is allowed to devise their own laws for achieving the goals set by the directive,
(iii) Decisions, which are legally binding laws with direct application, yet, they do not apply to all
member states but have specific respondents, (iv) Recommendations, and (v) Opinions, which are both
non-binding laws that only serve as guidance for the EU’s member states. The entire repository of EU
legislation is available at the EUR-Lex portal [
A wide spectrum of acts covers all the important legal topics across the member states. A few
examples are the GDPR [
In this study, the main concern lies around the DORA and the EAA. The DORA is a legislation
that requires increased cyber-security measures in organizations of the financial sector, like banks,
or insurance and investment companies. Its aim is to reduce the vulnerability of EU-based financial
organizations against IT-related incidents, for example, cyber-attacks [
Continuous compliance is required by EU-based organizations, however, the environment that they operate in, results in a challenging situation. Initially, derived from the complexity and the requirements of the introduced laws, changes and adjustments to the organization’s capabilities are needed as a response to the external legal context [11]. However, context factors of diferent origins, like political, economic, social, technological, environmental, etc. (PESTLE analysis [12]), are always posing threats to the compliance level of an organization to a specific act, even if they are introduced as opportunities and threats rising from the organization’s context.
EM involves creating an integrated model of an organization that captures relevant aspects for a specific
modeling objective, such as concepts, goals, processes, or business rules. The integrated view of these
aspects is crucial for a holistic understanding of the organization [
Regarding EU act implementation, EM can facilitate a comprehensive understanding of how diferent parts of the given organization interact, which is essential for aligning regulatory requirements with organizational practices. An eficient EM framework can provide several specific benefits for the task. First, it can enhance regulatory clarity by enabling a comprehensive and structured analysis of the regulation’s content. This can help organizations interpret and apply regulations consistently, reducing the risk of non-compliant practices. Second, it can support optimizing resource allocation by documenting the specific areas where investments in technology, personnel, and processes are needed, based on modeled gaps. Third, it promotes continuous learning and adaptation by incorporating feedback mechanisms and structured model updates based on changes in regulations or organizational contexts.
The goal of this study is to elicit a set of requirements for a modeling framework that will support the implementation of EU Acts in organizations. This can be considered as one of the initial steps of a DSR [8] project. In particular, the DSR framework employed in this study is [16], which consists of five steps. These are (i) Problem explication, (ii) Requirements definition and outline of the artifact, (iii) Artifact design and development, (iv) Artifact demonstration, and (v) Artifact evaluation. This study comprises partially the first, and essentially the second step of the project, being the one before the development of the artifact. In other words, the aim of the project is the development of the artifact, yet, the aim of this paper is the elicitation of the artifact’s requirements. A qualitative survey strategy has been employed, combined with interviews as a data collection method and thematic analysis for analysing the data.
The overall research approach is based on the DSR principle that dictates identifying a category of specific problems, abstracting into a generic problem, and providing a generic solution artifact that can address all the specific problems that are specializations of the generic problem [ 16]. This study concerns the implementation of two specific EU acts, which have been used as examples of specific problems, the DORA, which is a regulation, and the EAA, which is a directive. The two diferent act types are used to ensure that the generic problem can be addressed even when diverse specific problems are used for the generalization. Thus, identifying requirements for implementing these two specific acts enables a synthesis and abstraction that can provide an initial set of requirements for the generic problem, which is the implementation of EU acts in organizations in general.
The selection of participants was performed using as criteria their professional background and expertise with relevance for each act. In particular, the DORA participants were selected with a background in security and finance, and the EAA participants were selected for their software development background, and when applicable, accessibility expertise as well. All eleven participants are working in organizations based in Sweden, and their work experience varies from three to thirty-eight years, with an average of seventeen years of work experience per participant. The domains they come from vary, from economics P1 P2 P3 P4 P5 P6 P7 P8 P9 P10 P11
Senior Cyber Security Advisor Cyber Security specialist Information Security Specialist Consultant Manager/Cyber Security Chief Information Security Oficer Senior Software Engineer Full-Stack Developer Senior Web and Mobile Developer Node Developer and Accessibility Specialist Advisor on Accessibility/Accessibility Engineer
Years of work experience 25 38 6 16 4 28 3 14 4 22 29 and law, to IT and Management. The common denominator in all cases is their experience or expertise in the fields addressed by the two given acts. The initial contact with the participants was initiated via Linkedin and personal contacts, followed by snowballing via recommendations by the initial participants. Table 1 depicts the participants, with their assigned anonymous codes, their roles and domains, and their years of work experience.
The collection of data was based on individual semi-structured interviews with the participants. Eleven interviews were conducted in total, six of them focusing on requirements for implementing the DORA, and the other five focusing on the EAA. Eight out of eleven interviews were held online for convenience reasons, and the remaining three were conducted in person in the participants’ work environment. The average interview time was one hour, and they were all digitally recorded.
The data collection protocol consisted of questions about (i) the participants back-ground in relation to the act (cyber-security or accessibility), (ii) their current involvement in implementation initiatives, (iii) the essential facilitating factors for the given act, (iv) the essential hindering factors for the given act, (v) how they perceive the overall attitude towards the act (personal and organizational), (vi) their knowledge about the act, and potential dificulties to interpret it, (vii) the resources needed for the implementation, both existing and needed, and how they can be acquired, (viii) existing technological and/or operational frameworks, guidelines, tools and approaches used for the implementation, and (ix) any training received, or planned to be developed/delivered about the implementation.
Once the interviews were completed, the recordings were anonymized, transcribed and coded. The collected dataset was subjected to descriptive coding, as described in [17]. The data analysis method that has been employed is thematic analysis, which can be inductive or deductive [18]. Inductive is driven by the data itself, minimizing the risk of researcher bias. Deductive thematic analysis concerns a pre-existing research framework that drives not only the development of the data collection protocol, but also the analysis procedure. In this study, inductive analysis has been employed, so, in practice, a structured set of requirements has been formed based on the themes, categories and codes derived from the collected empirical data. Both the coding and the analysis was completed in several iterations.
The empirical results were summarized, combined, and abstraction was applied on them, in order to
produce a set of requirements for the generic problem. The result of these activities was a set of goals,
which are considered requirement artifacts, in the Requirements Engineering (RE) context [19]. A goal
is defined as a desired state of afairs that needs to be attained [
This section will discuss the threats to the validity of this study, along with means employed to mitigate them, whenever possible. Initially, the selection of the participants was performed following a purposive and convenience sampling approach due to the limitations in time and resources. The experience with the given acts, which was used a criterion, guaranteed that the interviews would provide value for the research goal, however, more time and resources could potentially result in an optimal group of participants, with a higher average in years of work experience. In order to minimize the individual analyst’s bias, at least two of the authors were involved in every iteration of the descriptive coding and thematic analysis. Finally, one point that needs to be mentioned is the limited generalizability of the ifndings, because, at the current state of the project, there has been no evaluation or validation of the requirements set.
This section presents the empirical results of the survey, per act. Initially, the interviewees showed the tendency to deviate significantly from the posed questions, which on one hand is expected during a semi-structured interview, on the other hand, there were several topics and concepts brought up that did not align directly with the posed questions. One overarching theme that was common in both parts of the survey was the need to classify activities regarding the implementation and compliance to an act in phases. This emerged organically, even if none of the posed questions explicitly mentioned specific phases for act-specific implementations projects. Both the DORA and EAA respondents classified the activities in three main phases, (i) the pre-implementation, (ii) the main implementation phase, (iii) and the post-implementation phase. All the respondents are currently engaged in an implementation project or planning for it, that is, they are in a preparatory state aligned with the identified pre-implementation phase. To no surprise, there were minimum to no details elaborated about the post-implementation phase, since the participants are lacking practical experience from that specific phase. 4.1. DORA Initially, one of the main themes that emerged from the analysis of the DORA-specific interviews was the need for regulatory clarity. The respondents discussed the need for clarification provided by the authorities, mentioning specific institutions, like the Swedish Finansinspektionen (FI), from which clarifications and guidelines are systematically expected.
This also brought up the issue of misinterpretations during the absence of regulatory clarifications. In practice, as the respondents pointed out, there are many factors that augment the diversity in interpretations of an act. The most common factor that was mentioned was the interpretation per country/member state of the EU. Another important factor that was mentioned was the interpretation of what is a requirement in DORA and what is not, in other words, what must be implemented and what should/could/may be implemented. From a RE perspective, this can be perceived as lack of clarity in prioritization [19], leading to diversity in interpretations. This is also relevant to another factor leading to interpretation, which was mentioned as the degree of implementation, meaning that it is not clear when the efort has reached adequate levels and compliance has been reached. This is associated to the lack of clear compliance criteria, which were mentioned as an omission derived from the lack of clear guidelines, both about the implementation, and about its assessment. Finally, this theme also includes the updates on existing regulations.
One of the most important aspects that emerged as a theme was the existence, documentation and analysis of the relevant knowledge about DORA. The participants brought up knowledge about similar earlier legislation about the same domain, like the Directive on security of Network and Information Systems (NIS) and NIS2 [20].
Another important type of relevant knowledge concerns the contextual factors that are essential for the implementation. The theme that emerged was context-dependency for the implementation. Three important factors were mentioned. The size of the organization was the first one, with the participants mentioning that bigger organizations are overall better prepared for implementing DORA, since there are parts of DORA that are already fulfilled, while, on the contrary, smaller organizations have never met such demands. Another factor is the business domain, with organizations like banks being considered more prepared in comparison with organizations like insurance companies. One last factor that was mentioned was the risk-level, with organizations with higher risk-level, like banks, being considered harder to implement that low-risk ones.
Another theme that emerged was the existence of existing methods and tools that are deemed necessary during the DORA implementation. One such method that was strongly emphasized was gap analysis, which was mentioned as being essential both during the pre-implementation and postimplementation. The mention about pre-implementation derived from practical experience, while gap analysis in post-implementation was only mentioned theoretically and on a planning level. Another strongly emphasized method was risk management and analysis. A lot of details were emphasized about properly establishing risk management, so that proper risk assessments are conducted and reporting systems are set up. Best practices are also part of the knowledge that is required for the implementation, coming from either diferent member countries or earlier implementations of similar acts. This also involves variations and best practices from third parties in the organization’s ecosystem, for which compliance also needs to be monitored.
Finally, another theme concerned the required training, which concerns how this identified knowledge needs to be transferred. The means that were mentioned were workshops, seminars, and lectures. 4.2. EAA The EAA part of the survey resulted in a set of themes with several overlapping parts with the DORA one. Initially the first important theme concerned management enablement. The participants have emphasized the importance of supporting the management, especially when it comes to organizational support. There were also specific activities that were deemed as essential and were categories in the results of the thematic analysis. The first one was the allocation of resources. This includes both material and immaterial resources, for example, financial resources, infrastructure, and equipment. Knowledge and human resources have also been mentioned, however, they were emphasized enough for them to be independent themes, which will be discussed later in this section. Budgeting activities have also been mentioned and belong here. They are considered important by the interviewees, since they can eficiently support the proper allocation of resources. The final activity for which the managers of an organization will need support, is the establishment of dedicated personnel for the implementation project. The EAA participants emphasized more on the aspect of dedicated personnel, also combining it with the education aspect that is discussed in the next paragraph. More specifically, dedicated personnel can be acquired both by supporting the management in hiring individuals with the required expertise and knowledge, and by training the existing staf in the required knowledge.
The required knowledge and education themes are overlapping with the DORA findings to a significant degree. Education is also deemed valuable in the EAA implementation and can be delivered via seminars and workshops. The required knowledge on which the individuals have to be educated concerns, legislation training, both current and similar relevant guidelines like the Web Content Accessibility Guidelines (WCAG) [21], technical training and accessibility training, which is act-specific knowledge. The participants also emphasized on the need to have education that also promotes a shift in the mindset of the organization towards a company-wide mindset of the EAA. Finally, in a similar way to DORA, EAA implementation can benefit from familiarity with best practices. What was emphasized for EAA but not in DORA was the need to communicate best practices, even among teams that implement the EAA in parallel.
Another important theme that emerged from the EAA part was the stakeholder engagement. The improvement of the relations with stakeholders and their inclusion was deemed essential. The participants emphasized the need not only to establish feedback mechanisms, like discussion and thought panels, but also the integration of the collected feedback, which can enhance the implementation. The additional benefits from stakeholder engagement, according to the interviewees, are the promotion of the EAA’s importance, and potentially, new perspectives and ideas that may rise from the efective interaction with the stakeholders.
Technological and operational adjustments is a theme that included a variety of concepts about the EAA implementation. Initially, there are specialized tools that can be employed and integrated with the implementation process. Categories of such tools that has been mentioned by the participants are scaling tools, compliance monitoring tools, auditing tools, and tools that individuals with disabilities use commonly, and accessibility checklists. These are deemed as highly important because software development involves a high degree of automation, and the tools can improve the eficiency of the implementation. Naturally, this also requires keeping the existing IT infrastructure that exists in the organization and is relevant with the implementation of the EAA, up to date. In a similar way, the processes of the organization will potentially have to be adjusted, either by adopting new ones, for example via best practices, or by performing changes to the existing ones.
Based on the findings derived from the the survey, a synthesis and abstraction have been performed. In particular, all the knowledge required for an implementation has been summarized into one goal, which includes previous legislation, contextual factors, best practices, technical and act-specific knowledge. Other parts were elaborated more than the theme level, for example the ways for expert staf acquisition and the stakeholder engagement, where more detailed sub-goals were introduced, like the training and hiring of expert staf, and the implementation of feedback mechanisms and integration of the collected feedback, respectively. The purpose of these activities was to reflect more on the operational capabilities of the envisioned artifact.
Tables 2-4 present the goals for the pre-implementation, implementation and post-implementation phases, along with their descriptions, and the survey part that they originated from.
Based on the list of goals that was elicited from abstracting and synthesizing the empirical results of the two-part survey, a 4EM Goals model (Fig. 1) has been developed to complement the inter-goal relationships, for example, goals and sub-goals the existence of which supports or hinders other goals and sub-goals.
Initially, the elicitation of requirements and initial outline of artifacts is iterative, like any other DSR step. This study has completed the first iteration, which provides a solid basis for further elaboration, and also outlines the essential capabilities of the artifact under development.
To prepare for the implemen- Before the implementation, a series of preparatory activitation ties should be supported by the artifact.
To provide organizational support
Organizational support should be facilitated by the artifact, in terms of managerial activities.
To enable management for implementation activities
Management should be given the proper level of support by the artifact before the implementation.
To establish dedicated per- The implementation requires personnel dedicated to it, and sonnel the artifact should support establishing it.
To manage the allocation of necessary resources
Resources of all kinds are needed for the implementation and the artifact should support their allocation.
To perform budgeting activi- Budgeting activities will be supported, since they can be ties used for optimizing resource allocation.
To acquire staf with the required expertise To train existing staf
The artifact will support the acquisition of expert staf.
Staf training will be supported. 10 To develop training programs
Developing lectures, seminars, and simi-lar training activities should be supported by the artifact. 11 To hire expert staf
The artifact should support employing experts. 12 To identify required knowl- Act-specific knowledge, like previous regulations, needs to edge be identified and trained to employees. 31 To perform gap analysis
A gap analysis component should be included.
One potential limitation of this study is the restricted areas of the experts. The financial and cybersecurity domain, and software development domain, are eficient for the exploration of DORA and EAA, respectively. However, the introduced generalization that has been performed in this study may benefit significantly from the inclusion of experts from diferent areas. Optimally, the included experts’ areas should be as diverse as the topics addressed by EU acts.
The current version of the requirements set, split into phases and with several linear and succeeding activities indicate the need for developing a method artifact to be used as the envisioned modeling framework. A modeling method includes additional components [22], that is, semantics, syntax, procedure, mechanisms, and potentially a notation. These will require additional technical requirements. Technical requirements for a modeling framework are important, yet, they have not been addressed in this study. This was a deliberate omission, since we opted for reporting on the frame-work’s envisioned capabilities, and not on its form. We consider this an early stage of the project for eliciting technical requirements for the tool. Naturally, every DSR project has an iterative nature, and the elicited set of requirements is expected to evolve over the forthcoming iterations, and also be complemented by technical modeling requirements.
The current version also involves several external components, for example gap analysis, which has been emphasized as essential both in the pre- and post-implementation phases, risk management and analysis approaches, auditing and budgeting techniques, existing tools, even educational formats like workshops and seminars, or educational content like best practices and earlier legislation. On the one 13 To support the implementa- The artifact must facilitate the implementation activities tion during the main phase. 14 To ensure regulatory clarity
Ambiguous parts of an act must be addressed. 15 To use detailed guidelines
The artifact should facilitate the use of implantation guidelines for the given act. 16 To update regulations regularly
Regulations are often revised and their updates must be addressed by the developed artifact. 17 To clarify updates
Ambiguous updates of an act must be addressed. 18 To implement technologi- An act may require adjusting the technological and opera- EAA cal and operational adjust- tional infrastructure, tools and/or processes.
ments 19 To employ specialized tools
The integration of specialized tools must be addressed by the developed artifact.
EAA 20 To keep ICT infrastructure updated
The organization’s technological infrastructure may re- EAA quire updates that need to be facilitated. 21 To establish risk management procedures
Risk management approaches should be included as artifact component(s). 22 To set up reporting systems
Risk reports have value that the artifact cannot overlook, so, proper systems need to be set up. 23 To conduct risk assessments
The actual assessments should also be facilitated. 24 To monitor and evaluate compliance
The implementation will need to be dynamically monitored per steps and activities. 25 To perform audits
The artifact should include audit component(s). 26 To engage stakeholders ef- The efective interaction with the acts’s stakeholders must fectively be facilitated by the artifact. 27 To monitor third-party rela- Third parties and their compliance to the act needs to be tionships monitored by the supported organization. 28 To integrate stakeholder feedback
The integration of the feedback collected by the stakehold- EAA ers must be systematically integrated. 29 To implement feedback mechanisms
There must be systematic mechanisms to collect feedback from stakeholders.
EAA hand, this has practical value from both operational and design perspectives, since it saves resources by avoiding the need to “reinvent the wheel”. On the other hand, this is a strong indication that complex integration eforts will be required to ensure the compatibility of all the external components, both methodologically and data-wise.
Strong emphasis has been put on training in specialized knowledge, a fact indicating that the developed artifact will need to properly document and classify all types of relevant knowledge, that is, contextual, legislative, both in terms of current and previous legislation, technical, operational and any other act-specific knowledge. From a design perspective, the artifact must point to the relevant and valuable context information and knowledge, while in parallel optimizing the process by avoiding to waste time and efort on anything that bears no value for the implementation. To support EU act implemen- The main goal of the artifact will be to support implement- DORA, tation during all its phases ing EU acts in organizations. EAA 30 To assess the impact of the implementation
When the implementation is complete, the artifact must provide means to assess its impact.
A gap analysis component should be included.
The fact that there were no actual data collected about the post-implementation phase indicates two possible paths to fill this gap. There can either be a succeeding iteration with experts that have completed the implementation of an older act and have experienced analyzing the impact of such a project, or repeat the data collection activities for the given acts once the project has already been completed and the post-implementation phase has been initiated. This is one of the potential paths for future research derived from this study, and we aspire that the community will be motivated to contribute with valuable insights.
Another potential path for future research would be to complement this study with additional requirements from implementation projects that concern diferent acts, as for example the recent AI act [10]. On an alternative research plan, the elicited set of requirements could lead to the development of an initial version of the envisioned artifact, which could, in return, be tested and evaluated on the implementation of the AI act.
One final path for future research would be to combine the requirement set or the artifact that will be developed based on it, with existing EM approaches that are specialized for modeling change phenomena and evaluate their eficiency in modeling an EU act implementation. One potential candidate is the KYKLOS method [23] and tool [24], which is an EM method specialized for modeling changing organizational capabilities. Adopting the perspective that every EU act implementation is a transition of an organization’s capability, from a non-compliant version to the compliant version of the capability, enables potentials for additional paths in research around EM and EU act compliance.
This study tackles the challenge of implementing EU acts in organizations, by eliciting a set of requirements towards the development of a framework based on Enterprise Modeling. A two-part qualitative survey has been conducted to collect data from expert interviews regarding two specific EU acts, the DORA and the EAA. The results have been synthesized into one unified set of goals. Supporting management for expert staf acquisition and optimized resource allocation, regulatory clarity, risk analysis, efective stakeholder engagement, and technological and operational adjustments are several of the main identified aspects that a domain-specific modeling framework should address. [7] D. Karagiannis, R. A. Buchmann, P. Burzynski, U. Reimer, M. Walch, Fundamental Conceptual Modeling Languages in OMiLAB, in: D. Karagiannis, H. C. Mayr, J. Mylopoulos (Eds.), DomainSpecific Conceptual Modeling, Springer International Publishing, Cham, 2016, pp. 3–30. URL: http://link.springer.com/10.1007/978-3-319-39417-6_1. doi:10.1007/978-3-319-39417-6_1. [8] A. Hevner, S. Chatterjee, Design Research in Information Systems, volume 22 of Integrated Series in Information Systems, Springer US, Boston, MA, 2010. URL: http://link.springer.com/10.1007/ 978-1-4419-5653-8. doi:10.1007/978-1-4419-5653-8. [9] Types of legislation | European Union, 2024. URL: https://european-union.europa.eu/ institutions-law-budget/law/types-legislation_en. [10] European Parliament, Council of the European Union, Regulation (EU) 2024/1689 of the European Parliament and of the Council of 13 June 2024 laying down harmonised rules on artificial intelligence and amending Regulations (EC) No 300/2008, (EU) No 167/2013, (EU) No 168/2013, (EU) 2018/858, (EU) 2018/1139 and (EU) 2019/2144 and Directives 2014/90/EU, (EU) 2016/797 and (EU) 2020/1828 (Artificial Intelligence Act), 2024. URL: http://data.europa.eu/eli/reg/2024/1689/oj/eng, legislative Body: CONSIL, EP. [11] G. Koutsopoulos, M. Henkel, J. Stirna, Modeling the Phenomenon of Capability Change: The KYKLOS Method, in: D. Karagiannis, M. Lee, K. Hinkelmann, W. Utz (Eds.), Domain-Specific Conceptual Modeling, Springer International Publishing, Cham, 2022, pp. 265–288. URL: https: //link.springer.com/10.1007/978-3-030-93547-4_12. doi:10.1007/978-3-030-93547-4_12. [12] J. Law, A dictionary of business and management, Oxford paperback reference, 5th ed ed., Oxford
University Press, Oxford [England] ; New York, 2009. OCLC: ocn277068142. [13] U. Frank, Enterprise modelling: The next steps, Enterprise Modelling and Information Systems
Architectures (EMISAJ) 9 (2014) 22–37. [14] Object Management Group (OMG), OMG® Unified Modeling Language®, 2017. URL: https://www.
omg.org/spec/UML/2.5.1/PDF. [15] Object Management Group (OMG), Business Process Model and Notation, 2011. [16] P. Johannesson, E. Perjons, An Introduction to Design Science, Springer International Publishing, Cham, 2014. URL: http://link.springer.com/10.1007/978-3-319-10632-8. doi:10.1007/ 978-3-319-10632-8. [17] J. Saldaña, The coding manual for qualitative researchers, Sage, Los Angeles, Calif, 2009. OCLC: ocn233937452. [18] V. Braun, V. Clarke, Using thematic analysis in psychology, Qualitative Research in Psychology 3 (2006) 77–101. URL: http://www.tandfonline.com/doi/abs/10.1191/1478088706qp063oa. doi:10. 1191/1478088706qp063oa. [19] K. Pohl, Requirements engineering: fundamentals, principles, and techniques, Springer, Heidelberg ; New York, 2010. OCLC: ocn642291082. [20] European Parliament, Council of the European Union, Directive (EU) 2022/2555 of the European Parliament and of the Council of 14 December 2022 on measures for a high common level of cybersecurity across the Union, amending Regulation (EU) No 910/2014 and Directive (EU) 2018/1972, and repealing Directive (EU) 2016/1148 (NIS 2 Directive), 2022. URL: http://data.europa.eu/eli/dir/2022/2555/oj/eng. [21] W. W. A. Initiative (WAI), WCAG 2 Overview, 2008. URL: https://www.w3.org/WAI/ standards-guidelines/wcag/. [22] D. Karagiannis, H. Kühn, Metamodelling Platforms, in: G. Goos, J. Hartmanis, J. van Leeuwen, K. Bauknecht, A. M. Tjoa, G. Quirchmayr (Eds.), E-Commerce and Web Technologies, volume 2455, Springer Berlin Heidelberg, Berlin, Heidelberg, 2002, pp. 182–182. URL: http://link.springer. com/10.1007/3-540-45705-4_19. doi:10.1007/3-540-45705-4_19, series Title: Lecture Notes in Computer Science. [23] G. Koutsopoulos, KYKLOS - A modeling method and tool for managing changing capabilities in organizations, Doctoral thesis, comprehensive summary, Department of Computer and Systems Sciences, Stockholm University, Stockholm, 2024. URL: http://urn.kb.se/resolve?urn=urn:nbn:se: su:diva-226282, iSBN: 978-91-8014-663-0 (print) ISBN: 978-91-8014-664-7 (electronic) Number Of Volumes: 24-005 Publication Title: Report Series / Department of Computer & Systems Sciences 24-005. [24] G. Koutsopoulos, M. Henkel, J. Stirna, The KYKLOS Tool for Modeling Changing Capabilities, in: C. Cabanillas, F. Pérez (Eds.), Intelligent Information Systems, volume 477, Springer International Publishing, Cham, 2023, pp. 146–155. URL: https://link.springer.com/10.1007/978-3-031-34674-3_ 18. doi:10.1007/978-3-031-34674-3_18, series Title: Lecture Notes in Business Information Processing.