Utilizando Grounded Theory para Compreender a Aceitação de uma Técnica de Elicitação de Requisitos

Transcrição

1 Utilizando Grounded Theory para Compreender a Aceitação de uma Técnica de Elicitação de Requisitos Amadeu Anderlin Neto, Cristina Araújo, Horácio A. B. F. Oliveira, Tayana Conte Departamento de Ciência da Computação, Universidade Federal do Amazonas Av. Rodrigo Octávio, CEP Manaus, Amazonas Brasil {neto.amadeu,crisoara,horacio,tayana}@dcc.ufam.edu.br Abstract. The requirements elicitation phase is critical to the software project success. If the requirements are not well defined, the entire project development cycle can be compromised. Therefore, it is necessary to use a requirements elicitation technique that is suitable for a particular situation. However, few analysts make use of different elicitation techniques. This paper proposes the use of Grounded Theory in the qualitative analysis of the acceptance of a particular technique for requirements elicitation. Preliminary results, obtained from an exploratory research in a software development company, indicate the main factors when accepting and using a new elicitation technique. Resumo. A fase de elicitação de requisitos é fundamental para o sucesso do projeto de software. Se os requisitos não forem bem definidos, todo o ciclo de desenvolvimento do projeto pode ser comprometido. Por isso, faz-se necessário utilizar uma técnica de elicitação de requisitos que seja adequada a uma determinada situação. No entanto, são poucos os analistas que fazem uso de diferentes técnicas de elicitação. Este artigo propõe a utilização do método Grounded Theory na análise qualitativa de aceitação de uma determinada técnica de elicitação de requisitos. Resultados iniciais, obtidos a partir de uma pesquisa exploratória em uma empresa, indicam os fatores mais críticos na aceitação de uma nova técnica de elicitação. Palavras-chave: elicitação de requisitos, análise qualitativa, Grounded Theory. 1. Introdução A Engenharia de Requisitos abrange as atividades de elicitação (levantamento), análise (negociação), especificação e validação de requisitos (Kotonya e Sommerville, 1998). Segundo Dieste et al. (2008), embora a elicitação de requisitos pareça ser uma atividade simples, na verdade, é uma das mais complexas no processo de desenvolvimento de software. Para a atividade de elicitação, há uma série de métodos e técnicas que são empregadas para se obter os requisitos (Nuseibeh e Easterbrook, 2000). No entanto, na maioria dos casos, a informação é capturada apenas por meio de entrevistas, embora não haja evidências de que as entrevistas sejam sempre a melhor opção para extrair as necessidades do usuário (Carrizo et al., 2008).

