1. A engenharia de requisitos envolve a descoberta do que o sistema deve fazer e possíveis restrições através de técnicas como entrevistas, observação e prototipagem. 2. É importante documentar os requisitos levantados para que sirvam de base para o desenvolvimento de software. 3. As principais etapas da engenharia de requisitos são concepção, levantamento, elaboração, negociação, especificação, validação e gestão.

1. 1
ASPECTOS DA ENGENHARIA DE REQUISITOS
Jaffer dos Santos Veronezi – UAM-SP (jafferveronezi@gmail.com)
Carlos J. Locoselli (cjlocoselli@uol.com.br)
Resumo
A Engenharia de Requisitos estando bem estruturada pode nos garantir mais
qualidade, confiabilidade e integridade ao produto de software a ser desenvolvido. Ela
envolve a descoberta do que o sistema deverá fazer e possíveis restrições do mesmo.
Novos usuários podem aparecer durante o processo de elicitação, sendo que fatores
políticos e organizacionais também podem influenciar nos requisitos. O objetivo dessa
pesquisa é mostrar os aspectos mais relevantes da Engenharia de Requisitos bem como
sua importância no processo de desenvolvimento de software, procurando descrever o
que é um requisito, quais os conceitos chave que a Engenharia de Requisitos fornece
para entendermos o que o cliente deseja, buscando analisar as necessidades, avaliar a
viabilidade, negociar uma solução razoável, especificar a solução sem ambiguidades,
validar a especificação e gerenciar as necessidades a medida que são transformadas em
um sistema. Também iremos mostrar algumas técnicas que são utilizadas em cada fase
da Engenharia de Requisitos visando auxiliar os trabalhos da coleta e manutenção dos
requisitos.
Palavras-chave: Engenharia de Requisitos, Requisitos, Engenharia de Software.
Introdução
No processo de desenvolvimento de software, o levantamento de requisitos
compreensíveis por todas as partes envolvidas no desenvolvimento do sistema (clientes,
analistas, desenvolvedores, etc.) é um fator básico e extremamente importante, evitando
falhas no entendimento do problema a ser solucionado. A obtenção de requisitos dentro
do contexto da organização deve ser realizada de forma adequada, com métodos, técnicas
e ferramentas que deem suporte à etapa do processo de desenvolvimento. Para isso, dentro
do contexto de Engenharia de Requisitos, a representação dos requisitos tem papel
fundamental na condução das demais atividades desse processo. Ela está presente ao
longo do ciclo de vida do software, identificando as expectativas das partes interessadas
no sistema e definindo o que o sistema deve fazer para satisfazer essas expectativas. Para
Sommerville (2003), “a Engenharia de Requisitos é um processo que envolve todas as
atividades exigidas para criar e manter o documento de requisitos de sistema.”
Existem algumas etapas na engenharia de requisitos, são elas: concepção,
levantamento, elaboração, negociação, especificação, validação e gestão. A concepção é
a primeira etapa da engenharia de requisitos e nessa etapa procura-se definir o escopo e a
natureza do problema que estamos tentando resolver para o cliente; A segunda etapa é a
de levantamento em que se procura ajudar os interessados a definir o que é necessário; A
terceira etapa é a de elaboração em que os requisitos básicos são refinados e modificados;
A quarta etapa é a de negociação onde se definem quais são as prioridades, o que é
essencial e quando é necessário; Na quinta etapa especifica-se o problema e então, na

