Resumo: O levantamento de requisitos é uma das atividades mais importantes na construção de sistemas. Para ser executada eficientemente, faz-se necessário familiarizar-se com as ferramentas de produtividade utilizadas para capturar os resultados do trabalho de levantamento de requisitos. Novas ferramentas e técnicas para a captura das funcionalidades dos sistemas surgem freqüentemente, sempre buscando facilitar o processo e a melhoria dos artefatos produzidos. O mapa mental permite a diagramação do pensamento, em um formato não linear, assumindo o tipo de estrutura que a nossa memória utiliza e que o aprendizado humano obedece a essa sistemática. O uso de mapas mentais pode facilitar a compreensão dos requisitos e o seu correto mapeamento, conforme as necessidades do cliente. Se cada analista de requisitos seguisse esses passos, a produtividade no levantamento de requisitos aumentaria, melhorando a qualidade dos sistemas e aumentando a satisfação dos clientes.
1. Introdução
Sendo um dos principais responsáveis pela qualidade final dos sistemas construídos, o levantamento de requisitos, disciplina da engenharia de software, necessita cada vez mais de analistas de requisitos capazes de interpretar e transcrever aos desenvolvedores as funcionalidades indispensáveis para o bom funcionamento de um software.
Existem várias metodologias e processos construídos exclusivamente para o levantamento de requisitos. Dentre elas podemos falar que o RUP e a UML são unânimes entre os analistas de requisitos e a indústria da tecnologia da informação.
A proposta desse artigo não é em hipótese alguma tentar substituir esses processos já consolidados, mas sim apresentar uma técnica inovadora usada para armazenar, organizar e priorizar informações: o Mapa Mental.
Nesse artigo será apresentado o uso de Mapas Mentais como um recurso capaz de facilitar na compreensão das fases do levantamento de requisitos, auxiliando de forma significativa a capacidade de aprendizado, memorização e planejamento.
2. A importância do Levantamento de Requisitos
A qualidade de um sistema está diretamente relacionada com a correta compreensão das funcionalidades que ele irá possuir. Essa função fica a cargo de um profissional chamado Especificador de Requisitos ou Analista de Requisitos, que dentre as suas aptidões precisa de boas habilidades de comunicação seja para sua própria expressão oral ou para escrever o documento que sintetiza o sistema com as suas regras de negócios, fluxos de eventos, requisitos funcionais, requisitos não funcionais, restrições, dentre outras coisas. A esse documento ou artefato é dado o nome de Especificação de Caso de Uso.
O correto uso de uma ferramenta ou técnica para a captura desses requisitos facilita o entendimento do sistema, evitando que erros em tempo de projeto existam.
Segundo Pressman (2006), cerca de 60% dos erros ocorrem já na fase de elaboração do projeto, nas atividades exercidas pela engenharia de requisitos e análise de sistemas. Obviamente esses erros podem ser corrigidos antes do final do projeto. Porém, o custo para a correção desses erros tende a aumentar conforme o sistema vai chegando próximo a sua versão final. Após a sua entrega, a correção de um defeito pode custar até 1.000 vezes mais que na fase de levantamento dos requisitos.
Dados coletados por Boehm (1981) demonstram esse fenômeno (figura 1).
Figura 1: Custo Relativo do Conserto de um Erro.
Fonte: Boehm (1981)
Muitos fatores influenciam na correção de um defeito. Na verdade, não é uma tarefa simples entender o custo de se corrigir um defeito. Esse custo pode ser influenciado pela escolha do ciclo de vida do produto e até a forma que é realizado o seu desenvolvimento. Tudo isso tem grande influência na hora de decidir colocar um sistema que teve um grande número de incidências de erros durante a sua criação em produção.
Algumas empresas, por mais absurdo que isso possa parecer, não sabem o custo de se corrigir um defeito dentro da sua organização. Para se chegar a uma estimativa os defeitos encontrados precisam ser mapeados e corrigidos. A detecção dos defeitos é apenas o primeiro passo. Posteriormente deve-se localizar o motivo da falha, decidir como a mesma deve ser corrigida, desenvolver os testes (unitários, de sistema, de integração, etc.), aplicar os testes para as correções e procurar por possíveis defeitos que a correção pode ter causado.
Sem um mapeamento preciso do custo de correção, levando-se em conta, ainda, outros fatores como a experiência da equipe, complexidade do defeito, tempo para corrigir o defeito, tecnologia utilizada, dentre outras, os números jamais serão coesos. O que se sabe é que o custo de correção de um sistema tende a aumentar com o passar dos anos e, ainda mais, com a constante evolução da tecnologia.
Certamente, a melhor maneira para evitar os altos custos de correção sejam evitá-los desde o início, investindo na qualidade do levantamento de requisitos.
2.1. O que são Requisitos?
Segundo o RUP[1], um requisito é definido como uma condição ou um recurso com o qual um sistema deve possuir e estar em conformidade. O RUP utiliza a abordagem da orientação a objetos e a notação UML[2] para ilustrar os processos em ação.
Sendo então um requisito algo que um produto deve fazer ou uma qualidade que deve ter, vários deles podem fazer parte de um sistema. Devido à diferença de uso e aplicação entre eles, os mesmos podem ser categorizados em três categorias: requisitos funcionais, requisitos não-funcionais e restrições.
Os requisitos funcionais especificam as ações que um determinado sistema deve ser capaz de executar, sem levar em consideração possíveis restrições físicas. Na verdade requisitos funcionais são Casos de Uso, embora não sejam todos, que indicam o que o sistema deverá executar, especificando os comportamentos de entrada e saída.
Os requisitos funcionais são normalmente descritos em um documento de Especificação de Caso de Uso. Esse tipo de requisito é normalmente levantando junto ao cliente e aos usuários que irão utilizá-lo. Existem várias maneiras de fazer a coleta desses requisitos, cabendo a cada Analista de Requisitos, fazendo uso da sua experiência ou de um processo, identificar a melhor maneira de mapeá-las.
Na figura 2 podemos ver um exemplo do Diagrama de Caso de Uso com alguns requisitos funcionais:
Figura 2: Diagrama de Casos de Uso.
Fonte: Autoria própria (2010)
Esse simples exemplo de Diagrama de Casos de Uso construído com a notação UML apresenta um sistema de automação bancário onde um ator identificado como Cliente pode executar algumas operações como Autenticar no Sistema, Efetuar Depósito ou Retirar Extrato.
Obviamente um sistema bancário pode possuir de dezenas a milhares de operações disponíveis, vários atores e outros tipos de transações. Imagine o esforço necessário para levantar todos esses requisitos. Pense agora se não houvesse padrões para modelar os sistemas, processos para gerenciar os requisitos ou ferramentas para aumentar a produtividade. Seria humanamente impossível desenvolver sistemas de qualidade e ainda entregá-los dentro do prazo desejado pelo cliente. Isso tudo sem falar no alto custo de desenvolvimento que eles teriam e sem nenhuma forma de mensurar os seus gastos durante as várias fases que a construção de software possui.
Os requisitos não-funcionais descrevem apenas os atributos do sistema, atributos do ambiente do sistema ou qualidades do produto. De acordo com Grady (1992), uma maneira de categorizá-los é descrita como o modelo FURPS+, onde retirando-se a letra “F” que representa os requisitos funcionais, o "URPS" restante representa as principais categorias que podem ser usadas para definir as suas respectivas subcategorias, conforme será exibido a seguir:
· Usability (Usabilidade) – avalia a interface com o usuário. Dentre as suas subcategorias, podemos destacar: estética e design, prevenção de erros, consistência, padrões e documentação.
· Reliability (Confiabilidade) – referente à integridade, conformidade e interoperabilidade do software. Os possíveis requisitos são: freqüência e gravidade de falha, possibilidade de previsão, possibilidade de recuperação, exatidão, tempo médio entre falhas (MTBF[3]).
· Performance (Desempenho) – avalia os requisitos de desempenho do software. Podem ser medidos de várias maneiras, dentre elas: consumo de memória, utilização da CPU, tempo de resposta, disponibilidade da aplicação e capacidade de carga.
· Supportability (Suportabilidade) – esses requisitos agrupam várias características como: adaptabilidade, compatibilidade, configurabilidade, testabilidade, manutenibilidade, escalabilidade e instalabilidade.
O símbolo "+" na sigla FURPS+ é usado para identificar outras categorias que representam, geralmente, as restrições (EELES, 2007). As restrições são requisitos globais como a finalidade do produto ou os usuários que irão atender. São aplicáveis ao produto como um todo e normalmente são especificados antes do início da obtenção dos demais requisitos.
Segundo Eeles (2007), esses requisitos podem ser agrupados nas seguintes categorias:
· Requisitos de design – Esse tipo de requisito é normalmente chamado de uma restrição de design e especifica ou restringe as opções para a concepção de um sistema. Podem incluir: um banco de dados relacional, o uso de ferramentas de desenvolvimento, uma biblioteca de classes, dentre outros.
· Requisitos de implementação – especifica ou restringe o código ou a construção de um sistema. Os exemplos podem ser:
o padrões obrigatórios;
o linguagens de implementação;
o políticas de integridade de banco de dados;
o limites de recursos;
o ambientes operacionais.
· Requisitos de interface – especifica um item externo com o qual o sistema deve interagir, ou restrições de formatos ou de outros elementos, dentro de uma interação. Podem ser: uma opção de filtro na emissão de um relatório, um botão para gerar um gráfico, a resolução das imagens, o tamanho da interface do sistema, dentre outros.
· Requisitos físicos – especifica uma limitação física imposta ao hardware utilizado, por exemplo: material, forma, tamanho ou peso. Podem, ainda, representar requisitos de hardware como as configurações físicas de rede obrigatórias.
Podemos perceber que a tarefa de levantamento de requisitos exige um alto grau de conhecimento de vários métodos, padrões, técnicas e modelos de documentos para uma correta compreensão das necessidades do cliente.
Devido à complexidade que os sistemas atuais exigem, faz-se necessária uma forma mais prática e eficaz que permita ao Analista de Requisitos preocupar-se mais com o entendimento das regras de negócios, os fluxos de eventos do caso de uso (básico, alternativo e exceção) traduzindo-as de forma compreensível para os desenvolvedores, e menos tempo com a confecção da documentação do software.
Como a grande maioria dos sistemas desenvolvidos hoje em dia necessita de um conjunto de requisitos semelhantes, um modelo com as etapas de sua coleta pode ser construído, baseando-se nos principais processos e modelos apresentados até o momento juntamente com uso de mapas mentais.
Obviamente, outros modelos devem ser construídos ou ainda serem reescritos conforme a notação dos mapas mentais, facilitando o entendimento do sistema, os seus fluxos de atividades, as trocas de mensagens e outros tipos de diagramas indispensáveis para a construção de um software.
Mas para isso é preciso saber o que é um mapa mental e de que maneira ele pode ajudar na qualidade do desenvolvimento de sistemas. Essas e outras questões serão explicadas no capítulo 3, logo a seguir.
3. Os Mapas Mentais
O Mapa Mental (Mind Map®[4]) é um recurso que canaliza a criatividade, porque faz uso de todas as habilidades relacionadas a ela, sobretudo a imaginação, a associação de idéias e a flexibilidade. (BUZAN, 2009).
O uso de Mapas Mentais é uma maneira rápida, prática e clara de organizar, armazenar e priorizar qualquer tipo de conhecimento, idéia, processo, tarefa, dentre outras atividades necessárias para o aprendizado, memorização e planejamento. É possível agrupar em pouco tempo uma grande quantidade de conhecimento em um pequeno espaço, poupando escrever muitas ligações.
Diferente dos sistemas tradicionais de anotação, que fazem uso de texto e listas, o Mapa Mental não opta por um esquema de registro linear. Desenhado como um neurônio[5], ele reproduz o modo com essa célula se liga a outras no cérebro, concebendo uma rede natural de conexões que se irradiam em torno de uma idéia principal.
Um Mapa Mental utiliza todas as habilidades do cérebro para interpretar palavras, imagens, números, conceitos lógicos, ritmos, cores e percepção espacial com uma técnica simples e eficiente. Ele nos dá a liberdade de ir onde quer que nossa mente nos leve. (BUZAN, 2009)
Os Mapas Mentais são, portanto, instrumentos que permitem reproduzir, de certa forma, o que aprendemos e memorizamos fazendo relações com aprendizados anteriores, numa complexa rede neural. Os Mapas Mentais são, portanto, um sistema que auxilia no aprendizado, na organização do aprendizado, na assimilação de novas informações e também é uma excelente forma para tomar notas.
Enfim, o Mapa Mental é uma ferramenta altamente produtiva para capturar de forma não linear uma idéia principal, que é colocada no centro de uma folha de papel branco, proporcionando maior visibilidade das idéias. As idéias são descritas apenas com palavras chaves e podem ser ilustradas com imagens, ícones e muitas cores.
Um Mapa Mental é organizado e hierarquizado seguindo os tópicos de um assunto, ao mesmo tempo em que sintetiza, fornece a visão global, mostra os detalhes e as interligações do assunto e, por fim, utilizando figuras e cores, permite registrar e reter os dados com o máximo de agilidade e eficiência, liberando todo o potencial criativo da mente. (BUZAN, 2009)
Segundo Buzan (2009) os Mapas Mentais podem ser usados para os mais diversos e qualquer propósito na vida: A lista a seguir exibe alguns exemplos:
· Na escola – leitura, revisão de conteúdo, anotações, desenvolvimento de idéias criativas, gerenciamento de projetos, ensino.
· No trabalho – geração de idéias, gerenciamento de tempo, elaboração de projetos, formação de equipes, apresentações.
· Em casa – estabelecimento de prioridades, planejamento de projetos e da vida, compras, gerenciamento de acontecimentos e da vida familiar.
· Na vida social – lembrança de datas importantes, recordação de pessoas e lugares, planejamento de atividades de lazer e eventos pessoais, comunicação.
Sabendo que o uso de Mapas Mentais é capaz de aumentar de forma significativa nossa capacidade de aprendizado, memorização e planejamento, podemos afirmar que com o uso dessa técnica é possível melhorar o processo de Levantamento de Requisitos. Porém, é preciso saber como construir um Mapa Mental, como aplicá-lo e como usá-lo nessa tarefa árdua de muitos Analistas de Requisitos.
No próximo item desse capítulo será exibida a forma de criação dos Mapas Mentais.
3.1. Elaborando um Mapa Mental
Um Mapa Mental pode ser elabora apenas fazendo o uso de uma folha papel sem pautas e lápis ou canetas coloridas. As cores estimulam a imaginação e fornecem uma melhor visão do todo.
Seja o Mapa Mental apenas um esboço com rápidas idéias ou algo mais detalhado, deve-se colocar as informações que são importantes conectadas aos pontos do assunto sendo desenhado.
Existem diversos softwares disponíveis comercialmente ou em versões gratuitas que podem ser usados para facilitar a elaboração dos Mapas Mentais. Essa é com certeza a maneira mais eficiente de desenhar um Mapa Mental.
Fazendo o uso de uma ferramenta ou de papel e caneta, as etapas de criação de um Mapa Mental são as mesmas. Para elaborar um Mapa Mental, siga os passos a seguir:
1º. Defina qual é o assunto, tópico, tarefa, idéia ou problema a ser mapeado.
2º. Levante o máximo de informações sobre o tema que foi definido.
3º. A partir do centro desenhe uma imagem ou escreva uma palavra que represente o assunto sobre o qual será desenvolvido o Mapa Mental.
4º. Faça ramificações ao redor do assunto central e escreva nelas palavras-chave ligadas a ele.
5º. Não é recomendado escrever várias palavras na mesma ramificação. Cada palavra deve ser tratada como uma unidade, ficando assim livre para pendurar nela tantos outros conceitos seja necessário.
6º. Use imagens sempre que possível.
7º. Normalmente um Mapa Mental é lido no sentido horário. Porém, alguns Mapas Mentais podem possuir milhares de ramificações, dificultando a sua leitura e assimilação por pessoas menos experientes. Para facilitar o entendimento acrescente números para hierarquizar a importância ou indicar uma ordem adequada.
8º. Faça a quantidade necessária de revisões para ter um Mapa Mental completo e que ajude ao máximo alcançar o seu objetivo.
A figura 3, logo abaixo, foi construída utilizando os passos sugeridos. Nela são exibidos requisitos baseados no modelo FURPS+, citado no item 2.1 deste artigo:
Figura 3: Mapa Mental para Levantamento de Requisitos usando o Modelo FURPS+.
O nível de detalhamento escolhido para construir o Mapa Mental foi alto, chegando até ao ponto de dar uma breve descrição de cada requisito. Essa informação pode ser suprimida, deixando a visualização mais limpa. Porém, para uma memorização mais fácil por parte de Analistas menos experientes, as descrições foram inseridas com o intuito de evitar erros de interpretação durante a fase de coleta de requisitos.
O uso de cores e figuras auxilia na interpretação das categorias. Dessa forma é possível memorizar os conceitos de uma forma mais rápida, acrescentando foco e tornando-o mais atrativo. Isso também ajudará a expandir a mente estimulando tanto o lado direito quanto o lado esquerdo do cérebro. (BUZAN, 2009)
Vale à pena ressaltar que os requisitos funcionais inseridos na imagem são comumente utilizados em vários sistemas. Normalmente os requisitos funcionais são levantados junto ao cliente e o seu funcionamento detalhado no documento de Especificação de Caso de Uso, fazendo uso ou não do RUP e a UML, assuntos tratados anteriormente neste artigo.
De posse do conhecimento necessário para a confecção de Mapas Mentais, partiremos agora para o seu uso no Levantamento de Requisitos, assunto do próximo capítulo.
4. Usando Mapas Mentais no Levantamento de Requisitos
O levantamento e a análise de requisitos é essencial para descobrir junto aos clientes e usuários as informações sobre o domínio da aplicação, os serviços que devem possuir, o desempenho esperado, as restrições de hardware e de software, dentre outras coisas.
É um processo difícil por envolver diferentes tipos de pessoas com diversos tipos de envolvimento com o sistema. Segundo Somerville (2003) o termo stakeholder é utilizado para se referir a qualquer pessoa que terá alguma influência direta ou indireta sobre os requisitos do sistema.
Diante desses fatos, a adoção de um processo de levantamento e análise de requisitos é altamente recomendada. A figura 4 exibe um modelo genérico construído com o uso de Mapa Mental para o levantamento e análise, podendo ser alterado conforme as necessidades de cada organização.
Figura 4: Mapa Mental do Processo de Levantamento e Análise de Requisitos
Fonte: Fonte: Sugestão do autor, customizada a partir de (SOMMERVILLE, 2003)
As atividades do processo apresentado são:
1. Compreensão do domínio – o analista de requisitos deve desenvolver a compreensão do domínio da aplicação. Por exemplo, se for um sistema de automação bancária, o analista deverá descobrir como operam as instituições bancárias. Nessa etapa o analista pode utilizar diversas técnicas para auxiliá-lo como:
o Entrevista – consiste em entrevistas com os stakeholders em busca de extrair os problemas correntes no processo de negócio, as suas necessidades e seus desejos para o sistema.
o Workshop – consiste numa reunião estruturada, da qual devem fazer parte um grupo de analistas e os stakeholders, para então obter um conjunto de requisitos bem definidos. Diferentemente de uma reunião, promove-se a interação entre todos os elementos presentes com momentos de descontração como forma de dinamizar o trabalho em equipe, existindo um facilitador neutro cujo papel é conduzir a workshop e promover a discussão entre os vários participantes.
o Brainstorm – sessão de discussão do analista em conjunto com os stakeholders, a fim de que idéias sejam geradas e sejam identificados os requisitos do sistema.
o Storyboard - corresponde a qualquer técnica que expressa o comportamento do sistema, projeto ou intenção de implementação pela perspectiva dos stakeholders. Esta técnica foi utilizada inicialmente no cinema e desenhos animados, representando um esboço dos personagens e da história.
o Casos de uso – as funcionalidades do sistema para que os stakeholders atinjam seus objetivos.
o Role playing - consiste em observar o stakeholder executando determinada tarefa, no dia-a-dia do seu trabalho, ou, até mesmo, o analista fazendo o trabalho, para identificar suas dificuldades e necessidades, sentindo na pele como é realizá-la.
o Prototipagem - atividade de desenvolvimento de uma versão inicial do sistema baseada no atendimento dos requisitos ainda pouco definidos, permitindo a descoberta de falhas difíceis de serem encontradas na comunicação verbal.
2. Coleta de requisitos – processo onde o analista deve interagir com os stakeholders do sistema para coletar seus requisitos. Durante essa fase a compreensão do domínio aumenta.
3. Classificação dos requisitos – nessa etapa os requisitos são organizados em conjuntos coerentes conforme descrito no modelo FURPS+. (GRADY, 1992)
4. Resolução dos conflitos – quando vários stakeholders estão envolvidos, os requisitos podem apresentar conflitos. Cabe ao analista encontrar e solucionar esses conflitos.
5. Priorização – alguns requisitos serão mais importantes do que outros e cabe ao analista levantar com os stakeholders a prioridade de cada um deles. O analista pode classificá-los como:
o Essencial – requisito sem o qual o sistema não entra em funcionamento.
o Importante – requisito sem o qual o sistema entra em funcionamento, mas de maneira insatisfatória.
o Desejável – requisito que não compromete as funcionalidades básicas do sistema, isto é, o sistema pode funcionar de forma satisfatória sem ele.
6. Verificação de requisitos – os requisitos são verificados, com o intuito de descobrir se são completos e consistentes e se estão em concordância com as necessidades dos stakeholders.
Percebe-se que o levantamento e a análise de requisitos é um processo iterativo, com feedback contínuo de cada atividade para as outras. O ciclo tem início com a compreensão do domínio e termina com a verificação dos requisitos. Dessa forma, a compreensão dos requisitos pelo analista melhora a cada fase do ciclo. (SOMMERVILLE, 2003)
O processo de levantamento e análise de requisitos apresentado na figura 4 fazendo o uso do Mapa Mental facilita a memorização das etapas, deixando de forma clara as etapas de cada atividade. O entendimento de cada etapa fica mais claro com essa apresentação do que se fosse efetuada a leitura de um texto estruturado de forma linear.
Na figura 5 é apresentado um mapa de requisitos de um sistema de automação bancária hipotético. Vale ressaltar que tanto no RUP quanto na UML não existe tal artefato. Fazendo o uso de Mapas Mentais temos então uma alternativa para os analistas de requisitos durante o processo de levantamento de requisitos.
Figura 5: Mapa de Requisitos do Sistema
Fonte: Autoria própria (2010)
Unindo o RUP e a UML e ainda adotando o modelo FURPS+ para auxiliar na identificação dos tipos de requisitos, podemos visualizar de forma clara e objetiva as necessidades do sistema, facilitando bastante a compreensão dos envolvidos no projeto durante a fase de análise e posteriormente na de construção do sistema.
Analisando a figura 5 podemos perceber que os requisitos ficam agrupados conforme o seu tipo (funcionais, não-funcionais e restrições). Dentro de cada tipo eles são divididos em subcategorias. Finalmente, em cada subcategoria estão os requisitos com um breve detalhamento de cada um.
Um artefato comumente escrito pela grande maioria dos analistas de requisitos é a especificação de caso de uso. A grande maioria das organizações possui um modelo próprio desse documento, sendo alguns mais detalhados e outros não.
Dependendo no nível de detalhamento do documento de especificação de caso de uso, o mesmo pode levar horas e até mesmo dias para ser confeccionado e chegar à sua versão final homologada e aprovada pelo cliente. Esse é um processo demorado que depende muito mais da experiência do analista de requisitos em compreender o domínio e as necessidades do cliente do que no processo adotado para coletar as informações.
Diante da importância do documento de especificação de caso de uso, o mesmo é apresentado na figura 6 usando a técnica de construção de Mapas Mentais.
Figura 6: Especificação de Caso de Uso
Fonte: Autoria própria (2010)
Claro, objetivo e indo direto ao ponto, a especificação de caso de uso utilizando Mapa Mental, mais uma vez, facilita a compreensão do requisito funcional denominado Autenticar no Sistema. Fazendo o uso de notação UML, vemos que o mesmo possui um relacionamento de inclusão com o requisito Validar Usuário e uma associação de extensão com o requisito Gerar Log de Erro. Optou-se nesse modelo colocar quais são os atributos de cada um desses requisitos para facilitar ainda mais no momento que for desenvolvê-los.
Esse modelo de especificação de caso de uso mostra rapidamente quem são os Atores (1), as Pré-Condições (2), os Fluxos de Eventos (3), as Regras de Negócio (4) e as Mensagens de Interface (5). Seguindo a notação comumente utilizada nos documentos de especificação de casos de uso tradicionais, nos Fluxos de Eventos foram mapeados todos os relacionamentos que cada passo possui.
Uma especificação de caso de uso pode ser detalhada em pouco tempo fazendo o uso de Mapas Mentais. Em pouco tempo todas as necessidades de um requisito funcional são desenhadas, aumentando a produtividade do analista de requisitos. Da mesma forma, durante a fase de construção do sistema, um desenvolvedor certamente irá achar mais rápido e prático visualizar os fluxos de eventos, regras de negócio e as mensagens de interface em uma única imagem do que ter que ler várias páginas de um documento.
Obviamente, as notações utilizadas para a construção dos Mapas Mentais dentro de uma empresa devem ser padronizadas, evitando interpretações erradas dentro da equipe. Partindo do princípio que a construção e o entendimento de como se utilizar Mapas Mentais é fácil, em pouco tempo toda a equipe estará alinhada e a produtividade da empresa irá aumentar com o passar do tempo.
5. Conclusão
A qualidade dos sistemas construídos depende em grande parte da correta compreensão de suas necessidades. Cabe então ao analista de requisitos durante a atividade de levantamento de requisitos detalhar de forma clara e eficiente todos os requisitos do sistema, evitando assim o retrabalho e contribuindo para o aumento da qualidade do mesmo.
Existem várias técnicas consagradas para auxiliar no processo de levantamento de requisitos, dentre elas podemos destacar o processo RUP e a notação UML. Nesse artigo foi apresentado o uso de Mapas Mentais em conjunto com essas técnicas.
Conforme foi explicado, o uso de Mapas Mentais facilita a compreensão das fases do levantamento de requisitos, auxiliando de forma significativa a capacidade de aprendizado, memorização e planejamento. De fácil entendimento e aprendizado, os Mapas Mentais são capazes de em pouco tempo ser utilizado para os mais diversos fins e uso.
Foram apresentados aqui alguns Mapas Mentais criados especificamente para auxiliar no levantamento de requisitos. Os mesmos mostraram-se eficientes e facilitadores na compreensão das necessidades do sistema. Dessa forma, os Mapas Mentais apresentados nas figuras 4, 5 e 6 servem como modelo para auxiliar no processo de levantamento de requisitos.
Para o futuro fica a sugestão de desenvolver outros modelos de Mapas Mentais que facilitem ainda mais a indispensável tarefa de levantamento de requisitos ou de outras disciplinas da engenharia de software.
6. Referências
BOEHM, Barry. Software Engineering Economics. Prentice-Hall, 1981.
BUZAN, Tony. Mapas Mentais. Rio de Janeiro: Sextante, 2009.
EELES, Peter. Capturing Architectural Requirements. 15 Nov 2005. Disponível em: <http://www.ibm.com/developerworks/rational/library/4706.html>. Acesso em: 26 jun. 2010.
GRADY, Robert. Practical Software Metrics for Project Management and Process Improvement. Prentice-Hall, 1992.
GUEDES, Gilleanes. UML 2 – Guia Prático. São Paulo: Novatec, 2007.
PRESSMAN, Roger S. Engenharia de Software. 6ª edição. Rio de Janeiro: McGrawHill, 2006.
SOMMERVILLE, Ian. Engenharia de Software. 6ª edição. São Paulo: Pearson Addison Wesley, 2003.
[1] Rational Unified Process® ou simplesmente Processo Unificado Rational, é um processo proprietário de Engenharia de Software criado pela Rational Software Corporation, adquirida pela IBM, que fornece técnicas a serem seguidas pelos membros de uma equipe de desenvolvimento de software com o objetivo de aumentar a sua produtividade no processo de desenvolvimento. Uma versão gratuita em português está disponível em <http://www.wthreex.com/rup/portugues/>. Acesso em 24 jun. 2010.
[2] UML (Unified Modeling Language ou Linguagem de Modelagem Unificada) é uma linguagem visual utilizada para modelar sistemas computacionais orientados a objeto que se consagrou como a linguagem-padrão de modelagem adotada pela indústria de engenharia de software, existindo um amplo mercado para profissionais que a dominem. (GUEDES, 2007)
[3] MTBF (Mean Time Between Failures) ou período médio entre falhas é um valor atribuído a um determinado dispositivo ou aparelho para descrever a sua confiabilidade. Este valor atribuído indica quando poderá ocorrer uma falha no aparelho em questão. Quanto maior for este índice, maior será a confiabilidade no equipamento e, conseqüentemente, a manutenção será avaliada em questões de eficiência. Disponível em <http://pt.wikipedia.org/wiki/MTBF>. Acesso em 25 jun. 2010.
[4] Mind Map® é marca registrada da Buzan Organization Limited 1990.
[5] Neurônio é a célula do sistema nervoso responsável pela condução do impulso nervoso na qual está localizada no cérebro. Há cerca de 86 bilhões de neurônios no sistema nervoso humano. Disponível em <http://pt.wikipedia.org/wiki/Neuronio>. Acesso em 27 jun. 2010.
3 comentários:
Excelente conteúdo!
Gostaria de saber, se na opinião do autor, mapas mentais seriam entregáveis aceitáveis como Modelos Conceituais de Dados.
Um Mapa Mental pode ser utilizado para a apresentação de um modelo conceitual de banco de dados. Lembrando que esse tipo de artefato serve para o entendimento e a memorização do tópico que é apresentado.
Postar um comentário
Todos os comentários anônimos serão moderados.