Uma linha de processo de software para elicitação de requisitos baseada na criatividade combinacional

Departamento de Informática e Matemática Aplicada Programa de Pós-Graduação em Sistemas e Computação

Mestrado Acadêmico em Sistemas e Computação

Uma Linha de Processo de Software para

Elicitação de Requisitos Baseada na

Criatividade Combinacional

Rafael de Morais Pinto

Uma Linha de Processo de Software para Elicitação de

Requisitos Baseada na Criatividade Combinacional

Dissertação de Mestrado apresentada ao Pro-grama de Pós-Graduação em Sistemas e Computação do Departamento de Informá-tica e MatemáInformá-tica Aplicada da Universidade Federal do Rio Grande do Norte como re-quisito parcial para a obtenção do título de Mestre em Sistemas e Computação.

Linha de pesquisa: Engenharia de Software

Orientadora

Profa. Dra. Marcia Jacyntha Nunes Rodrigues Lucena

Coorientadora

Profa. Dra. Lyrene Fernandes da Silva

PPgSC  Programa de Pós-Graduação em Sistemas e Computação DIMAp  Departamento de Informática e Matemática Aplicada

CCET  Centro de Ciências Exatas e da Terra UFRN  Universidade Federal do Rio Grande do Norte

Natal-RN Outubro de 2016

de Requisitos Baseada na Criatividade Combinacional apresentada por Rafael de Morais Pinto e aceita pelo Programa de Pós-Graduação em Sistemas e Computação do Departa-mento de Informática e Matemática Aplicada da Universidade Federal do Rio Grande do Norte, sendo aprovada por todos os membros da banca examinadora abaixo especicada:

Profa. Dra. Marcia Jacyntha Nunes Rodrigues Lucena

Presidente

DIMAp  Departamento de Informática e Matemática Aplicada UFRN  Universidade Federal do Rio Grande do Norte

Profa. Dra. Lyrene Fernandes da Silva

Examinadora

DIMAp  Departamento de Informática e Matemática Aplicada UFRN  Universidade Federal do Rio Grande do Norte

Prof. Dr. Fernando Marques Figueira Filho

Examinador

DIMAp  Departamento de Informática e Matemática Aplicada UFRN  Universidade Federal do Rio Grande do Norte

Prof. Dr. Fellipe Araújo Aleixo

Examinador

DIATINF  Diretoria Acadêmica de Gestão e Tec. da Informação CNAT  Campus Natal Central

IFRN  Instituto Federal do Rio Grande do Norte

Prof. Dr. Denis Silva da Silveira

Examinador

DCA  Departamento de Ciências Administrativas CCSA  Centro de Ciências Sociais Aplicadas UFPE  Universidade Federal de Pernambuco

Catalogação da Publicação na Fonte. UFRN / SISBI / Biblioteca Setorial Especializada do Centro de Ciências Exatas e da Terra – CCET. Pinto, Rafael de Morais.

Uma linha de processo de software para elicitação de requisitos baseada na criatividade combinacional / Rafael de Morais Pinto. – Natal, RN, 2016. 87 f. : il.

Orientadora: Profa. Dra. Marcia Jacyntha Nunes Rodrigues Lucena. Coorientadora: Profa. Dra. Lyrene Fernandes da Silva.

Dissertação (Mestrado) – Universidade Federal do Rio Grande do Norte. Centro de Ciências Exatas e da Terra. Departamento de Informática e Matemática Aplicada. Programa de Pós-Graduação em Sistemas e Computação.

1. Engenharia de software – Dissertação. 2. Engenharia de requisitos – Dissertação. 3. Elicitação de requisitos – Dissertação. 4. Criatividade combinacional – Dissertação. 5. Linha de processo de software – Dissertação. I. Lucena, Marcia Jacyntha Nunes Rodrigues. II. Silva, Lyrene Fernandes da. III. Título.

e aos meus lhos Gabriel e Miguel, fonte inesgotável de amor.

Agradecimentos

Agradeço primeiramente a Deus, por ter traçado meu caminho, me dado muito mais do que pedi e ter me permitido concluir esta fase da minha vida.

À minha esposa, Talita, e meus lhos Gabriel e Miguel, onde encontro paz e harmonia, e são a razão da minha motivação para superar as diculdades.

Aos meus pais, Rubens e Gloriete, pelos ensinamentos, incentivos aos estudos em cada fase da minha vida, e por terem me moldado para chegar até aqui.

Aos meus irmãos, Daniel, Rubinho e Lu, pelo suporte dado a mim e minha família. À minha tia Bereka, pelo amor, vibração, dedicação, incentivo e por todo o acompa-nhamento durante esse período de pesquisa, sempre tentando ajudar e me manter moti-vado.

À minha tia Liene, pelo incondicional apoio à minha família, sempre estando disponível para ajudar.

À minha avó Marlene, que esteve sempre presente nos meus estudos, me apoiando nas minhas decisões e com sabedoria e amor me ensinando as coisas mais simples da vida.

À professora Márcia Lucena, pela oportunidade que me foi concedida ao me aceitar como orientando, pelos momentos de orientação e pelo aprendizado.

À professora Lyrene Fernandes, que me permitiu moldar este trabalho que foi iniciado na sua disciplina, pela atenção e paciência que dispôs para realização do mesmo.

Aos amigos da COSINF do IFRN que torceram e me acompanharam nessa jornada. Aos colegas de mestrado do LETS.

E a todos aqueles que, de forma direta ou indireta, contribuíram com o desenvolvi-mento deste trabalho.

Requisitos Baseada na Criatividade Combinacional

Resumo

A necessidade por inovação e valorização de soluções criativas têm impulsionado a enge-nharia de requisitos a investigar técnicas de criatividade para elicitar requisitos úteis e originais. Tais técnicas baseiam-se na composição de idéias (requisitos, palavras ou pro-blemas), geralmente vindas de fontes diversas e realizada em um processo que envolve papéis também diversos. No entanto, como identicar o núcleo comum e quais variações podem ser adaptadas ao contexto organizacional onde a técnica será usada? Esta disser-tação apresenta uma Linha de Processo de Software (LPrS) para elicidisser-tação de requisitos baseada na criatividade combinacional. Esta LPrS abstrai o núcleo comum e as variações encontradas em algumas técnicas de criatividade combinacional, com o objetivo de ajudar equipes de engenharia de requisitos a denirem a técnica combinacional de acordo com o contexto organizacional em questão. Para validar essa abordagem, discutimos como a LPrS atende às principais features dos trabalhos relacionados e como nossa LPrS genera-liza as especidades de 3 técnicas de criatividade combinacional que já foram utigenera-lizadas em estudos experimentais, produzindo resultados satisfatórios.

Palavras-chave: Engenharia de Requisitos, Elicitação de Requisitos, Criatividade Combi-nacional, Linha de Processo de Software.

Based on Combinational Creativity

Autor: Rafael de Morais Pinto Orientadora: Dra. Marcia Jacyntha Nunes Rodrigues Lucena Coorientadora: Dra. Lyrene Fernandes da Silva

Abstract

The need for innovation and appreciation of creative solutions has driven requirements engineering researchers to investigate creativity techniques to elicit useful and unique re-quirements. Such techniques are based on the combination of ideas (requirements, words or problems) that generally come from dierent sources and are carried out in a process that involves dierent roles. However, how can we identify the common core and which variations can be adapted to the organizational context where the technique will be used? This article presents a Software Process Line (SPrL) to elicit requirements based on com-binational creativity. This SPrL represents commonalities and variabilities found in some combinational creativity techniques thereby it helps teams to dene the combinational technique according their organizational context. We validate this approach by discussing how the SPrL complies with the related works' major features and how it generalizes three techniques that have already been used in experimental studies, producing satisfactory results.

Keywords: Requirements Engineering, Requirements Elicitation, Combinational Creati-vity, Software Process Line.

Lista de Figuras

1 Exemplo de como a criatividade pode ser classicada. . . p. 20 2 Exemplo de processo para atualização de software. . . p. 28 3 Notação utilizada em diagramas de features. . . p. 30 4 Exemplo de modelo de features para o processo de atualização de software. p. 31 5 Processo para elicitação de requisitos baseado na criatividade

combina-cional. . . p. 33 6 Diagrama de features utilizadas no processo proposto. . . p. 34 7 Variações da tarefa Denir Fontes de Elementos. . . p. 35 8 Variações da tarefa Selecionar Elementos. . . p. 37 9 Variações da tarefa Denir Critérios para Elaboração de Requisitos. . . p. 38 10 Variações da tarefa Criar Novos Requisitos. . . p. 40 11 Variações da tarefa Validar Requisitos. . . p. 41 12 Variações da tarefa Aperfeiçoar Requisitos. . . p. 43 13 Exemplo de instância da LPrS proposta. . . p. 44 14 Features selecionadas para criação de uma nova instância da LPrS. . . p. 45 15 Interface da ferramenta Ideasy para que o stakeholder visualize as

