Abordagem de Apoio ao Reúso de Requisitos em …...Abordagem de Apoio ao Reúso de Requisitos em...

Universidade Federal de Mato Grosso do Sul

Faculdade de Computação

Programa de Mestrado em Ciência da Computação

Doglas Wendll Sorgatto

Abordagem de Apoio ao Reúso de Requisitos

em Linhas de Processos de Negócio

Campo Grande – MS

Maio, 2018

Universidade Federal de Mato Grosso do Sul

Faculdade de Computação

Programa de Mestrado em Ciência da Computação

Doglas Wendll Sorgatto

Abordagem de Apoio ao Reúso de Requisitos em Linhas

de Processos de Negócio

Dissertação apresentada ao Programa de Mes-trado em Ciência da Computação da Faculdadede Computação, mantido pela Fundação Univer-sidade Federal do Mato Grosso do Sul, como re-quisito para obtenção do título de mestre. Áreade Concentração: Engenharia de Software.

Orientadora: Profa. Dra. Maria Istela Cagnin Machado

Campo Grande – MS

Maio, 2018

Agradecimentos

Agradeço primeiramente a Deus que me concedeu paciência, saúde, sabedoria e amigos

para que este trabalho de mestrado tomasse forma e chegasse à conclusão.

Entre os amigos que me ajudaram devo muitos agradecimentos a minha orientadora,

Profa Maria Istela, que teve paciência, usou de seu tempo livre para corrigir meus rascunhos,

escutou reclamações, apontou caminhos, cumprindo com muito esmero sua nobre função.

Não posso esquecer a paciência e o carinho de minha adorável esposa, Gislaine Siqueira,

que suportou os momentos de ausência, cuidou de nossas adoráveis meninas, Lorena (7 anos),

Laura (3 anos) e Lívia (2 anos), enquanto eu gestava este projeto pessoal e que não me deixou de-

sanimar quando a preguiça tomava corpo. Que Deus recompense seu carinho, amor e dedicação

à família.

Aos meus pais, Eliseu e Carly, que não tiveram a chance de estudar em sua época mas

que sempre estimularam o estudo como forma de conquistar uma vida melhor e não pouparam

esforços para ver seus filhos formados.

Aos colegas de faculdade Bruno Nazário e Augusto Ribas. O primeiro porque se tornou

amigo e me ensinou a não reclamar dos problemas e das dificuldades, além de me cobrar para

fazer todos os códigos, trabalhos e apresentações com muito capricho, afinal a beleza dá um

pontinho extra. O segundo, um biólogo que tem na praticidade, objetividade e no rigor metodo-

lógico sua marca registrada, valores que procuro imitar em meu trabalho e nesta pesquisa.

Aos diretores e colegas das escolas em que leciono, que permitiram que eu utilizasse o

tempo de planejamento escolar para redigir este trabalho, participar de reuniões com a orienta-

dora, assistir as aulas do mestrado e entenderam a necessidade de substitutos que precisei enviar

em algumas situações.

“A sabedoria inspira a vida aos seus filhos;

ela toma sob a sua proteção aqueles que a procuram;

ela os precede no caminho da justiça.”

(Bíblia Sagrada, Eclesiástico 4, 12)

ResumoSORGATTO, Doglas Wendll. Abordagem de Apoio ao Reúso de Requisitos em Linhas de

Processos de Negócio. Maio, 2018. 178 f. Dissertação (Mestrado em Ciências da

Computação) – FACOM - Faculdade de Computação, Universidade Federal de Mato Grosso

do Sul, Campo Grande, 2018.

Osmodelos de processos de negócio auxiliam a elicitação de requisitos pois, como facilitam o en-

tendimento do negócio para o qual o software será desenvolvido, diminuem o tempo gasto nesta

fase do processo de desenvolvimento e melhoram a qualidade dos requisitos elicitados, pois

estes se alinham mais ao negócio. Este potencial é ampliado quando se utilizam as Linhas de

Processos de Negócio (LPNs), um conjunto de modelos de processos de negócio representados

em artefatos que documentam as variabilidades e comunalidades de um domínio e constituem

uma técnica de reúso no contexto de modelos de processos de negócio. Ao reusar os modelos

de processos de negócio é possível também reusar os requisitos associados aos elementos re-

presentados nestes modelos. Um desafio que ocorre ao reusar estes requisitos é que eles podem

estar duplicados, ambíguos, incompletos ou possuírem conflitos. Assim, para possibilitar a elici-

tação, o reúso e a especificação de requisitos de um determinado domínio de negócio é proposta

a abordagem ARReq – Apoio ao Reúso de Requisitos em Linhas de Processos de Negócio que

é genérica, se aplicando a qualquer abordagem de gestão de LPNs, independente da técnica de

elicitação de requisitos, capaz de reduzir os principais problemas de requisitos e de especificar

os requisitos funcionais, não funcionais e regras de negócio em dois formatos distintos (estórias

de usuário e documento de requisitos), além de possibilitar a rastreabilidade entre os requisitos e

o modelo de processo de negócio, instância da linha. Para avaliar a aplicabilidade da ARReq foi

planejada uma avaliação baseada em GQM (Goal Question Metric) utilizando como base uma

LPN com vários tipos de variabilidade, que forneceu como resultado a indicação da satisfação

dos objetivos propostos.

Palavras-chaves: Engenharia de Requisitos, Reúso, Linha de Processos de Negócio.

AbstractSORGATTO, Doglas Wendll. An Approach to Support on Reuse of Requirements in

Business Process Lines. Maio, 2018. 178 f. Dissertation (Master Degree in Computer

Science) – FACOM - Faculty of Computing, Federal University of Mato Grosso do Sul,

Campo Grande, 2018.

Business process models help to elicit requirements because, as they facilitate the understanding

of the business for which the software will be developed, they reduce the time spent in this phase

of the development process and improve the quality of the requirements elicited, since these are

more aligned to business. This potential is enlarged when using Business Process Lines (BPL),

a set of business process models represented in artifacts that depict the variabilities and com-

monalities of a domain and constitute a reuse technique in the context of business process mod-

els. By reusing business process models it is also possible to reuse the requirements associated

with the elements represented in these models. One challenge that occurs when reusing these

requirements is that they may be duplicate, ambiguous, incomplete, or have conflicts. Thus, in

order to enable the elicitation, reuse and specification of requirements of a particular business

domain, the ARReq - (Support for Requirements Reuse in Business Process Lines) approach is

proposed, which is generic, applying to any LPN management approach, independent of the re-

quirements elicitation technique, able to reduce the main requirements problems and to specify

functional, non-functional requirements and business rules in two distinct formats (user stories

and requirements document), in addition to enabling the traceability between the requirements

and the business process model, which is the instance of the line. To assess the applicability

of the ARReq, an assessment based on GQM (Goal Question Metric) was planned based on an

LPN with various types of variability, that provided an indication of satisfaction of the proposed

objectives.

Keywords: Requirement Engineering, Reuse, Business Process Line.

Lista de ilustrações

Figura 1 – Colaborações para formação da proposta. . . . . . . . . . . . . . . . . . . . 27

Figura 2 – Fases da metodologia utilizada. . . . . . . . . . . . . . . . . . . . . . . . . 29

Figura 3 – Estrutura da abordagem. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Figura 4 – Localização conceitual da ARReq. . . . . . . . . . . . . . . . . . . . . . . 33

Figura 5 – Processo de engenharia de requisitos. . . . . . . . . . . . . . . . . . . . . . 35

Figura 6 – Exemplo de Matriz de Rastreabilidade. . . . . . . . . . . . . . . . . . . . . 39

Figura 7 – Exemplo de diagrama de processo de negócio em BPMN. . . . . . . . . . . 42

Figura 8 – Visão geral do funcionamento do SRPD. . . . . . . . . . . . . . . . . . . . 43

Figura 9 – Visão geral da aplicação da Técnica REMO. . . . . . . . . . . . . . . . . . 44

Figura 10 – Exemplo de elicitação de requisitos. . . . . . . . . . . . . . . . . . . . . . 45

Figura 11 – Heurísticas REMO – Versão 1.3. . . . . . . . . . . . . . . . . . . . . . . . 47

Figura 12 – Modelo esquemático dos processos da GLPN. . . . . . . . . . . . . . . . . 49

Figura 13 – Exemplo de Modelo de Features. . . . . . . . . . . . . . . . . . . . . . . . 51

Figura 14 – Exemplo de TMPN. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

Figura 15 – Exemplo de PDO. Adaptado de Terenciani (2015). . . . . . . . . . . . . . . 53

Figura 16 – Metodologia para realizar o snowballing backward. . . . . . . . . . . . . . 63

Figura 17 – Trabalhos publicados por ano. . . . . . . . . . . . . . . . . . . . . . . . . . 64

Figura 18 – Distribuição dos resultados nos trabalhos selecionados. . . . . . . . . . . . 69

Figura 19 – Estrutura da LPN com a abordagem. . . . . . . . . . . . . . . . . . . . . . 73

Figura 20 – Modelo esquemático dos conceitos. . . . . . . . . . . . . . . . . . . . . . . 74

Figura 21 – Subprocesso de Elicitação de Requisitos em LPN. . . . . . . . . . . . . . . 75

Figura 22 – Subprocesso de Especificação de Requisitos. . . . . . . . . . . . . . . . . . 76

Figura 23 – Modelo de features – Vendas. . . . . . . . . . . . . . . . . . . . . . . . . . 78

Figura 24 – LPN1 em BPMN*. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

Figura 25 – LPN2 baseado em Gröner et al. (2013). . . . . . . . . . . . . . . . . . . . . 80

Figura 26 – Modelo ortogonal – Vendas. . . . . . . . . . . . . . . . . . . . . . . . . . . 80

Figura 27 – LPN3 em vrBPMN. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

Figura 28 – LPN4 baseado em Yousfi et al. (2016). . . . . . . . . . . . . . . . . . . . . 82

Figura 29 – Subprocesso de Elicitação de Requisitos, expandido. . . . . . . . . . . . . . 84

Figura 30 – Instância da LPN de vendas. . . . . . . . . . . . . . . . . . . . . . . . . . 93

Figura 31 – Atividade Preparar Especificação de Requisitos, expandida. . . . . . . . . 95

Figura 32 – Atividade Verificar Pontos de Variação, expandida. . . . . . . . . . . . . . 96

Figura 33 – Atividade Configurar Variáveis, expandida. . . . . . . . . . . . . . . . . . 98

Figura 34 – Exemplo para atividade Configurar de Variáveis. . . . . . . . . . . . . . . 99

Figura 35 – Atividade Gerar Especificação de Requisitos, expandida. . . . . . . . . . . 102

Figura 36 – Objetivos, questões e métricas para avaliação da ARReq. . . . . . . . . . . 111

Figura 37 – Integração entre GLPN e ARReq. . . . . . . . . . . . . . . . . . . . . . . . 112

Figura 38 – Modelo de features – Locação. . . . . . . . . . . . . . . . . . . . . . . . . 112

Figura 39 – TMPN do domínio de locação. . . . . . . . . . . . . . . . . . . . . . . . . 113

Figura 40 – Instância do domínio de locação. . . . . . . . . . . . . . . . . . . . . . . . 118

Lista de tabelas

Tabela 1 – Elementos da notação BPMN*. . . . . . . . . . . . . . . . . . . . . . . . . 52

Tabela 2 – Estudos retornados pelas máquinas de busca das bibliotecas digitais. . . . . 59

Tabela 3 – Resumo do processo de aplicação dos critérios de inclusão e exclusão. . . . 60

Tabela 4 – Quantidade de trabalhos após a leitura do resumo, introdução e conclusão. . 60

Tabela 5 – Quantitativo dos trabalhos após o snowballing backward. . . . . . . . . . . 63

Tabela 6 – Matriz de Rastreabilidade da LPN de vendas. . . . . . . . . . . . . . . . . 88

Tabela 7 – Matriz de Rastreabilidade da LPN de vendas – Atualizada. . . . . . . . . . 92

Tabela 8 – Exemplo de Matriz da instância – Vendas. . . . . . . . . . . . . . . . . . . 95

Tabela 9 – Matriz de Rastreabilidade – Vendas. . . . . . . . . . . . . . . . . . . . . . 106

Tabela 10 – Matriz de Rastreabilidade da LPN – Locação. . . . . . . . . . . . . . . . . 115

Tabela 11 – Matriz da instância – Locação. . . . . . . . . . . . . . . . . . . . . . . . . 119

Tabela 12 – Matriz de Rastreabilidade – Locação. . . . . . . . . . . . . . . . . . . . . . 125

Tabela 13 – Resumo dos resultados obtidos com a avaliação. . . . . . . . . . . . . . . . 126

Tabela 14 – Relação dos Requisitos Elicitados – Locação. . . . . . . . . . . . . . . . . 145

Tabela 15 – Arquétipo de Requisitos – Locação. . . . . . . . . . . . . . . . . . . . . . 149

Tabela 16 – Matriz de Rastreabilidade da LPN – Locação. . . . . . . . . . . . . . . . . 155

Tabela 17 – Requisitos da instância – Locação. . . . . . . . . . . . . . . . . . . . . . . 157

Tabela 18 – Matriz da instância – Locação. . . . . . . . . . . . . . . . . . . . . . . . . 161

Tabela 19 – Requisitos da instância – Locação – Atualizado. . . . . . . . . . . . . . . . 163

Tabela 20 – Matriz da instância – Atualizada – Locação. . . . . . . . . . . . . . . . . . 167

Tabela 21 – Modelo de Requisitos – Estória de Usuário. . . . . . . . . . . . . . . . . . 169

Tabela 22 – Modelo de Requisitos – Documento de Requisitos. . . . . . . . . . . . . . 173

Tabela 23 – Matriz de Rastreabilidade. . . . . . . . . . . . . . . . . . . . . . . . . . . . 177

Lista de quadros

Quadro 1 – Questões de pesquisa. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

Quadro 2 – String de busca padrão. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

Quadro 3 – Critérios de inclusão e exclusão. . . . . . . . . . . . . . . . . . . . . . . . 58

Quadro 4 – Estudos selecionados para composição do start set. . . . . . . . . . . . . . 61

Quadro 5 – Síntese dos trabalhos do start set. . . . . . . . . . . . . . . . . . . . . . . 62

Quadro 6 – Estudos selecionados por snowballing backward. . . . . . . . . . . . . . . 64

Quadro 7 – Síntese dos trabalhos selecionados por snowballing backward. . . . . . . . 65

Quadro 8 – Respostas às questões de pesquisa (Start set). . . . . . . . . . . . . . . . . 67

Quadro 9 – Respostas às questões de pesquisa (Snowballing). . . . . . . . . . . . . . . 68

Quadro 10 – Correspondência entre os pontos de variação nas LPNs. . . . . . . . . . . 83

Quadro 11 – Requisitos para o subprocesso SP1. . . . . . . . . . . . . . . . . . . . . . 85



Quadro 14 – Outros requisitos elicitados – Vendas. . . . . . . . . . . . . . . . . . . . . 87

Quadro 15 – Estrutura sintática dos requisitos no arquétipo. . . . . . . . . . . . . . . . 88

Quadro 16 – Exemplo parcial do Arquétipo de Requisitos. . . . . . . . . . . . . . . . . 89

Quadro 17 – Arquétipo de Requisitos. . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

Quadro 18 – Exemplo de Requisitos da instância – Vendas. . . . . . . . . . . . . . . . . 94

Quadro 19 – Estrutura sintática para requisitos novos do ponto de variação. . . . . . . . 96

Quadro 20 – Exemplo de criação de requisitos – Vendas. . . . . . . . . . . . . . . . . . 97

Quadro 21 – Resumo das ações nos pontos de variação. . . . . . . . . . . . . . . . . . 97

Quadro 22 – Requisitos da instância – Vendas, atualizado. . . . . . . . . . . . . . . . . 102

Quadro 23 – Estrutura sintática para o formato de estória de usuário. . . . . . . . . . . . 103

Quadro 24 – Estrutura sintática para o formato de documento de requisitos. . . . . . . . 103

Quadro 25 – Estrutura sintática para redação dos requisitos. . . . . . . . . . . . . . . . 103

Quadro 26 – Exemplo de Modelo de Requisitos – Vendas. . . . . . . . . . . . . . . . . 105

Quadro 27 – Relação dos Requisitos Elicitados – Locação. . . . . . . . . . . . . . . . . 114

Quadro 28 – Arquétipo de Requisitos – Locação. . . . . . . . . . . . . . . . . . . . . . 116

Quadro 29 – Requisitos da instância – Locação. . . . . . . . . . . . . . . . . . . . . . . 119

Quadro 30 – Exemplo de criação de requisitos – PV – Locação. . . . . . . . . . . . . . 120

Quadro 31 – Exemplo de configuração e criação de requisitos – CV – Locação. . . . . . 121

Quadro 32 – Exemplo de modificação de requisitos. . . . . . . . . . . . . . . . . . . . 122

Quadro 33 – Exemplo de inserção de requisitos. . . . . . . . . . . . . . . . . . . . . . 122

Quadro 34 – Exemplo de estórias de usuário. . . . . . . . . . . . . . . . . . . . . . . . 124

Quadro 35 – Exemplo de documento de requisitos. . . . . . . . . . . . . . . . . . . . . 124

Lista de abreviaturas e siglas

ATL Atlas Transformation Language

ARReq Apoio ao Reúso de Requisitos em Linhas de Processos de Negócio

BPM Business Process Management

BPMN Business Process Model and Notation

BTD Banco de Teses e Dissertações

CAPES Coordenação de Aperfeiçoamento de Pessoal de Nível Superior

CIM Modelo Independente de Computação

EDN Engenharia de Domínio do Negócio

EPN Engenharia de Processo de Negócio

FACOM Faculdade de Computação

GLPN Gestão de Linhas de Processos de Negócios

LPN Linha de Processo de Negócio

LPS Linha de Produto de Software

MDA Model Driven Architecture

MDD Model Driven Development

MPNV Modelo de Processos de Negócio com Variabilidade

PDO Modelo de Processo de Negócio do Domínio

PV Ponto de Variação

RF Requisito Funcional

RN Regra de Negócio

RNF Requisito Não Funcional

TMPN Template de Modelo de Processo de Negócio

UFMS Universidade Federal de Mato Grosso do Sul

UML Unified Modeling Language

Sumário

1 INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

1.1 Justificativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

1.2 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

1.3 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

1.4 Organização da Escrita . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

2 EMBASAMENTO TEÓRICO . . . . . . . . . . . . . . . . . . . . . . 33

2.1 Engenharia de Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . 34

2.1.1 Elicitação e Análise de Requisitos . . . . . . . . . . . . . . . . . . . . . . . 35

2.1.2 Especificação de Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . 37

2.1.3 Gerenciamento de Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . 38

2.2 Modelagem de Processos de Negócio . . . . . . . . . . . . . . . . . . 39

2.2.1 Heurísticas da Técnica REMO . . . . . . . . . . . . . . . . . . . . . . . . 44

2.3 Linha de Processos de Negócio . . . . . . . . . . . . . . . . . . . . . . 46

2.3.1 Mecanismo de Variabilidade . . . . . . . . . . . . . . . . . . . . . . . . . . 50

2.3.2 Modelagem de Variabilidade . . . . . . . . . . . . . . . . . . . . . . . . . . 51

2.3.3 Instância . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

2.4 Considerações Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

3 REVISÃO SISTEMÁTICA DA LITERATURA . . . . . . . . . . . . . 55

3.1 Planejamento da Revisão . . . . . . . . . . . . . . . . . . . . . . . . . 55

3.1.1 Questões de Pesquisa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

3.1.2 Bibliotecas Digitais e String de Busca Padrão . . . . . . . . . . . . . . . . 56

3.1.3 Critérios de Inclusão e Exclusão . . . . . . . . . . . . . . . . . . . . . . . . 57

3.1.4 Estratégias de Pesquisa . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

3.2 Condução da Revisão . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

3.2.1 Análise do start set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

3.3 Execução do snowballing backward . . . . . . . . . . . . . . . . . . . 61

3.4 Síntese dos Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . 63


4 ARREQ - APOIO AO REÚSO DE REQUISITOS . . . . . . . . . . . 71

4.1 Descrição da ARReq . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

4.1.1 Elicitação de Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74


4.2 Exemplos de LPNs em diferentes notações . . . . . . . . . . . . . . . 77

4.3 Detalhamento e Aplicabilidade da ARReq . . . . . . . . . . . . . . . 83

4.3.1 Elicitação de Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83



5 AVALIAÇÃO DA ARREQ . . . . . . . . . . . . . . . . . . . . . . . . 109

5.1 Planejamento da avaliação . . . . . . . . . . . . . . . . . . . . . . . . . 109

5.2 Linha de Processos de Negócio – Domínio de Locação . . . . . . . . 110

5.3 Subprocesso de Elicitação de Requisitos . . . . . . . . . . . . . . . . 112

5.3.1 Atividade Realizar Elicitação de Requisitos . . . . . . . . . . . . . . . . . . 113

5.3.2 Atividade Gerar Arquétipo de Requisitos . . . . . . . . . . . . . . . . . . . 115

5.4 Subprocesso de Especificação de Requisitos . . . . . . . . . . . . . . 117

5.4.1 Atividade Preparar Especificação de Requisitos . . . . . . . . . . . . . . . . 117

5.4.2 Atividade Gerar Especificação de Requisitos . . . . . . . . . . . . . . . . . 123

5.5 Discussão dos Resultados . . . . . . . . . . . . . . . . . . . . . . . . . 124

5.6 Ameaças à validade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129


6 CONCLUSÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133

6.1 Síntese e Contribuições . . . . . . . . . . . . . . . . . . . . . . . . . . . 133

6.2 Limitações . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136

6.3 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

REFERÊNCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139

A RELAÇÃO DE REQUISITOS ELICITADOS – LOCAÇÃO . . . . . . 145

B ARQUÉTIPO DE REQUISITOS – LOCAÇÃO . . . . . . . . . . . . 149

C MATRIZ DE RASTREABILIDADE DA LPN – LOCAÇÃO . . . . . 155

D REQUISITOS DA INSTÂNCIA – LOCAÇÃO . . . . . . . . . . . . . 157

E MATRIZ DA INSTÂNCIA – LOCAÇÃO . . . . . . . . . . . . . . . . 161

F REQUISITOS DA INSTÂNCIA ATUALIZADOS . . . . . . . . . . . 163

G MATRIZ DA INSTÂNCIA ATUALIZADA . . . . . . . . . . . . . . . 167

H MODELO DE REQUISITOS – ESTÓRIAS DE USUÁRIO . . . . . . 169

I MODELO DE REQUISITOS – DOCUMENTO DE REQUISITOS . 173

J MATRIZ DE RASTREABILIDADE . . . . . . . . . . . . . . . . . . 177

23

1 Introdução

A construção de um software não é um trabalho trivial devido ao nível de abstração

do software e às necessidades de diferentes interessados que este tem de atender (SOMMER-

VILLE, 2015). Contudo, a importância estratégica dos sistemas de informação dentro das em-

presas e instituições é crescente e os softwares empregados podem ser um importante diferencial

no processo produtivo (CARVALHO, 2009), auxiliando na redução de custos, na melhoria da

qualidade e eficiência dos serviços ou produtos oferecidos e, também, fornecendo informações

gerenciais que auxiliam a tomada de decisões.

Diante dessa importância do software para o negócio, possuir um sistema computacional

que esteja alinhado com as necessidades da empresa é de suma importância para alcançar os obje-

tivos em todos os níveis empresariais (estratégico, tático e operacional). Para tanto, os requisitos

funcionais e não funcionais do software devem estar alinhados com os objetivos empresariais, e

isso pode ser obtido com o uso de modelos de processos de negócio para a elicitação dos requisi-

tos necessários à criação, evolução e manutenção de um software corporativo (WAZLAWICK,

2011).

A modelagem de processos de negócio é uma prática comum em algumas empresas e

consiste em representar graficamente as atividades, atores, eventos, dados e subprocessos pelos

quais a produção de um ativo (produto ou serviço) percorre para ser realizada (CARVALHO,

2009; ERIKSSON; PENKER, 2000), objetivando melhorar processos, descobrir gargalos e for-

necer conhecimento sobre os processos produtivos.

Sabe-se que o uso de modelos de processos de negócio como fonte de requisitos de

software vem crescendo nas últimas décadas (CHIARELLO, 2013), pois garante requisitos ali-

nhados com o negócio, mitiga os problemas de requisitos que ocorrem durante a produção de

software, entre eles a não atomicidade, ambiguidade, incompletude, duplicidade e o conflito de

requisitos (ANDRADE, 2015), bem como, favorece a comunicação entre os analistas do negócio

e os analistas de sistemas, pois ambos compreendem as representações do processo de negócio

o que agiliza a compreensão e a validação dos requisitos (WAZLAWICK, 2011).

24 Capítulo 1. Introdução

Há diversas formas de representar os modelos de processos de negócio, algumas utilizam

notações específicas, tais como BPMN1, EKD2 e i* framework3; e outras adaptam notações exis-

tentes, como ocorre com o uso deUML4 e Redes de Petri5. Nas últimas décadas a notação BPMN

tem ganhado espaço e é considerada a notação mais adequada para favorecer a elicitação de re-

quisitos a partir dos modelos de processos de negócio (VARA; SÁNCHEZ, 2009), pois trata-se

de uma notação compreensível por todos os envolvidos no negócio, desde os analistas de negó-

cio que criam os processos até os desenvolvedores técnicos responsáveis pela implementação

da tecnologia que executará esses processos, passando inclusive pelos gestores dos processos

(OMG, 2012).

Outra vantagem da representação dos modelos de processos de negócio em BPMN é a

possibilidade de elicitar os requisitos de software e as regras de negócio diretamente desses mo-

delos, seja de forma manual (VIEIRA, 2012; CHIARELLO, 2013) ou com apoio computacional

(CRUZ; MACHADO; SANTOS, 2015a; SINHA; PARADKAR, 2010). Essas abordagens me-

lhoraram o tempo de elicitação e a qualidade dos requisitos elicitados (OLIVEIRA et al., 2013),

pois estes estão mais alinhados com o negócio.

Mesmo com os benefícios oferecidos pela modelagem de processos de negócios, é ne-

cessário despender tempo e, consequentemente, custos para executá-la (LADEIRA, 2008). O

problema da redução de custos pode ser resolvido por meio do reúso de artefatos no contexto

de processos de negócio de um domínio com o uso das Linhas de Processos de Negócio (LPNs)

(LANDRE, 2012; BOFFOLI et al., 2012; ROLLAND; NURCAN, 2010; NUNES; WERNER;

SANTORO, 2010).

A LPN tem por base a teoria das Linhas de Produtos de Software (LPS) (POHL; BÖC-

KLE; LINDEN, 2005), um conceito já bastante difundido na literatura de Engenharia de Soft-

ware e que vem sendo aplicado com o uso de técnicas e ferramentas computacionais que favore-

cem a criação, instanciação e validação dessas linhas. Em ambos os tipos de linha o reúso exige

uma preparação adequada dos artefatos, que deverão ser pensados e documentados visando a

reutilização e, também, uma rastreabilidade que favoreça a localização das informações neces-

sárias para o momento de instanciar a linha, obtendo-se seus produtos finais, evoluir a linha ou

dar-lhe manutenção (PRESSMAN; MAXIM, 2016; POHL; BÖCKLE; LINDEN, 2005). Assim1Business Process Model and Notation (OMG, 2012).2Enterprise Knowlegde Development (JANIS; STIRNA; BRASH, 1998).3Originado dos trabalhos de Yu et al. (2011).4Unified Modeling Language (OMG, 2005).5Murata (1989).

25

como em LPS, as atividades para a criação de LPNs exigem um custo de preparação e somente

são indicadas para empresas com demandas de reúso de modelos de negócio no mesmo domínio.

As LPNs se caracterizam por agruparem em um único modelo todas as variabilidades

e comunalidades de um domínio de negócio, o que pode gerar modelos complexos devido às

características intrínsecas do domínio e ao dinamismo do negócio (TERENCIANI, 2015). A

possibilidade de representar as múltiplas variabilidades de um negócio se mostra a principal

característica para quem precisa produzir diversos modelos de processos de negócio, dentro do

mesmo domínio, para atender as necessidades dos interessados (YOUSFI et al., 2016; TEREN-

CIANI, 2015; GRÖNER et al., 2013).

Assim, ao reutilizar os artefatos do negócio viabilizados pela LPN é possível reduzir

custos de elaboração de modelos que representam o negócio, devido ao reaproveitamento, e de

validação, pois os artefatos reutilizados já foram validados previamente e estão alinhados com

o domínio do negócio.

Além disso, as LPNs favorecem a explicitação, compartilhamento do conhecimento e

entendimento comum sobre o domínio do negócio e, por meio de sua instanciação, colaboram

para a padronização na forma de representar os processos de negócio de empresas que perten-

cem ao domínio da LPN e oferecem oportunidades de evoluir o negócio, pois as possibilidades

para explorar o domínio estão representadas adequadamente por meio de comunalidades e vari-

abilidades.

Diante das vantagens oferecidas pelas LPNs e levando em consideração os benefícios da

elicitação de requisitos a partir de modelos de processos de negócios, observa-se a oportunidade

de elicitar requisitos a partir de modelos de processos de negócio do domínio, presentes nas

LPNs, e reusar tais requisitos durante a instanciação dessas linhas.

Com essa prática, as empresas que desenvolvem produtos de software em um mesmo

domínio e que despendem tempo na elicitação e especificação de requisitos de cada software,

pois criam requisitos a partir do zero ou a partir de modificações em especificações existentes de

sistemas semelhantes obtendo especificações de requisitos com baixa qualidade, poderão obter

requisitos especificados de maneira padronizada, alinhados com o negócio, com qualidade (ou

seja, requisitos completos, não ambíguos, atômicos, sem duplicidade, etc.) e com menos custos.

Portanto, o uso de LPNs com requisitos do domínio associados é uma alternativa para

empresas que procuram a redução dos custos, em especial no processo de Engenharia de Requisi-


tos, bem como a melhoria da qualidade dos requisitos. Isso colabora com a redução de erros nas

fases iniciais do desenvolvimento de software e do retrabalho nas fases posteriores, propiciando

também redução de tempo e, consequentemente, custos durante toda a produção do software.

Os benefícios são similares durante a manutenção de software, quando novos requisitos

devem ser incorporados em softwares existentes para atender a evolução do negócio incentivada

e apoiada por LPNs e que possuem requisitos do domínio disponíveis para reúso.

1.1 Justificativa

O grupo de pesquisa em Engenharia de Software da UFMS observou carência de uma

abordagem para favorecer a elicitação de requisitos de software a partir de LPNs (BITEN-

COURT; PAIVA; CAGNIN, 2016) e, com isso, propiciar o reúso de requisitos como política

de eficiência durante a Engenharia de Requisitos.

Estas constatações foram confirmadas pela revisão sistemática atualizada neste trabalho,

Capítulo 3, que tratou também de comprovar que há abordagens, algumas automatizadas, que

extraem requisitos de modelos de processos de negócio em BPMN, por meio do uso de heurísti-

cas (CIBRÁN, 2009; VIEIRA, 2012; DIAS et al., 2006; OLIVEIRA et al., 2013; NOGUEIRA,

2017) ou de algoritmos de transformação (SOUZA, 2014; SRIGANESH; RAMANATHAN,

2012; RODRÍGUEZ; FERNÁNDEZ-MEDINA; PIATTINI, 2007; RUNGWORAWUT; SENI-

VONGSE, 2005), mas nenhuma delas se aplica à LPN.

Quatro trabalhos anteriores do grupo de pesquisa em Engenharia de Software da UFMS

contribuíram para o cenário atual da pesquisa. As relações entre eles estão apresentadas na Fi-

gura 1.

O primeiro trabalho, proposto por Landre (2012), criou uma abordagem para a Gestão

de Linhas de Processos de Negócios (GLPN), apresentando as fases necessárias para a criação,

instanciação e melhoria de LPNs. Para a definição dessa abordagem, o autor tomou como base

o trabalho de Pohl, Böckle e Linden (2005), do qual os conceitos e mecanismos de LPS foram

abstraídos para o contexto de LPN.

O segundo trabalho, conduzido por Terenciani et al. (2015a), propôs a notação BPMN*,

que é uma extensão da notação BPMN (OMG, 2012) para representar comunalidades e variabili-

dades de domínio do negócio emmodelos de processos de negócio. O autor também desenvolveu

1.1. Justificativa 27

um plugin do Eclipse, denominado BPL-Framework 1.0 (TERENCIANI, 2015), que consiste

em uma ferramenta de apoio computacional à criação e validação de LPNs em conformidade

com a GLPN.

O terceiro trabalho, conduzido por Ferreira (2017), evoluiu o BPL-Framework para a

versão 2.0 (FERREIRA; PAIVA; CAGNIN, 2017) com o objetivo de apoiar a instanciação de

LPN em conformidade com a GLPN e melhorar a configuração de variabilidades.

O quarto trabalho, uma revisão sistemática conduzida por Bitencourt, Paiva e Cagnin

(2016), levantou os trabalhos que tratam sobre a elicitação de requisitos de software (funcionais

e não funcionais) e regras de negócio a partir de modelos de processos de negócio em BPMN,

a fim de identificar as lacunas existentes para oportunizar novas pesquisas, observando que há

poucos trabalhos sobre o assunto e nenhum que trata sobre elicitação no contexto das LPNs. Essa

revisão sistemática foi atualizada neste trabalho e seus resultados são discutidos no Capítulo 3.

Figura 1 – Colaborações para formação da proposta.

Diante dos trabalhos desenvolvidos pelo grupo de pesquisa se percebe a preocupação

com a evolução e melhoria da GLPN que já possibilita o reúso de elementos dos modelos de

processos de negócio do domínio em suas instâncias de forma automatizada.

Contudo, este trabalho de mestrado pretende contribuir com o reúso de requisitos no

contexto de LPNs, com o intuito de proporcionar a obtenção de requisitos alinhados com o

negócio, bem especificados e que indiretamente proporcionarão redução de tempo e custo na

Engenharia de Requisitos.


1.2 Objetivos

O objetivo geral desta pesquisa de mestrado é definir uma abordagem, denominada AR-

Req – Apoio ao Reúso de Requisitos em Linhas de Processos de Negócio, que permita elicitar,

reusar e especificar requisitos a partir de LPNs que utilizem a linguagem BPMN.

Para atingir o objetivo principal, os seguintes objetivos específicos foram definidos:

• Possibilitar a redução de problemas de requisitos: não atomicidade, ambiguidade, incom-

pletude, duplicidade e o conflito de requisitos;

• Utilizar qualquer técnica de elicitação de requisitos aplicável a modelos de processos de

negócio em BPMN;

• Gerar modelos de requisitos no formatos de casos de uso, estórias de usuário e documento

de requisitos;

• Possibilitar a adequação dos requisitos às necessidades do negócio no momento da instan-

ciação da LPN;

• Possibilitar a rastreabilidade entre os requisitos especificados e os elementos do modelos

de processos de negócio, instância da linha, que lhes deu origem;

• Permitir a integração da ARReq com qualquer abordagem de gestão de LPNs; e

• Permitir reusar requisitos funcionais, não funcionais e regras de negócio a partir de LPNs.

Algumas considerações sobre a ARReq são necessárias para a correta delimitação do

trabalho. Primeiramente, a análise da qualidade do domínio do negócio representado pela LPN

não pertence ao escopo e parte-se do pressuposto que os artefatos criados pelas abordagens de

gestão de LPNs são válidos e corretos.

Consequentemente, a qualidade dos requisitos elicitados e especificados depende dire-

tamente dos ativos existentes na LPN. Uma LPN com poucos elementos, e estes com poucas

informações, fornece um conjunto de requisitos com baixa qualidade. Já uma LPN com vários

elementos e estes dotados de informações completas e corretas possibilita produzir um conjunto

de requisitos com alta qualidade.

1.3. Metodologia 29

1.3 Metodologia

A metodologia para a elaboração da ARReq seguiu o paradigma da Pesquisa Observaci-

onal com viés positivista (WAINER, 2007). Nesta forma de pesquisa, o pesquisador observa um

problema do mundo real e cria, de forma exploratória, uma solução para esse problema (WAI-

NER, 2007). Com o intuito de organizar o processo de desenvolvimento deste estudo definiu-

se sua divisão em quatro fases: exploratória, planejamento, ação e avaliação. Estas fases são

apresentadas na Figura 2, compõem partes desta dissertação e suas atividades são descritas nos

próximos parágrafos.

Na fase exploratória foi realizada uma pesquisa bibliográfica visando maior aprofun-

damento e familiaridade com o problema estudado e para o desenvolvimento do embasamento

teórico, apresentado no Capítulo 2, englobando os seguintes conceitos: i) Engenharia de Re-

quisitos; ii) Modelagem de Processos de Negócio; iii) Linha de Processos de Negócio; e iv)

Gerenciamento de Variabilidade.

Figura 2 – Fases da metodologia utilizada.

Em paralelo à pesquisa bibliográfica foi conduzida a atualização da Revisão Sistemática

de Literatura (RSL), realizada por Bitencourt, Paiva e Cagnin (2016) e descrita no Capítulo 3,

para avaliar o estado da arte da elicitação e especificação de requisitos a partir de modelos de

processos de negócio em BPMN. Como resultado, constatou-se que há ausência de trabalhos

que tratam da elicitação de requisitos a partir de LPNs.

Depois, foi realizado um estudo sobre os conceitos e técnicas necessários para elicitação

e especificação de requisitos em LPNs, objetivando evoluir as heurísticas utilizadas em mode-

los de processos de negócio para atender as linhas. Com o estudo, percebeu-se que a técnica de

elicitação não influencia nos resultados da elicitação a partir da linha, quando com uso da AR-

Req, haja vista que a adaptação dos requisitos elicitados para uma sintaxe genérica mostrou-se

adequada às técnicas de elicitação encontradas na literatura.


Quanto à especificação de requisitos, o estudo constatou que as formas comumente em-

pregadas na literatura são os casos de uso, estórias de usuário e documento de requisitos. Assim,

tornou-se necessário planejar a criação de estruturas sintáticas que permitissem gerar os requisi-

tos nestes formatos.

Também foram analisadas as formas existentes de representar variabilidade em LPNs,

de modo que a abordagem pudesse ser utilizada com diversos mecanismos de variabilidade

mantendo sua eficiência e a qualidade dos requisitos. Lembrando que a qualidade dos requisitos

elicitados é diretamente relacionada à qualidade da representação do domínio do negócio pela

LPN.

Para finalizar a fase exploratória, tratou-se de estudar os problemas de requisitos (não

atomicidade, ambiguidade, incompletude, duplicidade e o conflito de requisitos). Com os es-

tudos foram planejadas estratégias adequadas para lidar com cada um deles, sendo que os três

primeiros problemas foram tratados durante o processo de elicitação de requisitos. Já os confli-

tos de requisitos, que dependem da configuração de variabilidade adotada para criar a instância

da linha, foram tratados durante o processo de especificação dos requisitos.

Depois da condução destes estudos teve início a fase de planejamento, na qual a ARReq

foi estruturada, conforme apresentado na Figura 3. A abordagem contém basicamente dois pro-

cessos integrados ao funcionamento de qualquer abordagem de gestão de LPNs: um processo

para a elicitação de requisitos, que será realizado na fase de criação, evolução e manutenção de

