Engenharia de Requisitos
“achismos”. Alguns de seus principais objetivos
Desenvolver software é uma atividade complexa
por natureza. Uma das razões para esta afirma-
ção é que não existe uma única solução para
cada cenário de desenvolvimento. Além disso,
lidamos o tempo todo com pessoas, o que torna o
sucesso do projeto bastante relacionado à com-
petência da equipe e à forma como trabalham, e,
para dificultar ainda mais, muitas vezes não fa-
zemos uso de um processo bem definido para
apoiar as atividades do projeto.
Entende-se por processo, neste contexto, como
sendo um conjunto de atividades bem definidas
com os respectivos responsáveis por execução,
ferramentas de apoio e artefatos produzidos. Ou
seja, define-se como a equipe deverá trabalhar
para alcançar o objetivo: desenvolver software
com qualidade dentro de prazos, custos e requisi-
tos definidos.
A boa notícia é que muitas empresas estão se
movimentando no sentido de definirem detalha-
damente seus processos para apoiarem suas
atividades de desenvolvimento. Uma recente
matéria publicada na revista Exame relata o cres-
cimento do número de empresas que atingiram
níveis de maturidade considerando modelos co-
mo MPS.BR e CMMI.
Este resultado é um forte indicador de que as
empresas nacionais estão se preocupando com a
qualidade dos serviços que oferecem, conseguin-
do, dessa forma, uma inserção maior no mercado
internacional de desenvolvimento de software.
Neste artigo, faremos uma introdução à Engenha-
ria de Requisitos, atividade base para as demais
tarefas associadas ao desenvolvimento de sof-
tware.
Engenharia de Software e Requisitos
Vimos na introdução que se busca cada vez mais
o apoio dos fundamentos da engenharia de sof-
tware no desenvolvimento de sistemas. Enten-
demos engenharia de software como sendo, de
acordo com o IEEE, a aplicação de uma aborda-
gem sistemática, disciplinada e quantificável no
desenvolvimento, operação e manutenção de
software. Sistemática por que parte do princípio
de que existe um processo de desenvolvimento
definindo as atividades que deverão ser executa-
das. Disciplinada por que parte do princípio de
que os processos definidos serão seguidos.
Quantificável por que se deve definir um conjunto
de medidas a serem extraídas do processo du-
rante o desenvolvimento de forma que as toma-
das de decisão relacionadas ao desenvolvimento
do software (por exemplo, melhoria de processo)
sejam embasadas em dados reais, e não em
são:
· Qualidade de software;
· Produtividade no desenvolvimento, operação e
manutenção de software;
· Permitir que profissionais tenham controle sobre
o desenvolvimento de software dentro de custos,
prazos e níveis de qualidade desejados.
Entretanto, o cenário de desenvolvimento de sof-
tware atual e o cenário idealizado junto à enge-
nharia de software ainda estão distantes. Vários
fatores contribuem para isso, podemos citar dois:
· O não uso dos fundamentos da engenharia de
software para apoiar as atividades do desenvol-
vimento;
· O mau uso dos fundamentos da engenharia de
software para apoiar as atividades do desenvol-
vimento.
Isso tem diversas consequências. Gostaríamos
de destacar neste artigo o crescente custo com
manutenção dos sistemas. Consideramos como
manutenção neste artigo como sendo qualquer
retrabalho (em nível de requisitos, projeto, codifi-
cação, teste) causado por uma definição do do-
mínio do problema mal elaborada nas fases inici-
ais do desenvolvimento.
Neste ponto, é importante analisamos os dados
da Tabela 1. Perceba que o custo das atividades
relacionadas à análise de requisitos é baixo. Por
outro lado, é nesta fase que grande parte dos
defeitos são inseridos. Podemos perceber ainda
analisando a primeira linha que o custo de corre-
ção destes problemas nesta fase é baixo. Conti-
nuando a análise, percebemos que estes defeitos
não são tratados no momento devido, o que pode
aumentar bastante o custo com o projeto.
Embora simples, esta análise nos permite concluir
que é importante que seja dada maior importância
às atividades relacionadas à especificação dos
requisitos do software.
Tabela 1. Cenário atual de desenvolvimento.
1
Reforçando a importância que as atividades rela-
cionadas a requisitos devem possuir na indústria
de software, estudo realizado pelo Standish
Group, considerando 350 companhias e 8.000
projetos de software, em 1995 revelou que
(ver Figura 1):
· 16,2% dos projetos são finalizados com suces-
so, ou seja, cobre todas as funcionalidades em
tempo e dentro do custo previsto;
· 52.7% dos projetos são considerados problemá-
ticos, ou seja, não cobre todas as funcionalidades
exigidas, custo aumentado e está atrasado.
· 31,1% dos projetos fracassam, ou seja, o projeto
é cancelado durante o desenvolvimento.
Tabela 2. Distribuição da conclusão dos projetos
de software.
O Standish Group ainda fez uma análise sobre os
fatores críticos para sucesso dos projetos de sof-
tware. O resultado dos dez mais lembrados pode
ser visto na Tabela 2. Podemos perceber que três
dos principais fatores estão relacionados às ativi-
dades de requisitos: (1) Requisitos Incompletos;
(2) Falta de Envolvimento do Usuário; (6) Mudan-
ça de Requisitos e Especificações.
Neste ponto, sabemos que um trabalho mais cri-
terioso na área de requisitos é fundamental para
o sucesso de projetos de software. A partir da
próxima seção conheceremos a definição de re-
quisitos e algumas de suas definições relaciona-
das antes de discutirmos mais profundamente a
engenharia de requisitos.
Requisitos
Existem diferentes definições encontradas na
literatura técnica para requisitos:
· Um requisito é uma característica do sistema ou
a descrição de algo que o sistema é capaz de
realizar para atingir os seus objetivos;
· As descrições das funções e restrições são os
requisitos do sistema;
· Um requisito é uma propriedade que o software
deve exibir para resolver algum problema no
mundo real;
· Uma condição ou uma capacidade que deve ser
alcançada ou estar presente em um sistema para
satisfazer um contrato, padrão, especificação ou
outro documento formalmente imposto...
Percebe-se que as citações encontradas definem
o mesmo conceito sob diferentes perspectivas.
Podemos entender requisitos como sendo o con-
junto de necessidades explicitadas pelo cliente
que deverão ser atendidas para solucionar um
determinado problema do negócio no qual o clien-
te faz parte.
É importante estar atento para esta definição:
embora o requisito seja definido pelo cliente, nem
sempre o que o cliente quer é o que o negócio
precisa. Cabe à equipe de consultores identificar
a real necessidade do negócio.
Neste contexto, requisitos são importantes para:
· Estabelecer uma base de concordância entre o
cliente e o fornecedor sobre o que o software
fará;
· Fornecer uma referência para a validação do
produto final;
· Reduzir o custo de desenvolvimento (como vi-
mos anteriormente, requisitos mal definidos cau-
sam retrabalho).
Entendida a definição de requisitos, é preciso
conhecer seus tipos.
Requisitos Funcionais
2
São requisitos diretamente ligados a funcionali-
dade do software, descrevem as funções que o
software deve executar. Alguns exemplos são:
· O software deve permitir o cadastro de clientes;
· O software deve permitir a geração de relatórios
sobre o desempenho de vendas no semestre;
· O software deve permitir o pagamento das com-
pras através de cartão de crédito.
Requisitos não Funcionais
São requisitos que expressam condições que o
software deve atender ou qualidades específicas
que o software deve ter. Em vez de informar o
que o sistema fará, os requisitos não-funcionais
colocam restrições no sistema. Alguns exemplos
são:
· Processo de descobrir, analisar, documentar e
verificar as funções e restrições do sistema.
Embora coerentes, estas definições podem ser
melhoradas. Perceba que elas referem-se apenas
às atividades relacionadas à produção de requisi-
tos. Entretanto, nada é dito a respeito da gerência
destas atividades, também conhecida como ge-
rência de requisitos. Com isto em mente, pode-
mos evoluir a definição de engenharia de requisi-
tos para: termo usado para descrever as ativida-
des relacionadas à produção (levantamento, re-
gistro, validação e verificação) e gerência (contro-
le de mudanças, gerência de configuração, ras-
treabilidade, gerência de qualidade dos requisi-
tos) de requisitos. A Figura 3 representa essa
definição.

· O software deve ser compatível com os

browsers IE (versão 5.0 ou superior) e Firefox
(1.0 ou superior);

· O software deve garantir que o tempo de retorno

das consultas não seja maior do que 5 segundos.

Requisitos de Domínio

São requisitos derivados do domínio da aplicação

