Engenharia de Software I - 3 - Processos de Engenharia de Requisitos

Prévia do material em texto

. 
 
 
Engenharia de Software I 
 
PROCESSOS DE 
ENGENHARIA DE REQUISITOS 
 
 Engenharia de Software 1 
 Prof. Me. Marcelo dos Santos Moreira 
1. INTRODUÇÃO 
O objetivo do processo de engenharia de requisitos é criar e manter um 
documento de requisitos de sistema. O processo geral inclui quatro subprocessos de alto nível 
de engenharia de requisitos. Eles estão relacionados à: 
 estudo de viabilidade: avaliação se o sistema é útil para a empresa 
 elicitação e análise: obtenção de requisitos 
 especificação: conversão desses requisitos em alguma forma padrão 
 validação: verificação se os requisitos realmente definem o sistema 
que o cliente deseja 
A Figura 1.1 ilustra o relacionamento entre essas atividades. Ela mostra 
também os documentos produzidos em cada estágio do processo de engenharia de requisitos. 
A especificação e a documentação foram abordadas na apostila 2 – Requisitos de Software e 
esta apostila se concentra nas outras atividades da engenharia de requisitos. 
As atividades mostradas na Figura 1.1 estão relacionadas à obtenção, 
documentação e verificação de requisitos. Na prática, no entanto, todos os requisitos de 
sistema mudam. As pessoas envolvidas desenvolvem uma compreensão maior do que 
desejam que o software faça, a organização que está comprando o sistema muda, são feitas 
modificações no hardware, no software e no ambiente organizacional do sistema. O processo 
de gerenciamento dessas mudanças de requisitos é denominado gerenciamento de requisitos 
e é abordado na seção final desta apostila. 
 
Figura 1.1 – Processo de engenharia de requisitos 
Estudo de 
viabilidade 
Elicitação e 
análise de 
requisitos 
Especificação 
de requisitos 
Validação de 
requisitos 
Documento 
de requisitos 
Requisitos de 
usuário e de 
sistema 
Modelos de 
sistemas 
Relatório de 
viabilidade 
 
PROCESSOS DE 
ENGENHARIA DE REQUISITOS 
 
 Engenharia de Software 2 
 Prof. Me. Marcelo dos Santos Moreira 
A figura 1.2 apresenta uma perspectiva alternativa do processo de engenharia 
de requisitos – modelo espiral. Ela mostra o processo como uma atividade de três estágios, 
no qual as atividades estão organizadas como um processo iterativo em espiral. A quantidade 
de tempo e esforço dispensado para cada atividade na iteração depende do estágio do 
processo geral e do tipo de sistema que está sendo desenvolvido. No início do processo, a 
maior parte do esforço será empregada na compreensão dos requisitos de alto nível de 
negócios, requisitos não funcionais e requisitos de usuário. Próximo ao fim do processo, nas 
partes mais externas da espiral, um esforço maior será dedicado à engenharia de requisitos e à 
modelagem de sistema. 
O modelo em espiral acomoda abordagens de desenvolvimento em que os 
requisitos são desenvolvidos para diferentes níveis de detalhes. O número de iterações na 
espiral pode variar, de modo que se pode sair da espiral depois que alguns ou todos os 
requisitos de usuário tiverem sido elicitados. Se a atividade de prototipação apresentada sob a 
validação de requisitos for ampliada para incluir o desenvolvimento iterativo, este modelo 
permitirá que os requisitos e a implementação de sistema sejam desenvolvidos em conjunto. 
 
Algumas pessoas consideram a engenharia de requisitos como se fosse o 
processo de aplicação de um método estruturado de análise como, por exemplo, a análise 
orientada a objetos. Isso consiste na análise do sistema e no desenvolvimento de um conjunto 
de modelos gráficos de sistemas, como modelos de casos de uso, que servem como uma 
especificação de sistema. O conjunto de modelos descreve o comportamento do sistema e 
Figura 1.2 – Modelo em espiral dos processos de engenharia de requisitos 
Elicitação de 
requisitos 
Validação de 
requisitos 
Especificação 
de requisitos 
Especificação de 
requisitos de sistema 
e modelagem 
Especificação de 
requisitos de usuário 
Especificação de 
requisitos de negócios 
Estudo de 
viabilidade 
Prototipação 
Revisões 
Elicitação de 
requisitos 
de usuário 
Elicitação de 
requisitos 
de sistema 
Documento de requisitos 
de sistema 
 
PROCESSOS DE 
ENGENHARIA DE REQUISITOS 
 
 Engenharia de Software 3 
 Prof. Me. Marcelo dos Santos Moreira 
inclui anotações com descrições adicionais de informações como, por exemplo, o desempenho 
ou a confiabilidade necessária. 
Embora os métodos estruturados possuam um papel a desempenhar no 
processo de engenharia de requisitos, existe muito mais sobre engenharia de requisitos do que 
é abordado nesses métodos. A elicitação de requisitos, em particular, é uma atividade centrada 
em pessoas, e as pessoas não gostam das restrições impostas pelos modelos rígidos de 
sistema. 
2. ESTUDO DE VIABILIDADE 
Em todos os sistemas novos, o processo de engenharia de requisitos deve 
começar com um estudo de viabilidade. A entrada para o estudo de viabilidade consiste de um 
conjunto preliminar de requisitos de negócios, um esboço da descrição do sistema e como o 
sistema pretende apoiar os processos de negócios. Os resultados do estudo de viabilidade 
devem estar em um relatório que recomenda se vale a pena ou não prosseguir com os 
processos de engenharia de requisitos e de desenvolvimento do sistema. 
Um estudo de viabilidade é um estudo breve e focalizado que procura 
responder a uma série de questões: 
1. O sistema contribui para os objetivos gerais da organização? 
2. O sistema pode ser implementado com tecnologia atual e dentro das 
restrições definidas de custo e prazo? 
3. O sistema pode ser integrado a outros sistemas já implantados? 
A questão de se o sistema contribui ou não para os objetivos da empresa é 
crítica. Se um sistema não apoia esses objetivos, ele não tem valor real para a empresa. 
Apesar de esse fato parecer óbvio, muitas organizações desenvolvem sistemas que não 
contribuem para seus objetivos, porque elas não têm um perfil claro desses objetivos, pois 
falham em definir os requisitos de negócios para o sistema, ou porque outros fatores políticos 
ou organizacionais influenciam na aquisição do sistema. 
A realização de um estudo de viabilidade envolve a avaliação de informações, 
sua coleta e a elaboração de um relatório. 
A avaliação de informações identifica as informações necessárias para 
responder às três questões apresentadas anteriormente. Após a identificação das informações, 
é necessário falar com as fontes de informações para descobrir as respostas a essas 
perguntas. Alguns exemplos de possíveis questões que podem ser levantadas são: 
 
PROCESSOS DE 
ENGENHARIA DE REQUISITOS 
 
 Engenharia de Software 4 
 Prof. Me. Marcelo dos Santos Moreira 
1. Como a organização se comportaria se esse sistema não fosse 
implementado? 
2. Quais são os problemas com os processos atuais e como o novo 
sistema ajudaria a reduzir esses problemas? 
3. Qual será a contribuição direta do sistema para os objetivos e requisitos 
da empresa? 
4. As informações podem ser transferidas e recebidas de outros sistemas 
da organização? 
5. O sistema requer tecnologia que ainda não foi usada na organização? 
6. O que deve ser apoiado pelo sistema e o que não precisa ser apoiado? 
Em um estudo de viabilidade, pode-se consultar fontes de informações como 
os gerentes de departamentos em que o sistema será usado, engenheiros de software 
familiarizados com o tipo de sistema proposto, especialistas em tecnologia e usuários finais do 
sistema. Normalmente, deve-se tentar concluir um estudo de viabilidade em duas ou três 
semanas. Após obter as informações, é elaborado o relatório de estudo de viabilidade. Deve-se 
fazer uma recomendaçãode se o desenvolvimento do sistema deve ou não prosseguir. No 
relatório podem ser propostas mudanças de escopo, orçamento e prazo e sugerir requisitos de 
alto nível adicionais para o sistema. 
3. ELICITAÇÃO E ANÁLISE DE REQUISITOS 
O próximo estágio do processo de engenharia de requisitos é a elicitação e 
análise de requisitos. Nessa atividade, os engenheiros de software trabalham com os clientes e 
os usuários finais do sistema para aprender sobre o domínio da aplicação, quais serviços o 
sistema deve fornecer, o desempenho esperado do sistema, restrições de hardware etc. 
A elicitação e a análise de requisitos podem envolver várias pessoas de uma 
organização. O termo stakeholder é usado para se referir a qualquer pessoa ou grupo afetado 
pelo sistema, direta ou indiretamente. Os stakeholders incluem os usuários finais que 
interagem com o sistema e todo pessoal na organização que possa ser afetado por sua 
instalação. Outros stakeholders no sistema podem ser os engenheiros que estão 
desenvolvendo ou mantendo sistemas relacionados, gerentes de negócios, especialistas do 
domínio e representantes do sindicato. 
A elicitação e a compreensão dos requisitos dos stakeholders são difíceis 
devido a várias razões: 
 
