Técnicas para levantamento de Requisitos

O início para toda a atividade de desenvolvimento de software é o levantamento de requisitos, sendo esta atividade repetida em todas as demais etapas da engenharia de requisitos.

Relacionado: Guia de Levantamento de Requisitos

Sommerville (2003) propõe um processo genérico de levantamento e análise que contém as seguintes atividades:

• Compreensão do domínio: Os analistas devem desenvolver sua compreensão do domínio da aplicação;
• Coleta de requisitos: É o processo de interagir com os stakeholders do sistema para descobrir seus requisitos. A compreensão do domínio se desenvolve mais durante essa atividade;
• Classificação: Essa atividade considera o conjunto não estruturado dos requisitos e os organiza em grupos coerentes;
• Resolução de conflitos: Quando múltiplos stakeholders estão envolvidos, os requisitos apresentarão conflitos. Essa atividade tem por objetivo solucionar esses conflitos;
• Definição das prioridades: Em qualquer conjunto de requisitos, alguns serão mais importantes do que outros. Esse estágio envolve interação com os stakeholders para a definição dos requisitos mais importantes;
• Verificação de requisitos: Os requisitos são verificados para descobrir se estão completos e consistentes e se estão em concordância com o que os stakeholders desejam do sistema.

O levantamento e análise de requisitos é um processo iterativo, com uma contínua validação de uma atividade para outra, conforme exemplificado pela Figura 1.

Dificuldades encontradas

O problema de não saber especificar corretamente o que o sistema deverá fazer é muito antigo. Pompilho (1995) cita um exemplo do relatório produzido por McKinsey, em 1968, e mencionado por B. Langefords e B. Sundgren onde se afirmava que dois terços das empresas ali estudadas estavam desapontadas com o atendimento recebido em sistemas de informação.

Após mais de 30 anos da elaboração do relatório a situação não é muito diferente. Algumas das razões para o baixo grau de satisfação dos usuários para os sistemas destacam-se:

• Na fase de levantamento de requisitos do projeto, onde não é utilizada uma técnica adequada para extrair os requisitos do sistema;
• A falha do analista em não descrever os requisitos do sistema de modo claro, sem ambigüidades, conciso e consistente com todos os aspectos significativos do sistema proposto.

Entre as dificuldades encontradas na fase de levantamento de requisitos estão: o usuário principal do sistema não sabe o que quer que o sistema faça ou sabe e não consegue transmitir para o analista; requisitos identificados, mas que não são realistas e não identificam os requisitos similares informados por pessoas diferentes. Um stakeholder errado afetará em perda de tempo e dinheiro para ambas as partes envolvidas no desenvolvimento do sistema.

Identifica-se um levantamento de requisitos adequado através da boa definição do projeto, da efetividade do projeto, de informações necessárias a um perfeito diagnóstico e de soluções inteligentes. Quanto ao levantamento de requisitos inadequado, o resultado é um diagnóstico pobre com conclusões comprometidas, não identificação das causas dos problemas, custos elevados, prazos vencidos ou comprometedores, omissão de processos fundamentais e descréditos.

Técnicas de Levantamento de Requisitos

As técnicas de levantamento de requisitos têm por objetivo superar as dificuldades relativas a esta fase. Todas as técnicas possuem um conceito próprio e suas respectivas vantagens e desvantagens, que podem ser utilizadas em conjunto pelo analista.

Serão apresentadas de forma resumida nesse artigo algumas técnicas de levantamento de requisitos.

Levantamento orientado a pontos de vista

Para qualquer sistema, de tamanho médio ou grande, normalmente há diferentes tipos de usuário final. Muitos stakeholders têm algum tipo de interesse nos requisitos do sistema. Por esse motivo, mesmo para um sistema relativamente simples, existem muitos pontos de vista diferentes que devem ser considerados. Os diferentes pontos de vista a respeito de um problema ‘vêem’ o problema de modos diferentes. Contudo, suas perspectivas não são inteiramente independentes, mas em geral apresentam alguma duplicidade, de modo que apresentam requisitos comuns.

