I_Teorico (4)

Prévia do material em texto

Inserir Título Aqui 
Inserir Título Aqui
Engenharia de 
Requisitos
Engenharia de Requisitos
Responsável pelo Conteúdo:
Prof. Me. Afonso Maria Luiz Rodrigues Pavão
Revisão Textual:
Prof. Esp. Claudio Pereira do Nascimento
Nesta unidade, trabalharemos os seguintes tópicos:
• Engenharia de Requisitos.
Fonte: iStock/Getty Im
ages
Objetivos
• Compreender e identificar os aspectos fundamentais requeridos para o processo de software 
em seu desenvolvimento.
Caro Aluno(a)!
Normalmente, com a correria do dia a dia, não nos organizamos e deixamos para o 
último momento o acesso ao estudo, o que implicará o não aprofundamento no material 
trabalhado ou, ainda, a perda dos prazos para o lançamento das atividades solicitadas.
Assim, organize seus estudos de maneira que entrem na sua rotina. Por exemplo, você 
poderá escolher um dia ao longo da semana ou um determinado horário todos ou alguns 
dias e determinar como o seu “momento do estudo”.
No material de cada Unidade, há videoaulas e leituras indicadas, assim como sugestões 
de materiais complementares, elementos didáticos que ampliarão sua interpretação e 
auxiliarão o pleno entendimento dos temas abordados.
Após o contato com o conteúdo proposto, participe dos debates mediados em fóruns de 
discussão, pois estes ajudarão a verificar o quanto você absorveu do conteúdo, além de 
propiciar o contato com seus colegas e tutores, o que se apresenta como rico espaço de 
troca de ideias e aprendizagem.
Bons Estudos!
Engenharia de Requisitos
UNIDADE 
Engenharia de Requisitos
Contextualização
Quando se fala em processo de desenvolvimento de software, geralmente todos 
lembram da engenharia de software, mas raramente cita-se a engenharia de requisitos 
em seu contexto mais amplo possível. Ou seja, restringe-se os comentários à análise e 
à especificação dos requisitos, sem se dar conta que há muitas circunstâncias e fatos 
ocorrendo paralelamente às técnicas propriamente ditas.
Para variar um pouco, vamos iniciar nossos estudos a partir das lembranças dos 
fatos que interferem no processo da engenharia de requisitos e, consequentemente, 
na elaboração de um projeto de software. E claro, que trazem muitos prejuízos que 
poderiam ser evitados.
Um software que irá controlar os batimentos cardíacos de um paciente, o monitora-
mento dos aparelhos em um centro cirúrgico por exemplo, nos dá uma ideia da respon-
sabilidade e seriedade com que devem ser tratadas suas especificações.
Então, porque não se dá a devida valia também aos softwares legados ou menos 
críticos? Será que a ética, a especialização ou o empenho dos desenvolvedores é tão 
vulnerável ou suscetível às diversas situações que se apresentam? Ou estes não merecem 
de fato a mesma atenção?
A importância da comunicação na definição das especificações de um software é 
sabidamente alta. Além disso, há os fatores individuais entre os emissores e os receptores, 
que podem fazer com que o entendimento entre ambos seja o mais adequado ou o correto.
Isso tudo nos remete aos problemas e dificuldades na determinação das especificações 
de um software.
Em outras palavras, a elaboração de um projeto de software tem como premissa fun-
damental uma boa identificação de suas especificações, não só para atender às necessi-
dades dos usuários, como também – e não menos importante, para facilitar o processo 
do desenvolvimento do software, viabilizar o cronograma e atender ao orçamento.
Simples assim. Mas não é exatamente isso que acontece, como veremos a seguir.
6
7
Engenharia de Requisitos
O processo de desenvolvimento de software pode ser considerado complexo, mas o 
mesmo não pode ser dito sobre a engenharia de requisitos. Entretanto, é ela, que está 
contida na engenharia de software, a causadora dos maiores problemas, desastres e 
prejuízos em uma organização.
Para citar alguns, temos o foguete Mariner em 1962 com prejuízo de US$ 18,5 
milhões ou o Ariane 5 que custou US$ 500 milhões, a quebra da bolsa de valores em 
Wall Street em 1987 com perdas de US$ 500 bilhões em um dia, o custo de US$ 475 
milhões com a falha do processador Pentium em 1993, ou ainda o bug do milênio que 
gerou perdas também da ordem de US$ 500 bilhões em 1999. E isso sem falar nos 
erros que por pouco não causaram outra guerra mundial.
Veja a Tabela 1 e reflita sobre os custos gerados.
Tabela 1 – Prejuízos com software
Year Company Outcome (Costs in us $)
2005 Hudson Bay Co. [Canada] Problems with inventory system contribute to $33.3 million* loss.
2004-05 UK Inland Revenue Software errors contribute to $3.45 billion* tax-credit overpayment.
2004 Avis Europe PLC [UK] Enterprise resource planning (ERP) system canceled after $54.5 million* is spent.
2004 Ford Motor Co. Purchasin system abandoned after deployment costing approximately $400 million.
2004 J SainsBury PLC [UK] Supply-chain management system abandoned after deployment costing $527 million.*
2004 Hewlett-Packard Co. Problems with ERP system contribute to $160 million loss.
2003-04 AT&T Wireless Customer relations management (CRM) upgrade problems lead to revenue loss of $100 million.
2002 McDonald’s Corp. The Innovate information-purchasing system canceled after $ 170 million is spent.
2002 Sydney Water Corp. [Australia] Billing system canceled after $33.2 million* is spent.
2002 CIGNA Corp. Problems with CRM system contribute to $445 million loss.
2001 Nike Inc. Problems with supply-chain management system contribute to $100 million loss.
2001 Kmart Corp. Supply-chain management system canceled after $130 million is spent.
2000 Washignton D.C. City payroll system abandoned after deployment costing $25 million.
1999 United Way Administrative processing system canceled after $12 million is spent.
1999 State of Mississipi Tax system canceled after $11.2 million is spent; state receives $185 million damages.
1999 Hershey Foods Corp. Problems with ERP system contribute to $151 million loss.
1998 Snap-on Inc. Problems witn order-entry system contribute to revenue loss of $50 million.
1997 U.S. Internal Revenue Service Tax modernization effort canceled after $4 billion is spent.
1997 State of Washington Department of Motor Vehicle (DMV) system canceled after $40 million is spent.
1997 Oxford Health Plans Inc. Billing and claims system problems contribute to quaterly loss; stock plummets, leading to $3.4 billion loss in corporate value.
1996 Arianespace [France] Software specification and design error cause $350 million Ariane 5 rocket to explode.
1996 FoxMeyer Drug Co. $40 million ERP system abandoned after deployment, forcing company into bankruptcy.
1995 Toronto Stock [Canada] Electronic trading system canceled after $25.5 million** is spent.
7
UNIDADE 
Engenharia de Requisitos
Year Company Outcome (Costs in us $)
1994 U.S. Federal Aviation Administration Advanced Automation System canceled after $2.6 billion is spent.
1994 State of California DMV system canceled after $44 million is spent.
1994 Chemical Bank Software error causes a total of $15 million to be deducted from 100.000 customer accounts.
1993 London Stock Exchange [UK] Taurus stock settlement system canceled after $600 million** is spent.
1993 Allstate Insurance Co. Office automation system abandoned after deployment, consting $130 million.
1993 London Ambulance Service [UK] Dispatch system canceled in 1990 at $11.25 million**; second attempt abandoned after deployment, costing $15 million.**
1993 Greyhound Lines Inc. Bus reservation system crashes repeatedly upon introduction, contributing to revenue loss of $61 million.
1992
Budget Rent-A-Car, Hilton 
Hotels, Marriott International, 
and AMR [American Airlines]
Travel reservation system canceled after $165 million is spent.
Fonte: Adaptação de: https://goo.gl/2vdePR
Não vamos citar prejuízos gerados por softwares no Brasil por inexistência de dados 
confiáveis e também porque os prejuízos com a pirataria e corrupção são ainda maiores. 
Mas todos imaginamos que também foram muito altos.
Esses sãoalguns dos motivos para que desenvolvedores, gerentes de projetos e 
stakeholders procurem dar mais atenção às especificações do software. Se refletirmos e 
lembrarmos das situações pelas quais passamos ou soubemos, veremos que as despesas, 
os custos e os prejuízos foram também de grande monta.
Muitos problemas podem acontecer durante o processo de desenvolvimento de um 
software, além das causas mais comuns de ficar mais caro que o previsto, atrasar ou não 
ficar conforme o esperado.
É claro que o pior a se acontecer é não entregar o combinado, prometido ou ainda, 
contratado. A percepção de todos é que se algo (por mínimo que seja) não está funcionando 
bem, então nada funciona bem. Essa sensação tende a aumentar significativamente 
quando maior for a quantidade de reuniões ou mensagens trocadas entre as partes. Essa 
troca de mensagens deve acontecer antes e durante a fase de planejamento, exatamente 
para evitar erros, falhas ou omissões no decorrer do projeto.
Uma das coisas que podem afetar o desenvolvimento de um projeto, evidentemente, 
é a falta de motivação da equipe. E alguns dos fatores podem ser que os projetos são 
longos e/ou os prazos rígidos – isto por si só já obriga a equipe a ter foco e dedicação. 
Outro fator que pode afetar a motivação de um grupo é a existência de uma pessoa 
“problemática”, com ciúmes ou egocêntrica. 
Outro fato é que as metas traçadas nem sempre reproduzem a realidade da equipe ou 
não foram calculadas adequadamente; a consequência é que haverá grande possibilidade 
de não trazer os resultados esperados. Estas metas devem ser bastante claras e devem 
ter indicadores simples para serem acompanhados e monitorados.
8
9
Um aspecto que nem sempre é considerado como possível falha em um projeto é o 
excesso de ruídos. Sim, pois se uma equipe que deve concentrar-se para pensar, projetar 
ou escrever linhas de código não estiver em local que propicie um ambiente tranquilo e 
com o mínimo de ruído possível, poderá haver muitas interrupções por causa de barulho.
Outro erro é supor que a contratação de mais desenvolvedores irá ajudar a evitar (ou 
eliminar) atrasos. Isso pode até servir para outras áreas de trabalho, mas no desenvolvi-
mento de software poderá até causar mais atraso ainda, já que o conhecimento sobre 
o assunto está em plena formação ainda e a chegada de outro membro irá provocar o 
deslocamento de alguém para treinar, orientar ou com frequência, elucidar suas dúvidas. 
E a produção de quem chega raramente será no mínimo razoável.
Outro aspecto simples e básico, mas que normalmente é esquecido pela equipe de desen-
volvimento (que pode até ser a mais competente possível), é esquecer que são os usuários 
que irão fazer uso do software e que, portanto, sua usabilidade é fundamental – ou este não 
será aproveitado como poderia ser.
Por outro lado, por mais que às vezes seja necessário aceitar-se um prazo restrito, não 
significa que fazer um cronograma para cumpri-lo seja o mais inteligente. Isso apenas 
servirá para que a pressão sobre a equipe aumente, fazendo com que atrase ainda 
mais devido a erros que acabam acontecendo. O cronograma deve ser preparado com 
parcimônia, equilíbrio e sensatez.
A comunicação é outra vilã no processo de desenvolvimento de software, já que ela é 
base para a engenharia de requisitos, pois falhas como excesso, truncadas, desconexas, 
impróprias ou incompletas podem ser provocadas pela forma como as informações 
chegam e são transmitidas dentro da equipe de projeto (desenvolvedores, usuários 
e stakeholders). Estas falhas podem ser pontuais ou pior, estruturais – o que pode 
comprometer ainda mais um projeto.
Nesse contexto, se as informações dos usuários forem insuficientes, é certo que 
haverá um fracasso no projeto de software. Esta é a maior causa de erros apontada 
pelos profissionais envolvidos no desenvolvimento de um software.
Por outro lado, não podemos esquecer que se a integração entre os envolvidos for 
baixa, estes terão dificuldades em compartilhar dados e informações relativas aos pro-
cessos e ao desenvolvimento, o que afetará a criatividade e a possibilidade de se elimi-
nar mais rapidamente quaisquer dúvidas ou falhas ainda na fase de projeto. Há alguns 
métodos de trabalho que podem ser aplicados para tornar as equipes mais integradas.
Outro problema causado pela falta de integração é que podem ser criadas redundâncias 
ou funções que sequer serão usadas além de dificultar a definição das funcionalidades 
principais ou prioritárias do software.
Comum também é a ausência de controle nas mudanças dos requisitos. Estimam-
se que mais de 20% deles sejam modificados desde o início até a primeira versão do 
sistema. Para que não aconteça isso, é necessário controlar (controlar a existência, mas 
não deixar de atender) essas mudanças até para evitar algumas desnecessárias.
9
UNIDADE 
Engenharia de Requisitos
Quando o assunto é prazo, muitas vezes alguns desenvolvedores acabam assumindo e 
acumulando outras funções no decorrer do projeto, fazendo-os perder em desempenho. 
Isto acontece, pois fatalmente haverá perda no principal foco de seu trabalho, além de 
que, poderá acumular funções que não são de seu interesse ou habilidade. O resultado 
será redução na eficiência, na produtividade e aumento na confusão causado pela falta 
de sintonia em suas ações.
Outras vezes, o grupo de projeto, para recuperar o tempo que acabou e reduzir as recla-
mações e pressões que surgem, acabam por esquecer o planejamento e os testes e começam 
a entregar algumas funcionalidades, provocando alterações de correção em maior volume.
Outra tendência é a equipe, mesmo usando um método ágil, “bypassar” todo o pla-
nejamento e sair escrevendo códigos; isso irá resultar em inúmeras modificações. Ou 
ainda, apostar em uma única tecnologia e nela insistir sem obter os resultados esperados.
É óbvio que muitos dos aspectos aqui citados estão vinculados também à gestão de desen-
volvimento de um software, mas não podíamos deixar de citá-las, já que afeta diretamente 
a engenharia de requisitos.
É importante lembrar que não existe uma fórmula mágica para se gerir uma equipe de 
desenvolvimento, pois tanto o perfil dos desenvolvedores quanto do gerente de projeto 
ou até mesmo dos usuários ou da T.I. como um todo devem ser coerentes e ajustados à 
organização, seus objetivos e metas.
Explore o antigo (e ao mesmo tempo recente) artigo Erros clássicos. 
Disponível em: https://goo.gl/L6qG3D 
E já que estamos falando em prejuízos, que tal pensarmos um pouco nos custos de desen-
volvimento – claro, enfatizando a engenharia de requisitos. Seriam eles altos ou justificáveis? 
Podem ser menores?
À primeira vista, os custos da engenharia de requisitos devem ser altos, já que os prejuízos 
são enormes. Mas não! Na verdade, das etapas de desenvolvimento de um software, os 
custos da identificação e da definição dos requisitos são os menores de todo o processo.
E isso apesar de que normalmente a quantidade de stakeholders envolvidos no pro-
jeto e suas respectivas remunerações serem altas (e usualmente maiores) que as dos 
programadores de sistemas – independente da linguagem.
E não é que os maiores custos (cerca de 50%) estão exatamente relacionados com a 
fase de implementação? Pois é!
Exige-se menos dos engenheiros de software (devido ao custo, gastando-se mais com 
os programadores) e gasta-se mais na manutenção (devido ao custo menor dos mesmos 
programadores). É um paradoxo, não é mesmo?
10
11
Em seu artigo na DevMedia, Oliveira tece diversas considerações relativas aos custos 
por etapa de desenvolvimento de software. Ao analisarmos os dados por ele apresentados, 
nota-se que o menor custo é na análise de requisitos e o maior é na manutenção. Por outro 
lado, 55% dos erros são introduzidos exatamente na fase de análise de requisitos.
Tabela 2 – Custos por Etapa de Desenvolvimento de Software
% do Custo de 
Desenvolvimento
% dos Erros dos 
Introduzidos
% dos Erros 
Encontrados
Custo Relativo 
de CorreçãoAnálise de Requisitos 5 55 18 1
Projeto 25 30 10 1-1.5
Codificação e Teste 
de Unidade 50
Teste 10 10 50 01/mai
Validação e 
Documentação 10
Manutenção 5 22 10-100
Fonte: Adaptação de https://goo.gl/TfRDLN
A satisfação dos usuários, como era de se esperar, é baixa. Para confirmar o que citamos 
anteriormente, o mesmo autor apresenta o gráfico de atendimento que um software faz ao 
usuário final.
Veja que apenas 16% dos projetos são considerados concluídos com sucesso. Quase 
o dobro (31%) são considerados fracassados.
Distribuição da Conclusão de Projetos
Fracasso;
31,10%
Sucesso;
16,20%
Problemáticos;
52,70%
Gráfico 1: Distribuição da Conclusão de Projetos
Fonte: Adaptação de https://goo.gl/at7sNh
11
UNIDADE 
Engenharia de Requisitos
Outra informação alarmante – para não criticarmos apenas os engenheiros de software 
– é que juntos requisitos incompletos e falta de envolvimento dos usuários somam mais de 
25% dos fatores críticos de sucesso de um projeto, enquanto que somadas a mudança de 
requisitos e a falta de planejamento somam quase 17%, conforme se observa na tabela 3.
Tabela 3 – Fatores Críticos de Sucesso de Projeto
Fatores Críticos %
Requisitos incopletos 13,1
Faltade envolvimento do usuário 12,4
Falta de recursos 10,6
Expectativas irreais 9,9
Falta de apoio executivo 9,3
Mudança de requisitos e especificações 8,7
Falta de planejamento 8,1
Sistema não mais necessário 7,5
Fonte: Adaptação de https://goo.gl/XY6k6F
Como se observou, a adequada especificação dos requisitos em projetos de desen-
volvimento de software é de suma importância como fator crítico para seu sucesso. 
Por esse motivo, é necessário introduzirmos um aspecto fundamental da engenharia de 
requisitos: a comunicação.
Sim, a comunicação, embora pareça ser óbvio que esta é a grande causadora de 
desentendimentos na coleta de dados do processo de engenharia de requisitos, pouco 
dela se fala. A figura de conhecido personagem das estórias em quadrinhos reflete, com 
bom humor, os equívocos de uma comunicação.
Equívoco de entendimento pelo humor: https://goo.gl/xEZyox
É normal nos comunicarmos de modo informal no dia a dia e as eventuais divergên-
cias que podem acontecer geralmente são esclarecidas rapidamente. Geralmente, mas 
nem sempre.
O problema é que ao definirmos uma necessidade – um requisito – de um software, 
isso pode se tornar uma verdade absoluta se não houver um entendimento do processo 
pelas partes envolvidas. Como consequência, uma definição ou um conceito mal 
interpretado ou mal escrito poderá desencadear uma série de equívocos em cascata em 
um projeto de software.
Equívoco de entendimento pela interpretação: https://goo.gl/VepLjC
A comunicação, verbal ou não, é fundamental no processo de coleta de requisitos e 
pode trazer consequências desastrosas. 
12
13
Sabe-se que cerca de 80% do tempo nas organizações é gasto com comunicação 
ou o processamento de informações e que esta deveria ser o centro de uma análise 
organizacional, apesar de que sua importância varia conforme a empresa.
Sabe-se também que a comunicação depende muito de diversas variáveis e fatores 
(inclusive pessoais) que envolvem o emissor, o receptor e as circunstâncias – ou objetivos 
da comunicação.
Todos os fatores e variáveis, somados à rotina diária dos stakeholders e colaboradores 
na organização, fatalmente, trarão problemas (ou sintomas na melhor das hipóteses) de 
sobrecarga, distorção ou omissão de informações.
Lógico que o processo de comunicação em uma organização (qualquer que seja 
ela – pública, privada ou familiar) é complexo. Não vamos entrar no mérito do porte, 
tipo ou tamanho de uma empresa, já que este não é nosso objetivo. Mas, com toda a 
certeza, podemos afirmar que devido essa complexidade, a comunicação afeta o (bom) 
funcionamento de seus processos.
Um software poderia (deveria) auxiliar nesse processo de comunicação, e, apesar 
de tudo, muitas vezes, é ele que acaba não tendo utilidade devido exatamente a esse 
processo comunicacional ineficiente.
Conforme Hall (2004): “As comunicações, nas organizações, devem proporcionar 
informações precisas, com as implicações emocionais apropriadas, para todos os 
membros que precisam do conteúdo da comunicação. Isso supõe que nem um excesso 
ou uma falta de informações se encontra no sistema, estando claro, desde o início, quem 
pode utilizar aquilo que está disponível”.
Para Ruggiero (2002), a qualidade da comunicação é derivada de alguns pontos 
considerados muito importantes, tais como a prioridade dada à comunicação, descen-
tralização de informações, proatividade dos colaboradores, autenticidade da informação, 
velocidade da informação, competências básicas para saber ouvir ou falar, equilíbrio en-
tre tecnologia e relações interpessoais, características individuais ou melhorias na apren-
dizagem sobre os processos – inclusive o de comunicação.
Assim sendo, e dadas as mudanças que ocorrem no ambiente empresarial e nas neces-
sidades de informação visando as decisões nos processos, a comunicação é fundamental 
nas atividades de coleta de requisitos para que estejam claros e facilitem ao processo de 
desenvolvimento do software e atendam, também, a organização com qualidade.
Conforme Ruggiero (2002), a qualidade na comunicação das organizações deve con-
siderar que os processos muitas vezes podem ser vistos como individuais devido as di-
ferenças naturais nas referências, nível de experiência, amplitude de interesses, grau de 
motivação e de pessoa para pessoa.
13
UNIDADE 
Engenharia de Requisitos
As especificações dos requisitos, na engenharia de software, são consideradas o 
“calcanhar de Aquiles” do processo de software, não só porque as necessidades dos 
usuários podem (e devem) mudar conforme muda o cenário econômico macro e micro, 
como também pelos fatos de que a concorrência, a globalização e as tecnologias da 
informação e da comunicação muito têm contribuído para que a gestão empresarial 
esteja sempre em busca de melhorias estratégicas. Surgem então as dificuldades na 
definição dos requisitos.
Parafraseando Steve Jobs, “As pessoas não sabem o que querem, até mostrarmos a 
elas”. Mas não é bem assim. O fato é que, na verdade, diversas são as dificuldades que 
podem surgir na obtenção dos requisitos de um software. Cada qual pode ter seu grau 
de importância, frequência ou consequência.
Naturalmente, a comunicação é a principal causadora de dificuldades no entendimento 
dos requisitos devido à ambiguidade de nossa linguagem no dia a dia.
Além disso, há os ruídos – que são todos os elementos que perturbam ou dificultam a 
compreensão entre o emissor e o(s) receptor(es) – e podem ser um barulho ou uma voz muito 
alta ou baixa. Outros elementos como rabiscos, borrões, má caligrafia ou erros ortográficos 
ou de pontuação também afetam uma boa comunicação na engenharia de requisitos.
Os principais aspectos que podem gerar falhas são:
• A apatia – ou incapacidade de se colocar no lugar do outro, compreendendo o nível 
sociocultural e o temperamento;
• A insegurança, já que profissionais inseguros tendem a se comportar de forma 
agressiva, podendo causar medo ou intimidação;
• A impaciência é outro inimigo, pois torna difícil ensinar e aprender, não sobrando 
espaço para observar e trocar informações.
Outro fator é a incoerência, ou seja, falar, defender uma ideia, valores ou posição e 
não seguir seu próprio discurso, levando a desconfiança e descrédito.
A prolixidade torna cansativo e entediante uma conversa ou texto, é um dos maiores 
pecados da comunicação, já que ocorre a falta de objetividade.
A ignorância ou falta de conhecimento, sabedoria ou instrução sobre um determinado 
assunto também interfere no processo de comunicação, deixando-o truncado, tanto 
quanto a arrogância – ou falta de humildade, alguém que não deseja ouvir, aprender algo 
que não saiba.
E pior que a falta de informação a ser fornecida e a suposição de se conhecer algo, é 
explicar errado seu funcionamento.
Certamente não seesgota esse assunto, até porque cada caso tem suas peculiaridades 
e cada situação deve ser tratada de acordo com a experiência e vivência das partes 
envolvidas, sejam usuários diretos, indiretos ou desenvolvedores.
É importante ter em mente que todo e qualquer trabalho que envolve conhecimento 
e relações interpessoais requer esforços e atenção redobrados para a consecução dos 
objetivos pretendidos. Mas não sem dificuldades – e muitas.
14
15
Por todos esses motivos, manter a sintonia entre os envolvidos é igualmente difícil. 
As partes interessadas nem sempre definem (ou se responsabilizam) as prioridades, 
como também, muitas vezes, divergem sobre elas.
A definição da importância deve ser facilitada pelo gerente de projeto, ainda que sejam 
centenas os requisitos a atender.
Outra dificuldade é que muitas vezes os usuários não conseguem definir claramente 
seus anseios, ou por não estar devidamente esclarecidos, ou por desconhecerem detalhes 
do processo. Nesse caso, o trabalho do desenvolvedor é ainda mais árduo porque é sua 
responsabilidade transformar as incertezas em requisitos específicos.
Outro ponto que gera dificuldade é que às vezes, por falta de tempo, políticas, 
diferenças hierárquicas, técnicas ou culturais, ou ainda permissão, os desenvolvedores 
não conseguem interagir com uma ou mais partes de interesse no projeto, sejam de 
dentro ou de fora da organização.
Outras situações podem acontecer, quando, por exemplo, uma parte envolvida no 
projeto não será por ele beneficiada ou ainda pior, quando será beneficiada, mas não 
quer se envolver por qualquer motivo.
Comum também é a resistência à mudança, pois geralmente um projeto de software 
traz consigo alguma alteração no processo, gerando desconforto ou insegurança nos 
usuários, já que é natural a maioria ficar em sua “zona de conforto”. E se um projeto 
for iniciado sem a devida comunicação, então o nível de colaboração será no mínimo 
menor. Mas há casos em que o usuário declaradamente se torna um opositor ferrenho 
ao projeto, prejudicando-o sobremaneira.
Há ainda as situações que provocam inconsistência nos requisitos, pois com a evolu-
ção da atividade na sua definição, um mesmo assunto pode ter mais de uma definição 
conceitual, sejam em termos semelhantes usados com finalidades iguais ou os mesmos 
termos sendo aplicados com finalidades diferentes ou até divergentes. 
Outras situações, mais comuns até acontecem, quando por exemplo há modificações 
nos requisitos iniciais ao longo do projeto e estas são consideradas importantes e plausí-
veis de ocorrerem, afetando outras especificações ou outras partes do projeto.
Mas, também, há casos em que mais de um desenvolvedor especificou os requisitos, 
podendo gerar inconsistências ou erros graves.
Não menos importante, as indefinições ou indecisões provocadas pelas dificuldades dos 
usuários em deixar claro exatamente o que quer, ou ainda, de expressar adequadamente 
o que necessita são bastante comuns, independentemente de sua experiência ou do 
desenvolvedor. Isso pode ocorrer, por exemplo, quando há um volume muito grande 
dessas necessidades, ou quando os usuários estão formulando mudanças na execução 
do processo alvo do projeto.
Essas situações aumentam ainda mais as dificuldades na determinação dos requisitos 
de um software. 
15
UNIDADE 
Engenharia de Requisitos
É bastante comum também no decorrer de um projeto, que tanto usuários como desen-
volvedores supõem que a outra parte tem conhecimento de uma determinada situação, e, 
assim, não se preocupam em expressá-la de forma adequada, até que ocorre um problema 
decorrente dessa situação. São as chamadas “necessidades implícitas”, que seriam “des-
necessárias serem ditas”.
Outros problemas estão relacionados com os conflitos gerados quando, por exem-
plo, um projeto com muitas partes interessadas em seus resultados acaba por provocar 
muitas vezes, dificuldades em atender simultaneamente requisitos de origens diferentes, 
seja devido a incompatibilidade ou inconsistência de solução, seja por demandas que não 
estão no escopo do projeto, ou ainda, ausência (comum) de sintonia entre as partes e 
seus processos. 
Por mais estranho que possa parecer, há também a situação causada quando uma 
ou mais partes envolvidas não dominam o negócio ou assunto. Embora possa ser uma 
situação incomum ou passageira, pode acontecer quando há mudanças de gestor ou 
quando a parte interessada delega, propositalmente, para a área da tecnologia da 
informação ou para terceiros, a definição de requisitos relativos a seu processo.
E se, por algum motivo qualquer, uma (ou mais) parte não dá a devida atenção ou não 
se preocupa com os requisitos, as dificuldades e os prejuízos daí derivados podem ser 
altos. Isso é mais comum do que se pensa. As partes não assimilam o grau de importân-
cia da definição dos requisitos por serem elas pouco objetivas ou por entender que não 
é necessário revisar.
É comum também problemas decorrentes quando, por exemplo, uma parte interessada 
se empolga com as possíveis soluções e devaneia querendo incorporar até mesmo coisas 
que não pertencem ao escopo do projeto. Isso se agrava ainda mais quando não há 
restrição orçamentária – por exemplo, com usuários internos que compartilham o custo 
da tecnologia da informação.
Por fim, a dificuldade mais genérica é aquela relacionada com as modificações, pois 
também é bastante comum a regularidade com que se solicitam alterações nos requisi-
tos. Algumas são determinadas pelos organismos regulatórios, por mudança de gestor, 
outras pela necessidade de se estabelecer novas estratégias devido a sazonalidade ou 
mudança no mercado, mas a maioria, lamentavelmente, ocorre devido as falhas nas 
atividades de coleta de dados.
Pois então, é para evitar esses tropeços que devemos tratar adequadamente os requi-
sitos, que, de acordo com a Wikipedia, “...é a definição documentada de uma proprie-
dade ou comportamento que um produto ou serviço deve atender”.
E conforme Aurélio, é a condição necessária para a obtenção de um certo objetivo, 
ou para o preenchimento de certo fim.
Porém, segundo Sommerville, o termo não é usado de forma consistente, e pode, às 
vezes, ser definido apenas como uma declaração abstrata e generalizada de um serviço ou de 
uma restrição do software, e outras vezes como sendo uma declaração detalhada e formal. 
Mas a amplitude e a complexidade de um software podem explicar essa ambiguidade.
16
17
Para Pressman (2011), requisito é a condição necessária para se obter um objetivo 
ou para se concluir um certo objetivo.
E, com esses, pode-se determinar critérios para se verificar e avaliar a qualidade de um 
software concluído.
A ISO/IEC/IEEE 24765 caracteriza requisito como sendo:
• Condição necessária para que um usuário possa solucionar um problema ou con-
seguir atingir um objetivo;
• Capacidade a ser obtida por um sistema ou parte dele, para atender a uma especi-
ficação, a um padrão ou a uma determinação documental;
• Representação documental para atender a uma determinada condição.
Podemos inferir que há 3 momentos: 
• primeiro: ao se pensar numa solução de um problema; 
• segundo: na possibilidade de ter-se o resultado desejado; 
• terceiro: de se ter formalmente representada a solução.
Assim, a engenharia de requisitos, para Pressman (2011), fornece mecanismos apro-
priados para entendermos o que os usuários querem que um software faça.
E esses mecanismos devem permitir:
• analisar as necessidades;
• avaliar a viabilidade de atender;
• negociar uma possível solução razoável;
• especificar claramente a solução;
• validar a especificação; 
• gerenciar as especificações conforme são operacionalizadas.
A engenharia de requisitos, então, é base para o projeto e para sua constru-
ção e deve possibilitar:
• examinar o contexto do software a desenvolver;
• compreender as especificidades para atender o projeto e a implementação;
• entender quais as prioridades e a ordem com que as atividades devem ser feitas;• compreender as informações, funções e comportamentos que podem afetar o pro-
cesso de desenvolvimento do projeto.
De acordo com Vazques (2016), a engenharia de requisitos refere-se a aquisição e 
aplicação de conhecimento para criar, aperfeiçoar e implementar sistemas de informação.
Ela determina o processo da definição dos requisitos como sendo um processo onde 
o que será feito deve ser extraído, modelado e analisado. Esse processo deve trabalhar 
com diversos pontos de vista e combinar métodos, ferramentas e pessoas.
O resultado é um documento produzido com um modelo dos requisitos.
17
UNIDADE 
Engenharia de Requisitos
A engenharia de requisitos é de vital importância porque visa evitar, eliminar ou reduzir:
• atrasos em cronogramas;
• custos adicionais decorrentes de atrasos;
• retrabalhos cuja origem é a falta de entendimento do processo;
• volume de erros ou defeitos no software;
• entrega de software que não atenda às necessidades da automação dos usuários;
• defeitos detectados depois da elaboração do projeto e originados por falhas nos 
requisitos são os mais difíceis de se eliminar.
Mas, a engenharia de requisitos tem algumas dificuldades ainda maiores. Na 
prática, ela é:
• esquecida pelos usuários;
• negligenciada pelo mercado;
• desacreditada pelos desenvolvedores; 
• relegada a segundo plano no meio acadêmico.
O pressuposto básico da engenharia de requisitos, mantendo ou não a mesma equipe 
de projeto, é que seja possível encontrar, identificar, validar, especificar, criar, estruturar 
e manter um conhecimento sobre um processo e um software.
Concluindo, a engenharia de requisitos deve facilitar os trabalhos de levantamento de 
dados que visem o desenvolvimento de um projeto de software. 
A aplicação adequada de suas técnicas, acompanhada de um bom processo (ou 
paradigma) de software, facilitam à equipe de projeto mecanismos adicionais de 
controle e de qualidade no projeto e no processo de desenvolvimento, garantindo assim, 
a qualidade do produto.
18
19
Material Complementar
Indicações para saber mais sobre os assuntos abordados nesta Unidade:
 Sites
