Livro-Texto - Unidade III (1)

Prévia do material em texto

80
Unidade III
Unidade III
5 METODOLOGIAS ÁGEIS
5.1 Manifesto para Desenvolvimento Ágil de Software
O Manifesto para Desenvolvimento Ágil de Software deu início a uma nova forma de desenvolvimento 
do software.
Tal Manifesto desconsidera elementos prescritivos de modelos de processos de desenvolvimento 
de software, que, muitas vezes, eram práticas exaustivas, de custo alto e que ocupavam muito tempo. 
Os modelos de processos de desenvolvimento de software considerados até então eram descartados 
quando se exigiam implementações rápidas para o software.
No entanto, vários profissionais da área já utilizavam outras técnicas de desenvolvimento consideradas 
tão eficientes quanto os modelos usados na época. Essas outras técnicas de desenvolvimento passaram 
a se chamar metodologias ágeis.
Por meio do Manifesto para Desenvolvimento Ágil de Software, publicado nos dias 11 a 13 de 
fevereiro de 2001 por Kent Beck e mais 16 notáveis desenvolvedores, são defendidas as seguintes regras:
 
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.
Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens 
à esquerda (BECK et al., 2001).
 
A frase “Mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda” (BECK et al., 
2001) pode ser explicada com base na figura 30. 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 do lado 
81
FUNDAMENTOS DE ENGENHARIA DE SOFTWARE
esquerdo) caminham ao contrário e, mesmo assim, as metodologias ágeis não infringem uma sólida 
prática da engenharia de software.
Destaque:
Liberdade
Tamanho da equipe de 
desenvolvedores:
Pequena (menor que 10)
Destaque:
Alto rigor
Tamanho da equipe de 
desenvolvedores:
Média (de 10 a 20)
Destaque:
Controle
Tamanho da equipe de 
desenvolvedores:
Grande (maior que 20)
XP FDD RUP
Figura 30 – Valores da metodologia ágil
 Saiba mais
Consulte a referência a seguir:
BECK, K. et al. Manifesto para Desenvolvimento Ágil de Software. 
Agilemanifesto.org, 2001. Disponível em: https://bit.ly/3cnXQWi. Acesso 
em: 3 mar. 2021.
 Observação
Métodos ágeis envolvem uma coleção de metodologias pautadas na 
prática para modelagem efetiva de sistemas baseados em software. É uma 
filosofia em que muitas metodologias se encaixam.
As metodologias ágeis aplicam uma coleção de práticas guiadas por princípios e valores que podem 
ser adotados por profissionais de software no dia a dia. Os princípios aplicados nas metodologias ágeis 
são mostrados no quadro a seguir.
 
Embora esses métodos ágeis sejam todos baseados na noção de 
desenvolvimento e entrega incremental, eles propõem diferentes processos 
para alcançar tal objetivo. No entanto, compartilham um conjunto de 
princípios, com base no manifesto ágil, e por isso têm muito em comum 
(SOMMERVILLE, 2011, p. 40).
82
Unidade III
Quadro 5 – Os princípios dos métodos ágeis
Princípios Descrição
Envolvimento do cliente
Os clientes devem estar intimamente envolvidos no processo de 
desenvolvimento. Seu papel é fornecer e priorizar novos requisitos do sistema e 
avaliar suas iterações
Entrega incremental O software é desenvolvido em incrementos com o cliente, especificando os requisitos para serem incluídos em cada um
Pessoas, não processos
As habilidades da equipe de desenvolvimento devem ser reconhecidas e 
exploradas. Membros da equipe devem desenvolver suas próprias maneiras de 
trabalhar, sem processos prescritivos
Aceitar as mudanças Deve-se ter em mente que os requisitos do sistema vão mudar. Por isso, projete o sistema de maneira a acomodar essas mudanças
Manter a simplicidade
Focalize a simplicidade, tanto do software a ser desenvolvido quanto do 
processo de desenvolvimento. Sempre que possível, trabalhe ativamente para 
eliminar a complexidade do sistema
Fonte: Sommerville (2011, p. 40).
5.2 Metodologias ágeis
5.2.1 Extreme Programming (XP)
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).
As quatro atividades-chaves da XP a serem desenvolvidas são mostradas no ciclo de desenvolvimento 
do processo XP:
Valores das histórias de usuários
Critérios de teste de aceitação
Plano de iteração
Teste de unidades
Integração contínua
Teste de aceitação
Versão
Programação em dupla
Projetos simples
Cartões CRC
Soluções pontuais
Protótipos
Refabricação
Planejam
ento
Projeto
Teste
Codificaç
ão
Incremento de software
 Velocidade de projeto registrado 
(computada)
Figura 31 – O processo da XP
83
FUNDAMENTOS DE ENGENHARIA DE SOFTWARE
 Saiba mais
Consulte a referência a seguir para fixar o conteúdo estudado: XP. 
Programação extrema: uma introdução suave. XP Extreme Programming, 
8 out. 2013. Disponível em: http://www.extremeprogramming.org/. Acesso 
em: 8 mar. 2021.
• Planejamento: também chamado jogo do planejamento. Nessa fase, faz-se um planejamento 
de projeto, não muito elaborado ou que leve muito tempo para ser feito. Na maioria das vezes, 
detalhes são omitidos, considerando a habilidade dos membros da equipe em interpretar os 
resultados que se quer atingir.
O jogo de planejamento se inicia com a atividade “ouvir” – uma atividade de 
levantamento de requisitos que capacita os membros técnicos da equipe XP 
a entender o ambiente de negócios do software e possibilita que se consiga 
ter uma percepção ampla sobre os resultados solicitados, fatores principais 
e funcionalidade (PRESSMAN, 2011, p. 88).
• Projeto: o projeto XP preserva a simplicidade. É preferível sempre um projeto simples a uma 
representação mais complexa (PRESSMAN, 2011). Esse design não comporta muitas funcionalidades 
com antecedência e segue um determinado número de ações:
— Escolher metáfora do sistema. As metáforas são elementos que o desenvolvedor usa do 
computador, tais como lixeira, ambiente operacional, janelas e pastas para simular o ambiente 
de software a ser criado.
— Usar cartões CRC (classe/responsabilidade/colaborador) para sessões de design. Os cartões CRC 
identificam e organizam classes orientadas a objetos.
— Criar soluções de pico para reduzir riscos.
— Cuidado na adição das funcionalidades com muita antecedência.
— Sempre que possível, refatorar para aprimorar a concepção do software. A refatoração é uma 
técnica de construção para otimização de projetos; significa que a atividade de projeto é 
realizada continuamente enquanto o sistema estiver sendo desenvolvido.
• Codificação: inicialmente, são desenvolvidos vários testes de unidades. Na implementação 
do código, todos revisam e fazem acréscimos de funcionalidades. Uma inovação da XP é 
a programação em dupla. Existe uma grande ênfase para o trabalho em duplas, assim, um 
dos programadores pode trabalhar na codificação enquanto o outro cuida de integração, 
84
Unidade III
padrões de código e testes das unidades. A ideia é: “Duas cabeças normalmente funcionam 
melhor que uma”.
• Testes: antes de liberar o código, a equipe faz testes de unidades para possíveis correções de 
falhas no software. Os testes de unidades são criados na codificação com o princípio de poderem 
ser repetidos de forma fácil. Quando um erro é encontrado, os testes são criados. Os testes de 
aceitação são realizados frequentemente e uma pontuação é executada. 
 Lembrete
