Engenharia de Requisitos

Adriana Carniello
 Objetivos
• Identificar as atividades básicas da Engenharia
de Requisitos
• Identificar as abordagens para análise de
problemas
• Pesquisar abordagens para a construção de
requisitos de software
• Medir a qualidade dos requisitos de software
 Requisito de Software
• É a descrição dos principais recursos de um
produto de software, seu fluxo de informações,
seu comportamento e atributos

• O grau de compreensibilidade, precisão e rigor da

descrição fornecida por um documento de
requisitos de software tende a ser diretamente
proporcional ao grau de qualidade do produto
resultante
 Foco Principal da Engenharia de
Requisitos

• Definir e descrever o que um sistema de

software deve fazer para satisfazer aos
requisitos informais fornecidos por um relatório
de necessidades

• O pensamento na análise de requisitos deve

voltar-se principalmente aos problemas, não às
soluções
Principais Resultados da Análise de
Requisitos
• Funcional (ações principais): uma descrição
funcional identifica as atividades do sistema
• Comportamental (atividades de controle): uma
descrição comportamental descreve a
seqüência e a possível sobreposição das
funções do sistema
• Não-comportamental (atributos): uma
descrição não-comportamental do software
inclui planejamento de engenharia humana e de
garantia de qualidade
Principais Produtos de um Processo de
Requisitos Satisfatório
• Especificação de requisitos de software (ERS)
completa: uma descrição de um sistema (suas funções,
seu comportamento, seu desempenho, suas interfaces
interna e externa e seus atributos de qualidade)
• Plano de garantia de qualidade: uma indicação da
portabilidade, eficiência, confiabilidade, critérios de
validação e verificação, custos e critérios de aceitação
a serem seguidos pelas equipes de projeto
 Análise de Problemas
• Especificação de requisitos: é altamente
abstrata e, por isso, uma parte difícil do
processo de software

• Engenharia de Requisitos começa com a

Análise de Problemas (também conhecida
como Análise de Requisitos)
 Análise de Problemas
• Resulta na identificação:
– do ambiente (pessoas afetadas por um produto de
software, máquinas utilizadas ou afetadas pelo
software, serviços necessários e outros itens afetados
pelas operações do software)
– dos itens produzidos (itens processados, itens
consumidos e itens produzidos)
– das principais funções executadas pelas pessoas e
máquinas para produzir um produto desejado
– dos métodos necessários e do cronograma de
operações
 Análise de Problemas
• Análise de Problemas  ponto de partida para o
desenvolvimento das especificações de requisitos
de software

• Principal objetivo da especificação de requisitos de

software:
– Descrever os objetos, as funções e os estados
relacionados a um problema
 Especificação de Requisitos de
Software (ERS)
• A ERS emerge dos componentes da Análise de
Problemas

• Os primeiros esboços das seções de uma ERS

geralmente são escritos durante o processo de
decomposição resultante da análise de
problemas
 Especificação de Requisitos de
Software (ERS)
• Ao escrever uma ERS, o engenheiro de
requisitos lida com 05 questões básicas:
– Funcionalidade: o que o software deve fazer
– Interfaces externas: interação do software com
o usuário(s), com hardware do sistema, outros
softwares
 Especificação de Requisitos de
Software (ERS)

– Desempenho: velocidade, disponibilidade,

tempo de resposta
– Atributos: portabilidade, rastreabilidade,
manutenibilidade, estabilidade, segurança, etc.
– Restrições: padrões de qualidade, linguagem de
codificação, limites de recursos, orçamento,
etc.
 Partes de uma ERS
(derivado do padrão IEEE 830-1993)

Índice Analítico
1.Introdução
2.Descrição Global
3.Requisitos Específicos
4.Rastreabilidade dos Requisitos (baseado no padrão de
ERS do DoD)

5.Apêndices
6.Índice Remissivo
 Partes de uma ERS - Introdução