LPNs; e o processo para a especificação de requisitos que acontecerá na fase de instanciação da

linha.

Assim, além do produto da LPN que é resultado de sua instância, será possível, com o

apoio da ARReq, reusar também o Modelo de Requisitos em diversos formatos e a Matriz de

Rastreabilidade correspondentes a instância da LPN.

Terminada a fase de planejamento deu-se início à fase de ação, na qual a abordagem

desenvolvida foi aplicada em uma LPN do domínio de vendas. Esta LPN foi representada com

várias técnicas de modelagem e mecanismos de variabilidade, objetivando demonstrar a genera-

lidade da ARReq e verificar a satisfação dos objetivos pretendidos, testando cada processo que

compõe a abordagem.

Para cada iteração entre as fases de ação e avaliação, os resultados foram avaliados e, caso

necessário, a abordagem foi refinada e integrada à gestão de LPN para novos testes, compondo

1.4. Organização da Escrita 31

Figura 3 – Estrutura da abordagem.

assim, a primeira etapa da fase de avaliação. A segunda etapa desta fase ocorreu quando os

resultados foram considerados satisfatórios.

Considerada satisfatória, a ARReq foi submetida a uma avaliação de aplicação, que con-

sistiu verificar se a abordagem agia conforme descrito para um exemplo do mundo real. Nesta

etapa, a ARReq foi aplicada a uma LPN com diversas variabilidades, construída por uma abor-

dagem de gestão de LPNs específica, com o objetivo de averiguar se os resultados obtidos na

fase de ação são mantidos. Caso identificado algum problema, ajustes podem ser necessários e

se retorna a fase de ação para refinar a abordagem.

Sendo a ARReq considerada adequada, finaliza-se o processo escrevendo artigos cientí-

ficos para a publicação da abordagem em eventos e revistas da área.

1.4 Organização da Escrita

Este texto está organizado em mais cinco capítulos. No Capítulo 2 há o embasamento

teórico, contendo a definição de conceitos utilizados para execução da pesquisa e para a compre-

ensão dos assuntos abordados. No Capítulo 3 é apresentada a atualização da revisão sistemática

conduzida por Bitencourt, Paiva e Cagnin (2016) e são discutidas as carências observadas na li-


teratura. No Capítulo 4 é apresentada a ARReq, suas premissas, processos e estruturas que visam

a obtenção dos artefatos Modelo de Requisitos e Matriz de Rastreabilidade durante a instancia-

ção de LPNs. No Capítulo 5 é apresentada a avaliação que analisa a aplicabilidade da ARReq

para uma abordagem de gestão de LPN específica. Por fim, no Capítulo 6 estão as conclusões

do trabalho, suas contribuições, limitações e sugestões de trabalhos futuros.

33

2 Embasamento Teórico

Para facilitar o entendimento desta pesquisa se faz necessário fundamentar o conheci-

mento de conceitos que foram imprescindíveis para o desenvolvimento do projeto: Engenharia

de Requisitos, Modelagem de Processos de Negócio e Linhas de Processos de Negócio. Isso se

faz necessário pois a ARReq está na intersecção dessas áreas de conhecimento, como apresen-

tado na Figura 4.

Figura 4 – Localização conceitual da ARReq.

Na Seção 2.1 é apresentada uma visão geral sobre Engenharia de Requisitos e são abor-

dadas algumas técnicas utilizadas para especificação de requisitos, pois são de interesse deste

trabalho, visto que os requisitos extraídos de LPNs devem ser armazenados em um artefato

genérico que contenha atributos utilizados pelas principais técnicas de especificação.

Na Seção 2.2 é apresentado o conceito de modelagem de processos de negócio. Uma

técnica pertencente a Engenharia de Processos de Negócio que facilita a compreensão do negó-

cio, descrevendo graficamente como ele ocorre e os insumos necessários para sua execução e a

produção do objetivo final esperado (CARVALHO, 2009).

Em seguida, na Seção 2.3, explica-se o conceito relacionado com as Linhas de Processos

de Negócio (LPN). Uma variação das Linhas de Produto de Software aplicada aos processos de

negócio e com o objetivo de facilitar o reúso destes.

Por fim, na Seção 2.4 são apresentadas as considerações finais deste capítulo, fundamen-

tando como a abordagem proposta se relaciona com os conceitos descritos anteriormente.

34 Capítulo 2. Embasamento Teórico

2.1 Engenharia de Requisitos

De acordo com o que está definido na norma ISO/IEC/IEEE 29.148 (ISO, 2011), o con-

ceito de Engenharia de Requisitos pode ser traduzido como uma “função interdisciplinar que

faz a mediação entre os domínios do adquirente e o fornecedor para estabelecer e manter as

exigências a serem cumpridas pelo sistema, software ou serviço de interesse”.

Desta definição se depreende que a Engenharia de Requisitos é interdisciplinar, ou seja,

envolve um conjunto de disciplinas que englobam os conceitos, aspectos e fenômenos necessá-

rios para compreender o domínio de software e retirar deste domínio aquilo que precisa ser feito.

É composta por um conjunto de conceitos que preocupam-se como os requisitos são elicitados,

especificados, gerenciados, rastreados, validados e verificados (ISO, 2011).

Logo, é uma área extremamente abrangente, interdisciplinar, aberta e lida com a descri-

ção de observações do mundo real por meio de notações apropriadas. Mais especificamente é

responsável pelas atividades de descobrir, analisar, documentar e verificar o conjunto de requi-

sitos de um sistema informatizado (SOMMERVILLE, 2015).

A importância e a complexidade da elicitação de requisitos levou ao surgimento, no

início dos anos 90, da Engenharia de Requisitos. O objetivo desta denominação é ressaltar que

o processo de definir os requisitos de software é uma atividade extremamente importante e

independente das outras atividades da Engenharia de Software. Ela requer fundamentação e

processos próprios, e que devem ser planejados e gerenciados ao longo de todo o ciclo de vida

do produto (SOMMERVILLE, 2015).

Segundo Zave (1995), os objetivos do processo de Engenharia de Requisitos podem ser

separados em três grandes grupos: i) investigação de objetivos, funções e restrições de uma apli-

cação de software; ii) especificação do comportamento do software; e iii) o gerenciamento da

evolução dos requisitos durante todo o ciclo de vida do software. Essa divisão mostra que a

Engenharia de Requisitos é uma disciplina que percorre todo o processo de produção do soft-

ware cuidando de sua criação, evolução e de sua manutenção após a entrega (SOMMERVILLE,

2015).

Para Sommerville (2015) todo o processo de Engenharia de Requisitos é composto por

cinco subprocessos e estão apresentados na Figura 5: i) estudo de viabilidade, ii) elicitação e aná-

lise de requisitos, iii) especificação de requisitos, iv) validação de requisitos e v) gerenciamento

de requisitos.

2.1. Engenharia de Requisitos 35

Figura 5 – Processo de engenharia de requisitos. Adaptado de Sommerville (2015).

Nas subseções a seguir são descritos os subprocessos de interesse deste trabalho, sendo

que apenas os subprocessos estudo de viabilidade e validação de requisitos não serão apresen-

tados, pois estão fora do escopo deste trabalho.

2.1.1 Elicitação e Análise de Requisitos

Decidido pela viabilidade do software é hora de conhecer melhor o negócio, reunir seus

interessados para conhecer o domínio da aplicação, os serviços pretendidos, as restrições de

hardware e de desempenho, ou seja, detalhar o que se deseja do software em si.

Para Wazlawick (2011), a elicitação de requisitos corresponde a buscar todas as informa-

ções possíveis sobre as funções que o sistema deve executar e as restrições sobre as quais deve

operar.

É um subprocesso longo, que precisa de muita atenção por parte dos analistas de requi-

sitos, pois dele dependem todo o processo produtivo. A elicitação de requisitos não se encerra

neste subprocesso, mas reúne todas as informações que são necessárias para a construção do

produto pretendido. É a fase em que mais pessoas estão envolvidas, pois além dos analistas é

comum, e extremamente desejável, a participação dos clientes e usuários finais, além de outros

interessados.

Para Sommerville (2015), este subprocesso é o mais complexo e exige todo esse cuidado

pois, geralmente:

• Os interessados não sabem o que querem do sistema a não ser em termos gerais;


• A forma como os interessados expressam seus requisitos são em sua própria linguagem

de trabalho e, muito frequentemente, deixam de falar muita informação por considerarem

que está implícita no que desejam;

• Diferentes interessados têm diferentes formas de expressar os mesmos requisitos;

• Os fatores políticos podem influenciar os requisitos de sistema; e

• O ambiente econômico, político e legal sobre o qual esse primeiro levantamento é feito

pode ser dinâmico.

Para ajudar no processo de elicitação de requisitos e evitar essa série de problemas apre-

sentados anteriormente, Sommerville (2015) sugere algumas estratégias, dentre elas: entrevistas,

elaboração de cenários e estórias de usuários.

As entrevistas consistem em questões propostas aos interessados a respeito do produto

que será desenvolvido. Deve procurar elicitar os requisitos funcionais pretendidos e as regras

de negócio.

A técnica de cenários procura reproduzir o dia-a-dia da organização, com destaque para

as atividades que são realizadas. Procura descrever quem são os atores e suas ações, com des-

crição sequencial destas ações e dos objetivos pretendidos com as atividades, bem como as

dificuldades e problemas para sua execução.

Rosson e Carroll (2012) detalham a importância do cenário para a Engenharia de Requi-

sitos, pois com esta técnica é possível omitir detalhes de implementação, pois estes se tornam

implícitos na descrição do cenário. Também é importante valorizar o papel do usuário final do

sistema.

Já, as estórias de usuário surgiram com a popularização dos métodos ágeis e favorecem a

perspectiva do usuário fornecendo as informações de requisitos sem uma estrutura muito formal.

São declarações informais de um requisito de usuário e sua intenção é fornecer à equipe uma

resposta rápida para aquilo que o usuário precisa (LONGO; SILVA, 2014).

Geralmente as estórias de usuário são escritas a mão, em cartões de papel por meio de

uma conversa com o usuário e que são posteriormente confirmadas com os testes de aceitação. É

importante que os cartões com as estórias de usuário também contenham elementos que permi-

tam fazer a identificação e a priorização desses requisitos, bem como uma estimativa do tempo

para atender, ou construir, aquela funcionalidade (COHEN, 2004).

2.1. Engenharia de Requisitos 37

Salienta-se que os responsáveis administrativos pelas empresas têm procurado registrar

seus processos produtivos no formato de modelos de processos de negócio, pois este registro

permite conhecer melhor o funcionamento dos processos empresariais e pode ser utilizado como

fonte para aperfeiçoamento desses mesmos processos, sendo úteis, inclusive, para a elicitação

de requisitos (VIEIRA, 2012; OLIVEIRA et al., 2013; CARVALHO, 2009).

2.1.2 Especificação de Requisitos

De acordo com Pressman e Maxim (2016), a especificação de requisitos consiste em

produzir um documento no qual estão definidos todos os requisitos elicitados, analisados e ne-

gociados. Este documento pode apresentar uma série de formatos, dentre eles tem-se: casos

de uso, documento de requisitos, cenários e estórias de usuário (PRESSMAN; MAXIM, 2016;

WAZLAWICK, 2015). O importante é que estes documentos atendam a norma ISO/IEC 29.148

(ISO, 2011), a qual estabelece os seguintes atributos de qualidade para os requisitos:

• Necessário: indicam necessidades, restrições, ações e outras características do sistema

que devem ser implementadas para o correto funcionamento destes. Não devem se tornar

obsoletas com o tempo ou avanço tecnológico;

• Livre de implementação: Não deve indicar necessidades arquiteturais ou informações so-

bre como deve ser codificado ou implementado. Estas decisões são de projeto e não devem

estar no requisito.

• Não ambíguo: O requisitos deve ser interpretado de um único modo, sendo claro e fácil

de entender;

• Consistente: O requisito deve ser livre de conflito com outros requisitos;

• Completo: O requisito deve indicar todas as informações necessárias para sua compreen-

são e criação;

• Singular: O requisito deve ser atômico, ou seja, não pode conter outros requisitos em si

mesmo;

• Factível: O requisito deve ser possível de ser implementado com a tecnologia disponível

e as limitações dadas pelo contrato (orçamento, prazos, etc);

• Rastreável: O requisito deve ser rastreável no sistema, para que mudanças nos requisitos

possam ser realizadas no sistema com maior facilidade (manutenibilidade);


• Verificável: O requisito deve ser redigido de forma que seja possível verificar que ele foi

satisfeito na entrega do sistema;

Ao redigir os requisitos de forma a atender estes atributos de qualidade é possível evitar

alguns dos problemas mais comuns no desenvolvimento de softwares (SOUZA, 2014), dentre

eles a descrição pouco clara dos requisitos, conflitos entre requisitos, requisitos incompletos ou

não realistas e a alta volatilidade dos requisitos (ANDRADE, 2015).

Os casos de uso (COCKBURN, 2001) descrevem um conjunto de ações e atividades que

serão construídas no sistema para atender as necessidades do usuário e possui muitos detalhes,

descrevendo tudo que o desenvolvedor precisa para atender a demanda do cliente.

De acordo com Wazlawick (2015), os casos de uso apresentam os requisitos funcionais

demais alto nível em um sistema. Nos casos de uso podem ser feitas anotações que representarão

os requisitos não funcionais e até regras de negócio. Os casos de uso são úteis, de acordo com o

autor, para: i) definição e validação da arquitetura do sistema; ii) para criação dos casos de teste;

iii) para o planejamento das iterações; e iv) como base para o documento de requisitos.

O documento de requisitos é o documento final que contém todos os serviços e funções

que o sistema deve prover, suas limitações e descrições de hardware necessários e de desempe-

nho, segurança e confiabilidade (WAZLAWICK, 2015).

Há diversas classificações para os requisitos que constam em um documento de requisi-

tos. As classificações utilizadas nesta pesquisa são retiradas de Sommerville (2015) e classificam

os requisitos em requisitos funcionais e requisitos não funcionais.

Os requisitos funcionais descrevem funções que o sistema deve desempenhar, como o

sistema deve reagir às entradas e se comportar nas situações cotidianas. Também podem infor-

mar explicitamente funções que o sistema não deve fazer (SOMMERVILLE, 2015).

Os requisitos não funcionais são restrições sobre os serviços ou funções oferecidos pelo

software (SOUZA, 2014; SOMMERVILLE, 2015). Destacam-se restrições de tempo, desempe-

nho, segurança, portabilidade, entre outras.

2.1.3 Gerenciamento de Requisitos

Como alguns requisitos são dinâmicos e mudam ao longo do processo de desenvolvi-

mento do software, e o fazem por diversas razões, é preciso ter alguma forma de gerenciar os re-

2.2. Modelagem de Processos de Negócio 39

quisitos. Sommerville (2015) afirma que o gerenciamento de requisito é um modelo sistemático

para encontrar, documentar, organizar e rastrear os requisitos, os planos de projeto e os artefatos

desenvolvidos. Para ser realizado com sucesso deve-se garantir que os requisitos tenham sido

bem identificados e sejam rastreáveis.

As mudanças nos requisitos são normais na Engenharia de Requisitos e devem ser do-

cumentadas. Uma avaliação do impacto da mudança do requisito pode ser solicitada pelos inte-

ressados para confirmar se a mudança será realmente necessária, portanto, a rastreabilidade é a

principal característica desta fase do processo de Engenharia de Requisitos (SOMMERVILLE,

2015).

A rastreabilidade de requisitos favorece o entendimento entre os relacionamentos dos

requisitos e entre outros artefatos gerados durante o projeto de desenvolvimento de software. É,

também, uma forma de garantir que os artefatos produzidos durante a execução do processo de

desenvolvimento satisfazem os requisitos do cliente (SOMMERVILLE, 2015). A matriz de ras-

treabilidade é um mecanismo que proporciona visibilidade ao rastreamento e ao relacionamento

entre os requisitos, artefatos do modelo, código e casos de teste. A evolução de um sistema se dá

pelo resultado das mudanças solicitadas, por isto, é importante que os requisitos elicitados sejam

rastreáveis (MARQUES, 2013). Na Figura 6 é ilustrada uma matriz que mostra a rastreabilidade

entre os requisitos da coluna A com os elementos BPMN na linha 1.

Figura 6 – Exemplo de matriz de rastreabilidade entre requisitos e elementosBPMN.

2.2 Modelagem de Processos de Negócio

Para o entendimento do conceito de modelagem de processos de negócio é preciso com-

preender que ele é uma subárea da Engenharia de Processos de Negócio (EPN). Esta é uma

atividade multidisciplinar, presente em várias áreas de conhecimento e que consiste em uma


arquitetura para entendimento, análise e melhoria dos processos dentro das organizações (CAR-

VALHO, 2009; SANTOS, 2002).

Os processos de negócios são ordenações temporais e lógicas, ou cooperação de ativi-

dades, com o objetivo de finalizar uma tarefa, obtendo um produto ou serviço para um cliente

ou outro processo. São formados por uma ou mais atividades executadas por trabalhadores ou

sistemas, regidos por regras de negócio, iniciados a partir de eventos externos ou internos à

organização e finalizados por algum tipo de evento que indica o alcance do seu objetivo (CAR-

VALHO, 2009; SANTOS, 2002).

EmCarvalho (2009), a modelagem de processos de negócio compreende o entendimento

da estrutura organizacional, das regras de negócio que afetam a operação, dos objetivos, das ativi-

dades e responsabilidades dos envolvidos, bem como dos dados manipulados, representando-os

em modelos que capturem diversas características do negócio. Deste modo o modelo de proces-

sos de negócio consiste em uma representação de um, ou mais processos de negócio, com suas

atividades, recursos, interações, atores e condicionais que possibilitam a entrega do produto ou

serviço para o cliente ou para outro processo (ERIKSSON; PENKER, 2000).

Um modelo de processos de negócio é construído por um analista do negócio e pode

ser um processo do mundo real ou apenas um modelo teórico (ANDRADE, 2015). Assim, este

modelo é uma representação do(s) processo(s) de negócio que permite às empresas documentar,

simular, compartilhar, implementar, avaliar e melhorar continuamente suas operações (JOSUT-

TIS, 2008). Um modelo de processos de negócio permite entender e visualizar o funcionamento

da organização e proporcionar uma compreensão de todos os aspectos envolvidos no domínio

do negócio (LADEIRA, 2008).

Por representarem o negócio, suas atividades, recursos, atores, dados e outras informa-

ções imprescindíveis e importantes para a Engenharia de Software é que a modelagem de pro-

cessos de negócio é utilizada por esta como parte da Engenharia de Requisitos.

Dentro da Engenharia de Software, amodelagem de negócios é uma atividade que apoia a

Engenharia de Requisitos por meio da construção de modelos que representam o funcionamento

de um negócio para o qual o software será desenvolvido e implantado. Estes modelos permitem

que o engenheiro de software entenda o funcionamento do negócio, o que auxilia e facilita o

levantamento de requisitos (WAZLAWICK, 2011).


Há várias definições para processos de negócio. Será utilizada aquela que define pro-

cessos de negócio como um conjunto de atividades que representam os passos necessários para

atingir um objetivo do negócio, incluindo todo o fluxo e uso de informações e recursos (OMG,

2012). Estes processos de negócio dentro das organizações possuem definições apropriadas, ma-

nifestas como políticas, leis, padrões, procedimentos, convenções ou contratos e se tornam, na

modelagem do negócio, as regras do negócio (LADEIRA, 2008).

As regras de negócio são, de acordo com Marshall (2000 apud LADEIRA et al., 2008,

p. 27), como uma política que deve ser aplicada sempre que uma situação acontece e estas

regras podem estar na forma de procedimentos, responsabilidades, autorizações e mecanismos

de delegação. Regras de negócios podem expressar objetivos do negócio, o modo de execução

de um processo, detalhar condições de um relacionamento ou restringir o comportamento de um

recurso.

As regras de negócio podem controlar ou influenciar a execução dos processos de negó-

cio e sua estrutura de recursos, restringindo ou condicionando a execução de certas atividades

(ERIKSSON; PENKER, 2000). Estas regras possuem várias classificações na literatura e a es-

colha do conjunto de classificação a ser usado depende de vários fatores, tais como: explicar

o conjunto de regras a ser obtido; simplificar e guiar o processo de descoberta das regras; ex-

pressar as regras com clareza e entendimento, favorecendo a cultura empresarial (CARVALHO,

2009).

Para Carvalho (2009), o maior benefício de descobrir as regras do negócio para os sis-

temas de software são “os benefícios concretos com independência técnica, desenvolvimento

ágil de aplicativos, melhor qualidade de requisitos, facilidade de mudança e evolução, além do

balanceamento entre flexibilidade e controle organizado”. Esta autora também reforça que “a

descoberta de regras de negócio é uma forma efetiva de descobrir os requisitos principais dos sis-

temas de informação” (CARVALHO, 2009), comprovando que as regras de negócio não podem

ser negligenciadas na modelagem de negócios e na elicitação de requisitos.

Para executar essa modelagem do processo de forma adequada é necessário utilizar uma

linguagem de modelagem e um procedimento de modelagem (KARAGIANNIS; KÜHN, 2002).

Para confecção e apresentação de um modelo de processo de negócio há diversas lingua-

gens de modelagem disponíveis. Para a execução desta pesquisa será utilizada a notação BPMN

(OMG, 2012), pois é a mais utilizada com esta finalidade (CHINOSI; TROMBETTA, 2012).


É uma notação compreensível por todos os envolvidos no negócio, desde os analistas de negó-

cio que criam os processos até os desenvolvedores técnicos responsáveis pela implementação

da tecnologia que executará esses processos, passando inclusive pelos gestores dos processos

(CARVALHO, 2009).

Além disso, BPMN também é suportado por ummodelo interno que possibilita a geração

de código executável, criando, assim, segundo a OMG (2012), uma forma padronizada de cobrir

a lacuna entre os processos de negócio e a implementação dos mesmos. E, por fim, por ser uma

linguagem que vai dar continuidade aos trabalhos desenvolvidos anteriormente pelo grupo de

pesquisa em Engenharia de Software desta Universidade.

O BPMN é considerado uma linguagem de modelagem para processos de negócio cujos

modelos podem ser utilizados para auxiliar a extração de requisitos pois oferece suporte para

vários atores, visões do negócio, artefatos e relações entre esses itens (OMG, 2012). Há possibi-

lidade de estender essa linguagem, personalizando-a, para acrescentar informações relevantes,

tais como requisitos de segurança, de qualidade e outros mais que se pretenda extrair no processo

de elicitação de requisitos realizado no desenvolvimento de um software e tem sido objeto de es-

tudos em diversos trabalhos na literatura (RESPÍCIO; DOMINGOS, 2015; ABURUB; ODEH;

BEESON, 2007; AUER; GEIST; DRAHEIM, 2009; DECKER et al., 2010; BOCCIARELLI;

D’AMBROGIO, 2011; BRAUN, 2015).

Um exemplo de modelo de processos de negócio em BPMN é apresentado na Figura 7.

Nesta figura é possível visualizar o processo de negócio para a venda de mercadorias em um

mercado. Observa-se a sequência de atividades realizadas pelo ator (caixa), a partir do evento

de início (cliente chega com as compras), seguido por três atividades e, na terceira, ocorre a

emissão de documento (comprovante de pagamento), finalizando com a decisão pelo tipo de

entrega (imediata ou a domicílio) para encerrar o processo.

Figura 7 – Exemplo de diagrama de processo de negócio em BPMN. Adaptado deTerenciani et al. (2015a).


As atividades da Engenharia de Requisitos ganharam com a técnica de modelagem de

processos de negócio um auxílio para tentar minimizar os efeitos de uma elicitação de requisitos

ineficaz ou insuficiente (ANDRADE, 2015). O uso de heurísticas para ajudar na transcrição

dos processos de negócio em requisitos de software tem ganhado espaço, como comprovam as

pesquisas de Vieira (2012), Dias et al. (2006), Cibrán (2009), Oliveira et al. (2013) e Nogueira

(2017).

Dentre os trabalhos citados, dois possuem mecanismos apropriados para a aplicação da

ARReq por terem heurísticas que se aplicam a modelos de processos de negócio em BPMN. O

primeiro, Nogueira (2017) possui heurísticas que possibilitam a elicitação de forma automati-

zada, enquanto o segundo, Vieira (2012), desenvolveu heurísticas para elicitação manual. Além

disso, as heurísticas propostas por Vieira (2012) são utilizadas nos Capítulos 4 e 5 para detalhar

e analisar, respectivamente, a aplicabilidade da ARReq.

O trabalho de Nogueira (2017) apresenta um software, chamado SRPD1, que utiliza dois

conjuntos de heurísticas para elicitar requisitos funcionais, não funcionais e regras de negócio

a partir de modelos de processos de negócio em BPMN em arquivos no formato XPDL (XML

Process Definition Language). O primeiro conjunto, chamado Heurísticas de Negócio, verifica

a adequação do modelo de processos aos critérios de qualidade e completude de informações

necessárias para melhor eficiência do software. O segundo conjunto, chamado Heurísticas de

Requisitos, cuida de elicitar os requisitos de software e as regras de negócio produzindo um

arquivo XML como documento de requisitos, estruturado de acordo com a ISO/IEC 29.148 (ISO,

2011). Um esquema de seu funcionamento pode ser visualizado na Figura 8.

Figura 8 – Visão geral do funcionamento do SRPD. Extraído de Nogueira (2017).

1SRPD - Software Requirements from Process Definitions


Já o trabalho de Vieira (2012) apresenta uma técnica manual baseada em heurísticas,

chamada Técnica REMO2, e apropriada para os elementos BPMN, que não necessita de modi-

ficações ou adição de informações complementares no modelo de processos de negócio e que

permite sua adoção em modelos já existentes nas empresas ou sem versão digital. Este conjunto

de heurísticas independe de formato de arquivo e, apesar de não contar com um processo auto-

matizado para elicitação, há o protótipo de uma ferramenta desenvolvida por Sorgatto e Cagnin

(2017). Nesta técnica, apresentada na Figura 9, o analista de requisitos percorre o modelo de pro-

cessos de negócio e, para cada elemento BPMN, aplica as heurísticas indicadas, elicitando assim

os requisitos e anotando-os em um documento de requisitos no formato desejado. Na subseção

a seguir é apresentado o conjunto de heurísticas da técnica REMO (VIEIRA, 2012).

Figura 9 – Visão geral da aplicação da Técnica REMO. Extraído de Vieira (2012).

2.2.1 Heurísticas da Técnica REMO

As heurísticas da técnica REMO foram criadas e evoluídas por Vieira (2012) e estão na

versão três. Nesta última versão é possível extrair requisitos de modelos de processos de negócio,

mas esta extração ainda ocorre de forma manual, ou seja, o analista de requisitos percorre o mo-

delo de processo de negócio, seguindo seu fluxo, e anota os requisitos existentes nas categorias

propostas.

Na Figura 10 estão apresentados dois elementos de um processo de negócio: uma ati-

vidade e uma mensagem. Utilizando a técnica REMO o analista poderá extrair e especificar

dois requisitos, um requisito funcional (exemplificado pelo texto identificado por RF01) e um

requisito não funcional (identificado como RNF01).2REMO - Requirements Elicitation oriented by business process MOdeling.


Figura 10 – Exemplo de elicitação de requisitos com base na heurística REMO –H3. Extraído de Vieira (2012).

De acordo com Oliveira et al. (2013), as heurísticas da técnica REMO foram validadas

e tiveram sua eficiência confirmada, retornando menos falsos positivos e fornecendo requisitos

mais adequados que as técnicas tradicionais de elicitação de requisitos sem o apoio de modelos

de processos de negócio.

Nesta terceira versão o processo de elicitação ganhou duas etapas. Inicialmente realiza-

se a Compreensão dos Processos de Negócios em que é preciso compreender e definir o escopo

do projeto que terá seus requisitos elicitados e a segunda etapa é responsável pela Elicitação de

Requisitos propriamente dita (VIEIRA, 2012).

Na etapa Compreensão dos Processos de Negócio o analista de requisitos precisa ter um

bom conhecimento do escopo do projeto para poder elicitar adequadamente os requisitos. Para

isso, a REMO propõe a adoção de um questionário que permite identificar o contexto no qual o

software irá funcionar.

O questionário contém questões que dizem respeito aos seguintes aspectos: i) proble-

mas e necessidades do negócio; ii) papéis envolvidos; iii) recursos de infraestrutura que estão

disponíveis; iv) uma visão geral dos outros processos de negócio envolvidos no problema; e v)

clareza quanto ao tipo de aplicação que será desenvolvida (web, desktop oumobile). Além desse

questionário é importante que o analista de requisitos tenha em mãos uma cópia do modelo de

processos de negócio que irá tomar como base para realizar a elicitação dos requisitos (VIEIRA,

2012).

As informações do questionário e do modelo de processos de negócio serão úteis para

que o analista de requisitos redija adequadamente os requisitos para cada elemento representado

no modelo.


Na etapa Elicitação de Requisitos o analista de requisitos analisa cada elemento do mo-

delo de processos de negócio e verifica se pode ser desempenhado pelo sistema. Depois, anota

em cada um desses elementos a heurística correspondente e, por fim, aplica essa heurística e

especifica o requisito extraído no documento de requisitos. Contudo, os autores não discutem

como os requisitos devem ser especificados.

Elementos gráficos da notação BPMN são utilizados para indicar qual heurística pode

ser empregada e que tipo de requisito cada elemento pode fornecer. Estes elementos gráficos

e as nove heurísticas a que se aplicam estão descritos na Figura 11. Conforme já mencionado,

os requisitos oriundos da técnica REMO podem ser: i) requisitos funcionais (RN); ii) requisitos

não funcionais (RNF); e iii) regras de negócio (RN).

As heurísticas apresentadas na Figura 11, possuem palavras-chave para facilitar ao ana-

lista de requisitos identificar os requisitos a que se referem. As heurísticas relacionadas a requisi-

tos funcionais iniciam com o imperativo analise, as correspondentes a requisitos não funcionais

iniciam com o imperativo avalie, e as relacionadas com regras de negócio iniciam com o impe-

rativo verifique.

2.3 Linha de Processos de Negócio

A Linha de Processos de Negócio (LPN) é a aplicação dos conceitos de Linha de Pro-

dutos de Software (LPS) (POHL; BÖCKLE; LINDEN, 2005) para facilitar o reúso de modelos

de processos de negócio. Uma LPN é composta por um conjunto de artefatos (GRÖNER et al.,

2013; LANDRE et al., 2014): i) modelo de variabilidades; ii) templates de modelos de proces-

sos de negócio; iii) modelos de processos de negócio do domínio; e iv) rastreabilidade entre o

modelo de variabilidades e o template de modelos de processos de negócio. Estes artefatos estão

definidos e exemplificados adiante.

Um dos pontos herdados das LPS são os conceitos de variabilidade e comunalidade. Em

LPS, o termo variabilidade refere-se às características do produto que podem ser customizadas

e é composto por dois atributos, o ponto de variação, que é o local em que a variação pode

ocorrer, por exemplo, forma de pagamento, e as variantes que são as possíveis soluções para

o ponto de variação, no exemplo cartão de crédito, débito ou em dinheiro. Já o conceito de

comunalidade diz respeito às características que permanecem obrigatórias a todos os produtos

do domínio (YOUSFI et al., 2016; ROLLAND; NURCAN, 2010; BACHMANN; BASS, 2001).

2.3. Linha de Processos de Negócio 47

Figura 11 – Heurísticas REMO versão 1.3. Extraído de Vieira (2012).

A partir de 2006, com a adaptação dos conceitos de LPS para o contexto de processos

de negócio, surgiu o termo Linha de Processos de Negócio (LPN), ou Família de Processos de

Negócio, ou ainda Linha de Produto de Processos de Negócio. O objetivo dessa adaptação é

gerenciar um conjunto similar de processos de negócio, todos do mesmo domínio, tornando-o


um portfólio estreitamente relacionado com variabilidades nas características e contextos ope-

racionais (BOFFOLI et al., 2012; YOUSFI et al., 2016).

Segundo Boffoli et al. (2012), uma LPN é capaz de gerenciar tanto os elementos inva-

riantes, as comunalidades, quanto os componentes variantes, as variabilidades, e oferecer uma

forma de administrar as variabilidades do processo de negócio, adequando-as ao processo de

destino, além de promover o reúso das atividades, atores, artefatos e outros elementos, com fins

de garantir a flexibilidade necessária em um ambiente de negócio em constante mudança.

O gerenciamento da variabilidade envolve técnicas de modelagem de variabilidade e

mecanismos para implementar a variabilidade (YOUSFI et al., 2016). Enquanto aquelas tratam

de como a variabilidade é representada graficamente no modelo de processos de negócio, estes

dizem respeito a forma como a variabilidade é gerenciada e realizada. Cada abordagem para

gestão de LPNs precisa definir claramente qual a técnica de modelagem e o mecanismo de

implementação de variabilidade que adota.

Os mecanismos de variabilidade são variados, utilizados em diversas linhas de produtos,

inclusive de softwares e de processos de negócio. Os mecanismos mais comuns são o modelo

de features (KANG et al., 1990) e o modelo ortogonal (POHL; BÖCKLE; LINDEN, 2005). Há,

porém autores, Yousfi et al. (2016) entre eles, que representam o mecanismo de variabilidade no

própriomodelo de representação da linha, utilizando para isso recursos disponíveis na linguagem

de modelagem adotada ou extensões dessas linguagens que tratem de realizar e gerenciar a

variabilidade.

Nas técnicas de modelagem de variabilidade encontra-se autores que representam a va-

riabilidade como fluxos alternativos no próprio modelo de processos de negócio, como é o caso

de Gröner et al. (2013) e Yousfi et al. (2016); e outros que utilizam extensões da linguagem

de modelagem adotada para representar o modelo de processos de negócio com variabilidade,

como exemplo os trabalhos de Terenciani et al. (2015b) (BPMN*) e de Schnieders e Puhlmann

(2006) (vrBPMN).

Na literatura há diversas abordagens que tratam da gestão de LPNs, ou seja, criação, ins-

tanciação e validação desse tipo de linha. Algumas dessas abordagens possuem como instância

um produto de software e outras um modelo de processos de negócio. O interesse deste trabalho

é em abordagens que possuem como instâncias modelos de processos de negócio, como exemplo

a GLPN (LANDRE, 2012), definida pelo grupo de pesquisa deste trabalho.


A criação de uma LPN ocorre pela análise de vários modelos de processos de negócio de

um mesmo domínio. Estes modelos são comparados em suas atividades, atores, eventos e arte-

fatos de dados em busca de comunalidades e variabilidades. As variabilidades são gerenciadas

utilizando o mecanismo de variabilidade empregado pela linha e representadas nos modelos de

processos de negócio pela forma de modelagem de variabilidade escolhida, obtendo-se um Mo-

delo de Processos de Negócio comVariabilidade (MPNV). No caso da GLPN (LANDRE, 2012),

o mecanismo de controle de variabilidades é o modelo de features (KANG et al., 1990) e a mo-

delagem das variabilidades é realizada em BPMN* (TERENCIANI et al., 2015b), obtendo-se o

TMPN (Template de Modelo de Processos de Negócio).

Na instanciação o principal processo é a configuração de variabilidade. Esse processo

diz respeito à seleção, dentre os elementos que compõem a LPN, daqueles que farão parte da

instância. O responsável pelo processo de configuração de variabilidade terá de selecionar as

variabilidades e comunalidades que deseja na instância resultante da instanciação da linha, seja

ela software ou modelo de processos de negócio.

A GLPN (LANDRE, 2012) possui dois processos, representados na Figura 12, o EDN

- Engenharia de Domínio de Negócio que trata da criação, instanciação, validação e gerencia-

mento das LPN; e o EPN - Engenharia de Processos de Negócio, que trata da instanciação da

linha, através da configuração de variabilidade que foi descrita no parágrafo anterior.

Figura 12 –Modelo esquemático dos processos da GLPN.

Em LPNs cuja instância é um software, a configuração das variabilidades dará origem

aos artefatos necessários para a criação do software que atende ao modelo de processo de ne-

gócio que foi configurado. Já nas LPNs que produzem modelos de processos de negócio, a

configuração de variabilidades gera um modelo de processos de negócio específico, contendo

apenas as comunalidades e variabilidades que atendam às necessidades do interessado.


O processo de validação de uma LPN averígua os elementos que compõem o domínio

representado. Verifica, por exemplo, as duplicidades de elementos, se as variabilidades estão

representadas de acordo com o mecanismo proposto, se existem conflitos e se a representação

da modelagem está de acordo com o estabelecido e se a instância está sintaticamente correta

(LANDRE, 2012; TERENCIANI, 2015; FERREIRA, 2017).

Nas subseções a seguir são descritos o mecanismo e a modelagem de variabilidade, além

do processo de criação de instâncias, que são considerados pela GLPN e úteis para aplicar a

ARReq na avaliação da abordagem, apresentada no Capítulo 5.

2.3.1 Mecanismo de Variabilidade

Existem vários mecanismos para representar a variabilidade. Inicialmente a confecção

da GLPN (LANDRE, 2012) utilizou como mecanismo de representação de variabilidade o mo-

delo ortogonal (POHL; BÖCKLE; LINDEN, 2005). Coube a Terenciani (2015), através de uma

revisão de literatura, comprovar que o modelo de features era mais adequado para os objetivos

da GLPN e para a confecção do BPL-Framework 1.0.

O modelo de features, proposto por Kang et al. (1990), tem por objetivo capturar em um

modelo o entendimento dos usuários finais acerca das capacidades gerais de aplicações em um

domínio. Assim, esse modelo representa as características comuns e específicas de um conjunto

de aplicações de um domínio (KANG et al., 1990).

O modelo de features, além de possuir elementos para representar pontos de variação

e variantes, representam dependências e também restrições de variabilidade. As dependências

definem como um ponto de variação se relaciona com suas variantes, que por sua vez se relaci-

onam entre si, sendo que uma variante pode ser mandatória, opcional ou alternativa. Além da

dependência que um ponto de variação e suas variantes possuem entre si, variantes podem de-

pender de outros pontos de variação ou de outras variantes de outros pontos de variação (POHL;

BÖCKLE; LINDEN, 2005).

Na Figura 13 é ilustrado o modelo de features do subdomínio Pagamento e Entrega.

É possível observar três pontos de variação: i) Entrega, que é opcional e possui duas varian-

tes associadas por meio do relacionamento alternativo: Carro de Entrega e Entrega Simples, o

que indica que somente uma das variantes deve ser selecionada durante a configuração das va-

riabilidades na instanciação da linha; ii) Pagamento, que é obrigatório e possui três variantes


Figura 13 – Exemplo de Modelo de Features. Adaptado de Landre et al. (2014).

associadas por meio do relacionamento opcional (<< or >>): Crédito, Débito e Dinheiro, o

que indica que uma ou mais variantes deverão ser selecionadas; e iii) Recibo, que é obrigatório

e possui duas variantes associadas por meio do relacionamento alternativo: Recibo Eletrônico

e Recibo Manual. Ainda é possível observar a restrição de variabilidade do tipo Inclusão entre

a variante Crédito e a variante Recibo Eletrônico, a qual indica que se a variante Crédito for

selecionada, a variante Recibo Eletrônico deve ser selecionada também.

2.3.2 Modelagem de Variabilidade

