26 - Engenharia de Software I - SAGAH

Prévia do material em texto

Conceitos da engenharia de software
APRESENTAÇÃO
A engenharia de software tem como objetivo, a aplicação de metodologias no processo de 
desenvolvimento, visando a promoção da qualidade, aumento da produtividade e redução dos 
custos. A criação de software foi subestimada e realizada sem nenhuma metodologia, gerando 
erros em sistemas, como: problemas de cálculos, perdas financeiras e de tempo. Nesse período, 
podemos dizer que houve a Crise do Software. Com isso, em 1967 a OTAN (Organização do 
Tratado do Atlântico Norte) designou o termo Engenharia de Software para adequar o processo 
de desenvolvimento de software com metodologias, já utilizadas em outras engenharias. Uma 
série de metodologias e técnicas passaram a ser utilizadas antes, durante e depois da criação 
dos softwares. Dados históricos apontam que houve uma diminuição brutal nos problemas no 
desenvolvimento de softwares após a adoção dessas metodologias, fazendo com que a indústria 
de software pudesse entregar sistemas com maior qualidade, em menos tempo e com custos 
reduzidos de manutenção. 
Nesta Unidade de Aprendizagem, você irá adquirir conhecimentos fundamentais para avançar 
no aprendizado sobre Engenharia de Software. Iremos abordar, inicialmente, conceitos básicos 
sobre o que é Engenharia de Software, sua história e importância na indústria.
Bons estudos.
Ao final desta Unidade de Aprendizagem, você deve apresentar os seguintes aprendizados:
Reconhecer o histórico e conceitos fundamentais da Engenharia de Software.•
Analisar a evolução do desenvolvimento de software.•
Identificar a importância da Engenharia de Software.•
DESAFIO
Paulo é gestor de uma empresa de tecnologia e costuma viajar com frequência para atender 
clientes. Mediante uma curta fase de ociosidade de sua equipe, o empresário resolveu aproveitar 
para solicitar o desenvolvimento de um software que integrasse a sua agenda e a compra 
1
automática de suas passagens aéreas. No segundo mês de uso do software, ao chegar no 
aeroporto e tentar fazer o check-in, Paulo percebeu que a passagem havia sido comprada para 
Fortaleza ao invés de Salvador.
Analise esse cenário e associe o erro do software com o conceito de Engenharia de Software.
INFOGRÁFICO
A Engenharia de Software utiliza os princípios da engenharia para obter softwares de maneira 
econômica e confiável, o que pode garantir inúmeras vantagens para o processo de criação. 
Acompanhe, no infográfico a seguir, as características e vantagens da engenharia de software.
2
CONTEÚDO DO LIVRO
A engenharia de software foi criada para tentar solucionar os problemas da "Crise de Software". 
Ela abrange uma série de metodologias que guiam todo o processo de criação de software, 
garantindo a alta qualidade, respeito aos prazos e custos do projeto.
Acompanhe a leitura do capítulo Conceitos da Engenharia de Software, da obra Engenharia de 
Software e saiba mais sobre os conceitos básicos de engenharia, bem como sua história e 
importância na indústria.
Boa leitura!
3
Conceitos da Engenharia 
de Software
Objetivos de aprendizagem
Ao final deste texto, você deve apresentar os seguintes aprendizados:
 � Reconhecer o histórico e os conceitos fundamentais da Engenharia
de Software.
 � Analisar a evolução do desenvolvimento de software.
 � Identificar a importância da Engenharia de Software.
Introdução
Por muitos anos a Engenharia de Software foi utilizada com o objetivo 
de criar software de qualidade dentro dos custos e dos prazos estimados 
pelo cliente, evitando desperdícios de tempo, esforços, direções erradas e 
atrasos. A criação de software foi subestimada e realizada sem nenhuma 
metodologia, gerando erros em sistemas, como problemas de cálculos 
e perdas financeiras e de tempo. Nesse período, podemos dizer 
que houve a crise do software. Com isso, em 1967, a Organização do 
Tratado do Atlântico Norte (OTAN) designou o termo Engenharia de 
Software para adequar o processo de desenvolvimento de software com 
metodologias já utilizadas em outras Engenharias. Uma série de 
metodologias e técnicas passaram a ser utilizadas antes, durante e 
depois da criação de software. Dados históricos apontam que houve 
uma diminuição brutal nos problemas em software após a adoção 
dessas metodologias, fazendo com que a indústria de software 
pudesse entregar sistemas com maior qualidade, em menos tempo e 
com custos reduzidos de manutenção. 
Neste capítulo, você irá adquirir conhecimentos fundamentais 
para avançar no aprendizado sobre Engenharia de Software. Iremos 
abordar inicialmente conceitos básicos sobre o que é essa Engenharia, 
sua história e a importância na indústria.
4
Histórico e conceitos fundamentais da 
Engenharia de Software
A Engenharia de Software é uma disciplina da Engenharia, mais especifica-
mente da Ciência da Computação, que estuda todos os processos envolvidos 
no desenvolvimento de software, uma atividade complexa que envolve a rea-
lização conjunta de diversas atividades distintas, as quais exigem habilidades 
multidisciplinares e, por consequência, trabalho colaborativo de um grande 
grupo de profissionais (SOMMERVILLE, 2011).
A Engenharia de Software é uma área de grande importância, uma vez 
que as pessoas e a sociedade como um todo estão a cada dia mais dependentes 
de software. Por isso, faz-se necessário que seja produzido software mais 
confiável e de forma mais rápida a cada dia. Além disso, para as empresas 
desenvolvedoras de sistemas, geralmente é mais barato, a longo prazo, usar 
métodos e técnicas da Engenharia de Software para o desenvolvimento de 
sistemas do que desenvolver os sistemas sem documentação e estruturação, 
uma vez que, desta forma, é desestruturada e dificultada a manutenção do 
software (SOMMERVILLE, 2011).
Contudo, esta disciplina nem sempre foi alvo de atenção dos profissionais 
de Tecnologia da Informação. Por muito tempo, o desenvolvimento de sistemas 
foi realizado sem atenção a processos, metodologias e estruturas organizacio-
nais no que diz respeito a tarefas, atividades e responsabilidades. Essa falta 
de controle sobre os processos fez com que, muitas vezes, o software fosse 
entregue aos clientes sem a devida qualidade e com grande número de erros, 
como problemas de cálculos e perdas financeiras e de tempo. Nesse período, 
podemos dizer que houve a crise do software. Com isso, em 1967, a OTAN 
designou o termo Engenharia de Software para adequar o processo de desen-
volvimento de software com metodologias já utilizadas em outras engenharias.
A partir desse momento, os profissionais e as empresas de Tecnologia 
da Informação passaram a preocupar-se mais com os diversos setores que 
envolvem o desenvolvimento de sistemas, como análise de requisitos, análise 
de sistemas, desenvolvimento, testes e implantação. Neste contexto, derivaram 
diversas metodologias, métodos e processos para auxiliar e guiar o trabalho 
de cada um desses segmentos. 
 da Engenharia de SoftwareConceitos
5
Evolução do desenvolvimento de software
O desenvolvimento de software, bem como outras Ciências, empregou diversas 
mudanças e adaptações para melhorar, facilitar e adaptar-se ao cotidiano dos 
profissionais que realizam esse trabalho. As principais evoluções no desen-
volvimento de software podem ser classificadas em dois grandes grupos: 
mudanças processuais e mudanças tecnológicas.
Mudanças tecnológicas
Embora atualmente, quando se fala em software, sejamos remetidos a lembrar 
de computadores modernos, smartphones, tablets, etc., o desenvolvimento de 
software começou muito antes desses dispositivos serem criados, sendo pro-
gramado por volta de 1725, em cartões perfurados. Posteriormente, surgiram 
as primeiras linguagens de programação, tais quais as que existem hoje, sendo 
elas FORTRAN (1955), List Processor (LISP) e Common Business Oriented 
Language (COBOL). Posteriormente, surgiram linguagens de programação de 
alto nível, isto é, que se aproximam mais da linguagem humana, são exemplos: 
Java, JavaScript,Visual Basic, Object Pascal e PHP (PACIEVITCH, 2017).
Junto com as linguagens de programação, foram sendo criados paradigmas 
para o desenvolvimento de sistemas. Um paradigma nada mais é do que a 
forma como um sistema é construído e seu desenvolvimento é organizado. 
Os paradigmas mais conhecidos são o paradigma estruturado e o paradigma 
orientado a objetos, sendo o paradigma orientado a objetos o mais utilizado 
atualmente. A programação orientada a objetos é um paradigma em que o 
software é construído considerando que tudo o que é inserido no programa é um 
objeto e que esse objeto pertence a uma classe e tem características (atributos) 
específicas sobre as quais podem ser feitas ações (métodos). Por outro lado, 
um princípio básico da programação estruturada é que um programa pode 
ser dividido em três partes que se interligam, sendo elas sequência, seleção e 
iteração (ABÍLIO, 2017). Na sequência, o código do programa é criado para 
ser executado de forma sequencial, seguindo estritamente a ordem na qual 
foi programado. Na seleção, o programa encontra locais onde pode seguir um 
ou mais caminhos distintos. Na interação, é permitido ao programa executar 
diversas vezes o mesmo trecho de código. 
Conceitos da Engenharia de Software
6
 � Ao programar uma calculadora, quando cria-se um programa e o único fluxo
que este pode seguir é receber dois números, somar esses números e mostrar o 
resultado, faz-se um programa utilizando apenas sequência.
 � Quando se insere neste programa a opção de selecionar se deve somar ou subtrair 
os números, se está programando uma seleção.
 � Quando, ao final do cálculo, pergunta-se para o usuário se deseja fazer novamente,