As abordagens orientadas a ponto de vista, na engenharia de requisitos, reconhecem esses diferentes pontos de vista e os utilizam para estruturar e organizar o processo de levantamento e os próprios requisitos. Uma importante capacidade da análise orientada a pontos de vista é que ela reconhece a existência de várias perspectivas e oferece um framework para descobrir conflitos nos requisitos propostos por diferentes stakeholders.

O método VORD (viewpoint-oriented requirements definition – definição de requisitos orientada a ponto de vista) foi projetado como um framework orientado a serviço para o levantamento e análise de requisitos.

A primeira etapa da análise de ponto de vista é identificar os possíveis pontos de vista. Nessa etapa os analistas se reúnem com os stakeholders e utilizam a abordagem de brainstorming para identificar os serviços em potencial e as entidades que interagem com o sistema.

A segunda etapa é a estruturação de pontos de vista, que envolve agrupar pontos de vista relacionados, segundo uma hierarquia. Serviços comuns estão localizados nos níveis mais altos da hierarquia e herdados por pontos de vista de nível inferior.

A etapa de documentação do ponto de vista tem por objetivo refinar a descrição dos pontos de vista e serviços identificados.

O mapeamento de sistema conforme ponto de vista envolve identificar objetos em um projeto orientado a objetos, utilizando as informações de serviço que estão encapsuladas nos pontos de vista.

A Figura 2 exemplifica a técnica de levantamento orientado a ponto de vista.

Etnografia

A etnografia é uma técnica de observação que pode ser utilizada para compreender os requisitos sociais e organizacionais, ou seja, entender a política organizacional bem como a cultura de trabalho com objetivo de familiarizar-se com o sistema e sua história. Os cientistas sociais e antropólogos usam técnicas de observação para desenvolver um entendimento completo e detalhado de culturas particulares.

Nesta técnica, o analista se insere no ambiente de trabalho em que o sistema será utilizado. O trabalho diário é observado e são anotadas as tarefas reais em que o sistema será utilizado. O principal objetivo da etnografia é que ela ajuda a descobrir requisitos de sistema implícitos, que refletem os processos reais, em vez de os processos formais, onde as pessoas estão envolvidas.

Etnografia é particularmente eficaz na descoberta de dois tipos de requisitos:

• Os requisitos derivados da maneira como as pessoas realmente trabalham, em vez da maneira pelas quais as definições de processo dizem como elas deveriam trabalhar;
• Os requisitos derivados da cooperação e conscientização das atividades de outras pessoas.

Alguns itens importantes que devem ser executados antes, durante e depois do estudo de observação:

• Antes, é necessário identificar as áreas de usuário a serem observadas; obter a aprovação das gerências apropriadas para executar as observações; obter os nomes e funções das pessoas chave que estão envolvidas no estudo de observação; e explicar a finalidade do estudo;
• Durante, é necessário familiarizar-se com o local de trabalho que está sendo observado. Para isso é preciso observar os agrupamentos organizacionais atuais; as facilidades manuais e automatizadas; coletar amostras de documentos e procedimentos escritos que são usados em cada processo específico que está sendo observado; e acumular informações estatísticas a respeito das tarefas, como: freqüência que ocorrem, estimativas de volumes, tempo de duração para cada pessoa que está sendo observada. Além de observar as operações normais de negócios acima é importante observar as exceções;
• Depois, é necessário documentar as descobertas resultantes das observações feitas. Para consolidar o resultado é preciso rever os resultados com as pessoas observadas e/ou com seus superiores.

A análise de observação tem algumas desvantagens como, consumir bastante tempo e o analista ser induzido a erros em suas observações. Mas em geral a técnica de observação é muito útil e freqüentemente usada para complementar descobertas obtidas por outras técnicas.

Workshops

Trata-se de uma técnica de elicitação em grupo usada em uma reunião estruturada. Devem fazer parte do grupo uma equipe de analistas e uma seleção dos stakeholders que melhor representam a organização e o contexto em que o sistema será usado, obtendo assim um conjunto de requisitos bem definidos.

Ao contrário das reuniões, onde existe pouca interação entre todos os elementos presentes, o workshop tem o objetivo de acionar o trabalho em equipe. Há um facilitador neutro cujo papel é conduzir a workshop e promover a discussão entre os vários mediadores. As tomadas de decisão são baseadas em processos bem definidos e com o objetivo de obter um processo de negociação, mediado pelo facilitador.