As metodologias ágeis aplicam uma coleção de práticas guiadas 
por princípios e valores que podem ser adotados por profissionais de 
software no dia a dia.
5.2.2 Scrum
A origem do nome Scrum vem da atividadede jogadores de rúgbi; refere-se ao trabalho de deslocar 
a bola pelo campo estando “fortemente” juntos. O Scrum foi concebido por Jeff Sutherland e sua equipe 
de desenvolvimento na década de 1990 (PRESSMAN, 2011). O desenvolvimento ágil Scrum segue os 
mesmos princípios do Manifesto Ágil.
Scrum é um processo para construir software de modo incremental e em ambientes complexos, 
cujos requisitos não são claros ou mudam com muita frequência.
O objetivo do Scrum é fornecer um processo conveniente para projetos e desenvolvimento 
orientado a objetos.
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.
O processo do Scrum incorpora as seguintes atividades estruturais: requisitos, análise, projeto, 
evolução e entrega (PRESSMAN, 2011).
Inicialmente, são determinados papéis e responsabilidades. Na figura 36, nota-se que o processo 
ágil do Scrum é organizado em ciclos. Os ciclos ágeis de processos do Scrum são definidos por um breve 
período, acompanhados de certa disciplina a ser seguida em compasso com os sprints.
85
FUNDAMENTOS DE ENGENHARIA DE SOFTWARE
Um sprint tem um período curto de tempo. Funciona do seguinte modo: os funcionários devem 
realizar uma série de atividades e a cada novo sprint o profissional adquire novas experiências com base 
na etapa anterior, levando a melhorias em cada sprint subsequente. O número de sprints necessários 
varia de acordo com o tamanho e a complexidade do artefato a ser construído.
Sprint
No esporte e em muitas outras atividades ocorrem as seguintes etapas: no início, vale toda energia e 
velocidade para se conseguir uma boa posição; durante a competição, administra-se todo o desempenho; 
no fim, vale toda a atenção, energia, potência, velocidade e exaustão. O objetivo é conquistar a melhor 
posição e, se possível, a vitória. Essa finalização é chamada de sprint.
Observe a seguir as características do Scrum:
• O Scrum promove reuniões diárias de 15 minutos e nelas todos respondem às seguintes questões:
— O que você realizou desde a última 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.
• Promovem o compartilhamento de conhecimento:
— Progresso medido continuamente.
— Minimização de riscos.
Pressman (2011) explica que o Scrum enfatiza o uso de um conjunto de padrões de processo 
de software que comprovam sua eficácia em projetos com prazos curtos, requisitos mutáveis e 
críticos do negócio.
Acompanhe o fluxo apresentado na figura 32. O método Scrum é composto de um conjunto de ações 
de desenvolvimento do processo de software e é aplicado de forma sequencial, com várias iterações e 
entregas de software por incrementos.
86
Unidade III
• Planejamento
• Andamento do processo 
Sprint (corrida)
 — Ciclos
• Encerramento
• Escopo do andamento 
Sprint (corrida)
Reunião diária 
do Scrum
Tarefas detalhadas 
pela equipe
Lista de prioridades 
do produto em espera 
(backlog)
Nova demonstração 
de funcionalidade, 
podendo ser liberado 
para uso
24h
2 a 4
semanas
Figura 32 – Metodologia de desenvolvimento ágil Scrum
Registro pendente de trabalhos (backlog) – é um termo utilizado para 
designar listas com prioridades dos requisitos ou funcionalidades do projeto 
que fornecem valor ao cliente. Os itens podem ser adicionados a esse registro 
em qualquer momento.
Urgências (corridas de curta distância) sprints – são unidades de trabalho 
solicitadas para atingir um requisito do registro de trabalho (backlog), 
normalmente em trinta dias.
Reuniões Scrum – são reuniões curtas (em torno de 15 minutos) realizadas 
diariamente.
Demos – entrega do incremento de software ao cliente para que a 
funcionalidade implementada possa ser avaliada pelo cliente. O demo não 
precisa estar completo, mas deve apresentar as principais funções no prazo 
determinado (PRESSMAN, 2011, p. 95).
5.2.3 FDD
 
