Slides de Aula III

Prévia do material em texto

Prof. Me. Edson Moreno
UNIDADE III
Fundamentos de 
Engenharia de Software
 Na Unidade II foram apresentados vários modelos de processos de software, que em boa 
parte precisam de muita documentação e burocracia, acarretando demora e alto custo. 
 Em contraponto são apresentadas na Unidade III as principais metodologias ágeis de 
desenvolvimento do software: XP, SCRUM, FDD, DSDM, Crystal e AM.
 Na Unidade III também serão abordadas as melhores práticas da engenharia de requisitos, 
que permitem a concepção do projeto de software. 
 Serão abordados os principais requisitos do software a serem registrados, bem como a 
atividade da análise e a modelagem do projeto e do produto software. 
 Nesse contexto, a Unidade III, da disciplina Fundamentos de 
Engenharia de Software, trata das metodologias ágeis e 
engenharia de requisitos.
Introdução
 Com emprego de técnicas consideradas eficientes no desenvolvimento do software, elas 
passaram a se chamar de metodologias ágeis. 
Nesse capítulo serão abordados os seguintes itens:
 Manifesto para desenvolvimento ágil de software.
 Metodologias ágeis: XP, SCRUM, FDD, DSDM, Crystal e AM.
5 Metodologias ágeis
Fonte: ALMEIDA, Ricardo. IBM adotando Metodologia Ágil?. 
Disponível em:
https://manifestonaweb.wordpress.com/2008/06/20/metodol
ogia-agil-na-ibm/, 20/06/2008. Acesso em: 21 dez. 2020.
A IBM, fornecedora do RUP e 
concorrente, reconhece a 
importância das metodologias ágeis.
 Por meio do Manifesto for Agile Software Development (Manifesto para Desenvolvimento Ágil 
de Software), publicado nos dias 11 a 13 de fevereiro de 2001, Kent Beck e mais dezesseis 
notáveis desenvolvedores se reuniram para defender as seguintes regras:
Manifesto para desenvolvimento ágil de software I
Manifesto para Desenvolvimento Ágil de Software
“Estamos descobrindo maneiras melhores de desenvolver 
software, fazendo-o nós mesmos e ajudando outros a fazerem 
o mesmo. Por meio desse trabalho, passamos a valorizar:
Indivíduos e interações mais que processos e ferramentas.
Software em funcionamento mais do que 
documentação abrangente.
Colaboração com o cliente mais do que 
negociação de contratos.
Responder a mudanças mais que seguir um plano.”
Fonte: BECK, Kent, et al. Manifesto para 
Desenvolvimento Ágil de Software, 2001. 
Disponível em: 
https://agilemanifesto.org/iso/ptbr/manifes
to.html, 2001. Acesso em: 30 jun. 2020.
 A frase que finaliza esse manifesto é: “Mesmo havendo valor nos itens à direita, valorizamos 
mais os itens à esquerda” (BECK, 2001). Pode ser explicada com base na figura abaixo.
 Enquanto o RUP (lado direito da figura) é extremamente rígido com altos níveis de controle e 
forte documentação, as metodologias ágeis (no centro e lado esquerdo da figura) caminham 
ao contrário e, mesmo assim, as metodologias ágeis não infringem uma sólida prática da 
Engenharia de Software.
Manifesto para desenvolvimento ágil de software II
Fonte: Moreno (2020).
Manifesto para desenvolvimento ágil de software – princípios 
Princípios Descrição
Envolvimento do cliente O cliente fornece e prioriza novos requisitos.
Entrega incremental Os requisitos são incluídos em incrementos sucessivos.
Pessoas, não processos Habilidades e comunicação informal são exploradas. 
Aceitar as mudanças Os requisitos sempre mudam.
Manter a simplicidade Sem complexidade no processo de software.
Fonte: Sommerville (2011).
 A Extreme Programing (Programação Extrema) emprega uma abordagem orientada a 
