Aula 04

Engenharia de Software para Concursos - Curso Regular

Professor: Diego Carvalho
 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 04

AULA 04

SUMÁRIO PÁGINA
Apresentação 01
- Engenharia de Requisitos 03
Lista de Exercícios Comentados 81
Gabarito 105

16712855225

Prof. Diego Carvalho [Link] Pág. 1 de 106

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 04

Engenharia de Software. Conceitos Básicos ou Gerais. Ciclo de vida do software. Modelos,

Metodologias ou Processos de Desenvolvimento de Software: Modelo em Cascata. Modelo Orientado
a Reuso. Modelo em Prototipagem, Modelo Evolucionário, Modelo Espiral, Modelo Formal, RAD, Modelo
Iterativo e Incremental. Processo Unificado: Conceitos Básicos, Dimensões Dinâmica, Estática e
Prática, Gráfico das Baleias, Fases (Iniciação, Elaboração, Construção e Transição), Disciplinas ou
Fluxo de Processos (Modelagem de Negócio, Requisitos, Análise e Projeto, Implementação, Teste,
Implantação, Gestão de Configuração e Mudança, Gestão de Projetos, Ambiente), Artefatos,
Atividades, Melhores Práticas, Principais Marcos, Princípios Chaves. Metodologias Ágeis de
Desenvolvimento de Software: Scrum, eXtreme Programming (XP), Feature-driven Development
(FDD), Test-driven Development (TDD), Acceptance Test-driven Development (ATDD), Kanban.
Definição de Requisito, Classificação de Requisitos (Funcional, Não- Funcional, Domínio; Produto,
Organizacional, Externo; Confiabilidade, Proteção, Desempenho, etc); Engenharia de Requisitos:
Estudo de Viabilidade, Elicitação e Análise de Requisitos, Especificação de Requisitos, Validação de
Requisitos, Gestão de Requisitos. Técnicas de Elicitação e Técnicas de Validação. Linguagem de
Modelagem: Unified Modeling Language (UML) 2.x – Contexto Histórico, Conceitos Básicos, Tipos de
Diagramas (Estruturais, Comportamentais, Interação). Diagramas de Classes, Componentes,
Implantação, Perfil, Objetos, Estrutura Composta, Pacotes, Máquina de Estados, Casos de Uso,
Atividades, Sequência, Comunicação, Interação Geral e Tempo. Conceitos Básicos do Paradigma
Estruturado. Conceitos Básicos de Orientação a Objetos: Classes, Objetos, Atributos, Métodos,
Mensagens, Abstração, Encapsulamento, Polimorfismo, Herança, Relacionamentos). Análise e
Projeto: Conceitos Básicos, Diferenças, Modelos, Classes de Fronteira, Controle e Entidade. Análise
de Pontos de Função: IFPUG – Definição e Contexto, Benefícios e Vantagens, Componentes de Dados
(AIE, ALI) e Transação (EE, SE, CE), Etapas do Procedimento de Contagem: Determinar Tipo de
Contagem, Determinar Escopo e Fronteira, Cálculo dos Pontos de Função Não-Ajustados, Cálculo do
Fator de Ajuste, Cálculo dos Pontos de Função Ajustados. NESMA - Tipos de Contagem e Deflatores.
Qualidade de Software: Garantia e Controle, Principais Características, Verificação & Validação,
Erro, Falha, Falta e Defeito. Testes de Software: Conceitos Básicos, Processo de Testes, Técnicas de
Testes (Teste Caixa Banca, Cinza e Preta), Níveis de Testes (Teste de Unidade, Módulo, Componente;
16712855225

Teste de Integração; Teste de Aceitação, Validação, Release; Teste de Sistema/Funcional). Tipos de

Testes: Carga, Estresse, Volume, Desempenho, Usabilidade, Cenários, Regressão, Back-to-Back,
Comparação, Recuperação, Alfa, Beta, Compatibilidade, Estático, Dinâmico). Arquitetura de
Software. Arquitetura em Camadas (Cliente/Servidor). Arquitetura MVC. Arquitetura Distribuída.
Arquitetura Hub. Arquitetura Microsserviços. Arquitetura Mainframe. Arquitetura Orientada a
Serviços (SOA): Conceitos Básicos, SOAP, WSDL, UDDI. REST. WS-Security. Interoperabilidade de
Sistemas. e- PING: Conceitos Básicos, Interoperabilidade, Escopo, Políticas Gerais, Segmentação,
Gestão. Acessibilidade de Sistemas. e-MAG 3.1: Conceitos Básicos, Acessibilidade, Acesso, Passos
para um Sítio Acessível, Segmentos, Recomendações. Engenharia de Usabilidade. Gerenciamento
Eletrônico de Documentos (GED). Portais Corporativos e Colaborativos.

Prof. Diego Carvalho [Link] Pág. 2 de 106

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 04

REQUISITOS

Cara, esse é um conceito bem tranquilo de entender! Vamos passar para a vida
real? É época de matrícula na faculdade e você cursa o 2º Semestre de Ciência da
Computação, mas você quer pegar uma disciplina lá do 8º Semestre! No entanto,
há um pequeno detalhe! Essa disciplina provavelmente contém diversos pré-
requisitos que você tem que cumprir para fazê- .

Querem outro exemplo? Vamos para a área jurídica! Algum de vocês aí quer mudar
o Brasil e decide se candidatar à presidência da república! Espera um pouco... para
tal, devem ser cumpridos alguns requisitos: ser filiado a um partido político; ter
domicílio eleitoral na circunscrição; ter realizado o alistamento eleitoral (caso seja
homem); estar em pleno exercício dos direitos políticos; e ser brasileiro nato.

Pois é... mesmo cumprindo todos esses requisitos, ainda falta mais um: ter idade
mínima de 35 anos! Satisfeitos esses requisitos, você – revolucionário que irá mudar
nossa nação – poderá ser candidato à presidência. Bacana, pessoal? Na vida real
fica bem tranquilo de compreender o que é um requisito! É natural, pois faz parte
do nosso cotidiano.

O verbo requisitar é o mesmo que pedir, solicitar, exigir algo que seja condição
necessária para alguma finalidade específica. Grosso modo, o requisito é uma
condição ou exigência indispensável para um fim determinado. Vocês se lembram
do RUP? Ele conceitua requisito como uma condição ou capacidade com a qual o
sistema deve estar de acordo.

Na Engenharia, costuma-se definir requisito como uma propriedade ou

16712855225

comportamento que um produto ou serviço deve atender. Na Engenharia de

Software, dizemos que um requisito é a condição que deve ser satisfeita para se
alcançar um objetivo, ou a qualidade do sistema que deve ser provida para ser útil
a seus usuários.

Bem, esses conceitos são todos muito parecidos e é fácil de associar a situações
comuns em nossas vidas. Requisito, assim como todos os outros conceitos que
derivam dele, é muito importante e é quase certeza que cairá em sua prova. E digo
mais, isso é um tema clássico de provas discursivas! Portanto, tenham esses
conceitos perfeitamente guardados em suas memórias. Ok? ;)

Prof. Diego Carvalho [Link] Pág. 3 de 106

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 04

CLASSIFICAÇÃO DE REQUISITOS

Vamos falar um pouco agora sobre as classificações de requisitos – existem várias!

Alguns dos problemas que ocorrem durante o processo de engenharia de requisitos
são resultado da falha em se fazer uma clara separação entre os níveis de abstração
da descrição dos requisitos. Galera, usuários são leigos e eles não têm a menor
obrigação de entender detalhes técnicos. Dito isso, vamos às classificações!

Classificação quanto ao Nível de Abstração

 Requisitos de Usuário: descrições, em linguagem natural e com diagramas, de

quais serviços o sistema deve fornecer e as restrições sob as quais deve operar.
São requisitos com alto nível de abstração e poucos detalhes, feitos para serem
lidos por pessoas leigas – podem ser funcionais ou não funcionais.

o Exemplo: O software deve fornecer um meio de representar e acessar

arquivos externos criados por outras ferramentas.

 Requisitos de Sistema: descrições detalhadas sobre as funções, operações e

restrições de sistema que definem exatamente o que deve ser implementado.
São requisitos com baixo nível de abstração e muitos detalhes, feitos para serem
lidos por pessoas experientes – podem ser funcionais ou não funcionais.

o Exemplo: O usuário deve dispor de recursos de tecnologia assistiva para

acessar dados de bancos externos.

Professor, isso é só para complicar a minha vida? Não, pessoal! Isso tem a sua
utilidade! Deve-se escrever os requisitos em diferentes níveis de detalhamento,
tendo em vista que os leitores os utilizam de maneiras diferentes. Usuários
16712855225

geralmente não dão a mínima para como o sistema será implementado. Já os

leitores de requisitos de sistema necessitam de detalhes mais exatos e precisos.

Classificação quanto à Qualidade

O Quality Function Deployment (QFD) é uma técnica de gestão da qualidade que

traduz as necessidades do cliente para requisitos técnicos. O QFD “concentra-se em
maximizar a satisfação do cliente por meio do processo de engenharia de software”.
Para tal, enfatiza o entendimento do que é valioso para o cliente e emprega esses
valores ao longo do processo de engenharia.

Prof. Diego Carvalho [Link] Pág. 4 de 106

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 04

 Requisitos Normais: refletem os objetivos e metas estabelecidos para um

produto ou sistema durante reuniões com o cliente. Se esses requisitos estiverem
presentes, o cliente fica satisfeito. Exemplos de Requisitos Normais poderiam ser
tipos de displays gráficos solicitados, funções de sistema específicas e níveis de
desempenho definidos.

 Requisitos Esperados: estão implícitos no produto ou sistema e podem ser tão

fundamentais que o cliente não os declara explicitamente. Sua ausência será
causa de grande insatisfação. Exemplos de Requisitos Esperados: facilidade na
interação homem-máquina, confiabilidade e correção operacional global e
facilidade na instalação do software.

 Requisitos Fascinantes: esses recursos vão além da expectativa dos clientes e

demonstram ser muito satisfatórios quando presentes. Por exemplo, o software
para um novo celular vem com recursos-padrão, mas junto vem um conjunto de
capacidades não esperadas. Exemplos de Requisitos Fascinantes: tecla
multitoque e correio de voz visual.

Classificação quanto a Evolução e Manutenção

 Requisitos Permanentes: também chamados de Requisitos Estáveis, estão

diretamente ligados a atividade principal da organização. São concebidos com
a essência de um sistema e seu domínio da aplicação, e mudam mais lentamente
que requisitos voláteis. Em geral, eles são derivados do Modelo de Domínio.

 Requisitos Voláteis: também chamados de Requisitos Instáveis, são específicos

para a instanciação de um sistema em um ambiente ou um cliente particular e
são mais propensos a mudança. Se modificam quando o sistema está em
desenvolvimento ou em uso. Podem ser: 16712855225

o Mutáveis: são os requisitos que se modificam em função de mudanças no

ambiente no qual o sistema opera. Por exemplo, os requisitos para um
sistema que calcula taxas de dedução que evolui conforme as leis fiscais são
atualizadas (muito comum no Brasil).

o Emergentes: são os requisitos que não podem ser completamente definidos

quando o sistema é especificado e emergem (olha a dica!) à medida que a
compreensão do cliente sobre o sistema se desenvolve. Em geral, eles só
aparecerão durante o desenvolvimento.

Prof. Diego Carvalho [Link] Pág. 5 de 106

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 04

o Consequentes: são os requisitos baseados em suposições de como o sistema

será utilizado, isto é, são resultado da introdução do sistema no ambiente do
usuário. O usuário percebe as necessidades enquanto utiliza o sistema e esses
requisitos são uma consequência (olha a dica!) do uso.

o De Compatibilidade: são os requisitos que dependem de outro equipamento,

processo, componente ou elemento. Conforme outros elementos mudam,
esses requisitos também mudam. Esses são requisitos menos comuns, mas
que também ocorrem.

Classificação quanto à Funcionalidade

Percebam o seguinte: podemos classificar requisitos de diversas maneiras. No

entanto, não se discute que a classificação de requisitos quanto a sua funcionalidade
é, com total e absoluta certeza, a classificação mais tradicional e mais
frequentemente cobrada em provas. Galera, isso vai cair na sua prova objetiva e
talvez até na sua prova discursiva, mas fiquem tranquilos porque é fácil ;)

Requisitos Funcionais: são declarações de serviços que um sistema deve fornecer,

como o sistema deve reagir a entradas específicas e como o sistema deve (ou não)
se comportar em situações particulares. Depende do tipo de software, dos usuários
esperados e do tipo de sistema onde o software será implantado. Eles fazem parte
da arquitetura do aplicativo de um sistema.

Problemas dos Requisitos Funcionais: frequentemente, requisitos funcionais não são

estabelecidos precisamente. Há descrições de requisitos ambíguos, que permitem
diversas interpretações; há também requisitos incompletos, que não descrevem
toda a funcionalidade do serviço; e há requisitos inconsistentes, que contradizem
outros requisitos do sistema. 16712855225

Exemplos de Requisitos Funcionais

 Pensemos em um Requisito do Outlook:

o Sistema deverá fornecer opção de filtrar e-mails por Assunto e Anexos.
 Pensemos em um Requisito do Youtube:
o Sistema deverá reagir com suspensão de vídeos que ferem direito autoral.
 Pensemos em um Requisito do GoogleMaps:
o Sistema deverá procurar rua mais próxima, caso não encontre a desejada.

Prof. Diego Carvalho [Link] Pág. 6 de 106

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 04

Requisitos Não-Funcionais: são restrições nos serviços ou funções oferecidas pel

sistema. Não estão diretamente relacionados às funções específicas do sistema, mas
às gerais e podem incluir restrições de tempo, processo de desenvolvimento e
restrições impostas por padrões. Podem ser mais críticos que os funcionais e sempre
devem ser verificáveis. Eles fazem parte da arquitetura técnica de um sistema.

Problemas de Requisitos Não-Funcionais: frequentemente, requisitos não-

funcionais são bastante difíceis de se especificar objetivamente. Para tal, utilizam-se
medidas que possam ser testadas ou mensuradas. No entanto, o problema mais
comum são os requisitos conflitantes. Por exemplo, o cliente deseja um
desempenho altíssimo, mas quer que o sistema tenha baixo custo.

Exemplos de Requisitos Não-Funcionais

 Pensemos em um Requisito do Whatsapp:

o Sistema deverá fornecer disponibilidade mínima de 99,8%.
 Pensemos em um Requisito do Facebook:
o Sistema deverá ser desenvolvido na Linguagem Java.
 Pensemos em um Requisito do Android:
o Sistema deverá ser capaz de rodar com apenas 1Gb de RAM.

Requisitos de Domínio: são requisitos derivados do domínio da aplicação e refletem

características de sua área de negócio. Eles podem ser requisitos funcionais ou não-
funcionais e, caso não sejam satisfeitos, o sistema pode não ser realizável. Por
exemplo, um avião que não atende aos requisitos de confiabilidade, não será
certificado para voo.

Problemas de Requisitos de Domínio frequentemente, requisitos de domínio são

descritos na linguagem ou jargão do domínio da aplicação. Especialistas de domínio
16712855225

compreendem tão profundamente assuntos sobre a sua área que eventualmente

eles deixam de detalhar informações importantes, por acharem que são óbvias
demais ou que já estão subentendidas.

Exemplos de Requisitos de Domínio:

 Pensemos em um Requisito da USP:

o Sistema deverá calcular a nota final da prova de mestrado segundo a
fórmula (1.74N1+3.17N2 + 2.59N3)/3 * IRA (Aluno).
 Pensemos em um Requisito da STN:

Prof. Diego Carvalho [Link] Pág. 7 de 106

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 04

o Sistema deverá calcular o valor do Título Público NTN-B multiplicado pelo

valor da Taxa SELIC do mês corrente.
 Pensemos em um Requisito da NASA:
o Sistema deverá funcionar em uma Câmera 4K captando infravermelho e
resistente a variações de temperatura.

IMPORTANTE

Os Requisitos de Domínio são um pouco problemáticos e, muitas vezes, inúteis. Curiosamente,

na última edição do livro do Sommerville, deu-se bem menos destaque. Para quem ainda não
os entendeu, vejamos: no sistema de uma Biblioteca, pode existir o requisito "Permitir
adicionar livro"; no sistema de uma Locadora, pode existir o requisito "Permitir adicionar
filme"; no sistema de uma loja de Instrumentos Musicais, pode existir o requisito "Permitir
adicionar guitarra".

Vocês percebem que, de modo geral, é tudo a mesma coisa? Pois é! Agora imaginem o
requisito "Permitir que o valor do Título Público NTN-B possa ser multiplicado pelo valor da
Taxa Selic corrente quando essa for menor que 0,5% ao mês". Ora, esse requisito
dificilmente poderá ser aplicado em algum outro contexto que não seja aquele específico de
um sistema/domínio de venda de títulos da dívida pública, portanto, trata-se de um Requisito
de Domínio.

De acordo com Sommerville: a distinção entre esses diferentes tipos de requisitos

não é tão clara como sugere essas definições. Um requisito pode parecer-se
inicialmente não funcional, mas quando desenvolvido com mais detalhes pode dar
origem a uma série de novos requisitos funcionais. Ao discutirmos sobre requisitos
devemos levar em conta que na realidade a distinção entre eles é artificial.
16712855225

Nosso autor ainda diz que os requisitos não funcionais estão raramente associados
às características individuais do sistema. Tratam-se de qualidades globais de um
software, como manutenibilidade, usabilidade, desempenho, custos e várias outras.
Normalmente estes requisitos são descritos de maneira informal. Galera, em geral,
afetam a arquitetura do sistema.

Classificação quanto à Origem

Agora vamos partir para outra classificação um pouco menos importante!

Pesquisadores observaram que os requisitos não-funcionais também podiam ser
agrupados por meio de suas características comuns. Para tanto, criou-se a

Prof. Diego Carvalho [Link] Pág. 8 de 106

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 04

subclassificação dos requisitos não-funcionais em: requisitos de produto, requisitos

organizacionais e requisitos externos.

 Requisitos de Produto: especificam o comportamento do produto. Entre os

exemplos, estão requisitos de desempenho quanto à rapidez com que o sistema
deve operar e quanto de memória ele requer, requisitos de confiabilidade que
definem a taxa aceitável de falhas, requisitos de portabilidade e requisitos de
usabilidade.

 Requisitos Organizacionais: são derivados de políticas e procedimentos da

organização do cliente e do desenvolvedor. Entre os exemplos, estão padrões
de processo que devem ser usados, linguagem de programação ou o método
de projeto usado, e requisitos de entrega que especificam quando o produto e
a sua documentação devem ser entregues.

 Requisitos Externos: abrange todos os requisitos derivados de fatores externos

ao sistema e seu processo de desenvolvimento. Entre os exemplos, estão a
interoperabilidade que define como o sistema interage com outros sistemas,
requisitos legais que devem ser seguidos, requisitos éticos sistema para
assegurar que ele será aceito por todos.

IMPORTANTE

A Interoperabilidade é um requisito de Produto, Organizacional ou Externo? Estou citando

essa funcionalidade específica, porque já vi diversas pessoas pensando que é de Produto. Na
verdade, ela é um Requisito Externo, porque depende de padronizações fora de seu controle.

Acabaram as classificações, professor? Infelizmente, não! Cada uma dessas três

16712855225

subclassificações se dividem também em várias outras, como mostra a imagem

abaixo. Cabe salientar que essa classificação está em conformidade com a 9ª Edição
do Sommverville, em que há pequenas diferenças quanto à mesma imagem de
edições anteriores. Vamos lá!

REQUISITOS EXEMPLOS

REQUISITOS DE O sistema não deve ficar fora do ar por mais de cinco

CONFIABILIDADE segundos durante o dia.

Prof. Diego Carvalho [Link] Pág. 9 de 106

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 04

REQUISITOS O sistema não deve permitir que os usuários modifiquem

DE PROTEÇÃO senhas de acesso que eles não criaram.
REQUISITOS O sistema deverá ser capaz de processar oitocentas
DE DESEMPENHO requisições por segundo.
REQUISITOS DE ESPAÇO (OU O sistema deverá ocupar, no máximo, 80Mb da memória
ARMAZENAMENTO) interna do dispositivo.
REQUISITOS Os usuários deverão operar todas as funcionalidades do
DE USABILIDADE sistema após 2 horas de treino.
REQUISITOS O sistema não deve permitir a ativação simultânea de mais
DE SEGURANÇA de três sinais de alarme.
REQUISITOS O sistema não apresentará aos usuários quaisquer dados
ÉTICOS de natureza confidencial de outrem.
REQUISITOS DE A interface de usuário deve ser implementada em HTML e
IMPLEMENTAÇÃO não se deve utilizar Applets de Java.

REQUISITOS X REGRAS DE NEGÓCIO

Requisitos tratam do funcionamento de um sistema e Regras de Negócio tratam do

funcionamento de um negócio, sendo independentes de um sistema específico. Vamos ver um
exemplo no contexto de um caixa eletrônico?

1. O Sistema deve sacar da conta a quantia determinada pelo usuário – trata-se de um

Requisito Funcional, visto que é uma funcionalidade oferecida pelo sistema.

2. O Limite de Saque é de R$1000 por dia – trata-se de uma Regra de Negócio, visto que
é uma regra do banco e não só do sistema.
16712855225

Eventualmente, há uma confusão entre Requisitos Funcionais e Requisitos Não-Funcionais.

Por exemplo:

1. O Sistema deve conter uma política de controle de acesso – trata-se de um Requisito

Não-Funcional, visto que isso não é uma funcionalidade em si.

2. O Sistema não deve permitir que usuários com Perfil X alterem dados – trata-se de
um Requisito Funcional, visto que é uma restrição à funcionalidade e, não, ao sistema.

Prof. Diego Carvalho [Link] Pág. 10 de 106

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 04