e descrevem características do sistema e quali-
dades que refletem o domínio. Podem ser requisi-
tos funcionais novos, restrições sobre requisitos
existentes ou computações específicas. Dois
exemplos de requisitos do domínio são:
· O cálculo da média final de cada aluno é dado
pela fórmula: (Nota1 * 2 + Nota2 * 3)/5;
Figura 3. Engenharia de Requisitos.
Desta forma, os dois conceitos base (produção e
gerência) devem ser considerados em conjunto
ao se definir estratégias de trabalho com requisi-
tos nas organizações (ver Figura 4).

· Um aluno pode se matricular em uma disciplina

desde que ele tenha sido aprovado nas discipli-
nas consideradas pré-requisitos.

A partir da próxima seção apresentaremos os

conceitos envolvidos na engenharia de requisitos.

Engenharia de Requisitos Figura 4. Produção e Gerência de Requisitos.

Existem diferentes definições encontradas na
literatura técnica para engenharia de requisitos:
· Termo usado para descrever as atividades rela-
cionadas à investigação e definição de escopo de
um sistema de software;
· Processo sistemático de desenvolvimento de
requisitos através de um processo cooperativo de
análise onde os resultados das observações são
codificados em uma variedade de formatos e a
acurácia das observações é constantemente veri-
ficada;
Neste ponto podemos citar alguns dos principais
objetivos da engenharia de requisitos:
· estabelecer uma visão comum entre o cliente e
a equipe de projeto em relação aos requisitos que
serão atendidos pelo projeto de software;
· registrar e acompanhar requisitos ao longo de
todo o processo de desenvolvimento;
· documentar e controlar os requisitos alocados
para estabelecer uma baseline para uso gerencial
e da engenharia de software;

3
· manter planos, artefatos e atividades de softwa-
re consistentes com os requisitos alocados.
Para apoiar o alcance destes objetivos, é impor-
tante que se tenha um processo de engenharia
de requisitos bem definido. Um processo de en-
genharia de requisitos é um conjunto estruturado
de atividades a serem seguidas para criar, validar
e manter um documento de requisitos. Poucas
organizações têm um processo de ER explicita-
mente definido e padronizado. Entretanto, sugere-
se que cada organização deva desenvolver um
processo adequado à sua realidade. A Figura
5 apresenta um modelo genérico de atividades
que pode descrever a maioria dos processos de
engenharia de requisitos. Perceba que ele está
concentrado nas atividades de produção dos re-
quisitos
Figura 5. Processo de Engenharia de Requisitos.
Apesar do aparente fluxo entre as atividades, não
existe uma fronteira explícita elas. Na prática
existe muita sobreposição e interação entre uma
atividade e outra.
Como entradas para o processo são considera-
das:
· Descrições do que os stakeholders necessitam
para suportar suas atividades;
· Informações a respeito do sistema que será
substituído ou de qualquer sistema com o qual o
sistema sendo definido terá que interagir;
· Padrões vigentes na organização a respeito de
práticas de desenvolvimento de sistemas, gerên-
cia de qualidade, etc.;
· Regulamentos externos, tais como leis, regula-
mentos de segurança ou saúde;
· Informações gerais sobre o domínio de aplica-
ção.
Em paralelo à execução das atividades definidas
no processo da Figura 5, está o processo de
gerência dos requisitos, voltado ao endereçamen-
to de modificações nos requisitos. Os aspectos
relacionados às atividades de gerência podem ser
vistos na Figura 3.
A partir de agora conheceremos cada um dos
conceitos que, em conjunto, definem a engenha-
ria de requisitos.
Produção de Requisitos
A cada fase do ciclo de vida do software produzi-
mos um documento contendo uma representação
distinta do software a ser construído. Cada um
desses documentos representa o software em um
determinado nível de abstração. A tendência é
diminuirmos o nível de abstração através da in-
clusão de mais e mais detalhes, até que, sua
última representação seja o código fonte na lin-
guagem escolhida.
Um dos artefatos produzidos no início do proces-
so de desenvolvimento de software é a sua espe-
cificação de requisitos. Ele é base para as demais
atividades de desenvolvimento e sua qualidade é
fundamental para o sucesso do projeto. Uma
especificação de requisitos bem elaborada é pré-
requisito para um software de qualidade, embora
não seja garantia disso. Desta forma, durante a
produção de requisitos devemos possuir, além
das atividades essenciais de levantamento e es-
pecificação, atividades relacionadas à garantia da
qualidade. Conheceremos nesta seção as quatro
atividades base relacionadas com a produção de
requisitos.
Levantamento
Esta atividade relaciona-se à obtenção dos requi-
sitos do software. Para isto, analistas e engenhei-
ros de software trabalham com clientes e usuários
finais para descobrir o problema a ser resolvido,
os serviços do sistema, o desempenho necessá-
rio, restrições de hardware e outras informações.
Existem algumas técnicas que apóiam as ativida-
des de levantamento de requisitos. Uma breve
descrição de algumas delas é:
· Entrevista: esta técnica resume-se em “conver-
sas” realizadas com o usuário (entrevistado) para
levantar os requisitos do sistema a ser desenvol-
vido. Podemos decompor esta técnica nas se-
guintes atividades:
 Ler material de suporte;
 Estabelecer os objetivos da entrevista;
 Decidir quem entrevistar;
 Preparar o entrevistado;
4
 Decidir os tipos de questões e a sua estru-
tura.
Uma entrevista pode ser estruturada de três dife-
rentes formas:
- Estrutura em pirâmide: iniciamos as entrevistas
com perguntas mais especificas sobre o sistema
e fechamos com perguntas mais genéricas. Ge-
ralmente utilizadas com usuários mais relutantes;
de Requisitos para o sistema com consenso de
todos de forma a ser uma validação formal dos
requisitos do sistema.
O JAD é divido quem quatro fases. A Figura
6 apresenta estas fases e os artefatos produzidos
por cada uma delas.

- Estrutura em funil: iniciamos as entrevistas com

perguntas mais genéricas sobre o sistema e fe-
chamos com perguntas mais especificas. Geral-
mente utilizadas com usuários que tem uma rela-
ção mais afetiva com o assunto;

- Estrutura em diamante: esta estrutura combina

as duas estruturas anteriores e é utilizada para
manter a usuário entrevistado interessado no
assunto e para isto se utiliza de perguntas varia- Figura 6. Fases da técnica para levantamento de
das. requisitos JAD.

- Prototipação: é uma versão inicial de um A atividade de levantamento de requisitos não é

sistema para experimentação. Permite aos
utilizadores identificar os pontos fortes e fracos do
sistema por ser algo concreto que pode ser
criticado. Temos dois tipos de protótipos:
- Protótipos “Throw-away”: ajudam o levantamen-
to e desenvolvimento dos requisitos e suportam
os requisitos mais difíceis de perceber;
trivial. Existe um conjunto grande e variado de
fatores que a tornam complexa, por exemplo:
- Falta de conhecimento do usuário das suas
reais necessidades
- Usuário com vaga noção do que precisa e do
que um produto de software pode oferecer.

- Protótipos Evolutivos: ajudam o desenvolvimen- - Falta de conhecimento do desenvolvedor do

to rápido de uma versão inicial do sistema e su-
portam os requisitos bem definidos e conhecidos.
Algumas das desvantagens da prototipação são
os custos de aprendizagem e os custos de
desenvolvimento.
- JAD (Joint Application Development): é uma
técnica que permite a interação entre pessoas
que necessitam tomar decisões que afetem múlti-
plas áreas de uma organização. Esta técnica
envolve atividades de preparação para as reuni-
ões, sessões de workshop com os participantes,
agenda para as reuniões, participantes assumin-
do papeis de facilitador / condutor e documenta-
dor além de facilidades visuais, como a utilização
de flipchart, quadro negro.
Esta técnica deve ser utilizada nos casos onde
existe a necessidade de consenso entre diversos
usuários, pois possibilita a todos os envolvidos ter
uma visão global do sistema, ajudando a consoli-
dar interesses de diversos usuários quanto ao
sistema a ser desenvolvido.
O objetivo desta técnica é aumentar o comprome-
timento e participação do usuário e obter subsí-
dios para elaborar o documento de Especificação
domínio do problema
- Desenvolvedor sem conhecimento adequado do
domínio, o que leva a decisões erradas.
- Domínio do processo de levantamento de requi-
sitos pelos desenvolvedores
- Desenvolvedor não ouve o que os usuários têm
a dizer e força suas próprias visões e interpreta-
ções.
- Comunicação inadequada entre os desenvolve-
dores e usuários
- Usuários incapazes de expressar suas necessi-
dades apropriadamente;
- Significados diferentes a termos comuns.
- Dificuldade do usuário tomar decisões
- Falta de entendimento sobre as consequências
das decisões ou as alternativas possíveis.
- Problemas de comportamento
- O levantamento de requisitos é um processo
social;

