Supporting Viewpoint Coordination for Compliance by Design with an Artifact Model for Regulatory Requirements Engineering

Supporting Viewpoint Coordination for Compliance by Design with an Artifact Model for Regulatory Requirements Engineering

arXiv:2611.03631v1 [cs.SE] 2 Nov 2026

Oleksandr Kosenkov1,2*, Davide Fucci1 , Michael Unterkalmsteiner1 , Daniel Mendez1,2 1*

Blekinge Institute of Technology, Karlskrona, Sweden. 2 fortiss GmbH, Munich, Germany.

*Corresponding author(s). E-mail(s): oleksandr.kosenkov@bth.se; Abstract Regulatory compliance has become an essential software requirement. Legal demands for compliance by design (CbD) call for requirements engineering (RE) approaches that derive requirements and support compliance implementation in subsequent software engineering (SE) processes such as software design. The complexity of the legal knowledge demanded in regulatory RE makes it important to involve legal experts and ensure the relevant specifications are valid and usable for them. Regulatory requirements must support compliance implementation in software design. However, there is a lack of approaches bridging legal and SE viewpoints, and interaction challenges between the two persist. To address engineering–legal coordination in specification of regulatory requirements, we propose the Artifact Model for Regulatory Requirements Engineering (AM4RRE), operationalized through templates. AM4RRE was positively evaluated by most of the 37 practitioners for coordination in regulatory RE and for supporting requirements quality. Results from a quasi-experiment with 34 of them in 10 groups indicated that template-guided coordination was associated with, on average, shorter total specification time when executed first and higher requirements quality in most groups in which it varied. Existing RE research and practice provide little attention and support for viewpoint coordination in regulatory RE for CbD. Artifact-oriented approaches such as AM4RRE have the potential to guide coordination in RE for better RE results and contribute to concretizing the role and contribution of RE to CbD. Keywords: empirical software engineering, requirements engineering, regulatory requirements, software compliance, compliance by design, compliance engineering

1

1 Introduction In recent years, countries worldwide have enacted multiple sophisticated regulations affecting software engineering (SE) [17, 42] across domains. Consequently, regulatory compliance has emerged as a cross-cutting software quality requirement that demands legally verifiable conformance. Recently introduced compliance by design (CbD) obligations demand integrating regulatory requirements into software design rather than addressing them as an afterthought. To address the challenge of systematically accounting for regulations and supporting compliance implementation in SE, regulatory requirements engineering (RE) approaches must both derive requirements from regulations and support their implementation throughout software engineering processes [18, 24]. In practice, awareness and adoption of regulatory RE approaches remain limited [27, 33]. We argue this is because two conditions tied to core RE challenges are overlooked. First, processing the legal knowledge required to implement compliance, along with SE expertise [32, 37], is more complex than other types of domain knowledge addressed in RE. Legal knowledge and specifications are required in RE and downstream processes to demonstrate compliance [8, 50] and in legal disputes [6]. Applying legal knowledge involves specific legal roles, processes, and goals that together form a distinct viewpoint. For example, legal interpretation concretizes abstract regulatory norms into case-specific demands and supports compliance demonstrability through regulation-to-implementation traceability, which differs from the traceability typically required in SE [8, 33]. Even when legal experts are available, the semantic gap between engineering and legal professionals [4, 48] makes it difficult to explicate, specify, and reuse legal knowledge [30] or to achieve shared understanding. Still, existing RE approaches provide limited support for either enabling engineers with basic legal knowledge to complete legal specifications [39] or meaningfully involving legal experts. The second overlooked practical condition is the role of regulatory RE in supporting downstream compliance implementation by coordinating interdependent legal and SE viewpoints [5, 6, 19]. Regulatory requirements are often a “natural afterthought” because determining regulations’ applicability and selecting implementation options [14] depend on existing SE specifications [20]. Engineeringlegal decision-making must therefore address how regulations impact non-regulatory requirements [38] and system design [33], while balancing legal constraints, business objectives, and technical feasibility [30, 39]. CbD obligations emphasize such coordination to keep interpretations and implementation aligned. Although engineering-legal interaction already occurs in practice, it remains largely unstructured [27], complicated by semantic gaps, differences in methods [22], and ways of working [30]. Practitioners, therefore, would benefit from approaches that support systematic specification and coordination of legal and SE viewpoints in regulatory RE for CbD. Existing research offers little practical support for this. To address this gap, we propose the Artifact Model for Regulatory Requirements Engineering (AM4RRE1 ), which supports regulatory RE for CbD by guiding specification and coordination activities of legal, managerial, RE, and software architecture 1 AM4RRE is pronounced like amphora—an ancient ceramic container for water or wine with two large handles. Some amphorae were so large and heavy that two people had to carry them collaboratively.

2

viewpoints, and by guiding the specification of regulatory requirements grounded in these viewpoints. Our proposed approach follows artifact orientation, which guides RE activities through a blueprint of artifacts and their dependencies rather than through prescribed activities. AM4RRE makes two primary contributions to the existing state of regulatory RE research and practice, which are: • it offers a systematic way to capture and make explicit specific knowledge, processes, goals, and context of the roles involved in regulatory RE through viewpoint modeling. In particular, the legal viewpoint model incorporates legal concepts used in legal interpretation to help legal experts complete the legal specifications required in regulatory RE. This is intended to facilitate their involvement and make the resulting specifications useful, rather than detached from legal practice. • it supports engineering-legal coordination by making relationships between viewpoint concerns explicit and enabling these concerns to be reflected in resulting regulatory requirements specifications. In particular, it supports the inclusion of information about regulatory demands directly relevant to software design and the specification of new or affected software design components. The evaluation of AM4RRE presented in this study focuses on these two contributions—usefulness for completing SE and legal viewpoint specifications, and support for guiding coordination between viewpoints. For the evaluation, we tailored the AM4RRE artifact model to the General Data Protection Regulation (GDPR) and the Cyber Resilience Act (CRA), both of which require CbD, and we operationalized it through a series of templates. We evaluated AM4RRE using subjective feature analysis with screening [25] with 40 practitioners (3 of whom withdrew) and a quasi-experiment [54] with 34 of these practitioners in 10 groups. Practitioners found the coordination driven by AM4RRE templates to be aligned with regulatory RE practices and positively perceived the usefulness of AM4RRE to support the quality of regulatory requirements, coordination in regulatory RE, compliance implementation in software design, and achievement of viewpoint-specific goals. The quasi-experiment results support the feature analysis by indicating an association between using AM4RRE-based templates and, compared with free-form coordination, shorter average total requirements-specification time when guided specification was executed first, higher completeness in all groups in which completeness varied, higher consistency in eight out of ten groups, and higher correctness in nine out of ten groups. Our results further suggest that RE can help address the well-known domain knowledge challenge in SE and, on that basis, contributes to coordinating domain experts and SE roles in downstream SE processes such as software design. This contributes to further understanding of both the domain knowledge and the intermediating role of RE between the software application domain and SE processes. The paper is structured as follows. Sections 2 and 3 introduce background and related work. Section 4 presents AM4RRE and the regulatory requirements templates. Section 5 describes our methodology, and Sections 6 and 7 report and discuss our key results. Section 8 discusses the main threats to validity and how we mitigate them, before outlining conclusions and future work in Section 9.

3

2 Background This study focuses on RE for regulatory compliance of software systems – a state of verifiable implementation of obligatory, pre-defined, legally binding norms specified in applicable regulations [32]. Because regulations (e.g., GDPR) usually require demonstrating compliance, we suggest that both software engineers and legal experts should be able to verify compliance implementation. Recent EU regulations introduce the obligation of compliance by design (CbD), requiring regulatory compliance to be implemented in software design rather than being addressed as an afterthought. CbD has different regulation-specific facets: data protection- or privacy by design (PbD), required by Article 25 of the GDPR, and security by design (SbD), de facto required under Article 13 of the Cyber Resilience Act (CRA) [11, 12]. Regulatory RE for CbD is a specialized area of RE that translates regulations into requirements and supports regulatory compliance implementation in software design. Regulatory RE for CbD involves multiple viewpoints – complementary and interdependent perspectives that contribute to regulatory RE and compliance implementation and are characterized by specific syntax and specification concepts, roles with their knowledge and qualifications, processes, and goals pursued in regulatory RE [36]. The legal viewpoint in regulatory RE is characterized by the demand for legal knowledge to execute a legal interpretation, that is, to concretize abstract regulatory norms into concrete context-specific demands and system-specific requirements. We define legal knowledge as knowledge about legal concepts, their relationships, and how they are applied in legal processes. Legal concepts are “stereotypical” semantic elements of regulatory acts that carry the meaning relevant to legal interpretation and that eventually determine interpretation outcomes [31]. Regulatory RE requires actionable mechanisms that address divergent interpretations of specifications [16] and differing methods and tools [55] between the disciplines. We define coordination of viewpoints in regulatory RE for CbD as the explication, identification, specification, and exchange of information between legal and SE viewpoints to specify regulatory requirements and implement regulatory compliance in software design. Specification transparency is the quality of a specification underpinning coordination by allowing one to find and understand the required information. Because substantial research on interdisciplinary coordination in RE is lacking, our study focuses on measuring specification time and requirements specification quality as outcomes rather than the coordination process. Correctness of regulatory requirements refers to the extent to which the requirements accurately reflect applicable regulations and support their implementation; internal completeness means that all required elements are specified; and consistency is the absence of conflicts between regulatory requirements and their source specifications (viewpoint specifications under guided or case descriptions under free-form coordination). This study applies artifact-oriented regulatory RE, which guides RE through the content of RE results rather than RE activities [41]. We use the state-of-the-art Artifact Model for Domain-independent Requirements Engineering (AMDiRE) [40], composed of role, process, and an artifact model as the backbone, as the basis for developing our AM4RRE approach. In the context of artifact orientation, we use the terms regulatory requirement specifications and regulatory requirements as synonyms. 4

3 Related work Next, we provide an overview of the studies in research tracks related to our study. Regulatory RE and compliance by design research In regulatory RE studies, approaches to complex legal knowledge range from generic methods such as grounded theory or deontic logic (e.g., [8, 26]) to custom conceptual models (e.g., [45, 48]) and adapted legal concepts (e.g., Hohfeldian model of jural relations [15]). However, existing approaches do not support the semantic analysis and legal interpretation that legal experts perform, preventing both meaningful involvement and expert review of the results [31]. Many existing regulatory RE approaches focus solely on modeling regulations (e.g., [8, 48]) and do not account, in the RE process, for the system or context to which the regulation applies. Approaches that account for such context usually suggest using the same engineering notations for both regulations and requirements (e.g., a goal-oriented requirements language [15]). This constrains the expressiveness of regulation models and the execution of legal interpretation. Many studies assume that compliance should be addressed only in the RE process [10] and ignore the demand for CbD. Studies focusing on CbD emphasize the importance of engineering-legal collaboration and specifying both viewpoints [7, 47]; however, they do not suggest systematic ways to analyze different regulations [33]. Some empirical studies (e.g., [39]) suggest that RE tools, rather than replacing lawyers, should guide software engineers in legal interpretation and in exchanging information with legal experts. Recent studies on automated regulatory RE methods, including AI-based methods, also recognize the need to involve legal experts [46, 48]. Only a few studies considered such involvement, and they either proposed a high-level vision of the activities legal experts should perform [2, 10] or focused on information shared between engineers and legal experts [5], neither of which allows meaningful engineering-legal interaction. Shared understanding Shared understanding is essential in supporting RE [16] and downstream activities [53]. Studies in this area point to legal knowledge as a challenge to shared understanding [16, 53]. However, no approaches specifically address shared understanding in regulatory RE, and available studies mainly focus on shared understanding between RE and downstream SE processes [13], while addressing aspects at a higher level (e.g., [43]). This makes it difficult to adapt them for interdisciplinary engineeringlegal shared understanding. These studies also mention artifacts as an important but auxiliary means of establishing shared understanding [13, 16]. Viewpoints in RE and SE Existing RE studies suggest using viewpoints as a means for organizing RE processes that involve multiple heterogeneous stakeholders, large volumes of viewpointspecific information, and potential conflicts and inconsistencies between stakeholders [9, 35, 36, 49]. Purposes of viewpoint application include facilitating a deeper

5

understanding of the problem domain, improving backward traceability, addressing problem-domain complexity, and explicitly capturing differences between viewpoints [9]. In this research track, the legal viewpoint is defined as the indirect viewpoint that generates requirements constraining the SE viewpoints [35]. Still, there is a lack of studies that apply viewpoints to regulatory RE specifically. Further, viewpoint applications remain at an abstract level (e.g., [35]) and are only loosely adaptable to regulatory RE. In addition, to the best of our knowledge, viewpoints have seen limited application in RE practice because of the tendency to express requirements in viewpoint-specific working notations and the limited capacity of viewpoint models to reflect organizational problems alongside technical ones [49]. Coordination in requirements and software engineering Some SE studies focus on coordination and interdependencies across SE teams that apply different specialized practices (e.g., agile vs. waterfall), belong to different disciplines (e.g., hardware vs. software), or involve stakeholders with conflicting interests [51]. In this area, boundary objects (artifacts in which knowledge is manifested [55]) were identified as coordination mechanisms in large-scale agile software development [22], facilitating interaction, knowledge sharing, and integration of work across SE teams [55]. Studies in this research track identified regulations as one type of boundary object used to ensure common understanding and compliance [22]. However, these studies focus on interactions among engineers (e.g., [44]), rather than interdisciplinary engineering-legal interaction; thus, they neither specify a legal viewpoint nor support legal interpretation. Research gap Existing studies recognize legal knowledge as a barrier to shared understanding, identify a distinct legal viewpoint, and characterize regulations as boundary objects for coordination across SE teams. However, there is a lack of approaches that support the specification of legal viewpoints (with or without legal experts), enable legal interpretation, and meet other legal goals required in practice. Existing methods do not explicitly and transparently capture each viewpoint’s implicit knowledge as domainspecific concepts and goals, so they do little to help roles understand other viewpoints or coordinate. The literature also lacks methods for specifying regulatory requirements that consider downstream artifacts, as regulatory RE for CbD requires. As a result, stakeholders usually have to capture additional information separate from the engineering artifacts, creating unnecessary overhead. Finally, to the best of our knowledge, we still lack studies considering approaches under realistic conditions involving legal experts and software engineering roles at the same time. Earlier versions of AM4RRE [29, 31] aimed to enable engineers to support legal interpretation using corresponding legal concepts. However, recent empirical studies identified additional legal concepts relevant to CbD [33], potentially diverging viewpoint-specific goals [33, 34] and views on challenges to regulatory RE [32]. This made it clear that an effective coordination between legal experts and software engineers is essential. Since no approach accommodates viewpoint differences and implements more structured coordination, we address this gap with the contributions presented here. 6

Supporting viewpoint-specific tailoring Artifact model What specified?

Process model When specified?

Proj. context model Why specified?

Goal model For which goals?

Role model Who specifies?

Structure model Content model Specifications Concepts Content items

Sequence, relations of milestones

Prioritization of encountered challenges

Hierarchy of pursued goals

Responsibility, qualification of involved roles

Legal viewpoint

Legal artifact

Legal process

Challenges legal

Legal goal

Legal role

Managerial viewpoint

Managerial artifact

Managerial process

Challenges manag.

Managerial goal

Managerial role

Requirements viewpoint

RE artifact

RE process

Challenges RE

RE goal

RE role

Softw. arch. viewpoint

Soft. arch. artifact

Soft. arch. process

Challenges soft. arch.

Soft. arch. goal

Soft. architect role

Operationalization:

Tailoring profiles

Templates

Checklists

Tool support

Fig. 1: Overview of the core AM4RRE components and associated viewpoints, intentionally kept at an abstract level.

4 Artifact Model for Regulatory Requirements Engineering (AM4RRE) In this section, we describe the Artifact Model for Regulatory Requirements Engineering (AM4RRE), its development, tailoring, operationalization with templates, and AM4RRE-based templates for regulatory requirements specifications for CbD. We focus only on the aspects relevant to the study at hand. AM4RRE in a nutshell AM4RRE is an artifact-oriented approach that guides all roles involved in regulatory RE for CbD by means of a central artifact model and the dependencies between the artifacts it covers. By focusing on what should be specified rather than how it should be specified, it avoids prescribing complex processes and supports consistency and shared terminology in central artifacts. Artifact orientation provides several benefits [40, 41], including a closer focus on deliverable quality, greater flexibility (it can drive RE as the core approach, complement activity-based approaches, and integrate into existing SE process models), and better management of artifact availability and dependencies. We chose it as the basis for AM4RRE because it suits the distinctive features of regulatory RE. Figure 1 provides a high-level overview of AM4RRE; Figure 2 complements it with the AM4RRE meta-model, showing extensions of the original AMDiRE components to accommodate regulatory RE. AM4RRE components are as follows: Artifact model (answering the question What is specified? ) is the backbone of AM4RRE and defines the artifacts and information specified in regulatory RE for CbD. It contains two artifact views, each a separate (sub)model: a structure model and an underlying content model. The structure model organizes related concepts into artifacts and uses a common specification syntax to form so-called content items (the smallest semantically coherent aggregation of information with the same purpose and meaning) and specifications (groups of content items serving the goals of one role and viewpoint). It can be compared to documents and underlying sections with 7

prioritizes

A

+Artifact A

A

Context Model

M

Goal Model

Process Model

Artifact Model contributes to

◀ refines

A

Artifact Structure parent

subgoals

0..1

A

Challenge

A

0..*

Goal

1..*

0..*

1..*

0..*

A

1

0..*

Uses (Input) 0..1

1

1

Process Type

A

A

1

A

Content Item

ViewKind : {legal, managerial, requirements, architecture}

+Content

ViewKind : {legal, managerial, requirements, architecture}

1 M

Role Model

1

0..*

M

0..*

Level of Abstraction

0..*

+Concept

0..*

Artifact View spans ◀

Role Type

contains ▶

A

1

1

A

A

A

1

View 1

Knowledge

Content Dependency

Concept Item

1

+Target

1

- Conformance Constraint

0..1 defines

defines

Viewpoint 1..*

uses ▼

Viewpoint Abstraction Model 1

1..*

- AttributeCollection ViewKind : {legal, managerial, requirements, architecture}

+Source 1..*

0..* 1

1..* managerial, requirements,

architecture}

0..*

A

has