16712855225

Prof. Diego Carvalho [Link] Pág. 11 de 106

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 04

ENGENHARIA DE REQUISITOS

Pessoal, considerem a seguinte hipótese: vocês fazem uma excelente prova objetiva
e partem para a prova discursiva. O primeiro item pede a definição de Requisito!
Bem, vocês abrem um sorrisão e respondem! O segundo item pede a definição de
Engenharia de Requisitos. Bem, agora não tem mais sorrisão! Esse é um conceito
que todo mundo sabe, mas que é difícil de colocar no papel.

Porém, vocês enrolam e conseguem responder. Aí vem o terceiro item, que pede
as fases do processo de engenharia de requisitos! E aí, quantos de vocês
conseguiriam responder? Estão vendo como é complicado? Então vamos entender
tudo isso... esse termo foi utilizado pela primeira vez na década de 70 em um
relatório técnico da TRW Inc., mas não chegou a se tornar um jargão.

Ele só ficou, de fato, mais conhecido na década de 90 com a publicação de um

tutorial da IEEE e a criação de uma série de conferências sobre esse assunto. Ok,
mas qual é a definição de Engenharia de Requisitos? Ora, ela pode ser definida como
uma abordagem sistemática para a formulação, análise, documentação e
manutenção de requisitos de um sistema. Fácil, né?! ;)

Pessoal, essa é a fase mais crítica no desenvolvimento de um software, tendo em

vista que erros durante esse estágio conduzem inevitavelmente a problemas
posteriores no projeto e na implementação do sistema. Sabe-se que muitos
engenheiros se perguntam como assegurar que eles especificaram um sistema
exatamente de acordo com as necessidades dos clientes.

Bem, não há uma resposta perfeita para esse questionamento, contudo um sólido
processo de engenharia de requisitos é capaz de encontrar a melhor solução viável
no momento. Percebam que é praticamente impossível satisfazer absolutamente
16712855225

todas as expectativas dos clientes, na medida em que requisitos podem ser bastante
complexos e voláteis.

Na prática, todos os requisitos de sistema se modificam. Isso ocorre, porque as

pessoas envolvidas desenvolvem uma compreensão maior do que desejam que o
software faça; a própria organização que está comprando o sistema muda;
modificações são feitas no hardware, software e no ambiente organizacional do
sistema; entre outros.

Prof. Diego Carvalho [Link] Pág. 12 de 106

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 04

O Engenheiro de Software da IBM, Fred Brooks diz: “A parte mais

árdua na construção de um sistema de software consiste em decidir o
que construir! Nenhuma outra fase do processo de desenvolvimento
compromete tanto o resultado final do sistema se feita errada e
nenhuma outra dificulta tanto as correções posteriores”.

SEGUNDO MIRANDA (2002 APUD SANTOS, 2007, P.12):

50% dos principais defeitos de software são oriundos da fase de especificação de software.
12% das principais causas de fracassos em projetos são oriundos de requisitos incompletos.
12% das principais causas de sucesso em projetos são oriundos de requisitos consistentes.

16712855225

A Engenharia de Requisitos fornece um mecanismo adequado para compreender o

que o cliente deseja, para analisar as necessidades, para avaliar a viabilidade, para
negociar uma solução razoável, para especificar um solução não-ambígua, para
validar a especificação e para gerenciar os requisitos à medida que eles são
transformados em um sistema operacionalizável.

Enfim, chegamos à última pergunta! Quais são as fases do processo de Engenharia

de Requisitos? Bem, há duas respostas para essa pergunta! Como assim, professor?
É que há uma divergência entre os principais autores. Nós vamos nos aprofundar

Prof. Diego Carvalho [Link] Pág. 13 de 106

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 04

nas fases do Sommerville, porque ele é o mais cobrado em provas nesse quesito,
porém não custa nada ver também as fases do Pressman abaixo:

Concepção: após uma necessidade de o negócio ser identificada, busca-se

estabelecer um entendimento básico do problema. Trata-se da concepção inicial
do software e busca entender o problema, quem são os envolvidos, a natureza
da solução e iniciar o processo de comunicação entre clientes e colaboradores.

Levantamento: etapa crítica, utiliza uma abordagem organizada para descobrir

o que o cliente deseja em seu sistema. Envolve intensa participação do
stakeholders e faz três perguntas: Qual o objetivo do produto? Como o produto
se enquadra nas necessidades do negócio? Como o produto será utilizado?

Elaboração: informações obtidas do cliente durante a concepção e levantamento

são expandidas e refinadas em um modelo, definindo o domínio do problema.
Incluem-se modelagens de cenários de interação do usuário com o sistema e
modelagens das classes envolvidas (e a relação entre elas).

Negociação: tem por objetivo chegar a um consenso sobre os conflitos entre

clientes e usuários, por intermédio de um processo de negociação. Os requisitos
são avaliados junto ao cliente e podem ser combinar, excluir ou até mesmo
inserir novos requisitos.

Especificação: produto final do engenheiro de requisitos, pode ser um

documento escrito, um modelo gráfico, cenários de uso, protótipos, etc. Trata-
se da apresentação formal dos dados obtidos até o momento de modo que
possa guiar o desenvolvimento futuro do software.

Validação: os produtos de trabalho resultantes da engenharia de requisitos são

16712855225

avaliados quanto a sua qualidade por todos os envolvidos (clientes,

colaboradores e usuários). Buscam-se erros de interpretação, ambiguidades e
omissões.

Gestão: conjunto de atividades que auxiliam a equipe de projeto a identificar,

controlar e rastrear requisitos e mudanças nos requisitos a qualquer momento1.
Para projetos de grande porte, é uma fase essencial na medida em que
mudanças em um requisito podem afetar diversos outros requisitos.

1
Para tal, recomenda-se utilizar tabelas de rastreamento de características, fontes, dependências, subsistemas
e interfaces.

Prof. Diego Carvalho [Link] Pág. 14 de 106

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 04

POR SOMMERVILLE POR PRESSMAN

Estudo de Viabilidade Concepção

Elicitação e Análise de Requisitos Levantamento

- Obtenção de Requisitos Elaboração

- Classificação e Organização
- Priorização e Negociação Negociação
- Documentação de Requisitos
Especificação Especificação

Validação Validação

Gestão Gestão

Muito bem! Se vocês respondessem a prova discursiva com essas fases, estaria
perfeitamente correto. Acima podemos ver uma comparação entre as fases de
acordo com ambos os autores. Lembrando que essas fases buscam produzir um
documento de requisitos que especifique um sistema e satisfaça os requisitos dos
stakeholders. Entendido? ;)

Bem, chegou a hora de eu ganhar alguns inimigos! Por muito tempo, eu deixei isso
fora da aula para evitar que isso acontecesse, mas eu cheguei à conclusão de que
pode ajudar muita gente – além de ser apenas uma bobagem! Bem, quando eu
estudava esse assunto, eu criei mnemônicos para decorar as fases de cada autor.
16712855225

Espero que ajudem vocês a decorarem.

FASES PRESSMAN: CLUBE ENERGÚMENO: VASCO DA GAMA

CONCEPÇÃO > LEVANTAMENTO > ELABORAÇÃO > NEGOCIAÇÃO >

ESPECIFICAÇÃO > VALIDAÇÃO > GESTÃO

Prof. Diego Carvalho [Link] Pág. 15 de 106

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 04

FASES SOMMERVILLE: ESTÃO VIABILIZANDO ELIANA ESPECIALMENTE NO VASCO DA GAMA

ESTUDO DE VIABILIDADE > ELICITAÇÃO E ANÁLISE DE REQUISITOS >

ESPECIFICAÇÃO > VALIDAÇÃO > GESTÃO

Vascaínos, peço que não se sintam ofendidos. Isso é apenas uma maneira que eu
encontrei para decorar tempos atrás e que efetivamente me ajudou muito. Caso
vocês conheçam outros mnemônicos para decorar essas fases, eu posso
gentilmente trocá-los. Estou colocando-os aqui apenas para ajudá-los, caso haja
muitas reclamações, eu posso retirá-los. Prosseguindo...

A imagem abaixo apresenta graficamente as fases da Engenharia de Requisitos de

16712855225

acordo com Sommerville. São elas: Estudo de Viabilidade, Elicitação e Análise de

Requisitos, Especificação de Requisitos e Validação de Requisitos. Por fim, há uma
última fase que envolve todas as anteriores e também é de suma importância:
Gerenciamento de Requisitos.

Prof. Diego Carvalho [Link] Pág. 16 de 106

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 04

Sommerville afirma que o objetivo da engenharia de requisitos é criar e manter um

documento de requisitos de sistema. As fases são: avaliação de se o sistema é útil
para a empresa (Estudo de Viabilidade); obtenção de requisitos (Elicitação e Análise);
conversão desses requisitos em alguma forma-padrão (Especificação); e verificação
de se os requisitos realmente definem o sistema que o cliente deseja (Validação).

16712855225

Prof. Diego Carvalho [Link] Pág. 17 de 106

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 04

ESTUDO DE VIABILIDADE

É a realização de uma avaliação relativamente rápida e barata para verificar se as

necessidades identificadas dos usuários podem ser satisfeitas por meio das
tecnologias atuais de sistemas de software e hardware. O resultado dessa avaliação
deve fornecer informações para a tomada de decisão quanto a prosseguir para uma
análise mais detalhada ou não.

Ele deve ser um estudo curto e bem focado, devendo ser realizado no início do
processo de engenharia de requisitos e, ao final, deverá entregar um relatório de
viabilidade. Além disso, o Estudo de Viabilidade deve responder às três questões
principais em que – caso alguma delas tenha uma resposta negativa – o projeto não
deve seguir adiante. São elas:

1. O sistema contribui para os objetivos gerais da organização?

2. O sistema pode ser implementado com tecnologia atual e dentro do custo e prazo?
3. O sistema pode ser integrado a outros sistemas já implantados?

As respostas para essas três questões não é algo simples de ser obtido, visto que
geralmente a empresa não tem a exata definição de seus objetivos. Para ajudar
nesta definição, questões podem ser levantadas e, com as respostas em mãos,
pode-se concluir se o desenvolvimento do sistema deve prosseguir ou não; pode-
se propor alterações de escopo, orçamento, prazo, etc.

1. Se o sistema não fosse implementado, qual seria o rumo da organização?

2. Quais são as falhas dos processos atuais e quais soluções o novo sistema traria?
3. Quanto aos objetivos e requisitos, qual a contribuição direta do novo sistema?
4. Existe a possibilidade de integração com outros sistemas?
5. Quais das tecnologias serão novas?
16712855225

6. O que o novo sistema irá apoiar?

Prof. Diego Carvalho [Link] Pág. 18 de 106

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 04

ELICITAÇÃO E ANÁLISE DE REQUSIITOS

É o processo de levantamento e derivação de requisitos de sistema através da

observação de sistemas existentes, discussões com usuários potenciais e
compradores, análise de tarefas, etc. Isso pode envolver o desenvolvimento de um
ou mais modelos de sistema e protótipos, que ajudam o analista a compreender o
sistema a ser especificado.

Elicitar é o mesmo que descobrir, identificar, deduzir, extrair, evocar, obter

informações sobre uma questão específica. Para tal, os engenheiros de software
trabalham com os clientes e usuários finais para aprender sobre o domínio da
16712855225

aplicação, quais serviços o sistema deve fornecer, o desempenho esperado,

restrições de hardware, entre outros.

Pessoal, por que dizem por aí que a elicitação

e compreensão de requisitos é tão difícil? Ora,
muitas vezes, os stakeholders não sabem o
que querem; outras vezes, deixam dados de
seu domínio implícitos por pensarem que são
óbvios; há, também, casos em que os
requisitos são conflitantes; além de fatores
políticos, econômicos e de negócio que

Prof. Diego Carvalho [Link] Pág. 19 de 106

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 04

podem influenciar o levantamento de requisitos do sistema. As principais atividades

do processo de elicitação e análise de requisitos são:

Obtenção de Requisitos: processo de interação com os stakeholders para

coletar requisitos. Os requisitos de domínio também são descobertos durante
essa atividade.

Classificação e organização de requisitos: esta atividade envolve a coleção de

requisitos não estruturados, agrupa os requisitos relacionados e os organiza
em conjuntos coerentes.

Priorização e negociação de requisitos: inevitavelmente, os requisitos serão

conflitantes. Assim, busca-se priorizar os requisitos e resolver conflitos por
meio da negociação.

Documentação de requisitos: os requisitos são documentados e colocados

na próxima volta da espiral. Podem ser produzidos documentos de requisitos
formais ou informais.

16712855225

Pessoal, um dos temas campeões em prova se refere às técnicas de elicitação.

Professor, são realmente necessárias técnicas para levantar requisitos? Sim, pessoal!
Como eu já repeti diversas vezes, levantar requisitos é uma tarefa árdua. Portanto,
para ajudar a assegurar uma cobertura ampla dos requisitos, utilizam-se as
seguintes técnicas (sublinhei as que mais caem em prova):

Entrevistas:

Prof. Diego Carvalho [Link] Pág. 20 de 106

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 04

Entrevistas formais ou informais com os stakeholders no sistema fazem parte da

maioria dos processos de engenharia de requisitos. Nessas entrevistas, a equipe de
engenharia de requisitos formula questões para os stakeholders sobre o sistema que
eles usam e o sistema a ser desenvolvido. Os requisitos são derivados das respostas
a essas questões.

As entrevistas podem ser abertas, quando não há um roteiro predefinido ou podem

ser fechadas, quando há um roteiro pronto. Na prática, as entrevistas com os
stakeholders são, geralmente, uma combinação desses tipos. As respostas a
algumas perguntas podem levar a outros assuntos discutidos de maneira menos
estruturada.

As discussões completamente abertas raramente funcionam bem; a maioria das

entrevistas requer algumas perguntas como ponto de partida e para manter o foco
no sistema a ser desenvolvido. As entrevistas são úteis para obter um entendimento
geral sobre o que os stakeholders fazem, como eles podem interagir com o sistema
e as dificuldades que enfrentam com os sistemas atuais.

As pessoas gostam de falar sobre seu trabalho e, normalmente, ficam felizes em

participar de entrevistas. No entanto, as entrevistas não são tão úteis para
compreender os requisitos do domínio da aplicação. Não é eficiente para elicitação
de conhecimentos sobre os requisitos e as restrições organizacionais, pois existem
relacionamentos sutis de poder e influência entre os stakeholders.

As estruturas organizacionais públicas raramente coincidem com a realidade da

tomada de decisões na organização, mas os entrevistados podem não querer
revelar a estrutura real, em lugar da teórica, a um estranho. Em geral, a maioria das
pessoas é relutante em discutir questões políticas e organizacionais que podem
16712855225

afetar os requisitos.

Etnografia:

Técnica de observação utilizada para compreender os requisitos organizacionais e

sociais. Coloca o analista dentro do campo de atuação dos usuários, observando o
trabalho diário anotando as tarefas reais em que os participantes estão envolvidos.
Essa é uma técnica utilizada em conjunto com outras técnicas para descobrir
requisitos implícitos.

Prof. Diego Carvalho [Link] Pág. 21 de 106

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 04

O valor da etnografia está na ajuda que presta aos analistas para descobrir os
requisitos implícitos de sistema que refletem os processos reais, e não os formais,
com os quais as pessoas estão envolvidas. As pessoas frequentemente consideram
muito difícil articular detalhes de seu trabalho rotineiro, na medida em que isso é
secundário para elas.

Elas compreendem seu próprio trabalho, mas podem não compreender seu
relacionamento com o trabalho de outros na organização. Os fatores sociais e
organizacionais, que afetam o trabalho, mas que não são óbvios para as pessoas,
podem somente se tomar claros quando examinados por um observador imparcial
– por isso, a etnografia é importante!

Cenários:

As pessoas geralmente consideram mais fácil relatar exemplos da vida real do que
abstrair descrições. Elas podem compreender e criticar um cenário de como
interagiriam com um sistema de software. Os engenheiros de requisitos podem usar
as informações obtidas nessa discussão para elaborar os requisitos reais do sistema
de software.

Os cenários podem ser particularmente úteis para adicionar detalhes a um esboço

da descrição de requisitos. Eles são descrições de exemplos das sessões de
interação. Cada cenário abrange uma ou mais interações possíveis. Diversos tipos
de cenários foram desenvolvidos, cada um dos quais fornecendo diferentes tipos de
informações sobre o sistema em diferentes níveis de detalhamento.

O uso de cenários para descrever requisitos é parte integrante dos métodos ágeis,
como a Extreme Programming. O cenário começa com um esboço da interação e,
durante a elicitação, os detalhes são adicionados para criar uma descrição completa
16712855225

dessa interação. A elicitação baseada em cenários pode ser realizada também de

informalmente.

Os engenheiros de requisitos trabalham com os stakeholders para identificar

cenários e captar os detalhes desses cenários. Os cenários podem ser escritos na
forma de textos, complementados por diagramas, imagens de computador etc.
Como alternativa, pode ser adotada uma abordagem mais estruturada, como
cenários de eventos ou casos de uso.

Questionários:

Prof. Diego Carvalho [Link] Pág. 22 de 106

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 04

Formulários distribuídos aos stakeholders com questões pré-definidas. Torna-se útil

quando a quantidade de stakeholders é muito grande. Tem baixo custo, é fácil de
aplicar, pode atingir várias pessoas, demanda menos tempo e fornece rápido
feedback. No entanto, há uma tonelada de problemas, como falta de interação,
perguntas pouco objetivas, difícil compreensão das perguntas, entre outros.

Diferentemente da entrevista, essa técnica é interessante quando temos uma

quantidade grande de pessoas para extrair as mesmas informações. As questões
são dirigidas por escrito aos participantes com o objetivo de ter conhecimento sobre
opiniões das mesmas questões – são autoaplicáveis, pois o próprio informante
responde.

Workshop de Requisitos:

Reunião estruturada e intensiva entre analistas e usuários com o intuito de obter um

conjunto de requisitos bem definidos. Possui um facilitador neutro responsável pelas
atividades de logística e promoção de momentos de descontração, como forma de
dinamizar o trabalho em equipe. Permite utilizar técnicas como brainstorming ou
interpretação de papéis.

Devem fazer parte do grupo uma equipe de analistas e uma seleção dos
stakeholders que melhor representam a organização e o contexto em que o sistema
será usado, obtendo assim um conjunto de requisitos bem definidos. Por ser
realizado por convocação por dia e horário, pode ocasionar problemas no
presenciais dos stakeholders.

Brainstorming (Filtro de Ideias)

É uma abordagem ocorrida em grupo em ambientes informais durante cerca de 15

16712855225

minutos em que toda a ideia deve ser levada em consideração, sendo proibida a
crítica a qualquer sugestão dada, e encorajada, inclusive, a criação de ideias que
pareçam estranhas ou exóticas. Busca-se explorar a potencialidade criativa de um
grupo – um facilitador organiza e prioriza os resultados.

Dentre suas vantagens, podemos afirmar que várias pessoas pensam melhor do que
uma. Além disso, essa técnica democratiza a participação de membros do grupo.
Uma desvantagem é que depende da disponibilidade dos integrantes. O
Brainstorming muitas vezes é utilizado em conjunto com outras técnicas, tais como
Workshops de Requisitos.

Prof. Diego Carvalho [Link] Pág. 23 de 106

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 04

Leitura de Documentos:

Coleta informações que são geralmente mais difíceis de se obter por meio de
entrevistas, questionários e observações sociais, como – por exemplo – histórico da
organização, cultura e hábitos internos, relacionamentos setoriais, informações
financeiras e direcionamentos futuros. São muito utilizadas no contexto de sistemas
legados.

Estudo e reutilização de documentação de diferentes naturezas, para a identificação

de requisitos a serem implementados no sistema que se está modelando, podem
ser utilizados. Uma grande variedade de documentação pode ser analisada
incluindo estrutura organizacional da empresa, padrões de mercado, leis, manuais
de usuário, relatório de pesquisas de mercado, glossário de termos de negócio, etc.

JAD (Joint Application Design)

Similar à técnica de Workshop de Requisitos e registrada pela IBM, ela busca reunir
os usuários e desenvolvedores em um workshop estruturado para levantar requisitos
e promover a tomada de decisões por meio de dinâmicas de grupo, técnicas visuais,
processos racionais e documentação. É bastante interativa e promove a participação
ativa dos envolvidos.

O processo consiste em três fases principais: customização, sessões e agrupamento.

Na customização, o analista prepara as tarefas para as sessões como organizar os
times, preparar o material, etc. Na fase de sessões, o analista marca uma ou mais
reuniões com os stakeholders. No início da sessão, o engenheiro de requisitos provê
uma visão genérica sobre o sistema.

A discussão com os stakeholders continua até o fim do levantamento de requisitos.

16712855225

Na fase de agrupamento todos os requisitos levantados nas fases anteriores são

convertidos em documentos de especificação de requisitos. As discussões que
ocorrem na fase de sessões são altamente produtivas, porque resolvem dificuldades
entre as partes enquanto se dá o desenvolvimento do sistema para a empresa

Prototipação:

Técnica utilizada no estágio inicial do projeto, ajudando stakeholders a

desenvolverem uma forte noção sobre a aplicação a ser implementada. Por meio
da visualização de um esboço da aplicação, podem-se identificar requisitos reais e

Prof. Diego Carvalho [Link] Pág. 24 de 106

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 04

fluxos de trabalho do sistema. São frequentemente utilizadas quando os usuários

são incapazes de expressar suas necessidades.

Permite alcançar um feedback antecipado dos stakeholders e reduzir o tempo e o

custo de desenvolvimento devido a detecção dos erros em uma fase inicial do
projeto. Ela fornece também alto nível de satisfação dos usuários devido a sensação
de segurança ao ver algo próximo do real. No entanto, há um alto custo de
investimento em relação a outros métodos.