O Desenvolvimento Dirigido a Funcionalidades (Feature Driven Development) 
foi concebido por Peter Coad e seus colegas em 1999, teve como premissa 
criar um modelo prático de processo para a engenharia de software orientada 
a objetos. No entanto, Stephen Palmer e John Felsing em 2002 aprimoraram 
o modelo descrevendo um processo ágil e adaptativo que pode ser aplicado 
a projetos de software tanto a projetos de médio como de grande porte 
(PRESSMAN, 2011, p. 98).
87
FUNDAMENTOS DE ENGENHARIA DE SOFTWARE
O FDD (Feature Driven Development) tem como foco a entrega frequente de software funcional ao 
cliente. Está baseado no processo de desenvolvimento de software iterativo e incremental.
Com FDD os clientes têm resultados rápidos e relatórios de acompanhamento do desenvolvimento 
numa linguagem que eles entendem, os gerentes de projeto têm uma visão completa e exata de 
acompanhamento do projeto e os desenvolvedores conseguem trabalhar em novas tarefas em poucos 
dias e ficam mais envolvidos em análise, projeto e codificação.
Para controle, o FDD utiliza um termo comum chamado “característica” (feature, em inglês). Na 
figura 33, Deluca (2008) destaca a feature e suas descrições. De acordo com vários autores e para um 
melhor entendimento, o termo a ser usado no texto é em português: “característica”.
A característica é uma função relativamente pequena e que deve ser alinhada diretamente 
com o cliente:
• As características podem ser pequenos blocos de funções ou certa funcionalidade, sendo 
determinadas com base no tamanho e na complexidade do artefato a ser desenvolvido. Esse 
recurso é para que usuários e desenvolvedores possam ter melhor controle e entendimento de 
todo o processo.
• As características são organizadas em agrupamentos com base na hierarquia ou prioridades 
relacionadas ao negócio.
• Normalmente, a equipe estabelece metas a cada duas semanas para o desenvolvimento de novas 
características.
Requisitos
Desenvolver 
um modelo 
abrangente
Construir 
a lista 
de features
Planejar 
por 
feature
Produto
Concepção e planejamento
Plano de 
desenvolvimento
ProgressoDetalhar 
por 
feature
Construir 
por 
feature
Construção
Mais forma que conteúdo
Mais conteúdo na forma
Modelo de objetos
Pacotes de trabalho
Figura 33 – Engenharia de software com FDD
O FDD é a metodologia ágil de desenvolvimento que mais enfatiza as diretrizes e técnicas de gestão 
de projetos. O projeto é claro para todos os envolvidos. Essa metodologia pode ser combinada com 
88
Unidade III
outras metodologias ágeis, a exemplo do Scrum. O FDD define seis processos (ou marcas de referência) 
durante o projeto e a implementação de uma característica:
• Ciclo de desenvolvimento do código.
• Projeto.
• Inspeção do projeto.
• Codificação.
• Inspeção do código.
• Promoção para a construção.
5.2.4 DSDM
Dynamic System Development Method é tido como um dos primeiros métodos 
ágeis de desenvolvimento, engenharia de software baseada em componentes 
(CBSE – Component-Based Software Engineering). O desenvolvimento 
de software é através da composição de componentes de software 
independentes e implantáveis que estão consistentes com um modelo de 
componentes na engenharia de sistemas (SOMMERVILLE, 2011, p. 514).
O método dinâmico de desenvolvimento de sistemas (DSDM – Dynamic Systems Development 
Method) surgiu como uma extensão do modelo RAD. O DSDM é aplicado em projetos de sistemas 
caracterizados pelos cronogramas e custos limitados. Seu foco está na especificação do sistema, na 
integração de seus componentes e nos testes para verificar se o sistema atende os requisitos especificados.
A filosofia DSDM se baseia em uma versão modificada do princípio de Pareto, isto é, 80% de uma aplicação 
podem ser entregues em 20% do tempo que levaria para entregar a aplicação completa (PRESSMAN, 2011).
Características principais do DSDM:
• Progenitor do XP.
• Estruturapara RAD.
• Fixa tempo e recursos ajustando a quantia de funcionalidades.
• Equipes pequenas. A equipe tem poder para tomar decisão.
• Suporta mudanças nos requisitos durante o ciclo de vida.
89
FUNDAMENTOS DE ENGENHARIA DE SOFTWARE
O DSDM possui nove princípios fundamentais:
• Envolvimento ativo do usuário.
• Equipes capacitadas (com poderes).
• Entrega frequente.
• Aptidão para negócios.
• Desenvolvimento incremental.
• Alterações reversíveis.
• Linha de base para os requisitos.
• Teste integrado.
• Colaboração das partes interessadas.
A figura 34 mostra que o DSDM divide o ciclo de vida do desenvolvimento em cinco estágios: 
viabilidade, estudo de revisão, modelo funcional de iteração, projeto e construção da iteração 
e implementação.
Modelo funcional 
de iteração
Viabilidade
Estudos de revisão
Implementação
Projeto e 
construção da 
iteração
Figura 34 – Os cinco estágios de desenvolvimento do software com a metodologia de desenvolvimento ágil DSDM
Conforme a figura 34, o ciclo de vida DSDM define três ciclos iterativos e duas atividades de ciclo de 
vida adicionais (PRESSMAN, 2011):
90
Unidade III
• Viabilidade: determina os principais requisitos do negócio e restrições, o que permite viabilizar o 
desenvolvimento do software com o DSDM.
• Estudos de revisão (ou negócio): define os requisitos funcionais, a estrutura da informação, 
uma arquitetura básica da aplicação e os recursos que facilitam a manutenção.
• Modelo funcional de iteração: atividade de prototipação para demonstrar a funcionalidade 
ao cliente.
• Projeto e construção da iteração: para atender os objetivos do negócio, os protótipos 
desenvolvidos são verificados, para assegurar que cada modelo funcional tenha passado por um 
processo de engenharia.
• Implementação: a partir da última versão do incremento de software, é gerado um release 
para o cliente.
5.2.5 Crystal
Conforme Pressman (2011), Alistair Cockburn, em 2005, e Jim Highsmith, em 2002, criaram a família 
Crystal de métodos ágeis visando conseguir elaborar uma abordagem de desenvolvimento de software 
que priorizasse a adaptabilidade.
O método Crystal/Clear faz parte de um conjunto de metodologias criadas com o intuito de fazer 
uma analogia com os cristais geológicos, apresentados na natureza com sua própria cor, forma e dureza. 
As premissas destacadas para a existência desse conjunto são:
• Todo projeto tem necessidades, convenções e uma metodologia diferente.
• O funcionamento do projeto é influenciado por fatores humanos, e há melhora do projeto quando 
os indivíduos produzem melhor.
• Melhor comunicação e lançamentos frequentes reduzem a necessidade de construir produtos 
intermediários do processo.
O método Crystal/Clear é direcionado a projetos pequenos, com equipes de até seis desenvolvedores.
Assim como o Scrum, os membros da equipe têm especialidades distintas e existe uma forte ênfase 
na comunicação entre os membros.
Existem também outras metodologias Crystal para grupos maiores. A figura 35 mostra políticas e 
práticas que devem ser personalizadas para acomodar as propriedades Crystal.
91
FUNDAMENTOS DE ENGENHARIA DE SOFTWARE
Trabalho em 
equipe Comunicação Simplicidade Reflexão
Ajustes 
frequentes
Melhores 
processos
Figura 35 
Toda especificação do projeto é feita informalmente, utilizando quadros publicamente visíveis. Os 
requisitos são elaborados utilizando casos de uso, assim, são enunciados os requisitos como tarefas e 
um processo para sua execução.
As entregas das novas versões de software são feitas em incrementos regulares de um mês e existem 
alguns subprodutos do processo que são responsabilidade de membros específicos do projeto.
 
Destaca-se a manobrabilidade com o significado de um jogo cooperativo 
de invenção e comunicação de recursos limitados, com o principal 
objetivo de entregar software útil funcionando e objetivo secundário 
de preparar-se para o jogo seguinte A família Crystal é, na verdade, um 
conjunto de processos ágeis que se mostraram efetivos para diferentes 
tipos de projeto. A intenção é permitir que equipes ágeis selecionem o 
membro da família Crystal mais apropriado para o seu projeto e ambiente 
(PRESSMAN, 2017, p. 71).
5.2.6 Agile Modeling (AM)
É uma metodologia pautada na prática para modelagem e documentação efetiva de sistemas 
baseados em software.
A AM dispõe de múltiplos modelos para descrever software. É uma coleção de valores, princípios 
e práticas de modelagem de software que podem ser aplicados a um projeto de desenvolvimento de 
software de modo efetivo e leve. Os modelos ágeis são mais efetivos do que os modelos tradicionais, 
porque eles são suficientemente bons, não precisando ser perfeitos.
A expressão “viajar leve” é muito usada na AM. Orienta-se que é preciso conservar apenas os modelos 
que fornecerão valor a longo prazo, e os demais modelos devem ser descartados.
92
Unidade III
 Saiba mais
Acesse o site Agile Modeling:
Disponível em: http://agilemodeling.com. Acesso em: 20 abr. 2021.
6 ENGENHARIA DE REQUISITOS
6.1 Processo da engenharia de requisitos do software
Sommerville (2003) destaca que 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.
Esse documento pode ser usado em contratos e licitações para o desenvolvimento de software, 
escolha de fornecedores de componentes do sistema, acompanhamento de mudanças e especificação 
do software.
 
