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

Questo articolo presenta il modello AM4RRE, un approccio basato su artefatti e prospettive multiple per integrare sistematicamente l'ingegneria dei requisiti normativi nel ciclo di vita dello sviluppo software, al fine di realizzare una conformità "by design" e raccogliere feedback per la fase finale di uno studio dottorale.

L'essenziale

Immagina di dover costruire una casa (il tuo software) in un paese dove le leggi sono cambiate ogni settimana e sono scritte in un linguaggio complicatissimo, quasi incomprensibile per un muratore. Questo è il problema che affronta la tesi di dottorato di Oleksandr Kosenkov.

Ecco una spiegazione semplice, usando metafore per rendere tutto più chiaro.

🏗️ Il Problema: Costruire su Terreni Instabili

Fino a poco tempo fa, costruire software era come costruire una casa: avevi un progetto, i mattoni e si andava avanti. Oggi, però, ci sono migliaia di nuove leggi (come quelle sulla privacy o la sicurezza) che dicono esattamente come devi costruire quella casa.

Il problema è che:

1. Gli ingegneri (i muratori) non parlano la lingua dei giuristi (gli architetti legali).
2. Le aziende spesso provano a rispettare le leggi "alla buona", aggiungendo regole a caso alla fine, invece di pensarle fin dall'inizio. È come dipingere la casa di bianco dopo averla costruita male, sperando che sembri nuova.
3. Le leggi sono complesse e cambiano, creando confusione tra chi scrive il codice e chi deve assicurarsi che sia legale.

💡 La Soluzione: Il "Ponte" dei Punti di Vista

L'autore dice che non serve inventare nuovi metodi complicati. Serve creare un ponte tra i diversi "punti di vista" (o prospettive) che lavorano sullo stesso progetto.

Immagina di avere quattro gruppi di persone che devono costruire un ponte:

• I Giuristi: Vedono le regole astratte (es. "Il ponte deve essere sicuro per tutti").
• I Manager: Vogliono che il ponte sia economico e veloce.
• Gli Ingegneri dei Requisiti: Vogliono sapere cosa deve fare il ponte.
• Gli Architetti Software: Vogliono sapere come costruirlo tecnicamente.

Spesso, questi gruppi parlano lingue diverse e finiscono per costruire pezzi che non si incastrano. L'autore ha creato un modello chiamato AM4RRE (un po' come un manuale di istruzioni universale o un puzzle gigante).

🧩 Il Modello AM4RRE: Il Puzzle Perfetto

Invece di dire "fai questo, poi fai quello" (un processo rigido), questo modello dice: "Ecco i pezzi del puzzle che ogni gruppo deve avere per parlare la stessa lingua".

Ecco come funziona, con un'analogia culinaria:
Immagina di dover preparare un piatto complesso per un banchetto internazionale (il software).

• Il Giurista ha la lista degli ingredienti vietati (es. "Niente arachidi per allergie").
• Lo Chef deve sapere esattamente quali ingredienti usare e come combinarli.

Il modello AM4RRE è come un ricettario intelligente che traduce la lista degli ingredienti vietati (legge) in istruzioni precise per lo chef (software), assicurandosi che:

1. Nessuno dimentichi un ingrediente (completezza).
2. Nessuno metta due cose che non stanno insieme (coerenza).
3. Se la legge cambia, il ricettario si aggiorna automaticamente per tutti.

🔧 Come si usa nella pratica? (Il "Cucinare")

Il modello non è rigido. Si può "cucinare" su misura per ogni situazione:

1. Adatta alla Legge: Se devi rispettare una legge specifica (es. GDPR), il modello ti dice quali "pezzi" del puzzle devi preparare.
2. Adatta al Progetto: Se il tuo software è diverso, il modello ti aiuta a collegare i pezzi giusti.
3. Adatta agli Obiettivi: Se vuoi essere super sicuro o super veloce, il modello ti aiuta a scegliere quali pezzi enfatizzare.