10. Reúso de Requisitos:

Estudo e reutilização de especificações e glossários referentes a projetos de sistemas

legados ou sistemas de mesma família ou com funcionalidades de negócio similares.
Estudos mostram que sistemas similares podem reutilizar mais de 80% de seus
requisitos. Assim, eles têm chances maiores de serem compreendidos pelos
stakeholders.

Economiza tempo e dinheiro! Estudos têm mostrado que sistemas similares podem
reutilizar acima de 80% de seus requisitos. Pode levar também a uma reutilização
adicional de outros itens em outras atividades do ciclo de vida de desenvolvimento.
Além disso, reduz riscos, visto que requisitos reutilizados têm uma chance maior de
serem compreendidos pelos stakeholders.

11. Histórias de Usuários

Introduzida pela Metodologia XP, nada mais é do que uma história contada na
linguagem do usuário final capaz de capturar aquilo que o usuário de fato necessita
fazer para realizar seu trabalho. Deve ser concisa o suficiente para caber em um
post- . Um padrão seria: “Como um <papel>, eu quero <meta> de modo que
16712855225

<benefício>”.

12. Participação Ativa de Usuários:

Técnica que permite a incorporação dos usuários ao grupo de engenharia de

requisitos. Os usuários precisam aprender as linguagens de modelagem utilizadas
para ser capaz de ler as descrições e criticá-las. Permite uma interação real entre
clientes e usuários, no entanto necessita de um certo treinamento aos usuários
participantes.

13. Encenação

Prof. Diego Carvalho [Link] Pág. 25 de 106

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 04

É uma abordagem que implica usar uma ferramenta para ilustrar para os usuários
(atores) como o sistema se ajustará à organização e também indicar como ele se
comportará. Um facilitador mostra uma encenação para o grupo e este último faz
comentários. Ajuda a restringir requisitos, estimula soluções mais criativas e a revisão
em equipe, facilita o processo de entrevista, etc.

14. Interpretação de Papeis

É uma abordagem que atribui a cada membro do grupo um papel de interesse para
o sistema. O grupo inspecionará então como o sistema é usado. Ao longo do
caminho, haverá discussões sobre quem é responsável por o quê. O Analista de
Sistemas interpreta o papel do usuário, o que o ajuda a obter um discernimento real
do domínio do problema.

15. Grupo Focal

Trata-se de um grupo de discussão informal e de tamanho reduzido (até 12

pessoas), com o propósito de obter informação qualitativa em profundidade.
pessoas são convidadas para participar da discussão sobre determinado assunto.
Possui baixo custo, resposta rápida e flexibilidade, obtendo informações de
qualidade em um curto prazo.

16. Análise de Protocolos:

Essa técnica consiste em analisar o trabalho de determinada pessoa por meio de

verbalização, estabelecendo a racionalidade utilizada na execução de tarefas. É feita
por meio da pergunta “O que você faria se...?” e, assim, possibilita elicitar fatos não
facilmente observáveis e permite melhor entendimento dos fatos. Galera, funciona
16712855225

como um protocolo passo a passo.

17. Pontos de Vista (Viewpoint-Oriented Requirements Definition – VORD):

Essa técnica considera as perspectivas de diversas partes interessadas sobre os

requisitos do sistema de software. Ela reconhece os pontos de vista dos stakeholders
e fornece um framework para se tentar descobrir conflitos nos requisitos propostos
por cada um deles. Eles podem ser de três tipos principais: interação, indiretos e de
domínio.

Prof. Diego Carvalho [Link] Pág. 26 de 106

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 04

Galera, é possível se aprofundar bastante em cada uma dessas técnicas. No entanto,

eu acredito que dentro do contexto de Engenharia de Requisitos, basta saber
breve scrição. Aprofundar-se em cada uma é inviável e pouco eficiente. Ademais,
é possível aprender mais dentro do contexto em que são mais utilizadas (Ex:
Histórias de Usuário, no contexto de XP; Casos de Uso, no contexto de UML; etc).

Bem, falamos um bocado sobre a Obtenção de Requisitos. Agora vamos falar

brevemente do restante das atividades de elicitação e análise de requisitos.
Comecemos pela Classificação e Organização. Pessoal, levantaram-se vários
requisitos para o sistema. Vocês se lembram da quantidade de classificações que nós
estudamos, certo? Ela será útil neste momento!

Agora os diversos requisitos levantados serão agrupados de acordo com suas

características comuns e serão organizados em conjuntos coerentes. Além disso,
analista de requisitos se preocupará em fazer várias verificações de conflito,
consistência, omissão e ambiguidade, de modo que haja um mínimo de erros para
a fase seguinte.

Então, chegamos à atividade de priorização e negociação. Nessa fase, o engenheiro

de requisitos deve conciliar os conflitos por meio de uma negociação entre clientes,
usuários e partes interessadas. Pergunta-se a eles quais são seus requisitos
prioritários. Então, utiliza-se uma abordagem iterativa que avalia custos e riscos de
modo a balancear todas as demandas.

Enfim, chegamos à documentação de requisitos. Esse estágio tem simplesmente a

função de documentar formalmente ou informalmente os requisitos levantados,
classificados, organizados, priorizados e negociados, de modo que possam ser
utilizados para auxiliar as próximas obtenções de requisitos. Já se obtém um esboço
do documento de requisitos. 16712855225

Prof. Diego Carvalho [Link] Pág. 27 de 106

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 04

ESPECIFICAÇÃO DE REQUISITOS

Atividade de traduzir as informações coletadas durante a atividade de elicitação e

análise em um documento que define um conjunto de requisitos. De fato, é o
processo de escrever os requisitos de usuário e requisitos de sistema em um
documento de requisitos. Idealmente, requisitos de usuário e sistema devem ser
claros, não-ambíguos, fáceis de entender, completos e consistentes.

Na prática, isso é extremamente difícil de se atingir, na medida em que as partes

interessadas interpretam os requisitos de maneiras diferentes e, frequentemente, há
conflitos e inconsistências. Requisitos de usuário devem ser escritos em linguagem
natural, com tabelas simples, diagramas intuitivos, entre outros.

Já os requisitos de sistema adicionam detalhes e explicam como requisitos de

usuário devem ser fornecidos pelo sistema. Idealmente, ambos devem descrever
simplesmente o comportamento externo e suas restrições operacionais. Eles não
devem ser preocupar em como o sistema deve ser projetado ou implementado,
apesar de, na prática, ser quase impossível não o fazer.

Por fim, ele gera o conjunto de requisitos do sistema que, na próxima fase, apenas
será validado. Ele é bastante útil em diversas áreas de engenharia, descrevendo as
funcionalidades de um sistema de software e suas limitações. Ademais, permite
detalhar as informações de entrada e saída do sistema, de modo que se implemente
uma arquitetura confiável do sistema.

16712855225

Prof. Diego Carvalho [Link] Pág. 28 de 106

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 04

VALIDAÇÃO DE REQUISITOS

Essa atividade verifica os requisitos em relação ao realismo, consistência,

abrangência, validade, completude, etc. Durante esse processo, erros no
documento de requisitos são inevitavelmente descobertos. Devem, então, ser feitas
modificações para corrigir esses problemas. Busca-se demonstrar que os requisitos
definem, de fato, o que o usuário deseja em seu sistema.

Este estágio é focado no cliente e está relacionado à descoberta de problemas com

requisitos. A validação de requisitos é extremamente importante porque os erros
em um documento de requisitos podem levar a custos excessivos de retrabalho
quando são descobertos durante o desenvolvimento ou depois que o sistema está
em operação.

O custo de correção de um problema de requisitos, fazendo uma mudança de

sistema, é muito maior do que a correção de erros de projeto e de codificação. A
razão disso é que uma mudança de requisitos significa geralmente que o projeto e
a implementação do sistema devem também ser mudados e o sistema deve ser
novamente testado.

Não se deve subestimar os problemas de validação de requisitos. É difícil

demonstrar que um conjunto de requisitos atende às necessidades do usuário. Os
usuários devem imaginar o sistema em operação e avaliar sua adequação ao
trabalho. É difícil para profissionais de informática habilidosos realizarem esse tipo
de análise abstrata e é ainda mais difícil para os usuários do sistema.

Como resultado, raramente encontram-se todos os problemas de requisitos durante

o processo de validação. É inevitável que haja mudanças de requisitos posteriores
para corrigir omissões e mal-entendidos depois da aprovação do documento de
16712855225

requisitos. Enfim, uma série de técnicas de validação de requisitos pode ser usada
em conjunto ou individualmente, entre elas:

 Revisão de Requisitos: os requisitos são analisados sistematicamente por uma

equipe de revisores. Em revisões informais, a equipe de revisores pode
simplesmente ter uma conversa, envolvendo o maior número possível de
representantes das partes interessadas, acerca dos requisitos produzidos. Em
revisões formais, a equipe de revisores deve confirmar junto do cliente um
conjunto de critérios que todos os requisitos devem cumprir.

Prof. Diego Carvalho [Link] Pág. 29 de 106

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 04

 Prototipação: um modelo executável do sistema é apresentado para usuários

finais e clientes. Eles podem experimentar o modelo para verificar se atende
às suas necessidades reais. Esta técnica também tem desvantagens: o tempo
gasto na sua implementação pode não justificar o seu uso, pode enviesar os
usuários e pode ainda levar os programadores a cair na tentação de usar o
protótipo para continuar o desenvolvimento do sistema.

 Geração de Casos de Teste: os requisitos devem ser testáveis. Se os testes

dos requisitos forem criados como parte do processo de validação, eles
frequentemente revelarão problemas de requisitos. Se um teste for difícil ou
impossível de ser projetado, significa geralmente que os requisitos serão
difíceis de serem implementados e devem ser reconsiderados para
implementação.

A diferença entre Verificação e Validação de Requisitos é, na maioria das vezes

ignorada em prova; mas, algumas vezes, ela é cobrada. A Verificação de Requisitos
tem o objetivo de descobrir se os requisitos são claros, precisos, completos e
consistentes, e se eles estão em concordância com o que as partes interessadas
realmente desejam do sistema.

A verificação de requisitos tem por objetivo analisar se os modelos construídos estão

de acordo com os requisitos definidos. Professor, e a Validação de Requisitos? Ela se
ocupa de mostrar que os requisitos realmente definem o sistema que o cliente
deseja, i.e., visa assegurar que as necessidades do cliente estão sendo atendidas por
tais requisitos. Entenderam melhor?

A validação de requisitos é importante, porque a ocorrência de erros em um

documento de requisitos pode levar a grandes custos relacionados ao retrabalho,
quando esses erros são descobertos durante o desenvolvimento ou depois que o
16712855225

sistema estiver em operação. Na validação ocorrem diferentes tipos de verificação

(de validade, consistência, completeza, realismo, facilidade, etc).

Prof. Diego Carvalho [Link] Pág. 30 de 106

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 04

GERENCIAMENTO DE REQUISITOS

Enfim, finalizamos as etapas de Engenharia de Requisitos. No entanto, há um

processo extremamente importante que envolve todas as fases estudadas:
Gerenciamento de Requisitos. Sabe-se que os requisitos estão em constante
evolução. Portanto, esse é o processo responsável por compreender, acompanhar
e controlar as mudanças dos requisitos de sistema.

É preciso manter o acompanhamento dos requisitos individuais e manter as ligações

entre os requisitos dependentes, de modo que seja possível avaliar o impacto das
mudanças de requisitos (rastreabilidade). É necessário, também, estabelecer um
processo formal para fazer propostas de mudança e ligá-las aos requisitos de
sistema. Entenderam isso?

O processo de gerenciamento de requisitos deve se iniciar assim que uma versão

inicial do documento de requisitos esteja disponível, mas o planejamento das
mudanças de requisitos deve ser iniciado durante o processo de elicitação de
requisitos. A evolução de requisitos, durante o processo de engenharia de requisitos
e após a entrada de um sistema em operação, é inevitável.

O desenvolvimento de requisitos de software enfoca as capacidades de software,

objetivos da empresa e outros sistemas da empresa. À medida que a definição dos
requisitos se desenvolve, uma compreensão maior das necessidades dos usuários é
obtida. Isso realimenta as informações do usuário que pode, então, propor uma
mudança nos requisitos.

Existem vários relacionamentos entre os requisitos e entre os requisitos e o projeto

do sistema. Há também ligações entre requisitos e os motivos básicos de por que
esses requisitos foram propostos. Quando as mudanças são propostas, deve-se
16712855225

rastrear seu impacto em outros requisitos e no projeto do sistema.

A rastreabilidade é a propriedade de uma especificação de requisitos que reflete a

facilidade de encontrar os requisitos relacionados. Ela é frequentemente
representada por meio de matrizes de rastreabilidade que relacionam os requisitos
aos stakeholders, aos outros requisitos ou aos módulos de projeto.

Em uma matriz de rastreabilidade de requisitos, cada requisito é introduzido em

uma linha e uma coluna da matriz. As dependências entre diferentes requisitos são
registradas na célula correspondente à intersecção de linha/coluna. Existem três
tipos de informações de rastreabilidade que podem ser mantidas:

Prof. Diego Carvalho [Link] Pág. 31 de 106

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 04

 Informações de rastreabilidade da origem: ligam os requisitos aos

stakeholders que propuseram os requisitos e aos motivos desses requisitos.
Quando uma mudança é proposta, usam-se essas informações para
consultar os stakeholders sobre a mudança.

 Informações de rastreabilidade de requisitos: ligam os requisitos dependentes

dentro do documento de requisitos. Usam-se essas informações para avaliar
quantos requisitos serão afetados pela mudança e a extensão das mudanças
de requisitos necessárias.

 Informações de rastreabilidade de projeto: ligam os requisitos aos módulos

de projeto, nos quais esses requisitos são implementados. Você usa essas
informações para avaliar o impacto das mudanças de requisitos propostas no
projeto e na implementação do sistema.

As matrizes de rastreabilidade podem ser usadas quando um pequeno número de

requisitos deve ser gerenciado, mas para sistemas de grande porte, com muitos
requisitos, tomam-se muito difíceis de serem gerenciadas e sua manutenção é
dispendiosa. Para esses sistemas, deve-se captar as informações de rastreabilidade
em um banco de dados de requisitos.

16712855225

Prof. Diego Carvalho [Link] Pág. 32 de 106

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 04

(CESPE - 2011 - EBC - Analista - Engenharia de Software) No processo de

construção e(ou) manutenção de um produto de software, o termo requisito
pode ser definido da seguinte forma: uma condição, característica ou
capacidade, determinada no universo das necessidades do negócio do usuário,
que deve ser atendida por um software na forma de aspectos funcionais e não
funcionais.

Comentários:

Perfeito! Apenas mais uma boa definição de requisitos.

Gabarito: C

(CESPE - 2010 - ABIN - Desenvolvimento E Manutenção De Sistemas) Requisitos

não funcionais são restrições sobre os serviços ou as funções oferecidas pelo
sistema, e podem ser, também, declarações de serviços que o sistema deve
fornecer, como o sistema deve reagir a entradas específicas e como deve
comportar-se em diversas situações.

Comentários:

Na verdade, declarações de serviços que o sistema deve fornecer, como o sistema

deve reagir a entradas específicas e como deve comportar-se em diversas situações
16712855225

trata-se de requisitos funcionais.

Gabarito: E

(CESPE - 2010 - MPU - Analista de Informática - senvolvimento de Sistemas)

Os requisitos normativos, geralmente oriundos da análise das regras de negócio
a que está submetido um sistema, nunca podem ser considerados requisitos
funcionais, por estarem fora do sistema, ou seja, do domínio do negócio.

Comentários:

Prof. Diego Carvalho [Link] Pág. 33 de 106

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 04

Bem, a questão disse que nunca pode ser considerado um requisito funcional. De
fato, geralmente ele é um requisito não-funcional, mas pode haver casos em que
esse requisito normativo faça parte do domínio do negócio e deva ser
implementado como uma funcionalidade.

Gabarito: E

(CESPE - - DETRAN-DF - Análise de Sistemas) Requisitos funcionais são

restrições sobre as funções ou serviços oferecidos pelo sistema. Esses requisitos
consideram as declarações de serviços, a forma do sistema reagir e como ele
deve se comportar em determinadas situações. Cenários e casos de uso são
técnicas eficazes para elicitação de requisitos funcionais segundo pontos de vista
de interação.

Comentários:

Na verdade, requisitos não-funcionais são restrições sobre as funções ou serviços

oferecidos pelo sistema.

Gabarito: E

(CESPE - 2011 - EBC - Analista - Engenharia de Software) O principal artefato

elaborado no processo de produção de requisitos do sistema, segundo a ER, é
o documento de requisitos. Por sua vez, o documento de requisitos é uma
declaração formal dos requisitos para os stakeholders, que podem ser clientes,
usuários finais ou a equipe de desenvolvimento do software.

Comentários:
16712855225

Perfeito! Stakeholders são as partes interessadas, dentre elas há os clientes, usuários

finais e a própria equipe de desenvolvimento.

Gabarito: C

(CESPE - - MPE- - Analista de Sistemas) Os requisitos de um sistema são

descrições dos serviços fornecidos pelo sistema e suas restrições operacionais. O
processo de descobrir, analisar, documentar e verificar esses serviços e restrições
é denominado engenharia de requisitos. Requisitos de um sistema de software
podem ser funcionais, não funcionais ou de domínio.

Prof. Diego Carvalho [Link] Pág. 34 de 106

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 04

Comentários:

Perfeito! É isso mesmo...

Gabarito: C

(CESPE - 2008 - STJ - Analista Judiciário - Tecnologia da Informação) Os

requisitos de um sistema podem ser descrições dos serviços fornecidos ou
restrições operacionais. Requisitos podem ainda ser classificados como
funcionais, não funcionais, ou de domínio. A engenharia de requisitos visa
compreender e definir os requisitos. Um processo de engenharia de requisitos
pode envolver o estudo de viabilidade, a análise, a especificação e a validação
de requisitos.

Comentários:

Perfeito! É isso mesmo...

Gabarito: C

(CESPE - 2004 – AGE/ES – Auditor do Estado - Tecnologia da Informação) A

engenharia de requisitos fornece mecanismos que permitem entender e analisar
a necessidade de o cliente avaliar a exequibilidade, negociar uma solução
razoável e especificá-la de maneira não-ambígua, validar a especificação e
administrar os requisitos.

Comentários:

Galera, discordo dessa questão! A redação dela é extremamente confusa – ela diz
16712855225

que o cliente deve avaliar a exequibilidade. Uma redação correta seria: A engenharia
de requisitos fornece mecanismos que permitem entender e analisar a necessidade
do cliente, avaliar a exequibilidade, negociar uma solução razoável e especificá-la de
maneira não-ambígua, validar a especificação e administrar os requisitos. Contudo,
o CESPE considerou-a como correta.

Gabarito: C

(CESPE - 2011 - FUB - Analista de Tecnologia da Informação - Específicos) O

estudo de viabilidade, uma atividade inicial do processo de engenharia de

Prof. Diego Carvalho [Link] Pág. 35 de 106

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 04

requisitos, consiste em um conjunto preliminar de requisitos de negócio, um

esboço da descrição do sistema e da forma como o sistema pretende apoiar os
processos de negócios.

Comentários:

Perfeito! É uma excelente descrição de Estudo de Viabilidade.

Gabarito: C

10. (CESPE - 2004 – Prefeitura de Boa Vista - Analista Municipal) Requisitos

adequadamente definidos constituem base importante sobre a qual um sistema
poderá ser bem desenvolvido. No processo de engenharia de requisitos, o
estudo de viabilidade utiliza as informações do processo de levantamento de
requisitos para gerar um relatório que recomenda se é viável ou não realizar o
processo de desenvolvimento do sistema.

Comentários:

Opa... calma aí! Estudo de Viabilidade vem antes do processo de Levantamento de

Requisitos.

Gabarito: E

11. (CESPE - 2011 - BRB - Analista de Tecnologia da Informação) O levantamento de

requisitos de software privilegia a visão do desenvolvedor em relação aos
requisitos de um produto. Já a análise dos requisitos prioriza a visão que o cliente
e os usuários têm dos requisitos de um produto.
16712855225

Comentários:

Olhem as pegadinhas do CESPE! Está invertido, no levantamento privilegia-se a

visão do usuário/cliente e na análise, a visão do desenvolvedor.

Gabarito: E

12. (CESPE - 2011 - FUB - Analista de Tecnologia da Informação - Específicos) A

etnografia, uma técnica de levantamento de requisitos, é uma abordagem
completa para elicitação, utilizada para compreender os requisitos sociais e

Prof. Diego Carvalho [Link] Pág. 36 de 106

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 04

organizacionais e que identifica novas características a serem acrescentadas em

um sistema.

Comentários:

Na verdade, ela não é completa! Lembremos que ela busca encontrar requisitos
implícitos!

Gabarito: E

13. (CESPE - 2010 - ABIN - Oficial Técnico De Inteligência - Área De Desenvolvimento

E Manutenção De Sistemas) Se os requisitos forem organizados de acordo com
os diversos pontos de vista relativos a grupos de usuários do sistema, é possível
identificar aqueles comuns a todos ou à maioria dos pontos de vista. Esses
requisitos comuns podem estar relacionados a assuntos separados,
implementados como extensões da funcionalidade central.

Comentários:

Essa não precisava nem saber o conteúdo. Como requisitos comuns podem ser
implementados como extensões da funcionalidade central? Não faz sequer sentido!

Gabarito: E

14. (CESPE - 2010 - MPU - Analista de Informática - Desenvolvimento de Sistemas)

O levantamento de requisitos é realizado ao final da primeira versão de um
protótipo, para se definir, junto aos envolvidos no processo, quais são as
premissas básicas para o início do entendimento das funcionalidades desejadas.
16712855225

Comentários:

Essa questão não faz sentido, uma vez que – para se fazer um protótipo – é
necessário levantar uma certa quantidade de requisitos!

Gabarito: E

15. (CESPE - 2010 - MPU - Analista de Informática - Desenvolvimento de Sistemas)

Embora a criação de uma sequência ilustrada de telas por meio de programas
de desenho gráfico seja útil para a identificação de alguns requisitos do software,

Prof. Diego Carvalho [Link] Pág. 37 de 106

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 04

ela não é considerada uma atividade de prototipação por não envolver o uso de
uma linguagem de programação.

Comentário

Na verdade, a identificação de requisitos é independente de linguagem de

programação.

Gabarito: E

16. (CESPE - 2008 - SERPRO - Analista - Desenvolvimento de Sistemas) O

levantamento de requisitos é importante, porém não é fundamental, pois
recomenda-se avançar o quanto antes para as demais atividades que permitam
uma visualização do software e reduzam a ansiedade do cliente em ver algo
pronto.

Comentários:

Que isso? É importante, fundamental, essencial, sim!

Gabarito: E

17. (CESPE - 2004 – COHAB - Analista de Sistemas) O QFD (Quality Function

Deployment) tem uma abordagem embasada na criação de uma equipe
formada por clientes e desenvolvedores, que trabalham juntos para identificar o
problema, propor elementos da solução, negociar diferentes abordagens e
especificar um conjunto de requisitos da solução.

Comentários: 16712855225

No QFD, não há uma equipe formada por clientes e desenvolvedores, apenas

especialistas experientes. Eu diria que essa descrição se parece mais com JAD que
QFD.

Gabarito: E

18. (CESPE - 2004 – COHAB - Analista de Sistemas) As atividades de análise de

requisitos resultam na especificação das características operacionais do software,
na indicação da interface do software com outros elementos do sistema e no
estabelecimento de restrições que o software deve satisfazer.

Prof. Diego Carvalho [Link] Pág. 38 de 106

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 04

Comentários:

Perfeito, é isso mesmo!

Gabarito: C

19. (CESPE - 2004 – COHAB - Analista de Sistemas) À medida que os requisitos são
elucidados, o analista de software pode criar um conjunto de cenários, ou seja,
casos de uso, que identificam uma linha de uso para o sistema a ser construído.

Comentários:

Questão linda! É exatamente isso... lembrem-se que cenários são casos de uso.

Gabarito: C

(CESPE - - IPEA - Analista - Desenvolvimento de Sistemas) Elicitação

envolve a identificação sistemática de requisitos nem sempre explicitados pelos
clientes. Protótipos, pesquisas estruturadas, testes-beta, análise de casos de
negócio, walkthroughs, QFD, grupos de trabalho são exemplos de técnicas
utilizadas para elicitar necessidades, expectativas, restrições e interfaces dos
stakeholders para todas as fases do ciclo de vida do produto.

Comentários:

Perfeito! Ótima definição de Elicitação de Requisitos. Um aluno já me perguntou:

“Professor, Testes-beta também?”. Sim, de fato não é nada usual. No entanto,
imaginemos um Teste-beta (aquele que ocorre no ambiente real de utilização do
16712855225

usuário) e descobrimos um problema. Esse problema pode se transformar em um

novo requisito, concordam? Portanto, eu posso utilizá-lo como uma técnica para
descobrir novos requisitos.

Porém, é preciso ter aquela experiência que se adquire quando se faz várias provas
para saber quando esse é o foco da questão e quando não é - nesse caso, não é.

Gabarito: C

21. (CESPE - - SERPRO - Analista de Sistemas) O levantamento de requisitos é

importante, porém não é fundamental, pois recomenda-se avançar o quanto

Prof. Diego Carvalho [Link] Pág. 39 de 106

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 04

antes para as demais atividades que permitam uma visualização do software e

reduzam a ansiedade do cliente em ver algo pronto.

Comentários:

Galera, podem rir à vontade! Essa questão é hilária... não é fundamental?

Completamente errado!

Gabarito: E

(CESPE - 2005 - SERPRO - Analista de Sistemas) Uma das principais atividades

relacionadas à engenharia de software é o levantamento dos requisitos. Nesse
contexto, foi introduzida, na década de 80 do século XX, uma técnica de
entrevista conhecida como JAD (Joint Application Development), que consistia
em uma rápida entrevista e um processo acelerado de coleta de dados em que
todos os principais usuários e o pessoal da análise de sistemas agrupavam-se
em uma única e intensiva reunião.

Comentários:

Galera, não sei também porque essa questão foi dada como certa! JAD não consiste
em uma rápida entrevista, mas em uma intensa reunião. Ademais, não se trata de
uma única reunião.

Gabarito: C

(CESPE - – TCE/RN - Analista de Sistemas) A etnografia é uma técnica

utilizada para a descoberta de requisitos de sistemas de software na qual, por
meio de observações, procura-se compreender os requisitos sociais e
16712855225

organizacionais do ambiente onde o sistema será usado.

Comentários:

Perfeito, é essa a função da técnica de etnografia.

Gabarito: C

24. (CESPE - 2012 - MPE-PI - Analista Ministerial - Informática - Cargo 6) Identificada

facilidade do cliente em entender uma especificação matemática, é correto
utilizar, também, na especificação dos requisitos, notações baseadas em

Prof. Diego Carvalho [Link] Pág. 40 de 106

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 04

máquinas de estado finito, uma vez que elas podem reduzir a ambiguidade de
um documento de requisitos.

Comentários:

Bem, se o cliente tem facilidade em entender uma especificação matemática,

notações baseadas em máquinas de estado finito serão bastante intuitivas, uma vez
que são bastante formais.

Gabarito: C

(CESPE - 2010 - DETRAN-ES - Analista de Sistemas) A técnica de brainstorm é

adequada para a produção de especificações de requisitos para um sistema de
informação em desenvolvimento.

Comentários:

Especificação de Requisitos, não! Levantamento de Requisitos.

Gabarito: E

(CESPE - 2007 – MPU - Analista de Sistemas) A especificação de requisitos

permite, em determinado momento, revelar o que o sistema irá realizar no que
se refere às funcionalidades, sem definir, nesse momento, como as
funcionalidades serão implementadas.

Comentários:

Perfeito! A Especificação de Requisitos permite isso ao seu final.

16712855225

Gabarito: C

27. (CESPE - – TSE- Analista de Sistemas - IV) Na especificação de requisitos,

pode-se construir um documento que descreva o sistema em termos gerais. Esse
documento apresenta uma visão do sistema e pode capturar as necessidades
dos usuários.

Comentários:

Prof. Diego Carvalho [Link] Pág. 41 de 106

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 04

Perfeito! Ele gera um documento que contém um conjunto de requisitos que

descrevem o sistema.

Gabarito: C

(CESPE - 2011 - EBC - Analista - Engenharia de Software) Uma das principais

técnicas de verificação é a prototipação. Um protótipo é um produto
parcialmente desenvolvido, que possibilita aos clientes e desenvolvedores
examinarem certos aspectos do sistema proposto e decidir se eles são ou não
apropriados ou adequados para o produto acabado.

Comentários:

Como resultado, raramente encontram-se todos os problemas de requisitos durante

o processo de validação. É inevitável que haja mudanças de requisitos posteriores
para corrigir omissões e mal-entendidos depois da aprovação do documento de
requisitos. Enfim, uma série de técnicas de validação de requisitos pode ser usada em
conjunto ou individualmente, entre elas:

Prototipação: um modelo executável do sistema é apresentado para usuários finais e

clientes. Eles podem experimentar o modelo para verificar se atende às suas
necessidades reais. Esta técnica também tem desvantagens: o tempo gasto na sua
implementação pode não justificar o seu uso, pode enviesar os usuários e pode ainda
levar os programadores a cair na tentação de usar o protótipo para continuar o
desenvolvimento do sistema.

Conforme vimos em aula, a Prototipação é uma técnica de Validação de Requisitos.

16712855225

Gabarito: E

(CESPE - 2011 - -ES - Analista Judiciário - Análise de Sistemas - Específicos)

Assim como o software, os requisitos também devem ser avaliados quanto à
qualidade. A validação, atividade da engenharia de requisitos, é responsável por
garantir que os requisitos tenham sido declarados de forma clara e precisa. Além
disso, a validação busca detectar inconsistências, erros e omissões, objetivando
alinhar os requisitos às normas estabelecidas para o projeto, produto e processo.

Comentários:

Prof. Diego Carvalho [Link] Pág. 42 de 106

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 04

Essa atividade verifica os requisitos em relação ao realismo, consistência, abrangência,

validade, completude, etc. Durante esse processo, erros no documento de requisitos
são inevitavelmente descobertos. Devem, então, ser feitas modificações para corrigir
esses problemas. Busca-se demonstrar que os requisitos definem, de fato, o que o
usuário deseja em seu sistema.

Conforme vimos em aula, a questão está perfeita!

Gabarito: C

(CESPE - 2011 - STM - Analista Judiciário - Análise de Sistemas - Específicos) São

consideradas técnicas de validação de requisitos: revisões de requisitos,
prototipação e geração de casos de teste.

Comentários:

Como resultado, raramente encontram-se todos os problemas de requisitos durante

o processo de validação. É inevitável que haja mudanças de requisitos posteriores
para corrigir omissões e mal-entendidos depois da aprovação do documento de
requisitos. Enfim, uma série de técnicas de validação de requisitos pode ser usada em
conjunto ou individualmente, entre elas:

Revisão de Requisitos: os requisitos são analisados sistematicamente por uma equipe

de revisores. Em revisões informais, a equipe de revisores pode simplesmente ter uma
conversa, envolvendo o maior número possível de representantes das partes
interessadas, acerca dos requisitos produzidos. Em revisões formais, a equipe de
revisores deve confirmar junto do cliente um conjunto de critérios que todos os
requisitos devem cumprir.
16712855225

Prototipação: um modelo executável do sistema é apresentado para usuários finais e

clientes. Eles podem experimentar o modelo para verificar se atende às suas
necessidades reais. Esta técnica também tem desvantagens: o tempo gasto na sua
implementação pode não justificar o seu uso, pode enviesar os usuários e pode ainda
levar os programadores a cair na tentação de usar o protótipo para continuar o
desenvolvimento do sistema.

Geração de Casos de Teste: os requisitos devem ser testáveis. Se os testes dos

requisitos forem criados como parte do processo de validação, eles frequentemente
revelarão problemas de requisitos. Se um teste for difícil ou impossível de ser

Prof. Diego Carvalho [Link] Pág. 43 de 106

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 04

projetado, significa geralmente que os requisitos serão difíceis de serem

implementados e devem ser reconsiderados para implementação.

Conforme vimos em aula, a questão está perfeita!

Gabarito: C

31. (CESPE - 2010 - MPU - Analista de Informática - Desenvolvimento de Sistemas)

A verificação de requisitos tem por objetivo analisar se os modelos construídos
estão de acordo com os requisitos definidos. Por sua vez, a validação de
requisitos visa assegurar que as necessidades do cliente estão sendo atendidas
por tais requisitos.

Comentários:

A diferença entre Verificação e Validação de Requisitos é, na maioria das vezes,

ignorada em prova; mas, algumas vezes, ela é cobrada. A Verificação de Requisitos
tem o objetivo de descobrir se os requisitos são claros, precisos, completos e
consistentes, e se eles estão em concordância com o que as partes interessadas
realmente desejam do sistema.

A verificação de requisitos tem por objetivo analisar se os modelos construídos estão

de acordo com os requisitos definidos. Professor, e a Validação de Requisitos? Ela se
ocupa de mostrar que os requisitos realmente definem o sistema que o cliente deseja,
i.e., visa assegurar que as necessidades do cliente estão sendo atendidas por tais
requisitos. Entenderam melhor?

A validação de requisitos é importante, porque a ocorrência de erros em um

documento de requisitos pode levar a grandes custos relacionados ao retrabalho,
16712855225

quando esses erros são descobertos durante o desenvolvimento ou depois que o

sistema estiver em operação. Na validação ocorrem diferentes tipos de verificação (de
validade, consistência, completeza, realismo, facilidade, etc).

Conforme vimos em aula, a questão está perfeita!

Gabarito: C

(CESPE - 2011 - -ES - Técnico de Informática - Específicos) Verificação e

validação são atividades da análise de software, necessárias para se identificar o

Prof. Diego Carvalho [Link] Pág. 44 de 106

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 04

que o software precisa executar, seguida de uma avaliação do usuário quanto às

atividades definidas.

Comentários:

Vamos por partes: de fato, são atividades da análise de software (eu disse análise
de software e, não, requisitos). Ela faz parte da Engenharia de Requisitos, que busca
entender o que o software precisa executar e de uma posterior avaliação do usuário.
A redação da questão está bem confusa, pois dá a entender que a verificação
identifica o que o software precisa executar.

Gabarito: C

(CESPE - 2007 - MPU – Analista de Informática) Na validação de requisitos —

parte integrante da especificação desses requisitos —, é correto o uso de
diagramas da UML, tais como diagrama de classes, de casos de uso e de
interação.

Comentários:

Galera, questão um pouco polêmica! Por que? Porque a Validação de Requisitos

não é parte da Especificação de Requisitos – são fases distintas. De todo modo, a
questão foi dada como certa! Outra parte que gera alguma dúvida é dizer que é
correto a utilização de diagramas da UML! Alguns afirmam que não faz sentido o
uso de Diagramas de Classes na validação de requisitos. Galera, de fato, o Diagrama
de Casos de Uso é o mais adequado, mas não há nada de incorreto utilizar também
o Diagrama de Classes para auxiliar na validação junto ao cliente.

16712855225

Gabarito: C

34. (CESPE - 2011 - MEC - Gerente de Projetos) A rastreabilidade de requisitos ocorre

apenas na relação entre os requisitos propriamente ditos e os artefatos ou
subprodutos de desenvolvimento gerados.

Comentários:

Na verdade, pode ser implementada entre requisitos, entre requisitos e suas fontes
e entre requisitos e componentes que os implementam.

Gabarito: E

Prof. Diego Carvalho [Link] Pág. 45 de 106

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 04

(CESPE - 2010 - TCU - Auditor Federal de Controle Externo - Tecnologia da

Informação - Parte II) Por se tratar de função essencial da engenharia de
requisitos, a gestão formal de requisitos é indispensável mesmo para projetos de
pequeno porte, com apenas duas ou três dezenas de requisitos identificáveis.

Comentários:

Pelo contrário, a gestão formal de requisitos é iniciada somente para grandes

projetos com centenas de requisitos identificáveis. Para pequenos projetos, essa
função de engenharia de requisitos é consideravelmente menos formal.

Gabarito: E

(CESPE - 2013 - MPU - Analista - Desenvolvimento de Sistemas) As atividades do

gerenciamento de requisitos incluem a análise e a negociação, a qual visa
garantir que todos os requisitos do sistema tenham sido declarados de modo
não ambíguo, sem inconsistências, omissões e erros.

Comentários:

Galera, olhem a bagunça! De acordo com Sommerville, a Análise é uma fase da

Engenharia de Requisitos. De acordo com Pressman, a Negociação é uma fase da
Engenharia de Requisitos. Nenhuma das duas é atividade do Gerenciamento de
Requisitos, que também é uma fase da Engenharia de Requisitos (de acordo com
Sommerville). Para piorar tudo, quem visa garantir que todos os requisitos tenham
sido declarados de modo não ambíguo, sem inconsistências, omissões e erros, é a
Validação.
16712855225

Gabarito: E

37. (CESPE - 2009 - IPEA - Analista - Desenvolvimento de Sistemas) A política

organizacional para o planejamento e execução do processo de gerenciamento
de requisitos reflete as expectativas organizacionais para processos de gestão de
requisitos e para que seja possível identificar inconsistências entre os requisitos
e os planos do projeto.

Comentários:

Prof. Diego Carvalho [Link] Pág. 46 de 106

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 04

Perfeito! A Gestão/Gerenciamento de Requisitos permite identificar inconsistências

entre o projeto inicial e os requisitos.

Gabarito: C

(CESPE - - SERPRO - Analista de Sistemas) O gerenciamento de requisitos

inclui, entre outras, as seguintes atividades: levantar, analisar, especificar, validar
e prototipar requisitos funcionais e não-funcionais.

Comentários:

Galera, a questão trata claramente de Engenharia de Requisitos e, não,

Gerenciamento de Requisitos. Eu não sei se não entraram com recurso contra essa
questão ou se entraram e o CESPE o ignorou. O fato é que essa questão é
absurdamente errada, mas o gabarito foi mantido como correto.

Gabarito: C

(CESPE - – MPOG/ATI - Analista de Sistemas) Tão logo exista uma versão

do documento de requisitos, o processo de gerenciamento de requisitos deverá
ser iniciado.

Comentários:

O processo de gerenciamento de requisitos deve se iniciar assim que uma versão

inicial do documento de requisitos esteja disponível, mas o planejamento das
mudanças de requisitos deve ser iniciado durante o processo de elicitação de
requisitos. A evolução de requisitos, durante o processo de engenharia de requisitos e
após a entrada de um sistema em operação, é inevitável.
16712855225

Conforme vimos em aula, a questão está perfeita!

Gabarito: C

40. (CESPE - 2015 – MPOG/ATI - Analista de Sistemas) As informações de

rastreabilidade de requisitos possibilitam a realização de estimativa do custo de
mudanças em requisitos.

Comentários:

Prof. Diego Carvalho [Link] Pág. 47 de 106

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 04

É preciso manter o acompanhamento dos requisitos individuais e manter as ligações

entre os requisitos dependentes, de modo que seja possível avaliar o impacto das
mudanças de requisitos (rastreabilidade). É necessário, também, estabelecer um
processo formal para fazer propostas de mudança e ligá-las aos requisitos de sistema.
Entenderam isso?

Conforme vimos em aula, a rastreabilidade permite avaliar impacto e possibilita

estimar o custo de mudanças em requisitos. Galera, observem que a questão utiliza
‘possibilita’. Sempre que a banca faz isso, ela está te ajudando, porque para essa
questão estar errada, não deveria haver absolutamente nenhuma possibilidade de
estimar custos de mudanças em requisitos por meio de informações de
rastreabilidade.

Gabarito: C

41. (CESPE - 2015 – MPOG/ATI - Analista de Sistemas) As mudanças de requisitos

em processos ágeis de desenvolvimento não seguem um processo formal de
gerenciamento de requisitos.

Comentários:

De fato, as mudanças de requisitos em processos ágeis de desenvolvimento seguem

um processo mais informal de gerenciamento. Não há, por exemplo, documentação
extensa ou matrizes de rastreabilidade! Em geral, metodologias ágeis não podem
se dar ao luxo de processos muito formais.

Gabarito: C

42. (CESPE - 2015 – MPOG/ATI - Analista de Sistemas) Para a elicitação dos

16712855225

requisitos, é indicada à empresa a realização de um workshop de requisitos, em

que seja determinado um facilitador, mesmo que sem grande experiência com
os processos de gerenciamento de requisitos.

Comentários:

18. Workshop de Requisitos:

Reunião estruturada e intensiva entre analistas e usuários com o intuito de obter um

conjunto de requisitos bem definidos. Possui um facilitador neutro responsável pelas
atividades de logística e promoção de momentos de descontração, como forma de

Prof. Diego Carvalho [Link] Pág. 48 de 106

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 04

dinamizar o trabalho em equipe. Permite utilizar técnicas como brainstorming ou

interpretação de papéis.

Devem fazer parte do grupo uma equipe de analistas e uma seleção dos stakeholders
que melhor representam a organização e o contexto em que o sistema será usado,
obtendo assim um conjunto de requisitos bem definidos. Por ser realizado por
convocação por dia e horário, pode ocasionar problemas no presenciais dos
stakeholders.

Essa questão foi bastante polêmica! Alguns podem argumentar que não é técnica
mais indicada. No entanto, a questão não afirma isso, ela apenas afirma que é
indicada – e, de fato, ela é indicada para elicitação de requisitos. Além disso,
conforme eu disse em aula, o facilitador deve ser neutro e responsável por
atividades de logística, organização, etc.

Muitas vezes, ele não precisa ser sequer um cara da área de tecnologia, pode ser
um cara da área de gestão de pessoas, por exemplo. Seu papel é facilitar o
workshop, mas – similar ao Scrum Master no contexto de Gestão de Projetos de
Desenvolvimento de Software – não precisa ter nenhuma experiência específica no
gerenciamento de requisitos.

A questão poderia até ser passível de recurso se falasse ‘sem experiência alguma’,
mas como ela disse apenas ‘sem GRANDE experiência’, eu a avalio como correta.

Gabarito: C

43. (CESPE - 2015 – MPOG/ATI - Analista de Sistemas) Os requisitos não funcionais

a serem especificados estabelecerão restrições que devem ser seguidas por todo
o sistema da referida empresa, podendo até mesmo levar à necessidade de
16712855225

definição de requisitos funcionais.

Comentários:

Requisitos Não-Funcionais: são restrições nos serviços ou funções oferecidas pelo

sistema. Não estão diretamente relacionados às funções específicas do sistema, mas
às gerais e podem incluir restrições de tempo, processo de desenvolvimento e
restrições impostas por padrões. Podem ser mais críticos que os funcionais e sempre
devem ser verificáveis. Eles fazem parte da arquitetura técnica de um sistema.

Prof. Diego Carvalho [Link] Pág. 49 de 106

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 04

Os requisitos não funcionais estabelecem restrições? Sim! Eles podem levar à

necessidade de definição de requisitos funcionais? Também! O que a questão quer
dizer é que, ao levantar e especificar os requisitos funcionais, pode-se acabar
percebendo a necessidade de se estabelecer novos requisitos funcionais (ou
modificá-los).