2 Uma das áreas de pesquisa em Engenharia de Requisitos é a identificação de quais são as técnicas mais adequadas para elicitação. Dentre exemplos de pesquisa nessa área pode-se citar a revisão sistemática conduzida por Dieste et al. (2008) sobre seleção de técnicas de elicitação de requisitos e também o estudo sobre a adequação de técnicas de elicitação feito por Carrizo et al. (2008), que propõe um framework para auxiliar os desenvolvedores a selecionar as melhores técnicas de elicitação. Embora seja muito importante apontar quais as melhores técnicas de elicitação, igualmente importante é entender por que, existindo tantas técnicas, entrevistas são usadas na maioria das vezes. Faz-se necessário investigar a aceitação de técnicas de elicitação em diferentes contextos. Quais os fatores que levam um analista a adotar uma determinada técnica de elicitação? Supõe-se que estes fatores não sejam fatores simplesmente técnicos e sim sócio-técnicos, que consideram aspectos relacionados à adequação da técnica ao processo de desenvolvimento e ao contexto do projeto. Neste trabalho, é apresentado um estudo de caso sobre a aceitação de uma determinada técnica de elicitação de requisitos, no contexto de uma empresa de desenvolvimento de software. Trata-se de um estudo qualitativo, de caráter exploratório, que visa investigar a aceitação (e utilização) de uma determinada técnica de elicitação por analistas que adotavam, principalmente, entrevistas. Os dados coletados no estudo foram analisados através do método Grounded Theory. Segundo Easterbrook et al. (2007), os métodos de pesquisa qualitativa são métodos interpretativos, que analisam os aspectos ligados às pessoas, que são objetos de pesquisa, observação dos fatos do ponto de vista de alguém interno ao problema e compreensão profunda do contexto da situação estudada. Ao realizar este estudo qualitativo, buscamos aumentar a compreensão dos fatores que impactam na aceitação e consequente utilização de uma técnica de elicitação de requisitos por analistas. Através deste trabalho, quatro importantes contribuições para a área de Engenharia de Requisitos e, mais especificamente, na elicitação de requisitos são apresentadas. Primeiro, é apresentado um relato da condução do estudo de caso. Em segundo, são apresentados os resultados da análise qualitativa sobre aspectos que levam à aceitação de uma técnica de elicitação de requisitos. Terceiro, procura-se contribuir com a disseminação do método de pesquisa qualitativa junto à comunidade de pesquisadores em Engenharia de Requisitos. Por último, uma contribuição muito importante do presente trabalho é a proposição de utilização do método Grounded Theory para a análise qualitativa dos dados coletados neste tipo de estudo. O restante deste artigo está organizado como segue. A Seção 2 apresenta um breve referencial teórico sobre técnicas de elicitação e descreve a técnica que foi utilizada no estudo de caso. A Seção 3 apresenta resumidamente o método de pesquisa qualitativa utilizado no estudo: Grounded Theory (GT). A Seção 4 descreve o planejamento e a execução do estudo de caso. A Seção 5 discute os resultados da análise qualitativa. Por fim, a Seção 6 apresenta as conclusões e lições aprendidas com essa experiência.

3 2. Técnicas de Elicitação de Requisitos A maioria dos problemas no processo de desenvolvimento de software é atribuída aos requisitos do software. Requisitos que não refletem as reais necessidades dos usuários, incompletos e/ou inconsistentes, mudanças em requisitos que foram acordados e a dificuldade para conseguir um entendimento comum entre usuários e desenvolvedores são as principais dificuldades relatadas, provocando re-trabalho, atrasos no cronograma, custos ultrapassados e a insatisfação dos clientes e usuários do software (Kotonya e Sommerville, 1998). Para tentar minimizar esses problemas, surgiram as técnicas de elicitação de requisitos. As técnicas existentes são utilizadas em determinados cenários, ou até mesmo, adaptadas a eles. Segundo Nuseibeh e Easterbrook (2000), as técnicas de elicitação de requisitos são divididas em: técnicas tradicionais, técnicas em grupo, técnicas de prototipação, técnicas orientadas a modelos e técnicas cognitivas e contextuais. As técnicas tradicionais são as mais comumente utilizadas, mas nem sempre são aplicadas de forma proveitosa. Devem ser bem planejadas para que os resultados sejam satisfatórios. Alguns exemplos de tais técnicas incluem as entrevistas e os questionários. As técnicas em grupo são realizadas com a finalidade de definir restrições e funcionalidades do projeto. Como exemplos têm-se o Brainstorming e o JAD (Joint Application Design). As técnicas de prototipação são utilizadas quando o protótipo puder ser desenvolvido muito mais rápido que o sistema real. Exemplos: protótipo descartável e protótipo evolutivo. As técnicas orientadas a modelos são baseadas em cenários e casos de uso. Os cenários fornecem uma descrição de como o sistema será usado. Através dos casos de uso, são identificados os atores e, assim, pode-se observar seu comportamento ao interagir com o sistema. As técnicas cognitivas e contextuais são card sorting e etnografia, respectivamente. A finalidade da primeira é descobrir como o usuário classifica determinada informação. A segunda tem por definição a observação, para que haja uma compreensão social e organizacional dos requisitos. O objetivo maior é fazer com que o observador absorva a prática e não a teoria. Neste artigo, foi escolhida uma única técnica de elicitação para verificarmos se seria aceita ou não por analistas de uma empresa. Foram analisadas quais técnicas os analistas da empresa não conheciam e, então, foi escolhida uma técnica para ser apresentada. Descartou-se a possibilidade de apresentar mais de uma técnica, pois isto poderia causar viés no aprendizado, dificultando a aceitação. Desta forma, a técnica escolhida no estudo de caso foi a técnica de elicitação utilizando mockups em wireframe, que é uma técnica de prototipação. Tal técnica será descrita na seção seguinte.