Assim como os mecanismos de variabilidade são diversos, as técnicas de modelagem

também possuem variação na literatura, dependendo dos objetivos pretendidos.

O trabalho de Terenciani (2015) procurou, na mesma revisão da literatura verificar a téc-

nica mais adequada para a GLPN com o objetivo de modelar a variabilidade de um domínio.

Não encontrando uma técnica que atendesse os objetivos propostos pela GLPN, o autor criou a

representação BPMN* (TERENCIANI et al., 2015b), descrita a seguir, que permite representar

as comunalidades e as variabilidades, apresentadas no modelo de features, no próprio fluxo do

processo de negócio, obtendo-se o template de modelo de processos de negócio (TMPN). Esse

template permite ter uma visão geral de todas as possibilidades do negócio durante a configura-

ção da LPN e permite ao analista de negócio escolher adequadamente as variantes que deseja

em seu negócio.

Assim, na Tabela 1 estão apresentados os elementos adicionados ao BPMN para a repre-

sentação de variabilidades em modelos de processos de negócio, obtendo-se a extensão BPMN*

(TERENCIANI et al., 2015b).

Durante a concepção doBPMN* foram adicionados seis estereótipos (<< varpoint >>,

<< variant >>, << mandatory >>, << optional >>, << or >> e << xor >>) e um


Tabela 1 – Elementos da notação BPMN*. Adaptado de Terenciani et al. (2015b).

Elementos DescriçãoElemento gráfico denominado Associação de Variabilidade utilizadopara representar a associação entre um ponto de variação e sua variante.

<< varpoint >>Estereótipo utilizado na identificação de pontos de variação, ou seja, lu-gar em que a variabilidade ocorre.

<< variant >>Estereótipo utilizado na identificação de variantes, ou seja, possíveis re-soluções de pontos de variação. Uma variante sempre estará associada àum ponto de variação através do elemento Associação de Variabilidade.

<< mandatory >>Estereótipo utilizado para identificar pontos de variação que devem serobrigatoriamente resolvidos. Este estereótipo pode ser omitido.

<< optional >>Estereótipo utilizado para identificar os pontos de variação que possuemum comportamento opcional.

<< or >>

Estereótipo adicionado ao elemento Associação de Variabilidade paraidentificar o comportamento do ponto de variação. Neste caso, indicaque uma ou mais variantes do ponto de variação deverão ser seleciona-das durante a configuração de variabilidade.

<< xor >>

Estereótipo adicionado ao elemento Associação de Variabilidade paraidentificar o comportamento do ponto de variação. Neste caso, indicaque somente uma das variantes do ponto de variação deve ser selecio-nada durante a configuração de variabilidade.

featureParâmetro semelhante ao tagged value da UML para identificar a cor-respondência e manter a rastreabilidade entre os elementos do TMPN eas variabilidades do modelo de features.

elemento (associação de variabilidade) ao BPMN, correspondentes aos principais elementos do

modelo de features. Adicionalmente, foi acrescentada uma tagged value (feature) para possi-

bilitar a rastreabilidade entre o TMPN e o modelo de features.

Entre os pontos de variação apresentados na Figura 13, está o de Pagamento. Este ponto

de variação é ilustrado na Figura 14, na atividade Realizar Pagamento, utilizando BPMN*. O

estereótipo << varpoint >> indica que essa atividade corresponde a um ponto de variação

e a tagged value feature indica o nome da variabilidade correspondente no modelo de varia-

bilidades, possibilitando a rastreabilidade entre o Modelo de Features (Figura 13) e o TMPN

(Figura 14). As variantes são identificadas pelo esterótipo << variant >> e estão associa-

das ao ponto de variação por meio da associação de variabilidade com o estereótipo<< or >>,

que indica omesmo comportamento doModelo de Features. O estereótipo<< mandatory >>

indica que a atividade é obrigatória, porém este estereótipo pode ser omitido.

Os autores da notação BPMN* afirmam que, uma vez que os elementos da notação são

baseados no modelo de features, isto torna sua curva de aprendizado menor, consequentemente,

leva a uma elaboração de TMPNs com menor quantidade de erros (FERREIRA, 2017).


Figura 14 – Exemplo de TMPN. Adaptado de Terenciani et al. (2015b).

2.3.3 Instância

No caso da GLPN, os modelos de processos de negócio do domínio (PDOs) são o con-

junto de processos de negócio, em notação BPMN, que fazem parte de um domínio específico.

Estes PDOs podem ser utilizados para construir a LPN ou podem ser também o produto final

(instância) destas linhas.

Na Figura 15 está apresentado um possível PDO resultante de uma instanciação da LPN

cujo TMPN está ilustrado na Figura 14. Para a criação desta instância foram selecionadas, na

configuração de variabilidade, as variantes Pagamento em dinheiro e Pagamento em cartão de

débito. Deste modo, apenas estas opções estarão disponíveis no processo. As demais ativida-

des, Registrar compras e Emitir comprovante de pagamento, como se tratam de comunalidades,

serão mantidas em todas as instâncias do TMPN em questão.

Figura 15 – Exemplo de PDO. Adaptado de Terenciani (2015).


Como é possível realizar diversas configurações de variabilidades da LPN, os PDOs gera-

dos serão diferentes, demonstrando processos de negócio distintos, mas pertencentes ao mesmo

domínio. Deste modo é possível reusar as informações do negócio para um mesmo domínio,

economizando recursos.

2.4 Considerações Finais

A Engenharia de Requisitos conta com vários subprocessos para garantir que os requi-

sitos estejam de acordo com as necessidades do cliente em todo o ciclo de vida do software. O

objetivo deste trabalho vai de encontro a aplicação de alguns subprocessos da Engenharia de

Requisitos (elicitação, especificação) no contexto de LPN para propiciar o reúso de requisitos a

partir da instanciação desse tipo de linha.

Os modelos de processos de negócio são uma forma relativamente recente de representar

o negócio e têm se tornado objeto de diversos trabalhos devido a sua importância tanto para a

melhoria do negócio quando para a elicitação de requisitos de software.

As LPNs são um conceito criado em 2006 que possibilitam reusar os modelos de proces-

sos de negócio pertencentes ao mesmo domínio, tornando a modelagem de processos de negócio

uma atividade menos custosa, mais eficiente e menos sujeita a erros, duplicidades e ambiguida-

des, pois reaproveita elementos, processos e subprocessos já alinhados com o negócio.

A partir dos PDOs, que sãomodelos de processos de um negócio específico, é possível ao

analista de requisitos elicitar os requisitos de sistema que são desejáveis pelo cliente conforme

já descrito na Seção 2.2 deste capítulo. Porém, nesse caso, os requisitos são elicitados para cada

modelo de processos de negócio resultante da instanciação da linha, diferentemente quando os

requisitos são elicitados da LPN, o que permite o reúso dos requisitos correspondentes a cada

PDO da linha. Infere-se que, com isso, menos recursos são necessários para a obtenção dos

requisitos se comparado à obtenção a partir dos PDOs.

Com base em todas as teorias e conceitos apresentados é definida, neste trabalho, a AR-

Req para apoiar subprocessos da Engenharia de Requisitos, em especial a elicitação e especifi-

cação, e assim permitir o reúso dos requisitos a partir de LPNs.

55

3 Revisão Sistemática da Literatura

Neste capítulo é apresentada uma revisão sistemática da literatura com o objetivo de atu-

alizar a revisão sistemática conduzida por Bitencourt, Paiva e Cagnin (2016). Para a elaboração

desta revisão foi utilizado omodelometodológico proposto porWohlin (2014) e por Kitchenham

et al. (2009), na intenção de fornecer o estado da arte sobre a elicitação de requisitos a partir de

modelos de processos de negócio em BPMN e descobrir lacunas que possam ser preenchidas

por este trabalho.

A opção pela temática da elicitação de requisitos a partir de modelos de processos de

negócio em BPMN se deveu pela possibilidade de analisar os dados, comparativamente, com o

trabalho anterior de Bitencourt, Paiva e Cagnin (2016), pela maneira como esses modelos tem

ganhado espaço na Engenharia de Requisitos (CHINOSI; TROMBETTA, 2012) e por BPMN ser

uma linguagem que permite a compreensão dos processos de negócio tanto pelos interessados,

quanto pela equipe de desenvolvimento.

A organização deste capítulo segue a seguinte estrutura: na Seção 3.1 é explicado como

foi realizado o planejamento da Revisão Sistemática da Literatura; na Seção 3.2 é apresentada

a condução da revisão; na Seção 3.4 é descrita a síntese dos resultados obtidos; e, por fim, na

Seção 3.5 encontram-se as considerações finais.

3.1 Planejamento da Revisão

As questões de pesquisa, a string de busca e alguns dos critérios para inclusão e exclu-

são de trabalhos retornados, que fizeram parte da revisão sistemática conduzida por Bitencourt,

Paiva e Cagnin (2016), foram aqui retomados e atualizados.

Nas subseções seguintes é apresentada a forma como foram atualizadas as questões e a

estratégia de pesquisa, bem como a seleção das bases de busca e a string padrão inicial para as

buscas e os critérios adotados para a inclusão e exclusão de trabalhos.

Para levantar um número maior de trabalhos relacionados ao interesse de pesquisa deste

mestrado, optou-se por acrescentar à revisão sistemática o processo de snowballing, que consiste

56 Capítulo 3. Revisão Sistemática da Literatura

em procurar de forma sistemática nas referências bibliográficas dos textos retornados pelas fer-

ramentas de busca, outros textos que possam ser de interesse deste trabalho.

3.1.1 Questões de Pesquisa

As questões de pesquisa utilizadas neste trabalho foram as propostas na revisão siste-

mática conduzida por Bitencourt, Paiva e Cagnin (2016). Acrescentando-se uma outra questão,

QP-2, que trata sobre a forma como os requisitos são especificados, pois esta informação é im-

portante para o escopo desta pesquisa, visto que os requisitos elicitados devem ser especificados

de alguma forma. As questões de pesquisa estão apresentadas no Quadro 1.

Quadro 1 – Questões de pesquisa.

Questão Descrição

QP-1 Como requisitos são elicitados a partir de modelos de processos de negócios?QP-1.1 Quais os tipos de requisitos que são elicitados?QP-1.2 Em que forma os requisitos são elicitados?QP-2 Quais técnicas de especificação de requisitos são utilizadas?

Com o objetivo de realizar a Engenharia de Requisitos a partir de modelos de processos

de negócio em BPMN, é importante analisar como os estudiosos abordam os dois processos

fundamentais: a elicitação e a especificação de requisitos a partir dos modelos em BPMN.

Esta verificação permitirá que se identifique abordagens para elicitar os requisitos e as

formas mais comuns de especificar os requisitos em seus trabalhos. Deste modo pretende-se

manter a pesquisa alinhada às tendências já existentes na literatura.

3.1.2 Bibliotecas Digitais e String de Busca Padrão

Para realizar a revisão sistemática optou-se por pesquisar nas seguintes bibliotecas di-

gitais: ACM1, Science Direct2, Compendex3, Scopus4 e IEEE Xplore5. Elas foram escolhidas

devido a quantidade de trabalhos armazenados e sua relevância para a área de Computação.

Para a busca dos trabalhos foi construída uma string de busca padrão, apresentada no

Quadro 2, e que foi adaptada de acordo com os parâmetros de cada biblioteca digital. Para garan-1<http://dl.acm.org/>2<http://www.sciencedirect.com/science/search>3<https://www.engineeringvillage.com/search/quick.url>4<https://www.scopus.com/>5<http://ieeexplore.ieee.org/search/advsearch.jsp>

http://dl.acm.org/

http://www.sciencedirect.com/science/search

https://www.engineeringvillage.com/search/quick.url

https://www.scopus.com/

http://ieeexplore.ieee.org/search/advsearch.jsp

3.1. Planejamento da Revisão 57

tir a eficácia da busca, a pesquisa pelos termos, quando permitido pela biblioteca, foi realizada

nos títulos, palavras-chave e resumos dos trabalhos.

Quadro 2 – String de busca padrão.

((“business process model”) AND (“functional requirement” OR “non functional re-quirement” OR “Requirement Engineering” OR “Requirement Elicitation” OR “Elici-tation of Requirement”) AND (BPMNOR “Business ProcessModel andNotation”OR“Business Process Modeling Notation” OR “Business Process Modelling Notation”))

Também foi realizada uma busca no Banco de Teses e Dissertações6 (BTD), acervo uti-

lizado no trabalho de Bitencourt, Paiva e Cagnin (2016), que é mantido pela CAPES (Coor-

denação de Aperfeiçoamento de Pessoal de Nível Superior). Esta biblioteca digital conta com

publicações de teses e dissertações em diversas áreas. Na pesquisa realizada nesta biblioteca

digital a string de busca padrão foi adaptada para o português.

Na string padrão de busca optou-se por não incluir o termo LPN, Linha de Processo de

Negócio e seus sinônimos, pois criaria uma limitação ao universo de busca que tornaria o resul-

tado muito específico e restrito, excluindo trabalhos que poderiam ter informações relevantes

para o sucesso da abordagem proposta neste trabalho de mestrado.

Os termos relativos a especificação de requisitos não foram incluídos na string padrão por

não acrescentarem informações relevantes para o sucesso das buscas. Os trabalhos que tratam

de elicitação de requisitos, em sua maioria, apresentam esses requisitos de alguma forma, o que

caracteriza o subprocesso de especificação, não sendo possível especificar os requisitos sem

antes elicitá-los tendo por base o modelo em BPMN.

3.1.3 Critérios de Inclusão e Exclusão

Os critérios utilizados para incluir (CI) ou excluir (CE) um trabalho no conjunto de estu-

dos que foram analisados nesta revisão sistemática estão apresentados no Quadro 3.

Optou-se por não incluir no Quadro 3 um Critério de Inclusão (CI) específico para espe-

cificação de requisitos pelo fato de que a elicitação de requisitos é pré-requisito para a especifi-

cação de requisitos a partir de modelos de processos de negócio em BPMN.

6<http://bancodeteses.capes.gov.br/banco-teses>

http://bancodeteses.capes.gov.br/banco-teses


Quadro 3 – Critérios de inclusão e exclusão.

Sigla Critério

CI1 O estudo apresenta um abordagem para elicitar requisitos a partir de modelosde processos de negócio em BPMN;

CI2 O estudo descreve uma ou mais atividades para elicitar requisitos de modelosde processos de negócio em BPMN;

CI3 O estudo apresenta uma adaptação do modelo de processo de negócio emBPMN para elicitar requisitos;

CE1 O estudo está fora do escopo de elicitação de requisitos a partir de modelos deprocessos de negócio em BPMN;

CE2 O estudo não é um texto científico (é um manual ou relatório); e

CE3 O estudo não está escrito em inglês ou português.

3.1.4 Estratégias de Pesquisa

As estratégias para a condução da pesquisa bibliográfica foram baseadas nos passos uti-

lizados por Kitchenham et al. (2009) e estão elencados a seguir:

• Criação de banco de dados de trabalhos a partir da extração dos estudos das bibliotecas

digitais selecionadas utilizando a string padrão de busca definida na Seção 3.1.2. Para o

gerenciamento deste banco de trabalhos foi utilizada a ferramentaMendely Desktop7. Sua

escolha se deveu aos recursos da ferramenta e ao conhecimento que o autor já possui de

seu uso.

• Eliminação dos estudos duplicados;

• Filtragem dos estudos por título, palavras-chave e análise do resumo usando os critérios

de inclusão e exclusão, definidos na Seção 3.1.3;

• Composição do start set para o processo de snowballing. O start set representa o conjunto

inicial de trabalhos, obtidos a partir das ferramentas de busca das bibliotecas digitais e que

atendemos critérios de inclusão e exclusão. São os trabalhos a partir dos quais se procederá

o processo de snowballing;

• Verificação das referências dos trabalhos selecionados para a seleção de novas referências.

Tomando como base os critérios definidos na Seção 3.1.3;

• Inclusão dos trabalhos referenciados e selecionados no banco de trabalhos;

• Leitura para construção da síntese de cada trabalho selecionado; e

7Disponível para download em <https://www.mendeley.com/>

https://www.mendeley.com/

3.2. Condução da Revisão 59

• Responder as questões de pesquisa definidas no Quadro 1 e elaborar as conclusões a partir

da síntese dos trabalhos selecionados.

3.2 Condução da Revisão

A string de busca padrão sofreu pequenas alterações para se adaptar aos mecanismos

de busca de cada acervo digital de modo que os resultados atendessem os critérios pretendidos.

Estes critérios são os termos básicos da pesquisa e incluem: Engenharia de Requisitos, BPMN

e os tipos de requisitos (funcional e não funcional).

Os quantitativos de trabalhos retornados por cada biblioteca digital na busca realizada

no período de novembro de 2016 a janeiro de 2017 estão apresentados na Tabela 2.

Tabela 2 – Estudos retornados pelas máquinas de busca das bibliotecas digitais.

Acervo digital Estudos retornadosACM 122Scopus 35Compendex 16Science Direct 11IEEE Xplore 191BTD 69Total 444

Para armazenar e gerenciar os resultados desta primeira busca foi criado um banco de

dados com as referências de cada trabalho retornado das bibliotecas digitais e seu respectivo

resumo.

Com o apoio da ferramenta de gerenciamento, foram excluídos os trabalhos duplicados

e aplicado o critério de exclusão que trata dos trabalhos que não estejam em inglês ou português

(CE3). Depois, pela leitura do resumo de cada trabalho restante, foram aplicados os demais

critérios de inclusão e exclusão que foram definidos anteriormente no Quadro 3.

O resumo do processo de eliminação dos trabalhos duplicados e a aplicação dos critérios

de inclusão e exclusão pode ser visualizado na Tabela 3, organizado por biblioteca digital. Os

números negativos indicam o quantitativo de trabalhos retirados do banco de trabalhos.

Destes 54 estudos restantes no banco de trabalhos foram lidos o resumo, a introdução e,

se necessário, a conclusão, com apoio da professora orientadora, em busca de tópicos, concei-

tos e informações que comprovassem que o trabalho era de interesse do escopo desta revisão.


Tabela 3 – Resumo do processo de aplicação dos critérios de inclusão e exclusão.

Acervo digital Inicial Duplicados CE1 CE2 CE3 FinalACM 122 -2 -110 -2 0 8Scopus 35 -7 -16 -4 -1 7Compendex 16 0 -9 0 0 7Science Direct 11 -1 -6 0 0 4IEEE Xplore 191 -4 -165 -3 0 19BTD 69 0 -60 0 0 9Total 444 -14 -366 -9 -1 54

Com esse procedimento houve uma significativa redução na quantidade de estudos no banco de

dados dos trabalhos, conforme indicado na Tabela 4, em que, novamente, os números negativos

indicam o quantitativo de trabalhos que foram retirados do banco de trabalhos.

Neste processo de leitura a maior parte dos trabalhos foi excluída por apresentar formas

de elicitação de requisitos a partir de modelos de processos de negócio que não estavam represen-

tados em BPMN. Outro motivo para a exclusão dos trabalhos foi a constatação de que trataram

de formas para representar mais eficientemente os requisitos e regras de negócio nos modelos

de processos de negócio, melhorando a qualidade do modelo, objetivando facilitar uma futura

elicitação, mas não discorrendo sobre o processo de elicitação em si.

Tabela 4 – Quantidade de trabalhos após a leitura do resumo, introdução e conclu-são.

Acervo digital Inicial Leitura FinalACM 8 -8 0Scopus 7 -4 3Compendex 7 -6 1Science Direct 4 -4 0IEEE Xplore 19 -17 2BTD 9 -5 4Total 54 -44 10

3.2.1 Análise do start set

A última coluna da Tabela 4 apresenta a quantidade de estudos selecionados para leitura

completa e extração das informações para responder as questões de pesquisa apresentadas no

Quadro 1. Estes trabalhos foram agrupados em um start set, um conjunto inicial de trabalho,

sobre o qual se aplicou o processo de snowballing a partir das referências bibliográficas neles

existentes.

3.3. Execução do snowballing backward 61

Para melhor visualização e apresentação, os trabalhos do start set foram organizados no

Quadro 4. O Brasil possui muitos textos nessa área, destacando-se Rio de Janeiro, Pernambuco

e Amazonas. Essas são as regiões de origem dos trabalhos de Souza (2014), Vieira (2012) e seus

colaboradores.

Quadro 4 – Estudos selecionados para composição do start set.

Sigla Citação Tipo Publicação País

BTD1 Chiarello (2013) Dissertação Brasil

BTD2 Souza (2014) Dissertação Brasil

BTD3 Vieira (2012) Dissertação Brasil

BTD4 Vieira et al. (2012b) Conferência Brasil

COMP Vara e Sánchez (2009) Conferência Espanha

I3E1 Sinha e Paradkar (2010) Conferência EUA

I3E2 Sriganesh e Ramanathan (2012) Conferência Índia

SCP1 Cruz, Machado e Santos (2014a) Conferência Portugal

SCP2 Cruz, Machado e Santos (2015a) Conferência Portugal

SCP3 Cruz, Machado e Santos (2016) Conferência Portugal

No Quadro 5 é apresentado um breve resumo dos dez trabalhos do start set e suas abor-

dagens para a elicitação de requisitos a partir de modelos de processos de negócio.

3.3 Execução do snowballing backward

O processo de snowballing consiste em verificar se há trabalhos de interesse a partir das

referências bibliográficas dos trabalhos já retornados pelas bibliotecas digitais. Para execução

deste processo utilizou-se os procedimentos apresentados na Figura 16 que foram executados

para os dez trabalhos que compunham o start set, sendo realizada apenas uma iteração do snow-

balling backward, ou seja, não se verificou possíveis trabalhos de interesse nas bibliografias dos

trabalhos obtidos a partir das bibliografias que compunham o start set.

A Tabela 5 apresenta os resultados do snowballing para os trabalhos do start set. Nesta

etapa foram catalogadas as referências e analisados os títulos de interesse. Os números negativos

indicam os trabalhos que foram excluídos pelo título da relação de referências. Os números da

última coluna indicam os trabalhos adicionados à lista de trabalhos para posterior leitura dos

resumos e introduções.

O quantitativo final de 73 trabalhos na lista para leitura passou por mais dois filtros: a eli-

minação dos trabalhos duplicados, computando 27 eliminações; e dos trabalhos que não estavam


Quadro 5 – Síntese dos trabalhos do start set.

Sigla Resumo

BTD1

Apresenta uma proposta para elicitação de requisitos, mas não trata de regras de negócio enão oferece automação. Verificação da validade da proposta é fraca quanto a fundamentaçãoe aos testes. Consiste em seguir um arcabouço, com partes fixas, que devem ser preenchidassegundo o modelo. Define problemas, envolvidos, funcionalidades, atividades e as fronteirasdo problema.

BTD2

Destaca a utilização de MDD (desenvolvimento dirigido a modelos). Utiliza modelos de pro-cesso de negócio como ponto de partida para engenharia de requisitos e oferece suporte au-tomatizado. Utiliza os modelos de processo de negócio como CIM (Modelo Independentede Computação), dentro do MDA (arquitetura dirigida a modelos). Há três conceitos funda-mentais: modelo de negócio, modelo de requisitos e modelo do sistema. Utiliza como basepara transformação do BPMN em requisitos as heurísticas da técnica REMO, de BDT3, e otrabalho de Cibrán (2009), que não foi selecionado neste trabalho por utilizar modelos emUML.

BTD3Apresenta as heurísticas da técnica REMO para extração de requisitos funcionais, não funci-onais e regras de negócio a partir de modelos de processos de negócio em BPMN. Apresentaa evolução da construção da heurística e sua construção final com os testes de validação.

BTD4

Este artigo é uma parte do trabalho BDT3. Mostra a evolução da técnica REMO da primeirapara a segunda versão e apresenta os resultados dos testes de validação. Há trabalhos inte-ressantes na revisão de literatura sobre técnicas para elicitação de requisitos baseadas emprocessos de negócio em várias linguagens.

COMPVisa apresentar uma abordagem que guia apropriadamente a especificação de requisitos fun-cionais a partir de modelos de processos de negócio. Propõe uma extensão do BPMN quepermite a elicitação das descrições das tarefas auxiliando no desenvolvimento do software.

I3E1

Neste trabalho é apresentado uma técnica para transformar semi-automaticamente processosde negócio escritos no formato de Casos de Uso em processos de negócio na linguagemBPMN, e criar mapeamento entre eles. A transformação é feita com base na análise das descri-ções textuais do Caso de Uso que cria subprocessos BPMN correspondentes a partes do casode uso. Em seguida, explora a relação definição-uso entre os objetos de negócio e deriva umarepresentação intermediária que pode ser utilizada pelo analista de negócio para a criação deum modelo de processo de negócio adequado aos objetivos.

I3E2Propõe uma técnica para identificar e extrair regras de negócio que estão representadas emmodelos de processos de negócio escritos em BPMN. Esta técnica analisa os gateways embusca de decisões que possam identificar regras de negócio.

SCP1O objetivo deste trabalho é definir um método capaz de obter representação de requisitos desoftware, em UML, a partir de um conjunto de modelos de processo de negócio em BPMNpreviamente fornecidos.

SCP2Este artigo apresenta uma abordagem que procura agregar em um modelo de casos de usotodas as informações que podem ser extraídas de um conjunto de modelos de processos denegócio que servirão de suporte para o desenvolvimento de um software.

SCP3

O artigo trata de como construir o modelo de dados a partir de modelos de processos denegócio. Para isso os diagramas de processos de negócio, em BPMN, serão entrada para atécnica 4SRS e esta construirá a arquitetura lógica do sistema, com seus objetos e modelos declasse representados em UML.

em língua inglesa ou em português (CE3), com o qual apenas 1 trabalho precisou ser excluído.

Para os 45 trabalhos restantes procedeu-se a leitura do resumo e introdução para verificar se

pertenciam ao escopo da revisão sistemática.

3.4. Síntese dos Resultados 63

Figura 16 –Metodologia para realizar o snowballing backward.

Tabela 5 – Quantitativo dos trabalhos após o snowballing backward.

Sigla Qtde deReferências

Excluídas pelotítulo Lista para leitura

BTD1 57 -43 14

BTD2 66 -58 8

BTD3 55 -42 13

BTD4 36 -23 13

COMP 28 -25 3

I3E1 12 -10 2

I3E2 19 -19 0

SCP1 48 -38 10

SCP2 26 -19 7

SCP3 18 -15 3

Total 365 -292 73

Com a leitura do resumo e da introdução, 33 trabalhos foram considerados fora do es-

copo por não atenderem os critérios de inclusão (CI) apresentados na Tabela 3. Os 12 trabalhos

finais selecionados para leitura completa, resumo e levantamento das respostas das questões de

pesquisa estão listados no Quadro 6 e resumidos no Quadro 7.

3.4 Síntese dos Resultados

Analisando a relação dos trabalhos no Quadro 4 e no Quadro 6 quanto ao tipo das pu-

blicações e apoiado pela Figura 18a é possível verificar que a elicitação de requisitos a partir

de modelos de processos de negócio em BPMN se mostra incipiente, pois contém 64% dos


Quadro 6 – Estudos selecionados por snowballing backward.

Sigla Citação Publicação País

SNW01 Carvalho (2009) Dissertação Brasil

SNW02 Carvalho, Escovedo e Melo (2009) Conferência Brasil

SNW03 Cruz, Machado e Santos (2014b) Conferência Portugal

SNW04 Cruz, Machado e Santos (2014c) Conferência Portugal

SNW05 Cruz, Machado e Santos (2015b) Conferência Portugal

SNW06 Vara e Diáz (2007) Journal Espanha

SNW07 Vara et al. (2008) Capítulo Espanha

SNW08 Hernández, Rodríguez e Martin (2010) Conferência México

SNW09 Rodríguez, Fernández-Medina e Piattini (2007) Capítulo Chile

SNW10 Rodríguez, Fernández-Medina e Piattini (2008) Capítulo Chile

SNW11 Rungworawut e Senivongse (2005) Conferência Tailândia

SNW12 Vieira et al. (2012a) Conferência Brasil

trabalhos apresentados em conferências, 18% são dissertações de mestrado, 14% são capítulos

de livros específicos da área de Engenharia de Software e há apenas uma publicação, 4%, em

Journal.

Levando em consideração todos os trabalhos selecionados, a Figura 17 permite observar

que os trabalhos se concentram nos anos de 2012 e 2014 e que não foram encontrados trabalhos

anteriores a 2005 que fossem de interesse desta revisão. Com isso, observa-se que a pesquisa

sobre elicitação de requisitos a partir de modelos de processos de negócio é recente, tendomenos

de duas décadas (VARA; SÁNCHEZ, 2009) e mantém, em média, 2 publicações por ano.

Figura 17 – Trabalhos publicados por ano.

Pela leitura dos trabalhos se verifica o aprofundamento do aproveitamento da modela-

gem de processos de negócio em BPMN como fonte dos requisitos e das regras de negócio para

as equipes de desenvolvimento de software, de modo que os trabalhos mais recentes procuram

a automatização e a utilização de heurísticas a fim de melhorar a qualidade dos requisitos elici-


Quadro 7 – Síntese dos trabalhos selecionados por snowballing backward.

Sigla Resumo

SNW01

Dissertação de mestrado em Engenharia da Produção. Reúne os trabalhos que usam os processos denegócio para elicitar requisitos do sistema. Dez trabalhos são analisados e a conclusão é que 9 das10 abordagens representam o processo de negócio em diagramas UML; a exceção utiliza um modelogenérico (independente de representação) que especifica em forma de Documento de requisitos. Nãoapresenta uma proposta própria.

SNW02Apresenta uma proposta genérica (sem uma linguagem definida para representação do modelo de pro-cesso de negócio) para a transformação do modelo de processos de negócio em modelo de requisitos.Se baseia no trabalho de Knight (2004) e na Engenharia de Processos de Negócio. Não especifica comoos requisitos são apresentados e exige participação dos interessados no processo.

SNW03Apresenta um método para gerar um modelo de software, com seus requisitos, baseado em um conjuntode modelos de processos de negócio inter-relacionados previamente fornecidos, com especial atenção amodelagem dos dados da aplicação e como será o suporte ao negócio.

SNW04Abordagem em que elicita requisitos a partir de modelos de processos de negócio representados emBPMN para especificar como descrição dos casos de uso para, no fim, apresentar como modelos decasos de uso. Fornece regras (heurísticas) para transformar elementos do BPMN na descrição dos casosde uso.

SNW05Trata de uma abordagem para criar um modelo de casos de uso descritivos obtidos a partir de um con-junto de diagramas de processos de negócio em BPMN que sejam inter-relacionados. Para obter o resul-tado são utilizadas duas abordagens detalhadas em trabalhos anteriores dos autores: a transformação deBPMN em modelos de caso de uso e o uso da decomposição triangular.

SNW06

Descreve uma abordagem que deriva modelos de requisitos a partir de modelos organizacionais pormeio de modelagem de objetivos. Parte de modelos de negócio em BPMN, cria um árvore de objetivose, por fim, especifica os requisitos no formato de modelos de casos de uso. A árvore de objetivos écriada em linguagem i* e segue heurísticas que não estão no artigo. Os passos para execução consistemem: i) gerente de negócio fornece os objetivos empresariais; ii) analista de negócio faz a modelagem dainfraestrutura do negócio e, iii) analista de sistemas define a infraestrutura de TI. Depois desses passosse constrói o BPMN, a árvore de objetivos e, por fim, o modelo de casos de uso.

SNW07

O ambiente de negócios é modelado na forma de diagramas BPMN. Os diagramas são validados pe-los usuários finais e são analisados por analistas de sistemas para chegar a um acordo sobre o efeitoque o sistema de informação terá sobre a organização. Finalmente, os requisitos são especificados pormeio da descrição das tarefas do processo de negócios a serem suportadas pelo sistema de informação.A abordagem consiste em três estágios: modelagem organizacional, análise do processo de negócio eespecificação dos requisitos funcionais.

SNW08

Cria uma abordagem chamada Use Processes (UP), baseada em BPMN e no diagrama de casos deuso (UML), que representa os processos de negócio em um UPD (Diagrama de Processos de Uso).Esta abordagem possui cinco passos: definição do problema a ser resolvido; modelagem do processo denegócio (em BPMN); definição dos limites do sistema; descrição das atividades e dos atores envolvidos;identificação e descrição das funcionalidades do sistema. As funcionalidades são especificadas comocasos de uso, utilizando templates sugeridos no trabalho.

SNW09Segue o paradigma MDA. Aborda BPMN’s estendidos com informações para segurança (BPSec). Pro-põe uma abordagem para converter um BPMN em diagramas de caso de uso (UML) para especificar osrequisitos. Esta transformação utiliza regras QVT (Query View Transformation).

SNW10Segue o paradigmaMDA. Propõe uma transformação mediante QVT a partir do modelo de negócios emBPMN para os diagramas de classe e casos de uso (UML) como representação dos requisitos durante aexecução das disciplinas Modelagem de negócio e Requisitos do PU (Processo Unificado).

SNW11

Segue o paradigma MDA. Propõe um abordagem para converter um BPM em um PIM (Modelo In-dependente de Plataforma). A partir de um modelo de processos de negócio em BPMN pretende criarum diagrama de classes UML enriquecido com detalhes e informações semânticas sobre o domínio emum trabalho feito manualmente. Usa uma estratégia de identificação de substantivos no BPM e umaestratégia de categoria de conceitos (criadas pelos analistas do negócio) para interpretar o BPM.

SNW12Utiliza uma série de estudos empíricos para avaliar a técnica REMO, composta pelas heurísticas criadaspelo autor. Extrai os requisitos e regras de negócio de diagramas em BPMN mas não informa comoespecificá-los.

tados, pois os elicitam já alinhados com o negócio, com menor custo (tempo e pessoal) e com

menor chance de erro (não atomicidade, ambiguidade, incompletude, duplicidade e conflitos de

requisitos).


Avaliando os trabalhos quanto a conformidade com as questões de pesquisa, propostas

no Quadro 1, tem-se o resultado apresentado no Quadro 8. Para uniformizar as respostas, foram

utilizadas as seguintes siglas, agrupadas por interesse:

• Tipos de requisitos: RF – Requisitos funcionais; RNF – Requisitos não funcionais; RN

– Regras de negócio; NC – Não classifica.

• Forma de elicitação:M – Manual; A – Automatizada;

• Técnica de especificação: DR – Documento de Requisitos; CS – Caso de Uso; EU -

Estórias de Usuário; DT – Descrição de Tarefas; NC – Não Consta ou não deixa claro;

OU – Outros formatos;

Observou-se que 59% dos trabalhos elicitam apenas requisitos funcionais (RF), enquanto

18% extraem os requisitos funcionais, não funcionais e as regras de negócio (RF, RNF, RN) e

que 18% não informam (NC), ou não deixam claro, o tipo de requisito que estão elicitando a

partir dos modelos de processos de negócio, enquanto que 5% elicitam apenas regras de negócio

(RN) como se observa na Figura 18b.

Quanto a forma de condução da elicitação de requisitos, 41% dos trabalhos se preocupam

em automatizar a elicitação, uma queda se considerarmos apenas os trabalhos do start set em

que 60% das propostas utilizam a automação. Os 59% restantes utilizam a elicitação manual,

conforme se observa na Figura 18c. Esta informação reforça a crescente procura pela automação

da elicitação de requisitos nos trabalhos mais recentes.

A respeito das técnicas de especificação, a Figura 18d nos permite observar que os for-

matos mais comuns são os Casos de Uso (CS), com 45% e o Documento de Requisitos (DR),

com 23%. Destaca-se que não houve trabalhos que tenham especificado requisitos no formato

de Estórias de Usuário (EU) e que 18% não deixaram claro o tipo de especificação que empre-

garam em seus estudos. A descrição de tarefas (DT) contou com 9% dos trabalhos e 1 trabalho

(5%) especificou os requisitos como diagramas de atividades da UML enriquecidos, registrado

como outros formatos de especificação (OU).

Diante dos estudos selecionados, observa-se que houve aumento nas pesquisas na área

de elicitação de requisitos a partir de modelos de processos de negócio em BPMN. O foco da

elicitação ainda está voltado para os modelos representados em UML, o que levou a exclusão


Quadro 8 – Respostas às questões de pesquisa (Start set).

Sigla QP-1 QP-1.1 QP-1.2 QP-2

BTD1

A partir de um arcabouço próprio, iterativo, que define proble-mas, envolvidos e modela o processo descrevendo as suas ativi-dades e envolvidos nestas atividades para, enfim, descrever asfuncionalidades que o software terá.

RF M NC

BTD2

Faz a identificação e especificação de requisitos utilizando a abor-dagem MDD, de forma automatizada – ferramenta ModelER – ,através de um arquivo XML de um modelo de processo de negó-cio e utilizando uma linguagem de transformação entre modelos– ATL gerando arquivos XML com os requisitos.

NC A DR

BTD3

Apresentam uma proposta de uma técnica de elicitação de requi-sitos, denominada REMO, a qual é guiada por um conjunto deheurísticas para extrair os requisitos a partir de diagramas de pro-cessos de negócios em BPMN.

RF,RNF,RN

M DR

BTD4 Apresenta a Técnica REMO, evoluída, para elicitar requisitos apartir de diagramas de processos de negócio em BPMN.

RF,RNF,RN

M DR

COMP

Cria um guia, um arcabouço em duas etapas – enriquecimentodo modelo de processo de negócio e especificação das tarefasdo sistema –, para analisar os modelos de processos de negócio,em conjunto com os stackholders, e extrair apenas os requisitosfuncionais e apresentá-lo com o formato de descrição de tarefas(e subtarefas, se for o caso).

RF M DT

I3E1

Demonstra um algoritmo que permite converter casos de uso emmodelos de processos de negócio ou diagramas UML. Utilizaprocessamento de linguagem natural e algumas heurísticas paratransformar o texto nos diagramas. Técnica transpõe os requisitosencontrados no texto para os diagramas. Não é uma ferramentade elicitação.

NC A NC

I3E2Procura extrair regras de negócio dos modelos de processo denegócio em BPMN analisando os gateways em busca de regrasde negócio.

RN A NC

SCP1

Propõe a criação de casos de uso e demodelos de dados a partir demodelos de processos de negócio em BPMN e nos casos de usoespecifica os requisitos funcionais. Utiliza um arcabouço própriopara realizar a transformação.

RF A CS

SCP2

Apresenta uma abordagem para criar um modelo de casos de usoque tenha origem em vários modelos de processos de negócio.Usa uma abordagem iterativa e incremental que inicia identifi-cando o escopo do sistema e os atores envolvidos, depois as prin-cipais funcionalidades são identificadas e apresentadas ao usuá-rio que as aprova.

RF A CS

SCP3

Propõe uma adaptação e extensão do método 4SRS (4-Step RuleSet) para gerar um modelo de dados que será utilizado para criara arquitetura lógica e elicitar os requisitos a partir de um conjuntode modelos de processos de negócio em BPMN.

RF A CS

de grande parte dos trabalhos retornados pelas máquinas de busca e das referências analisadas

no snowballing.


Quadro 9 – Respostas às questões de pesquisa (Snowballing).

Sigla QP-1 QP-1.1 QP-1.2 QP-2

SNW01 Analisa vários trabalhos mas não apresenta um método próprio. NC M NC

SNW02

Propõe um método genérico que usa como ponto de partida os estágiosde implementação de métodos de projeto e ferramentas da Engenhariade Processos de Negócio e alguns elementos da abordagem proposta porKnight (2004).