pa-lavras geradas em formato de lista. . . p. 46 16 Interface da ferramenta Ideasy para que o stakeholder visualize as

pa-lavras geradas em formato de nuvem. . . p. 46 17 Interface da ferramenta Ideasy onde o EngR processa a fonte de

elemen-tos textuais. . . p. 48 18 Interface da ferramenta Ideasy onde o EngR Analisa e Valida as Palavras

com sua proposta de novos requisitos. . . p. 50 20 Interface da ferramenta Ideasy onde o Stakeholder avalia as propostas

de novos requisitos dos demais participantes. . . p. 51 21 LPrS em contraste com a abordagem proposta em (BHOWMIK et al., 2014). p. 54

Lista de Tabelas

1 Análise da classicação morfossintática de sentenças distintas com

pala-vras idênticas. . . p. 27 2 Escala de pontuação dos requisitos quanto a originalidade e utilidade. . p. 42 3 Exemplo de customização de atividades do processo, decorrentes da

es-colha de features. . . p. 44 4 Comparação entre atividades da LPrS e o framework de Bhowmik. . . . p. 55 5 Resumo da classicação dos requisitos. . . p. 57 6 Comparação entre atividades da LPrS e a abordagem utilizada por Pinto,

R. no experimento do SIGAA. . . p. 58 7 Resultados do experimento realizado com o SUAP-EDU. . . p. 62 8 Comparação entre atividades da LPrS e a abordagem utilizada por Pinto,

R. no experimento do SUAP-EDU. . . p. 64 9 Comparação entre variabilidades utilizadas nas abordagens analisadas

utilizando criatividade combinacional. . . p. 66 10 Características da LPrS segundo a taxonomia proposta por (BATISTA;

CARVALHO, 2003) . . . p. 73

11 Comparação das variabilidades identicadas nos trabalhos relacionados

Lista de Abreviaturas e Siglas

Engenharia de Requisitos (ER) Engenheiro de Requisitos (EngR) Linha de Processo de Software (LPrS) Design Thinking (DT)

Processamento de Linguagem Natural (PLN) Business Process Modelling Notation (BPMN) Exame Nacional do Ensino Médio (Enem)

Sumário

1 Introdução p. 14

1.1 Problema . . . p. 16 1.2 Objetivos Gerais e Especícos . . . p. 17 1.3 Organização do Trabalho . . . p. 17

2 Fundamentação Teórica p. 19

2.1 Estratégias para Elicitação de Requisitos Criativos . . . p. 19 2.1.1 Técnicas de Elicitação Baseadas em Criatividade . . . p. 21 2.1.2 Técnicas de Elicitação Baseadas em Criatividade Combinacional p. 24 2.2 Linha de Processos de Software . . . p. 27 3 Um Modelo Conceitual para Elicitação de Requisitos Baseado na

Criatividade Combinacional p. 32

3.1 Modelo Proposto . . . p. 32 3.1.1 Denir Fontes de Elementos . . . p. 34 3.1.2 Selecionar Elementos . . . p. 36 3.1.3 Denir Critérios para Elaboração de Requisitos . . . p. 38 3.1.4 Criar Novos Requisitos . . . p. 39 3.1.5 Validar Requisitos . . . p. 40 3.1.6 Aperfeiçoar Requisitos . . . p. 42 3.1.7 Instanciando a LPrS Proposta . . . p. 43 3.2 Ideasy - Uma Ferramenta de Apoio a Abordagem Proposta . . . p. 45 3.2.1 Criando um Novo Projeto . . . p. 46

3.2.3 Processando a Fonte de Elementos Textual . . . p. 47 3.2.4 Analisando e Validando as Palavras Geradas . . . p. 48 3.2.5 Criando Novos Requisitos . . . p. 49 3.2.6 Avaliando os Requisitos Criados . . . p. 50

4 Validação da Abordagem p. 52

4.1 Framework Proposto por Bhowmik, T. e outros (2014) Aplicado ao

Fi-refox e Mylyn . . . p. 52 4.2 Abordagem Proposta por Pinto, R. e outros (2015) Aplicada ao Sistema

Sigaa . . . p. 55 4.3 Abordagem Proposta por Pinto, R. e outros (2015) Aplicada ao Sistema

SUAP . . . p. 59 4.4 Discussão . . . p. 64 5 Conclusão p. 68 5.1 Contribuições . . . p. 68 5.2 Trabalhos Relacionados . . . p. 69 5.3 Trabalhos Futuros . . . p. 75 Referências p. 77

1 Introdução

A cada dia a indústria de desenvolvimento de software tem evoluído e se tornado mais competitiva tentando trazer produtos únicos (originais) e úteis. A m de se sustentar, um sistema de software precisa distinguir-se de outros produtos semelhantes e, de forma consistente, encantar os clientes com características novas e úteis. Como resultado, os engenheiros de requisitos precisam criar requisitos inovadores, a m de equipar o software com vantagem competitiva (BHOWMIK et al., 2014).

A Engenharia de Requisitos (ER) é o processo de descobrir o propósito de um sistema, através da identicação das partes interessadas (stakeholders) e suas necessidades, e do-cumentar estas informações de uma maneira passível de análise, comunicação e posterior implementação (NUSEIBEH; EASTERBROOK, 2000). No entanto, stakeholders, em algumas situações, não identicam como melhorar seus produtos ou como torná-los competitivos. Esta identicação é ainda mais difícil quando se trata de um novo produto ou de um mer-cado desconhecido (SAHA et al., 2012). Além disso, encontrar os requisitos corretos não é

simplesmente extrair requisitos dos stakeholders. Mais do que isso, signica ajudá-los a descobrir exigências que eles não estavam cientes e resolver problemas que eles não sabiam que tinham (HORKOFF; MAIDEN, 2015).

Assim, a criatividade pode ser considerada como um fator de sucesso para as organi-zações e indústrias. Especialmente na indústria de software, a criatividade na engenharia de requisitos pode ser reconhecida por proporcionar melhoria e inovação, durante o de-senvolvimento de sistemas de software (SAHA et al., 2012).

A criatividade pode ser denida como a habilidade em produzir algo inovador (original e inesperado) e apropriado (útil e adaptável para as atividades requeridas) (STERNBERG,

1999). No contexto da Engenharia de Requisitos, Maiden e outros (MAIDEN et al., 2010)

adotam esta denição de que requisitos criativos são inovadores e apropriados, e destacam a importância estratégica da criatividade e inovação para o desenvolvimento de software. Em nosso trabalho, também usamos esta denição para requisitos criativos.

Há diversas abordagens para estimular o pensamento criativo durante o processo de elicitação de requisitos, cujo objetivo é desenvolver produtos inovadores. Dentre estas abordagens podemos citar: (i) a realização de workshops de requisitos para incentivar o pensamento criativo durante a elicitação (MAIDEN; GIZIKIS; ROBERTSON, 2004), (ii)

téc-nicas com forte apoio da psicologia, tal qual a EPM Create proposta por Mich e outros (MICH; ANESI; BERRY, 2005), (iii) elicitação baseada na colaboração integrada entre

tec-nólogos e usuários (YANG-TURNER; LAU, 2011), (iv) uso de Design Thinking (VETTERLI et al., 2013) e (v) abordagens utilizando combinação de palavras para criação de novos

requisitos (BHOWMIK et al., 2014; PINTO et al., 2015). Tais técnicas podem promover o

entendimento das expectativas implícitas do cliente ou auxiliar na criação de requisitos originais, para que assim, possa se diferenciar dos concorrentes e atrair novos clientes (LEMOS et al., 2012).

Dentre as técnicas de elicitação de requisitos criativas, focamos o framework pro-posto por Bhowmik e outros (BHOWMIK et al., 2014). Este framework propõe a criação

de novos requisitos para determinado software através da combinação de palavras. Estas palavras são extraídas através de um uxo de tarefas que envolve Análise de Rede Social, Processamento de Linguagem Natural (PLN) e Análise de Similaridade. Ao m destas tarefas, um conjunto de pares de palavras (substantivos e verbos) são disponibilizados aos stakeholders para que os mesmos criem requisitos, utilizando os pares de palavras. Um experimento realizado pelos pesquisadores mostrou que o framework proposto é capaz de criar requisitos criativos. Entretanto nos questionamos se variações implementadas na técnica proposta pelos pesquisadores gerariam, da mesma maneira, requisitos criativos.

Assim, em (PINTO et al., 2015), nós denimos um processo baseado no proposto em