2. 2
sexta etapa de Validação é realizada uma revisão e validação para garantir que o
entendimento dos problemas coincidem com o que os interessados haviam explicado.
Essa parte é realizada com os interessados; Por fim, ainda temos uma sétima etapa que é
a Gestão dos requisitos em que se controlam os requisitos.
1 Requisito
De acordo com o Dicionário Moderno da Língua Portuguesa, requisito é uma
condição ou exigência imprescindível a que se deve satisfazer para alcançar determinado
fim.
Segundo Sommerville (2003), “o termo requisito não é utilizado pela indústria de
software de modo consistente. Em alguns casos, um requisito é visto como uma
declaração abstrata, de alto nível, de uma função que o sistema deve fornecer ou de uma
restrição do sistema. No outro extremo, ele é uma definição detalhada, matematicamente
formal, de uma função do sistema.”
Para ISO/IEC/IEEE (2010), o requisito pode ser definido como:
1. “Uma condição ou capacidade necessária por um usuário para resolver um
problema ou alcançar um objetivo.
2. Uma condição ou capacidade que deve ser atendida por uma solução para
satisfazer um contrato, especificação, padrão ou quaisquer outros
documentos formais impostos.
3. Documentação da representação das condições ou capacidades
apresentadas nos dois itens anteriores.”
“A definição de requisito é fundamental entender e aplicar a definição de
qualidade usada em tantos modelos de referência. Isso porque, considerando que
requisitos seja também resolver um problema ou atingir um objetivo, aderência aos
requisitos já engloba a adequação ao uso.” Vazquez (2016)
Um conceito chave que garante uma boa consistência no projeto de
desenvolvimento dos requisitos está na documentação clara e precisa dos processos, a fim
de compor um trabalho responsável e eficiente. Assim sendo, pode-se considerar que a
Engenharia de Requisitos é uma das fases mais importantes do processo de engenharia de
software a fim de melhorar a qualidade dos requisitos.
1.1 Requisitos funcionais
São requisitos diretamente ligados a funcionalidade do software, descrevem as
funções que o software deve executar. Segundo Sommerville (2003), “são declarações de
funções que o sistema deve fornecer, como o sistema deve reagir a entradas específicas e
como deve se comportar em determinadas situações. Em alguns casos, os requisitos
funcionais podem também explicitamente declarar o que os sistema não deve fazer.”
Para Vazquez (2016), “os requisitos funcionais descrevem o comportamento que
o software deve ter em termos das tarefas ou serviços do usuário.”.
Alguns exemplos são:

3. 3
• 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 compras através de cartão de crédito.
1.2 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. Segundo Sommerville
(2003), “são restrições sobre os serviços ou as funções oferecidas pelo sistema. Entre eles
destacam-se restrições sobre o processo de desenvolvimento, padrões, ente outros.”
Alguns exemplos sã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.
1.3 Requisitos de domínio
Segundo Sommerville (2003), “são requisitos que se originam do domínio de
aplicação dos sistema e que refletem caraterísticas desse domínio. Podem ser requisitos
funcionais ou não funcionais.”
São requisitos derivados do domínio da aplicação e descrevem características do
sistema e qualidades que refletem o domínio. Podem ser requisitos funcionais novos,
restrições sobre requisitos existentes ou computações específicas.
Exemplos de requisito de domínio são:
• O calculo da média final de cada aluno é dado pela fórmula: (Nota1 * 2 + Nota2
* 3)/5;
• Um aluno pode se matricular em uma disciplina desde que ele tenha sido aprovado
nas disciplinas consideradas pré-requisitos.
2 A Engenharia de Requisitos
“A Engenharia de Requisitos pode ser definida como disciplina da Engenharia de
Software que consiste no uso sistemático e repetitivo de técnicas para cobrir atividades
de obtenção, documentação e manutenção de um conjunto de requisitos para o software
que atendam aos objetivos de negócios e sejam de qualidade.” Vazquez (2016)
Para Pressman (2011), “a engenharia de requisitos constrói uma ponte para o
projeto e para a construção.”, busca fornecer um mecanismo apropriado para entender
aquilo que o cliente deseja.

4. 4
Com isso podemos evoluir a definição de engenharia de requisitos para: termo
usado para descrever as atividades relacionadas à produção (levantamento, registro,
validação e verificação) e gerência (controle de mudanças, gerência de configuração,
rastreabilidade, gerência de qualidade dos requisitos) de requisitos.
3 Produção de Requisitos
A cada fase do ciclo de vida do software produzimos 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 inclusão de mais e mais detalhes, até que, sua última
representação seja o código fonte na linguagem escolhida. Um dos artefatos produzidos
no início do processo de desenvolvimento de software é a sua especificaçã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 especificação, atividades relacionadas à garantia da qualidade.
Segundo Sommerville (2003), “para todos os sistemas novos, o processo de
engenharia de requisitos de sistema deve começar com um estudo de viabilidade. A
entrada para o estudo de viabilidade é uma descrição geral do sistema e de como ele será
utilizado dentro de uma organização. Os resultados do estudo de viabilidade devem ser
um relatório que recomenda se vale a pena ou não realizar o processo de engenharia de
requisitos e o processo de desenvolvimento de sistemas”. Essa etapa inicial envolve
avaliar e coletar informações e criar relatórios. Realizando esses passos podemos passar
para o próximo estágio do processo, o levantamento e análise de requisitos.
4 Levantamento e Análise de Requisitos
No levantamento e análise de requisitos “os membros da equipe técnica de
desenvolvimento de software trabalham com o cliente e os usuários finais do sistema para
descobrir mais informações sobre o domínio da aplicação, que serviços o sistema deve
fornecer, o desempenho exigido do sistema, as restrições de hardware e assim por diante”
Sommerville (2003). Esta atividade é relacionada a obtenção dos requisitos do software.
Para isto, analistas e engenheiros 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 apoiam as atividades de levantamento de requisitos,
para qualquer uma delas temos quatro atividades fundamentais: São elas, segundo
Vazquez (2016):
• Preparação (ou planejamento)
• Execução
• Documentação