RF, RNF,RN M DR

SNW03

Obtém uma descrição de casos de uso a partir de um conjunto de pro-cessos de negócio modelados em BPMN e que sejam inter-relacionados.Usando várias técnicas abordadas em outros trabalhos permite criar asdescrições de caso de uso usando um template simplificado

RF A CS

SNW04

Abordagem dividida em duas partes: utiliza um conjunto de regras paraobter um diagrama de casos de uso a partir de BPMN; depois utiliza asregras para derivar as descrições dos casos de uso identificados anterior-mente. Com essas informações é preenchido um template de descriçãode caso de uso que contém os requisitos funcionais e não funcionais.

RF M CS

SNW05

Utilizadas duas abordagens detalhadas em trabalhos anteriores dos au-tores: a transformação de BPMN em modelos de caso de uso e o uso dadecomposição triangular (identificação dos atores e dos escopo; identi-ficação das principais funcionalidades; identifica operações CRUD).

RF M CS

SNW06

A abordagem possui três passos: conhecer a estratégia do negócio; ma-pear a infraestrutura do negócio (onde serão construídos os BPMN dosprocessos de negócio) e, por fim, conhecer a infraestrutura de TI. Comessas informações é possível, partir dos modelos de processos de negó-cio em BPMN, criar uma árvore de objetivos (modelada em i*) e, porfim, especificar os requisitos no formato de modelos de casos de uso

RF M CS

SNW07A abordagem consiste em três etapas: modelagem organizacional, aná-lise de processos de negócios e especificação de requisitos funcionais.Necessita da aprovação e intervenção dos interessados.

RF M DT

SNW08

Esta abordagem possuí cinco passos: definição do problema a ser resol-vido; modelagem do processo de negócio (em BPMN); definição dos li-mites do sistema; descrição das atividades e dos atores envolvidos; iden-tificação e descrição das funcionalidades do sistema.

RF M CS

SNW09Propõe uma abordagem para converter umBPMN em diagramas de casode uso. Para esta transformação utiliza regras QVT (query view transfor-mation).

RF A CS

SNW10 Propõe uma abordagem para converter os diagramas em BPMN em dia-gramas de caso de uso utilizando regras QVT. RF A CS

SNW11

A partir de um BPMN pretende criar um diagrama de classes UML en-riquecido com detalhes e informações semânticas sobre o domínio. Usauma estratégia de identificação de substantivos no modelo de processode negócio e uma estratégia de categoria de conceitos (criadas pelos ana-listas do negócio) para interpretar este modelo.

NC M OU

SNW12 Utiliza heurísticas para, manualmente, percorrer um BPMN e elicitar osrequisitos funcionais, não funcionais e as regras de negócio

RF, RNF,RN M DR

Observou-se também melhoria na qualidade dos requisitos extraídos de modelos de pro-

cessos de negócio, devido às novas técnicas de elicitação (uso de heurísticas, de regras QVT), a

automação e a utilização de extensões à linguagem BPMN para representar melhor os requisitos

ou para incluir requisitos não antes representados.

Contudo, ainda é complexo representar e elicitar requisitos não funcionais e regras de

negócio a partir de modelos em BPMN. Fato corroborado pela pouca quantidade de trabalhos

que se dedicam a esse fim.

3.5. Considerações Finais 69

(a) Tipo de publicação. (b) Tipo de requisitos.

(c)Mecanismo de elicitação. (d) Técnica de especificação.

Figura 18 – Distribuição dos resultados nos trabalhos selecionados.


Neste capítulo foi apresentada uma revisão sistemática com o intuito de atualizar o es-

tado da arte observado em uma revisão sistemática anterior (BITENCOURT; PAIVA; CAGNIN,

2016). A revisão sistemática realizada procurou enriquecer a busca por trabalhos com informa-

ções relevantes com o apoio da técnica snowballing. A partir dos estudos primários selecionados

observou-se que a elicitação de requisitos a partir demodelos de processos de negócio emBPMN

é recente, commenos de 15 anos; encontra-se bem automatizada, contando com apoio de heurís-

ticas e transformações via QVT; dedica-se principalmente a requisitos funcionais; e especifica

os requisitos, na maioria dos trabalhos, como casos de uso.

Como principais limitações da revisão sistemática destaca-se a realização de apenas uma

iteração da técnica snowballing; e a ausência de padronização dos termos e conceitos emprega-

dos pelos autores, o que foi, em parte, amenizado com o uso do snowballing, mas ainda pode

ter deixado trabalhos interessantes fora da pesquisa por utilizarem conceitos com nomenclaturas

distintas da empregada nesta revisão.


Deste modo, constata-se a existência de poucos trabalhos que tratam da elicitação de

requisitos a partir de modelos de processos de negócio em BPMN e a ausência de trabalhos para

o contexto de LPNs.

71

4 ARReq - Apoio ao Reúso de Requisitos

Neste capítulo é apresentada a abordagem de Apoio ao Reúso de Requisitos, ARReq, que

visa permitir o reúso dos requisitos funcionais, não funcionais e regras de negócio a partir de

LPNs, com o intuito de garantir requisitos alinhados com o negócio, melhor qualidade de requi-

sitos, por diminuir as chances destes serem duplicados, incompletos, ambíguos ou conflitantes,

gerando assim economia de recursos no processo de Engenharia de Requisitos.

A abordagem é composta por dois processos principais que são executados em conjunto

com processos de abordagens de gestão de LPNs. O primeiro trata da Elicitação de Requisitos a

partir de modelos de processos de negócio com variabilidades, apresentados na notação BPMN,

os quais representam LPNs. O segundo processo trata da Especificação de Requisitos e da gera-

ção dos artefatos de requisitos do negócio, resultantes da instanciação da LPN. Deve-se ressaltar

que a qualidade dos requisitos resultantes da aplicação da ARReq está diretamente relacionada

à qualidade da representação do domínio do negócio pela LPN.

É importante afirmar que são premissas da abordagem ARReq: i) deve ser genérica, po-

dendo ser utilizada por quaisquer abordagens de gestão de LPNs, independentemente do meca-

nismo e da técnica de variabilidade empregados, desde que utilizem os conceitos de ponto de

variação e variantes; ii) a atividade de elicitação de requisitos pode ser realizada com qualquer

técnica de elicitação apropriada para modelos de processos de negócio em BPMN, indepen-

dentemente de ser uma técnica automatizada ou manual; iii) deve fornecer um Arquétipo de

Requisitos que adaptará os requisitos elicitados para uma sintaxe genérica que visa favorecer a

especificação em dois formatos distintos: estórias de usuário e documento de requisitos; e iv)

deve permitir a seleção, modificação, inclusão e exclusão de requisitos na elaboração da relação

de requisitos da instância da linha.

Este capítulo está organizado da seguinte forma: Na Seção 4.1 é feita uma breve descri-

ção da abordagem, com seus principais processos e elementos. Na Seção 4.2 são apresentadas

LPNs do domínio de vendas, utilizando várias abordagens de gestão de LPNs, com seus diferen-

tes mecanismos e técnicas de variabilidade. Na Seção 4.3 é feito o detalhamento do funciona-

mento da ARReq, utilizando como exemplo as LPNs apresentadas na seção anterior e, também,

é realizada a exemplificação dos processos e mecanismos definidos para permitir o reúso de re-

72 Capítulo 4. ARReq - Apoio ao Reúso de Requisitos

quisitos a partir de LPNs. Por fim, na Seção 4.4 são apresentadas as considerações finais sobre

a ARReq, com um resumo de suas contribuições para a Engenharia de Requisitos.

4.1 Descrição da ARReq

Para a definição da ARReq foi realizado um estudo sobre os conceitos e técnicas ne-

cessários para elicitação e para especificação de requisitos, dispensando uma atenção maior às

técnicas que elicitam requisitos a partir de modelos de processos de negócio em BPMN. Con-

forme apresentado no Capítulo 3, foram encontradas diversas formas de realizar a elicitação

dos requisitos e avaliou-se que as melhores são as apoiadas por heurísticas, pois fornecem re-

quisitos mais alinhados com o negócio, com menos problemas (não atomicidade, ambiguidade,

incompletude, duplicidade e conflito de requisitos), de forma rápida e por consistirem em uma

estratégia de elicitação com menor curva de aprendizado.

Também foi preciso analisar as formas existentes de representar variabilidade em LPN,

de modo que a abordagem proposta pudesse ser utilizada com diversos mecanismos de varia-

bilidade mantendo sua eficiência e o alinhamento dos requisitos com o negócio. Desta análise

se constatou que é necessário que o mecanismo de variabilidade utilize os conceitos de ponto

de variação e variantes, importantes para auxiliar na resolução de problemas com os requisi-

tos, e que a qualidade dos requisitos obtidos está diretamente relacionada com a qualidade da

representação do domínio da LPN.

Os problemas mais comuns envolvendo requisitos – não atomicidade, ambiguidade, in-

completude, duplicidade e o conflito de requisitos –, que podem surgir durante a elicitação de

requisitos ou na configuração das variabilidades durante a instanciação da LPN, são abordados

pela ARReq, oferecendo a oportunidade de diminuir a ocorrência destes problemas. Assim, a

não atomicidade, a ambiguidade e a incompletude são amenizadas com o uso de uma sintaxe

genérica para registrar os requisitos elicitados; os problemas de duplicidade são abordados com

uma estratégia de eliminação dos requisitos duplicados; e os conflitos de requisitos tem possibi-

lidade de solução na instanciação da linha, quando o analista de requisitos do negócio visualizará

o conjunto de requisitos e poderá selecionar, modificar, adicionar ou excluir requisitos de acordo

com as necessidades específicas do negócio e com o objetivo de eliminar os conflitos, caso os

identifique.

4.1. Descrição da ARReq 73

Na Figura 19 está representada a abordagem proposta e sua integração com a aborda-

gem de gestão de LPNs. Observa-se que a ARReq deve ser inserida como subprocessos de uma

abordagem de gestão de LPNs qualquer, não sendo, portanto, um arcabouço externo à gestão

de LPN. Na imagem, a abordagem de gestão de LPNs mantêm seus processos de Criação, Evo-

lução e Manutenção, incorporando o subprocesso proposto por esta abordagem, Elicitação de

Requisitos, descrito na Subseção 4.1.1 e representado na Figura 21, que deve ser executado pelo

analista de requisitos do domínio do negócio. Este subprocesso receberá o MPNV (Modelo de

Processos de Negócio com Variabilidades), que consiste no artefato que representa os modelos

de processos de negócio com as variabilidades adotadas pela linha. Este subprocesso produzirá

os artefatos não entregáveisMatriz de Rastreabilidade da LPN e Arquétipo de Requisitos.

Figura 19 – Estrutura da LPN com a abordagem.

O outro subprocesso proposto pela abordagem deve ser executado pelo analista de requi-

sitos do negócio e está apresentado na Figura 19 com o nome Especificação de Requisitos. Esse

subprocesso também será incorporado à gestão de LPNs, mas no processo que trata da instan-

ciação da linha, de modo que esta continuará produzindo seus artefatos, sejam eles modelos de

processos de negócio ou softwares, e acrescentando a opção de gerar dois artefatos: o Modelo

de Requisitos, que poderá ser formatado por opção do analista de requisitos do negócio como

documento de requisitos ou estórias de usuário; e a Matriz de Rastreabilidade da instância da


linha. Este subprocesso e seus artefatos estão descritos na Subseção 4.1.2 e representados na

Figura 22.

Paramelhor compreensão dos conceitos utilizados pela ARReq é preciso deixar claro que

os subprocessos são os processos que a abordagem possui, Elicitação de Requisitos e Especifi-

cação de Requisitos. São considerados subprocessos por estarem inseridos dentro dos processos

da gestão de LPNs. As Atividades são os conjuntos de tarefas que estão dentro dos subproces-

sos e seu texto está em negrito. São exemplos de atividades Gerar Arquétipo de Requisitos

(Figura 21) e Gerar Especificação de Requisitos (Figura 22). As Tarefas são responsáveis por

executar ações atômicas como, por exemplo, Elicitar Requisitos (Figura 29), Criar Requisitos

da instância (Figura 31), etc. Um modelo esquemático da representação destes conceitos pode

ser visualizado na Figura 20.

Figura 20 –Modelo esquemático da representação dos conceitos empregados naARReq.

A ARReq produz um total de sete artefatos, cujas funções, conteúdos e importância

nos subprocessos serão descritos no decorrer do capítulo. Destes sete artefatos, cinco deles não

são entregáveis, são eles:Matriz de Rastreabilidade da LPN, Relação de Requisitos Elicitados,

Arquétipo de Requisitos, Requisitos da instância eMatriz da instância. São entregáveis apenas

os artefatosModelo de Requisitos eMatriz de Rastreabilidade.

4.1.1 Elicitação de Requisitos

A atividade Realizar Elicitação de Requisitos do subprocesso de Elicitação de requisitos,

apresentado na Figura 21, recebe o MPNV e percorre seus elementos verificando as dependên-

cias e relações entre eles. Depois, para cada elemento do MPNV será aplicada qualquer técnica

4.1. Descrição da ARReq 75

de heurísticas de elicitação de requisitos em modelos de processos de negócio em BMPN, es-

colhida pelo analista de requisitos do domínio do negócio, e são gerados dois artefatos: uma

Relação de Requisitos Elicitados e aMatriz de Rastreabilidade da LPN. O primeiro, contém os

requisitos elicitados de cada elemento da LPN sem qualquer tratamento, o que pode gerar requi-

sitos duplicados, conflitantes, incompletos ou ambíguos, problemas estes que serão resolvidos

por atividades da ARReq. O segundo contém uma matriz que vincula os requisitos elicitados

aos elementos da LPN que lhes deram origem.

Figura 21 – Subprocesso de Elicitação de Requisitos em LPN.

A segunda atividade do subprocesso Elicitação de Requisitos é Gerar Arquétipo de Re-

quisitos. Esta recebe a Matriz de Rastreabilidade da LPN e a Relação de Requisitos Elicitados

e executa uma série de tarefas que estão detalhadas e exemplificadas na Subseção 4.3.1, tendo

como objetivos i) adaptar a especificação dos requisitos elicitados para uma sintaxe genérica

que eliminará as ambiguidades, não atomicidade e incompletudes dos requisitos; ii) produzir o

Arquétipo de Requisitos, artefato central do subprocesso, responsável pela eliminação dos re-

quisitos duplicados; e iii) atualizar a Matriz de Rastreabilidade da LPN em caso de mudanças

ocasionadas pela execução das tarefas internas da atividade.


Considera-se que o subprocesso Especificação de Requisitos, apresentado na Figura 22,

oferece ao analista de requisitos do negócio a liberdade de escolher gerar os artefatosModelo de

Requisitos eMatriz de Rastreabilidade ou apenas um deles. O analista de requisitos do negócio

também poderá gerar mais de um formato deModelo de Requisitos.


Figura 22 – Subprocesso de Especificação de Requisitos.

A primeira atividade deste subprocesso, Preparar Especificação de Requisitos, receberá

oMPNV configurado, que é o artefato que contém os elementos da LPN que foram selecionados

pelo analista de requisitos do negócio para fazer parte da instância da LPN. Também receberá

o Arquétipo de Requisitos e a Matriz de Rastreabilidade da LPN, que foram produzidos pelo

subprocesso Elicitação de requisitos.

Com estes artefatos, a atividade Preparar Especificação de Requisitos tratará de verifi-

car situações específicas, apresentadas e discutidas na Subseção 4.3.2, nas quais será necessário

criar novos requisitos para a instância da LPN, além daqueles já disponíveis no Arquétipo de

Requisitos. Esta atividade produzirá dois artefatos: os Requisitos da instância, que é um subcon-

junto dos requisitos constantes no Arquétipo de Requisitos, ou seja, um ou mais dos requisitos

de cada elemento selecionado para constar na instância da linha. O artefato também poderá con-

ter os requisitos que, devido às situações específicas, serão criados pelas atividades e tarefas

internas.

O segundo artefato criado por esta atividade é aMatriz de Rastreabilidade, que consiste

em uma derivação simples daMatriz de Rastreabilidade da LPN, com pareamento 1:N entre os

elementos selecionados na configuração de variabilidade (MPNV configurado) e os requisitos a

4.2. Exemplos de LPNs em diferentes notações 77

eles associados constantes na matriz de origem. Este artefato também conterá os vínculos entre

os requisitos novos que tenham sido criados e os elementos que lhes deram origem.

Esta primeira atividade também dará a oportunidade ao analista de requisitos do negócio

de selecionar nos Requisitos da instância os requisitos que deseja reusar, podendo modificar,

adicionar e/ou excluir novos requisitos no artefato sem, contudo, modificar o Arquétipo de Re-

quisitos. Com essa atividade o analista de requisitos do negócio tem a possibilidade de resolver

os conflitos de requisitos que conseguir identificar e também adequar os requisitos ao escopo

do software que será desenvolvido, modificando, incluindo ou excluindo requisitos específicos

do negócio e não reusados da LPN.

É importante ressaltar que algumas abordagens de gestão de LPNs permitem a inserção,

exclusão ou modificação de elementos no modelo de processos de negócio que é instância da

linha. Para os casos de exclusão de elemento, os requisitos que lhe são relacionados serão su-

primidos dos Requisitos da instância. Nos casos de inserção de novos elementos no modelo de

processos de negócio ou de modificações nestes elementos, recai sobre o analisa de requisitos do

negócio a obrigação de inserir ou modificar os requisitos relacionados a estes elementos nesta

primeira atividade da ARReq.

A segunda atividade é Gerar Especificação de Requisitos e consiste em tarefas e ativi-

dades que têm por objetivo gerar os artefatos entregáveis da ARReq. O primeiro é oModelo de

Requisitos, um artefato que conterá os Requisitos da instância no formato selecionado pelo ana-

lista de requisitos do negócio, dentre os dois disponíveis: documento de requisitos ou estórias

de usuário.

O segundo artefato é aMatriz de Rastreabilidade que consiste em umamatriz que vincula

os requisitos do Modelo de Requisitos aos elementos da instância da linha e visa favorecer a

manutenibilidade do software, permitindo a rastreabilidade em caso de mudanças no modelo de

processos de negócio.

4.2 Exemplos de LPNs em diferentes notações

Para melhor apresentar a aplicabilidade da ARReq em LPNs apresenta-se nesta seção

quatro LPNs, todas do domínio de vendas e contendo os mesmos processos, subprocessos e

tarefas. Estas LPNs estão representadas utilizando diferentes abordagens de gestão de LPNs, que


empregam distintos mecanismos e técnicas de modelagem de variabilidade1 e serão utilizadas

na Seção 4.3 para detalhar e exemplificar o uso da abordagem proposta e favorecer a constatação

da generalidade da ARReq.

A Figura 23 apresenta um modelo de features para o domínio de vendas que representa

quatro pontos de variação com cinco variantes. Três destes pontos de variação são opcionais e

um obrigatório e é do tipo alternative, ou seja, na configuração de variabilidade, durante a ins-

tanciação da linha, apenas uma de suas variantes deve ser selecionada. Com base neste modelo

foram elaboradas as LPNs LPN1, Figura 24, e LPN2, Figura 25.

Figura 23 –Modelo de features do domínio de Vendas.

Na Figura 24 está representada a LPN1 do domínio de vendas, que utiliza o modelo de

features apresentado na Figura 23 e emprega como técnica de modelagem a extensão BPMN*

(TERENCIANI, 2015). Atente-se para as tags sob os subprocessos e tarefas, que representam

pontos de variação (<<VarPoint>>) e variantes (<<Variant>>), mostrando aqueles que são

opcionais (<<Optional>>) e também garantem a rastreabilidade com omodelo de features. Os

elementos que não possuem tags são as comunalidades deste domínio e estarão presentes em

todas as instâncias da linha.

O modelo apresentado na Figura 25, para mostrar o domínio de vendas na LPN2, utiliza

na técnica de modelagem apenas os elementos comuns do BPMN, sem extensões ou tags. Para

identificar os pontos de variação e variantes é preciso indicar a rastreabilidade entre os elementos

do modelo de features e os elementos que representam variabilidades no MPNV da LPN, que

na imagem são os identificadores que constam no final do nome de cada feature – F1 , F2 etc.

Esta técnica de modelagem foi proposta por Gröner et al. (2013) e, em seus trabalhos, recebe o

nome de Família de Processos de Negócio.

1Os mecanismos e técnicas de modelagem de variabilidade foram discutidos nas Subseções 2.3.1 e 2.3.2, doCapítulo 2.


Figura 24 – LPN1 -Modelo de processo de negócio com variabilidades emBPMN*,adaptado de Terenciani (2015).

Na Figura 26 o mecanismo de variabilidade utilizado para representar o domínio de ven-

das na LPN3 é o modelo ortogonal (POHL; BÖCKLE; LINDEN, 2005), correspondente ao

modelo de features da Figura 23.

Na Figura 27 a técnica de modelagem empregada é o vrBPMN (SCHNIEDERS; PUHL-

MANN, 2006) e representa o domínio de vendas na LPN3. Nesta técnica de modelagem, os

pontos de variação são tarefas cujos textos reproduzem as informações constante no modelo

de variabilidade e são complementados com tags para informar o tipo de ponto de variação e

permitir a rastreabilidade com o modelo ortogonal de origem. O texto das variantes é identifi-

cado pela presença da tag <<Variant>>, sua classificação e informações para rastreabilidade.

O texto dos pontos de variação opcionais é indicado pela presença da tag <<Null>>. Os pon-

tos de variação também possuem indicação de rastreabilidade com o modelo de variabilidades.

Este modelo em vrBPMN, com algumas pequenas alterações nas tags, pode ser utilizado com o

modelo de features.


Figura 25 – LPN2 - Modelo de processo de negócio com variabilidades baseado emGröner et al. (2013).

Figura 26 –Modelo ortogonal do domínio de Vendas, extraído de Landre (2012).

Omodelo apresentado na Figura 28 paramostrar o domínio de vendas na LPN4 é baseado

na técnica de modelagem proposta por Yousfi et al. (2016), que busca representar as variabili-

dades em um processo de negócio. Esta técnica foi adaptada neste trabalho para representar a

variabilidade em uma LPN. Ela não precisa de um artefato separado para o mecanismo de vari-

abilidade, este mecanismo é representado no próprio modelo, sem extensões ou tags, sendo que


Figura 27 – LPN3 - Modelo de processo de negócio com variabilidades emvrBPMN (SCHNIEDERS; PUHLMANN, 2006).

os pontos de variação estão identificados por agrupamentos e a variabilidade é modelada com o

uso de gateways.

A abordagemARReq exige, para seu correto funcionamento, que a gestão de LPN utilize

os conceitos de ponto de variação e variantes. Mas a representação dos pontos de variação e das

variantes é diferente nas LPNs, pois depende da abordagem de gestão da LPN e do mecanismo

de representação da variabilidade. Assim, para evitar ambiguidade, o Quadro 10 apresenta as

correspondências entre os pontos de variação (PV) das LPNs aqui apresentadas e aproveita-se

para classificar os tipos destes pontos de variação.


Figura 28 – LPN4 - Modelo de processo de negócio com variabilidade baseado emYousfi et al. (2016).

São três as possibilidades de classificação dos pontos de variação: alternative, que exige

que apenas uma variante seja escolhida na instanciação da linha; or, em que ao menos uma

variante deve ser escolhida; optional, em que é possível escolher qualquer número de variantes,

inclusive nenhuma. Estas informações de classificação do ponto de variação podem ser obtidas

observando-se o mecanismo de variabilidade utilizado na gestão da LPN.

Independentemente do mecanismo de variabilidade ou da técnica de modelagem, todas

as LPNs apresentadas possuirão o mesmo conjunto de requisitos, elicitados na técnica ou heu-

rística que o analista de requisitos do domínio do negócio considerar mais adequada durante

a aplicação da ARReq, conforme será apresentado na próxima seção em que está detalhado o

funcionamento da abordagem.

4.3. Detalhamento e Aplicabilidade da ARReq 83

Quadro 10 – Correspondência entre os pontos de variação nas LPNs.

PV Tipo LPN1 LPN2 LPN3 LPN4

PV1 Optional

Tags que acompa-nham o subpro-cesso Verificardisponibilidade deprodutos – SP1

Gateway que per-mite escolher o sub-processo SP1 oucontinuar o fluxo.

Tarefa Verificardisponibilidade epelas tags que aacompanham

Agrupamento VP1:Verificar disponibi-lidade de produtos.

PV2 Optional

Tags que acompa-nham o subpro-cesso Consultarcadastro do cliente– SP2

Gateway que per-mite escolher o sub-processo SP2 oucontinuar o fluxo.

Tarefa Consultarcadastro do clientee pelas tags que aacompanham

Agrupamento VP2:Consultar cadastrodo cliente

PV3 OptionalTarefa Emitir ga-rantia e pelas tagsque a acompanham

Gateway que per-mite escolher a ta-refa Emitir garan-tia ou continuar ofluxo.

Tarefa Emitir ga-rantia e pelas tagsque a acompanham

Agrupamento VP3:Emitir garantia

PV4 Alternative

Tarefa Entregarprodutos e pe-las tags que aacompanham

Gateway que per-mite escolher ouo subprocesso SP3ou a tarefa Entregaimediata

Tarefa Entregarprodutos e pe-las tags que aacompanham

Agrupamento VP4:Entregar produtos

4.3 Detalhamento e Aplicabilidade da ARReq

Para mostrar a aplicação da ARReq se procederá da seguinte forma: serão utilizadas

as LPNs apresentadas na seção anterior para explicar sua aplicabilidade e suas exigências de

funcionamento. As LPNs terão seus requisitos elicitados utilizando a técnica REMO (VIEIRA,

2012) e produzindo os documentos internos durante a execução do subprocesso Elicitação de

Requisitos, conforme apresentado na Seção 4.3.1. Depois se explicará, na Seção 4.3.2, com base

nos mesmos exemplos, o funcionamento do subprocesso de Especificação de Requisitos.

Como as LPNs são iguais quanto aos elementos, diferindo apenas na modelagem e no

mecanismo de variabilidade, não será necessário escolher uma para dar início a aplicação da

ARReq.

4.3.1 Elicitação de Requisitos

É importante destacar que a abordagem não necessita de uma técnica específica e exclu-

siva para elicitação de requisitos, podendo a ARReq se utilizar de qualquer técnica de elicitação

que se aplique a modelos de processos de negócio em BPMN. Para fins didáticos e para ilustrar

a aplicação da ARReq na elicitação de requisitos utilizou-se a técnica REMO (VIEIRA, 2012),

que se caracteriza por ter elicitação manual e por elicitar requisitos a partir de cada elemento


do modelo de processos de negócio. Também poderiam ser utilizadas, por exemplo, as heurís-

ticas propostas por Nogueira (2017), mas estas exigem uma ferramenta específica, uma saída

específica e alto grau de informações no modelo, apesar de trabalhar de forma automática.

A ferramenta ou a técnica de elicitação, desde que seja apropriada para modelos de pro-

cessos de negócio em BPMN, não influencia na aplicação da ARReq. Isso ocorre porque os

requisitos elicitados serão adaptados para uma sintaxe genérica na tarefa Adaptar Requisitos

para Sintaxe Genérica, da atividade Gerar Arquétipo de Requisitos, tornando os requisitos in-

dependentes do formato da especificação dos requisitos elicitados.

O subprocesso Elicitação de Requisitos da abordagem ARReq é apresentado de forma

expandida na Figura 29 e recebe o modelo de processos de negócio com as variabilidades repre-

sentadas, independentemente do mecanismo de variabilidade utilizado e da técnica de modela-

gem empregada.

Figura 29 – Subprocesso de Elicitação de Requisitos, expandido.

É importante ressaltar que os requisitos elicitados na tarefa Elicitar Requisitos, da ati-

vidade Realizar Elicitação de Requisitos, e que estarão na Relação de Requisitos Elicitados,

devem ser atômicos para os elementos que compõem a LPN. Assim, é necessário que os sub-

processos, que são elementos de uma LPN, possuam seus requisitos como o conjunto composto

pelos requisitos dos elementos que compõem o subprocesso. O mesmo deve ocorrer quando a

LPN é composta por vários modelos de processos de negócio, primeiro devem ser elicitados os

requisitos de cada modelo, para então serem unificados na Relação dos Requisitos Elicitados.


Para garantir esta atomicidade dos requisitos serão elicitados, primeiramente, os requi-

sitos para os elementos que são parte dos subprocessos que compõem as LPNs de exemplo. O

resultado da elicitação dos requisitos dos elementos dos subprocessos está apresentado nos Qua-

dros 11, 12 e 13. No Quadro 14 estão apresentados os requisitos elicitados que são próprios dos

subprocessos, das comunalidades, dos pontos de variação e variantes que não são subprocessos

como, por exemplo, o ponto de variação Emitir Garantia.

Para compreensão das informações nos Quadros 11, 12, 13 e 14, a primeira coluna apre-

senta um identificador para o elemento da LPN (ID). Para garantir a identificação do elemento

nas LPNs, este está descrito na coluna elemento, com informações sobre o tipo de elemento e o

texto que o acompanha. A coluna TR contém o tipo do requisito elicitado e a coluna Descrição

possui o requisito especificado de acordo com a técnica REMO (VIEIRA, 2012). Por fim, o re-

quisito recebe um identificador (IDr) que permitirá rastreá-lo nos artefatos gerados pela ARReq

e nas tabelas e quadros utilizados na exemplificação.

Quadro 11 – Requisitos para o subprocesso Verificar disponibilidade de produtos(SP1), expandido.

ID Elemento TR Descrição IDr

T01 Tarefa: Consultar dispo-nibilidade dos produtos

RF

O sistema consulta no estoque a disponibilidadedos produtos solicitados. Para a consulta devemser informados ao menos uma das seguintes infor-mações do produto: nome ou código;

RF01

G01 Gateway: disponibili-dade de produtos

RN A partir do resultado da pesquisa registrar o tipode venda: total, parcial ou encerrar o atendimento;

RN01

T02Tarefa: Informar que osprodutos não estão dispo-níveis

RF

O sistema deve informar ao cliente que todos osprodutos solicitados estão indisponíveis e encerraro processo de venda para evitar venda de produtosinexistentes no estoque;

RF02

T03 Tarefa: Informar os pro-dutos indisponíveis

RFO sistema deve informar ao cliente os produtos queestão indisponíveis para obter autorização paravenda parcial;

RF03

T03 Tarefa: Informar os pro-dutos indisponíveis

RFO sistema deve oferecer a possibilidade de con-tinuar a venda após a aprovação do cliente paravenda parcial;

RF04

A Relação de Requisitos Elicitados, criada na tarefa Elicitar Requisitos, é um artefato

importante para a atividade Gerar Arquétipo de Requisitos e é formada pela junção dos requi-

sitos apresentados nos Quadros 11, 12, 13 e 14. Atente para o fato de que estes requisitos não

sofreram qualquer tipo de tratamento, podendo ser encontrados requisitos duplicados, ambíguos,

incompleto e/ou conflitantes e, também, existem requisitos que possuem valores variáveis, como

por exemplo, o tempo de execução no RNF02 e os valores limites na RN06 (Quadro 14), que


Quadro 12 – Requisitos para o subprocesso Consultar Cadastro do cliente (SP2),expandido.


T01 Tarefa: Consultar cadas-tro do cliente

RF O sistema deve consultar se há cadastro do clientea fim de evitar o registro de cadastros duplicados;

RF05

G01 Gateway: Cliente cadas-trado?

RN Efetuar o cadastro, mesmo que simplificado, dosclientes não cadastrados;

RN02

T02 Tarefa: Realizar cadastrodo cliente

RFO sistema deve realizar o cadastro do cliente com,no mínimo, as seguintes informações: nome e tele-fone;

RF06

Quadro 13 – Requisitos para o subprocesso Entrega imediata ou a domicílio (SP3),expandido.


G01 Gateway: Entrega a do-micílio?

RF O sistema deve registrar a forma de entrega solici-tada pelo cliente: a domicílio ou imediata;

RF07


RN Entregas imediatas têm prioridade sobre entregasa domicílio;

RN03


RN Não há entrega a domicílio para produtos perecí-veis;

RN04

T01 Tarefa: Entregar no do-micílio

RFO sistema deve solicitar e registrar as informa-ções para realizar a entrega no domicílio do cliente:nome, endereço e telefone;

RF08

T02 Tarefa: Entrega imediata RFO sistema deve informar ao funcionário responsá-vel para preparar os produtos para entrega imedi-ata;

RF09

precisarão ser adaptados para atender ao principal objetivo de uma LPN, que é representar o

domínio e não uma instância.

Enquanto os requisitos são elicitados na tarefa Elicitar requisitos é possível, paralela-

mente, ir compondo aMatriz de Rastreabilidade da LPN, criada na tarefa Gerar Matriz de Ras-

treabilidade, em que se vincula o requisito elicitado ao elemento da LPN que lhe deu origem

formando uma matriz como está apresentada na Tabela 6.

Depois que os requisitos estão elicitados e especificados de acordo com as heurísticas

de elicitação utilizadas, eles são adaptados para um Arquétipo de Requisitos na atividade Gerar

Arquétipo de Requisitos (Figura 29). Este arquétipo contém informações básicas do requisito

para permitir sua identificação e sua especificação em dois formatos distintos na instância da

LPN: documento de requisitos e estórias de usuário.

Uma premissa já apresentada é que o arquétipo deve ser um arcabouço capaz de acei-

tar Relações de Requisitos Elicitados em várias técnicas diferentes, mas aplicáveis a modelos


Quadro 14 – Requisitos elicitados para subprocessos, comunalidades e outros ele-mentos da LPN do domínio de vendas.


SP1Subprocesso: Verifi-car disponibilidade deprodutos

RN O sistema permite pedidos parciais, desde que au-torizados pelo cliente;

RN05


RNF O usuário deve se identificar através de login e se-nha em seção única;

RNF01


RNF O sistema deve retornar o resultado da consulta emmenos de 30 segundos;

RNF02

SP2 Subprocesso: consultarcadastro do cliente

RNF O usuário deve se identificar através de login e se-nha em seção única;

RNF03

T01 Tarefa: Registrar produ-tos vendidos

RFO sistema deve registrar os produtos vendidos nofaturamento a fim de garantir o controle financeiroe do estoque;

RF10

T02 Tarefa: Informar o valortotal da venda

RF O sistema deve informar o valor total da venda aocliente;

RF11

T02 Tarefa: Informar o valortotal da venda

RN Permitir desconto de até 10% para compras acimade R$ 200,00;

RN06

T03 Tarefa: Receber o valorda venda

RF

O sistema deve registrar o recebimento do valor davenda, dar baixa dos produtos no estoque e emitiro comprovante de pagamento para manter dadosfinanceiros e de estoque atualizados;

RF12

T04 Tarefa: Emitir garantia RF

O sistema deve emitir o certificado de garantia,quando solicitado pelo cliente, para os produtosadquiridos contendo: a data da venda, tempo degarantia e condições por produto;

RF13

T05 Tarefa: Entrega imediata RFO sistema deve informar ao funcionário responsá-vel para preparar os produtos para entrega imedi-ata;

RF14

SP3 Subprocesso: entregaimediata ou a domicílio

RN O cliente pode escolher se sua entrega será imedi-ata ou a domicílio;

RN07

de processos de negócio em BPMN. Apesar de cada técnica possibilitar redação diferente para

os requisitos, isto não será problema para a ARReq, pois os requisitos serão adaptados para

uma sintaxe genérica na tarefa Adaptar Requisitos para Sintaxe Genérica, garantindo assim a

uniformidade dos requisitos e resolvendo os problemas de ambiguidade, não atomicidade e in-

completude, haja vista que a sintaxe genérica possui atributos claros e objetivos que dificultam

a existência destes problemas.

A sintaxe genérica para o arquétipo é baseada na estrutura sugerida pela ISO 29.148

(ISO, 2011), adaptada às informações disponíveis nos modelos de processos de negócio, cuja

estrutura está apresentada no Quadro 15. Nesta estrutura os termos entre colchetes são atributos


Tabela 6 –Matriz de Rastreabilidade da LPN de vendas.

Elementos da LPNIDr SP1 SP2 SP3 T01 T02 T03 T04 T05RF01 XRF02 XRF03 XRF04 XRF05 XRF06 XRF07 XRF08 XRF09 XRF10 XRF11 XRF12 XRF13 XRF14 XRNF01 XRNF02 XRNF03 XRN01 XRN02 XRN03 XRN04 XRN05 XRN06 XRN07 X

e aqueles obrigatórios estão em negrito. Note que as regras de negócio são tratadas com os

mesmos atributos dos requisitos funcionais, pois possuem uma estrutura sintática semelhante.

Quadro 15 – Estrutura sintática dos requisitos no arquétipo.

Tipo EstruturaRequisito Funcio-nal

[Ator/sujeito] [Ação/objetivo] [Restrição] [Valor/Razão]

Requisito NãoFuncional

Sistema [Ação/objetivo] [Restrição] [Valor/Razão]

Regra de Negócio [Ator/sujeito] [Ação/objetivo] [Restrição] [Valor/Razão]

O analista de requisitos do domínio do negócio, ao proceder a adaptação da Relação

de Requisitos Elicitados para a estrutura da sintaxe genérica na tarefa Adaptar Requisitos para

Sintaxe Genérica deve resolver os casos de ambiguidade ou falta dos atributos obrigatórios nos


requisitos, contribuindo assim para possibilitar que os problemas de ambiguidade e incomple-

tude nos requisitos sejam sanados.

Outra importante observação na execução da tarefa Adaptar Requisitos para Sintaxe

Genérica é que os valores variáveis, que estão presentes nos requisitos da Relação de Requisitos

Elicitados, sejam adaptados, substituindo-os pela tag <<variável>>, para serem configurados

no momento da instanciação da LPN de acordo com as necessidades do negócio.

Exemplificando, no Quadro 16 é apresentada uma parte do artefato Arquétipo de Requi-

sitos criado na tarefa Adaptar Requisitos para Sintaxe Genérica tomando como base a Relação

de Requisitos Elicitados, formada pela união dos requisitos apresentados nos Quadros 11, 12,

13 e 14, adaptados para a sintaxe genérica.

Quadro 16 – Exemplo parcial do Arquétipo de Requisitos.

ID Ator/sujeito Ação/objetivo Restrição Valor/razão

RF01 VendedorConsultar no estoque a dis-ponibilidade dos produtossolicitados

Informar ao menos ounome ou código doproduto

—

RF02 Vendedor

Informar ao cliente que osprodutos estão todos indis-poníveis e encerrar o atendi-mento

—Evitar venda de produ-tos inexistentes no es-toque

RF03 Vendedor Informar ao cliente os produ-tos indisponíveis — Obter autorização para

venda parcial

RNF01 Sistema Identificar usuário com lo-gin e senha Garantir seção única —

RNF02 SistemaRetornar o resultado da con-sulta em <<variável>> se-gundos

— —

RN01 SistemaRegistrar tipo de venda:venda parcial, total ouencerramento

— —

RN02 Sistema Permitir cadastro com infor-mações mínimas

Mínimo: nome e tele-fone —

RN06 Sistema Dar desconto de até<<variável>>%

Compras acima de R$<<variável>>

—

A tarefa Eliminar Requisitos Duplicados visa resolver o problema da duplicidade de