Uma técnica utilizada em workshops é o brainstorming. Após os workshops serão produzidas documentações que refletem os requisitos e decisões tomadas sobre o sistema a ser desenvolvido.

Alguns aspectos importantes a serem considerados: a postura do condutor do seminário deve ser de mediador e observador; a convocação deve possuir dia, hora, local, horário de início e de término; assunto a ser discutido e a documentação do seminário.

Prototipagem

Protótipo tem por objetivo explorar aspectos críticos dos requisitos de um produto, implementando de forma rápida um pequeno subconjunto de funcionalidades deste produto. O protótipo é indicado para estudar as alternativas de interface do usuário; problemas de comunicação com outros produtos; e a viabilidade de atendimento dos requisitos de desempenho. As técnicas utilizadas na elaboração do protótipo são várias: interface de usuário, relatórios textuais, relatórios gráficos, entre outras.

Alguns dos benefícios do protótipo são as reduções dos riscos na construção do sistema, pois o usuário chave já verificou o que o analista captou nos requisitos do produto. Para ter sucesso na elaboração dos protótipos é necessária a escolha do ambiente de prototipagem, o entendimento dos objetivos do protótipo por parte de todos os interessados no projeto, a focalização em áreas menos compreendidas e a rapidez na construção.

Entrevistas

A entrevista é uma das técnicas tradicionais mais simples de utilizar e que produz bons resultados na fase inicial de obtenção de dados. Convém que o entrevistador dê margem ao entrevistado para expor as suas idéias. É necessário ter um plano de entrevista para que não haja dispersão do assunto principal e a entrevista fique longa, deixando o entrevistado cansado e não produzindo bons resultados.

As seguintes diretrizes podem ser de grande auxilio na direção de entrevistas bem sucedidas com o usuário: desenvolver um plano geral de entrevistas, certificar-se da autorização para falar com os usuários, planejar a entrevista para fazer uso eficiente do tempo, utilizar ferramentas automatizadas que sejam adequadas, tentar descobrir que informação o usuário está mais interessado e usar um estilo adequado ao entrevistar.

Para planejar a entrevista é necessário que antes dela sejam coletados e estudados todos os dados pertinentes à discussão, como formulários, relatórios, documentos e outros. Dessa forma, o analista estará bem contextualizado e terá mais produtividade nos assuntos a serem discutidos na entrevista.

É importante determinar um escopo relativamente limitado, focalizando uma pequena parte do sistema para que a reunião não se estenda por mais de uma hora. O usuário tem dificuldade de concentração em reuniões muito longas, por isso é importante focalizar a reunião no escopo definido.

Após a entrevista é necessário validar se o que foi documentado pelo analista está de acordo com a necessidade do usuário, que o usuário não mudou de opinião e que o usuário entende a notação ou representação gráfica de suas informações.

A atitude do analista em relação à entrevista é determinar seu fracasso ou sucesso. Uma entrevista não é uma competição, deve-se evitar o uso excessivo de termos técnicos e não conduzir a entrevista em uma tentativa de persuasão. O modo como o analista fala não deve ser muito alto, nem muito baixo, tampouco indiretamente, ou seja, utilizar os termos: ele disse isso ou aquilo na reunião para o outro entrevistado. O modo melhor para agir seria, por exemplo, dizer: O João vê a solução para o projeto dessa forma. E o senhor André, qual é a sua opinião? Em uma entrevista o analista nunca deve criticar a credibilidade do entrevistado. O analista deve ter em mente que o entrevistado é o perito no assunto e fornecerá as informações necessárias ao sistema.

Para elaborar perguntas detalhadas é necessário solicitar que o usuário:

• Explique o relacionamento entre o que está em discussão e as demais partes do sistema;
• Descreva o ponto de vista de outros usuários em relação ao item que esteja sendo discutido;
• Descreva informalmente a narrativa do item em que o analista deseja obter informações;
• Perguntar ao usuário se o item em discussão depende para a sua existência de alguma outra coisa, para assim poder juntar os requisitos comuns do sistema, formando assim um escopo conciso.