5. 5
• Confirmação
Dentre essas técnicas podemos citar:
Entrevista: esta técnica resume-se em conversas realizadas com o usuário
‘entrevistado” para levantar os requisitos do sistema a ser desenvolvido. Para Vazquez
(2016), “é uma forma de diálogo, formal ou informal”, entre duas ou mais pessoas, onde
o entrevistador busca respostas para um conjunto de questões previamente planejadas e
os entrevistados se apresentam como fonte de informação”. Podemos separar esta técnica
em atividades, tais como: ler material de suporte, estabelecer os objetivos da entrevista,
definir quem será o entrevistado, preparar o entrevistado, definir os tipos de questões e
sua estrutura.
Etnografia (Observação): 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. Segundo Sommerville (2003), “a etnografia
é uma técnica de observação que pode ser utilizada para compreender os requisitos sociais
e organizacionais”. O principal objetivo da etnografia é que ela ajuda a descobrir
requisitos de sistema implícitos, que refletem os processos reais, em vez de os processos
formais, onde as pessoas estão envolvidas. Ela é então um meio de elicitar requisitos pela
condução de uma avaliação do ambiente de trabalho das partes interessadas apropriadas,
quando documentando detalhes sobre um processo existente ou quando se propõe
melhorar ou modificar um processo atual, segundo Vazquez (2016).
Prototipagem: o protótipo tem por objetivo explorar aspectos críticos dos
requisitos de um produto, implementando de forma rápida um pequeno subconjunto de
funcionalidades deste produto. O protótipo é indicado para estudar as alternativas de
interface do usuário; problemas de comunicação com outros produtos; e a viabilidade de
atendimento dos requisitos de desempenho. As técnicas utilizadas na elaboraçã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.
Questionário (pesquisa): “a pesquisa consiste na aplicação de um questionário às
partes interessadas e posterior análise das repostas. Difere da entrevista porque não há
interação com os respondentes durante a reposta.” Vazquez (2016). O uso de questionário
é indicado, por exemplo, quando há diversos grupos de usuários que podem 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 importante, 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 espaços em branco. O
questionário deve ser desenvolvido de forma a minimizar o tempo gasto em sua resposta.

