O BABOK e A Elicitao de Requisitos

05/04/2017 O BABOK e a elicitação de requisitos
www.devmedia.com.br
[versão para impressão]
Link original:
http://www.devmedia.com.br/articles/viewcomp.asp?
comp=36857
O BABOK e a elicitação de
requisitos
Este artigo apresenta uma comparação
entre os analistas de requisitos e os de
negócio, além de discutir uma das áreas de
conhecimento do BABOK (Business
Analysis Body of Knowledge), a elicitação
de requisitos.
Fique por dentro
Este artigo apresenta uma comparação entre os analistas de
requisitos e os de negócio, além de discutir uma das áreas de
conhecimento do BABOK, a elicitação de requisitos. Esse tema
http://www.devmedia.com.br/articles/viewcomp_forprint.asp?comp=36857 1/21
é muito útil tanto para analistas de requisitos quanto para
analistas de negócio, pois irá auxiliálos a fazer todo e
qualquer levantamento de requisitos para o desenvolvimento
de sistemas além de facilitar o entendimento da análise das
informações extraídas dos stakeholders.
Antes de qualquer coisa, é necessário diferenciar duas profissões
que hoje se assemelham muito e, ao mesmo tempo, se
diferenciam: a análise de negócio e a análise de requisitos. Para
conceituar a Análise de Requisitos, é primordial conceituar e
contextualizar requisitos.
Um requisito é um “quesito; condição básica e necessária para se
obter alguma coisa ou para alcançar determinado propósito.”.
Usado não só para o desenvolvimento de sistemas, o requisito é
usado em tudo no dia a dia, inclusive no direito, medicina, etc.
Voltando para o desenvolvimento de sistemas, os requisitos são
utilizados principalmente, e de maneira bem alto nível, para
entender e descrever a(s) necessidade(s) do(s) usuário(s) de um
(ou mais) sistema(s).
O objetivo principal da análise de requisitos e, por consequência,
do analista de requisitos é identificar, analisar, especificar e
definir as necessidades do usuário para o desenvolvimento de um
sistema. Para ser um bom profissional da área, são necessários
alguns prérequisitos, habilidades: entre eles “requer dominar a
comunicação sólida e efetiva e sólidos conhecimentos técnicos”,
como descrito em diversas vagas de emprego para o profissional.
É fato que não é tão necessário conhecimentos de programação,
porém teria um ganho bastante importante, pois a especificação
também é feita para os profissionais de desenvolvimento.
Além de mapear e analisar requisitos listados pelos stakeholders,
os chamados requisitos funcionais (abordam O QUE o sistema
deve fazer), mapeiam outros requisitos mais necessários ao
desenvolvimento de sistema, os chamados requisitos não
funcionais (abordam características de qualidade que o sistema
deve possuir e que estão relacionadas às suas funcionalidades,
como confiabilidade, portabilidade, segurança e usabilidade).
De uma maneira bem sintética, o fluxo de trabalho de um analista
de requisitos é identificar as necessidades do negócio, definir os
requisitos, escrever a especificação de cada item definido,
modelar os requisitos, coordenar a validação e gerenciálos. É
com isso que os gerentes de projetos têm insumo para estimar a
implementação dos requisitos especificados. É muito importante
sempre envolver o cliente desde o início do processo do
desenvolvimento do sistema. Isso é uma garantia de que o
produto final terá a qualidade desejada por ele e que atende ao
que ele deseja.
Conceituando o Analista de Negócio