5
- Conflitos e ambiguidades nos papéis que os
usuários e desenvolvedores desempenham.
- Questões técnicas
- Complexidade crescente dos sistemas atuais.
Registro
Uma vez identificados e negociados, os requisitos
devem ser documentados para que possam servir
de base para o restante do processo de desen-
volvimento.
Entre os muitos problemas que enfrentamos na
documentação de requisitos, certamente, admi-
nistrar o grande volume de informações gerado
pelo processo de requisitos é um dos principais.
Os requisitos são documentados em um nível
apropriado de detalhe. Em geral é produzido um
documento de especificação de requisitos, de
forma que todos os stakeholders possam enten-
dê-lo.
O registro dos requisitos num documento próprio
facilita o controle de alterações de todos os en-
volvidos na manutenção dos requisitos, bem co-
mo a geração de versões do documento e a faci-
lidade de acesso por todos os envolvidos.
Verificação
Esta atividade examina a especificação do sof-
tware, de forma a assegurar que todos os requisi-
tos foram definidos sem ambiguidades, inconsis-
tências ou omissões, detectando e corrigindo
possíveis problemas ainda durante a fase de de-
finição dos requisitos.
Neste contexto, sabe-se que o custo da correção
de defeitos aumenta na medida em que o proces-
so de desenvolvimento progride. Revisões de
artefatos de software têm se mostrado uma abor-
dagem eficiente e de baixo custo para encontrar
defeitos logo após terem sido introduzidos, redu-
zindo o retrabalho e melhorando a qualidade dos
produtos. Não é em vão que modelos de maturi-
dade de processo de software, como o CMMI e o
MPS BR exigem a condução de revisões.
Um tipo particular de revisão de software são as
inspeções. Inspeções possuem um processo de
detecção de defeitos rigoroso e bem definido. Os
benefícios de se aplicar inspeções são maiores
para artefatos desenvolvidos no início do proces-
so, como o documento de requisitos. Conhece-
remos um pouco mais sobre inspeção de softwa-
re em um segundo artigo a ser publicado na se-
gunda edição da Engenharia de Software Maga-
zine.
Validação
A validação representa a atividade em que obte-
mos o aceite do cliente sob determinado artefato.
No cenário de engenharia de requisitos, esta ati-
vidade significa aprovar junto ao cliente os requi-
sitos que foram especificados. Embora aparente-
mente simples, esta atividade pode ser bastante
dificultada pelo cliente ou mesmo por um proces-
so de validação inadequado utilizado pela empre-
sa.
Gerência de Requisitos
Requisitos são por natureza voláteis. Diversos
fatores contribuem para sua instabilidade ao lon-
go do tempo. Mudanças externas no ambiente
(mudanças de legislação, mudanças no mercado,
mudança no posicionamento estratégico da em-
presa), erros incorridos no processo de requisitos,
entre outros. Todos esses fatores fazem com que
seja necessário alterar os requisitos. Tais altera-
ções precisam ser conduzidas de forma ordenada
para que não se perca controle sobre o prazo e o
custo do desenvolvimento.
Denominamos a atividade de administrar os re-
quisitos ao longo do tempo de gerenciamento de
requisitos. Os benefícios desta atividade são per-
cebidos no médio prazo, sendo que são necessá-
rios investimentos no curto prazo. Assim, a ativi-
dade é, muitas vezes, tida como um fardo desne-
cessário à condução do processo. Contudo, sua
não implementação faz com que as economias de
curto prazo sejam logo suplantadas pelas despe-
sas no longo prazo, verificadas com superação de
custo e prazo nos projetos conduzidos.
Veremos a partir de agora algumas das ativida-
des que devem ser consideradas durante a ge-
rência dos requisitos.
Controle de Mudanças
Conforme foi citado anteriormente, os requisitos
são voláteis e, portanto, sofrem mudanças ao
logo do tempo, para conduzir estas mudanças
recomenda-se preparo e planejamento. Uma das
maneiras bastante utilizadas para organizar estas
mudanças é a “baseline” de requisitos que nos
permite diferenciar o que era o requisito original, o
que foi introduzido e o que foi descartado. Além
disto, é interessante estabelecer um único canal
para controle de mudanças, bem como utilizar um
sistema para este controle.
Apresentamos a seguir uma sugestão de passos
que devem ser seguidos para um processo de
controle de mudança:
· Checar validade da solicitação de mudança;
6
· Identificar os requisitos diretamente afetados
com a mudança;
· Identificar dependências entre requisitos para
buscar os requisitos afetados indiretamente;
· Assegurar com solicitante a mudança a ser rea-
lizada;
· Estimar custos da mudança;
· Obter acordo com usuário sobre o custo da mu-
dança.
Após a realização desta análise, podemos aceitar
ou rejeitar a mudança, conforme os impactos e
custos que ela pode ter no sistema.
Gerência de Configuração
Durante o ciclo de vida do desenvolvimento, o
software passa por uma série de modificações,
desde a especificação dos requisitos até a im-
plantação do sistema. A gerência de configuração
de software existe no intuito de definir critérios
que permitam realizar tais modificações manten-
do-se a consistência e a integridade do software
com as especificações, minimizando problemas
decorrentes ao processo de desenvolvimento,
através de um controle sistemático sobre as mo-
dificações.
A criação de um plano de gerência de configura-
ção consiste em estabelecer normas, ferramentas
e templates que permitam gerenciar de maneira
satisfatória os itens de configuração de um siste-
ma, que são definidos por Pressman como: “cada
um dos elementos de informação que são criados
durante o desenvolvimento de um produto de
software, ou que para este desenvolvimento se-
jam necessários, que são identificados de manei-
ra única e cuja evolução é passível de rastrea-
mento”.
Em cada fase do processo de desenvolvimento,
um conjunto bem definido de itens de configura-
ção deve ser estabelecido. A este conjunto é da-
do o nome de baselines. Estas baselines servem
como marco no processo de desenvolvimento,
pois ao final de cada fase é estabelecida uma
nova baseline e, portanto, todos os itens de confi-
guração estão sob total controle de seus desen-
volvedores. Desta forma, nesta baseline é guar-
dada “uma foto” dos artefatos criados até aquele
momento:
· tornando mais fácil realizar modificações nos
artefatos de maneira controlada;
· possibilitando ter um controle sistemático sobre
todos os itens de configuração abordados em
cada fase do ciclo de vida do software, e;
· tornando possível que sejam realizadas, mais
facilmente, avaliações sobre seu grau de evolu-
ção.
Rastreabilidade
No centro da atividade de gerenciamento de re-
quisitos está a rastreabilidade. Esta é definida
como a habilidade de se acompanhar a vida de
um requisito em ambas as direções (por exemplo:
partindo de requisitos e chegando a projeto ou,
partindo de projeto e chegando a requisitos) do
processo de software e durante todo o seu ciclo
de vida.
A dificuldade envolvida com a rastreabilidade está
no grande volume de informações gerado. As
informações do processo de requisitos devem ser
catalogadas e associadas aos outros elementos
de forma que possam ser referenciadas através
dos diversos itens de informação registrados. É
um trabalho extenso que, sem o auxílio de ferra-
mentas adequadas, muito provavelmente não
poderá ser feito
Para implementar a rastreabilidade, usualmente é
confeccionado em conjunto com a especificação
de requisitos um artefato chamado matriz de ras-
treabilidade, que tem como objetivo mapear os
rastros dos requisitos descritos na especificação.
Os rastros dos requisitos podem ser de dois tipos:
· Pré-rastreabilidade: os rastros (artefatos: plano
de negócio, atas de reunião com o usuário) que
fundamentaram a criação do requisito.
· Pós-rastreabilidade: os rastros (artefatos: códi-
go, documentos) que se formaram a partir do
requisito criado.
Gerência de Qualidade de Requisitos
Segundo o padrão IEEE 830, devemos considerar
alguns critérios de qualidade ao trabalharmos
com requisitos:
· Correção: um documento de requisitos é consi-
derado correto se todos os requisitos represen-
tam algo que deve estar presente no sistema que
está sendo desenvolvido, ou seja, os requisitos
reais do usuário devem coincidir com os requisi-
tos identificados. Esta não é uma tarefa trivial e
parte de seu sucesso está associada a uma boa
atividade de validação dos requisitos.
· Não ambiguidade: um conjunto de requisitos é
não ambíguo quando somente pode ser interpre-
tado por todos os envolvidos em um projeto de
uma única maneira.
7
· Completude: um conjunto de requisitos é dito
completo quando descreve todas as demandas
de interesse dos usuários. Estas demandas inclu-
em requisitos funcionais, de desempenho, restri-
ções, atributos e interfaces externas.
· Consistência: um conjunto de requisitos é dito
consistente se nenhum subconjunto destes requi-
sitos entra em conflito com os demais requisitos
do sistema.
· Verificabilidade: um requisito é verificável se
existe uma forma efetiva, em termos de tempo e
custo, para que pessoas ou ferramentas indiquem
se um sistema cumpre o requisito (IEEE). Em
quase todas as situações, é difícil provar de forma
conclusiva que um requisito é cumprido por um
software. Entretanto, escrever bem o requisito
pode ajudar a aumentar a confiança na avaliação.
· Modificabilidade: um conjunto de requisitos é
modificável quando seu estilo e estrutura é tal que
as alterações podem ser realizadas de forma
simples e consistente com os demais requisitos.
A gerência, neste cenário, é responsável por
manter uma infraestrutura necessária para ativi-
dades de verificação que tornem possível investi-
garmos a qualidade dos requisitos que estamos
definindo.
Técnicas de Elicitação de Requisitos
O Levantamento de Requisitos de Software
O início para toda a atividade de desenvolvimento
de software é o levantamento de requisitos, sen-
do esta atividade repetida em todas as demais
etapas da engenharia de requisitos.
Sommerville (2003) propõe um processo genérico
de levantamento e análise que contém as seguin-
tes atividades:
 Compreensão do domínio: Os analistas