4 2.1. Técnica de Elicitação Utilizando Mockups em Wireframe Unger e Chandler (2009) definem um projeto baseado na experiência do usuário como a criação e sincronização dos elementos que afetam a experiência dos usuários em uma empresa, com a intenção de influenciar as suas percepções e o seu comportamento. Seguindo essa proposta, Unger e Chandler (2009) sugerem a utilização de protótipos visuais (mockups) desenhados utilizando wireframes para elicitar requisitos. Para explicar melhor o que é um mockup, é necessário entender a prototipagem. De acordo com Unger e Kane (2009), prototipagem é o ato de criar e testar toda ou parte da funcionalidade de uma aplicação ou site com os usuários. Um mockup desenhado com wireframe é um protótipo de baixa fidelidade de uma página da web ou da tela de uma aplicação. Um wireframe é usado para identificar os elementos que serão exibidos na página ou na tela como navegação, seções de conteúdo, necessidades de imagem ou mídia, elementos de forma e chamadas para as funcionalidades do sistema, conforme os requisitos fornecidos pelo usuário. Para construir os mockups é necessária uma série de requisições que podem ser providas pelo cliente ou pelo resumo do projeto: (1) entender que tecnologia será utilizada na aplicação; (2) compreender o ambiente onde esta aplicação será implantada; (3) saber que tipo de usuário vai utilizar o sistema e; (4) conhecer como os usuários poderão interagir com o sistema, ou seja, quais as tarefas que deverão ser executadas. Depois da realização desta análise, a construção do protótipo é simples e rápida. O analista pode fazer rascunhos com lápis e papel, ou mesmo em quadro branco, das telas que pretende projetar. Feito este rascunho das telas, ele deve fazer a transferência para uma solução tecnológica que tenha mais familiaridade (tal como um editor visual, um editor de apresentações). A escolha de uma ferramenta visual adequada permite que o analista possa modificá-los ao lado do usuário, realizando últimos ajustes ou tirando dúvidas que podem ter ficado na última reunião. Após a descrição da técnica utilizando mockups em wireframe, os procedimentos do método GT são apresentados na seção seguinte. 3. Método Grounded Theory para Análise Qualitativa O método de pesquisa GT, que pode ser traduzido como Teoria Fundamentada em Dados, foi desenvolvido como alternativa à tradição hipotético-dedutiva da sociologia da década de 1960 (Glaser e Strauss, 1967). Os autores defendiam que as teorias existentes eram muito abstratas e propuseram um método de pesquisa que descobrisse os elementos da teoria sociológica de forma mais fácil. Por isso, GT tem como objetivo gerar explicações sobre ações dos indivíduos, porque e como determinados grupos interagem com outros grupos em situações específicas, de acordo com um contexto delimitado a partir da realidade vivida por esses grupos. De acordo com Montoni e Rocha (2007), GT é uma técnica qualitativa indicada para estudar o comportamento humano e a cultura organizacional, por isso a escolha em utilizá-la como base para a análise dos resultados do presente estudo. Strauss e Corbin (1998) definem o termo GT como teoria derivada de dados sistematicamente coletados e analisados. A GT se preocupa em gerar uma teoria substantiva com alto poder explicativo, que seja capaz de explicar como e por que ocorrem diferentes formas de comportamento e como podem se modificar no decorrer do tempo.