PROCESSOS DE 
ENGENHARIA DE REQUISITOS 
 
 Engenharia de Software 5 
 Prof. Me. Marcelo dos Santos Moreira 
1. Os stakeholders, frequentemente, não sabem o que querem do sistema 
de computador a não ser em termos gerais. Eles podem achar difícil 
articular o que desejam que o sistema faça ou fazem pedidos não 
realistas, pois ignoram o custo de seus requisitos. 
2. Os stakeholders expressam os requisitos naturalmente em seus 
próprios termos e com o conhecimento implícito de se trabalho. Os 
engenheiros de requisitos, sem experiência no domínio do cliente, 
devem entender esses requisitos. 
3. Diferentes stakeholders possuem diferentes requisitos, expressos de 
diferentes formas. Os engenheiros de requisitos precisam considerar 
todas as fontes potenciais de requisitos e descobrir pontos em comum 
e conflitos. 
4. Fatores políticos podem influenciar os requisitos do sistema. Por 
exemplo, os gerentes podem solicitar requisitos específicos do sistema 
que aumentarão a sua influência na organização. 
5. O ambiente econômico e de negócios sobre o qual a análise é 
realizada é dinâmico. Ele muda inevitavelmente durante o processo de 
análise. Portanto, a importância de determinado requisito pode mudar. 
Novos requisitos podem surgir de novos stakeholders que não haviam 
sido consultados anteriormente. 
Um modelo de processo bastante genérico de elicitação e análise de requisitos 
é apresentado na figura 3.1. Cada organização terá a sua própria versão ou modelo desse 
modelo geral, dependendo de fatores locais, como o nível de conhecimento da equipe, o tipo 
do sistema que está sendo desenvolvido e os padrões usados. Novamente, pode-se pensar 
nessas atividades como uma espiral, de modo que as atividades se intercalem à medida que o 
processo progrida da parte interna da espiral para a externa. 
As atividades de processo são: 
1. Obtenção de requisitos: é o processo de interação com os 
stakeholders no sistema para coletar os seus requisitos. Os requisitos 
de domínio são também descobertos durante essa atividade, 
provenientes dos stakeholders e da documentação. 
2. Classificação e organização de requisitos: esta atividade envolve a 
coleção de requisitos não estruturados, agrupa os requisitos 
relacionados e os organiza em conjuntos coerentes. 
 
PROCESSOS DE 
ENGENHARIA DE REQUISITOS 
 
 Engenharia de Software 6 
 Prof. Me. Marcelo dos Santos Moreira 
 
3. Priorização e negociação de requisitos: inevitavelmente, quando 
vários stakeholders participam do processo, os requisitos serão 
conflitantes. Esta atividade está relacionada à priorização de requisitos, 
à procura e à resolução de conflitos de requisitos por meio da 
negociação. 
4. Documentação de requisitos: os requisitos são documentados e 
colocados na próxima volta da espiral. Podem ser produzidos 
documentos de requisitos formais ou informais. 
A figura 3.1 mostra que a elicitação e a análise de requisitos é um processo 
iterativo com realimentação contínua de cada atividade para outras atividades. O ciclo do 
processo começa com a obtenção de requisitos e termina com a documentação de requisitos. 
O entendimento dos requisitos pelo analista aumenta a cada volta do ciclo. 
Aqui é enfocado principalmente a descoberta de requisitos e as diversas 
técnicas desenvolvidas para dar apoio a essas atividades. A classificação e a organização de 
requisitos estão relacionadas principalmente com a identificação da sobreposição de requisitos 
dos diferentes stakeholders e o agrupamento de requisitos relacionados. O modo mais comum 
de agrupamento de requisitos é usar um modelo de arquitetura de sistema para identificar os 
subsistemas e associar os requisitos a cada subsistema. Isso enfatiza que a engenharia de 
requisitos e o projeto de arquitetura nem sempre podem estar separados. 
Inevitavelmente, os stakeholders possuem visões diferentes sobre a 
importância e a prioridade dos requisitos e, algumas vezes, essas visões entram em conflito. 
Durante o processo, deve-se organizar negociações frequentes com os stakeholders, de modo 
que os compromissos possam ser atingidos. É impossível satisfazer completamente a todos os 
stakeholders, mas, se alguns deles perceberem que suas visões não foram consideradas de 
maneira apropriada, eles podem tentar boicotar intencionalmente o processo de engenharia de 
requisitos. 
No estágio de documentação, os requisitos elicitados são documentados de 
modo que possam ser usados para auxiliar as próximas obtenções de requisitos. Nesse 
estágio, uma versão inicial dos requisitos do sistema pode ser produzida, mas terá seções 
faltantes e requisitos incompletos. Como alternativa, os requisitos podem ser documentados 
como tabelas em um documento ou em cartões. Escrever os requisitos em cartões (abordagem 
usada na extreme programming) pode ser muito eficiente, pois os stakeholders podem 
manusear, alterar e organizar os cartões com facilidade. 
 
PROCESSOS DE 
ENGENHARIA DE REQUISITOS 
 
 Engenharia de Software 7 
 Prof. Me. Marcelo dos Santos Moreira 
 
3.1. Obtenção de requisitos 
A obtenção de requisitos é o processo que reúne informações sobre o sistema 
proposto e os existentes para obter os requisitos de usuário e de sistema com base nessas 
informações. As fontes de informações, durante a fase de obtenção de requisitos, incluem 
documentação, stakeholders de sistema e especificações de sistemas similares. A interação 
com os stakeholders ocorre por meio de entrevistas e observações, podendo ser usados 
cenários e protótipos para auxiliar na obtenção dos requisitos. Aqui é apresentada uma 
abordagem que ajuda a assegurar uma cobertura ampla de stakeholders durante a obtenção 
de requisitos e descritas técnicas que incluem entrevistas, cenários e etnografia. Outras 
técnicas de obtenção de requisitos que podem ser usadas incluem métodos estruturados de 
análise e prototipação de sistema. 
Os stakeholders variam de usuários finais do sistema a gerentes e envolvidos 
externos, como regulamentadores que certificam a aceitação do sistema. Por exemplo, os 
stakeholders em um sistema de caixa eletrônico bancário incluem: 
1. Clientes atuais do banco que recebem serviços do sistema. 
2. Representantes de outros bancos que têm acordos recíprocos que 
permitem usar os caixas eletrônicos uns dos outros. 
Figura 3.1 – Processo de elicitação e análise de requisitos 
Classificação e 
organização de 
requisitos 
Priorização e 
negociação derequisitos 
Documentação 
de requisitos 
Obtenção de 
requisitos 
 
PROCESSOS DE 
ENGENHARIA DE REQUISITOS 
 
 Engenharia de Software 8 
 Prof. Me. Marcelo dos Santos Moreira 