Algumas pessoas consideram a engenharia de requisitos o processo de 
aplicação de um método estruturado, como a análise orientada a objetos. 
Trata-se de analisar o sistema e desenvolver um conjunto de modelos 
gráficos de sistema, como modelos de casos de uso, que, então, servem como 
especificação do sistema. O conjunto de modelos descreve o comportamento 
do sistema e recebe informações adicionais, descrevendo, por exemplo, seu 
desempenho ou sua confiabilidade (SOMMERVILLE, 2011, p. 69).
As principais atividades do processo da engenharia de requisitos do software/sistema são:
• Estudo da viabilidade do sistema.
• Elicitação.
• Análise.
• Especificação.
• Modelagem.
• Validação.
93
FUNDAMENTOS DE ENGENHARIA DE SOFTWARE
Modelo do Processo da Engenharia de Requisitos do software/sistema: a figura 36 mostra o fluxo de 
atividades do processo da engenharia de requisitos do software/sistema.
Estudo da viabilidade 
do sistema
Especificação, 
modelagem e 
documentação
Elicitação e análise 
de requisitos Validação
Desenvolvimento 
do sistema
Início
Nova iteração
Figura 36 
Observe que na figura 36 o desenvolvimento do sistema só ocorre após a validação dos requisitos. 
Caso os requisitos não sejam validados, ocorre uma iteração, ou seja, todo o processo será revisto, 
incluindo as abordagens para levantamento dos requisitos.
Sommerville (2011) define que as atividades do processo da engenharia de requisitos do 
software/sistema podem ser decompostas em quatro níveis distintos de serviços:
• Nível 1 (Estudo da viabilidade do sistema): esse estudo é de grande importância, pois garante 
que as necessidades do cliente para implementação do sistema estejam de acordo com os 
interesses organizacionais e que os recursos necessários estão disponíveis para o desenvolvimento 
ou integração do novo software/sistema. Um estudo de viabilidade deve ser relativamente barato 
e rápido. O resultado deve informar a decisão de avançar ou não, com uma análise mais 
detalhada (SOMMERVILLE, 2011).
• Nível 2 (Elicitação e análise de requisitos): nessa fase são feitas várias reuniões entre cliente 
e desenvolvedor, com o objetivo de extrair com detalhes o conhecimento do negócio para que se 
destine o software/sistema.
• Nível 3 (Especificação, modelagem e documentação dos requisitos): após a interpretação 
e o entendimento dos detalhes do negócio, inicia-se a preparação do documento de requisitos, 
que deve ser formada pelos vários requisitos discutidos em reunião. Essa fase deveser feita pelo 
desenvolvedor com acompanhamento do cliente. São descritos textos breves interpretativos sobre 
cada requisito, acompanhados sempre que necessário de um modelo visual e, consequentemente, 
da elaboração do documento de requisitos do software/sistema.
• Nível 4 (Validação de requisitos): a validação é a apresentação do documento de requisitos 
em reunião com a participação do grupo formado pelos interessados no sistema. O objetivo é 
94
Unidade III
aprimorar, incluir mudanças propostas e aprovar o início do projeto e o desenvolvimento do 
software/sistema. O documento a ser validado pode ser elaborado para um único sistema, para 
parte do sistema ou para cada funcionalidade do sistema. Vale o bom senso. A análise decisiva 
deve ter base no tamanho e na complexidade do sistema ou da funcionalidade, associada ao seu 
prazo e custo.
O processo da engenharia de requisitos antecede o projeto. A fase de levantamento de requisitos 
busca a interpretação, o entendimento e a especificação do negócio a ser alinhado com a TI. Essa fase 
permite criar uma linguagem única entre o cliente e o desenvolvedor. Conforme a figura 37, para 
iniciar as atividades de projeto, é necessário que as entradas de projeto estejam claras para o cliente 
e para o desenvolvedor.
Informação de 
plataforma
Arquitetura 
de sistema
Especificação de 
banco de dados
Especificação 
de interface
Especificação 
de componentes
Projeto de 
arquitetura
Projeto de 
interface
Projeto de banco de dados
Projeto de 
componentes
Especificação de 
requisitos Descrição de dados
Entradas de projeto
Atividades de projeto
Saídas de projeto
Figura 37 – Modelo geral do processo e projeto
 Lembrete
Conforme Sommerville (2003), 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.
95
FUNDAMENTOS DE ENGENHARIA DE SOFTWARE
6.2 Estudo da viabilidade do sistema
Quanto à identificação (concepção), a maioria dos projetos começa quando uma necessidade de 
negócio é identificada ou um mercado ou serviço novo é descoberto. Os desenvolvedores fazem uma 
série de perguntas com a intenção de estabelecer um entendimento básico do problema. Deve haver 
uma colaboração entre cliente e desenvolvedor.
Para todos os sistemas novos, de acordo com a figura 38, o processo de engenharia de requisitos 
de sistema deve começar com o estudo de viabilidade, antes mesmo da obtenção e da análise de 
requisitos. A entrada para o estudo de viabilidade é uma descrição geral do sistema e de como ele será 
utilizado dentro de uma organização. Os resultados do estudo de viabilidade devem ser: um relatório 
que recomenda se vale ou não a pena realizar o processo de engenharia de requisitos e o processo de 
desenvolvimento de sistemas.
Sugere-se também que o estudo de viabilidade seja feito no acompanhamento de mudanças do 
software que irão ocorrer em seu ciclo de vida.
Estudo da viabilidade
Especificação 
de requisitos
Validação 
de requisitos
Elicitação e análise 
de requisitos
Relatório de 
viabilidade
Modelos 
de sistema
Requisitos de 
usuários e de sistema
Documentação 
de requisitos
Figura 38 – Processo da engenharia de requisitos
Um estudo de viabilidade é um estudo breve, direcionado, que se destina a responder algumas perguntas:
• O sistema proposto contribui para os objetivos gerais da organização?
• No caso, são considerados os aspectos culturais da organização, a hierarquia de comando na 
tomada de decisão e o processo de negócio? Nesse aspecto, é considerado se as regras de negócio 
estão de acordo com a organização?
96
Unidade III
• O sistema pode ser implementado com a utilização de tecnologia atual dentro das restrições de 
custo e prazo?
• O que o cliente quer está dentro do orçamento e prazo para entrega do sistema?
• O sistema pode ser integrado com os outros sistemas já em operação? Qual o impacto das 
mudanças no ambiente operacional do cliente?
• A tecnologia a ser implementada é adaptável ao sistema do cliente (se este existir)?
6.3 Elicitação e análise de requisitos
6.3.1 Elicitação
Elicitação dos requisitos é a tarefa de comunicar-se com os usuários e clientes para determinar quais 
são os requisitos.
Na elicitação o analista deve ter habilidade e sutileza para extrair informações durante uma conversa.
Os analistas podem empregar várias técnicas para elicitar os requisitos dos clientes. As técnicas mais 
utilizadas são:
• Organizar reuniões, entrevistas ou grupos focais (workshops) e, consequentemente, a criação 
da lista de requisitos. O workshop de requisitos consiste na realização de reuniões estruturadas 
e delimitadas entre os analistas de requisitos do projeto e representantes do cliente.
• Prototipação e casos de uso. O analista irá aplicar uma combinação de métodos para 
estabelecer os requisitos exatos de seus stakeholders (qualquer pessoa que terá influência 
direta ou indireta sobre os requisitos do sistema), de forma que um sistema que atenda as 
necessidades do negócio seja produzido. O protótipo é recomendado para avaliar a interface do 
usuário, os problemas de comunicação com outros produtos e a possibilidade de cumprimento 
dos requisitos de desempenho.
Os métodos mais utilizados para elicitar requisitos são:
• Questionários dirigidos.
• Perguntas abertas e brainstorming.
• Grupos de desenvolvimento de sistemas do tipo projeto de aplicação conjunta (JAD – Joint 
Application Design). O JAD é uma técnica de captura de requisitos baseada em reuniões. As 
técnicas JAD aplicam os conceitos de visões refinadas, sendo três as visões da aplicação: overview 
(geral), macro e detalhe (FOURNIER, 1994).
97
FUNDAMENTOS DE ENGENHARIA DE SOFTWARE
Observe a seguir a formulação das primeiras questões:
• Quem está por trás da solicitação desse trabalho?
• Quem vai usar a solução?
• Qual será o benefício econômico de uma solução bem-sucedida?
• Há outra fonte para a solução que você necessita?
Essas questões ajudam a identificar todos os que têm interesse no software a ser construído 
(PRESSMAN, 2011).
As técnicas reconhecidas como eficientes e efetivas na elicitação dos requisitos são:
• Etnografia. É uma técnica de observação utilizada para entender os processos operacionais; o 
analista acompanha o ambiente de trabalho em que o sistema será usado (SOMMERVILLE, 2011).
• Técnicas Facilitadas de Especificação de Aplicações Melhorada (eFAST – Enhanced Facilitated 
Application Specification Techniques). O eFAST é uma melhoria do método JAD, que serve para 
captura de requisitos. Seu principal objetivo é cobrir o gap (falha de entendimento) entre o que o 
desenvolvedor pensa que vai produzir e o que os clientes pensam que vão receber.
 Saiba mais