5 Para analisar os dados com GT, utiliza-se a codificação que, segundo Douglas (2003), é o resultado de fazer questionamentos e dar respostas provisórias sobre categorias e suas relações. Essas respostas são avaliadas nas três fases do processo de codificação sugerido por Strauss e Corbin (1998), que são: aberta, axial e seletiva. Codificação aberta envolve a quebra, a análise, a comparação, a conceituação e a categorização dos dados. A finalidade da codificação aberta é gerar e validar propriedades e categorias por meio de constantes comparações. À medida que as entrevistas são lidas, o pesquisador identifica segmentos de dados como citações, objetos e eventos e os conecta em código. Segundo Bandeira-de-Mello e Cunha (2006), nas fases iniciais da codificação aberta, o pesquisador explora os dados examinando minuciosamente aquilo que lhe parece relevante devido à leitura intensiva dos textos. Codificação axial segundo Strauss e Corbin (1998), essa fase nos mostra o relacionamento entre as categorias e subcategorias, de acordo com suas propriedades e dimensões identificadas na primeira fase. Durante a codificação axial é feita uma análise para tentarmos obter respostas para as seguintes perguntas: Por quê?, Como surgiu?, Onde?, Quando?, Como? e Com quais resultados? (Montoni e Rocha, 2007). Com as categorias e subcategorias criadas, precisamos fazer os relacionamentos dos códigos que foram encontrados na análise. Como proposto por Strauss e Corbin (1998), essa relação pode ser definida pelo pesquisador e podem ser: condições causais, intervenientes, consequências e estratégias de ações ou interações. A Tabela 1, adaptada de Conte et al. (2009), apresenta uma sugestão de conectores, com base na linha proposta por Strauss e Corbin (1998). Tabela 1. Conectores de Códigos (Conte et al., 2009). Símbolo Rótulo Descrição das Relações Isa Is a O código-origem é um tipo, ou forma, do código-destino. É definido por um padrão de variação dimensional ao longo das propriedades da categoria (código-destino). == Is associated O código-origem e o código-destino têm conceitos específicos with relacionados. => Is cause of O código-origem (condição causal) causa a ocorrência do código-destino. [ ] Is part of O código-origem é uma parte que compõe juntamente com outras partes o código-destino. Codificação seletiva o objetivo desta fase é integrar e refinar a teoria (Strauss e Corbin, 1998), identificando uma categoria central (core category), que deve ser relacionada com todas as outras categorias. A categoria central deve ser capaz de integrar todas as outras categorias e expressar a essência do processo social que ocorre entre os envolvidos. Esta categoria central pode ser uma categoria existente, ou uma nova categoria que pode ser criada pelo analista. As próximas seções apresentam o estudo de caso e a análise qualitativa de seus resultados, com base no método GT. 4. Estudo de Caso - Utilização de uma Nova Técnica de Elicitação Com o intuito de analisar a aceitação de uma determinada técnica de elicitação de requisitos, através de sua utilização, foi realizado um estudo de caso, utilizando-se o método GT como base para a análise qualitativa dos dados obtidos.