6. 6
Requisitos identificados e negociados, eles devem ser documentados para que
possam servir de base para o restante do processo de desenvolvimento. Dentre os
problemas que enfrentamos na documentação de requisitos, administrar 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 entendê-lo. O registro dos requisitos num documento próprio facilita o controle
de alterações de todos os envolvidos na manutenção dos requisitos, bem como a geração
de versões do documento e a facilidade de acesso por todos os envolvidos.
5 Verificação dos Requisitos
A Verificação é a atividade que examina a especificação do software, de forma a
assegurar que todos os requisitos foram definidos sem ambiguidades, inconsistências ou
omissões, detectando e corrigindo possíveis problemas ainda durante a fase de definição
dos requisitos. Sabemos que o custo da correção de defeitos aumenta à medida que o
processo de desenvolvimento avança. Revisões de artefatos de software têm se mostrado
uma abordagem eficiente e de baixo custo para encontrar defeitos logo após terem sido
introduzidos, reduzindo o retrabalho e melhorando a qualidade dos produtos.
6 Validação dos Requisitos
Quanto a validação dos requisitos, ela “se ocupa de mostrar que os requisitos
realmente definem o sistema que o cliente deseja” Sommerville (2003). “Procura garantir
que todas as necessidades de negócio das partes interessadas no escopo do projeto serão
satisfeitas. A finalidade é garantir que a especificação defina o produto certo a ser
desenvolvido pelo projeto” Vazquez (2016). No cenário de engenharia de requisitos, esta
atividade significa aprovar junto ao cliente os requisitos que foram especificados. Embora
aparentemente simples, esta atividade pode ser bastante dificultada pelo cliente ou mesmo
por um processo de validação inadequado utilizado pela empresa.
7 Gerência de Requisitos
“Os requisitos para grandes sistemas de software estão sempre sendo modificados.
Uma das razões para isso é que esses sistemas são geralmente desenvolvidos para lidar
com problemas ‘intrincados’”, Sommerville (2003). Requisitos são por natureza voláteis.
Diversos fatores contribuem para sua instabilidade ao longo do tempo. Mudanças
externas no ambiente tais como: mudanças de legislação, mudanças no mercado,
mudança no posicionamento estratégico da empresa, 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. Chamamos a atividade de
administrar os requisitos ao longo do tempo de gerenciamento de requisitos, “que tem por

7. 7
objetivo gerenciar os requisitos dos produtos do projeto e dos seus componentes e garantir
o alinhamento entre os requisitos, os planos do projeto e os produtos de trabalho do
projeto ” Vazquez (2016).
Os benefícios desta atividade são percebidos no médio prazo, sendo que são
necessários investimentos no curto prazo. Com isso esta atividade é muitas vezes, tida
como um fardo desnecessário à condução do processo, porém sua não implementação faz
com que as economias de curto prazo sejam logo suplantadas pelas despesas no longo
prazo, verificadas com superação de custo e prazo nos projetos conduzidos.
Segundo Vazquez (2016), “para alcançar tais objetivos, são definidos práticas
específicas a serem cumpridas:
1. Entender os requisitos: faz com que os requisitos sejam entendidos,
avaliados e aceitos junto aos fornecedores de requisitos (partes
interessadas), utilizando critérios objetivos. Para buscar o consenso entre
as várias partes interessadas é comum precisar também solucionar
conflitos.
2. Obter comprometimento sobre os requisitos: busca garantir que a equipe
do projeto está comprometida em trabalhar na versão mais atual dos
requisitos aprovados.
3. Gerenciar mudanças: garante que um processo formal de gestão de
mudanças sobre os requisitos é aplicado.
4. Manter rastreabilidade bidirecional entre requisitos e seus produtos: a
rastreabilidade ajuda na gestão do escopo e na avaliação de impacto de
mudanças.
5. Garantir alinhamento entre trabalho do projeto e requisitos: revisões em
planos e produtos de trabalho do projeto são realizadas visando identificar
e corrigir inconsistências quanto aos requisitos”.
7.1 Controle de Mudanças
Os requisitos estão sempre sendo modificados, uma das maneiras utilizadas para
organizar estas mudanças a baseline de requisitos que nos permite diferenciar o que era
requisito original, o que foi adicionado 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. Temos três estágios principais em um processo de controle de
mudança, são eles segundo Sommerville (2003):
• Análise do problema e especificação da mudança: O processo começa com
a identificação de um problema com os requisitos ou, algumas vezes, com
uma proposta específica de mudança. Nesse estágio, é realizada a análise
do problema ou da proposta de mudança, a fim de verificar sua validade.
Uma proposta mais específica de mudanças nos requisitos pode então ser
efetuada.
• Análise e custo da mudança: O efeito da mudança proposta é avaliado,
utilizando-se informações sobre a facilidade de rastreamento e o
conhecimento geral dos requisitos do sistema. O custo da mudança
´estimado em termos das modificações no documento de requisitos e, se

