1. Diferencie requisitos funcionais de requisitos não-funcionais.

Os Requisitos Funcionais definem as ações que o sistema deve realizar ou não; são as
propriedades que visam a fazer com que o sistema satisfaça as exigências dos usuários, delineando assim
as operações do sistema, seja no momento do login, na geração de relatórios, cálculos, entre outros. Ao
contrário dos Requisitos não-funcionais, definindo o modo como o sistema deve se comportar. Estão
vinculados às propriedades que determinam a excelência do sistema, seja em termos de desempenho (o
sistema deve ser ágil para atender as solicitações dos usuários, por ex.), segurança, usabilidade,
escalabilidade (se o sistema é capaz de lidar com um volume grande de usuários e dados), etc. Os
requisitos funcionais determinam as ações do sistema, enquanto os requisitos não-funcionais definem a
maneira como o sistema se comporta.

2. Em 2015, descobriu-se que o software instalado em mais de 11 milhões de carros da

Volkswagen detectava quando eles estavam sendo testados em um laboratório de certificação.
Nessas situações, o carro emitia poluentes dentro das normas legais. Fora do laboratório, emitia-
se mais poluentes, para melhorar o desempenho. Ou seja, o código provavelmente incluía uma
estrutura de decisão como a seguinte (meramente ilustrativa, para fins deste exercício):
if "Carro sendo testado em um laboratório" "Emita poluentes dentro das normas" else
"Emita poluentes fora das normas"
O que você faria se seu chefe pedisse para escrever um if como o acima? (para mais
informações sobre esse episódio com automóveis Volkswagen, consulte essa página da
Wikipedia).
Me recusaria a ceder, pois o comando manipula os resultados de testes de emissões
colocando em risco a saúde pública.

3. [POSCOMP 2010, adaptado] Sobre Engenharia de Requisitos, marque somente a

afirmação FALSA.
( ) A Engenharia de Requisitos, como todas as outras atividades de Engenharia de Software,
precisa ser adaptada às necessidades do processo, do projeto, do produto e do pessoal que está
fazendo o trabalho.
( ) No estágio de levantamento e análise dos requisitos, os membros da equipe técnica de
desenvolvimento do software trabalham com o cliente e os usuários finais do sistema para
descobrir mais informações sobre o domínio da aplicação, que serviços o sistema deve oferecer,
o desempenho exigido do sistema, as restrições de hardware, entre outras informações.

(X) Na medida em que a informação de vários pontos de vista é coletada, os requisitos

emergentes são consistentes.
( ) A validação de requisitos se ocupa de mostrar que estes realmente definem o sistema que o
cliente deseja. Ela é importante porque a ocorrência de erros em um documento de requisitos
pode levar a grandes custos relacionados ao retrabalho.

4. Cite o nome de pelo menos cinco técnicas para levantamento de requisitos.

1: Entrevista: diálogo aberto, claro e aprofundado com cada stakeholder.
 2: Observação: visão direta e realista do contexto de trabalho dos stakeholders.
3: Prototipagem: criar protótipos do sistema para visualização e interação no
primeiro momento, a fim de que haja feedbacks sobre suas funcionalidades e usabilidade.
4: Mapa mental: organiza as informações coletadas em um diagrama visual, usando
tópicos principais, subtópicos e as relações entre eles ou detalhar as funcionalidades que o
sistema deve oferecer.
5: Questionários: permitindo o alcance de um grande número de stakeholders de
forma rápida e mais eficiente.

5. No livro “Engenharia de Software Moderna”, o prof. Marco Valente descreve a

técnica de Histórias de Usuários para efetuar o levantamento de requisitos (Leia aqui Cap.
3: Requisitos – Engenharia de Software Moderna
(engsoftmoderna.info));
A partir da leitura deste trecho, escreva um caso de uso para um Sistema de Controle de
Bibliotecas (similar ao que foi usado para ilustrar a escrita de histórias).

6. O seguinte caso de uso tem apenas o fluxo normal.

Escreva extensões para ele. (Saiba sobre extensões mais em Cap. 3: Requisitos –
Engenharia de Software Moderna (engsoftmoderna.info) )

07. O que é Produto Mínimo Viável (MVP)?

(Saiba sobre mais em Cap. 3: Requisitos – Engenharia de Software Moderna
(engsoftmoderna.info) )
É uma versão inicial de um produto que possui somente os recursos essenciais para
atender as necessidades básicas dos clientes/usuários e testar a viabilidade do negócio sendo
uma ferramenta importante para empresas que desejam lançar os seus produtos de forma
rápida, investindo pouco tempo e recursos em funcionalidades que podem não ser bem-
sucedidas.

08. Quando começou, a EasyTaxi — a empresa brasileira de aplicativos para solicitação de