6 O estudo de caso, segundo Easterbrook et al. (2007), é uma investigação experimental de um fenômeno contemporâneo dentro de seu contexto da vida real, especialmente quando as fronteiras entre o fenômeno e o contexto não estão claras. O estudo de caso é utilizado como investigação inicial de alguns fenômenos para derivar hipóteses e construir teorias. A Tabela 2 apresenta o objetivo deste estudo de caso definido através do paradigma GQM (Goal-Questions-Metrics), que sugere que o objetivo de um estudo experimental em engenharia de software seja elaborado de forma estruturada (Basili e Rombach, 1988). Analisar Com o propósito de Em relação à Do ponto de vista No contexto de Tabela 2. Objetivo do estudo de caso segundo o paradigma GQM. a aceitação de uma técnica de elicitação de requisitos caracterizar identificação de fatores que impactam na aceitação e utilização da técnica dos analistas uma empresa de desenvolvimento de software Participaram deste estudo inicial dois analistas da empresa, sendo um analista pleno (com 8 anos de experiência) e um analista júnior (com 2 anos de experiência). Além da participação dos analistas, houve também um pesquisador especialista na técnica de elicitação baseada em mockups, descrita na Seção 2.1, um pesquisadorobservador e um pesquisador que participou na análise dos dados. O pesquisador especialista fez uma apresentação na empresa dos analistas, onde a técnica de elicitação foi ensinada. Após a apresentação, foi realizada uma entrevista com cada um dos analistas com questões que tratavam sobre o entendimento e a aceitação da técnica baseada em mockups. Durante duas semanas, foi feita uma observação na empresa para que fosse possível obter dados de aceitação e utilização da técnica. Após o período de observação, foi feita outra entrevista com questões relacionadas à utilização da técnica. Todas as questões eram subjetivas, onde o entrevistado responde de forma livre. Com isso, nas duas entrevistas foram feitos questionamentos sobre três diferentes perspectivas: entendimento, aceitação e utilização da técnica. A Figura 1 mostra parte do questionário utilizado nas entrevistas. I Questões sobre o Entendimento da Técnica: I.1) Como você entendeu a técnica? I.2) O que mais chamou sua atenção na técnica? I.3) Qual(is) a(s) dificuldade(s)/facilidade(s) em aprender a técnica? I.4) Você ficou com alguma dúvida sobre como utilizar a técnica? II Questões sobre Aceitação da Técnica: II.1) Do seu ponto de vista, quais as principais facilidades/ dificuldades da técnica?... Figura 1. Parte do questionário utilizado nas entrevistas. Após a realização das entrevistas, foi feita a análise dos dados qualitativos utilizando o método GT. Na próxima seção, são apresentados a realização da análise qualitativa e os resultados obtidos.

7 5. A Análise Qualitativa com o Método Grounded Theory Após a transcrição das entrevistas, foi realizada a análise qualitativa dos dados. Conforme sugerido por Bandeira-de-Mello e Cunha (2003), foi eleito um questionário como fonte inicial de exploração dos dados. Com auxílio do software Atlas.ti 1, foi iniciada a etapa de codificação aberta, conforme ilustrado na Figura 2. Os códigos gerados eram relacionados a citações do questionário, respondido pelo entrevistado, referentes ao entendimento, aceitação e utilização da técnica de elicitação baseada em mockups. Dois pesquisadores fizeram a análise inicial e, posteriormente, a revisaram com um terceiro pesquisador. Após esta revisão, foi iniciada a codificação do outro questionário, seguindo a mesma sistemática inicial, ou seja, analisando os dados e criando códigos. Figura 2. Exemplo de um código relacionado com a citação no texto na etapa de codificação aberta. Ao final da codificação aberta, os códigos gerados foram agrupados de acordo com suas propriedades. Iniciando a etapa de codificação axial, notou-se que os códigos gerados durante a codificação aberta poderiam ser melhorados de modo que o relacionamento entre eles fosse melhor compreendido. Com isso, foi feita uma revisão completa da codificação aberta e, ao final, foram gerados trinta e dois códigos. Em relação à codificação axial, foram identificadas quatro categorias associadas aos códigos: Adaptação da técnica à realidade da empresa, Problemas da utilização da técnica de entrevistas, Facilidades da utilização da técnica e Dificuldades da utilização da técnica. Todas essas categorias têm relação com a questão de pesquisa sobre fatores que impactam na aceitação de uma técnica de elicitação de requisitos. A Figura 3 apresenta os códigos associados à categoria Adaptação da técnica à realidade da empresa. Os códigos desta categoria mostram que a técnica baseada em mockups foi aprendida e utilizada. É mostrado também que a técnica foi adaptada e adotada pela empresa, sendo utilizada em conjunto com as entrevistas, técnica que os analistas utilizavam antes. O pesquisador-observador percebeu que essa adaptação se deu da seguinte forma: (1) os analistas continuaram utilizando as entrevistas, como primeiro instrumento de elicitação de requisitos; (2) depois de analisar e organizar os requisitos, os analistas desenvolviam telas que ilustravam como determinada funcionalidade se comportaria e as exibiam para o cliente; (3) o cliente solicitava modificações que eram rapidamente atendidas; (4) novas telas eram desenvolvidas e exibidas para o cliente, até que chegavam a um consenso. Para fazer observações, comentários e explicações de idéias que surgiram no decorrer da análise, os pesquisadores fizeram uso de um elemento gráfico chamado Memo, que permite registrar notas da análise sobre afirmações, hipóteses ou questões 1 Atlas.ti The Knowledge Workbench, Scientific Software Development