🚀 Cosa succederà dopo?

L'autore ha già costruito il "progetto" del puzzle (il modello teorico). Ora, la parte finale della sua tesi è testarlo nella vita reale.
Vuole vedere se, dando a un gruppo di giuristi, manager e ingegneri questo "puzzle" da assemblare insieme, riescono a costruire software che è:

• Legale (rispetta le leggi).
• Funzionale (fa quello che deve fare).
• Senza mal di testa (nessuno perde tempo a tradurre le regole).

In sintesi

Questa ricerca dice: "Smettiamola di trattare le leggi come un ostacolo da saltare alla fine. Usiamo un sistema di 'traduzione' (il modello AM4RRE) che metta tutti d'accordo fin dall'inizio, così che costruire software sicuro e legale diventi naturale, come seguire una ricetta perfetta."

È un tentativo di trasformare la burocrazia legale in un'ingegneria precisa, dove ogni pezzo ha il suo posto e tutti sanno esattamente cosa fare.

Sommario tecnico

Ecco un riassunto tecnico dettagliato del paper in italiano, strutturato secondo le sezioni richieste.

Titolo: Verso un'Ingegneria dei Requisiti Normativi Basata su Artefatti e Centrata sulle Prospettive per la Conformità by Design

1. Il Problema

L'integrazione della conformità normativa nell'ingegneria del software (SE) rappresenta una sfida crescente a causa dell'aumento del volume, della complessità e della portata delle normative. Nonostante i numerosi approcci proposti dalla comunità di ricerca, l'industria fatica a integrare sistematicamente questi requisiti nei processi di Ingegneria dei Requisiti (RE) e nel Ciclo di Vita dello Sviluppo Software (SDLC).
Le principali criticità identificate sono:

• Disallineamento metodologico: I metodi RE tradizionali basati su processi sono spesso inadatti alla variabilità dei progetti reali e alle metodologie agili, che favoriscono approcci ad-hoc.
• Natura "retroattiva": I requisiti normativi sono spesso trattati come un ripensamento ("afterthought"), introdotti solo dopo che specifiche di sistema o requisiti iniziali sono già stati definiti.
• Complessità della coordinazione: Esiste una forte dipendenza tra requisiti normativi e non normativi, richiedendo iterazioni complesse.
• Divario di conoscenza: La comunicazione tra esperti legali e ingegneri software è difficile a causa di obiettivi conflittuali, differenze nei punti di vista (viewpoint) e della difficoltà di tradurre concetti legali astratti in specifiche tecniche concrete.
• Mancanza di integrazione: Spesso le organizzazioni gestiscono processi normativi come entità isolate, creando silos che ostacolano la "conformità by design" (conformità integrata nel design).

2. Metodologia

La ricerca è condotta come studio di dottorato empirico, guidato da tre domande di ricerca (RQ) e basato su un approccio misto che combina revisioni sistematiche della letteratura e studi empirici sul campo.

