Apresentação - GenNormas - Dissertação (2)

(1)

GENNORMAS:

UM PROCESSO GENÉRICO PARA A

CONFORMIDADE LEGAL NA ENGENHARIA DE REQUISITOS

Defesa de Dissertação de Mestrado Hidelberg Oliveira Albuquerque

Orientadora: Carla Silva Co-Orientadora: Danielle Rousy

João Pessoa, 2014

UNIVERSIDADE FEDERAL DA PARAÍBA (UFPB) CENTRO DE INFORMÁTICA (CI)

(2)

Agenda

• Introdução

• Motivação

• Objetivos

• Metodologia

• Desenvolvimento

• Proposta

• Conclusões

2

(3)

Introdução

• Leis regulam os estados de mundo da sociedade.

• No âmbito particular: os indivíduos.

• No âmbito organizacional: práticas de negócio.

• Leis têm crescido como fonte de requisitos.

• Exigência dos departamentos governamentais.

• Porém, leis NÃO SÃO requisitos (desejos) dos stakeholders.

• Stakeholders escolhem seus requisitos e objetivos.

• Leis são imposições feitas aos stakeholders.

• Leis podem contradizer os interesses dos stakeholders¹.

3 ¹ Siena, A.. Engineering Law-Compliant Requirements. The Nòmos Framework.

(4)

Motivação

• Garantir que os requisitos de software ou de processo de

negócio estejam sob a Conformidade Legal com as

legislações relacionadas ao escopo da aplicação ou ao

domínio do negócio, sem deixar de satisfazer as necessidades

dos stakeholders.

• Área da Pesquisa:

• Elicitação, Análise e Especificação de Requisitos de Software e/ou Processos de Negócio.

• A Conformidade Legal (CL) dos processos de negócios e dos

requisitos de software pode reduzir o impacto de mudanças,

minimizar violações legais e evitar transtornos financeiros e

judiciais¹.

4 ¹ Gordon, D., Breaux, T.. Assessing Regulatory Change through Legal Requirements

(5)

Objetivo Geral

Adaptar o processo do Framework Nòmos para que ele se torne menos dependente da linguagem de modelagem i*, e possa ser usado para alcançar a conformidade legal em especificações de requisitos de software ou de processos de negócio descritas em diversas linguagens de modelagem.

1. Realizar uma revisão dos trabalhos relacionados à CL na ER;

2. Criar um modelo de dependência legal para o domínio do comércio eletrônico. 3. Aplicar o Nòmos ao domínio de e-commerce, para analisar a aplicabilidade do

seu processo e levantar possíveis limitações;

4. Adaptar o Nòmos, no intuito de torná-lo genérico e aplicável à outras linguagens de elicitação de requisitos e processos de negócio;

5. Aplicar o processo proposto ao exemplo do e-commerce em modelos já aceitos na indústria.

5

(6)

Metodologia

1. Revisão da literatura:

• Influência das Leis no desenvolvimento de software e processos de negócio. • Framework Nòmos.

2. Pesquisa nas leis brasileiras.

• Código de Defesa do Consumidor e a Lei do e-commerce

3. Aplicação do Nòmos à um exemplo de e-commerce.

4. Adaptação do Nòmos, para torná-lo independente de linguagem.

• Nossa proposta: GenNormas.

5. Aplicação do GenNormas ao exemplo de e-commerce, utilizando

linguagens consolidadas na indústria.

• BPMN, Diagrama de Casos de Uso e User Story.

(7)

(8)

Framework Nòmos¹

• Framework de elicitação de requisitos legais, utilizando os

conceitos do Framework i*.

• Fornece uma metodologia para a análise da CL, procurando

alinhar os requisitos dos stakeholders às exigências legais.

• Fase 1: Processo de Elicitação

• Requisitos dos Stakeholders e Legislação relacionada

• Fase 2: Processo de Modelagem

• Refinamento e Operacionalização dos Requisitos

• Fase 3: Processo de Verificação da Conformidade

• Conformidade Legal dos documentos gerados e da solução • Aceitabilidade dos novos requisitos pelos stakeholders

8 ¹ Siena, A.. Engineering Law-Compliant Requirements. The Nòmos Framework. Ph.D. thesis.

(9)

Modelo Final de Requisitos de Conformidade em

Nòmos

Forne cedor em bodi es Consu midor em bo die_s

(10)

Modelo Final de Requisitos de Conformidade em

Nòmos

Ator Ator

embodies