Análise de negócios se refere ao conjunto de atividades utilizado
para servir como ligação entre as partes interessadas (cliente) e
as soluções que permitam que a organização alcance suas metas.
É uma profissão muito nova (possivelmente teve início em 2008,
aproximadamente) e promissora. Muitas vezes atuam sem saber
que já o fazem e são pouco valorizados, confundidos, na maioria
das vezes, com outros analistas, como os de requisitos.
Atualmente o papel do analista de negócio vem sendo cada vez
mais acionado pelas organizações. Ele atua principalmente na
intermediação entre as partes interessadas e o desenvolvimento
do software, mantendo o foco no problema que precisa ser
resolvido. Para o analista de negócios executar bem sua tarefa,
da mesma maneira que o gerente de projetos possui o PMBOK,
ele possui o BABOK, que detalha bem cada técnica, ferramenta e
fonte de informação para esse profissional. Entre as atividades
que o analista de negócios desempenha, temos:
Analisar a contabilidade de balanços e balancetes;
Analisar erros de sistemas e providenciar soluções;
Atuar no planejamento e controle de solução;
Realizar levantamentos sobre as necessidades dos clientes;
Elaborar a documentação de processos de sistema;
Elaborar manuais e dar treinamentos;
Analisar a alimentação de dados de qualquer natureza do
sistema;
Realizar conferências nacionais e internacionais;
Definir os procedimentos de homologação e testes do
sistema;
Transformar os requisitos de negócio em requisitos de
software.
O profissional analista de negócios veio para unir o conhecimento
e a experiência entre as áreas de negócio e TI (Tecnologia da
Informação). Hoje, um dos maiores problemas enfrentados pelas
empresas é saber onde encaixar o analista de negócio dentro do
organograma da sua organização, de tal maneira a obter um
melhor resultado e desempenho: permanecer com eles na TI pelo
seu conhecimento técnico ou em um departamento específico,
explorando seu conhecimento de mercado.
O BABOK e suas áreas de conhecimento

O BABOK é um guia que define um padrão para práticas de
análise de negócio. Mantido pelo IIBA (International Institute of
Business Analysis), ele define as áreas de conhecimentos, suas
respectivas atividades e tarefas, e as habilidades necessárias
para ser eficaz na sua execução. As áreas de conhecimento
definem o que um analista de negócios precisa conhecer e as
tarefas que ele deve ser capaz de executar. As áreas de
conhecimento não representam as fases do desenvolvimento de
um projeto. Atualmente existem sete áreas (vide Figura 1):
1. Planejamento e monitoramento da análise de negócio;
2. Elicitação de requisitos;
3. Gerenciamento e comunicação dos requisitos;
4. Análise corporativa;
5. Análise de requisitos;
6. Avaliação e validação da solução;
7. Competências fundamentais.
Figura 1. Relacionamentos entre as áreas de conhecimento.
Fonte: (IIBA, 2011)
Todas as áreas de conhecimento possuem entradas, tarefas a
serem executadas em cada área e saídas, obrigatórias ou não.
As atividades da área de planejamento e monitoramento da
análise de negócio são responsáveis por coordenar as demais
tarefas. Já em elicitação de requisitos são realizadas as tarefas
de compreender as necessidades das partes interessadas. A área
de gerenciamento e comunicação dos requisitos descreve a forma
como o analista de negócios deve gerenciar os conflitos,
problemas e mudanças. Para a área de análise corporativa, suas
atividades envolvem a identificação da necessidade do negócio, a
definição da natureza de uma solução que atenda a essa
necessidade e a definição da justificativa para o investimento
necessário para a entrega da solução. Em seguida temos a
análise de requisitos, que é responsável pela priorização e
detalhamento incremental dos requisitos do projeto. A área de
avaliação e validação da solução se destina à determinação de
qual solução se encaixa melhor à necessidade do negócio. Por
fim, a área de competências fundamentais apresenta a descrição
dos comportamentos, características, conhecimentos e
qualidades que apoiam a prática da análise de negócio, não sendo
essas exclusivas da profissão.
Como elicitar um requisito
De볢nição de elicitação
O presente artigo tem como objetivo principal a segunda área de
conhecimento do BABOK, a elicitação de requisitos (ver Figura
2). Para o analista de negócios, a identificação dos requisitos de
um projeto é um fator primordial para o sucesso de um sistema e
envolve a qualidade do sistema produzido.
É essencial que os requisitos estejam completos, claros, corretos
e consistentes por servirem como base da solução para as
necessidades do negócio.
Figura 2. Diagrama de entrada e saída da Elicitação. Fonte:
(IIBA, 2011)
A elicitação é definida como o processo de extrair dos
consumidores, usuários e outros stakeholders os requisitos do
negócio. Essa atividade e/ou tarefa possui alguns objetivos
conhecidos. São eles:
Identificação e listagem de quais stakeholders são
necessários para o levantamento dos requisitos;
Compreensão dos objetivos do negócio para identificar as
tarefas consideradas mais necessárias para os objetivos da
organização;
Identificação dos requisitos e desenvolvimento das
atividades essenciais para atingir as metas desejadas.
A elicitação de requisitos sempre foi uma área crítica nos projetos
de desenvolvimento de qualquer software. Essa fase de elicitar
requisitos requer um processo interativo que pode (e deve)
acontecer de forma colaborativa, e envolve analistas, usuários e
aplicação de técnicas. Durante o processo de elicitação, é
primordial o contato com os usuários e clientes do sistema para
levantar as reais necessidades. Essa relação de produtividade
entre os elicitadores foi identificada levando em consideração a
experiência, principalmente do profissional que está fazendo o
levantamento dos requisitos.
Técnicas de elicitação de requisitos

