xxxxxxxxxxxxxxxxxxxxxxxxxxxx

1. 1
Engenharia de Requisitos
Alexandre Vasconcelos
(amlv@cin.ufpe.br)

2. 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. 3
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

4. 22
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

5. 23
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

6. 24
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).

7. 25
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

8. 26
Tipos de Requisitos
 Requisitos Funcionais
 Requisitos Não-Funcionais
 Requisitos de Domínio

9. 27
Requisitos Funcionais
 Descreve funcionalidade e serviços do
sistema
 Depende do
 Tipo do software
 Usuários esperados
 Tipo do sistema onde o software é usado

10. 28
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

11. 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.

12. 31
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

13. 32
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

14. 33
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,
etc.)

15. 34
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

16. 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

17. 37
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

18. 40
Requisitos
Requisitos
Não-funcionais
Organização
Funcionais Domínio
Produto Externo
Sistema
Usuário 

19. 41
Técnicas de Elicitação
 Entrevistas
 Questionários
 Casos de Uso
 Jogo de Funções
 Brainstorming
 Workshop de Requisitos

20. 52
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

21. 53
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.

22. 54
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)

23. 55
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

24. 56
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

25. 57
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

26. 58
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)

27. 59
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

28. 60
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

29. 61
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

30. 62
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

31. 63
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

32. 64
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

33. 65
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

34. 66
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

35. 67
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

36. 68
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

37. 69
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
Projeto
Modelos Suítes Teste
Teste
2 3
Req A
1
Requisitos
Produto
(Características)
Requisitos
Detalhados
(Casos de Uso)
Req B
Plano
Doc. Usuário
4
Rastreamento

38. 70
 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

39. 71
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

40. 72
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

41. 73
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

42. 74
Diagramas de Casos de Uso
Alexandre Vasconcelos
(amlv@cin.ufpe.br)

43. 75
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

44. 76
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

45. 77
Use Case e Ator
 Alguém ou alguma
coisa (fora do
sistema) que
interage com o
sistema
Emissor/Receptor

46. 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

47. 80
Use Case e Ator
Função
Emissor
Passo 1
Passo 2
…
Passo N
Descrição

48. 81
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

49. 82
Exemplo de Use Case e Ator
Cliente
Transferir
dinheiro
Sacar
dinheiro
Consultar
saldo
Valor de
resultado
observável

50. 83
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?

51. 84
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

52. 91
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

53. 92
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

54. 93
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

55. 94
Inclusão
Sacar
dinheiro
Consultar
saldo
Autenticar
usuário
<< include >> << include >>

56. 95
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). ...

57. 96
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

58. 97
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

59. 98
Extensão
Atendimento
Pontos de extensão
urgente
Atendimento
de urgência
<< extend >>
(urgente)

60. 99
Extensão
 Descrição de Atendimento
 Fluxo de Eventos Principal:
 Colete os itens do pedido. (urgente).
Submeta pedido para processamento.

61. 100
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

62. 101
Especialização
Atendimento
Atendimento
de urgência


Cliente
Cliente
comercial

63. 102
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

64. 103
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)

65. 104
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”

66. 105
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.

67. 106
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.

68. 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

69. 109
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)

70. 110
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.

71. 111
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

72. Diagrama de atividades: exemplo
112

73. 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

74. 115
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

75. 116
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.