ViewKind : {legal,

Concept Type

0..*

1 1..*

1..*

1

Modelling View

A

1..*

Artifact Content

1

A

Qualification

Dependency

1

1..* 0..*

+Role 1..* A

1

◀ depends on 0..1

Role

Artifact

1..*

Content Concept Link

Artifact Abstraction Model

◀ refines

M

Structure Dependency

+Artifact

1

1

0..*

has

0..*

+Task

A

1

0..* +Source

1..*

0..*

A

Goal Type

Responsibility

0..*

1..*

Produces (Output) +Task

M

0..*

- State

+Artifact 0..*

1

0..*

Task

A

1

1..*

+Target has

0..1 1..*

0..1

0..*

1..*

0..*

Artifact Type

1..*

level : {0, 1, 2, 3}

{1..12} ViewKind : {legal, managerial, requirements, architecture}

0..*

1..*

+Artifact 0..*

1..*

uses 0..12 ranking : Integer [0..1]

0..*

Milestone

A

defines

A

1 A

5

ViewKind : {legal, managerial, requirements, architecture}

Syntax

ModelKind : {role, goal, context, process, artifact}

1..*

1

Skill

Method

1 defines

Concept

1..*

Fig. 2: AM4RRE meta-model based on the AMDiRE meta-model [41]. Added elements are yellow (marked “A” ); original elements are blue (marked “M” if modified).

associated responsibilities captured in the role model. The detailed content view, in turn, abstracts from the modeling concepts through a content model and, thus, supports consistency and seamless modeling. Role model (Who specifies? ) describes the roles involved, their responsibilities for artifacts, and their required qualifications. Process model (When specified? ) establishes the milestones at which corresponding roles complete, review, or accept artifacts. Goal model (For which goals? ) specifies the goals relevant in regulatory RE for CbD. Goals are organized into different hierarchical levels, with the root goal (level 0) supporting CbD implementation itself; each goal can be supported by a non-exhaustive set of subgoals on the next level. Goals guide project-specific decisions. Project context model (Why specified? ) captures the project context by prioritizing challenges to regulatory RE for CbD from each role’s perspective. To manage concerns of different roles and enable their involvement, we organize elements of each model related to a particular role into views (e.g., legal artifact model view). Views across models related to the same role constitute one of the four viewpoints: legal, managerial, requirements, and software architecture. For brevity in this paper and the quasi-experiment materials, we occasionally refer to corresponding views as models (e.g., legal artifact model). The version of AM4RRE we present extends the state-of-the-art Artifact Model for Domain-independent Requirements Engineering (AMDiRE) for non-regulatory RE [40] using the data of recent empirical studies as follows: 8

GR1.1

GR3.1

Identify all relevant norms and concepts

Identify and resolve conflicts between impacted concerns

GR3.2

GR1.2

Ensure requirements traceability to their origin

Identify types of impacted technical concerns supports

GR1.3

GR4 Support communication across functions

supports

GR3

Collaborate and coordinate effectively

Ensure requirements are correct

supports supports

supports

supports

supports

GR1.4

supports

Ensure requirements are complete GR1.5

GR: Support CbD implementation by the requirements engineer

Prioritize requirements

GR1

supports

Specify regulatory requirements

supports

GR2.1

Synthesize best practices and reuse experience

Implement regulatory requirements throughout the SDLC

supports

GR2.2

Ensure regulatory requirements are clear to each role in its context

supports

Identify impacts on engineering processes

supports

supports

GR2.3

GR2.5

Maintain one information source for shared understanding across roles

Ensure development teams retain autonomy in compliance implementation

GR2.4

Ensure consistent legal interpretation across projects and products

GR1.8

Maintain a requirements overview

GR2.6

Identify compliance roles and their responsibilities

supports

GR1.7

Promote understanding and awareness

supports

supports

supports

GR1.6

Ensure specification sustainability through changes

supports

GR2.7

GR2

supports

supports supports

supports

GR1.9

Keep interpretations and legal context available over time GR1.10

Specify requirements ownership

Fig. 3: RE view of the goal model. The root goal is not shown; the first-level goal is denoted with a view ID, the second-level goals as whole numbers following the view ID (e.g., GR1), and third-level goals as a fractional part (e.g., GR1.1).

• extends the artifact model with legal concepts and artifacts identified in [31, 33]; • introduces views and viewpoints (see Figure 2 for comparison with AMDiRE); • adds the legal expert role and changes other roles in the role model [27, 30, 32]; • adds legal interpretation milestones in the process model based on [30, 31]; • introduces the project context model prioritizing challenges identified in [32]; • introduces the goal model based on [33, 34]. Our study extends the previous version of AM4RRE [31] by integrating legal concepts from [33], merging two legal specifications into one, adding project context and goal models, and revising role and process models using empirical data [30]. Most importantly, we evaluate AM4RRE operationalized through templates. Viewpoint specification and coordination AM4RRE guides viewpoint specification by defining baseline elements for each view (see above). For the legal viewpoint, for example, these include regulation-independent concepts and artifacts for a legal interpretation, legal experts’ responsibilities and qualifications, interpretation milestones and tasks, legal experts’ goals in regulatory RE for CbD, and regulatory RE challenges to prioritize from their perspective. Together, these views capture the legal viewpoint’s distinctive features, help explicate legal specifications and align them with legal practice, and provide SE roles with a structured overview that may guide specification completion. AM4RRE supports viewpoint coordination by enabling the involved roles to (1) identify concepts required for a legal interpretation using the legal viewpoint tailored to a regulation, as in the GDPR example, (2) identify existing or new SE concepts that correspond to the required legal concepts, guided by their properties and definitions, and (3) integrate the required concepts into the means used for SE specification completion (e.g., via templates) with the preservation of traceability to the relevant 9

Regulatory requirement - component - control - stakeholder - activity - article - sanction size 0..* 0..*

Regulation

Regulatory act

0..*

enacts 1..*

1..*

1..* defines 1..*

1..*

Article - id - name

defines 1..*

1..* 1..*

Project scope

Stakeholder model

1

Problem description

1..* 1..*

Jurisdiction

has

- id - name - validity time - priority

1..*

1..*

Field of law

- criterion - territory

infers

Stakeholder 0..1

determined by

1..*

Intent statement

1..*

- criterion

1

1..*

relates to

1..*

defines

defines 1..*

0..*

0..*

Regulator - name

0..* 0..*

determined by

has

1..*

0..*

Software context specification

Regulatory demands specification

1

defines

- residence - users’ and partners residence - processing of personal data

1

- ID - person type: natural, legal - legal capacity: underage, adult - residence 1..*

1..*

defines

Requirements specification Legal subject 0..*

Legal relation

relates to

0..*

Legal subject 0..*

Usage model

0..*

0..*

- person type: natural; legal - legal capacity: underage; adult - normative role: right-holder; duty-bearer - residence - definition

relates to 1..*

- legal subject 0..* - modality: right, duty;

- matter - condition - article

0..* 1..*

0..*

1..* 1..*

- stakeholder - precondition - postcondition - actions - data object

Legal object 0..*

0..*

0..*

0..*

Control

0..*

- abstr. level: req-s, system - definition 0..* 0..1

1..*

0..* 0..*

1..*

addresses

0..*

0..*

Criterion

0..*

- abstr. level: req-s, system - definition

Legal sanction

0..*

- abstr. level: req-s, system - definition 0..1

should meet

1..*

0..*

0..*

Legal sanction

Target of regulation 0..*

System specification

- personal data: Yes, No - purpose

0..1

implements

implements

Architecture overview

- type: fine, administrative 0..* - article - size

Data model

1..*

Component

Data element

1..*

0..*

- processing purpose - special data - international transfer 0..* - profiling - location

directed at directed at

0..*

0..*

0..*

directed at

0..*

Data object

Functional scenario

1..*

directed at

Data model 0..*

Legal relation

should meet

0..*

- personal identified: Yes, No - purpose

0..1

directed at

Fig. 4: Content model tailored to the GDPR and used for template development. A UML class diagram depicts viewpoint-specific concepts (content view); a UML package diagram depicts the structure view overlaid with content items and specifications (regulatory demands, software context, requirements, and system specifications).

legal concepts. Relations between concepts in different views guide the regulatory RE process. Finally, to ensure that the resulting specifications (project-level artifacts) address concerns from different viewpoints, the artifact model captures concepts that constitute the content of regulatory requirements specifications and belong to different viewpoints. AM4RRE supports the following forms of engineering-legal coordination. The first is when the model is tailored to a domain and/or regulation, e.g., before a project starts or when a unit adapts its methodologies. Here, team members define the reference model to be used in projects. Next, the model can be tailored to the specific project setting. Here, legal experts and SE roles responsible for specific artifacts establish relations and context-specific equivalences between legal and SE concepts. During project execution, engineering-legal coordination occurs when legal experts and corresponding SE roles use the operationalized, tailored model to specify the corresponding legal concepts embedded in the SE specifications, and directly interact to specify regulatory requirements according to the tailored template. AM4RRE tailoring Before AM4RRE can guide regulatory RE for CbD, it must be adapted to specific regulation and organizational or project contexts. We denote this adaptation as tailoring, which includes some of the instantiation activities. Tailoring can be applied at 10

the organizational, project, or both levels in three ways: [T1] regulation-specific, [T2] project-specific, and [T3] optional goal-driven tailoring. Next, we provide an overview of each of them. T1. Regulation-specific tailoring of the artifact model identifies the legal concepts that constitute the artifact content model for implementing a specific regulation. It includes the following steps: [T1.1] identification of the instances of legal concepts from the AM4RRE legal artifact content model in the selected regulation (e.g., by annotations). [T1.2] identification of the relevant attributes of concept instances according to the regulation. First, existing attributes of corresponding concepts in the nontailored AM4RRE are checked and transferred to the tailored instance if they are relevant. If there is no corresponding attribute, it should be added to the tailored AM4RRE instance. [T1.3] removal of concepts and content items not relevant to the corresponding regulation. [T1.4] ad hoc addition of new legal concepts required for legal interpretation if a person possessing legal knowledge considers them important. Experts with the required legal knowledge should conduct this tailoring independently. T2. Project-specific tailoring adapts models constituting AM4RRE to organizational or project context and establishes relations between the legal and SE concepts of the artifact content model. It is conducted in the following steps. [T2.1]: for each legal concept and its attribute in the tailored legal artifact model, semantically related concepts in SE artifact content models are identified by coordinating and negotiating between the legal and SE roles responsible for the corresponding relevant concepts (tailoring-time coordination). [T2.2]: checking that definitions of legal and SE concepts between which a relation was established are compatible; If a concept or an attribute is missing from the SE specification, it is added to the most suitable SE content item and concept and defined according to the corresponding legal concept definition. The relations established during this tailoring further guide the roles toward specific artifacts, content items, and concepts in regulatory RE. It must be performed for each organizational or project context and regulation, by the responsible SE roles, with legal experts validating the relations. T3. Goal-driven tailoring is optional and is used to scope regulatory RE toward the achievement of specific goals. For this, relevant goals are selected using the goal model, and relationships between goals and artifacts in the artifact model are used to determine which concepts need to be specified and prioritized to achieve the corresponding goals (e.g., effective management of the non-compliance goal requires specifying the legal sanction concept). This type of tailoring is outside the scope of this study. Figure 4 already shows the artifact model tailored to the GDPR, and the following example illustrates this tailoring. Example. During the GDPR-specific tailoring, the legal expert of a company identifies the data subject as a GDPR-specific instance of «legal subject» and adds the attribute residence to the legal concept «legal subject» because, according to the GDPR, the residence of data subjects is one of the factors determining GDPR applicability (we abstract from additional legal intricacies regarding GDPR applicability). Next, during project-specific tailoring, the legal expert identifies the managerial concept «stakeholder» as a specialization of the legal concept «legal subject». The legal expert, in coordination with the managerial role, adds the attribute residence to the

11

«stakeholder» managerial concept, as required for legal interpretation. After that, the legal expert and manager verify that attributes are coherently defined from both views and that residence and person type attributes will be understandable to specifiers (tailoring-time coordination). After the tailoring, the model is operationalized through templates. Next, project roles use the templates individually, specifying the corresponding attributes that support identifying the stakeholder instances to which GDPR applies. Once specifications are available, the involved roles collaboratively specify requirements using the tailored regulatory requirements specification template. Here, the relations between concept instances drive specification-time coordination: systematic, targeted discussion of the applicability of legal concepts, followed by specification of regulatory requirements. AM4RRE operationalization In this study, we operationalize AM4RRE using specification templates. AM4RREbased templates are intended to facilitate the capture of viewpoint-specific information required for regulatory RE, guide specifiers with or without viewpoint-specific knowledge, and support the exchange of information between the viewpoints. We developed specification templates based on the artifact model, and each template usually corresponds to one content item. The process model determines the sequence of template specifications and their dependencies.

Legal Perspective

Team:

Role:

Legal Perspective

Template for Specification of Legal Object

Team:

Role:

Example

This template is intended for specification of legal objects according to the legal perspective. The template helps to identify and document the main types of legal objects (targets of regulation, and controls), criteria applicable to them and relations between them. One of the main purposes of the template is to help to allocate legal objects across the levels of abstraction and separate more abstract legal objects (requirements) and concrete software-system relevant legal objects (system specification). !IMPORTANT. In some cases, legal norms can imply the development or availability of a system component (e.g., “employee has provided an information” implies a software component for processing information provided by employees). During the specification according to this template, such components should be explicated. !IMPORTANT. To improve the visual analysis, targets of regulation, controls and criteria which are applicable concretely to software system (abstractness: system) and the ones which are more abstract (abstractness: requirements) are located in di!erent swimlanes (boxes) and are colorcoded. !IMPORTANT. In case you are not able to identify the right level of abstraction this can be done jointly with architect role and requirements engineer role in the later phase of the workshop. Specification: UML class diagram

Definitions Legal object is any object or right towards which legal norm is directed. Target of regulation is existing components of software systems, organizational processes which are addressed in regulations. Regulations can also target misuse cases of the system that should be addressed. Compliance control is any new or existing software components, organizational processes introduced or assigned to address the targets of regulation. Criterion is a property of compliance controls AND/OR targets of regulations which qualify them as acceptable from the legal perspective. Requirements (abstraction level) include abstract concepts not specific to particular system-level specification and demanding additional interpretation. System (abstraction level) includes concepts directly related to system and not requiring additional interpretation. The relations between di!erent concepts are as follows:

Specification Task

Requirements (abstraction level)

On the basis of the provided excerpts from the legal text (see the handout “HealthyApp Development: Privacy Compliance Perspective”), please do the following: • identify all the legal objects mentioned in the excerpts from the GDPR (legal perspective). For this, you may use the provided green, red/pink/ and violet highlighters. • specify the legal objects using a diagram (see the next page). Add additional figures when necessary and include the relationships between the elements.

System (abstraction level)

Herewith, possible relationships between the instances of concepts can be as follows: 1. relationships between di!erent instances of “target of regulation”; 2. relationship between “target of regulation” and “criterion”; 3. relationships between “control” and “target of regulation”; 4. relationships between “control” and “criterion”; 5. relationships between di!erent instances of “control”. See specification example and specification task on the following page.

<<criterion>> lawfulness

<<target>> personal data (PD)

<<target>> PD collection

<<criterion>> processing purposes given

<<criterion>> consent given

<<target>> PD processing

<<target>> PD recording

<<target>> PD storage

<<control>> consent service

<<target>> PD erasure

Fig. 5: Example of an AM4RRE-based template: legal object specification (legal viewpoint). Numbers 1 to 4 mark the four template sections.

12

AM4RRE-based templates developed for this study are composed of the following sections (see Figure 5): (1) template description including its purpose, references to the viewpoint-specific case description, relations to other templates, a short description of the syntax and elements; (2) definitions of the concepts used; (3) example of specification (for SE templates, examples were based on systems and regulations unrelated to the case, and in legal templates, examples were based on the GDPR or CRA); (4) specification task and form or figures with some basic information (e.g., UML component diagram figures) for the specification. Regulatory requirements template Finally, the AM4RRE content model also covers the concepts of different views used for the requirements specification itself. The non-tailored template for specification of regulatory requirements for compliance by design is as follows: should implement Target of regulation / control

involving control / matter of legal relation

for compliance with

under the threat of

sanction size

sanction article

legal subject(s)

The template follows the content model and resembles structured natural-language requirement patterns, extended with regulatory elements. The template should be tailored as described above. Tailoring allows for the inclusion of only the relevant information and the optimization of the specification process (e.g., if the prioritization of regulatory requirements based on potential sanctions is not required, specification of sanctions can be excluded using the goal-driven tailoring). The template tailored for a specific regulation is constructed from the SE concepts to which legal concepts were related during project-specific tailoring (T2). For example, a regulatory requirements template tailored for GDPR has the following structure: should implement involving for Component / control

compliance with

actions / control

under the threat of

GDPR article

stakeholder(s)

size of the sanction

The template was constructed from the concepts belonging to different viewpoints to address the essential regulatory RE challenges, such as capturing the relevant information across all four viewpoints, ensuring traceability of compliance implementation to software design specification, addressing compliance implementation in both existing and new software components, and allowing the initial prioritization using the information about sanctions.

13

Methodology overview Evaluation preparation

EP01: Participant profile forms development

Evaluation organization

EO01: Participants recruitment

(steps were recurring for each session)

EP02: Regulationspecific tailoring

EO02: Format and location selection 9 sessions: 6 onsite,1 hybrid, 2 online

40 recruited

EP03: Substitute for project-specific tailoring

EO03: Handouts distribution

EP04: Development of fictitious cases

EP05: Templates development

4 case descriptions PbD 4 case descriptions SbD

11 templates PbD 11 templates SbD

EO04: Group formation

EO05: Treatment sequence assignment

11 groups formed 1 group withdrawn

6 groups - GF 4 groups - FG

Feature analysis EE01: Introduction to workshop

EP06: Templates evaluation forms development 11 evaluation forms

EP07: Specification task development Task 1: 5 elements Task 2: 2 reqs. x 5 el.

EP08: AM4RRE evaluation form development 1 form

EE09: Completion of specification tasks in coordination (Quasi-experiment) 34 participants

EE04: Role and goal models application

EE02: Discussion of PbD/SbD approaches

EE03: Project context model application

15 indicated CbD method

37 completed

14 commented on roles 36 rated goals

EE07: Templates completion

EE08: Templates evaluation

39 participants completed

39 participants

GF treatment sequence (GP01, GP02, GP03, GP06, GS01, GS04)

14

Evaluation execution

EE05: Introduction to artifact-guided coordination

EE06: Cases introduction

Period 1: Completion of tasks introducing guided coordination Untimed

Period 1: Completion of Tasks 1-2 in coord. guided by AM4RRE templates

Period 2: Completion of Tasks 1-2 in freeform coord.

FG treatment sequence (GP04, GP05, GP07, GS02) Period 1: Completion of Tasks 1-2 in freeform coord.

Period 2: Completion of tasks introducing guided coordination Untimed

Period 2: Completion of Tasks 1-2 in coord. guided by AM4RRE templates

RQ4: analysis of specifications’ quality

RQ5: analysis of av. evaluations per criterion

RQ6: analysis of the av. evaluations per criterion

CC05-CC12

CC13-CC18

EE10: AM4RRE evaluation 37 participants (3 not in EE09)

Evaluation analysis (not executed in particular sequence)

RQ1: comparison of compon. application and spec. compl. time and quality

RQ2: proportion of completed and positively evaluated components

RQ3: analysis of the av. evaluations per criterion CC05-07,CC11,CC13-14

RQ3: in- and between-group analysis of specification time

RQ4: analysis of the av. evaluations per criterion CC01-CC04

Legend Steps related to both feature analysis and quasi-experiment

Steps primarily related to feature analysis

Steps primarily related to quasi-experiment

Sequence of step execution (not dependencies)

Fig. 6: Schematic visual overview of the methodology applied in the study.

5 Methodology We conducted this study to evaluate AM4RRE in systematically guiding practitioners in specifying and coordinating legal and SE viewpoints during regulatory RE for CbD. The following research questions guided our study: RQ1: To what extent can AM4RRE be applied in regulatory RE for privacy by design (PbD) according to GDPR and for security by design (SbD) according to CRA? RQ2: To what extent can practitioners apply AM4RRE in regulatory RE for CbD? RQ3: To what extent can AM4RRE support coordination among legal, managerial, RE, and software architecture viewpoints? RQ4: To what extent can AM4RRE support the quality of regulatory requirements? RQ5: To what extent can AM4RRE support the regulatory RE process? RQ6: To what extent can AM4RRE support achieving the goals of different viewpoints in regulatory RE? For the AM4RRE evaluation, we used a mixed-methods approach that combines feature analysis as the main data source [25] with a crossover quasi-experiment as an auxiliary source to complement the feature analysis results [52, 54]. To implement the feature analysis and quasi-experiment, we created fictitious cases focused on implementing PbD under GDPR and SbD under CRA. We simulated the work and role coordination from four viewpoints: legal, managerial, RE, and software architecture. For the feature analysis, each participant reviewed and applied project context, role, and goal models and completed viewpoint-specific AM4RRE templates to specify the information required for coordination, using the corresponding case descriptions. Based on this exposure to AM4RRE, participants individually evaluated the usefulness of viewpoint-specific templates using 9 criteria and, after the quasi-experiment, evaluated AM4RRE against 18 further criteria. In the two-period crossover quasi-experiment, we explored the use of completed AM4RRE-based templates as a treatment in guided coordination between roles (G), compared with free-form coordination without completed templates (F). We allocated 34 participants to ten groups. Each group completed the same requirements specification tasks twice, once in Period 1 (P1) and once in Period 2 (P2). They used completed AM4RRE-based templates after untimed introductory tasks (G) or case descriptions only (F). Groups followed two treatment sequences: G in P1 followed by F in P2 (GF treatment sequence), or F in P1 followed by G in P2 (FG treatment sequence). We analyzed specification time and the quality of specified regulatory requirements. We selected a quasi-experimental design because we could not randomly assign group composition or fully randomize treatment assignment due to the limited availability of legal experts and other participants. For several reasons, including the lack of systematic CbD methods for comparison and potential carry-over effects, our study aims not to infer causal relations but to examine the association between applying AM4RRE-based templates and the time and quality of regulatory requirements specification. Hence, the hypotheses and evaluation goals we formulate in this study are exploratory rather than confirmatory. We use feature analysis to answer RQ1-6, and the quasi-experiment as an additional data source to answer RQ1-4. We formulate the following exploratory evaluation goals for feature analysis and hypotheses for the quasi-experiment in connection with selected RQs requiring them. 15

Evaluation goal 1 (RQ2). Each template can be fully completed by more than 50% of participants using the guidance embedded within the templates. We assessed this goal by analyzing participants’ completed templates and evaluations. Evaluation goal 2 (RQ2). Participants can specify at least 50% of the elements assigned in specification tasks using AM4RRE-based templates. To assess this goal, we analyzed the specifications each group completed using AM4RRE-based templates. Hypothesis 1 for RQ3: Total specification time is shorter in the groups that use AM4RRE-guided coordination in Period 1 (GF sequence) than the total time in the groups that apply free-form coordination in Period
1 (FG sequence): TTotal,GF = TP1,guided + TP2,free < TTotal,FG = TP1,free + TP2,guided . We suggest that coordination guided by AM4RRE templates, when executed first, can be associated with a shorter total specification times. Hypothesis 2 (RQ3): The difference in specification time between Period 1 and Period 2 is larger in groups with FG treatment
sequence than in groups with GF
treatment sequence: ∆TFG = TP1,free − TP2,guided > ∆TGF = TP1,guided − TP2,free . Hypothesis 3 (RQ4): In each group, specification under coordination guided by AM4RRE templates is associated with higher specification completeness (Cm), consistency (Cn), and correctness (Cr) than specification under free-form coordination:


(CmP,guided > CmP,free ; (CnP,guided > CnP,free ; (CrP,guided > CrP,free . We report the steps of the methodology following its four phases: (1) evaluation materials preparation (EP), (2) evaluation organization (EO), (3) evaluation execution (EE), and (4) analysis of the evaluation results (EA). Figure 6 provides an overview of the methodology, and Table 1 presents the handout materials.

5.1 Evaluation materials preparation (EP) We report the development of the evaluation materials (see Table 1). EP01: Development of participant profile forms resulted in two handouts: FD, which collected data on participants’ organizations, positions, work experience, and use of regulatory RE methods for CbD; and FC01, which collected free-form descriptions of regulatory RE challenges known to practitioners. EP02: Regulation-specific tailoring was conducted by the first author using GDPR or CRA norms commonly examined in prior studies2 and resulted in five tailored content items of the AM4RRE legal artifact model (see Figure 4). EP03: Substitute for project-specific tailoring used the original AMDiRE artifact model to link SE concepts in six content items—two each from managerial, requirements, and architecture specifications—to legal concepts in five content items tailored in EP02, adding new SE concepts where needed. Next, we developed handouts for the remaining untailored AM4RRE models: a ranking of challenges for the project context model, role descriptions for the role model, and four goal model handouts. EP04: Development of fictitious cases produced four viewpoint-specific case descriptions per case with compliance concerns and minimal overlap (e.g., legal descriptions contained only norm excerpts). 2 We selected excerpts from GDPR articles 4(1),(2),(4),(7),(8),(11),(15); 6(1)(a); 8(1),(2); 9(1),(2); 13(1)(c),(f); 13(2)(b),(f); 15(1)(a),(b),(c),(h); 15(3); 83(4)(a); 83(5)(a),(b) and the following CRA norms recital (67), Article 3(1),(2),(10),(13),(14),(17),(23),(40); 13(1),(5); 20(4); Annex I (2)(d),(e),(g),(h).

16

ID

Name

Role(s)

Output of Input to

Handout Set I FD Demographic data Each role EP01 FC01 Form for spec. of challenges Each role EP01 Handout Set II FC02 Form for ranking challenges Each role EP03 FR Form with roles descriptions Each role EP03 GL Form with goals for legal role Legal EP03 GM Form with goals for managerial role Manager. EP03 GR Form with goals for RE role RE EP03 GA Form with goals for architect role Arch. EP03 Handout Set III CL_PB/SB Viewpoint-specific case description Legal EP04 CM_PB/SB Viewpoint-specific case description Manager. EP04 CR_PB/SB Viewpoint-specific case description RE EP04 CA_PB/SB Viewpoint-specific case description Arch. EP04 TAct_LP/LS Template for regulatory act spec. Legal EP05 TSubj_LP/LS Template for legal subject spec. Legal EP05 TRel_LP/LS Template for regulatory relations spec. Legal EP05 TObj_LP/LS Template for legal object spec. Legal EP05 TSanc_LP/LS Template for regulatory sanctions spec. Legal EP05 TScop_MP/MS Template for project scope spec. Manager. EP05 TStak_MP/MS Template for stakeholder model spec. Manager. EP05 TUsag_RP/RS Template for usage model spec. RE EP05 TData01_RP/RS Template for data model spec. RE EP05 TArch_AP/AS Template for archit. overview spec. Arch. EP05 TData02_AP/AS Template for data model spec. Arch. EP05 Handout Set IV SAct_LP/LS Eval. form for regulatory act TAct_ Legal EP06 SSubj_LP/LS Eval. form. for legal subject TSubj_ Legal EP06 SRel_LP/LS Eval. form. for legal relations TRel_ Legal EP06 SObj_LP/LS Eval. form. for legal object TObj_ Legal EP06 SSanc_LP/LS Eval. form. for legal sanctions TSanc_ Legal EP06 SScop_MP/MS Eval. form. for project scope TScop_ Manager. EP06 SStak_MP/MS Eval. form. for stakeh. model TStak_ Manager. EP06 SUsag_RP/RS Eval. form. for usage model TUsag_ RE EP06 SData01_RP/RS Eval. form. for data model TData01_ RE EP06 SArch_AP/AS Eval. form. for archit. overview TArch_ Arch. EP06 SData02_AP/AS Eval. form. for data model TData02_ Arch. EP06 Handout Set V (order depended on the assigned sequence of specification tasks execution) CF Tasks for free form coordination Jointly EP07 Handout Set VI (order depended on the assigned sequence of specification tasks execution) CG01_P/S Intro. tasks for guided coordination Jointly EP07 CG02 Tasks for guided coordination Jointly EP07 Handout Set VII EF Evaluation form Each role EP08 Total pages

Completion method

Pp.

EE01 EE03

Free text, option selection Free text

1 1

EE03 EE04 EE04 EE04 EE04 EE04

Ranking Free-text spec. Rating Rating Rating Rating

1 2 2 2 2 2

EE06 EE06 EE06 EE06 EE07 EE07 EE07 EE07 EE07 EE07 EE07 EE07 EE07 EE07 EE07

Not applicable Not applicable Not applicable Not applicable Guided text. Guided use case diagram Guided text. G. class diag., text highligh. Guided text. Guided text. Guided case diagram Guided text. Guided class diag. Guided component diag. Guided class diag.

1 1 1 1 1 2 1 3 1 1 2 2 1 2 1

EE08 EE08 EE08 EE08 EE08 EE08 EE08 EE08 EE08 EE08 EE08

Rating, free text eval. Rating, free text eval. Rating, free text eval. Rating, free text eval. Rating, free text eval. Rating, free text eval. Rating, free text eval. Rating, free text eval. Rating, free text eval. Rating, free text eval. Rating, free text eval.

1 2 1 3 1 1 2 2 1 2 1

EE09

Free text., requir. template

1

EE09 EE09

Free text. Free text., requir. template

1 1

EE10

Rating, free text.

1 55

Table 1: Overview of evaluation handouts. The ID suffix (e.g., _LP) encodes viewpoint (L - legal, M -manag., R - requir., A - archit.), and case (P - PbD, S - SbD). “Each role”–every role received the same handout; “Jointly”–joint completion by group participants. “Guided completion”–specification instructions were given.

EP05: Template development. Using the tailored artifact model, we developed one template for each of the 11 selected content items (Table 1), covering viewpointspecific information and information required by related items in the legal viewpoints. EP06: Development of template evaluation forms (feature analysis). Evaluation forms included example specifications and the following nine criteria for evaluation using a five-point Likert scale and space for comments: TC01 (RK in Table 6) capturing role-specific knowledge (e.g., legal knowledge); TC02 (Expl.) explicating and explaining the role-specific knowledge that is tacit; TC03 (Tran.) specifying information in a way transparent to other roles; TC04 (Comm.) specifying information to use specifications for communication; TC05 (Cm.) capturing all the required information; TC06 (Trac.) tracing the information between different roles and specifications; TC07 (Cn.) specifying information in a consistent way; TC08 (Eas.) ease of information specification; TC09 (Comp.) guiding specification by persons without role-specific knowledge / compensating for the absence of the role-specific knowledge. 17

During the quasi-experiment, we also substituted example specifications for completed templates when the corresponding role was absent from a group. EP07: Specification task development (quasi-experiment). Handouts for both guided (CG02 ) and free-form (CF ) coordination described two tasks: (1) specifying two existing regulated software components, two new system components or controls (e.g., processes) to implement compliance, and one relationship between existing and new components; and (2) specifying two regulatory requirements using the regulatory requirements template (Section 4). The guided-coordination handout (CG02) included requirement templates with placeholders; the free-form coordination handout included an example template and a free-text form to allow flexibility. For free-form coordination, we instructed participants to use only case descriptions, whereas during guided coordination, participants used their completed templates and consulted case descriptions as needed. To introduce AM4RRE-guided coordination and its templates, we developed five instructional tasks (CG01 ), distinct from the main tasks (see open dataset for their description). PbD and SbD handouts differed only in task descriptions and wording. EP08 Development of AM4RRE evaluation form (feature analysis). The form contained 18 criteria in three groups corresponding to the RQs they address. Requirements quality (Qual. in Table 7) (RQ4) CC01 (Cm. in Table 7) completeness of requirements deriving from GDPR / CRA; CC02 (Cn.1 ) consistency between requirements deriving from GDPR / CRA; CC03 (Cn.2 ) consistency between GDPR/CRA and other requirements; CC04 (Cr.) correctness of requirements deriving from GDPR / CRA. Regulatory RE process (RE ) (RQ3, RQ5) CC05 (Coord.) facilitating coordination for regulatory requirements specification; CC06 (LK ) capturing legal domain knowledge; CC07 (RK ) capturing other role-specific knowledge (business, requirements, etc.); CC08 (Comp.) in case of the absence of legal knowledge, compensation for the absence of it (guiding a non-specialist in specification); CC09 (Trac.) facilitate traceability between specifications and roles; CC10 (Cn3 ) facilitate consistency between roles (when coordinating); CC11 (Tran.) assure transparency of specifications to other roles; CC12 (Inter.) support interpretation of regulations. Achievement of role-specific goals (Goal ) (RQ3, RQ6) CC13 (SA) facilitating GDPR / CRA compliance in software architecture; CC14 (SDLC ) facilitating GDPR / CRA compliance throughout the SDLC; CC15 (Decis.) enabling decision-making about compliance; CC16 (Doc.) documenting the required information; CC17 (Gov.) facilitating compliance governance; CC18 (Bus.) addressing business concerns in CbD implementation. We used the following five-point Likert scale for rating goals (EP03 ), template evaluation (EP06 ), and AM4RRE evaluation (EP08 ): -2–not useful, -1–potentially not useful, 0–no assessment, +1–potentially useful, +2–useful.

18

5.2 Evaluation organization (EO) Next, we report participant recruitment, evaluation format, and organization. EO01: Participants recruitment using purposive sampling [3] gained 40 participants (28 in evaluation for PbD, 12 – in SbD) from 23 companies (see Table 2) with GDPR or CRA experience in SE to fill four roles: legal expert (9-PbD, 4-SbD), software architect (8-PbD, 4-SbD), requirements engineer (6-PbD, 3-SbD), and manager (5-PbD, 1-SbD). Eligibility required one year of GDPR or CRA experience, and we counted relevant training or regulatory exposure as fulfilling this requirement. Of the 40 participants, 37 completed the final AM4RRE evaluation3 . Of these 37, 34 completed the quasi-experiment in ten groups, as P15.L was not assigned to any group, and S7.3L and S8.3M did not complete tasks because two members of GS03 withdrew. EO02: Evaluation format and location. We held sessions on-site using printed handouts, except for GS01 and GS03, which were fully online via Zoom and used Zoom Whiteboard, and GP05, with P16.5L joining remotely and three participants attending on-site (we printed completed digital templates for on-site use and scanned completed paper templates to Zoom Whiteboard). EO03: Handouts distribution was organized in sets (see Table 1) to prevent bias from later materials (e.g., templates and forms with specification instances). EO04: Group formation (quasi-experiment) aimed to represent all four viewpoints per group, which we achieved in GP04-GP07. GP01 included two architects and no RE role, and GP07 included two legal experts. GP03, GS01, and GS02 lacked managerial roles. Managerial and RE roles were absent in GP02 and GS04. In these groups, specification instances from the evaluation forms replaced absent roles. Most groups participated in separate evaluation sessions. GP02, GP03, and GP04 worked in parallel during one shared evaluation session. EO05: Treatment sequence assignment (quasi-experiment). Each group completed the specification tasks under both coordination conditions: guided coordination (G) and free-form coordination (F). Each group followed either the GF or FG treatment sequence. To accommodate practitioners’ limited availability and avoid prolonged free-form coordination, we avoided the FG treatment sequence for groups with (1) missing roles, (2) no prior collaboration, (3) limited GDPR/CRA experience or (4) CbD knowledge, or (5) participants from small and medium organizations.

3 P3.1R, S9.3R, S10.3A withdrew due to unforeseen circumstances. We kept data from the activities they completed: for all three — known CbD methods, free-form challenge descriptions, challenge ranking, and goal ratings; for P3.1R — evaluation of one template; for S9.3R — evaluation of two RE templates.

19

Group

Org.

Org.

Wk.

Reg.

ID

Durat.

ID

Role

Format

Position

ID

Size

Industry

Exp.

Exp.

CbD

FA

QE

Handout

GP01 GP01 GP01 GP01 GP01

6h:25m

P1.1L P2.1M P3.1R P4.1A P5.1A

Legal expert Manager RE Software architect Software architect

Onsite Onsite Onsite Onsite Onsite

Product Security Lead Security consultant Business architecture analyst Product Security Engineer Information Security Architect

C1 C2 C3 C4 C5

>250 <10 >250 >250 >250

IT IT, Retail, Fin., Tel. IT Finances Healthcare

8 20 3 7 10

3 8 1 2 2

No No No No Yes

Yes Yes No Yes Yes

Yes Yes No Yes Yes

TObj_L

GP02 GP02

P6.2L P7.2A

Legal expert Software architect

Onsite Onsite

Privacy Operations Manager Product Security Engineer

C6 C6

>250 >250

IT IT

7 5

7 5

Yes No

Yes Yes

Yes Yes

-

GP03 GP03 GP03

P8.3L P9.3R P10.3A

Legal expert RE Software architect

Onsite Onsite Onsite

GRC Analyst Senior GRC Analyst Product Security Engineer

C6 C6 C6

>250 >250 >250

IT IT IT

3 4 2

1 3 2

No Yes No

Yes Yes Yes

Yes Yes Yes

-

P11.4L P12.4M P13.4R P14.4A

Legal expert Manager RE Software architect

Onsite Onsite Onsite Onsite

ISO System Manager Vice President Engineering Cybersecurity Analyst Senior Software Engineer

C6 C6 C6 C6

>250 >250 >250 >250

IT IT IT IT

9 6 4 10

7 7 1 1

No Yes No No

Yes Yes Yes Yes

Yes Yes Yes Yes

-

GP04 GP04 GP04 GP04

Part.

6h:40m

Addit

20

NA

P15.L

Legal expert

Onsite

GRC Analyst

C6

>250

IT

3

1

No

Yes

No

-

GP05 GP05 GP05 GP05

5h:45m

P16.5L P17.5M P18.5R P19.5A

Legal expert Manager RE Software architect

Online Onsite Onsite Onsite

Corp. Data Protection Manager Web Analyst Quality&Compliance manager IT architect

C7 C8 C9 C10

>250 50-249 <10 >250

Logistics Telecommunications Aerospace Automotive

10 9 3 10

10 5 1 9

NA No No Yes

Yes Yes Yes Yes

Yes Yes Yes Yes

-

GP06 GP06 GP06 GP06

5h:15m

P20.6L P21.6M P22.6R P23.6A

Legal expert Manager RE Software architect

Onsite Onsite Onsite Onsite

Privacy manager Technical manager IT Manager Cloud Security Architect

C11 C12 C13 C14

>250 50-249 >250 >250

Retail IT Automotive, IT, Fin. IT

7 10 20 3

7 1 6 5

No No No Yes

Yes Yes Yes Yes

Yes Yes Yes Yes

GL; TObj_L

GS01 GS01 GS01

6h:00m

S1.1L S2.1R S3.1A

Legal expert RE Software architect

Online Online Online

Lawyer External CIO Managing Software Architect

C15 C16 C17

<10 50-249 <10

NA Finances Automotive, IT

3-5 25 10

1 0 0.5

Yes Yes Yes

Yes Yes Yes

Yes Yes Yes

-

GS02 GS02 GS02

4h:10m

S4.2L S5.2R S6.2A

Legal expert RE Software architect

Onsite Onsite Onsite

Cybersecurity Professional Product manager Cyber Threat Intel. Expert

C18 C19 C20

NA >250 >250

Manufacturing Telecommunications Automotive

7 20 10

1 1 0.5

Yes No Yes

Yes Yes Yes

Yes Yes Yes

TObj_L -

GS03 GS03 GS03 GS03

4h:30m

S7.3L S8.3M S9.3R S10.3A

Legal expert Manager RE Software architect

Online Online Online Online

Information Security Officer Deputy CTO Security Head of Product Security Security compliance manager

C21 C21 C21 C21

>250 >250 >250 >250

IT, Finances IT, Finances IT, Finances IT, Finances

7 15 15 15

1 1.5 0.5 1

Yes Yes Yes No

Yes Yes Part. Part.

No No No No

-

GP07 GP07 GP07 GP07 GP07

5h:30m

P24.7L P25.7L P26.7M P27.7R P28.7A

Legal expert Legal expert Manager RE Software architect

Onsite Onsite Onsite Onsite Onsite

DPO Assoc. Gener. Counsel Solution Architect VP Product Development Head of Development Product manager

C6 C6 C6 C6 C6

>250 >250 >250 >250 >250

IT IT IT IT IT

25 14 20 12 4

7 1 6 1 1

No No No No No

Yes Yes Yes Yes Yes

Yes Yes Yes Yes Yes

GL; TObj_L

GS04 GS04

4h:40m

S11.4L S12.4A

Legal expert Software architect

Onsite Onsite

Data Protection Officer Solution Architect

C22 C23

>250 >250

IT IT

6 15

2 1

Yes No

Yes Yes

Yes Yes

-

Table 2: Data about participants and groups. Columns are as follows: (1) group ID with prefix indicating PbD (e.g., GP01) or SbD (e.g., GS01); (2) participant ID (e.g., P1.1L) in a format: case identifier, unique participant number (e.g., P1), group number, role/viewpoint identifier (L for legal, M–manager, R–RE, A–software architect); (3) the role the participant represented; (4) participation format, (5) the participant’s position; (6) company ID; (7) company size; (8) company industry; (9) experience in current or related position (years); (10) experience with GDPR or CRA ; (11) knowledge/use of method for PbD/SbD, (12) fully completed feature analysis, (12) fully completed quasi-experiment, (13) ID(s) of additionally filled-in handouts.

5.3 Evaluation execution (EE) The first author conducted nine evaluation sessions from October 2025 to March 2026, averaging 5h:26m (see Table 2). In addition to comments in handouts, we collected qualitative data by taking notes on observations, comments, and discussions between participants. We report each evaluation step with approximate duration. EE01: Introduction (5-10 min) covered the evaluation overview, completion of the demographics forms FD, and participant introductions. EE02: Recap and discussion of PbD/SbD approaches (10-15 min) covered the PbD/SbD methods known to or used by participants. EE03: Application of project context model (feature analysis) (15-20 min) included specifying the regulatory RE challenge in free form using FC01 and, after a joint discussion, ranking 12 predefined challenges using FC02. EE04: Role and goal models application (feature analysis) (15-20 min) involved reviewing the role model (FR handout), selecting a role, and rating all of its viewpoint-specific goals and second-level goals of other viewpoints. In GP01, only the goals of the assigned viewpoints were rated. Additionally, P7.2A, P23.6A, P28.7A, S6.2A rated the legal, and P20.6L - software architecture viewpoints goals. EE05: Introduction to artifact-guided coordination (10 min) by the session lead covered artifact-guided coordination, without the templates. EE06: Case introduction (10 min) using viewpoint-specific descriptions. EE07: Viewpoint-specific templates completion (feature analysis) (90120 min) was done in the assigned order using case descriptions. P5.1A, P23.6A, P28.7A, and S5.2R additionally completed the legal object template TObj_L. EE08: Templates evaluation (feature analysis) (30-40 min) involved participants reviewing specification instances, evaluating templates without changing completed templates, and returning evaluation forms upon completion. EE09: Completion of specification tasks in coordination (quasiexperiment) (40-80 min) required participants to use completed templates and case descriptions when necessary (e.g., the TObj template required highlighting concepts in the case description) for AM4RRE-guided coordination and case descriptions with any auxiliary materials for free-form coordination. Before each Period, groups had time to read, ask questions, or discuss the tasks. Task timing began and ended on participants’ explicit signals. Immediately before performing the guided coordination tasks, participants completed untimed tasks (CG01 ) introducing template-guided coordination. Specification instances from the evaluation handouts substituted for absent roles. The lead could introduce the instances or point to information in them in an ad hoc way, but only when questions were raised and without intervening in task completion. Groups with multiple completed templates per viewpoint (GP01, GP07) used all available specifications, each completed only by a participant in the corresponding role. In GP01, handouts provided only minimal guidance for organization (e.g., assigning someone to record results) and for introductory and specification tasks (CG01, CG02 ), with the session lead providing guidance ad hoc. This organizational guidance was also embedded in handouts for later groups. EE10: AM4RRE evaluation (10 min) (feature analysis). Participants evaluated AM4RRE as a whole against 18 criteria using handout EF. 21

5.4 Evaluation analysis (EA) To answer RQ1, we compared results for PbD and SbD cases: role model (free-form comments); goal model (goal ratings); AM4RRE evaluation (average evaluation per criterion); specification time; and requirements quality. For evaluations, a difference of 1 point or more (≥ 25%) was considered substantial. For RQ2, we used the following applicability criteria. We considered the project context model applicable if rankings were heterogeneous (low Kendall’s W) and participants confirmed model usefulness to capture heterogeneity. The role model – in the absence of substantially critical written comments. The goal model – if over 50% of all ratings were positive (+1 or +2), and over 50% of goals had an average rating above 0. And the templates – if over 50% of participants completed them fully, over 50% of evaluations across nine criteria were positive, and the average evaluation for each criterion was above 0. For the quasi-experiment, we considered AM4RRE applicable for specification if more than 50% of specification elements were completed. We chose the 50% threshold to ensure that at least one of the two regulatory requirements is available for evaluation. For RQ3-6, we analyzed the number of evaluations and average evaluations per criterion in feature analysis, focusing on outlier groups or participants. For RQ3, we analyzed the results across six criteria contributing to coordination (CC05-07, CC11, CC13-14 ). For RQ4-6, we focused on criteria for requirements quality (CC01-CC04), RE process (CC05-CC12), and viewpoint goals support (CC13-CC18), respectively. To answer RQ1-4, we also analyzed specification time and quality in the quasiexperiment by comparing outcomes between groups following the GF and FG treatment sequences, and between Period 1 and Period 2 within each group. We assessed specification quality for internal completeness (Task 2), consistency, and correctness of each element in Tasks 1 and 2 (see definitions in Section 2). Completely missing specification elements (separate elements in Task 1 and requirements in Task 2) were not assessed for quality and were reported for RQ2. We included any additional requirements or specification components in the quality assessment. For completeness, we assigned 0.2 for each of the five requirement element types, following the regulatory requirements template (see Section 4). For consistency, we assigned 1 for full agreement with the completed templates (guided) or the case descriptions (freeform), and 0.5 when the relevant component was present but specified inconsistently. For correctness, we assigned 1 if the element contributed to compliance implementation according to GDPR or CRA norms in the legal case description, and 0.5 if it was partially correct or if the specification concerned norms outside the scope of the case description. If participants used legal instead of SE concepts and these were consistent and correct, we assigned 0.5. Specification quality was assessed in two rounds involving independent referees: a legal expert with experience in both GDPR and CRA for correctness, and an undergraduate computer science student with privacy and security knowledge for consistency. First, the first author and referees used case descriptions, assessment rules reported above, completed templates, and requirements specifications to assess correctness independently (referee was blinded for coordination type) and consistency (not blinded). Afterward, we discussed and resolved disagreements to finalize the assessment. 22

6 Results Before presenting the results for each RQ, we summarize the regulatory RE or CbD methods and the challenges reported in the profile forms. State of practice and challenges. In FD, 15 of 40 participants reported using or knowing a regulatory RE approach for CbD (6 for PbD, 9 for SbD), with the most frequently mentioned threat modeling, data protection impact assessments, standards, and technical approaches (e.g., zero-trust architecture). While some approaches involved interaction between roles, none specifically focused on it. This suggests that approaches used or known to participants are unlikely to affect the quasi-experiment substantially. To analyze the 177 challenges to regulatory RE for CbD reported by 35 participants in the FC01 handout, we classified them into 12 challenge categories used for ranking challenges in the FC02 handout. Participants most often mentioned conflict with existing SE practices, compliance enforcement, interaction between experts, organizational challenges, and resource intensity (see Table 3).

6.1 RQ1: To what extent can AM4RRE be applied in regulatory RE for PbD and SbD? We compared goal ratings, template evaluation, and coordination results in PbD and SbD cases to assess AM4RRE applicability in both. Project context model (step EE03). The comparison of challenge rankings did not identify a substantial difference–the same four challenges appeared in the top five ranking positions, and agreement according to Kendall’s W was 0.15 in PbD and SbD. Role model (step EE04). Qualitative analysis of participants’ written comments did not identify a substantial difference between PbD and SbD evaluation sessions. SbD participants made 27 suggestions and PbD participants 21, although fewer people took part in SbD sessions. Goal models (step EE04). The proportion of positive ratings for different goal models differed by 4 to 7 percentage points (see Table 4). Average usefulness ratings (see open dataset) differed by at least one point between PbD and SbD for 18 of 74 goals across four viewpoints (24%). Eight of these were management-viewpoint goals, with only one participant in the SbD sessions. For 11 of the 18 goals, the average usefulness was positive, indicating agreement on their usefulness but to different degrees. For the remaining seven goals, the average rating either in PbD or SbD was 0 (no assessment). Only one of 74 goals (GR1.2) had a positive average rating in PbD, and a negative average rating in SbD evaluation, indicating considerable disagreement. Templates evaluation (step EE08). Of 99 average evaluations of 11 templates against nine evaluation criteria, 16 (16.16%) across eight templates differed by at least one point between PbD and SbD (see Table 6)—six of these concerned the managerialviewpoint templates, which were evaluated by only one participant assigned to the SbD case. From these 16, six had opposite signs in PbD and SbD, indicating considerable disagreement. Of 198 total average evaluations, one average evaluation had opposite signs, but differed by less than 1 point. 23

Ch. Challenge ID Name Ch01 Abstractness regulations

Challenge Ment A.rk. S.rk. Example FC01 FC02 FC02 "lack of clear rules 7 5.46 202 on what to implement exactly (S11.4L)"

Ch02

"balance it out out with all other requirements (S3.1A)" "team only knows one part not end-to-end (P16.5L)"

41

6.03

217

16

4.95

183

"a big amount of new features and how to cover all of it (P1.1L)"

14

6.22

230

"teams working in silos (P23.6A)"

21

5.32

197

"Make estimations regarding time, costs, quality (magic triangle) or avoid them (S3.1A)"

17

5.14

185

NA

NA

9.32

345

28

6.97

251

3

6.69

234

5

7.81

289

5

7.44

268

20

5.92

213

Ch03

Ch04

Ch05

Ch06

Ch07

Ch08

Challenge Description of Regulations are often too abstract to be directly applicable in SE and therefore require interpretation and translation into concrete software requirements. Conflicts/changes Regulations may directly or indirectly conflict to existing SE with existing software engineering practices or practices necessitate changes to them. Demand for knowl- Implementing regulations requires legal domain edge/expertise knowledge to translate regulatory texts; additionally, SE expertise, business domain knowledge, and privacy and security expertise are required for compliance implementation. Complexity of reg- The implementation of regulatory compliance is ulations processing complex, primarily due to the inherent comand implementa- plexity of the regulations themselves and the tion complexity of modern software systems. Interaction Implementing regulatory compliance is interdisbetween different ciplinary and requires interaction among experts experts from various domains (e.g., law or compliance, software technology, business, privacy, and security). These experts are also highly interdependent. Resource intensity Ensuring regulatory compliance in software sysof processing and tems can require significant financial, techniimplementation of cal, human, time, and other resources. These regulations resources are needed not only for processing regulations and implementing technical solutions but also for auxiliary activities such as documentation and audits. Provability chal- Implementation of regulatory compliance must lenges always be supported by evidence such as documentation. Producing such evidence is difficult due to the complexity of the required information and the multiplicity of sources that must be considered. Enforcement chal- It is often challenging to ensure that regulations lenges are implemented as intended (e.g., ensuring that engineers follow the required processes).

Ch09 Dynamics of software context and regulations Ch10 Multiplicity of regulations Ch11 Dynamics of software systems Ch12 Organizational challenges

"Some changes don’t go through the change management procedures (S7.3L)" Both regulations and the business domains of "unstable nature of software systems can change rapidly, creating project goals (P16.5L)" multiple barriers to maintaining compliance. Multiple regulations often need to be complied "[s]ame feature must with simultaneously within the same software comply with different system. regulations (P24.7L)" Software systems can evolve rapidly, especially "continuous changes in agile software development environments or in (P17.5M)" the case of AI-based systems, dynamic in nature. Regulatory compliance in software systems "lack of structural requires changes in both the organization of soft- approach to PbD (4) ware development and the overall organizational (P6.2L)" structure (e.g., planning, strategy).

Table 3: Overview of challenges to regulatory RE mentioned in free-form in FC01 and ranked in FC02 (in the order presented to participants in FC02). Columns: challenge ID, name, description, example of challenge from FC01, number of mentions in FC01, average ranking in FC02, sum of ranks in FC02.

AM4RRE evaluation (step EE10). The total average evaluation of AM4RRE was 0.21 lower in SbD (1.02) than in PbD (1.23) (see Table 7). In none of the average per-criterion evaluations was the difference between PbD and SbD 1 or higher. Specification time and requirements quality (EE09). The analysis of specification time and quality (see Table 8) indicated no considerable differences between PbD and SbD cases. Summary. Application results and feedback on the project context, role, and goal models indicated no substantial differences between PbD and SbD contexts. Template evaluations were mixed across cases, and AM4RRE evaluations were lower in the SbD case. The differences reflected disagreement about the degree of usefulness, while the overall evaluation was positive. These findings provide preliminary evidence that AM4RRE is useful in both PbD and SbD sessions. 24

6.2 RQ2: To what extent can practitioners apply AM4RRE in regulatory RE for CbD? We report our analysis and observations on applying the project context, role, and goal models, and AM4RRE-based templates. Project context model (step EE03). Of 37 participants who ranked the challenges4 , 32 provided complete rankings; two omitted at least one rank, and four assigned duplicate ranks. Based on average and summed ranks, the top-ranked challenges were abstractness of regulations, demand for domain knowledge, expert interaction, resource intensity, and organizational challenges (see Table 3). However, average ranks ranged from 4.95 to 9.32, and Kendall’s W was 0.12, indicating differences in prioritization. Further analysis of average ranks by participant group (roles, company affiliation) also showed no clearly dominant challenges; however, RE roles showed higher agreement (Kendall’s W = 0.39) than managerial roles (0.23), architect roles (0.18), and legal roles (0.13). In a written comment, P16.5L suggested that challenge rankings strongly depend on company size, sector, culture, and other context factors. Oral comments from some participants (e.g., in groups GP02, GP03, and GP04) suggested that the ranking of challenges could contribute to better mutual understanding and prioritization of challenges across roles when discussed collectively. Role model (step EE04). Participants suggested 48 changes to the role models: 18 for requirements engineers, 13 for software architects, nine for legal experts, and eight for managerial roles. Suggestions primarily focused on additional role-specific knowledge, such as risk management (managerial role); cross-domain and technical knowledge (requirements engineer); and product and business knowledge (software architect role). Suggestions regarding role skills included, for example, communication and strong critical thinking (legal expert); communication and prioritization (requirements engineer); and basic compliance review (managerial role). According to P20.6L, legal experts need a basic understanding of the business domain and only consult and validate, rather than ensure compliance. ID GL PbD GL SbD GM PbD GM SbD GR PbD GR SbD GA PbD GA SbD Total

Viewpoint

Viewp. Goals

Other Goals

Legal

21

11

Manag.

19

11

RE

23

12

Archit.

12

14

-

74

-

Part. 10 5 5 1 5 3 7 4 36

Total Rates 271 158 129 29 153 101 139 102 1082

-2 5 2 3 0 6 1 4 0 21

Ratings count -1 0 +1 +2 13 19 89 145 13 13 62 68 10 13 41 62 0 7 12 10 10 11 51 75 5 16 26 53 6 19 50 60 4 10 47 41 61 108 378 514

Posit. 86.35% 82.28% 79.84% 75.86% 82.35% 78.22% 79.12% 86.27% -

Total Posit. 84.85% 79.11% 80.71% 82.16% 82.44%

Table 4: Summary of the goals rating: goal model and case, viewpoint, number of viewpointspecific goals, number of second-level goals of other viewpoints, number of participants who completed rating, number of ratings per evaluation scale.

Goal model (step EE04). Of all goal ratings (see Table 4), 82.44% were positive on average. Of the 74 rated goals in four viewpoints, one had a negative average 4

Including P3.1R, S9.3R, S10.3A

25

(GA2.2–isolation from business logic), and three had an average of 0–no assessment (GM4.5–ability to choose between compliance solutions, and GR1.2–traceability to the origin, GR2.5–assuring development team autonomy). For the remaining goals, the average rating was above zero. Participants’ oral comments indicated that nearly all goals seemed useful but would need prioritizing in practice. Templates (EE07-EE08). Of the 11 templates, five were fully completed by all participants (TRel_L, TScop_M, TUsag_R, TData01_R, TData02_A), and five by 67% to 92% of them. TObj_L was the only template that was completed by fewer than 50% of participants–41.18% of participants completed it fully and 41.18% completed it partially. Templ. ID TAct_L TSubj_L TRel_L TObj_L TSanc_L TScop_M TStak_M TUsag_R TData01_R TArch_A TData02_A

Templ. Name Regulatory act spec. templ. Legal subject spec. templ. Regulatory relations spec. templ. Legal object spec. templ. Regulatory sanctions spec. templ. Project scope spec. templ. Stakeholder model spec. templ. Usage model spec. templ. Data model spec. templ. Architecture overview spec. templ. Data model spec. templ.

Partic. Viewp. Legal Legal Legal Legal Legal Manager. Manager. RE Requirem. Architect. Architect.

Total

Total number 12 12 12 17 12 6 6 9 8 11 10

Eval. 105 105 106 150 104 52 53 80 71 97 88

-2 6 1 0 14 3 4 0 0 2 0 5

1011

35

Evaluations number -1 0 +1 +2 10 14 37 38 5 29 30 40 12 12 30 52 23 38 47 28 5 16 29 51 5 13 21 9 9 10 18 16 2 12 31 35 2 14 23 30 6 16 49 26 3 12 34 34 82

186

349

359

Posit. 71.43% 66.70% 77.36% 50.00% 76.92% 57.69% 64.15% 82.50% 74.65% 77.32% 77.27% 70.03%

Table 5: Summary of template evaluation From a total of 1011 evaluations of templates by 39 participants, according to one of the 9 criteria (see Table 5), 70.03% of evaluations were positive (min 50.00% for TObj_L and max 82.50% for TUsag_R). Of all evaluations 35 evaluations (3.46%) identified templates as “not useful” (-2) (min 0% for TRel_L, max 9.33% for TObj_L), 82 evaluations (8.11%) were “potentially not useful” (-1) (min 2.50% for TUsag_R, max 16.98% for TStak_M ), 186 evaluations (18.40%) were “no assessment” (0) (min 11.32% for TRel_L, max 27.62% for TSubj_L), 349 evaluations (34.52%) were “potentially useful” (+1) (min 27.88% for TSanc_L, max 50.52% for TArch_A) and 359 evaluations (35.51%) were “useful” (min 17.31% for TScop_M, max 49.06% for TRel_L). Of 99 template-by-criterion average evaluations (see Table 6), only two were negative (ease of specification of TObj, traceability of TScop), three were 0 (for role knowledge explication of TStak, capturing role knowledge and completeness of TScop); the remaining 94 evaluations were above 0, and 41 were above +1. Positive evaluation was also supported by some of the written comments (see below): “It is a good overview without security assessment. It can be used as a basis for discussion with other stakeholders.” - P5.1A on TArch_AP.

Participants’ written comments concerned unsuitable specification syntax (for TArch_AP ) and format (TData02_AP ), potentially high complexity (TSubj_LP, TRel_LP ), or limited readability of specifications (TStak_MP ). Others suggested that specifications need more flexibility (TSubj_LP ), that the resulting specifications can be too high-level (TStak_MP, TScop_MP ), or that they require additional detail (TStak_MP, TArch_AS ). Most participants completed the templates using 26

Templ. ID TAct_L TAct_LP TAct_LS TAct_L TSubj_L TSubj_LP TSubj_LS TSubj_L TRel_L TRel_LP TRel_LS TRel_L TObj_L TObj_LP TObj_LS TObj_L TSanc_L TSanc_LP TSanc_LS TSanc_L TScop_M TScop_MP TScop_MS TScop_M TStak_M TStak_MP TStak_MS TStak_M TUsag_R TUsag_RP TUsag_RS TUsag_R TData01_R TData01_RP TData01_RS TData01_R TArch_A TArch_AP TArch_AS TArch_A TData02_A TData02_AP TData02_AS TData02_A

Summary Total Avg. PbD Avg. SbD Avg. PbD-SbD Diff. Total Avg. PbD Avg. SbD Avg. PbD-SbD Diff. Total Avg. PbD Avg. SbD Avg. PbD-SbD Diff. Total Avg. PbD Avg. SbD Avg. PbD-SbD Diff. Total Avg. PbD Avg. SbD Avg. PbD-SbD Diff. Total Avg. PbD Avg. SbD Avg. PbD-SbD Diff. Total Avg. PbD Avg. SbD Avg. PbD-SbD Diff. Total Avg. PbD Avg. SbD Avg. PbD-SbD Diff. Total Avg. PbD Avg. SbD Avg. PbD-SbD Diff. Total Avg. PbD Avg. SbD Avg. PbD-SbD Diff. Total Avg. PbD Avg. SbD Avg. PbD-SbD Diff.

FC 8 4 4

PC 1 1 0

NC 3 3 0

9 5 4 13 9 4 7 4 3 12 8 4 6 5 1 5 5 0 8 5 3 8 5 3 10 7 3 11 8 3 -

4 4 0 0 0 0 7 6 1 0 0 0 0 0 0 1 0 1 0 0 0 0 0 0 1 1 0 0 0 0 -

0 0 0 0 0 0 3 2 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 -

TC01 RK +0.50 +0.38 +0.75 |0.38| +1.00 +0.88 +1.25 |0.38| +1.58 +1.50 +1.75 |0.25| +0.76 +1.00 +0.20 |0.80| +1.42 +1.50 +1.25 |0.25| 0.00 0.00 0.00 0.00 +0.50 +0.20 +2.00 |1.80| +1.67 +1.50 +2.00 |0.50| +1.63 +1.60 +1.67 |0.07| +1.55 +1.75 +1.00 |0.75| +1.80 +1.86 +1.67 |0.19|

TC02 Expl. +0.92 +0.88 +1.00 |0.13| +1.08 +0.88 +1.50 |0.63| +1.64 +1.43 +2.00 |0.57| +0.59 +0.83 0.00 |0.83| +1.20 +1.67 +0.50 |1.17| +0.50 +0.80 -1.00 |1.80| 0.00 0.00 0.00 |0.00| +1.11 +1.00 +1.33 |0.33| +1.38 +1.40 +1.33 |0.07| +1.20 +1.14 +1.33 |0.19| +1.10 +1.00 +1.33 |0.33|

TC03 Tran. +1.27 +1.38 +1.00 |0.38| +1.33 +1.38 +1.25 |0.13| +1.50 +1.38 +1.75 |0.38| +0.41 +0.58 0.00 |0.58| +1.50 +1.50 +1.50 0.00 +1.17 +1.40 0.00 |1.40| +1.50 +1.60 +1.00 |0.60| +1.89 +1.83 +2.00 |0.17| +1.71 +1.60 +2.00 |0.40| +1.18 +1.13 +1.33 |0.21| +0.70 +0.43 +1.33 |0.90|

TC04 Comm. +0.83 +0.88 +0.75 |0.13| +1.09 +1.25 +0.67 |0.58| +1.42 +1.13 +2.00 |0.88| +0.47 +0.33 +0.80 |0.47| +1.42 +1.25 +1.75 |0.50| +1.17 +1.60 -1.00 |2.60| +1.33 +1.40 +1.00 |0.40| +1.33 +1.50 +1.00 |0.50| +1.13 +1.20 +1.00 |0.20| +0.82 +0.63 +1.33 |0.71| +0.70 +0.57 +1.00 |0.43|

TC05 Cm. +0.75 +0.75 +0.75 0.00 +0.50 +0.25 +1.00 |0.75| +1.00 +0.88 +1.25 |0.38| +0.33 +0.64 -0.50 |1.14| +0.64 +0.63 +0.67 |0.04| 0.00 -0.20 +1.00 |1.20| +0.67 +0.60 +1.00 |0.40| +0.89 +1.00 +0.67 |0.33| +0.63 +1.20 -0.33 |1.53| +0.36 +0.38 +0.33 |0.04| +1.13 +1.00 +1.33 |0.33|

TC06 Trac. +0.67 +0.75 +0.50 |0.25| +1.00 +0.88 +1.25 |0.38| +1.25 +1.13 +1.50 |0.38| +0.29 +0.50 -0.20 |0.70| +0.92 +1.00 +0.75 |0.25| -0.20 -0.25 0.00 |0.25| +0.83 +0.80 +1.00 |0.20| +0.67 +0.83 +0.33 |0.50| +0.25 +1.00 -1.00 |2.00| +0.91 +0.88 +1.00 |0.13| +0.70 +0.86 +0.33 |0.52|

TC07 Cn. +1.17 +1.25 +1.00 |0.25| +1.00 +0.75 +1.50 |0.75| +0.83 +0.75 +1.00 |0.25| +0.24 +0.33 0.00 |0.33| +1.00 +1.00 +1.00 0.00 +0.50 +0.60 0.00 |0.60| +1.00 +1.00 +1.00 |0.00| +1.11 +1.17 +1.00 |0.17| +1.00 +1.60 0.00 |1.60| +1.20 +1.00 +1.67 |0.67| +1.30 +1.00 +2.00 |1.00|

TC08 Eas. +1.00 +0.63 +1.75 |1.13| +0.75 +0.25 +1.75 |1.50| +0.36 +0.25 +0.67 |0.42| -0.35 -0.08 -1.00 |0.92| +1.42 +1.25 +1.75 |0.50| +0.50 +0.40 +1.00 |0.60| +0.33 +0.40 0.00 |0.40| +1.33 +1.17 +1.67 |0.50| +1.00 +1.00 +1.00 |0.00| +0.91 +0.75 +1.33 |0.58| +1.20 +1.00 +1.67 |0.67|

TC09 Comp. +0.70 +0.43 +1.33 |0.90| +1.10 +0.67 +1.75 |1.08| +0.75 +0.63 +1.00 |0.38| +0.38 +0.18 +0.80 |0.62| +0.82 +0.71 +1.00 |0.29| +0.80 +0.75 +1.00 |0.25| +0.80 +1.00 0.00 |1.00| +1.13 +1.00 +1.33 |0.33| +1.13 +1.00 +1.33 |0.33| +0.73 +0.50 +1.33 |0.83| +0.50 +0.14 +1.33 |1.19|

Table 6: Number of fully completed templates (FC), partially completed (PC), noncompleted (NC) templates and average evaluation of each of 11 templates as per (1) PbD evaluation, (2) SbD evaluation, (3) difference between average evaluation in PbD and SbD evaluation (absolute value), and (4) both PbD and SbD evaluation. For color coding see Table 7.

only the embedded instruction; however, some participants in the legal role (e.g., P6.2L, P20.6L) initially struggled with the idea of completing templates using only regulatory norms and without software project-specific information. “This is a little too complex [..]. As a model, it can be useful, but only after the different subjects have been identified, as it can “focus” on one specific role and illustrate the relationships around it.” - P24.7L on TRel_LP.

The legal object specification template (TObj_L) was particularly challenging for participants to complete. Of 17 participants, 7 completed it fully (highlighting and modeling concepts), 7 partially (only one of the two), and three not at all. Written comments suggest that some participants understood the template’s purpose better after completing it. “Makes sense after the fact, very hard to wrap the mind around to create from text method feels “off ” ”. - P16.5L regarding TObj_LP.

27

“Now I understand. It’s just about reading and identifying the various meanings. Not sure this is really useful, but maybe. I am afraid that making it into a scheme would lose meaning and nuance.” - P24.7L TObj_LP.

Of the four participants additionally assigned TObj_L, P5.1A highlighted concepts and added elements, P23.6A only highlighted concepts, P28.7A annotated concepts to a limited degree due to colorblindness, and S5.2R completed neither task. S5.2R and P23.6A evaluated the template mainly negatively; P23.6A’s written comment stated that the template lacks anything specific to the architecture role. P5.1A and P28.7A evaluated the template mainly positively, with P5.1A pointing to the need for additional training (see quotation below). “You need practice to find and differentiate between control, criterion, and target of regulation.” - P5.1A about TObj_LP.

AM4RRE (EE09-EE10). When discussing AM4RRE applicability from the legal perspective, P16.5L mentioned that it reminded them of their daily work and P24.7L directly confirmed its compatibility with existing practice. Session lead: - Can you imagine that this approach could be used in your company? P24.7L: - We did something like this, but in a less structured way.

In the quasi-experiment, under guided coordination, GP06 omitted three, GP07 five, and GS02 one of five specification elements in Task 1, but specified all 10 requirement elements in Task 2, corresponding to 80%, 67%, and 93% completion. The remaining groups specified all required elements. In free-form coordination, GP01 omitted two elements, GP07 one, and GS01 completely omitted one requirement in Task 2. Based on observations, participants discussed but did not finish specifications for unclear reasons. Several groups specified more than the tasks required. In Task 1, nine additional elements were specified in five free-form periods and eight in four guided periods. In Task 2, guided periods produced 24 requirements in total (GP02 and GP03 each specified one extra requirement and GP04 two), and free-form periods produced 20 (GP03 specified one extra, and GS01 omitted one) (see the open dataset). Evaluation goal 1 was partially met as 10 of 11 templates, except for TObj_L, were completed by more than 50% of participants and got more than 50% of positive evaluations; for 8 templates, except for TObj_L, TScop_M, and TStak_M, all average evaluations across nine criteria were above 0. Evaluation goal 2 was achieved with all ten groups specifying more than 50% of the required elements under guided coordination. RQ2: The results indicate that participants applied most AM4RRE components: the project context model was useful for capturing heterogeneous opinions about challenges; the role model received only minor change suggestions; and 70 of 74 goals in the goal model received an average rating above zero, and, on average, 82.44% of all given rates were positive.

28

29

Part. ID P1.1L P2.1M P3.1R P4.1A P5.1A GP01 Av P6.2L P7.2A GP02 Av P8.3L P9.3R P10.3A GP03 Av P11.4L P12.4M P13.4R P14.4A GP04 Av P15.L P16.5L P17.5M P18.5R P19.5A GP05 Av P20.6L P21.6M P22.6R P23.6A GP06 Av P24.7L P25.7L P26.7M P27.7R P28.7A GP07 Av S1.1L S2.1R S3.1A GS01 Av S4.2L S5.2R S6.2A GS02 Av S7.3L S8.3M S9.3R S10.3A GS03 Av S11.4L S12.4A GS04 Av

Part. Qual. CC01 CC02 CC03 CC04 RE CC05 CC06 CC07 CC08 CC09 CC10 CC11 CC12 Goal. CC13 CC14 CC15 CC16 CC17 CC18 Av Av Cm. Cn.1 Cn.2 Cr. Av Coord. LK RK Comp. Trac. Cn3. Tran. Inter. Av SA SE Dec. Doc. Gov. Bus. +0.94 +0.5 +1 0 0 +1 +1.25 +2 +1 0 +1 +2 +1 +1 +2 +0.80 +1 -1 +2 +1 NA +1 +1.11 +1.5 +2 +2 +1 +1 +1 +1 +2 +1 0 +1 +1 +1 +1 +1 +1 +1 +1 +1 +1 +1 NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA +1.06 +1.25 +1 +2 +1 +1 +1.13 +1 +1 +1 +1 +1 +1 +2 +1 +0.83 +1 0 +1 +1 +1 +1 +1.28 +1 +1 +1 +1 +1 +1.13 +2 +1 +1 +1 +1 +1 +1 +1 +1.67 +2 +2 +2 +1 +1 +2 +1.10 +1.06 +1.25 +1.25 +0.75 +1.00 +1.13 +1.50 +1.25 +0.75 +0.75 +1.25 +1.00 +1.25 +1.25 +1.08 +1.25 +0.50 +1.50 +1.00 +1.00 +1.25 +1.83 +2 +2 +2 +2 +2 +2 +2 +2 +2 +2 +2 +2 +2 +2 +1.5 +1 +1 +2 +2 +2 +1 +1.72 +2 +2 +2 +2 +2 +1.5 +2 +2 +2 +2 +1 +1 0 +2 +1.83 +2 +1 +2 +2 +2 +2 +1.78 +2.00 +2.00 +2.00 +2.00 +2.00 +1.75 +2.00 +2.00 +2.00 +2.00 +1.50 +1.50 +1.00 +2.00 +1.67 +1.50 +1.00 +2.00 +2.00 +2.00 +1.50 +1.67 +1.75 +2 +2 +1 +2 +1.38 +1 +2 +1 +2 0 +1 +2 +2 +2 +2 +2 +2 +2 +2 +2 +1.72 +1.75 +2 +2 +1 +2 +1.75 +2 +2 +2 +2 +1 +1 +2 +2 +1.67 +1 +1 +2 +2 +2 +2 +1.61 +2 +2 +2 +2 +2 +1.5 +2 +2 +2 +1 +1 +1 +2 +1 +1.5 +1 +1 +2 +1 +2 +2 +1.67 +1.83 +2.00 +2.00 +1.33 +2.00 +1.54 +1.67 +2.00 +1.67 +1.67 +0.67 +1.00 +2.00 +1.67 +1.72 +1.33 +1.33 +2.00 +1.67 +2.00 +2.00 +0.94 +1 +1 +1 +1 +1 +1 +1 0 0 +1 +2 +2 +1 +1 +0.83 +1 +1 0 +1 +1 +1 +0.72 +0.5 +1 +1 0 0 +0.88 +2 +1 +1 +1 +1 0 +1 0 +0.67 +1 0 +1 +1 +1 0 +1.67 +2 +2 +2 +2 +2 +1.5 +2 +2 +1 +2 +1 +1 +1 +2 +1.67 0 +2 +2 +2 +2 +2 +1.5 +2 +2 +2 +2 +2 +1.25 +2 0 +2 0 +1 +1 +2 +2 +1.5 +2 0 +1 +2 +2 +2 +1.21 +1.38 +1.50 +1.50 +1.25 +1.25 +1.16 +1.75 +0.75 +1.00 +1.00 +1.25 +1.00 +1.25 +1.25 +1.17 +1.00 +0.75 +1.00 +1.50 +1.50 +1.25 +1.65 +2 +2 +2 +2 +2 +1.14 +2 NA +1 0 0 +1 +2 +2 +2 +2 +2 +2 +2 +2 +2 +1.06 +1.25 +1 +2 +1 +1 +0.75 +1 +1 +1 0 +2 +1 +1 -1 +1.33 +1 +1 +2 +2 0 +2 +1.33 +0.75 0 +1 +1 +1 +1.63 +2 +2 +2 +1 +1 +1 +2 +2 +1.33 0 +1 +2 +1 +2 +2 +1.06 +1.25 +1 +1 +1 +2 +1.14 0 NA +1 +1 +2 +1 +2 +1 +0.83 +1 +1 +1 0 +1 +1 +0.89 +0.75 0 +1 +1 +1 +1 +2 +1 +1 -1 +2 +1 +1 +1 +0.83 +1 +1 +1 +1 +1 0 +1.08 +1.00 +0.50 +1.25 +1.00 +1.25 +1.13 +1.25 +1.33 +1.25 +0.25 +1.75 +1.00 +1.50 +0.75 +1.08 +0.75 +1.00 +1.50 +1.00 +1.00 +1.25 +0.39 +0.25 +1 0 -1 +1 0 +1 -1 0 -1 0 0 +1 0 +1 +1 0 +1 +2 +1 +1 +1.71 +2 +2 +2 +2 +2 +1.71 +2 +2 +2 NA +1 +1 +2 +2 +1.5 +2 +1 +1 +2 +2 +1 +1.22 +0.75 +1 0 +1 +1 +1.38 +1 +2 +1 +1 +2 +1 +2 +1 +1.33 +1 +1 +1 +2 +1 +2 -0.39 +0.5 +1 0 0 +1 -0.5 -2 +1 -2 -2 -1 +1 -1 +2 -0.83 +1 0 -1 -2 -2 -1 +0.73 +0.88 +1.25 +0.50 +0.50 +1.25 +0.65 +0.50 +1.00 +0.25 -0.67 +0.50 +0.75 +1.00 +1.25 +0.75 +1.25 +0.50 +0.50 +1.00 +0.50 +0.75 +1.17 +1 +1 +1 +1 +1 +1.25 +2 +1 +1 +1 +1 +1 +2 +1 +1.17 +1 +1 +1 +1 +2 +1 +1.06 +1 +1 +1 0 +2 +1.25 +2 +2 0 +1 +1 +1 +1 +2 +0.83 0 +1 +1 +2 +1 0 +1.67 +1.5 +2 +2 +1 +1 +1.63 +1 +2 +2 +2 0 +2 +2 +2 +1.83 +2 +2 +1 +2 +2 +2 +1.28 +2 +2 +2 +2 +2 +1.75 +2 +1 +2 +1 +2 +2 +2 +2 +0.17 +1 0 0 0 0 0 +1.22 +2 +2 +2 +2 +2 +0.63 +2 +1 +1 0 0 +1 0 0 +1.5 +2 +1 +2 +1 +1 +2 +1.28 +1.50 +1.60 +1.60 +1.20 +1.60 +1.30 +1.80 +1.40 +1.20 +1.00 +0.80 +1.40 +1.40 +1.40 +1.10 +1.20 +1.00 +1.00 +1.20 +1.20 +1.00 +0.44 0 -1 +1 +1 -1 +1 +1 +1 +1 +1 +1 +1 +1 +1 0 +1 -1 -1 +1 +1 -1 0 +0.25 0 +1 0 0 0 -1 -1 0 -1 +1 +1 +1 0 -0.17 0 0 -1 +1 0 -1 +1.44 +1.75 +2 +2 +1 +2 +1.25 +2 +1 +1 0 +2 +1 +2 +1 +1.5 +1 +2 +1 +2 +2 +1 +0.63 +0.67 +0.33 +1.33 +0.67 +0.33 +0.75 +0.67 +0.33 +0.67 0 +1.33 +1.00 +1.33 +0.67 +0.44 +0.67 +0.33 -0.33 +1.33 +1.00 -0.33 +1.06 +1.5 +2 +1 +1 +2 +0.43 +1 NA +1 +1 -1 -1 +1 +1 +1.60 +1 +2 +2 +2 NA +1 +0.88 +0.75 +1 0 +1 +1 +0.71 0 +2 +1 NA 0 +1 +1 0 +1.17 +1 +1 +2 +2 0 +1 +1.33 +1 +1 +1 0 +2 +1 +2 +1 +2 0 +1 +1 +1 0 +2 +2 +2 +2 +2 +2 +2 +1.09 +1.08 +1.33 +0.67 +0.67 +1.67 +0.71 +1.00 +1.50 +1.33 +0.50 0 +0.33 +1.00 +0.33 +1.59 +1.33 +1.67 +2.00 +2.00 +1.00 +1.33 +1.11 +1 0 +1 +1 +2 +1 +1 +1 +2 +1 0 +1 +1 +1 +1.33 +2 +1 +1 +1 +2 +1 +0.83 +0.5 0 0 +1 +1 +0.88 +1 0 +1 0 +1 +1 +2 +1 +1 +2 +1 0 0 +1 +2 NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA +0.97 +0.75 0 +0.50 +1.00 +1.50 +0.94 +1.00 +0.50 +1.50 +0.50 +0.50 +1.00 +1.50 +1.00 +1.17 +2.00 +1.00 +0.50 +0.50 +1.50 +1.50 +1.39 +0.75 +2 -1 +1 +1 +1.63 +2 +1 +2 +1 +2 +2 +2 +1 +1.5 +2 +1 +2 +2 +2 0 +1.67 +1.75 +1 +2 +2 +2 +1.63 +2 +1 +2 +1 +1 +2 +2 +2 +1.67 +2 +2 +2 +1 +2 +1 +1.53 +1.25 +1.50 +0.50 +1.50 +1.50 +1.63 +2.00 +1.00 +2.00 +1.00 +1.50 +2.00 +2.00 +1.50 +1.58 +2.00 +1.50 +2.00 +1.50 +2.00 +0.50

Total Av PbD Av SbD Av Diff.

+1.17 +1.23 +1.24 +1.24 +1.05 +1.38 +1.12 +1.38 +1.18 +1.14 +0.69 +0.97 +1.05 +1.38 +1.19 +1.19 +1.24 +0.95 +1.22 +1.32 +1.29 +1.11 +1.23 +1.34 +1.41 +1.41 +1.11 +1.44 +1.19 +1.48 +1.32 +1.07 +0.77 +1.04 +1.07 +1.37 +1.33 +1.20 +1.19 +0.89 +1.30 +1.30 +1.27 +1.26 +1.02 +0.93 +0.80 +0.80 +0.90 +1.20 +0.95 +1.10 +0.78 +1.30 +0.44 +0.80 +1.00 +1.40 +0.80 +1.16 +1.40 +1.10 +1.00 +1.40 +1.33 +0.70 |0.21| |0.42| |0.61| |0.61| |0.21| |0.24| |0.23| |0.38| |0.54| |0.23| |0.32| |0.24| |0.07| |0.03| |0.53| |0.04| |0.21| |0.21| |0.30| |0.10| |0.06| |0.56|

Legal Av +1.13 Manag. Av +1.23 RE Av +1.12 Arch. Av +1.21 Ev. num. +2 +1 0 -1 -2

Total 252 299 80 23 5

+1.08 +1.13 +1.25 +1.45

+1.15 +1.17 +1.29 +1.36

+1.00 +1.33 +1.14 +1.55

+0.85 +1.00 +1.14 +1.27

+1.31 +1.00 +1.43 +1.64

+1.08 +1.29 +1.16 +1.05

+1.46 +1.50 +0.86 +1.55

+1.00 +1.50 +1.33 +1.09

+0.92 +1.50 +1.14 +1.18

+0.85 +0.80 +1.00 +0.27

+0.92 +0.83 +1.29 +0.91

+1.00 +1.00 +1.14 +1.09

+1.38 +1.67 +1.57 +1.09

+1.15 +1.33 +1.14 +1.18

+1.21 +1.22 +0.95 +1.27

+1.23 +1.33 +0.71 +1.55

+0.85 +1.00 +0.86 +1.09

+1.31 +1.00 +1.00 +1.36

+1.62 +1.17 +1.29 +1.09

+1.45 +1.50 +0.86 +1.27

+0.92 +1.33 +1.00 +1.27

61 64 19 4 0

16 15 5 1 0

17 13 6 1 0

10 20 6 1 0

18 16 2 1 0

102 140 35 11 3

21 12 2 1 1

13 16 3 2 0

13 18 5 0 1

6 17 8 3 1

10 18 7 2 0

6 28 2 1 0

18 16 2 1 0

15 15 6 1 0

89 95 26 8 2

13 20 4 0 0

9 19 7 2 0

17 14 3 3 0

18 15 3 0 1

17 13 4 0 1

15 14 5 3 0

Table 7: Results of AM4RRE evaluation. Columns show participant IDs and average and criterion-specific ratings. For an overview of the criteria and their groups, see Section 5.1. Color coding, where x denotes an individual rating or an average rating: dark green, x > 1; light green, 0 < x ≤ 1; light blue, x = 0; orange, −1 ≤ x < 0; red, x < −1.

6.3 RQ3: To what extent can AM4RRE support coordination among the viewpoints? To answer RQ3, we report the feature analysis for coordination-related criteria (see Table 7) and specification time in the quasi-experiment (see Table 8). AM4RRE was evaluated as useful for role coordination (CC05) in 21 of 37 evaluations, with an average evaluation of 1.38. S3.1A suggested that AM4RRE could be a “middle way” between overly abstract and overly prescriptive methods (see below). “Method seems to be a good middle way between principles (Marty Cagan) or legal texts only (without guidance) and procedural work (step by step) which involves a lot of work of preparation.” - S3.1A in the evaluation of AM4RRE

Evaluations varied most among RE and software architect roles and in groups GP06 and GS01. As S2.1R explained in an oral comment, they evaluated AM4RRE as potentially not useful (-1) due to the “delayed” and “insufficient” involvement of a legal expert and the need for earlier and more extensive legal input. In an exchange during the session in GP06, P23.6A and P20.6L questioned the idea of coordination in regulatory RE, arguing that close interaction between roles is not required because each role is responsible only within its own competence (see the following quotation). “My role is to support development teams by enabling and facilitating their work. The responsibility for implementing GDPR compliance within systems remains with the engineering and product teams. It would not be an effective use of my limited capacity to assign me to work directly with engineers who do not possess foundational GDPR knowledge or relevant experience. [D]evelopment teams are expected to have the necessary baseline competency in GDPR requirements before engaging in implementation-related collaboration.” - P20.6L in an oral comment.

P23.6A agreed with this criticism, arguing that email and other conventional communication channels should suffice for engineering-legal coordination. Still, P20.6L evaluated AM4RRE-guided coordination as potentially useful (+1). Some participants who evaluated the templates negatively (e.g., P24.7L see Section 6.2) still considered AM4RRE as potentially useful for coordination. For capturing legal domain knowledge (CC06), AM4RRE was most often evaluated as potentially useful (16 of 34 evaluations), with an average evaluation of 1.18. P20.6L and S2.1R evaluated AM4RRE as "potentially not useful" for the reasons reported above. We suggest that evaluations according to this criterion were closely related to some legal-role participants’ concerns that modeling regulations can be too “simplistic”, will result in losing the “meaning” and “nuance” or will not allow for capturing all the legal knowledge (see Section 6.2 for comments about legal specification templates). Oral comments of participants indicated that failing to capture the complexity of legal knowledge may constrain regulatory RE (see the following quote). “This is way too schematic. It may serve as a warning, but is very far from the finefocus of the GDPR and would not serve in the specific case-analysis.” - P24.7L in a comment regarding TSanc_LP template.

30

Participants evaluated AM4RRE’s usefulness for capturing role-specific knowledge (CC07) as 1.14 on average, and 18 of 37 found it potentially useful. P23.6A, who was critical of the coordination approach overall, rated it “not useful”. For transparency of specifications to other roles (CC11), 18 of 37 participants evaluated it as useful, with an average evaluation of 1.38. Only P23.6A gave a negative evaluation. For facilitating the implementation of regulatory compliance in software architecture (CC13), participants assigned an average evaluation of 1.24, with 20 of 37 evaluating AM4RRE as potentially useful. For CC13, average evaluations by requirements engineers (0.71) and software architects (1.55) diverged. The written feedback of participants also indicated that AM4RRE is useful for supporting interdisciplinary structured coordination in regulatory RE for CbD (see quote next). “If properly refined, I believe this could be a significant leap forward in how to structure communication and reusability of knowledge in the field of PbD, well, really AnythingByDesign.” - P16.5L in the evaluation of AM4RRE

For facilitating the implementation of regulatory compliance throughout the other SE processes (CC14), 19 of 37 participants evaluated AM4RRE as potentially useful, and the overall average evaluation was 0.95. Only two participants assigned a “potentially not useful” evaluation: P1.1L and S1.1L. Gr. Pr. Av. Mx. Period 1 Period 2 Total Difference ID # Ex Ex Cl Sq Time Cm Cn Cr Time Cm Cn Cr Time Time Cm Cn Cr GP01 4 3.75 8 No GF 18m:31s 1 0.66 0.81 8m:49s 0.80 0.61 0.57 27m:20s -9m:42s -52% -0.20 -0.05 -0.24 GP02 2 6 7 Yes GF 11m:00s 1 0.83 0.90 8m:05s 1 0.75 0.85 19m:05s -2m:55s -27% 0 -0.08 -0.05 GP03 3 2 3 Yes GF 11m:02s 1 0.62 0.79 7m:05s 1 0.50 0.64 18m:07s -3m:57s -36% 0 -0.12 -0.15 GP04 4 4 7 Yes FG 25m:00s 1 0.77 0.70 7m:32s 1 0.82 0.90 32m:32s -17m:28s -70% 0 +0.05 +0.20 GP05 4 6.25 10 No FG 34m:42s 1 0.63 0.87 27m:21s 1 0.93 0.97 62m:03s -7m:21s -21% 0 +0.30 +0.10 GP06 4 4.75 7 No GF 8m:49s 1 0.50 0.71 10m:35s 1 0.40 0.60 19m:24s +1m:46s +20% 0 -0.10 -0.11 GP07 5 3.2 7 Yes FG 29m:22s 0.90 0.45 0.84 17m:01s 1 0.46 0.92 46m:23s -12m:21s -42% +0.10 +0.01 +0.08 GS01 3 0.50 1 No GF 13m:28s 1 0.88 0.94 9m:21s 0.80 0.46 0.38 22m:49s -4m:07s -31% -0.20 -0.42 -0.56 GS02 3 0.67 1 Yes FG 20m:51s 1 0.70 0.77 10m:07s 1 0.69 0.78 30m:58s -10m:44s -51% 0 -0.01 +0.01 GS04 2 1.5 2 No GF 15m:00s 1 0.80 0.80 12m:16s 1 0.91 0.97 27m:16s -2m:44s -18% 0 +0.11 +0.17 Av Av

3 4

3.1 3.5

4.7 6.3

-

GF 12m:58s 1 0.72 0.83 9m:22s 0.93 0.61 0.67 22m:20s -3m:37s -28% -0.07 -0.11 -0.16 FG 27m:29s 0.98 0.64 0.80 15m:30s 1 0.73 0.89 42m:59s -11m:59s -44% +0.03 +0.09 +0.10

Table 8: Specification task outcomes. Columns: group ID, number of participants, average and maximum experience with regulation (years), collaboration experience, treatment sequence, for P1 and P2: specification completion time, requirements completeness, requirements consistency, requirements correctness, total specification completion time, differences between P1 and P2.

In the quasi-experiment, 10 of 11 groups, except GS03 in which two force-majeure withdrawals occurred, completed the specification tasks, including fully onsite groups, the online GS01 group, and GP05, with only a legal expert participating online. Across both periods, the four groups with FG treatment sequence (GP04, GP05, GP07, GS02) had an average total specification time of 42m:59s (see Table 8). In contrast, in the groups with GF treatment sequence (GP01, GP02, GP03, GP06, GS01, GS04), the corresponding average was 22m:20s, showing a difference of 20m:39s. This pattern was also observed at the level of groups: the longest total time of any GF group (27:20) was shorter than the shortest FG total (30:58). Notably, the average total time for groups with GF treatment sequence (22m:20s) was lower than the 31

average specification time in Period 1 (P1) alone among the groups with FG sequence (27m:29s). Guided coordination averaged 12:58 when done first (GF) and 15:30 when done second (FG). Free-form coordination executed first in FG sequence took on average 27m:29s, and only 9m:22s when executed after guided coordination in GF sequence groups. These findings provide indicative evidence for Hypothesis 1 that the average total specification time is shorter in groups that used templates guided coordination in Period 1 (GF sequence) than the average total time in the groups that applied free-form coordination in Period 1 (FG sequence), with a difference of 20m:39s between the averages. Specification time decreased from Period 1 to Period 2 in all groups, except GP06, where P20.6L and P23.6A were critical of the idea of coordination. The average time reduction for groups with the GF treatment sequence was 3m:37s (28%), and for groups with the FG sequence, 11m:59s (44%), corresponding to a difference of 8m:22s (16 percentage points). Among groups with GF sequence, the largest reductions occurred in GP01 (with minimal organizational guidance) (52% or 9m:42s), and GP03 (36% or 3m:57s). In contrast, the smallest reductions in groups with FG sequence occurred in GP05 (21% or 7m:21s) (with hybrid participation) and GP07 (42% or 12m:21s). In absolute terms, three of four FG groups exceeded the largest time reduction among the GF groups in GP01, however, in relative terms, only GP04 did. For comparison, if GP01, which initially received only minimal organizational guidance, is excluded, three of four FG groups also exceeded the relative time reduction observed in GP03. RQ3 : Feature analysis results indicate that AM4RRE was perceived as useful for coordination in regulatory requirements specification (CC05 ), and ensuring specification transparency (CC11 ), potentially useful for capturing legal (CC06 ) or other role-specific knowledge (CC07 ), supporting compliance implementation in software design (CC13 ), and other downstream SE processes (CC14 ). Quasi-experiment results complement the positive feature analysis results and suggest that applying AM4RRE templates before free-form coordination (GF sequence) was associated with shorter total specification time than in groups that applied free-form coordination first (FG sequence). These results are also consistent with Hypothesis 2 –the average reduction in specification time from Period 1 to Period 2 was greater in groups with the FG treatment sequence than in groups with the GF sequence, by approximately 8m:22s, or 16 percentage points.

32

6.4 RQ4: To what extent can AM4RRE support the quality of regulatory requirements? To answer RQ4, we report feature analysis results for criteria CC01–CC04 (Table 7) and the quality of specifications produced in the quasi-experiment (Table 8). For regulatory requirements completeness (CC01), 16 of 37 participants found AM4RRE useful, and the average evaluation was 1.24. For support of regulatory requirements consistency (CC02), AM4RRE averaged 1.24, and 17 of 37 participants found it useful. For support of consistency of regulatory and other requirements (CC03), the average evaluation was 1.05, and 20 of 37 participants found it potentially useful. Finally, for supporting regulatory requirements correctness (CC04), AM4RRE received an average rating of 1.38, and 18 of 37 participants evaluated AM4RRE as useful. Each of CC01-CC04 was evaluated negatively only once. Next, we report the results of requirements specifications quality analysis. Internal completeness was maximal (1.00) across all the groups, except for three free-form coordination periods in GP07 (0.90), GP01 (0.80), GS01 (0.80). In six groups with GF treatment sequence, specifications produced in P1 guided by AM4RRE templates had an average consistency of 0.72 and an average correctness of 0.83. In P2, under free-form coordination, consistency was 0.11 (15%) lower (0.61), and correctness was 0.16 (19%) lower (0.67). In five of the six GF groups, AM4RRE templates were associated with higher consistency and correctness, except in GS04, where the free-form coordination period showed higher consistency and correctness by 0.11 (14%) and 0.17 (21%), respectively. In four groups with FG treatment sequence, P1 had an average consistency of 0.64 and an average correctness of 0.80. In guided P2, average consistency increased by 0.09 (14%) to 0.73, and correctness increased by 0.09 (11%) to 0.89. In three of the four FG groups both were higher in the guided period. In GS02 consistency was 0.01 lower. Average completeness under guided coordination was higher in the groups with GF treatment sequence (0.07) in comparison to FG groups (0.03), and consistency was higher by similar margins in both GF (0.11) and FG (0.09) sequence groups. The correctness advantage of guided coordination was larger in GF groups (0.16) than in FG groups (0.10). Persistent quality defects were related to using legal subject names (e.g., data subject) instead of corresponding stakeholder names (e.g., EU adult users), despite considering managerial specifications. None of the groups addressed compliance concerns from the RE case descriptions, possibly because they mainly focused on legal and software architecture specifications and needed to specify only two requirements. RQ4 : According to the feature analysis results, participants found AM4RRE useful for supporting correctness (CC04), completeness (CC01), and consistency of regulatory requirements (CC02), and potentially useful for supporting consistency between regulatory and other requirements (CC03). The quasi-experiment partially supports Hypothesis 3. Regardless of treatment sequence, guided coordination was associated with higher requirement completeness in three groups where it varied, higher consistency in 8 of 10 groups, and higher correctness in 9 of 10 groups. 33

6.5 RQ5: To what extent can AM4RRE support the regulatory RE process? We report feature analysis results for criteria on regulatory RE process support (CC05 -CC12, see Section 6.3 for results according to CC05-CC07, CC11 ). For compensating for the absence of legal knowledge and guiding non-experts in legal specifications (CC08), AM4RRE averaged 0.69, with 17 of 35 participants rating it as potentially useful. P23.6A assigned a “not useful” evaluation, and P19.5A, P20.6L, and S2.1R gave a “potentially not useful” rating. The average evaluation by participants in legal roles was relatively low–0.85. Participants did not make specific comments about CC08; however, we speculate that the low rating reflected broader concerns regarding the potential loss of legal nuance (see Section 6.3). Other comments suggested that AM4RRE can give insight into other viewpoints and their knowledge, including a legal viewpoint (see the quotes next). “Now, I better understand what our legal people do.” - P1.1L in an oral comment. “It helps with seeing things from different perspectives.” - P13.4R in final evaluation.

For support of the tracing in regulatory RE (CC09), participants averaged 0.97, with 18 of 37 participants considering AM4RRE potentially useful. Two participants assigned a rating below zero: P23.6A and S4.2L. Notably, participants in RE roles assigned the highest average evaluation of 1.29. Regarding AM4RRE’s support of consistency in the regulatory RE process (CC10), participants on average rated it 1.05, and 28 of 37 considered AM4RRE “potentially useful”. S4.2L was the only participant who assigned a negative evaluation. For supporting interpretation of regulations (CC12), participants gave an average rating of 1.19; 15 participants considered it “potentially useful” and 15 “useful”. The only participant who assigned a rating below zero for this criterion was P16.5L. In a follow-up discussion, participants described template-guided coordination as very “mechanistic” consideration of different interpretation options and regulatory requirements. They note that in practice, this process is guided by legal expertise, and interpretation results can be captured in a form allowing systematic reuse (see the quotation below). “The conceptual design of the framework seems reasonable; in the practical exercise, it felt a little like “brute-forcing” the requirements, as in establishing all relevant potential ones to capture them. Like many other frameworks, this will likely become more effective with a repository of elements that can be reused.” - P16.5L in AM4RRE evaluation.

RQ5 : Feature analysis results indicated that AM4RRE is potentially useful for supporting traceability (CC09 ), consistency (CC10 ), and regulations interpretation (CC12 ) in regulatory RE. To a lesser degree, AM4RRE was evaluated as potentially useful for compensating for the absence of legal knowledge (CC08 ).

34

6.6 RQ6: To what extent can AM4RRE support achieving the goals of different viewpoints? We report feature analysis results for CC13 -CC18 on support for viewpointspecific goals. Details for CC13-CC14 are available in Section 6.3). The average evaluation of AM4RRE across CC13-CC18 criteria was 1.19. For enabling decision-making about regulatory compliance (CC15), AM4RRE was on average evaluated as 1.22, with 17 of 37 participants considering AM4RRE “useful”. For documenting the required information (CC16), the average evaluation was 1.32, with 18 of 37 participants considering AM4RRE “useful”. Participants in legal roles gave the highest average evaluation (1.62), perhaps because they rely most on such documentation. For facilitation of compliance governance (CC17), the average evaluation was 1.29, with 17 of 35 participants considering AM4RRE “useful”. Notably, participants in managerial roles, for whom this goal is most relevant, gave the highest average (1.50). For addressing business concerns (CC18), the average evaluation was 1.11, with 15 of 37 participants considering AM4RRE “useful” and managerial roles most related to business goals also assigning the highest average evaluation–1.33. CC16 and CC17 were evaluated as “not useful” only by P23.6A. CC15 and CC18 were evaluated as “potentially not useful” only by P23.6A, S1.1L, and S2.1R. RQ6: According to feature analysis results, participants most often evaluated AM4RRE as useful (+2) for documenting the information for compliance (CC16 ), decision-making in regulatory compliance (CC15 ), facilitating governance of regulatory compliance (CC17 ), and addressing business concerns during regulatory compliance implementation (CC18 ).

7 Discussion and future work Next, we discuss the core results and suggest directions for future work. Applicability of AM4RRE for CbD according to CRA and GDPR (RQ1) AM4RRE was applied in regulatory RE for CbD under the GDPR and the CRA, although only one of its five models (the artifact model) was tailored. AM4RRE templates supported coordination in both PbD and SbD cases, though AM4RRE evaluations were generally lower for SbD. The largest PbD-SbD differences, in both template and overall evaluations, concerned completeness (CC01, TC05), consistency (CC02, TC07), capturing legal knowledge (CC06) along with regulation interpretation (CC12) in the AM4RRE evaluation, and explicating role knowledge (TC02) in template evaluation. Despite the smaller sample, SbD evaluation participants reported more known regulatory RE methods for CbD, which were also more technologyfocused. These findings suggest regulation-specific differences, consistent with legal practice demanding specialized expertise across fields of law. Future research could examine such specificity and ways to tailor regulatory RE approaches, for example by tailoring all AM4RRE models.

35

Practical applicability of AM4RRE components and templates (RQ2) The results indicate that our conceptualization of regulatory RE for CbD as specification and coordination across viewpoints is compatible with existing practice. Regulatory RE can thus be seen as a complex RE situation in which fine-grained requirements may not be immediately specifiable [23], but can be specified after coordinating and considering regulations’ impact on existing specifications. Characterizing similar complex RE situations is an important topic for future work. AM4RRE was applied and positively perceived both by participants who had not worked together before and by colleagues from one organization. We speculate that participants’ ability to complete specification templates with minimal guidance suggests that AM4RRE’s artifact orientation may support integration with existing viewpoint-specific processes without requiring significant redesign. Using specification instances in place of absent participants also suggests potential for flexible and asynchronous coordination. AM4RRE was also applied in onsite, online, and hybrid coordination formats. Together, these findings suggest that AM4RRE may accommodate variability in regulatory RE processes and ways of working. Future research could compare artifact- and activity-oriented RE approaches in addressing this variability, including different coordination formats (e.g., fully asynchronous). We explored goal and context models to explicate different viewpoints. Although previous studies used goal models to represent regulations, to our knowledge, their use to guide and coordinate roles in regulatory RE has not previously been explored. Future research could investigate how well goal models capture the regulatory RE context and directly support requirements specification. Our results suggest that organizational context (e.g., division of responsibilities) and goals (e.g., compliance governance) influence the applicability of regulatory RE approaches beyond organizational size alone. Feedback from P23.6A and P20.6L suggests that coordination may not be perceived as important even in large enterprises with dedicated legal experts. We also argue that enterprises where a single SE role handles both legal and SE specifications may be motivated to separate and coordinate these specifications to improve regulatory RE outcomes (e.g., verifiability). Future evaluations of AM4RRE could assess its applicability across organizational contexts. Although participants suggested several improvements to AM4RRE-based templates, the results indicate their applicability to support coordination. We argue that difficulties with the TObj template arose from the need to combine legal knowledge for identifying legal concepts with SE knowledge for allocating them between requirements and system levels of abstraction. This highlights the need to explore how regulatory RE should address the close intersection of legal and SE knowledge. Since the evaluation did not cover the full effort required for AM4RRE tailoring (only some tasks of legal roles resembled regulation-specific tailoring), future research should evaluate the costs and benefits of AM4RRE in a real organizational context. Such evaluations could investigate whether AM4RRE introduces additional overhead, as suggested by P20.6L and P23.6A, and whether this overhead is offset by its benefits. Other research directions include tailoring AM4RRE to multiple regulations simultaneously and integrating it into existing SE processes and artifacts.

36

AM4RRE support for coordination in regulatory RE for CbD (RQ3) Feature analysis indicates positive perceived usefulness across both template and AM4RRE criteria: capturing and explicating role-specific knowledge through templates (TC01, TC02) and AM4RRE (CC06, CC07), and specification transparency (TC03, CC11). Participants in legal roles rated knowledge capture positively (1.00) and interpretation support—presumably requiring their involvement—higher (1.15). In the quasi-experiment, AM4RRE templates were associated with shorter average specification time in groups that executed guided coordination first and higher requirements quality in most of the groups, with some exceptions. We compare these findings with prior studies, discuss group differences, potential confounding factors, and learning effects (how familiarity with the approach or case affects subsequent tasks [28, 52]). It is important to note that the treatment comprised only completed AM4RRE templates preceded by introductory tasks. Before specification tasks, all groups were exposed to AM4RRE context, role, and goal models,viewpoint-specific templates, and the regulatory requirements specification template. Fully isolating AM4RRE as the treatment could therefore yield different results. To our knowledge, no prior regulatory RE study evaluated structured engineeringlegal coordination with both roles present. Studies in privacy threat modeling [7, 47] partly cover legal and SE viewpoints for identifying threats in existing design and data flows, but do not address broader RE concerns related to software context and requirements. Boltz et al.[7] emphasize legal interpretation and use the same legal concepts as AM4RRE (legal object, legal subject), but do not evaluate their approach with threat modeling practitioners. Engiel et al. [10] tested an approach applicable to engineering-legal RE with software engineers only, eliciting more requirements than ad hoc practice in equal time. Similarly, in our study, GP02 and GP04 specified more requirements with AM4RRE templates than with free-form coordination, although this measure was not predefined. Alhirabi et al. [1] evaluated their PbD tool separately with software engineers and legal experts: 71% found it useful for implementing six PbD principles, and 46% found it easy to use and efficient. For AM4RRE, 89% perceived it positively for compliance in software design; template evaluations for ease of information specification were 55% (legal), 50% (managerial), 77% (RE), and 85% (software architecture). Although direct comparison of study results is not possible, our study contributes to existing state of research by evaluating AM4RRE with legal and engineering practitioners working together. When considering coordination format as a potential confounding factor, GP05, with hybrid participation, had the longest specification time but one of the largest increases in consistency and correctness under guided coordination. Online GS01 had the third-longest specification time among GF groups, but had substantially higher consistency and correctness in guided P1 than free-form P2. These findings suggest that it is important to explore if AM4RRE may be particularly useful in hybrid or remote coordination. The results of GP05 and GS04 suggest a possible association between the specification time and requirements quality. GS04 had the second-longest total time among GF groups and the smallest overall time reduction, but it was the only GF group to achieve higher consistency and correctness in P2.

37

Quality gains in GP05 and GS04 may reflect stronger learning effects linked to greater average experience with regulation, while GS01’s lower average may explain its lack of evident learning effects in P2. Experience may also explain why two experienced participants in GP02 achieved higher consistency and correctness than the three less experienced participants in GP03 in a similar time. Among groups with the same treatment sequence, those with more participants tended to show greater time reductions (e.g., GP04 and GS02 or GP02 and GP03), but no clear quality improvements. GP07, with five participants, achieved correctness comparable to GP02, with two participants, but with lower consistency. Since smaller groups used specification instances for absent roles, these findings suggest completed templates may partly compensate for fewer participants. Shorter P2 specification times suggested a potential learning effect across both sequences in all groups except GP06, where P20.6L and P23.6A were critical of coordination. Since distinguishing learning from treatment effects requires more controlled conditions, we examined only indicative associations. We compared average time reductions between groups with FG and GF treatment sequences with AM4RRE template use. However, in groups with the GF treatment sequence, guided coordination may have induced stronger learning than free-form coordination in FG groups, contributing to subsequent time reductions. Average free-form times support this possibility: 27m:29s in P1 (FG) and 9m:22s in P2 (GF). Guided coordination averaged 12m:58s in P1 (GF) versus 15m:30s in P2 (FG). Longer guided coordination in P2 may reflect participant differences, fatigue, or switching effort observed in some groups. The almost threefold difference in average free-form specification times may reflect learning associated with prior AM4RRE template use. Still, this comparison does not clearly isolate learning from period effects or between-group differences. AM4RRE support for requirements quality (RQ4) Feature analysis showed that participants evaluated AM4RRE highest for requirements correctness (1.38), followed by completeness and consistency between regulatory requirements (both 1.24), and consistency between regulatory and other requirements (1.05). These perceptions align with the quasi-experiment in which correctness in guided coordination in GF groups had the greatest average advantage (0.16). In the quasi-experiment, requirements quality showed a different pattern of potential learning effects from specification time. Across treatment sequences, guided coordination was associated with higher completeness in the three groups where it varied, higher consistency in eight of ten groups (except GS02 and GS04), and higher correctness in nine (except GS04). Marginal changes under guided P2 in GS02 (consistency -0.01; correctness +0.01) may relate to its shortest total specification time among FG groups and third-largest time reduction overall. Under guided coordination, average completeness was unchanged across periods, while consistency and correctness were 0.01 and 0.06 higher in P2 (FG), suggesting that guided coordination may better support applying knowledge acquired in P1. Under free-form coordination, P1 (FG) had higher means: completeness by 0.04, consistency by 0.03, and correctness by 0.13. These differences may reflect participant characteristics, difficulty switching from guided to free-form coordination, or overreliance on acquired knowledge.

38

We observed other manifestations of possible learning effects: participants in SE roles sometimes relied on memorized information. Legal experts often used general regulatory knowledge instead of the case descriptions or their specifications. These behaviors may reflect learning during the evaluation, prior expertise, or both. RE methods may help practitioners internalize knowledge within and beyond their roles, reducing explicit method use. This may have unintended consequences, such as role interference, as when a GP05 participant in a managerial role provided architecturerelated information. We suggest that regulatory RE approaches should adapt as practitioners’ familiarity with regulations or the project grows. Participants used different coordination forms, such as displaying completed templates or conveying contents verbally without showing them. We observed that coordination forms were related to specification syntax–GP01 participants reported that complex template syntax hindered coordination. Together with observations on the legal object template, this highlights the importance of syntactic differences in interdisciplinary work, and potentially within software engineering teams. One important finding is that coordination can support regulatory requirements quality but does not guarantee it. Across all groups and treatments, specifications used legal concepts (e.g., data subject) instead of corresponding SE concepts derived through legal interpretation. Engineers may understand these specifications, especially when collaborating with legal experts, but leaving interpretations implicit limits usefulness for SE and risks misinterpretation when coordination context is lost [33]. This issue may affect regulatory and other multi-viewpoint RE, motivating dedicated quality assurance and further research. AM4RRE contribution to regulatory RE (RQ5) Support for traceability was on average evaluated around +1 both for templates (TC06) and for AM4RRE (CC09). Interestingly, participants in RE roles evaluated CC09 considerably higher (1.29) than other roles (0.83-0.92), while evaluating AM4RRE lower for coordination (0.86 vs. 1.46-1.55). S2.1R linked their negative evaluation to the “delayed” and “insufficient” interaction between RE and legal roles, which could be relevant for other participants in RE roles. Participants in legal roles evaluated AM4RRE for compensating for absent legal knowledge (CC08 ) as relatively low (0.85), describing coordination as “brute-forcing” requirements (P16.5L), mechanistic or overloaded (P20.6L), and specifications as risking “los[ing] meaning and nuance” (P24.7L). Participants in legal and occasionally other roles sometimes raised provisions or regulations beyond the cases in discussions (e.g., US privacy regulation raised by P2.1M). These observations suggest that legal experts draw on broad legal knowledge and context, which must be captured to preserve their interpretations and maintain backward traceability to regulations. The comment by S3.1A (see Section 6.3) suggests that AM4RRE has potential to integrate into different SE process models, support both independent work on viewpoint-specific specifications and targeted collaboration across coordination formats. This may offer an alternative to less structured coordination as in Agile SE.

39

AM4RRE support for goal achievement (RQ6) Average usefulness evaluation for CC13–CC18 goal support was positive but varied across roles. Most ratings for other viewpoints’ second-level goals were also positive across goal models. Future research could explore goal support across roles (e.g., decision-making) to align regulatory RE research with practice, identify each goal’s primary stakeholders, and prioritize goals relevant across stakeholders. Relatively low AM4RRE evaluation for compliance support across SE processes (0.95) suggests a need for additional SE viewpoints spanning the software development life cycle. Different evaluations for compliance support in software design between RE (0.71) and software architecture (1.55) may reflect differences in expectations or participation. The role of RE in engineering-legal coordination Our findings suggest that RE roles were insufficiently involved in the quasiexperiment in two respects. First, no group addressed compliance from the RE viewpoint (case description or templates) in regulatory requirements specification. Although managerial and RE roles were involved in the coordination process and their specifications or case descriptions were occasionally reviewed, regulatory requirements primarily reflected software architecture and legal specifications or case descriptions. Possible explanations for this include study design (only two requirements per period were required), insufficient AM4RRE guidance, RE engagement patterns, and prioritizing regulatory architecture constraints over alignment with existing requirements. We argue that these observations reflect existing challenges–few studies address alignment between regulatory and non-regulatory requirements, and regulatory constraints are considered easy to overlook [8, 26]. We attribute RE participants’ still positive average evaluation to perceived coordination potential. Future work could examine whether addressing existing non-regulatory requirements should be integrated with CbD implementation or handled separately. Second, we speculate that RE roles were passive or perceived as secondary. Participants were free to choose who organized and documented coordination, although the goal and role models suggested RE leadership. Nevertheless, none of the seven groups with RE participants selected an RE role to record specifications–four chose the legal expert (GP04-05, GS01, GS02) and three–the software architect (GP03, GP06-07). This observation resembles the finding that regulatory compliance research focusing on downstream SE processes often does not account for RE [32]. We therefore suggest that RE research and practice should better formulate and establish the RE role in supporting compliance implementation. Our findings highlight the importance of RE guidance for ensuring the quality of regulatory requirements specifications. In four of the six GF groups, specification times decreased alongside consistency and correctness. We speculate that learning effects may have encouraged reliance on acquired knowledge and faster specification while quality declined. Together with the use of legal instead of system-specific SE concepts, these findings suggest the need for dedicated RE guidance and quality assurance. Beyond providing indicative evidence of AM4RRE feasibility and perceived usefulness, this study highlights the multifaceted role of RE in supporting regulatory compliance, particularly compliance by design. Regulatory RE approaches should support explication of relevant viewpoints. Modeling goals and challenges may help 40

to uncover task and information dependencies among viewpoints. RE further needs to provide viewpoint coordination mechanisms, such as shared artifacts, templates, and tools. RE can support requirements specification that remains traceable to legal specifications for legal experts and to SE specifications that are understandable and actionable for software architects and other SE roles. In this dynamic process, AM4RRE was already perceived as supporting these needs by structuring viewpoint specifications and making information interdependencies explicit. We plan to explore AM4RRE operationalization with tool support in real organizational settings. While AM4RRE emphasizes pragmatic information exchange through direct role involvement, it also provides a basis for exploring feasible automation. AI-based tools may capture viewpoints and context, but they may not give users enough agency or understanding and may still require expert involvement [46, 48]. Key Takeaways Next, we summarize the important findings. Key research takeaways are: • RE can support downstream compliance implementation by communicating required knowledge and information between legal and SE viewpoints; • regulatory RE demands mechanisms for interpreting applicable regulatory norms in the context of the existing software and SE specifications; • dynamic aspects of RE processes, including coordination among roles, should be considered in regulatory RE and potentially other RE settings; • regulatory RE approaches should reflect practice and integrate with SE processes and the wider organizational context; • modeling goals and challenges can provide mechanisms to contextualize regulatory RE processes and capture different viewpoints; • research should further explore engineering and tailoring of RE approaches for varying contexts and roles directly involved in RE; • regulatory RE research could further concretize the mediating role of RE between legal and SE viewpoints by exploring how it supports both. Our results suggest the following key takeaways for practitioners: • it is important to approach regulatory RE as a lever for supporting compliance implementation in subsequent SE processes; • regulatory RE requires special attention to coordination of regulatory and nonregulatory requirements and existing design; • with or without a dedicated legal role, maintaining separate legal specifications can help capture legal rationale and ensure backward traceability; • it is important to consider different coordination formats (e.g., hybrid) and forms (e.g., intermediated by specifications) to support regulatory RE better; • regulatory RE activities should be guided by intended benefits, such as shorter specification times and improved requirements quality; • in interdisciplinary settings, requirements quality should be observed, and resulting specifications should be understandable without experts’ involvement; • approaches and tools for regulatory RE should support seamless integration with existing SE processes and tools.

41

8 Threats to validity Our conclusions rely primarily on feature analysis, complemented by quasiexperimental results; next, we discuss validity threats for both. For construct validity in feature analysis, we developed evaluation criteria using common requirements quality attributes, goal- and process-related concerns identified in recent empirical studies [33, 34]. We analyzed feature analysis results using a dedicated coordination criterion (CC05) and criteria covering its aspects (see Section 6.3). Participants rated each criterion after the corresponding activity. Participants evaluated templates after completing them and AM4RRE after completing the specification tasks in the quasi-experiment. Without an established comparable systematic method, participants drew on their practical and workshop experience. All participants had exposure to the tasks of the role they represented, enabling comparison. The first author developed and operationalized AM4RRE, introduced it, and led all sessions, which may have influenced evaluations. To limit this influence, participants evaluated templates and AM4RRE individually in writing, and the session lead did not review results until session end. Additionally, handouts allowed free-form comments, and participants could express opinions during sessions. We explained criteria for feature analysis during sessions and summarized them in template evaluation forms. Sessions were not recorded; oral comments illustrating feature-analysis results derive from the first author’s field notes and follow-ups with some participants. For the quasi-experiment, we designed the tasks so that no single role could specify the requirements alone; at a minimum, the legal expert and the software architect had to interact. During guided coordination, participants were encouraged to use only completed templates, but were allowed to use case descriptions if required. During free-form coordination, participants were not allowed to use templates. Consistency of requirements specified under free-form coordination was assessed against the case descriptions and under guided coordination–against completed templates. For internal validity, we followed guidelines for method evaluation [25] and quasi-experiments [21, 28, 52, 54] as far as our settings allowed. Phased planning and execution supported systematic evaluation and refinement of methods. We also report the applied methodology in detail. To address selection bias, we distributed a standard invitation through multiple channels. The invitations named viewpoint coordination as the focus of evaluation, although we encouraged participation regardless of interest in such coordination. Fifteen participants were recruited from the same company (C6), allowing us to include individuals motivated by organizational factors. We formed groups by availability and did not randomize treatment sequences. To keep sessions viable, we avoided the FG sequence for groups likely to be delayed. We assigned the FG treatment sequence to GP05 because of high GDPR experience, and to GS02 because of partial prior collaboration and high experience in CRA and cybersecurity. As a result, FG groups were larger on average (four vs. three participants) and more often had all roles present. Comparisons of total time between sequences thus reflect group composition and treatment order. To introduce AM4RRE templates, we used untimed introductory tasks (CG01) immediately before guided coordination without a free-form counterpart. To address the potential validity threat 42

due to this, we designed introductory tasks to overlap with the timed tasks minimally and excluded the architecture overview and legal object templates. All groups received standardized handouts, with minor PbD/SbD differences and the same regulatory requirements template — the guided version provided placeholders, and the free-form version provided it as an example. Guidance on guided coordination was added after GP01. Although this could affect quasi-experimental results, results without GP01 still point to the same trends and associations. For conclusion validity, two referees additionally assessed requirements correctness and consistency. The correctness referee was blinded to coordination type. The consistency referee was not blinded, because the assessment required different reference materials by condition. We excluded missing specification elements rather than scoring them as zero, consistently in all calculations for feature analysis and quasi-experiment. This affects the guided periods of GP06, GP07, and GS02 and the free-form periods of GP01, GP07, and GS01, where participants discussed but did not record requirement elements. To support reliability of treatment implementation, the session lead refrained from intervening during feature analysis and the quasi-experiment. When substituting for one or two missing roles, he introduced only case or specification samples and pointed to the required information on request. Given the small sample and limited control, we report descriptive results and associations rather than causal relationships. We also report data on potential confounding factors: regulatory experience, knowledge of regulatory RE methods for CbD, and collaboration experience. Within the feature analysis, template and AM4RRE evaluations mainly converged (e.g., TC03 and CC11), although evaluations differed between roles. Because feature analysis and the quasi-experiment shared participants, we treat agreement as corroboration rather than independent confirmation. Measured requirements quality corroborates perceived quality support (CC01–CC04); time results lack a feature-analysis counterpart and remain exploratory. For external validity, we recruited practitioners with varied positions and with GDPR or CRA experience. For SbD sessions, we waived the one-year experience requirement because the main CRA obligations apply only from December 2027. Several participants represented roles differing from their job titles, but most had relevant backgrounds, experience, or knowledge of the corresponding role (e.g., S7.3L studied law at university). Fifteen of the 40 participants came from C6, including all members of GP02–GP04 and GP07, so their responses may reflect shared organizational practices or opinions. Most participants worked in large companies, limiting generalization for small and medium organizations. Results are further bounded by two EU regulations, fictitious cases, and tasks requiring two requirements per period, unlike real project settings involving more requirements and longer coordination. Comments by P20.6L and P23.6A suggest that coordination needs may depend more on compliance priorities and organizational practices than on company size. AM4RRE may therefore be relevant where organizations require both legal and engineering involvement in implementing compliance by design.

43

9 Conclusion To address growing regulatory demands and support compliance by design, software engineering practitioners need adaptable, practice-oriented regulatory RE methods. Such methods should support knowledge-intensive regulatory analysis and compliance implementation throughout software engineering processes. Our findings suggest that direct coordination between legal and engineering viewpoints is a pragmatic and promising basis for specifying regulatory requirements for software design. The Artifact Model for Regulatory Requirements Engineering (AM4RRE) presented in this study operationalizes engineering-legal coordination through viewpoint templates and explicit relations between specification content. Evaluation with 37 practitioners using fictitious GDPR and CRA cases provided indicative evidence of feasibility and perceived usefulness. Practitioner feedback suggested that AM4RRE is compatible with their existing regulatory requirements engineering practice. Feature analysis indicated positive evaluations of ten of eleven viewpoint-specific templates; the exception was the one requiring simultaneous application of legal and engineering knowledge. These templates were perceived as useful for capturing, explicating, and communicating role-specific knowledge. They also guided coordination in the quasi-experiment. AM4RRE as a whole received positive average usefulness ratings for viewpoint coordination, requirements quality, regulatory RE processes, and viewpoint-specific goals. These perceptions partially aligned with the quasi-experiment results. Across both treatment sequences, guided coordination was associated with higher completeness in three groups where it varied, higher consistency in eight of ten groups, and higher correctness in nine of ten groups. However, the use of legal instead of system-specific SE concepts highlights a continuing need for RE guidance and quality assurance. Groups using AM4RRE-based templates for guided coordination before free-form coordination had shorter total specification times and almost three times shorter average freeform specification time than groups that used free-form specification first. The groups using the templates afterward showed greater average time reductions between the two periods. Although these associations do not establish causal effects, the results on specification quality are consistent with the evaluations assigned in feature analysis. We argue that approaching regulatory requirements engineering as a coordination challenge among multiple viewpoints reflects the complexity of practice. However, our observations suggest that practitioners can overlook the contribution of requirements engineering in this process. We suggest that requirements engineering methods must be further refined to meet the practical demands of coordination and support the goals of the involved viewpoints. This can equip requirements engineering practitioners with the knowledge and tools to explicitly and meaningfully contribute to resolving complex software engineering challenges, such as processing regulations and implementing regulatory compliance. Data availability statement. The open dataset for this publication is available on Zenodo (DOI: 10.5281/zenodo.23726817).

44

References [1] Alhirabi N, Beaumont S, Llanos JT, et al (2023) Parrot: Interactive privacy-aware internet of things application design tool. Proceedings of the ACM on Interactive, Mobile, Wearable and Ubiquitous Technologies 7(1):1–37 [2] Ayala-Rivera V, Portillo-Dominguez AO, Pasquale L (2024) Gdpr compliance via software evolution: Weaving security controls in software design. Journal of Systems and Software 216:112144 [3] Baltes S, Ralph P (2022) Sampling in software engineering research: A critical review and guidelines. Empirical Software Engineering 27(4):94 [4] Bednar K, Spiekermann S, Langheinrich M (2019) Engineering privacy by design: Are engineers ready to live up to the challenge? The Information Society 35(3):122–142 [5] Bobkowska A, Kowalska M (2010) On efficient collaboration between lawyers and software engineers when transforming legal regulations to law-related requirements. In: 2010 2nd International Conference on Information Technology,(2010 ICIT), IEEE, pp 105–109 [6] Boella G, Humphreys L, Muthuri R, et al (2014) A critical analysis of legal requirements engineering from the perspective of legal practice. In: 2014 IEEE 7th International Workshop on Requirements Engineering and Law (RELAW), IEEE, pp 14–21 [7] Boltz N, Sterz L, Raabe O, et al (2026) Enabling a model-driven workflow for ongoing interdisciplinary collaboration in legal threat modeling. Information and Software Technology p 108121 [8] Breaux T, Antón A (2008) Analyzing regulatory rules for privacy and security requirements. IEEE transactions on software engineering 34(1):5–20 [9] Easterbrook S, Yu E, Aranda J, et al (2005) Do viewpoints lead to better conceptual models? an exploratory case study. In: 13th IEEE International Conference on Requirements Engineering (RE’05), IEEE, pp 199–208 [10] Engiel P, Leite JCSDP, Mylopoulos J (2017) A tool-supported compliance process for software systems. In: 2017 11th International Conference on Research Challenges in Information Science (RCIS), IEEE, pp 66–76 [11] European Commission (2024) Seventh progress report on the implementation of the eu security union strategy. COM(2024) 198 final [12] European Commission (2024) State of the digital decade. COM(2024) 260 final [13] Fricker S, Gorschek T, Myllyperkiö P (2007) Handshaking between software projects and stakeholders using implementation proposals. In: International Working Conference on Requirements Engineering: Foundation for Software Quality, Springer, pp 144–159 [14] Ghanavati S, Hulstijn J (2015) Impact of legal interpretation in business process compliance. In: 2015 IEEE/ACM 1st International Workshop on TEchnical and

45

LEgal aspects of data pRivacy and SEcurity, IEEE, pp 26–31 [15] Ghanavati S, Amyot D, Rifaut A (2014) Legal goal-oriented requirement language (legal grl) for modeling regulations. In: Proceedings of the 6th international workshop on modeling in software engineering, pp 1–6 [16] Glinz M, Fricker SA (2015) On shared understanding in software engineering: an essay. Computer Science-Research and Development 30(3):363–376 [17] Green Software Foundation (2023) Software legislation has quadrupled in the last decade [18] Hjerppe K, Ruohonen J, Leppänen V (2019) The general data protection regulation: requirements, architectures, and constraints. In: IEEE 27th International Requirements Engineering Conference (RE), pp 265–275 [19] Horstmann SA, Domiks S, Gutfleisch M, et al (2024) “those things are written by lawyers, and programmers are reading that.” mapping the communication gap between software developers and privacy experts. Proceedings on Privacy Enhancing Technologies [20] Ingolfo S, Siena A, Jureta I, et al (2013) Choosing compliance solutions through stakeholder preferences. In: International Working Conference on Requirements Engineering: Foundation for Software Quality, pp 206–220 [21] Kampenes VB, Dybå T, Hannay JE, et al (2009) A systematic review of quasi-experiments in software engineering. Information and Software Technology 51(1):71–82 [22] Kasauli R, Wohlrab R, Knauss E, et al (2020) Charting coordination needs in large-scale agile organisations with boundary objects and methodological islands. In: Proceedings of the International Conference on Software and System Processes, pp 51–60 [23] Katina PF, Keating CB, Jaradat RM (2014) System requirements engineering in complex situations. Requirements engineering 19(1):45–62 [24] Kempe E, Massey A (2021) Regulatory and security standard compliance throughout the software development lifecycle [25] Kitchenham B, Linkman S, Law D (1996) Desmet: A method for evaluating software engineering methods and tools. Keele University [26] Kiyavitskaya N, Zeni N, Breaux TD, et al (2007) Extracting rights and obligations from regulations: toward a tool-supported process. In: Proceedings of the 22nd IEEE/ACM International Conference on Automated Software Engineering [27] Klymenko O, Kosenkov O, Meisenbacher S, et al (2022) Understanding the implementation of technical measures in the process of data privacy compliance: A qualitative study. In: Proceedings of the 16th ACM/IEEE International Symposium on Empirical Software Engineering and Measurement, pp 261–271 [28] Ko AJ, LaToza TD, Burnett MM (2015) A practical guide to controlled experiments of software engineering tools with human participants. Empirical Software Engineering 20(1):110–141 46

[29] Kosenkov O, Unterkalmsteiner M, Mendez D, et al (2021) Vision for an artefactbased approach to regulatory requirements engineering. In: Proceedings of the 15th ACM/IEEE International Symposium on Empirical Software Engineering and Measurement (ESEM), pp 1–6 [30] Kosenkov O, Unterkalmsteiner M, Mendez D, et al (2024) Regulatory requirements engineering in large enterprises: An interview study on the european accessibility act. In: International Conference on Product-Focused Software Process Improvement, Springer, pp 204–220 [31] Kosenkov O, Unterkalmsteiner M, Mendez D, et al (2024) On developing an artifact-based approach to regulatory requirements engineering. In: 2024 IEEE 32nd International Requirements Engineering Conference Workshops (REW) [32] Kosenkov O, Elahidoost P, Gorschek T, et al (2025) Systematic mapping study on requirements engineering for regulatory compliance of software systems. Information and Software Technology 178:107622 [33] Kosenkov O, Zabardast E, Fucci D, et al (2025) Privacy by design: Aligning gdpr and software engineering specifications with a requirements engineering approach. Information and Software Technology p 107946 [34] Kosenkov O, Zabardast E, Fischbach J, et al (2026) Towards a goal-centric assessment of requirements engineering methods for privacy by design. In: 2026 Conference on Requirements Engineering Foundation for Software Quality [35] Kotonya G, Sommerville I (1996) Requirements engineering with viewpoints. Software Engineering Journal 11(1):5–18 [36] Leite JCSdP (1996) Viewpoints on viewpoints. In: Joint proceedings of the second ISAW-2 and Viewpoints’ 96 on SIGSOFT’96 workshops, pp 285–288 [37] Martin YS, Kung A (2018) Methods and tools for gdpr compliance through privacy and data protection engineering. In: 2018 IEEE European symposium on security and privacy workshops (EuroS&PW), IEEE, pp 108–111 [38] Massey AK, Otto PN, Hayward LJ, et al (2010) Evaluating existing security and privacy requirements for legal compliance. Requirements engineering 15(1) [39] Massey AK, Otto PN, Antón AI (2014) Evaluating legal implementation readiness decision-making. Transactions on Software Engineering 41(6) [40] Méndez Fernández D, Penzenstadler B (2015) Artefact-based requirements engineering: the amdire approach. Requirements Engineering 20(4):405–434 [41] Méndez Fernández D, Penzenstadler B, Kuhrmann M, et al (2010) A meta model for artefact-orientation: fundamentals and lessons learned in requirements engineering. In: International Conference on Model Driven Engineering Languages and Systems, Springer, pp 183–197 [42] Osborne Clarke (2025) Navigating the next phases of digital regulation [43] Quiñones JVC, Bautista IR, Delgado VA, et al (2024) Guide for strengthening the building of shared understanding in requirements engineering activities. In: Iberoamerican Workshop on Human-Computer Interaction 47

[44] Shenouda A, Santilli T, Siavashi F, et al (2024) Using boundary objects for continuous compliance in automotive development. In: 2024 IEEE 35th International Symposium on Software Reliability Engineering Workshops (ISSREW), IEEE, pp 224–231 [45] Siena A, Jureta I, Ingolfo S, et al (2012) Capturing variability of law with nomos 2. In: International Conference on Conceptual Modeling, pp 383–396 [46] Singhal A, Breaux T (2026) Code generation for legal metadata extraction: a decomposition-based in-context learning approach. Requirements Engineering 31(2):15 [47] Sion L, Dewitte P, Van Landuyt D, et al (2020) Dpmf: a modeling framework for data protection by design. Enterprise Modelling and Information Systems Architectures -International Journal of Conceptual Modeling 15:10–1 [48] Sleimi A, Sannier N, Sabetzadeh M, et al (2021) An automated framework for the extraction of semantic legal metadata from legal texts. Empirical Software Engineering 26(3):43 [49] Sommerville I, Sawyer P (1997) Viewpoints: principles, problems and a practical approach to requirements engineering. Annals of software engineering 3(1):101– 130 [50] Syed Abdullah N, Sadiq S, Indulska M (2010) Emerging challenges in information systems research for regulatory compliance management. In: International Conference on Advanced Information Systems Engineering [51] Toffolon C, Dakhli S (2000) A framework for studying the coordination process in software engineering. In: Proceedings of the 2000 ACM symposium on Applied computing-Volume 2, pp 851–857 [52] Vegas S, Apa C, Juristo N (2015) Crossover designs in software engineering experiments: Benefits and perils. IEEE Transactions on Software Engineering 42(2):120–135 [53] Werner C, Li ZS, Ernst N, et al (2020) The lack of shared understanding of non-functional requirements in continuous software engineering: Accidental or essential? In: 2020 IEEE 28th international requirements engineering conference (RE), IEEE, pp 90–101 [54] Wohlin C, Runeson P, Höst M, et al (2012) Experimentation in software engineering, vol 236. Springer [55] Wohlrab R, Pelliccione P, et al (2019) Boundary objects and their use in agile systems engineering. Journal of Software: Evolution and Process 31(5)

48

Related documents

• Exploring Automated GDPR-Compliance in Requirements Engineering: A Systematic Mapping Study#400545
• ConfIs: A Tool for Privacy and Security Analysis and Conflict Resolution for Supporting GDPR Compliance through Privacy-by-Design#964745
• The Boundary Discipline: Where the Lens Starts, Stops, and Applies to Itself#688607
• How Do Brazilian IT Companies Address Ambiguity Resolution in Legal Requirements Specification? - A study focused on data protection laws#1176993
• Poking Around in the Dark: Why a Shared Understanding of Components Matters#1036717