objetos como paradigma preferido e envolve um conjunto de regras e práticas constantes no 
contexto de quatro atividades metodológicas: planejamento, projeto, codificação e testes 
(PRESSMAN, 2011).
Metodologia ágil Extreme Programming (XP) 
Fonte: Pressman (2011).
Fonte: JOURNEY. Metodologia XP (Extreme 
Programming) – Desenvolvimento Ágil. Disponível em: 
https://acordocoletivo.org/2018/01/01/metodologia-xp-
extreme-programming-desenvolvimento-agil/, 
01/01/2018. Acesso em: 30 jun. 2020.
Valores das histórias
de usuários, critérios
de teste de aceitação e
plano de iteração
Projeto simples
cartões CRC
Soluções pontuais
protótipos
Fabricação
Teste de unidades
integração contínua
Teste de aceitação
Versão
Programação em dupla
Incremento de software
velocidade de projeto registrado
(computada)
Metodologia ágil Extreme Programming (XP) – distribuição de tarefas 
Fonte: Moreno (2020).
 O modelo ágil mais 
conhecido é o XP.
 Grande ênfase na 
programação em duplas.
 Figura: porcentagem 
estimada de distribuição 
de tarefas na metodologia 
ágil XP.
 Planejamento (12,5%)
Usuários são 
selecionados
 Projeto (12,5%)
Documentação
Responsabilidades
Detalhes das tarefas
Plano de detalhes do 
projeto
 Codificação (50,0%)
Implementação, teste, 
integração e qualidade
 Teste (25,0%)
Qualidade, bugs e 
depuração
Projeto
12,5%
Codificação
50,0%
Planejamento
12,5%
Teste
25,0%
O Manifesto for Agile Software Development (Manifesto para Desenvolvimento Ágil de 
Software) foi criado, em 2001, por Kent Beck e mais dezesseis notáveis desenvolvedores que 
se reuniram para defender algumas regras. Assinale a alternativa considerada uma regra no 
desenvolvimento ágil de software:
a) Acompanha o modelo de processo balbúrdia.
b) Não possui documentação, mas tem uma comunicação eficaz.
c) Os métodos são específicos para o uso da UML.
d) Propõe sistemas somente se estiver integrado e adaptado a outros sistemas ágeis.
e) Software em funcionamento mais do que documentação abrangente.
Interatividade
O Manifesto for Agile Software Development (Manifesto para Desenvolvimento Ágil de 
Software) foi criado, em 2001, por Kent Beck e mais dezesseis notáveis desenvolvedores que 
se reuniram para defender algumas regras. Assinale a alternativa considerada uma regra no 
desenvolvimento ágil de software:
a) Acompanha o modelo de processo balbúrdia.
b) Não possui documentação, mas tem uma comunicação eficaz.
c) Os métodos são específicos para o uso da UML.
d) Propõe sistemas somente se estiver integrado e adaptado a outros sistemas ágeis.
e) Software em funcionamento mais do que documentação abrangente.
Resposta
BECK, Kent, et al. Manifesto para 
Desenvolvimento Ágil de Software, 2001. 
Disponível em: 
https://agilemanifesto.org/iso/ptbr/manifest
o.html, 2001. Acesso em: 30 jun. 2020.
Conheça as 
regras do 
Manifesto Ágil.
 O nome SCRUM vem da atividade de jogadores de rugby, no trabalho de deslocar a bola 
estando “fortemente” juntos. 
 Com base nesse contexto, Jeff Sutherland, na década de 1990, desenvolveu o método ágil 
SCRUM, que segue os mesmos princípios básicos do Manifesto Ágil. 
Metodologia ágil SCRUM
A metodologia é baseada em princípios semelhantes 
aos do XP
 Equipes pequenas.
 Requisitos pouco estáveis ou desconhecidos.
 Iterações curtas para promover visibilidade para o 
desenvolvimento.
Metodologia ágil SCRUM – sprint
Características do SCRUM
O SCRUM promove reuniões diárias de 15 minutos em que 
todos respondem às questões:
 O que você realizou desde o último SCRUM? 
 Você está tendo alguma dificuldade? 
 O que você irá fazer até a próxima reunião? 
Benefícios: 
 Maior integração entre os membros da equipe. 
 Rápida solução de problemas.