requisitos e, para isso, encontrará requisitos que possuem redação similar para todos os atributos

da sintaxe genérica, de acordo com o tipo do requisito. Encontrados requisitos similares eles

serão unificados, mantendo-se a referência do requisito que ocorrer primeiro e eliminando os

restantes.


Por exemplo, os requisitos funcionais RF09 (Quadro 13) e RF14 (Quadro 14) possuem

a mesma redação para elementos diferentes, um subprocesso e uma tarefa. Dessa forma, esses

requisitos serão unificados, tornando-se único. O RF14 deixará de existir e em seu lugar será

mantido apenas o RF09 para toda a LPN. Processo semelhante acontecerá com os requisitos não

funcionais RNF01 e RNF03 (Quadro 14), no qual o segundo requisito – RNF03 – deixará de

existir e o RNF01 será mantido.

Quando a tarefa Eliminar Requisitos Duplicados estiver concluída, o Arquétipo de Requi-

sitos é atualizado pela tarefa Atualizar Arquétipo de Requisitos para que comporte a atualização

da relação dos requisitos e cujo exemplo está no Quadro 17. Também é atualizada a Matriz de

Rastreabilidade da LPN, na tarefa Atualizar Matriz de Rastreabilidade da LPN, conforme mos-

trado na Tabela 7, na qual estão em destaque as modificações realizadas. Com estas atualizações,

a integridade e o relacionamento dos requisitos são mantidos.

O Arquétipo de Requisitos e a Matriz de Rastreabilidade da LPN servirão de entrada

para o subprocesso Especificação de Requisitos, descrito e exemplificado na próxima seção.


O subprocesso Especificação de Requisitos se inicia quando, na instanciação da linha,

o artefato que representa a LPN possuir suas variabilidades selecionadas, obtendo-se o artefato

MPNV configurado. Esta seleção das variabilidades é realizada pelo responsável por esta tarefa

de acordo com a abordagem de gestão da LPN, gerando uma instância da linha.

Para exemplificar o funcionamento do subprocesso Especificação de Requisitos será uti-

lizada a instância originária de quaisquer das LPNs apresentadas na Seção 4.2 e cujo modelo de

processos de negócio pode ser visualizado na Figura 30. Observe que esta instância foi obtida a

partir da seleção dos pontos de variação: PV1 e PV4, este com a variante Entrega Imediata. Para

facilitar o entendimento da especificação de requisitos e a rastreabilidade dos artefatos, foram

adicionados na, Figura 30, indicadores para cada elemento da instância da LPN de vendas.

Como mencionado anteriormene, o subprocesso Especificação de Requisitos, apresen-

tado na Figura 22, possui duas atividades principais, Preparar Especificação de Requisitos e

Gerar Especificação de Requisitos, que possibilitam ao analista de requisitos do negócio reusar

requisitos a partir dos artefatos da LPN obtendo dois importantes artefatos da Engenharia de

Software: oModelo de Requisitos e aMatriz de Rastreabilidade.


Quadro 17 – Arquétipo de Requisitos.

IDr Ator/Sujeito Ação/Objetivo Restrição Valor/Razão

RF01 VendedorConsultar no estoque a dispo-nibilidade dos produtos solicita-dos

Informar ao menos ounome ou código do pro-duto

—

RF02 VendedorInformar ao cliente que os pro-dutos estão todos indisponíveise encerrar o atendimento

— Evitar venda de produtosinexistentes no estoque

RF03 Vendedor Informar ao cliente os produtosindisponíveis — Obter autorização para

venda parcial

RF04 Vendedor Oferecer a possibilidade devenda parcial

Necessária autorizaçãodo cliente —

RF05 Vendedor Consultar se há cadastro do cli-ente — Evitar cadastros duplica-

dos

RF06 Vendedor Registrar cadastro do cliente Informações mínimas:nome e telefone —

RF07 Vendedor Registrar forma de entrega soli-citada: Imediata ou domicílio — —

RF08 VendedorRegistrar informações para en-trega em domicílio: nome, ende-reço e telefone

— —

RF09 VendedorInformar funcionário para pre-parar os produtos para entregaimediata ao cliente

— —

RF10 Vendedor Registrar os produtos vendidosno faturamento — Garantir o controle finan-

ceiro e de estoque

RF11 Vendedor Informar o valor total da vendaao cliente — —

RF12 Vendedor

Registrar o recebimento do va-lor da venda, dar baixa dos pro-dutos no estoque e emitir com-provante de pagamento

Comprovante de paga-mento é obrigatório

Manter dados financeirose de estoque atualizados

RF13 Vendedor

Emitir certificado de garantiapara os produtos contendo: datada venda, tempo de garantia econdições por produto

Deve ser solicitado pelocliente —

RNF01 Sistema Identificar usuário com login esenha Garantir seção única —

RNF02 Sistema Retornar o resultado da consultaem <<variável>> segundos — —

RN01 Sistema Registrar tipo de venda: vendaparcial, total ou encerramento — —

RN02 Sistema Permitir cadastro com informa-ções mínimas Mínimo: nome e telefone —

RN03 SistemaGarantir que entregas imediatastêm prioridade sobre entregas adomicílio

— —

RN04 SistemaInformar o cliente que não háentrega a domicílio para produ-tos perecíveis

— —

RN05 Sistema Permitir pedidos parciais Solicitar autorização docliente —

RN06 Sistema Dar desconto de até<<variável>>%

Compras acima de R$<<variável>>

—

RN07 Sistema Oferecer opção de entrega ime-diata ou a domicílio — —

As atividades e tarefas deste subprocesso estão detalhadas, para exemplificação e en-

tendimento do funcionamento, nas Figuras 31, 32, 33 e 35. Esta separação foi necessária, pois


Tabela 7 –Matriz de Rastreabilidade da LPN de vendas – Atualizada.

Elementos da LPNIDr SP1 SP2 SP3 T01 T02 T03 T04 T05RF01 XRF02 XRF03 XRF04 XRF05 XRF06 XRF07 XRF08 XRF09 X XRF10 XRF11 XRF12 XRF13 XRNF01 X XRNF02 XRN01 XRN02 XRN03 XRN04 XRN05 XRN06 XRN07 X

uma única figura com este subprocesso expandido ficaria ilegível. Também foi necessário repli-

car nas figuras alguns objetos de dados, que representam artefatos da ARReq, para favorecer a

compreensão e facilitar a organização das atividades e tarefas.

A Figura 31 apresenta a atividade Preparar Especificação de Requisitos de forma expan-

dida. O objetivo desta atividade é preparar os requisitos, criando novos em situações específicas,

e oferecer a oportunidade de selecionar aqueles que realmente são úteis às necessidades do ne-

gócio, permitindo inclusive, que sejam modificados, incluídos e/ou excluídos, de acordo com a

decisão do analista de requisitos do negócio.

A primeira tarefa é Criar Requisitos da Instância. Nesta tarefa o MPNV configurado e

o Arquétipo de Requisitos são utilizados para criar os Requisitos da instância, cujo exemplo

é apresentado no Quadro 18. Este artefato é um subconjunto dos requisitos do Arquétipo de

Requisitos, pois contém apenas os requisitos associados aos elementos selecionados no MPNV


Figura 30 – Instância da LPN de vendas.

configurado, e será o principal artefato para diversas atividades e tarefas do subprocesso. A

coluna IDr contém a identificação dos requisitos na origem (Arquétipo de Requisitos), apenas

para permitir a rastreabilidade com este artefato, pois na criação dos Requisitos da instância

os requisitos são renumerados, coluna ID, de acordo com o fluxo dos elementos existentes na

instância da linha. As demais colunas mantêm a denominação do Arquétipo de Requisitos.

A próxima tarefa é Criar Matriz da Instância. Esta tarefa recebe o MPNV configurado

e aMatriz de Rastreabilidade da LPN para criar o artefatoMatriz da instância, cujo exemplo é

apresentado na Tabela 8, que contém um subconjunto da Matriz de Rastreabilidade da LPN e

será indispensável para criar aMatriz de Rastreabilidade, artefato que conterá os vínculos entre

os requisitos e os elementos presentes na instância da linha. NaMatriz da instância os requisitos

possuem a identificação atribuída pelos Requisitos da instância, coluna ID, enquanto as demais

colunas representam os elementos da instância da LPN de acordo com seu fluxo.

A atividade Verificar Pontos de Variação, expandida na Figura 32, analisará cada ponto

de variação constante do MPNV configurado quanto ao tipo e, dependendo dessa classificação,

poderá criar requisitos novos que serão vinculados, na Matriz da instância, aos elementos que

estão contidos no ponto de variação em análise. Esta vinculação acontece na tarefa Atualizar

Artefatos, que trata também de incluir os requisitos criados nos Requisitos da instância.


Quadro 18 – Exemplo do artefato Requisitos da instância para a instância apresen-tada na Figura 30.

IDr ID Ator/sujeito Ação/objetivo Restrição Valor/razão

RF01 RF01 VendedorConsultar no estoque a dis-ponibilidade dos produtossolicitados

Informar aomenos ou nomeou código doproduto

—

RF02 RF02 Vendedor

Informar ao cliente que osprodutos estão todos indis-poníveis e encerrar o atendi-mento

—

Evitar vendade produtosinexistentes noestoque

RF03 RF03 Vendedor Informar ao cliente os produ-tos indisponíveis —

Obter autorizaçãopara venda par-cial

RF04 RF04 Vendedor Oferecer a possibilidade devenda parcial

Necessária autori-zação do cliente —

RF09 RF05 VendedorInformar funcionário parapreparar os produtos para en-trega imediata ao cliente

— —

RF10 RF06 Vendedor Registrar os produtos vendi-dos no faturamento —

Garantir o con-trole financeiro ede estoque

RF11 RF07 Vendedor Informar o valor total davenda ao cliente — —

RF12 RF08 Vendedor

Registrar o recebimento dovalor da venda, dar baixa dosprodutos no estoque e emitircomprovante de pagamento

Comprovante depagamento é obri-gatório

Manter dados fi-nanceiros e de es-toque atualizados

RNF01 RNF01 Sistema Identificar usuário com lo-gin e senha

Garantir seçãoúnica —

RNF02 RNF02 SistemaRetornar o resultado da con-sulta em <<variável>> se-gundos

— —

RN01 RN01 SistemaRegistrar tipo de venda:venda parcial, total ouencerramento

— —

RN05 RN02 Sistema Permitir pedidos parciais Solicitar autoriza-ção do cliente —

RN06 RN03 Sistema Dar desconto de até<<variável>>%

Comprasacima de R$<<variável>>

—

A atividade Verificar Pontos de Variação pode produzir requisitos novos para pontos

de variação do tipo or ou optional se estiverem selecionadas mais de uma variante no MPNV

configurado. Estes requisitos se justificam pois não seriam possíveis apenas pela análise dos ele-

mentos do modelo de processos de negócio com variabilidades. São acrescentados à relação dos

Requisitos da instância os seguintes requisitos funcionais: i) Cadastrar as variantes no sistema,

pois são correspondentes a requisitos que estarão disponíveis no sistema; ii) Exibir as variantes


Figura 31 – Atividade Preparar Especificação de Requisitos, expandida.

Tabela 8 – Exemplo do artefatoMatriz da instância para a instância apresentada naFigura 30.

Elementos da InstânciaID SP1 T01 T02 T03 T04

RF01 XRF02 XRF03 XRF04 XRF05 XRF06 XRF07 XRF08 XRNF01 XRNF02 XRN01 XRN02 XRN03 X


Figura 32 – Atividade Verificar Pontos de Variação, expandida.

cadastradas e disponíveis para uso; iii) Selecionar as variantes (zero ou mais) e seus atributos.

Estes requisitos devem seguir a estrutura de sintaxe genérica apresentada no Quadro 19, que é

baseada na do Quadro 15.

Quadro 19 – Estrutura sintática para requisitos novos do ponto de variação.

Ator/sujeito Ação/objetivo Restrição Valor/razão

[Ator/sujeito] Cadastrar como <<PontodeVariação>> as op-ções: <<Variantes>>

[Restrição] [Valor/razão]

[Ator/sujeito] Exibir como <<PontodeVariação>> as opções:<<Variantes>>


[Ator/sujeito]Permitir selecionar como<<PontodeVariação>> uma ou mais dentre asseguintes opções: <<Variantes>>


A importância de criar os requisitos novos, que acontece na tarefa Criar Requisitos do

Ponto de Varição, se dá pela necessidade de complementar os requisitos, informando ao analisa

de requisitos do negócio que é necessário cadastrar as opções, exibir essas opções ao usuário e

permitir que o usuário selecione uma ou mais opções dentre as cadastradas.

Nas LPNs de exemplo os três pontos de variação do tipo optional não possuem mais de

uma variante, logo não produzirão os requisitos novos que seriam exigidos com a possibilidade

de escolha de múltiplas variantes e, assim, não modificam os Requisitos da instância. Na ava-

liação de aplicação apresentada no próximo capítulo, que utiliza uma LPN que contempla esta

situação, é apresentada a obtenção de novos requisitos a partir de pontos de variação do tipo or.

Um exemplo genérico pode ser sugerido para ilustrar a criação de novos requisitos. Tome-

se uma LPN na qual um ponto de variação do tipo or – Forma de Pagamento – contenha três

variantes – Dinheiro, Crédito, Débito – e as três variantes podem estar selecionadas no MPNV

configurado. Neste exemplo, os requisitos novos, criados durante a atividade Verificar Pontos

de Variação, são apresentados no Quadro 20. Observe que os requisitos criados, que serão in-


cluídos nos Requisitos da instância e vinculados aos elementos naMatriz da instância, seguem

os mesmos atributos da estrutura sintática definida para os requisitos no Quadro 15, o que lhes

permitirá assumir o formato escolhido pelo analista de requisitos do negócio quando for executar

a atividade Gerar Modelo de Requisitos.

Quadro 20 – Exemplo de requisitos criados pela atividade Verificar Ponto de Vari-ação.


RF15 Sistema Cadastrar como forma de pagamento as opções:Dinheiro, Crédito e Débito — —

RF16 Sistema Exibir como forma de pagamento as opções: Di-nheiro, Crédito e Débito — —

RF17 SistemaPermitir selecionar como forma de pagamentouma ou mais dentre as opções: Dinheiro, Créditoe Débito

— —

Para os pontos de variação do tipo alternative, ou quando estão selecionadas apenas uma

variante nos pontos de variação dos tipos or e optional, não é necessário criar requisitos novos e

a relação de requisitos contida nos Requisitos da instância não sofrerá alteração na quantidade

de requisitos. Um resumo das ações da atividade Verificar Pontos de Variação nos pontos de

variação está apresentado no Quadro 21.

Quadro 21 – Resumo das ações nos pontos de variação.

tipo Descrição Ação

alternativePermite selecio-nar apenas umavariante

Não são criados novos requisitos. Utilizam-se os requisitos já eli-citados do elemento.

orPermite seleci-onar ao menosuma variante

Se selecionado mais de uma variante criam-se três novos requisi-tos: Cadastrar; Exibir e Selecionar acrescentando-os aos requisi-tos já existentes. Em caso de uma variante selecionada utiliza-seos requisitos desta variante sem criar os novos.

optionalPermite selecio-nar zero ou maisvariantes

Se selecionado mais de uma variante procede-se como nos PVdo tipo or. Caso não se selecione variantes, não há requisitos areusar.

Observe, na Figura 32, que ao fim da análise de cada ponto de variação, caso tenham

sido criados requisitos novos, é executada a tarefa Atualizar Artefatos. Esta tarefa incluirá os

novos requisitos nos Requisitos da instância e os vinculará aos elementos do ponto de variação

em análise naMatriz da instância, mantendo assim a consistência destes artefatos.

Depois de executada a atividade Verificar Pontos de Variação é executada a atividade

Configurar Variáveis, expandida na Figura 33, que permite ao analista de requisitos do negócio


atribuir valores aos requisitos que contém a tag <<variável>>. Esta atividade é executada

enquanto houver requisitos nos Requisitos da instância que necessitem de atribuição de valores.

Figura 33 – Atividade Configurar Variáveis, expandida.

Se a tag <<variável>> estiver vinculada a apenas um elemento daMatriz da instância

ela é configurada na tarefa Configurar Variável e nenhuma outra ação é necessária além de

atualizar os Requisitos da instância, substituindo a tag pelo valor atribuído. Esta atualização

ocorre na tarefa Atualizar Artefatos.

Mas caso a tag <<variável>> esteja vinculada a mais de um elemento da Matriz da

instância, ela deve ser configurada na tarefa Configurar Variável para cada Vínculo e desta

configuração duas situações podem decorrer. Na primeira, o analista configura todas as tags, em

todos os vínculos, com os mesmos valores. Neste caso, nada muda na quantidade de requisitos,

ocorrendo apenas a atualização dos Requisitos da instância.

Na segunda situação, pode acontecer do analista de requisitos do negócio necessitar atri-

buir valores distintos às tags. Isto ocorrendo, é necessário criar um novo requisito para cada

valor distinto que for atribuído, tarefa desempenhada pela atividade Criar Requisitos Novos. Es-

tes novos requisitos mantém os atributos estruturais idênticos ao original, tendo como diferença

apenas o valor da variável configurado. Na tarefa Atualizar Requisitos ocorre, além da substi-

tuição da tag <<variável>> pelo valor atribuído, a inclusão deste(s) novo(s) requisito(s) nos

Requisitos da instância e a separação dos vínculos naMatriz da instância, como exemplificado

a seguir.

Por exemplo, suponha que a instância apresentada na Figura 30 contivesse o SP2, Con-

sultar cadastro do cliente, e que este subprocesso possuísse um requisito não funcional de de-

sempenho idêntico ao RNF02 (Quadro 14), logo este requisito está vinculado a dois elementos:


SP1 e SP2. Na atividade Configurar Pontos de Variação o analista de requisitos do negócio tem

que configurar a variável do RNF02 para os dois elementos, ou seja, tem de fazer duas configura-

ções na atividade Configurar Variável para cada Vínculo. Supondo que os valores configurados

para a tag <<variável>> sejam idênticos, nada muda para a atualização dos Requisitos da ins-

tância. Mas se os valores configurados forem distintos, por exemplo 20 para o SP1 e 15 para o

SP2, é necessário separar os requisitos, criando um novo. Outro exemplo pode ser visualizado

na Figura 34, na qual as linhas em destaque são requisitos criados pela atividade Configurar

Variáveis.

Figura 34 – Exemplo para atividade Configurar de Variáveis.

Após a atividade Configurar Variáveis, será oferecida ao analista de requisitos no negó-

cio a possibilidade de modificar, incluir ou excluir requisitos nos Requisitos da instância. Isto

acontecerá na tarefa Refinar Requisitos (Figura 31), a qual exigirá que o analista de requisitos

do negócio selecione quais requisitos deseja realmente reusar. Caso todos os requisitos sejam

selecionados, nada muda nos artefatos Requisitos da instância e Matriz da instância. Mas caso

o analista de requisitos modifique a redação de algum requisito, ou insira novos requisitos que

julgar necessário, ou ainda, exclua algum requisito, ambos os artefatos deverão ser atualizados

e isso acontecerá na tarefa Atualizar Requisitos.

A tarefaRefinar Requisitos é importante, pois oferece a oportunidade ao analista de requi-

sitos de negócio visualizar a totalidade dos requisitos da instância da LPN, encontrar possíveis

conflitos de requisitos e solucioná-los. Boa parte dos conflitos de requisitos são solucionadas

na gestão de LPNs, pois estas utilizam os mecanismos de variabilidade para evitar que tarefas


conflitantes sejam selecionadas e, logicamente, se não há tarefas conflitantes, a chance de haver

requisitos conflitantes diminui consideravelmente. Os mecanismos de variabilidade também uti-

lizam as tags include ou exclude para evidenciar e controlar os conflitos nas tarefas do modelo

de processos de negócio. A tarefa Refinar Requisitos oferece uma chance a mais de reduzir os

conflitos de requisitos nos projetos de software.

Quando se afirma que o analista de requisitos do negócio poderá incluir requisitos,

refere-se a situações específicas de negócio, não contempladas na LPN, que necessitem de requi-

sitos que não estão nos Requisitos da instância. Por exemplo, em uma loja de eletroeletrônicos,

o modelo de processos de negócio da instância (Figura 30) na tarefa T04, poderia ser acrescen-

tado o requisito Verificar o funcionamento dos produtos eletroeletrônicos antes da entrega, que

passaria a fazer parte dos Requisitos da instância e seria incluído seguindo a sintaxe genérica

de requisitos, apresentada no Quadro 15, na qual estão representados os demais requisitos do ar-

tefato. O requisitos criado deverá ser vinculado, pelo analista de requisitos do negócio, a algum

dos elementos da instância da linha, de modo a garantir a consistência daMatriz da instância.

A tarefa também permitirá excluir requisitos. Como a LPN reflete um domínio e possui

requisitos para diversas especificidades, pode acontecer de alguns requisitos de um elemento se

mostrarem desnecessários para algumas instâncias e, nesta tarefa, haverá a possibilidade de não

selecioná-los, excluindo-os dos Requisitos da instância sem, contudo, excluí-los do Arquétipo

de Requisitos, pois este último artefato faz parte do domínio da LPN. Por exemplo, em uma

mercearia de pequeno porte, se mostra desnecessário o requisito RF09 (Quadro 18), pois quem

realiza a entrega imediata dos produtos é o próprio caixa do comércio, assim esse requisito pode

ser eliminado dos Requisitos da instância.

A opção de modificar requisitos, permite resolver conflitos e refinar os requisitos para

redação mais apropriada à especificidade do negócio. Por exemplo, o analista de requisitos de

negócio pode desejar modificar o requisito RNF02 (Quadro 18), no atributo Ação/objetivo, para

a redação Retornar o resultado da consulta ao estoque em menos de 30 segundos.

Para ilustrar a resolução de conflito tem-se como exemplo que o SP1 (Figura 30) possui o

requisito RNF02 que exige o retorno do resultado da consulta em 30 segundos. Agora, suponha

que houvessem requisitos de desempenho para os elementos internos deste subprocesso, por

exemplo 15 segundos para a tarefa Consultar disponibilidade de produtos e 30 segundos para

realizar uma das três ações a partir do resultado da consulta, totalizando 45 segundos para a


execução dos dois requisitos. A soma dos tempos ultrapassa o tempo total estipulado no RNF02.

Logo, o analista terá a oportunidade de modificar o valor das variáveis para resolver este conflito

de requisitos.

A tarefa Refinar Requisitos também possibilita que se resolva um problema que pode

ocorrer na instanciação da LPN, quando há inclusão ou modificação de elementos no modelo de

processos de negócio da instância. Estas ações tem implicação direta na relação dos requisitos

e precisam ser tratadas pela ARReq.

A modificação ou a inclusão de elemento exige que o analista de requisitos do negócio

faça as adequações para garantir a consistência e integridade dos artefatos. O analista de requisi-

tos do negócio pode atribuir requisitos para o novo elemento do modelo de processo de negócio

e modificar os requisitos que julgar necessário para garantir a coerência com o elemento que foi

modificado, e deve também atualizar os vínculos naMatriz da instância.

No caso de exclusão de um elemento do modelo de processos de negócio correspondente

a uma comunalidade da LPN, a tarefa Criar Requisitos da Instância, descrita no início desta

seção, suprime da relação dos Requisitos da instância os requisitos vinculados ao elemento

excluído, o mesmo ocorrendo por ocasião da criação daMatriz da instância.

A próxima e última tarefa da atividade Preparar Especificação de Requisitos é Atualizar

Artefatos. Esta tarefa atualiza os Requisitos da instância, registrando as modificações realizadas

pela tarefa anterior e cuidando para que os requisitos estejam numerados de acordo com o fluxo

do modelo de processos de negócio da instância. Também atualiza a Matriz da Instância, para

manter consistente a matriz que representa o vínculo entre os requisitos e os elementos do mo-

delo de processos de negócio que é instância da linha.

Para a instância apresentada na Figura 30 as modificações nos Requisitos da instância,

realizada pela tarefa Atualizar Requisitos, seriam a substituição das tags <<variável>> pelos

seus valores, na atividade Configurar Variáveis, e a modificação da redação do requisito RNF02

pela tarefa Refinar Requisitos. O Quadro 22 apresenta a redação apenas destas modificações nos

Requisitos da instância atualizado. A Matriz da instância não precisou ser atualizada, pois não

foram criados ou inseridos requisitos novos.

A segunda atividade do subprocesso Especificação de Requisitos é Gerar Especificação

de Requisitos, apresentada de forma expandida na Figura 35. Esta atividade trata da geração dos

artefatos entregáveis da ARReq, Modelo de Requisitos e Matriz de Rastreabilidade. A geração


Quadro 22 – Exemplo de atualização do artefato Requisitos da instância.


RNF02 SistemaRetornar o resultado da con-sulta ao estoque em menosde 30 segundos

— —

RN03 Sistema Dar desconto de até 15% Compras acimade R$ 250,00 —

dos artefatos é opcional e depende de ações diretas do analista de requisitos do negócio que pode

escolher gerar um, os dois ou nenhum dos artefatos.

Figura 35 – Atividade Gerar Especificação de Requisitos, expandida.

A atividadeGerarModelo de Requisitos trata de criar oModelo de Requisitos. O formato

de saída deste artefato é selecionado na tarefa Escolher Formato e a tarefa Formatar Modelo de

Requisitos recebe os atributos dos requisitos, que estão nos Requisitos da instância, e os formata

para o estilo selecionado utilizando estruturas sintáticas de estória de usuário e documento de

requisitos, apresentadas respectivamente nos Quadros 23 e 24. Por fim, a tarefa Publicar Mo-

delo de Requisitos cuida de gerar o Modelo de Requisitos contendo os requisitos da instância

especificado(s) no(s) formato(s) escolhido(s).

O Quadro 23 contém a estrutura sintática para o formato de estória de usuário seguindo

a estrutura sugerida por Cockburn (2001).


Quadro 23 – Estrutura sintática para o formato de estória de usuário.

Tipo Estrutura

Requisitos Funcio-nais

Como um <<Ator/sujeito>> eu quero <<Ação/objetivo>>,com a restrição de <<Restrição>>, a fim de<<Valor/Razão>>.

Requisitos Não funci-onais

O sistema deve <<Ação/objetivo>>, com a restrição de<<Restrição>>, a fim de <<Valor/Razão>>

Regras de Negócio O <<Ator/sujeito>> deve <<Ação/objetivo>>, com a res-trição de <<Restrição>>, a fim de <<Valor/Razão>>

A opção pelo documento de requisitos formata o Modelo de Requisitos com a estrutura

apresentada no Quadro 24 e que se baseia no modelo de requisitos sugerido pela ISO 29.148

(ISO, 2011) e adaptado às informações que podem ser obtidas a partir da instância de uma LPN.

Quadro 24 – Estrutura sintática para o formato de documento de requisitos.

Seção Título Descrição1 Atores Relação dos atores e sujeitos relacionados ao sistema

2 Requisitos funcio-nais Relação dos requisitos funcionais do processo

3 Requisitos nãofuncionais Relação dos requisitos não funcionais do processo

4 Regras de negó-cio Relação das regras de negócio do processo

O Quadro 24 apresenta a estrutura sintática para o Modelo de Requisitos de documento

de requisitos, com suas seções e descrição do conteúdo dessas seções. No Quadro 25 é apresen-

tada uma estrutura sintática para a redação dos requisitos para o documentos de requisitos. Esta

estrutura se baseia na norma ISO 29.148 (ISO, 2011).

Quadro 25 – Estrutura sintática para redação dos requisitos em documento de requi-sitos.

Tipo EstruturaRequisitos Funcio-nais

O/A <<Ator/sujeito>> deve <<Ação/objetivo>>, a fim de<<Valor/Razão>>. Restrição: <<Restrição>>.

Requisitos Não funci-onais

O sistema deve <<Ação/objetivo>>, a fim de<<Valor/Razão>>. Restrição: <<Restrição>>.

Regras de Negócio O/A <<Ator/sujeito>> deve <<Ação/objetivo>>, a fim de<<Valor/Razão>>. Restrição: <<Restrição>>.

Um outro formato de especificação de requisitos comumente utilizado são os casos de

uso, conforme constatado no Capítulo 3, no entanto, depois de criada a estrutura sintática dos

casos de uso, a aplicação desta estrutura mostrou-se ineficaz, necessitando de muita intervenção


do usuário e utilizando-se pouco dos requisitos constantes nos Requisitos da instância. Para

contornar essa situação seria necessário inserir informações adicionais nos elementos do modelo

de processos de negócio, instância da linha. Dentre estas informações incluem-se, mas não se

limitam, identificação do tipo do fluxo (normal ou alternativo), classificação do autor da tarefa

representada pelo elemento (sistema, pessoa, script), relações de dependência (includes) para

identificar quando um caso de uso inclui outro caso de uso.

Assim, devido a complexidade de criar uma estratégia de adaptação dos requisitos exis-

tentes nos Requisito da instância para o formato de casos de uso neste trabalho, optou-se por

não criar o Modelo de Requisitos neste formato, mas colocando essa possibilidade no escopo

dos trabalhos futuros.

Para a instância da Figura 30 um exemplo doModelo de Requisitos, no formato estória de

usuário, está apresentado no Quadro 26. A primeira coluna (IDr) contêm os identificadores dos

requisitos que permite localizá-los no Arquétipo de Requisitos. A segunda coluna (ID) contêm

os identificadores renumerados pelas tarefas Atualizar Artefatos, que tratam dos Requisitos da

instância, e a última coluna contêm os requisitos redigidos no formato de estória de usuário de

acordo com a sintaxe proposta no Quadro 23. Atente que nenhum requisito novo foi inserido

nos Requisitos da instância pela atividade Preparar Especificação de Requisitos.

AMatriz de Rastreabilidade é um artefato gerado pela tarefaGerar Matriz de Rastreabi-

lidade e vincula os requisitos constantes nos Requisitos da instância aos elementos do modelo

de processos de negócio que é instância da linha, produzindo um documento que possibilita a

visualização desta relação.

Mantendo como exemplo a Figura 30, a Matriz de Rastreabilidade resultante está apre-

sentada na Tabela 9. A primeira coluna contém o identificador do requisito (ID), cuja numeração

segue o que foi apresentado no exemplo do Modelo de Requisitos (Quadro 26). As demais co-

lunas são os elementos presentes na instância da LPN de vendas. Os X indicam o vínculo entre

os requisitos e os elementos da instância. Atente que nenhum vínculo novo foi criado para esta

instância da linha na atividade Preparar Especificação de Requisitos.


A ARReq pretende ser uma forma de enriquecimento dos benefícios oriundos das LPNs

acrescentando à gestão dessas linhas a possibilidade de elicitar e reusar requisitos funcionais, não


Quadro 26 –Modelo de Requisitos no formato estórias de usuário da Instância deVendas.

IDr ID Estória de usuário

RF01 RF01Como vendedor quero consultar no estoque a disponibilidade dos produ-tos solicitados com a restrição de informar ao menos ou nome ou códigodo produto.

RF02 RF02Como vendedor quero informar ao cliente que os produtos estão todosindisponíveis e encerrar o atendimento, a fim de evitar venda de produ-tos inexistentes no estoque.

RF03 RF03 Como vendedor quero informar ao cliente os produtos que estão indis-poníveis a fim de obter autorização para venda parcial.

RF04 RF04 Como vendedor quero oferecer a possibilidade de venda parcial, com arestrição de ser necessária a autorização do cliente.

RF09 RF05 Como vendedor quero informar o funcionário para preparar os produtospara entrega imediata ao cliente.

RF10 RF06Como vendedor quero registrar os produtos vendidos no cadastro docliente e no faturamento a fim de garantir o controle financeiro e deestoque.

RF11 RF07 Como vendedor quero informar o valor total da venda ao cliente.

RF12 RF08Como vendedor quero registrar o recebimento do valor da venda, darbaixa dos produtos no estoque e emitir o comprovante de pagamento,com a restrição de que o comprovante de pagamento é obrigatório.

RNF01 RNF01 O sistema deve exigir a identificação do usuário com login e senha, coma restrição de garantir seção única de acesso

RNF02 RNF02 O sistema deve retornar o resultado da consulta ao estoque em menosde 30 segundos

RN01 RN01 O sistema deve classificar a venda em total, parcial ou encerrá-la deacordo com o pedido do cliente.

RN05 RN02 O sistema deve permitir pedidos parciais, com a restrição de ser autori-zado pelo cliente

RN06 RN03 O sistema deve permitir dar desconto de até 15%, com a restrição de queas compras sejam acima de R$ 250,00

funcionais e regras de negócio, gerando a economia proveniente das técnicas de reúso, durante

a Engenharia de Requisitos.

É possível destacar como pontos inovadores da ARReq: i) a preocupação com a solução

de problemas comuns na elicitação de requisitos: não atomicidade, a ambiguidade, a duplicidade,

a incompletude e o conflito de requisitos, com os quais é possível ter requisitos commelhor qua-

lidade por serem completos, atômicos, alinhados com o negócio e não ambíguos; e ii) a criação

de um Arquétipo de Requisitos que possibilita o reúso e, por sua estrutura sintática, auxilia na

redução dos problemas de requisitos, além de permitir gerar os artefatos para a obtenção do

Modelo de Requisitos em dois formatos diferentes.


Tabela 9 –Matriz de Rastreabilidade da instância da LPN de vendas.

Elementos da InstânciaID SP1 T01 T02 T03 T04

RF01 XRF02 XRF03 XRF04 XRF05 XRF06 XRF07 XRF08 XRNF01 XRNF02 XRN01 XRN02 XRN03 X

A abordagem também se preocupa com a rastreabilidade e a manutenibilidade do soft-

ware ao propor aMatriz de Rastreabilidade como um documento acessível ao analista de requi-

sitos do negócio que utiliza a ARReq. Esta matriz permite vincular os requisitos aos processos

de negócio da instância da LPN, favorecendo a modificação dos requisitos do software em caso

de modificações nos processos de negócio.

Destaca-se, também, que a abordagem tem condições de reduzir custos com processos

da Engenharia de Requisitos e que, independentemente da técnica de elicitação de requisitos

empregada, o ganho com o reúso de requisitos é garantido pelo seu alinhamento com o negócio,

melhoria na velocidade de elicitação e especificação para novos modelos de processos de negó-

cio que sejam instâncias da linha e por possibilitar a adequação de requisitos às especificidades

de cada negócio do domínio.

A qualidade dos requisitos ao final da aplicação da ARReq está diretamente relacionada

com a qualidade dos requisitos representados na LPN e elicitados pela técnica de elicitação

escolhida. Os requisitos elicitados serão trabalhados pelas atividades e tarefas da ARReq, mas

não terão sua qualidade alterada, portanto, a qualidade está intimamente relacionada à forma

como os requisitos foram elicitados na aplicação da abordagem e esta se relaciona com a forma

como o processo está representado na linha.

A primeira premissa proposta para a ARReq refere-se a generalidade, podendo ser uti-

lizada por quaisquer abordagens de gestão de LPNs, independentemente do mecanismo e da


técnica de variabilidade empregados, desde que empreguem os conceitos de ponto de variação e

variante. Essa premissa está atendida tendo em vista que foram utilizadas como exemplo quatro

LPNs com abordagens de gestão diversas.

A segunda premissa diz respeito ao processo de elicitação de requisitos que pode ser

realizado com qualquer técnica de elicitação apropriada para modelos de processos de negócio

em BPMN, seja automatizada ou manual. Pode-se considerar atendida, pois os requisitos espe-

cificados em qualquer formato foram adaptados à sintaxe genérica, tornando-se independentes

do formato de especificação de requisitos empregado pela técnica de elicitação utilizada e ainda

minimizando a ambiguidade, não atomicidade e a incompletude dos requisitos, pois a sintaxe

genérica possui atributos claros e objetivos.

A terceira premissa prevê que a ARReq terá um Arquétipo de Requisitos que tratará de

eliminar os requisitos duplicados e adaptará os requisitos elicitados para uma estrutura genérica

que visa favorecer a especificação em dois formatos distintos: estórias de usuário e documento

de requisitos. Essa premissa foi comprovada pelo sucesso em elicitar, adaptar, configurar e es-

pecificar os requisitos para as LPNs de exemplo apresentadas neste capítulo.

A quarta premissa trata da possibilidade de permitir a modificação, inclusão e exclusão

de requisitos na elaboração dos artefatos entregáveis da ARReq. Pode-se concluir que esta pre-

missa foi atendida com a atividade Refinar Requisitos, a qual possibilita que ajustes sejam feitos

nos requisitos para adequá-los às especificidades do negócio e possibilitar a redução de conflito

de requisitos, solucionando aqueles que o analista de requisitos do negócio localizar.

Pelo atendimento das premissas propostas acredita-se que aARReq satisfaz os problemas

para as quais se aplica e pode auxiliar o reúso de requisitos em LPNs para as abordagens de

gestão de LPN que satisfazem os critérios exigidos por ela, quais sejam, adotam a linguagem

de modelagem BPMN e modelam a variabilidade utilizando os conceitos de ponto de variação

e variantes.

109

5 Avaliação da ARReq

Nesta capítulo é apresentada a avaliação de aplicação da ARReq. Para a condução da

avaliação, a ARReq é aplicada em uma LPN com mais opções de variabilidade de modo a

ter todos os mecanismos propostos, de elicitação e de especialização de requisitos, testados

e exemplificados. Para planejar a avaliação é utilizada a metodologia GQM (Goal, Question,

Metric) (BASILI, 1992), a fim de que os objetivos pretendidos com a abordagem possam ser

verificados por meio de métricas claras e objetivas.

O capítulo está organizado da seguinte forma: na Seção 5.1 é planejada a avaliação com

uso da metodologia GQM. Na Seção 5.2 é apresentada a LPN do domínio de Locação e jus-

tificada sua escolha para ser utilizada na avaliação. Na Seção 5.3 são aplicadas as atividades

e tarefas do subprocesso Elicitação de Requisitos. Já na Seção 5.4 são aplicadas as atividades

e tarefas do subprocesso Especificação de Requisitos. Os resultados obtidos são discutidos na

Seção 5.5. Por fim, na Seção 5.7 estão apresentadas as considerações finais sobre a aplicação da

ARReq na LPN do domínio de Locação.

5.1 Planejamento da avaliação

A metodologia GQM (BASILI, 1992) possibilita estabelecer métricas relacionadas a

questões e objetivos que dão sentido àquilo que está sendo medido e permite melhor compreen-

são das informações obtidas. Assim, para verificar se os objetivos propostos no Capítulo 1 deste

trabalho foram alcançados e para avaliar os processos da ARReq detalhados no Capítulo 4 é que

se estabelece o planejamento da avaliação de aplicação da abordagem em conformidade com o

GQM.

O objeto desta avaliação de aplicação é a ARReq e o objetivo é verificar a aplicação

dessa abordagem no âmbito de uma Linha de Processos de Negócio criada com apoio da GLPN.

A avaliação tem como foco qualitativo verificar a capacidade da ARReq de permitir o reúso de

requisitos completos, não ambíguos, atômicos e únicos, especificando-os nos formatos de casos

de uso, estória de usuário e documento de requisitos, e fornecendo uma matriz de rastreabilidade

entre os requisitos e os elementos que compõem a instância da linha. A avaliação tem como

perspectiva analistas de requisitos do domínio (responsáveis pela elicitação de requisitos) e