Para se elicitar os requisitos, existem algumas técnicas que
podem ser utilizadas (individualmente ou em conjunto):
Entrevistas;
Questionários;
Observação de campo;
Investigação e análise documental;
Prototipação.
Vamos, a seguir, explicitar cada uma delas.
Entrevista
Essa é a técnica mais usada da elicitação de requisitos. Mas
algumas perguntas vêm à cabeça: como elas são feitas? É
preciso entrevistar todas as pessoas da organização? O que deve
ser perguntado aos entrevistados?
A entrevista tem como objetivo obter a opinião dos entrevistados,
o que ajuda na descoberta do que está errado e o que será
tratado, conhecer o estado atual do sistema (caso já exista um) e
levantar procedimentos formais e informais.
As entrevistas têm como foco principal a capacidade de unir um
grande número de informação de maneira relativamente rápida.
Existem 3 tipos de entrevistas:
Entrevista não estruturada: o entrevistador somente guia a
discussão sem um roteiro ou lista de questões prédefinidas.
O problema desse tipo de entrevista é não abordar alguns
assuntos e/ou tópicos com o(s) entrevistado(s). Esse tipo é
o mais indicado quando não se tem total compreensão do
domínio da aplicação;
Entrevista estruturada: utiliza questões prédefinidas com
objetivo de coletar informações desejadas;
Entrevista semiestruturada: encontrase entre os dois tipos
anteriores.
A Tabela 1 apresenta um quadro com algumas vantagens e
desvantagens da técnica de entrevista.
Vantagens Desvantagens
Após um planejamento bem feito Podem ocorrer desvios de curso
pelo analista de negócios, ele terá no decorrer da entrevista.
facilidade em descobrir qual(is)
informação(ões) o usuário está
mais interessado e usar um estilo
adequado ao entrevistar.
Habilidade em alterar o curso da Consumir mais tempo e recursos
entrevista de forma a obter com sua realização.
informações sobre aspectos Normalmente a conversa rende
importantes que não tinham sido bem mais que o esperado.
previstos no planejamento inicial da
entrevista.
Habilidade em alterar a ordem Tratamento diferenciado para os
sequencial das perguntas de acordo entrevistados.
com o curso da entrevista.
Habilidade em eliminar perguntas É necessário ter um plano de
anteriormente planejadas caso o entrevista para que não haja
analista de negócios veja que é dispersão do assunto principal e
necessário. a entrevista fique longa,
deixando o entrevistado cansado
e não produzindo bons
resultados.
Da mesma maneira que é possível O usuário tem dificuldade de
excluir, é possível incluir perguntas concentração em reuniões muito
que não estavam na programação longas.
da entrevista.
Poder motivar o entrevistado no O entrevistado pode não saber
decorrer do processo, expressar corretamente suas
principalmente se o analista de necessidades ao analista.
negócios perceber que o
entrevistado está desmotivado ou
desanimado com a entrevista.
Tabela 1. Vantagens e desvantagens das entrevistas.
Questionários
Essa técnica é muito útil nos estágios atuais da elicitação de
requisitos e pode ser constituída de perguntas abertas e
fechadas. Os questionários podem fornecer um feedback rápido,
pois possuem formato de “pergunta/resposta” e podem levantar
informações de uma grande quantidade de pessoas. Por outro
lado, aconselhase utilizálos como técnica complementar a outra
(geralmente, mas não é via de regra, a técnica de entrevista).
A partir dessa técnica, stakeholders chave podem ser
selecionados para aprofundar o levantamento de informações.
Outro problema nessa técnica é a falta física do entrevistador no
momento da aplicação dos questionários. Para lidar com isso,
alguns cuidados são necessários:
Faça questões claras e sem ambiguidades (questões
ambíguas podem gerar inclusive desconforto em quem está
respondendo o questionário);
Tenha um fluxo de questões definido;
Faça um planejamento detalhado;
Levante antecipadamente as dúvidas dos participantes que
irão responder (é interessante tentar prever as possíveis
dúvidas de quem irá responder o questionário);
Para as perguntas subjetivas:
o Limite a quantidade de caracteres e/ou palavras da
resposta para que o(s) participante(s) não se prolongue(m)
demais na resposta. Por exemplo: “Responda com no
máximo 40 palavras. ”;
o Devese tomar cuidado com as que permitem respostas
muito vagas.
Para as perguntas objetivas:
o A melhor opção é utilizar o método de escala. Por
exemplo: “Numa escala de 1 a 5, qual o nível de satisfação
da funcionalidade XPTO, sendo 1 para muito insatisfeito e 5
para muito satisfeito.”.
Questionários não devem passar duas laudas em A4.
É importante lembrar que a melhor forma de aplicar a técnica de
questionário é fazendo reuniões para responder as perguntas do
questionário. Outra forma de aplicação da técnica de questionário
é o analista de negócio entregar e recolher os questionários
individualmente. A desvantagem é o tempo que se perde nessa
estratégia.
desvantagens da técnica de questionário.
Atinge um grande número de Não há garantia de que a maioria
pessoas, fazendo assim que se dos participantes respondam ao
tenha menores custos. questionário.
Permite que os participantes Os resultados são bastante críticos
respondam no momento em que em relação ao objetivo, pois as
acharem conveniente. perguntas podem ter significados
diferentes a cada participante
questionado.
Questões padronizadas garantem
uniformidade.
Tabela 2. Vantagens e desvantagens dos questionários.
Observação de campo
Normalmente, as pessoas acham complicado descrever o que
elas fazem, pois isso é muito natural para elas. Às vezes, a
melhor forma de entender será observálas no trabalho. O
objetivo dessa técnica é capturar o máximo de informações no
levantamento de requisitos para o desenvolvimento de um
projeto, pois faz com que o analista esteja dentro do campo de
atuação dos usuários do sistema, observando o dia a dia, o
funcionamento na prática, e quais são os processos e quais as
decisões alternativas ao chamado “mundo perfeito”.
É importante que o analista de negócios e/ou o analista de
requisitos tenha uma posição passiva para observar o ambiente
da organização que “encomendou” o sistema. Essa técnica
consiste em observar o comportamento e o ambiente dos
indivíduos de vários níveis organizacionais. Utilizandoa, é
possível capturar o que realmente é feito e qual tipo de suporte
computacional é realmente necessário. Ela ajuda a confirmar ou
refutar informações obtidas com outras técnicas e ajuda a
identificar tarefas que podem ser automatizadas e que não foram
identificadas pelos interessados.
A observação possibilita um contato mais pessoal e estreito do
pesquisador com o pesquisado, principalmente se houver empatia
entre ambas as partes, o que apresenta uma série de vantagens.
As técnicas de observação são extremamente úteis para
“descobrir” (ou em alguns casos redescobrir) aspectos novos de
um problema ou até mesmo corrigir problemas já existentes. Isso
se torna fundamental nas situações em que não existe uma base
teórica sólida que oriente a coleta de dados. Ao mesmo tempo em
que o contato direto e prolongado do pesquisador com a situação
pesquisada apresenta as vantagens mencionadas, envolve
também uma série de problemas. Algumas críticas são feitas ao
método de observação, primeiramente por provocar alterações no
ambiente ou no comportamento das pessoas observadas. Outra
crítica é a de que esse método se baseia muito na interpretação
pessoal. Além disso, há críticas no sentido de que o grande
envolvimento do pesquisador leve a uma visão distorcida do
fenômeno ou a uma representação parcial da realidade. A Tabela
3 apresenta um quadro com algumas vantagens e desvantagens
da técnica da observação de campo.
Capaz de captar o Polarizada pelo observador.
comportamento natural das
pessoas.
Nível de intromissão Requer treinamento especializado.
relativamente baixo.
Confiável para observações com Efeitos do observador nas pessoas.
baixo nível de inferência.
Captura o que realmente é feito Não comprova/esclarece o
e não o que é documentado ou observado.
explicado.
Auxilia a compreensão do Número restrito de variáveis.
relacionamento entre o Analista
de Negócio (quem irá observar)
e os demais (os usuários dos
sistemas).
Auxilia a confirmar (ou negar) Provoca alterações no ambiente ou
informações obtidas por outras no comportamento das pessoas
técnicas. observadas.
Baseia muito na interpretação
pessoal, o que pode gerar
ambiguidade.
O grande envolvimento do
pesquisador pode levar a uma
visão distorcida do fenômeno ou a
uma representação parcial da
realidade.
Tabela 3. Vantagens e desvantagens da observação de campo.
Investigação e análise documental