• RQ1 (Stato dell'arte): Analisi tramite Systematic Mapping Study e Systematic Literature Reviews per identificare le sfide della RE normativa e i metodi esistenti per la "Privacy by Design".
• RQ2 (Stato della pratica): Indagine empirica attraverso cinque studi (interviste, focus group con esperti legali, analisi di processi di impatto normativo in grandi imprese) per comprendere come la conformità viene gestita nella realtà e quali ostacoli pratici esistono.
• RQ3 (Sintesi del modello): Sviluppo di un modello concettuale basato su artefatti per coordinare le diverse prospettive (legale, ingegneristica, ecc.).
• Approccio di Sintesi: Il lavoro si basa sull'estensione del modello esistente Artefact Model for Domain-independent Requirements Engineering (AMDiRE), adattandolo al dominio normativo per creare l'AM4RRE (Artefact Model for Regulatory Requirements Engineering).

3. Contributi Chiave

Il contributo principale del paper è la proposta e la sintesi del modello AM4RRE, un approccio basato su artefatti che coordina le diverse prospettive (viewpoint) necessarie per la conformità normativa.

Componenti del modello AM4RRE:
Il modello è strutturato in cinque componenti (C1-C5) che definiscono chi specifica, quali obiettivi persegue, il contesto, la tempistica e il contenuto degli artefatti:

1. Modello dei Ruoli (C1): Definisce responsabilità e qualifiche (es. esperto legale, esperto di dominio, ingegnere dei requisiti, architetto software).
2. Modello degli Obiettivi (C2): Specifica gli obiettivi perseguiti da ciascun ruolo (es. obiettivi legali, gestionali, di ingegneria).
3. Modello del Contesto di Progetto (C3): Include informazioni contestuali e sfide da affrontare.
4. Modello delle Milestone (C4): Stabilisce la sequenza di specifica dei contenuti.
5. Modello dei Contenuti (C5): Definisce il contenuto degli artefatti specifici:
   • Specifica Legale (contiene concetti giuridici e richieste normative).
   • Specifica del Contesto Software.
   • Specifica dei Requisiti.
   • Specifica del Sistema.

Meccanismo di Adattamento (Tailoring):
Il modello non è rigido ma richiede un adattamento sistematico (tailoring) per essere applicato a normative e progetti specifici:

• T1 (Specifico alla Normativa): Identificazione delle istanze di concetti legali nel testo della norma e mappatura sugli attributi necessari.
• T2 (Specifico ai Contenuti): Creazione di relazioni tra i concetti legali e le specifiche ingegneristiche (es. collegare il concetto legale di "soggetto" al concetto tecnico di "stakeholder") per evitare duplicazioni e garantire coerenza.
• T3 (Guidato dagli Obiettivi): Selezione degli elementi da specificare in base agli obiettivi organizzativi prioritari.

4. Risultati

• Analisi delle Sfide: È stato confermato che le sfide principali risiedono nella mancanza di conoscenza di dominio specifica (legale/IT) e nella difficoltà di coordinamento tra prospettive diverse.
• Validazione Preliminare: Studi precedenti hanno dimostrato che gli esperti legali possono concretizzare norme astratte in requisiti specifici utilizzando un processo di interpretazione guidato da concetti legali strutturati.
• Applicabilità del Modello: La validazione con la pratica ha mostrato che l'approccio basato su artefatti permette di tracciare la conformità dalla norma fino all'architettura di sistema. I partecipanti hanno valutato positivamente la capacità del modello di catturare la conoscenza del dominio legale e di garantire la tracciabilità.
• Rilevanza degli Obiettivi: È emerso che è più facile per i praticanti ragionare sugli obiettivi (es. gestione delle sanzioni) rispetto alle caratteristiche dei metodi, giustificando l'inclusione del modello degli obiettivi nel framework.

5. Significatività e Impatto

Questo lavoro è significativo perché offre una soluzione strutturata per colmare il divario tra diritto e ingegneria del software:

• Passaggio da Processi ad Artefatti: Sposta il focus dal "come" (attività) al "cosa" (contenuto degli artefatti), rendendo il processo più adattabile ai contesti agili e dinamici.
• Conformità by Design Sistematica: Fornisce un framework per integrare la conformità normativa direttamente nel ciclo di vita dello sviluppo, evitando approcci ad-hoc o retroattivi.
• Coordinamento delle Prospettive: Risolve il problema della comunicazione tra esperti legali e ingegneri definendo formalmente le relazioni tra i loro artefatti, garantendo coerenza, completezza e correttezza.
• Futuro della Ricerca: Il paper delinea i passi successivi per la validazione finale del modello AM4RRE attraverso esperimenti pratici con checklist e template, mirando a creare uno strumento operativo per l'industria.

In sintesi, il paper propone un modello teorico-pratico che trasforma la conformità normativa da un ostacolo burocratico in un requisito ingegneristico gestibile, tracciabile e integrato nel design del software.