110 Capítulo 5. Avaliação da ARReq

analistas de requisitos do negócio (responsáveis pelo reúso e especificação de requisitos do

negócio). Como contexto, a avaliação de aplicação, realizada em março de 2018, foi conduzida

pelo autor deste trabalho, tendo a colaboração de uma docente como orientadora, a partir de

LPN adaptada de trabalho anterior de autor pertencente ao Grupo de Pesquisa em Engenharia

de Software desta Universidade.

A partir da seleção da LPN e da abordagem de gestão de LPNs que seriam empregadas

na avaliação, procedeu-se o planejamento do GQM, de modo a verificar se a ARReq atende

os objetivos propostos e se seus processos, atividades e tarefas cumprem a contento o que foi

proposto ao ser apresentada no capítulo anterior.

Os objetivos (O), questões (Q) e métricas (M) utilizados para avaliação da ARReq estão

apresentados na Figura 36.

5.2 Linha de Processos de Negócio – Domínio de Locação

Como já explicado no Capítulo 2, uma LPN é composta por um mecanismo de variabili-

dade e uma técnica de modelagem de variabilidade para representar os processos de um domínio

específico. Para execução desta avaliação, optou-se pela abordagem de gestão de LPN denomi-

nada GLPN (LANDRE, 2012), cujo funcionamento e mecanismos foram discutidos na Seção

2.3 do referido capítulo.

Na GLPN exitem dois processos, o EDN - Engenharia de Domínio de Negócio e o EPN -

Engenharia de Processo de Negócio. A integração destes processos com a ARReq pode ser visu-

alizada na Figura 37. O processo EDN trata da criação, evolução, validação e gerenciamento das

LPNs e fornece à ARReq o modelo de processos de negócio com variabilidades representadas,

que na GLPN é denominado TMPN, sobre o qual será executado o subprocesso Elicitação de

Requisitos.

Já o processo EPN da GLPN trata da instanciação das LPNs e possui atividades para

configurar o TMPN com as variabilidades desejadas para a instância, fornecendo-o à ARReq

para que esta possa realizar o subprocesso Especificação de Requisitos e produzir os artefatos

entregáveis da abordagem.

Assim, utilizando-se da GLPN, foi criada uma LPN pertencente ao domínio de locação

(LANDRE, 2012), cujo mecanismo de variabilidade é o modelo de features apresentado na

5.2. Linha de Processos de Negócio – Domínio de Locação 111

Figura 36 – Objetivos, questões e métricas para avaliação da ARReq.

Figura 38. Deste modelo se depreende que a LPN tem cinco pontos de variação, sendo três

opcionais e dois obrigatórios.

A GLPN utiliza, como técnica de modelagem de variabilidades, a linguagem BPMN*

(TERENCIANI, 2015). O artefato que representa essa modelagem é denominado TMPN e está

apresentado na Figura 39. Na imagem são visualizadas as comunalidades e variabilidades deste

domínio de locação e sobre este TMPN que se aplicará o processo de elicitação de requisitos da

ARReq nesta avaliação.


Figura 37 – Integração entre GLPN e ARReq.

Figura 38 –Modelo de features para o domínio de locação. Adaptado de Landre(2012).

Como mostrado no Capítulo 4, a ARReq é composta por dois subprocessos principais: a

Elicitação de Requisitos e a Especificação de Requisitos. Nas próximas seções é apresentada a

execução destes subprocessos e seus resultados para a LPN do domínio de locação.

5.3 Subprocesso de Elicitação de Requisitos

A Elicitação de Requisitos possui duas atividades executadas no processo EDN - Enge-

nharia de Domínio do Negócio da GLPN (LANDRE, 2012). Estas atividades tratam de elicitar

os requisitos dos TMPNs existentes na GLPN e preparar esses requisitos para serem reusados

no processo Engenharia de Processos do Negócio da GLPN, que produz as instâncias da linha,

denominadas PDOs.

5.3. Subprocesso de Elicitação de Requisitos 113

Figura 39 – Template de Modelo de Processos de Negócio do domínio de locação.Adaptado de Landre (2012).

5.3.1 Atividade Realizar Elicitação de Requisitos

Esta atividade visa preparar os requisitos, elicitando-os dos elementos do TMPN e cri-

ando a Relação dos Requisitos Elicitados e aMatriz de Rastreabilidade da LPN.


Para elicitação dos requisitos da LPN do domínio de locação foi utilizada a técnica

REMO (VIEIRA, 2012), pois se caracteriza por ter elicitação manual e por elicitar requisitos a

partir de cada elemento do modelo de processos de negócio. Segue, no Quadro 27, um exemplo

parcial da Relação dos Requisitos Elicitados, a versão completa do artefato está no Apêndice A.

Quadro 27 – Amostra da Relação dos Requisitos Elicitados para o domínio de Lo-cação.


SP1 Tarefa - T01: Verificar histó-rico de locação do cliente RF Realizar consulta no histórico do cliente RF01

SP1 Tarefa - T01: Verificar histó-rico de locação do cliente RF Autorizar ou não a locação com base no histórico do

cliente RF02

SP2 Tarefa - T01: Verificar histó-rico de locação RF Realizar consulta no histórico do cliente RF03

SP2 Tarefa - T01: Verificar histó-rico de locação RNF O resultado da consulta deve ser retornado em 5 segun-

dos RNF04

T01 Tarefa: Realizar Locação RF Registrar locação: cliente, material locado, valor da lo-cação, data da locação RF06

E01 Evento: Aguardar devolu-ção RN Ligar para o cliente após um dia de atraso na devolução

do material locado RN05

T02 Tarefa: Verificar condiçãodo material RN Informar cliente de problemas encontrados no material

locado RN06

T03 Tarefa: Realizar registro dadevolução RF

Registrar no cadastro do cliente a devolução do materiallocado: data da devolução, condição do material, despe-sas relativas ao conserto

RF12

G01 Gateway: Atraso na devolu-ção? RF Verificar atraso na devolução dos itens locados RF13

T04 Tarefa: Suspender clientepor um mês RF Suspender cliente por um mês, não permitindo novas lo-

cações RF14

T05 Tarefa: Suspender clientepor uma semana RN Registrar suspensão no cadastro do cliente RN12

T06 Tarefa: Calcular multa RF Calcular multa considerando a diária de locação por diade atraso na devolução de cada item locado RF16

T07 Tarefa: Receber em Di-nheiro RF Receber os valores devidos e fornecer troco, se necessá-

rio RF19

T08 Tarefa: Receber cheque RFReceber pagamento em cheque registrando informaçõesda folha: número do cheque, tempo de cliente, banco,agência e conta

RF20

T09 Tarefa: Receber cartão cré-dito RN Parcelamentos no cartão de crédito em até 6 vezes RN18

T10 Tarefa: Receber cartão dé-bito RF Receber pagamento com cartão de débito RF23

T11 Tarefa: Registrar paga-mento RF Permitir recebimento de pagamento em várias formas RF26

A Matriz de Rastreabilidade da LPN, da qual uma amostra pode ser visualizada na Ta-

bela 10, é também criada nesta atividade. Este artefato cria um vínculo entre os requisitos elicita-

dos e os elementos do TMPN que lhes deram origem. Para visualizar aMatriz de Rastreabilidade

da LPN em sua versão final e completa consulte o Apêndice C.

Ambos os artefatos, Relação dos Requisitos Elicitados e Matriz de Rastreabilidade da

LPN, foram criados como uma primeira versão de requisitos, redigidos de forma sucinta, em alto

5.3. Subprocesso de Elicitação de Requisitos 115

Tabela 10 – Amostra da Matriz de Rastreabilidade da LPN – Locação.

Elementos da LPNIDr SP1 SP2 E01 G01 T01 T02 T03 T04 T05 T06 T07 T08 T09 T10 T11RF01 XRF02 XRF03 XRF06 XRF12 XRF13 XRF14 XRF16 XRF19 XRF20 XRF23 XRF26 XRN05 XRN06 XRN12 XRN18 XRNF04 X

nível, por isso, é possível encontrar requisitos com problemas (não atomicidade, ambiguidade,

incompletude, duplicidade). O objetivo de apresentar estes artefatos redigidos desta forma é

ilustrar como estes requisitos serão tratados pela abordagem, ganhando alguns dos atributos de

qualidade sugeridos pela norma ISO 29.148 (ISO, 2011).

Para exemplificar alguns desses problemas de requisitos que estão na Relação de Requi-

sitos Elicitados (Apêndice A) pode-se observar que os requisitos funcionais RF01 e RF03, os

requisitos não funcionais RNF03 e RNF06, as regras de negócio RN11 e RN12, estão duplica-

dos. São ambíguos os requisitos RN05 (ligar para o cliente a fim de quê?), RN18 (parcelar o

quê?), RF26 (qual legislação?). Estão incompletos os requisitos RF16 (falta ator/sujeito), RN06

(falta valor/razão, ator/sujeito) e RN10 (falta ator/sujeito).

5.3.2 Atividade Gerar Arquétipo de Requisitos

Nesta atividade os requisitos são adaptados para a sintaxe genérica1, criando o Arquétipo

de Requisitos. Um exemplo parcial do Arquétipo de Requisitos é apresentado no Quadro 28 e a

versão final e completa do artefato está no Apêndice B.

Atente para o fato que a tarefa Adaptar Requisitos para a Sintaxe Genérica cria o Arqué-

tipo de Requisitos e possibilita a eliminação das faltas de atomicidade, ambiguidades e incom-1Os atributos desta sintaxe genérica foram apresentados no Quadro 15 do Capítulo 4.


pletudes devido a exigência de adequar os requisitos aos atributos da sintaxe genérica. Tam-

bém nesta tarefa os valores variáveis que estão nos requisitos devem ser substituídos pela tag

<<variável>>.

Quadro 28 – Amostra do Arquétipo de Requisitos para o domínio de locação.


RF01 Funcionário Realizar consulta no histórico do cli-ente — Visualizar pendências com a

empresa

RF02 Funcionário Autorizar ou não a locação combase no histórico do cliente — Diminuir perdas com atrasos

ou não pagamentos

RF08 Funcionário Gerar uma relação das devoluçõesesperadas para o dia — Checar as devoluções que fo-

rem realizadas

RF13 Funcionário Suspender cliente por um mês, nãoautorizando novas locações — Evitar perdas com atrasos

e/ou reincidências

RN04 FuncionárioLigar para o cliente após<<variável>> dia(s) de atraso nadevolução do material locado

— Evitar atrasos longos na devo-lução

RN05 FuncionárioInformar cliente sobre os problemasencontrados na devolução do mate-rial locado

— Dar ciência ao cliente sobreos problemas encontrados

RN06 Funcionário

Informar cliente que materiais comdano superior a <<variável>>%do valor do bem locado deverá sersubstituído pelo cliente

— —

RNF01 Sistema Retornar o resultado da consulta em<<variável>> segundos — —

RNF02 Sistema Exigir login e senha para acesso aohistórico do cliente — Garantir controle seção única

RNF03 Sistema Realizar backup do banco de dadosa cada <<variável>>

— garantir a segurança dos da-dos em caso de incidentes

Depois que os requisitos são adaptados para a sintaxe genérica ocorre a tarefa Eliminar

Requisitos Duplicados. Esta tarefa unifica os requisitos que possuem os mesmos atributos, ga-

rantindo que sejam únicos, mas mantendo os vínculos na Matriz de Rastreabilidade da LPN

com os elementos do TMPN. Um exemplo de eliminação de duplicados pode ser dado com os

requisitos RN09, RN15 e RN19 da Relação dos Requisitos Elicitados que serão unificados no

RN09, receberão a tag <<variável>> para o valor de R$ 100,00, mas manterão o vínculo aos

elementos originais (T02, T05 e T09) naMatriz de Rastreabilidade da LPN.

Por fim, o Arquétipo de Requisitos (Apêndice B) e a Matriz de Rastreabilidade da LPN

(Apêndice C) são atualizados, os requisitos são renumerados e os vínculos atualizados. Deste

modo, o subprocesso de Elicitação de Requisitos finaliza suas funções disponibilizando requi-

sitos únicos, não ambíguos e completos para reúso no processo de Engenharia de Processos de

Negócio na GLPN.

5.4. Subprocesso de Especificação de Requisitos 117

5.4 Subprocesso de Especificação de Requisitos

O subprocesso Especificação de Requisitos atua no processo EPN - Engenharia de Pro-

cesso de Negócio da GLPN (LANDRE, 2012) e produz os artefatos entregáveis da ARReq e

recebe como entrada o TMPN com a configuração de variabilidades realizada pelo analista de

requisitos do negócio2, o Arquétipo de Requisitos e aMatriz de Rastreabilidade da LPN.

O TMPN com a configuração de variabilidades produz uma instância da linha que é um

modelo de processos de negócio, denominado PDO na abordagem GLPN (LANDRE, 2012).

Para prosseguir com a avaliação foi criada a instância do domínio de locação apresen-

tada na Figura 40. Esta instância é obtida pela seleção das seguintes variantes do modelo de

features apresentado na Figura 38: o subprocesso Verificar histórico do cliente (feature F2) e a

tarefa Suspender cliente por uma semana (feature F8), que são, respectivamente, as variantes

dos pontos de variação F1 e F6, ambos do tipo Alternative. Também foram selecionadas as va-

riantes Verificar condição do material e Relatório de despesas (respectivamente, F4 e F5). Por

fim, a instância também é composta por três variantes (Receber dinheiro – F10, Receber cartão

crédito – F12 e Receber cartão débito – F13) do ponto de variação F9, do tipo Or.

Utilizando a instância apresentada na Figura 40 foram executadas as atividades do sub-

processo Especificação de Requisitos. Na primeira atividade, Preparar Especificação de Re-

quisitos (Subseção 5.4.1) ocorre a criação dos artefatos Requisitos da instância e Matriz da

instância que fornecerão suporte às atividades e tarefas deste subprocesso. A segunda atividade,

Gerar Especificação de Requisitos (Subseção 5.4.2) produz os artefatos entregáveis da ARReq,

o Modelo de Requisitos e a Matriz de Rastreabilidade.

5.4.1 Atividade Preparar Especificação de Requisitos

Como a denominação desta atividade sugere, ela prepara os requisitos constantes no

Arquétipo de Requisitos para que sejam especificados nos formatos desejados. Para tanto, é

composta por subatividades e tarefas que visam adequar os requisitos doArquétipo de Requisitos

às necessidades do negócio, representadas no TMPN com as variabilidades configuradas.

A primeira tarefa desta atividade consiste em Criar os Requisitos da instância. Este

artefato contém os requisitos relativos aos elementos do TMPN com variabilidades configuradas

2Este artefato equivale aoMPNV configurado utilizado na descrição da ARReq no Capítulo 4.


Figura 40 – Instância do domínio de locação.

originários do Arquétipo de Requisitos. Um exemplo parcial deste artefato está no Quadro 29.

O artefato completo pode ser visualizado no Apêndice D.

A próxima tarefa é Criar a Matriz da instância, um artefato derivado da Matriz de Ras-

treabilidade da LPN que contêm os vínculos apenas dos elementos que foram selecionados


Quadro 29 – Amostra do artefato Requisitos da instância para a instância de Loca-ção.


RF04 FuncionárioEmitir relação do material lo-cado: cliente, funcionário, mate-rial locado, valor e data da loca-ção

—Favorecer a confe-rência do materialna devolução

RF05 FuncionárioEmitir comprovante de locação:cliente, funcionário, material lo-cado, valor da locação, data dalocação e data da devolução

Uma via deve serentregue ao cliente

Favorecer a confe-rência na devoluçãoe comprovar a reti-rada do material lo-cado

RF06 Funcionário Gerar uma relação das devolu-ções esperadas para o dia —

Checar as devolu-ções que forem rea-lizadas

RF15 Funcionário Receber os valores devidos efornecer troco, se necessário

Troco somente parapagamento em di-nheiro

—

RF16 Funcionário Receber pagamento com cartãode crédito — —

RN03 FuncionárioLigar para o cliente após<<variável>> dia(s) deatraso na devolução do materiallocado

— Evitar atrasos lon-gos na devolução

RN04 FuncionárioInformar cliente sobre os pro-blemas encontrados na devolu-ção do material locado

—Dar ciência ao cli-ente sobre os pro-blemas encontrados

RN08 Funcionário

Registrar o valor das despesase não permitir locação pelo cli-ente até a dívida ser quitada ounegociada e, neste último caso,a primeira parcela paga

— —

RNF01 Sistema Retornar o resultado da consultaem <<variável>> segundos — —

RNF02 Sistema Exigir login e senha para acessoao histórico do cliente — Garantir controle

seção única

na configuração de variabilidades para a criação do PDO. Um amostra deste artefato pode ser

visualizada na Tabela 11, e o artefato completo encontra-se no Apêndice E.

Tabela 11 – Amostra do artefatoMatriz da instância para a instância de Locação.

Elementos da InstânciaIDr SP1 E01 G01 T01 T02 T03 T04 T05 T06 T07 T08 T09RF01 XRF02 XRF05 XRF12 XRF21 XRN01 XRN03 XRN14 XRNF01 XRNF04 X


A próxima atividade é Verificar Pontos de Variação. Esta atividade verifica os pontos de

variação quanto ao seu tipo para propor a criação de novos requisitos, caso estes pontos sejam

do tipo or ou optional e tenham mais de duas variantes selecionadas para a instância da linha,

como exemplificado no Capítulo 4.

Para a instância apresentada na Figura 40, o ponto de variação Receber pagamento é do

tipo or e possui três variantes selecionadas, Receber dinheiro, Receber cartão débito e Receber

cartão crédito. Logo, a relação dos Requisitos da instância receberá os três novos requisitos

propostos para esta situação (Quadro 30) e que foram criados de acordo com a estrutura sintática

apresentada no Quadro 19.

Quadro 30 – Requisitos criados pela atividade Verificar Ponto de Variação.


RF23 SistemaCadastrar como Receber pagamento as opções: Receberdinheiro, Receber cartão crédito e Receber cartão dé-bito

— —

RF24 Sistema Exibir como Receber pagamento as opções: Receber di-nheiro, Receber cartão crédito e Receber cartão débito — —

RF25 SistemaPermitir selecionar como Receber pagamento uma oumais dentre as opções: Receber dinheiro, Receber car-tão crédito e Receber cartão débito

— —

De acordo com o que foi detalhado sobre o funcionamento da atividade Verificar Pontos

de Variação no Capítulo 4, estes novos requisitos serão vinculados, naMatriz da instância, aos

elementos que compõem o ponto de variação, ou seja, os elementos T06, T07 e T08 receberão

o vínculo para estes novos requisitos. Exemplos da relação dos Requisitos da instância e da

Matriz da instância atualizadas serão apresentados após a atividade Refinar Requisitos e de

forma completa, respectivamente, nos Apêndices F e G.

Outra observação pertinente quanto aos requisitos criados pela atividadeVerificar Pontos

de Variação é que a redação deles pode não ser fluída, devido a estrutura sintática utilizada, como

ocorre nos exemplos do Quadro 30. Isso não é necessariamente um problema, pois a atividade

Refinar Requisitos permite modificar a redação dos requisitos, tornando-os mais adequados,

como será apresentado adiante.

A próxima atividade é Configurar Variáveis e cuida de atribuir valor aos requisitos que

possuem tags <<variável>>. Esta atividade pode criar requisitos novos nos casos em que

o requisito está vinculado a mais de um elemento na instância da linha e receber as atribui-

ções de valores distintos. No Quadro 31 é possível visualizar os requisitos que tiveram as tags

<<variável>> configuradas.


Quadro 31 – Requisitos criados e configurados pela atividade Configurar Variá-veis.


RN01 FuncionárioNão autorizar locação de clientes com débito,locação sem devolução, em suspensão ou commais de 5 dias de atraso em 3 locações distintasnos últimos 12 meses

—Garantir critérios de lo-cação uniformes e obje-tivos

RN03 Funcionário Ligar para o cliente após 1 dia de atraso na de-volução do material locado — Evitar atrasos longos na

devolução

RN05 FuncionárioInformar cliente que materiais com dano supe-rior a 80% do valor do bem locado deverá sersubstituído pelo cliente

— —

RN07 Funcionário Informar cliente que valores inferiores a R$50,00 não devem ser parcelados — Evitar parcelamento de

valores baixos

RN08 Funcionário Informar cliente que valores inferiores a R$100,00 não devem ser parcelados — Evitar parcelamento de

valores baixos

RN12 Funcionário Informar cliente que o valor mínimo da parcelada multa é de R$ 30,00 — —

RN14 Funcionário Parcelar pagamentos no cartão de crédito em, nomáximo, 6 vezes — —

RNF01 Sistema Retornar o resultado da consulta em 5 segundos — —

RNF03 Sistema Realizar backup do banco de dados a cada dia —garantir a segurança dosdados em caso de inci-dentes

Para exemplificar, serão atribuídos dois valores distintos ao RN07 (Apêndice D) que

está vinculado a três elementos da instância (Apêndice E). Para os vínculos T02 e T05 (Apên-

dice G) foi atribuído valor de R$ 50,00 (Apêndice F) e para o vínculo T07 (Apêndice G) o valor

de R$ 100,00 (Apêndice F). Deste modo, no Quadro 31, é possível visualizar que o RN07 se

manteve e foi criado o RN08 com redação diferente apenas para o valor da variável. NaMatriz

da instância (Apêndice G) o RN07 está agora vinculado ao T02 e T05 e o RN08 vinculado ao

T07. Lembrando que os requisitos posteriores foram renumerados pela tarefa Atualizar Artefa-

tos. Os artefatos Requisitos da Instância e aMatriz da instância completos e finalizados podem

ser visualizados, respectivamente, nos Apêndices F e G.

Depois de configurados os valores variáveis nos requisitos e criados os requisitos no-

vos para os casos em que isso foi necessário, tem início a tarefa Refinar Requisitos. Esta tarefa

permite ao analista de requisitos do negócio modificar, inserir ou excluir os requisitos nos Re-

quisitos da instância, visando adequá-los às especificidades do negócio, aprimorá-los quanto a

redação e possibilitar a resolução de conflitos de requisitos que sejam identificados, conforme

foi detalhado na Seção 4.3 do capítulo anterior.

Para exemplificar a possibilidade demodificação dos requisitos pode-se alterar a redação

dos requisitos criados para os pontos de variação (Quadro 30) que, devido a estrutura sintática

utilizada, ficaram com a redação comprometida. Observe uma possibilidade de reescrita destes


requisitos no Quadro 32. Aproveita-se para deixar mais claro a redação dos requisitos RN07 e

RN08 para evitar possíveis ambiguidades (compare a redação destes requisitos nos Quadros 31

e 32).

Quadro 32 –Modificação de requisitos pela tarefa Refinar Requisitos.


RF23 SistemaCadastrar como opções para receber pagamento:Receber em dinheiro, cartão de crédito e cartãode débito

— Oferecer opções de pa-gamento

RF24 SistemaExibir como opção para receber pagamento: Re-ceber em dinheiro, cartão de crédito e cartão dedébito


RF25 SistemaPermitir selecionar como opção para receber pa-gamento: Receber em dinheiro, cartão de créditoe cartão de débito


RN07 FuncionárioInformar cliente que valores inferiores a R$50,00 para multas ou despesas com danos nãodevem ser parcelados

— Evitar parcelamento devalores baixos

RN08 FuncionárioInformar cliente que valores inferiores a R$100,00 para o total da locação não devem serparcelados

— Evitar parcelamento devalores baixos

Para exemplificar a inserção de novos requisitos na tarefa Refinar Requisitos é preciso

considerar as especificidades do negócio. Suponha que o PDO apresentado na Figura 40 seja

de uma locadora de ferramentas para pequenos consertos, o analista de requisitos do negócio

pode acrescentar na T01 (Realizar locação) o requisito funcional Oferecer seguro contra perda

ou dano no valor de 5% da locação. Este requisito será inserido na relação dos Requisitos da

instância respeitando os atributos da sintaxe genérica e será vinculado, na Matriz da instância,

ao elemento T01. Um exemplo de redação para a inserção deste requisito pode ser visualizado

no Quadro 33.

Quadro 33 – Inserção de requisito pela tarefa Refinar Requisitos.


RF26 Funcionário Oferecer seguro contra perda ou dano Valor de 5% da locaçãoEvitar prejuízo com ma-teriais danificados ouperdidos

Já para exemplificar a exclusão de requisitos pela tarefaRefinar Requisitos basta verificar

se há requisitos que não se aplicam às necessidades do negócio. Assim, para o negócio utilizado

como exemplo, pode-se supor que não seja desejável manter a RN14 (Quadro 31), sobre permitir

parcelamento no cartão de crédito, pois a empresa deseja ter todas as locações pagas a vista.

Assim, basta excluir a RN14 dos Requisitos da instância e da Matriz da instância.

Terminada a tarefa Refinar Requisitos é necessário atualizar os artefatos Requisitos da

instância eMatriz da instância registrando as alterações realizadas e renumerando os requisitos


e vínculos para manter a integridade dos artefatos. Para visualizar os Requisitos da instância atu-

alizados e com todas as modificações, inserções e exclusões sugeridas anteriormente recomenda-

se consultar o Apêndice F e o mesmo vale para a Matriz da instância atualizada, disponível no

Apêndice G.

5.4.2 Atividade Gerar Especificação de Requisitos

Esta atividade visa produzir os artefatos entregáveis da ARReq: oModelo de Requisitos

e a Matriz de Rastreabilidade. Como explicado no Capítulo 4, o Modelo de Requisitos poderá

ser gerado em dois formatos pré-estabelecidos: estórias de usuário e documento de requisitos

que serão exemplificados adiante.

A Matriz de Rastreabilidade é a versão entregável da Matriz da instância. Uma matriz

em que os requisitos são vinculados aos elementos do PDO que lhes deram origem e que tem a

função de favorecer a manutenibilidade do software em caso de evolução ou modificação nos

requisitos e/ou modelos de processos de negócio.

A atividade Gerar Modelo de Requisitos é a responsável por gerar o artefato que con-

tém os requisitos. Nela o analista de requisitos do negócio seleciona o formato desejado e os

requisitos dos Requisitos da instância são transformados para a versão desejada por meio das

estruturas sintáticas apresentadas no Capítulo 4.

Para mostrar que as estruturas sintáticas para geração do Modelo de Requisitos funcio-

nam são apresentados os dois formatos do modelo de requisitos para a instância da Figura 40.

No Quadro 34 contém uma amostra do Modelo de Requisitos no formato de estórias de

usuário para a instância apresentada. O artefato completo pode ser visualizado no Apêndice H.

O Modelo de Requisitos no formato de documento de requisitos possui quatro seções:

Atores, Requisitos Funcionais, Requisitos Não Funcionais e Regras de Negócio. Uma amostra

pode ser visualizada no Quadro 35 e o artefato completo para a instância da linha que está sob

avaliação pode ser visualizado no Apêndice I.

Uma amostra daMatriz de Rastreabilidade pode ser visualizada na Tabela 12. Estamatriz

é idêntica à Matriz da instância quanto ao conteúdo, sendo a tarefa Gerar Matriz da instância

responsável por torná-la um artefato entregável. Para visualizar a Matriz de Rastreabilidade

completa, com todos os requisitos, elementos e vínculos basta consultar o Apêndice J.


Quadro 34 – Amostra doModelo de Requisitos no formato de estórias de usuário.

IDr Estória de Usuário

RF01 Como um funcionário eu quero realizar consulta no histórico do cliente, a fim de visualizarpendências com a empresa.

RF02 Como um funcionário eu quero autorizar ou não a locação com base no histórico do cliente, afim de diminuir perdas com atrasos ou não pagamentos.

RF21Como um funcionário eu quero permitir o pagamento do valor total utilizando várias formasde pagamento, com a restrição de escolher dentre as formas autorizadas pela empresa, a fim degarantir recebimento dos valores devidos.

RF22 Como um funcionário eu quero emitir comprovante de pagamento (nota fiscal), com a restriçãode respeitar as normas fiscais vigentes, a fim de garantir o pagamento da locação.

RN02 O funcionário deve cadastrar o cliente na primeira locação: nome, CPF/CNPJ, telefone e ende-reço, a fim de agilizar futuras locações e iniciar histórico de locações.

RN06 O funcionário deve informar cliente que negociações sobre prazos, valores e financiamento parareposição de material danificado deve ser realizado pela gerência.

RN07 O funcionário deve informar cliente que valores inferiores a R$ 50,00 para multas ou despesascom danos não devem ser parcelados, a fim de evitar parcelamento de valores baixos.

RNF01 O sistema deve retornar o resultado da consulta em 5 segundos.

RNF04 O sistema deve exigir identificação com login e senha para habilitar o recebimento de pagamen-tos, a fim de garantir controle e seção única.

Quadro 35 – Amostra doModelo de Requisitos no formato de documento de requi-sitos.

ID Seção 1 – Atores

1.1 Funcionário: empregado da loja, responsável por registrar as locações, verificar os materiais nadevolução e receber pagamentos.

1.4 Sistema: entidade que armazena os dados e registra as locações, pagamentos e devoluções.IDr Seção 2 – Requisitos Funcionais

RF14 O funcionário deve emitir taxa de multa discriminando: item locado, tempo de atraso, valor dadiária e valor total da multa, a fim de garantir controle de caixa.

RF15 O funcionário deve receber os valores devidos e fornecer troco, se necessário. Restrição: trocosomente para pagamento em dinheiro.

IDr Seção 3 – Requisitos Não FuncionaisRNF01 O sistema deve retornar o resultado da consulta em 5 segundos.

RNF02 O sistema deve exigir login e senha para acesso ao histórico do cliente, a fim de garantir controlee seção única.

IDr Seção 4 – Regras de Negócio

RN06 O funcionário deve informar cliente que negociações sobre prazos, valores e financiamento parareposição de material danificado deve ser realizado pela gerência.

RN07 O funcionário deve informar cliente que valores inferiores a R$ 50,00 para multas ou despesascom danos não devem ser parcelados, a fim de evitar parcelamento de valores baixos.

5.5 Discussão dos Resultados

Depois de realizada a aplicação daARReq a uma LPN é necessário avaliar se os objetivos

propostos no planejamento da avaliação foram alcançados, verificar os resultados obtidos e suas

implicações.

O resumo dos resultados é apresentado na Tabela 13. Para chegar a esses resultados

foram considerados os processos e mecanismos utilizados durante a avaliação de aplicação da

ARReq.

5.5. Discussão dos Resultados 125

Tabela 12 – Amostra da Matriz de Rastreabilidade – Instância da LPN do domíniode Locação.

Elementos da InstânciaIDr SP1 E01 G01 T01 T02 T03 T04 T05 T06 T07 T08 T09RF01 XRF17 XRF18 XRF19 XRF20 XRF22 XRF23 X X XRF26 XRN01 XRN07 X XRN08 XRN13 XRN14 XRNF01 XRNF04 X

O objetivo 1 (O-1) diz respeito a gerar os modelos de requisito nos formatos de casos

de uso, estórias de usuário e documento de requisitos. Para os formatos de estórias de usuário

e documento de requisitos a ARReq gera os artefatos, como ficou demonstrado na avaliação de

aplicação e nos Apêndices H e I. Para o formato de casos de uso (Q-1.1), a abordagem não gera

o artefato de forma eficiente, necessitando de grande intervenção do analista de requisitos do

negócio e subutilizando os requisitos constantes no artefato Requisito da instância, de modo que

foi excluída a possibilidade, neste trabalho, da ARReq gerar oModelo de Requisitos no formato

de casos de uso. A quarta questão tem resposta não, pois a ARReq foi criada para atender estes

dois formatos que estão entre os mais comuns na literatura. Nada impede que sejam criadas

novas estruturas sintáticas para gerar oModelo de Requisitos em outros formatos, mas isso está

no escopo dos trabalhos futuros.

O segundo objetivo (O-2) avalia a possibilidade de redução dos problemas de requisitos:

não atomicidade, ambiguidade, incompletude, duplicidade e o conflito de requisitos. Devido a

estrutura sintática utilizada no Arquétipo de Requisitos é possível ter requisitos atômicos, não

ambíguos, completos e únicos, satisfazendo as questões Q-2.1, Q-2.2, Q-2.4 e Q-2.5 deste obje-

tivo. A questão Q-2.3, sobre o conflito de requisitos, é atendida desde que o analista de requisitos

do negócio identifique os conflitos e os resolva, o que ocorre na tarefa Refinar Requisitos, e sa-

tisfaz a questão se for considerado que há a possibilidade de resolução de conflitos de requisitos.

Para a questão Q-2.6 a resposta é não, pois a ARReq não garante a resolução dos problemas, ape-


Tabela 13 – Resumo dos resultados obtidos com a avaliação.

ObjetivosQuestões O-1 O-2 O-3 O-4 O-5 O-6 O-7Q-1.1 NQ-1.2 SQ-1.3 SQ-1.4 NQ-2.1 SQ-2.2 SQ-2.3 NQ-2.4 SQ-2.5 SQ-2.6 NQ-3.1 SQ-3.2 SQ-3.3 SQ-3.4 SQ-4.1 SQ-4.2 SQ-4.3 SQ-4.4 NQ-4.5 NQ-4.6 SQ-4.7 SQ-5.1 SQ-5.2 SQ-6.1 SQ-6.2 SQ-6.3 SQ-7.1 SQ-7.2 SQ-7.3 NQ-7.4 NQ-7.5 SQ-7.6 SQ-7.7 NQ-7.8 NQ-7.9 2

nas possibilita mecanismos para minimizar sua ocorrência e não realiza nenhuma conferência

para verificar que os problemas foram sanados.

5.5. Discussão dos Resultados 127

Para o objetivo 3 (O-3) que verifica se a ARReq possibilita que seja utilizada qualquer

técnica de elicitação de requisitos aplicáveis a modelos de processos de negócio em BPMN,

todas as respostas foram sim. Apesar de não demonstrado o processo de elicitação com mais

de uma técnica (questão Q-3.1), foi justificado que, devido a adaptação dos requisitos para a

sintaxe genérica, este processo torna-se independente da técnica de elicitação empregada. O

uso desta sintaxe genérica torna afirmativa a resposta à questão Q-3.2 e a resposta à questão

Q-3.3 é comprovada pelos exemplos de eliminação de requisitos duplicados e pelo ganho em

clareza (não ambiguidade) e completude, quando há comparação dos requisitos na Relação dos

Requisitos Elicitados (Apêndice A) com os requisitos constantes no Arquétipo de Requisitos

(Apêndice B). Os Modelos de Requisitos apresentados comprovam a afirmação na resposta à

questão Q-3.4 deste objetivo.

O objetivo 4 (O-4) trata de avaliar a possibilidade de adequação dos requisitos às neces-

sidades do negócio no momento da instanciação. As três primeiras questões possuem respostas

afirmativas que são alcançadas pela tarefa Refinar Requisitos que, como já foi mostrado, trata de

possibilitar a inclusão, exclusão e modificação dos requisitos para adequá-los às especificidades

do negócio. A resposta negativa à questão Q-4.4 se deve ao fato de que a ARReq não possui

um mecanismo para atualização dos artefatos entre os subprocessos de Elicitação de Requisi-

tos e Especificação de Requisitos, o que exigiria um mecanismo de avaliação da adequação do

requisito ao domínio da LPN, o que pode ser realizado em trabalhos futuros. A questão Q-4.5

também tem resposta negativa, pois a ARReq não interfere nos modelos de processos de negó-

cio. As questões Q-4.6 e Q-4.7 possuem respostas afirmativas e o tratamento destas situações

fica a cargo do analista de requisitos do negócio na tarefa Refinar Requisitos.

Já o objetivo 5 (O-5) que avalia a possibilidade de rastrear os requisitos especificados aos

elementos do modelo de processos de negócio, instância da linha, que lhes deram origem, têm

ambas as respostas afirmativas e a justificativa está na existência da Matriz de Rastreabilidade

e das tarefas Atualizar artefatos que tratam de manter a consistência entre os requisitos novos,

modificados ou excluídos e a Matriz da instância, que contém os vínculos entre os elementos

do modelo de processos de negócio e os requisitos.

O objetivo 6 (O-6) avalia a possibilitar de reusar os requisitos tendo em vista sua classifi-

cação em requisitos funcionais, não funcionais ou regras de negócio. Como a classificação dos

requisitos é realizada no momento da elicitação pela a técnica escolhida pelo analista de requi-

sitos do domínio, a ARReq mantém a classificação atribuída e reusa os requisitos sem alterá-la.


Portanto, as respostas às três questões deste objetivo são afirmativas, haja vista que os requisitos

serão reusados, se selecionados, independentemente da classificação. Os requisitos que forem

inseridos na tarefa Refinar Requisitos serão classificados pelo analista de requisitos do negócio

para serem utilizados na atividade Gerar Especificação de Requisitos.

Por fim, o objetivo 7 (O-7) avalia se a ARReq pode ser utilizada por quaisquer abor-

dagens de gestão de LPNs. Neste objetivo estão sendo avaliados a dependência da ARReq em

relação a gestão de LPNs, a escalabilidade da abordagem e o quanto ela é genérica em seus pro-

cedimentos. A primeira questão (Q-7.1) tem resposta afirmativa, pois mudanças no MPNV ou

noMPNV Configurado exigem mudanças nos artefatos da ARReq, pois estes artefatos são, res-

pectivamente, a origem dos requisitos e a fonte que seleciona os requisitos que serão reusados.

As questões Q-7.2, Q-7.5 e Q-7.6 têm respostas afirmativas e as constatações estão no Capítulo 4

em que é demonstrada a aplicação da ARReq em diferentes abordagens de gestão de LPNs com

vários mecanismos e técnicas de modelagem de variabilidade. As questões Q-7.3, Q-7.7 e Q-7.8,

sobre interferência entre artefatos, têm as respostas negativas, pois a ARReq foi concebida para

não interferir nos processos e artefatos da LPN e ser independente do mecanismo e da técnica de

modelagem de variabilidade, como apresentado no Capítulo 4, com a ressalva, apresentada nas

explicações, de que a variabilidade deve ser representada utilizando o paradigma de pontos de

variação e variantes. A questão Q-7.4 avalia se o número de elementos na LPN interfere na es-

calabilidade da ARReq e a resposta negativa vem dos mecanismos criados para permitir o reúso

dos requisitos (sintaxe genérica e Arquétipo de Requisitos), que são independentes do número

de elementos na linha. A última questão (Q-7.9) avalia a dependência que a ARReq possui dos

artefatos da gestão de LPN, o que foi comprovado com a observação de que apenas dois artefatos

da LPN são necessários para a ARReq realizar seus objetivos, o MPNV e oMPNV Configurado

o que indica a pouca dependência e, conseguinte, necessidade de adaptação da gestão de LPNs,

para uso da ARReq.

Após essas considerações pode-se concluir que o objetivo principal, elicitar, reusar e

especificar requisitos a partir de LPNs que utilizam a linguagem BPMN, é alcançado com o uso

da ARReq.

5.6. Ameaças à validade 129

5.6 Ameaças à validade

Identificar as ameaças à validade tem o objetivo de garantir que os resultados produzidos

sejam válidos e estejam corretos. As formas de ameaças à validade foram agrupadas de acordo

com a descrição proposta por Travassos, Gurov e Amaral (2002) que identifica quatro tipos de

validade para experimentos: a validade interna, a validade de conclusão, a validade de externa