devem desenvolver sua compreensão do domínio
da aplicação;
 Coleta de requisitos: É o processo de inte-
ragir com os stakeholders do sistema para des-
cobrir seus requisitos. A compreensão do domínio
se desenvolve mais durante essa atividade;
 Classificação: Essa atividade considera o
conjunto não estruturado dos requisitos e os or-
ganiza em grupos coerentes;
 Resolução de conflitos: Quando múltiplos
stakeholders estão envolvidos, os requisitos
apresentarão conflitos. Essa atividade tem por
objetivo solucionar esses conflitos;
 Definição das prioridades: Em qualquer
conjunto de requisitos, alguns serão mais impor-
tantes do que outros. Esse estágio envolve inte-
ração com os stakeholders para a definição dos
requisitos mais importantes;
 Verificação de requisitos: Os requisitos são
verificados para descobrir se estão completos e
consistentes e se estão em concordância com o
que os stakeholders desejam do sistema.
O levantamento e análise de requisitos é um pro-
cesso iterativo, com uma contínua validação de
uma atividade para outra, conforme exemplificado
pela Figura 1.
Figura 1. Processo de levantamento e análise de
requisitos (SOMMERVILLE, 2003)
Dificuldades encontradas
O problema de não saber especificar corretamen-
te o que o sistema deverá fazer é muito antigo.
Pompilho (1995) cita um exemplo do relatório
produzido por McKinsey, em 1968, e mencionado
por B. Langefords e B. Sundgren onde se afirma-
va que dois terços das empresas ali estudadas
estavam desapontadas com o atendimento rece-
bido em sistemas de informação.
Após mais de 30 anos da elaboração do relatório
a situação não é muito diferente. Algumas das
razões para o baixo grau de satisfação dos usuá-
rios para os sistemas destacam-se:
 Na fase de levantamento de requisitos do
projeto, onde não é utilizada uma técnica ade-
quada para extrair os requisitos do sistema;
 A falha do analista em não descrever os
requisitos do sistema de modo claro, sem ambi-
guidades, conciso e consistente com todos os
aspectos significativos do sistema proposto.
Entre as dificuldades encontradas na fase de
levantamento de requisitos estão: o usuário prin-
cipal do sistema não sabe o que quer que o sis-
tema faça ou sabe e não consegue transmitir para
o analista; requisitos identificados, mas que não
são realistas e não identificam os requisitos simi-
8
lares informados por pessoas diferentes. Um
stakeholder errado afetará em perda de tempo e
dinheiro para ambas as partes envolvidas no de-
senvolvimento do sistema.
Identifica-se um levantamento de requisitos ade-
quado através da boa definição do projeto, da
efetividade do projeto, de informações necessá-
rias a um perfeito diagnóstico e de soluções inte-
ligentes. Quanto ao levantamento de requisitos
inadequado, o resultado é um diagnóstico pobre
com conclusões comprometidas, não identifica-
ção das causas dos problemas, custos elevados,
prazos vencidos ou comprometedores, omissão
de processos fundamentais e descréditos.
As técnicas de levantamento de requisitos têm
por objetivo superar as dificuldades relativas a
esta fase. Todas as técnicas possuem um concei-
to próprio e suas respectivas vantagens e des-
vantagens, que podem ser utilizadas em conjunto
pelo analista.
Serão apresentadas de forma resumida nesse
artigo algumas técnicas de levantamento de re-
quisitos.
Levantamento Orientado a Pontos de Vista
Para qualquer sistema, de tamanho médio ou
grande, normalmente há diferentes tipos de usuá-
rio final. Muitos stakeholders têm algum tipo de
interesse nos requisitos do sistema. Por esse
motivo, mesmo para um sistema relativamente
simples, existem muitos pontos de vista diferentes
que devem ser considerados. Os diferentes pon-
tos de vista a respeito de um problema ‘veem’ o
problema de modos diferentes. Contudo, suas
perspectivas não são inteiramente independen-
tes, mas em geral apresentam alguma duplicida-
de, de modo que apresentam requisitos comuns.
As abordagens orientadas a ponto de vista, na
engenharia de requisitos, reconhecem esses dife-
rentes pontos de vista e os utilizam para estrutu-
rar e organizar o processo de levantamento e os
próprios requisitos. Uma importante capacidade
da análise orientada a pontos de vista é que ela
reconhece a existência de várias perspectivas e
oferece um framework para descobrir conflitos
nos requisitos propostos por diferentes stakehol-
ders.
O método VORD (viewpoint-oriented require-
ments definition – definição de requisitos orienta-
da a ponto de vista) foi projetado como um fra-
mework orientado a serviço para o levantamento
e análise de requisitos.
A primeira etapa da análise de ponto de vista é
identificar os possíveis pontos de vista. Nessa
etapa os analistas se reúnem com os stakehol-
ders e utilizam a abordagem de brainstorming
para identificar os serviços em potencial e as
entidades que interagem com o sistema.
A segunda etapa é a estruturação de pontos de
vista, que envolve agrupar pontos de vista relaci-
onados, segundo uma hierarquia. Serviços co-
muns estão localizados nos níveis mais altos da
hierarquia e herdados por pontos de vista de nível
inferior.
A etapa de documentação do ponto de vista tem
por objetivo refinar a descrição dos pontos de
vista e serviços identificados.
O mapeamento de sistema conforme ponto de
vista envolve identificar objetos em um projeto
orientado a objetos, utilizando as informações de
serviço que estão encapsuladas nos pontos de
vista.
A Figura 2 exemplifica a técnica de levantamento
orientado a ponto de vista.
Figura 2. Método VORD, SOMMERVILLE – 2003
Etnografia
A etnografia é uma técnica de observação que
pode ser utilizada para compreender os requisitos
sociais e organizacionais, ou seja, entender a
política organizacional bem como a cultura de
trabalho com objetivo de familiarizar-se com o
sistema e sua história. Os cientistas sociais e
antropólogos usam técnicas de observação para
desenvolver um entendimento completo e deta-
lhado de culturas particulares.
Nesta técnica, o analista se insere no ambiente
de trabalho em que o sistema será utilizado. O
trabalho diário é observado e são anotadas as
tarefas reais em que o sistema será utilizado. O
principal objetivo da etnografia é que ela ajuda a
descobrir requisitos de sistema implícitos, que
refletem os processos reais, em vez de os pro-
cessos formais, onde as pessoas estão envolvi-
das.
Etnografia é particularmente eficaz na descoberta
de dois tipos de requisitos:
 Os requisitos derivados da maneira como
as pessoas realmente trabalham, em vez da ma-
neira pelas quais as definições de processo di-
zem como elas deveriam trabalhar;
9
 Os requisitos derivados da cooperação e
conscientização das atividades de outras pesso-
as.
Alguns itens importantes que devem ser executa-
dos antes, durante e depois do estudo de obser-
vação:
 Antes, é necessário identificar as áreas de
usuário a serem observadas; obter a aprovação
das gerências apropriadas para executar as ob-
servações; obter os nomes e funções das pesso-
as chave que estão envolvidas no estudo de ob-
servação; e explicar a finalidade do estudo;
 Durante, é necessário familiarizar-se com o
