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

Este artigo relata a síntese e busca feedback sobre o Modelo de Artefatos para Engenharia de Requisitos Regulatórios (AM4RRE), uma abordagem proposta para integrar a conformidade por projeto ao ciclo de vida de desenvolvimento de software, superando os desafios de coordenação entre múltiplas perspectivas e a falta de processos sistemáticos na indústria.

O essencial

Imagine que você é o arquiteto de um prédio muito complexo. Agora, imagine que, antes de colocar o primeiro tijolo, você precisa garantir que seu prédio obedeça a uma lista gigantesca de leis: leis de segurança, leis ambientais, leis de acessibilidade e até leis que dizem como as pessoas devem se sentir ao entrar no prédio.

Esse é o desafio que o pesquisador Oleksandr Kosenkov está tentando resolver no mundo do desenvolvimento de software. O artigo dele fala sobre como fazer com que os programas de computador (software) nasçam já "legais", ou seja, em conformidade com as regras desde o primeiro dia.

Aqui está a explicação do trabalho dele, traduzida para uma linguagem simples e com algumas analogias divertidas:

1. O Problema: A Torre de Babel entre Advogados e Programadores

Hoje, existem muitas leis novas (como a LGPD no Brasil ou o GDPR na Europa) que dizem como as empresas devem tratar dados e criar sistemas. O problema é que advogados e programadores falam línguas completamente diferentes.

• O Advogado fala em termos abstratos: "O sujeito deve ter consentimento".
• O Programador precisa de instruções concretas: "Criar um botão 'Aceitar' que salva um registro no banco de dados".

Atualmente, as empresas tentam resolver isso de um jeito bagunçado: o advogado entrega um texto gigante de 100 páginas, e a equipe de TI tenta adivinhar o que fazer. Isso gera erros, retrabalho e sistemas que podem ser multados. É como tentar construir uma casa usando um manual de instruções escrito em um código secreto que ninguém decifrou direito.

2. A Solução Proposta: O "Mapa de Tesouro" (AM4RRE)

O autor criou um modelo chamado AM4RRE. Pense nele como um Mapa de Tesouro ou um Kit de Montagem Universal que conecta os dois mundos.

Em vez de apenas listar tarefas (como "fazer reunião"), o modelo foca nos Artefatos (os documentos e peças que precisam ser criados). Ele diz: "Para construir essa casa segura, precisamos de esta peça de madeira (requisito legal) que se encaixa perfeitamente com este parafuso (requisito técnico)".

O modelo organiza tudo em 5 partes principais:

1. Quem faz o quê? (Quem é o advogado, quem é o engenheiro).
2. O que queremos? (Os objetivos de cada um).
3. O contexto? (Quais leis específicas estamos seguindo?).
4. Quando? (A ordem das coisas).
5. O que vamos escrever? (O conteúdo dos documentos).

3. A Grande Inovação: Traduzindo o "Juridiquês" para "Techês"

A parte mais legal do trabalho é como ele lida com a tradução. O autor percebeu que não adianta apenas jogar o texto da lei no computador. É preciso fazer um processo de Tailoring (como se fosse um alfaiate ajustando um terno).

Imagine que a lei é um tecido gigante e caro. O modelo do autor ensina a equipe a:

• Cortar o tecido (Tailoring T1): Identificar exatamente quais partes da lei se aplicam ao projeto atual.
• Costurar as peças (Tailoring T2): Conectar o conceito legal (ex: "Direito à privacidade") com o conceito técnico (ex: "Criptografia de dados"). Se o técnico não tiver o conceito de "privacidade" no seu plano, o modelo diz: "Ei, você precisa adicionar isso aqui, senão o terno não fecha!".
• Focar no objetivo (Tailoring T3): Escolher quais partes do terno são mais importantes para o cliente.

Isso evita que o programador crie duas coisas iguais em lugares diferentes (redundância) e garante que nada seja esquecido.

4. O Futuro: Testando o Mapa

O autor ainda está no final da sua jornada de doutorado. Ele já desenhou o mapa (o modelo), mas agora precisa ver se ele funciona na vida real.

Ele planeja fazer um "treino" com profissionais reais. Imagine um jogo de tabuleiro onde quatro pessoas sentam à mesa: uma advogada, um gerente, um engenheiro de requisitos e um arquiteto de software. Elas recebem um caso real (como "criar um app de banco") e devem usar os modelos e listas de verificação (checklists) criadas pelo autor para construir o sistema juntos.

O objetivo é ver se, usando esse "Mapa de Tesouro", eles conseguem construir o sistema mais rápido, sem erros e, o mais importante, sem quebrar a lei.

Resumo em uma frase

Este artigo propõe uma "ponte de tradução" feita de documentos e modelos que ajuda advogados e programadores a trabalharem juntos desde o início, garantindo que o software seja construído de forma legal, segura e sem dor de cabeça, transformando regras complexas em instruções claras de construção.

Resumo técnico

Aqui está um resumo técnico detalhado do artigo "Towards Viewpoint-centric Artifact-based Regulatory Requirements Engineering for Compliance by Design", apresentado em português:

Título:

Engenharia de Requisitos Regulatórios Centrada em Perspectivas e Baseada em Artefatos para Conformidade por Design

1. Problema Identificado

A engenharia de requisitos (ER) regulatória — o processo de transformar regulamentações em requisitos de software para garantir conformidade — enfrenta desafios críticos devido ao volume crescente, complexidade e escopo expandido das leis.