8 (Montoni e Rocha, 2007). O Memo que aparece na Figura 3 contém as notas de análise sobre a relação de causa entre o aprendizado e a utilização da técnica. Figura 3. Representação gráfica das associações relacionadas à categoria Adaptação da técnica à realidade da empresa. Pode-se notar que em cada código, são apresentados dois números. O primeiro representa o grau de fundamentação do código (groundedness). O segundo representa o grau de densidade teórica (density). O grau de fundamentação identifica a quantidade de citações com que o código está relacionado. O grau de densidade teórica identifica a quantidade de relacionamentos de um código com os demais. Os códigos que apresentam grau de fundamentação igual a zero representam as categorias e subcategorias as quais não possuem associação com citações dos questionários. Como motivação para a utilização da técnica, foram identificados códigos relacionados a citações dos analistas sobre a técnica que eles costumavam utilizar: (1) o processo de construção de sites é lento e difícil e (2) existem mudanças que afetam todo o projeto. O primeiro código indica que o processo de desenvolvimento que o analista costumava seguir, gerava algumas dificuldades no decorrer do projeto. O segundo código representa a situação citada de que, de acordo com as mudanças que o cliente solicitava, o projeto sofria alterações de cronograma, custo e esforço. Esses códigos foram associados à categoria Problemas da utilização da técnica de entrevistas, que relaciona aspectos que motivaram a utilização da técnica baseada em mockups. A Figura 4 mostra a categoria relacionada com as duas citações. A nota de análise apresentada nesta figura informa que os entrevistados citaram problemas que ocorriam antes da técnica ser utilizada. Figura 4. Associações da categoria Problemas da utilização da técnica de entrevistas. Além da motivação, os entrevistados apontaram várias facilidades da técnica relacionadas ao entendimento, aceitação e utilização. Foram identificados três aspectos distintos relacionados às facilidades. Para cada aspecto, foram criadas as seguintes subcategorias: Aspectos de facilidades relacionados à técnica, Aspectos de facilidades relacionados ao projeto e Aspectos de facilidades relacionados aos

9 clientes. Estas subcategorias estão diretamente relacionadas com a categoria chamada Facilidades da utilização da técnica, que pode ser visualizada na Figura 5. A nota de análise contém as definições de comprometimento e interatividade, além de explicar a relação de causa entre os códigos Comprometimento do cliente com o projeto e Interatividade com o cliente. A subcategoria Aspectos de facilidades relacionados à técnica possui cinco códigos associados através da relação é um tipo. Por outro lado, a subcategoria Aspectos de facilidades relacionados ao projeto possui apenas três códigos associados através da mesma relação, é um tipo. Estes códigos não estão sendo exibidos na Figura 5, que mostra apenas uma parte da categoria. Figura 5. Representação gráfica das associações relacionadas à parte da categoria Facilidades da utilização da técnica. Por fim, os entrevistados citaram também algumas dificuldades relacionadas ao entendimento, aceitação e utilização da técnica. É importante salientar que algumas dificuldades citadas pelos analistas não ocorreram, efetivamente, durante a utilização da técnica, mas os entrevistados acreditam que podem vir a acontecer. Foram identificados dois aspectos distintos relacionados à categoria Dificuldades da utilização da técnica, que pode ser vista na Figura 6. Um destes aspectos está diretamente ligado aos clientes e é representado através da subcategoria Falta de disponibilidade do cliente. O outro aspecto relacionado à categoria é o de Dificuldade em elaborar os wireframes.