Consulte a referência a seguir:
DAD, K.; JAMIL, A. N. Enhanced Facilitated Application Specification 
Techniques (eFAST). In: IEEE/ACIS INTERNATIONAL CONFERENCE ON 
COMPUTER AND INFORMATION SCIENCE, 5., 2006, Honolulu (USA). Anais 
[…]. Honululu: Institute of Electrical and Electronics Engineers (IEEE), 2006. 
Disponível em: https://bit.ly/3rTxOQY. Acesso em: 3 mar. 2021.
• Implantação da função de qualidade (QFD – Quality Function Deployment). A QFD identifica três 
tipos de requisitos: normais; esperados e fascinantes (PRESSMAN, 2011).
• Cenários de uso. Um caso de uso representa uma descrição breve de uso de uma determinada 
funcionalidade do sistema que é requisitada pelo usuário. O diagrama de casos de uso (figura 39) 
mostra a relação entre os casos de uso e a entidade (ator). Esse diagrama faz parte do padrão 
de diagramas UML. Ele é composto dos seguintes elementos: cenário, casos de uso (interações), 
atores (agentes ou entidades) e o relacionamento de comunicação.
98
Unidade III
Registro de 
venda — PDV
Estoque 
restaurante
Estoque 
Rodoalimenta
LEC
Pedido de compra do 
restaurante
Pedido de compra da 
Rodoalimenta
<<include>>
<<include>>
<<include>>
Fornecedor
Caixa
Gerente de comprasRodoalimenta
Gerente de 
restaurante <<extend>>
<<extend>>
Figura 39 – Diagrama de caso de uso em UML para a função de 
gerenciamento de compras do centro de distribuição Rodoalimenta
Na elicitação o diagrama de casos de uso apresenta um cenário de uso específico do sistema, em 
que apenas as interações do usuário com o sistema são mostradas, servindo como um modelo para o 
processo de negócio. Os detalhes técnicos de construção do sistema não são mostrados nesse diagrama, 
eles são apresentados em outros diagramas da UML.
 Observação
Na interpretação de como o sistema de informação da logística irá 
funcionar, o diagrama de casos de uso ilustrado na figura 39 corresponde a 
um sistema de informação da logística para o controle de estoque.
Acompanhe os elementos do diagrama na figura 39. O ator Caixa registra a venda ao passar 
o código de barras do produto pelo leitor ótico do ponto de venda (PDV). Assim, é feito o 
registro correspondente ao caso de uso Registro de Venda. Essa venda faz com que o sistema de 
informação registre uma baixa de estoque pelo caso de uso Estoque Restaurante, por meio do qual 
foi efetuada a venda. Para a compra de reposição do estoque, o sistema faz o cálculo no caso de 
uso Lote Econômico de Compra (LEC), que possui o registro da quantidade de produtos existentes, 
bem como o período certo para se fazer o pedido de compra para reposição do estoque. O ator 
Gerente Restaurante acessa o caso de uso Pedido de Compra do Restaurante para fazer seu pedido. 
A Rodoalimenta é um centro de distribuição de produtos para restaurantes cujo ator Gerente 
de Compras Rodoalimenta atende o pedido de compra do restaurante pelo caso de uso Pedido de 
Compra do Restaurante, monitora o estoque do centro de distribuição pelo caso de uso Estoque 
Rodoalimenta e, se for necessário, faz o pedido de reposição do estoque do produto, pelo caso de uso 
Pedido de Compra da Rodoalimenta.
99
FUNDAMENTOS DE ENGENHARIA DE SOFTWARE
6.3.2 Levantamento e análise de requisitos
Durante o levantamento de requisitos, ocorrem reuniões com analistas de negócios por parte 
do cliente. A atividade de análise dos requisitos por parte do analista de sistemas é fazer pesquisas 
e classificar e agrupar as ideias, com o objetivo de entender como funciona o negócio e já estabelecer 
algumas funcionalidades para o sistema. As reuniões com o cliente devem ocorrer periodicamente para 
se ter uma completa compreensão do domínio do sistema (veja a figura 40).
Na análise, os membros da equipe técnica trabalham com o cliente e os usuários para descobrir 
informações sobre o domínio da aplicação, que serviços o sistema deve fornecer, o desempenho exigido 
do sistema, bem como as restrições de software e hardware (SOMMERVILLE, 2003).
Especificação 
de requisitos
Documento 
de requisitos
Verificação 
de requisitos
Classificação
Compreensão 
do domínio
Coleta de 
requisitos
Definição 
das prioridades
Resolução 
de conflitos
Entrada do processo
Figura 40 – Processo de levantamento e análise de requisitos
6.4 Especificação, documentação e modelagem dos requisitos
Em sistemas e software, o termo especificação significa coisas diferentes para pessoas diferentes. 
A especificação e a modelagem são os produtos do trabalho final produzido pelo engenheiro 
de requisitos. Elas servem como fundamento das atividades de engenharia de software subsequentes. 
Assim, descrevem-se a função e o desempenho do sistema e as restrições que acompanharam seu 
desenvolvimento. Uma 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.
100
Unidade III
 Saiba mais
