ARTIGO
Técnicas de Levantamento de Requisitos
*
Fabrício Portes Braga*
Analista de Sistemas graduado pelo UNIEURO – Centro Universitário Euro-Americano, pós-graduado pela UPIS – União Pioneira de Integração Social, Brasília- DF. Trabalha atualmente como Analista de Requisitos em empresa de Tecnologia da Informação em Brasília - DF.
E-mail: [email protected]
Resumo
Este artigo tem como objetivo, apresentar as principais técnicas de levantamento de requisitos, fazer uma comparação entre elas e demonstrar sua aplicação conforme as situações e ambientes encontrados na atividade de levantamento de requisitos.
Palavras-chave
Requisitos; Técnicas; Levantamento.
Techniques Survey of Requirements
Abstract
This article aims to, presenting the main techniques for waiver of requirements, make a comparison between them and demonstrate their application as the situations and environments found in the activity of lifting of requirements. .
Keywords
Requirements; Techniques; Survey .
*
Artigo apresentado à diretoria de ensino de pós-graduação, pesquisa e extensão, da UPIS – União Pioneira de Integração Social, em cumprimento à exigência para conclusão de MBA em Engenharia de Software com Ênfase em Gerencia de Projetos, sob orientação do professor Vinícius Lopes Coutinho.
APRESENTAÇÃO
O presente artigo caracteriza-se por uma abordagem técnica/didática, é destinado aos analistas de sistemas, analistas de requisitos, gerentes de requisitos e gerente de projetos,
por tratar de técnicas utilizadas
freqüentemente por tais profissionais no desempenho de suas funções.
Trata-se de uma revisão literária que abordará as principais técnicas de levantamento de requisitos com o intuito de prover ao leitor identificar as diferenças entre as técnicas abordadas e permitir que o mesmo utilize a
técnica correta conforme a situação
encontrada.
INTRODUÇÃO
A definição de requisitos é muito ampla, contudo todas se convergem para um senso
comum: Requisitos são a base de
comunicação entre a demanda conceitual para o entendimento de problema e a efetiva
construção/estruturação de idéias para
concretizá-los, ou ainda, “Requisito é uma declaração abstrata, de alto nível, de uma função que o sistema deve fornecer ou de uma restrição do sistema” [SOMMERVILLE 2003], ou, “Requisito é uma definição detalhada, matematicamente formal, de uma função do sistema.”[DAVIS 1993].
Um dos grandes problemas enfrentados no ambiente de desenvolvimento de software é a definição e o entendimento dos requisitos de
software corretamente e em sua totalidade,
quanto para o usuário, “Uma compreensão completa dos requisitos de software é fundamental para um projeto bem-sucedido. Um problema mal analisado e especificado desapontará o usuário e trará aborrecimentos ao desenvolvedor”[ PRESSMAN95].
A comunicação é parte fundamental no levantamento de requisitos, porém, estabelecer e manter uma comunicação produtiva para o entendimento muitas vezes é cheia de obstáculos, contudo, segundo Kendall [1992] para auxiliar o levantamento de requisitos, existem várias técnicas que podem ser utilizadas. O estudo realizado discutirá as características e a utilização das mesmas.
ESTABELECENDO A COMUNICAÇÃO O início do processo de levantamento de requisitos é estabelecer a comunicação entre a parte interessada na solução e a designada em prover a solução.
Para iniciar a comunicação entre as partes interessadas conforme Presman[1995], é necessária uma entrevista inicial. “A técnica mais comumente usada para preencher a falta de comunicação entre o cliente e o desenvolvedor é realizar um encontro ou entrevista preliminar”.
Na entrevista é aconselhável segundo
Gause[1989] que o entrevistador comece fazendo perguntas livres de contexto, ou seja, perguntas focadas à compreensão básica do problema como, por exemplo: “Quem está por trás do pedido deste trabalho?”, ou, “Há outra fonte para a solução exigida?”.
A próxima seqüência de perguntas deve permitir ao entrevistador obter uma melhor compreensão do problema e permitir ao entrevistado expor suas percepções sobre uma solução, um exemplo de perguntas a serem feitas nesta fase seria: “Quais problemas esta
solução resolverá?”, ou, “Você poderia mostrar-me (ou descrever-me) o ambiente em que a solução será utilizada?”.
Já a terceira e última leva de perguntas, ainda
segundo GAUSE [1989] seriam as
metaperguntas: “Conjunto de perguntas que
se concentram na efetividade do encontro”, são perguntas que visam um feedback do entrevistado e lhe permitem saber informações importantes como: “Você é a pessoa certa para responder a essas perguntas? Suas respostas são oficiais?”, “Minhas perguntas são pertinentes ao problema que você tem?” ou “Existe algo que você queria dizer que não foi perguntado?”.
As perguntas apresentadas devem ser feitas apenas no primeiro encontro com a finalidade de um conhecimento a cerca do problema, não devem ser estendidas para as demais reuniões, onde a finalidade é o levantamento da solução.
ENTREVISTA
Segundo Kendall[1992], “Entrevista é uma conversa entre duas ou mais pessoas com uma finalidade específica”. A entrevista é uma das etapas mais importantes no processo de levantamento de requisitos, é através dela que o responsável pela captação dos requisitos conhece as opiniões, as expectativas e os problemas a serem tratados e é através dela que deve ser traçada a estratégia para o levantamento.
Kendall[1992], expõe que as entrevistas devem seguir as seguintes etapas: Planejamento, condução e registro, podendo ser gravada ou não.
Antes de realizar a entrevista, o entrevistador deverá estabelecer os objetivos, delimitando assim o que perguntar, sem deixar de lado a formulação das perguntas e o tipo delas
(objetivas, subjetivas, aprofundamento), outro ponto importante é averiguar se o entrevistado é a pessoa mais indicada a responder as perguntas.
A formulação das perguntas deve ser feita conforme o objetivo esperado: podem ser subjetivas caso o entrevistador queira criar um ambiente de maior espontaneidade, obter riqueza de detalhes ou obter questionamentos mais abrangentes, contudo, o uso desta técnica pode fornecer detalhes irrelevantes e a perda de controle da entrevista, além de, em alguns casos passar a impressão que o entrevistador está sem objetivo. Caso queira limitar as respostas possíveis ou ganhar tempo, podem-se fazer perguntas objetivas (Quem? Quanto tempo? Quantos?). Já no caso de necessidade de obtenção de um detalhamento melhor a respeito de algum tópico, a utilização de perguntas de aprofundamento (Por quê? Poderia me dar um exemplo? Como é iniciado o processo?), é o mais indicado. Contudo, é importante evitar perguntas que levem o entrevistado a responder de forma específica ou perguntas que possuem duas respostas. Conforme Kendall[1992], a utilização das questões acima comentadas deve ser estruturada visando uma forma melhor de conduzir a entrevista. Em uma reunião onde o entrevistado não consegue abordar um assunto determinado, a estrutura pirâmide é a mais indicada, pois, é iniciada com perguntas detalhadas/objetivas e à medida que a entrevista progride, são utilizadas perguntas mais subjetivas. Já a estrutura de Funil, é aconselhada quando o entrevistador deseja uma maior espontaneidade ou é utilizada no começo de uma bateria de entrevistas, caracteriza-se por perguntas mais abrangentes no início e à medida que a reunião se desenvolve são utilizadas perguntas mais específicas. A estrutura Diamante é uma fusão dos dois tipos de estrutura (funil e pirâmide), geralmente é a mais utilizada, pois começa com questões específicas seguidas por questões mais abrangentes e termina com o entrevistador abordando novamente questões
objetivas, esta técnica tem como característica manter a atenção do entrevistado devido à variedade de questões.
QUESTIONÁRIO
O comprometimento dos detentores dos requisitos do sistema é determinante para o sucesso do projeto. Mas, em alguns casos, como a indisponibilidade física ou quando ocorre uma dispersão das pessoas envolvidas, ou até mesmo quando se deseja uma captação estatística, o questionário é a melhor forma de
levantamento, alem de, segundo
Kendall[1992], constituir uma técnica de levantamento que permite obter informações de várias pessoas afetadas pelo sistema como por exemplo: quantificação a respeito do levantado nas entrevistas, examinar uma grande amostra de usuários do sistema, obter um feedback a respeito de problemas ou identificar possíveis melhorias.
“A elaboração de um questionário é um processo muito mais complexo do que possa aparentar. Um questionário mal formulado pode levar a considerações erradas, o que acaba sendo prejudicial ao projeto em
questão” [PARASURAMAN91], daí a
importância de se fazer um planejamento adequado visando o conteúdo, formato e ordem das questões. Um questionário deverá possuir questões claras e sem ambigüidade, ter
fluxo definido, prever antecipadamente
dúvidas que possam surgir e não pode ser
muito extenso, pois pode ocasionar
desinteresse das pessoas que irão respondê-lo. A forma de entrega ou apresentação do
questionário também é abordada por
Parassuraman [1991]. A auto-resposta via correio ou e-mail, onde sua principal vantagem, é o envio a um grande número de pessoas, que podem responder quando quiserem, contudo, é provada a baixa taxa de respostas, obrigando assim ao remetente
enviar uma quantidade de e-mails/cartas além da quantidade desejada para que se atinja o mínimo de respostas. Já a auto-resposta em grupo, é um método que reúne um grupo de
pessoas e as perguntas são feitas
simultaneamente, mas cada um responde o questionário individualmente, a vantagem é que se obtêm as respostas rapidamente (ao
final da sessão) e perguntas e/ou
esclarecimentos podem ser feitos pelos questionados no momento em que surgirem as dúvidas. A auto-resposta (porta a porta) é uma técnica menos habitual, onde o investigador desloca-se pessoalmente ao local de trabalho ou à residência do entrevistado, entrega e explica o questionário e depois retorna para recebê-lo. A vantagem é o elevado número de respostas, porém, o tempo e os custos são elevados. Cabe ao responsável pela pesquisa, escolher a melhor técnica conforme a situação encontrada.
JOINT APPLICATION DEVELOPMENT
A técnica denominada por Joint Application
Development (JAD), desenvolvida pela IBM,
é uma reunião realizada com um grupo de
Stakeholders de diversas áreas e que estão ou
serão envolvidos no projeto em determinado tempo, sua finalidade elicitar dúvidas que são levantadas em áreas distintas como: Banco de Dados, Desenvolvimento e Usuários do Sistema. Participam também, um facilitador e uma pessoa designada para fazer anotações. Segundo Pádua [2001], esta técnica apresenta
as seguintes vantagens: obter maior
comprometimento dos usuários com os requisitos; reduzir o tempo necessário ao levantamento da especificação dos requisitos; retirar do projeto requisitos que de valor
questionável; esclarecer dúvidas de
interpretação dos requisitos entre usuários e desenvolvedores; identificar e discutir o mais cedo possível, problemas políticos que possam interferir no projeto.
JAD deve ser iniciada com a personalização, que visa a preparação, onde a equipe é definida, e orientações em relação á técnica é passada aos participantes, preparação das instalações, que devem ser externas ao local de trabalho dos participantes e definição de aspectos particulares relativos ao projeto. Pode-se também, segundo Pressman [1995], que atribui à JAD, uma abordagem popular da técnica Facilitaded Application Specification
Techniques (FAST) “solicitar aos participantes que elaborem uma lista de objetos que fazem parte do ambiente que circunda o sistema, de outros objetos que são produzidos pelo sistema e dos objetos que são usados para que o sistema execute suas funções, alem de uma lista de operações (processos ou funções), que manipulam ou interagem com os objetos”, ou seja, levantar anteriormente, o máximo de informações ou expectativas a respeito do que será discutido na reunião.
Logo após a fase de personalização, dá-se prosseguimento com sessões propriamente ditas. As sessões de JAD são divididas em etapas, de acordo com Pádua [2001], a
abertura, onde uma apresentação das
finalidades da sessão, agenda e tempo previstos; a macro definição de requisitos, ou seja: identificação de necessidades, objetivos e benefícios esperados e possíveis funções; a definição do escopo do produto; levantamento e detalhamento dos casos de uso do produto; leiaute das interfaces com o usuário; definição
de interfaces com outros produtos;
planejamento do JAD de análise e
documentação dos problemas e registro considerações e decisões tomadas durante as sessões.
Por último, a fase de fechamento, onde deverá ser produzida uma coletânea de tudo que fora levantado durante as sessões, um esboço da especificação de requisitos de software, que deverá ser apresentada para os responsáveis pela decisão de continuar o projeto.
Conforme Pádua [2001], a técnica JAD deve ser aplicada com cuidado, pois existem pontos que podem comprometer seriamente sua eficácia como: “o não envolvimento de pessoas que desempenham papeis chaves no processo de uso do produto”; “A participação de pessoas não-comprometidas com o produto” e “o número excessivo de participantes (varia de 8 a 15 para grupos experientes)”, alem disso, o líder do JAD deve possuir experiência e o envolvimento dos participantes integralmente em todas as reuniões é importantíssimo. Contudo, as experiências de JAD´s de sucesso onde o índice de mudança de requisitos é baixíssimo e a redução de tempo e esforço gastos no levantamento de requisitos a torna uma técnica a ser considerada.
PROTOTIPAÇÃO
A prototipação é uma técnica que permite a obtenção rápida de sugestões, inovações, revisões ou mudanças e permite captar o sentimento do usuário a respeito do sistema em desenvolvimento [Kendall1992].
Os protótipos embora sejam desenvolvidos visando principalmente a apresentação para o usuário de um esboço do sistema, deve ser classificado com descartável ou evolucionário. O protótipo evolucionário é desenvolvido com a finalidade de construir partes de um produto funcional de forma iterativa, permitindo assim ao usuário o acompanhamento do desenvolvimento de maneira que alguma alteração possa ser feita com custos relativamente menores em relação ao produto completo.
O protótipo descartável tem por objetivo demonstrar ao usuário, aspectos relacionados à interface de usuário, problemas de comunicação com outros produtos e a
viabilidade de atendimento relativo ao desempenho de forma extremamente rápida. Em sua construção, podem ser utilizadas ferramentas de programação que possuam biblioteca de componentes, processadores de texto, ferramentas de manipulação de imagens ou até mesmo um lápis e papel, entretanto, no caso de protótipos descartáveis, como o próprio nome diz, é aconselhável que o mesmo não seja aproveitado para fins de implementação por não seguir referências de qualidade, ocasionando assim um aumento manutenibilidade / estabilidade de requisitos.
BRAINSTORMING
Segundo LEFFINGWELL [2003],
brainstorming (tempestade de idéias) é uma
técnica que visa explorar a criatividade dos participantes gerando assim, através da diferença de pensamentos, idéias e respostas. É muito utilizada para a criação de novos produtos ou efetuar melhoramentos nos existentes, resolução de problemas, gestão de projetos e engenharia de requisitos.
De autoria de Alex Osborn, prega a técnica, que se reúnam de uma até dez pessoas de preferência de competências e setores diferentes, para que suas experiências diversas colaborem com a diversificação de pontos de vista. Deve ser feita com a presença de um facilitador que deverá anotar todas as idéias sem exceção e um líder, que conduzirá a reunião e proporá os temas a serem discutidos. O Mais importante é que nenhuma idéia deve ser julgada como errada ou absurda, contribuindo assim para que sejam geradas muitas idéias e principalmente não constranger os integrantes. Uma sessão de
brainstorming deve durar em torno de 30
minutos.
Após terem se esgotadas as idéias possíveis, o líder de posse das idéias levantadas, as
distribui para um pequeno grupo (de três a sete pessoas) solicitando que sejam escolhidas as melhores idéias, que depois de selecionadas, devem ser redistribuídas a todos os participantes.
ANÁLISE DE COMPETIDORES
A análise de competidores, ou SWOT
(Strengths), Fraquezas (Weaknesses),
Oportunidades (Opportunities), foi criada por dois professores de Havard, Kenneth Andrews e Roland Christensen. Consiste em analisar os pontos fortes e fracos além de ameaças e oportunidades, ou seja, uma comparação do que já exista no mercado, com fins de se projetar um produto que maximiza os pontos fortes levantados e minimizar os pontos fracos
encontrados nos produtos semelhantes
existentes, resumindo: “O objetivo da SWOT é definir estratégias para manter pontos fortes, reduzir a intensidade de pontos fracos,
aproveitando oportunidades e protegendo-se
de ameaças.”
Existem alguns pontos que devem ser observados como: verificar se as informações são recentes e isentas; as fontes devem ser idôneas e desprovidas de viés; todos os participantes devem conhecer os conceitos envolvidos;
CONSIDERAÇÕES FINAIS
O analista deve fazer uma análise de todo o universo envolvendo o levantamento, os
steakeholders, o ambiente, a disponibilidade e
a localização física dos detentores da informação devem ser levados em consideração, para que seja escolhida a técnica adequada para uma determinada situação ou momento.
Estabelecer uma boa relação com os provedores de requisitos é um fator crítico de sucesso, “quebrar o gelo” e tentar tornar a reunião para levantamento de requisitos um momento de cumplicidade é o primeiro passo a ser tomado.
A entrevista é vista como a técnica mais utilizada conforme Kendall[1992]. Especial atenção deve ser reservada ao planejamento e ao registro, sendo que o entrevistador deve fazer um estudo a respeito do tema e procurar levantar e ler documentos que possam ajudar a entender o negócio. A análise de competidores, outra técnica de levantamento de requisitos, poderá ser utilizada em conjunto, pois ajuda a levantar dúvidas, idéias e delimitar o projeto a ser desenvolvido. A entrevista deve ser documentada de preferência através de uma ata ou registro e assinada pelos participantes, pois, como a informação discutida será utilizada no desenvolvimento do projeto, o registro serve como documento que comprova os requisitos levantados durante a reunião.
O questionário deve ter por objetivo, a captação de informações de diversas pessoas ou de pessoas dispersa em locais distintos. Deve-se frisar a necessidade de formulação de questões claras e objetivas, com cuidado para não gerar interpretações erradas. Apesar dos diversos meios de encaminhamento dos questionários levantados neste artigo, é interessante que se prive pela diminuição dos custos, optando assim pelo envio via e-mail. Porém, para que fique evidenciada a importância da colaboração do questionado, é aconselhável redigir uma proposta explicando a finalidade e agradecendo a colaboração. Já a técnica JAD, tem por objetivo, a busca de opiniões e definição de requisitos entre envolvidos de diversas áreas como banco de dados, desenvolvimento e usuários do sistema. Deve ser utilizada visando apenas aspectos técnicos, contudo, nem sempre o usuário possui conhecimento de informações da
linguagem utilizada pelo corpo técnico e vice versa, sendo necessário em alguns casos a apresentação de um glossário contendo os termos que possam gerar dúvidas a respeito do negócio/sistema.
As sessões de JAD devem ser planejadas e documentadas, a necessidade de um facilitador ou líder para conduzir as reuniões e um secretário para anotar as considerações e decisões tomadas durante as sessões é de extrema importância. O local físico deve ser neutro e a não interferência por fatores externos é necessária, porém, não se faz obrigatória a realização da reunião em um ambiente externo, o que acarreta em aumento de custos do projeto.
A Prototipação é praticamente imprescindível a todos os projetos, arquitetura, indústria automobilística, aeronáutica etc. A construção de um protótipo tem por finalidade a apresentação de um esboço do produto ou de parte dele aos envolvidos.
Tal técnica contribui para o aperfeiçoamento do produto a ser entregue, pois apresenta a interface de usuário facilitando assim, a percepção de aspectos que não foram lembrados ou levantados anteriormente e atenuando a expectativa dos envolvidos. Os protótipos com finalidade de demonstração (descartáveis), não devem ser aproveitados para a construção do sistema, pois a qualidade não é considerada durante sua criação.
Brainstorming tem a finalidade de gerar novas
idéias a respeito de um determinado produto, prega a técnica, que seja realizada reunião entre uma até dez pessoas com a presença de um facilitador responsável pela condução da reunião. Porém um mínimo de pessoas deve ser considerado, pois a quantidade de idéias e a participação são fatores determinantes. A análise de competidores visa analisar características de produtos semelhantes ao que se deseja construir ou alterar, visando levantar os pontos fortes/fracos e as
oportunidades/ameaças objetivando o desenvolvimento de um produto melhor que o esperado.
Características principais, layout e funcionalidades devem ser registradas e estudadas, mantendo o foco no que deve ser melhorado. É aconselhável que mais de uma pessoa opine sobre o estudado, sendo que uma sessão de brainstorming pode ser realizada visando uma colaboração mutua entre os envolvidos.
É fato que as técnicas apresentadas, contribuem em muito para um levantamento de requisitos de forma correta, porém, a utilização de uma técnica específica isoladamente pode não ser suficiente para uma especificação satisfatória.
Artigo apresentado à diretoria de ensino de pós-graduação, pesquisa e extensão, da UPIS – União Pioneira de Integração Social, em 30.04.2008.
REFERÊNCIAS
KENDALL, K.E. Kendall, J.E. Kendall; Systems Analysis and Design, Prentice Hall, 1992. [KENDALL92]
LEFFINGWELL, Dean, Don Widrig: Managing Software Requirements - A Use Case Approach, Second Edition 2003 [LEFFINGWELL2003].
PÁDUA, Wilson; 2001. Engenharia de Software fundamentos, métodos e padrões. LCT Livros técnicos e científicos, Rio de Janeiro, Brasil, 2001. [PÁDUA01].
SOMMERVILLE, Ian; 2003. Engenharia de Software. Pearson Education do Brasil, São Paulo, Brasil, 2003. [SOMMERVILLE 2003].
PRESSMAN, Roger S; 2005. Engenharia de Software. Pearson Education do Brasil, São Paulo, Brasil, 2005. [PRESSMAN 2005]. PARASURAMAN, A. Zeithaml; 1991 marketing research. ed. Addison Wesley Publishing Company, 1991. [PARASURAMAN 91] GAUSE, D. C., WEINBERG, G.M., 1991, Explorando Requerimentos de Sistema, 1a. ed., Rio de Janeiro, Makron Books, 1991. [GAUSE89]
DAVIS, William; 1987. Análise e Projeto de Sistemas uma Abordagem Estruturada. LTC - Livros Técnicos e Científicos Editora S.A. Rio de Janeiro, Brasil. 1987. [DAVIS87].