local de trabalho que está sendo observado. Para
isso é preciso observar os agrupamentos organi-
zacionais atuais; as facilidades manuais e auto-
matizadas; coletar amostras de documentos e
procedimentos escritos que são usados em cada
processo específico que está sendo observado; e
acumular informações estatísticas a respeito das
tarefas, como: frequência que ocorrem, estimati-
vas de volumes, tempo de duração para cada
pessoa que está sendo observada. Além de ob-
servar as operações normais de negócios acima
é importante observar as exceções;
 Depois, é necessário documentar as des-
cobertas resultantes das observações feitas. Para
consolidar o resultado é preciso rever os resulta-
dos com as pessoas observadas e/ou com seus
superiores.
A análise de observação tem algumas desvanta-
gens como, consumir bastante tempo e o analista
ser induzido a erros em suas observações. Mas
em geral a técnica de observação é muito útil e
frequentemente usada para complementar des-
cobertas obtidas por outras técnicas.
Workshops
Trata-se de uma técnica de elicitação em grupo
usada em uma reunião estruturada. Devem fazer
parte do grupo uma equipe de analistas e uma
seleção dos stakeholders que melhor represen-
tam a organização e o contexto em que o sistema
será usado, obtendo assim um conjunto de requi-
sitos bem definidos.
Ao contrário das reuniões, onde existe pouca
interação entre todos os elementos presentes, o
workshop tem o objetivo de acionar o trabalho em
equipe. Há um facilitador neutro cujo papel é con-
duzir a workshop e promover a discussão entre
os vários mediadores. As tomadas de decisão
são baseadas em processos bem definidos e com
o objetivo de obter um processo de negociação,
mediado pelo facilitador.
Uma técnica utilizada em workshops é o brains-
torming. Após os workshops serão produzidas
documentações que refletem os requisitos e deci-
sões tomadas sobre o sistema a ser desenvolvi-
do.
Alguns aspectos importantes a serem considera-
dos: a postura do condutor do seminário deve ser
de mediador e observador; a convocação deve
possuir dia, hora, local, horário de início e de tér-
mino; assunto a ser discutido e a documentação
do seminário.
Prototipagem
Protótipo tem por objetivo explorar aspectos críti-
cos dos requisitos de um produto, implementando
de forma rápida um pequeno subconjunto de fun-
cionalidades deste produto. O protótipo é indicado
para estudar as alternativas de interface do usuá-
rio; problemas de comunicação com outros produ-
tos; e a viabilidade de atendimento dos requisitos
de desempenho. As técnicas utilizadas na elabo-
ração do protótipo são várias: interface de usuá-
rio, relatórios textuais, relatórios gráficos, entre
outras.
Alguns dos benefícios do protótipo são as redu-
ções dos riscos na construção do sistema, pois o
usuário chave já verificou o que o analista captou
nos requisitos do produto. Para ter sucesso na
elaboração dos protótipos é necessária a escolha
do ambiente de prototipagem, o entendimento
dos objetivos do protótipo por parte de todos os
interessados no projeto, a focalização em áreas
menos compreendidas e a rapidez na construção.
Entrevistas
A entrevista é uma das técnicas tradicionais mais
simples de utilizar e que produz bons resultados
na fase inicial de obtenção de dados. Convém
que o entrevistador dê margem ao entrevistado
para expor as suas ideias. É necessário ter um
plano de entrevista para que não haja dispersão
do assunto principal e a entrevista fique longa,
deixando o entrevistado cansado e não produzin-
do bons resultados.
As seguintes diretrizes podem ser de grande auxi-
lio na direção de entrevistas bem-sucedidas com
o usuário: desenvolver um plano geral de entre-
vistas, certificar-se da autorização para falar com
os usuários, planejar a entrevista para fazer uso
eficiente do tempo, utilizar ferramentas automati-
zadas que sejam adequadas, tentar descobrir que
informação o usuário está mais interessado e
usar um estilo adequado ao entrevistar.
Para planejar a entrevista é necessário que antes
dela sejam coletados e estudados todos os dados
10
pertinentes à discussão, como formulários, relató-
rios, documentos e outros. Dessa forma, o analis-
ta estará bem contextualizado e terá mais produ-
tividade nos assuntos a serem discutidos na en-
trevista.
É importante determinar um escopo relativamente
limitado, focalizando uma pequena parte do sis-
tema para que a reunião não se estenda por mais
de uma hora. O usuário tem dificuldade de con-
centração em reuniões muito longas, por isso é
importante focalizar a reunião no escopo definido.
Após a entrevista é necessário validar se o que
foi documentado pelo analista está de acordo
com a necessidade do usuário, que o usuário não
mudou de opinião e que o usuário entende a no-
tação ou representação gráfica de suas informa-
ções.
A atitude do analista em relação à entrevista é
determinar seu fracasso ou sucesso. Uma entre-
vista não é uma competição, deve-se evitar o uso
excessivo de termos técnicos e não conduzir a
entrevista em uma tentativa de persuasão. O
modo como o analista fala não deve ser muito
alto, nem muito baixo, tampouco indiretamente,
ou seja, utilizar os termos: ele disse isso ou aquilo
na reunião para o outro entrevistado. O modo
melhor para agir seria, por exemplo, dizer: O João
vê a solução para o projeto dessa forma. E o se-
nhor André, qual é a sua opinião? Em uma entre-
vista o analista nunca deve criticar a credibilidade
do entrevistado. O analista deve ter em mente
que o entrevistado é o perito no assunto e forne-
cerá as informações necessárias ao sistema.
Para elaborar perguntas detalhadas é necessário
solicitar que o usuário:
 Explique o relacionamento entre o que está
em discussão e as demais partes do sistema;
 Descreva o ponto de vista de outros usuá-
rios em relação ao item que esteja sendo discuti-
do;
 Descreva informalmente a narrativa do item
em que o analista deseja obter informações;
 Perguntar ao usuário se o item em discus-
são depende para a sua existência de alguma
outra coisa, para assim poder juntar os requisitos
comuns do sistema, formando assim um escopo
conciso.
Pode-se utilizar a confirmação, para tanto o ana-
lista deve dizer ao usuário o que acha que ouviu
ele dizer. Neste caso, o analista deve utilizar as
suas próprias palavras em lugar das do entrevis-
tado e solicitar ao entrevistado confirmação do
que foi dito.
Questionários
O uso de questionário é indicado, por exemplo,
quando há diversos grupos de usuários que po-
dem estar em diversos locais diferentes do país.
Neste caso, elaboram-se pesquisas específicas
de acompanhamento com usuários selecionados,
que a contribuição em potencial pareça mais im-
portante, pois não seria prático entrevistar todas
as pessoas em todos os locais.
Existem vários tipos de questionários que podem
ser utilizados. Entre estes podemos listar: múltipla
escolha, lista de verificação e questões com es-
paços em branco. O questionário deve ser de-
senvolvido de forma a minimizar o tempo gasto
em sua resposta.
Na fase de preparação do questionário deve ser
indicado o tipo de informação que se deseja ob-
ter. Assim que os requisitos forem definidos o
analista deve elaborar o questionário com ques-
tões de forma simples, clara e concisa, deixar
espaço suficiente para as repostas que forem
descritivas e agrupar as questões de tópicos es-
pecíficos em um conjunto com um título especial.
O questionário deve ser acompanhado por uma
carta explicativa, redigida por um alto executivo,
para enfatizar a importância dessa pesquisa para
a organização.
Deve ser desenvolvido um controle que identifi-
que todas as pessoas que receberão os questio-
nários. A distribuição deve ocorrer junto com ins-
truções detalhadas sobre como preenchê-lo e ser
indicado claramente o prazo para devolução do
questionário. Ao analisar as respostas dos parti-
cipantes é feito uma consolidação das informa-
ções fornecidas no questionário, documentando
as principais descobertas e enviando uma cópia
com estas informações para o participante como
forma de consideração pelo tempo dedicado a
pesquisa.
Brainstorming
Brainstorming é uma técnica para geração de
idéias. Ela consiste em uma ou várias reuniões
que permitem que as pessoas sugiram e explo-
rem idéias.
As principais etapas necessárias para conduzir
uma sessão de brainstorming são:
 Seleção dos participantes: Os participantes
devem ser selecionados em função das contribui-
ções diretas que possam dar durante a sessão. A
presença de pessoas bem informadas, vindas de
11
diferentes grupos garantirá uma boa representa-
ção;
 Explicar a técnica e as regras a serem se-
guidas: O líder da sessão explica os conceitos
básicos de brainstorming e as regras a serem
seguidas durante a sessão;
 Produzir uma boa quantidade de idéias: Os