3. Gerentes de agências bancárias que obtêm informações de 
gerenciamento do sistema. 
4. Pessoal de atendimento nas agências bancárias envolvidos na 
operação diária do sistema. 
5. Administradores de banco de dados responsáveis pela integração do 
sistema com o banco de dados dos clientes do banco. 
6. Gerentes de proteção bancária que devem assegurar que o sistema 
não seja exposto a riscos de proteção. 
7. Departamento de marketing do banco provavelmente interessado em 
usar o sistema como meio de marketing do banco. 
8. Engenheiros de manutenção de hardware e software que são 
responsáveis pela manutenção e atualização de hardware e software. 
9. Reguladores nacionais de bancos responsáveis por assegurar que o 
sistema esteja em conformidade com os regulamentos bancários. 
 Além dos stakeholders no sistema, vimos anteriormente que os requisitos 
podem ser provenientes do domínio de aplicação e de outros sistemas que interagem com o 
sistema que está sendo especificado. Tudo isso deve ser considerado durante o processo de 
elicitação de requisitos. 
Essas fontes de requisitos (stakeholders, domínio, sistemas) podem ser 
representadas como pontos de vista do sistema, em que cada ponto de vista apresenta um 
subconjunto de requisitos do sistema. Cada ponto de vista fornece uma perspectiva nova do 
sistema, mas essas perspectivas não são completamente independentes – elas geralmente se 
sobrepõem de modo que haja requisitos comuns. 
Pontos de vista 
As abordagens orientadas a pontos de vista para engenharia de requisitos 
organizam o processo de elicitação e os próprios requisitos usando pontos de vista. Um ponto 
forte da análise orientada a pontos de vista é que ela reconhece várias perspectivas e fornece 
um framework para descobrir conflitos nos requisitos propostos por diferentes stakeholders. 
Os pontos de vista podem ser usados como um meio de classificação de 
stakeholders e de outras fontes de requisitos. Existem três tipos genéricos de pontos de vista: 
 
PROCESSOS DE 
ENGENHARIA DE REQUISITOS 
 
 Engenharia de Software 9 
 Prof. Me. Marcelo dos Santos Moreira 
1. Pontos de vista de interação: representam pessoas ou outros 
sistemas que interagem diretamente com o sistema. No sistema de 
caixa eletrônico bancário, exemplos de pontos de vista de interação 
são os clientes do banco e o banco de dados de contas bancárias. 
2. Pontos de vista indiretos: representam os stakeholders que não 
usam o sistema diretamente, mas que influenciam requisitos de alguma 
forma. No sistema de caixa eletrônico bancário, exemplos de pontos de 
vista indiretos são a gerência do banco e o pessoal de proteção do 
banco. 
3. Pontos de vista de domínio: representam características e restrições 
de domínio que influenciam os requisitos de sistema. No sistema de 
caixa eletrônico bancário, um exemplo de um ponto de vista de domínio 
são os padrões desenvolvidos para comunicações entre os bancos. 
Tipicamente, esses pontos de vista fornecem diferentes tipos de requisitos: 
 os pontos de vista de interação fornecem requisitos de sistema 
detalhados que abrangem as características e as interfaces do sistema. 
 os pontos de vista indiretos são os que mais provavelmente 
fornecem requisitos e restrições organizacionais de alto nível. 
 os pontos de vista de domínio fornecem normalmente as restrições 
de domínio que se aplicam ao sistema. 
A identificação inicial dos pontos de vista relevantes ao sistema pode ser difícil 
algumas vezes. Para ajudar nesse processo, deve-se tentar identificar tipos mais específicos 
de pontos de vista: 
1. Fornecedores e receptores de serviços do sistema. 
2. Sistemas que devem interfacear diretamente com o sistema que está 
sendo especificado. 
3. Regulamentos e padrões que se aplicam ao sistema. 
4. Fontes de requisitos de negócios e não funcionais do sistema. 
5. Pontos de vista de engenharia que refletem os requisitos de pessoas 
que devem desenvolver, gerenciar e manter o sistema. 
 
PROCESSOS DE 
ENGENHARIA DE REQUISITOS 
 
 Engenharia de Software 10 
 Prof. Me. Marcelo dos Santos Moreira 
6. Pontos de vista de marketing e outros pontos de vista que geram 
requisitos de características do produto esperadas pelos clientes e 
como o sistema deve refletir a imagem externa da organização. 
Quase todos os sistemas organizacionais devem interoperar com outros 
sistemas na organização. Quando um novo sistema é planejado, as interações com outros 
sistemas devem ser planejadas. As interfaces oferecidas por esses outros sistemas já foram 
projetadas. Elas podem incluir requisitos e restrições sobre o novo sistema. Além disso, novos 
sistemas podem precisar estar em conformidade com regulamentos e padrões preexistentes 
que restringem os requisitos do sistema. 
Conforme explicado anteriormente, deve-se identificar os requisitos de negócio 
e não funcionais de alto nível no início do processo de engenharia de requisitos. As fontes 
desses requisitos podem ser pontos de vista úteis em um processo mais detalhado. Elas 
devem ser capazes de expandir e desenvolver os requisitos de alto nível gerando requisitos de 
sistema mais específicos. 
Os pontos de vista de engenharia podem ser importantes por duas razões. 
Primeiro, os engenheiros que desenvolvem o sistema podem ter experiência com sistemas 
similares e ser capazes de sugerir requisitos levando em conta essa experiência. Segundo, o 
pessoal técnico que deve gerenciar e manter o sistema pode ter requisitos que irão ajudar a 
simplificar o apoio ao sistema. Os requisitos de gerenciamento de sistema são cada vez mais 
importantes, pois os custos de gerenciamento constituem uma porção cada vez maior dos 
custos totais no tempo de vida do sistema. 
Finalmente, os pontos de vista que fornecem requisitos podem ser 
provenientes dos departamentos de marketing ou de negócios externos em uma organização. 
Isso é especialmente verdadeiro em sistemas baseados na Web, mais especificamente 
sistemas de e-commerce e softwares comerciais. Os sistemas baseados na Web devem 
apresentar uma imagem favorável da organização, assim como oferecer funcionalidade ao 
usuário. No tocante a produtos de software, o departamento de marketing deve conhecer quais 
características tornarão o sistema mais atraente aos potenciais compradores. 
Para qualquer sistema não trivial, existe um grande número de possíveis 
pontos de vista, e é praticamente impossível elicitar os requisitos baseado em todos eles. 
Portanto, é importante que se organize e se estruture os pontos de vista em uma hierarquia. Os 
pontos de vista do mesmo ramo provavelmente compartilharão requisitos comuns. 
Como ilustração, considere a hierarquia de pontos de vista apresentada na 
Figura 3.2. É um diagrama relativamente simples de pontos de vista que podem ser 
consultados para derivar requisitos para o sistema LIBSYS. Pode-se observar que a 
 
PROCESSOS DE 
ENGENHARIA DE REQUISITOS 
 
 Engenharia de Software 11 
 Prof. Me. Marcelo dos Santos Moreira 
classificação dos pontos de vista de interação, indiretos e de domínio ajuda a identificar fontes 
de requisitos independente dos usuários imediatos do sistema. 
Depois que os pontos de vista forem identificados e estruturados, pode-se 
tentar identificar os pontos de vista mais importantes e iniciar com eles a obtenção de 
requisitos do sistema. 
 
Entrevistas 
Entrevistas formais ou informais com os stakeholders no sistema fazem parte 
da maioria dos processos de engenharia de requisitos.Nessas entrevistas, a equipe de 
engenharia de requisitos formula questões para os stakeholders sobre o sistema que eles 
usam e o sistema a ser desenvolvido. Os requisitos são derivados das respostas a essas 
questões. As entrevistas podem ser de dois tipos: 
1. Entrevistas fechadas: nas quais o stakeholder responde a um 
conjunto de perguntas predefinidas. 
2. Entrevistas abertas: nas quais não existe um roteiro predefinido. A 
equipe de engenharia de requisitos explora vários assuntos com os 
stakeholders do sistema e, assim, desenvolve uma compreensão maior 
de suas necessidades. 
Figura 3.2 – Pontos de vista no LIBSYS 
Todos os pontos de vista 
Indiretos 
Gerente da 
biblioteca 
 
Finanças 
Fornecedores 
de artigos 
Interação 
 