Promove o compartilhamento de conhecimento: 
 Progresso medido continuamente. 
 Minimização de riscos. 
Metodologia ágil SCRUM – fases
Fonte: Moreno (2020); Pressman (2011).
 Backlog – registro 
pendente de trabalhos.
 Sprints – unidades de 
trabalho para atingir os 
requisitos.
 Reuniões SCRUM –
diárias de 15 minutos.
 Demos – entrega de 
funcionalidades.
Metodologia ágil Feature Driven Development (FDD)
Fonte: Deluca (2008).
Conceito do termo “característica”
usado no FDD
A “característica” é uma função 
relativamente pequena alinhada com o 
cliente: 
 As “características” podem ser 
pequenos blocos de funções ou uma 
funcionalidade. Esse recurso permiteum melhor controle e entendimento 
do processo. 
 As “características” são organizadas 
com base na hierarquia ou prioridades 
relacionadas ao negócio. 
 A equipe estabelece metas para o 
desenvolvimento de novas 
“características”. 
FDD é a 
metodologia ágil 
que mais enfatiza a 
gestão de projetos.
Mais forma que conteúdo
Modelo de objetos
Mais conteúdo na forma
Plano de
Desenvolvimento
Progresso
Desenvolver
um Modelo
Abrangente
Construir
a Lista de
Features
Planejar
por
Feature
Construir
por
Feature
Detalhar
por
Feature
Pacotes de trabalho
Metodologia ágil Dynamic Systems Development Method (DSDM)
Fonte: Moreno (2020).
O Método Dinâmico de Desenvolvimento de Sistemas 
(DSDM) surge como uma extensão do modelo RAD. 
O DSDM possui nove princípios 
fundamentais
1. Envolvimento ativo do usuário.
2. Equipes capacitadas (com poderes).
3. Entrega frequente.
4. Aptidão para negócios.
5. Desenvolvimento incremental.
6. Alterações reversíveis.
7. Linha de base para os requisitos.
8. Teste integrado.
9. Colaboração das partes interessadas.
Os focos do DSDM
são a especificação 
do sistema e a 
integração de seus 
componentes e 
testes.
Viabilidade
Estudos de revisão
Modelo funcional
de iteração
Implementação
Projeto e
construção da 
iteração
 Crystal/Clear faz parte de um conjunto completo de metodologias criadas com intuito de fazer 
uma analogia com os cristais geológicos, apresentados na natureza com sua própria cor, 
forma e dureza.
Premissas apresentadas para a existência do conjunto de metodologias: 
 Todo projeto tem necessidades e metodologias diferentes. 
 O funcionamento do projeto é influenciado por fatores humanos, 
e há melhora nele quando os indivíduos produzem melhor. 
 Comunicação melhor e lançamentos frequentes reduzem a 
necessidade de construir produtos intermediários do processo. 
Metodologia ágil Crystal
Fonte: Coimbra (2020).
Manobrabilidade –
termo usado no 
Crystal para 
escolha de 
metodologias.
Trabalho em
equipe
Comunicação Simplicidade Reflexão Ajustes
frequentes
Melhorar
processos
 A Modelagem Ágil (AM) é uma metodologia baseada na prática para modelagem e 
documentação efetiva de sistemas baseados em software. 
 A Modelagem Ágil dispõe de múltiplos modelos para descrever software, é uma coleção de 