Percebam outro detalhe: a questão afirma “podendo até” – sempre que a questão
usar o verbo poder, ela já te ajuda! Por que? Porque, para a questão estar errada,
não poderia haver nenhuma possibilidade de se chegar à requisitos funcionais a
partir da especificação dos requisitos não-funcionais. Entenderam isso? Caiu de novo
a mesma coisa!

Gabarito: C

44. (CESPE - 2015 – MPOG/ATI - Analista de Sistemas) A definição de um protótipo

para a validação dos requisitos pode tornar o processo de requisitos mais barato
e mais simplificado, já que ele vai corresponder à real forma de uso do sistema
a ser construído.

Comentários:

De novo, de novo e de novo! Observem que a questão afirma que “pode tornar o
processo mais barato e simplificado”. E, sim, ele pode tornar o processo mais barato
e simplificado. No entanto, o protótipo não necessariamente vai corresponder à real
forma de uso do sistema a ser construído. Na verdade, o protótipo, em geral, é
utilizado para validar requisitos de alto nível, logo ele não vai contemplar diversas
funcionalidades que estarão no sistema real. Pressman afirma:

“Yet, prototyping can be problematic for the following reasons: 1. Stakeholders see
16712855225

what appears to be a working version of the software, unaware that the prototype is
held together haphazardly, unaware that in the rush to get it working you haven’t
considered overall software quality or long-term maintainability. When informed that
the product must be rebuilt so that high levels of quality can be maintained,
stakeholders cry foul and demand that “a few fixes” be applied to make the prototype
a working product. Too often, software development management relents”.

Gabarito: E

45. (CESPE - 2015 – MPOG/ATI - Analista de Sistemas) Uma forma de validação dos
requisitos é a geração de casos de teste para os requisitos documentados.

Prof. Diego Carvalho [Link] Pág. 50 de 106

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 04

Comentários:

Como resultado, raramente encontram-se todos os problemas de requisitos durante

o processo de validação. É inevitável que haja mudanças de requisitos posteriores
para corrigir omissões e mal-entendidos depois da aprovação do documento de
requisitos. Enfim, uma série de técnicas de validação de requisitos pode ser usada em
conjunto ou individualmente, entre elas:

 Geração de Casos de Teste: os requisitos devem ser testáveis. Se os testes dos requisitos forem
criados como parte do processo de validação, eles frequentemente revelarão problemas de
requisitos. Se um teste for difícil ou impossível de ser projetado, significa geralmente que os
requisitos serão difíceis de serem implementados e devem ser reconsiderados para
implementação.

Conforme vimos em aula, existem três técnicas de validação de requisitos: Revisão

de Requisitos, Prototipação e Geração de Casos de Teste.

Gabarito: C

46. (CESPE - 2015 – MPOG/ATI - Analista de Sistemas) No ciclo de vida do software,

o congelamento dos requisitos do software garante que este, quando em
desenvolvimento, atenda à expectativa do usuário, desde que tudo que tenha
sido requisitado seja implementado.

Comentários:

Requisitos não são estáticos, são dinâmicos e precisam ser refinados

constantemente. O processo de definição de requisitos gera um feedback que pode
16712855225

acabar modificando os próprios requisitos. Dessa forma, é evidente que o

congelamento de requisitos não garante o atendimento à expectativa do usuário.
Em geral, usuários não sabem o que querem; aqueles que sabem, mudam de
opinião durante o processo de desenvolvimento de software. Logo, mesmo que
tudo que foi requisitado tenha sido implementado, pode não atender às
expectativas do usuário, tendo em vista que, logo após o congelamento dos
requisitos, o usuário pode muito bem querer modificá-lo.

Gabarito: E

Prof. Diego Carvalho [Link] Pág. 51 de 106

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 04

47. (CESPE - 2015 – STJ – Analista de Sistemas) Os requisitos ambientais,

operacionais e de desenvolvimento são organizacionais e não funcionais.

Comentários:

Conforme vimos em aula, bastava ver a parte superior direita do quadrinho!

Gabarito: C

48. (CESPE - 2015 – STJ – Analista de Sistemas) Os requisitos reguladores, legais e

éticos são externos e não funcionais.

Comentários:

16712855225

Conforme vimos em aula, bastava ver a parte inferior do quadrinho! No entanto,

vamos tentar resolver por lógica? Faz sentido pensar em requisitos reguladores, legais

Prof. Diego Carvalho [Link] Pág. 52 de 106

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 04

e éticos como externos? Sim! E eles são funcionais ou não funcionais? Ora, não-
funcionais. Logo, era possível matar a questão!

Gabarito: C

ACERTEI ERREI

16712855225

Prof. Diego Carvalho [Link] Pág. 53 de 106

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 04

(ESAF - 2005 – AFRFB - Analista de Sistemas - II) Durante a análise de requisitos,

são especificados a função e o desempenho do software, bem como a sua
interface com outros elementos do sistema. Nessa etapa, também, são
estabelecidas as restrições de projeto, a que o software deve atender.

Comentários:

Pessoal, o que essa questão quis dizer? Especificar função = Requisitos Funcionais;
Especificar Desempenho e Restrições = Requisitos Não-Funcionais.

Gabarito: C

(ESAF - – AFRFB - Analista de Sistemas - III) Durante a análise de requisitos,

o principal foco do analista recai sobre como? e não sobre o que?. Nesse caso,
o analista concentra-se em como o sistema produz ou consome dados, como o
sistema deve executar as funções e como as restrições e interfaces são definidas.

Comentários:

Na verdade, a atividade de análise de requisitos se preocupa com O QUE? e a

atividade de projeto se preocupa com COMO?.
16712855225

Gabarito: E

(ESA - – AFRFB - Analista de Sistemas - IV) Durante a especificação dos

requisitos, são estabelecidos os critérios que permitirão ao desenvolvedor e ao
cliente avaliar a qualidade, assim que o software for construído.

Comentários:

Perfeito! A partir da especificação de requisitos que se avalia a qualidade.

Prof. Diego Carvalho [Link] Pág. 54 de 106

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 04

Gabarito: C

(ESAF - 2010 – CVM – Analista de Sistemas) Assinale a opção correta.

a) Gestão de requisitos preocupa-se com a documentação, atualização e

controle de stakeholders envolvidos na fase de identificação da demanda.

b) Engenharia de requisitos compreende: identificar, analisar, especificar e definir

as necessidades de negócio que um aplicativo deve prover para solução do
problema levantado.

c) Engenharia de requisitos compreende: planejar, especificar e desenvolver as

necessidades de negócio que um aplicativo deve prover para minimização dos
problemas levantados.

d) Engenharia de requisitos compreende: identificar, analisar, programar e testar

os programas das necessidades de solução de problemas que um negócio deve
prover para satisfazer usuários.

e) Gestão de requisitos preocupa-se com a documentação, direcionamento,

controle de definição e acesso aos requisitos levantados na fase de planejamento
de escopo.

Comentários:

(a) Errado, documentação, atualização e controle de stakeholders não é gestão de

requisitos; (b) Correto, trata das necessidades para solucionar um problema; (c)
Errado, na engenharia de requisitos não se desenvolve as necessidades de negócio,
entre outros erros; (d) Errado, programar não é uma das atividades, entre outros
16712855225

erros; (e) Errado, planejamento de escopo não é foco da engenharia de requisitos.

Gabarito: B

(ESAF - 2010 – MPOG – Analista de Sistemas) As áreas de esforços da Análise de

Requisitos são:

a) reconhecimento dos objetivos, avaliação e controle, modelagem, estruturação

e revisão.

Prof. Diego Carvalho [Link] Pág. 55 de 106

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 04

b) reconhecimento do problema, avaliação e síntese, modelagem, especificação

e revisão.

c) reengenharia, planejamento, avaliação e controle, modelagem e conclusão.

d) reconhecimento do problema, análise e síntese, reengenharia, especificação e

análise de resultados.

e) reconhecimento do problema, modelagem, especificação de entidades,

estruturação e revisão.

Comentários:

Essa questão foi retirada do livro do Denis Alcides Rezendo, que afirma que, a partir
do relato e necessidades, a análise de requisitos possibilita que o Engenheiro de
Software especifique as funções, o desempenho, interfaces, restrições, etc do
software. Proporciona avaliar a qualidade de atendimento e satisfação, podendo ser
dividido em cinco áreas de esforço: reconhecimento do problema, avaliação e
síntese, modelagem, especificação e revisão.

Gabarito: B

ACERTEI ERREI

16712855225

Prof. Diego Carvalho [Link] Pág. 56 de 106

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 04

(FCC - 2012 - TST - Analista Judiciário - Análise de Sistemas) Na Engenharia de

Requisitos, o gerente de requisitos:

a) acompanha e monitora ações durante a verificação do software, sendo este o

processo que garante o atendimento aos requisitos informados pelo usuário final.

b) possui autonomia para realizar alterações no projeto para garantir que o

software seja bem construído e atenda as necessidades da equipe de
desenvolvimento.

c) mantém atualizados os requisitos junto ao usuário final e a equipe de

desenvolvimento, a fim de obter sucesso no processo de homologação do
software, atendendo as necessidades e expectativas.

d) classifica os requisitos em diferentes tipos, sendo os do tipo funcional

relacionados com o custo e confiabilidade do software e os do tipo não-funcional
relacionados com os casos de uso.

e) obtém o comprometimento dos integrantes da equipe de desenvolvimento de

software para o cumprimento do processo de software.

Comentários:
16712855225

(a) Ele trata da validação e, não, da verificação; (b) Necessidades do usuário e, não,
da equipe de desenvolvimento; (c) Perfeito, é isso! (d) A questão inverteu os
conceitos; (e) Não é função do Gerente de Requisitos.

Gabarito: C

(FCC - 2012 - TCE-AP - Analista de Controle Externo - Tecnologia da Informação)

Em relação a requisitos de sistemas, considere:

Prof. Diego Carvalho [Link] Pág. 57 de 106

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 04

I. O modo como um sistema deve reagir a certas entradas e o comportamento

em que o sistema deve ter em certas situações e, em alguns casos, especificar o
que o sistema não deve fazer, são chamados de requisitos não-funcionais.

II. As restrições aos serviços ou funções de um sistema, como, por exemplo,

processos de desenvolvimento ou utilização de padrões, são requisitos de
funcionamento do sistema ou requisitos funcionais.

III. Requisitos que vem do domínio da aplicação do sistema e refletem

características ou restrições para aquele domínio são chamados de requisitos de
domínio e podem ser requisitos funcionais e/ou não-funcionais.

Está correto o que se afirma em:

a) III, apenas.
b) I, II e III.
c) I e II, apenas.
d) II e III, apenas.
e) I, apenas.

Comentários:

(a) Não, são chamados de Requisitos Funcionais; (b) Não, são Requisitos Não-
Funcionais; (c) Perfeito, é exatamente isso!

Gabarito: A

(FCC - 2011 - INFRAERO - Analista de Sistemas - Gestão de TI - D) No contexto

de levantamento de requisitos, funcionalidade é um dos aspectos que deve ser
16712855225

levado em conta na abordagem dos requisitos funcionais.

Comentários:

Perfeito, é exatamente isso!

Gabarito: C

(FCC - 2010 - BAHIAGÁS - Analista de Processos Organizacionais - Análise de

Sistemas) É uma restrição sobre os serviços ou as funções oferecidos pelo
sistema. Pode ser uma restrição de timing, sobre o processo de desenvolvimento,

Prof. Diego Carvalho [Link] Pág. 58 de 106

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 04

sobre o desempenho ou sobre a confiabilidade do sistema, entre outras. Trata-

se de:

a) requisito não funcional.

b) requisto funcional.
c) especificação de risco.
d) iteração de processo.
e) etnografia.

Comentários:

Tranquila! É um Requisito Não-Funcional!

Gabarito: A

(FCC - 2006 - BACEN - Analista de Sistemas) Em relação à análise de requisitos

funcionais e não-funcionais, é correto afirmar:

a) Dependendo da fase de projeto, a análise dos requisitos funcionais e não-

funcionais recebe o mesmo nível de tratamento, em função da necessidade de
se definir o que é para fazer, qual produto gerar (requisito não-funcional) e qual
a forma, conteúdo, comportamento e atributos deve conter o produto (requisito
funcional).

b) Os requisitos funcionais e não-funcionais têm tratamento diferenciado em

cada fase de projeto. Primeiro, é necessário definir o que é para fazer, qual
produto gerar (requisito não-funcional); segundo, qual forma, conteúdo,
comportamento e atributos deve conter o produto (requisito funcional). Isto quer
dizer que somente se consegue definir atributos ou características de qualidade
16712855225

à medida que se tenha a definição do produto.

c) Na fase de estudo preliminar ou estudos de projeto, a validação dos requisitos

depende do processo de qualificação das informações de origem,
funcionalidade e relacionamento de dependências dos requisitos e do processo
de qualificação de exigências pelos stakeholders. Nesta fase os requisitos não-
funcionais são documentados e priorizados para serem utilizados na fase de
implantação.

d) A fase de modelo físico deve agregar aos requisitos funcionais os requisitos

não-funcionais obtidos nas várias oportunidades de captura de informações,

Prof. Diego Carvalho [Link] Pág. 59 de 106

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 04

tratá-los em termos de prioridade, precedência e relacionamentos entre si, com

ênfase em como o software deve funcionar.

e) Na fase de modelo lógico, são detalhados os eventos e visões dos processos,

identificados os papéis e responsabilidades dos stakeholders. Esta fase deve
agregar aos requisitos funcionais os requisitos nãofuncionais obtidos nas várias
oportunidades de captura de informações, tratá-los em termos de prioridade,
precedência e relacionamentos entre si.

Comentários:

(a) Errado! Qual produto gerar? É um requisito funcional! Basta imaginar: “Eu quero
um aplicativo que permita troca de mensagens”. Qual forma, conteúdo,
comportamento e atributos deve conter? É um requisito não-funcional! Basta
imaginar: “Eu quero um aplicativo interativo que rode com pouca memória e tenha
recursos de segurança da informação”. (b) Errado! Mesmo caso do primeiro item; (c)
Errado! Após a validação, são apurados os riscos de implementação e a definição
de prioridade de implementação dos requisitos funcionais, os requisitos não-
funcionais são documentados, mas ainda não priorizados; (d) Perfeito! (e) A questão
trata do Modelo Físico.

Gabarito: D

(FCC - 2009 – SEFAZ/SP - Analista de Sistemas) É necessário que o software

calcule os salários dos diaristas e mensalistas e emita relatórios mensais
sumariados por tipo de salário. Entretanto, a base de dados deve estar protegida
e com acesso restrito aos usuários autorizados. De qualquer forma, o tempo de
resposta das consultas não deve superar os quinze segundos, pois inviabilizaria
todo o investimento nesse sistema. Devo lembrar que os relatórios individuais dos
16712855225

departamentos, nos quais constam os salários dos funcionários, devem ser

emitidos quinzenalmente em razão dos adiantamentos e vales que recebem. É
fundamental que o software seja operacionalizado usando código aberto.
Necessito, ainda, forte gerenciamento de risco, prazo e custo, porque a entrega do
produto final não pode ultrapassar o prazo de oito meses a contar da data de
início do projeto. No texto, são requisitos funcionais:

a) Calcule os salários dos diaristas e mensalistas e os relatórios individuais dos

departamentos, nos quais constam os salários dos funcionários, devem ser
emitidos quinzenalmente.

Prof. Diego Carvalho [Link] Pág. 60 de 106

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 04

b) Necessito, ainda, forte gerenciamento de risco, prazo e custo e a base de

dados deve estar protegida e com acesso restrito aos usuários autorizados.

c) É fundamental que o software seja operacionalizado usando código aberto e

emita relatórios mensais sumariados por tipo de salário.

d) Emita relatórios mensais sumariados por tipo de salário e Necessito, ainda,

forte gerenciamento de risco, prazo e custo.

e) A base de dados deve estar protegida e com acesso restrito aos usuários
autorizados e entrega do produto final não pode ultrapassar o prazo de oito
meses.

Comentários:

a) Calcular os salários dos diaristas e mensalistas? RF, visto que é uma possível
funcionalidade que o sistema deve apresentar; Emitir relatórios individuais
quinzenalmente? RF, visto que também é uma possível funcionalidade que o sistema
deve apresentar.

b) Gerenciamento de Risco, Prazo e Custo? RNF, visto que é uma restrição do

sistema; Base de dados protegida e com acesso restrito? RNF, visto que é uma
restrição do sistema.

c) Operacionalizar o software com código aberto? RNF, visto que é uma restrição
do sistema; Emitir relatórios mensais sumarizados? RF, é uma possível
funcionalidade que o sistema deve apresentar.

d) Emitir relatórios mensais sumarizados? RF, visto que é uma possível

16712855225

funcionalidade que o sistema deve apresentar. Gerenciamento de Risco, Prazo e

Custo? RNF, visto que é uma restrição do sistema.

e) Base de dados protegida e com acesso restrito? RNF, visto que é uma restrição
do sistema; Restrição de 8 meses quanto ao prazo? RNF, visto que é uma restrição
do sistema.

Observe que os Requisitos Funcionais estão mais relacionados a possíveis utilizações

do usuário, em sua interação com o sistema e como o sistema vai realizar alguma
atividade. Já os Requisitos Não Funcionais estão mais relacionados a aspectos

Prof. Diego Carvalho [Link] Pág. 61 de 106

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 04

qualitativos do sistema, de seu processo de desenvolvimento e de suas restrições.

Logo, percebe-se que somente a Letra A possui ambos os Requisitos Funcionais!

Gabarito: A

(FCC - 2010 – DPE/SP - Analista de Sistemas) Sobre análise de requisitos da

engenharia de software, considere:

I. Os requisitos de usuário podem descrever tanto requisitos funcionais quanto

requisitos não- funcionais.

II. Os requisitos de sistema podem descrever apenas requisitos não funcionais.

III. Os requisitos não-funcionais podem ser divididos em requisitos de produto,

organizacionais e externos.

Está correto o que se afirma em:

a) III, apenas.
b) I e II, apenas.
c) I e III, apenas.
d) II e III, apenas.
e) I, II e III.

Comentários:

(a) Correto! É exatamente isso. Lembrando que Requisitos de Usuários são

descrições, em linguagem natural e com diagramas, de quais serviços o sistema
deve fornecer e as restrições sob as quais deve operar. São requisitos com alto nível
16712855225

de abstração e poucos detalhes, feitos para serem lidos por pessoas leigas. (b)
Errado! Podem descrever requisitos funcionais ou não-funcionais. Lembrando que
Requisitos de Sistema são descrições detalhadas sobre as funções, operações e
restrições de sistema que definem exatamente o que deve ser implementado. São
requisitos com baixo nível de abstração e muitos detalhes, feitos para serem lidos
por pessoas experientes. (c) Correto! É exatamente isso!

Gabarito: C

(FCC - - TRT - 3ª Região (MG) - Analista Judiciário - Tecnologia da

Informação) Com relação aos requisitos de software, considere:

Prof. Diego Carvalho [Link] Pág. 62 de 106

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 04

I. funcionais são somente requisitos de usuário.

II. funcionais e não-funcionais podem ser requisitos de usuário.
III. funcionais e não-funcionais podem ser requisitos de sistema.

Está correto o que se afirma APENAS em

a) I.
b) II.
c) III.
d) I e III.
e) II e III.

Comentários:

Requisitos funcionais e não-funcionais podem ser tanto requisitos de usuário quanto

requisitos de sistema.

Gabarito: E

(FCC - 2010 – DPE/SP - Analista de Sistemas - III) No contexto da Engenharia de

Requisitos, considere:

I. O sistema deve fornecer uma entrada de dados que possibilite a inclusão de

atributos de permissão de acesso às dependências da corporação por técnicos,
supervisores e chefes.

II. Algumas permissões de acesso deverão ter tratamento especial para a entrada
de atributos. Para este tipo de permissão, atributos excedentes a uma faixa
16712855225

predeterminada só poderão ser incluídos por chefes de seção.

Em relação às assertivas acima, é correto afirmar:

a) O item I trata de um requisito funcional e a ele está associado o requisito não

funcional, contido no item II.

b) O item I trata de um requisito não funcional e a ele está associado o requisito

funcional, contido no item II.

c) Ambos referem-se a requisitos funcionais.

Prof. Diego Carvalho [Link] Pág. 63 de 106

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 04

d) A assertiva contida no item II é uma condição restritiva do requisito não

funcional do item I. Por si só, não constitui um requisito, tanto funcional quanto
não funcional.

e) A assertiva contida no item II é uma condição restritiva do requisito funcional

do item I. Por si só, não constitui um requisito, tanto funcional quanto não
funcional.

Comentários:

Galera, o primeiro item trata de um possível serviço do sistema, logo é um Requisito

Funcional. Já o segundo item, da maneira que está escrito, trata-se de uma Regra
de Negócio, i.e., não é sequer um Requisito. É possível transformá-lo em um
Requisito? Sim, percebam:

II. O Sistema deve permitir um tratamento especial para indivíduos com determinada
permissão de acesso, i.e., atributos excedentes só poderão ser incluídos por chefes de
sessão.

Pronto, nós transformamos a Regra de Negócio em um Requisito Funcional.

Sommerville afirma que eles definem como o sistema deve reagir em condições e
até o que o sistema não deve fazer (restrições). Portanto, acredito que a resposta é
a Letra E, mas a banca entendeu que o segundo item é um Requisito Não-Funcional.

Gabarito: A

10. (FCC - 2013 – SEFAZ/SP – Analista de Sistemas) Dentre os requisitos obtidos para
a construção do software constavam: 16712855225

1. O software deve permitir as funções de cadastro, consultas diversas, alteração

de dados e exclusão de alunos, professores e demais colaboradores.

2. O sistema deve ser fácil de usar, fácil de encontrar o que se procura e fácil de
memorizar os passos para executar as operações mais comuns.