Usuários 
Pessoal da 
biblioteca 
Domínio 
Padrões 
de IU 
Sistema de 
classificação 
 
Estudantes 
 
Externos 
 
Pessoal Gerente do sistema 
Responsável 
pela catalogação 
 
PROCESSOS DE 
ENGENHARIA DE REQUISITOS 
 
 Engenharia de Software 12 
 Prof. Me. Marcelo dos Santos Moreira 
Na prática, as entrevistas com os stakeholders são, geralmente, uma 
combinação desses tipos. As respostas a algumas perguntas podem levar a outros assuntos 
discutidos de maneira menos estruturada. As discussões completamente abertas raramente 
funcionam bem; a maioria das entrevistas requer algumas perguntas como ponto de partida e 
para manter o foco no sistema a ser desenvolvido. 
As entrevistas são úteis para obter um entendimento geral sobre o que os 
stakeholders fazem, como eles podem interagir com o sistema e as dificuldades que enfrentam 
com os sistemas atuais. As pessoas gostam de falar sobre o seu trabalho e, normalmente, 
ficam felizes em participar de entrevistas. No entanto, as entrevistas não são tão úteis para 
compreender os requisitos do domínio da aplicação. 
É difícil elicitar o conhecimento de domínio durante as entrevistas por dois 
motivos: 
1. Todos os especialistas de domínio usam terminologia e jargões 
específicos. É impossível para eles explicar os requisitos de domínio 
sem usar essa terminologia. Eles em geral usam a terminologia de 
maneira precisa e específica, o que facilmente provoca mal-entendidos 
por parte dos engenheiros de requisitos. 
2. Alguns conhecimentos de domínio são tão familiares aos stakeholders 
que são considerados difíceis de explicar ou considerados tão 
fundamentais que não vale a pena mencioná-los. Por exemplo, para 
uma bibliotecária, não há necessidade de dizer que todas as 
aquisições são catalogadas antes de serem colocadas na biblioteca. 
Contudo, isso pode não ser óbvio para o entrevistador e, portanto, não 
é levado em consideração nos requisitos. 
A entrevista não é uma técnica eficiente para elicitação de conhecimentos 
sobre os requisitos e as restrições organizacionais, pois existem relacionamentos sutis de 
poder e influência entre os stakeholders na organização. As estruturas organizacionais públicas 
raramente coincidem com a realidade da tomada de decisões na organização, mas os 
entrevistados podem não querer revelar a estrutura real, em lugar da teórica, a um estranho. 
Em geral, a maioria das pessoas é relutante em discutir questões políticas e organizacionais 
que podem afetar os requisitos. 
Os entrevistadores eficientes possuem duas características: 
1. Possuem mente aberta, evitam ideias preconcebidas sobre os 
requisitos e querem ouvir os stakeholders. Se o stakeholder propuser 
 
PROCESSOS DE 
ENGENHARIA DE REQUISITOS 
 
 Engenharia de Software 13 
 Prof. Me. Marcelo dos Santos Moreira 
requisitos surpreendentes, os entrevistadores estão dispostos a mudar 
de ideia sobre o sistema. 
2. Induzem os entrevistados a iniciar as discussões com uma questão, 
uma proposta de requisitos ou sugerindo um trabalho conjunto em um 
protótipo do sistema. Dizer para as pessoas 'conte-me o que você 
necessita/deseja' provavelmente trará informações úteis como 
resultado. A maioria das pessoas considera mais fácil falar em um 
contexto definido do que em termos gerais. 
As informações obtidas das entrevistas complementam outras informações 
sobre o sistema obtidas de documentos, observações de usuários etc. Às vezes, 
independentemente das informações de documentos, as entrevistas podem ser as únicas 
fontes de informações sobre os requisitos do sistema. No entanto, apenas com as entrevistas 
pode haver a perda de informações essenciais; assim, essa técnica deve ser usada junto com 
outras para a elicitação de requisitos. 
Cenários 
As pessoas geralmente consideram mais fácil relatar exemplos da vida real do 
que abstrair descrições. Elas podem compreender e criticar um cenário de como interagiriam 
com um sistema de software. Os engenheiros de requisitos podem usar as informações obtidas 
nessa discussão para elaborar os requisitos reais do sistema. 
Os cenários podem ser particularmente úteis para adicionar detalhes a um 
esboço da descrição de requisitos. Eles são descrições de exemplos das sessões de interação. 
Cada cenário abrange uma ou mais interações possíveis. Diversos tipos de cenários foram 
desenvolvidos, cada um dos quais fornecendo diferentes tipos de informações sobre o sistema 
em diferentes níveis de detalhamento. O uso de cenários para descrever requisitos é parte 
integrante dos métodos ágeis, como a extreme programming. 
O cenário começa com um esboço da interação e, durante a elicitação, os 
detalhes são adicionados para criar uma descrição completa dessa interação. De maneira geral, 
um cenário deve incluir: 
1. Uma descrição do que os usuários esperam do sistema no início do 
cenário 
2. Uma descrição do fluxo normal de eventos no cenário 
3. Uma descrição do que pode dar errado e como isso é tratado 
4. Informações sobre outras atividades que podem ocorrer 
simultaneamente 
 
PROCESSOS DE 
ENGENHARIA DE REQUISITOS 
 
 Engenharia de Software 14 
 Prof. Me. Marcelo dos Santos Moreira 
5. Uma descrição do estado de sistema no fim do cenário 
A elicitação baseada em cenários pode ser realizada informalmente – os 
engenheiros de requisitos trabalham com os stakeholders para identificar cenários e captar os 
detalhes desses cenários. Os cenários podem ser escritos na forma de textos, 
complementados por diagramas, imagens de computador etc. Como alternativa, pode ser 
adotada uma abordagem mais estruturada, como cenários de eventos ou casos de uso. 
Como exemplo de um cenário simples em texto, considere como um usuário 
do sistema LIBSYS de biblioteca pode usar o sistema. O cenário é mostrado no Quadro 3.1. O 
usuário deseja imprimir uma cópia para uso pessoal de um artigo de uma revista médica. Essa 
revista permite cópias gratuitas de artigos disponíveis para assinantes, mas os não-assinantes 
devem pagar uma taxa por artigo. O usuário conhece o artigo, seu título e a data da publicação. 
Quadro 3.1 – Cenário para download de artigo no LIBSYS 
Hipótese inicial: O usuário se conectou ao sistema LlBSYS e localizou a revista que contém a cópia do 
artigo. 
Normal: O usuário seleciona o artigo a ser copiado. O sistema solicita que o usuário forneça as 
informações de assinante da revista ou indique uma forma de pagamento pelo artigo. O pagamento pode 
ser feito por meio de cartão de crédito ou com a informação de um número de conta da organização. 
É solicitado, depois, que o usuário preencha um formulário de direitos autorais com os detalhes da 
transação e o envie ao sistema LlBSYS. 
O formulário de direitos autorais é verificado e, caso aprovado, a versão do artigo em PDF é baixada na 
área de trabalho do LlBSYS no computador do usuário e este é avisado de que o artigo está disponível. 
É solicitadoque o usuário selecione uma impressora e uma cópia do artigo é impressa. Se o artigo 
estiver marcado como 'apenas para impressão', este será apagado automaticamente do sistema do 
usuário após o término da impressão. 
O que pode dar errado: O usuário pode não preencher o formulário de direitos autorais corretamente. 
Nesse caso, o formulário deverá ser reapresentado ao usuário para correção. 
Se o formulário reapresentado ainda estiver incorreto, a solicitação do usuário para o artigo será 
rejeitada. 
O pagamento pode ser rejeitado pelo sistema; nesse caso, a solicitação do usuário para o artigo será 
rejeitada. 
O download do artigo pode falhar, o que faz com que o sistema tente novamente até que a operação 
seja bem-sucedida ou que o usuário termine a sessão. 
Pode não ser possível imprimir o artigo. Se o artigo não estiver marcado como 'apenas para impressão', 
ele será mantido na área de trabalho do LlBSYS. Caso contrário, o artigo será apagado automaticamente 
e o custo do artigo será debitado na conta do usuário. 
Outras atividades: Downloads simultâneos de outros artigos. 
Estado de sistema após o término: O usuário estará conectado. O artigo baixado teria sido apagado 
da área de trabalho do LlBSYS caso estivesse marcado como 'apenas para impressão' . 
 
 
PROCESSOS DE 
ENGENHARIA DE REQUISITOS 
 
 Engenharia de Software 15 
 Prof. Me. Marcelo dos Santos Moreira 