(BHOWMIK et al., 2014) sem utilizar Análise de Rede Social e Análise de Similaridade. O

objetivo era simplicar o processo tornando-o mais exível para o Engenheiro de Requisi-tos (EngR), de forma que o mesmo pudesse utilizar elemenRequisi-tos (texRequisi-tos) que estivessem ao seu dispor. A fonte de textos que originou a combinação de palavras foi a documentação do software (documento de visão e especicação de casos de uso). Além disso, usamos as palavras mais e menos frequentes e também permitimos que o EngR adicionasse ou excluísse palavras manualmente. Igualmente como na abordagem de Bhomik, classica-mos as palavras segundo sua categoria gramatical (considerando apenas substantivos, verbos). Para isso, utilizamos algoritmos de Processamento de Linguagem Natural. Além dessas variações, outras foram testadas, tais como: localização do stakeholder poderia ser remota; tipo e quantidade de stakeholders participantes; forma de avaliar os requisitos criados; denição dos avaliadores; e quantidade de avaliadores.

Diante destas variações, realizamos um experimento com 11 participantes que gera-ram 25 requisitos para o sistema em questão, sendo 11 destes considerados novos (que não haviam sido considerados durante a elaboração do sistema). Desta forma, constata-mos que mesmo diante de algumas variações também era possível utilizar a abordagem combinacional para elicitar requisitos úteis e originais para o software em questão.

Diante desta descoberta, automatizamos a abordagem proposta em (PINTO et al., 2015)

através de uma ferramenta web denominada Ideasy. Além disso propomos novas varia-ções para o uxo de tarefas. As novas possibilidades testadas em experimento, para esta segunda versão, foram: (i) diversicação da origem dos textos; (ii) diversicação da forma de processar as palavras selecionadas; (iii) possibilidade do EngR incluir, alterar ou ex-cluir palavras e; (iv) nova forma de avaliar os requisitos criados. Além disso, adicionamos uma nova tarefa ao processo onde incluímos a possibilidade de aperfeiçoar os requisitos propostos. Mais uma vez a abordagem proposta foi capaz de gerar requisitos criativos mesmo diante das variações sofridas.

1.1 Problema

Diante dos três experimentos realizados utilizando abordagens de criatividade com-binacional, observamos que existem diversas formas de extrair e combinar os elementos que compõem a estratégia de elicitação. Apesar dos experimentos realizados terem levado em consideração textos para combinação de palavras, outros elementos podem ser sele-cionados e combinados tais como imagens, arquivos de áudio ou vídeos. Estes elementos podem ser combinados de formas alternadas ou sobrepostas. A criatividade combinacional é caracterizada pela improbabilidade da combinação, ou em outras palavras, a surpresa encontrada quando uma combinação não comum é apresentada (MAIDEN et al., 2004).

Além disso, diversas são as variabilidades que podem ser empregadas em cada uma das tarefas das técnicas de elicitação baseadas em criatividade combinacional. Assim, utili-zar a criatividade combinacional para elicitação de requisitos pode exigir grande esforço de seus utilizadores (EngR) na medida em que várias são as possibilidades a serem con-sideradas. Ademais, o contexto organizacional inui diretamente nas variações a serem aplicadas ao utilizar esse tipo de técnica, ou seja, cada empresa gestora de um produto de software possui determinado contexto, que deve ser levado em consideração na esco-lha das variações. Chamamos de contexto organizacional os recursos humanos (pessoas), materiais, nanceiros e tecnológicos disponíveis para o levantamento de requisitos. Logo, a respeito deste contexto, deve-se ser analisado quais stakeholders estão disponíveis para

participar da técnica de elicitação (tecnólogos, analistas de negócio, usuários nais), se estes participantes podem se reunir presencialmente ou remotamente, que tipo de mídias (textos, imagens, áudios ou vídeos) desejam utilizar como fonte de informação e se há ferramentas tecnológias que auxiliem na coleta dessas informações, por exemplo.

Assim, o presente trabalho propõe uma Linha de Processo de Software (LPrS) para elicitação de requisitos utilizando a perspectiva da criatividade combinacional. Uma LPrS representa uma família de sistemas de software que compartilham um conjunto de ca-racterísticas comuns, e se diferem por um conjunto de variabilidades (ALEIXO; KULESZA; JUNIOR, 2013). Nós mapeamos as tarefas realizadas nos experimentos anteriores e abs-traímos as variações de forma a adaptar o modelo proposto ao contexto organizacional em que o software será desenvolvido. As variações encontradas permitem uma maior exibi-lização por parte do EngR ao instanciar a abordagem, cando a critério do EngR denir as variações de acordo com cada situação especíca. Nossa LPrS vai além das combi-nações de palavras extraídas de fontes de dados textuais. Nossa proposta visa combinar qualquer tipo de elemento que o EngR tenha à disposição, não impondo limitações ou complexidades para utilização da abordagem.

1.2 Objetivos Gerais e Especícos

Considerando a importância do uso de técnicas que estimulam o pensamento criativo na Engenharia de Requisitos, esta dissertação tem como objetivo principal propor e validar uma Linha de Processo de Software baseado na criatividade combinacional para apoiar a geração de requisitos criativos. A partir deste objetivo geral temos os seguintes objetivos especícos:

• Analisar as práticas atuais que auxiliam a Elicitação de Requisitos utilizando a criatividade combinacional, a m de abstrair e propor uma LPrS;

• Denir as variabilidades identicadas através de modelos de features;

• Validar a Linha de Processo de Software proposta através do contraste de suas características com as características das abordagens especícas já experimentadas.

1.3 Organização do Trabalho

Os capítulos deste trabalho estão organizados da seguinte maneira. No capítulo 2 se-rão apresentadas as denições e os conteúdos teóricos relacionados a abordagem proposta

neste trabalho. No capítulo 3 denimos e detalhamos a LPrS proposta para elicitar requisi-tos, utilizando a perspectiva da criatividade combinacional. No capítulo 4 validamos nossa LPrS através de análise dos experimentos previamente realizados, utilizando técnicas de criatividade combinacional, comparando as características e variações de cada um desses experimentos com nossa proposta. Por m, o capítulo 5 apresenta as conclusões gerais, uma revisão das contribuições do trabalho, além dos trabalhos relacionados e trabalhos futuros. O Apêndice A mostra o documento elaborado para descrever textualmente as features identicadas e suas regras.

2 Fundamentação Teórica

Neste capítulo serão apresentadas as denições e os conteúdos teóricos relacionados à abordagem proposta neste trabalho. Serão tratados os seguintes conteúdos: Criatividade na Elicitação de Requisitos, criatividade combinacional, processamento da linguagem na-tural, Linha de Processos de Software e modelos de Features.

2.1 Estratégias para Elicitação de Requisitos Criativos

1984) deniram que fatores inesperados de satisfação são propriedades do sistema que os stakeholders não conhecem ou esperam, e que são descobertos apenas ao utilizar o sistema. Técnicas de criatividade são as mais indicadas para elicitar esses tipos de fatores (POHL; RUPP, 2011a). Para Maiden (MAIDEN; GIZIKIS, 2001) e Robertson (ROBERTSON, 2002)

a criatividade em Engenharia de Requisitos (ER) oferece grande vantagem competitiva para os produtos.

A criatividade pode ser denida como um processo mental que envolve a geração de ideias inéditas e inovadoras (NGUYEN; SHANKS, 2009) e pode ser classicada como exploratória, combinacional ou transformacional (BODEN, 2004). Neste sentido, Maiden

(MAIDEN, 2013) arma que essa classicação na ER varia de acordo com as técnicas e

heurísticas utilizadas. Na criatividade exploratória, os requisitos criativos são obtidos por explorar as possibilidades em um espaço de busca delimitado por regras e restrições de tarefas especícas para o sistema de software pretendido. A criatividade combinacional é alcançada fazendo conexões desconhecidas entre requisitos conhecidos em um ambiente familiar. Ou seja, é caracterizada pela solução encontrada em uma combinação improvável. A criatividade transformacional é realizada na ER ao desaar as restrições sobre o espaço de busca, extrapolando esse espaço de restrições.

A Figura 1 ilustra conceitualmente os três tipos de criatividade. Assumindo o de-senvolvimento hipotético de um sistema de Home Care, vamos considerar um requisito denominado Registrar a Temperatura do Paciente. Uma limitação para as possíveis so-luções para este requisito é o hardware disponível e o custo de implementação. O espaço de busca está delimitado por essas restrições e ilustrado na gura pelo círculo azul. Assim, Termômetro de Contato e Termômetro Infravermelho são soluções encontradas dentro do espaço de busca usando criatividade exploratória. Combinar as duas soluções conheci-das (Termômetro de Contato e Termômetro Infravermelho) e obter um resultado que atenda ao requisito é uma nova solução encontrada utilizando criatividade combinacional. Extrapolar as regras denidas ou desconsiderá-las, em busca de uma solução (como por exemplo desenvolver uma Pulseira que aura a temperatura e registre-a de tempos em tempos no sistema), é uma forma de criatividade transformacional.