Leia o texto indicado a seguir:
BAHN, C. IEEE 830-1998: prática recomendada do IEEE para especificações 
de requisitos de software. Comitê de Normas de Engenharia de Software e 
Sistemas, 20 out. 1998 [reafirmado em 9 dez. 2009]. 
Disponível em: https://bit.ly/3rIqVCf. Acesso em: 3 mar. 2021.
Os stakeholders interpretam os requisitos de maneiras diferentes e, muitas vezes, notam-se conflitos 
e inconsistências inerentes aos requisitos (SOMMERVILLE, 2011).
Existem vários requisitos que devem ser levantados e deduzidos. Contudo, as atividades e tarefas 
descritas na preparação do documento de requisitos se baseiam em quatro principais grupos de 
requisitos, que serão descritos nesse mesmo tópico. Os principais grupos de requisitos para elaboração 
do contrato do software/sistema são:
• Requisitos do usuário.
• Requisitos do sistema.
• Requisitos funcionais.
• Requisitos não funcionais.
6.4.1 O documento de requisitos de software
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 declaração oficial do que é 
exigido dos desenvolvedores de sistema. Ele deve incluir os requisitos de usuário para um sistema e uma 
especificação detalhada dos requisitos de sistema, abrangendo desde a alta gerência da organização até 
os analistas responsáveis pelo desenvolvimento.
Pressman (2011) sugere o modelo de especificação de requisitos de software, descrito a seguir:
Sumário
Histórico de revisão
1. Introdução
1.1 Propósito
101
FUNDAMENTOS DE ENGENHARIA DE SOFTWARE
1.2 Convenções do documento
1.3 Público-alvo e sugestões de leitura
1.4 Escopo do projeto
1.5 Referências
2. Descrição geral
2.1 Perspectiva do produto
2.2 Características do produto
2.3 Classes de usuários e características
2.4 Ambiente operacional
2.5 Restrições de projeto e implementação
2.6 Documentação para usuários
2.7 Hipóteses e dependências
3. Características do sistema
3.1 Características do sistema 1
3.2 Características do sistema 2 (e assim por diante)
4. Requisitos de interfaces externas
4.1 Interfaces do usuário
4.2 Interfaces de hardware
4.3 Interfaces de software
4.4 Interfaces de comunicação
5. Outros requisitos não funcionais
5.1 Necessidades de desempenho
102
Unidade III
5.2 Necessidades de proteção
5.3 Necessidades de segurança
5.4 Atributos de qualidade de software
6. Outros requisitos
Apêndice A: Glossário
Apêndice B: Modelos de análise
Apêndice C: Lista de problemas
6.4.2 Requisitos do usuário (RU)
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. Esse documento pode ser 
elaborado pelo representante do usuário.
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 é um modelo 
de fácil interpretação. Normalmente, utiliza-se um modelo construído com o diagrama de atividade da 
UML, que é uma ferramenta fácil de usar e que inclusive o cliente se sente à vontade para expor 
suas ideias em um desenho, o que auxilia muito o analista. A modelagem do processo de negócio 
(BPM – Business Process Management) pode ser constrúida com o aplicativo BizAgi Modeler, que é 
oferecido gratuitamente pela Object Management Group (OMG).
Os cenários de uso são construídos com o diagrama de casos de uso da UML. É uma resposta do 
analista de sistemas para apresentar o escopo ou partes do software que será construído.
 Saiba mais
Faça o download da ferramenta gratuita de nome BizAgi, fornecida pela 
OMG. Essa ferramenta é padrão na construção modelos de negócios.
OBJECT MANAGEMENT GROUP (OMG). Categoria de modelagem de 
negócios: especificações associadas. [s.d.]. 
Disponível em https://bit.ly/3lb2Ph5. Acesso em: 3 mar. 2021.
103
FUNDAMENTOS DE ENGENHARIA DE SOFTWARE
6.4.3 Requisitos funcionais (RF)
Nesse instante você deve pensar: “Será que os requistos funcionais são sobre aquilo que irá funcionar 
no sistema, para fazer o que preciso?” Exatamente isso!
Requisitos funcionais são declarações mais detalhadas dos requisitos do usuário com uma 
especificação completa e consistentede 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.
Para que os objetivos das funções fiquem claros, aconselha-se fazer um quadro de especificações das 
funções do software e que contenha um código que identifique o requisito e a descrição do requisito, 
conforme é mostrado no quadro:
Quadro 6 – Especificação de requisitos funcionais
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
As especificações das funcionalidades do software normalmente são refinadas por meio da 
prototipagem, que é uma forma colaborativa de participação do cliente no desenvolvimento 
do software.
A modelagem da análise é uma ação de elaboração e cujas informações obtidas do cliente 
são expandidas e refinadas. A modelagem destaca o desenvolvimento de um modelo técnico 
visual das funções, características e restrições do software. Ela é guiada pela criação e pelo 
refinamento de cenários do usuário, que descrevem como o usuário (e outros atores) vão 
interagir com o sistema.
Os relacionamentos e a colaboração entre as classes são identificados e uma variedade de diagramas 
UML é produzida. A modelagem serve também para avaliar a eficiência do fluxo de trabalho e a forma 
como ocorrerá o desenvolvimento. Veja o exemplo a seguir de como funciona o refinamento 
dos modelos.
104
Unidade III
Exemplo de aplicação
A partir do caso de uso Registro acadêmico, foram projetados os modelos apresentados nas figuras 
41 e 42. A figura 41 apresenta o diagrama das classes derivado do caso de uso Registro acadêmico, 
conjunto de classes usado para estruturar a informação. Já a figura 42 apresenta na parte inferior 
o diagrama de sequência para mostrar o comportamento do software. Observe que, na figura 42, o 
diagrama de sequência é criado a partir dos métodos apresentados nas classes Aluno e Professor.
Em apoio a esses diagramas, para refinar o processo do projeto são apresentados também diagramas 
de: objetos, pacotes, estados, comunicação e interação.
Pessoa
 - CPF
 - nome
 - dataNascimento
Aluno
 - matricula: int
Professor
 - registroAcademico: int
Figura 41 – Diagrama de classes que mostra a herança de objetos
Pessoa
 - CPF
 - nome
 - dataNascimento
Aluno
 - matricula
+ informarMatricula( ) int
+ receberNota(double) void
Professor
- registroAcademico int
- informarNota(int) double
João :Professor Pedro :Aluno
informarMatricula( ) :int
receberNota(double)
Figura 42 – Na parte inferior da figura está o diagrama de sequências construído 
a partir dos métodos das classes, apresentadas na parte superior da figura
105
FUNDAMENTOS DE ENGENHARIA DE SOFTWARE
6.4.4 Requisitos não funcionais (RNF)
Agora você deve pensar: “Será que os requistos não funcionais envolvem o que não irá funcionar no 
sistema?” Totalmente errado.
 