Casos de uso 
Os casos de uso constituem uma técnica baseada em cenários para elicitação 
de requisitos e se tornaram uma característica fundamental da notação UML para descrição de 
modelos de sistema orientado a objetos. Em sua forma mais simples, um caso de uso identifica 
o tipo da interação e os agentes envolvidos. Por exemplo, a figura 3.3 mostra o caso de uso de 
alto nível do recurso de impressão de artigos no LIBSYS, descrito no Quadro 3.1. 
 
A figura 3.3 mostra os elementos essenciais da notação de caso de uso. Os 
agentes no processo são representados como bonecos e cada classe de interação é 
representada como uma elipse identificada. O conjunto de casos de uso representa todas as 
possíveis interações a serem representadas nos requisitos de sistema. A figura 3.4 desenvolve 
o exemplo do LIBSYS e mostra outros casos de uso nesse ambiente. 
 
Usuário da 
biblioteca 
Figura 3.4 – Casos de uso para o sistema de biblioteca 
Busca de 
artigos 
Impressão 
de artigos 
Administração 
de usuários 
Serviços de 
catálogo 
Fornecedor 
Pessoal da 
biblioteca 
Impressão 
de artigos 
Usuário da 
biblioteca 
Figura 3.3 – Caso de uso simples para impressão de artigos 
 
PROCESSOS DE 
ENGENHARIA DE REQUISITOS 
 
 Engenharia de Software 16 
 Prof. Me. Marcelo dos Santos Moreira 
Algumas vezes, existe confusão sobre se um caso de uso é um cenário em si 
ou se um caso de uso engloba um conjunto de cenários, sendo cada cenário um 
encadeamento isolado ao longo do caso de uso. Se um cenário incluir vários encadeamentos, 
existirá um cenário para interação normal e mais cenários para cada possível exceção. 
Os casos de uso identificam as interações individuais com o sistema. Eles 
podem ser documentados por meio de texto ou de links com os modelos UML que 
desenvolvem o cenário mais detalhadamente. Os diagramas de sequência são frequentemente 
usados para adicionar informações ao caso de uso. Os diagramas de sequência mostram os 
agentes envolvidos na interação, os objetos com os quais interagem e as operações 
associadas a esses objetos. 
Como ilustração disto, a figura 3.5 mostra as interações envolvidas no uso do 
LIBSYS para baixar e imprimir um artigo na forma de diagrama de sequência. Na figura 3.5, 
existem quatro objetos de classes – Artigo, Formulário, Área de Trabalho e Impressora – 
envolvidos na interação. A sequência de ações ocorre de cima para baixo e os rótulos sobre as 
setas entre os agentes e os objetos indicam os nomes das operações. Essencialmente, a 
solicitação de um artigo pelo usuário dispara uma requisição para um formulário de direitos 
autorais. Quando o usuário concluir o preenchimento do formulário, o artigo será baixado e 
enviado para a impressora. Quando a impressão terminar, o artigo será apagado da área de 
trabalho do LIBSYS. 
 
Figura 3.5 – Diagrama de sequência das interações do sistema para impressão de artigos 
apagar 
informar 
confirmar 
enviar 
imprimir 
artigo ok 
liberar 
direitos autorais ok 
retornar 
completar 
solicitar 
solicitar 
Item: Artigo copyrightForm: 
Formulário 
myWorkspace: 
Área de trabalho 
myPrinter: 
Impressora Usuário da 
biblioteca 
 
PROCESSOS DE 
ENGENHARIA DE REQUISITOS 
 
 Engenharia de Software 17 
 Prof. Me. Marcelo dos Santos Moreira 
A UML é um padrão real para a modelagem orientada a objetos e, portanto, os 
casos de uso e a elicitação baseada em casos de uso têm sido cada vez mais usados para 
elicitação de requisitos. 
Cenários e casos de uso são técnicas eficazes para elicitação de requisitos 
segundo pontos de vista de interação, em que cada tipo de interação pode ser representado 
como um caso de uso. Eles também podem ser usados em conjunto com alguns pontos de 
vista indiretos, sendo que esses pontos de vista recebem alguns resultados (como um relatório 
gerencial) do sistema. Contudo, como eles enfocam as interações, não são eficazes para 
elicitar restrições ou requisitos de negócios e não funcionais de alto nível com base nos pontos 
de vista indiretos ou para obter requisitos de domínio. 
Etnografia 
Os sistemas de software não existem isoladamente – eles são usados em um 
contexto social e organizacional e os requisitos do sistema de software podem ser derivados ou 
restringidos por esse contexto. Geralmente, satisfazer esses requisitos sociais e 
organizacionais é importante para o sucesso do sistema. Uma razão pela qual vários sistemas 
de software são entregues, mas nunca usados, é que eles não dão a importância devida a 
esses requisitos. 
Etnografia é uma técnica de observação que pode ser usada para 
compreender os requisitos sociais e organizacionais. Um analista se insere no ambiente de 
trabalho onde o sistema será usado. Ele observa o trabalho do dia a dia e anota as tarefas 
reais nas quais os participantes estão envolvidos. O valor da etnografia está na ajuda que 
presta aos analistas para descobrir os requisitos implícitos de sistema que refletem os 
processos reais, e não os formais, com os quais as pessoas estão envolvidas. 
As pessoas frequentemente consideram muito difícil articular detalhes de seu 
trabalho, pois isso é secundário para elas. Elas compreendem seu próprio trabalho, mas 
podem não compreender seu relacionamento com o trabalho de outros na organização. Os 
fatores sociais e organizacionais, que afetam o trabalho, mas que não são óbvios para as 
pessoas, podem somente se tornar claros quando examinados por um observador imparcial. 
Pesquisadores usaram a etnografia para estudar o trabalho em escritório e 
concluíram que as práticas reais de trabalho eram mais ricas, mais complexas e mais 
dinâmicas do que os simples modelos considerados pelos sistemas e automação de escritório. 
A diferença entre o trabalho suposto e o real é a razão mais importante pela qual os sistemas 
de escritório não tiveram efeito significativo na produtividade. Outros estudos de etnografia 
para a compreensão dos requisitos de sistema incluíram estudos sobre controle de tráfego 
aéreo, salas de controle do metrô, sistemas financeiros e várias atividades de projeto. 
 
PROCESSOS DE 
ENGENHARIA DE REQUISITOS 
 
 Engenharia de Software 18 
 Prof. Me. Marcelo dos Santos Moreira 