valores, princípios e práticas de modelagem de software aplicados a um projeto de modo 
efetivo e leve.
Metodologia ágil AM (Agile Modeling)
AM. Agile Modeling. Modelagem Ágil (AM).
Disponível em: http://agilemodeling.com. Acesso em: 30 jun. 2020.
A expressão “viajar leve” é muito 
usada na Modelagem Ágil. Orienta 
que conserve apenas os modelos 
que fornecerão valor a longo prazo 
e demais modelos devem ser 
descartados.
Conheça os 
modelos da 
metodologia AM.
Um analista de sistemas na atividade da engenharia de software precisa incluir em seu projeto 
equipes especializadas no desenvolvimento ágil do software, que apresentem os perfis:
1. Entender o projeto e determinar as atividades do desenvolvimento.
2. Fazer levantamento de escopo e normatizar reuniões.
3. Para a codificação e testes de artefatos do software, selecionar pequenas equipes com 
duas pessoas.
Assinale abaixo, respectivamente, os métodos ágeis correspondentes às principais áreas ou 
atividades de desenvolvimento listadas acima:
a) FDD; 2. SCRUM; 3. XP.
b) FDD; 2. XP; 3. SCRUM.
c) SCRUM; 2. FDD; 3. XP.
d) SCRUM; 2. XP; 3. FDD.
e) XP; 2. FDD; 3. SCRUM.
Interatividade
Um analista de sistemas na atividade da engenharia de software precisa incluir em seu projeto 
equipes especializadas no desenvolvimento ágil do software, que apresentem os perfis:
1. Entender o projeto e determinar as atividades do desenvolvimento.
2. Fazer levantamento de escopo e normatizar reuniões.
3. Para a codificação e testes de artefatos do software, selecionar pequenas equipes com 
duas pessoas.
Assinale abaixo, respectivamente, os métodos ágeis correspondentes às principais áreas ou 
atividades de desenvolvimento listadas acima:
a) FDD; 2. SCRUM; 3. XP.
b) FDD; 2. XP; 3. SCRUM.
c) SCRUM; 2. FDD; 3. XP.
d) SCRUM; 2. XP; 3. FDD.
e) XP; 2. FDD; 3. SCRUM.
Resposta
 A concepção para o projeto de software constitui os procedimentos para criar o documento 
de requisitos do software.
 Nesse documento se definem: requisitos do usuário, requisitos do sistema, requisitos 
funcionais e não funcionais. 
 A engenharia de requisitos contempla as principais atividades e práticas no estudo de 
viabilidade do sistema, elicitação, análise, especificação, modelagem e validação para o 
processo, o projeto e o produto software.
6 Engenharia de requisitos
Nesse capítulo serão abordados os seguintes itens:
 Processo da engenharia de requisitos do software.
 Elicitação e análise de requisitos.
 Especificação, documentação e modelagem dos requisitos.
O software começa aqui.
 A Engenharia de Requisitos do Software é um processo que envolve todas as atividades 
exigidas para criar e manter o documento de requisitos do software/sistema 
(SOMMERVILLE, 2003). 
Uso desse documento:
 Contratos e licitações para o desenvolvimento de software.
 Escolha de fornecedores de componentes do sistema.
 Acompanhamento de mudanças.
 Especificação do software.
Processo de engenharia de requisitos do software
Atividades do processo da engenharia 
de requisitos do software/sistema
 Estudo da viabilidade do sistema;
 Elicitação;
 Análise;
 Especificação;
 Modelagem; 
 Validação.
 A figura mostra o fluxo do processo da engenharia de requisitos do software/sistema.
 O desenvolvimento do sistema só ocorre após a validação dos requisitos. 
 Caso os requisitos não sejam validados ocorre uma iteração, o que significa que todo o 
processo será revisto, incluindo as abordagens para levantamento dos requisitos.
Processo de engenharia de requisitos – modelo do processo
Fonte: Moreno (2020).
Elicitação e Análise
de requisitos
Estudo da Viabilidade
do sistema
Validação
Especificação,
Modelagem e
Documentação
Início
Nova Iteração
Desenvolvimento 
do Sistema
O estudo de viabilidade é breve e é direcionado a responder algumas perguntas:
1. O sistema proposto contribui para os objetivos gerais da organização?
2. São consideradas se as regras de negócio estão de acordo com a organização?
3. O sistema pode ser implementado com tecnologia atual dentro do custo e prazo?
4. O que o cliente quer está dentro do orçamento e do prazo para entrega do sistema? 
5. O sistema pode ser integrado com os outros sistemas já em operação? Qual o impacto das 
mudanças no ambiente operacional do cliente?
6. A tecnologia a ser implementada é adaptável ao sistema do cliente (se esse existir)? 
Estudo da viabilidade do sistema 
 Elicitação dos requisitos é a tarefa de se comunicar com os usuários e os clientes para 
