Engenharia de Requisitos

Objetivos

n Descrever as principais atividades da

engenharia de requisitos
n Introduzir técnicas para a elicitação
e análise de requisitos
n Descrever validação de requisitos
n Discutir o gerenciamento de
requisitos
 O Processo da Engenharia de
Requisitos
Estudo de Elicitação de
viabilidade requisitos e
análise
Especificação
de requisitos
Validação
Relatório de de requisitos
viabilidade

Requisitos do
usuário e do
sistema

Modelos do Documento de
sistema requisitos
Elicitação de requisitos e
análise
n Esta atividade divide-se em dois
esforços maiores:
n Elicitação dos requisitos em si
n Técnicas de elicitação
n Análise do que foi elicitado
n Processo de análise
Que é um requisito?

n Tanto pode ser

n Uma declaração abstrata de alto nível de
um serviço
n Como uma restrição do sistema
n Quanto uma especificação funcional
matemática detalhada
Elicitação de Requisitos

n Também denominada de descoberta de

requisitos
n Envolve pessoal objetivando descobrir o
domínio de aplicação, serviços que devem
ser fornecidos bem como restrições
n Deve envolver usuários finais, gerentes,
pessoal envolvido na manutenção,
especialistas no domínio, etc.
(Stakeholders).
Visão dos Requisitos

n Requisitos do Usuário
n Declarações em linguagem natural com
diagramas de serviços que o sistema deve
oferecer e suas restrições operacionais.
Escrito para os clientes
n Requisitos do Sistema
n Documento estruturado com descrições
detalhadas sobre os serviços do sistema.
Contrato entre cliente e fornecedor
Tipos de Requisitos

n Requisitos Funcionais

n Requisitos Não-Funcionais

n Requisitos de Domínio
Requisitos Funcionais

n Descreve funcionalidade e serviços do

sistema
n Depende do
n Tipo do software
n Usuários esperados
n Tipo do sistema onde o software é usado
Exemplos de R.F.

n [RF001] Usuário pode pesquisar todo ou um

sub-conjunto do banco de dados
n [RF002] Sistema deve oferecer
visualizadores apropriados para o usuário
ler documentos armazenados
n [RF003] A todo pedido deve ser associado
um identificador único (PID), o qual o
usuário pode copiar para a área de
armazenamento permanente da conta
Requisitos Não-Funcionais

n Definem propriedades e restrições do

sistema (tempo, espaço, etc)
n Requisitos de processo também podem
especificar o uso de determinadas
linguagens de programação, método de
desenvolvimento
n Requisitos não-funcionais podem ser mais
críticos que requisitos funcionais. Não
satisfaz, sistema inútil.
Requisitos Não-Funcionais

n Devido à sua própria definição,

requisitos não-funcionais são
esperados mensuráveis
n Assim, deve-se associar forma de
medida/referência a cada requisito
não-funcional elicitado
 Medidas de Requisitos
(Não-Funcionais)
Propriedade Medida
Velocidade Transações processadas/seg
Tempo de resposta do usuário/evento
Tamanho K bytes
No de chips de RAM
Facilidade de uso Tempo de treinamento
No de quadros de ajuda
Confiabilidade Tempo médio de falhas
Probabilidade de indisponibilidade
Taxa de ocorrência de falhas
Robustez Tempo de reinício após falha
Percentual de eventos causando falhas
Probabilidade de corrupção de dados após falha
Portabilidade Percentual de declarações dependentes do destino
No de sistemas destino
Classificação de R. N. F.
n Requisitos do Produto
n Produto deve comportar-se de forma particular
(velocidade de execução, confiabilidade, etc.)
n Requisitos Organizacionais
n Conseqüência de políticas e procedimentos
organizacionais (padrões de processo usados,
requisitos de implementação, etc.)
n Requisitos Externos
n Conseqüência de fatores externos ao sistema e
ao processo de desenvolvimento (legislação,
etc.)
Exemplos de R. N. F.

n Requisitos do Produto
n [RNF001] Toda consulta ao B.D., baseada em
código de barras, deve resultar em até 5 s
n Requisitos Organizacionais
n [RNF002] Todos os documentos entregues
devem seguir o padrão de relatórios XYZ-00
n Requisitos Externos
n [RNF003] Informações pessoais do usuário não
devem ser vistas pelos operadores do sistema
Requisitos de Domínio

n Derivados do domínio da aplicação e

descrevem características do sistema e
qualidades que refletem o domínio
n Podem ser requisitos funcionais novos,
restrições sobre requisitos existentes ou
computações específicas
n Se requisitos de domínio não forem
satisfeitos, o sistema pode tornar-se
impraticável
Requisitos de Domínio
(Problemas)
n Entendimento
n Requisitos são descritos na linguagem do
domínio da aplicação
n Não é entendido pelos engenheiros de
software que vão desenvolver a aplicação
n Implicitude
n Especialistas no domínio entendem a área
tão bem que não tornam todos os
requisitos de domínio explícitos
 Requisitos
Requisitos

Usuário  Sistema

Funcionais Não-funcionais Domínio

Produto Organização Externo

Técnicas de Elicitação

n Entrevistas
n Questionários
n Casos de Uso
n Jogo de Funções
n Brainstorming
n Workshop de Requisitos
 Análise de Requisitos
Definição e
Documento
especificação
de requisitos
de requisitos
7 8

Validação
dos requisitos
Entendimento 6
Atrib. Prioridade
Entrada do do domínio
1
processo 5

2 4
Coleta de Resolução
requisitos de conflito
3

Classificação
Entendimento do Domínio

n Desenvolver sistemas envolve

domínios além de software e
hardware
n Podemos ter que entender sobre
n Contabilidade
n Saúde
n Supermercados
n Etc.
Coleta de Requisitos