Outras pesquisas investigaram métodos de integração de etnografiano 
processo de engenharia de software, ligando-o aos métodos de engenharia de requisitos e pela 
documentação de padrões de interação em sistemas cooperativos. 
A etnografia é particularmente eficaz para descobrir dois tipos de requisitos: 
1. Requisitos derivados da maneira como as pessoas realmente 
trabalham em vez da maneira pela qual as definições de processo 
dizem que elas deveriam trabalhar. Por exemplo, os controladores de 
tráfego aéreo podem desligar um sistema de alerta de colisão de 
aeronaves que detecta rotas de voo em colisão, embora os 
procedimentos normais de controle especifiquem que ele deve ser 
usado. Sua estratégia de controle é projetada para assegurar que 
essas aeronaves sejam afastadas antes que ocorram problemas e os 
controladores consideram que o alarme de alerta os distrai de seu 
trabalho. 
2. Requisitos derivados da cooperação e do conhecimento das 
atividades de outras pessoas. Por exemplo, os controladores de 
tráfego aéreo podem usar o conhecimento que têm do trabalho de 
outros controladores para prever o número de aeronaves que entrarão 
em seu setor de controle. Depois eles modificam suas estratégias de 
controle, dependendo da sobrecarga prevista. Portanto, um sistema 
automatizado de controle de tráfego aéreo deve permitir que os 
controladores em um setor tenham alguma visibilidade do trabalho em 
setores adjacentes. 
A etnografia pode ser combinada com a prototipação (figura 3.6). A etnografia 
informa o desenvolvimento do protótipo de tal modo que poucos ciclos de refinamento de 
protótipo sejam necessários. Além disso, a prototipação enfoca a etnografia, identificando os 
problemas e as questões que podem, assim, ser discutidos com o etnógrafo. O etnógrafo deve, 
então, procurar as respostas a estas questões durante a próxima fase do estudo de sistema. 
Os estudos de etnografia podem revelar detalhes importantes do processo 
frequentemente ignorados por outras técnicas de elicitação de requisitos. No entanto, devido a 
seu foco no usuário final, essa abordagem não é apropriada para obter os requisitos 
organizacionais ou de domínio. Os estudos etnográficos nem sempre podem identificar novas 
características a serem acrescentadas a um sistema. A etnografia não é, portanto, uma 
abordagem completa para elicitação e deve ser usada para complementar outras abordagens, 
como a análise de casos de uso. 
 
PROCESSOS DE 
ENGENHARIA DE REQUISITOS 
 
 Engenharia de Software 19 
 Prof. Me. Marcelo dos Santos Moreira 
 
4. VALIDAÇÃO DE REQUISITOS 
A validação de requisitos dedica-se a mostrar que os requisitos realmente 
definem o sistema que o usuário deseja/necessita. A validação de requisitos se sobrepõe à 
análise; está relacionada à descoberta de problemas com os requisitos. A validação de 
requisitos é importante porque os erros em um documento de requisitos podem levar a custos 
excessivos de retrabalho quando são descobertos durante o desenvolvimento ou depois que o 
sistema está em operação. O custo de correção de um problema de requisitos, fazendo uma 
mudança de sistema, é muito maior do que a correção de erros de projeto e de codificação. A 
razão disso é que uma mudança de requisitos significa geralmente que o projeto e a 
implementação do sistema devem também ser mudados e o sistema deve ser novamente 
testado. 
Durante o processo de validação de requisitos, devem ser realizadas 
verificações nos requisitos do documento de requisitos. Essas verificações incluem: 
1. Verificações de validade: um usuário pode pensar que um sistema é 
necessário para desempenhar determinadas funções. Contudo, mais 
estudos e análises podem identificar que funções adicionais e 
diferentes são necessárias. Os sistemas têm diversos stakeholders 
com necessidades diferentes e qualquer conjunto de requisitos é, 
inevitavelmente, um compromisso da comunidade de stakeholders. 
2. Verificações de consistência: os requisitos em um documento não 
devem ser conflitantes. Isso significa que não devem existir restrições 
ou descrições contraditórias para a mesma função do sistema. 
Figura 3.6 – Etnografia e prototipação para análise de requisitos 
Análise 
etnográfica 
Reuniões 
de prestação 
de contas 
Etnografia 
focalizada 
Desenvolvimento 
de sistema 
genérico 
Prototipação 
de sistema 
Avaliação de 
protótipo 
 
PROCESSOS DE 
ENGENHARIA DE REQUISITOS 
 
 Engenharia de Software 20 
 Prof. Me. Marcelo dos Santos Moreira 
3. Verificações de completeza: o documento de requisitos deve incluir 
requisitos que definam todas as funções e as restrições desejadas 
pelo usuário do sistema. 
4. Verificações de realismo: usando o conhecimento da tecnologia 
existente, os requisitos devem ser verificados quanto a se realmente 
podem ser implementados. Essas verificações também devem levar 
em consideração o orçamento e o prazo para o desenvolvimento do 
sistema. 
5. Facilidade de verificação: para reduzir o potencial de divergências 
entre cliente e fornecedor, os requisitos do sistema devem sempre 
ser escritos de modo que sejam verificáveis. Isso significa que deve-
se ser capaz de escrever um conjunto de testes que possa 
demonstrar que o sistema entregue atende a cada requisito 
especificado. 
Uma série de técnicas de validação de requisitos pode ser usada em conjunto 
ou individualmente: 
1. Revisões de requisitos: os requisitos são analisados 
sistematicamente por uma equipe de revisores. 
2. Prototipação: nesta abordagem de validação, um modelo executável 
do sistema é apresentado para usuários finais e clientes. Eles podem 
experimentar o modelo para verificar se atende às suas necessidades 
reais. 
3. Geração de casos de teste: os requisitos devem ser testáveis. Se os 
testes dos requisitos forem criados como parte do processo de 
validação, eles frequentemente revelarão problemas de requisitos. Se 
um teste for difícil ou impossível de ser projetado, isso significa 
geralmente que os requisitos serão difíceis de ser implementados e 
devem ser reconsiderados. O desenvolvimento de testes a partir de 
requisitos de usuário, antes de o código estar escrito, é uma parte 
integrante da extreme programming. 
Não se deve subestimar os problemas de validação de requisitos. É difícil 
demonstrar que um conjunto de requisitos atende às necessidades do usuário. Os usuários 
devem imaginar o sistema em operação e avaliar sua adequação ao trabalho. É difícil para 
profissionais de informática habilidosos realizar esse tipo de análise abstrata e é ainda mais 
difícil para os usuários do sistema. Como resultado, raramente se encontra todos os problemas 
 
PROCESSOS DE 
ENGENHARIA DE REQUISITOS 
 
 Engenharia de Software 21 
 Prof. Me. Marcelo dos Santos Moreira 
de requisitos durante o processo de validação. É inevitável que haja mudanças de requisitos 
posteriores para corrigir omissões e mal-entendidos depois da aprovação do documento de 
requisitos. 
4.1. Revisões de requisitos 
A revisão de requisitos é um processo manual que envolve pessoas de ambas 
as organizações, do cliente e do fornecedor. Eles verificam o documento de requisitos em 
busca de anomalias e omissões. O processo de revisão pode ser gerenciado da mesma 
maneira que as inspeções de programa – auditoria de sistemas. Como alternativa, ele pode ser 
organizado como uma atividade mais ampla, sendo que diferentes pessoas verificam diferentes 
partes do documento. 
As revisões de requisitos podem ser informais ou formais. As revisões 
informais envolvem simplesmente os fornecedores que discutem os requisitos com o maior 
número possível de stakeholders. É surpreendente a frequência com que a comunicação entre 
os projetistas e os stakeholders terminaapós a elicitação e não existe confirmação de se os 
requisitos documentados são os que os stakeholders realmente solicitaram. Muitos problemas 
podem ser detectados simplesmente conversando sobre o sistema com os stakeholders antes 
do comprometimento de uma revisão formal. 
Em uma revisão formal de requisitos, a equipe de desenvolvimento deve 
'conduzir' o cliente pelos requisitos de sistema, explicando as implicações de cada requisito. A 
equipe de revisão deve verificar cada requisito em termos de consistência bem como verificar 
os requisitos como um todo em termos de completeza. Os revisores podem também verificar: 
1. Facilidade de verificação: o requisito, conforme estabelecido, é 
testável de forma realística? 
2. Facilidade de compreensão: os adquirentes e os usuários finais do 
sistema compreendem o requisito de forma apropriada? 
3. Rastreabilidade: a origem do requisito está estabelecida claramente? 
Talvez seja necessário retornar à fonte do requisito para avaliar o 
impacto de uma mudança. A rastreabilidade é importante, pois 
permite que o impacto de uma mudança seja avaliado em relação ao 
restante do sistema. A rastreabilidade é explicada mais 
detalhadamente na próxima seção. 
4. Adaptabilidade: o requisito é adaptável? Isto é, o requisito pode ser 
mudado sem efeitos em grande escala sobre os outros requisitos de 
sistema? 
 
PROCESSOS DE 
ENGENHARIA DE REQUISITOS 
 
 Engenharia de Software 22 
 Prof. Me. Marcelo dos Santos Moreira 
