Neste artigo iremos abordar algumas técnicas de levantamento de requisitos como objetivo reunir o máximo de informação do cliente para execução de um projeto. Cada técnica tem seu próprio conceito, vantagens e desvantagens, podendo também ser utilizadas em conjuntos.
Levantamento orientado a pontos de vista
Como início na exemplificação deste tipo de levantamento de requisitos, devemos levar em consideração a quantidade de stakeholders, pois isso influência muito na utilização desta técnica, ou seja, como será coletado a visão de cada um para criação do sistema, solução ou personalização de um projeto.
Esta metodologia se baseia na união de levantamento dos processos que irão compor o projeto e o modo como é visto por cada participante do projeto, com ela reconhecemos várias perspectivas e oferece um framework para descobrir os conflitos entre essas diversas visões.
O método VORD (viewpoint-oriented requirements definition – definição de requisitos orientada a ponto de vista) foi criado como um framework orientado a serviço para o levantamento e análise de requisitos.
Como primeiro ponto na análise baseada em ponto de vista é uma reunião destes stakeholders e assim ter uma abordagem de brainstorming para identificação dos serviços.
Na próxima etapa é o alinhamento e estruturação de pontos de vistas, de modo a agrupá-los e diminuir ao máximo estes conflitos de ideias.
Na figura abaixo Sommerville (2003) exemplificado o fluxo do processo para levantamento orientado a ponto de vista.
Figura 1 - Médoto VORD, SOMMERVILLE - 2003
Etnografia
Na etnografia é uma técnica de observação onde analisamos e buscamos compreender os requisitos sociais e organizacionais, assim, entender a política organizacional e a cultura da empresa, entendimento do seu funcionamento e sua história.
Na etnografia, o analista estará presente no dia a dia de funcionamento da empresa, acompanhando rotinas, fluxos de sistemas e tarefas reais do dia a dia, assim, descobrindo os requisitos de sistema implícitos. Com isto, será analisado a realidade dos processos, sendo eles reais e formais, onde as pessoas estão envolvidas.
Como destaque na etnografia temos dois tipos de requisitos eficazes:
· Os requisitos derivados do fluxo de trabalho real das pessoas na empresa e não o que foi documentado como deveria seguir a execução de tais funções.
· Os requisitos derivados da cooperação e conscientização das atividades de outras pessoas.
No fluxo geral da etnografia, temos alguns passos importantes em cada momento:
· Antes, identificar as áreas a serem observadas; permissões de acesso, gerencia ou gestor de setor, nomes e funções de usuários chaves e por final explicar a finalidade do estudo.
· Durante, imersão no fluxo e local de trabalho, grupos organizacionais, documentações, estatísticas de trabalho, frequência, volumes, duração. Também observar as exceções nas operações normais de negócios.
· Depois, documentar as descobertas que foram encontradas nas observações feitas. Rever e checar com as pessoas observadas e validação com seus superiores.
Como ponto negativo é um processo que gasta um tempo de maior que em outras análises, devido a esse acompanhamento no menor universo da empresa para entendimento do fluxo de funcionamento, sendo muito utilizada por outras técnicas em um item específico para melhor detalhamento.
Workshops
Como uma técnica utilizada de mais costume, são reuniões estruturadas com um grupo de pessoas do projeto. É realizada uma seleção de stakeholders ou P.O. do projeto que será desenvolvido.
Diferente das outras reuniões, nesta todos são de extrema importância e deve ser uma construção de trabalho em equipe. Sempre há um facilitador neutro que promove as discussões entre os mediadores da reunião. Mediado pelo facilitador são bem definidos os processos e as tomadas de decisões. Como destaque nas reuniões de workshop é o “brainstorming”, onde vão surgindo ideias a partir das discussões criadas e opinião dos membros que compõe o workshop.
Após a reunião, que muita das vezes são gravadas, sendo assim uma boa dica para futura pesquisa ou revisão de momentos específicos, regras, definições de fluxos, é gerado uma documentação de requisitos com todos os pontos e projeto abordado.
Prototipagem
No protótipo resumidamente são baseados em rascunhos, sendo de sistemas, gráficos, relatórios, até mesmo um comparativo do que pode ser para o projeto futuro. Onde pode ser realizado também uma reunião com a equipe do projeto para apresentação e discussão dos requisitos.
Um dos grandes benefícios da prototipagem e a redução de riscos por conta de ser um pré-projeto, também o ganho de tempo por já assim possuir um esqueleto do que é desejado pelo cliente.
Entrevistas
A entrevista se encaixa em uma das metodologias mais utilizadas e simples no levantamento de requisitos. Onde escutamos o cliente e suas ideias iniciais para o projeto. É sempre importante ter um plano de entrevista com o cliente para que não perca o foco principal do projeto e não deixando a reunião muito longa e cansativa.
Algumas diretrizes a serem seguidas para grande auxílio neste levantamento:
· Um plano geral das entrevistas a serem realizadas;
· Autorização para conversas com usuários;
· Gestão do tempo;
· Busca de informações onde o usuário mais se interessa do assunto.
Para iniciar o processo de entrevistas, deve ser realizado um escopo com limites, assim, quebrando o projeto principal e diversas partes para não estender as reuniões e limita-las em períodos de uma hora. Em reuniões muito extensas se tornam cansativas e menos produtivas.
Após estas entrevistas deve ser gerado uma breve documentação, podendo ser até uma ata básica para garantir as informações passadas pelo usuário, afim de garantir a segurança e integridade das informações. Para no futuro ao ser construído o documento final de requisitos não ocorra divergência por parte do mesmo em discordar do que está no documento.
O posicionamento do analista nestas reuniões deve ser o direcionador de assuntos e discussões de ideias entre os membros, tento uma linguagem não tão técnica e nem muito agressiva a ponto de colocar dois usuários para conflito, mas sim ter um manejo em questão de julgar as opiniões distintas, exemplo: Sr. Mario, tivemos a ideia deste fluxo com o Sr. Hugo, gostaria de complementar com alguma sugestão? Com isto, tornamos o diálogo mais fluídos e integração das informações entre as diversas partes.
Segue algumas dicas de perguntas que ajudarão na coleta de informações:
· Sempre manter alinhado o que está em discussão em relação as outras partes do sistema;
· Apresentar sempre o ponto de visão de todos usuários no tema ou item que está sendo discutido;
· Sempre descrever informalmente a narrativa do item em que o analista deseja obter informações;
· Alinhar com o usuário dos itens que foram levantados terão algumas pendencias ou dependência de outro fator externo para ser criado ou realizado.
Em alguns momentos pode se colocar como validação uma fala própria do analista se posicionando do assunto e pedindo confirmação aos usuários.
Questionários
Uma das grandes vantagens da utilização de questionários e a possibilidade de ser aplicada não somente fisicamente em um local, ou seja, pode ser aplicado em qualquer localidade, por meio digital ou físico e não somente para um cliente no mesmo tempo. Com isso também potencializa a coleta de informações de um modo mais rápido.
Como modelos temos diversos tipos que podem ser utilizados nestas coletas de dados, sendo eles: múltipla escolha, checklists, questões abertas para texto descritivo, mas como melhores práticas não criar questionamentos que seja gasto um grande tempo para preenchimento e entendimento pelo cliente.
Na construção do questionário dever ser bem indicado o tipo de informação que será importante para o projeto e possível resposta do cliente. Após a definição dos requisitos o analista deve produzir esse questionário para melhor validar as confirmações do que será produzido ao cliente, também podendo agrupar as questões por tópico, se adequando ao projeto.
Na visão da parte gestacional da utilização do questionário, também tem que ter o controle destes questionários, definindo prazos e relação de envios destes questionários, checando prazos e preenchimentos para evitar a falta de informações, outro ponto é a falta destas informações e não atingir.
Brainstorming
Brainstorming que na tradução ao pé da letra “tempestade de ideias”, é uma técnica dinâmica de grupo, onde são reunidas as partes interessantes, sendo cliente, colaborador ou grupo interno mesmo da empresa em uma reunião.
Para iniciar a reunião de brainstorming é necessário definir algumas etapas:
· Escolha dos participantes: a partir das funções e o quão iram contribuir para o projeto, também uma variação de pessoas para diversas visões e corroborar com o objetivo.
· Detalhar o funcionamento do brainstorming: como é o funcionamento, regras e conceitos a serem seguidos na reunião.
· Produção de dados com qualidade: gerenciar o caminhar da reunião, colocando regras limitando a uma ideia por participante, um por vez, caso haja algum impedimento é passado para o próximo participante.
No brainstorming as ideias podem surgir a partir de princípios não convencionais, mas estimulam aos participantes pensarem em novas soluções criativas para o problema. No geral o volume de ideias é bem grande, pois a partir de novas ideias, geralmente aparece outras mais novas, sendo assim, elas devem sempre estar visíveis aos outros participantes para gerarem discussões e acrescentar mais valor ao projeto.
Por fim as ideias são reunidas e é realizada uma revisão, sendo analisada uma por vez, as que são consideradas de alto valor ao projeto são mantidas e classificadas por ordem.
JAD
JAD (Joint Application Design) é uma técnica utilizada para cooperação, entendimento e trabalho em grupo que envolve a equipe de desenvolvedores.
Segundo VIANNA, (2003, pg 1) JAD é uma metodologia que permite extrair informações de alta qualidade dos usuários, em curto espaço de tempo, através de reuniões estruturadas que buscam decisões por consenso, que é uma das formas mais produtivas de decisão em grupo.
Com o JAD é facilitado a visão compartilhada do projeto de software e como o mesmo deve ser. Com o conhecimento dos desenvolvedores é facilitado o questionamento para acrescentar mais conteúdo ao projeto e atingir os ideais do mesmo. Com isso, também atingimos um melhor afeto aos usuários por sentirem estar mais inclusos nas decisões e ver a importância da opinião dos mesmos.
Nesta técnica temos quatro princípios básicos:
· Dinâmica de grupo: com auxílio de um líder experiente, analista, usuário e gerentes, são geradas reuniões para despertar e instigar a criatividade dos participantes. Por final será a definição de objetivos e requisitos do projeto;
· Uso de técnicas visuais: rascunhos e exemplos para melhora no entendimento;
· Manutenção do processo organizado e racional: o JAD emprega a análise top down e atividades bem definidas. Tornando assim a garantia de uma análise completa reduzindo assim as chances de falhas e brechas no projeto.
· Documentação padrão: toda a documentação é preenchida e assinada por todos os participantes do projeto. Com este documento é garantido a qualidade esperada do projeto e torna confiável os itens definidos para serem produzidos.
Na técnica JAD temos duas etapas principais: planejamento, onde tem o objetivo de elicitar e especificar os requisitos, projeto, onde é trabalhado o projeto de software.
Cada etapa do JAD temos três fases: adaptação, sessão e finalização. Na adaptação é onde preparamos a sessão, organização de equipe, adaptar o processo JAD para produzir o produto e preparar material. Na sessão é onde realiza as sessões e encontros estruturados, envolvendo toda a equipe e os requisitos são desenvolvidos e documentados. Por final na fase de finalização o objetivo principal é a finalização da documentação de especificação de requisitos a partir da utilização da sessão.
Para compor a equipe do projeto utilizando JED, temos seis tipos de participantes:
· Líder da sessão: o facilitador das reuniões. Deve ser uma pessoa competente, com grande qualidade de relacionamento pessoal e qualidades gerencias de liderança;
· Engenheiro de requisitos: responsável pela produção da documentação de requisitos. Um desenvolvedor experiente capaz de captar todas as ideias e visões do projeto, transpor as ideias para a documentação;
· Executor: responsável pelo produto que está sendo construído. Tem como função transparecer a visão geral dos pontos estratégicos do produto de software a ser construído e tomar as decisões executivas, alocação de recursos, que podem afetar os requisitos e o projeto de novo produto;
· Representantes dos usuários: pessoas que irão utilizar o software. No momento da extração de requisitos, são frequentemente gerentes ou pessoas chaves dentro da empresa, pois, possuem uma visão melhor do todo e de como ele será usado;
· Representantes de produtos de software: são pessoas familiarizadas com as capacidades dos produtos de software, cujo objetivo e ajudar os usuários entenderem as funcionalidades e o que pode ser fazer com o software.
· Especialista: pessoa que tem o conhecimento de informações detalhadas sobre tópicos específicos.
Na maioria das técnicas JAD funcionam melhor em projetos pequenos e médios. Para um sistema mais complexo e grande posse utilizar múltiplas sessões de JAD para aceleração no processo de documentação de requisitos do sistema.
Conclusão
Como visão geral de todos as metodologias não existe a melhor a ser utilizada, o que definirá será cada projeto, cada ambiente de cliente e melhor adequação com equipe.
O mais importante é ficar bem detalhado os requisitos de projetos para evitar problemas futuros e na maior grande parte acabar com o retrabalho, sendo uma das premissas mais críticas quando não é realizado o levantamento de requisitos.
Para o objetivo ser alcançado, segue abaixo uma listagem de capacidade que o analista deve possuir:
· Compre conceitos abstratos, reorganizá-los em divisões lógicas e sintetizar soluções baseadas em cada divisão;
· Entendimento do ambiente do usuário / cliente;
· Comunicar bem nas formas escritas, verbal e visão global do objetivo do projeto.
Abaixo segue uma tabela de grupo de técnicas de levantamento de requisitos:
Referências Bibliográficas
Somerville, I. Engenharia de software. 6° ed. Tradução Maurício de Andrade. São Paulo: Ed Addison-Wesley, 2003
Pompilho, S. Análise Essencial Guia Prático de Análise de Sistemas. Rio de Janeiro: Ed Ciência Moderna Ltda, 1995.
PRESSMAN, Roger S. Engenharia de Software. São Paulo. Ed. Markon Books, 1995
VIANNA, Heraldo M. Pesquisa em Educação: a observação.Brasília: Plano Editora, 2003.
Este artigo ficou muito bom.