• Desconexão Prática: Embora existam muitas abordagens acadêmicas, a indústria ainda lida com a conformidade de forma ad-hoc ou através de processos regulatórios isolados, sem integração sistêmica no Ciclo de Vida de Desenvolvimento de Software (SDLC).
• Desafios de Integração: A conformidade por design exige que os controles sejam implementados em todo o SDLC. No entanto, a integração é dificultada por:
  • A necessidade de consistência, completude e correção em ambientes ágeis dinâmicos.
  • Requisitos regulatórios serem frequentemente tratados como uma "reflexão tardia" (após a definição inicial de requisitos).
  • Conflitos e iterações entre requisitos regulatórios e não regulatórios.
  • Dificuldade de comunicação e tradução entre diferentes perspectivas (especialistas legais vs. engenheiros de software), devido à natureza abstrata das leis e à falta de conhecimento jurídico profundo nas equipes de TI.
  • A dificuldade de automatizar a interação entre essas perspectivas.

2. Metodologia

O estudo de doutorado adota uma abordagem empírica e iterativa, guiada por três perguntas de pesquisa (RQs), combinando revisão sistemática da literatura e pesquisa empírica:

• RQ1 (Estado da Arte): Realização de um estudo de mapeamento sistemático e revisões sistemáticas da literatura para identificar desafios na ER regulatória e métodos de "Privacidade por Design" (PbD).
• RQ2 (Estado da Prática): Execução de cinco estudos empíricos (entrevistas, grupos focais com especialistas legais e engenheiros, e análise de processos de impacto regulatório) para entender como a conformidade é implementada na indústria e quais métodos são necessários.
• RQ3 (Síntese do Modelo): Desenvolvimento e validação conceitual de um novo modelo baseado em artefatos para coordenar as diferentes perspectivas envolvidas.
• Abordagem de Validação: O autor utiliza validação walkthrough com especialistas legais e validação com praticantes de PbD para refinar o modelo conceitual antes da fase final de validação prática.

3. Principais Contribuições

A contribuição central do trabalho é o AM4RRE (Artefact Model for Regulatory Requirements Engineering), um modelo conceitual que substitui abordagens baseadas em atividades por uma abordagem baseada em artefatos para coordenar perspectivas.

O AM4RRE estende o modelo existente AMDiRE (Artefact Model for Domain-independent Requirements Engineering) e é composto por cinco componentes principais:

1. Modelo de Papéis (C1): Define responsabilidades de especialistas legais, especialistas de domínio, engenheiros de requisitos e arquitetos de software.
2. Modelo de Objetivos (C2): Especifica os objetivos de cada papel na ER regulatória.
3. Modelo de Contexto do Projeto (C3): Inclui desafios e atividades de ER.
4. Modelo de Marcos (C4): Estabelece a sequência de especificação.
5. Modelo de Conteúdo (C5): O núcleo do modelo. Define o conteúdo das especificações (Especificação Legal, Contexto de Software, Requisitos e Especificação de Sistema) compostos por itens de conteúdo e conceitos.

Mecanismo de Coordenação:
O modelo foca na troca de informações entre as perspectivas (Legal, Negócio, Requisitos e Arquitetura) através da especificação de artefatos, garantindo que o conhecimento jurídico seja concretizado em requisitos e arquitetura de software sem duplicação ou perda de informação.

Processo de Adaptação (Tailoring):
O modelo prevê três níveis de adaptação para ser aplicável na prática:

• T1 (Específico à Regulamentação): Anotação de textos legais para identificar instâncias de conceitos jurídicos e atributos necessários.
• T2 (Específico ao Conteúdo): Estabelecimento de relações entre conceitos legais e conceitos de engenharia (ex: ligar "sujeito de dados" legal a "stakeholder" no contexto de software) para evitar duplicação e garantir consistência.
• T3 (Orientado a Objetivos): Seleção de itens de conteúdo com base nos objetivos organizacionais (ex: se o objetivo é gerenciar sanções, o item "sanção" deve ser especificado).

4. Resultados Preliminares

• Identificação de Lacunas: Confirmou-se que a ER regulatória não pode ser resolvida apenas com a inclusão de especialistas legais ou técnicas de ER padrão; é necessária uma coordenação profunda de perspectivas.
• Validação do Modelo Legal: A especificação da perspectiva legal (contexto e demandas) foi validada com pesquisadores jurídicos, recebendo feedback positivo sobre sua capacidade de concretizar normas abstratas.
• Aplicabilidade em PbD: A validação com praticantes de "Privacidade por Design" (GDPR) indicou que a abordagem de alocação de instâncias de conceitos entre níveis de requisitos e sistema é viável para capturar conhecimento jurídico.
• Fatores Críticos de Sucesso: As características mais importantes para métodos de ER em conformidade são a captura de conhecimento de domínio legal, a transparência das especificações e a rastreabilidade.

5. Significado e Impacto

• Mudança de Paradigma: O trabalho propõe uma mudança de abordagens baseadas em processos/atividades para abordagens baseadas em artefatos, o que é mais adequado para lidar com a complexidade e a variabilidade de projetos de software reais, especialmente em metodologias ágeis.
• Conformidade por Design Sistêmica: Oferece um caminho prático para integrar a conformidade legal diretamente no SDLC, evitando processos paralelos e isolados que geram retrabalho e inconsistências.
• Ponte entre Domínios: O AM4RRE atua como uma "ponte" semântica entre o domínio jurídico (abstrato) e o domínio de engenharia de software (concreto), facilitando a comunicação e a tradução de requisitos.
• Futuro: O estudo aponta para a necessidade de operacionalizar o modelo através de listas de verificação (checklists) e templates, com planos de validação final envolvendo profissionais experientes em engenharia de privacidade em cenários de caso de uso.

Em resumo, este artigo apresenta uma estrutura teórica e prática robusta para superar a fragmentação entre conformidade legal e desenvolvimento de software, propondo um modelo de artefatos que permite uma gestão coordenada, consistente e verificável dos requisitos regulatórios.