3. O sistema deve ter seu funcionamento baseado nas tecnologias web.

4. Todas as operações disponibilizadas no sistema devem contemplar a

legislação vigente.

Prof. Diego Carvalho [Link] Pág. 64 de 106

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 04

5. O sistema deve fazer interface com o sistema da Receita Federal por meio de
requisições/respostas utilizando XML.

6. Os alunos devem poder obter por meio do sistema informações sobre suas
faltas e notas em cada disciplina.

7. O boletim e o histórico do aluno poderão ser consultados e visualizados pelos

gestores, funcionários da secretaria e pelo próprio aluno.

8. Ao clicar em uma opção para gerar o boletim do aluno, deve ser apresentada
ao solicitante uma tabela com todas as disciplinas que o aluno cursou, bem como
as notas das provas e o número total de faltas em cada disciplina.

9. O sistema deve responder à solicitação de geração do boletim de um aluno

em no máximo 10 segundos.

10. O sistema deve calcular a média aritmética das duas maiores dentre três notas
de cada disciplina no final do semestre.

11. Quando o sistema constatar que o aluno tem mais que 25% de faltas em uma
disciplina do semestre, deve ser exibida no boletim do aluno a informação
"Reprovado".

12. O sistema deverá suportar a execução em qualquer plataforma de hardware

e/ou sistema operacional.

13. O sistema deve enviar automaticamente para o e-mail dos gestores

autorizados um relatório com o número de alunos inadimplentes por curso.
16712855225

14. O sistema não deve revelar quaisquer dados pessoais dos alunos aos
professores, exceto informações sobre notas e faltas no curso em que o
professor leciona.

15. O sistema deve permitir que o professor inclua ou modifique as notas de seus
alunos durante o semestre letivo.

16. A quantidade de memória necessária para que um terminal possa executar o

sistema nas condições mínimas aceitáveis é de 1 gigabyte.

Prof. Diego Carvalho [Link] Pág. 65 de 106

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 04

17. A taxa aceitável de falhas nas operações realizadas pelo usuário no sistema
deve ser de 1 falha para cada 200 operações.

18. O sistema e sua respectiva documentação deverão ser entregues em um ano

a partir da data atual.

19. O sistema não deve permitir operações que beneficiem alguns usuários em
detrimento de outros.

20. A interface do usuário deve ser construída utilizando HTML5 e CSS.

21. Se a média do aluno por disciplina, calculada no final do semestre, for menor
do que 7, deve ser exibido no boletim do aluno a informação "Reprovado".

Baseado nos requisitos apresentados, é correto afirmar que são requisitos

funcionais os de números:

a) 1, 2, 6, 10, 11, 14, 15, 16 e 21.

b) 1, 6, 8, 10, 11, 13, 14, 17, 18 e 19.
c) 1, 6, 7, 8, 10, 11, 13, 15 e 21.
d) 1, 3, 4, 8, 10, 11, 12, 13, 15, 18 e 21.
e) 2, 3, 4, 5, 9, 12, 14, 16, 17, 18, 19 e 20.

Comentários:

Requisitos Funcionais (RF): 1, 6, 7, 8, 10, 11, 13, 15, 21; Requisitos Não-Funcionais (RNF):
2, 3, 4, 5, 9, 12, 14, 16, 17, 18, 19, 20. Não era necessário analisar todos os requisitos,
era possível fazer por eliminação, i.e., 1 é RF, elimina-se a Letra E; 2 é RNF, elimina-
se a Letra A; 3 é RNF, elimina-se a Letra D; 7 é RF, elimina-se a Letra B.
16712855225

Gabarito: C

11. (FCC - 2013 – MPE/MA – Analista de Sistemas) O escopo de um projeto é

determinado pelo levantamento de requisitos funcionais e não funcionais. Dentre
os requisitos não funcionais se enquadram os requisitos organizacionais, que
podem ser divididos em:

a) reguladores e éticos.
b) ambientais, operacionais e de desenvolvimento.
c) contábeis e de segurança.

Prof. Diego Carvalho [Link] Pág. 66 de 106

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 04

d) de desempenho e de espaço.
e) de eficiência, de confiança e de proteção.

Comentários:

Os Requisitos Organizacionais podem ser divididos em Requisitos Ambientais,

Operacionais e de Desenvolvimento (ou Implementação).

Gabarito: B

12. (FCC - 2012 - MPE-PE - Analista Ministerial - Informática) Os requisitos não

funcionais não estão diretamente ligados aos serviços específicos oferecidos pelo
sistema a seus usuários. Eles podem estar relacionados às propriedades
emergentes do sistema, como confiabilidade, tempo de resposta e ocupação de
área, entre outros. Dentre os tipos de requisitos não funcionais, é possível
destacar os requisitos de produto, organizacionais e externos. Dentre os
requisitos de produto, podemos citar os requisitos:

a) de eficiência e de confiança.
b) contábeis e de desempenho.
c) legais e de usabilidade.
d) reguladores e de proteção.
e) legais e contábeis.

Comentários:

Os Requisitos de Produto são: Desempenho, Confiabilidade, Portabilidade,

Eficiência, Performance e Espaço (8ª Edição); ou Usabilidade, Eficiência,
Desempenho, Espaço, Proteção e Confiabilidade (9ª Edição).
16712855225

Gabarito: A

13. (FCC - 2012 - TRE- - Analista Judiciário - Análise de Sistemas) Considere:

I. Para cada cliente deve ser aplicado um identificador único.

II. O tempo de resposta entre a requisição e a informação não pode exceder a 2

ms.

Prof. Diego Carvalho [Link] Pág. 67 de 106

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 04

III. Clientes têm filiais que devem "carregar", na base de dados, o identificador
do cliente principal.

IV. O sistema não deve ferir as leis de proteção ambiental.

São requisitos não funcionais os que constam em

a) I e II, apenas.
b) II e III, apenas.
c) II e IV, apenas.
d) I, III e IV, apenas.
e) I, II, III e IV.

Comentários:

(I) RF; (II) RNF; (III) RF; (IV) RNF.

Gabarito: C

14. (FCC - 2012 - TST - Analista Judiciário - Análise de Sistemas) Na Engenharia de

Requisitos, o gerente de requisitos:

a) acompanha e monitora ações durante a verificação do software, sendo este o

processo que garante o atendimento aos requisitos informados pelo usuário
final.

b) possui autonomia para realizar alterações no projeto para garantir que o

software seja bem construído e atenda às necessidades da equipe de
desenvolvimento. 16712855225

c) mantém atualizados os requisitos junto ao usuário final e a equipe de

desenvolvimento, a fim de obter sucesso no processo de homologação do
software, atendendo as necessidades e expectativas.

d) classifica os requisitos em diferentes tipos, sendo os do tipo funcional

relacionados com o custo e confiabilidade do software e os do tipo não-funcional
relacionados com os casos de uso.

e) obtém o comprometimento dos integrantes da equipe de desenvolvimento

de software para o cumprimento do processo de software.

Prof. Diego Carvalho [Link] Pág. 68 de 106

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 04

Comentários:

(a) Não é durante a Verificação, mas Validação de Software; (b) Não são as
necessidades da Equipe de Desenvolvimento, mas dos usuários; (c) Perfeito, é
exatamente isso; (d) Estão invertidos, custo e confiabilidade são RNF e Casos de Uso
são RF; (e) Isso é responsabilidade do Gerente de Projetos e, não, do Gerente de
Requisitos.

Gabarito: C

15. (FCC - 2012 - -PE - Analista Judiciário - Análise de Sistemas) Na engenharia de

requisitos trata-se de uma técnica de elicitação que ocorre em ambiente mais
informal em que toda a idéia deve ser levada em consideração para a solução
de um problema, sendo proibida a crítica a qualquer sugestão dada, e
encorajada, inclusive, a criação de ideias que pareçam estranhas ou exóticas:

a) Prototipação.
b) Entrevista.
c) Questionário.
d) Brainstorming.
e) Análise de protocolos.

Comentários:

Trata-se da Técnica de Brainstorming.

Gabarito: D
16712855225

16. (FCC - 2011 - TRT - 19ª Região (AL) - Analista Judiciário - Tecnologia da
Informação) De acordo com Sommerville, são atividades do processo de
elicitação de requisitos, pela ordem:

a) casos de uso; análise; projeto; arquitetura.

b) etnografia; casos de uso; análise; validação; arquitetura.
c) entrevista; etnografia; documentação; registro.
d) cenários; classificação; organização; priorização; documentação.
e) obtenção; classificação e organização; priorização e negociação;
documentação.

Prof. Diego Carvalho [Link] Pág. 69 de 106

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 04

Comentários:

De acordo com Sommerville (8ª Ed.): Obtenção; Classificação e Organização;

Priorização e Negociação; e Documentação.

Gabarito: E

17. (FCC - 2011 - INFRAERO - Analista de Sistemas - Desenvolvimento e

Manutenção) A engenharia de requisitos ajuda os engenheiros de software a
compreender melhor o problema que eles vão trabalhar para resolver. Ela inclui
um conjunto de tarefas que levam a um entendimento de qual será o impacto
do software sobre o negócio, do que o cliente quer e de como os usuários finais
vão interagir com o software. A função de negociação no processo de
engenharia de requisitos:

a) especifica, revisa e valida o problema de modo a garantir que seu

entendimento e o entendimento do cliente sobre o problema coincidam.

b) refina e modifica os requisitos. É uma ação de modelagem de análise

composta de várias tarefas de modelagem e refinamento.

c) define quais são as prioridades, o que é essencial, o que é necessário. Clientes,

usuários e outros interessados são solicitados a ordenar os requisitos e depois
discutir os conflitos de prioridade.

d) ajuda o cliente a definir o que é necessário.

e) define o escopo e a natureza do problema a ser resolvido.

16712855225

Comentários:

Galera... falou em Negociação, tem que lembrar de consenso entre as partes

interessadas. E para chegar a um consenso, deve-se definir prioridades.

Gabarito: C

18. (FCC - 2011 - TRT - 1ª REGIÃO (RJ) - Analista Judiciário - Tecnologia da

Informação) A técnica utilizada na compreensão de requisitos sociais e
organizacionais por observação das rotinas dos envolvidos é a:

Prof. Diego Carvalho [Link] Pág. 70 de 106

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 04

a) prototipação.
b) por pontos de vista.
c) por cenário.
d) entrevista.
e) etnografia.

Comentários:

Observação de Rotinas? Etnografia!

Gabarito: E

19. (FCC - - TRT - 7ª Região (CE) - Analista Judiciário - Tecnologia da

Informação) No processo de engenharia de requisitos, é uma técnica de
observação que pode ser usada para compreender os requisitos sociais e
organizacionais.

Trata-se de

a) Workshop.
b) Brainstorming.
c) Scrum.
d) Análise de ponto de vista.
e) Etnografia.

Comentários:

Já viram quantas vezes essa técnica caiu em provas? De novo, Etnografia!

16712855225

Gabarito: E

(FCC - 2010 - MPE-RN - Analista de Tecnologia da Informação - Engenharia de

Software) Na engenharia de software, etnografia é:

a) uma fase do processo de software aplicada no modelo em cascata.

b) uma fase do processo de software aplicada no modelo em espiral.

c) uma técnica de observação que pode ser usada para compreender os

requisitos sociais e organizacionais.

Prof. Diego Carvalho [Link] Pág. 71 de 106

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 04

d) uma técnica aplicada na engenharia de requisitos cujo objetivo é definir, a

priori, as classes que contém elementos gráficos (BLOB).

e) um projeto cujo principal objetivo é criar interfaces gráficas, que facilitam o

acesso do usuário (GUI).

Comentários:

Uma técnica de observação para compreender requisitos.

Gabarito: C

21. (FCC - - TRT - 3ª Região (MG) - Analista Judiciário - Tecnologia da

Informação) São técnicas e abordagens utilizadas na obtenção dos requisitos:

a) estresse, cenários e workshop.

b) workshop, etnografia e estresse.
c) etnografia, questionários e validação.
d) pontos de vista, cenários e entrevista.
e) pontos de vista, casos de uso e validação.

Comentários:

Pontos de Vista, Cenários e Entrevista.

barito: D

(FCC - 2011 - INFRAERO - Analista de Sistemas - Desenvolvimento e

16712855225

Manutenção) Os produtos de trabalho resultantes da engenharia de requisitos

são avaliados quanto à qualidade durante a etapa de validação de requisitos.
Analise os itens a seguir referentes a essa etapa:

I. Um dos principais mecanismos de validação de requisitos é a avaliação técnica

formal.

II. O modelo de análise pode garantir que os requisitos foram consistentemente

declarados.

Prof. Diego Carvalho [Link] Pág. 72 de 106

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 04

III. É frequentemente útil examinar cada requisito em face de um conjunto de

questões do tipo checklist.

IV. A equipe de revisão que avalia os requisitos inclui apenas pessoas com
conhecimento técnico na área de TI, como engenheiros de softwares,
desenvolvedores etc.

Está correto o que consta em:

a) I, II, III e IV.

b) II e IV, apenas.
c) I, II e IV, apenas.
d) II, III e IV, apenas.
e) I, II e III, apenas.

Comentários:

(I) Correto! Um dos principais mecanismos de validação de requisitos é a avaliação

técnica formal; (II) Correto! Também conhecida como Revisão Técnica Formal. (III)
Correto! Embora a revisão para validação dos requisitos possa ser conduzida de
qualquer maneira desde que possibilite a descoberta de erros nos requisitos, é útil
examinar cada requisito contra um checklist. (IV) O time de revisão inclui os
engenheiros de sistema, clientes, usuários e outros stakeholders que examinam a
especificação do sistema à procura de erros de conteúdo ou interpretação, pontos
onde pode ser necessário esclarecimento, perda de informações, inconsistências
(um dos maiores problemas da engenharia de grandes produtos), requisitos
conflitantes, ou requisitos irreais (de desenvolvimento impossível).

16712855225

Gabarito: E

(FCC - 2013 – DPE/SP – Analista de Sistemas) Em uma das etapas da Engenharia

de Requisitos há a preocupação em se observar a especificação produzida,
visando verificar que os requisitos tenham sido declarados, por exemplo, sem
ambiguidades.

O texto refere-se à etapa de:

a) gestão dos requisitos.

b) elicitação dos requisitos.
c) negociação dos requisitos.

Prof. Diego Carvalho [Link] Pág. 73 de 106

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 04

d) levantamento dos requisitos.

e) validação dos requisitos.

Comentários:

Galera, os produtos de trabalho resultantes da engenharia de requisitos são

avaliados quanto a qualidade no processo de validação. A validação dos requisitos
examina a especificação para garantir que todos os requisitos do software tenham
sido declarados de modo não ambíguo.

Gabarito: E

24. (FCC - 2011 - TRT - 19ª Região (AL) - Analista Judiciário - Tecnologia da
Informação) A avaliação do impacto de mudança de um requisito, muitas vezes,
faz com que seja necessário retornar à sua fonte. Na validação dos requisitos, a
equipe deve estar atenta, portanto, à:

a) rastreabilidade.
b) adaptabilidade.
c) qualidade.
d) facilidade de compreensão.
e) facilidade de verificação.

Comentários:

Trata-se da Rastreabilidade, i.e., avaliar impacto no projeto da mudança em um

requisito.

16712855225

Gabarito: A

(FCC - - PGE- - Técnico Superior de Análise de Sistemas e Métodos) No

âmbito da Engenharia de Requisitos, uma revisão técnica formal é:

a) um teste de desempenho.
b) uma técnica de elicitação.
c) um instrumento de rastreamento.
d) o resultado do escopo.
e) um mecanismo de validação.

Comentários:

Prof. Diego Carvalho [Link] Pág. 74 de 106

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 04

A Revisão Técnica Formal é uma técnica ou mecanismo de validação de requisitos.

Gabarito: E

(FCC - 2011 - TRT - 23ª REGIÃO (MT) - Analista Judiciário - Tecnologia da

Informação) Tabelas de rastreamento para relacionar os requisitos identificados
a um ou mais aspectos do sistema ou do seu ambiente devem ser desenvolvidas,
segundo Pressman, na engenharia de requisitos por meio da função de:

a) gestão.
b) especificação.
c) elaboração.
d) negociação.
e) validação.

Comentários:

De acordo com Pressman, a gestão de requisitos começa com a identificação. A

cada requisito é atribuído um modo identificador. Uma vez identificados os
requisitos, tabelas de rastreamento são desenvolvidas.

Gabarito: A

27. (FCC - 2010 - MPE-RN - Analista de Tecnologia da Informação - Engenharia de

Software) As políticas de rastreabilidade de requisitos são decididas durante o
estágio de:

a) agregação dos requisitos funcionais, apenas.

16712855225

b) implementação do sistema, apenas.

c) implementação do sistema
d) eliminação dos requisitos não funcionais.
e) gerenciamento de requisitos.

Comentários:

Trata-se do Gerenciamento de Requisitos.

Gabarito: E

Prof. Diego Carvalho [Link] Pág. 75 de 106

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 04

ACERTEI ERREI

16712855225

Prof. Diego Carvalho [Link] Pág. 76 de 106

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 04

(FGV - 2010 - BADESC - Analista de Sistemas - Desenvolvimento de Sistemas)

Analise o fragmento a seguir:

"A base de dados deve ser protegida para acesso apenas de usuários
autorizados".

O fragmento acima apresenta um exemplo do seguinte requisito:

a) funcional.
b) de usuário.
c) de sistema.
d) de domínio.
e) não-funcional.

Comentários:

Sommerville ainda diz que os requisitos não funcionais estão raramente associados
às características individuais do sistema. Tratam-se de qualidades globais de um
software, como manutenibilidade, usabilidade, desempenho, custos e várias outras.
Normalmente estes requisitos são descritos de maneira informal. Galera, em geral,
afetam a arquitetura do sistema.
16712855225

Questão polêmica! No entanto, trata-se de um Requisito Não-Funcional!

Gabarito: E

(FGV - - MEC - Analista de Sistemas - Especialista) Requisitos não-

funcionais estão diretamente relacionados com a satisfação dos usuários.
Assinale a alternativa que não indique um requisito não-funcional:

a) O sistema de arquivos deve ser protegido, para acesso, apenas, de usuários

autorizados.

Prof. Diego Carvalho [Link] Pág. 77 de 106

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 04

b) O software deve ser implementado usando os conceitos de orientação a

objetos.

c) O tempo de desenvolvimento do software não deve ultrapassar seis meses.

d) O software poderá ser executado em plataforma windows e linux.

e) O software deve emitir relatórios de vendas a cada quinze dias.

Comentários:

Todos, exceto o último, são requisitos não-funcionais – restrições sobre o sistema.

Já o último é uma funcionalidade a ser oferecida pelo sistema.

Gabarito: E

(FGV - 2009 - MEC - Analista de Sistemas - Especialista) As declarações de

serviços que o sistema deve fornecer, de como ele deve reagir a entradas
específicas ou se comportar em determinadas situações, são chamadas de
requisitos:

a) não-funcionais.
b) de domínio.
c) de sistema.
d) funcionais.
e) de usuário.

Comentários:
16712855225

Requisitos Funcionais: são declarações de serviços que um sistema deve fornecer,

como o sistema deve reagir a entradas específicas e como o sistema deve (ou não) se
comportar em situações particulares. Depende do tipo de software, dos usuários
esperados e do tipo de sistema onde o software será implantado. Eles fazem parte da
arquitetura do aplicativo de um sistema.

Conforme vimos em aula, são Requisitos Funcionais.

Gabarito: D

Prof. Diego Carvalho [Link] Pág. 78 de 106

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 04

(FGV - 2008 - Senado Federal - Analista de Sistemas) Entre as atividades listadas

a seguir, uma não faz parte da Engenharia de Requisitos. Assinale-a.

a) estudo de viabilidade.
b) análise de risco.
c) levantamento de necessidades do cliente.
d) verificação.
e) gerenciamento.

Comentários:

Pessoal, questão complicada! Essas fases não existem exatamente dessa maneira
em nenhuma bibliografia, então temos que fazer algumas associações. Estudo de
Viabilidade é a primeira fase; Análise de Riscos não está em nenhum lugar;
16712855225

Levantamento de Necessidades do Cliente pode ser entendido como Elicitação de

Requisitos; Verificação pode ser incluída na fase de Validação (apesar de eu não
concordar); por fim, gerenciamento percorre de fato todas essas fases.

Gabarito: B

(FGV - - MEC - Analista de Sistemas - Especialista) Existem técnicas que são

usadas na fase de levantamento de requisitos para coletar conhecimento dos
usuários sobre os requisitos. Assinale a alternativa que indique apenas técnicas
utilizadas na fase de levantamento de requisitos.

Prof. Diego Carvalho [Link] Pág. 79 de 106

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 04

a) JAD, WFMS, WBS, cenários e brainstorming.

b) JAD, cenários, WFMS, questionários e intercepting.
c) cenários, entrevistas, protótipos, workshop, brainstorming.
d) leitura de documentos, protótipos, workshop, WBS e workflow.
e) brainstorming, protótipos, workflow, leitura de documentos e intercepting.

Comentários:

Cenários, Entrevistas, Protótipos, Workshop e Brainstorm!

Gabarito: C

(FGV - 2010 - FIOCRUZ - Tecnologista em Saúde - TI - Sistemas de Informação)

Sobre os processos de engenharia de requisitos, na elicitação e na análise ocorre
total interação com os stakeholders no sistema, sendo o principal objetivo:

a) a obtenção dos requisitos.

b) a homologação do sistema.
c) a elaboração do manual do usuário.
d) a conversão de especificações em requisitos.
e) a execução do estudo de viabilidade do sistema.

Comentários:

É o processo de levantamento e derivação de requisitos de sistema através da

