Trabalhos Relacionados

A seguir, comparamos os principais trabalhos relacionados à técnicas de elicitação de requisitos utilizando criatividade, encontrados na literatura, destacando as diferenças e pontos em comum entre eles.

O trabalho de Bhowmik e outros (BHOWMIK et al., 2014) é o principal trabalho relacio-

nado de nossa pesquisa, uma vez que a partir dele foi possível propor as variações descritas nos experimentos aplicados aos sistemas SIGAA (PINTO et al., 2015) e SUAP-EDU, a m

de observar se o resultado seria capaz de elicitar novos requisitos. No capítulo anterior, detalhamos este framework e observamos a abordagem combinacional para elicitação de requisitos baseada na interação social dos stakeholders dos sistemas Firefox e Mylyn, uti- lizando pares de palavras (verbos e substantivos) que não possuíssem familiaridade entre si.

A seguir, podemos relatar a técnica que implementamos seguindo um raciocínio pa- recido com o apresentado por Bhowmik. Em (PINTO et al., 2015) procuramos simplicar

alguns passos e modicamos algumas variabilidades, uma vez que o contexto organiza- cional em que o software estava inserido era diferente do proposto originalmente por Bhowmik. Ainda que o resultado dos experimentos não tenha constatado altos índices

de requisitos criativos, o resultado nal mostrou que essa proposta era capaz de gerar requisitos úteis, utilizando as variações disponíveis, em menos tempo e com menos esforço por parte dos desenvolvedores, uma vez que não foi necessário construir e agrupar uma rede social a m de obter combinações não familiares de ideias familiares. Ao invés disso, palavras foram extraídas da documentação do software e foi criada uma lista de verbos e substantivos, considerados mais e menos frequentes em relação ao texto.

Como apresentado no Capítulo 2, EPMcreate (EPM Creative Requirements Engine- ering TEchnique), embora não seja uma técnica de criatividade combinacional, é uma técnica que estimula o pensamento criativo baseada no EPM. Assim, Mich (MICH; ANESI; BERRY, 2005) aproveitou sua familiaridade com o EPM e sua experiência com elicitação

de requisitos para estruturar esta técnica, descrevendo como o EngR deve conduzir 16 seções de mini brainstorms para tentar extrair novos requisitos a partir do ponto de vista dos stakeholders. É possível destacar no relato de Mich (MICH; ANESI; BERRY, 2005) a iteração e interação com que o EngR deve lidar para alcançar o objetivo proposto, dando-lhe instruções de como se concentrar nas diferentes combinações de diferentes pon- tos de vistas dos stakeholders. O experimento realizado pelos pesquisadores contou com a colaboração de 8 stakeholders (estudantes e analistas prossionais) para elicitar novos requisitos para dois sistemas. O primeiro sistema, denominado Corsi Online, é um sistema web para o ensino à distância. O segundo, denominado Civilia, é um sistema de admi- nistração pública. O experimento conseguiu gerar 169 ideias, para os dois sistemas, em duas horas de atividades. Após isso, o grupo validou as ideias geradas 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). A avaliação dos requisitos foi realizada com a ajuda de gerentes e analistas envolvidos no projeto original. O resultado da avaliação mostrou que 66 dos requisitos criados, podem ser considerados novos e realizáveis (alguns destes considerados muito inovador para o projeto).

É possível observar, no experimento realizado de Mich e outros (MICH; ANESI; BERRY,

2005), algumas variabilidades identicadas pela nossa LPrS. Exemplo disso, é o tempo utilizado pelos participantes para elicitação de requisitos, a quantidade de participantes, o tipo de stakeholder, a forma de avaliar os requisitos criados, a quantidade e o perl dos avaliadores dos requisitos e a quantidade de requisitos criados.

A abordagem proposta por Yang-Turner e outros (YANG-TURNER; LAU, 2011) visa

envolver tecnólogos e usuários da aplicação para que os mesmos criem e validem novas ideias e requisitos. Os dois grupos de stakeholders (tecnólogos e usuários da aplicação)

devem entender os processos que envolvem o software em questão para poder contribuir com novos requisitos e validar reciprocamente as ideias propostas. Os autores reforçam que os parceiros técnicos (pessoas envolvidas tanto em soluções técnicas quanto cientistas e pesquisadores) devem estar plenamente integrados no processo de levantamento de re- quisitos. Os tecnólogos devem estabelecer uma comunicação integrada com os usuários da aplicação, a m de que possam entender seus pontos de vista e propor soluções inovado- ras. O ponto que merece destaque na abordagem é que a visão dos usuários da aplicação e propostas dos parceiros técnicos pode divergir e este é um processo iterativo e intera- tivo para eles entenderem, se inspirarem e estimularem uns aos outros até chegar a uma solução.