se está programando uma interação.
Mudanças de processo
No desenvolvimento de sistemas, além das mudanças tecnológicas, foram 
ocorrendo mudanças na forma como as empresas se organizam e estruturam 
o trabalho. A forma tradicional de desenvolvimento de sistemas foi a primeira
a ser criada, empregando o ciclo de vida em estrutura de cascata (1970), na
qual as etapas são executadas de forma sequencial, sem que seja possível
retornar de uma etapa posterior para uma etapa anterior.
Figura 1. Modelo Cascata 
Fonte: Sommerville (2011, p. 20).
De�nição
de requisitos
Projeto de sistema
e software
Implentação
e teste unitário
Integração e
teste de sistema
Operação e
manutenção
Conceitos da Engenharia de Software
7
Posteriormente, falou-se em desenvolvimento iterativo e incremental. 
Nesse modelo, implementa-se pequenas partes entregáveis do software para 
que o cliente tenha um feedback mais rápido sobre o produto que está sendo 
desenvolvimento.
Figura 2. Entrega Incremental.
Fonte: Sommerville (2011, p. 31).
De�nição esboço
de requisitos
Atribuir requisitos
aos incrementos
Validar
incrementos
Integrar
incrementos
Implantar
incrementos
Validar
sistema
Sistema
incompleto?
Sistema
completo?
Sistema
�nal
Projetar arquitetura
de sistema
Desenvolver incrementos
de sistema
O modelo em espiral se assemelha muito ao modelo iterativo e incremen-
tal, uma vez que ele também considera pequenas entregas de software e a 
execução de todas as etapas espiralmente (várias vezes). Contudo, o ciclo de 
vida espiral considera a presença explícita da análise de riscos como uma das 
etapas de cada iteração. Nesse processo em espiral, o ciclo de vida do software 
é representado como uma espiral em que a volta na espiral representa uma fase 
do processo de software, sendo que a volta mais interna pode preocupar-se 
com a viabilidade do sistema, o ciclo seguinte, com definição de requisitos, 
o seguinte, com o projeto do sistema, e assim por diante.
Conceitos da Engenharia de Software
8
Figura 3. Modelo Espiral.
Fonte: Sommerville (2011, p. 33).
Determinar objetivos,
alternativas e restrições
Análise
de riscos
Protótipo
operacionalProtótipo 3
Protótipo 2
Protó-
tipo 1
Simulações, modelos, benchmarks
Requisitos
de S/W Projeto de
produto Projeto 
detalhado
Código
Teste unitário
Teste de
integraçãoTeste de
aceitação
Projeto 
V&V
Operação
Validação 
de requisitos
Conceito de 
operação
Plano de requisitos
Plano de ciclo de vida
Plano de 
desenvolvimento
Planejar próxima fase
Plano de integração 
e testes
Análise
de riscos
Análise
de riscos
Análise
de riscos
Avalir alternativas,
identi�car, resolver riscos
Desenvolver e veri�car próximo
nível do produto
Revisão
No ano de 2001, um grupo de profissionais de tecnologia da informação 
lançou um documento chamado Manifesto Ágil para o Desenvolvimento de 
Sistemas. Deste então popularizaram-se os métodos ágeis de desenvolvimento 
de sistemas, sendo os mais conhecidos o método Scrun e o método XP. Todos 
eles têm em comum a aplicação dos valores propostos pelo Manifesto Ágil 
para o Desenvolvimento de Sistemas, sendo eles: indivíduos e interações são 
mais que processos e ferramentas, software em funcionamento é mais que 
documentação abrangente, colaboração com o cliente é mais que negociação 
de contratos e respostas a mudanças são mais que seguir um plano (BECK 
et al., 2001).
Todos esses ciclos de vida, somados aos Métodos Ágeis de Desenvolvimento 
de Sistemas, apresentaram estrutura e organização maiores para o processo de 
desenvolvimento de sistemas, propiciando melhoria da comunicação entre os 
envolvidos no processo, seja entre os próprios profissionais de Tecnologia da 
Informação ou destes com o cliente. Com a adoção de processos e a atenção às 
evoluções tecnológicas, buscando sempre acompanhar aquilo que o mercado 
Conceitos da Engenharia de Software
9
tem de melhor para oferecer, pode-se atingir maior excelência nos produtos 
entregues e atender melhor às necessidades do cliente.
Importância da Engenharia de Software
Conforme supracitado, a Engenharia de Software é uma disciplina de Enge-
nharia cujo foco está em todos os aspectos da produção de software, desde 
os estágios iniciais da especificação do sistema até a sua manutenção, quando 
o sistema já está sendo usado (SOMMERVILLE, 2011). Neste contexto, é
clara a importância fundamental da Engenharia de Software, uma vez que,
se o processo de desenvolvimento de sistemas envolve diversas atividades
distintas e a Engenharia de Software é a disciplina que preocupa-se em estudar 
e monitorar o bom andamento de todas essas atividades e a integração entre
elas, é trivial notar que é baseado na Engenharia de Software o sucesso de
um projeto no que tange a sua organização.
Engenharia de Software envolve planejamento. Planejamento diz respeito 
também a pessoas e cronograma de trabalho. Pessoas porque divide as respon-
sabilidades, de forma individual ou coletiva. Cronograma porque conforme 
o planejamento é que os gestores têm a possibilidade de mensurar o tempo
necessário para o desenvolvimento de cada projeto. Engenharia de Software
envolve também a preocupação com a qualidade do produto. Qualidade, neste
contexto, não se refere apenas à entrega de produtos em funcionamento, mas
também ao atendimento das necessidades do cliente, e, por isso, a área da
Engenharia de Software, que trata de engenharia de requisitos ou análise de
requisitos, tem importância fundamental, na medida em que é por meio dela
que as equipes de desenvolvimento recebem a expectativa do cliente sobre o
produto que está sendo desenvolvido para buscar atendê-la.
Além disso, na fase de desenvolvimento da programação em si, a Enge-
nharia de Software se faz presente, uma vez que a escolha do processo ideal 
irá influenciar diretamente no trabalho cotidiano de todos os envolvidos, 
incluindo a programação. Esse fator ganha relevância ainda maior em times 
que trabalham em horários distintos ou locais geograficamente distribuídos.
Uma vez entregue o software para o cliente, a Engenharia de Software 
tem sua importância revelada no momento de realizar a manutenção nesse 
software. Isto porque, se o sistema tiver sido corretamente planejado, o código 
do sistema tende a estar mais limpo e com menos defeitos. Isso irá causar 
menos manutençãoe facilitar as manutenções que precisam ser realizadas.
Conceitos da Engenharia de Software
10
 da Engenharia de Software Conceitos
