Transcript USE CASE - Prof. Msc. Marcela Santos

ENGENHARIA DE REQUISITOS
MARCELA SANTOS
1
Apresentação baseada no material do professor
Alexandre Vasconcelos
([email protected])
“Todos os projetos são
viáveis,
desde que tenham
ilimitados recursos e
tempo infinito!”
2
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

3
O PROCESSO DA ENGENHARIA DE
REQUISITOS
Estudo de
viabilidade
Elicitação de
requisitos e
análise
Especificação
de requisitos
Relatório de
viabilidade
Validação
de requisitos
Requisitos do
usuário e do
sistema
Modelos do
sistema
Documento de
4
requisitos
O PROCESSO DA ENGENHARIA DE
REQUISITOS
Estudo de
viabilidade
Elicitação de
requisitos e
análise
Especificação
de requisitos
Relatório de
viabilidade
Validação
de requisitos
Requisitos do
usuário e do
sistema
Modelos do
sistema
Documento de
23
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
24
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
25
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.
(Stakeholders).
26
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
27
TIPOS DE REQUISITOS

Requisitos Funcionais

Requisitos Não-Funcionais

Requisitos de Domínio
28
REQUISITOS FUNCIONAIS
Descreve funcionalidade e serviços do sistema
 Depende do

Tipo do software
 Usuários esperados
 Tipo do sistema onde o software é usado

29
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
armazenamento permanente da conta
30
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.
32
REQUISITOS NÃO-FUNCIONAIS
Devido à sua própria definição, requisitos nãofuncionais são esperados mensuráveis
 Assim, deve-se associar forma de
medida/referência a cada requisito não-funcional
elicitado

33
MEDIDAS DE REQUISITOS
(NÃO-FUNCIONAIS)
Propriedade
Velocidade
Tamanho
Facilidade de uso
Confiabilidade
Robustez
Portabilidade
Medida
Transações processadas/seg
Tempo de resposta do usuário/evento
K bytes
No de chips de RAM
Tempo de treinamento
No de quadros de ajuda
Tempo médio de falhas
Probabilidade de indisponibilidade
Taxa de ocorrência de falhas
Tempo de reinício após falha
Percentual de eventos causando falhas
Probabilidade de corrupção de dados após falha
34
Percentual de declarações dependentes do destino
No de sistemas destino
CLASSIFICAÇÃO DE R. N. F.
 Requisitos

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

do Produto
Externos
Conseqüência de fatores externos ao sistema e
ao processo de desenvolvimento (legislação,
etc.)
35
EXEMPLOS DE R. N. F.
 Requisitos

[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

do Produto
Externos
[RNF003] Informações pessoais do usuário não
devem ser vistas pelos operadores do sistema
36
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
impraticável
38
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
39
REQUISITOS
Requisitos
Usuário
Funcionais
Produto

Sistema
Não-funcionais
Organização
Domínio
Externo
42
TÉCNICAS DE ELICITAÇÃO
Entrevistas
 Questionários
 Casos de Uso
 Jogo de Funções
 Brainstorming
 Workshop de Requisitos

43
ANÁLISE DE REQUISITOS
Definição e
especificação
de requisitos
Documento
de requisitos
7
8
Validação
dos requisitos
Entrada do
processo
Entendimento
do domínio
Coleta de
requisitos
6
1
Atrib. Prioridade
5
4
2
3
Classificação
Resolução
de conflito
54
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.
55
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)

56
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
57
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

58
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 mudar

59
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)
60
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

61
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
62
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
63
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

64
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
65
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

Desenvolver testes específicos para os
requisitos para avaliá-los
 Análise

de Casos de Teste
de Consistência Automática
Avaliar uma especificação dos requisitos
66
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

67
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
68
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
69
RASTREAMENTO

Rastreamento de Requisitos


Rastreamento de Projeto


Associação entre requisitos dependentes
Associação dos requisitos com o projeto
Usar hipertexto ou referência cruzada