e a validade construção.

Validade interna é a confiança que se tem de que o efeito observado é realmente devido

à manipulação feita e não a outros fatores (WAINER, 2007). Uma ameaça interna identificada

é a expectativa do experimentador, caracterizada pelo fato de ser o autor quem selecionou na

literatura a LPN e a abordagem de gestão na qual foi integrada a ARReq. Também foi o experi-

mentador quem escolheu a técnica de elicitação, criou a instância da linha e realizou os processos

para a avaliação, logo é plausível que tenha realizado suas escolhas e conduzido os processos

de modo a atingir os objetivos propostos. Para reduzir os efeitos desta ameaça as escolhas do

autor e os resultados da avaliação foram validados por um especialista na área de Engenharia de

Software.

A validade de conclusão diz respeito as decisões que são tomadas no planejamento da

avaliação e como essas decisões podem impactar no resultado da avaliação (TRAVASSOS; GU-

ROV; AMARAL, 2002). Nesta ameaça pode-se alegar que foi escolhida para a construção e

para a avaliação de aplicação da ARReq uma LPN simples e de conhecimento do autor, o que

influenciou nos resultados. Em defesa do trabalho pode-se observar que as linhas utilizadas no

trabalho são representativas dos domínios a que se referem, não foram criadas pelo autor, sendo

ambas retiradas de trabalhos publicados e, portanto, disponíveis na literatura (TERENCIANI,

2015) e todo o trabalho de seleção, criação e avaliação foi acompanhado e validado por um

especialista na área de Engenharia de Software.

Validade externa é a confiança que se tem que o efeito observável é generalizável (WAI-

NER, 2007). Como aARReq foi testada emLPNs com poucos elementos, é justificável a ameaça

de que não possa ser generalizada para LPNs maiores ou para ambientes industriais. Para con-

tornar essa ameaça se justifica que o tamanho dos artefatos oriundos das LPNs e utilizados pela

ARReq (MPNV e MPNV Configurado) não interferem nos processos da ARReq, pois o uso da

sintaxe genérica para criar o Arquétipo de Requisitos e as atividades para especificar os requi-

sitos são independentes do tamanho dos artefatos de origem. O uso em ambientes industriais


não foi testado, mas acredita-se que a ARReq é aplicável no ambiente industrial devido i) a sua

baixa dependência de artefatos da LPN; ii) a sua simplicidade de aplicação (os processos, ativi-

dades e tarefas não são complexos); iii) sua importância para o negócio, provendo o reúso de

requisitos e, com isso, reduzindo custos com elicitação para o mesmo domínio; iv) sua escalabi-

lidade, podendo ser utilizada mesmo que a linha evolua e se torne complexa (atendendo muitas

especificidades de um mesmo domínio); e v) sua generalidade, pois pode se adaptar a qualquer

gestão de LPNs que adote o BPMN como linguagem de modelagem dos processos de negócio

e o paradigma de pontos de variação e variantes para registrar a variabilidade.

Por fim, a validade de construção que diz respeito aos problemas que podem ocorrer

na hora de colocar as ideias presentes na teoria nos experimentos realizados (TRAVASSOS;

GUROV; AMARAL, 2002). No caso da ARReq pode-se afirmar que é uma ameaça deste tipo

o fato do autor ter escolhido os elementos que compõem a instância da linha que foi utilizada

para testar a abordagem. Para contornar essa ameaça, justifica-se que a instância foi aprovada

por um especialista em Engenharia de Software e que é uma das versões possíveis que atende a

premissa de testar todos os processos que a ARReq possui.


A avaliação conduzida mostra que a ARReq funciona para uma LPN diferente daquela

sobre a qual foi criada. As atividades e subprocessos, bem como os artefatos produzidos, indi-

cam que ela atinge o objetivo de entregar requisitos atômicos, únicos, não ambíguos, completos

como foi proposto ao possibilitar o tratamento dos problemas de requisitos (não atomicidade,

ambiguidade, incompletude e duplicidade).

Como visto, os modelos de requisitos criados nos dois formatos indicam que a estrutura

sintática para criação do Modelo de Requisitos está adequada, bem como a Matriz de Rastre-

abilidade cumpre seu objetivo de vincular os requisitos aos elementos do PDO (instância da

linha).

Como avaliação procurou-se utilizar todas as atividades e tarefas existentes na ARReq.

Assim, mostra-se que a criação de requisitos novos, na atividade Verificar Pontos de Variação,

atende seu objetivo e acrescenta os requisitos aos Requisitos da instância. A atividade Configu-

rar Variáveis também cria novos requisitos nos casos de requisitos com variáveis e vinculados

a vários elementos que tenham sido configurados com valores distintos.


A tarefa Refinar Requisitos obteve êxito ao permitir que os requisitos fossemmelhor ade-

quados às especificidades do negócio, eliminando os desnecessários, modificando a redação de

alguns atributos e inseridos outros que se mostraram necessários mas não estavam no Arquétipo

de Requisitos.

As questões avaliadas que tiveram respostas negativas incluem a impossibilidade de criar

oModelo de Requisitos no formato de casos de uso e de não oferecer garantias para os atributos

de qualidade de requisitos. Também não é possível incluir no Arquétipo de Requisitos os requi-

sitos inseridos na instância da linha e a ARReq não pode criar elementos na instância da linha,

já que os processos da ARReq não interferem nos processos da abordagem de gestão de LPNs,

conforme explicado na discussão dos resultados desta avaliação.

Assim, observa-se que a ARReq satisfaz os objetivos propostos, de elicitar e especificar

requisitos, entrega os artefatos pretendidos e permite o reúso de requisitos a partir de LPNs.

133

6 Conclusão

Neste capítulo são apresentadas a síntese do trabalho e as contribuições daARReq (Seção

6.1), suas limitações (Seção 6.2) e as sugestões de trabalhos futuros visando delinear desdobra-

mentos do trabalho desenvolvido com o intuito de melhorar e evoluir a ARReq (Seção 6.3).

6.1 Síntese e Contribuições

Este trabalho de mestrado procurou apresentar o reúso como técnica importante para me-

lhorar a Engenharia de Requisitos a partir de LPNs que utilizam o BPMN como linguagem de

modelagem. Para tanto, apresentou-se a importância da modelagem de negócio para a compre-

ensão das necessidades do negócio e a forma como essa modelagem pode auxiliar a Engenharia

de Requisitos.

Estabeleceu-se como objetivo a criação de uma abordagem, a ARReq, que permitisse

elicitar, reusar e especificar requisitos de software a partir de LPNs que utilizem a linguagem

BPMN. E, para obter este objetivo, a abordagem deveria ser genérica, utilizar qualquer técnica de

elicitação de requisitos aplicável, reduzir problemas de requisitos e possibilitar a rastreabilidade

entre os requisitos e o modelo de processos de negócio instância da linha.

Para tanto utilizou-se uma pesquisa observacional com viés positivista organizada em

quatro fases: exploratória, planejamento, ação e avaliação; executadas ao longo deste trabalho.

No embasamento teórico procurou-se retomar os principais conceitos e subprocessos da

Engenharia de Requisitos, especialmente Elicitação de Requisitos e Especificação de Requisitos,

a fim de comprovar que a abordagem procura seguir esses subprocessos para realizar seu traba-

lho com eficiência e entregar requisitos que respeitam a normatização de qualidade ISO 29.148

(ISO, 2011), sendo atômicos, não ambíguos, completos, consistentes, entre outras características

sugeridas pela norma.

Em seguida, fundamentou-se a importância da modelagem de processos de negócio e

como se pode elicitar requisitos a partir dela. Deu-se destaque e apresentou-se com maiores

detalhes a técnica REMO (VIEIRA, 2012), por ter sido a empregada para exemplificar a ARReq

e conduzir a elicitação durante a avaliação de aplicação da abordagem. No entanto, a ARReq

134 Capítulo 6. Conclusão

pode ser aplicada utilizando qualquer técnica de elicitação de requisitos adequada a modelos de

processos de negócio em BPMN.

Por fim, apresentaram-se as justificativas que tornam as LPNs uma forma eficiente e pro-

missora de reusar modelos de processos de negócio, e os requisitos associados a seus elementos,

para agilizar a Engenharia de Requisitos. Explicou-se sobre sua composição, funcionamento,

representação das variabilidades e como são criadas as instâncias destas linhas. Procurou-se

exemplificar os artefatos destas LPNs utilizando os pertencentes à GLPN (LANDRE, 2012)

pois esta abordagem de gestão de LPNs foi empregada para avaliar a aplicação da ARReq.

No Capítulo 3 foi apresentada uma Revisão Sistemática da Literatura, na qual se pro-

curou atualizar a revisão conduzida por Bitencourt, Paiva e Cagnin (2016) e se concluiu que

há poucos trabalhos na literatura que elicitam requisitos a partir de modelos de processos de

negócio e nenhum que o faz no âmbito das LPNs.

A ARReq pretende ser uma abordagem de reúso genérica, aplicável a qualquer forma de

gestão de LPNs que utilize o paradigma de pontos de variação e variantes para representar as

variabilidades. Esta abordagem complementa os processos de abordagens de gestão de LPNs,

acrescentando-lhes mecanismos de elicitar os requisitos, permitir o reúso destes requisitos, gerar

oModelo de Requisitos em dois formatos distintos e uma matriz de rastreabilidade que vincula

os requisitos elicitados aos elementos presentes na instância da linha.

Na construção da ARReq se percebeu que a forma de elicitação empregada para obter os

requisitos não influenciaria na execução da abordagem, pois esta contaria com uma adaptação

dos requisitos elicitados para uma sintaxe genérica, composta por atributos claros e objetivos,

que permitem diminuir os problemas de falta de atomicidade, incompletude, duplicidade e am-

biguidade dos requisitos e torna-a independente da técnica de elicitação.

A norma ISO/IEC 29.148 (ISO, 2011) sugere nove atributos de qualidade para os requi-

sitos de software: necessários, livres de implementação, não ambíguos, consistentes, completos,

singular (neste trabalho denominado atômico), factível, rastreável e verificável. Destes atributos

de qualidade infere-se que dois sejam atendidos pela elicitação de requisitos a partir da modela-

gem de processos de negócio em BPMN: i) Necessário, pois os requisitos retirados dos modelos

de processos de negócio, que representam as necessidades do negócio, permitem a inferência de

que os requisitos estão alinhados com o negócio; e ii) Livre de implementação, pois o modelo de

processos de negócio não possui informações computacionais ou sobre a plataforma sobre a qual

6.1. Síntese e Contribuições 135

o software será construído, de modo que os desenvolvedores terão a liberdade de implementar

o requisitos de acordo com as especificidades do negócio a ser atendido pelo software. Como a

ARReq elicita os requisitos a partir de LPNs criadas sobre modelos de processos de negócio de

um domínio específico, pode-se deduzir que estes dois atributos de qualidade também estarão

nos requisitos especificados com o uso da abordagem.

Os atributos de qualidade não ambíguo, completo e singular, são atendidos pela ARReq,

pois o subprocesso de elicitação de requisitos, descrito no Capítulo 4, favorece a diminuição da

ambiguidade, duplicidade e incompletude dos requisitos, bem como torna o requisito singular,

devido aos mecanismo adotados para a construção do Arquétipo de Requisitos. A sugestão de

que os requisitos sejam consistentes também é atendida pela abordagem, pois a ARReq oferece

a possibilidade de resolução de conflitos de requisitos que sejam identificados pelo analista

de requisitos do negócio quando da especificação dos requisitos para uma instância da LPN;

e rastreável, pois contam com um artefato próprio para representar e indicar a rastreabilidade

entre os requisitos e os elementos do modelo de processos de negócio, denominado Matriz de

Rastreabilidade.

Assim, dos nove atributos de qualidade propostos pela norma ISO/IEC 29.148 a ARReq

favorece o atendimento de sete deles, sendo exceções os atributos factível e verificável. Estes

atributos não são contemplados pois dizem respeito ao escopo do desenvolvimento do software.

Os atributos da sintaxe genérica são armazenados pela abordagem no Arquétipo de Re-

quisitos, um artefato que contém todos os requisitos da LPN e permite que estes sejam especi-

ficados, no momento da instanciação, em dois dos formatos mais comuns da literatura: estórias

de usuário e documento de requisitos.

Para a criação do Arquétipo de Requisitos, além da adaptação para a sintaxe genérica,

os requisitos duplicados são eliminados e aqueles que possuem valores variáveis atribuídos são

generalizados com o uso da tag <<variável>>, contribuindo para que os artefatos internos da

ARReq mantenham-se consistentes com o domínio que representam.

Para seu funcionamento, a ARReq possui dois processos principais, a Elicitação de Re-

quisitos, que realiza as ações descritas nos parágrafos anteriores, e aEspecificação de Requisitos,

responsável por gerar os artefatos entregáveis da abordagem e permitir a adaptação dos requisi-

tos às necessidades específicas do negócio que não estejam contempladas pela LPN.


Dentre estas adaptações estão a criação de requisitos novos quando da seleção de mais

de uma variante em pontos de variação do tipo or ou optional, ou quando há configurações de

variáveis de requisitos que estão vinculados a vários elementos e possuem atribuições diferentes;

bem como, quando o analista de requisitos do negócio insere, modifica ou exclui requisitos para

adequar os requisitos reusados às necessidades do negócio.

Os artefatos entregáveis da ARReq são oModelo de Requisitos, que pode ser formatado

como estória de usuário ou documento de requisitos e contêm os requisitos da instância da linha.

O outro artefato é a Matriz de Rastreabilidade que contêm os vínculos entre os requisitos e os

elementos da instância da linha e auxilia na manutenibilidade do projeto de software.

A avaliação de aplicação, conduzida no Capítulo 5, baseou-se na metodologia GQM

(BASILI, 1992) e verificou que a ARReq funciona para os subprocessos e atividades que propõe,

pois se acoplou adequadamente a uma abordagem de gestão de LPNs, elicitou requisitos a partir

de uma LPN criada com o apoio desta abordagem, eliminou os requisitos duplicados, ambíguos

e incompletos e, para a instância apresentada, gerou os modelos de requisitos nos formatos

de estória de usuário e documento de requisitos, além da matriz de rastreabilidade para essa

instância.

Sobre os objetivos da avaliação de aplicação e as questões que foram propostas, verificou-

se que a ARReq atingiu boa parte dos objetivos que foram propostos na avaliação e comprovou-

se que a abordagem é genérica, pouco dependente da gestão de LPN, que reduz os problemas de

requisitos mais comuns e permite que os requisitos especificados sejam reusados e adaptados às

especificidades do negócio.

6.2 Limitações

O potencial da ARReq para auxiliar no reúso de requisitos é considerável. Algumas

limitações foram identificadas principalmente a partir dos resultados da avaliação da ARReq e

estão listadas a seguir para que encorajem novos trabalhos que visem melhorá-la.

• A avaliação da eficiência da ARReq quanto à redução de custos nos processos da Enge-

nharia de Requisitos não fez parte do escopo deste trabalho;

• Não são oferecidas garantias para a resolução dos problemas de requisitos, apenas possi-

bilidades de redução da ocorrência destes problemas;

6.3. Trabalhos Futuros 137

• Algumas atividades, especialmente na fase de Especificação de Requisitos, têm forte de-

pendência do conhecimento, habilidade e experiência do analista de requisitos do negócio;

• Não foram realizados experimentos ou estudos de caso que fornecessem dados empíricos

que pudessem ser utilizados como métrica para avaliação dos resultados e para servirem

de comparação com outras abordagens que, porventura, venham a ser criadas;

• Não está clara como será a gestão dos requisitos por ocasião da atualização da LPN com

a inserção de novos elementos, processos ou subprocessos;

• Os requisitos inseridos pelo analista de requisitos do negócio ao executar a atividade Refi-

nar Requisitos, não são incluídos aos requisitos do Arquétipo de Requisitos, deixando de

oportunizar novos requisitos para enriquecer a linha;

• Não provê apoio computacional à elicitação e especificação dos requisitos, necessitando

ser realizada de forma manual;

• Não é possível especificar os requisitos no formato de casos de uso, pois este formato

exige que informações específicas sejam atribuídas aos elementos da LPN (fluxo, atores,

dependências, início e fim), o que não foi realizado neste trabalho de mestrado.

6.3 Trabalhos Futuros

Motivados pelas limitações apresentadas na seção anterior, os seguintes trabalhos futuros

são sugeridos:

• Quantificar o impacto do uso da ARReq nos custos da Engenharia de Requisitos, por meio

de experimentos, definir métricas de eficiência e quantificar o quanto a ARReq pode fa-

vorecer a Engenharia de Requisitos se comparada a outras formas de elicitação e especi-

ficação com reúso;

• Verificar a possibilidade de garantir a resolução dos problemas de requisitos, criando heu-

rísticas, processos de verificação ou outros mecanismos para certificar que os problemas

de requisitos sejam sanados, em especial, os conflitos de requisitos, pois sua solução na

ARReq é muito dependente da interferência humana;

• Executar avaliações para observar a eficiência da ARReq. Estas avaliações podem forne-

cer informações sobre a qualidade dos requisitos de acordo com a norma ISO/IEC 29.148

(ISO, 2011), curva de aprendizado da abordagem, relação percentual entre os requisitos


fornecidos pela abordagem e aqueles especificados com outras técnicas para um mesmo

modelo de processos de negócio;

• Definir mecanismos para atualizar os requisitos constantes no Arquétipo de Requisitos

por ocasião da inserção de novos elementos, processos ou subprocessos na LPN, a fim de

manter este artefato sempre atualizado e consistente com a linha que representa o domínio.

• Definir uma estratégia para que os requisitos incluídos pelo analista de requisitos do negó-

cio, na tarefa Refinar Requisitos, sejam avaliados e possibilitem uma tomada de decisão

que pode incluir: i) manter o requisito apenas como parte da instância, pois é muito especí-

fico; ii) incluir o requisito no Arquétipo de Requisitos, pois enriquece os requisitos de um

elemento já existente na linha; e, por fim, iii) incluir novos elementos à linha, evoluindo-a,

pois o requisito inserido necessita de novas tarefas ou elementos no modelo de processos

de negócio com variabilidades;

• Vincular a ARReq a uma gestão de LPN automatizada, por exemplo o BPL-Framework

2.0 (FERREIRA; PAIVA; CAGNIN, 2017), para verificar se é possível acoplar a ARReq

em abordagens de gestão que tenham suporte computacional para o reúso dos requisitos;

• Aprimorar a atividade Gerar Modelos de Requisitos para permitir a geração de modelos

de requisitos no formato de casos de uso, pois este formato é o mais utilizado na literatura

e deve ser contemplado pela ARReq. Uma sugestão pode ser encontrada no trabalho de

Nogueira (2017) que permite a extração automatizada de requisitos no formato de casos

de uso. O trabalho deste autor poderia ser adaptado para os artefatos da ARReq para gerar

o Modelo de Requisitos no formato de casos de uso; e

• Possibilitar a inclusão de novas estruturas sintáticas para a geração domodelo de requisitos

em outros formatos ainda não contemplados;

139

Referências

ABURUB, F.; ODEH, M.; BEESON, I. Modelling non-functional requirements of businessprocesses. Information and Software Technology, v. 49, n. 11–12, p. 1162–1171, 2007.

ANDRADE, A. C. Processando Requisitos: O Uso De Processos Na Especificação DeRequisitos. CEUR Workshop Proceedings, v. 1542, n. 9, p. 33–36, 2015.

AUER, D.; GEIST, V.; DRAHEIM, D. Extending BPMN with Submit/Response-Style UserInteraction Modeling. In: 2009 IEEE Conference on Commerce and Enterprise Computing.Vienna, Austria: IEEE, 2009. p. 368–374.

BACHMANN, F.; BASS, L. Managing variability in software architectures. In: Proceedings ofthe 2001 symposium on Software reusability putting software reuse in context - SSR ’01. NewYork, New York, USA: ACM Press, 2001. v. 26, p. 126–132.

BASILI, V. R. Software modeling and measurement: the Goal Question Metric paradigm.Computer Science Technical Report Series, University of Maryland, College Park, MD, n.CS-TR-2956 (UMIACS-TR-92-96), p. 24, Set 1992.

BITENCOURT, A. S.; PAIVA, D. M. B.; CAGNIN, M. I. Elicitação de Requisitos a partir deModelos de Processos de Negócio em BPMN : Uma Revisão Sistemática. In: XII BrazilianSymposium on Information Systems. Florianópolis, SC, Brazil: SBC, 2016. p. 200–207.

BOCCIARELLI, P.; D’AMBROGIO, A. A BPMN Extension for Modeling Non FunctionalProperties of Business Processes. In: Proceedings of the 2011 Symposium on Theory ofModeling & Simulation: DEVS Integrative M&S Symposium. San Diego, CA, USA: Societyfor Computer Simulation International, 2011. (TMS-DEVS ’11), p. 160–168.

BOFFOLI, N. et al. Business Process Lines and Decision Tables Driving Flexibility bySelection. In: Software Composition: 11th International Conference, SC 2012, Prague, CzechRepublic, May 31 – June 1, 2012. Proceedings. Berlin, Heidelberg, Germany: Springer, 2012.p. 178–193.

BRAUN, R. BPMN Extension Profiles – Adapting the Profile Mechanism for IntegratedBPMN Extensibility. In: 2015 IEEE 17th Conference on Business Informatics. Lisboa, Portugal:IEEE, 2015. v. 1, p. 133–142.

CARVALHO, E. A.; ESCOVEDO, T.; MELO, R. N. Using Business Processes in SystemRequirements Definition. In: 2009 33rd Annual IEEE Software Engineering Workshop. Skövde,Sweden: IEEE, 2009. p. 125–130.

CARVALHO, E. A. de. Engenharia de Processos de Negócios e a Engenharia de Requisitos:Análise e Comparações de Abordagens e Métodos de Elicitação de Requisitos de SistemaOrientada por Processos de Negócio. Tese (mestrado) — UFRJ - Universidade Federal do Riode Janeiro, Rio de Janeiro - RJ, 2009.

CHIARELLO, M. A. Abordagem para elicitação de requisitos de software baseada emmodelo de processo de negócio. 1–118 p. Dissertação (Mestrado) — UTFPR - UniversidadeTecnológica Federal do Paraná, 2013.

140 Referências

CHINOSI, M.; TROMBETTA, A. BPMN: An introduction to the standard. ComputerStandards and Interfaces, Elsevier B.V., v. 34, n. 1, p. 124–134, 2012.

CIBRÁN, M. A. Translating BPMN models into UML activities. Lecture Notes in BusinessInformation Processing, v. 17 LNBIP, p. 236–247, 2009.

COCKBURN, A. Writing effective use cases. ACM SIGSOFT Software Engineering Notes,New York, NY, USA, v. 26, n. 1, p. 94, 2001.

COHEN, M. User Stories Applied: For Agile Software Development. Boston, MA, USA:Addison-Wesley, 2004.

CRUZ, E. F.; MACHADO, R. J.; SANTOS, M. Y. Derivation of Data-Driven Software Modelsfrom Business Process Representations. In: 9th International Conference on the Quality ofInformation and Communications Technology. Guimarães, Portugal: IEEE, 2014. p. 276–281.

CRUZ, E. F.; MACHADO, R. J.; SANTOS, M. Y. Derivation of Data-Driven Software Modelsfrom Business Process Representations. In: 9th International Conference on the Quality ofInformation and Communications Technology. Guimarães, Portugal: IEEE, 2014. p. 276–281.

CRUZ, E. F.; MACHADO, R. J.; SANTOS, M. Y. From business process models to use casemodels: A systematic approach. In: 4th Enterprise Engineering Working Conference, EEWC2014. Madeira, Portugal: CIAO, 2014. v. 174 LNBIP, p. 167–181.

CRUZ, E. F.; MACHADO, R. J.; SANTOS, M. Y. Bridging the gap between a set ofinterrelated business process models and software models. In: ICEIS 2015 - 17th InternationalConference on Enterprise Information Systems. Barcelona, Spain: SCITEPRESS - Science andand Technology Publications, 2015. v. 2, p. 338–345.

CRUZ, E. F.; MACHADO, R. J.; SANTOS, M. Y. Bridging the gap between a set of interrelatedbusiness process models and software models. ICEIS 2015 - 17th International Conference onEnterprise Information Systems, Proceedings, Barcelona, Spain, v. 2, p. 338–345, 2015.

CRUZ, E. F.; MACHADO, R. J.; SANTOS, M. Y. Deriving Software Design Models from aSet of Business Processes. In: 4th International Conference on Model-Driven Engineering andSoftware Development. Rome, Italy: SCITEPRESS - Science and and Technology Publications,2016. p. 489–496.

DECKER, M. et al. Modeling Mobile Workflows with BPMN. In: 2010 Ninth InternationalConference on Mobile Business and 2010 Ninth Global Mobility Roundtable (ICMB-GMR).Athens, Greece: IEEE, 2010. p. 272–279.

DIAS, F. et al. Uma Abordagem para a Transformação Automática do Modelo de Negócio emModelo de Requisitos.Workshop de Engenharia de Requisitos, p. 51–60, 2006.

ERIKSSON, H.-E.; PENKER, M. Business modeling with UML: Business Patterns at Work. 1.ed. New York, NY, USA: OMG Press, 2000. 459 p.

FERREIRA, D. A. M. Um arcabouço computacional de apoio à instanciação de linhas deprocessos de negócios. 126 p. Dissertação (Mestrado) — UFMS, Campo Grande, MS, Brasil,2017.

Referências 141

FERREIRA, D. A. M.; PAIVA, D. M. B.; CAGNIN, M. I. BPL-Framework 2.0: Support toolfor Creation and Instantiation of Business Process Lines. In: XXIX International Conferenceon Software Engineering and Knowledge Engineering. Pittsburgh, PA, USA: Scopus, 2017. p.1–20.

GRÖNER, G. et al. Modeling and validation of business process families. Information Systems,v. 38, n. 5, p. 709–726, jul 2013.

HERNÁNDEZ, U. I.; RODRÍGUEZ, F. J.; MARTIN, M. V. Use Processes - Modelingrequirements based on elements of BPMN and UML Use Case Diagrams. In: ICSTE 2010 -2nd International Conference on Software Technology and Engineering, Proceedings. SanJuan, PR, USA: IEEE, 2010. v. 2.

ISO. 29148-2011 - ISO/IEC/IEEE International Standard - Systems and software engineering– Life cycle processes –Requirements engineering. Vernier, Geneva, Switzerland, 2011. 1–94 p.

JANIS, B.; STIRNA, J.; BRASH, D. EKD user guide. Dept. of Computer and Systems Sciences,Royal Institute of Technology, Stockholm, Sweden, 1998.

JOSUTTIS, N. M. SOA na Prática: A arte da Modelagem de Sistemas Distribuídos. 1º. ed. Riode Janeiro, RJ, Brazil: Alta Books, 2008.

KANG, K. et al. Feature-Oriented Domain Analysis (FODA) Feasibility Study. Pittsburgh, PA,USA, 1990.

KARAGIANNIS, D.; KÜHN, H. Metamodelling Platforms. In: BAUKNECHT, K.; TJOA,A. M.; QUIRCHMAYR, G. (Ed.). Proceedings of the Third International Conference EC-Web.Berlin, Heidelberg, Germany: Springer Berlin Heidelberg, 2002. (Lecture Notes in ComputerScience, v. 2455), p. 182.

KITCHENHAM, B. et al. Systematic literature reviews in software engineering – A systematicliterature review. Information and Software Technology, Elsevier B.V., v. 51, n. 1, p. 7–15,2009.

KNIGHT, D. M. Elicitação de requisitos de software a partir do modelo de negócio.Dissertação (Mestrado) — UFRJ - Universidade Federal do Rio de Janeiro. Instituto deMatemática. Núcleo de Computação Eletrônica., Rio de Janeiro, RJ, Brazil, 2004.

LADEIRA, S. A. Z. Reutilização de modelagem de negócios baseada em visões. 1–166 p.Dissertação (Mestrado) — Centro Universitário Eurípides de Marília, Marília, SP, Brazil, 2008.

LADEIRA, S. A. Z. et al. Reutilização de Modelagem de Negócios baseada em Visões: umEstudo de Caso. XXII Simpósio Brasileiro de Engenharia de Software (SBES 2008), Campinas,SP, Brazil, p. 140–155, 2008.

LANDRE, G. et al. vrBPMN* and FM: An Approach to Model Business Process Line. In:FOURNIER, F.; MENDLING, J. (Ed.). Business Process Management Workshops: BPM 2014International Workshops. Eindhoven, The Netherlands: Springer, 2014. p. 130–141.

LANDRE, G. B. GLPN – Uma Abordagem para Gestão de Linhas de Processos de Negócios.111 p. Dissertação (Mestrado) — Universidade Federal de Mato Grosso do Sul, Campo Grande,MS, Brazil, 2012.

142 Referências

LONGO, H. E. R.; SILVA, M. P. da. A Utilização de Histórias de Usuários no Levantamentode Requisitos Ágeis. International Journal of Knowledge Engineering and Management,Florianópolis, SC, Brazil, v. 6, n. 3, p. 1–30, 2014.

MARQUES, M. R. S. Engenharia de Requisitos Baseada em Modelos para o Domínio deSoftware Embarcado. 75 p. Dissertação (Mestrado) — Universidade Federal de Pelotas, 2013.

MARSHALL, C. Enterprise Modeling with UML: Designing Successful Software ThroughBusiness Analysis. Essex, UK: Addison-Wesley Longman Ltd., 2000.

MURATA, T. Petri nets: Properties, analysis and applications. Proceedings of the IEEE, IEEE,v. 77, n. 4, p. 541–580, 1989.

NOGUEIRA, F. A. Levantamento e especificação de requisitos de software utilizando modelosde processos de negócio. 137 p. Dissertação (Mestrado) — Universidade Estadual PaulistaJúlio de Mesquita Filho, Instituto de Biociências, Letras e Ciências Exatas, Rio Claro, SP,Brazil, 2017.

NUNES, V. T.; WERNER, C. M. L.; SANTORO, F. M. S. Context-based process line. In:12th International Conference on Enterprise Information Systems. Funchal, Madeira, Portugal:Scopus, 2010. v. 3, p. 277–282.

OLIVEIRA, M. A. B. D. et al. Elicitação de Requisitos a partir de Modelos de Processos deNegócio e Modelos Organizacionais: Uma pesquisa para definição de técnicas baseadas emheurísticas. In: 21st IEEE International Requirements Engineering Conference - ER@BR. Riode Janeiro, RJ, Brazil: IEEE, 2013. p. 1–6.

OMG. Unified Modeling Language: Infrastructure. The Object Management Group, n. July,p. 226, 2005.

OMG. Business Process Model and Notation. Berlin, Heidelberg, Germany: SpringerBerlin Heidelberg, 2012. v. 125. 532 p. (Lecture Notes in Business Information Processing,December).

POHL, K.; BÖCKLE, G.; LINDEN, F. J. v. D. Software product line engineering: foundations,principles and techniques. 1. ed. Berlin, Heidelberg, Germany: Springer Science & BusinessMedia, 2005. 467 p.

PRESSMAN, R. S.; MAXIM, B. R. Engenharia de Software. 8ª. ed. São Paulo, SP, Brazil:McGraw Hill Education, 2016. 968 p.

RESPÍCIO, A.; DOMINGOS, D. Reliability of BPMN Business Processes. Procedia ComputerScience, v. 64, p. 643–650, 2015.

RODRÍGUEZ, A.; FERNÁNDEZ-MEDINA, E.; PIATTINI, M. Towards CIM to PIMTransformation: From Secure Business Processes Defined in BPMN to Use-Cases. In: BusinessProcess Management. Berlin, Heidelberg: Springer, 2007. v. 4714, p. 408–415.

RODRÍGUEZ, A.; FERNÁNDEZ-MEDINA, E.; PIATTINI, M. Towards ObtainingAnalysis-Level Class and Use Case Diagrams from Business Process Models. In: Advances inConceptual Modeling – Challenges and Opportunities. Berlin, Heidelberg: Springer, 2008. v.5232 LNCS, p. 103–112.

Referências 143

ROLLAND, C.; NURCAN, S. Business process lines to deal with the variability. In: 43rdHawaii International Conference on System Sciences. Honolulu, Hawaii, USA: IEEE, 2010.p. 10.

ROSSON, M.; CARROLL, J. Scenario-Based Design. In: The Human-Computer InteractionHandbook: Fundamentals, Evolving Technologies and Emerging Applications. 3. ed. BocaRaton, FL, USA: CRC Press, 2012. p. 1105–1124.

RUNGWORAWUT, W.; SENIVONGSE, T. A guideline to mapping business processes toUML class diagrams.WSEAS Transactions on Computers, v. 4, n. 11, p. 233–238, 2005.

SANTOS, R. P. C. Engenharia de Processos: Análise do referencial teórico-conceitual,instrumentos, aplicações e casos. 297 p. Dissertação (Mestrado) — UFRJ - UniversidadeFederal do Rio de Janeiro, 2002.

SCHNIEDERS, A.; PUHLMANN, F. Variability Mechanisms in E-Business Process Families.9th International Conference on Business Information Systems (BIS 2006), Klagenfurt, Austria,LNI 85, p. 583–601, 2006.

SINHA, A.; PARADKAR, A. Use Cases to Process Specifications in Business ProcessModeling Notation. In: 2010 IEEE International Conference on Web Services. Miami, FL,USA: IEEE, 2010. p. 473–480.

SOMMERVILLE, I. Engenharia de Software. 10ª. ed. São Paulo, SP, Brazil: Addison-Wesley,2015. 816 p.

SORGATTO, D. W.; CAGNIN, M. I. CapyReq: Ferramenta de apoio à extração de requisitosa partir de modelos de processos de negócio em BPMN. 7 p. Trabalho de Conclusão de Curso— UFMS - Universidade Federal de Mato Grosso do Sul, Campo Grande, MS, Brazil, 2017.

SOUZA, R. X. d. O. Modeler: Uma abordagem baseada em modelos aplicada ao processo deelicitação de requisitos. Dissertação (Mestrado) — UFSE - Universidade Federal de Sergipe,São Cristovão, SE, Brazil, 2014.

SRIGANESH, S.; RAMANATHAN, C. Externalizing business rules from business processesfor model based testing. In: 2012 IEEE International Conference on Industrial Technology.New York, NY, USA: IEEE, 2012. p. 312–318.

TERENCIANI, M. F. Um Arcabouço Computacional de Apoio à Criação de Linha deProcessos de Negócio. 102 p. Dissertação (Mestrado) — Universidade Federal de Mato Grossodo Sul, Campo Grande, MS, Brazil, 2015.

TERENCIANI, M. F. et al. A Plugin for Eclipse towards Supporting Business Process LinesDocumentation. In: 2015 IEEE/ACS 12th International Conference of Computer Systems andApplications (AICCSA). Marrakech, Morocco: IEEE, 2015. p. 1–8.

TERENCIANI, M. F. et al. BPMN*-A Notation for Representation of Variability in BusinessProcess Towards Supporting Business Process Line Modeling. In: 27th InternationalConference on Software Engineering & Knowledge Engineering (SEKE’2015). Pittsburgh, PA,USA: Scopus, 2015.

TRAVASSOS, G. H.; GUROV, D.; AMARAL, E. A. G. do. Introdução à Engenharia deSoftware Experimental. Rio de Janeiro - RJ, 2002. RT-ES-590/02, 52 p.

144 Referências

VARA, J. L. d. l.; SÁNCHEZ, J. BPMN-Based Specification of Task Descriptions: Approachand Lessons Learnt. In: Requirements Engineering: Foundation for Software Quality.Amsterdam, Netherlands: Springer, 2009. v. 5512 LNCS, p. 124–138.

VARA, J. L. de la; DIÁZ, J. S. Business process-driven requirements engineering: a goal-basedapproach. Journal of the 8th Workshop on Business, p. 1–9, 2007.

VARA, J. L. de la et al. Improving Requirements Analysis through Business Process Modelling:A Participative Approach. In: Business Information Systems. Berlin, Heidelberg, Germany:Springer, 2008. v. 7, p. 165–176.

VIEIRA, S. R. C. REMO: Uma técnica de elicitação de requisitos orientada pela modelagemde processos de negócios. 1–129 p. Dissertação (Mestrado) — UFAM - Universidade Federaldo Amazonas, 2012.

VIEIRA, S. R. C. et al. Using Empirical Studies to evaluate the REMO Requirement ElicitationTechnique. In: SEKE 2012 – 24th International Conference on Software Engineering andKnowledge Engineering. San Francisco Bay, CA, USA: Knowledge Systems Institute GraduateSchool, 2012. p. 33–38.

VIEIRA, S. R. C. et al. Avaliando uma Técnica para Extrair Requisitos a partir de Diagramasde Processos de Negócios através de Estudos Experimentais. In: CLEI 2012 - XXXVIIIConferencia Latinoamericana en Informática. Medelin, Colombia: Elsevier, 2012. p. 11.

WAINER, J. Métodos de pesquisa quantitativa e qualitativa para a Ciência da Computação.Atualização em Informática. Org: Tomasz Kowaltowski, v. 1, p. 221–262, 2007.

WAZLAWICK, R. S. Análise e projeto de sistemas de informação orientada a objetos. 2ª. ed.Rio de Janeiro, RJ, Brazil: Elsevier, 2011.

WAZLAWICK, R. S. Análise e design orientados a objetos para sistemas de informação. 3ª.ed. Rio de Janeiro, RJ, Brazil: Elsevier, 2015.

WOHLIN, C. Guidelines for snowballing in systematic literature studies and a replication insoftware engineering. In: Proceedings of the 18th International Conference on Evaluation andAssessment in Software Engineering - EASE ’14. New York, NY, USA: ACM Press, 2014.p. 10.

YOUSFI, A. et al. Variability patterns for business processes in BPMN. Information Systemsand e-Business Management, v. 14, n. 3, p. 443–467, Aug 2016.

YU, E. et al. Social modeling for requirements engineering: An introduction. Social Modelingfor requirements engineering, MIT Press, p. 3–10, 2011.

ZAVE, P. Classification of research efforts in requirements engineering. In: 1995 IEEEInternational Symposium on Requirements Engineering (RE’95). York, UK: IEEE, 1995. v. 29,n. 4, p. 214–216.

145

A Relação de Requisitos Elicitados – Locação

Segue a relação completa dos requisitos existentes no artefato Relação dos Requisitos

Elicitados para o domínio de Locação apresentado no Capítulo 5. Estes requisitos foram elicita-

dos utilizando a técnica REMO (VIEIRA, 2012).

Tabela 14 – Relação dos Requisitos Elicitados – Locação.


SP1 Tarefa - T01: Verificar histó-

rico de locação do clienteRF Realizar consulta no histórico do cliente RF01


rico de locação do clienteRF Autorizar ou não a locação com base no histórico do

clienteRF02


rico de locação do clienteRNF O resultado da consulta deve ser retornado em 5 segun-

dosRNF01


rico de locação do clienteRNF Exigir login e senha para acesso ao histórico do cliente

para controle e garantir seção únicaRNF02

SP1 Gateway - G01: Locação au-

torizada?RN

Não autorizar locação de cliente com débitos, com loca-

ção sem devolução, em suspensão ou com mais de três

dias de atraso em duas locações distintas nos últimos

seis meses

RN01

SP1 Objeto de Dados - D01: Ca-

