Engenharia de Requisitos

Apresentação em tema: "Engenharia de Requisitos"— Transcrição da apresentação:

1 Engenharia de Requisitos
Alexandre Monteiro

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 Relatório de Elicitação de requisitos e análise Modelos do sistema Especificação de requisitos Validação Requisitos do usuário e do Documento de requisitos

4 Estudo de Viabilidade O que é um estudo de viabilidade?
O que estudar e concluir? Benefícios e custos Análise de custo/benefício Alternativas de comparação

5 Estudo de Viabilidade Estudo que indica se o esforço em desenvolver a idéia vale a pena Visa tanto a tomada de decisão Como a sugestão de possíveis alternativas de solução

6 Estudo de Viabilidade Deve oferecer informações para ajudar na decisão
Se o projeto pode ou não ser feito Se o produto final irá ou não beneficiar os usuários interessados Escolha das alternativas entre as possíveis soluções Há uma melhor alternativa?

7 O Que Estudar? Sistema organizacional apresentado
Usuários, políticas, funções, objetivos, etc. Problemas com o sistema apresentado Inconsistências, funcionalidades inadequadas, performance, etc. Objetivos e outros requisitos para o novo sistema O que precisa mudar?

8 O Que Estudar? Restrições Alternativas possíveis
Incluindo requisitos não-funcionais do sistema (superficialmente) Alternativas possíveis Sistema atual é geralmente uma das alternativas Vantagens e desvantagens das alternativas

9 Testes de Viabilidade Operacional Técnica
Medida do grau de adequação da solução para a organização Avaliação de como as pessoas se sentem sobre o sistema/projeto Técnica Avaliação da praticidade de uma solução técnica específica e a disponibilidade dos recursos técnicos e dos especialistas

10 Testes de Viabilidade Cronograma Econômica
Avaliação de quão razoável está o cronograma do projeto Econômica Avaliação de custo-eficiência de um projeto ou solução Conhecida como análise de custo/benefício

11 Viabilidade Operacional
Avalia a urgência do problema (visão e fases de estudo) ou a aceitação da solução (definição, seleção, aquisição, e fases do projeto) Há dois aspectos da viabilidade operacional a serem considerados O problema vale a pena ser resolvido ou a solução proposta para o problema funcionará? Como o usuário final e a gerência sentem-se sobre o problema (solução)?

12 Viabilidade Técnica A solução ou a tecnologia proposta é prática?
Já possuímos a tecnologia necessária? Já possuímos o conhecimento técnico necessário?

13 Viabilidade de Cronograma
Dado nosso conhecimento técnico, os prazos dos projetos são razoáveis? Alguns projetos são iniciados com prazos específicos Você precisa determinar se os prazos são obrigatórios ou desejáveis Se são mais desejáveis que obrigatórios, o analista pode propor outros cronogramas

14 Viabilidade Econômica
Talvez a mais crítica Durante as fases iniciais do projeto, a análise da viabilidade econômica consiste em julgar se os possíveis benefícios de solucionar o problema são ou não vantajosos Tão logo os requisitos específicos e soluções sejam identificados, o analista pode levar em consideração os custos e benefícios de cada alternativa Isso é chamado de análise de custo-benefício

15 Tipos de Custos Custos de desenvolvimento de sistemas
Desenvolvimento e aquisição Custos de instalação e de conversão Custos operacionais (contínuo) Manutenção Pessoal

16 Análise Custo-Benefício
Há três técnicas principais Análise do retorno financeiro (payback analysis) Retorno do investimento (return on investments) Valor atual líquido (Net present value)

17 Análise de Retorno do Investimento
A técnica de análise de retorno do investimento (ROI) compara os benefícios das diferentes soluções ou projetos O ROI para uma solução ou projeto é a taxa percentual que mede a relação entre a quantia que a empresa obtém de retorno ao seu investimento e a quantia investida