ABÍLIO, I. Programação orientada a objetos versus programação estruturada. Disponí-
vel em: <http://www.devmedia.com.br/programacao-orientada-a-objetos-versus-
-programacao-estruturada/32813>. Acesso em: 17 ago. 2017.
BECK, K. et al. Manifesto for agile software development. c2001. Disponível em:<http://
agilemanifesto.org/>. Acesso em: 17 ago. 2017.
PACIEVITCH, Y. História da programação. Disponível em: <http://www.infoescola.com/
informatica/historia-da-programacao>. Acesso em: 17 ago. 2017.
SOMMERVILLE, I. Engenharia de software. 9. ed. São Paulo: Pearson, 2011.
Leituras recomendadas
ENDEAVOR BRASIL. PDCA: a prática levando sua gestão à perfeição. 2015. Disponível 
em: <https://endeavor.org.br/pdca/>. Acesso em: 4 nov. 2016.
PEQUENO, C. N.; CARVALHO, M. G. F.; FONTES, V. M. Redução do consumo de produto 
químico utilizado em uma linha de produção de uma indústria de pneus. 2015. Trabalho 
de Conclusão de Curso (Graduação em Engenharia de Produção)–Universidade do 
Estado do Rio de Janeiro, Rio de Janeiro, 2015.
REY, B. Como fazer um brainstorming eficiente. 2013. Disponível em: <http://exame.abril.
com.br/carreira/como-fazer-um-brainstorming-eficiente/>. Acesso em: 4 nov. 2016.
RODRIGUES, S. Crise: perigo, oportunidade e… papo furado. 2013. Disponível em: 
<http://veja.abril.com.br/blog/sobre-palavras/lendo-a-lenda/crise-perigo-oportu-
nidade-e-papo-furado/>. Acesso em: 4 nov. 2016.
SILVA, M. D. L. et al. Gestão da produção: estudo sobre a gestão da manutenção na 
geração de energia e vapor utilizando caldeiras de uma indústria. In: ENCONTRO 
PARAENSE DE ENGENHARIA DE PRODUÇÃO, 7., 2016, Belém. Anais... Belém: [s.n.], 2016.
SLACK, N. et al. Gerenciamento de operações e de processos: princípios e práticas de 
impacto estratégico. 2. ed. Porto Alegre: Bookman, 2013.
SOUZA, T. de J. F. et al. Proposta de melhoria do processo de uma fábrica de polpas 
por meio da metodologia de análise e solução de problemas. In: ENCONTRO NACIO-
NAL DE ENGENHARIA DE PRODUÇÃO, 35., 2015, Fortaleza. Anais... Fortaleza: ABEPRO, 
2015. Disponível em: <http://www.abepro.org.br/biblioteca/TN_STP_207_228_27341.
pdf>. Acesso em: 4 nov. 2016. 
11
DICA DO PROFESSOR
A Engenharia Software surgiu em 1967 para atender uma necessidade de desenvolvimento de 
softwares de qualidade, a partir de técnicas de engenharia. Veja, na dica do professor a seguir, o 
que foi a crise de software, e acompanhe alguns conceitos e a importância da engenharia de 
software no desenvolvimento de sistemas.
Conteúdo interativo disponível na plataforma de ensino!
EXERCÍCIOS
1) O que foi a Crise de Software?
A) A Crise de Software permitiu o desenvolvimento de software de alta qualidade já que
houve um aumento da concorrência.
B) A Crise de Software foi um termo que surgiu nos anos 70. O termo expressava as
dificuldades do desenvolvimento de software frente ao rápido crescimento da demanda por
software.
C) A Crise de Software foi acompanhada pela Crise de Hardware, que acabou gerando
inúmeros desempregos na década de 70.
D) A Crise de Software foi um termo criado para expressar momentos em que um sistema
apresenta processamento lento.
E) A Crise de Software ocorreu após a Segunda Guerra Mundial quando nenhum software era
vendido.
2) Qual foi o motivo da criação da Engenharia de Software?
12
A) A Engenharia de Software foi criada porque nenhum software disponível antes da
Engenharia de Software conseguia realizar cálculos complexos.
B) A Engenharia de Software foi criada para permitir o uso de elementos da engenharia de
forma controlada e sistemática no desenvolvimento de software. Também para evitar a
Crise de Software.
C) A Engenharia de Software foi criada para acelerar o desenvolvimento de software no
Brasil.
D) A Engenharia de Software foi criada para facilitar o uso de software.
E) A Engenharia de Software foi criada para permitir que a produção de novos sistemas
tivesse mais elementos gráficos e amigáveis ao usuário.
3) Com a introdução da Engenharia de Software, o que mudou no processo de
desenvolvimento de software?
A) Iniciou-se o uso de técnicas e metodologias sistemáticas e controladas já presentes na
engenharia e amplamente utilizadas em outras áreas.
B) A Engenharia de Software melhorou o entendimento do desenvolvedor na leitura dos
requisitos de Software.
C) Aumentaram as vendas de sistemas de software na década de 80.
D) Permitiu que mais pessoas pudessem ter acesso a sistemas de software.
E) Removeu da criação de software as técnicas e metodologias sistemáticas e controladas já
presentes na engenharia e amplamente utilizadas em outras áreas.
13
4) João, dono de uma empresa de software, tem que criar um sistema para um cliente.
Até o momento, o cliente fez apenas uma ligação informando o tipo de software que
ele quer. Qual a primeira coisa que João deve fazer?
A) Ir para a sua empresa e começar a programar imediatamente.
B) Modelar algumas telas do sistema e perguntar ao cliente a sua opinião.
C) Contratar uma grande equipe de desenvolvedores para criar o software o mais rápido
possível.
D) Entender o negócio do cliente e realizar reuniões para mensurar o que ele precisa.
E) Informar para o cliente que em um mês o sistema estará em pleno funcionamento, além de
informar qual será o custo do sistema.
5) Qual é a base dos elementos da Engenharia de Software?
A) Métodos.
B) Ferramentas.
C) Foco na qualidade.
D) Processo.
E) Conceitual.
NA PRÁTICA
14
Você consegue identificar a necessidade do uso de metodologias da Engenharia de Software? 
Para demonstrar essa importância, iremos analisar e comparar duas situações no 
desenvolvimento de sistemas, uma utilizando o método chamado "Go Horse" e a outra a 
Engenharia de Software.
Conteúdo interativo disponível na plataforma de ensino!
Podemos ver que Pedro não utilizou nenhum método para garantir a qualidade do sistema, não 
planejou o desenvolvimento, não testou o produto final e entregou um software de má 
qualidade. Além disso, a correção dos problemas levou quatro vezes mais tempo que o 
planejado inicialmente e custou mais, pois precisou alocar um desenvolvedor durante todo o 
período. Esses problemas poderiam ter sido evitados se Pedro tivesse utilizado métodos 
amplamente abordados na Engenharia de Software.
Conteúdo interativo disponível na plataforma de ensino!
João seguiu etapas bastante utilizadas na Engenharia de Software, essas etapas puderam garantir 
a entrega de um software de qualidade, desempenhando as funções de acordo com o que o 
cliente precisava. O sistema foi entregue dentro do prazo e custo estimados, obtendo lucro no 
final.
Comparando as duas situações...
No exemplo da situação 1, Pedro utilizou o método "Go Horse" onde se passa uma tarefa pouco 
planejada para o desenvolvedor iniciar imediatamente, construindo algo que não vai ao encontro 
das necessidades do cliente.
Na situação 2, João utilizou etapas da Engenharia de Software para estruturar o 
desenvolvimento, tentando garantir um produto de qualidade, com custo e tempo adequados. Na 
Engenharia de Software encontramos diversos modelos, técnicas e análises, além das fases 
demonstradas neste exemplo.
SAIBA MAIS
Para ampliar o seu conhecimento a respeito desse assunto, veja abaixo as sugestões do 
15
professor:
No vídeo a seguir, você poderá saber mais sobre a importancia da Engenharia de 
Software, bem como conhecer alguns modelos de processos e técnicas, o desenvolvimento 
ágil e a gestão de projetos.
Conteúdo interativo disponível na plataforma de ensino!
O termo Engenharia de software tornou-se conhecido após uma conferência em 1968, com 
a discussão das dificuldades da projeção de sistemas complexos. Veja, a seguir, uma breve 
história da Engenharia de Software.
Conteúdo interativo disponível na plataforma de ensino!
Confira uma introdução aos fundamentos teóricosda engenharia de software e os aspectos 
mais práticos do ciclo de vida do software, na obra Engenharia de Software: Os 
Paradigmas Clássico & Orientado a Objetos.
No livro Engenharia de Software: Uma abordagem Profissional, você poderá saber mais 
sobre a segurança de software e os desafios específicos ao desenvolvimento para aplicativos 
móveis.
16
Fundamentos da engenharia de 
requisitos
APRESENTAÇÃO
Você já percebeu como a vida de todos é rodeada de produtos de software, mesmo que poucas 
pessoas se deem conta disto? Utilizamos smartphones diariamente para ouvir música, assistir 
filmes, jogar, chamar uma condução, pedir uma pizza, pagar uma conta ou fazer uma reserva de 
viagem. Isso sem falar do bate-papo virtual com os amigos ou daquela espiadinha nas redes 
sociais. Nossos hábitos do dia a dia são constantemente alterados pela introdução de novas 
tecnologias que passam a oferecer serviços que antes não eram possíveis.
Qualquer que seja o ramo de atuação de uma empresa, sua existência hoje só é possível pela 
presença maciça de produtos de software, seja para gerenciar o negócio, seja para viabilizar sua 
operação. Tente imaginar, por exemplo, como seria o funcionamento de um banco hoje sem a 
presença de software? E de um supermercado? E de uma indústria de manufatura?
Os meios de transporte, como automóveis, aviões e navios, nada mais são do que uma carcaça 
metálica e um emaranhado de componentes mecânicos e eletrônicos, operados e gerenciados por 
software, muito software. Você sabia que um carro de luxo possui mais de um milhão de linhas 
de código?
Como garantir que tudo isto funcione adequadamente e que os serviços sejam prestados de 
acordo com as necessidades? Tudo começa com a compreensão do que precisa ser construído, 
ou seja, começa com o entendimento dos requisitos! Se os profissionais da área de computação, 
não conseguirem identificar, analisar, especificar e gerenciar adequadamente os requisitos que 
devem estar presentes no produto de software, ele pode não atender às suas necessidades e, em 
última instância, não servir para nada. Pode ainda causar grandes prejuízos financeiros ou até 
mesmo custar a vida de alguém, como no caso da operação de veículos autônomos, por 
exemplo, ou de equipamentos médicos.
Nesta Unidade de Aprendizagem você aprenderá sobre a importância das atividades de 
Engenharia de Requisitos no ciclo de desenvolvimento de software e como requisitos mal 
compreendidos e mal definidos podem afetar a qualidade do produto final. Além disto, 
aprenderá sobre as atividades da Engenharia de Requisitos e como elas podem contribuir para 
17
que os problemas provenientes dos requisitos possam ser eliminados, ou pelo menos 
minimizados.
Bons estudos.
Ao final desta Unidade de Aprendizagem, você deve apresentar os seguintes aprendizados:
Discutir os problemas advindos dos requisitos em projetos de software.•
Reconhecer a importância da Engenharia de Requisitos no ciclo de vida de um software.•
Identificar as etapas da Engenharia de Requisitos.•
DESAFIO
A Engenharia de Requisitos, quando mal executada em projetos de software, pode ser a causa de 
diversos problemas, como, por exemplo, atrasos nas entregas, retrabalho, insatisfação do cliente, 
desgaste da imagem da empresa e erros que podem gerar prejuízos financeiros ou até mesmo a 
perda de vidas.
Conteúdo interativo disponível na plataforma de ensino!
Você, como novo contratado, precisa ajudar Paul na solução das questões levantadas. Para isso:
Encontre pelo menos 3 problemas que foram observados e as suas possíveis soluções.
INFOGRÁFICO
A Engenharia de Requisitos pode ser considerada como um conjunto de práticas necessárias ao 
tratamento de requisitos ao longo de todo o ciclo de vida de um produto de software, desde a sua 
concepção até a sua descontinuação. 
Acompanhe as atividades envolvidas na Engenharia de Requisitos no Infográfico a seguir. Nele, 
você poderá ver o fluxo das solicitações, desde a captura dos requisitos a partir das fontes de 
informação, até a validação, passando pelas etapas de gerenciamento de solicitações de 
mudanças.
18
No Infográfico a seguir, você verá as etapas que compõem a Engenharia de 
Requisitos. Dois ciclos se destacam: o Desenvolvimento de Requisitos e o 
Gerenciamento de Requisitos. 
r-------------
DESENVOLVIMENTO 
DE REQUISITOS 
ELICITAÇÃO 
FONTES DE 
INFORMAÇÃO 
São os fornecedores de requisitos, 
que podem ser clientes, usuários, leis, 
documentos, processos, etc. 
Investigação, busca e descoberta 
dos requisitos. 
ANÁLISE 
Avaliação de possíveis conflitos, 
identificação das relações com o 
contexto e definição dos requisitos. 
ESPECIFICAÇÃO 1--. 
Documentação e detalhamento das 
especificações dos requisitos. 
No DESENVOLVIMENTO DE 
formam a Baseline de Requisitos 
VALIDAÇÃO 
Validação dos requisitos em relação 
aos propósitos do produto de software.
_______________ .J 
No GERENCIAMENTO DE 
REQUISITOS, os novos 
requisitos acordados com os 
stakeho/ders formam a Nova 
Baseline de Requisitos. 
r----------------
GERENCIAMENTO 
DE REQUISITOS 
IDENTIFICAÇÃO 
DE MUDANÇAS 
\ 1 / 
,,,, -�-/ '/ \ 
MUDANÇAS 
Mudanças podem ser provenientes de 
diversas fontes como: usuários, clientes, 
estratégias, leis, etc. 
Identificação de mudanças ocorridas 
no contexto do projeto/produto ou 
advindas dos stakeho/ders.
ANÁLISE 
DE IMPACTO 
MANUTENÇÃO DA 
RASTREABILIDADE 
Construção e manutenção da rastreabilidade 
entre as fontes de informação, os requisitos 
e demais elementos do produto. 
Avaliação do impacto das mudanças 
sobre os requisitos e demais elementos 
do produto. 
TOMADA 
DE DECISÃO 
Decisão sobre a mudança, 
considerando a análise de impacto. 
_______________ .J 
19
CONTEÚDO DO LIVRO
Requisitos representam um dos pontos mais cruciais da produção de software. Requisitos mal 
compreendidos, mal especificados e mal gerenciados são uma das maiores causas de fracassos 
em projetos de Tecnologia da Informação. A Engenharia de Requisitos é a área da Engenharia 
de Software que oferece ferramentas para que o profissional de computação possa lidar 
adequadamente com os requisitos nas diversas fases do ciclo de vida de um produto de software.
No capítulo Fundamentos da Engenharia de Requisitos, do livro Engenharia de Requisitos, base 
teórica desta Unidade de Aprendizagem, você vai ler sobre os problemas causados em 
decorrência das deficiências no tratamento dos requisitos, bem como compreender a importância 
da Engenharia de Requisitos no ciclo de vida de um produto de software. Ao final, vai tratar das 
atividades que compõem a Engenharia de Requisitos.
Boa leitura.
20
Fundamentos da 
engenharia de requisitos
Objetivos de aprendizagem
Ao final deste texto, você deve apresentar os seguintes aprendizados:
 � Discutir os problemas advindos dos requisitos em projetos de software.
 � Reconhecer a importância da engenharia de requisitos no ciclo de