Conflitos, contradições, erros e omissões nos requisitos devem ser apontados 
pelos revisores e registrados formalmente no relatório de revisão. É, portanto, de 
responsabilidade dos usuários, do adquirente de sistema e do desenvolvedor de sistema 
negociar uma solução para esses problemas identificados. 
5. GERENCIAMENTO DE REQUISITOS 
Os requisitos de sistemas de software de grande porte estão sempre mudando. 
Um motivo para isso é que esses sistemas são geralmente desenvolvidos para lidar com 
problemas 'perversos'. Como o problema não pode ser totalmente definido, os requisitos de 
software tendem a ser incompletos. Durante o processo de software, o entendimento dos 
stakeholders sobre o problema muda constantemente. Esses requisitos devem então evoluir 
para refletir essas novas visões do problema. 
Além disso, depois que o sistema estiver instalado, inevitavelmente surgirão 
novos requisitos. É difícil para os usuários e os clientes do sistema anteciparem quais efeitos o 
novo sistema causará na organização. Quando os usuários adquirirem experiência com o 
sistema, eles descobrirão novas necessidades e prioridades: 
1. Sistemas de grande porte geralmente têm uma comunidade 
diversificada de usuários, sendo que esses usuários têm diferentes 
requisitos e prioridades, os quais podem ser conflitantes ou 
contraditórios. Os requisitos finais do sistema constituem 
inevitavelmente um compromisso entre eles e, com a experiência, 
descobre-se frequentemente que o equilíbrio de apoio dado aos 
diferentes usuários tem de ser mudado. 
2. As pessoas que pagam por um sistema e os usuários de um sistema 
raramente são as mesmas pessoas. Os clientes do sistema impõem 
requisitos devido a restrições organizacionais e de orçamento. Essas 
restrições podem ser conflitantes com os requisitos dos usuários finais 
e, após a entrega, novas características podem ser incluídas para 
apoio do usuário, fazendo com que o sistema alcance as suas metas. 
3. Os ambientes de negócios e técnico do sistema mudam após a 
instalação e essas mudanças devem se refletir no sistema. 
4. Um novo hardware pode ser introduzido, pode ser necessária uma 
interface com outros sistemas, as prioridades de negócios podem 
mudar trazendo consequentes mudanças no apoio ao sistema e uma 
 
PROCESSOS DE 
ENGENHARIA DE REQUISITOS 
 
 Engenharia de Software 23 
 Prof. Me. Marcelo dos Santos Moreira 
nova legislação e regulamentos em ser introduzidos devendo ser 
implementados no sistema. 
O gerenciamento de requisitos é um processo para compreender e controlar as 
mudanças dos requisitos de sistema. É necessário manter o acompanhamento dos requisitos 
individuais e manter as ligações entre os requisitos dependentes, de modo que seja possível 
avaliar o impacto das mudanças de requisitos. É necessário estabelecer um processo formal 
para fazer propostas de mudança e ligá-las aos requisitos de sistema. O processo de 
gerenciamento de requisitos deve se iniciar assim que uma versão inicial do documento de 
requisitos esteja disponível, mas deve-se iniciar o planejamento das mudanças de requisitos 
durante o processo de elicitação de requisitos. 
5.1. Requisitos permanentes e voláteis 
A evolução de requisitos, durante o processo de engenharia de requisitos e 
após a entrada de um sistema em operação, é inevitável. O desenvolvimento de requisitos de 
software enfoca as capacidades de software, objetivos da empresa e outros sistemas da 
empresa. À medida que a definição dos requisitos se desenvolve, uma compreensão maior das 
necessidades dos usuários é obtida. Isso realimenta as informações do usuário que pode, 
então, propor uma mudança nos requisitos (figura 5.1). Além disso, pode levar muitos anos 
para especificar um sistema de grande porte. Ao longo desse tempo, o ambiente do sistema e 
os objetivos da empresa mudam e os requisitos evoluem para refletir essas mudanças. 
 
Do ponto de vista da evolução, os requisitos dividem-se em duas classes: 
1. Requisitos permanentes: são requisitos relativamente estáveis 
derivados da atividade central da organização e que se relacionam 
diretamente ao domínio do sistema. Por exemplo, em um hospital, 
sempre existirão requisitos relacionados a pacientes, médicos, 
Compreensão 
inicial 
do problema 
Requisitos 
iniciais 
Compreensão 
modificada 
 do problema 
Requisitos 
modificados 
tempo 
Figura 5.1 – Evolução de requisitos 
 
PROCESSOS DE 
ENGENHARIA DE REQUISITOS 
 
 Engenharia de Software 24 
 Prof. Me. Marcelo dos Santos Moreira 
enfermeiros e tratamentos. Esses requisitos podem ser derivados 
de modelos de domínio que mostram as entidades e as relações 
que caracterizam um domínio de aplicação. 
2. Requisitos voláteis: são requisitos que provavelmente irão mudar 
durante o processo de desenvolvimento do sistema ou depois que o 
sistema estiver em operação. Um exemplo seria os requisitos que 
resultam de políticas de saúde do governo. 
Sugere-se que os requisitos voláteis sejam divididos em cinco classes, 
conforme demonstrado na tabela 5.1. 
Tabela 5.1 – Classificação de requisitos voláteis 
Tipo de requisito Descrição 
Requisitos 
mutáveis 
Requisitos que mudam devido a mudanças no ambiente no qual a 
organização está operando. Por exemplo, em sistemas hospitalares, o 
financiamento do tratamento de pacientes pode mudar e, assim, exigir 
que informações de diferentes tratamentos sejam coletadas. 
Requisitos 
emergentes 
Requisitos que surgem à medida que a compreensão do sistema pelo 
cliente progride durante o desenvolvimento do sistema. O processo de 
projeto pode revelar novos requisitos emergentes. 
Requisitos 
consequentes 
Requisitos que resultam da introdução do sistema de computador. A 
introdução do sistema de computador pode mudar os processos da 
organização e criar novas formas de trabalho que geram novos 
requisitos de sistema. 
Requisitos de 
compatibilidade 
 
Requisitos que dependem de sistemas ou processos de negócios 
específicos dentro de uma organização. À medida que eles mudam, os 
requisitos de compatibilidade do sistema encomendado ou entregue 
podem também evoluir. 
 
5.2. Planejamento de gerenciamento de requisitos 
O planejamentoé o primeiro estágio essencial no processo de gerenciamento 
de requisitos. O gerenciamento de requisitos é muito dispendioso. Para cada projeto, o estágio 
de planejamento estabelece o nível de detalhamento necessário para o gerenciamento de 
requisitos. Durante o estágio de gerenciamento de requisitos, deve-se decidir sobre: 
1. Identificação de requisitos: cada requisito deve ser identificado 
unicamente de modo que possa ser feita a referência cruzada entre 
este e outros requisitos para que ele possa ser usado nas 
avaliações de rastreabilidade. 
 
PROCESSOS DE 
ENGENHARIA DE REQUISITOS 
 
 Engenharia de Software 25 
 Prof. Me. Marcelo dos Santos Moreira 