O trabalho relatado em (YANG-TURNER; LAU, 2011) não detalha o experimento rea-

lizado para elicitar requisitos, no entanto, podemos destacar a importância dos tipos de stakeholders no levantamento de requisitos criativos. Todas as partes interessadas desem- penham um papel fundamental em termos de proporcionar ideias criativas. Além disso, cada grupo de stakeholder têm diferentes perspectivas e expectativas, que podem ser conitantes ou não. Daí a necessidade de interação e iteração entre eles. Podemos ma- pear em nossa LPrS, como sendo uma variabilidade, uma característica destacada pelos pesquisadores: o perl dos stakeholders. Mesmo sabendo que o grupo dividiu as partes interessadas em tecnólogos e usuários da aplicação, ainda existe outros fatores a serem explorados, como por exemplo: O tempo de experiência com o projeto, idade, sexo e for- mação acadêmica. Ademais, saber se o participante é um individuo criativo também pode ser uma variabilidade a ser explorada.

Maiden e outros (MAIDEN; GIZIKIS; ROBERTSON, 2004) trouxeram bons resultados

quando relatam sobre o uso de workshops para incentivar o pensamento criativo na fase de elicitação de requisitos. As lições expostas por este trabalho nos levaram a reetir sobre como abordá-las, o que resultou em nossa tarefa de Aperfeiçoar Requisitos. Nesta tarefa é possível adaptar outras técnicas de elicitação de requisitos com a nalidade de validar e melhorar as ideias elencadas na tarefa Criar Novos Requisitos. Nesse momento, o pensa- mento criativo pode surgir e é importante que o EngR esteja atento para explorá-lo. Um destaque que o grupo relata e que também compactuamos diante de dois experimentos realizados utilizando instâncias de nossa LPrS é que o sucesso desse momento de dis- cussão e ideação dependem do apoio recebido dos stakeholders. Participar de discussões que estimulam o pensamento criativo requer interesse em apoiar e contribuir com esses momentos.

Dentre o relato de Maiden e outros (MAIDEN; GIZIKIS; ROBERTSON, 2004) é possí-

vel elencar algumas variabilidades mapeadas pela nossa LPrS, dentre as quais podemos destacar: Tempo utilizado para criar novas ideias (3 dias), a quantidade de stakeholders envolvidos (entre 16 e 20 membros por workshop - entre 64 e 80 participantes), quanti- dade de requisitos criados (201) e o método de avaliação dos requisitos criados (segundo a relevância para o sistema). O grupo não deixa claro se foram os mesmos participantes que avaliaram os requisitos criados.

Segundo Vetterli e outros (VETTERLI et al., 2013) a Engenharia de Requisitos para

aplicações web e aplicações móveis se beneciam muito com o uso de Design Thinking (DT), uma vez que a dinâmica para atender e impactar uma grande quantidade de clientes em um curto espaço de tempo muda muito rapidamente e processos tradicionais podem demorar para realizar essa tarefa. Os protótipos de baixa resolução, utilizados pelo DT, auxiliam as partes interessadas a buscarem uma solução completa e não necessariamente resolver um problema pontual do software em questão.

O artigo apresentado por Vetterli e outros não realiza nenhum experimento prático, para que possamos buscar variabilidades mapeadas pela nossa LPrS, no entanto enten- demos que poderíamos adaptar a utilização desta técnica, que envolve interação entre as partes interessadas, na tarefa de Aperfeiçoar Requisitos, buscando entender melhor algum requisito chave que tenha sido levantado na tarefa Criar Novos Requisitos e precise de um melhor desenvolvimento e discussão.

Segundo Batista e Carvalho (BATISTA; CARVALHO, 2003), a escolha das técnicas de

elicitação não é tarefa trivial. Cada estrutura organizacional dispõe de recursos distin- tos (fonte de obtenção de requisitos, stakeholders disponíveis, nível de conhecimento do desenvolvedor para aplicar determinada técnica, por exemplo) e por isso nem todas as técnicas podem ser utilizadas. Assim, os autores propuseram parâmetros que pudessem ajudar a equipe de desenvolvimento a ter melhores condições de escolher as técnicas fase de elicitação. Apesar da contribuição dos autores ao mapear características das técnicas de elicitação de requisitos (BATISTA; CARVALHO, 2003), algumas dessas características

são vagamente explicadas, dicultando assim na escolha da opção mais adequada. A Ta- bela 10 apresenta as características da nossa LPrS segundo a taxonomia proposta pelos pesquisadores.