vida de um software.
 � Identificar as etapas da engenharia de requisitos.
Introdução
É inquestionável a presença da tecnologia em nosso dia a dia. Produtos 
de software fazem parte de praticamente todas as atividades humanas, 
sejam elas pessoais, sejam profissionais. Quando um software não funciona 
de forma adequada, sentimos o impacto por meio de transtornos, como 
a falta de sincronização de semáforos nas grandes cidades, o atraso e o 
cancelamento de voos, a impossibilidade de fazer uma compra on-line, 
a indisponibilidade de serviços bancários, e mais uma infinidade de con-
tratempos. Falhas em software também podem tirar vidas.
Uma das principais fontes de problemas em produtos de software 
está relacionada aos requisitos. Requisitos mal compreendidos, mal 
especificados e mal gerenciados podem comprometer o desempenho de 
produtos de software e representam uma das maiores causas de fracasso 
em projetos de tecnologia da informação. 
Neste capítulo, você vai ler sobre a importância do softwarena socie-
dade moderna e os impactos provenientes de problemas relacionados 
a requisitos de software. Verá também a importância da engenharia de 
requisitos no ciclo de desenvolvimento de software e sua influência nas 
atividades de desenvolvimento. Por fim, você vai saber como a enge-
nharia de requisitos pode ajudar a eliminar, ou pelo menos minimizar, 
os problemas relacionados a requisitos. 
21
1 Problemas advindos dos requisitos 
de software
Produtos de software estão presentes em todos os momentos de nossas vidas. 
Diariamente, mesmo sem nos darmos conta, entramos em contato com dife-
rentes tipos de software. Acordamos despertados por uma funcionalidade de 
nossos smartphones e olhamos a previsão do tempo disponibilizada por outro 
aplicativo. Saímos para o exercício matinal acompanhados do smartwatch, 
que registra todo o nosso desempenho, incluindo o tempo, o percurso e até 
mesmo os batimentos cardíacos. Retornamos e aquecemos o café da manhã no 
micro-ondas, cuja programação automática é feita por um software embarcado 
no eletrodoméstico. Em seguida pedimos o transporte, utilizando mais um 
aplicativo no celular. 
Ao chegar no trabalho, um mundo de diferentes sistemas de software nos 
apoia no dia a dia da empresa (email, mensagens instantâneas, programas 
de gestão, de controle de produção, de marketing, de vendas e por aí vai). 
Ao final do dia, cansados, voltamos do trabalho ouvindo uma música para 
relaxar usando o streamer de músicas e aproveitamos para, no caminho, pedir 
uma refeição no sistema de entrega de comida e acionar o ar condicionado 
de casa, para que esteja na temperatura ideal quando chegarmos. Ainda dá 
para marcar aquele encontro com os amigos para o final de semana, usando 
o aplicativo de troca de mensagens. Checamos nosso saldo no banco e veri-
ficamos se o débito automático da conta de luz foi realizado. Após o jantar,
que pagamos com a máquina de cartão de crédito por aproximação do celular, 
encerramos o dia assistindo nossa série preferida no programa de streaming
de vídeo e damos uma espiadinha nas redes sociais. O despertador já está
programado para o próximo dia.
Praticamente nada disso seria possível sem o uso da tecnologia e dos 
sistemas de software que viabilizam esses serviços. Atualmente, todos os 
segmentos da atividade humana são permeados por software — e serão cada 
vez mais. Imagine, por um momento, se todo software do planeta parasse de 
funcionar. Quais seriam os impactos? Que atividades você realiza hoje que 
não poderia realizar? Que serviços essenciais deixariam de ser prestados? 
Algumas dessas facilidades estão tão enraizadas em nossas vidas que parece 
que elas sempre estiveram lá.
Com tantas novas tecnologias a cada dia, construir software se tornou 
uma atividade cada vez mais complexa. Se, por um lado, não temos mais as 
restrições de memória e de poder de processamento que tínhamos na década 
de 1960, a variedade e a complexidade dos elementos envolvidos atualmente 
 da engenharia de requisitos Fundamentos
22
trazem novos desafios para o desenvolvimento de software. Além disso, 
os ambientes de negócios se tornaram mais sofisticados e complexos. O re-
sultado é que desenvolver projetos de software não é uma atividade trivial, e 
os desafios começam na parte inicial do ciclo de vida: os requisitos.
Primeiramente, vamos definir requisitos. O Glossário padrão de termi-
nologia de engenharia de software do Institute of Electrical and Electronic 
Engineers (IEEE, 1990) define requisito como:
1. Uma condição ou capacidade necessária para um usuário resolver um
problema ou alcançar um objetivo.
2. Uma condição ou capacidade que deve ser atendida ou tida por um
sistema ou componente do sistema para satisfazer a um contrato, padrão, 
especificação ou outro documento formalmente imposto.
3. Uma representação documentada de uma condição ou capacidade con-
forme estabelecido em 1 e 2.
Independentemente de a empresa ter processos mais burocráticos e formais 
de desenvolvimento ou utilizar métodos ágeis, requisitos mal compreendidos 
e mal gerenciados são causa frequente de inúmeros prejuízos e insatisfações. 
Diversos são os exemplos de falhas de software que podem ser ligadas a 
problemas relacionados a requisitos e levar a milhões em prejuízos. Vamos 
dar uma olhadinha em algumas delas?
 � Na década de 1990, o Aeroporto de Denver, no Colorado, havia
sido projetado para ser o maior hub de aviação dos Estados Unidos.
Um dos pontos mais críticos estava relacionado aos requisitos que 
o sistema de gerenciamento de bagagens deveria atender para que o
tempo em solo das aeronaves pudesse ser limitado a apenas 30 minutos. 
A complexidade técnica para implementar esse requisito foi subes-
timada, uma vez que o algoritmo de roteamento das bagagens não
era trivial. Isso levou a um atraso de 16 meses na inauguração e a
um prejuízo de 1,1 milhão de dólares ao dia para a cidade de Denver
(CALLEAM CONSULTING, 2008).
 � Em 1996, o foguete europeu Ariane 5 explodiu em pleno ar apenas
66 segundos após ter sido lançado. A causa principal foi o requisito de
reutilizar o software de seu antecessor, o Ariane 4, que tinha alguns 
campos internos com tamanhos diferentes do Ariane 5. O requisito de 
compatibilidade entre os modelos não foi corretamente analisado e o 
prejuízo estimado foi de 370 milhões de dólares (HINKEL, [201-?]).
Fundamentos da engenharia de requisitos
23
 � Em 1999, a sonda espacial climática da NASA que iria para Marte
errou o ponto de inserção orbital no planeta, realizando a manobra
com um erro de 100 km, o que ocasionou a destruição do equipamento 
e gerou um prejuízo estimado de 125 milhões de dólares. A causa foi 
um problema no sistema de conversão de medidas — enquanto uma 
equipe estava usando o sistema métrico decimal, a outra estava usando 
o sistema imperial (ISBELL; SAVAGE, 1999).
 � Em 2019, a Boeing foi obrigada a suspender toda a frota de 387 aviões
do modelo Boeing 737 Max, que voavam para 59 companhias aéreas em 
todo o mundo. O fato ocorreu depois que dois acidentes aéreos tiraram 
a vida de 346 pessoas em menos de 5 meses. A causa foi atribuída a 
problemas encontrados no novo software de controle de voo que havia 
sido implantado (BOEING…, 2019).
Esses são apenas alguns dos inúmeros exemplos ocorridos, cuja conse-
quência pode ser a perda de vidas ou o prejuízo financeiro, ou ambos. No dia a 
dia das empresas de software, a consequência mais comum dos problemas em 
requisitos é o aumento do retrabalho, ou seja, a necessidade de refazer coisas 
que já estavam prontas, levando a custos não previstos inicialmente. Quanto 
mais longe do início do projeto ou da sprint se percebe o problema, mais caro é 
para consertar. Quanto mais atividade já tiver sido realizada sobre o requisito 
(especificação, implementação, testes, entrega), mais difícil e trabalhoso é 
consertar e maiores são os impactos negativos para o projeto ou para a sprint. 
Sprint é o termo que denomina um ciclo de desenvolvimento em uma empresa que 
utiliza o método ágil Scrum. Uma sprint tem uma duração de duas a quatro semanas 
e visa à entrega de um item possivelmente liberável e que agrega valor ao cliente 
(SCHWABER; SUTHERLAND, 2018).
Fundamentos da engenharia de requisitos
24
Os problemas estão relacionados ao fato de que um requisito pode:
 � estar incompleto;
 � estar em um nível de detalhe insuficiente para as etapas seguintes do