8. 8
apropriado, no projeto de sistemas e na implementação. Uma vez
concluída essa análise, é tomada uma decisão sobre prosseguir com a
alteração de requisitos ou não.
• Implementação de mudanças: O documento de requisitos e, quando for
necessário, o projeto de sistema e a implementação são modificados. O
documento de requisitos deve ser organizado de maneira que as mudanças
possam ser acomodadas sem muito esforço. Assim como ocorre com os
programas, a facilidade de modificações em documentos é alcançada ao se
minimizar referências externas e ao tornar as seções do documento tão
modulares quanto possível”.
7.2 Gerência de Configuração
Durante o ciclo de vida do desenvolvimento, o software passa várias
modificações, desde a especificação dos requisitos até a implantação do sistema. A
gerência de configuração de software existe no intuito de definir critérios que permitam
realizar tais modificações mantendo-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 modificações. O plano de gerência de
configuração estabelece normas, ferramentas e templates que permitam gerenciar de
maneira satisfatória os itens de configuração de um sistema. Em cada fase do processo de
desenvolvimento, um conjunto bem definido de itens de configuração deve ser
estabelecido. A este conjunto é dado 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 configuração estão sob total controle de seus
desenvolvedores.
7.3 Rastreabilidade
Segundo Vazquez (2016), “a rastreabilidade dos requisitos é o processo de
identificar e documentar os elos (ou vínculos) que envolvem um determinado requisito,
para que seja possível rastrear sua origem, os artefatos derivados e os demais requisitos
relacionados” .
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. Para implementar a rastreabilidade, usualmente
é confeccionado em conjunto com a especificação de requisitos um artefato chamado
matriz de rastreabilidade, que tem como objetivo mapear os rastros dos requisitos
descritos na especificação. Há dois tipos de rastreabilidade:
• Rastreabilidade horizontal e vertical
• Pré e pós-rastreabilidade

9. 9
A rastreabilidade horizontal estabelece vínculos entre as versões de requisitos em uma
determinada fase do ciclo de vida do projeto, já a rastreabilidade vertical relaciona os
requisitos ou artefatos produzidos nas distintas fases ao longo do ciclo de vida do projeto.
A pré-rastreabilidade permite identificar a origem de cada requisito e também quais se
originam de uma determinada fonte, enquanto que a pós-rastreabilidade permite
identificar quais componentes do software implementam um determinado requisito.
8 Considerações finais
Este estudo procurou mostrar os principais aspectos da Engenharia de Software,
buscam evidenciar que a Engenharia de Requisitos como primeiro passo no
desenvolvimento do sistema tem um impacto significativo sobre o sucesso do projeto. Ela
delimita o escopo do projeto e estabelece a base comum para a comunicação para todas
as disciplinas envolvidas no projeto. Quanto melhor a engenharia de requisitos e o
gerenciamento de requisitos são realizados dentro do projeto, erros menos custosos
ocorreram durante o desenvolvimento, diminuindo o custo total de erros nos projetos.
Entendo que a Engenharia de Requisitos define, sem dúvida, um dos mais
importantes conjuntos de atividades a serem realizadas em projetos de desenvolvimento
de software. Embora não garanta a qualidade dos produtos gerados, é um pré-requisitos
básico para que obtenhamos sucesso no desenvolvimento do projeto.
9 Referências
SOMMERVILLE, Ian. Engenharia de Software. 6º ed. São Paulo: Addison Wesley,
2003.
PRESSMAN, Roger S. Engenharia de Software: uma abordagem profissional. 7º ed.
Porto Alegre: AMGH, 2011.
VAZQUEZ, Carlos E. e SIMÕES, Guilherme S. Engenharia de requisitos: software
orientado ao negócio. Rio de Janeiro: Brasport, 2016.
UOL. MICHAELIS. São Paulo, 2017. Disponível em: <http://michaelis.uol.com.br>.
Acesso em: 16 jul. 2017.
QUITERIO, Ana Paula. Análise de Requisitos. São Paulo, 2017. Disponível em:
<http://www.infoescola.com/engenharia-de-software/analise-de-requisitos/>. Acesso
em: 6 jul. 2017.
ÁVILA, Ana Luiza. Artigo Engenharia de Software – Introdução à Engenharia de
Requisitos. São Paulo, 2017. Disponível em: <http://www.devmedia.com.br/artigo-
engenharia-de-software-introducao-a-engenharia-de-requisitos/8034>. Acesso em: 6 jul.
2017.
BEDANI, Janaína. Engenharia de Software 2 – Técnicas para Levantamento de
Requisitos. São Paulo, 2017. Disponível em:<http://www.devmedia.com.br/engenharia-
de-software-2-tecnicas-para-levantamento-de-requisitos/9151>. Acesso em: 7 jul. 2017.