n Como vimos anteriormente, a coleta

de requisitos é feita através de
técnicas
n Nesta etapa, os requisitos são
simplesmente documentados à medida
que são coletados
n Resulta em documento preliminar
(draft)
Classificação dos Requisitos

n Esta etapa consiste basicamente em

agrupar os diversos requisitos
coletados em categorias (clusters)
bem-definidos
n Por exemplo
n Deve ser possível consultar o preço de
uma mercadoria
n A consulta deve retornar uma resposta em no
máximo 5s
Problema da Análise de
Requisitos
n Stakeholders em geral não sabem o
que querem
n Stakeholders expressam requisitos
em sua terminologia
n Stakeholders diferentes podem gerar
requisitos conflitantes
Problema da Análise de
Requisitos
n Fatores políticos e organizacionais
podem influenciar os requisitos do
sistema
n Requisitos mudam durante o processo
de análise. Stakeholders novos podem
surgir e o ambiente de trabalho
mudar
Resolução de Conflitos

n É normal que ocorram requisitos

conflitantes
n Por exemplo
n R-23: O sistema deve ...
n R-45: O sistema não deve ...
n Cliente/usuário deve ser consultado
para resolver conflitos
(ambigüidades)
Atribuição de Prioridade

n Alguns requisitos são mais urgentes

que outros
n É essencial determinar a prioridade
dos requisitos junto ao cliente
n Requisitos de maior prioridade são
considerados em primeiro lugar
Prioridade

n Requisitos podem ser vistos em três

classes distintas
n Essenciais
n Importantes
n Desejáveis
n Em princípio, sistema deve resolver
todos os requisitos de essenciais para
desejáveis
Exemplo de Prioridade
n [RF001] Consulta X ao B.D. deve retornar
dados A, B, C
n Prioridade: Essencial
n [RNF001] Consulta X ao B.D. deve visualizar
dados segundo padrão Y
n Prioridade: Importante
n [RNF010] Consulta X ao B.D. deve usar
cores azuis nos resultados
n Prioridade: Desejável
Validação dos Requisitos

n Será que realmente entendi o que o

cliente deseja?
n Devo me certificar de que não houve
falha em nossa interação
(comunicação)
n Há diversas técnicas de validação
Validação de Requisitos

n Demonstrar que os requisitos definem

o sistema que o cliente realmente
deseja
n Custos com erros de requisitos são
altos
n Consertar um erro de requisitos após
entrega do sistema pode custar mais de
100 vezes o custo de um erro de
implementação
Técnicas de Validação de
Requisitos
n Revisões de Requisitos
n Análise manual sistemática dos requisitos
n Prototipação
n Uso de modelo executável do sistema para
avaliar requisitos
n Geração de Casos de Teste
n Desenvolver testes específicos para os
requisitos para avaliá-los
n Análise de Consistência Automática
n Avaliar uma especificação dos requisitos
Gerenciamento de Requisitos

n Gerenciamento de requisitos é o
processo de controlar as mudanças
dos requisitos durante
n O processo da engenharia de requisitos
n E desenvolvimento do sistema
Gerenciamento de Requisitos

n Requisitos são inevitavelmente incompletos

e inconsistentes
n Requisitos novos surgem durante o processo de
acordo com mudanças nas necessidades do
negócio e um entendimento melhor do sistema é
desenvolvido
n Diferentes pontos de vista têm diferentes
requisitos e esses geralmente são
contraditórios
Rastreamento

n Responsável por dependências entre

requisitos, suas origens e projeto do
sistema
n Rastreamento de Origem
n Associação entre requisitos e
stakeholders que propuseram tais
requisitos
Rastreamento

n Rastreamento de Requisitos
n Associação entre requisitos dependentes
n Rastreamento de Projeto
n Associação dos requisitos com o projeto
n Usar hipertexto ou referência
cruzada
n Ou matriz de rastreamento
 Rastreamento
1.Rastrear requisitos do
Requisitos usuário nos do sistema
Req A
Produto
(Características)
2.Rastrear requisitos no
projeto
1 3.Rastrear requisitos
nos procedimentos de
Requisitos
Detalhados Req B teste
(Casos de Uso) 4.Rastrear requisitos do
2 3 4 usuário no plano

Projeto Teste Doc. Usuário

Modelos Suítes Teste Plano

 Rastreamento: Análise de
Impacto
Req A antes Req A depois
“if return value > $5” “if return value > $2”

Req B Req B

Req C Req C

n Links dos requisitos devem ser marcados como

“revisar”
n Links “revisar” devem ser analisados
Documento de Requisitos
n Fonte: IEEE/ANSI (830-1998)
n 1. Introdução
1.1 Propósito do documento
n

n 1.2 Escopo do sistema

n1.3 Definições, acrônimos(Palavra formada pelas letras ou

sílabas iniciais de várias outras palavras, e que se pronuncia sílaba a sílaba e não letra a
letra (SIDA, laser, etc.). É a junção de palavras formando uma nova, diferente de sigla que

é a junção da primeira letra de cada palavra. ) e abreviaturas

n 1.4 Referências
n 1.5 Descrição do resto do documento
Documento de Requisitos

n Fonte: IEEE/ANSI (830-1998)

n 2. Descrição geral
n 2.1 Perspectiva do produto
n 2.2 Funções do produto
n 2.3 Características dos usuários
n 2.4 Restrições gerais
n 2.5 Assertivas e dependências
Documento de Requisitos

n Fonte: IEEE/ANSI (830-1998)

n 3. Requisitos específicos
n requisitos funcionais, não-funcionais,
GUI com o usuário:
n funcionalidade, interfaces externas,

desempenho, restrições, atributos do

sistema, caract. qualidade, ...
n Apêndices
n Índice