Relação de Personificação Relação de Dependência Legal

Lei Tarefa Relação de Realização AP Artefato de Prova Fornecedor em bodi es Legenda

(11)

Aplicação do Nòmos ao e-commerce

• Aplicação fora do domínio original foi bem sucedido.

• O processo do Nòmos:

• Claro e sistemático, para ser aplicado a outro domínio

(e-commerce).

• O processo original não precisou de extensões.

• Por outro lado:

• Nòmos mantêm forte acoplamento com o framework i*

• Exige do profissional o conhecimento prévio

• O i* não é muito popular na indústria¹.

• Estes fatores podem prejudicar a adoção do Nòmos na indústria.

11 ¹ YU, E., et al.. Practical Applications of i* in Industry: The State of the Art. In:

(12)

(13)

O GenNormas

• Adaptar o processo do Framework Nòmos para que ele se torne

menos dependente da linguagem de modelagem i*.

• Adoção do processo na indústria através de outras linguagens de requisitos.

• Originalmente: GenNòmos¹

• Nossa proposta elegeu partes do Nòmos imutáveis, e outras que

devem ser adaptáveis à linguagem de modelagem escolhida.

• Opção por um processo genérico:

• Para os profissionais de requisitos: liberdade para usar qualquer linguagem

• Para os stakeholders: facilitar a comunicação

13¹ ALBUQUERQUE, H.O., SILVA, C., SILVA, D. R. D. GenNòmos: um processo genérico

para utilização do framework Nòmos. In: X Simpósio Brasileiro de Sist. de Informação, 2014

(14)

Processo

(15)

Aplicação do GenNormas ao e-commerce

• Critério para seleção do domínio

• Aumento das transações online (e das reclamações)

• Lei sobre o Comércio Eletrônico: Decreto Federal nº 7.962, de

05/2013

• Critério de seleção das linguagens:

• Facilidade de comunicação.

• Aceitação no mercado.

• Linguagens escolhidas

• Diagrama de processo de negócio, em BPMN (NòmosBPMN¹) • Diagrama de caso de uso, da UML

• Técnica ágil da User Story

• Causar o mínimo de impacto nas ferramentas CASE.

15

¹ ALBUQUERQUE, H.O., SILVA, C., SILVA, D. R. D. NòmosBPMN: Adaptando o Nòmos para a Modelagem

de Processos de Negócio. In: CibSE2014, XVII Congresso Ibero-Americano em Eng. de Software, Pucón-Chile, 2014.

(16)

Processo

• Fase 1: Elicitação de Requisitos

• Etapa 1: Elicitação dos Requisitos dos Stakeholders

• Liberdade para aplicação de quaisquer técnicas.

• Para o e-commerce: BPMN, Diagrama de Caso de Uso e UserStory

(17)

(18)

Requisitos Iniciais em Diagrama de Casos de Uso

(19)

Requisitos Iniciais em User Story

“Como <papel>, eu quero <ação> para <objetivo>”

(20)

Processo

• Fase 1: Elicitação de Requisitos

• Etapa 2: Elicitação de Normas ou Leis

• Seleção e Mapeamento das Leis

• Transposição da etapa original “Identificação de Alternativas Legais”. • Exemplo: Npa > NPb

• Modelos utilizados:

• Modelo NPx

(21)

Processo

• Fase 1: Elicitação de Requisitos

• Etapa 2: Elicitação de Normas ou Leis

• Modelos utilizados:

• Representação das dependências legais (igual ao Nòmos)

(22)

Processo

• Representação das Dependências Legais no e-commerce

(23)

Processo

• Fase 2: Processo de Modelagem

• Etapa 1: Personificação de Sujeitos Legais

• Identificação dos atores/entidades do processo como sujeitos legais.

* <Entity> embodies <SujeitoLegal> <<Legal Conformance Story>>

Personificação em User Story

*Extensão de Generalização de Atores * Extensão: Pacotes Rotulados

Personificação em Diagrama de Caso de Uso

Ator --> embodies --> Sujeito Legal

(24)

Processo

• Fase 2: Processo de Modelagem

• Etapa 2: Busca por realizações.

• Busca e refinamento de requisitos para conformidade legal.

• Para cada NP, todos os elementos devem ser investigados • Realização, Violação ou Afetação.

• Regras gerais:

• não podem haver requisitos que se oponham as leis (risco imediato) • não podem haver leis sem realizações (risco grave)

• não pode haver cumprimento parcial de leis (risco leve)