ciclo de desenvolvimento;
 � conter ambiguidades ou imprecisões que levem os membros da equipe
a interpretá-lo de forma diferente do que o esperado, levando a erros
nas fases seguintes do ciclo de desenvolvimento;
 � ser incompatível com outro requisito;
 � ser tecnicamente inviável;
 � ser difícil de testar e validar;
 � ter priorização conflitante sob a ótica dos diversos stakeholders.
E por que esses problemas acontecem com os requisitos? Existem diversos 
motivos pelos quais esses problemas podem acontecer, e isso varia de acordo 
com o tipo de projeto, com o contexto de negócio, comas características da 
equipe e das tecnologias envolvidas. Um projeto simples, cujo contexto de 
negócios é dominado pela equipe técnica, vai ter menos riscos associados a 
requisitos do que um projeto que envolva uma equipe menos experiente ou 
um negócio muito inovador e sem histórico anterior. 
Existem projetos que têm um cliente bem definido e usuários com perfis 
conhecidos. Nesse contexto, os requisitos podem ser obtidos pelo contato 
direto com o cliente ou com os próprios usuários. Os requisitos, nesse caso, 
podem falhar por problemas de comunicação entre as partes, nos quais cada 
uma tem uma perspectiva diferente e até mesmo um vocabulário diferente. 
É comum ouvir que os usuários não sabem o que querem, mas, na verdade, 
por mais que eles saibam, sua perspectiva pode mudar pelo simples fato de 
entrarem em contato com a equipe, por experimentar a primeira versão de 
um protótipo ou mesmo pelo fato de que suas necessidades mudam ao longo 
do tempo. Os efeitos da mudança vão depender de diversos fatores, mas o 
seu tratamento vai depender fortemente do grau de confiança entre as partes. 
Quanto maior o grau de confiança, mas fácil é de se gerenciar as mudanças 
nos requisitos e suas consequências para o projeto, para o produto e para o 
relacionamento entre as partes.
Há projetos que são inovadores e visam a criar um produto de software que 
não existe ainda, como é o caso das startups de tecnologia. Nesse cenário, de 
onde podem vir os requisitos? Eles podem ser resultantes da própria equipe 
que está criando o produto, com base no que elas enxergam que o mercado 
Fundamentos da engenharia de requisitos
25
precisa. Por esse motivo, para esses casos, um MVP (minimum viable product 
ou produto mínimo viável) é criado para analisar se a ideia pode ou não ir 
adiante. Quanto mais cedo surge falha, mais cedo a ideia é pivotada e um novo 
ciclo de desenvolvimento é iniciado, com novos requisitos. 
Quanto maior a capacidade da equipe de perceber os requisitos que o mercado deseja 
para o produto, maiores são as chances de sucesso da startup.
Há casos ainda em que o projeto visa a uma atualização tecnológica de 
um produto, na qual a própria versão anterior do produto pode ser a fonte de 
requisitos. Nesses casos, a qualidade dos requisitos obtidos depende fortemente 
da qualidade do sistema anterior e da habilidade da equipe em extrair esses 
requisitos.
Algumas das causas mais frequentes dos problemas relacionados a requi-
sitos, de acordo com Wiegers e Beatty (2013), são:
 � os objetivos de negócio, a visão e o escopo do projeto nunca foram
definidos claramente;
 � os clientes estavam muito ocupados para dedicar mais tempo trabalhando 
com os analistas ou os desenvolvedores nos requisitos;
 � o time não pode interagir diretamente com usuários representativos
para entender suas necessidades;
 � os clientes argumentaram que todos os requisitos eram críticos, por
isso eles não estabeleceram prioridades;
 � os desenvolvedores encontraram ambiguidades e informações faltan-
tes quando foram codificar, então, eles precisaram adivinhar certas
informações;
 � as comunicações entre o cliente e os desenvolvedores focaram na apa-
rência da interface do usuário e não no que os usuários necessitavam
alcançar com o software;
 � os clientes nunca aprovaram os requisitos;
 � os usuários aprovaram os requisitos para um release ou iteração e então 
mudaram eles continuamente;
Fundamentos da engenharia de requisitos
26
 � o escopo do projeto aumentou à medida que as mudanças de requisitos
foram aceitas, mas o cronograma se desviou porque nenhum recurso
adicional foi fornecido e nenhuma funcionalidade foi removida;
 � as mudanças solicitadas nos requisitos foram perdidas; ninguém sabia
o status de solicitações de mudanças específicas;
 � os clientes requisitaram certa funcionalidade e os desenvolvedores a
desenvolveram, mas ninguém nunca utilizou;
 � ao final do projeto, a especificação foi satisfeita, mas o usuário e os
objetivos de negócio não.
Relembrando o que Frederick Brooks já nos alertava em 1987 (BROOKS, 
1987, p. 13):
A parte mais difícil ao se construir um sistema de software é decidir precisa-
mente o que construir. Nenhuma outra parte do trabalho conceitual é tão difícil 
quanto estabelecer os requisitos técnicos detalhados, incluindo a interface 
com as pessoas, máquinas e outros sistemas de software. Nenhuma outra 
parte afeta tanto o sistema resultante se for feita de forma errada. Nenhuma 
outra parte é tão difícil de consertar depois.
2 Ciclo de vida de software e engenharia 
de requisitos
O ciclo de vida de um produto de software pode ser compreendido como um 
conjunto de etapas pelas quais o produto passa ao longo de sua existência, 
conforme ilustra, de forma simplificada, a Figura 1.
Figura 1. Ciclo de vida de um produto de software.
CONCEPÇÃO
DESENVOLVIMENTO
MANUTENÇÃO
DESCONTINUAÇÃO
Identi�cação da ideia
inicial e análise da
viabilidade de se
construir o produto
Especi�cação,
implementação e
implantação do 
produto de software
Manutenção corretiva 
e adaptativa do 
produto de software
ao longo de sua vida
útil em atividade
Desativação do produto
de software quando ele 
se torna obsoleto e
não é mais necessário
Fundamentos da engenharia de requisitos
27
Concepção
Inicialmente, a necessidade de um novo produto de software é identificada e 
a viabilidade de sua construção é analisada. Como produtos de software podem 
ter diversas naturezas, a fonte dessa necessidade pode variar enormemente, 
especialmente hoje, quando a tecnologia permeia todas as nossas atividades, 
como vimos no início deste capítulo.
Na fase de concepção, os primeiros requisitos aparecem na forma de 
objetivos de negócio de alto nível, do tipo: “Precisamos de um software para 
apoiar o gerenciamento do fluxo de solicitações”. Às vezes esse objetivo vem 
atrelado a uma meta: “(…) de modo a reduzir o tempo de prestação do serviço 
a 6 horas”. Ainda assim, não sabemos exatamente o que precisa ser construído, 
até que sejam detalhados os requisitos que representam as funcionalidades do 
produto, conhecidos como requisitos funcionais de produto. Então evoluímos 
para algo do tipo: “O sistema deve ter uma função que emita alertas toda vez 
que uma solicitação estiver parada por mais de 2 horas”.
Nesse momento é também comum que surjam os requisitos de projeto 
e de processo. Os requisitos de projeto podem impor restrições ao projeto 
em si, e podem ser relacionados com os prazos, os recursos e o orçamento. 
Já os requisitos de processo podem imprimir restrições relacionadas à forma 
como o projeto será desenvolvido, como, por exemplo, um método específico 
de desenvolvimento.
De posse dessas informações iniciais, é possível avaliar a viabilidade de 
se dar início ou não ao Desenvolvimento. Um projeto pode ser cancelado 
antes mesmo de ter sido iniciado. Isso pode ocorrer por diversos motivos, 
entre eles o fato de o escopo não estar suficientemente claro para que se possa 
comprometer recursos para a sua execução.
Desenvolvimento
A fase de desenvolvimento compreende todas as atividades necessárias para 
a produção do software. Isso inclui aquelas relacionadas a requisitos, análise 
e design, implementação, testes, homologação e implantação, além de todas 
as atividades de suporte ao desenvolvimento e à gestão do desenvolvimento, 
conforme ilustra a Figura 2.
 da engenharia de requisitos Fundamentos
28
Figura 2. Etapas do desenvolvimento de software.
Embora o termo “etapas do desenvolvimento” esteja sendo utilizado, aqui ele não 
se refere a um modelo de ciclo de vida sequencial ou cascata. Essas etapas são mais 
parecidas com disciplinas, que podem se intercalar e se repetir à medida que o projeto 
avança, de forma iterativa e incremental. A Figura 2 ilustra essas etapas.
Quando um projeto de desenvolvimento de software tem início, é comum 
que um escopo esteja estabelecido, mesmo que esse escopo ainda esteja em um 
nível alto de granularidade. A partir daí,as atividades relacionadas a requisitos, 
que tiveram início na etapa de concepção, são intensificadas. Os detalhes 
referentes à engenharia de requisitos serão explorados na próxima seção.
Dependendo do tipo e criticidade do projeto, uma vez estabelecidos os 
requisitos, têm início as atividades de design. Essa etapa consiste em projetar a 
solução que implementará os requisitos. Esses modelos ajudam a aprofundar a 
compreensão do contexto e a delinear a solução que será implementada. Mesmo 
empresas que utilizam métodos ágeis costumam ter uma sprint zero, que se 
dedica a conceber a arquitetura da aplicação. Nesse momento é estabelecida 
a arquitetura do sistema, os componentes e como eles se relacionam.
Fundamentos da engenharia de requisitos
29
Durante a etapa de análise e design podem emergir novos requisitos, 
derivados ou não daqueles que foram inicialmente elicitados. Isso pode ocorrer 
porque, ao modelar a solução, o analista de sistemas pode:
 � identificar requisitos técnicos adicionais, advindos da arquitetura
escolhida;
 � perceber que determinados requisitos não têm viabilidade técnica de
execução;
 � identificar requisitos conflitantes;
 � identificar requisitos incompletos ou imaturos para a implementação