Os requisitos não funcionais, como o nome sugere, são requisitos que não 
estão diretamente relacionados com os 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. Uma alternativa a esse cenário seriam os requisitos definirem 
restrições sobre a implementação do sistema, como as capacidades dos 
dispositivos de E/S ou as representações de dados usadas nas interfaces com 
outros sistemas (SOMMERVILLE, 2003, p. 85).
Os requisitos não funcionais determinam a qualidade do software, que é o diferencial de uma 
aplicação. Uma forma de memorizar o que são requisitos não funcionais é saber que requisito não 
funcional é tudo aquilo que o cliente não pede, mas que, se der problema, ele vai reclamar.
Observe essa situação: determinado usuário levou uma hora preenchendo um formulário na rede 
local de um sistema servidor/cliente. Ao finalizar e salvar o formulário, o software emite um aviso, de 
tela inteira, de sistema forma do ar. Se o software possuir o recurso de recuperação do arquivo, mesmo 
que seja no computador local, o usuário vai encarar isso de forma mais amena, diferentemente se ele 
perder o formulário já preenchido: ele vai reclamar de um problema de confiabilidade.
De acordo com Sommerville (2003), na figura 43 são mostrados os tipos de requisitos não funcionais, 
formados pelos grupos: requisitos do produto, requisitos organizacionais e requisitos externos.
Requisitos 
não funcionais
Requisitos 
do produto
Requisitos 
de usabilidade
Requisitos 
de eficiência
Requisitos de 
implementação
Requisitos 
éticos
Requisitos 
legais
Requisitos de 
portabilidade
Requisitos de 
desempenho
Requisitos 
de espaço
Requisitos de 
segurança
Requisitos de 
privacidade
Requisitos de 
confiabilidade
Requisitos de 
padrões
Requisitos 
de entrega
Requisitos de 
interoperabilidade
Requisitos 
organizacionais
Requisitos 
externos
Figura 43 – Tipos de requisitos não funcionais
106
Unidade III
O quadro a seguir apresenta as principais métricas de requisitos do produto. Essas métricas servem 
como base para o desenvolvimento do produto software. São determinadas principalmente como meta 
para estabelecer a qualidade exigida em que o software irá operar.
Quadro 7 – Métricas de requisitos do produto
Propriedade Medida
Velocidade (Desempenho)
Transações processadas/segundo
Tempo de resposta ao usuário/evento
Tempo de atualização da tela
Tamanho (Espaço)
Tamanho em megabytes do software final
Tamanho da memória
Facilidade de uso (Usabilidade)
Tempo de treinamento necessário
Número de frames de ajuda
Confiabilidade
Tempo médio para falhar
Probabilidade de indisponibilidade
Disponibilidade
Taxa de ocorrência de falhas
Robustez
Tempo de reinício após falha
Percentual de eventos que causam falhas
Probabilidade de corrupção de dados em caso de falha
Portabilidade
Percentual de declarações dependentes do sistema-alvo
Número de sistemas-alvo
Fonte: Sommerville (2011, p. 62-63).
6.4.5 Requisitos do sistema (RS)
São descrições mais detalhadas dos requisitos do usuário com o foco no sistema, com uma 
especificação completa e consistente de todos os componentes do sistema. Podem ser apresentados 
vários modelos que mostram objetos ou fluxo de dados. Servem como base para o contrato destinado à 
implementação do sistema. Os componentes podem ser divididos em dois grupos:
• A visão estática da arquitetura promove a visão da organização e relações dos componentes do 
software com elementos de dados (banco de dados, arquivos-texto etc.), com o hardware e outros 
ambientes operacionais.
• A visão dinâmica da arquitetura promove a visão comportamental do sistema e de seus 
componentes. São definidos os seguintes aspectos: como os componentes reagem a eventos 
internos e externos e a forma como eles se comunicam (ou trocam mensagens).
107
FUNDAMENTOS DE ENGENHARIA DE SOFTWARE
 Saiba mais
Leia a referência a seguir:
SILVA, T. A. S. Modelos UML estáticos vs. dinâmicos. TASSinfo, 19 abr. 
2016. Disponível em: https://bit.ly/3l8KzVi. Acesso em: 3 mar. 2021.
Os requisitos do sistema são especificados conforme o quadro a seguir:
Quadro 8 – Especificação de requisitos do sistema
Requisito do 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
A engenharia de projeto no nível de componentesocorre após a conclusão da primeira iteração, 
após a elaboração da arquitetura (ou prototipação) do software ou do sistema.
“O objetivo da atividade de projetar é gerar um modelo ou representação que apresente solidez, 
comodidade e deleite. Para tanto, temos de praticar a diversificação e depois a convergência” 
(PRESSMAN, 2011, p. 207).
Para a modelagem dos requisitos do sistema, são utilizados basicamente os diagramas de 
componentes e o diagrama de implantação da UML.
Exemplo de aplicação
“A prática da diversificação é adquirir e construir um repertório de alternativas, a matéria-prima 
do projeto: componentes, soluções de componentes e conhecimento” (BELADY, 1981 apud PRESSMAN, 
2011, p. 407).
A figura 44 fornece diversos componentes e módulos disponíveis para o projetista construir e 
implantar infraestruturas de TI que apoiem um determinado sistema.
108
Unidade III
Cliente - SO Windows Server - SOR Windows Web Server - Apache/Tomcat
Cliente - Browser Server - SOR Linux Server = SGBD SQL Microsoft
Server - Gerenciador de telas Web server - Microsoft Ils Server = SGBD MySQL
Server - Gerenciador de contas (Login) Server - App Controle de Estoque (JSP)
Cliente - PC 
Computer
Nó1 - Server 
Computer 1
Nó2 - Server 
Computer 2
Figura 44 – Repertório de alternativas para a construção de um sistema
O projetista na prática da convergência escolhe os elementos do repertório que satisfaça os requisitos 
e os resume em uma particular configuração de componentes após a criação do produto final. A figura 45 
apresenta a convergência de alguns desses componentes em módulos. O módulo, representado por uma 
“caixa”, é construído com o diagrama de implantação; ele representa o modelo de implantação desse 
sistema. Observe que os módulos são formados pelos mesmos componentes destacados na figura 44.
Cliente - PC Computer
<<TCP/IP>>
<<HTTP>>
Cliente - SO Windows
Cliente - Browser
Nó 1 - Server computer 1
<<HTML>>
Server - SOR Windows
Web - Server - Microsoft Ils
Server - Gerenciador de telas
<<HTML>>
Server - Gerenciador de contas
<<HTML>>
<<TCP/IP>>
<<DNS>>
<<JSP>>
Nó 2 - Server computer 2
<<MySQL>>
Server - SOR Linux
Web Server - Apache/Tomcat
Server - App-controle de estoque
<<JSP>>
Server - SGBD MySQL
<<MySQL>>
Figura 45 – Modelo de módulo de um sistema
109
FUNDAMENTOS DE ENGENHARIA DE SOFTWARE
6.4.6 Validação dos requisitos
A validação dos requisitos ocorre formalmente. Os produtos de trabalho resultantes da engenharia 
de requisitos são avaliados e aprovados quanto à qualidade. A atividade de validação é a última fase do 
processo da engenharia de requisitos, responsável por autorizar o desenvolvimento do sistema/software. 
É 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.
Os critérios de validação são especificações para demonstrar o entendimento e viabilizar uma 
implementação de software bem-sucedida logo que informações básicas, funções, desempenho, 
comportamento e interfaces forem descritos. Esses critérios servem de base para as atividades de teste 
que ocorrerão posteriormente no processo de engenharia de software.
O documento a ser validado pode ser elaborado para um único sistema, para parte do sistema ou 
para cada funcionalidade dele. Vale o bom senso. A análise decisiva deve ter base no tamanho, na 
complexidade ou na qualidade exigida do sistema ou da funcionalidade, sendo associada ao seu prazo 
e custo. Esse documento pode ser interpretado como o “aceite do cliente”.
O cliente valida os requisitos, processo que envolve as informações fornecidas e o 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 comprometem em desenvolver o sistema no custo e prazo 
determinado. No desenvolvimento irão ocorrer algumas ou muitas mudanças nos requisitos, o que 
causará nova verificação dos requisitos, incluindo custo e prazo para novas implementações.
A validação de requisitos examina a especificação para garantir que todos os requisitos do software 
tenham sido declarados de modo não ambíguo, que as inconsistências, omissões e erros tenham sido 
detectados e corrigidos e que os produtos de trabalho estejam de acordo com as normas estabelecidas 
para o processo, o projeto e o produto.
O principal mecanismo de validação de requisitos é a revisão formal (checklist). A equipe de revisão 
deve incluir engenheiros de software, clientes, usuários e outros interessados no software/sistema.
Exemplo de aplicação
Um manual do usuário preliminar pode ser rascunhado para casos em que um protótipo não tenha 
sido desenvolvido. O manual estimula o usuário/cliente a revisar o software a partir de uma perspectiva 
de engenharia humana. Por exemplo: comentário do usuário: “A ideia é boa, mas não é desse jeito 
que eu pretendia fazer isso...”. Esses tipos de comentários devem ser feitos o quanto antes no processo 
revisional. Tal ação auxilia a melhoria ou o entendimento do produto. Antes de finalizado, o processo revisional 
normalmente resulta em modificações na função, no desempenho, nas representações da informação, 
nas restrições ou nos critérios da validação.
110
Unidade III
 Resumo