• não pode haver elemento que seja afetado ou afete uma realização encontrada.

• Critérios para CL:

• Prova de Cumprimento: cada NP deve ter, pelo menos, uma realização. • Prova de Conformidade: não há nenhum elemento em situação irregular

(violação ou afetação) 24

(25)

Processo

• Fase 2: Processo de Modelagem

• Etapa 2: Busca por realizações.

• Representação:

25

(26)

Processo

• Fase 2: Processo de Modelagem

• Etapa 3: Operacionalização de Realizações

• Detalhamento ou refinamento dos objetivos de alto nível em tarefas de execução.

• Conforme o modelo utilizado, esta tarefa pode ser omitida ou

readaptada. _{Como <papel>, eu quero}_<ação>

para <objetivo>

Realizada na definição da US

Operacionalização em User Story Operacionalização em BPMN

1. Elementos como tarefas, eventos expressam o comportamento do sistema. 2. Elementos passaram por

refinamentos para realização.

3. Etapa não foi utilizada.

1. Diagrama expressa o comportamento desejado pelo

cliente.

2. DCU não detalha as condições para realizar o comportamento. 3. Uso da Descrição do Caso de

Uso para esta etapa.

(27)

Processo

• Fase 2: Processo de Modelagem

• Etapa 4: Identificação de Artefatos de Prova

• Necessidade de provar que o projeto está sob a Conformidade Legal.

• Para um tribunal, o que importa é a execução da aplicação/processo.

• Inserção e identificação de recursos que comprovem a CL, que deverão ser implementados posteriormente.

• Se o uso deste artefato for desnecessário, esta etapa pode ser omitida.

27

Artefatos de Prova em User Story Artefatos de Prova em BPMN Artefatos de Prova em Diagrama de Casos de Uso

(28)

Processo

• Fase 3: Verificação da Conformidade

• Validar a conformidade e cumprimento legais.

• Validar os artefatos produzidos

• se estão de acordo com processo (evitar discrepâncias)

• Validar se os requisitos são aceitos pelos stakeholders.

• Se qualquer uma das verificações falhar, o processo volta para

a modelagem.

• Se todas forem aceitas:

• Conformidade Legal é determinada • O processo é finalizado.

(29)

Documento Final - Requisitos de Conformidade do GenNormas ao e-commerce, em BPMN

(30)

(31)

Documento Final - Requisitos de Conformidade do GenNormas ao e-commerce, em UserStory

(32)

Conclusões

• Contribuições

1. Revisão dos trabalhos relacionados ao tema CL e ER

2. Aplicação do Framework Nòmos ao domínio do e-commerce.

3. Mapeamento da Lei do e-commerce no modelo de dependência legal. 4. Proposta do GenNormas para utilização do processo Nòmos na

indústria, utilizando qualquer linguagem de requisitos ou processo de negócio.

• Padronização de um processo que busca a CL, e não de uma linguagem específica

5. Aplicação do GenNormas a modelos aceitos e utilizados na indústria

• Levantamento de limitações nas linguagens, do ponto de vista da CL

• Sugestão de diretrizes de uso e extensões nos modelos para representar a CL 32

(33)

Conclusões

• Limitações

• As etapas de levantamento, seleção e mapeamento das leis é feita de maneira manual.

• Em virtude da complexidade e falta de padronização das leis.

• Pode demandar tempo e custo alto, relacionado ao uso de especialistas no Direito. • Busca híbrida (manual +automatizada) seria um benefício.

• BREAUX e POWERS (2009)¹

• As etapas de negociação e refinamento dos requisitos são basicamente discursivas.

• O GenNormas não apresenta diretrizes para guiar as discussões.

• Pode demandar discussões improdutivas, além de tempo e custo desnecessários.

• INGOLGO et al. (2013)²

33

¹ BREAUX, T., POWERS, P.. Early Studies in Acquiring Evidentiary, Reusable Business Process Models for Legal Compliance. 6th International Conference on Information Technology: New Generations. 2009. ² INGOLFO, S. et al. Arguing regulatory compliance of software requirements. In: Data & Knowledge Engineering, 2013

(34)

Conclusões

• Limitações

• No contexto da rastreabilidade e acompanhamento de

modificações nos requisitos e/ou nas leis.

• Leis e Requisitos podem ser atualizados, ou eliminados do projeto.

• Mudanças podem causar impacto na conformidade da solução.

• O GenNormas não prevê diretrizes claras para analisar e avaliar o impacto destas mudanças no projeto.