Ou matriz de rastreamento
70
RASTREAMENTO
1.Rastrear requisitos
Requisitos
Produto
(Características)
Req A
1
Requisitos
Detalhados
(Casos de Uso)
Req B
2
3
Projeto
Teste
Modelos
Suítes Teste
4
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
Doc. Usuário
Plano
71
RASTREAMENTO: ANÁLISE DE IMPACTO
Req A antes
Req A depois
“if return value > $5”
“if return value > $2”
Req B
Req C


Req B
Req C
Links dos requisitos devem ser marcados como
“revisar”
Links “revisar” devem ser analisados
72
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
73
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
74
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
 Índice

75
DIAGRAMAS DE CASOS DE USO
76
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

77
USE CASE
 Seqüência
de ações,
executada pelo
sistema, que gera
um resultado

Função

De valor observável
E para ator
particular
Procedimento computacional/algorítmico atômico
78
USE CASE E ATOR
 Alguém
ou alguma
coisa (fora do
sistema) que
interage com o
sistema
Emissor/Receptor
79
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

81
USE CASE E ATOR
Descrição
Passo 1
Passo 2
…
Passo N
Emissor
Função
82
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

83
EXEMPLO DE USE CASE E ATOR
Valor de
resultado
observável
Transferir
dinheiro
Sacar
dinheiro
Consultar
saldo 84
Cliente
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?
85
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

86
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

93
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

#include da linguagem C
94
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
95
INCLUSÃO
<< include >>
Sacar
dinheiro
Autenticar
usuário
<< include >>
Consultar
saldo
96
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). ...
97
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
98
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
99
EXTENSÃO
<< extend >>
(urgente)
Atendimento
de urgência
Atendimento
Pontos de extensão
urgente
100
EXTENSÃO

Descrição de Atendimento

Fluxo de Eventos Principal:

Colete os itens do pedido. (urgente). Submeta pedido para
processamento.
101
ESPECIALIZAÇÃO

Use case pode especializar outro


Adição/refinamento do fluxo de eventos original
Especialização permite modelar comportamento
de estruturas de aplicação em comum
102
ESPECIALIZAÇÃO

Atendimento
de urgência
Atendimento

Cliente
comercial
Cliente
103
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
104
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)
105
EXEMPLO DE FLUXO DE EVENTOS

Um esboço inicial sobre Sacar dinheiro seria
1.
2.
3.
O use case inicia quando o Cliente insere um
cartão no CA. Sistema lê e valida informação do
cartão
Sistema pede a senha. Cliente entra com a senha.
Sistema valida a senha.
Sistema pede seleção do serviço. Cliente escolhe
“Sacar dinheiro”
106
EXEMPLO DE FLUXO DE EVENTOS

Um esboço inicial sobre Sacar dinheiro seria
4.
5.
6.
Sistema pede a quantia a sacar. Cliente informa.
Sistema pede seleção da conta (corrente, etc).
Cliente informa.
Sistema comunica com a rede para validar a conta,
senha e o valor a sacar.
107
EXEMPLO DE FLUXO DE EVENTOS

Um esboço inicial sobre Sacar dinheiro seria
7.
8.
Sistema pede remoção do cartão. Cliente remove.
Sistema entrega quantia solicitada.
108
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
110
SUB-FLUXOS DE EVENTOS

Fluxo de eventos visto como


Sub-fluxos são descritos como



Vários sub-fluxos de eventos
Principal
Alternativos/excepcionais
Abordagem visa reuso de fluxos de eventos (subfluxos)
111
EXEMPLO DE SUB-FLUXOS
 Seja

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:


o use case Validar usuário
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.
112
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
113
DIAGRAMA DE ATIVIDADES:
EXEMPLO
114
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
116
EXEMPLO DE DIAGRAMA
Sistema de validação
de cartão de crédito
Transação de
cartão
Cliente
Processa
fatura
Instituição
vendedora
Reconcilia
transações
Cliente
individual
Cliente
corporativo
Gerencia
conta
Financeira
117
BIBLIOGRAFIA
Sommerville, I. Software Engineering
 Kruchten, P. The Rational Unified Process: An
Introduction. 2nd Ed
 Booch, G. et al. The Unified Modeling Language
User Guide.

118