Figura 1: Exemplo de como a criatividade pode ser classicada.

O principal objetivo de todas as técnicas de elicitação é auxiliar o ER a identicar o conhecimento e requisitos dos stakeholders. Como e quando aplicar uma determinada técnica vai depender das condições encontradas (POHL; RUPP, 2011a). Ou seja, estrutura organizacional disponível para a elicitação dos requisitos pode habilitar ou desabilitar o uso de algumas técnicas (BATISTA; CARVALHO, 2003). Na última década várias pesquisas

relacionadas à criatividade na elicitação de requisitos foram desenvolvidas. No decorrer desta seção, destacamos alguns destes trabalhos.

2.1.1 Técnicas de Elicitação Baseadas em Criatividade

Mapeamento Sistemático da Literatura

Lemos e outros (LEMOS et al., 2012) realizaram um estudo sistemático com o objetivo

de mapear toda literatura desenvolvida sobre criatividade no processo de Engenharia de Requisitos. Neste mapeamento, foram analisados 46 artigos e constatou-se uma gama diversicada de trabalhos, desde de técnicas experimentais para fomentar criatividade na elicitação de requisitos até artigos de teor losóco. Como resultado, eles apontaram que a maior parte dos artigos analisados (60%) tinham o foco na fase de elicitação de requisitos. Além disso, alguns artigos apontam para o surgimento de novas técnicas que estimulam o uso da criatividade também na fase de elicitação de requisitos. Os autores concluem que o uso de técnicas que estimulam o pensamento criativo potencializam a elicitação de requisitos mais inovadores. Entretanto, alertam que não existe um consenso sobre onde e como integrar técnicas de criatividade no processo tradicional da Engenharia de Requisitos.

Workshop de Requisitos

Maiden e outros relatam (MAIDEN; GIZIKIS; ROBERTSON, 2004) o uso de técnicas de

criatividades através da realização de workshops de requisitos para incentivar o pensa-mento criativo durante a elicitação. Neste trabalho, os autores relatam os resultados e lições aprendidas com a realização de workshops de requisitos apoiados com técnicas de analogia. O grupo realizou 4 workshops, com duração de um dia cada, para gerar requisitos e ideias para um sistema de gestão de tráfego aéreo (CORA-2). Cada workshop envolveu entre 16 e 20 participantes. Os três primeiros workshops geraram 201 novas ideias para o CORE-2. Além disso, o grupo utilizou estes 201 novos requisitos e ideias como base para escrever casos de uso e cenários mais precisos que, por sua vez, permitiu a elaboração e especicação de requisitos utilizando ART-SCENE, um ambiente de software que gera automaticamente cenários a partir das especicações dos casos de uso, em seguida, ori-enta os stakeholders a percorrer estes cenários para descobrir novos requisitos. O quarto workshop foi realizado para os participantes selecionarem as ideias e priorizarem-nas de acordo com sua relevância para o sistema CORA-2 (ou seu sucessor CORA-3). O grupo relata os seguintes pontos importantes como lições aprendidas:

• Os participantes encontraram diculdades para explorar as analogias no primeiro workshop. O grupo relata que para incentivar a aprendizagem analógica durante a

exploração das ideias, é necessário explicar as analogias para os participantes com exemplos simples que encoraje-os a aprender as abstrações subjacentes importantes. • O grupo projetou períodos de tempo mais longos para ideias de incubação e prazos mais curtos para posteriormente desenvolver as ideias, resultando em tempo insu-ciente para clarear as ideias analógicas, por exemplo. O grupo sugere adotar um planejamento mais exível para responder a tópicos imprevistos durante o pensa-mento criativo, pois foi neste mopensa-mento que o pensapensa-mento criativo ocorreu de forma mais ecaz.

• Os autores relatam que o sucesso dos workshops depende do apoio recebido dos ges-tores e stakeholders. Participar deste tipo de atividade requer interesse em abraçar e apoiar as oportunidades criativas que serão abordadas.

Dado os problemas identicados na abordagem, os autores aplicaram as lições aprendi-das em workshops subsequentes. A m de integrar workshops de criatividade em processos de requisitos estruturados, o grupo utilizou as saídas obtidas (novos requisitos e ideias) como artefatos de entrada para técnicas estruturadas como o ART-SCENE.

EPMCreate

Mich e outros (MICH; ANESI; BERRY, 2005) propõem uma técnica denominada

EPM-create (Acrônimo em inglês de EPM Creative Requirements Engineering TEchnique). Se-gundo os autores é uma técnica pragmática com forte apoio da psicologia, adaptada a partir da Técnica EPM (Acrônimo em inglês de Elementary Pragmatic Model). A técnica proposta consiste em 16 passos, onde, em cada um deles o problema é analisado de acordo com um dos comportamentos identicados pelo EPM. Os autores consideram o método estruturado, com instruções para o analista se concentrar em combinações de diferentes pontos de vista dos stakeholders. A viabilidade e a ecácia da técnica na elicitação de requisitos foi demonstrada por experimentos em dois projetos com características muito diferentes. Cada experimento comparou o desempenho de duas equipes de análise, um deles utilizando EPMCreate e o outro utilizando Brainstorm. Cada experimento contou com a participação de 8 stakeholder. Os resultados dos experimentos foram analisados quantitativamente, contando o número de ideias e requisitos gerados, e qualitativamente, comparando a viabilidade e a inovação das ideias e requisitos. Em termos quantitativos, a equipe de stakeholders utilizando a técnica EPMcreate conseguiu gerar 169 ideias e requisitos, ao passo que a outra equipe gerou 65. As ideias e requisitos criadas foram vali-dadas segundo critérios próprios (requisitos novos e realizáveis, novos mas não realizáveis,

já conhecidos mas não realizáveis ou já conhecidos e realizáveis). Assim, 66 das ideias e requisitos criados utilizando EPMcreate foram considerados novos e realizáveis, enquanto 18 obtiveram esta validação utilizando a técnica Brainstorm. Estes resultados atestaram a maior ecácia do EPMCreate.

Elicitação Baseada na Colaboração de Tecnólogos e Usuários

Yang-Turner e Lau (YANG-TURNER; LAU, 2011) propõem envolver tecnólogos e

usuá-rios da aplicação de maneira que possam, de forma integrada, criar e validar novas ideias e requisitos para o sistema em questão. O relato apresenta a experiência do grupo enquanto explora as questões estratégicas em cima do DICODE1 _{(Data-Intensive Collaboration and} Decision Making), um projeto de um framework da União Européia cujo objetivo é faci-litar e aumentar a colaboração e a tomada de decisões em ambientes de uso intensivo de dados complexos. O grupo procurou explorar as seguintes questões: (i) como posicionar os dois grupos de stakeholders, tecnólogos e usuários da aplicação, em um processo de levantamento de requisitos; (ii) como motivar toda a equipe para ser criativa e trabalhar em conjunto para o objetivo comum de levantamento de requisitos; e (iii) como gerir e transformar ideias criativas em requisitos estruturados. Esta estratégia estabelece que os grupos de stakeholders (tecnólogos ou usuários da aplicação) devem entender a atual prá-tica de trabalho, ou seja, tanto os usuários quanto os técnicos devem ter conhecimento dos casos de uso atuais. O objetivo comum a todos para levantamento de requisitos é produzir ideias criativas para o trabalho futuro dos usuários. A visão dos usuários e propostas dos técnicos podem divergir, mas ciclos iterativos e interativos devem ser realizados para eles entenderem, inspirarem e estimularem uns aos outros. O grupo destaca que a diversidade dos parceiros (usuários e técnicos) é um instrumento poderoso e essencial para o projeto. Cada parceiro tem sua contribuição a dar, segundo suas próprias experiências no contexto do projeto. Ao canalizar as trocas de ideias e pontos de vista de uma forma construtiva e progressiva, a inovação é desenvolvida.

Design Thinking

Vetterli e outros (VETTERLI et al., 2013) propõem a utilização de Design Thinking

(DT) para elicitação de requisitos. Os autores destacam que aplicações web e aplicações móveis são pequenas, exigem rápido desenvolvimento, devem atender as necessidades dos clientes de perto e mudam frequentemente. Design Thinking provê uma metodologia para