determinar quais são os requisitos.
Técnicas de elicitação:
 Organizar reuniões, entrevistas com objetivo de criar a lista de requisitos. 
 Prototipação e casos de uso. 
Métodos:
 Questionários dirigidos;
 Perguntas abertas e Brainstorming;
 Grupos de desenvolvimento de sistemas do tipo JAD. 
Elicitação e análise de requisitos – elicitação
IEEE. Enhanced Facilitated Application Specification Techniques 
(eFAST). Institute of Eletrical and Eletronics Engineers (IEEE). 
Disponível em: https://ieeexplore.ieee.org/document/1651985. 
Conheça a 
técnica de 
elicitação e Fast.
 Processo de levantamento 
e análise de requisitos.
Elicitação e análise de requisitos – levantamento e análise de requisitos
Fonte: Sommerville (2003).
Entrada
do processo
Verificação
de requisitos
Compreensão
do domínio
Coleta de
requisitos
Classificação
Resolução
de conflitos
Definição
das prioridades
Documento
de requisitos
Especificação
de requisitos
 A especificação e a modelagem são os produtos do trabalho final produzidos pelo 
engenheiro de requisitos. 
 Na especificaçãosão descritas a função e o desempenho do sistema e as restrições que 
acompanharam seu desenvolvimento. 
 A especificação pode ser um documento escrito, um modelo gráfico, um modelo matemático 
formal, casos de uso, protótipos ou qualquer combinação desses elementos.
Acesse BAHN e saiba como especificar o software dentro das normas:
Especificação, documentação e modelagem dos requisitos 
BAHN, Christy. 830-1998. Prática recomendada do IEEE para especificações de requisitos de software. Comitê de 
Normas de Engenharia de Software e Sistemas, 20/10/1998, reafirmado em 09/12/2009. 
Disponível em: https://standards.ieee.org/standard/830-1998.html. Acesso em: 29 jun. 2020.
Principais grupos de requisitos
 Requisitos do Usuário;
 Requisitos do Sistema;
 Requisitos Funcionais; 
 Requisitos Não Funcionais.
 A Especificação de Requisitos de Software (SRS – Software Requirements Specification) 
captura todos os requisitos de software para o sistema ou para uma parte do sistema.
 A especificação é a declaração 
oficial do que é exigido dos 
desenvolvedores de sistema.
Especificação, documentação e modelagem dos requisitos – documento
Modelo de especificação de requisitos
Sumário
Histórico de revisão
1. Introdução
2. Descrição geral
3. Características do sistema
4. Requisitos de interfaces externas
5. Requisitos não funcionais
6. Outros requisitos
Referências
Apêndice A: Glossário
Apêndice B: Modelos de análise
Apêndice C: Lista de problemas
São várias as atividades da engenharia de software, contudo algumas delas são específicas da 
engenharia de requisitos. Avalie as atividades abaixo e assinale a alternativa correspondente 
às atividades específicas da engenharia de requisitos do software:
Alternativas:
a) (I), (III), (VI), (VII), (VIII).
b) (II), (III), (IV), (V), (VI).
c) (II), (III), (V), (VII), (XI).
d) (III), (IV), (VI), (IX), (X).
e) (IV), (VI), (IX), (X), (XI).
Interatividade
I – Análise do negócio V – Especificação IX – Suporte técnico
II – Elicitação VI – Projeto X – Treinamento
III – Análise do sistema VII – Modelagem XI – Validação
IV – Prototipação VIII – Manutenção
São várias as atividades da engenharia de software, contudo algumas delas são específicas da 
engenharia de requisitos. Avalie as atividades abaixo e assinale a alternativa correspondente 
às atividades específicas da engenharia de requisitos do software:
Alternativas:
a) (I), (III), (VI), (VII), (VIII).
b) (II), (III), (IV), (V), (VI).
c) (II), (III), (V), (VII), (XI).
d) (III), (IV), (VI), (IX), (X).
e) (IV), (VI), (IX), (X), (XI).
Resposta
I – Análise do negócio V – Especificação IX – Suporte técnico
II – Elicitação VI – Projeto X – Treinamento
III – Análise do sistema VII – Modelagem XI – Validação
IV – Prototipação VIII – Manutenção
 São declarações em linguagem natural, formulários e diagramas simples, sobre as funções 