Alguns dos mais famosos erros de softwares da história
https://goo.gl/2ZuQEK
Erros clássicos
https://goo.gl/eGd5Vr
Estado actual de la investigación en requisitos no funcionales
https://goo.gl/j6F16Q
Falhas em software provocaram prejuízos de US$ 1.1 trilhão em 2016
https://goo.gl/bjU3t6
Falha na comunicação
https://goo.gl/EcV1FU
Falhas na comunicação
https://goo.gl/fyS4uo
Engenharia de Software - Introdução à Engenharia de Requisitos
https://goo.gl/SUCfw8
Porque os softwares falham
https://goo.gl/oPQ8oH
Requisitos, modelagem e UML
https://goo.gl/cFuBnT
5 principais desafios da comunicação interna
https://goo.gl/Q7Gvoa
10 falhas de software que marcaram a história
https://goo.gl/tta5n6
 Livros
Organizações: estruturas, processos e resultados
HALL, Richard H. Organizações: estruturas, processos e resultados. 8. ed. São Paulo: 
Pearson, 2004.
Gerenciamento de requisitos
KERR, Eduardo Santos. Gerenciamento de requisitos. São Paulo: Pearson, 2015. (e-book)
Engenharia de requisitos
VAZQUEZ, Carlos Eduardo & SIMÕES, Guilherme Siqueira. Engenharia de requisitos: 
software orientado ao negócio. Rios de Janeiro: Brasport, 2016.
19
UNIDADE 
Engenharia de Requisitos
 Leitura
