Mapas Mentais na Engenharia de Requisitos - Trabalho Acadêmico

DANIELLE MATIAS MATUDA MAPAS MENTAIS NA ENGENHARIA DE REQUISITOS Assis 2012 The image cannot be displayed Your computer may not have enough memory to open the image or the image may have been corrupted Restart your computer and then open the file again If the red x still appears you may have to delete the image and then insert it again DANIELLE MATIAS MATUDA MAPAS MENTAIS NA ENGENHARIA DE REQUISITOS Trabalho apresentado ao Programa Institucional de Bolsas de Iniciação Científica PIBIC Orientanda Danielle Matias Matuda Orientador Luiz Carlos Begosso Linha de Pesquisa Ciências Exatas e da Terra Assis 2012 The image cannot be displayed Your computer may not have enough memory to open the image or the image may have been corrupted Restart your computer and then open the file again If the red x still appears you may have to delete the image and then insert it again Lista de Ilustrações Figura 1 Mapa Mental de um Mapa Mental 19 Figura 2 Meta Mapa Mental para o Levantamento de Requisitos 21 Lista de Tabelas Tabela 1 Frequência de respostas obtidas por pergunta realizada 23 Sumário 1 Introdução 1 11 Objetivo do Trabalho 2 12 Motivação 2 13 Metodologia de Trabalho 3 14 Estrutura do Trabalho 3 2 Engenharia de Requisitos 4 21 O Processo de Engenharia de Requisitos 6 22 Técnicas para o Levantamento de Requisitos 8 3 Mapa Mental 16 4 Emprego de Mapa Mental na Engenharia de Requisitos 20 5 Estudo de Caso 22 51 Participantes 22 52 Método de Pesquisa 22 53 Análise dos Resultados 22 6 Conclusão 25 Referências 26 1 Introdução Os processos que envolvem o desenvolvimento de um software são de caráter complexo e minucioso Para alcançar os objetivos desejados existe o envolvimento de muitos fatores tais como usuário analista de sistemas metodologias ferramentas entre tantos outro determinantes Por isso não existe um padrão ou fórmula que garanta o sucesso do produto final de software De acordo com Pressman 2006 a Engenharia de Requisitos é uma das primeiras etapas de alta relevância na elaboração de um sistema Ela tem como principal objetivo elicitar negociar especificar validar e gerenciar os requisitos propostos pelos clientes Um sistema computacional ao longo do seu desenvolvimento requer atenção antes de iniciar a programação ou seja é necessário que haja segurança no entendimento da proposta Logo no início do desenvolvimento do sistema deparase com uma das mais delicadas etapas presente na Engenharia de Requisitos o Levantamento de Requisitos Devido a sua complexidade e alto risco de falhas é considerada a etapa de maior fragilidade por Peter e Pedrycz 2001 Nesta fase encontramse os principais problemas que podem levar o software ao insucesso Podem ser eles a dificuldade do cliente em transmitir os requisitos falhas na comunicação entre analista e programador entre diversas outras questões conflitantes O software é elaborado a partir dos requisitos propostos Logo se houver falha na comunicação dos requisitos o sistema poderá não atender as expectativas do cliente Existem muitas técnicas que amparam o analista de sistemas na prática de elicitação e entendimento dos requisitos tais como entrevistas questionários cenários prototipagem casos de uso etnografia análise orientada a pontos de vista coleta colaborativa de requisitos e diversos outros amparos No entanto é evidente a necessidade de uma exploração mais detalhada em tais etapas Em meio a estas técnicas de aprimoramento no espaço que paira entre usuários e analistas podese destacar a ferramenta de aprendizagem de Mapa Mental Este método visa estimular a compreensão e a memorização de maneira simples e intuitiva Faz uso de poucas palavras grande utilização de cores setas e imagens tornandoo mais atrativo para nossa assimilação Também é conhecido por ser um método motivador na realização de uma tarefa Este trabalho propõe a elaboração de um meta mapa mental que guiado pelas diretrizes da Engenharia de Requisitos potencialmente conduza o analista de sistemas a recolher os requisitos dos usuários com menor grau de dificuldade possível 11 Objetivo do Trabalho O desenvolvimento deste trabalho é objetivado pelos estudos das etapas presentes na Engenharia de Requisitos e na técnica de aprendizagem denominada de Mapa Mental com o propósito de elaborar um meta mapa mental guiado pelas diretrizes existentes em cada tópico E que nele esteja contido os principais métodos de apoio para tornar o Levantamento de Requisitos menos suscetível a erros Pretendese verificar junto a desenvolvedores de softwares se o meta mapa obtido proporciona melhor entendimento dos requisitos de usuários do sistema 12 Motivação O constante relato de falhas em sistemas computacionais oriundos do Levantamento de Requisitos com algum tipo de conflito tornamse cada vez mais latentes no atual mercado de software De acordo com Muller 2010 estimase que a economia americana gasta com as falhas de sistemas computacionais o equivalente a 595 bilhões de dólares anualmente Cerca de 06 do produto interno bruto do país Muller 2010 também ressalta que entre os cinco maiores motivos apontados como causa de softwares desastrosos os problemas ligados aos requisitos aparecem em duas posições na lista Quando os requisitos de um projeto de software são desenvolvidos com falhas é altamente custoso para corrigir os erros existentes Os custos podem tornarse exorbitantes de acordo com o tamanho do projeto o tempo de trabalho é elevado o desgaste da equipe desenvolvedora e dos clientes se torna excessivo e outros inúmeros problemas acarretados por tais falhas podem ocorrer Em vista de tais informações é que se projetou a necessidade de uma alternativa que possivelmente conduzisse analistas de sistemas a elicitar requisitos de usuários com maiores possibilidades 13 Metodologia de Trabalho Para a realização deste trabalho foram utilizadas pesquisas intensas em materiais bibliográficos e digitais em diferentes tipos de fontes como por exemplo em livros artigos e sites de conteúdo adequados E também ao final do trabalho será apresentado um estudo de caso elaborado a partir das informações recolhidas no decorrer do presente trabalho 14 Estrutura do Trabalho O presente trabalho tem contido em sua estrutura quatro capítulos conforme apresentados a seguir Como visto até o momento o Primeiro Capítulo é a Introdução do trabalho que possui quatro seções objetivo motivação metodologia e este narrando a estrutura O Segundo Capítulo diz respeito a Engenharia de Requisitos Ele está dividido em duas seções O Processo de Engenharia de Requisitos e Técnicas para o Levantamento de Requisitos onde são descritas as definições aplicações importância relevância entre outros O Terceiro Capítulo é composto pelos conceitos informações e especificações de Mapa Mental O Quarto Capítulo é dedicado ao meta mapa mental elaborado descrevendo as particularidades nele contida O Quinto Capítulo é voltado ao Estudo de Caso realizado no trabalho Tem o propósito de exibir os resultados obtidos nos estudos E por fim o Sexto Capítulo apresenta as conclusões e as considerações finais sobre a utilização de Mapas Mentais no processo de Levantamento de Requisitos proposto neste trabalho 2 Engenharia de Requisitos A Engenharia de Requisitos faz se presente no contexto da Engenharia de Software É dito como um dos processos fundamentais no desenvolvimento de um sistema computacional Nesta etapa estão presentes os métodos ferramentas e técnicas necessárias desde a elicitação até a validação dos requisitos Na definição de Zave 1997 p 315 Engenharia de Requisitos é o ramo da engenharia de software relacionado aos objetivos do mundo real estabelecidos para as funções e restrições aplicáveis a sistemas de software Está também relacionada com a ligação entre esses fatores e a precisa especificação do comportamento do software e com sua evolução no tempo e através de família de produtos Para que se possa entender Engenharia de Requisitos é fundamental compreender o que são requisitos e a importância que ocupam no processo de desenvolvimento Em um conceito simples requisito pode ser denominado como as particularidades bem como as restrições que o usuário necessita que o software atenda No editorial da IEEE Software Glinz e Weringa 2007 p 18 citam que para construir um sistema útil precisamos conhecer os seus requisitos para saber os seus requisitos precisamos conhecer os desejos e necessidades dos interessados Para Peters e Pedrycz 2001 um requisito de software deve representar os principais elementos a cerca de um produto de software como seu comportamento propriedade e fluxo de informações O requisito compõe a estrutura para o desenvolvimento de um produto final visto que o nível de precisão e entendimento dos requisitos estabelecido pelo documento de requisito tende a ser relativo ao grau de qualidade resultante do sistema final As classificações mais comuns atribuídas aos requisitos são Requisito de Usuário Requisito de Sistema Requisito Funcional e Requisito Não Funcional De acordo com Sommerville 2007 os Requisitos de Usuário podem ser entendidos como sendo uma lista de declarações esperada pelo usuário das atividades a serem realizadas pelo sistema Para o autor tal lista de declarações pode ser representada em linguagem natural ou por diagramas Com relação a Requisitos de Sistema Sommerville 2007 destaca que eles descrevem as funcionalidades serviços e restrições operacionais que o sistema deve possuir A especificação funcional ou documento de requisitos segundo o autor tem por objetivo determinar com precisão o que será realizado no sistema Os Requisitos Funcionais informam o que o sistema deverá fazer Onde suas funcionalidades devem ser escritas em detalhes São requisitos que dependem do stakeholder parte interessada no sistema como usuário ou cliente e do tipo de sistema a ser desenvolvido Segundo Sommerville 2007 p 80 São as declarações de serviços que o sistema deve fornecer como o sistema deve reagir a entradas específicas e como o sistema deve se comportar em determinadas situações Em alguns casos os requisitos funcionais podem também estabelecer explicitamente o que o sistema não deve fazer Os Requisitos Não Funcionais de acordo com Sommerville 2007 estão conectados intimamente com a qualidade do software e suas propriedades emergentes como a confiabilidade tempo de resposta desempenho entre outros Não estão relacionados diretamente às funções específicas fornecidas pelo sistema computacional A ocorrência de falha em um requisito não funcional pode comprometer o sistema como um todo Por exemplo se um sistema que vai funcionar em tempo real não obedecer ao tempo de resposta ou desempenho proposto o sistema poderá ser inutilizado Em Sommerville 2007 p 83 existem três tipos de requisitos não funcionais Requisitos de produto Estes requisitos especificam o comportamento do produto Requisitos organizacionais Estes requisitos são derivados de políticas e procedimento da organização do cliente e do desenvolvedor Requisitos externos Este título amplo abrange todos os requisitos derivados de fatores externos ao sistema seu processo de desenvolvimento O surgimento dos requisitos não funcionais acontece desde as necessidades do usuário até aos fatores externos 21 O Processo de Engenharia de Requisitos O Processo de Engenharia de Requisitos segundo Sommerville 2007 tem como objetivo criar e manter um documento de requisitos de sistema É uma combinação de atividades prontamente organizadas Para Pressman 2006 este Processo implica em prover a interpretação correta e escrita do problema a ser resolvido para todas as partes interessadas no sistema Não existe um Processo de Engenharia de Requisitos padrão a ser seguido visto que cada organização tem sua própria necessidade Então é adequado que seja adotado um processo genérico que possa ser moldado de acordo com o que se necessita Embora não haja modelo padrão para tal processo autores sugerem como fazê lo De acordo com Pressman 2006 a tarefa de Engenharia de Requisitos é divida em sete fases concepção levantamento elaboração negociação especificação validação e gestão de requisitos Para o autor a concepção de um projeto tem início quando há necessidade de um novo negócio ou serviço Então profissionais como analistas de sistemas gerentes de projeto ou negócio examinam a abrangência do mercado em questão visando a viabilidade do projeto podendo assim proceder de mais informação O propósito nesta etapa é constituir uma base de entendimento do problema entre aqueles que necessitam da solução e os integrantes da equipe que desenvolveram a solução Na etapa de levantamento de requisitos também conhecida como elicitação de requisitos é primordial que o analista de sistemas tenha compreendido o domínio no qual o sistema irá operar pois quanto maior for o entendimento sobre o domínio melhor será a comunicação entre o analista e os stakeholders Nesta fase a concentração também deve estar voltada para os usuários do sistema pois poderão contribuir muito com o projeto De acordo com Pressman 2006 neste percurso podemse encontrar diversas dificuldades tais como o usuário não saber com precisão quais as necessidades do sistema a negligência de informações a dificuldade do cliente em transmitir os atributos desejáveis do software o relato de requisitos divergentes e conflitantes entre tantas outras dificuldades Pode ocorrer também a possível interpretação errônea dos requisitos pelo analista de sistemas É o Levantamento de Requisitos a fase mais propícia ao acarretamento de erros Na fase de elaboração segundo Pressman 2006 as informações anteriormente obtidas nas etapas de concepção e levantamento de requisitos são refinadas e estendidas A atividade de elaboração designa uma série de tarefas de modelagem e refinamento onde são criados cenários descritos pelo usuário informando como será a ação mútua entre o usuário final e o sistema Na negociação dos requisitos conforme Pressman 2006 é habitual que os stakeholders solicitem mais do que é preciso Por isso o analista tem a função de mediar este processo As partes interessadas no projeto como usuários e clientes são orientados a debater sobre a prioridade de cada requisito visando extinguir ao máximo os prováveis conflitos existentes Nesta etapa também é identificado e analisado o risco presente em cada requisito para que possa ser avaliado o impacto dos mesmos no custo do projeto e no prazo de entrega E para que todas as partes fiquem satisfeitas e confiantes o bom senso do analista deve prevalecer para com o cliente Na fase de especificação Pressman 2006 menciona que diferentes tipos de documentos ou modelos podem ser atribuídos como especificação de requisitos Nesta etapa cada requisito seja ele funcional ou não funcional deve ser descrito de modo preciso e explícito de acordo com o sistema que está sendo desenvolvido Para sistemas de grande porte Pressman 2006 recomenda que a especificação dos requisitos seja em documento escrito utilizando descrições em linguagem natural e representações gráficas No entanto para sistemas menores e com bom nível de entendimento o autor indica o emprego de cenários de uso Na etapa de validação de requisitos avalia se os resultados obtidos durante todo o processo anterior da Engenharia de Requisitos Segundo Pressman 2006 está fase verifica a especificação com o propósito de checar se os requisitos declarados não são ambíguos assegurar que inconsistências conflitos e erros tenham sido identificados e corrigidos e que todas as normas anteriormente definidas para o projeto estejam condizentes com as diretrizes obtidas O autor menciona que a melhor maneira de consolidar a validação é as partes interessadas no projeto cliente usuário analista entre outros inspecionem os requisitos provenientes da especificação a procura de qualquer tipo de lapso de conteúdo ou de interpretação Para Pádua 2003 os requisitos obtidos devem apresentar algumas características de qualidade para que posteriormente sejam validados São Correto Todo requisito realmente existente é uma condição a se satisfazer do sistema a ser construído Preciso Todo requisito existente pode ser interpretado de apenas uma maneira reconhecida pelo analista de sistemas e stakeholders Completo Demonstra todas as resoluções de especificação que foram decididas Consistente Que não tenha conflitos entre os requisitos existentes Priorizado Cada requisito existente é classificado mediante seu grau de importância estabilidade e complexidade Verificável Todos os requisitos existentes devem ser verificáveis Modificável A estrutura deve permitir a mudança de qualquer requisito de forma fácil completa e consistente Rastreável Admite que não se tenha dificuldades em determinar acontecimentos anteriores e consequências de todos os requisitos A última etapa proposta por Pressman 2006 é a gestão de requisitos Durante a existência de um sistema computacional ocorre o desejo de modificação nos requisitos por isso tornase necessário administralos A gestão de requisitos é uma relação de atividades que colaboram para a equipe envolvida no projeto identifique controle e rastreie os requisitos a qualquer tempo Este processo iniciase com a identificação dos requisitos onde cada um recebe um modo identificador Após a identificação são produzidas tabelas de rastreamento na qual cada uma expõe os requisitos identificados à atributos do sistema 22 Técnicas para o Levantamento de Requisitos A Engenharia de Software por meio dos processos envolvidos em suas etapas tem como intuito amparar o analista de sistemas em todo o desenvolvimento do sistema computacional No entanto mesmo seguindo essas diretrizes existem altos índices de falhas em projetos de softwares A justificativa para essas falhas que aparecem com maior incidência são problemas relacionados a Engenharia de Requisitos Precisamente na elicitação de requisitos A Engenharia de Requisitos é altamente iterativa ou seja uma etapa precisa da outra A elicitação por ser uma das primeiras etapas tornase decisiva para as subsequentes Se ela for realizada com falhas e se as mesmas não forem corrigidas a tempo provavelmente isso afetará diretamente o projeto final Essas falhas podem estar relacionadas a problemas na comunicação das partes envolvidas como o entendimento errado entre o analista de sistemas e o stakeholder ou na má interpretação entre o analista e o programador Os erros oriundos das falhas na elicitação dos requisitos são acompanhados de diversos tipos de prejuízos a elevação no tempo de desenvolvimento o retrabalho o desgaste e a baixa estima da equipe envolvida no projeto Estas características dependem diretamente do tamanho do projeto de sua complexidade o que poderá gerar custos exorbitantes Embora não exista nenhum método oficial ou padrão para o levantamento de requisitos autores e estudiosos do tema recomendam técnicas que apoiam o analista de sistema neste processo de elicitação Em Sommerville 2007 o autor menciona a utilização de entrevistas para obtenção dos requisitos Está técnica consiste em entrevistas formais ou informais com os stakeholders onde a equipe envolvida no processo de desenvolvimento do sistema elabora questões para os interessados As respostas obtidas são os requisitos De acordo com o autor as entrevistas podem ser classificadas em duas categorias 1 Entrevistas fechadas cujo stakeholder responde uma lista de perguntas predefinidas 2 Entrevistas abertas nas quais não há um conjunto de perguntas predefinidas onde o analista tem liberdade para tratar de diversos assuntos com os stakeholders podendo assim compreender melhor o que espera se do sistema Em ambientes reais Sommerville 2007 menciona que acontece um misto dos dois tipos de entrevistas pois as respostas obtidas em algumas perguntas podem levar a outros questionamentos menos formais O autor relata também que as entrevistas totalmente abertas não funcionam com total êxito É preciso que haja um ponto de partida para que não se perca o foco no sistema em questão Este meio de elicitação também torna se útil para que se possa tomar conhecimento da função dos stakeholders dentro do sistema como podem interatuar com o projeto em questão e também os obstáculos no sistema atual Entretanto para o autor as entrevistas são ineficazes para entender os requisitos de domínio da aplicação Ele recomenda o uso desta técnica combinada com outras De acordo com Kendall e Kendall 2010 as entrevistas precisam ser planejadas O autor sugere cinco passos para tal planejamento 1 Ler o material de fundo É importante pesquisar materiais atualizados que ajudem na tarefa de conhecer a empresa A pesquisa pode ser realizada no site da organização boletins informativos ou relatórios Também é necessário que o analista esteja atento ao vocabulário utilizado na empresa A comunição tende a ficar mais fácil quando o analista e os stakeholders tem a linguagem nivelada Com este passo podese também otimizar o tempo utilizado na entrevista 2 Estabelecer objetivos As informações coletadas na pesquisa sobre a empresa e os stakeholders bem como a experiência do analista de sistemas podem ser utilizadas para a formulação de perguntas tais como a utilidade e usabilidade do sistema o que a utilização do sistema proporcionará aos seus usuários fontes de informação frequência na tomada de decisão entre outros 3 Decidir quem entrevistar É ideal que na lista dos entrevistados estejam as pessoas chave das diversas classes da empresa O cliente também pode ajudar nesta escolha 4 Preparar o entrevistado A entrevista deve ser marcada com antecedência para que o entrevistado possa refletir sobre o assunto Se a entrevista a ser realizada for de caráter profundo é permitido que o analista envie um email contendo algumas questões No entanto é preferencial que as entrevistas sejam conduzidas pessoalmente com o tempo 45 minutos ou uma hora no máximo 5 Decidir sobre os tipos de perguntas e estrutura Técnicas adequadas de questionamento pode ser o ponto forte da entrevista É preciso decidir com cautela e verificar qual a melhor estrutura para a realização das perguntas A entrevista pode ser estruturada em três tipos distintos Estrutura de Pirâmide Estrutura de Funil e Estrutura de Diamante A estrutura em forma de Pirâmide segundo Kendall e Kendall 2010 iniciase com questões mais detalhadas e objetivas e que ao decorrer da entrevista o analista de sistemas pode inserir perguntas de aspecto geral É proveitoso também quando o entrevistado necessita aquecerse sobre o assunto em pauta No segundo tipo de estrutura o de Funil Kendall e Kendall 2010 destacam que iniciase com questões mais abertas de aspecto geral e de acordo com o avanço da entrevista o entrevistador introduzirá perguntas fechadas e objetivas Na Estrutura de Diamante Kendall e Kendall 2010 mencionam que é um misto dos dois tipos de estruturas anterior Iniciase com questões objetivas logo em seguida questões de aspecto geral e finalizase novamente com perguntas objetivas No entanto o tempo de duração de uma entrevista com este tipo de estrutura tende ser maior que as demais Estão ilustradas abaixo a os tipos de estruturas citadas Pirâmide Começa com questões objetivas Finaliza com questões gerais Funil Começa com questões gerais Finaliza com questões objetivas Diamante Começa com questões objetivas Questões gerais Finaliza com questões objetivas Em Kendall e Kendall 2010 é sugerido a utilização de Questionários como técnica no levantamento de requisitos Para os autores tal meio pode ser entendido como uma coleta de informações que permiti ao analista de sistemas unir as atitudes crenças comportamentos e características das pessoas que utilizaram o sistema computacional Kendall e Kendall 2010 também ressaltam que é uma técnica eficaz para se coletar respostas de um grande número de stakeholders Além de auxiliar no levantamento de questões importantes por exemplo antes de uma entrevista Contudo por ser um meio rápido e sucinto tornase limitado quando precisa se de um nível de detalhamento maior nas questões Então os autores recomendam que esta técnica seja praticada como apoio de outra Para Kendall e Kendall 2010 o uso de questionários é útil quando 1 Os stakeholders necessários estão em locais dispersos 2 Quando o projeto do sistema conta com um número significativo de stakeholder e tornase necessário saber a proporção de aprovação ou desaprovação de um requisito 3 Se precisar saber através de um estudo exploratório a opinião generalizada de todos os envolvidos antes do projeto continuar 4 Quando deseja se garantir que os conflitos com o sistema atual foram identificados e manejados De acordo com Kendall e Kendall 2010 as perguntas que compõe o questionário podem ser denominadas abertas ou fechadas As perguntas abertas devem ser restritas de maneira que conduzam os stakeholders a responder as questões de forma especifica A utilização de perguntas abertas em um questionário prevê quais respostas esperase ter Segundo os autores este tipo de pergunta é eficaz quando se quer obter a opinião dos usuários sobre alguma feição do sistema Em relação as perguntas abertas Kendall e Kendall 2010 destacam que devem ser utilizadas quando o analista de sistemas pode mensurar as possíveis respostas ou quando há uma notável amostra de pessoas a se pesquisar Para que se possa formular um bom questionário Kendall e Kendall 2010 recomendam que seja elaborado de acordo com a linguagem utilizada na empresa Para averiguar tal linguagem indicam que o questionário seja aplicado antes em um grupo de testes e que os mesmos dê atenção aos termos utilizados Kendall e Kendall 2010 propõe algumas diretrizes na composição de um questionário Sempre que possível é importante utilizar a linguagem dos stakeholders As perguntas elaboradas devem ser curtas e simples Elaborar perguntas que podem ser respondidas Utilizar perguntas precisas Segundo Kendall e Kendall 2010 os questionários podem ser aplicados aos stakeholders de diversas maneiras como por exemplo permitir que os mesmos administrem o momento em que vão responder o questionário Ou então reunir de uma só vez todos os interessados e aplicarlhes o questionário Também é possível o envio por Correio Eletrônico Seja via email ou qualquer outro meio virtual Em Sommerville 2007 é proposta outra ferramenta no auxílio da elicitação de requisitos a utilização de Cenários Segundo o autor os stakeholders em geral possuem maior facilidade em narrar exemplos verídicos do que prescindir descrições O analista por sua vez pode usar as informações alcançadas destas conversas para dispor os requisitos reais do sistema Para Sommerville 2007 este método consiste em descrições que são exemplificadas pelos stakeholders nas sessões de interação Cada cenário descrito compreende uma situação onde cada um provê de informações e particularidades diferentes Para o autor os cenários podem ser representados por textos e complementados por diagramas desenhos imagens digitais entre outros Conforme Sommerville 2007 um cenário é um início da interação que ao longo do processo de levantamento de requisitos tem as particularidades acrescentadas para concluir a descrição dessa interação Para o autor um cenário deve abranger os seguintes aspectos 1 No início do cenário deve haver uma representação ou descrição do que os stakeholders desejam do sistema 2 Uma representação ou descrição de fluxo normal de acontecimentos no cenário 3 Uma representação ou descrição do que é suscetível a erros e como isso é manejado 4 Instruções de atividades que podem acontecer simultaneamente 5 Uma representação ou descrição de como encontrase o sistema no fim do cenário Existe também para a elicitação de requisitos a técnica de Casos de Uso citada em Sommerville 2007 Segundo o autor o método é baseado em cenários e tornouse uma passagem essencial na UML Unified Modeling Language para representação de sistemas orientados a objetos De forma mais simplista um caso de uso assimila as interações e os que estão envoltos ao sistema No entanto para o autor é um método ineficaz para obtenção das restrições desejáveis bem como para a elicitação de requisitos de domínio A técnica de Etnografia também faz se presente em Sommerville 2007 Visto que pessoas de uma organização podem apresentar dificuldades para informar detalhes de seu trabalho a etnografia tenta preencher esta lacuna Conforme o autor este método consiste na técnica de observação que pode compreender os requisitos sociais e os requisitos organizacionais Um analista de sistemas introduzse na empresa que utilizará o sistema observa o trabalho realizado pelos colaboradores e faz anotações das tarefas existentes podendo assim descobrir os requisitos tácitos O valor atribuído a etnografia está no auxílio aos analistas de sistemas Podem revelar os requisitos ocultos de sistema que espelham os processos reais De acordo com Sommerville 2007 p 105 a etnografia tem melhor desempenho para identificar dois tipos de requisitos 1 Requisitos derivados da maneira como as pessoas realmente trabalham em vez da maneira pela qual as definições de processo dizem que elas deveriam trabalhar 2 Requisitos derivados da cooperação e do conhecimento das atividades de outras pessoas Segundo o autor os estudos obtidos durante o processo de etnografia podem revelar detalhes que outros métodos de levantamento de requisitos ignoram Contudo está prática não é adequada para obter os requisitos de domínio O autor recomenda que seja utilizada como complemento de outras técnicas Em Kendall e Kendall 2010 também é proposto para auxiliar a elicitação de requisitos a técnica da Prototipagem Visto que para usuários definir requisitos no papel ou expressálos ao analista de sistemas pode ser uma tarefa difícil e com alto teor de complexidade no entendimento realizar a construção de um protótipo inicial do sistema e extrair dos usuários os requisitos desejáveis pode tornarse mais fácil pois tratase de um método que estimula a pensar no sistema de maneira real Para Kendall e Kendall 2010 a Prototipagem permite ao analista de sistemas determinar as primeiras reações do usuário em relação ao sistema As reações podem ser adquiridas por meio de entrevistas observação relatórios e questionários que demonstram a opinião de cada pessoa a cerca do protótipo Tais informações são importantes para que o analista possa mensurar e estabelecer as prioridades bem como redirecionar o sistema Existem diferentes tipos de protótipos Kendall e Kendall 2010 classificam os como Patchedup Prototype Este tipo de protótipo tem apenas a camada de interface programada não contendo funcionalidades reais Ele possui todas as características necessárias do sistema mas é ineficiente Tornase útil para a interação do usuário com o sistema para que se familiarizem com as telas e os tipos de entradas e saídas de dados Protótipo Não Operacional Este segundo tipo de protótipo objetiva testar alguns aspectos do sistema em desenvolvimento Presume como deverá ser a rotina do software e implementase todas as camadas Os usuários do sistema também poderão tomar decisões á partir das entradas e saídas obtidas do protótipo Primeiro de Uma Série O terceiro tipo de protótipo consiste na criação de um primeiro modelo um piloto Primeiro realizase testes neste modelo piloto depois é desenvolvido os demais com características uniformes ao primeiro Protótipo de Características Selecionada Este tipo de protótipo estabelece a construção de um modelo operacional que abrange algumas das características que o sistema deverá ter Por exemplo se um usuário solicita seis funcionalidades distintas apenas três serão implantadas no protótipo e a medida que o cliente manuseia o présistema relata ao analista o que considera funcional e o que não for pertinente O desenvolvimento deste exemplar de protótipo é realizado através de módulos onde as características que foram admitidas com sucesso pelo usuário podem ser inseridas no sistema final assim evitando retrabalho de interface Também é possível que o analista de sistemas utilize um misto de diferentes tipos de protótipos pois cada um tem uma particularidade adequada a diversos sistemas Para a elaboração de um protótipo Kendall e Kendall 2010 indicam que seja obervada quatro importantes diretrizes 1 Trabalhar com módulos que possam administrados 2 Elaborar o protótipo com agilidade 3 Alterar o protótipo em iterações subsequentes 4 Enfatizar a interface do sistema com o usuário De acordo com Kendall e Kendall 2010 a utilização da técnica de Prototipagem como auxílio no Levantamento de Requisitos pode conduzir vantagens como O sistema ser alterado com maior antecedência durante o desenvolvimento A interrupção de um sistema que não mostrase satisfatório Capacidade de desenvolver um sistema que está mais próximo as exigências do usuário e que possa melhor atender as suas expectativas No entanto a Prototipagem também apresenta algumas desvantagens segundo Kendall e Kendall 2010 são elas Pode ser complexo construir um protótipo para sistemas de grande porte Os usuários e analistas de sistemas ao longo do projeto podem se confundir e adotar o protótipo como sendo o produto final Outra técnica proposta por Sommerville 2007 para a obtenção dos requisitos do sistema é a abordagem orientada a Pontos de Vista Segundo o autor este método identifica diversas perspectivas e subsidia o analista de sistemas a identificar requisitos críticos propostos por diferentes stakeholders De acordo com Sommerville 2007 existem três tipos genéricos de pontos de vista 1 Pontos de vista de interação Descrevem a interação direta que pessoas ou então sistemas diferentes possuem com o sistema em questão 2 Pontos de vista indiretos Descreve a influência dos usuários que não utilizam o sistema diretamente sobre os requisitos 3 Pontos de vista de domínio Descreve as particularidades e restrições de domínio que influenciam o sistema em questão Os pontos de vista mencionados acima podem fornecer um misto de diferentes requisitos por isso é importante que o analista de sistemas analise cada situação com cuidado De acordo com Sommerville 2007 qualquer sistema computacional de porte maior exibirá uma grande quantidade de pontos de vista o que torna praticamente nulo a chance de levantar os requisitos do sistema amparado em todos eles Portanto é primordial que o analista organize e estruture os pontos de vista em hierarquia Outro técnica de apoio para elicitar requisitos é sugerida por Pressman 2006 a Coleta Colaborativa de Requisitos O autor destaca que tratase de um método onde um grupo de usuários e uma equipe de desenvolvedores trabalham juntos para identificar os requisitos do sistema computacional bem como evidenciar soluções para os problemas que surgiram ao longo do desenvolvimento Como diretrizes básicas para este método Pressman 2006 propõe Pessoas da equipe de desenvolvimento do sistema e usuários conduzem e assistem as reuniões onde são determinadas regras Podese utilizar uma agenda para tomar nota de todos os pontos cruciais Alguém que esteja envolvido no projeto analistas ou usuários que desempenhe a função de facilitador e conduza a reunião A utilização de um mecanismo de definição como por exemplo folhas de rascunho papel auto adesivo entre outros O objetivo é a definição do problema solução para tal conflito negociar diversas abordagens e descrever com antecedência um conjunto de requisitos 3 MAPA MENTAL O surgimento dos mapas mentais aconteceu na década de 1960 pelo psicólogo e escritor inglês Tony Buzan A partir de observações sobre alunos e colegas de estudos Buzan verificou que mesmo sem dedicarem muito tempo e preparo estes conseguiam obter um resultado superior à maioria Ao analisar este cenário o psicólogo constatou que as pessoas utilizavam muitos desenhos cores símbolos e setas Também grifavam as principais palavras de um texto Ou seja destacavam os pontos que julgavam importante durante a leitura Segundo Buzan 2009 p 10 Os Mapas Mentais são um método de armazenar organizar e priorizar informações em geral no papel usando PalavrasChave e ImagensChave que desencadeiam lembranças específicas e estimulam novas reflexões e ideias Cada ativador da memória em um Mapa Mental é uma chave que dá acesso a fatos ideias e informações além de liberar o verdadeiro potencial da mente de modo que possamos nos tornar o que quisermos ser A técnica do Mapa Mental consiste em auxiliar na organização de pensamentos e ideias com maior rapidez e eficiência Tratase de um método que aguça a criatividade e estimula maior uso do potencial do cérebro visto que usamos apenas cerca de 1 um por cento de nossa capacidade cerebral A estrutura de um Mapa Mental é similar à maneira na qual o nosso cérebro armazena e assimila informações De acordo com Buzan 2009 o nosso cérebro conta com um enorme potencial onde pode se criar inúmeras ideias imagens e conceitos Para o autor um mapa mental funciona da mesma maneira que nosso cérebro é uma representação plena do Pensamento Radiante em trabalho A medida em que se alocam informações parecidas com a forma que o cérebro age naturalmente maior será a destreza para se recordar dos acontecimentos Dentro do método de Mapa Mental existem alguns conceitos essências para o entendimento das etapas envolvidas a Chave a PalavraChave e a ImagemChave Na definição de Buzan 2009 p introdução Chave A Palavra chave associada aos termos números palavra e imagem significa muito mais do que importante Ela indica que é uma chave para a memória PalavraChave A PalavraChave é um termo especial que é escolhido ou criado para ser uma referência única a algo importante de que desejamos nos lembrar As palavras estimulam o lado esquerdo do cérebro e são um recurso vital para mantermos o domínio da memória ImagemChave As ImagensChaves constituem a base da memória São combinações de palavras e imagens cuidadosamente construídas para trazerem à mente lembranças armazenadas no fundo da memória As ImagensChaves são o elemento central das minhas técnicas de memorização e de criação de Mapas Mentais Os Mapas Mentais podem ser utilizados para planejar diversas atividades nos mais distintos assuntos Desde a rotina de uma casa até a organização dos componentes de uma aeronave Auxiliam na disposição das tarefas escolares gerenciamento de projeto revisão de conteúdo na priorização de funções nas compras do dia a dia na vida familiar na lembrança de datas na comunicação entre incontáveis outros meios E com o uso continuo Buzan 2009 afirma que um mapa mental pode auxiliar no desenvolvimento da criatividade bem como promover ajuda para gerir novas ideias e propor novas soluções Na escrita ocidental a que estamos habituados as anotações são realizadas da esquerda para direita de cima para baixo e tem seu alinhamento linear Para nossa assimilação é algo monótono Os Mapas Mentais tem a estrutura diferente onde há um tema central cujas informações proliferam de dentro para fora tornandose assim mais atrativo para o nosso entendimento e assimilação Dentre as vantagens existentes da utilização dos Mapas Mentais em relação ao modo tradicional Buzan 2009 cita que a ideia central é fixada com maior visibilidade cada representação ou ideia é descrita com nitidez as ideias centrais que ficam ao centro do mapa mental tem sua identificação instantânea os conceitos chaves e suas conexões são reconhecidas de imediato podemse revisar os dados contidos no mapa mental com maior eficiência tem maior facilidade na adição de informações e pela individualidade na criação de um mapa mental as memórias são precisas Entre os princípios básicos de um Mapa Mental estão as regras São divididas em duas categorias Técnica e Desenho Na definição de Buzan 2009 p36 As regras relativas à técnica são Destaque Faça associações Seja Claro Desenvolva um estilo pessoal As regras relativas ao desenho são Use hierarquia Empregue uma ordem numérica Basicamente os materiais usados na confecção de um mapa mental são folhas de papel branco e sem pautas canetas lápis coloridos e muita imaginação Para dar início à elaboração de um Mapa Mental é necessário definir o objetivo que se espera alcançar Como Construção de um projeto Revisar o conteúdo escolar Programar o final de semana etc Realizada a definição do objetivo o primeiro passo segundo Buzan 2009 é representar no centro no mapa mental seja com desenho ou figura algo que exemplifique a meta a ser trilhada Começar no centro da folha não restringe o cérebro a usar apenas uma diretriz linear pode tomar todas as direções livremente Na segunda recomendação Buzan 2005 cita para que seja utilizada uma imagem ou uma representação por figura como ideia central Uma imagem central auxilia a manter o foco no assunto evitando mudança de direção O terceiro passo Buzan 2005 menciona que seja utilizado cores durante todo o trecho de elaboração do mapa Pois uso de cores no mapa mental o torna estimulante além de deixalo alegre O quarto passo Buzan 2005 cita que os ramos principais do mapa mental sejam ligados a imagem central e que os ramos secundários e terciários sejam conectados aos ramos primários e secundários Visto que o cérebro exerce suas funções por meio de Associação ligando os ramos o aprendizado se tornara mais fácil O quinto passo Buzan 2005 menciona que os ramos não devem ser desenhados em linha reta e sim curvos Os ramos curvos parecido com os galhos de uma árvore são mais atrativos aos nossos olhos enquanto os ramos de linha reta entediam o cérebro O sexto passo Buzan 2005 cita que na elaboração do mapa mental deve se utilizar apenas uma única Palavra Chave por linha Usando uma única Palavra Chave ou ImagemChave por linha o desencadeamento de novas ideias surge livre proporcionando novas associações O sétimo e ultimo passo proposto por Buzan 2005 menciona que utilize imagens desde o início do processo de elaboração do mapa mental até o seu fim A Figura 1 ilustra um exemplo de Mapa Mental Figura 1 Mapa Mental de um Mapa Mental Para Buzan 2005 uma imagem é muito importante para nossa associação de ideias onde apenas uma imagem no Mapa Mental equivale a 1000 palavras escritas 4 Emprego de Mapa Mental na Engenharia de Requisitos A Engenharia de Requisitos junto aos processos presentes nesta etapa tornase decisiva para a elaboração de um sistema computacional É imprescindível não passar por este trecho Na parte interior desta Engenharia deparase com o Levantamento de Requisitos visto anteriormente e considerado como a etapa mais delicada e suscetível a erros afinal se os requisitos elicitados apresentarem falhas e as mesmas não forem identificadas e corrigidas a tempo o sistema inteiro poderá ser inutilizado Quando visto de longe o levantamento de requisitos pode até parecer simples o analista de sistemas indaga o stakeholder sobre o que ele espera do software bem como os seus objetivos restrições entre outros e é prontamente correspondido com respostas certeiras do usuário No entanto na prática dificilmente acontece isso pois diversos fatores vistos no Capítulo 2 contribuem para a elicitação sem sucesso Visando buscar uma resolução para tal questão foi encontrada na metodologia de Mapas Mentais uma possível alternativa para auxiliar no Levantamento de Requisitos a elaboração de um meta mapa mental Conforme estudos apresentados no Capítulo 3 um Mapa Mental é uma técnica eficiente para armazenar informações e resgatalas de forma eficiente Seguindo as diretrizes para a elaboração de um Mapa Mental e as técnicas que autores sugerem para o Levantamento de Requisitos é que se obtém o meta mapa mental No meta mapa mental estão presentes as principais técnicas de Levantamento de Requisitos que o analista de sistemas poderá utilizar bem como as particularidades de percurso de cada um dos métodos para elicitar os requisitos desejáveis do usuário Cada técnica vigente no meta mapa tem suas principais características destacadas como os tipos de cada estrutura as formas de representações possíveis para cada método os materiais essenciais as relações entre todos os demais tópicos inerentes que estão presentes nas técnicas Desta forma o meta mapa mental elaborado direciona o analista diretamente as práticas mais relevantes de maneira simples e evidente A Figura 2 ilustra o meta mapa mental obtido para o auxílio no Levantamento de Requisitos Figura 2 Meta Mapa Mental para o Levantamento de Requisitos 5 Estudo de Caso Para que a meta objetivada no início deste trabalho fosse cumprida foi realizado um estudo de caso com profissionais que atuam no mercado de Tecnologia da Informação Sendo possível então avaliar através dos dados obtidos a relevância dos estudos alcançados 51 Participantes Para que o meta mapa mental fosse testado e que assim tornasse possível mensurar resultados foram selecionados nove pessoas para realizar tal experimento São eles analistas de sistemas ou desenvolvedores de sistemas com o ensino superior concluído em informática de diferentes faixa etária e experiência bem como com empregadores diversificados e que atuam no setor de tecnologia brasileiro e americano 52 Método de Pesquisa Como instrumento de pesquisa foi elaborado um questionário vide Anexo A Nele foram propostas sete questões objetivas que abordam diretamente a etapa de Levantamento de Requisitos e sobre a incidência do meta mapa mental na referida fase Os questionários foram enviados aos participantes através de email e as respostas também foram restituídas por email 53 Análise dos Resultados No questionário enviado aos analistas e desenvolvedores de sistemas teve em sua composição perguntas sobre a nota considerada em relação a importância do processo de Levantamento de Requisitos a dificuldade em realizálo a abrangência do meta mapa mental sobre a comunicação com os usuários sobre a possibilidade de continuar o uso do meta mapa para elicitar requisitos entre outros assuntos conectados com o trabalho A Tabela 1 apresenta em forma de porcentagem a frequência de respostas obtidas para cada pergunta realizada Tabela 1 Frequência de respostas obtidas por pergunta realizada Pergunta Resposta Frequência 1 0 1 2 3 4 5 6 7 8 9 10 0 0 0 0 0 0 0 0 0 0 100 2 0 1 2 3 4 5 6 7 8 9 10 0 0 1111 0 0 1111 0 0 5555 2222 0 3 Não Um pouco Sim 0 0 100 4 Não Um pouco Sim 0 0 100 5 Não Um pouco Sim 0 2222 7777 6 0 1 2 3 4 5 6 7 8 9 10 0 0 0 0 0 0 0 0 4444 2222 3333 7 Não Talvez Sim 0 4444 5555 Examinando os dados da primeira questão Indique numa nota de 0 a 10 o quanto você considera importante a atividade de Levantamento de Requisitos é possível perceber a unanimidade dos participantes em relação a importância da atividade de Levantamento de Requisitos Esta informação pode justificar a quantidade de problemas existentes em tal etapa Com relação a segunda questão Indique numa nota de 0 a 10 o quanto você considera difícil a atividade de Levantamento de Requisitos podese notar que a maioria dos participantes com um total de 7777 classifica o grau de dificuldade no processo de Levantamento de Requisitos acima da nota 8 oito enquanto um número menor de participantes de 2222 classifica uma nota menor ou igual a 5 cinco Através das respostas obtidas da terceira questão Você acha que a comunicação com o clienteusuário poderia melhorar com o uso do mapa mental é que se pode mensurar a importância do uso do meta mapa mental em prol da comunicação com o usuáriocliente Todos os participantes 100 atribuíram a mesma resposta positiva para tal indagação Também houve resposta unanime para a questão de número quatro Você acha que o mapa mental é uma ferramenta que complementa a sua atividade de levantamento de requisitos Onde os participantes em sua totalidade atribuíram que o mapa mental é uma ferramenta que complementa a atividade de Levantamento de Requisitos Na quinta questão O Levantamento de Requisitos foi mais simples com o uso do mapa mental onde os participantes foram questionados se o Levantamento de Requisitos foi mais simples com a utilização do meta mapa mental não houve resposta negativa Um montante com resultados de 2222 opinaram informando que Um pouco enquanto que 7777 confirmaram com a resposta Sim Em relação a sexta pergunta As técnicas contidas no mapa mental são suficientes para elicitar os requisitos Dê uma nota de 0 a 10 que exprima sua opinião onde é questionado se as técnicas apresentadas pelo meta mapa mental são suficientes para elicitar requisitos os analistasdesenvolvedores de sistemas participantes consideraram notas iguais ou superiores a 8 oito Sendo 4444 atribuídos a nota 8 oito 2222 concedidos a nota 9 nove e 3333 determinados a nota 10 dez A sétima e última pergunta proposta Você passará a usar o mapa mental durante o processo de Levantamento de Requisitos questionou os participantes se passariam a fazer uso do meta mapa mental no Levantamento de Requisitos Como argumentos não houve nenhuma resposta negativa Um total de 5555 de participantes responderam que Sim Ou seja passaram a utilizar a ferramenta como auxílio na Elicitação de Requisitos Uma outra parte que corresponde a 4444 responderam que Talvez passariam a utilizar 6 Conclusão Mediante aos estudos apresentados neste trabalho foi possível visualizar a importância e relevância da Engenharia de Requisitos e suas etapas ao longo do desenvolvimento de um sistema computacional visto que esta Engenharia pode ser considerada a base para a elaboração de um software com sucesso O processo de Levantamento de Requisitos uma das mais delicadas fases presente neste contexto mostrou que apesar dos diversos recursos que auxiliam os analistas de sistemas a obter êxito no produto de software final necessita de mais ferramentas a colaborar com os profissionais da área de informática Foi possível também conhecer os principais conflitos incidentes nesta etapa bem como as sugestões indicações e recomendações para minimizálos Contudo maiores estudos neste processo ainda são necessários Tornouse possível também discernir com maior profundidade os Mapas Mentais que apresentaram ser um método de aprendizagem altamente explorável na Engenharia de Software Com a junção dos conceitos apresentados nos Capítulos 2 e 3 foi possível a elaboração do meta mapa mental que teve em seu conteúdo as principais práticas que podem favorecer a atividade de Levantamento de Requisitos A partir do meta mapa mental foi realizado um estudo de caso para que se pudesse mensurar a proposta idealizada pelo trabalho checando a validade dos resultados alcançados com o trabalho em questão Com a confecção do questionário e as respostas alcançadas através dos participantes do estudo foram identificados vestígios determinantes e positivos a utilização do meta mapa mental no amparo ao Levantamento de Requisitos Visto que as respostas negativas em praticamente todo o questionário foram mínimas Enquanto que as respostas positivas sobre a utilização do meta mapa mental e sua eficácia foram em sua maioria consideradas benéficas Portanto acreditase que os dados presentes neste trabalho podem contribuir ao estudo de viabilizar o uso dos Mapas Mentais na atividade de Levantamento de Requisitos Referências PRESSMAN Roger S Engenharia de Software 6ª Ed Tradução de Rosângela Delloso Penteado São Paulo Editora McGraw Hill Interamericana do Brasil Ltda 2006 PETERS James F PEDRYCZ Witold Engenharia de Software Tradução de Ana Patrícia Machado de Pinho Garcia Rio de Janeiro Editora Campus 2001 MULLER Peter Requirements Elicitation Zurich Disponível em httpwwwpminfethzcheducationcoursesksearchive2011lectures Acesso em 15 jun2012 ZAVE Pamela Classification of Research Efforts in Requirements Engineering ACM Computing Surveys 1997 GLINZ Martin WERINGA Roel J Guest Editors Introduction Stakeholders in Requirements Engineering Washington Disponível em httpswwwcomputerorgcsdlmagsso200702s2018html Acesso em 12 nov2011 PÁDUA Wilson P F Engenharia de Software Fundamentos Métodos e Padrões 3ª Ed Rio de Janeiro Editora Ltc 2009 SOMMERVILLE Ian Engenharia de Software 8ª Ed Tradução de Selma Shin Shimizu Melnikoff Reginaldo Arakaki Edílson de Andrade Barbosa São Paulo Editora Pearson 2007 KENDALL Kenneth E KENDALL Julie E Systems Analysis and Design 8º ed New Jersey Editora Prentice Hall 2011 BUZAN Tony Mapas Mentais Tradução de Paulo Polzonoff Junior Rio de Janeiro Editora Sextante 2009 BUZAN Tony Mapas Mentais e sua elaboração Tradução de Euclides Luiz Calloni Cleusa Margô Wosgrau São Paulo Editora Pensamento Cultrix LTDA 2005 GODDART Derek What is a Mind Map New Zealand Disponível em httpwwwmindwerxcommindevents20090521advancedmindmapping masterclasstonybuzanbrisbane Acesso em 05 jan2012 Anexos Anexo A Questionário elaborado Pesquisa sobre Técnicas de Levantamento de Requisitos 1 Indique numa nota de 0 a 10 o quanto você considera importante a atividade de Levantamento de Requisitos 0 1 2 3 4 5 6 7 8 9 10 2 Indique numa nota de 0 a 10 o quanto você considera difícil a atividade de Levantamento de Requisitos 0 1 2 3 4 5 6 7 8 9 10 3 Você acha que a comunicação com o clienteusuário poderia melhorar com o uso do mapa mental Não Um pouco Sim 4 Você acha que o mapa mental é uma ferramenta que complementa a sua atividade de levantamento de requisitos Não Um pouco Sim 5 O Levantamento de Requisitos foi mais simples com o uso do mapa mental Não Um pouco Sim 6 As técnicas contidas no mapa mental são suficientes para elicitar os requisitos Dê uma nota de 0 a 10 que exprima sua opinião 0 1 2 3 4 5 6 7 8 9 10 7 Você passará a usar o mapa mental durante o processo de Levantamento de Requisitos Não Talvez Sim