Download - 04 - Requisitos
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 deviabilidade
Relatório deviabilidade
Elicitação derequisitos e
análise
Modelos dosistema
Especificaçãode requisitos
Validaçãode requisitos
Requisitos dousuário e do
sistema
Documento derequisitos
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
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
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).
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
26
Tipos de Requisitos Requisitos Funcionais
Requisitos Não-Funcionais
Requisitos de Domínio
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
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
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.
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
32
Medidas de Requisitos(Não-Funcionais)
Propriedade MedidaVelocidade Transações processadas/seg
Tempo de resposta do usuário/eventoTamanho K bytes
No de chips de RAMFacilidade de uso Tempo de treinamento
No de quadros de ajudaConfiabilidade Tempo médio de falhas
Probabilidade de indisponibilidadeTaxa de ocorrência de falhas
Robustez Tempo de reinício após falhaPercentual de eventos causando falhasProbabilidade de corrupção de dados após falha
Portabilidade Percentual de declarações dependentes do destinoNo de sistemas destino
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.)
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
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
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
40
RequisitosRequisitos
Não-funcionais
Organização
Funcionais Domínio
Produto Externo
SistemaUsuário
41
Técnicas de Elicitação Entrevistas Questionários Casos de Uso Jogo de Funções Brainstorming Workshop de Requisitos
52
Análise de Requisitos
Entendimentodo domínio
Coleta derequisitos
Classificação
Definição eespecificaçãode requisitos
Resoluçãode conflito
Atrib. Prioridade
Validaçãodos requisitos
Entrada doprocesso
Documentode requisitos
1
2
3
4
5
6
7 8
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.
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)
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
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
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
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)
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
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
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
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
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
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
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
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
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
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
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
RequisitosProduto
(Características)
RequisitosDetalhados
(Casos de Uso)
Req B
Plano
Doc. Usuário
4
Rastreamento
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
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
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
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
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
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
77
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
80
Use Case e Ator
Função
Emissor
Passo 1Passo 2…Passo N
Descrição
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
82
Exemplo de Use Case e Ator
Cliente
Transferirdinheiro
Sacardinheiro
Consultarsaldo
Valor deresultado
observável
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?
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
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
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
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
94
Inclusão
Sacardinheiro
Consultarsaldo
Autenticarusuário
<< include >> << include >>
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). ...
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
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
98
Extensão
Atendimento
Pontos de extensãourgente
Atendimentode urgência
<< extend >>(urgente)
99
Extensão Descrição de Atendimento
Fluxo de Eventos Principal: Colete os itens do pedido. (urgente).
Submeta pedido para processamento.
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
101
Especialização
AtendimentoAtendimentode urgência
ClienteClientecomercial
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
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)
104
Exemplo de Fluxo de Eventos Um esboço inicial sobre Sacar
dinheiro seria1. 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”
105
Exemplo de Fluxo de Eventos Um esboço inicial sobre Sacar
dinheiro seria4. 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.
106
Exemplo de Fluxo de Eventos Um esboço inicial sobre Sacar
dinheiro seria7. Sistema pede remoção do cartão.
Cliente remove.8. 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
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)
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.
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
Diagrama de atividades: exemplo
112
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
115
Exemplo de Diagrama
Transação decartão
Clientecorporativo
Clienteindividual
Cliente Instituiçãovendedora
Financeira
Sistema de validaçãode cartão de crédito
Processafatura
Reconciliatransações
Gerenciaconta
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.