que o sistema/software deve fornecer e as restrições sobre as quais deve operar.
 Os requisitos do usuário são descritos de forma compreensível para que o stakeholder tenha 
um bom entendimento do que se quer do sistema a ser construído. 
 A modelagem do negócio é aplicada nesse processo. É um modelo de fácil interpretação, 
que se utiliza normalmente um modelo construído com o diagrama de atividade da UML.
Requisitos do Usuário (RU)
OMG. Categoria de modelagem de 
negócios – especificações associadas. 
OMG – Object Management Group®. 
Disponível em: 
https://www.omg.org/spec/category/busine
ss-modeling/. Acesso em: 29 jun. 2020.
Modelagem do 
negócio. Veja 
como funciona.
 Requisitos funcionais são declarações detalhadas dos requisitos do usuário com uma 
especificação completa de toda a funcionalidade ou serviços que se espera que o 
sistema forneça. 
 A atividade de elaboração dos requisitos funcionais consiste em extrair dos casos de uso as 
funções necessárias que irão operar no sistema. 
 O objetivo é preparar um material detalhado para que possa ser passado para a codificação.
 A tabela mostra a 
especificação de requisitos.
Requisitos Funcionais (RF)
Requisito
Funcional (RF)
Especificação
RF01
Chamada de menu: relatórios – deverá exibir o menu 
de relatórios disponíveis.
RF01.1
Função: relatório de compras – relatório com as 
compras efetuadas no período desejado. Exibindo: 
fornecedor, produto comprado, quantidade e valor.
RF01.2
Função: relatório de pagamentos efetuados – relatório 
com os pagamentos efetuados a fornecedores no 
período desejado. Exibindo: fornecedor, produto 
comprado, quantidade e valor pago.
 Os requisitos não funcionais são 
requisitos que não estão diretamente 
relacionados com os serviços 
específicos oferecidos pelo 
sistema a seus usuários 
(SOMMERVILLE, 2003). 
 Os requisitos não funcionais 
determinam a qualidade do software.
Na figura são mostrados os tipos de 
requisitos não funcionais.
Requisitos Não Funcionais (RNF)
Fonte: Sommerville (2003).
Requisitos
do Produto
Requisitos
de Entrega
Requisitos de 
Usabilidade
Requisitos
de Eficiência
Requisitos
de Confiabilidade
Requisitos de 
Portabilidade
Requisitos de 
Desempenho
Requisitos de 
Espaço
Requisitos de 
Padrões
Requisitos de 
Implementação
Requisitos 
Organizacionais
Requisitos
Externos
Requisitos de
Interoperabilidade
Requisitos
Éticos
Requisitos
Legais
Requisitos de
Segurança
Requisitos de
Privacidade
 São descrições detalhadas dos requisitos do usuário com o foco no sistema, com uma 