elicitar as necessidades dos clientes e produz uma série de rápidos e simples protótipos que eventualmente convergem para soluções inovadoras. Dessa forma, a metodologia torna-se consistente com as práticas iniciais de elicitação de requisitos e a rápida prototipação e customização envolvida de métodos de desenvolvimento ágeis. O Design Thinking enfa-tiza a perspectiva humana. Os autores aplicaram este método em problemas mal denidos dentro do contexto de aplicativos para usuários de smartphones. Iniciando com rapidez, protótipos de baixa resolução ajudam os times do projeto a divergirem dentro do con-texto do problema para evitar tomar decisões sobre a solução que podem ser somente soluções pontuais e não resolver a necessidade humana. Esses protótipos ajudam a con-cretizar ideias diferentes enquanto se concentra nas necessidades especícas e importantes dentro do contexto do projeto. Embora o desenvolvimento ágil e a engenharia de requisi-tos usem protótipos, a utilização destes como forma central, ajuda a convegir e eliminar inconsistências tão rapidamente quanto possível no início do processo.

O trabalho apresentado por Vetterli e outros (VETTERLI et al., 2013) relata ainda dois

casos de sucesso com o uso do Design Thinking na indústria. O primeiro, uma empresa de cartão de crédito da Suíça resolveu um problema de gestão de relacionamento com clientes usando DT para produzir um aplicativo de tablet para seus clientes. O segundo, uma grande fabricante de automóveis queria repensar a mobilidade e utilizou DT para desenvolver um aplicativo de tablet que ajuda a mover os clientes de um local para ou-tro, com diferentes formas de transporte. Eles apontaram que nem processos tradicionais da Engenharia de Requisitos, nem o desenvolvimento ágil eram bem adaptados a estas tarefas, apesar de parte dos seus processos terem sido utilizados de alguma forma no desenvolvimento do software.

O grupo naliza propondo que a utilização do Design Thinking com processos tradi-cionais da Engenharia de Requisitos e o Desenvolvimento Ágil vai deixá-los consideravel-mente fortes divergindo o modo de trabalho orientado a humanos de perspectivas mais técnicas conduzidas pelas outras metodologias.

2.1.2 Técnicas de Elicitação Baseadas em Criatividade

Combina-cional

Criatividade Combinacional

Combinar ideias existentes é uma das técnicas disponíveis para elicitação denominada criatividade combinacional. Esta técnica tipicamente requer uma rica fonte de dados e

a habilidade de combiná-las de diferentes formas (BODEN, 2004). É possível fazer uma

variação de elementos xos e/ou aleatórios, no qual um elemento do problema (o elemento xo) é combinado com um estímulo que é selecionado aleatoriamente obtido através de uma fonte geral de informações como fontes extraídas da internet ou outras fontes de problemas especícos como o modelo do domínio (MAIDEN et al., 2010).

Bhowmik e outros propõem em (BHOWMIK et al., 2014) um framework que aplica a

técnica da criatividade combinacional para obter novos requisitos para sistemas existentes. O framework se baseia nas informações que registra de uma rede social e na interação dos stakeholders do sistema em questão. A partir destas informações (requisitos e comentários) a estratégia propõe algoritmos de Topic Modeling e POS Tagging e análise de similaridade para disponibilizar palavras aos stakeholders para que estes possam criar novos requisitos. A proposta do grupo é que as palavras disponibilizadas não tenham nenhuma similaridade quando comparada aos textos originais.

O Processamento de Linguagem Natural (PLN) consiste no desenvolvimento de mode-los computacionais que lidam com problemas relacionados à automação da interpretação e da geração da língua humana em diversas aplicações. É possível citar inúmeras tarefas realizadas por meio do PLN, tais como a tradução e interpretação de textos, extração e recuperação de informações em documentos, sumarização automática de textos e catego-rização textual (NATURAL, acessado em 20 de Dezembro de 2014).

Em Bhowmik e em nosso trabalho, exploramos duas das tarefas contidas na grande área do Processamento da Linguagem Natural. A primeira, denominada Topic Modeling, consiste em usar modelos probabilísticos para descobrir temas contidos em uma coleção de documentos. A segunda, denominada Part-Of-Speech Tagging consiste na atribuição de uma marca (tag) correspondendo à categoria gramatical de cada unidade em um texto, baseada tanto na sua denição quanto no seu contexto. A utilização de algoritmos de PLN foi necessária, durante a realização de experimentos que validaram nossa abordagem, uma vez que uma quantidade extensa de textos foram analisados para se descobrir pala-vras relevantes (utilizando algoritmos de Topic Modeling). Algoritmos de Part-Of-Speech Tagging foram úteis para etiquetar estas palavras segundo sua classicação morfológica, permitindo o agrupamento das mesmas.

Topic Modeling

Algoritmos de topic modeling aplicam métodos estatísticos para analisar textos com o objetivo de descobrir temas, como esses temas são ligados uns aos outros, e como eles

mudam ao longo do tempo (BLEI, 2012). Neste aspecto, um tema é uma coleção de

pala-vras que co-ocorrem com frequência nos documentos analisados. Em um estudo realizado em 2009, Blei e outros, armam que topic models tem sido utilizados em vários tipos de documentos, incluindo e-mails, resumos cientícos e arquivos de jornais (BLEI; LAFFERTY,

2009). Atualmente, podemos acrescentar a utilização de topic models ao processamento de comentários de usuários em sites de aplicações como Apple Store2 _{e Google Play}3 (CARREÑO; WINBLADH, 2013; CHEN et al., 2014; GAO et al., 2015; MAALEJ; NABIL, 2015; GUZMAN; MAALEJ, 2014; TAKAHASHI; NAKAGAWA; TSUCHIYA, 2015), além da mineração

de repositórios de software analisando mudanças de código, mensagens de commits, so-licitações de melhorias, correção de bugs e arquivos de logs (CHEN; THOMAS; HASSAN,

2015).

Os algoritmos de topic modeling recebem um grande volume de textos como entrada e descobrem um conjunto de tópicos/temas recorrentes e o grau em que cada documento exibe esses tópicos. Os tópicos, resultantes do processamento, possibilitam, por exem-plo, uma maneira resumida de representar os documentos que é útil para navegação e compreensão destes documentos, sob diversos aspectos, por exemplo.

Para exemplicar a execução do algoritmo de topic modeling processamos o conteúdo de uma redação elaborada por um candidato ao Exame Nacional do Ensino Médio -ENEM de 2014. A redação analisada foi retirada da internet e obteve a pontuação máxima (1.000) na avaliação. O tema da redação era Publicidade infantil em questão no Brasil Conguramos nosso algoritmo para retornar 1 tópico, contendo 5 palavras. O resultado foi o seguinte conjunto de palavras: crianças, infantil, podem, publicidade e deve.

O resultado apresentado mostra as palavras mais relevantes que representam a redação analisada. Percebemos que o resultado do processamento está diretamente relacionado com o tema solicitado pelos avaliadores.

Part-Of-Speech Tagging

Em processamento de linguagem natural taggers são sistemas que analisam um texto e inserem etiquetas morfológicas, gramaticais ou sintáticas a cada unidade do texto. Um part-of-speech tagger é um etiquetador morfossintático, que analisa o texto e identica as categorias gramaticais como substantivos, adjetivos, pronomes e verbos, dentre ou-tras (SAYÃO, 2007). Nos casos onde há ambiguidade, ou seja, a unidade pode receber