2. Processo de gerenciamento de mudanças: é o conjunto de 
atividades que avaliam o impacto e custo das mudanças. 
3. Políticas de rastreabilidade: essas políticas definem os 
relacionamentos entre os requisitos e entre os requisitos e o projeto 
do sistema, que devem ser registrados e como esses registros 
devem ser mantidos. 
4. Apoio de ferramentas CASE: o gerenciamento de requisitos 
envolve o processamento de grandes quantidades de informações 
sobre os requisitos. As ferramentas que podem ser usadas variam 
desde sistemas especializados de gerenciamento de requisitos a 
planilhas e sistemas simples de banco de dados. 
Existem vários relacionamentos entre os requisitos e entre os requisitos e o 
projeto do sistema. Existem também ligações entre requisitos e os motivos básicos de por que 
esses requisitos foram propostos. Quando as mudanças são propostas, deve-se rastrear o seu 
impacto em outros requisitos e no projeto do sistema. A rastreabilidade é a propriedade de uma 
especificação de requisitos que reflete a facilidade de encontrar os requisitos relacionados. 
Existem três tipos de informações de rastreabilidade que podem ser mantidos: 
1. Informações de rastreabilidade da origem ligam os requisitos aos 
stakeholders que propuseram os requisitos e aos motivos desses 
requisitos. Quando uma mudança é proposta, essas informações são 
usadas para encontrar e consultar os stakeholders sobre a mudança. 
2. Informações de rastreabilidade de requisitos ligam os requisitos 
dependentes dentro do documento de requisitos. Essas informações 
são usadas para avaliar quantos requisitos provavelmente serão 
afetados pela mudança proposta e a extensão das mudanças de 
requisitos consequentes que podem ser necessários. 
3. Informações de rastreabilidade de projeto ligam os requisitos aos 
módulos de projeto, nos quais esses requisitos são implementados. 
Essas informações são usadas para avaliar o impacto das mudanças 
de requisitos propostas no projeto e na implementação do sistema. 
As informações de rastreabilidade são frequentemente representadas por meio 
de matrizes de rastreabilidade que relacionam os requisitos aos stakeholders, aos outros 
requisitos ou aos módulos de projeto. Em uma matriz de rastreabilidade de requisitos, cada 
 
PROCESSOS DE 
ENGENHARIA DE REQUISITOS 
 
 Engenharia de Software 26 
 Prof. Me. Marcelo dos Santos Moreira 
requisito é introduzido em uma linha e uma coluna da matriz. As dependências entre diferentes 
requisitos são registradas na célula correspondente à intersecção de linha/coluna. 
A tabela 5.2 mostra uma matriz simples de rastreabilidade que registra as 
dependências entre requisitos. A letra 'D' na intersecção linha/coluna ilustra que o requisito da 
linha depende do requisito identificado na coluna; a letra 'R' significa que existe algum outro 
relacionamento mais fraco entre os requisitos. Por exemplo, ambos podem definir os requisitos 
para partes do mesmo subsistema. 
Tabela 5.2 – Matriz de rastreabilidade 
ID de 
requisito 1.1 1.2 1.3 2.1 2.2 2.3 3.1 3.2 
1.1 D R 
1.2 D R D 
1.3 R R 
2.1 R D D 
2.2 D 
2.3 R D 
3.1 R 
3.2 R 
 
As matrizes de rastreabilidade podem ser usadas quando um pequeno número 
de requisitos deve ser gerenciado, mas para sistemas de grande porte, com muitos requisitos, 
tornam-se muito difíceis de serem gerenciadas e sua manutenção é dispendiosa, Para esses 
sistemas, deve-se captar as informações de rastreabilidade em um banco de dados de 
requisitos, no qual cada requisito é explicitamente ligado a requisitos relacionados. Pode-se, 
então, avaliar o impacto das mudanças usando os recursos de acesso ao banco de dados. As 
matrizes de rastreabilidade podem ser geradas automaticamente baseadas no banco de dados. 
O gerenciamento de requisitos precisa de apoio automatizado; as ferramentas 
CASE para essa finalidade devem ser selecionadas durante a fase de planejamento. O apoio 
de ferramentas é necessário para: 
1. Armazenamento de requisitos: os requisitos devem ser mantidos em 
um repositório de dados seguro e gerenciado, acessível a todos os 
envolvidos no processo de engenharia de requisitos. 
 
PROCESSOS DE 
ENGENHARIA DE REQUISITOS 
 
 Engenharia de Software 27 
 Prof. Me. Marcelo dos Santos Moreira 
2. Gerenciamento de mudanças: o processo de gerenciamento de 
mudanças (figura 5.2) é simplificado se um apoio ativo de ferramentas 
estiver disponível. 
3. Gerenciamento de rastreabilidade: conforme explicado anteriormente, 
o apoio de ferramentas para rastreabilidade permite que requisitos 
relacionados sejam obtidos. Algumas ferramentas usam técnicas de 
processamento de linguagem natural para auxiliar na descoberta de 
possíveis relacionamentos entre os requisitos. 
Para sistemas de pequeno porte, o uso de ferramentas especializadas de 
gerenciamento de requisitos pode não ser necessário. O processo de gerenciamento de 
requisitos pode ter o apoio de recursos disponíveis em processadores de texto, planilhas e 
bancos de dados. Contudo, para sistemas de grande porte, é necessária uma ferramenta de 
apoio mais especializada. 
5.3. Gerenciamento de mudanças de requisitos 
O gerenciamento de mudanças de requisitos (figura 5.2) deve ser aplicado a 
todas as mudanças propostas aos requisitos. A vantagem de usar um processo formal para 
gerenciamento de mudanças é que todas as propostas de mudança são tratadas 
consistentemente e as mudanças no documento de requisitos são feitas de maneira controlada. 
Existem três principais estágios para um processo de gerenciamento de mudanças: 
1. Análise do problema e especificação da mudança: o processo se 
inicia com um problema de requisitos identificado ou, às vezes, com 
uma proposta de mudança específica. Durante esse estágio, o 
problema ou a proposta de mudança é analisada para verificar se é 
válida. Os resultados da análise são realimentados para o solicitante 
da mudança e, algumas vezes, é feita uma proposta de mudança de 
requisitos mais específica. 
2. Análise da mudança e estimativa de custo: o efeito da mudança 
proposta é avaliado usando as informações de rastreabilidade e o 
conhecimento geral sobre os requisitos do sistema. O custo de 
realizar a mudança é estimado em termos de modificações no 
documento de requisitos e, se adequado, do projeto e da 
implementação do sistema. Uma vez completada esta análise, é 
tomada uma decisão sobre prosseguir ou não com a mudança de 
requisitos. 
 
PROCESSOS DE 
ENGENHARIA DE REQUISITOS 
 
 Engenharia de Software 28 
 Prof. Me. Marcelo dos Santos Moreira 
3. Implementação da mudança: o documento de requisitos e, quando 
necessário, o projeto e a implementação de sistema são modificados. 
Deve-se organizar o documento de requisitos de modo que possa 
realizar as mudanças sem reescrita ou reorganização extensivas. Da 
mesma maneira que na programação, a facilidade de mudanças no 
documento é obtida por meio da minimização das referências 
externas e tornandoas seções do documento o mais modulares 
possível. Assim, as seções individuais podem ser mudadas e 
substituídas sem afetar outras partes do documento. 
 
Se uma mudança de requisitos do sistema é solicitada com urgência, existe 
sempre uma propensão a realizar a mudança no sistema e, depois, retrospectivamente, 
modificar o documento de requisitos. Isso leva quase inevitavelmente à defasagem entre o 
documento de requisitos e a implementação do sistema. Uma vez feitas as mudanças no 
sistema, as mudanças no documento de requisitos podem ser esquecidas ou realizadas de 
maneira não consistente com as mudanças no sistema. 
Os processos iterativos de desenvolvimento, como extreme programming, 
foram definidos para lidar com requisitos que mudam durante o processo de desenvolvimento. 
Nesses processos, quando um usuário propõe mudança de requisito, essa mudança não é 
realizada por meio de um processo de gerenciamento de mudanças formal. Em vez disso, o 
usuário precisa priorizar essa mudança e, se a prioridade for alta, decidir quais características 
do sistema planejadas para a próxima iteração devem ser abandonadas. 
 
Análise do 
problema e 
especificação 
de mudanças 
Figura 5.2 – Gerenciamento de mudanças de requisitos 
Problema 
identificado Análise de mudanças e 
estimativa 
de custo 
 
Implementação 
das mudanças 
 
Requisitos 
revisados 
 
PROCESSOS DE 
ENGENHARIA DE REQUISITOS 
 
 Engenharia de Software 29 
 Prof. Me. Marcelo dos Santos Moreira 
 
 
 
Prof. Me. Marcelo dos Santos Moreira 
 Empresário 
 Consultor de Empresas 
 Professor Universitário 
 Mestre em Informática 
 Gestão de Sistemas de Informação 
 Especialista em Sistemas de Informatização 
Empresarial 
 Bacharel em Administração 
 Tecnólogo em Processamento de Dados 
 
marcelo.moreira2@fatec.sp.gov.br