observação de sistemas existentes, discussões com usuários potenciais e
compradores, análise de tarefas, etc. Isso pode envolver o desenvolvimento de um ou
mais modelos de sistema e protótipos, que ajudam o analista a compreender o
sistema a ser especificado. 16712855225

Tranquilo, não? O objetivo principal é a obtenção dos requisitos!

Gabarito: A

ACERTEI ERREI

Prof. Diego Carvalho [Link] Pág. 80 de 106

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 04

LISTA DE EXERCÍCIOS COMENTADOS (CESPE)

ENGENHARIA DE REQUISITOS

(CESPE - 2011 - EBC - Analista - Engenharia de Software) No processo de

construção e(ou) manutenção de um produto de software, o termo requisito
pode ser definido da seguinte forma: uma condição, característica ou
capacidade, determinada no universo das necessidades do negócio do usuário,
que deve ser atendida por um software na forma de aspectos funcionais e não
funcionais.

(CESPE - 2010 - ABIN - Desenvolvimento E Manutenção De Sistemas) Requisitos

não funcionais são restrições sobre os serviços ou as funções oferecidas pelo
sistema, e podem ser, também, declarações de serviços que o sistema deve
fornecer, como o sistema deve reagir a entradas específicas e como deve
comportar-se em diversas situações.

(CESPE - 2010 - MPU - Analista de Informática - Desenvolvimento de Sistemas)

Os requisitos normativos, geralmente oriundos da análise das regras de negócio
a que está submetido um sistema, nunca podem ser considerados requisitos
funcionais, por estarem fora do sistema, ou seja, do domínio do negócio.

(CESPE - - DETRAN-DF - Análise de Sistemas) Requisitos funcionais são

restrições sobre as funções ou serviços oferecidos pelo sistema. Esses requisitos
consideram as declarações de serviços, a forma do sistema reagir e como ele
deve se comportar em determinadas situações. Cenários e casos de uso são
técnicas eficazes para elicitação de requisitos funcionais segundo pontos de vista
de interação.
16712855225

(CESPE - 2011 - EBC - Analista - Engenharia de Software) O principal artefato

elaborado no processo de produção de requisitos do sistema, segundo a ER, é
o documento de requisitos. Por sua vez, o documento de requisitos é uma
declaração formal dos requisitos para os stakeholders, que podem ser clientes,
usuários finais ou a equipe de desenvolvimento do software.

(CESPE - - MPE- - Analista de Sistemas) Os requisitos de um sistema são

descrições dos serviços fornecidos pelo sistema e suas restrições operacionais. O
processo de descobrir, analisar, documentar e verificar esses serviços e restrições

Prof. Diego Carvalho [Link] Pág. 81 de 106

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 04

é denominado engenharia de requisitos. Requisitos de um sistema de software

podem ser funcionais, não funcionais ou de domínio.

(CESPE - 2008 - STJ - Analista Judiciário - Tecnologia da Informação) Os

requisitos de um sistema podem ser descrições dos serviços fornecidos ou
restrições operacionais. Requisitos podem ainda ser classificados como
funcionais, não funcionais, ou de domínio. A engenharia de requisitos visa
compreender e definir os requisitos. Um processo de engenharia de requisitos
pode envolver o estudo de viabilidade, a análise, a especificação e a validação
de requisitos.

(CESPE - 2004 – AGE/ES – Auditor do Estado - Tecnologia da Informação) A

engenharia de requisitos fornece mecanismos que permitem entender e analisar
a necessidade de o cliente avaliar a exequibilidade, negociar uma solução
razoável e especificá-la de maneira não-ambígua, validar a especificação e
administrar os requisitos.

(CESPE - 2011 - FUB - Analista de Tecnologia da Informação - Específicos) O

estudo de viabilidade, uma atividade inicial do processo de engenharia de
requisitos, consiste em um conjunto preliminar de requisitos de negócio, um
esboço da descrição do sistema e da forma como o sistema pretende apoiar os
processos de negócios.

10. (CESPE - 2004 – Prefeitura de Boa Vista - Analista Municipal) Requisitos

adequadamente definidos constituem base importante sobre a qual um sistema
poderá ser bem desenvolvido. No processo de engenharia de requisitos, o
estudo de viabilidade utiliza as informações do processo de levantamento de
requisitos para gerar um relatório que recomenda se é viável ou não realizar o
processo de desenvolvimento do sistema.
16712855225

11. (CESPE - 2011 - BRB - Analista de Tecnologia da Informação) O levantamento de

requisitos de software privilegia a visão do desenvolvedor em relação aos
requisitos de um produto. Já a análise dos requisitos prioriza a visão que o cliente
e os usuários têm dos requisitos de um produto.

12. (CESPE - 2011 - FUB - Analista de Tecnologia da Informação - Específicos) A

etnografia, uma técnica de levantamento de requisitos, é uma abordagem
completa para elicitação, utilizada para compreender os requisitos sociais e
organizacionais e que identifica novas características a serem acrescentadas em
um sistema.

Prof. Diego Carvalho [Link] Pág. 82 de 106

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 04

13. (CESPE - 2010 - ABIN - Oficial Técnico De Inteligência - Área De Desenvolvimento

E Manutenção De Sistemas) Se os requisitos forem organizados de acordo com
os diversos pontos de vista relativos a grupos de usuários do sistema, é possível
identificar aqueles comuns a todos ou à maioria dos pontos de vista. Esses
requisitos comuns podem estar relacionados a assuntos separados,
implementados como extensões da funcionalidade central.

14. (CESPE - 2010 - MPU - Analista de Informática - Desenvolvimento de Sistemas)

O levantamento de requisitos é realizado ao final da primeira versão de um
protótipo, para se definir, junto aos envolvidos no processo, quais são as
premissas básicas para o início do entendimento das funcionalidades desejadas.

15. (CESPE - 2010 - MPU - Analista de Informática - Desenvolvimento de Sistemas)

Embora a criação de uma sequência ilustrada de telas por meio de programas
de desenho gráfico seja útil para a identificação de alguns requisitos do software,
ela não é considerada uma atividade de prototipação por não envolver o uso de
uma linguagem de programação.

16. (CESPE - 2008 - SERPRO - Analista - Desenvolvimento de Sistemas) O

levantamento de requisitos é importante, porém não é fundamental, pois
recomenda-se avançar o quanto antes para as demais atividades que permitam
uma visualização do software e reduzam a ansiedade do cliente em ver algo
pronto.

17. (CESPE - 2004 – COHAB - Analista de Sistemas) O QFD (Quality Function

Deployment) tem uma abordagem embasada na criação de uma equipe
formada por clientes e desenvolvedores, que trabalham juntos para identificar o
problema, propor elementos da solução, negociar diferentes abordagens e
16712855225

especificar um conjunto de requisitos da solução.

18. (CESPE - 2004 – COHAB - Analista de Sistemas) As atividades de análise de

requisitos resultam na especificação das características operacionais do software,
na indicação da interface do software com outros elementos do sistema e no
estabelecimento de restrições que o software deve satisfazer.

19. (CESPE - 2004 – COHAB - Analista de Sistemas) À medida que os requisitos são
elucidados, o analista de software pode criar um conjunto de cenários, ou seja,
casos de uso, que identificam uma linha de uso para o sistema a ser construído.

Prof. Diego Carvalho [Link] Pág. 83 de 106

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 04

(CESPE - - IPEA - Analista - Desenvolvimento de Sistemas) Elicitação

envolve a identificação sistemática de requisitos nem sempre explicitados pelos
clientes. Protótipos, pesquisas estruturadas, testes-beta, análise de casos de
negócio, walkthroughs, QFD, grupos de trabalho são exemplos de técnicas
utilizadas para elicitar necessidades, expectativas, restrições e interfaces dos
stakeholders para todas as fases do ciclo de vida do produto.

21. (CESPE - - SERPRO - Analista de Sistemas) O levantamento de requisitos é

importante, porém não é fundamental, pois recomenda-se avançar o quanto
antes para as demais atividades que permitam uma visualização do software e
reduzam a ansiedade do cliente em ver algo pronto.

(CESPE - 2005 - SERPRO - Analista de Sistemas) Uma das principais atividades

relacionadas à engenharia de software é o levantamento dos requisitos. Nesse
contexto, foi introduzida, na década de 80 do século XX, uma técnica de
entrevista conhecida como JAD (Joint Application Development), que consistia
em uma rápida entrevista e um processo acelerado de coleta de dados em que
todos os principais usuários e o pessoal da análise de sistemas agrupavam-se
em uma única e intensiva reunião.

(CESPE - – TCE/RN - Analista de Sistemas) A etnografia é uma técnica

utilizada para a descoberta de requisitos de sistemas de software na qual, por
meio de observações, procura-se compreender os requisitos sociais e
organizacionais do ambiente onde o sistema será usado.

24. (CESPE - 2012 - MPE-PI - Analista Ministerial - Informática - Cargo 6) Identificada

facilidade do cliente em entender uma especificação matemática, é correto
utilizar, também, na especificação dos requisitos, notações baseadas em
máquinas de estado finito, uma vez que elas podem reduzir a ambiguidade de
16712855225

um documento de requisitos.

(CESPE - 2010 - DETRAN-ES - Analista de Sistemas) A técnica de brainstorm é

adequada para a produção de especificações de requisitos para um sistema de
informação em desenvolvimento.

(CESPE - 2007 – MPU - Analista de Sistemas) A especificação de requisitos

permite, em determinado momento, revelar o que o sistema irá realizar no que
se refere às funcionalidades, sem definir, nesse momento, como as
funcionalidades serão implementadas.

Prof. Diego Carvalho [Link] Pág. 84 de 106

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 04

27. (CESPE - – TSE- Analista de Sistemas - IV) Na especificação de requisitos,

pode-se construir um documento que descreva o sistema em termos gerais. Esse
documento apresenta uma visão do sistema e pode capturar as necessidades
dos usuários.

(CESPE - 2011 - EBC - Analista - Engenharia de Software) Uma das principais

técnicas de verificação é a prototipação. Um protótipo é um produto
parcialmente desenvolvido, que possibilita aos clientes e desenvolvedores
examinarem certos aspectos do sistema proposto e decidir se eles são ou não
apropriados ou adequados para o produto acabado.

(CESPE - 2011 - -ES - Analista Judiciário - Análise de Sistemas - Específicos)

Assim como o software, os requisitos também devem ser avaliados quanto à
qualidade. A validação, atividade da engenharia de requisitos, é responsável por
garantir que os requisitos tenham sido declarados de forma clara e precisa. Além
disso, a validação busca detectar inconsistências, erros e omissões, objetivando
alinhar os requisitos às normas estabelecidas para o projeto, produto e processo.

(CESPE - 2011 - STM - Analista Judiciário - Análise de Sistemas - Específicos) São

consideradas técnicas de validação de requisitos: revisões de requisitos,
prototipação e geração de casos de teste.

31. (CESPE - 2010 - MPU - Analista de Informática - Desenvolvimento de Sistemas)

A verificação de requisitos tem por objetivo analisar se os modelos construídos
estão de acordo com os requisitos definidos. Por sua vez, a validação de
requisitos visa assegurar que as necessidades do cliente estão sendo atendidas
por tais requisitos.

(CESPE - 2011 - -ES - Técnico de Informática - Específicos) Verificação e

16712855225

validação são atividades da análise de software, necessárias para se identificar o

que o software precisa executar, seguida de uma avaliação do usuário quanto às
atividades definidas.

(CESPE - 2007 - MPU – Analista de Informática) Na validação de requisitos —

parte integrante da especificação desses requisitos —, é correto o uso de
diagramas da UML, tais como diagrama de classes, de casos de uso e de
interação.

Prof. Diego Carvalho [Link] Pág. 85 de 106

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 04

34. (CESPE - 2011 - MEC - Gerente de Projetos) A rastreabilidade de requisitos ocorre

apenas na relação entre os requisitos propriamente ditos e os artefatos ou
subprodutos de desenvolvimento gerados.

(CESPE - 2010 - TCU - Auditor Federal de Controle Externo - Tecnologia da

Informação - Parte II) Por se tratar de função essencial da engenharia de
requisitos, a gestão formal de requisitos é indispensável mesmo para projetos de
pequeno porte, com apenas duas ou três dezenas de requisitos identificáveis.

(CESPE - 2013 - MPU - Analista - Desenvolvimento de Sistemas) As atividades do

gerenciamento de requisitos incluem a análise e a negociação, a qual visa
garantir que todos os requisitos do sistema tenham sido declarados de modo
não ambíguo, sem inconsistências, omissões e erros.

37. (CESPE - 2009 - IPEA - Analista - Desenvolvimento de Sistemas) A política

organizacional para o planejamento e execução do processo de gerenciamento
de requisitos reflete as expectativas organizacionais para processos de gestão de
requisitos e para que seja possível identificar inconsistências entre os requisitos
e os planos do projeto.

(CESPE - - SERPRO - Analista de Sistemas) O gerenciamento de requisitos

inclui, entre outras, as seguintes atividades: levantar, analisar, especificar, validar
e prototipar requisitos funcionais e não-funcionais.

(CESPE - 2015 – MPOG/ATI - Analista de Sistemas) Tão logo exista uma versão
do documento de requisitos, o processo de gerenciamento de requisitos deverá
ser iniciado.

40. (CESPE - 2015 – MPOG/ATI - Analista de Sistemas) As informações de

16712855225

rastreabilidade de requisitos possibilitam a realização de estimativa do custo de

mudanças em requisitos.

41. (CESPE - 2015 – MPOG/ATI - Analista de Sistemas) As mudanças de requisitos

em processos ágeis de desenvolvimento não seguem um processo formal de
gerenciamento de requisitos.

42. (CESPE - 2015 – MPOG/ATI - Analista de Sistemas) Para a elicitação dos

requisitos, é indicada à empresa a realização de um workshop de requisitos, em
que seja determinado um facilitador, mesmo que sem grande experiência com
os processos de gerenciamento de requisitos.

Prof. Diego Carvalho [Link] Pág. 86 de 106

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 04

43. (CESPE - 2015 – MPOG/ATI - Analista de Sistemas) Os requisitos não funcionais

a serem especificados estabelecerão restrições que devem ser seguidas por todo
o sistema da referida empresa, podendo até mesmo levar à necessidade de
definição de requisitos funcionais.

44. (CESPE - 2015 – MPOG/ATI - Analista de Sistemas) A definição de um protótipo

para a validação dos requisitos pode tornar o processo de requisitos mais barato
e mais simplificado, já que ele vai corresponder à real forma de uso do sistema
a ser construído.

45. (CESPE - 2015 – MPOG/ATI - Analista de Sistemas) Uma forma de validação dos
requisitos é a geração de casos de teste para os requisitos documentados.

46. (CESPE - 2015 – MPOG/ATI - Analista de Sistemas) No ciclo de vida do software,

o congelamento dos requisitos do software garante que este, quando em
desenvolvimento, atenda à expectativa do usuário, desde que tudo que tenha
sido requisitado seja implementado.

47. (CESPE - 2015 – STJ – Analista de Sistemas) Os requisitos ambientais,

operacionais e de desenvolvimento são organizacionais e não funcionais.

48. (CESPE - 2015 – STJ – Analista de Sistemas) Os requisitos reguladores, legais e

éticos são externos e não funcionais.

16712855225

Prof. Diego Carvalho [Link] Pág. 87 de 106

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 04

LISTA DE EXERCÍCIOS COMENTADOS (ESAF)

ENGENHARIA DE REQUISITOS

(ESAF - 2005 – AFRFB - Analista de Sistemas - II) Durante a análise de requisitos,

são especificados a função e o desempenho do software, bem como a sua
interface com outros elementos do sistema. Nessa etapa, também, são
estabelecidas as restrições de projeto, a que o software deve atender.

(ESAF - – AFRFB - Analista de Sistemas - III) Durante a análise de requisitos,

o principal foco do analista recai sobre como? e não sobre o que?. Nesse caso,
o analista concentra-se em como o sistema produz ou consome dados, como o
sistema deve executar as funções e como as restrições e interfaces são definidas.

(ESAF - – AFRFB - Analista de Sistemas - IV) Durante a especificação dos

requisitos, são estabelecidos os critérios que permitirão ao desenvolvedor e ao
cliente avaliar a qualidade, assim que o software for construído.

(ESAF - 2010 – CVM – Analista de Sistemas) Assinale a opção correta.

a) Gestão de requisitos preocupa-se com a documentação, atualização e

controle de stakeholders envolvidos na fase de identificação da demanda.

b) Engenharia de requisitos compreende: identificar, analisar, especificar e definir

as necessidades de negócio que um aplicativo deve prover para solução do
problema levantado.

c) Engenharia de requisitos compreende: planejar, especificar e desenvolver as

16712855225

necessidades de negócio que um aplicativo deve prover para minimização dos

problemas levantados.

d) Engenharia de requisitos compreende: identificar, analisar, programar e testar

os programas das necessidades de solução de problemas que um negócio deve
prover para satisfazer usuários.

e) Gestão de requisitos preocupa-se com a documentação, direcionamento,

controle de definição e acesso aos requisitos levantados na fase de planejamento
de escopo.

Prof. Diego Carvalho [Link] Pág. 88 de 106

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 04

(ESAF - 2010 – MPOG – Analista de Sistemas) As áreas de esforços da Análise de

Requisitos são:

a) reconhecimento dos objetivos, avaliação e controle, modelagem, estruturação

e revisão.

b) reconhecimento do problema, avaliação e síntese, modelagem, especificação

e revisão.

c) reengenharia, planejamento, avaliação e controle, modelagem e conclusão.

d) reconhecimento do problema, análise e síntese, reengenharia, especificação e

análise de resultados.

e) reconhecimento do problema, modelagem, especificação de entidades,

estruturação e revisão.

16712855225

Prof. Diego Carvalho [Link] Pág. 89 de 106

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 04

LISTA DE EXERCÍCIOS COMENTADOS (FCC)

ENGENHARIA DE REQUISITOS
(FCC - 2012 - TST - Analista Judiciário - Análise de Sistemas) Na Engenharia de
Requisitos, o gerente de requisitos:

a) acompanha e monitora ações durante a verificação do software, sendo este o

processo que garante o atendimento aos requisitos informados pelo usuário final.

b) possui autonomia para realizar alterações no projeto para garantir que o

software seja bem construído e atenda as necessidades da equipe de
desenvolvimento.

c) mantém atualizados os requisitos junto ao usuário final e a equipe de

desenvolvimento, a fim de obter sucesso no processo de homologação do
software, atendendo as necessidades e expectativas.

d) classifica os requisitos em diferentes tipos, sendo os do tipo funcional

relacionados com o custo e confiabilidade do software e os do tipo não-funcional
relacionados com os casos de uso.

e) obtém o comprometimento dos integrantes da equipe de desenvolvimento de

software para o cumprimento do processo de software.

(FCC - 2012 - TCE-AP - Analista de Controle Externo - Tecnologia da Informação)

Em relação a requisitos de sistemas, considere:

I. O modo como um sistema deve reagir a certas entradas e o comportamento

16712855225

em que o sistema deve ter em certas situações e, em alguns casos, especificar o

que o sistema não deve fazer, são chamados de requisitos não-funcionais.

II. As restrições aos serviços ou funções de um sistema, como, por exemplo,

processos de desenvolvimento ou utilização de padrões, são requisitos de
funcionamento do sistema ou requisitos funcionais.

III. Requisitos que vem do domínio da aplicação do sistema e refletem

características ou restrições para aquele domínio são chamados de requisitos de
domínio e podem ser requisitos funcionais e/ou não-funcionais.

Prof. Diego Carvalho [Link] Pág. 90 de 106

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 04

Está correto o que se afirma em:

a) III, apenas.
b) I, II e III.
c) I e II, apenas.
d) II e III, apenas.
e) I, apenas.

(FCC - 2011 - INFRAERO - Analista de Sistemas - Gestão de TI - D) No contexto

de levantamento de requisitos, funcionalidade é um dos aspectos que deve ser
levado em conta na abordagem dos requisitos funcionais.

(FCC - 2010 - BAHIAGÁS - Analista de Processos Organizacionais - Análise de

Sistemas) É uma restrição sobre os serviços ou as funções oferecidos pelo
sistema. Pode ser uma restrição de timing, sobre o processo de desenvolvimento,
sobre o desempenho ou sobre a confiabilidade do sistema, entre outras. Trata-
se de:

a) requisito não funcional.

b) requisto funcional.
c) especificação de risco.
d) iteração de processo.
e) etnografia.

(FCC - 2006 - BACEN - Analista de Sistemas) Em relação à análise de requisitos

funcionais e não-funcionais, é correto afirmar:

a) Dependendo da fase de projeto, a análise dos requisitos funcionais e não-

16712855225

funcionais recebe o mesmo nível de tratamento, em função da necessidade de

se definir o que é para fazer, qual produto gerar (requisito não-funcional) e qual
a forma, conteúdo, comportamento e atributos deve conter o produto (requisito
funcional).

b) Os requisitos funcionais e não-funcionais têm tratamento diferenciado em

cada fase de projeto. Primeiro, é necessário definir o que é para fazer, qual
produto gerar (requisito não-funcional); segundo, qual forma, conteúdo,
comportamento e atributos deve conter o produto (requisito funcional). Isto quer
dizer que somente se consegue definir atributos ou características de qualidade
à medida que se tenha a definição do produto.

Prof. Diego Carvalho [Link] Pág. 91 de 106

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 04

c) Na fase de estudo preliminar ou estudos de projeto, a validação dos requisitos

depende do processo de qualificação das informações de origem,
funcionalidade e relacionamento de dependências dos requisitos e do processo
de qualificação de exigências pelos stakeholders. Nesta fase os requisitos não-
funcionais são documentados e priorizados para serem utilizados na fase de
implantação.

d) A fase de modelo físico deve agregar aos requisitos funcionais os requisitos