10 Figura 6. Representação gráfica das associações relacionadas à categoria Dificuldades da utilização da técnica. No estudo de caso apresentado, não foi definida a categoria central que explica o principal fator de aceitação da técnica de elicitação de requisitos baseada em mockups. Isso porque foi feita apenas uma coleta de dados, o que não permite validar as propriedades das categorias geradas. Segundo Bandeira-de-Mello e Cunha (2006), uma das principais características de aplicação de GT é a circularidade entre as fases de coleta e de análise dos dados. Como continuação desta pesquisa, pretende-se realizar novas coletas de dados, com diferentes analistas/empresas. A partir destas novas coletas, novas categorias, conceitos e relacionamentos podem surgir. De acordo com Bandeira-de-Mello e Cunha (2006), deve-se coletar e analisar os dados sistematicamente até a saturação teórica ser atingida. Portanto, quando a coleta e análise de novos dados não possibilitam um ganho significativo de explicação teórica, a validação do que foi proposto pode ser obtida na codificação seletiva, onde a teoria substantiva é integrada. Os resultados coletados até o momento permitiram a identificação preliminar de fatores que os analistas julgaram relevantes para a aceitação de uma técnica de elicitação. Pode-se notar que problemas com a técnica usada anteriormente motivaram os analistas a tentar utilizar a técnica baseada em mockups. Entre os fatores que facilitaram a aceitação da técnica, os analistas destacaram tanto fatores que impactam na interação com o cliente, quanto fatores relacionados ao ciclo de desenvolvimento do projeto. Um ponto importante para a utilização da técnica foi a possibilidade de adaptação da mesma à realidade da empresa. Os resultados obtidos são bastante promissores. Entretanto, faz-se ainda necessário coletar novos dados com diferentes analistas e empresas para efetuar uma análise mais abrangente dos fatores que impactam à aceitação de uma técnica de elicitação de requisitos. Tais experimentações serão realizadas em trabalhos futuros. 6. Conclusões e Lições Aprendidas No presente trabalho foram apresentados os resultados iniciais de uma pesquisa exploratória sobre fatores que impactam na aceitação de uma técnica de elicitação de requisitos. Apesar da importância dos trabalhos que mostram porque determinada técnica de elicitação é mais adequada, do ponto de vista técnico, para se obter determinado resultado, também é preciso entender quais os fatores sócio-técnicos que

11 levam um analista a decidir adotar ou não uma determinada técnica de elicitação. Com este propósito, foi realizado um estudo de caso em uma empresa de desenvolvimento de software, onde dois analistas foram apresentados à técnica de elicitação de requisitos baseada em mockups. Para capturar a percepção dos analistas em relação aos fatores que os levaram a utilizar a técnica, foram realizadas entrevistas com questões subjetivas, analisadas com base nos procedimentos do método qualitativo GT. A categorização proposta é inicial e poderá ser alterada quando novos estudos forem realizados, considerando, ainda, o aperfeiçoamento dos instrumentos de coleta de dados e da abordagem utilizada. Mafra e Travassos (2006) afirmam que uma desvantagem do estudo de caso é a dificuldade em se generalizar os resultados obtidos. Não é possível generalizar os resultados do presente estudo, pois apenas foi coletada a percepção de analistas de uma única empresa com relação a uma determinada técnica. Em outro contexto, a percepção dos fatores relevantes para a aceitação de uma técnica de elicitação pode apresentar variações. Entretanto, mesmo com as limitações em relação à generalização dos resultados, espera-se contribuir com este trabalho para uma compreensão mais abrangente sobre fatores críticos para aceitação de técnicas de elicitação. Pesquisas qualitativas definem um foco reduzido de abordagem de um problema para poder investigá-lo com a necessária profundidade (Leitão, 2009). De acordo com Shull et al. (2004), nenhum estudo sobre uma determinada tecnologia pode ser considerado definitivo. Portanto, devem ser realizados mais estudos, em diferentes contextos, para que os resultados se tornem mais precisos e confiáveis. Desta forma, tendo em vista os resultados promissores obtidos através deste estudo inicial, sugere-se como trabalhos futuros a continuação desta pesquisa, através da realização de novos estudos de caso em diferentes cenários: outras empresas com analistas de diferentes perfis e apresentação de outras técnicas de elicitação. Agradecimentos Agradecemos à organização e aos analistas que participaram deste estudo. Agradecemos também o apoio financeiro da FAPEAM e do CNPq por meio dos projetos / e / Referências Bandeira-de-Mello, R., Cunha, C. (2003). Operacionalizando o Método da Grounded Theory nas Pesquisas em Estratégia: Técnicas e Procedimentos de Análise com Apoio do Software Atlas/ti. Encontro de Estudos em Estratégia. Curitiba, Brasil. Bandeira-de-Mello, R., Cunha, C. (2006). Grounded Theory. In: Godoi, C. K., Bandeira-de-Mello, R., Silva, A. B. d. (eds), Pesquisa Qualitativa em Estudos Organizacionais: Paradigmas, Estratégias e Métodos, Capítulo 8, São Paulo, Saraiva. Basili, V., Rombach, H. (1988). The Tame Project: Towards Improvement-oriented Software Environments. IEEE Transactions on Software Engineering 14(6):