participantes geram tantas idéias quantas forem
exigidas pelos tópicos que estão sendo o objeto
do brainstorming. Os participantes são convida-
dos, um por vez, a dar uma única idéia. Se al-
guém tiver problema, passa a vez e espera a
próxima rodada.
No brainstorming as idéias que a princípio pare-
çam não convencionais, são encorajadas, pois
elas frequentemente estimulam os participantes,
o que pode levar a soluções criativas para o pro-
blema. O número de idéias geradas deve ser bem
grande, pois quanto mais idéias forem propostas,
maior será a chance de aparecerem boas idéias.
Os participantes também devem ser encorajados
a combinar ou enriquecer as idéias de outros e,
para isso, é necessário que todas as idéias per-
maneçam visíveis a todos os participantes.
Nesta técnica é designada uma pessoa para re-
gistrar todas as idéias em uma lousa branca ou
em papel. À medida que cada folha de papel é
preenchida, ela é colocada de forma que todos os
participantes possam vê-la.
Analisar as idéias é a fase final do brainstorming.
Nessa fase é realizada uma revisão das idéias,
uma de cada vez. As consideradas valiosas pelo
grupo são mantidas e classificadas em ordem de
prioridade.
JAD
JAD (Joint Application Design) é uma técnica para
promover cooperação, entendimento e trabalho
em grupo entre os usuários desenvolvedores.
O JAD facilita a criação de uma visão comparti-
lhada do que o produto de software deve ser.
Através da sua utilização os desenvolvedores
ajudam os usuários a formular problemas e explo-
rar soluções. Dessa forma, os usuários ganham
um sentimento de envolvimento, posse e respon-
sabilidade com o sucesso do produto.
A técnica JAD tem 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 deter-
minaçã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: pre-
enchida 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 princi-
pais: 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. A fase de adaptação consis-
te na preparação para a sessão, ou seja, organi-
zar a equipe, adaptar o processo JAD ao produto
a ser construído e preparar o material. Na fase de
sessão é realizado um ou mais encontros estrutu-
rados, envolvendo desenvolvedores e usuários
onde os requisitos são desenvolvidos e documen-
tados.
A fase de finalização tem por objetivo converter a
informação da fase de sessão em sua forma final
(um documento de especificação de requisitos).
Há seis tipos de participantes, embora nem todos
participem de todas as fases:
 Líder da sessão: é responsável pelo suces-
so 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 do-
cumentos 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
idéias e expressá-las com clareza;
 Executor: é o responsável pelo produto
sendo construído. Tem que fornecer aos partici-
pantes 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 pro-
jeto do novo produto;
 Representantes dos usuários: são as pes-
soas na empresa que irão utilizar o produto de
software. Durante a extração de requisitos, os
12
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ífi-
co.

O conceito do JAD de abordagem e dinâmica de

grupo poderá ser utilizado para diversas finalida-
des, como: planejamento de atividades técnicas
para um grande projeto, discussão do escopo e
objetivos de um projeto e estimativa da quantida-
de de horas necessárias para desenvolver siste-
mas grandes e complexos.

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 requi-
sitos do sistema.
Não existe uma técnica padrão para o processo
de levantamento de requisitos. Para alcançar um
levantamento de requisitos mais preciso é impor-
tante o conhecimento de diversas técnicas para
saber que técnica de levantamento aplicar em
cada situação.
Tabela 1. Grupos de técnicas para levanta-
mento de requisitos
Gerenciamento de Requisitos
O que é Gerenciamento de Requisitos?
Corresponde ao conjunto de atividades que auxi-
lia a equipe do projeto a identificar, controlar e
rastrear os requisitos, bem como as alterações
nos requisitos em muitos momentos do projeto.

É primordial que o analista possua perfil adequa-
do. O analista de sistemas precisa de mais do
que apenas a capacidade de desenhar fluxogra-
mas e outros diagramas técnicos.
O analista de sistemas tem a função de projetar e
analisar sistemas de ótimo desempenho. Para
que esse objetivo seja alcançado, é necessário o
analista de sistema possuir a capacidade de:
 Compreender conceitos abstratos, reorga-
nizá-los em divisões lógicas e sintetizar soluções
baseadas em cada divisão;
 Absorver fatos pertinentes de fontes confli-
tantes ou confusas;
 Entender os ambientes do usuário/cliente;
 Aplicar elementos do sistema de hardware
e/ou software aos elementos do usuário/cliente;
 Comunicar bem nas formas escrita e verbal
e entender o objetivo global do software.
A Tabela 1 apresenta os grupos de técnicas para
o levantamento de requisitos.
Em outras palavras, é o processo que gerencia
mudanças nos requisitos de um sistema.
Estas mudanças ocorrem conforme os clientes
desenvolvem um melhor entendimento de suas
reais necessidades.
Novos requisitos surgem e há alterações nos
requisitos em todos os estágios do processo de
desenvolvimento do sistema. São comuns os
casos em que mais de 50% dos requisitos são
alterados antes que o sistema seja posto em ope-
ração, o que causa sérios problemas para os
desenvolvedores.
Para minimizar dificuldades, os requisitos devem
ser documentados e controlados.
Quando não há controle de alterações, mudanças
de baixa prioridade podem ser implementadas
antes daquelas de alta prioridade, além de mu-
danças com alto custo não serem necessaria-
mente aprovadas. Um levantamento em mais de
4.000 empresas européia identificou que uma das
principais áreas problemáticas do desenvolvimen-
to e produção de software era o gerenciamento
de requisitos dos clientes (internos e externos).

13
As principais preocupações de gerenciamento de
requisitos são:
 Gerenciar mudanças nos requisitos acor-
dados;
 Gerenciar os relacionamentos entre os
requisitos;
 Gerenciar as dependências entre o docu-
mento de requisitos e outros documentos produ-
zidos ao longo do sistema e do processo de en-
genharia de software.
As mudanças nos requisitos podem ser devidas a
erros e confusão no processo de engenharia de
requisitos, design ou problemas de implementa-
ção. Novos requisitos podem surgir conforme os
stakeholders desenvolvem uma melhor compre-
ensão do sistema ou em decorrência de altera-
ções em circunstâncias externas como novas leis
ou regulamentações introduzidas no ambiente de
negócio.
Os requisitos não podem ser gerenciados de for-
ma efetiva sem rastreabilidade. Um requisito é
rastreável se for possível identificar quem solici-
tou o requisito, porque o requisito existe, quais os
requisitos relacionados e como os requisitos se
relacionam as outras informações como design
de sistemas, implementações e documentos do
usuário. Estas informações são utilizadas para
identificar todos os requisitos afetados por mu-
danças propostas.
Boas práticas de gerenciamento de requisitos,
como uma manutenção de dependências entre
requisitos, têm benefícios em longo prazo, como
maior satisfação do cliente e custos de desenvol-
vimento mais baixos. Uma vez que os retornos
não são imediatos, o gerenciamento de requisitos
pode parecer uma despesa desnecessária. Entre-
tanto, sem a gerencia, a economia de curto prazo
será devastada pelos custos em longo prazo.
Os problemas com gerenciamento de requisitos
geralmente significam que os clientes não ficarão
satisfeitos quando da entrega do produto.
Ferramentas de gerenciamento de requisitos po-
dem prover facilidades como:
 Um sistema de banco de dados para arma-
zenamento de requisitos;
 Análise de documento e facilidades de
geração para ajudar a construir um banco de
dados de requisitos e auxiliar na criação dos do-
cumentos de requisitos;
 Facilidades de gerenciamento de mudan-
ças que ajudam a garantir que as mudanças fo-
ram avaliadas e cotadas corretamente;
 Facilidades de rastreabilidade que auxiliam