18 Análise de Retorno do Investimento
O ROI para uma solução ou projeto potencial é calculado como a seguir: ROI = (Benefícios totais - Custos totais) / Custos totais ROI = valor atual líquido / Custos totais Ex: ROI = (22508, ,20)/ 17321,20= 29,95% EX: ROI = 5187,44/ 17321,20 = 29,95% A solução que oferecer o ROI mais alto é a melhor alternativa

19 Matriz de Viabilidade Como nós comparamos alternativas quando existem vários critérios de seleção e nenhuma das alternativas é superior em todos os aspectos? Use uma Matriz de Análise de Viabilidade!

20 Relatório de Viabilidade
Após o esforço inicial, discutido anteriormente, deve-se elaborar um relatório de viabilidade Para cada aspecto apresentado, deve haver seção de avaliação Deve haver uma seção conclusiva sobre a melhor alternativa ou que o sistema não é viável

21 Exercício Determine a viabilidade de (+ROI):
1. Sistema para uma padaria de pequeno porte (Só caixa, no balcão também, etc.); 2. Sistema inteligente de preenchimento do IRPF pela própria pessoa física; 3. Sistema para gerar alocação de docentes, salas, horários, local de forma otimizada.

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 Requisitos do Sistema
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

29 Exercício Dê alguns exemplos de R.F.s para:
1. Sistema da padaria de pequeno porte; 2. Sistema inteligente de preenchimento do IRPF; 3. Sistema de alocação docente.

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

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 Requisitos Organizacionais
[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

35 Exercício Dê alguns exemplos de R.N.F.s para:
1. Sistema da padaria de pequeno porte; 2. Sistema inteligente de preenchimento do IRPF; 3. Sistema de alocação docente.

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 não prático

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

38 Requisitos de Domínio (Exemplo 1)
A desaceleração do trem deve ser computada através da fórmula Dtrem=Dcontrole+Dgradiente onde ...

39 Exercício Dê alguns exemplos de domínio para:
1. Sistema da padaria de pequeno porte; 2. Sistema inteligente de preenchimento do IRPF; 3. Sistema de alocação docente.

40 Requisitos Requisitos Usuário =df Sistema Funcionais Não-funcionais
Domínio Produto Organização Externo

41 Técnicas de Elicitação
What follows is a crash course in elicitation techniques. We will briefly discuss each topic in turn. Many of these techniques can be used together. There are many other techniques such as: Production software Task analysis ... Note: Storyboarding and prototyping have been moved to “Module 7: Refining the System Definition”. Entrevistas Questionários Casos de Uso Jogo de Funções Brainstorming Workshop de Requisitos We will discuss briefly each of these techniques in the following slides.

42 Entrevistas Técnica direta Objetivo
Refer back to the interview exercise we did at the beginning of the class to determine their needs for this class. Técnica direta Pode ser usada na análise do problema e na elicitação de requisitos Objetivo Entender os problemas reais e soluções potenciais das perspectivas dos usuários, clientes, e outros stakeholders Interviewing is probably the most useful technique to directly get needs from your stakeholders. It is helpful to interview key stakeholders for your project.

43 Entrevistas Quem são o cliente e o usuário?
Possuem necessidades diferentes? Quais são suas Capacidades Backgrounds Ambientes, etc. Qual é o problema? Como é resolvido atualmente? One of the 4 types of interview questions: User Process Product Meta-questions

44 Entrevistas Qual a razão para resolvê-lo?
Qual o valor de uma solução bem-sucedida? Onde mais uma solução pode ser encontrada? One of the 4 types of interview questions: User Process Product Meta-questions Note que algumas dessas perguntas já foram feitas no estudo de viabilidade.

45 Questionários Aplicabilidade a mercados específicos Hipóteses
Should still be prefaced by interviews to determine the correct questions to ask. How many customers should be interviewed to determine a good cross-section of questions? Usually is adequate. Most items should be categorized to allow for statistical analysis. Always leave some open-ended questions to allow for new ideas. Aplicabilidade a mercados específicos Onde perguntas são bem definidas Hipóteses Perguntas relevantes podem ser decididas antecipadamente Leitor ouve da maneira desejada Suprime o que é bom sobre análise Úteis após uma entrevista inicial A questionnaire can be useful for gathering data, but it should still be prefaced by interviews to determine the correct questions to ask. How many customers should be interviewed to determine a good cross-section of questions? Usually is adequate. Most items should be categorized to allow for statistical analysis. Always leave some open-ended questions to allow for new ideas.

46 Casos de Uso Discuta com o cliente o que o sistema fará
Identique quem interage com o sistema Identique que interfaces o sistema terá We will present a use-case model for defining our requirements, but we will often find that as we develop this model, it will uncover other needs that were not apparent originally. As a high-level elicitation technique, use cases and actors should be identified. This gives us a context for finding the needs of the stakeholders in terms of the functionality and interfaces of the system. In conjunction with identifying use cases, we might need to use our other elicitation techniques. For example, it is common to hold a requirements workshop for the purpose of identifying use cases.

47 Casos de Uso Verifique se não há requisitos faltando
Verifique que os desenvolvedores entendem os requisitos Vantagem é ter apelo visual dos requisitos mais relevantes do cliente We will present a use-case model for defining our requirements, but we will often find that as we develop this model, it will uncover other needs that were not apparent originally. As a high-level elicitation technique, use cases and actors should be identified. This gives us a context for finding the needs of the stakeholders in terms of the functionality and interfaces of the system. In conjunction with identifying use cases, we might need to use our other elicitation techniques. For example, it is common to hold a requirements workshop for the purpose of identifying use cases.

48 Jogo de Funções Engenheiro de requisitos Cliente
Ask group if they’ve used this technique. If anyone has used CRC cards they can share how they were used and if they were successful. The CRC Card technique is based on paper by Kent Beck and Ward Cunningham. The technique was made popular by Rebecca Wirffs-Brock. Engenheiro de requisitos Assume a função do usuário ou cliente Entender o domínio do problema Cliente Assume a função do usuário Entender os problemas que podem passar If the people you are getting requirements from are not the actual user, sometimes it can be useful to have them take on the role of a user and walk through some user scenarios.

49 Brainstorming Regras para Brainstorming
Estabeleça o objetivo da sessão Gere quantas idéias for possível Deixe sua imaginação livre Não admita críticas ou debates Ajuste e combine as idéias

50 Workshop de Requisitos
Ask: “Has anyone participated in a similar workshop?” This section is much more effective if it is presented in the context of a real (or close to real) workshop in which you have actually participated -- or at least in the context of an imaginary one which you might want to set up. Põe todos os stakeholders juntos por um período intensivo (focado) Facilitador conduz a reunião Todos têm sua vez de falar Resultados são disponíveis imediatamente Provê um ambiente para aplicar outras técnicas de elicitação A requirements workshop is one of the most cost-effective and time-efficient means to get feedback. The same concepts are used in JAD (Joint Application Development) or RAD (Rapid Application Development) sessions.

51 Exercício Quais técnicas poderiam ser usadas em:
1. Sistema da padaria de pequeno porte; 2. Sistema inteligente de preenchimento do IRPF; 3. Sistema de alocação docente.

52 Análise de Requisitos Definição e especificação de requisitos
Documento de requisitos 7 8 Validação dos requisitos Entendimento do domínio 6 Atrib. Prioridade Entrada do processo 1 5 2 4 Coleta de requisitos Resolução de conflito 3 Classificação

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 muda

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 Rastreamento de Projeto
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 Detalhados (Casos de Uso)
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 Requisitos Produto (Caracter.) Req A 1 Requisitos Detalhados (Casos de Uso) Req B Based on this structure, we then need to set up traceability links between all associated requirements or other project elements. 2 3 4 Projeto Teste Doc. Usuário Modelos Suítes Teste Plano

70 Rastreamento: Análise de Impacto
RequisitePro provides what are called “suspect links”, which notify that an associated requirement has changed. All directly related requirements should be reviewed to assess whether they are impacted. Why is the link from Req B to Req C not marked as suspect? Because it will only go suspect if B actually changes. The only way to resolve these are manually (by actually looking at the changes and the affected requirements). You can probably make a *lot* of money if you could figure out a way to do this automatically (joke). Req A antes “if return value > $5” Req B Req C “if return value > $2” Req A depois RequisitePro provides what are called “suspect links”, which can notify that an associated requirement has changed. All directly related requirements should be reviewed to assess whether they are affected. Why is the link from Req B to Req C not marked as suspect? The only way to resolve suspect links are manually (by actually looking at the changes and the affected requirements). Links dos requisitos devem ser marcados como “revisar” Links “revisar” devem ser analisados

71 Documento de Requisitos
Fonte: IEEE/ANSI ( ) 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 ( ) 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 ( ) 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

74 Diagramas de Casos de Uso
Alexandre Vasconcelos

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 Procedimento computacional/algorítmico atômico Função

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

78 Use Case e Ator Resultado de Valor Observável Ator Particular Função
Emissor Função 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 Descrição Passo 1 Passo 2 … Passo N Emissor Funçã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
Valor de resultado observável Transferir dinheiro Sacar dinheiro Consultar saldo Cliente

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

85 Identificando Use Cases
Facilitar gerenciamento durante ciclo de desenvolvimento A razão para agrupar funcionalidades e chamá-las de use cases

86 Exercício Tenho um sistema que é acionado 2 vezes por dia (às 10:20hs e 17:20hs), enviando-me um SMS. Também tenho como obter resultado semelhante acessando tal funcionalidade a partir de meu celular (web browser). Crie os casos de uso correspondentes.

87 Evolução de Use Cases Inicialmente use cases são simples
Apenas esboço sobre funcionamento é suficiente Mas com a sedimentação da modelagem Descrição mais detalhada do fluxo de eventos faz-se necessária Fluxo de eventos deve ser refinado Todos os stakeholders envolvidos devem estar de acordo com a descrição

88 Organizando Use Cases Sistema pequeno não demanda estruturação
Exemplo, seis use cases, com dois/três atores Já sistemas maiores requerem princípios de estruturação e organização Caso contrário, planejamento, atribuição de prioridades, etc., podem se tornar difíceis

89 Pacote de Use Case Primeiro esforço de estruturação
Agrupam-se use cases relacionados em único container

90 Clientes :: Atendimento
Pacote de Use Cases Clientes Clientes :: Atendimento

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 << include >> << include >>
Inclusão Autenticar usuário << include >> << include >> Sacar dinheiro Consultar saldo

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 << extend >>
Extensão << extend >> (urgente) Atendimento de urgência Atendimento Pontos de extensão 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   Atendimento de urgência Atendimento Cliente
comercial Cliente

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 seria 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”

105 Exemplo de Fluxo de Eventos
Um esboço inicial sobre Sacar dinheiro seria 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.

106 Exemplo de Fluxo de Eventos
Um esboço inicial sobre Sacar dinheiro seria Sistema pede remoção do cartão. Cliente remove. Sistema entrega quantia solicitada.

107 Exercício Remodele exercício anterior para mostrar a situação excepcional quando o serviço pode ser solicitado pelo browser do celular.

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

112 Elementos de um Diag. Ativ.

113 Exercício Remodele o exercício anterior usando um diagrama de atividade no lugar de linguagem natural

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   Cliente Instituição vendedora Cliente
Sistema de validação de cartão de crédito Transação de cartão Cliente Instituição vendedora Processa fatura   Reconcilia transações Cliente individual Cliente corporativo Gerencia conta Financeira

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.