especificação completa de todos os componentes do sistema. 
Os componentes podem ser divididos em dois grupos:
1. Visão estática da arquitetura – visão da organização e integração dos componentes do 
software com elementos de dados (banco de dados, arquivos-texto etc.), com o hardware e 
outros ambientes operacionais. 
2. Visão dinâmica da arquitetura – visão comportamental do sistema e de seus componentes. 
São definidos como os componentes reagem a eventos e a forma como se comunicam (ou 
trocam mensagens).
Requisitos do Sistema (RS) I
Tabela de requisitos do sistema:
Requisito
Sistema (RS)
Especificação
RS01 Computador cliente, modelo PC com médio desempenho.
RS02
Sistema operacional do computador cliente – Windows. 
Ver RS01
RS03
Navegador para internet. A aplicação irá funcionar em uma 
rede intranet.
Na elaboração do projeto, o projetista 
precisa praticar a diversificação e depois a 
convergência (PRESSMAN, 2007).
Requisitos do Sistema (RS) II
Fonte: Moreno (2020) (adaptado)
Fonte: Moreno (2020).
Diversificação
Convergência
Cliente – SO Windows
Cliente – Browser
Server – Gerenciador 
de telas
Server – Gerenciador 
de contas (Login)
Server – SOR 
Windows
Server – SOR 
Linux
Web Server –
Microsoft lls
Web Server –
Apache/Tomcat
Server – SGBD SQL
Microsoft
Server – SGBD MySQL
Server – App Controle 
de Estoque (JPS)
Cliente – PC
Computer
Nó1 – Server
Computer 1
Nó2 – Server
Computer 2
Cliente – PC Computer
Cliente – SO 
Windows
Cliente – Browser
<<HTML>>
Nó – Server Computer 1
Server – SOR 
Linux
Web – Server –
Microsoft lls
<<HTML>>
Server – Gerenciador de telas
<<HTML>>
Server – Gerenciador de contas
<<MySQL>>
Nó2 – Server Computer 2
Web – Server –
Apache/Tomcat
Server – SOR 
Windows
<<TCP/IP>>
<<HTTP>>
<<TCP/IP>>
<<DNS>>
<<JSP>>
<<JSP>>
Server – App-Controle de Estoque
<<MySQL>>
Server – SGBD MySQL
 A validação é a última fase do processo da engenharia de requisitos.
 É a tarefa de apresentar o documento de requisitos em reunião com a participação do grupo 
formado pelos interessados no sistema. 
 O objetivo é aprimorar, incluir mudanças propostas e aprovar o início do projeto e 
desenvolvimento do software/sistema. 
 O cliente valida os requisitos como compromisso das informações fornecidas e 
reconhecimento dos elementos que irão permitir a construção do sistema, bem como custos 
e prazos acordados com o desenvolvedor.
 Na validação, os desenvolvedores se comprometemem desenvolver o sistema com o custo 
e o prazo determinados.
Validação dos requisitos
Referente aos requisitos de software listados abaixo, responda à alternativa correspondente 
aos tipos desses requisitos:
I. São declarações em linguagem natural, formulários e diagramas simples, sobre as funções 
que o sistema deve fornecer e as restrições sobre as quais deve operar.
II. São declarações com uma especificação completa dos serviços que se espera que o 
sistema forneça.
Alternativas:
a) Domínio e usuário.
b) Funcionais e não funcionais.
c) Sistema e não funcionais.
d) Sistema e funcionais.
e) Usuário e funcionais.
Interatividade
Referente aos requisitos de software listados abaixo, responda à alternativa correspondente 
aos tipos desses requisitos:
I. São declarações em linguagem natural, formulários e diagramas simples, sobre as funções 
que o sistema deve fornecer e as restrições sobre as quais deve operar.
II. São declarações com uma especificação completa dos serviços que se espera que o 
sistema forneça.
Alternativas:
a) Domínio e usuário.
b) Funcionais e não funcionais.
c) Sistema e não funcionais.
d) Sistema e funcionais.
e) Usuário e funcionais.
Resposta
 BECK, Kent; et al. Manifesto para Desenvolvimento Ágil de Software, 2001. Disponível em: 
https://agilemanifesto.org/iso/ptbr/manifesto.html. Acesso em: 30 jun. 2020.
 COIMBRA. Agile Methods: DSDM. Disponível em: https://projetoseti.com.br/agile-methods-
dsdm. Acesso em: 30 jun. 2020.
 DELUCA, J. A importância da engenharia de software: FDD Feature-Driven Development. 
Disponível em: http://engenheirosdosoftware.blogspot.com/2008/10/fdd-feature-driven-
development.html. Acesso em: 30 jun. 2020.
 PRESSMAN, Roger S. Ph.D. Engenharia de Software: Uma Abordagem Profissional. 7. ed. 
Rio de Janeiro: McGraw-Hill, 2011.
 SOMMERVILLE, Ian. Engenharia de Software. 9. ed. São 
Paulo: Pearson Prentice Hall, 2011.
Referências
ATÉ A PRÓXIMA!