1. Introdução
1.1 Objetivo
1.2 Escopo
1.3 Definições, acrônimos e abreviações
1.4 Referências
1.5 Visão Geral
 Partes de uma ERS - Introdução
• O objetivo e o escopo devem estar vinculados ao
relatório de necessidades do processo de pré-
desenvolvimento e fornecerão refinamentos derivados
da análise de problemas

• 1.1 Objetivo  especifica as intenções e o público-alvo

da ERS
• 1.2 Escopo  identifica (determina) os produtos de
software a serem produzidos. São também descritos
nesta seção as capacidades, aplicações, benefícios
relevantes
 Partes de uma ERS - Introdução
• 1.3 Definições, acrônimos e abreviações
– Definições de termos utilizados
– Acrônimos
• Por exemplo: CEM – Controlador de Estruturas Metálicas
– Abreviações
• Por exemplo: pág. para página
– Símbolos
• Por exemplo: a constante Euler e = 2,718 ou exp(x) = ex
devem ser explicadas de forma que a ERS possas ser
interpretada
• Essas informações podem ser incluídas em um glossário,
uma tabela de símbolos ou um um apêndice
 Partes de uma ERS - Introdução

• 1.4 Referências
– Lista completa de todos os documentos referenciados na ERS

• 1.5 Visão Geral

– Fornece um mapa da ERS, descrevendo como a ERS está
organizada e um breve conteúdo do restante da ERS
 Partes de uma ERS
(derivado do padrão IEEE 830-1993)

Índice Analítico
1.Introdução
2.Descrição Global
3.Requisitos Específicos
4.Rastreabilidade dos Requisitos (baseado no padrão de
ERS do DoD)

5.Apêndices
6.Índice Remissivo
Partes de uma ERS – Descrição Global
• A seção Descrição Global indica os fatores gerais que
influenciam os produtos (resultado de um processo de
software) e seus requisitos

2. Descrição global
2.1 Perspectiva do produto
2.2 Funções do produto
2.3 Características do usuário
2.4 Restrições
2.5 Hipóteses e dependências
Partes de uma ERS – Descrição Global
• 2.1 Perspectiva do produto
– Informa se o produto é independente ou se faz parte
de um sistema maior. No caso de o produto fazer
parte de um sistema maior, esta seção descreve como
o produto está relacionado ao sistema maior: descreve
a funcionalidade e as interfaces com o sistema maior

• 2.2 Funções do produto

– Descreve as principais funções que serão
desempenhadas pelo software
Partes de uma ERS – Descrição Global
• 2.3 Características do usuário
– Indica a quais tipos de usuários o produto se destina e
o nível de escolaridade, a experiência e o
conhecimento técnico necessários dos usuários

• 2.4 Restrições
– Descrições gerais de quaisquer itens que limitarão as
opções do desenvolvedor ao produzir o software.
– Por exemplo: políticas regulamentares, limitações de
hardware (por exemplo, produto executa somente em
um tipo de processador), requisitos de linguagem de
alto nível (por exemplo, deve ser utilizado C++)
Partes de uma ERS – Descrição Global
• 2.5 Hipóteses, dependência
– Fatores (por exemplo, alterações) que podem afetar a
própria ERS e hipóteses sobre o software
– Por exemplo, indicar quais Diagramas de Fluxo de
Dados são afetados pela mudança das funções
existentes ou pela adição ou exclusão de funções
– As hipóteses também podem abordar os riscos (de
custos, pontos fracos) se determinados requisitos
forem adiados para versões futuras do sistema
– Dependências também devem ser consideradas. Por
exemplo, o produto requer Windows ou Mac OS
Partes de uma ERS – Descrição Global
• 2.6 Distribuição de requisitos
– Identifica os requisitos que serão adiados para
versões futuras do sistema, se houverem
 Referência Bibliográfica

• Engenharia de Software – Teoria e Prática

James F. Peters e Witold Pedrycz
Editora Campus