Essa técnica foca em coletar informações mais difíceis de obter
através das técnicas de entrevistas, questionários ou
observações. Essas informações são:
Histórico da organização;
Cultura e hábitos internos;
Relacionamentos entre os diferentes setores que utilizarão o
produto;
Informações financeiras;
Direcionamentos futuros.
Os dados coletados podem ser qualitativos e quantitativos. Os
dados quantitativos fornecem informações baseadas em números,
métricas, metas e relatórios de desempenho, relatórios usados
para tomadas de decisões, entre outros. Os dados qualitativos
são obtidos através da análise de memorandos, quadros de
avisos, manuais, entre outros.
desvantagens da técnica da investigação e análise documental.
Documentos com problemas
podem levar a uma falha na
definição dos requisitos.
Uma grande variedade de
documentação pode ser analisada,
incluindo estrutura organizacional
da organização, padrões de
mercado, leis, manuais de
usuário, relatório de pesquisas de
mercado, glossário de termos de
negócio, entre outras.
Tabela 4. Vantagens e desvantagens da investigação e análise
documental.
Prototipação
Essa técnica pode ser utilizada no estágio inicial do projeto,
ajudando os stakeholders a terem uma forte noção sobre a
aplicação em desenvolvimento, uma vez que através da
visualização da mesma eles podem identificar os reais requisitos
e fluxos de trabalho do sistema. O uso da prototipação é
recomendado quando os stakeholders são incapazes de expressar
os seus requisitos ou se os mesmos não têm nenhuma
experiência com o sistema. Essa técnica deve ser um instrumento
usado com bastante cautela tanto pelo analista que irá levantar
os requisitos a partir dela quanto pelos stakeholders que a
apresentam.
É considerada, na linguagem coloquial, “uma faca de dois gumes”,
pois caso o stakeholder não saiba se expressar ou se expresse de
forma ambígua ou de forma incorreta, ele poderá colocar o
levantamento de requisitos e a sua futura implementação toda a
perder. Os protótipos podem ser representados por fluxogramas,
montagens em slides ou até mesmo wireframes (um desenho
básico, como um esqueleto, que demonstra de forma direta a
arquitetura de como o objeto final será de acordo com as
especificações relatadas) tendo como grande vantagem
apresentar ao stakeholder inúmeras alternativas antes de orientar
esforços.
desvantagens da técnica da prototipação.
Permite alcançar um feedback Demanda um alto custo de
antecipado dos stakeholders. investimento, em relação a outros
métodos, para ser realizado.
Redução de tempo e custo de Demanda um tempo maior devido
desenvolvimento devido a à complexidade do sistema e a
detecção dos erros em uma fase limitações técnicas.
inicial do projeto.
Provê alto nível de satisfação dos Com o protótipo, o cliente pode
usuários devido a sensação de acreditar que a especificação
segurança ao ver algo próximo do funcional está concluída e querer
real “apressar” a implementação do
projeto.
Tabela 5. Vantagens e desvantagens da prototipação.
A complexidade na execução das atividades da área abordada
neste artigo, a elicitação de requisitos, é elevada. Algumas boas
práticas podem ser adotadas pelas equipes de desenvolvimento
de forma a facilitar o processo:
Prepararse previamente e de forma adequada para as
atividades planejadas, as quais são geralmente realizadas
através das técnicas de entrevistas e questionários;
Mapear, também com certa antecedência (quando possível,
claro), quem serão os participantes, seus papéis no projeto
e na organização, o nível de conhecimento e influência. É de
extrema importância que as pessoas certas sejam
envolvidas o quanto antes nas técnicas da elicitação;
Buscar sempre a efetividade na comunicação, assim como
procurar demonstrar ponderação durante as situações de
conflito;
É preciso focar no entendimento do problema e evitar
conclusões precipitadas;
Utilizar experiências anteriores para ajudar a compreender
melhor o problema. Porém, não considere que o problema
atual é igual a outro já vivido anteriormente, nem que a
solução poderá ser a mesma;
Descrever o problema de forma clara e objetiva. É preciso
sempre envolver o cliente, ou seja, tendo qualquer dúvida o
acione e evite inferências. Adotar diagramas, exemplos e
figuras sempre ajuda na documentação e no entendimento
dos requisitos. A criação de protótipos também auxilia para
o entendimento da solução proposta, porém como forma
complementar ao requisito, não como documento principal;
Por fim, é importante obter a validação da documentação pelos
stakeholders, verificando o entendimento do problema e as
melhorias desejadas. Ter os documentos validados é uma
segurança para se ter o escopo fechado e, caso haja qualquer
alteração, essa será realizada de forma mais controlada.
Referências
Belgamo, A., & Martins, L. E. (2000). Estudo Comparativo s
obre as Técnicas de Elicitação de Requisitos do Software. Sã
o Paulo.
Bittencourt, A. G. (2012). Aplicabilidade do Analista de Neg
ócios nas Organizações. Belo Horizonte: IETEC.
Freitas, D. P., Borges, M. R., & Araújo, R. M. (2007). Colab
oração e negociação na elicitação de requisitos. In Worksho
p Iberoamericano de Ingenieria de Requisitos y ambientes d
e software. Isla de Margarita.
Hass, K., Wessels, D. J., & Brennan, K. (2008). Getting it rig
ht: business requirement analysis tools and techniques. Vien
a, VA: Management Concepts.
IIBA. (2011). BABOK o Guia para o Corpo de Conhecime
nto de Análise de Negócios. Toronto: www.theiiba.org.
PMI. (2013). Um Guia do Conhecimento em Gerenciamento
Projetos (Guia PMBOK®) – Quinta Edição. Newtown Squar
e: Project Management Institute.
Sommerville, I. (2004). Engenharia de Software. Addison W
esley.
por Ana Gabriela
Engenharia de software lover

O BABOK e A Elicitao de Requisitos

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

O BABOK e A Elicitao de Requisitos

Загружено:

Авторское право:

Доступные форматы

05/04/2017 O BABOK e a elicitação de requisitos

Conceituando o Analista de Negócio

O BABOK e suas áreas de conhecimento

Como elicitar um requisito

Técnicas de elicitação de requisitos

Investigação e análise documental

Вам также может понравиться