Uma vez definidos os componentes no nível de detalhe compatível com 
as necessidades do projeto, iniciam as atividades de Implementação. Note 
que aqui pode haver um paralelismo de atividades, pois os componentes 
podem ir sendo especificados ao mesmo tempo em que outros já estão sendo 
implementados. Nessa etapa o desenvolvedor ainda pode detectar problemas 
nos requisitos, devido à inviabilidade técnica de implementar.
Ao concluir a codificação, o desenvolvedor realiza os testes individuais 
nas unidades pelas quais foi responsável pela implementação. Nesse momento 
são realizadas as atividades de verificação, usando os casos de teste manuais 
ou automatizados.
Há empresas que utilizam a abordagem DevOps, integrando o ciclo de 
desenvolvimento ao ciclo de operação em produção. Isso é feito utilizando 
os conceitos de integração contínua (CI, continuous integration) e entrega 
contínua (CD, continuous delivery) e implantação contínua (CD, continuous 
deployment). Entende-se por CI o fato de haver uma integração automática 
à medida que o desenvolvedor sobe o seu código para o repositório e este se 
integra a outras partes do código que foram desenvolvidas por outros desenvol-
vedores. Já a entrega contínua (CD) se refere a entregar uma solução integrada 
para o pessoal de implantação poder realizar a passagem para o ambiente de 
produção, e a implantação contínua (utiliza-se a sigla CD também) se refere 
à passagem automática para o ambiente de produção.
Quer conhecer mais sobre DevOps? Consulte o livro Jornada DevOps: unindo cultura ágil, 
Lean e tecnologia para entrega de software de qualidade, organizado por Muniz et al. (2019).
Fundamentos da engenharia de requisitos
30
Manutenção
A maior parte do tempo de vida de um produto de software se passa na etapa 
de Manutenção. A partir do momento que a primeira funcionalidade entra 
em produção e o produto começa a ser utilizado, já começam as requisições 
de mudanças, sejam elas por bugs encontrados pelos usuários, sejam por 
demandas de ordem legal/fiscal ou por melhorias e novas funcionalidades.
Na etapa de Manutenção, ocorre a maior parte das atividades de gerencia-
mento dos requisitos. Isso significa que a rastreabilidade é a ferramenta mais 
importante para a análise do impacto das solicitações de mudanças.
Descontinuação
Quando o produto de software não atende mais aos seus propósitos ele é 
descontinuado, ou seja, ele é retirado do ambiente de produção. Em alguns 
casos, basta solicitar a desinstalação do produto, como é o caso dos aplicativos 
que temos em nosso celular. Mas, na maioria das vezes, a descontinuação não 
é uma atividade tão simples.
Para descontinuar, por exemplo, um software de gestão do tipo ERP (en-
terprise resource planning, ou sistema de gestão empresarial), são necessários 
muitos anos, pois a transição para outro produto/fornecedor não é tão simples. 
Muitas vezes é necessário construir outro sistema para que se possa fazer a 
migração de dados e processos para o novo produto. Nesses casos, é importante 
compreender os requisitos da desativação. 
O negócio no qual o software está inserido pode ter requisitos específicos relacionados 
a questões de ordem legal e/ou fiscal, como o arquivamento de dados e documentos 
por um longo período. Por exemplo, contratos de trabalho precisam ser guardados 
por tempo indeterminado, enquanto outros documentos requerem prazos de 5, 
10, 20 e até 30 anos. Além disso, é preciso planejar a forma como esses dados serão 
recuperados em caso de necessidade. Esses são requisitos que podem estar presentes 
no projeto de desativação de um produto de software.
Fundamentos da engenharia de requisitos
31
3 Etapas da engenharia de requisitos
Agora que já entendemos quais problemas podem vir dos requisitos e com-
preendemos a importância da engenharia de requisitos para lidar com essas 
questões, vamos conhecer quais são as atividades a serem realizadas nessa 
etapa do desenvolvimento de software.
Falar em etapas da engenharia de requisitos pode sugerir que estamos 
nos referindo a um modelo de desenvolvimento cascata, cheio de burocracias 
e distante da realidade atual das empresas. Na verdade, no contexto deste 
capítulo, estamos considerando que as etapas da engenharia de requisitos 
são atividades que devem ser realizadas no desenvolvimento de produtos 
de software, independentemente do modelo de ciclo de vida que está sendo 
utilizado. O momento de realização dessas atividades e os artefatos envolvidos 
poderão variar, mas a essência é a mesma — o que varia é a forma. O objetivo 
é um só: construir produtos de software melhores e mais confiáveis!
Como você pode observar na Figura 3, a engenharia de requisitos compre-
ende duas grandes etapas: o desenvolvimento e o gerenciamento. No desen-
volvimento de requisitos estão englobadas as atividades de elicitação, análise, 
especificação e validação, as quais veremos em mais detalhes a seguir.
Figura 3. Etapas da engenharia de requisitos.
 da engenharia de requisitos Fundamentos
32
Elicitação de requisitos
A elicitação se refere à etapa de investigação dos requisitos. É o momento em 
que a equipe técnica precisa compreender o que deve ser feito. Antigamente, 
o termo utilizado era “levantamento de dados”, no entanto, essa expressão
está em desuso e, em seu lugar, usamos a expressão “elicitação de requisitos”
para denotar algo mais forte, que remete a uma busca ativa pelos requisitos.
Isso significa que o analista de requisitos ou papel similar (analista de 
negócios, analista de sistemas, product owner ou equivalente) deve adotar 
uma postura proativa para a descoberta e o entendimento dos requisitos. Isso 
implica em utilizar diversas formas de elicitação, de acordo com o contexto 
em que o sistema está sendo desenvolvido. Outros termos associados a esta 
etapa podem ser: captura de requisitos, descoberta de requisitos ou aquisição 
de requisitos (BOURQUE; FAIRLEY, 2014).
Quando falamos da Elicitação de requisitos não estamos enfatizando que 
é necessário ter todos os requisitos extensivamente detalhados no início do 
projeto, ou que esta etapa ocorra uma única vez no início do projeto. Em pro-
jetos ágeis, os requisitos podem emergir em diversos momentos, compondo o 
product backlog. No entanto, é importante ter em mente que alguns requisitos, 
quando descobertos muito tardiamente no ciclo de vida de um projeto, podem 
implicar em grande quantidade de retrabalho e custos adicionais. Esse é o caso, 
por exemplo, dos requisitos que impactam fortemente sobre a arquitetura do 
produto — esses são mais difíceis de serem alterados posteriormente.
Product backlog (ou “backlog do produto”) é o termo utilizado para denominar um 
conjunto de itens conhecidos que devem ser desenvolvidos paradeterminado produto. 
Quando itens do product backlog são priorizados para serem desenvolvidos em uma 
sprint, então, esse subconjunto é chamado de sprint backlog. O termo é comum em 
empresas que utilizam o método ágil Scrum (SCHWABER; SUTHERLAND, 2018).
Fundamentos da engenharia de requisitos
33
O processo de elicitação exige uma intensa comunicação com os stakehol-
ders do projeto. É no processo de comunicação que o analista de requisitos 
identifica o que realmente é imprescindível para o desenvolvimento do produto 
e não perde tempo detalhando o que não é importante ou que não precisa 
de detalhamento naquele momento. A comunicação ineficaz pode levar a 
requisitos incompletos e incorretos.
Há casos em que a comunicação com os stakeholders é direta e é possível 
aplicar técnicas como entrevistas e reuniões, pois existem fontes de infor-
mação humanas que compreendem o contexto de negócio e podem prover as 
informações necessárias para a definição dos requisitos. Delinear histórias 
do usuário ou mapear a jornada do usuário pode ajudar. Ambos se baseiam 
na narrativa de uma história de uso do sistema por um usuário.
No caso dos produtos inovadores, que estão sendo criados sem uma ex-
periência anterior, ou que tenham um propósito disruptivo, é necessário que 
sejam utilizadas técnicas com o propósito de despertar a criatividade. Isto 
pode ser feito utilizando sessões de cocriação, como o brainstorming ou o 
design thinking.
Há ainda os momentos em que os requisitos são obtidos a partir de do-
cumentações como editais de licitação (no caso de contratação advinda do 
setor público), de normas e leis (no caso de sistemas que precisam atender a 
legislações específicas e órgãos regulamentadores), de documentação de outros 
sistemas anteriores e, até mesmo, no pior caso, do próprio código-fonte anterior.
O importante nas atividades de elicitação de requisitos é que o analista 
de requisitos seja capaz de compreender o contexto em que o projeto está 
inserido e que possa planejar de que forma irá realizar sua atividade de elicitar 
os requisitos. Pode ser empregando uma única técnica, pode ser empregando 
uma combinação de técnicas. 
O papel do analista de requisitos é mergulhar no ambiente de negócio. O usuário 
não precisa de um software, ele precisa do serviço que o software presta, precisa de 
algo que resolva o seu problema de negócio. O mais importante é que o analista de 
requisitos tenha feito todos os esforços para engajar os stakeholders e fazer emergir 
os requisitos que farão do projeto um sucesso.
 da engenharia de requisitos Fundamentos