táxis — construiu um MVP que usava um software muito simples e uma parte operacional
realizada de forma manual. Pesquise na Internet sobre esse MVP (basta usar as palavras
EasyTaxi e MVP) e faça uma descrição do mesmo:
O aplicativo utilizava o GPS para localizar o usuário e mostrar os táxis disponíveis na
região. O tempo de chegada do táxi era estimado e o pagamento podia ser feito via cartão de
crédito ou dinheiro. A parte operacional do MVP era manual, os recepcionistas recebiam as
solicitações de corridas por telefone e as repassavam aos motoristas via rádio. Os motoristas
utilizavam rádios para receber as solicitações e se comunicar com os recepcionistas para que
os motoristas confirmassem a corrida por telefone com o passageiro.

10. Suponha que estamos em 2008, quando ainda não existia Spotify, e você decidiu criar
uma startup para oferecer um serviço de streaming de músicas na Internet. Então, como
primeiro passo, você decidiu começar com um MVP.
Quais métricas você usaria para medir o sucesso/fracasso do MVP?
As métricas a serem usadas para avaliar o sucesso/fracasso do MVP poderiam ser:
Tempo de uso; número de músicas ouvidas (média semanal ou mensal); diversidade de gêneros
musicais dos usuários; quantidade de pessoas que cancelam o serviço após um certo período;
custo; aba direcionada aos usuários para avaliarem o aplicativo e/ou sugerir melhorias quanto
ao custo/sistema de interação e interface interativa.
11. (ENADE 2011) Uma equipe está realizando testes com o código-fonte de um sistema.
Os testes envolvem a verificação de diversos componentes individualmente, bem como das
interfaces entre eles. Essa equipe está realizando testes de:
( ) unidade
( ) aceitação
( ) sistema e aceitação
( ) integração e sistema
(X) unidade e integração

12. Suponha o seguinte requisito: alunos recebem conceito A em uma disciplina se tiverem
nota maior ou igual a 90. Seja então a seguinte função que implementa esse requisito:
boolean isConceitoA(int nota) {
if (nota > 90) return true;
else return false;
}
A implementação dessa função possui um bug? Se sim, quando esse bug resulta em falha?
Sim, o bug se encontra na condição (nota > 90), a função retornará false para todas as
notas iguais a 90, o que está incorreto de acordo com o requisito. A condição deve ser alterada
para if (nota >= 90), verificando se a nota é maior ou igual a 90.

13. Sobre Refactoring, marque a alternativa FALSA:

( ) refactorings melhoram o projeto de um sistema de software.
( ) refactorings tornam o código de um sistema mais fácil de ser entendido.
( ) refactorings facilitam a localização e a correção de bugs futuros.
( ) refactorings aceleram a implementação de novas funcionalidades.

(X) refactorings melhoram o desempenho de um sistema, em termos de tempo de execução.

14. Defina e descreva o que é DevOps e quais os seus objetivos.

Um conjunto de práticas que visam integrar e unir as equipes de desenvolvimento
(Dev) e operações (Ops) de software. O objetivo principal é agilizar a entrega de software de
qualidade para os clientes, podemos citar entre eles: promover a comunicação, colaboração e
compartilhamento de responsabilidades entre as equipes (Dev e Ops) visando a otimizaçã, os
processos de desenvolvimento e operação para reduzir custos e aumentar a eficiência ou até
mesmo implementar práticas de monitoramento e segurança para garantir a confiabilidade e a
segurança do software.
15. Pesquise sobre CMMI (Capability Maturity Model Integration) e então descreva-o
com suas próprias palavras. (500 caracteres no mínimo)
É um modelo de referência para avaliação e aprimoramento de processos em
organizações. Foi desenvolvido pelo Departamento de Defesa dos Estados Unidos na década
de 1980 para avaliar a maturidade dos processos de desenvolvimento de software em empresas
contratadas com o objetivo de reduzir riscos e aumentar a confiabilidade em projetos de
grande porte.
O modelo foi baseado em modelos anteriores como o CMM (Capability Maturity
Model) e o SW-CMM (Software Capability Maturity Model) a fim de melhorar seus processos
de forma sistemática e mensurável fornecendo um conjunto de práticas que podem ser
utilizadas para identificar áreas de melhoria nos processos da organização ou atingir um nível
de maturidade que atenda às necessidades da organização e/ou dos clientes. O CMMI define
cinco níveis de maturidade para os processos de uma organização:
Nível 1- Inicial: Os processos da organização são caracterizados por serem ad-hoc e
inconsistentes. Ou seja, O sucesso depende das habilidades e da experiência dos indivíduos.
Nível 2 - Repetitivo: Os processos da organização são documentados e gerenciados,
mas ainda não são completamente padronizados.
Nível 3 - Definido: Os processos da organização são padronizados e documentados, e
existe um processo para gerenciar mudanças nos processos.
Nível 4 - Gerenciado: Os processos da organização são gerenciados de forma
quantitativa, e existe um processo para monitorar e melhorar os processos.
Nível 5 - Otimizado: Os processos da organização são continuamente otimizados para
melhorar o desempenho da organização.

É um padrão de referência que organizações de variados tamanhos e setores

podem empregar para avaliar e aperfeiçoar seus procedimentos. A incorporação do
CMMI pode resultar em inúmeros ganhos para as organizações, tais como
aprimoramento da qualidade do software, elevação da eficiência produtiva e a satisfação
do cliente.