12 Carrizo, D., Dieste, O., Juristo, N. (2008). Study of Elicitation Techniques Adequacy. 11º Workshop on Requirements Engineering (WER 2008), pp Conte, T., Cabral, R., Travassos, G. H. (2009). Aplicando Grounded Theory na Análise Qualitativa de um Estudo de Observação em Engenharia de Software Um Relato de Experiência. 5º Workshop Um Olhar Sociotécnico sobre a Engenharia de Software (WOSES 2009), pp Dieste, O., Lopez, M., Ramos, F. (2008). Updating a Systematic Review about Selection of Software Requirements Elicitation Techni ques. 11º Workshop on Requirements Engineering (WER 2008), pp Douglas, D. (2003). Grounded Theories of Management: a Methodological Review. Management Research News, v. 26, n. 5, pp Easterbrook, S., Singer, J., Storey, M., Damian, D. (2007). Guide to Advanced Empirical Software Engineering. Springer-Verlag, Nova Iorque, Capítulo 11 Selecting Empirical Methods for Software Engineering Research. Glaser, B., Strauss, A. (1967). The Discovery of Grounded Theory: Strategies for Qualitative Research. Nova Iorque, Aldine Transaction. Kotonya, G., Sommerville, I. (1998). Requirements Engineering: Processes and Techniques. John Wiley and Sons. Leitão, C. (2009). Métodos Qualitativos de Pesquisa Científica. Computação Brasil: Interação Humano-Computador no Brasil, pág Mafra, S., Travassos, G. H. (2006). Estudos Primários e Secundários Apoiando a Busca por Evidência em Engenharia de Software. Rio de Janeiro, COPPE/UFRJ. Montoni, M., Rocha, A. R. (2007). A Methodology for Identifying Critical Success Factors That Influence Software Process Improvement Initiatives: An Application in the Brazilian Software Industry. Software Process Improvement 14º European Conference, EuroSPI 2007, Potsdam, Alemanha, Springer Berlin / Heidelberg. Nuseibeh, B., Easterbrook, S. (2000). Requirements Engineering: a Roadmap. Em: Proceedings of the Conference on the Future of Software Engineering (Limerick, Irlanda, junho 04-11, 2000). ICSE ACM Press, Nova Iorque. Shull, F., Mendonça, M., Basili, V., Carver, J., Maldonado, J., Fabbri, S., Travassos, G., Ferreira, M. (2004). Knowledge-sharing Issues in Experimental Software Engineering. Empirical Software Engineering, v. 9, ed. 1-2, março. Strauss, A., Corbin, J. (1998). Basics of Qualitative Research: Techniques and Procedures for Developing Grounded Theory. Thounsand Oaks: Sage Publications. Unger, R., Chandler, C. (2009). A Project Guide to UX Design: For User Experience Designers in the Field or in the Making, Capítulo 11, New Riders. Unger, R., Kane, J. (2009). A Project Guide to UX Design: For User Experience Designers in the Field or in the Making, Capítulo 12, New Riders.