View
23
Download
0
Category
Preview:
DESCRIPTION
Engenharia de Requisitos Marcela Santos. Apresentação baseada no material do professor Alexandre Vasconcelos (amlv@cin.ufpe.br). “Todos os projetos são viáveis, desde que tenham ilimitados recursos e tempo infinito!”. Objetivos. - PowerPoint PPT Presentation
Citation preview
ENGENHARIA DE REQUISITOSMARCELA SANTOSApresentação baseada no material do professor Alexandre Vasconcelos
(amlv@cin.ufpe.br)
1
“Todos os projetos são viáveis,
desde que tenhamilimitados 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
4
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
O PROCESSO DA ENGENHARIA DE REQUISITOS
23
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
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ão-funcionais 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)
34
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
CLASSIFICAÇÃO DE R. N. F. Requisitos do Produto
Produto deve comportar-se de forma particular (velocidade de execução, confiabilidade, etc.)
Requisitos OrganizacionaisConseqüência de políticas e
procedimentos organizacionais (padrões de processo usados, requisitos de implementação, etc.)
Requisitos ExternosConseqüência de fatores externos ao
sistema e ao processo de desenvolvimento (legislação, etc.)
35
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
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
42
Requisitos
Não-funcionais
Organização
Funcionais Domínio
Produto Externo
SistemaUsuário
TÉCNICAS DE ELICITAÇÃO
Entrevistas Questionários Casos de Uso Jogo de Funções Brainstorming Workshop de Requisitos
43
ANÁLISE DE REQUISITOS
54
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
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, CPrioridade: Essencial
[RNF001] Consulta X ao B.D. deve visualizar dados segundo padrão YPrioridade: Importante
[RNF010] Consulta X ao B.D. deve usar cores azuis nos resultadosPrioridade: 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 RequisitosAnálise manual sistemática dos requisitos
PrototipaçãoUso 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áticaAvaliar 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 inconsistentesRequisitos 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 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
70
RASTREAMENTO
71
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: ANÁLISE DE IMPACTO
72
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
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 resultadoDe valor
observávelE para ator
particular
78
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
79
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
81
USE CASE E ATOR
82Função
Emissor
Passo 1Passo 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
83
EXEMPLO DE USE CASE E ATOR
84
Cliente
Transferirdinheiro
Sacardinheiro
Consultarsaldo
Valor deresultado
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?
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 senhaPode-se criar novo use case “Autenticar
usuário” e incluí-lo Mas atenção
NÃO SE DEVE CRIAR USE CASES MÍNIMOSDeve haver ganho no reuso
95
INCLUSÃO
96
Sacardinheiro
Consultarsaldo
Autenticarusuá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). ...
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
100
Atendimento
Pontos de extensãourgente
Atendimentode urgência
<< extend >>(urgente)
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
103
AtendimentoAtendimentode urgência
ClienteClientecomercial
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
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”
106
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.
107
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.
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 Vários sub-fluxos de eventos
Sub-fluxos são descritos como Principal Alternativos/excepcionais
Abordagem visa reuso de fluxos de eventos (sub-fluxos)
111
EXEMPLO DE SUB-FLUXOS
Seja o use case Validar usuárioFluxo 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. 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
117
Transação decartão
Clientecorporativo
Clienteindividual
Cliente Instituiçãovendedora
Financeira
Sistema de validaçãode cartão de crédito
Processafatura
Reconciliatransações
Gerenciaconta
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
Recommended