não-funcionais obtidos nas várias oportunidades de captura de informações,
tratá-los em termos de prioridade, precedência e relacionamentos entre si, com
ênfase em como o software deve funcionar.

e) Na fase de modelo lógico, são detalhados os eventos e visões dos processos,

identificados os papéis e responsabilidades dos stakeholders. Esta fase deve
agregar aos requisitos funcionais os requisitos nãofuncionais obtidos nas várias
oportunidades de captura de informações, tratá-los em termos de prioridade,
precedência e relacionamentos entre si.

(FCC - 2009 – SEFAZ/SP - Analista de Sistemas) É necessário que o software

calcule os salários dos diaristas e mensalistas e emita relatórios mensais
sumariados por tipo de salário. Entretanto, a base de dados deve estar protegida
e com acesso restrito aos usuários autorizados. De qualquer forma, o tempo de
resposta das consultas não deve superar os quinze segundos, pois inviabilizaria
todo o investimento nesse sistema. Devo lembrar que os relatórios individuais dos
departamentos, nos quais constam os salários dos funcionários, devem ser
emitidos quinzenalmente em razão dos adiantamentos e vales que recebem. É
fundamental que o software seja operacionalizado usando código aberto.
Necessito, ainda, forte gerenciamento de risco, prazo e custo, porque a entrega do
16712855225

produto final não pode ultrapassar o prazo de oito meses a contar da data de
início do projeto. No texto, são requisitos funcionais:

a) Calcule os salários dos diaristas e mensalistas e os relatórios individuais dos

departamentos, nos quais constam os salários dos funcionários, devem ser
emitidos quinzenalmente.

b) Necessito, ainda, forte gerenciamento de risco, prazo e custo e a base de

dados deve estar protegida e com acesso restrito aos usuários autorizados.

Prof. Diego Carvalho [Link] Pág. 92 de 106

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 04

c) É fundamental que o software seja operacionalizado usando código aberto e

emita relatórios mensais sumariados por tipo de salário.

d) Emita relatórios mensais sumariados por tipo de salário e Necessito, ainda,

forte gerenciamento de risco, prazo e custo.

e) A base de dados deve estar protegida e com acesso restrito aos usuários
autorizados e entrega do produto final não pode ultrapassar o prazo de oito
meses.

(FCC - 2010 – DPE/SP - Analista de Sistemas) Sobre análise de requisitos da

engenharia de software, considere:

I. Os requisitos de usuário podem descrever tanto requisitos funcionais quanto

requisitos não- funcionais.

II. Os requisitos de sistema podem descrever apenas requisitos não funcionais.

III. Os requisitos não-funcionais podem ser divididos em requisitos de produto,

organizacionais e externos.

Está correto o que se afirma em:

a) III, apenas.
b) I e II, apenas.
c) I e III, apenas.
d) II e III, apenas.
e) I, II e III.
16712855225

(FCC - - TRT - 3ª Região (MG) - Analista Judiciário - Tecnologia da

Informação) Com relação aos requisitos de software, considere:

I. funcionais são somente requisitos de usuário.

II. funcionais e não-funcionais podem ser requisitos de usuário.
III. funcionais e não-funcionais podem ser requisitos de sistema.

Está correto o que se afirma APENAS em

a) I.
b) II.

Prof. Diego Carvalho [Link] Pág. 93 de 106

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 04

c) III.
d) I e III.
e) II e III.

(FCC - 2010 – DPE/SP - Analista de Sistemas - III) No contexto da Engenharia de

Requisitos, considere:

I. O sistema deve fornecer uma entrada de dados que possibilite a inclusão de

atributos de permissão de acesso às dependências da corporação por técnicos,
supervisores e chefes.

II. Algumas permissões de acesso deverão ter tratamento especial para a entrada
de atributos. Para este tipo de permissão, atributos excedentes a uma faixa
predeterminada só poderão ser incluídos por chefes de seção.

Em relação às assertivas acima, é correto afirmar:

a) O item I trata de um requisito funcional e a ele está associado o requisito não

funcional, contido no item II.

b) O item I trata de um requisito não funcional e a ele está associado o requisito

funcional, contido no item II.

c) Ambos referem-se a requisitos funcionais.

d) A assertiva contida no item II é uma condição restritiva do requisito não

funcional do item I. Por si só, não constitui um requisito, tanto funcional quanto
não funcional.
16712855225

e) A assertiva contida no item II é uma condição restritiva do requisito funcional

do item I. Por si só, não constitui um requisito, tanto funcional quanto não
funcional.

10. (FCC - 2013 – SEFAZ/SP – Analista de Sistemas) Dentre os requisitos obtidos para
a construção do software constavam:

1. O software deve permitir as funções de cadastro, consultas diversas, alteração

de dados e exclusão de alunos, professores e demais colaboradores.

Prof. Diego Carvalho [Link] Pág. 94 de 106

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 04

2. O sistema deve ser fácil de usar, fácil de encontrar o que se procura e fácil de
memorizar os passos para executar as operações mais comuns.

3. O sistema deve ter seu funcionamento baseado nas tecnologias web.

4. Todas as operações disponibilizadas no sistema devem contemplar a

legislação vigente.

5. O sistema deve fazer interface com o sistema da Receita Federal por meio de
requisições/respostas utilizando XML.

6. Os alunos devem poder obter por meio do sistema informações sobre suas
faltas e notas em cada disciplina.

7. O boletim e o histórico do aluno poderão ser consultados e visualizados pelos

gestores, funcionários da secretaria e pelo próprio aluno.

8. Ao clicar em uma opção para gerar o boletim do aluno, deve ser apresentada
ao solicitante uma tabela com todas as disciplinas que o aluno cursou, bem como
as notas das provas e o número total de faltas em cada disciplina.

9. O sistema deve responder à solicitação de geração do boletim de um aluno

em no máximo 10 segundos.

10. O sistema deve calcular a média aritmética das duas maiores dentre três notas
de cada disciplina no final do semestre.

11. Quando o sistema constatar que o aluno tem mais que 25% de faltas em uma
disciplina do semestre, deve ser exibida no boletim do aluno a informação
16712855225

"Reprovado".

12. O sistema deverá suportar a execução em qualquer plataforma de hardware

e/ou sistema operacional.

13. O sistema deve enviar automaticamente para o e-mail dos gestores

autorizados um relatório com o número de alunos inadimplentes por curso.

14. O sistema não deve revelar quaisquer dados pessoais dos alunos aos
professores, exceto informações sobre notas e faltas no curso em que o
professor leciona.

Prof. Diego Carvalho [Link] Pág. 95 de 106

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 04

15. O sistema deve permitir que o professor inclua ou modifique as notas de seus
alunos durante o semestre letivo.

16. A quantidade de memória necessária para que um terminal possa executar o

sistema nas condições mínimas aceitáveis é de 1 gigabyte.

17. A taxa aceitável de falhas nas operações realizadas pelo usuário no sistema
deve ser de 1 falha para cada 200 operações.

18. O sistema e sua respectiva documentação deverão ser entregues em um ano

a partir da data atual.

19. O sistema não deve permitir operações que beneficiem alguns usuários em
detrimento de outros.

20. A interface do usuário deve ser construída utilizando HTML5 e CSS.

21. Se a média do aluno por disciplina, calculada no final do semestre, for menor
do que 7, deve ser exibido no boletim do aluno a informação "Reprovado".

Baseado nos requisitos apresentados, é correto afirmar que são requisitos

funcionais os de números:

f) 1, 2, 6, 10, 11, 14, 15, 16 e 21.

g) 1, 6, 8, 10, 11, 13, 14, 17, 18 e 19.
h) 1, 6, 7, 8, 10, 11, 13, 15 e 21.
i) 1, 3, 4, 8, 10, 11, 12, 13, 15, 18 e 21.
j) 2, 3, 4, 5, 9, 12, 14, 16, 17, 18, 19 e 20.
16712855225

11. (FCC - 2013 – MPE/MA – Analista de Sistemas) O escopo de um projeto é

determinado pelo levantamento de requisitos funcionais e não funcionais. Dentre
os requisitos não funcionais se enquadram os requisitos organizacionais, que
podem ser divididos em:

a) reguladores e éticos.
b) ambientais, operacionais e de desenvolvimento.
c) contábeis e de segurança.
d) de desempenho e de espaço.
e) de eficiência, de confiança e de proteção.

Prof. Diego Carvalho [Link] Pág. 96 de 106

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 04

12. (FCC - 2012 - MPE-PE - Analista Ministerial - Informática) Os requisitos não

funcionais não estão diretamente ligados aos serviços específicos oferecidos pelo
sistema a seus usuários. Eles podem estar relacionados às propriedades
emergentes do sistema, como confiabilidade, tempo de resposta e ocupação de
área, entre outros. Dentre os tipos de requisitos não funcionais, é possível
destacar os requisitos de produto, organizacionais e externos. Dentre os
requisitos de produto, podemos citar os requisitos:

a) de eficiência e de confiança.
b) contábeis e de desempenho.
c) legais e de usabilidade.
d) reguladores e de proteção.
e) legais e contábeis.

13. (FCC - 2012 - TRE- - Analista Judiciário - Análise de Sistemas) Considere:

I. Para cada cliente deve ser aplicado um identificador único.

II. O tempo de resposta entre a requisição e a informação não pode exceder a 2

ms.

III. Clientes têm filiais que devem "carregar", na base de dados, o identificador
do cliente principal.

IV. O sistema não deve ferir as leis de proteção ambiental.

São requisitos não funcionais os que constam em

16712855225

a) I e II, apenas.
b) II e III, apenas.
c) II e IV, apenas.
d) I, III e IV, apenas.
e) I, II, III e IV.

14. (FCC - 2012 - TST - Analista Judiciário - Análise de Sistemas) Na Engenharia de

Requisitos, o gerente de requisitos:

Prof. Diego Carvalho [Link] Pág. 97 de 106

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 04

a) acompanha e monitora ações durante a verificação do software, sendo este o

processo que garante o atendimento aos requisitos informados pelo usuário
final.

b) possui autonomia para realizar alterações no projeto para garantir que o

software seja bem construído e atenda às necessidades da equipe de
desenvolvimento.

c) mantém atualizados os requisitos junto ao usuário final e a equipe de

desenvolvimento, a fim de obter sucesso no processo de homologação do
software, atendendo as necessidades e expectativas.

d) classifica os requisitos em diferentes tipos, sendo os do tipo funcional

relacionados com o custo e confiabilidade do software e os do tipo não-funcional
relacionados com os casos de uso.

e) obtém o comprometimento dos integrantes da equipe de desenvolvimento

de software para o cumprimento do processo de software.

15. (FCC - 2012 - -PE - Analista Judiciário - Análise de Sistemas) Na engenharia de

requisitos trata-se de uma técnica de elicitação que ocorre em ambiente mais
informal em que toda a idéia deve ser levada em consideração para a solução
de um problema, sendo proibida a crítica a qualquer sugestão dada, e
encorajada, inclusive, a criação de ideias que pareçam estranhas ou exóticas:

a) Prototipação.
b) Entrevista.
c) Questionário.
d) Brainstorming. 16712855225

e) Análise de protocolos.

16. (FCC - 2011 - TRT - 19ª Região (AL) - Analista Judiciário - Tecnologia da
Informação) De acordo com Sommerville, são atividades do processo de
elicitação de requisitos, pela ordem:

a) casos de uso; análise; projeto; arquitetura.

b) etnografia; casos de uso; análise; validação; arquitetura.
c) entrevista; etnografia; documentação; registro.
d) cenários; classificação; organização; priorização; documentação.

Prof. Diego Carvalho [Link] Pág. 98 de 106

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 04

e) obtenção; classificação e organização; priorização e negociação;

documentação.

17. (FCC - 2011 - INFRAERO - Analista de Sistemas - Desenvolvimento e

Manutenção) A engenharia de requisitos ajuda os engenheiros de software a
compreender melhor o problema que eles vão trabalhar para resolver. Ela inclui
um conjunto de tarefas que levam a um entendimento de qual será o impacto
do software sobre o negócio, do que o cliente quer e de como os usuários finais
vão interagir com o software. A função de negociação no processo de
engenharia de requisitos:

a) especifica, revisa e valida o problema de modo a garantir que seu

entendimento e o entendimento do cliente sobre o problema coincidam.

b) refina e modifica os requisitos. É uma ação de modelagem de análise

composta de várias tarefas de modelagem e refinamento.

c) define quais são as prioridades, o que é essencial, o que é necessário. Clientes,

usuários e outros interessados são solicitados a ordenar os requisitos e depois
discutir os conflitos de prioridade.

d) ajuda o cliente a definir o que é necessário.

e) define o escopo e a natureza do problema a ser resolvido.

18. (FCC - 2011 - TRT - 1ª REGIÃO (RJ) - Analista Judiciário - Tecnologia da

Informação A técnica utilizada na compreensão de requisitos sociais e
organizacionais por observação das rotinas dos envolvidos é a:
16712855225

a) prototipação.
b) por pontos de vista.
c) por cenário.
d) entrevista.
e) etnografia.

19. (FCC - - TRT - 7ª Região (CE) - Analista Judiciário - Tecnologia da

Informação) No processo de engenharia de requisitos, é uma técnica de
observação que pode ser usada para compreender os requisitos sociais e
organizacionais.

Prof. Diego Carvalho [Link] Pág. 99 de 106

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 04

Trata-se de

a) Workshop.
b) Brainstorming.
c) Scrum.
d) Análise de ponto de vista.
e) Etnografia.

(FCC - 2010 - MPE-RN - Analista de Tecnologia da Informação - Engenharia de

Software) Na engenharia de software, etnografia é:

a) uma fase do processo de software aplicada no modelo em cascata.

b) uma fase do processo de software aplicada no modelo em espiral.

c) uma técnica de observação que pode ser usada para compreender os

requisitos sociais e organizacionais.

d) uma técnica aplicada na engenharia de requisitos cujo objetivo é definir, a

priori, as classes que contém elementos gráficos (BLOB).

e) um projeto cujo principal objetivo é criar interfaces gráficas, que facilitam o

acesso do usuário (GUI).

21. (FCC - - TRT - 3ª Região (MG) - Analista Judiciário - Tecnologia da

Informação) São técnicas e abordagens utilizadas na obtenção dos requisitos:

a) estresse, cenários e workshop.

b) workshop, etnografia e estresse. 16712855225

c) etnografia, questionários e validação.

d) pontos de vista, cenários e entrevista.
e) pontos de vista, casos de uso e validação.

(FCC - 2011 - INFRAERO - Analista de Sistemas - Desenvolvimento e

Manutenção) Os produtos de trabalho resultantes da engenharia de requisitos
são avaliados quanto à qualidade durante a etapa de validação de requisitos.
Analise os itens a seguir referentes a essa etapa:

I. Um dos principais mecanismos de validação de requisitos é a avaliação técnica

formal.

Prof. Diego Carvalho [Link] Pág. 100 de 106

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 04

II. O modelo de análise pode garantir que os requisitos foram consistentemente

declarados.

III. É frequentemente útil examinar cada requisito em face de um conjunto de

questões do tipo checklist.

IV. A equipe de revisão que avalia os requisitos inclui apenas pessoas com
conhecimento técnico na área de TI, como engenheiros de softwares,
desenvolvedores etc.

Está correto o que consta em:

a) I, II, III e IV.

b) II e IV, apenas.
c) I, II e IV, apenas.
d) II, III e IV, apenas.
e) I, II e III, apenas.

(FCC - 2013 – DPE/SP – Analista de Sistemas) Em uma das etapas da Engenharia

de Requisitos há a preocupação em se observar a especificação produzida,
visando verificar que os requisitos tenham sido declarados, por exemplo, sem
ambiguidades.

O texto refere-se à etapa de:

a) gestão dos requisitos.

b) elicitação dos requisitos.
c) negociação dos requisitos. 16712855225

d) levantamento dos requisitos.

e) validação dos requisitos.

24. (FC - 2011 - TRT - 19ª Região (AL) - Analista Judiciário - Tecnologia da
Informação) A avaliação do impacto de mudança de um requisito, muitas vezes,
faz com que seja necessário retornar à sua fonte. Na validação dos requisitos, a
equipe deve estar atenta, portanto, à:

a) rastreabilidade.
b) adaptabilidade.
c) qualidade.

Prof. Diego Carvalho [Link] Pág. 101 de 106

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 04

d) facilidade de compreensão.
e) facilidade de verificação.

(FCC - - PGE- - Técnico Superior de Análise de Sistemas e Métodos) No

âmbito da Engenharia de Requisitos, uma revisão técnica formal é:

a) um teste de desempenho.
b) uma técnica de elicitação.
c) um instrumento de rastreamento.
d) o resultado do escopo.
e) um mecanismo de validação.

(FCC - 2011 - TRT - 23ª REGIÃO (MT) - Analista Judiciário - Tecnologia da

Informação) Tabelas de rastreamento para relacionar os requisitos identificados
a um ou mais aspectos do sistema ou do seu ambiente devem ser desenvolvidas,
segundo Pressman, na engenharia de requisitos por meio da função de:

a) gestão.
b) especificação.
c) elaboração.
d) negociação.
e) validação.

27. (FCC - 2010 - MPE-RN - Analista de Tecnologia da Informação - Engenharia de

Software) As políticas de rastreabilidade de requisitos são decididas durante o
estágio de:

a) agregação dos requisitos funcionais, apenas.

b) implementação do sistema, apenas.
16712855225

c) implementação do sistema
d) eliminação dos requisitos não funcionais.
e) gerenciamento de requisitos.

Prof. Diego Carvalho [Link] Pág. 102 de 106

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 04

LISTA DE EXERCÍCIOS COMENTADOS (FGV)

ENGENHARIA DE REQUISITOS
FGV - 2010 - BADESC - Analista de Sistemas - Desenvolvimento de Sistemas)
Analise o fragmento a seguir:

"A base de dados deve ser protegida para acesso apenas de usuários
autorizados".

O fragmento acima apresenta um exemplo do seguinte requisito:

a) funcional.
b) de usuário.
c) de sistema.
d) de domínio.
e) não-funcional.

(FGV - - MEC - Analista de Sistemas - Especialista) Requisitos não-

funcionais estão diretamente relacionados com a satisfação dos usuários.
Assinale a alternativa que não indique um requisito não-funcional:

a) O sistema de arquivos deve ser protegido, para acesso, apenas, de usuários

autorizados.

b) O software deve ser implementado usando os conceitos de orientação a

objetos.

c) O tempo de desenvolvimento do software não deve ultrapassar seis meses.

16712855225

d) O software poderá ser executado em plataforma windows e linux.

e) O software deve emitir relatórios de vendas a cada quinze dias.

(FGV - 2009 - MEC - Analista de Sistemas - Especialista) As declarações de

serviços que o sistema deve fornecer, de como ele deve reagir a entradas
específicas ou se comportar em determinadas situações, são chamadas de
requisitos:

Prof. Diego Carvalho [Link] Pág. 103 de 106

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 04

a) não-funcionais.
b) de domínio.
c) de sistema.
d) funcionais.
e) de usuário.

(FGV - 2008 - Senado Federal - Analista de Sistemas) Entre as atividades listadas

a seguir, uma não faz parte da Engenharia de Requisitos. Assinale-a.

a) estudo de viabilidade.
b) análise de risco.
c) levantamento de necessidades do cliente.
d) verificação.
e) gerenciamento.

(FGV - - MEC - Analista de Sistemas - Especialista) Existem técnicas que são

usadas na fase de levantamento de requisitos para coletar conhecimento dos
usuários sobre os requisitos. Assinale a alternativa que indique apenas técnicas
utilizadas na fase de levantamento de requisitos.

a) JAD, WFMS, WBS, cenários e brainstorming.

b) JAD, cenários, WFMS, questionários e intercepting.
c) cenários, entrevistas, protótipos, workshop, brainstorming.
d) leitura de documentos, protótipos, workshop, WBS e workflow.
e) brainstorming, protótipos, workflow, leitura de documentos e intercepting.

(FGV - 2010 - FIOCRUZ - Tecnologista em Saúde - TI - Sistemas de Informação)

Sobre os processos de engenharia de requisitos, na elicitação e na análise ocorre
total interação com os stakeholders no sistema, sendo o principal objetivo:
16712855225

a) a obtenção dos requisitos.

b) a homologação do sistema.
c) a elaboração do manual do usuário.
d) a conversão de especificações em requisitos.
e) a execução do estudo de viabilidade do sistema.

Prof. Diego Carvalho [Link] Pág. 104 de 106

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 04

GABARITO DOS EXERCÍCIOS COMENTADOS (CESPE)

ENGENHARIA DE REQUISITOS

1 2 3 4 5 6 7 8 9 10
C E E E C C C C C E
11 12 13 14 15 16 17 18 19 20
E E E E E E E C C C
21 22 23 24 25 26 27 28 29 30
E C C C E C C E C C
31 32 33 34 35 36 37 38 39 40
C C C E E E C C C C
41 42 43 44 45 46 47 48 49 50
C C C E C E C C

GABARITO DOS EXERCÍCIOS COMENTADOS (ESAF)

ENGENHARIA DE REQUISITOS

1 2 3 4 5 6 7 8 9 10
C E C B B

GABARITO DOS EXERCÍCIOS COMENTADOS (FCC)

ENGENHARIA DE REQUISITOS
16712855225

1 2 3 4 5 6 7 8 9 10
C A C A D A C E A C
11 12 13 14 15 16 17 18 19 20
B A C C D E C E E C
21 22 23 24 25 26 27 28 29 30
D E E A E A E

GABARITO DOS EXERCÍCIOS COMENTADOS (FGV)

ENGENHARIA DE REQUISITOS

Prof. Diego Carvalho [Link] Pág. 105 de 106

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 04

1 2 3 4 5 6 7 8 9 10
E E D B C A

16712855225

Prof. Diego Carvalho [Link] Pág. 106 de 106