Observação
A técnica nada mais é do que o fato do engenheiro de requisitos responsável pela elicitação dos dados a ser inserido no contexto da organização estudada. Geralmente ele é inserido nos setores e departamentos que utilizarão o serviço ou produto a ser desenvolvido. O analista deverá estar atento a todas as atividades dos envolvidos e descrevê-la de forma a ser inserida na descrição do requisito.
Em alguns casos essa técnica é extremamente eficiente, pois acontece alguns casos em que os stakeholders não conseguem expressar e/ou descreverem determinadas ações. Essas ações podem ser visualizadas pelos analistas e inseridas na descrição do requisito.
De certa forma, não existe nenhuma técnica auxiliar. Basicamente consiste na observação e detalhamento dos processos. Porém, existem algumas críticas acerca da técnica Observação, em relação ao fato de que as pessoas podem alterar seus comportamentos ao saberem que o ambiente está em observação. Outro fato é que o analista observador pode se envolver no contexto da empresa e prover uma observação distorcida do ambiente.
Entrevista
Essa técnica consiste em reuniões com os stakeholders, formais ou informais, onde são colocadas questões formuladas pela equipe de engenharia de requisitos sobre o processo de trabalho atual do cliente e sobre o sistema que será desenvolvido. A Entrevista está presente na maioria dos processos de elaboração de requisitos, até porque é a partir dela que poderá surgir a necessidade da utilização de outras técnicas.
A partir dela também é possível a elaboração de um esboço de prova e confirmação por parte do stakeholder para o processo de elicitação de requisitos seja continuado.
Existem basicamente dois tipos de Entrevistas:
- As entrevistas fechadas, onde o stakeholder responde um conjunto de perguntas predefinido.
- As entrevistas abertas, que consistem na exploração de vários tópicos com os stakeholders, podendo ser entendidos outros assuntos que uma Entrevista fechada não abordaria, ou seja, não existe um conjunto de perguntas predefinido.
As entrevistas são, na prática, uma mistura entre as Entrevistas Fechadas e as Entrevistas Abertas. Em geral, são aplicadas algumas questões fechadas para os stakeholderss como ponto de partida para discussões sobre outros pontos, pois discussões somente abertas tem a tendência de não funcionar bem, por isso a necessidade de se começar com uma entrevista fechada e posteriormente partir para demais discussões nas entrevistas abertas.
Análise de protocolo
A técnica Análise de Protocolo pede ao stakeholder envolvido em determinado processo específico para executar a tarefa e ao mesmo tempo ir descrevendo e inserindo o que pensa sobre aquele processo. Alguns usuários alegam que esse tipo de linguagem pode ser considerado uma “verbalização direta do processo cognitivo específico”.
A técnica Análise de protocolos, assim como a técnica Entrevista, também está sujeita a más interpretações na descrição do processo, senão mais confusa. Por isso, ela é uma das técnicas menos recomendadas, devido ao produto final prover poucas informações confiáveis. Ou seja, o usuário envolvido no processo não tem qualquer modelo mental de como será a estrutura do sistema, restringindo muito a aplicação desta técnica.
Resumindo o motivo da não aplicação da técnica: “Os clientes têm conhecimento sobre negócios e necessidades organizacionais, enquanto o time de requisitos tem conhecimento sobre as possibilidades técnicas”.
JAD (Joint Application Development)
JAD (Joint Application Design) é uma técnica para promover cooperação, entendimento e trabalho em grupo entre os usuários desenvolvedores.
A técnica JAD foi desenvolvida pela IBM em 1977 no Canadá e tem o propósito de ser uma ferramenta de visão compartilhada, tanto por parte dos usuários, quanto por parte dos desenvolvedores (fornecedores). 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 possui 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.
Adaptação: Organização da equipe, preparação do material, isto é, preparação para a sessão.
Sessão: Encontros estruturados para extração e documentação dos requisitos, composto de desenvolvedores e usuários.
Finalização: Converter os requisitos da sessão em um documento final.
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 ideias 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.
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.
PD (Participatory Design) ou Design Participativo
Na técnica Design Participativo (ou Participatory Design – PD) os usuários são ativamente envolvidos no processo de desenvolvimento, tornando-se parceiros dos demais membros da equipe de design. Esta técnica possui uma abordagem mais voltada para projeto de interfaces.
Algumas abordagens mais tradicionais, o projeto de interfaces é realizado por uma equipe unidisciplinar, que geralmente possui uma ótica limitada a um escopo definido. Utilizando a técnica Design Participativo, uma equipe multidisciplinar é envolvida, onde questionamentos sob diferentes pontos de vista são efetuados e competências de diferentes áreas se complementam.
Esse tipo de abordagem é muito complexa, tendo em vista que envolver usuários em decisões de design é uma tarefa extremamente árdua, sendo imprescindível uma boa comunicação entre os usuários e os desenvolvedores.
QFD (Quality Function Deployment)
A técnica de QFD (Quality Function Deployment) ou Implantação da Função de Qualidade se consiste basicamente na tradução dos requisitos do cliente em requisitos técnicos. As fases iniciais do QFD podem ser descritas como sendo “simplesmente um sistema de identificação e priorização das necessidades do cliente obtidas de cada recurso avaliado”.
As principais atividades realizadas durante a aplicação dessa ferramenta são:
- a) Apontar os requisitos dos clientes do produto;
- b) Detalhar os requisitos do produto;
- c) Determinarem as especificações meta do produto.
Essas atividades são inseridas dentro da matriz QFD e as informações geradas são distribuídas.
QFD é um conceito que se aplica bem para a elicitação de requisitos, especialmente num modelo de elicitação onde a voz do cliente é o guia para a criação de requisitos.
CRC (Cooperative Requirements Capture)
CRC, ou Cooperative Requirements Capture, foi definido como sendo uma sessão de grupo, muito parecido o JAD, onde os papéis dos participantes e do facilitador são claramente definidos. No caso do CRC outras pessoas se envolvem diretamente na coleta de requisitos. A diferença básica do CRC para o JAD e do QFQ é que ele foca-se mais no usuário operativo, ou seja, que está ligado diretamente com as tarefas operacionais.
Prototipagem
A técnica de prototipagem é aplicada principalmente durante os processos de levantamento, desenvolvimento e validação dos requisitos do sistema. A técnica começa pelo estudo preliminar dos requisitos do usuário e conclui com vários requisitos formulados e um protótipo descartável do sistema para validação do usuário.
O conjunto inicial de requisitos é usado como base para criar o Protótipo de Interface do Usuário com o sistema inicial, mais simplificado.
Nessa fase inicial, devem-se mostrar todas as possibilidades dos protótipos simples para o usuário, para que ele possa validar e assim poder gastar esforços nos protótipos específicos (mais robustos), ou seja, não dispender recursos com protótipos errados.
A ideia é que depois dessa fase inicial da prototipagem, após a aceitação do protótipo pelos usuários, os desenvolvedores precisam criar um documento de especificação dos requisitos paralelo ao protótipo de Interface.
Depois desta aceitação e validação, é iniciado um processo de implementação incremental e iterativa entre os usuários e os desenvolvedores. Nessa fase do projeto, o cliente interage com o desenvolvedor, apresentando as funcionalidades desejadas de acordo com as necessidades.
Cenários
Segundo Sommerville (2007) geralmente as pessoas consideram mais fácil relatar exemplos da vida real do que abstrair descrições abstratas de suas tarefas. Para os usuários compreender e criticar um cenário pré-definido de suas possíveis interações com o sistema é mais fácil do que defini-las em palavras e idéias do começo ao fim.
Por esse motivo, é comum o desenvolvimento de um conjunto de interação dos cenários, e usá-los para elicitar e clarear os requisitos do sistema. Usuários finais simulam suas interações usando cenários.
O cenário começa com um esboço da interação e, durante a elicitação, os detalhes são adicionados para criar uma descrição completa dessa interação. De maneira geral, um cenário deve incluir:
Uma descrição do que os usuários esperam do sistema no início do cenário.
Uma descrição do fluxo normal de eventos no cenário.
Uma descrição do que pode dar errado e como isso é tratado.
Informações sobre outras atividades que pode ocorrer simultaneamente.
Uma descrição do estado de sistema no fim do cenário.
A utilização da técnica pode ser realizada de maneira informal, ou seja, os engenheiros de requisitos podem se reunir com os stakeholders e definir através de texto, diagramas, imagens de computador, etc. Caso o engenheiro queira, pode optar pela utilização de alguns recursos como cenários de eventos ou casos de uso.
Brainstorming
Brainstorming é uma técnica que consiste em uma ou várias reuniões que permitem que as pessoas sugiram e explorem ideias. Basicamente é uma técnica para geração de idéias. Ainda acrescenta que Brainstorming é uma reunião de várias pessoas que fazem sugestões de ideias sem que sejam criticadas ou julgadas, isto é, a técnica sugere a exploração de toda e qualquer ideia, fruto da reunião, seja explorada livremente.
Questionários
Questionários são usados em diversas áreas científicas, como para censo, pesquisas de opiniões, entre outros tipos de pesquisas. A técnica de Questionários consiste basicamente na elaboração de um conjunto de perguntas que irão guiar um stakeholder ou um grupo deles à respondê-las. Essa técnica não possui diretrizes bem definidas, mas existem recomendações diversas feitas por vários autores sobre como utilizar essa técnica para fazer o levantamento de requisitos.
Alguns cuidados também podem ser tomados para potencializar o resultado de um questionário, como utilizar perguntas claras e objetivas. A maneira como as perguntas são dispostas também podem fazer a diferença nos resultados.
Você pode aprende tudo isso e muito mais no curso CPRE-FL, que além de capacitar prepara o profissional para se certificar como especialista IREB.
REFERÊNCIAS
BELGAMO, Anderson; MARTINS, Luiz E. G.. Estudo Comparativo sobre as Técnicas de Elicitação de Requisitos do Software. São Paulo, 2000.
BASTOS JR., Paulo Roberto O. Elicitação de requisitos de software através da utilização de questionários. Dissertação de Mestrado. Rio de Janeiro, Abril de 2005.
ESPÍNDOLA, Rafael Senti. Um Estudo das Técnicas de Elicitação de Requisitos de Software. Trabalho De Conclusão De Curso. São Paulo, Junho de 2008.
MORAES, Janaína Bedani Dixon. Engenharia de Software 2 – Técnicas para levantamento de Requisitos. Disponível em http://www.devmedia.com.br/engenharia-de-software-2-tecnicas-para-levantamento-de-requisitos/9151
PEREIRA, Thiago. Elicitação de requisitos e suas técnicas – Parte 02, 2010. Disponível em http://imasters.com.br/artigo/18365/gerencia-de-projetos/elicitacao-de-requisitos-e-suas-tecnicas-parte-02/
PINTO, Rochelly Sirremes; FONTENELLE, Maria Aridenise Macena. Desdobramento Da Função Qualidade – Qfd No Processo De Desenvolvimento De Produtos: Uma Aplicação Prática, 2013. Disponível em http://www.abepro.org.br/biblioteca/enegep2013_TN_STP_181_033_22774.pdf
PRESSMAN, Roger S. Engenharia de Software – Uma abordagem Profissional, 7ª edição. Amgh Editora, 2011.
QUINTANS, Maria Ludovina. Um Estudo Exploratório Sobre O Conhecimento E Utilização De Técnicas De Elicitação De Requisitos Em Empresas De Software. Dissertação de Mestrado (Qualificação), 2009, 2010.
ROSEMBERG, Carlos; SCHILLING, Albert; BASTOS, Cristianne; ARARIPE, Rodrigo. Elicitação de Requisitos e Design Participativo através de Protótipos de Baixa Fidelidade – um Estudo de Caso. Disponível em http://www.infobrasil.inf.br/userfiles/Elicita%C3%A7%C3%A3o_de_Requisitos_e_Design_Participativo_atrav%C3%A9s_de_Prot%C3%B3tipos_de_baixa_Fidelidade.pdf
SOMMERVILLE. Ian. Engenharia de Software, 8ª edição. Addison Wesley, 2007.
Fonte: Redação ACerT
Comentários