2_{https://itunes.apple.com/br/genre/ios/id36?mt=8} 3_{https://play.google.com/}

mais de uma etiqueta, o desambiguador utiliza informações do contexto para realizar a desambiguação e denir a etiqueta mais provável.

Por exemplo, a análise da sentença O menino correu para o mato. Eu mato aquela cobra.. realizada por um etiquetador morfossintático, deverá exibir o seguinte resultado:

Palavra Classicação O Artigo menino Substantivo correu Verbo para Preposição o Artigo mato Substantivo . Pontuação Palavra Classicação Eu Pronome mato Verbo

aquela Pronome Demonstrativo cobra Substantivo

. Pontuação

Tabela 1: Análise da classicação morfossintática de sentenças distintas com palavras idênticas.

Neste exemplo, cada palavra das sentenças propostas foram etiquetadas, segundo sua classicação morfossintática. Observa-se que palavras idênticas em contextos diferentes são também diferenciadas pelo POS Tag. Na primeira sentença mato é um substantivo, enquanto na segunda, a mesma palavra é um verbo.

Em nosso trabalho, as formas de combinar diferentes repositórios de elementos re-lacionados, ou não, ao software em questão leva a seleção de diferentes elementos e a possibilidade de geração de novos requisitos, fazendo destas combinações (e do resultado delas) uma forma de criatividade combinacional.

2.2 Linha de Processos de Software

Nossa abordagem visa propor um modelo de processo genérico para elicitação de requisitos que possa ser instanciado e utilizado por equipes de desenvolvimento de software em diferentes contextos. Dessa forma é necessário denir o processo de elicitação, que é um processo de software, e como se dá sua reutilização.

Um processo de software pode ser denido como o conjunto de atividades necessárias para conceber, desenvolver, implantar e manter um produto de software (FUGGETTA,

alter-nativas de execução de suas atividades. Assim, um processo de software denido permite que prossionais de engenharia de software possam trabalhar de forma ordenada, possibili-tando um melhor entendimento do seu trabalho, bem como das atividades executadas por outros participantes do processo (WATTS, 1989). Entender a capacidade dos subprocessos

que compõem cada processo de software é o primeiro passo para que se possa evoluir e melhorar os processos existentes (FLORAC; CARLETON, 1999).

Um processo de software deve propor as atividades a serem realizadas, os recursos (humanos, de hardware e de software) necessários, os artefatos consumidos e produzidos e os procedimentos a serem adotados (métodos, técnicas, modelos de documentos, entre ou-tros) (FALBO; MENEZES; ROCHA, 1998;GRUHN, 2002). As atividades são as tarefas a serem

realizadas, sendo que elas podem requerer certos recursos, consumirem e/ou produzirem artefatos e adotarem procedimentos durante suas realizações. As atividades podem ser decompostas em outras atividades (subatividades) e, também, podem depender de outras atividades. Os artefatos são produtos de software que são consumidos ou produzidos du-rante a realização de uma atividade (FALBO; MENEZES; ROCHA, 1998). Como exemplo de

artefatos, podemos citar formulários preenchidos, relatórios, lista de requisitos descobertos e código fonte. Já os procedimentos são formas bem denidas de se conduzir a realização de uma atividade (FALBO; MENEZES; ROCHA, 1998), indicando a sequencia em que os

métodos serão realizados, tais como roteiros de documentos e normas de programação. Para representar a modelagem do processo, utilizamos em nosso trabalho a notação BPMN (Business Process Modelling Notation) (WHITE et al., 2004). BPMN é uma notação

desenvolvida pela Business Process Management Initiative (BPMI) e atualmente mantida pelo Object Management Group (OMG). Esta notação dene um modelo gráco para processos de negócio baseada na técnica de uxograma (HARRINGTON; ESSELING; VAN,

1991).

A Figura 2 ilustra um processo hipotético de atualização de um software. Este pro-cesso foi denido aqui para ilustrar uma linha de propro-cesso de software; ele é genérico suciente para ser utilizado por diferentes equipes de desenvolvimento, utilizando diver-sas variabilidades em suas tarefas, porém seguindo um mesmo uxo. Assim, o processo inicia através da atividade Modelar Informações, quando a equipe de desenvolvimento recebe uma lista de melhorias ou novas funcionalidades (artefato de entrada) do cliente. Nesta primeira tarefa, as equipes de desenvolvimento podem modelar estas informações de diversas maneiras, tais como diagramas de casos de uso, especicação de casos de uso, documento de visão, diagrama de entidade relacionamento, dentre outros. O documento com especicações das funcionalidades gerado nesta atividade, serve de artefato de entrada para a próxima atividade: Analisar e Estimar Esforço de Desenvolvimento. Novamente, as equipes de desenvolvimento possuem suas próprias formas para realizar esta atividade (Análise de Pontos de Função, Análise de Ponto por Caso de Uso, Quantidade de Serviços, Telas ou Relatórios, e.g.). O resultado desta atividade é uma lista de especicações com seus respectivos prazos e uma lista de problemas identicados. Caso este cronograma não seja aprovado, deverá ser analisado novamente até que haja um consenso em termos de prazo/escopo. Com o cronograma aprovado, a atividade Implementar Soluções especica atividades de codicação, integração com modelo de dados ou interface com usuário a depender de cada funcionalidade ou tipo de software. Após a realização desta atividade, entra em execução a atividade Realizar Testes, onde cada equipe implementa seus testes a m de validar as especicações e novas funcionalidades. As variabilidades desta tarefa podem incluir testes unitários ou integrados, manuais ou automatizados. Caso os testes sejam aceitos, o uxo naliza com o software disponível para lançamento. Caso contrário retorna para a tarefa de Implementar Soluções com a lista de erros detectados.

Segundo (ARMBRUST et al., 2009), uma Linha de Processo de Software é denida

como uma família de processos de software com um conjunto gerenciado de features que satisfazem necessidades especícas de uma organização e que são desenvolvidas a partir de um conjunto de processos comuns. Neste contexto, uma feature é denida como uma propriedade de sistema ou funcionalidade relevante para os stakeholders e é usada para capturar semelhanças e variabilidades entre os sistemas (CZARNECKI; EISENECKER, 2000; CZARNECKI; HELSEN; EISENECKER, 2005). A modelagem de features é uma tarefa

impor-tante em LPrS, uma vez que nessa fase é feita a modelagem das funcionalidades comuns e variáveis da família de processos. O modelo de features tem a estrutura de árvore e representa associações entre as features obrigatórias, opcionais e alternativas (ATAIDE et al., 2012).

Dentre os diferentes tipos de associação entre features, podemos citar: • Obrigatória: a feature tem de estar presente em todos os processos; • Opcional: feature que pode ou não existir em um determinado processo;

• Ou Inclusivo (Or): são característica que podem ser incluídas adicionalmente aos processos; e

• Alternativas (Xor): representa uma relação exclusiva, ou seja, quando uma feature é selecionada as demais são excluídas.

A Figura 3 exibe exemplos das associações entre as features. A subgura a demons-tra o relacionamento obrigatório e opcional das features. Dessa forma, a feature F1 deve ser selecionada no processo, enquanto a F2 pode ou não estar presente. A subgura b demonstra o relacionamento de features Ou Inclusivo (Or), dessa forma, é possível sele-cionar apenas uma das features ou ambas. A subgura c demonstra o relacionamento de features Alternativas (Xor), dessa forma, ao selecionar uma feature (F1, por exemplo) a outra (F2) não pode mais ser selecionada.

(a) Feature Obrigatória e

Opcional (b) Associação Ou Inclusivo (c) Associação Alternativas

Figura 3: Notação utilizada em diagramas de features.

A Figura 4 ilustra features do processo de atualização de software da Figura 2. É possível observar as features obrigatórias Documentação Textual e Documentação Gráca. Ambas possuem associação do tipo Ou Inclusivo com suas repectivas subfeatures.

Figura 4: Exemplo de modelo de features para o processo de atualização de software. No próximo capítulo apresentamos nossa Linha de Processo de Software, utilizando a notação BPMN para descrever o processo proposto e um modelo de features para detalhar suas variabilidades.

3 Um Modelo Conceitual para

Elicitação de Requisitos Baseado

na Criatividade Combinacional

Este capítulo apresenta nossa proposta de Linha de Processo de Software (LPrS) para elicitar requisitos utilizando a perspectiva da criatividade combinacional. Detalhamos seu uxo de atividades e explicamos as características comuns e variáveis deste processo, além de exemplicar como o EngR pode instanciar a LPrS proposta. Além disso, para auxiliar a execução de algumas atividades deste tipo de elicitação, desenvolvemos uma ferramenta web denominada Ideasy. Esta ferramenta automatiza algumas atividades da LPrS conforme relatamos na seção 3.2 deste capítulo.

3.1 Modelo Proposto

A abordagem proposta consiste de três artefatos: (i) um modelo de processo, no qual usamos a notação BPMN, que retrata (de forma abstrata) a sequência de atividades, os papéis que realizam cada atividade, e suas entradas e saídas; (ii) um modelo de fe-atures, que organiza as características do processo hierarquicamente, indicando quais as combinações possíveis. (iii) um documento de descrição das features identicadas, que foi elaborado com o objetivo de mapear as regras que compõem cada uma das features oriundas dos elementos do processo. Este último artefato está disponível no Apêndice A deste trabalho.

O planejamento, preparação das tarefas para realização do processo e a seleção das features são responsabilidade do EngR e ocorre de forma manual. Assim, o mesmo deve analisá-las de acordo com o contexto do software e, após isso, os stakeholders entram no processo contribuindo com os novos requisitos, validação e aperfeiçoamento dos mesmos. A Figura 5 apresenta o processo proposto neste trabalho. O uxo de tarefas se inicia com a denição do Engenheiro de Requisitos em quais fontes de elementos utilizar (tarefa Denir

Fontes de Elementos). São denominadas fontes de elementos os repositórios escolhidos pelo EngR que servem de fonte original de informações. Na próxima tarefa, Selecionar Elementos, o Engenheiro de Requisitos classica as fontes selecionadas agrupando-as em categorias e seleciona os elementos que serão disponibilizados aos stakeholders. Uma lista com os elementos selecionados e classicados é o artefato de saída desta atividade. Após isso, o EngR deve Denir Regras de Criação dos Requisitos e disponibilizar o conjunto de elementos selecionados e classicados juntamente com estas regras aos stakeholders. Na tarefa seguinte, Criar Novos Requisitos, os stakeholders deverão analisar os elementos disponibilizados e propor os novos requisitos de acordo com as regras especicadas. O artefato de saída é a lista de requisitos. Na continuação, a tarefa Validar Requisitos, recebe como artefato de entrada a lista de requisitos criados e um questionário de validação. Este último, dene formas e variações de validar os requisitos propostos pelos stakeholders. Neste sentido, temos como artefato de saída uma lista de requisitos validados. A última tarefa do processo, Aperfeiçoar Requisitos, é opcional e discute formas e variações de como aperfeiçoar os requisitos criados e validados. O processo naliza com o último artefato gerado: a lista de requisitos para o sistema em questão.

Figura 5: Processo para elicitação de requisitos baseado na criatividade combinacional. O modelo de features, Figura 6, inicia com um item abstrato que representa o processo de elicitação. Este item é decomposto em 5 features obrigatórias (Denir Fonte de Ele-mentos, Selecionar EleEle-mentos, Criar Novos Requisitos, Denir Critérios para Elaboração de Requisitos e Avaliar Requisitos) e uma opcional (Aperfeiçoar Requisitos). Estas featu-res têm uma relação direta com as atividades com mesmos nomes retratadas no processo da Figura 5, e serão explicadas a seguir.

Figura 6: Diagrama de features utilizadas no processo proposto.

3.1.1 Denir Fontes de Elementos

Nesta primeira atividade, o objetivo é denir os elementos que irão compor o conjunto nal de elementos selecionados e agrupados segundo sua classicação para a criação dos novos requisitos. No contexto do nosso trabalho, elementos são artefatos de trabalho bem delimitados e tangíveis, que possam ser produzidos ou visualizados pelas partes envolvidas. Exemplos desses elementos são textos, imagens, vídeos e áudios relacionados ou não com o software em desenvolvimento.

Nesta atividade o Engenheiro de Requisitos deve denir de onde extrair os elementos que compõem o conjunto disponibilizado para análise dos stakeholders. O EngR deve selecionar fontes que agrupem vários elementos de um mesmo tipo, para que a partir desses aglomerados de elementos seja possível sua classicação e seleção.

Existe uma grande variedade de fonte de elementos que pode ser utilizada nesta ati-vidade. Dentre elas podemos destacar: (i) textos e documentos que tenham relação direta com o software em análise, tais como a documentação do sistema (documentos de visão, documentos de caso de uso) ou seus manuais de uso e base de conhecimentos para solução de problemas; (ii) textos que estejam relacionados à área de atuação do software, mas que não tenham sido elaborados pela equipe do projeto (stakeholders, engenheiros de requisi-tos, analistas de sistemas, programadores e equipe de suporte), tais como a documentação ou manuais de sistemas similares, livros da área, legislação; (iii) textos alheios ao propósito do sofware extraídos de uma fonte geral e aberta (como site de notícias e redes sociais);

(iv) imagens relacionadas ao software; (v) imagens disponíveis na internet; (vi) vídeos diversos que estejam disponíveis, sejam eles palestras, propagandas, ou qualquer outro tipo de vídeo que o EngR queira utilizar para estimular o pensamento criativo através da criatividade combinacional; (vii) músicas, podcasts, conversas gravadas;

Além dessas possibilidades, o EngR pode denir alguma outra não citada ou até mesmo combinar as possibilidades existentes. Na Figura 7 podemos observar o diagrama de features com as possíveis variações desta tarefa. O EngR pode escolher uma ou mais fonte de elementos, conforme exposto no diagrama. A Relação Entre Software e Fonte de Elementos dene, como o próprio nome diz, como o software e a fonte de elementos estão relacionados. Dessa forma, uma fonte de elementos Interna deve possuir uma relação direta com o software, ou seja, ter sido produzida pela equipe de desenvolvimento ou stakeholders do software. Por sua vez, uma fonte de elementos Externa não deve possuir uma relação direta com o software.

Figura 7: Variações da tarefa Denir Fontes de Elementos.

Ao nal desta atividade o artefato de saída é composto por um conjunto de fontes de informação, que servem de artefato de entrada para a próxima tarefa, por exemplo, o EngR pode escolher fotos relacionadas ou não ao software em questão e textos extraídos de algum site de notícias.

3.1.2 Selecionar Elementos

Esta tarefa visa selecionar nas fontes de elementos escolhidas, quais elementos devem ser disponibilizados aos stakeholders para criação dos requisitos, a partir de critérios previamente denidos. A quantidade de elementos, como eles serão agrupados e a forma de seleção são variações identicadas nesta atividade.

Antes de escolher os elementos o EngR deve classicá-los e etiquetá-los, de forma que os mesmos possam ser agrupado segundo a classicação denida. Ou seja, para cada um dos elementos da fonte, o EngR deve denir um termo que classique aquele elemento. Essa classicação serve para determinar as regras das possíveis combinações disponíveis aos stakeholders no momento da criação dos novos requisitos. Por exemplo, para fontes de elementos textuais as abordagens (BHOWMIK et al., 2014; PINTO et al., 2015) etiquetaram

cada palavra dos textos segundo sua classicação gramatical. Após isso selecionaram os substantivos e verbos mais relevantes/frequentes. A combinação de palavras em classes distintas foi responsável por estimular o stakeholder a criar novos requisitos para o software em questão.

A Figura 8 mostra um diagrama de features com as possíveis variações da atividade Selecionar Elementos. O critério de seleção de elementos deve determinar como os ele-mentos serão selecionados e variam de acordo com o tipo da fonte de eleele-mentos denida. Caso o EngR tenha denido uma fonte de elementos textual, pode selecionar palavras mais/menos frequentes ou mais/menos relevantes, por exemplo. Caso tenha denido uma página em uma rede social de imagens ou vídeos como fonte de elementos, o EngR pode selecionar imagens e vídeos mais/menos avaliados, mais/menos visualizados ou alguma outra forma de seleção. Além disso, a feature Classicar Elementos caracteriza como os elementos serão classicados. Essa classicação também varia de acordo com o tipo da fonte de elementos. Para fonte de elementos textuais, uma possibilidade seria classicar as palavras segundo a categoria gramatical (verbos, substantivos, adjetivos). Para imagens, é possível classicar segundo seu contexto (imagens abstratas, imagens reais, e.g.) ou se-gundo uma categoria que o EngR determine (imagem de ação, imagem de objeto, e.g). No caso dos vídeos, possíveis classicações seriam propagandas ou palestras. Por m, nos casos de músicas é possível classicá-las segundo o estilo musical (MPB, Pop).

Figura 8: Variações da tarefa Selecionar Elementos.

Além do mais, a forma de selecionar os elementos também é uma possível variação, sendo ela manual ou automatizada. A seleção manual seria para os casos em que a fonte de elementos não possuim um grande volume de informações ou quando não está em formato digital (arquivos de textos impressos, fotos impressas). Desta forma, o EngR deve denir os critérios de seleção e manualmente classicar e escolher os elementos. Caso o volume de informações seja elevado ou esteja em formato digital, o EngR pode utilizar algoritmos de PLN ou ferramentas disponíveis para este m. Como apresentado no Capítulo 2 os trabalhos relacionados tem apostado na utilização de algoritmos de Processamento de Linguagem Natural para auxiliar nesta tarefa.

A quantidade de elementos selecionados também faz parte do modelo de features. Nossa LPrS não dene uma quantidade exata de elementos a serem disponibilizados. Nosso entendimento nesse aspecto é que quanto maior número de elementos (n), mais fácil será para o stakeholder gerar um novo requisito que ele já estava predisposto a solicitar (mediante alguma necessidade identicada empiricamente por ele). Ou seja, não haverá um esforço para criar algo ainda não pensado. Por outro lado, denir n com um valor muito baixo pode limitar o stakeholder, dicultando a elaboração de novos requisitos ou mesmo tornando sua tarefa de criação de requisitos entediante.

Embora nossa pesquisa deixe em aberto os possíveis métodos para denir o valor de n, consideramos que esta é uma feature importante para o sucesso da técnica.

Ao nal desta atividade o artefato de saída é composto pelos n elementos selecionados, agrupados segundo sua classicação.

3.1.3 Denir Critérios para Elaboração de Requisitos

Nesta tarefa o Engenheiro de Requisitos deve denir as regras de criação dos requisitos. Tais regras devem levar em consideração a classicação dos elementos, a maneira como elas devem ser combinadas entre si e a maneira como os elementos devem ser apresentados aos stakeholders para a criação das sentenças que representam os novos requisitos.

A Figura 9 mostra as features identicadas nesta tarefa. Inicialmente é necessário de-nir o conceito de requisitos. Subfeatures identicadas para este caso seriam Casos de Uso ou Sentenças Simples (frases que representem uma nova funcionalidade ou requisito para o sistema em questão). Após isso, deve-se denir como se deve realizar a Combinação de Elementos. Exemplos dessas combinações podem incluir a obrigatoriedade do stakeholder selecionar Um Elemento de Cada Grupo denido e/ou denir que os elementos seleci-onados em grupos distintos estejam diretamente relaciseleci-onados ao serem propostos pelos stakeholders. Também é necessário denir quanto tempo os stakeholders terão a disposição para a criação destes requisitos, através da feature Tempo para Elaboração. Além disso, é importante denir uma Forma de Apresentação dos Elementos aos stakeholders. Caso os elementos sejam palavras (verbos e substantivos), podem ser apresentadas em forma de tabela ou nuvem de palavras. Caso sejam vídeos, podem ser exibidos em sequência alternada. Caso sejam músicas, podem ser ouvidas de maneira sobreposta uma a outra.

Figura 9: Variações da tarefa Denir Critérios para Elaboração de Requisitos. Além disso, a criação das sentenças pode possuir um template preestabelecido, ou seja, podemos determinar como as sentenças devem ser formadas. Templates de requisitos

fornecem uma abordagem simples e compreensível e ajuda a reduzir as transformações de linguagem ao documentar requisitos, facilitando a alta qualidade e não-ambiguidade (POHL; RUPP, 2011a).

Considerando que uma instância de nosso modelo utilize 2 conjuntos de elementos classicados em verbos ou substantivos, podemos propor o seguinte template para criação das sentenças: O <sistema> deverá/deveria/irá + <elemento_conjunto_1> + comple-mento/verbo + <elemento_conjunto_2>. Assim, um exemplo de sentença criada, con-siderando o navegador Firefox e as palavras informar (verbo do conjunto 1) e aberto (substantivo do conjunto 2), seria: o Firefox deveria informar ao usuário a quantidade de abas abertas.

Ao nal desta atividade o artefato de saída é composto pelos n elementos selecionados e agrupados acrescidos das regras e do template para criação de novos requisitos.

3.1.4 Criar Novos Requisitos

Antes de explicarmos como executar esta tarefa, cabe destacar que não identicar ou não considerar quem são os stakeholders pode resultar em signicativas repercussões ne-gativas para o progresso desta atividade, pois certos requisitos podem não ser detectados. Segundo Pohl e Rupp Esses requisitos ignorados entrarão em cena mais tarde sob forma de solicitações de mudança durante a operação do sistema. Corrigir essas questões retro-ativamente implica em altos custos adicionais. Portanto, é essencial identicar todos os stakeholders e integrá-los aos procedimentos de elicitação. (POHL; RUPP, 2011b). Entre-tanto, não existe um método objetivo para se identicar os stakeholders, e nem todos eles precisam participar das abordagens para elicitação, uma vez que grupos amplos podem inviabilizar a análise das necessidades reais do sistema. Neste caso, o EngR deve ser capaz de selecionar os principais stakeholders de acordo com o contexto do software e a técnica de elicitação escolhida.

Com a disponibilização dos elementos selecionados, os stakeholders devem analisar in-dividualmente cada um deles para tentar criar novos requisitos para o sistema em questão de acordo com as regras e template estabelecidos.

A Figura 10 apresenta as features e possíveis variações desta tarefa. As features a serem levadas em consideração no planejamento da elicitação são: a localização dos stakeholders, os tipos de stakeholders, a organização e interação entre stakeholders e a quantidade de stakeholders participantes. Como variações para esta atividade podemos considerar

reali-zar essa tarefa de maneira presencial ou remota, individualmente, em pares, ou em grupos. Além disso, podemos separar os stakeholders por grupos: usuários nais, especialistas do domínio da aplicação ou desenvolvedores. A quantidade de stakeholders selecionados tam-bém é importante, pois pode interferir diretamente na quantidade de requisitos gerados.

Figura 10: Variações da tarefa Criar Novos Requisitos.

Ao nal desta atividade o artefato de saída é composto pelos novos requisitos criados pelos participantes.

3.1.5 Validar Requisitos

Após a criação de requisitos, os stakeholders devem validá-los. Cabe destacar que o Engenheiro de Requisitos pode analisar os requisitos propostos e resolver as possíveis redundâncias ou sentenças sem conexão com o sistema em questão, gerando uma lista melhorada de requisitos.

A Figura 11 apresenta as features associadas a esta atividade. A primeira variabilidade que pode ser explorada nesta tarefa é Critério de Avaliação. A denição de um requisito útil pode variar de acordo com o contexto desejado ao aplicar a técnica de elicitação. Em algumas abordagens o objetivo é gerar requisitos novos e realizáveis ou novos e não

pensados anteriormente. Entenda-se por realizáveis, requisitos em que o custo não seja excessivamente alto ou que faça parte do escopo do software em questão. Outras técnicas preferem considerar apenas requisitos criativos, mesmo que inviáveis tecnologicamente ou economicamente. Segundo a denição de Maiden e outros (MAIDEN et al., 2010) requisitos

criativos são inovadores e apropriados. Assim, caso o EngR queira utilizar outra denição para requisito útil ou avaliar segundo outro critério, deve deni-lo.

Além disso, determinar quem realiza a validação é outra forma de variabilidade da tarefa. A validação dos requisitos pode ser feita pelos próprios participantes (mesmo que eles não avaliem seus próprios requisitos), por uma equipe externa que não tenha par-ticipado da tarefa anterior, pela equipe técnica do software em questão ou pelo EngR (embora seja aconselhável que mais de uma pessoa avalie os requisitos criados).

Uma terceira variabilidade da tarefa é determinar a quantidade de requisitos a serem validados. Cabe esclarecer que a quantidade de requisitos gerada pela tarefa anterior pode ser grande ao ponto de não ser possível de serem, todos, validados pela mesma pessoa. Por exemplo, se 15 stakeholders criam, cada um, 5 sentenças, temos como resultado 75 sentenças a serem validadas. Este é um número muito grande de requisitos para ser validado por uma pessoa. O que pode tornar a validação enfadonha e comprometer a qualidade da mesma. Nesse aspecto, deixamos as possibilidades a respeito da quantidade de requisitos a serem validados como trabalhos futuros.

Por m, a pontuação dos requisitos pode ser realizada seguindo escala de Likert ou outras escalas como VAS (Visual Analogue Scales), escala numérica e escala Guttman (AMARO; PÓVOA; MACEDO, 2005).

Na Tabela 2 apresentamos a escala de pontuação de Likert de 5 pontos, avaliando os quesitos utilidade e originalidade.

Tabela 2: Escala de pontuação dos requisitos quanto a originalidade e utilidade. Pontuação A sentença proposta é útil.

1 Não concordo totalmente. 2 Não concordo.

3 Neutro/Indiferente. 4 Concordo.

5 Concordo totalmente.

Pontuação A sentença proposta é original. 1 Não concordo totalmente. 2 Não concordo.

3 Neutro/Indiferente. 4 Concordo.

5 Concordo totalmente.

É importante destacar que: (i) o avaliador não pode avaliar seu próprio requisito (caso tenha participado da criação) e (ii) o avaliador não pode saber quem sugeriu o requisito que está avaliando, a m de não ter sua pontuação inuenciada.

Ao nal desta atividade o artefato de saída é composto pelos novos requisitos com as respectivas pontuações, segundo o critério de avaliação estabelecido. Neste ponto da LPrS proposta, cabe ao EngR a decisão de prosseguir com o aperfeiçoamento dos requisitos ou nalizar a abordagem.

3.1.6 Aperfeiçoar Requisitos

De posse da lista de novos requisitos e suas respectivas pontuações o EngR pode reunir stakeholders para discutir a lista de requisitos, bem como o resultado das avaliações. Esta tarefa é opcional, no entanto a seleção da mesma obriga a denição das demais features subsequentes.

Selecionada esta tarefa, o EngR deve apresentar os requisitos aos demais participantes e tentar discorrer sobre as ideias apresentadas. Neste momento, caso o autor da sentença esteja participando desta atividade pode se identicar e explicar sua ideia com mais detalhes. Caso surjam novos requisitos ou caso o requisito seja alterado, o EngR deverá registrar esse fato. Mesmo que estas novas ideias não contemplem os elementos utilizados na frase original ou não façam parte dos conjuntos classicadores disponíveis, elas devem ser levadas em consideração e registradas. A única consideração deste registro é que haja consentimento dos stakeholders envolvidos e que os mesmos considerem relevante seu registro.