1
Engenharia de Requisitos
Alexandre Monteiro
Objetivos
Descrever as principais atividades da engenharia de requisitos
Introduzir técnicas para a elicitação e análise de requisitos
Descrever validação de requisitos
Discutir o gerenciamento de
requisitos
O Processo da Engenharia de Requisitos
Estudo de viabilidade
Relatório de viabilidade
Elicitação de requisitos e
análise
Modelos do sistema
Especificação de requisitos
Validação de requisitos
Requisitos do usuário e do
sistema
Documento de requisitos
Elicitação de requisitos e análise
Esta atividade divide-se em dois esforços maiores:
Elicitação dos requisitos em si
Técnicas de elicitação
Análise do que foi elicitado
Processo de análise
Que é um requisito?
Tanto pode ser
Uma declaração abstrata de alto nível de um serviço
Como uma restrição do sistema
Quanto uma especificação funcional
matemática detalhada
Elicitação de Requisitos
Também denominada de descoberta de requisitos
Envolve pessoal objetivando descobrir o domínio de aplicação, serviços que devem ser fornecidos bem como restrições
Deve envolver usuários finais, gerentes, pessoal envolvido na manutenção,
especialistas no domínio, etc.
Visão dos Requisitos
Requisitos do Usuário
Declarações em linguagem natural com
diagramas de serviços que o sistema deve oferecer e suas restrições operacionais.
Escrito para os clientes
Requisitos do Sistema
Documento estruturado com descrições detalhadas sobre os serviços do sistema.
Contrato entre cliente e fornecedor
Tipos de Requisitos
Requisitos Funcionais
Requisitos Não-Funcionais
Requisitos de Domínio
Requisitos Funcionais
Descreve funcionalidade e serviços do sistema
Depende do
Tipo do software
Usuários esperados
Tipo do sistema onde o software é usado
Exemplos de R.F.
[RF001] Usuário pode pesquisar todo ou um sub-conjunto do banco de dados
[RF002] Sistema deve oferecer
visualizadores apropriados para o usuário ler documentos armazenados
[RF003] A todo pedido deve ser associado um identificador único (PID), o qual o
usuário pode copiar para a área de
Requisitos Não-Funcionais
Definem propriedades e restrições do sistema (tempo, espaço, etc)
Requisitos de processo também podem especificar o uso de determinadas
linguagens de programação, método de desenvolvimento
Requisitos não-funcionais podem ser mais críticos que requisitos funcionais. Não
satisfaz, sistema inútil.
Requisitos Não-Funcionais
Devido à sua própria definição, requisitos não-funcionais são esperados mensuráveis
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.
Requisitos do Produto
Produto deve comportar-se de forma particular (velocidade de execução, confiabilidade, etc.)
Requisitos Organizacionais
Conseqüência de políticas e procedimentos organizacionais (padrões de processo usados, requisitos de implementação, etc.)
Requisitos Externos
Conseqüência de fatores externos ao sistema e ao processo de desenvolvimento (legislação,
Exemplos de R. N. F.
Requisitos do Produto
[RNF001] Toda consulta ao B.D., baseada em código de barras, deve resultar em até 5 s
Requisitos Organizacionais
[RNF002] Todos os documentos entregues devem seguir o padrão de relatórios XYZ-00
Requisitos Externos
[RNF003] Informações pessoais do usuário não devem ser vistas pelos operadores do sistema
Requisitos de Domínio
Derivados do domínio da aplicação e
descrevem características do sistema e qualidades que refletem o domínio
Podem ser requisitos funcionais novos,
restrições sobre requisitos existentes ou computações específicas
Se requisitos de domínio não forem
satisfeitos, o sistema pode tornar-se não
Requisitos de Domínio (Problemas)
Entendimento
Requisitos são descritos na linguagem do domínio da aplicação
Não é entendido pelos engenheiros de software que vão desenvolver a aplicação
Implicitude
Especialistas no domínio entendem a área tão bem que não tornam todos os
requisitos de domínio explícitos
Requisitos de Domínio (Exemplo 1)
A desaceleração do trem deve ser computada através da fórmula
D
trem=D
controle+D
gradienteonde ...
Requisitos
Requisitos
Não-funcionais
Organização
Funcionais Domínio
Produto Externo
Sistema Usuário =df
Técnicas de Elicitação
Entrevistas
Questionários
Casos de Uso
Jogo de Funções
Brainstorming
Workshop de Requisitos
Análise de Requisitos
Entendimento do domínio
Coleta de requisitos
Classificação Definição e
especificação de requisitos
Resolução de conflito Atrib. Prioridade Validação
dos requisitos
Entrada do processo
Documento de requisitos
1
2
3
4 5 6
7 8
Entendimento do Domínio
Desenvolver sistemas envolve domínios além de software e hardware
Podemos ter que entender sobre
Contabilidade
Saúde
Supermercados
Etc.
Coleta de Requisitos
Como vimos anteriormente, a coleta de requisitos é feita através de técnicas
Nesta etapa, os requisitos são
simplesmente documentados à medida que são coletados
Resulta em documento preliminar
(draft)
Classificação dos Requisitos
Esta etapa consiste basicamente em
agrupar os diversos requisitos coletados em categorias (clusters) bem-definidos
Por exemplo
Deve ser possível consultar o preço de uma mercadoria
A consulta deve retornar uma resposta em no máximo 5s
Problema da Análise de Requisitos
Stakeholders em geral não sabem o que querem
Stakeholders expressam requisitos em sua terminologia
Stakeholders diferentes podem gerar
requisitos conflitantes
Problema da Análise de Requisitos
Fatores políticos e organizacionais podem influenciar os requisitos do sistema
Requisitos mudam durante o processo
de análise. Stakeholders novos podem
surgir e o ambiente de trabalho muda
Resolução de Conflitos
É normal que ocorram requisitos conflitantes
Por exemplo
R-23: O sistema deve ...
R-45: O sistema não deve ...
Cliente/usuário deve ser consultado para resolver conflitos
(ambigüidades)
Atribuição de Prioridade
Alguns requisitos são mais urgentes que outros
É essencial determinar a prioridade dos requisitos junto ao cliente
Requisitos de maior prioridade são
considerados em primeiro lugar
Prioridade
Requisitos podem ser vistos em três classes distintas
Essenciais
Importantes
Desejáveis
Em princípio, sistema deve resolver
todos os requisitos de essenciais para
desejáveis
Exemplo de Prioridade
[RF001] Consulta X ao B.D. deve retornar dados A, B, C
Prioridade: Essencial
[RNF001] Consulta X ao B.D. deve visualizar dados segundo padrão Y
Prioridade: Importante
[RNF010] Consulta X ao B.D. deve usar cores azuis nos resultados
Prioridade: Desejável
Validação dos Requisitos
Será que realmente entendi o que o cliente deseja?
Devo me certificar de que não houve falha em nossa interação
(comunicação)
Há diversas técnicas de validação
Validação de Requisitos
Demonstrar que os requisitos definem o sistema que o cliente realmente deseja
Custos com erros de requisitos são altos
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
Revisões de Requisitos
Análise manual sistemática dos requisitos
Prototipação
Uso de modelo executável do sistema para avaliar requisitos
Geração de Casos de Teste
Desenvolver testes específicos para os requisitos para avaliá-los
Análise de Consistência Automática
Avaliar uma especificação dos requisitos
Gerenciamento de Requisitos
Gerenciamento de requisitos é o
processo de controlar as mudanças dos requisitos durante
O processo da engenharia de requisitos
E desenvolvimento do sistema
Gerenciamento de Requisitos
Requisitos são inevitavelmente incompletos e inconsistentes
Requisitos novos surgem durante o processo de acordo com mudanças nas necessidades do
negócio e um entendimento melhor do sistema é desenvolvido
Diferentes pontos de vista têm diferentes requisitos e esses geralmente são
contraditórios
Rastreamento
Responsável por dependências entre requisitos, suas origens e projeto do sistema
Rastreamento de Origem
Associação entre requisitos e
stakeholders que propuseram tais requisitos
Rastreamento
Rastreamento de Requisitos
Associação entre requisitos dependentes
Rastreamento de Projeto
Associação dos requisitos com o projeto
Usar hipertexto ou referência cruzada
Ou matriz de rastreamento
1.Rastrear requisitos do usuário nos do sistema
2.Rastrear requisitos no projeto
3.Rastrear requisitos nos procedimentos de teste
4.Rastrear requisitos do usuário no plano
2 3
Req A 1
Requisitos Produto (Caracter.)
Requisitos Detalhados (Casos de Uso)
Req B 4
Rastreamento
Links dos requisitos devem ser marcados como
“revisar”
Links “revisar” devem ser analisados Req A antes
“if return value > $5”
Req B
Req C
“if return value > $2”
Req A depois
Req C Req B
Rastreamento: Análise de
Impacto
Documento de Requisitos
Fonte: IEEE/ANSI (830-1998)
1. Introdução
1.1 Propósito do documento
1.2 Escopo do sistema
1.3 Definições, acrônimos e abreviaturas
1.4 Referências
1.5 Descrição do resto do documento
Documento de Requisitos
Fonte: IEEE/ANSI (830-1998)
2. Descrição geral
2.1 Perspectiva do produto
2.2 Funções do produto
2.3 Características dos usuários
2.4 Restrições gerais
2.5 Assertivas e dependências
Documento de Requisitos
Fonte: IEEE/ANSI (830-1998)
3. Requisitos específicos
requisitos funcionais, não-funcionais, GUI com o usuário:
funcionalidade, interfaces externas, desempenho, restrições, atributos do sistema, caract. qualidade, ...
Apêndices
Objetivos
Introduzir conceitos de use case , ator e fluxo de eventos
Apresentar sub-fluxos de eventos
Discutir sobre identificação, evolução e organização de use cases
Apresentar notação UML para reusar
atores e use cases
Use Case
Seqüência de
ações, executada pelo sistema, que gera um resultado
De valor observável
E para ator particular Função
Procedimento computacional/algorítmico atômico
Use Case e Ator
Alguém ou alguma coisa (fora do
sistema) que interage com o sistema
Emissor/Receptor
Use Case e Ator
A descrição de um use case define o que o sistema faz quando o use case é realizado
A funcionalidade do sistema é
definida por um conjunto de use
cases , cada um representando um
fluxo de eventos específico
Use Case e Ator
Emissor
Passo 1 Passo 2
…
Passo N Descrição
Exemplo de Use Case e Ator
Cliente de banco pode usar um caixa automático para
sacar dinheiro, transferir dinheiro ou consultar o saldo da conta
Ator: Cliente
Use cases : Sacar dinheiro, transferir
dinheiro e consultar saldo
Exemplo de Use Case e Ator
Transferir dinheiro
Sacar Consultar
Valor de resultado observável
Identificando Use Cases
Em geral, difícil decidir entre um ou vários use cases
Por exemplo, seriam use cases
Inserir cartão em um Caixa Automático?
Entrar com a senha?
Receber o cartão de volta?
Identificando Use Cases
Representar valor observável para ator
Pode-se determinar
De interações (seqüência de ações) com o sistema que resultam valores para atores
Satisfaz um objetivo particular de um ator que o sistema deve prover
Reuso em Use Cases
Comportamento comum a mais de dois use cases (ou forma parte
independente)
Pode-se modelar como use case para ser reusado
Há três possibilidades
Inclusão
Extensão
Generalização/Especialização
Inclusão
Vários use cases possuem texto de fluxo de eventos
Comum/idêntico
Sempre usado
Equivalente a fatoração feita em programação através de sub-
programas
Inclusão
Como exemplo, tanto “Sacar dinheiro”
quanto “Consultar saldo” necessitam da senha
Pode-se criar novo use case “Autenticar usuário” e incluí-lo
Mas atenção
NÃO SE DEVE CRIAR USE CASES MÍNIMOS
Deve haver ganho no reuso
Inclusão
Sacar Consultar
Autenticar usuário
<< include >> << include >>
Inclusão
Descrição de Consultar saldo
Fluxo de Eventos Principal:
include (Autenticar usuário). Sistema pede a Cliente que selecione tipo de conta (corrente, etc). ...
Extensão
Use case pode ser estendido por outro
Extensão de funcionalidade/Caso excepcional
Extensão ocorre em pontos específicos
Pontos de extensão
Extensão
Há também inclusão de texto (fluxo de eventos)
Porém sob condições particulares
Pode ser usada para
Simplificar fluxos de eventos complexos
Representar comportamentos opcionais
Lidar com exceções
Extensão
Atendimento
Pontos de extensão urgente
Atendimento de urgência
<< extend >>
(urgente)
Extensão
Descrição de Atendimento
Fluxo de Eventos Principal:
Colete os itens do pedido. (urgente).
Submeta pedido para processamento.
Especialização
U se case pode especializar outro
Adição/refinamento do fluxo de eventos original
Especialização permite modelar
comportamento de estruturas de
aplicação em comum
101
Especialização
Atendimento Atendimento
de urgência
Cliente Cliente
comercial
Fluxo de Eventos
Parte mais importante de um use case
Atividade de requisitos
Define a seqüência de ações entre o
ator e o sistema
Fluxo de Eventos
Geralmente em linguagem natural
Uso preciso de termos definidos no glossário de acordo com o domínio do problema
Também expresso formalmente
Pré e pós-condições (ou pseudo-código)
Exemplo de Fluxo de Eventos
Um esboço inicial sobre Sacar dinheiro seria
1. O use case inicia quando o Cliente
insere um cartão no CA. Sistema lê e valida informação do cartão
2. Sistema pede a senha. Cliente entra com a senha. Sistema valida a senha.
3. Sistema pede seleção do serviço.
Cliente escolhe “Sacar dinheiro”
Exemplo de Fluxo de Eventos
Um esboço inicial sobre Sacar dinheiro seria
4. Sistema pede a quantia a sacar. Cliente informa.
5. Sistema pede seleção da conta (corrente, etc). Cliente informa.
6. Sistema comunica com a rede para
validar a conta, senha e o valor a sacar.
Exemplo de Fluxo de Eventos
Um esboço inicial sobre Sacar dinheiro seria
7. Sistema pede remoção do cartão.
Cliente remove.
8. Sistema entrega quantia solicitada.
Fluxo de Eventos
Na descrição do que o sistema faz através de fluxos de eventos
completos
Surgem caminhos alternativos
Casos diferentes a considerar
Efeitos/valores diferentes a produzir
Eventualmente descreve todos esses
caminhos possíveis
Sub-fluxos de Eventos
Fluxo de eventos visto como
Vários sub-fluxos de eventos
Sub-fluxos são descritos como
Principal
Alternativos/excepcionais
Abordagem visa reuso de fluxos de
eventos (sub-fluxos)
Exemplo de Sub-fluxos
Seja o use case Validar usuário
Fluxo principal:
O use case inicia quando o sistema pede ao Cliente a senha. Cliente entra com senha. Sistema verifica se a senha é válida. Se a senha é válida, sistema confirma e termina o use case.
Fluxo excepcional:
Cliente pode cancelar a transação a qualquer momento pressionando a tecla ESC, reiniciando o use case.
Nenhuma modificação é feita na conta do Cliente.
Fluxo excepcional:
Se Cliente entra com senha inválida, o use case reinicia.
Diagrama de Atividades
Descreve fluxo de tarefas
Aspectos dinâmicos de um sistema
Podem também ser usados para criar sistemas executáveis
Depende do nível de detalhamento e grau de execução dos elementos usados
Alternativa para modelar fluxos de
eventos de casos de uso
Elementos de um Diag. Ativ.
Diagramas de Use Cases
Caracterizar limites da funcionalidade do sistema
Use cases são organizados dentro de um diagrama
Em diagramas de use cases
Atores são relacionados por generalização/especialização
Exemplo de Diagrama
Transação de cartão
Cliente corporativo
Cliente individual
Cliente Instituição
vendedora
Financeira
Sistema de validação de cartão de crédito
Processa fatura
Reconcilia transações
Gerencia conta
Bibliografia
Sommerville, I. Software Engineering
Kruchten, P. The Rational Unified Process: An Introduction. 2nd Ed