os engenheiros de requisitos a encontrar depen-
dências entre requisitos.
Especificação de Requisitos
A especificação de requisitos tem como objetivo
obter produtos de software de melhor qualidade
que satisfaçam às reais necessidades dos clien-
tes dentro de prazo e orçamento adequados.
Podemos entender requisito como uma função,
restrição ou propriedade que deve ser fornecida,
encontrada ou atendida para satisfazer às neces-
sidades do usuário do sistema. (Descreve um
serviço ou uma limitação)
Está comprovado: a maior parte dos problemas,
os de maior impacto negativo e os mais onerosos
tem origem nas etapas iniciais do desenvolvimen-
to de software. Justamente nas etapas de especi-
ficação dos requisitos é onde as principais ativi-
dades são definidas e onde os requisitos do pro-
duto devem ser identificados e mapeados com
objetividade e clareza.
Podemos dizer que as principais causas para o
fracasso dos projetos de software são: especifi-
cação de requisitos mal formulada e alterações
constantes nos requisitos.
Por serem atividades bases do processo de de-
senvolvimento de software as falhas cometidas
nas atividades de definição e validação de requi-
sitos irão originar documentos de requisitos in-
consistentes afetando as etapas seguintes de
projeto, implementação e testes e gerando produ-
tos de softwares de baixa qualidade.
Embora não exista um modelo padrão consagra-
do para gerenciar requisitos podemos definir al-
guns passos para um processo de especificação
de requisitos: (Soares, 2005) (Os processos de-
vem ser adaptados a cada necessidade / conjun-
tura)
1. Descoberta dos requisitos - consultas, do-
cumentos, pesquisas, entrevistas, JAD (Joint
Application Design);
2. Análise dos requisitos identificados com
refinamento e detalhamento dos mesmos;
3. Modelagem e Validação dos requisitos
verificando sua consistência (Documento de re-
quisitos);
4. Acompanhamento dos requisitos;
14
Ao final deste processo deve-se ter um documen-
to de requisitos bem definido e entendido por
todos os intervenientes do processo: Clientes,
desenvolvedores, líderes, analistas, gerentes,
patrocinadores, etc. (stakeholders)
Mas o que é Especificar um Requisito?
Especificar um requisito implica em compreender
exatamente o que deve ser feito e que se espera
receber como resultado.
Podemos classificar os requisitos em:
 Funcionais - descrevem as funcionalidades
do sistema desejadas pelos clientes, ou seja, O
QUE se espera que o software faça;
 Não funcionais - São as qualidades e res-
trições globais do sistema relacionados com ma-
nutenção, uso, desempenho, custo, interface,
etc...
Exemplos de requisitos funcionais:
O sistema deve possibilitar o cadastramento
dos dados pessoais dos clientes;
O sistema deve emitir relatórios gerenciais;
O sistema deve permitir a baixa automática do
estoque quando da venda de um produto;
A Norma ISO / IEC 9126 define seis característi-
cas de qualidade de software que devem ser ava-
liadas:
 Funcionalidade (finalidade do produto);
 Usabilidade (esforço para utilizar, aprender
o produto);
 Confiabilidade (frequência de falhas, recu-
perabilidade);
 Eficiência (característica relacionada
desempenho);
 Manutenibilidade (esforço necessário para
modificar);
 Portabilidade (capacidade de transferir o
produto para outros ambientes).
Exemplos de requisitos não funcionais:
tempo de resposta do sistema não deve ultra-
passar 10 segundos;
software deve ser operacionalizado no sistema
Windows;
O banco de dados usado deverá ser o Oracle;
Obs: "Os requisitos não funcionais são críticos
para o sucesso de sistemas de software e estão
diretamente relacionados com a satisfação dos
usuários. Devido a essa importância, alguns re-
quisitos funcionais podem ser sacrificados para
atender às restrições impostas pelos requisitos
não funcionais"
O documento de requisitos de sistema - DRS -
pode ser entendido como a descrição formal e
oficial onde é descrita e comunicada os requisitos
a todos os envolvidos no processo de desenvol-
vimento de software (stakeholders). Ele é basi-
camente composto de:
1. Os serviços e funções que o sistema deve
prover;
2. As limitações sobre as quais o sistema
deve operar;
3. Definições de outros sistemas com os
quais o sistema deve integrar;
4. Limitações no processo usado para desen-
volver o sistema;
5. Descrições sobre o hardware no qual o
sistema irá executar
Os requisitos podem ser modelados e validados
através de casos de uso que incluem o diagrama
de casos de uso e a especificação do caso de
uso.
Um caso de uso representa uma funcionalidade
completa, conforme percebida pelo ator e é defi-
nido como "um conjunto de seqüências de ações
que um sistema executa que produzem um resul-
tado observável por um particular ator".
Os casos de uso é uma das técnicas usadas para
descrever claramente todos os requisitos de um
ao dado sistema, esta técnica foi proposta por Ivar
Jacobson em sua metodologia de desenvolvi-
mento de sistemas orientados a objetos , visando
identificar os requisitos de um sistema.
O Diagrama de Casos de Uso fornece um modo
de descrever a visão externa do sistema e suas
interações com o mundo exterior, representando
uma visão de alto nível da funcionalidade do sis-
tema mediante uma requisição do usuário.
O modelo de casos de uso é um formato ágil para
capturar requisitos de software. Ele contrasta com
documentos maiores e descritivos que tentam
conter todos os requerimentos possíveis antes do
início da construção de um novo sistema, mas
15
falham completamente neste intento. Os princi-
pais benefícios dos casos de uso na modelagem
de requisitos são:
1. Os casos de uso podem ser facilmente
adicionados ao projeto de software e removidos
do projeto de software assim que as prioridades
mudarem;
2. Os casos de uso podem também servir
como base para estimar, escalonar e validar es-
forços;
3. Uma razão porque os casos de uso se
tornaram populares: são fáceis de entender por
pessoas da área de negócio e assim provaram
ser uma excelente ponte entre quem desenvolve
o software e os utilizadores finais.
Os casos de uso também têm as suas dificulda-
des. São excelentes para capturar os requisitos
funcionais de um sistema, mas não têm tanto
sucesso em capturar os não funcionais.
É importante notar que os modelos de casos de
uso não descrevem como o software deverá ser
construído, e sim, como ele deverá se comportar.
As descrições de casos de uso normalmente evi-
tam o uso de termos técnicos, preferindo a lin-
guagem do usuário final. Normalmente, os casos
de uso são feitos por quem desenvolve o software
e/ou por quem vai utilizar esse mesmo software.
Propósitos básicos:
1. Decidir e descrever os requisitos funcionais
do sistema;
2. Prover uma descrição clara e consistente
do que o sistema deve fazer;
3. Prover a base para a realização de testes
que validam e verificam o sistema;
4. Prover facilidades para rastrear requisitos
funcionais dentro das classes e operações do
sistema.
Principais Componentes do Modelo de Casos de
Uso:
 Caso de uso: especifica uma funcionalida-
de completa do sistema. É sempre iniciado por
um ator (direta ou indiretamente ordena ao siste-
ma a execução de um caso de uso);
 Ator: entidade externa que interage com os
casos de uso;
 Sistema: conjunto de casos de uso
A seguir temos a sequência que pode ser usada
para construir o modelo de casos de uso:
Definir o Sistema (conjunto de casos de uso);
Encontrar Os Atores;
Encontrar E Descrever Os Casos De Uso;
Definir Os Relacionamentos Entre Os Casos
De Uso;
Validar O Modelo.
Como Identificar um Ator?
As respostas às seguintes perguntas podem auxi-
liar na identificação dos atores:
1. Quem utiliza a principal funcionalidade do
sistema?
2. Quem vai precisar de suporte do sistema
para realizar suas tarefas diárias?
3. Quem precisa manter administrar e deixar
o sistema "rodando"?
4. Quais dispositivos de hardware o sistema
precisa manipular?
5. Com quais outros sistemas o sistema pre-
cisa interagir?
6. Quem ou o quê tem interesse nos resulta-
dos produzidos pelo sistema?
Propriedades de um caso de uso
 A descrição resumida do caso de uso é
uma breve descrição do caso de uso.
 Fluxo principal descreve o fluxo natural
seguido pelo caso de uso se todas as hipóteses
foram verdadeiras e se nenhum erro tiver ocorri-
do.
 Os fluxos alternativos representam os des-
vios alcançados pela execução do caso de uso,
causados pelos atores, por condições intrínsecas
ao caso de uso ou por erros ou exceções.
 Os pontos de extensões são somente rótu-