As metodologias ágeis surgiram para acrescentar um novo paradigma 
de desenvolvimento de software e melhor uso da engenharia de software. 
A metodologia ágil vai de encontro aos modelos prescritivos de desenvolvimento 
de software, com o argumento, ou melhor, com um manifesto pelo 
reconhecimento da nova tendência para desenvolver software.
Vários desses métodos ágeis foram dispostos nesta unidade, bem como 
as metodologias aplicáveis em todas as fases de projeto e construção do 
produto software de computador.
Esses métodos abrangem a programação e produtividade de software 
com equipes pequenas e com o objetivo de melhorar o desempenho nas 
entregas de produtos de software, tais como aplicações, implementação de 
novas funcionalidades, atualizações e mudanças.
As metodologias ágeis estudadas – XP, Scrum, FDD, DSDM, Crystal e 
AM – compõem um conjunto útil em cada fase do desenvolvimento, desde 
o entendimento do projeto, sua modelagem, codificação e implantação e 
com entregas rápidas, que variam de duas a quatro semanas.
Todo projeto começa pela ideia do que vai fazer e para que vai servir ou 
melhorar alguma coisa. A engenharia de requisitos é a principal fase, quando 
o analista concebe o entendimento da ideia e o negócio que será aplicado.
A engenharia de requisitos apresentada se baseia em quatro principais 
tipos de requisitos: usuário, funcional, não funcional e do sistema. Cada 
requisito tem um foco no desenvolvimento: o que o cliente quer? Abstração 
do negócio; especificação e modelagem do negócio; modelagem do produto 
e atividades que acompanham cada requisito.
Vimos que são ponderadas duas questões: “o que se quer? Será que 
dá para fazer?” Antes mesmo de começar o processo de engenharia dos 
requisitos, é feita a viabilidade para produzir um software específico ou 
parte deste. Para tal, consideram-se custos, prazos, organização das ideias 
e recursos e tecnologias a serem implementadas.
“O que se quer? O que está sendo feito?” A suscitação dessas questões 
traz eficácia e eficiência para a equipe de desenvolvimento. A validação dos 
requisitos acompanha todo o processo de desenvolvimento de software e 
garante metas e atividades específicas do processo.
111
FUNDAMENTOS DE ENGENHARIA DE SOFTWARE
 Exercícios
Questão 1. A Extreme Programing (Programação Extrema – XP) emprega uma abordagem orientada 
a objetos como paradigma e envolve um conjunto de regras e práticas constantes de quatro atividades 
metodológicas:
• planejamento;
• projeto;
• codificação;
• testes.
Em relação às quatro atividades-chaves da XP, analise as afirmativas.
I –Na fase de planejamento, é feito o planejamento do projeto, caracterizado por ser minucioso e 
apresentar todos os detalhes, não importando o tempo necessário para sua realização.
II – O projeto XP preserva a simplicidade.
III – Na codificação, são desenvolvidos vários testes de unidades.
IV – Na fase de testes, são feitos testes de unidades para possíveis correções de falhas no software.
É correto apenas o que se afirma em:
A) I e IV.
B) I e II.
C) II, III e IV.
D) I, III e IV.
E) I, II e III.
Resposta correta: alternativa C.
112
Unidade III
Análise das afirmativas
I – Afirmativa incorreta.
Justificativa: na fase de planejamento, é feito o planejamento do projeto. No entanto, ele não 
precisa ser muito elaborado e não deve levar muito tempo para ser feito. Na maioria das vezes, 
detalhes são omitidos, considerando a habilidade dos membros da equipe em interpretar os resultados 
que se quer atingir.
II – Afirmativa correta.
Justificativa: o projeto XP preserva a simplicidade. É preferível sempre um projeto simples a uma 
representação mais complexa. Esse design não comporta muitas funcionalidades com antecedência e 
segue determinado número de ações:
• escolher a metáfora do sistema;
• usar cartões CRC (classe-responsabilidade-colaborador) para sessões de design;
• criar soluções de pico para reduzir riscos;
• ter cuidado na adição das funcionalidades com muita antecedência;
• refatorar sempre que possível, para aprimorar a concepção do software.
III – Afirmativa correta.
Justificativa: na codificação, são desenvolvidos vários testes de unidades. Na implementação do 
código, todos revisam e fazem acréscimos de funcionalidades. Uma característica da XP é a programação 
em dupla. Existe grande ênfase para que o trabalho seja feito em duplas, a fim de permitir que um dos 
programadores trabalhe na codificação enquanto o outro cuida da integração, dos padrões de código e 
dos testes das unidades.
IV – Afirmativa correta.
Justificativa: antes de liberar o código, a equipe faz testes de unidades para possíveis correções de 
falhas no software. Os testes de unidades são criados na codificação com a característica de poderem 
ser repetidos de forma fácil. Quando um erro é encontrado, os testes são criados.
113
FUNDAMENTOS DE ENGENHARIA DE SOFTWARE
Questão 2. 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. O documento de 
requisitos de software pode ser usado nos contratos e licitações para o desenvolvimento de software, 
na escolha de fornecedores de componentes do sistema, no acompanhamento de mudanças e na 
especificação do software.
Algumas das atividades principais do processo da engenharia de requisitos do software/sistema são:
A) Estudo da viabilidade do sistema, verificação de condições de aplicação e análise.
B) Especificação, modelagem e validação.
C) Estudo da viabilidade do sistema, elicitação e permissão.
D) Especificação, modelagem e verificação de condições de aplicação.
E) Modelagem, análise e permissão.
Resposta correta: alternativa B.
Análise da questão
As principais atividades do processo da engenharia de requisitos do software/sistema são: estudo da 
viabilidade do sistema, elicitação, análise, especificação, modelagem e validação.
As atividades do processo da engenharia de requisitos do software/sistema podem ser decompostas 
em quatro níveis distintos de serviços, conforme segue.
Nível 1. Estudo da viabilidade do sistema.
Esse estudo é de grande importância, pois garante que as necessidades do cliente estão de acordo 
com os interesses organizacionais e que os recursos necessários estão disponíveis para o desenvolvimento 
ou a integração do novo software/sistema.
Nível 2. Elicitação e análise de requisitos.
Nessa fase, são feitas várias reuniões entre cliente e desenvolvedor, com o objetivo de extrair com 
detalhes o conhecimento do negócio ao qual se destina o software/sistema.
Nível 3. Especificação, modelagem e documentação dos requisitos.
Após a interpretação e o entendimento dos detalhes do negócio, inicia-se a preparação do documento 
de requisitos, que deve ser composto pelos vários requisitos discutidos em reunião. Nessa fase, que deve 
ser feita pelo desenvolvedor com acompanhamento do cliente, são descritos textos breves sobre cada 
requisito, acompanhados, sempre que necessário, de um modelo visual.
114
Unidade III
Nível 4. Validação de requisitos.
A validação é a apresentação do 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 o desenvolvimento do software/sistema.
A verificação de condições de aplicação e a permissão não são atividades previstas na engenharia de 
requisitos. Isso significa que as alternativas que as contêm não podem ser consideradas corretas. Assim, 
a alternativa correta é a B.