Característica Descrição Resumida Valores Possíveis Valor na LPrS Papel exercido pelo usuário Escala de variação da participação do usuário. Consultivo, Representativo ou Decisório Consultivo Categorias de aplicação Maneira de classicar a aplicação da técnica. Observação, Levantamento não-estruturado, Mapeamento e Levantamento estruturado Levantamento não-estruturado Fontes de obtenção dos requisitos

A origem da obtenção dos requisitos.

Indivíduo; Grupos; Mista;

Documentos e Observação Indivíduo, Grupo Nível do

treinamento do desenvolvedor na técnica

O desenvolvedor deve conhecer as técnicas que serão

empregadas no processo de elicitação e deve passar por algum processo de treinamento.

Baixo, Médio, Alto e Domínio

completo Médio

Habilidades exigidas do desenvolvedor

O desenvolvedor está sempre em contato com algum usuário, o que faz com que ele deva possuir um perl social adequado para relacionar-se com as pessoas de diferentes personalidades. Cada técnica exige alguma

característica pessoal do desenvolvedor.

Motivador do grupo, saber conduzir reuniões, ser neutro, capacidade de registrar/anotar eventos, capacidade de apresentar e capturar ideias, gerenciar o grupo, ser receptivo, capacidade de projetar, saber montar projetos e analisar pesquisas, saber entrevistar, elaborar testes/testar, negociador, capacidade de apresentação em público Saber conduzir reuniões, capacidade de apresentação em público Custo da técnica

Custo abordado é relativo ao tempo e esforços empregados no uso e preparação da técnica e não o custo nanceiro.

Baixo, Médio ou Alto Médio Finalidade da

informação coletada

A técnica é útil para capturar requisitos em um sistema novo e/ou sistema já existente.

Sistema novo, sistema atual ou

ambos Ambos

Qualidade informação coletada

A técnica consegue extrair informações em profundidade ou largura.

Profundidade ou Largura Largura Nível de

participação do usuário

Informa se a técnica requer uma grande participação e

preparação do usuário, ou o mesmo é apenas observado.

Baixa, Média ou Alta Alta

Tabela 10: Características da LPrS segundo a taxonomia proposta por (BATISTA; CARVA- LHO, 2003)

Segundo (POHL; RUPP, 2011a), é recomendável combinar diferentes técnicas na eli-

citação de requisitos, pois isso minimiza muitos dos riscos inerentes ao projeto. Pontos fracos e desvantagens de uma técnica podem ser compensados pelo uso de outra técnica que apresenta pontos fortes onde a primeira seja eventualmente decitária.

74

Lev

an

tamen

to Localização dos

Stakeholders Presencial Remota Presencial Presencial

Tipo de Atividade Individual Individual Em grupos de pares Em grupos Tipo de Stakeholder Especialista do domínio da_aplicação Usuário da aplicação Estudantes e Analistas

Gerente de projeto, engenheiros de requisitos, especialistas no domínio da aplicação

Quantidade de Stakeholders 1 11 8 Entre 16 e 20 membros por_workshop

A

valiação

Critério de Avaliação Requisitos criativos:considerados inovadores e apropriados

Considerado algo novo para o software pretendido

Critérios próprios: novos e realizáveis, novos mas não realizáveis, já conhecidos mas não realizáveis, já conhecidos e realizáveis

Segundo sua relevância para o sistema

Denir Avaliadores Desenvolvedores comexperiência nos softwares explorados

Analista de Sistemas com experiência no

desenvolvimento original do software

Gerente e desenvolvedores do projeto original

Não deixa claro se foram os mesmos participantes ou novos

Quantidade de Ideias

Geradas 13 25 169 201

Tempo para Geração das

Ideias 2 horas Até 15 minutos 2 horas 3 dias

Escala de Pontuação Escala Likert Classicando requisitoscomo válidos, inválidos,

novos ou comuns Não informado Não informado Quantidade de Avaliadores 29 1 Não informado Os próprios autores Quantidade de Requisitos

Avaliados Todos os criados

Em nosso trabalho, buscamos identicar e mapear as principais variabilidades encon- tradas em técnicas que utilizam a perspectiva da criatividade combinacional. Na Tabela 11 identicamos e comparamos as variabilidades encontradas nos trabalhos relacionados que possuiam experimentos relatados. É possível perceber que algumas das variabilidades mapeadas também estão presentes em trabalhos que não utilizam criatividade combina- cional, como por exemplo (MICH; ANESI; BERRY, 2005). O objetivo da nossa LPrS não

é demonstrar qual técnica é mais ecaz, mas sim mapear as variabilidades em técnicas de criatividade a m de auxiliar engenheiros de requisitos para que os mesmos possam implementar suas técnicas de criatividade combinacional mediante o contexto organizaci- onal do software. Na próxima seção relacionamos os trabalhos futuros identicados nesta dissertação.