los que indicam, nos fluxos, a extensão do caso
de uso. Podem existir vários pontos de extensões
no mesmo fluxo.
Como identificar um caso de uso?
As respostas às perguntas abaixo podem auxiliar
a identificar os Casos de Uso:
16
1. Quais funções o ator requer do sistema? O
que o ator precisa fazer?
2. Ator precisa criar, ler, destruir, modificar ou
armazenar algum tipo de informação dentro do
sistema?
3. Ator precisa ser notificado de eventos do
sistema? O ator precisa notificar o sistema sobre
algum evento?
4. Trabalho diário do ator poderia ser simplifi-
cado ou tornado mais eficiente por meio de novas
funcionalidades do sistema?
5. Quais entradas e saídas o sistema precisa?
6. Quais os principais problemas com o atual
sistema?
Mesmo ainda nesta fase do processo de desen-
volvimento de software, através de uma especifi-
cação de requisitos bem elaborada e documenta-
da através dos casos de uso pode-se usar a mé-
trica Pontos por Caso de Uso - PCU - (Use Case
Points) para realizar estimativas de tamanho,
prazo e custo em projetos de software.
O processo de contagem da métrica PCU é cons-
tituído por seis passos descritos a seguir:
1. Contar os atores e atribuir o grau de com-
plexidade;
2. Contar os casos de uso e atribuir a com-
plexidade;
3. Somar o total dos atores com o total de
casos de uso para obter o PCU não ajustado;
4. Determinar a complexidade do fator técni-
co;
5. Determinar a complexidade do fator ambi-
ente;
6. Calcular o PCU ajustado;
A técnica de análise de Pontos por Casos de
Uso foi criada para permitir que seja possível
estimar o tamanho do sistema ainda na fase de
levantamento de Casos de Uso, utilizando-se dos
próprios documentos gerados nesta fase de aná-
lise como subsídio para efetuar estimativas de
tamanho, prazo e custo de software.
Naturalmente existe um grau de incerteza ineren-
te a fase inicial do processo e as definições de
requisitos da ordem de 45%.
Assim, a medida do tamanho, complexidade e
riscos de um projeto de software vai depender da
qualidade e coerência dos requisitos definidos. É
de vital importância que a tarefa de levantamento
de requisitos seja executada de forma criteriosa e
detalhada, pois uma falha nessa etapa do ciclo de
vida do software vai gerar um projeto malsucedi-
do e a insatisfação do cliente.
Técnicas no Processo de Validação
Consegue-se entender então que os processos
de Validação de Requisitos têm como "variáveis"
de entrada o esboço vindo do processo de Análi-
se e Negociação de Requisitos, as normas de
qualidade da organização/projeto em que se inse-
re e do conhecimento empírico obtido de outros
projetos. Este processo "retorna" uma lista de
problemas que devem ser resolvidos. Iterativa-
mente o processo vai finalizar com o "retorno" de
uma versão final do documento de requisitos.
Mas falta ainda saber quais as técnicas eficazes
utilizadas para realizar este processo.
Revisão dos Requisitos
A revisão de requisitos deverá ser feita numa
reunião formal onde deverá estar presentes um
utilizador final ou um representante deste, um
especialista do domínio, um representante do
cliente, os responsáveis pelo desenho do sistema
e os engenheiros de requisitos. É importante que
esta reunião seja conduzida por alguém que este-
ja dentro do projeto, mas não esteve envolvido na
realização do documento de requisito, de forma a
este conduzir a reunião de uma forma rigorosa e
"livre de vícios".
Antes da realização da reunião formal é necessá-
rio existir um planeamento cuidado da revisão a
ser efetuada na reunião. Neste planeamento de-
vem ser preparadas checklists de revisão genéri-
cas e não deverão incidir sobre requisitos indivi-
duais, mas sim nas relações dos requisitos, assim
como as propriedades de qualidade do documen-
to. Os seguintes atributos de qualidade deverão
ser tomados em conta na formulação da chec-
klists:
1. Compreensibilidade
2. Redundância
3. Completude
4. Consistência
5. Organização
6. Conformidade com as normas
7. Rastreabilidade
17
Na tabela em baixo poderá ser visto um modelo
de questões a seguir na formulação dos atributos
de qualidade das checklists:
Devem ser distribuídos os documentos necessá-
rios para a reunião a todos os futuros envolvidos
nesta assim como haver uma preparação prévia
de todos. Na reunião cada requisito deve ser
apresentado à vez para discussão pelo grupo,
sendo tomado nota de todos os problemas identi-
ficados. As soluções para os problemas identifi-
cados apenas serão discutidas no final de todos
os requisitos serem apresentados.
Prototipagem
No processo de análise e negociação de requisi-
tos desenvolveu-se um protótipo para facilitar na
recolha de requisitos pois é usualmente mais fácil
para os Stakeholders conseguirem identificarem
exactamente o que querem de uma forma visual e
aproximada do que poderá ser o produto final.
Logo também será mais fácil na fase de validação
de requisitos validar estes através do mesmo
processo.
Obviamente que através do protótipo visual é
mais fácil detectar inconsistências e problemas
nos requisitos. É também de referir a possibilida-
de de iniciar-se já nesta fase os manuais de utili-
zação (pois normalmente são implementadas as
interfaces). Deve-se notar duas pequenas des-
vantagens na utilização desta técnica.
A implementação de um protótipo poderá levar a
desilusões para os utilizadores finais, quando as
interfaces da versão final não correspondem
exactamente às do protótipo e poderá tentar os
programadores a utilizar o protótipo como uma
continuação do desenvolvimento do sistema.
Também se deverá ter em conta o tempo gasto
na implementação do protótipo e medir se este
tempo no final será compensado pelas vantagens
trazidas por este.
Validação de Modelos
Uma especificação de requisitos de um sistema
pode ser constituída por variadíssimos modelos,
que obviamente necessitam de ser validados.
Essa validação deverá avaliar individualmente a
consistência de cada modelo assim como a con-
sistência entre os vários modelos do sistema.
Deverá também verificar se estes modelos real-
mente representam os requisitos reais dos
stakeholders.
Testes de Requisitos
Para cada requisito funcional deve ser possível
definir um ou mais testes a serem realizados no
sistema final para ser possível verificar se o sis-
tema cumpre o requisito na integra. Se este teste
não for possível ser definido isso vai significar que
o requisito necessita de ser clarificado pois muito
provavelmente irá criar problemas no desenvol-
vimento do produto. Na definição de cada teste
deverá ser tomado em conta os seguintes pontos:
1. Identificador do requisito
2. Requisitos relacionados
3. Descrição do teste
4. Problemas na realização do teste
5. Comentário e recomendações
O que é Prototipação?
A prototipação é um processo que tem como ob-
jetivo facilitar o entendimento dos requisitos,
apresentar conceitos e funcionalidades do softwa-
re. Desta forma, podemos propor uma solução
adequada para o problema do cliente, aumentan-
do sua percepção de valor.
Os protótipos também são grandes aliados das
metodologias ágeis de desenvolvimento, uma vez
que garantem maior alinhamento entre a equipe e
o cliente. Eles podem ser desenvolvidos em dife-
rentes níveis de fidelidade: quanto maior ela for,
mais o protótipo se assemelhará ao resultado
entregue. No entanto, um protótipo de alta fideli-
dade leva mais tempo para ser criado ou modifi-
cado. A escolha do protótipo ideal varia de acordo
com o nível de entendimento do negócio, a com-
plexidade dos requisitos, prazo e orçamento para
elaboração.
Podemos dividir os protótipos em três categorias:
Wireframes & Rascunhos
São protótipos de baixa fidelidade, rápidos para
se desenvolver e modificar. Wireframes não vão
mostrar detalhes visuais ou interações de tela,
mas vão ajudar a validar requisitos e regras de
negócio de maneira eficiente. Wireframes são a
melhor escolha para representar cenários com-
plexos onde um fluxo ou processo precisa ser
compreendido.
Ferramentas bacanas:
18
 Papel & caneta (a melhor de todas)
 Balsamiq Mockups
 Pencil Sketch
Protótipos Visuais
Criados com programas de edição gráfica, estes
protótipos têm maior apelo visual, entretanto, não
possuem interações de tela e demandam mais
tempo para se fazer ajustes e melhorias. São
uma ótima opção para telas com maior ênfase em
estética e usabilidade, quando os requisitos já
foram entendidos.
Ferramentas bacanas:
 Adobe Photoshop
 GIMP
Protótipos Interativos
São protótipos completos e representativos. Além
da parte visual, englobam uma série de detalhes
de estética e efeitos de interação, proporcionando
uma experiência rica e realista. Também ajudam
a equipe a identificar novos requisitos, oportuni-
dades e futuros problemas.
As consequências disso para o software são lu-
cros maiores a longo prazo e riscos menores
durante o desenvolvimento. Em contrapartida,
protótipos interativos demandam uma equipe de
maior conhecimento técnico e demoram mais
tempo para serem criados.
Ferramentas bacanas:
 HTML, CSS, Javascript (é, amigo, é mão
na massa, não tem jeito)
 CSS Twitter Bootstrap (framework CSS que
pode acelerar bastante o processo de prototipa-
ção)
 Adobe Dreamweaver (permite fazer protóti-
pos interativos mais simplistas, sem exigir tanto
conhecimento técnico)
Prototipação é importante pois é um meio rápido
e bastante eficiente de se validar uma ideia, uma
nova abordagem ou um novo conceito. Porém, o
tipo de protótipo deve ser pensado com cautela
de acordo com cada necessidade para que se
possa explorar o que de melhor essa técnica po-
de oferecer. Durante a criação de um protótipo de
média/alta fidelidade, esteja sempre alinhado com
a equipe de desenvolvimento; um simples detalhe
prototipado pode gerar um trabalho complexo
que, no final das contas, talvez não vá agregar
tanto valor para assim o cliente.
ANOTAÇÕES
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
19