34
Análise de requisitos
A análise de requisitos é a etapa na qual nos concentramos em aprofundar o 
entendimento acerca dos requisitos, buscando possíveis conflitos que podem 
ser advindos das diferentes visões que os stakeholders possam ter sobre o 
requisito e sua prioridade no projeto de desenvolvimento. Entretanto, os pro-
blemas podem vir também de requisitos conflitantes entre si, especialmente 
no que se refere a requisitos de qualidade, também chamados de requisitos 
não funcionais. A complexidade de um requisito funcional, por exemplo, pode 
ser incompatível com a necessidade de desempenho exigida. 
Faz parte da análise a decomposição de requisitos de alto nível em níveis 
apropriados de detalhe. Muitas vezes o requisito está expresso como um 
objetivo de negócio de alto nível e isso não é suficiente para as próximas 
etapas do desenvolvimento de software, sendo necessário decompô-lo em 
níveis mais detalhados.
Outro aspecto importante da análise dos requisitos diz respeito à defini-
ção dos atributos a ele associados, como o tipo do requisito, a volatilidade, 
o impacto sobre a arquitetura e o risco. Se um requisito, por exemplo, é volátil, 
ou seja, está mais sujeito a mudanças do que outros, pode ser que se decida
por implementá-lo posteriormente, quando o seu entendimento esteja mais
estabilizado. Da mesma forma, requisitos que tenham um grande impacto sobre 
a arquitetura da aplicação devem ser tratados com um cuidado redobrado, pois
podem implicar em consequências para todos os demais requisitos, incluindo
os requisitos de qualidade, como o desempenho da aplicação.
É importante lembrar que a extensão da análise de requisitos vai variar de 
acordo com a criticidade do software e qual o seu papel dentro do contexto no 
qual está inserido. Sistemas complexos, envolvendo, por exemplo hardware 
e software, como sistemas de software para a direção autônoma de veículos, 
precisam de uma etapa de análise de requisitos mais aprofundada, que pode 
até mesmo se confundir com o design e com as especificações arquiteturais 
do produto (o que envolve o sistema como um todo). Nos exemplos que vimos 
no início deste capítulo, pudemos observar como alguns requisitos técnicos 
podem levar sondas espaciais a se desintegrarem em pleno ar e aeronaves a 
serem retiradas de circulação após desastres aéreos provenientes do software. 
Em ambos os casos, com extensivos prejuízos materiais, mas, principalmente, 
com a perda de vidas humanas.
Fundamentos da engenharia de requisitos
35
Especificação de requisitos
A especificação de requisitos é a etapa dedicada a representar os requisitos de 
uma forma que eles possam perdurar ao longo do tempo e possam ser verifi-
cados e validados posteriormente. Isso pode implicar em formatos diferentes 
de especificação que envolvem textos, diagramas e tabelas. Aqui cabe uma 
pequena discussão acerca do que é exatamente representar os requisitos e de 
que forma deveríamos realizar essa atividade. 
Os métodos tradicionais de desenvolvimento, especialmente o cascata, 
com ciclos extensivos e exaustivos de especificação antes da codificação, 
já se mostraram ineficientes no passado e foram, gradualmente, substituídos. 
Há alguns anos que os métodos ágeis estão sendo mais amplamente adotados 
pela indústria, e muitos entendem que usar um método ágil significa não 
realizar qualquer tipo de “documentação”. A palavra aqui vem entre aspas para 
denotar que o termo é de uso pejorativo no ambiente ágil, estando relacionado 
a uma ação que agrega pouco ou nenhum valor ao produto final. Agilistas 
mais radicais defendem que a única documentação fiel de um produto é o seu 
código. São dois extremos que, em geral, se antagonizam.
Vamos refletir por um instante: imagine que você estivesse no hospital 
e sua vida dependesse da precisão de um equipamento cirúrgico, operado, 
em grande parte, por um software. Será que você iria preferir que os projetistas 
tivessem documentado adequadamente os requisitos técnicos, para garantir 
que os envolvidos nas fases seguintes desenvolvessem o produto de forma 
precisa? Ou você estaria confortável em ter apenas uma história de usuário 
de alto nível como documentação desses requisitos? 
A questão aqui é quanto de especificação é necessário antes de se dar início 
à implementação? A resposta é depende. Depende da complexidade do produto 
que está sendo desenvolvido, da criticidade de cada requisito, dos riscos de 
se ter um erro advindo de uma má compreensão, da experiência da equipe 
envolvida e até mesmo da fase em que o produto e a empresa se encontram.
É comum que empresas disruptivas de tecnologia, como as startups, iniciem 
suas atividades a partir de versões iniciais e pouco elaboradas do produto, 
o chamado MVP (em inglês, minimum viable product, isto é, produto mínimo 
viável). Nessa fase de sua existência, a empresa não se preocupa em especificar 
detalhadamente, pois seu foco é testar a viabilidade do negócio. Nesse momento
a equipe é pequena, composta de duas a três pessoas, e a comunicação é direta 
e simples. No entanto, à medida que essa startup cresce e se torna uma grande 
empresa, não é mais possível continuar a desenvolver sem a preocupação
com a especificação, pois a equipe também aumenta e a comunicação entre
 da engenharia de requisitos Fundamentos
36
os membros se torna mais complexa. Um erro no ambiente de produção pode 
afetar milharesde pessoas.
É preciso especificar os requisitos na medida certa para a situação. Nunca teremos 
os requisitos de forma perfeita. Precisamos ter os requisitos na forma necessária e 
suficiente para os objetivos do projeto e para prosseguir com as demais etapas do 
desenvolvimento, sejam elas denominadas de fases, sejam de etapas, iterações, estágios 
ou sprints.
Validação de requisitos
A especificação dos requisitos precisa ser validada entre os stakeholders e 
a equipe de desenvolvimento para garantir que existe uma compreensão correta 
e comum sobre os requisitos e que a equipe de desenvolvimento possui as 
condições de implementar um produto que irá satisfazer as necessidades do 
negócio (WIEGERS; BEATTY, 2013).
A validação pode ser realizada por meio de uma revisão sobre as espe-
cificações, que é feita por revisores designados para tal, com o apoio de um 
checklist, por exemplo. Há casos em que se conduzem workshops de validação, 
nos quais os diversos tipos de stakeholders são envolvidos.
Podem ainda ser usados protótipos funcionais que visam a confirmar os 
requisitos e até mesmo a apoiar a elicitação de novos requisitos. Nesse caso, 
é importante destacar a finalidade dessa validação. Existe o risco do processo 
de validação de um protótipo se resumir a analisar requisitos da interface com 
o usuário. Isso não será um problema se a interface com o usuário for um
ponto crítico e que precise de muita atenção. Entretanto, não se pode perder
de vista a validação das regras de negócio e dos demais tipos de requisitos,
como os requisitos de qualidade.
Especificar um conjunto de casos de teste que possam ser utilizados para 
testar o produto também faz parte desta etapa. Esses casos de teste podem 
ser documentos ou casos automatizados, dependendo do nível de maturidade 
da organização. Testes podem ser utilizados posteriormente para verificar se 
o produto final cumpre o que estava na especificação (verificação) ou para
validar se o produto faz aquilo que deveria fazer (validação).
Fundamentos da engenharia de requisitos
37
Gerenciamento de requisitos
Permeando todo o ciclo dos requisitos, encontram-se as atividades relacionadas 
à fase de gerenciamento dos requisitos, que trata do estabelecimento de formas 
de rastrear os requisitos e facilitar a análise do impacto de uma solicitação de 
mudança para a tomada de decisão. 
Pesquisa do PMI (Project Management Institute) aponta problemas no 
gerenciamento de requisitos (LARSON, 2014):
 � Somente 49% das organizações têm recursos alocados adequadamente 
para o gerenciamento de requisitos.
 � Somente 33% dos líderes das organizações valorizam o gerenciamento 
de requisitos como uma competência crítica.
 � Somente 47% das organizações têm um processo formal de validação
de requisitos.
 � Dos recursos financeiros gastos em projetos e programas, 51% são
desperdiçados devido ao gerenciamento de requisitos ineficiente.
 � Dos objetivos não atendidos de projetos, 47% foram devido ao geren-
