[Paper] Towards Viewpoint-centric Artifact-based Regulatory Requirements Engineering for Compliance by Design

Source: arXiv - 2603.09492v1

Overview

The paper presents AM4RRE, an artifact‑centric model that aims to weave regulatory compliance directly into the software requirements engineering (RE) process. By focusing on the different viewpoints (legal, business, development, etc.) that influence compliance, the author proposes a way to move from ad‑hoc “compliance by design” to a systematic, repeatable practice that can be embedded in everyday development workflows.

Key Contributions

• Artifact Model (AM4RRE): A structured set of deliverables (artifacts) that capture regulatory constraints, stakeholder viewpoints, and traceability links throughout the RE lifecycle.
• Viewpoint‑Centric Perspective: Explicit handling of cross‑functional viewpoints (legal, risk, product, architecture) to reduce miscommunication and ensure consistent interpretation of regulations.
• Integration Blueprint: Guidelines for plugging AM4RRE into existing RE and SDLC practices without adding heavyweight processes.
• Empirical Insight: Preliminary findings from a doctoral case study that highlight the gap between organizational regulatory RE processes and the day‑to‑day work of development teams.
• Research Roadmap: A plan for evaluating AM4RRE in real‑world settings and refining the model based on practitioner feedback.

Methodology

The author follows a design‑science research approach:

1. Problem Framing – Interviews and literature review identified the pain points of current regulatory RE (stand‑alone processes, ad‑hoc compliance, viewpoint misalignment).
2. Artifact Synthesis – Based on the identified needs, a set of artifacts (e.g., Regulatory Requirement Specification, Viewpoint Mapping Matrix, Compliance Traceability Matrix) was drafted and organized into the AM4RRE model.
3. Conceptual Validation – The model was presented to a small group of industry practitioners and academic peers for critique; feedback was collected via surveys and workshops.
4. Iterative Refinement – The author incorporated the feedback into a revised artifact set and prepared a concrete evaluation plan for future field studies.

The methodology is deliberately lightweight so that developers can grasp the core ideas without needing deep expertise in RE theory.

Results & Findings

• Regulatory RE is Distinct – Unlike functional requirements, regulatory requirements often originate from external legal texts, require continuous updates, and involve multiple organizational units.
• Current Practices are Fragmented – Organizations tend to maintain a “regulatory office” that produces compliance documents, while development teams interpret these documents informally, leading to inconsistencies.
• Artifact‑Based Coordination Reduces Gaps – Early prototypes of the AM4RRE artifacts (especially the Viewpoint Mapping Matrix) helped teams surface hidden assumptions and align terminology across legal and technical stakeholders.
• Low Overhead is Feasible – Practitioners reported that the proposed artifacts could be integrated into existing tools (e.g., JIRA, Confluence) with minimal additional effort.

Practical Implications

• Tool Integration – Teams can start by adding a few custom fields or templates to their current issue‑tracking system to capture regulatory artifacts, enabling traceability without buying new software.
• Cross‑Team Workshops – The Viewpoint Mapping Matrix serves as a concrete agenda item for joint sessions between legal counsel, product owners, and architects, fostering shared understanding early in the sprint.
• Continuous Compliance – Because artifacts are versioned and linked to code changes, automated checks (e.g., CI pipelines) can flag when a change potentially violates a regulatory constraint.
• Risk Reduction – Systematic traceability makes audit preparation easier and reduces the likelihood of costly post‑release compliance fixes.
• Scalable Governance – Organizations can scale the model from a single product team to enterprise‑wide governance by reusing the same artifact taxonomy across projects.

Limitations & Future Work

• Empirical Scope – The current validation relies on a limited set of interviews and a small pilot; results may not generalize across industries with vastly different regulatory regimes (e.g., finance vs. medical devices).
• Tooling Overhead – While the model is designed to be lightweight, some teams may still need to invest in custom integrations or training to maintain the artifacts consistently.
• Dynamic Regulations – The model does not yet address automated ingestion of regulatory text updates (e.g., from legal APIs), which could be a future enhancement.
• Evaluation Plan – The author proposes longitudinal field studies in multiple organizations to measure impact on compliance defect rates, development velocity, and audit effort.

The paper opens a promising conversation about making regulatory compliance a first‑class citizen in software engineering, and it offers a practical starting point for teams ready to move beyond “check‑the‑box” compliance.

Authors

• Oleksandr Kosenkov

Paper Information

• arXiv ID: 2603.09492v1
• Categories: cs.SE, cs.CY
• Published: March 10, 2026
• PDF: Download PDF