Artigo - elicitação de requisitos

Esta é uma pré-visualização de arquivo. Entre para ver o arquivo original

Observação 
A técnica Observação nada mais é do que o fato do engenheiro de requisitos responsável pela 
elicitação dos dados 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: 
1. As entrevistas fechadas, onde o stakeholder responde um conjunto de perguntas 
predefinido. 
2. 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 
conforme abaixo. 
 
 
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. 
Baseado nesse conceito a figura abaixo mostra as etapas deste processo de prototipagem. 
 
 
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 idéias. 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 idéias 
sem que sejam criticadas ou julgadas, isto é, a técnica sugere a exploração de toda e qualquer 
idéia, 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_Parti
cipativo_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