ciamento de requisitos ineficiente.
Para que os impactos de uma solicitação de mudança possam ser analisados 
de forma precisa, é necessário que se tenha conhecimento da fonte do requisito, 
de como os requisitos se relacionam entre si e de como eles se relacionam com 
os artefatos seguintes, como o código, por exemplo. Essa análise permite que 
tenhamos uma estimativa dos recursos e do tempo necessários para realizar 
a mudança solicitada, bem como para identificar quais artefatos precisam 
ser alterados. Isso permite que seja tomada uma decisão embasada sobre a 
solicitação de mudança.
Manter essa rastreabilidade entre os elementos não é uma atividade sim-
ples, especialmente em grandes produtos. Esta é uma atividade que permeia 
todo o ciclo de vida do produto e nasce quando os primeiros requisitos são 
identificados e especificados. Não é viável construir matrizes que precisem 
ser mantidas de forma manual, usando planilhas ou outro tipo de tabela; isso 
só é possível por meio de ferramentas automatizadas. Pior que não ter uma 
matriz de rastreabilidade é ter uma matriz desatualizada.
Fundamentos da engenharia de requisitos
38
BOEING 737 Max Lion Air crash caused by series of failures. BBC, Estados Unidos, 1990. 
Disponível em: https://www.bbc.com/news/business-50177788. Acesso em: 30 dez. 
2019.
BOURQUE, P.; FAIRLEY, R. (ed.). SWEBOK: guide to the software engineering body of 
knowledge version 3. Washington: IEEE Computer Society, 2014.
BROOKS, F. No silver bullet: essence and accidents of software engineering. Computer, 
v. 20, n. 4, p. 10–19, 1987.
CALLEAM CONSULTING. Denver airport baggage handling system case study. [S. l.], 2008. 
Disponível em: http://calleam.com/WTPF/wp-content/uploads/articles/DIABaggage.
pdf. Acesso em: 30 dez. 2019.
HINKEL, J. N. Ariane 5: um erro numérico (overflow) levou à falha no primeiro lançamento. 
São José dos Campos, [201-?]. Disponível em: https://www.ime.uerj.br/~demoura/
Especializ/Ariane/. Acesso em: 30 dez. 2019.
IEEE. IEEE Std 610.12-1990: IEEE Standard Glossary of Software Engineering Terminology. 
Los Alamitos: IEEE Computer Society Press, 1990.
ISBELL, D.; SAVAGE, D. Mars climate orbiter failure board releases report, numerous NASA 
actions underway in response. In: MARS POLAR LANDDER. Washington, 1999. Disponível 
em: https://mars.jpl.nasa.gov/msp98/news/mco991110.html. Acesso em: 30 dez. 2019.
LARSON, E. I still don”t have time to manage requirements: my project is later than ever. 
In: PMI® GLOBAL CONGRESS, 2014, Phoenix, AZ. Proceedings… Newtown Square, PA: 
Project Management Institute, 2014. Disponível em: https://www.pmi.org/learning/
library/poor-requirements-management-source-failed-projects-9341. Acesso em: 
30 dez. 2019.
MUNIZ, A. et al. Jornada DevOps: unindo cultura ágil, Lean e tecnologia para entrega 
de software de qualidade. Rio de Janeiro: Brasport, 2019. 
SCHWABER, K.; SUTHERLAND, J. Guia do SCRUM: um guia definitivo para o SCRUM: 
as regras do jogo. [S. l.], 2018. Disponível em: https://www.scrumguides.org/index.
html. Acesso em: 30 dez. 2019.
WIEGERS, K. E.; BEATTY, J. Software requirements. 3. ed. Redmond: Microsoft Press, 2013.
Leitura recomendada
PRESSMAN, R.; MAXIM, B. Engenharia de software: uma abordagem profissional. 8. ed. 
Porto Alegre: AMGH, 2016.
Fundamentos da engenharia de requisitos
39
DICA DO PROFESSOR
O Analista de Requisitos é o profissional responsável pelas atividades relacionadas à elicitação, 
análise, especificação, validação e gerenciamento de requisitos de projetos que envolvem 
software. Sua importância é estratégica para o sucesso do projeto, pois ele é o elo que une o 
contexto do negócio à equipe de tecnologia da informação.
Diversas são as habilidades técnicas e pessoais necessárias ao desempenho dessas atividades. 
Assista à Dica do Professor a seguir e conheça um pouco mais sobre o papel do Analista de 
Requisitos no ciclo de desenvolvimento de software.
Conteúdo interativo disponível na plataforma de ensino!
EXERCÍCIOS
1) Um software de contabilidade foi desenvolvido e implantado em diversas empresas da
cidade de São Paulo. Como o negócio estava prosperando, o produto estava
estabilizado e os clientes estavam satisfeitos, a empresa decidiu abrir a venda para
outros estados. No primeiro dia de operação do software na cidade de Blumenau, o
cliente ligou furioso avisando que: “este software não funciona! Os impostos estão
sendo calculados de forma incorreta!”
Esse é um problema que ocorre com frequência e sua causa raiz pode ser atribuída a
quê?
A) O Desenvolvedor não codificou corretamente a fórmula para calcular os impostos.
B) O Projetista de Interface não previu um campo para a alíquota correta do imposto na
interface do usuário.
O Analista de Testes não testou adequadamente o produto, deixando passar o erro no 
cálculo do imposto para a cidade de Blumenau. 
C)
40
D) O Analista de Integração deixou passar a integração de um componente implementado de
forma incorreta.
E) O Analista de Requisitosnão analisou corretamente o impacto da mudança de contexto.
2) Como você sabe, a Engenharia de Requisitos é composta por diversas etapas, entre
elas a Especificação de Requisitos.
Com relação a essa etapa, é correto afirmar que:
A) os requisitos são sempre especificados de forma detalhada, pois serão a base para realizar
o planejamento do projeto.
B) o foco é apenas nos requisitos funcionais do projeto, de modo que se possa ter o escopo
rapidamente definido antes que o programador comece a codificar.
C) não deve haver nenhum tipo de documentação, pois isso sempre atrasa o início da
programação, que é a etapa onde o produto é realmente produzido.
D) devem ser especificados os requisitos em nível de detalhe compatível com as necessidades
do projeto, o que pode variar de acordo com o contexto.
E) os requisitos de qualidade não são considerados ainda, pois eles só vão ser tratados na
etapa de testes de qualidade.
3) Para que o impacto de uma Solicitação de Mudança possa ser analisado
adequadamente, é importante que o Analista de Requisitos disponha da matriz de
rastreabilidade.
Sobre esse artefato, é correto afirmar que:
41
A) a matriz de rastreabilidade documenta os relacionamentos entre os diversos tipos de
requisitos e entre os requisitos e outros elementos do produto de software.
B) a matriz de rastreabilidade deve ser construída manualmente no formato de uma planilha.
C) a matriz de rastreabilidade precisa apenas relacionar os requisitos com as suas fontes de
informação, de modo que se possa identificar rapidamente quem pediu o requisito.
D) a matriz de rastreabilidade é uma ferramenta criada na etapa de Gerenciamento de
Requisitos.
E) a matriz de rastreabilidade é uma planilha que deve ser criada quando os desenvolvedores
terminaram a codificação, de modo a relacionar os requisitos e os códigos implementados.
4) Jones é um Desenvolvedor que acaba de ser promovido a Analista de Requisitos. Sua
primeira atividade na nova função é realizar as atividades de requisitos para o novo
sistema de avaliação de desempenho dos funcionários da empresa. A equipe usa
métodos ágeis de desenvolvimento. As regras para a avaliação ainda não estão
definidas, mas há diversos aspectos legais que devem ser levados em consideração.
Você é Analista de Requisitos há mais tempo e Jones pede a sua ajuda para
identificar por onde ele deveria começar. O que você recomendaria para Jones.
I. Como a empresa utiliza métodos ágeis, você recomenda que Jones converse com a
equipe de desenvolvimento e já comece a implementação das primeiras
funcionalidades.
II. Como o sistema possui aspectos legais a serem considerados, você recomenda que
Jones inicie identificando as fontes de informação e as técnicas que ele poderá aplicar
para elicitar os requisitos.
III. Como a empresa trabalha em um ambiente mais descontraído, utilizando
métodos ágeis, você recomenda que ele aplique a técnica de brainstorming.
42
A) As alternativas I, II e III estão corretas.
B) Apenas as alternativas I e II estão corretas.
C) Apenas as alternativas I e III estão corretas.
D) Apenas as alternativas II e III estão corretas.
E) A única alternativa correta é a II.
5) Como você sabe, a Engenharia de Requisitos possui diversas etapas. Entre elas, a
Validação de Requisitos.
Sobre essa etapa, é correto afirmar que:
A) ela é realizada pelo cliente apenas ao final do projeto, quando o produto final está
entregue.
B) ela é realizada pelo próprio Analista de Requisitos, quando termina sua atividade de
Especificação de Requisitos.
C) ela é realizada pelo cliente ao final da Especificação de Requisitos, para validar que a
equipe técnica entendeu o que foi solicitado.
D) ela é realizada pelo testador da equipe de desenvolvimento, quando os programadores
terminaram a programação.
43
E) ela é realizada pelo gerente do projeto, para validar que o trabalho do Analista de
Requisitos foi realizado com sucesso.
NA PRÁTICA
O Analista de Requisitos é o profissional responsável pelas atividades relacionadas à Engenharia 
de Requisitos, que vão desde a elicitação dos requisitos até a sua validação. Seu papel é muito 
importante para os projetos de software, uma vez que erros provenientes dessa etapa podem se 
propagar para as demais etapas do desenvolvimento com consequências que podem ser 
desastrosas para o projeto e para o produto final.
Judy é uma Analista de Requisitos que tem um novo projeto pela frente. Nesse Na Prática, você 
irá acompanhar os desafios de Judy e como ela organizou o seu trabalho desde o início para 
concluí-lo com sucesso.
Conteúdo interativo disponível na plataforma de ensino!
SAIBA MAIS
Para ampliar o seu conhecimento a respeito desse assunto, veja abaixo as sugestões do 
professor:
Um dia feito de vidro (em inglês)
A Day Made of Glass é um vídeo que mostra a tecnologia presente em todos os momentos do 
cotidiano, desde o instante em que duas crianças despertam para a ir à escola, até o momento em 
que retornam para casa, compartilhando suas experiências do dia. Paralelamente, o pai, após 
deixar as meninas na escola, utiliza a tecnologia como apoio para o seu trabalho como médico. 
Procure refletir como é o seu dia a dia e como seria se, de uma hora para outra, toda a tecnologia 
que você utiliza ficasse indisponível. O vídeo está em inglês, mas as imagens falam por si só!
Conteúdo interativo disponível na plataforma de ensino!
44
Testando a loja Amazon Go em São Francisco, Califórnia
Neste vídeo, o autor mostra como funciona a loja automatizada da Amazon Go, na qual basta 
pegar os produtos e sair da loja. Eles são automaticamente debitados do seu cartão de crédito. 
Procure refletir quais requisitos estão envolvidos nessa solução tecnológica.
Conteúdo interativo disponível na plataforma de ensino!
A natureza do software
Este material vai ajudar você a compreender e refletir sobre a natureza do software e suas 
particularidades. O capítulo inicia com um diálogo entre um dos autores e um desenvolvedor de 
jogos digitais. Em seguida, explica os diferentes tipos de software e suas implicações.
Gerenciamento de Requisitos
Neste vídeo, o autor Fabrício Laguna explica, em cerca de 5 minutos, a importância dos 
requisitos e ressalta o papel fundamental do gerenciamento de requisitos com um exemplo 
simples do dia a dia.
Conteúdo interativo disponível na plataforma de ensino!
45
Conhecer Modelo Incremental
APRESENTAÇÃO
No modelo incremental, o sistema é dividido em partes que são desenvolvidas e entregues de 
forma independente. Quando uma dessas partes é finalizada, ela é "incrementada" ao sistema, 
formando, ao final, o sistema completo. Conhecer este modelo é muito interessante, pois muitas 
empresas ainda utilizam quando existe pouca mão de obra para implementar um software.
Nesta Unidade de Aprendizagem, você irá adquirir conhecimentos fundamentais para avançar 
no aprendizado sobre o modelo incremental. Você verá conceitos básicos sobre o modelo e suas 
vantagens e desvantagens.
Bons estudos.
Ao final desta Unidade de Aprendizagem, você deve apresentar os seguintes aprendizados:
Relacionar os elementos dos modelos linear e prototipação com o modelo incremental.•
Identificar os incrementos.•
Descrever o funcionamento, vantagens e desvantagens do modelo incremental.•
DESAFIO
Roberto é dono de uma empresa que deseja criar um sistema Web para oferecer serviço de 
compartilhamento de informação e artigos. A ideia é que, com o tempo, o número de usuários 
cresça e novos módulos do sistema sejam criados.
No entanto, Roberto gostaria de aproveitar uma ação de marketing agendada para daqui a 15 
dias para divulgar o novo serviço. Sendo assim, a empresa começaria a oferecer parte do serviço 
aos usuários dentro deste prazo e iria inserindo mais serviços e funcionalidades com o tempo.
Você trabalha na empresa contratada para prestar este serviço a Roberto, e foi chamado pelo seu 
gestor para avaliar a situação. Descreva por que o modelo incremental