Pontos cegos em engenharia de requisitos
KANJIRATH, Nandita. Pontos cegos em engenharia de requisitos. Biblioteca virtual 
PMI, 2011.
https://goo.gl/ZSzzSJ
Revista Eletrônica de Administração
RUGGIERO (2002), apud SILVA, Tatiane Euzébio R. & GÓIS Italuelmo da Rocha in 
Revista Eletrônica de Administração – Vol. 08 – Edição 15 – julho-dezembro – 2009
https://goo.gl/d8n2nh
SRS Template IEEE
https://goo.gl/NwixS4
SRS Sample
https://goo.gl/rTr3Vv
SRS Template IEEE
https://goo.gl/NwixS4
20
21
Referências
FOGGETTI Cristiano, ORG. Gestão ágil de projetos. São Paulo, Pearson, 2015. (e-book).
PAGE-JONES, Meilir. Fundamentos do desenho orientado a objetos comUML. São 
Paulo: Makron Books, 2001. (e-book).
PFLEEGER, S. L. Engenharia de software - teoria e prática. 2. ed. São Paulo: Pearson/
Prentice Hall, 2004. (e-book).
PRESSMAN, R. S. Engenharia de software. 7. ed. Rio de Janeiro: McGraw-Hill do 
Brasil, 2011. (e-book).
SCHACH, S. R. Engenharia de software: os paradigmas clássicos & orientado a 
objetos. 7. ed. São Paulo: Bookman, 2009.
SOMMERVILLE, I. Engenharia de software. 9. ed. São Paulo: Pearson, 2001. (e-book).
VAZQUEZ, Carlos E; SIMÕES, Guilherme S. Engenharia de requisitos. São Paulo: 
Brasport, 2016.
WAZLAWICK, Raul Sidnei. Análise e design orientados a objetos para sistemas de 
informação: modelagem com UML, OCL e IFML. 3. ed. Rio de Janeiro: Campus, 2015.
21