Pode-se utilizar a confirmação, para tanto o analista deve dizer ao usuário o que acha que ouviu ele dizer. Neste caso, o analista deve utilizar as suas próprias palavras em lugar das do entrevistado e solicitar ao entrevistado confirmação do que foi dito.

Saiba mais sobre entrevistas para coleta de requisitos

Questionários

O uso de questionário é indicado, por exemplo, quando há diversos grupos de usuários que podem estar em diversos locais diferentes do país. Neste caso, elaboram-se pesquisas específicas de acompanhamento com usuários selecionados, que a contribuição em potencial pareça mais importante, pois não seria prático entrevistar todas as pessoas em todos os locais.

Existem vários tipos de questionários que podem ser utilizados. Entre estes podemos listar: múltipla escolha, lista de verificação e questões com espaços em branco. O questionário deve ser desenvolvido de forma a minimizar o tempo gasto em sua resposta.

Na fase de preparação do questionário deve ser indicado o tipo de informação que se deseja obter. Assim que os requisitos forem definidos o analista deve elaborar o questionário com questões de forma simples, clara e concisa, deixar espaço suficiente para as repostas que forem descritivas e agrupar as questões de tópicos específicos em um conjunto com um título especial. O questionário deve ser acompanhado por uma carta explicativa, redigida por um alto executivo, para enfatizar a importância dessa pesquisa para a organização.

Deve ser desenvolvido um controle que identifique todas as pessoas que receberão os questionários. A distribuição deve ocorrer junto com instruções detalhadas sobre como preenchê-lo e ser indicado claramente o prazo para devolução do questionário. Ao analisar as respostas dos participantes é feito uma consolidação das informações fornecidas no questionário, documentando as principais descobertas e enviando uma cópia com estas informações para o participante como forma de consideração pelo tempo dedicado a pesquisa.

Brainstorming

Brainstorming é uma técnica para geração de idéias. Ela consiste em uma ou várias reuniões que permitem que as pessoas sugiram e explorem idéias.

As principais etapas necessárias para conduzir uma sessão de brainstorming são:

• Seleção dos participantes: Os participantes devem ser selecionados em função das contribuições diretas que possam dar durante a sessão. A presença de pessoas bem informadas, vindas de diferentes grupos garantirá uma boa representação;
• Explicar a técnica e as regras a serem seguidas: O líder da sessão explica os conceitos básicos de brainstorming e as regras a serem seguidas durante a sessão;
• Produzir uma boa quantidade de idéias: Os participantes geram tantas idéias quantas forem exigidas pelos tópicos que estão sendo o objeto do brainstorming. Os participantes são convidados, um por vez, a dar uma única idéia. Se alguém tiver problema, passa a vez e espera a próxima rodada.

No brainstorming as idéias que a princípio pareçam não convencionais, são encorajadas, pois elas frequentemente estimulam os participantes, o que pode levar a soluções criativas para o problema. O número de idéias geradas deve ser bem grande, pois quanto mais idéias forem propostas, maior será a chance de aparecerem boas idéias. Os participantes também devem ser encorajados a combinar ou enriquecer as idéias de outros e, para isso, é necessário que todas as idéias permaneçam visíveis a todos os participantes.

Nesta técnica é designada uma pessoa para registrar todas as idéias em uma lousa branca ou em papel. À medida que cada folha de papel é preenchida, ela é colocada de forma que todos os participantes possam vê-la.

Analisar as idéias é a fase final do brainstorming. Nessa fase é realizada uma revisão das idéias, uma de cada vez. As consideradas valiosas pelo grupo são mantidas e classificadas em ordem de prioridade.

JAD

JAD (Joint Application Design) é uma técnica para promover cooperação, entendimento e trabalho em grupo entre os usuários desenvolvedores.

O JAD facilita a criação de uma visão compartilhada do que o produto de software deve ser. Através da sua utilização os desenvolvedores ajudam os usuários a formular problemas e explorar soluções. Dessa forma, os usuários ganham um sentimento de envolvimento, posse e responsabilidade com o sucesso do produto.

A técnica JAD tem quatro princípios básicos:

• Dinâmica de grupo: são realizadas reuniões com um líder experiente, analista, usuários e gerentes, para despertar a força e criatividade dos participantes. O resultado final será a determinação dos objetivos e requisitos do sistema;
• Uso de técnicas visuais: para aumentar a comunicação e o entendimento;
• Manutenção do processo organizado e racional: o JAD emprega a análise top down e atividades bem definidas. Possibilita assim, a garantia de uma análise completa reduzindo as chances de falhas ou lacunas no projeto e cada nível de detalhe recebe a devida atenção;
• Utilização de documentação padrão: preenchida e assinada por todos os participantes. Este documento garante a qualidade esperada do projeto e promove a confiança dos participantes.

A técnica JAD é composta de duas etapas principais: planejamento, que tem por objetivo elicitar e especificar os requisitos; e projeto, em que se lida com o projeto de software.

Cada etapa consiste em três fases: adaptação, sessão e finalização. A fase de adaptação consiste na preparação para a sessão, ou seja, organizar a equipe, adaptar o processo JAD ao produto a ser construído e preparar o material. Na fase de sessão é realizado um ou mais encontros estruturados, envolvendo desenvolvedores e usuários onde os requisitos são desenvolvidos e documentados. A fase de finalização tem por objetivo converter a informação da fase de sessão em sua forma final (um documento de especificação de requisitos).

Há seis tipos de participantes, embora nem todos participem de todas as fases:

• Líder da sessão: é responsável pelo sucesso do esforço, sendo o facilitador dos encontros. Deve ser competente, com bom relacionamento pessoal e qualidades gerenciais de liderança;
• Engenheiro de requisitos: é o participante diretamente responsável pela produção dos documentos de saída das sessões JAD. Deve ser um desenvolvedor experiente para entender as questões técnicas e detalhes que são discutidos durante as sessões e ter habilidade de organizar idéias e expressá-las com clareza;
• Executor: é o responsável pelo produto sendo construído. Tem que fornecer aos participantes uma visão geral dos pontos estratégicos do produto de software a ser construído e tomar as decisões executivas, tais como alocação de recursos, que podem afetar os requisitos e o projeto do novo produto;
• Representantes dos usuários: são as pessoas na empresa que irão utilizar o produto de software. Durante a extração de requisitos, os representantes são frequentemente gerentes ou pessoas-chave dentro da empresa que tem uma visão melhor do todo e de como ele será usado;
• Representantes de produtos de software: são pessoas que estão bastante familiarizadas com as capacidades dos produtos de software. Seu papel é ajudar os usuários a entender o que é razoável ou possível que o novo produto faça;
• Especialista: é a pessoa que pode fornecer informações detalhadas sobre um tópico específico.

O conceito do JAD de abordagem e dinâmica de grupo poderá ser utilizado para diversas finalidades, como: planejamento de atividades técnicas para um grande projeto, discussão do escopo e objetivos de um projeto e estimativa da quantidade de horas necessárias para desenvolver sistemas grandes e complexos.

A maioria das técnicas JAD funciona melhor em projetos pequenos ou médios. Para um sistema grande e complexo podem ser usadas múltiplas sessões JAD para acelerar a definição dos requisitos do sistema.

Saiba mais sobre as competências para se tornar um Engenheiro de Requisitos

Saiba mais sobre JAD

Conclusão

Não existe uma técnica padrão para o processo de levantamento de requisitos. Para alcançar um levantamento de requisitos mais preciso é importante o conhecimento de diversas técnicas para saber que técnica de levantamento aplicar em cada situação.

É primordial que o analista possua perfil adequado. O analista de sistemas precisa de mais do que apenas a capacidade de desenhar fluxogramas e outros diagramas técnicos. O analista de sistemas tem a função de projetar e analisar sistemas de ótimo desempenho. Para que esse objetivo seja alcançado, é necessário o analista de sistema possuir a capacidade de:

• Compreender conceitos abstratos, reorganizá-los em divisões lógicas e sintetizar soluções baseadas em cada divisão;
• Absorver fatos pertinentes de fontes conflitantes ou confusas;
• Entender os ambientes do usuário/cliente;
• Aplicar elementos do sistema de hardware e/ou software aos elementos do usuário/cliente;
• Comunicar bem nas formas escrita e verbal e entender o objetivo global do software.

A Tabela 1 apresenta os grupos de técnicas para o levantamento de requisitos.

Saiba mais sobre Requisitos de Software através do nosso Guia