dastro de clientesRNF Realizar backup do banco de dados a cada semana RNF03


rico de locaçãoRF Realizar consulta no histórico do cliente RF03


rico de locaçãoRNF O resultado da consulta deve ser retornado em 5 segun-

dosRNF04


rico de locaçãoRNF Exigir login e senha para acesso ao histórico do cliente

para controle e garantir seção únicaRNF05

SP2 Gateway - G01: Cliente

com pendências?RN

Não autorizar locação de cliente com débitos, com loca-

ção sem devolução, suspensos ou com mais de três dias

de atraso em duas locações distintas nos últimos seis me-

ses

RN02

SP2 Objeto de Dados - D01: Ca-

dastro de clientesRNF Realizar backup do banco de dados a cada semana RNF06

SP2Tarefa - T02: Verificar his-

tórico de multas junto ao de-

partamento de trânsito

RF Realizar consulta em base de dados externa (departa-

mento de trânsito)RF04

Continua na próxima página

146 Apêndice A. Relação de Requisitos Elicitados – Locação

Tabela 14 – Relação dos Requisitos Elicitados – Locação – Continuação





RF Manter histórico de acessos a sistemas externos (funci-

onário e consulta realizada) no logRNF07




RNF Exigir identificação com login e senha do funcionário

para garantir seção de acesso únicaRNF08




RNF O resultado da consulta deve ser retornado em 30 segun-

dosRNF09

SP2 Gateway - G02: Qtde de

multas?RN Não autorizar locação de cliente com mais de 2 multas

no resultado da consultaRN03

T01 Tarefa: Realizar Locação RF Registrar locação: cliente, material locado, valor da lo-

cação, data da locaçãoRF05

T01 Tarefa: Realizar Locação RF Emitir relação de material locado: cliente, funcionário,

material locado, valor da locação, data da locaçãoRF06

T01 Tarefa: Realizar Locação RFEmitir comprovante de locação: cliente, funcionário,

material locado, valor da locação, data da locação e data

da devolução

RF07

T01 Tarefa: Realizar Locação RN Cadastrar todo cliente na primeira locação: Nome, tele-

fone, endereçoRN04

E01 Evento: Aguardar devolu-

çãoRF Gerar uma relação das devoluções esperadas para o dia RF08

E01 Evento: Aguardar devolu-

çãoRN Ligar para o cliente após um dia de atraso na devolução

do material locadoRN05

T02 Tarefa: Verificar condição

do materialRF Verificar o estado de conservação do material locado RF09


do materialRN Informar cliente de problemas encontrados no material

locadoRN06


do materialRF Emitir relatório de despesas com descrição dos proble-

mas e valores para correção e entregar cópia ao clienteRF10


do materialRN Material com dano superior a 75% do valor do bem lo-

cado deverá ser substituído pelo clienteRN07


do materialRN

Negociações sobre prazos, valores, financiamento para

reposição de material danificado deve ser realizado pela

gerência

RN08


do materialRN Valores inferiores a R$ 100,00 não devem ser parcela-

dos.RN09


147




do materialRN

Registrar no cadastro do cliente o valor das despesas e

não permitir locação até a dívida ser quitada ou negoci-

ada e, neste último caso, a primeira parcela paga

RN10

T03 Tarefa: Realizar registro da

devoluçãoRF

Registrar no cadastro do cliente a devolução do material

locado: data da devolução, condição do material, despe-

sas relativas ao conserto

RF11

G01 Gateway: Atraso na devolu-

ção?RF Verificar atraso na devolução dos itens locados RF12

T04 Tarefa: Suspender cliente

por um mêsRF Suspender cliente por um mês, não permitindo novas lo-

caçõesRF13


por um mêsRN Registrar suspensão no cadastro do cliente RN11


por uma semanaRF Suspender cliente por uma semana, não permitindo no-

vas locaçõesRF14


por uma semanaRN Registrar suspensão no cadastro do cliente RN12

T06 Tarefa: Calcular multa RF Calcular multa considerando a diária de locação por dia

de atraso na devolução de cada item locadoRF15

T06 Tarefa: Calcular multa RF Registrar o valor da multa no cadastro do cliente RF16

T06 Tarefa: Calcular multa RF Emitir taxa de multa discriminando: item locado, tempo

de atraso, valor da diária e valor total da multaRF17

T06 Tarefa: Calcular multa RN Parcelamento do valor da multa deve ser autorizado pela

gerênciaRN13

T06 Tarefa: Calcular multa RN O valor mínimo da parcela da multa é de R$ 50,00 RN14

T06 Tarefa: Calcular multa RN Valores inferiores a R$ 100,00 não devem ser parcelados RN15

T07 Tarefa: Receber em Di-

nheiroRF Receber os valores devidos e fornecer troco, se necessá-

rioRF18

T08 Tarefa: Receber cheque RFReceber pagamento em cheque registrando informações

da folha: número do cheque, tempo de cliente, banco,

agência e conta

RF19

T08 Tarefa: Receber cheque RN Somente aceitar cheque no valor da locação, da praça e

em nome do clienteRN16

T09 Tarefa: Receber cartão cré-

ditoRF Receber pagamento com cartão de crédito RF20


ditoRN Aceitar somente as bandeiras especificadas pela gerên-

ciaRN17


148 Apêndice A. Relação de Requisitos Elicitados – Locação




ditoRN Parcelamentos no cartão de crédito em até 6 vezes RN18


ditoRF Permitir pagamento com mais de um cartão de crédito RF21


ditoRN Valores inferiores a R$ 100,00 não devem ser parcelados RN19

T10 Tarefa: Receber cartão dé-

bitoRF Receber pagamento com cartão de débito RF22

T10 Tarefa: Receber cartão dé-

bitoRF Permitir pagamento com mais de um cartão de débito RF23

T11 Tarefa: Registrar paga-

mentoRF Registrar pagamento no sistema financeiro para controle RF24


mentoRF Permitir recebimento de pagamento em várias formas RF25


mentoRF Emitir comprovante de pagamento (Nota fiscal) de

acordo com a legislaçãoRF26


mentoRN Utilizar informações do cadastro do cliente para emitir

nota fiscal: nome, CPF/CNPJ, telefone e endereçoRN20


mentoRNF Funcionário deve estar identificado com login e senha

para ser habilitado a receber pagamentosRNF10

149

B Arquétipo de Requisitos – Locação

Segue a relação completa dos requisitos armazenados no Arquétipo de Requisitos para

a LPN do domínio de Locação apresentada no Capítulo 5. Esta relação é o resultado da apli-

cação da tarefa Adaptar Requisitos para a Sintaxe Genérica, que adaptou os requisitos para a

sintaxe genérica proposta no Quadro 15 do Capítulo 4 e substituiu os valores variáveis pela tag

<<variável>>. Também foi executada a tarefa Eliminar Requisitos Duplicados, de modo que

estes foram eliminados da relação.

Tabela 15 – Arquétipo de Requisitos – Locação.


RF01 FuncionárioRealizar consulta no histórico do cli-

ente—

Visualizar pendências com a

empresa

RF02 FuncionárioAutorizar ou não a locação com

base no histórico do cliente—

Diminuir perdas com atrasos

ou não pagamentos

RF03 FuncionárioRealizar consulta em base de dados

externa (departamento de trânsito)—

Verificar pendências ou com-

portamentos de risco

RF04 FuncionárioRegistrar locação: cliente, material

locado, valor e data da locação—

Manter registro das locações

do cliente e controle de caixa

RF05 Funcionário

Emitir relação do material locado:

cliente, funcionário, material lo-

cado, valor e data da locação

—Favorecer a conferência do

material na devolução

RF06 Funcionário

Emitir comprovante de locação: cli-

ente, funcionário, material locado,

valor da locação, data da locação e

data da devolução

Uma via deve ser en-

tregue ao cliente

Favorecer a conferência na

devolução e comprovar a re-

tirada do material locado

RF07 FuncionárioGerar uma relação das devoluções

esperadas para o dia—

Checar as devoluções que fo-

rem realizadas

RF08 FuncionárioVerificar o estado do material lo-

cado

Verificar na presença

do cliente

Garantir a integridade e com-

pletude dos materiais locados

RF09 Funcionário

Emitir relatório de despesas com

descrição dos problemas e valores

para correção

Entregar uma cópia

ao cliente

Obter anuência do cliente

para os valores cobrados


150 Apêndice B. Arquétipo de Requisitos – Locação

Tabela 15 – Arquétipo de Requisitos – Locação – Continuação


RF10 Funcionário

Registrar a devolução do material

locado: cliente, data da devolução,

condição do material, despesas rela-

tivas ao conserto

—

Verificar cuidado do cliente

com materiais e oferecer pos-

síveis promoções para bons

clientes e tipificar o cliente

RF11 FuncionárioVerificar atrasos na devolução dos

itens locados—

Cobrar multa sobre itens de-

volvidos com atraso

RF12 FuncionárioSuspender cliente por um mês, não

autorizando novas locações—

Evitar perdas com atrasos

e/ou reincidências

RF13 FuncionárioSuspender cliente por uma semana,

não autorizando novas locações—


e/ou reincidências

RF14 Funcionário

Calcular a multa considerando a diá-

ria de locação por dia de atraso para

cada item locado

—

Evitar perdas por não realizar

novas locações com o item lo-

cado

RF15 FuncionárioRegistrar o valor da multa no sis-

tema financeiro—

Manter controle sobre histó-

rico de locação e tipificar o

cliente

RF16 Funcionário

Emitir taxa de multa discriminando:

item locado, tempo de atraso, valor

da diária e valor total da multa

— Garantir controle de caixa

RF17 FuncionárioReceber os valores devidos e forne-

cer troco, se necessário

Troco somente

para pagamento em

dinheiro

—

RF18 Funcionário

Receber pagamento em cheque, re-

gistrando informações: número do

cheque, banco, agência, conta, valor

e data para depósito

Valor do cheque deve

ser igual ao total a ser

pago

Criar controle sobre cheques

recebidos

RF19 FuncionárioReceber pagamento com cartão de

crédito— —

RF20 FuncionárioPermitir que o valor seja pago com

mais de um cartão de crédito—

Oferecer diferentes possibili-

dades de pagamento


débito— —

RF22 FuncionárioPermitir o pagamento utilizando

mais de um cartão de débito—


dades de pagamento

RF23 FuncionárioRegistrar pagamento no sistema fi-

nanceiro— Manter o controle financeiro


151



RF24 Funcionário

Permitir o pagamento do valor to-

tal utilizando várias formas de paga-

mento

Dentre as formas

autorizadas pela

empresa

Garantir recebimento dos va-

lores devidos

RF25 FuncionárioEmitir comprovante de pagamento

(nota fiscal)

Respeitando as nor-

mas fiscais vigentes

Garantir o pagamento da loca-

ção

RN01 Funcionário

Não autorizar locação de clientes

com débito, locação sem devolu-

ção, em suspensão ou com mais de

<<variável>> dias de atraso em

<<variável>> locações distintas

nos últimos <<variável>> meses

—Garantir critérios de locação

uniformes e objetivos

RN02 Funcionário

Não autorizar locação se cliente

com mais de duas multas como re-

sultado da consulta externa

— —

RN03 Funcionário

Cadastrar o cliente na primeira lo-

cação: nome, CPF/CNPJ, telefone e

endereço

—Agilizar futuras locações e

iniciar histórico de locações

RN04 Funcionário

Ligar para o cliente após

<<variável>> dia(s) de atraso na

devolução do material locado

—Evitar atrasos longos na devo-

lução

RN05 Funcionário

Informar cliente sobre os problemas

encontrados na devolução do mate-

rial locado

—Dar ciência ao cliente sobre

os problemas encontrados

RN06 Funcionário

Informar cliente que materiais com

dano superior a <<variável>>%

do valor do bem locado deverá ser

substituído pelo cliente

— —

RN07 Funcionário

Informar cliente que negociações

sobre prazos, valores e financia-

mento para reposição dematerial da-

nificado deve ser realizado pela ge-

rência

— —

RN08 Funcionário

Informar cliente que se o valor dos

danos nos materiais locados for in-

ferior a R$<<variável>>, o valor

deverá ser pago em uma única vez

—Evitar parcelamento com va-

lores muito baixos

RN09 Funcionário

Informar cliente que valores inferio-

res a R$<<variável>> não devem

ser parcelados

—Evitar parcelamento de valo-

res baixos


152 Apêndice B. Arquétipo de Requisitos – Locação



RN10 Funcionário

Registrar o valor das despesas e não

permitir locação pelo cliente até a

dívida ser quitada ou negociada e,

neste último caso, a primeira par-

cela paga

— —

RN11 FuncionárioRegistrar suspensão no cadastro do

cliente— Tipificar o cliente

RN12 Funcionário

Informar o cliente que o parcela-

mento do valor da multa deve ser au-

torizado pela gerência

— —

RN13 Funcionário

Informar cliente que o valor mí-

nimo da parcela da multa é de R$

<<variável>>

— —

RN14 Funcionário

Receber cheques somente no valor

da locação, da praça e em nome do

cliente

—Evitar problemas com des-

conto de cheques

RN15 Funcionário

Aceitar cartões de crédito apenas

das bandeiras especificadas pela ge-

rência

— —

RN16 Funcionário

Parcelar pagamentos no car-

tão de crédito em, no máximo,

<<variável>> vezes

— —

RN17 Funcionário

Utilizar informações do cadastro do

cliente para emitir nota fiscal: nome,

CPF/CNPJ, telefone e endereço

— —

RNF01 SistemaRetornar o resultado da consulta em

<<variável>> segundos— —

RNF02 SistemaExigir login e senha para acesso ao

histórico do cliente— Garantir controle seção única

RNF03 SistemaRealizar backup do banco de dados

a cada <<variável>>—

garantir a segurança dos da-

dos em caso de incidentes

RNF04 Sistema

Exigir identificação com login e se-

nha do funcionário para acesso a sis-

tema externo

—garantir seção de acesso

única

RNF05 Sistema

Retornar o resultado da consulta a

sistema externo em<<variável>>

segundos

— —


153



RNF06 Sistema


nha para habilitar o recebimento de

pagamento

—Garantir controle e seção

única

RNF07 SistemaManter histórico de acessos a sis-

tema externo no log

Registrar funcionário

e consulta realizadaGarantir auditoria

155

C Matriz de Rastreabilidade da LPN – Loca-ção

Segue a Matriz de Rastreabilidade da LPN para o Arquétipo de Requisitos apresentado

no Apêndice B e relacionada com a avaliação de aplicação detalhada no Capítulo 5.

Tabela 16 –Matriz de Rastreabilidade da LPN – Locação.

Elementos da LPN

IDr SP1 SP2 E01 G01 T01 T02 T03 T04 T05 T06 T07 T08 T09 T10 T11

RF01 X X

RF02 X

RF03 X

RF04 X

RF05 X

RF06 X

RF07 X

RF08 X

RF09 X

RF10 X

RF11 X

RF12 X

RF13 X

RF14 X

RF15 X

RF16 X

RF17 X

RF18 X

RF19 X

RF20 X

RF21 X

RF22 X

RF23 X


156 Apêndice C. Matriz de Rastreabilidade da LPN – Locação

Tabela 16 –Matriz de Rastreabilidade da LPN – Locação – Continuação

Elementos da LPN

IDr SP1 SP2 E01 G01 T01 T02 T03 T04 T05 T06 T07 T08 T09 T10 T11

RF24 X

RF25 X

RN01 X X

RN02 X

RN03 X

RN04 X

RN05 X

RN06 X

RN07 X

RN08 X

RN09 X X X

RN10 X

RN11 X X

RN12 X

RN13 X

RN14 X

RN15 X

RN16 X

RN17 X

RNF01 X X

RNF02 X X

RNF03 X X

RNF04 X

RNF05 X

RNF06 X

RNF07 X

157

D Requisitos da Instância – Locação

Segue a relação completa dos requisitos constantes nos Requisitos da instância, por oca-

sião de sua criação, para a instância da LPN do domínio de Locação apresentada no Capítulo 5.

Tabela 17 – Requisitos da instância – Locação.



ente—


empresa




ou não pagamentos




no cadastro do cliente e con-

trole de caixa

RF04 Funcionário






RF05 Funcionário




data da devolução


tregue ao cliente







rem realizadas


cado


do cliente

garantir a integridade e com-


RF08 Funcionário



para correção

Entregar uma cópia

ao cliente



RF09 Funcionário




tivas ao conserto

—






itens locados—


volvidos com atraso




e/ou reincidências


158 Apêndice D. Requisitos da Instância – Locação

Tabela 17 – Requisitos da instância – Continuação


RF12 Funcionário



cada item locado

—



cado


tema financeiro—



cliente

RF14 Funcionário







Troco somente

para pagamento em

dinheiro

—


crédito— —




dades de pagamento


débito— —




dades de pagamento



RF21 Funcionário



mento

Dentre as formas

autorizadas pela

empresa


lores devidos


(nota fiscal)

Respeitando as nor-



ção

RN01 Funcionário


com débito, locação sem devolu-

ção, em suspensão ou com mais de

<<variável>> dias de atraso em

<<variável>> locações distintas

nos últimos <<variável>> meses



RN02 Funcionário



endereço




159



RN03 Funcionário

Ligar para o cliente após

<<variável>> dia(s) de atraso na

devolução do material locado


lução

RN04 Funcionário



rial locado



RN05 Funcionário


dano superior a <<variável>>%

do valor do bem locado deverá ser

substituído pelo cliente

— —

RN06 Funcionário





rência

— —

RN07 Funcionário


res a R$<<variável>> não devem

ser parcelados


res baixos

RN08 Funcionário





cela paga

— —



RN10 Funcionário




— —

RN11 Funcionário

Informar cliente que o valor mí-

nimo da parcela da multa é de R$

<<variável>>

— —

RN12 Funcionário



rência

— —

RN13 Funcionário

Parcelar pagamentos no car-

tão de crédito em, no máximo,

<<variável>> vezes

— —


160 Apêndice D. Requisitos da Instância – Locação



RN14 Funcionário




— —


<<variável>> segundos— —




a cada <<variável>>—



RNF04 Sistema



pagamento


única

161

E Matriz da Instância – Locação

Segue o artefatoMatriz da instância, por ocasião de sua criação, para a instância da LPN

do domínio de Locação apresentada no Capítulo 5.

Tabela 18 –Matriz da instância – Locação.

Elementos da Instância

IDr SP1 E01 G01 T01 T02 T03 T04 T05 T06 T07 T08 T09

RF01 X

RF02 X

RF03 X

RF04 X

RF05 X

RF06 X

RF07 X

RF08 X

RF09 X

RF10 X

RF11 X

RF12 X

RF13 X

RF14 X

RF15 X

RF16 X

RF17 X

RF18 X

RF19 X

RF20 X

RF21 X

RF22 X

RN01 X

RN02 X

RN03 X


162 Apêndice E. Matriz da Instância – Locação

Tabela 18 –Matriz da Instância – Locação – Continuação



RN04 X

RN05 X

RN06 X

RN07 X X X

RN08 X

RN09 X

RN10 X

RN11 X

RN12 X

RN13 X

RN14 X

RNF01 X

RNF02 X

RNF03 X

RNF04 X

163

F Requisitos da Instância Atualizados

Segue a relação completa dos requisitos constantes nos Requisitos da instância depois da

execução das atividades Verificar Pontos de Variação, Configurar Variáveis e da tarefa Refinar

Requisitos, para a instância da LPN do domínio de Locação apresentada no Capítulo 5.

Tabela 19 – Requisitos da instância – Locação – Atualizado.



ente—


empresa




ou não pagamentos




no cadastro do cliente e con-

trole de caixa

RF04 Funcionário






RF05 Funcionário




data da devolução


tregue ao cliente







rem realizadas


cado


do cliente

garantir a integridade e com-


RF08 Funcionário



para correção

Entregar uma cópia

ao cliente



RF09 Funcionário




tivas ao conserto

—






itens locados—


volvidos com atraso




e/ou reincidências


164 Apêndice F. Requisitos da Instância Atualizados

Tabela 19 – Requisitos da instância (Atualizado) – Continuação


RF12 Funcionário



cada item locado

—



cado


tema financeiro—



cliente

RF14 Funcionário







Troco somente

para pagamento em

dinheiro

—


crédito— —




dades de pagamento


débito— —




dades de pagamento



RF21 Funcionário



mento

Dentre as formas

autorizadas pela

empresa


lores devidos


(nota fiscal)

Respeitando as nor-



ção

RF23 Sistema

Cadastrar como opções para receber

pagamento: Receber em dinheiro,

cartão de crédito e cartão de débito

—Oferecer opções de paga-

mento

RF24 Sistema

Exibir como opção para receber pa-

gamento: Receber em dinheiro, car-

tão de crédito e cartão de débito


mento

RF25 Sistema

Permitir selecionar como opção

para receber pagamento: Receber

em dinheiro, cartão de crédito e car-

tão de débito


mento


165



RF26 FuncionárioOferecer seguro contra perda ou

dano

Valor de 5% da loca-

ção

Evitar prejuízo commateriais

danificados ou perdidos

RN01 Funcionário


com débito, locação sem devolução,

em suspensão ou commais de 5 dias

de atraso em 3 locações distintas nos

últimos 12 meses



RN02 Funcionário



endereço



RN03 Funcionário

Ligar para o cliente após 1 dia de

atraso na devolução do material lo-

cado


lução

RN04 Funcionário



rial locado



RN05 Funcionário


dano superior a 80% do valor do

bem locado deverá ser substituído

pelo cliente

— —

RN06 Funcionário





rência

— —

RN07 Funcionário


res a R$ 50,00 para multas ou despe-

sas com danos não devem ser parce-

lados


res baixos

RN08 Funcionário


res a R$ 100,00 para o total da loca-

ção não devem ser parcelados


res baixos

RN09 Funcionário





cela paga

— —




166 Apêndice F. Requisitos da Instância Atualizados



RN11 Funcionário




— —

RN12 FuncionárioInformar cliente que o valor mínimo

da parcela da multa é de R$ 30,00— —

RN13 Funcionário



rência

— —

RN14 Funcionário




— —


5 segundos— —




a cada dia—



RNF04 Sistema



pagamento


única

167

G Matriz da Instância Atualizada

Segue aMatriz da instância depois da execução das atividades Verificar Pontos de Vari-

ação, Configurar Variáveis e da tarefa Refinar Requisitos, para a instância da LPN do domínio

de Locação apresentada no Capítulo 5.

Tabela 20 –Matriz da instância – Atualizada – Locação.



RF01 X

RF02 X

RF03 X

RF04 X

RF05 X

RF06 X

RF07 X

RF08 X

RF09 X

RF10 X

RF11 X

RF12 X

RF13 X

RF14 X

RF15 X

RF16 X

RF17 X

RF18 X

RF19 X

RF20 X

RF21 X

RF22 X

RF23 X X X

RF24 X X X


168 Apêndice G. Matriz da Instância Atualizada

Tabela 20 –Matriz da Instância (Atualizada) – Locação – Continuação



RF25 X X X

RF26 X

RN01 X

RN02 X

RN03 X

RN04 X

RN05 X

RN06 X

RN07 X X

RN08 X

RN09 X

RN10 X

RN11 X

RN12 X

RN13 X

RN14 X

RNF01 X

RNF02 X

RNF03 X

RNF04 X

169

H Modelo de Requisitos – Estórias de Usuá-rio

Segue a relação completa dos Requisitos Especificados no formato de estórias de usuário

para a instância da LPN do domínio de Locação apresentada no Capítulo 5, utilizando como base

a estrutura sintática do Quadro 23.

Tabela 21 –Modelo de Requisitos – Estória de Usuário.


RF01 Como um funcionário eu quero realizar consulta no histórico do cliente, a fim de visualizar

pendências com a empresa.

RF02 Como um funcionário eu quero autorizar ou não a locação com base no histórico do cliente, a

fim de diminuir perdas com atrasos ou não pagamentos.

RF03 Como um funcionário eu quero registrar locação: cliente, material locado, valor e data da loca-

ção, a fim de manter registro das locações no cadastro do cliente e controle de caixa.

RF04 Como um funcionário eu quero emitir relação do material locado: cliente, funcionário, material

locado, valor e data da locação, a fim de favorecer a conferência do material na devolução.

RF05

Como um funcionário eu quero emitir comprovante de locação: cliente, funcionário, material

locado, valor da locação, data da locação e data da devolução, com a restrição de uma via deve

ser entregue ao cliente, a fim de favorecer a conferência na devolução e comprovar a retirada do

material locado.

RF06 Como um funcionário eu quero gerar uma relação de devoluções esperadas para o dia, a fim de

checar as devoluções que foram realizadas.

RF07 Como um funcionário eu quero verificar o estado domaterial locado, com a restrição de verificar

na presença do cliente, a fim de garantir a integridade e completude dos materiais locados.

RF08Como um funcionário eu quero emitir relatório de despesas com descrição dos problemas e

valores para correção, com a restrição de entregar uma cópia ao cliente, a fim de obter anuência

do cliente para os valores cobrados.

RF09Como um funcionário eu quero registrar a devolução do material locado: cliente, data da devo-

lução, condição do material, despesas relativas a consertos, a fim de verificar cuidado do cliente

com materiais e oferecer possíveis promoções para bons cliente e tipificar o cliente.

RF10 Como um funcionário eu quero verificar atrasos na devolução dos itens locados, a fim de cobrar

multas sobre os itens devolvidos com atraso.

RF11 Como um funcionário eu quero suspender cliente por uma semana, não autorizando novas loca-

ções, a fim de evitar perda com atrasos e/ou reincidências.


170 Apêndice H. Modelo de Requisitos – Estórias de Usuário

Tabela 21 –Modelo de Requisitos – Estória de Usuário – Continuação


RF12Como um funcionário eu quero calcular a multa considerando a diária de locação por dia de

atraso para cada item locado, a fim de evitar perdas por não realizar novas locações com o item

locado.

RF13 Como um funcionário eu quero registrar o valor da multa no sistema financeiro, a fim de manter

controle sobre histórico de locação e tipificar o cliente.

RF14 Como um funcionário eu quero emitir taxa demulta discriminando: item locado, tempo de atraso,

valor da diária e valor total da multa, a fim de garantir controle de caixa.

RF15 Como um funcionário eu quero receber os valores devidos e fornecer troco, se necessário, com

a restrição de troco somente para pagamento em dinheiro.

RF16 Como um funcionário eu quero receber pagamento com cartão de crédito.

RF17 Como um funcionário eu quero permitir que o valor seja pago commais de um cartão de crédito,

a fim de oferecer diferentes possibilidades de pagamento.

RF18 Como um funcionário eu quero receber pagamento com cartão de débito.

RF19 Como um funcionário eu quero permitir o pagamento utilizando mais de um cartão de débito, a

fim de oferecer diferentes possibilidades de pagamento.

RF20 Como um funcionário eu quero registrar pagamento no sistema financeiro, a fim de manter o

controle financeiro.

RF21Como um funcionário eu quero permitir o pagamento do valor total utilizando várias formas

de pagamento, com a restrição de escolher dentre as formas autorizadas pela empresa, a fim de

garantir recebimento dos valores devidos.

RF22 Como um funcionário eu quero emitir comprovante de pagamento (nota fiscal), com a restrição

de respeitar as normas fiscais vigentes, a fim de garantir o pagamento da locação.

RF23 Como um sistema eu quero cadastrar como opções para receber pagamento: receber em dinheiro,

cartão de crédito e cartão de débito, a fim de oferecer várias opções de pagamento.

RF24 Como um sistema eu quero exibir como opção para receber pagamento: receber em dinheiro,

catão de crédito e cartão de débito, a fim de oferecer opções de pagamento.

RF25 Como um sistema eu quero permitir selecionar como opção para receber pagamento: receber em

dinheiro, cartão de crédito e cartão de débito, a fim de oferecer opções de pagamento.

RF26 Como um funcionário eu quero oferecer seguro contra perda ou dano, com a restrição de ser de

5% sobre o valor da locação, a fim de evitar prejuízos com materiais danificados ou perdidos.

RN01O funcionário deve não autorizar locação de clientes com débito, locação sem devolução, em

suspensão ou com mais de 5 dias de atraso em 3 locações distintas nos últimos 12 meses, a fim

de garantir critérios de locação uniformes e objetivos.

RN02 O funcionário deve cadastrar o cliente na primeira locação: nome, CPF/CNPJ, telefone e ende-

reço, a fim de agilizar futuras locações e iniciar histórico de locações.

RN03 O funcionário deve ligar para o cliente após 1 dia de atraso na devolução do material locado, a

fim de evitar atrasos longos na devolução.


171

Tabela 21 –Modelo de Requisitos – Estória de Usuário – Continuação


RN04 O funcionário deve informar o cliente sobre os problemas encontrados na devolução do material

locado, a fim de dar ciência ao cliente sobre os problemas encontrados.

RN05 O funcionário deve informar cliente que materiais com dano superior a 80% do valor do bem

deverão ser substituídos pelo cliente.

RN06 O funcionário deve informar cliente que negociações sobre prazos, valores e financiamento para

reposição de material danificado deve ser realizado pela gerência.

RN07 O funcionário deve informar cliente que valores inferiores a R$ 50,00 para multas ou despesas

com danos não devem ser parcelados, a fim de evitar parcelamento de valores baixos.

RN08 O funcionário deve informar cliente que valores inferiores a R$ 100,00 para o total da locação

não devem ser parcelados, a fim de evitar parcelamento de valores baixos.

RN09 O funcionário deve registrar o valor das despesas e não permitir locação pelo cliente até a dívida

ser quitada ou negociada e, neste último caso, a primeira parcela paga.

RN10 O funcionário deve registrar suspensão no cadastro do cliente, a fim de tipificar o cliente.

RN11 O funcionário deve informar o cliente que o parcelamento do valor da multa deve ser autorizado

pela gerência.

RN12 O funcionário deve informar cliente que o valor mínimo da parcela da multa é de R% 30,00.

RN13 O funcionário deve aceitar cartões de crédito apenas das bandeiras especificadas pela gerência.

RN14 O funcionário deve utilizar informações do cadastro do cliente para emitir a nota fiscal: nome,

cpf/cnpj, telefone e endereço.


RNF02 O sistema deve exigir login e senha para acesso ao histórico do cliente, a fim de garantir controle

e seção única.

RNF03 O sistema deve realizar backup do banco de dados a cada dia, a fim de garantir a segurança dos

dados em caso de incidentes.

RNF04 O sistema deve exigir identificação com login e senha para habilitar o recebimento de pagamen-

tos, a fim de garantir controle e seção única.

173

I Modelo de Requisitos – Documento de Re-quisitos

Segue a relação completa dos Requisitos Especificados no formato de documento de

requisitos (ISO, 2011) para a instância da LPN do domínio de Locação apresentada no Capítulo 5

usando como base a estrutura sintática do Quadro 24.

Tabela 22 –Modelo de Requisitos – Documento de Requisitos.

Documento de Requisitos

ID Seção 1 – Atores

1.1 Funcionário: empregado da loja, responsável por registrar as locações, verificar os materiais na

devolução e receber pagamentos.

1.2 Gerente: responsável administrativo e encarregado de autorizar parcelamentos.

1.3 Cliente: usuário dos recursos disponíveis para locação na loja.

1.4 Sistema: entidade que armazena os dados e registra as locações, pagamentos e devoluções.

IDr Seção 2 – Requisitos Funcionais

RF01 O funcionário deve realizar consulta no histórico do cliente, a fim de visualizar pendências com

a empresa.

RF02 O funcionário deve autorizar ou não a locação com base no histórico do cliente, a fim de diminuir

perdas com atrasos ou não pagamentos.

RF03 O funcionário deve registrar locação: cliente, material locado, valor e data da locação, a fim de

manter registro das locações no cadastro do cliente e controle de caixa.

RF04 O funcionário deve emitir relação domaterial locado: cliente, funcionário, material locado, valor

e data da locação, a fim de favorecer a conferência do material na devolução.

RF05O funcionário deve emitir comprovante de locação: cliente, funcionário, material locado, valor

da locação, data da locação e data da devolução, a fim de favorecer a conferência na devolução

e comprovar a retirada do material locado. Restrição: uma via deve ser entregue ao cliente.

RF06 O funcionário deve gerar uma relação de devoluções esperadas para o dia, a fim de checar as

devoluções que foram realizadas.

RF07 O funcionário deve verificar o estado do material locado, a fim de garantir a integridade e com-

pletude dos materiais locados. Restrição: verificar na presença do cliente.

RF08O funcionário deve emitir relatório de despesas com descrição dos problemas e valores para

correção, a fim de obter anuência do cliente para os valores cobrados. Restrição: entregar uma

cópia ao cliente,


174 Apêndice I. Modelo de Requisitos – Documento de Requisitos

Tabela 22 –Modelo de Requisitos – Documento de Requisitos – Continuação


RF09O funcionário deve registrar a devolução do material locado: cliente, data da devolução, con-

dição do material, despesas relativas a consertos, a fim de verificar cuidado do cliente com

materiais e oferecer possíveis promoções para bons cliente e tipificar o cliente.

RF10 O funcionário deve verificar atrasos na devolução dos itens locados, a fim de cobrar multas sobre

os itens devolvidos com atraso.

RF11 O funcionário deve suspender cliente por uma semana, não autorizando novas locações, a fim

de evitar perda com atrasos e/ou reincidências.

RF12 O funcionário deve calcular a multa considerando a diária de locação por dia de atraso para cada

item locado, a fim de evitar perdas por não realizar novas locações com o item locado.

RF13 O funcionário deve registrar o valor da multa no sistema financeiro, a fim de manter controle

sobre histórico de locação e tipificar o cliente.

RF14 O funcionário deve emitir taxa de multa discriminando: item locado, tempo de atraso, valor da

diária e valor total da multa, a fim de garantir controle de caixa.

RF15 O funcionário deve receber os valores devidos e fornecer troco, se necessário. Restrição: troco

somente para pagamento em dinheiro.

RF16 O funcionário deve receber pagamento com cartão de crédito.

RF17 O funcionário deve permitir que o valor seja pago com mais de um cartão de crédito, a fim de

oferecer diferentes possibilidades de pagamento.

RF18 O funcionário deve receber pagamento com cartão de débito.

RF19 O funcionário deve permitir o pagamento utilizando mais de um cartão de débito, a fim de

oferecer diferentes possibilidades de pagamento.

RF20 O funcionário deve registrar pagamento no sistema financeiro, a fim de manter o controle finan-

ceiro.

RF21O funcionário deve permitir o pagamento do valor total utilizando várias formas de pagamento,

a fim de garantir recebimento dos valores devidos. Restrição: escolher dentre as formas autori-

zadas pela empresa.

RF22 O funcionário deve emitir comprovante de pagamento (nota fiscal), a fim de garantir o paga-

mento da locação. Restrição: respeitar as normas fiscais vigentes.

RF23 O sistema deve cadastrar como opções para receber pagamento: receber em dinheiro, cartão de

crédito e cartão de débito, a fim de oferecer várias opções de pagamento.

RF24 O sistema deve exibir como opção para receber pagamento: receber em dinheiro, catão de crédito

e cartão de débito, a fim de oferecer opções de pagamento.

RF25 O sistema deve permitir selecionar como opção para receber pagamento: receber em dinheiro,

cartão de crédito e cartão de débito, a fim de oferecer opções de pagamento.

RF26 O funcionário deve oferecer seguro contra perda ou dano, a fim de evitar prejuízos commateriais

danificados ou perdidos. Restrição: ser de 5% sobre o valor da locação.

IDr Seção 3 – Requisitos Não Funcionais


175

Tabela 22 –Modelo de Requisitos – Documento de Requisitos – Continuação



RNF02 O sistema deve exigir login e senha para acesso ao histórico do cliente, a fim de garantir controle

e seção única.

RNF03 O sistema deve realizar backup do banco de dados a cada dia, a fim de garantir a segurança dos

dados em caso de incidentes.

RNF04 O sistema deve exigir identificação com login e senha para habilitar o recebimento de pagamen-

tos, a fim de garantir controle e seção única.

IDr Seção 4 – Regras de Negócio

RN01O funcionário deve não autorizar locação de clientes com débito, locação sem devolução, em

suspensão ou com mais de 5 dias de atraso em 3 locações distintas nos últimos 12 meses, a fim

de garantir critérios de locação uniformes e objetivos.

RN02 O funcionário deve cadastrar o cliente na primeira locação: nome, CPF/CNPJ, telefone e ende-

reço, a fim de agilizar futuras locações e iniciar histórico de locações.

RN03 O funcionário deve ligar para o cliente após 1 dia de atraso na devolução do material locado, a

fim de evitar atrasos longos na devolução.

RN04 O funcionário deve informar o cliente sobre os problemas encontrados na devolução do material

locado, a fim de dar ciência ao cliente sobre os problemas encontrados.

RN05 O funcionário deve informar cliente que materiais com dano superior a 80% do valor do bem

deverão ser substituídos pelo cliente.

RN06 O funcionário deve informar cliente que negociações sobre prazos, valores e financiamento para

reposição de material danificado deve ser realizado pela gerência.

RN07 O funcionário deve informar cliente que valores inferiores a R$ 50,00 para multas ou despesas

com danos não devem ser parcelados, a fim de evitar parcelamento de valores baixos.

RN08 O funcionário deve informar cliente que valores inferiores a R$ 100,00 para o total da locação

não devem ser parcelados, a fim de evitar parcelamento de valores baixos.

RN09 O funcionário deve registrar o valor das despesas e não permitir locação pelo cliente até a dívida

ser quitada ou negociada e, neste último caso, a primeira parcela paga.

RN10 O funcionário deve registrar suspensão no cadastro do cliente, a fim de tipificar o cliente.

RN11 O funcionário deve informar o cliente que o parcelamento do valor da multa deve ser autorizado

pela gerência.

RN12 O funcionário deve informar cliente que o valor mínimo da parcela da multa é de R% 30,00.

RN13 O funcionário deve aceitar cartões de crédito apenas das bandeiras especificadas pela gerência.

RN14 O funcionário deve utilizar informações do cadastro do cliente para emitir a nota fiscal: nome,

cpf/cnpj, telefone e endereço.

177

J Matriz de Rastreabilidade

Segue aMatriz de Rastreabilidade para a instância da LPN do domínio de Locação apre-

sentada no Capítulo 5.

Tabela 23 –Matriz de Rastreabilidade.



RF01 X

RF02 X

RF03 X

RF04 X

RF05 X

RF06 X

RF07 X

RF08 X

RF09 X

RF10 X

RF11 X

RF12 X

RF13 X

RF14 X

RF15 X

RF16 X

RF17 X

RF18 X

RF19 X

RF20 X

RF21 X

RF22 X

RF23 X X X

RF24 X X X

RF25 X X X


178 Apêndice J. Matriz de Rastreabilidade

Tabela 23 –Matriz de Rastreabilidade – Continuação



RF26 X

RN01 X

RN02 X

RN03 X

RN04 X

RN05 X

RN06 X

RN07 X X

RN08 X

RN09 X

RN10 X

RN11 X

RN12 X

RN13 X

RN14 X

RNF01 X

RNF02 X

RNF03 X

RNF04 X

Abordagem de Apoio ao Reúso de Requisitos em …...Abordagem de Apoio ao Reúso de Requisitos em...

Documents

Transcript of Abordagem de Apoio ao Reúso de Requisitos em …...Abordagem de Apoio ao Reúso de Requisitos em...