A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

Curso de Requisitos Módulo 03: Requisitos de Software Requisitos de Software, Técnicas de Levantamento, Identificação dos Problemas, Necessidades e Principais.

Apresentações semelhantes


Apresentação em tema: "Curso de Requisitos Módulo 03: Requisitos de Software Requisitos de Software, Técnicas de Levantamento, Identificação dos Problemas, Necessidades e Principais."— Transcrição da apresentação:

1 Curso de Requisitos Módulo 03: Requisitos de Software Requisitos de Software, Técnicas de Levantamento, Identificação dos Problemas, Necessidades e Principais Artefatos

2 Introdução à Gerencia de Requisitos: Visão Geral Sistema a ser construído Necessidades Requisitos de Software Design Procedimentos de Teste Docs do usuário Características Domínio da Solução Domínio do Problema Rastreabilidade Problem Problema

3 Definições Requisitos –A condição ou capacidade que o sistema deve possuir. Gerenciamento de Requisitos –Uma abordagem sistemática para: Detalhar, organizar, e documentar requisitos. Estabelecer e manter acordos entre cliente/usuário e equipe de projeto nas requisições de mudanças.

4 O que Requisitos de Software especificam? Entradas Saídas Funções Requisitos não funcionais (Ex.: Performance) Restrições de Design (Ex.: Ambientes) Sistema

5 Definições Requisições do Stakeholder Uma expressão independente de solução de um estado desejado pelo stakeholder da solução ou sujeito ao domínio. Requisitos de Software Requisito Funcional Um requisito que especifica, de uma perspectiva caixa-preta, como uma solução que interage com o mundo externo. Requisito não funcional Um requisito que expressa, de uma perspectiva caixa-preta, os atributos de qualidade da solução. Restrição Uma limitação no design do sistema ou nos processos usados para construir o sistema. Característica Um serviço externamente observável diretamente no sistema que atende a um ou mais requisições do stakeholder.

6 Exemplo de um Sistema de Registro em Curso Requisição do Stakeholder Precisa de menor despesa geral no registro. Professores precisam de acesso imediato a grade de aulas. Restrição Opera no Main Frame DEC VAX da Universidade. Requisito de Software Funcional O caso de uso começa quando o estudante seleciona o comando register for course. O sistema apresenta uma lista de cursos disponíveis… Não-Funcional Disponibilidade de 99% dos 24/7(3.65 dias off-line por ano) Característica Uma árvore de navegação de visualizar a grade de aulas, por semestre e por turma.

7 Caracterização das Definições Based on Leffingwell & Widrig, 1999 Requisitos de Software Restrições de Design Requisitos Funcionais Requisitos não funcionais tipos de Requisitos Requisições do Stakeholder Características

8 O que Como Necessidades do Stakeholder Características do Produto ou Sistema Requisitos de Software Especificação de Design Procedimentos de Teste Planos de Documentação Requisitos existem em vários níveis O que Como O que Como

9 Gerência de Requisitos Não é Fácil porque… Requisitos: –Nem sempre são óbvios. –Vem de várias fontes. –Nem sempre é fácil de expressar claramente em palavras. –São interelacionados e relacionados a outras entregas do processo de desenvolvimento de software. –Tem propriedades únicas ou valores de propriedade. –Mudam. –São difíceis de controlar quando em grande número.

10 Gerenciamento Requer Estratégia RUCS10: RM Plan

11 Gerenciamento de Requisitos efetivo Manter um claro estabelecimento dos requisitos requer: –Boa qualidade dos requisitos –Atributos aplicáveis para cada tipo de requisito –Rastreamento para outros requisitos e outros artefatos do projeto O OBJETIVO é entregar produtos de qualidade No tempo e no orçamento que atendam As reais necessidades do usuário.

12 O que é um Produto com Qualidade ? Qualidade: Velhos Conceitos –Satisfaz os documentos de requisitos. –Passa nos testes de sistema. –Adere ao processo de desenvolvimento. Qualidade: Conceitos Modernos –Entende todas as necessidades do usuário. –Continuamente revisa todos os artefatos para garantir que atendem às necessidades. Paradigma baseado em atividades Paradigma baseado em Resultados

13 Dimensões de Qualidade Componentes do FURPS+ Functionality Conjunto de características, segurança, e requisitos em geral Usability Fatores humanos estéticos, consistência, documentação Reliability Frequência/severidade da falha, recuperabilidade, previsibilidade, acurária, MTBF P erformance Velocidade, uso de recrusos, throughput, tempo de resposta Supportability Testabilidade Extensível Adaptabilidade Manutenível Compatibilidade Configurável DisponibilidadeInstalável LocalizávelRobustez

14 On Time and On Budget Tempo Quanto de trabalho nós podemos fazer? Recursos Orçamento Scope Escopo

15 Atendendo as reais necessidades do cliente Característica 1: O sistema deve... Característica 2: O sistema deve Característica 3: O sistema deve Característica 4: O sistema deve Característica 5: O sistema deve Característica 6: O sistema deve Característica 7: O sistema deve Característica n: O sistema deve… Como determinar prioridade? O que é um baseline? Como sabemos quais são as necessidades? Tempo Data de Início do Projeto Data-Alvo do Lançamento

16 Possibilitar um acordo entre os envolvidos Objetivos de sistema Verificação Requisitos Cliente Grupo de Usuários Sistema a ser construído Adapted from Al Davis Requisitos O Objetivo

17 Quais fatores contribuem para o sucesso do Projeto? 10. Outros aspectos 9. Estimativas confiáveis 8. Uso de métodos formais 7. Requisitos básicos firmes 6. Infra de Software padronizada 5. Escopo controlado 4. Objetivos Negociais claros 3. Gerente experiente 2. Envolvimento do Usuário 1. Suporte da Gerência Executiva Os Dez Motivos Standish Group, 01 (www.standishgroup.com) 28% dos projetos são completados no orçamento e prazo. 49% dos projetos ultrapassam as estimativas iniciais. - Tempo estoura em média 63%. - Custo ultrapassa em média 45%. 23% dos projetos são cancelados antes de sua conclusão. Fatores de Sucesso

18 Tamanho é importante Taxa de Sucesso (%) Standish Group, 99 (www.standishgroup.com) Sucesso pelo Tamanho do Projeto

19 O alto custo dos Requisitos Errados Custo relativo para reparar erros: Quando Introduzidos X Quando reparados Em tempo de Requisitos Design Codificação Teste Unitário Teste de Aceitação Manutenção All together, the results show as much as a 200:1 cost ratio between finding errors in the requirements and maintenance stages of the software lifecycle. Boehm 1988 A regra do

20 Ajuda para Projetos serem bem sucedidos Análise dos Problemas –Entender o Problema. –Obter o entendimento com os stakeholders. –Estabelecimento claro dos objetivos de negócio. Elicitação de Requisitos –Identificar quem utilizará o sistema (atores). –Elicitar como o sistema será usado (casos de uso). Gerenciamento de Requisitos –Especificar os requisitos de forma completa. –Gerenciar expectativas, mudanças, e erros. –Controlar quebra de escopo. –Listar todos os membros da equipe.

21 Envolvendo toda a Equipe com os Requisitos Desenvolvedores, Testadores, e Autores –Ajuda a desenvolveder as práticas de gerenciamento de requisitos. –Monitora a aderência às boas práticas. –Verifica o processo de elicitação. –Documenta requisitos. –Participa das revisões sobre os requisitos. –Participa como membro do Comitê de Controle de Mudanças (CCM). –Revisa as matrizes de rastreabilidade. –Verifica qualidade, testabilidade, e completude.

22 O resultado é pior quando a qualidade é baixa ? ? ? ?

23 Qualidades do Conjunto de requisitos de software Correto –É a descrição correta sobre o que o sistema deve fazer. Completo –Descreve todos os requisitos significantes para o contexto do negócio e do usuário. Consistente –Não está em conflito com outros requisitos. Não ambíguo –Está sujeito a apenas UM entendimento.

24 Qualidades do Conjunto de Requisitos (cont.) Verificável –Pode ser testado sem grandes custos. Classificável por importância e estabilidade –Pode ser classificado por importância para o cliente e estabilidade do requisito em si. Modificável –Mudanças não afetam a estrutura do todo. Rastreável –A origem de cada requisito pode ser apontada. Claro –Compreendido por usuários e desenvolvedores. Leffingwell & Widrig (1999). IEEE , § 4.3.2, 1994

25 IEEE , § 4.3.2, O sistema suporta acima de 1000 usuários simultâneos. - O sistema deve responder a qualquer consulta em 500ms. - A cor deve ser um agradável verde sombreado. - O sistema deve estar disponível em 24 x 7. -O sistema deve exportar visões dos dados em formato texto, separado por vírgula de acordo com o IEEE. Qualidades de um Requisito: Verificável Um requisito é verificável se: –É algo finito, em que uma pessoa ou máquina (com custo viável) pode checar se o produto atende ao requisito definido junto ao usuário. Estes requisitos são verificáveis? Se não, qual o melhor modo de definí-los?

26 Qualidades de um requisito: Rastreável Requisições do Stakeholder Características SuplementarCasos de Uso

27 ref - IEEE 830 A deve ir de B para C Qualidades de um Requisito: Não ambíguo O requisito é não ambíguo se tiver apenas uma interpretação. Requisito A

28 Como realizar os requisitos. O Modelo de Design espefica componentes de um sistema ou suas interfaces com outros sub- componentes. Como saber se os requisitos estão sendo atendidos. Um Test Suite contém um conjunto de scripts de teste e logs de teste. Quando os requisitos atendem. O Plano de desenvolvimento de software especifica cronograma, planos de verificação e validação, e planos de gerenciamento de configuração. Design O que NÃO é um Requisito? Verificação Dados de Projeto

29 RUP: Um Framework para Gerência de Requisitos

30 Disciplina de Requisitos: Detalhes do Workflow

31 Papéis e Artefatos

32 Quais artefatos são usados Onde o problema é definido? Onde os stakeholders e usuários são listados? Onde os ambientes e plataformas são identificadas? Onde os casos de uso são mantidos? Onde o vocabulário comum está descrito? Visão Especificações de Caso de uso Glossário Especificação Suplementar Onde os requisitos não funcionais estão localizados? Onde as Necessidades e Requisições dos stakeholders são capturadas? Requisições do Stakeholder

33 Onde estamos na disciplina de Requisitos?

34 Análise do Problema: Atividades e Artefatos

35 Análise do Problema É o processo de entender os problemas do mundo real, e como eles se relacionam com as necessidades dos stakeholders, e propor soluções para atender a estas necessidades. Qual o objetivo da Análise de Problemas? –Ter um melhor entendimento antes de começar o desenvolvimento. –Identificar as causas-raiz. –Ajudar na identificação da solução. Evitar o: Sim, mas… –Minimizar o trabalho extra. Qual o problema real?

36 Definição do Problema Um problema pode ser definido como uma diferença entre as coisas como são percebidas e como são desejadas. (Problema) Percebido Desejado

37 Passos para a Análise do Problema Identificar os stakeholders. Entender as causas-raiz. Chegar a um entendimento sobre os problemas. Identificar as restrições do sistema e do projeto. Identificar e validar a solução em relação as causas-raiz. Definir a fronteira (escopo) do sistema.

38 Elicitar Requisitos Expandir a lista de soluções do stakeholder. Roadmap da Análise de Problemas Escolher as melhores soluções para alcançar os objetivos. Melhor solução identificada Problema validado/ajustado Problema de Negócio Definido Problema Atual identificado e definido Identifique stakeholders para o problema. Análise da Causa-Raiz. Reavaliar qual é a melhor idéia de solução. Entendimento dos Problemas no Contexto dos Objetivos de Negócio. Problema de Negócio Idéia de Solução ou Oportunidade

39 Stakeholders: Definições Stakeholder –Um indivíduo que é materialmente afetados por uma saída do sistema ou do projeto que está produzindo o sistema. Representante do Stakeholder –Um stakeholder representa um ou mais stakeholders. Eles estão diretamente envolvidos na direção, concepção, e no escopo do projeto.

40 Identificar os Stakeholders Cada grupo de stakeholders precisa de um representante. Nem todos os grupos de stakeholders precisam ser consultados. –Vários irão fornecer os requisitos. Clientes, usuários, administradores do sistema –Vários podem não fornecer requisitos. Acionistas da empresa Quem destes são stakeholders nos seus projetos?

41 Descrever Stakeholders no Documento de Visão StakeholderDigitador RepresentanteKelly Hansen DescriçãoUsuário TipoO digitador é tipicamente um técnico com conhecimentos em informática. O digitador é treinado e experiente no uso do atual sistema batch de registro. ResponsabilidadesO digitador é responsável por administrar o cadastro de cursos para cada período letivo. Isto inclui a supervisão administrativa e de permissão de acesso aos dados. Critério de Sucesso Conseguir manter o banco de dados de estudantes e professores, e abrir/fechar cursos para matrícula. EnvolvimentoA responsabilidade primária dos digitadores será manter o banco de dados de estudantes e professores, e abrir/fechar cursos para matrícula. Também será requerido da área de matrículas…. EntregasGestor de Revisão – especialmente nas funcionalidades requisitadas pela área de Matrículas. Comentários/ Preocupações Nenhum

42 Quais problemas estão por trás dos problemas? Técnicas do Diagrama de Espinha de Peixe Liste as causas que contribuem para o problema detectado. Continue perguntando Por que? (expanda cada raia). Problema de negócio que foi percebido. Sem banco à noite Morosidade Quer privacidade quando sacar Clientes insatisfeitos com nossos serviços. Bancos nos aeroportos Mais pontos de atendimento Filas grandes e lentas nas filiais

43 Análise do Problema – Validando a solução Técnicas do Diagrama de Espinha de Peixe Liste as razões que justificam a solução. Continue perguntando Por que? (expanda cada raia). Solução percebida para os problemas. Sem banco à noite Morosidade Quer privacidade quando sacar Mais Máquinas de Auto Atendimento. Bancos nos aeroportos Mais pontos de atendimento Filas grandes e lentas nas filiais

44 Benefício Esforço 20% 80% Foco nos que mais contribuem – Lei de Pareto Classifique por ordem. Use a regra do para focar nas principais causas responsáveis pelas grandes porções de problema. 20% do esforço originam em 80% de benefício.

45 Compreender o contexto maior do problema A falta de entendimento do negócio e seus objetivos aumenta o risco. O problema está em algum componente do processo/empresa? A equipe entende qual o domínio do problema? A solução do problema cria oportunidades de melhoria do processo?

46 Disciplinas de Modelagem de Negócio e Requisitos Modelagem de NegócioRequisitos

47 Modelos de Negócio Modelo de Organização estrutural e dinâmico. –Processos de Negócio –Estrutura Organizacional –Papéis e responsabilidades Visualize a organização e seus negócios. Ajude a entender os problemas atuais. Identifique potenciais melhorias. Derive e valide os requisitos de sistema necessários à Organização. Produtos Entregas Eventos

48 Descrever o problema no Documento de Visão Especificações de Manual do Usuário Especificações de Design Requisições do Stakeholder Documento de Visão Especificação Suplementar Modelo de Caso de Uso Definição do Problema

49 Documento de Visão As mesmas informações para gerência, marketing, e equipe de projeto. Fornece o feedback inicial do cliente. Promove uma compreensão única do produto. Define escopo e prioridade em alto-nível das requisições do stakeholder e suas características. Um documento em nível de sistema que descreve o que e porquê do produto. Visão

50 Estrutura do Documento de Visão 1.Introdução 2.Posicionamento 3.Descrições do Stakeholder e Usuário 4.Visão Geral do Produto 5.Características do Produto 6.Restrições 7.Faixas de Qualidade 8.Precedência e Prioridade 9.Outros Requisitos do Produto 10.Requisitos de Documentação 11.Anexo 1 – Atributos das Características

51 Obtendo o Entendimento do Problema Descrição do Problema Visão O problema de(descreva o problema) afeta (os stakeholders afetados pelo problema) O impacto disto é que (qual o impacto do problema) Uma solução de sucesso seria (listar vários benefícios-chave de negócio para uma solução de sucesso)

52 Identificar as Restrições Econômicas Técnicas De ambiente Sistêmicas Políticas Viabilidade

53 Identificar as melhores soluções de negócio Identificar as várias soluções para os problemas principais. –Técnico, não-técnico, ou ambos. Escolher a que: –Melhor resolve as causas-raiz. –Suporta os objetivos de negócio. Obter os requisitos que permitem implementar a solução.

54 Definir a fronteira da solução de sistema Manutenção Comunicações Relatórios Novo Sistema Outros sistemas Usuários Sistemas Legados

55 Atores ajudam a definir a fronteira do sistema PC Fronteira do sistema? Servidor PC Quem é o ator? Os módulos do sistema ou o usuário? Servidor Usuário PC

56 Capturando o Vocabulário comum do sistema Definir os termos usados no projeto. Ajudar a previnir mal-entendidos. Glossário Capturar o Vocabulário Comum Começar o mais cedo possível. Continua durante todo o projeto.

57 Visualize o Glossário como um modelo de Domínio Cliente Acao Cliente. Transacao ** Transacao geralTransferenciaLimite Credito

58 Entender Necessidades: Atividades e Artefatos

59 Quais são as fontes de Requisitos? Analista Cliente Domínio do Problema Usuários Parceiros Visitas ao Site Experts no Negócio Analistas de Mercado Infos Competitivas Requisições Iniciais Relatórios de Erro Mudanças de Requisito Especif. de Requisitos Modelo de Negócio Planos de Negócio Objetivos Pessoais

60 Como é o Processo? Aprovado pelo Cliente Especificação corrigida Rejeitada NovamenteEspecificação corrigidaRejeitado pelo cliente Especificação de Requisitos Cliente Requisitos Ad-hoc vindos de um cliente Membro do Projeto

61 Quais problemas podem ser encontrados? Stakeholders –Tem uma idéia pré-concebida da solução. –Não sabem exatamente o que querem. –Não conseguem articular o que querem. –Pensam que sabem o que querem, mas não reconhecem o que sugeriram quando da entrega. Analistas –Eles acham que entendem mais sobre os problemas do usuário do que o próprio usuário. Todo mundo –Todo mundo vê as coisas sob seu ponto de vista. –Todo mundo é politicamente motivado. StakeholderAnalista ??

62 Expressando as Requisições do Stakeholder STRQ Estudantes precisam de acesso fácil das grades Relatórios podem ser impressos Os resultados de fim de ano devem ser enviados por para os estudantes Professores precisam saber quem está matriculado Listas das turmas são enviadas por após matrículas

63 O Artefato de Requisição do Stakeholder Vem dos stakeholders. Tem todas as requisições do stakeholders. É consolidado de várias fontes. – , especificação de requisitos do cliente, guardanapos, quadro branco, planilhas, e etc. Usados pelos membros do projeto para criar requisitos e funcionalidades do sistema. Pode conter referências para qualquer tipo de fonte externa. Docs do Usuário Espec. Design Requisições do Stakeholder Documento de Visão Esp. Supl. Modelo de Caso de Uso

64 Técnicas para Elicitar Requisições do Stakeholder Revisar especificações de requisitos do cliente Workshop de Requisitos –Workshops de Casos de Uso –Brainstorming e redução de idéias Entrevistas Questionários Role playing Protótipos Storyboards

65 Revisar as Especificações do Cliente Identificar Requisitos. –Reconhecer e rotular: Comportamentos da Aplicação Atributos comportamentais Questões e Suposições Perguntar ao cliente. Revisão dos Requisitos

66 Brainstorming Produza o maior número de idéias possíveis. Regras do Brainstorming Esclareça o objetivo da sessão. Gere o maior número de idéias possíveis. Deixe a imaginação voar. Não permita críticas ou debates. Mescle idéias.

67 Brainstorming: Vantagens e Desvantagens Vantagens –Usado a qualquer tempo, em qualquer lugar. –Bom para grupos. –Bom para coisas de alto-nível e pressuposições. –Bom para algum nível de automação. Desvantagens –Se aplica mais a processos em grupo. –Não sistemática na forma clássica.

68 Redução de Idéias: Podar e organizar Afine Diagramas

69 Redução de Idéias: Priorize Idéias Priorize idéias restantes. –Vote Votos cumulativos –Compre idéias Voto único –Aplique avaliações –Critério Não ponderado Ponderado Rational University bucks

70 Definição do Sistema: Atividades e Artefatos

71 Posicionamento do Produto Comunica a intenção e importância. Dica: Use declaração do problema como ponto de partida. Para (cliente alvo) Que (declare oportunidade e necessidade) O (nome do produto) É um (tipo de produto) Que (estabeleça os benefícios, que levaria a investir no produto) Diferentemente (concorrente) Nosso produto (diferença para o concorrente)

72 Capture os Requisitos de Software Especificações de Documentação do Usuário Especificação de Projeto Requisições de Stakeholders Documento de Visão Especificação Suplementar Modelo de CSU Requisições Chave do Stakeholder e Características Requisitos de Software Requições do Stakeholder

73 Passos para criar o Modelo de Casos de Uso 1. Identifique atores e casos de uso. - Descrição Breve. 2. Rabisque cada caso de uso. - Fluxo básico de Eventos. - Fluxos alternativos. 3. Detalhe cada caso de uso. - Detalhe os fluxos de eventos. - Estruture cada fluxo do CSU. - Adicione Detalhes. Condições Pré e Pós, requisitos especiais, relacionamentos, diagramas de caso de uso, e etc.

74 Exemplo de Diagrama Sistema de Notícias Cliente de Negociação Sistema de Negociação na Bolsa Operador Sistema de Cotações Agendador Rede Financeira Efetuar Negociação Conta Gerenciar Portfolio Obter Cotação Executar Negociação Distribuir Notícias Rever Conta

75 Esboço de cada caso de uso Nome do Caso de Uso Descrição Breve Fluxo Básico 1. Primeiro Passo 2. Segundo Passo 3. Terceiro Passo A1 Fluxo Alternativo 1 A2 Fluxo Alternativo 2 A3 Fluxo Alternativo 3 Estruturar o fluxo em passos Numerar os passos

76 Porque esboçar casos de uso? Esboço Caso de Uso Muito Peq.? Tamanho do Caso de Uso Muito Grande? É mais de um caso de uso? Esboçar ajuda a identificar fluxos alternativos ? ? ?

77 Fluxo de Eventos (Básico e Alternativo) Um fluxo básico –Cenário do Caminho Feliz –Cenário de sucesso do início ao fim. Vários fluxos alternativos –Variantes regulares –Casos ímpares –Fluxos excepcionais (erros) Fluxo: um conjunto de passos seqüenciais.

78 Representando fluxos básicos e alternativos Passo 1 Pas. 2 A1 A3 Passo 4 A4 Passo 3 A2 A5 1. Descrição Breve 2. Fluxo de Eventos 2.1 Fluxo Básico Passo 1 Passo 2 Passo 3 Passo Fluxos Alternativos A1 … A2 … A3 … A4 … A5 …

79 O que é um cenário? Fluxo Cenário Fluxo: um conjunto de passos sequenciais. Caso de Uso: Um repositório com a descrição de todos os fluxos. Cenário: Um conjunto ordenado de fluxos que vem do início do caso de uso até seus pontos finais.

80 Capturando os cenários do Caso de Uso Capture os cenários na especificação de caso de uso em sua própria seção. Dê um nome a cada cenário. Liste o nome de cada fluxo em cada cenário. –Coloque os fluxos em seqüência. Exemplo do Cenário de Caso de Uso Obter Cotação Cenário Conexão do servidor caiu. Fluxos: Fluxo Básico, Sistema de Cotações Indisponível.

81 Esboçe o fluxo de eventos Fluxo Básico –Quais eventos iniciam o caso de uso? –Como o caso de uso termina? –Como o caso de uso repete um comportamento? Fluxos Alternativos –Há situações não obrigatórias que ocorrem? –O que pode acontecer de estranho? –Quais variantes podem acontecer? –O que pode estar errado? –O que não pode acontecer? –Que tipos de recurso podem ser bloqueados?

82 Desenho passo-a-passo: Obter Cotação Fluxo Básico 1. O cliente se autentica. 2. O cliente requisita a obtenção de uma cotação. 3. O cliente seleciona o botão de negociação de ações. 4. O cliente obtêm a cotação desejada. 5. O sistema apresenta a cotação. 6. O cliente obtêm outras cotações. 7. O cliente sai do sistema. Fluxos Alternativos A1. Cliente de Ações não identificado. A2. Sistema de Cotações indisponível. A3. Sair. Existem outras alternativas?

83 Packages (Pacote): Organize o Modelo de CSU Use-Case Packages Package Raiz Use Cases Use-Case Packages Atores

84 Refinar a definição do sistema: Atividades e Artefatos

85 O que são restrições de projeto? Um requisito que se refere ao projeto e/ou arquitetura do sistema é uma restrição de projeto. –Distinguir de outros requisitos. –Colocá-la em uma seção especial do Documento de Requisitos. –Identificar a fonte de cada uma. –Documentar a razão de cada uma. Exemplos. –Um algoritmo de uso obrigatório. –O uso de um determinado produto de banco de dados. –A linguagem de programação que deve ser usada.

86 O que Como O que Como O que Como Necessidades Características Casos de Uso Espec. Técnica Procedimentos Teste Planos Documentação O homem de cima É o Homem do outro andar. Davis, 1993 O Dilema do O Que-Versus-Como Questão: Como especificar um requisito de projeto? Resposta: Depende de seu ponto de vista.

87 Características levam a Requisitos de Software Caract 63 – o sistema de acompanhamento de defeitos irá fornecer informações de tendências para ajudar o gerente de projeto a ter conhecimento do andamento Informações de tendências serão apresentadas em um gráfico de linhas apresentando tempo em x, e nº de defeitos em y. Períodos de negocição podem ser digitadas em dias, semanas e meses. Imprimir Relatório de Status Operador Gerente de Projeto

88 O sistema pode … O sistema deve … O sistema deve... Qual escolher? Como especificar requisitos funcionais? Use os casos de uso e setenças declarativas. –Ambos são necessários para entender um sistema de complexidade relevante. Dê preferência a casos de uso, onde apropriados. + Casos de UsoSentenças Declarativas

89 E sobre requisitos que não estão em Casos de Uso? Escreva uma sentença declarativa que não esteja em caso de uso. –Use uma palavra-chave que para ajudar na identificação, por exemplo deve. –Numere e dê um título a cada requisito. –Agrupe requisitos relacionados. Use language the team easily understands. –Use uma estrutura de setença simples. Adjetivo + Substantivo. –Seja conciso e claro. Descreva o requisito em 1 a 3 sentenças. Torne o requisito completo. –Use termos do glossário.

90 Requisitos Funcionais em Sentenças Declarativas Alguns requisitos são mais fáceis de entender em sentenças declarativas. –Exemplo do sistema RU e-st 1. Localização: SUPL120: O sistema RU e-st deve suportar a apresentação de todas as mensagens e menus no idioma escolhido pelo usuário a qualquer hora. Os idiomas suportados devem ser Inglês, Espanhol, Francês, Alemão, e Sueco.

91 Onde as sentenças declarativas são especificadas? Se o requisito se aplicar ao caso de uso: –Especifique no caso de uso –Na seção Requisitos especiais O requisito se aplica a uma parte do sistema: –Especifique na Especificação Suplementar

92 Variações nos Requisitos Funcionais O sistema com um pequeno comportamento externo observável. O sistema com muito comportamento externo observável.

93 Por que detalhar casos de uso? Para especificar os requisitos de software. –Criar a especificação que deve ser implementada. Esclarecer detalhes importantes do fluxo de eventos. –O que um ator faz. –Como o sistema deve responder ao ator. –Quais informações são trocadas. Descrição de informação adicional. –Pré-Condições –Pós-Condições

94 Detalhe um caso de uso 1. Procure atores e casos de uso. 2. Detalhes do caso de uso. 1. Descrição Breve 2. Fluxo de Eventos Fluxo Básico de Eventos Fluxos Alternativos 3. Requisitos Especiais 4. Pré-Condições 5. Pós-Condições 6. Pontos de Extensão 7. Relacionamentos 8. Diagramas de Caso de Uso 9. Outros diagramas e itens 1. Descrição Breve 2. Fluxo de Eventos Fluxo Básico de Eventos Fluxos Alternativos 3. Requisitos Especiais 4. Pré-Condições 5. Pós-Condições 6. Pontos de Extensão 7. Relacionamentos 8. Diagramas de Caso de Uso 9. Outros diagramas e itens Esboço Adicione Detalhes

95 Detalhe o fluxo básico de eventos Estruture o fluxo em passos Numere e dê títulos a cada passo Descreva passos (completamente e claramente) Torne cada passo um conjunto de eventos Obter Cotação 1.1 Fluxo Básico 1. Cliente se autentica O caso de uso se inicia quando o cliente se autentica. O sistema valida login e senha do cliente. O sistema apresenta uma lista de funcionalidades. 2. O cliente seleciona a função Obter Cotação O cliente escolhe obter uma cotação. O sistema apresenta uma lista de símbolos de cotação e nomes de seguros. 3. O Cliente seleciona o seguro O cliente seleciona de uma lista de seguros ou informa o símbolo de seguro para a cotação. 4. O sistema obtêm a cotação do sistema de cotações O sistema envia o símbolo de cotação para o Sistema de Cotações, e recebe uma resposta do sistema de cotações. O sistema apresenta a tela correspondente da cotação (veja em campos apresentados na Especificação Suplementar) ao cliente.

96 Gerenciar Detalhes Caixa pretaCaixa Branca Saber quem vai ler. Escreva para a caixa preta. Algum texto de caixa branca pode melhorar o entendimento porque torna o caso de uso mais concreto.

97 Estruturar os fluxos de caso de uso Organização interna do caso de uso. –Melhora legibilidade. –Torna os requisitos mais fáceis de entender. Documente os estilos aceitáveis nos Guias de Modelagem de Casos de Uso.

98 Numeração e Referência Cruzada Estilo do RUP Estilo de Tag 1. Customer Logs On In Step 1, Customer Logs On, in {Trading Customer Logs on} In {Trading Customer logs on},

99 Alternative Flows A3 Request Additional Quotes In Step 3, Customer Gets Quote, in the Basic Flow, if the customer wants additional quotes. The use case continues at Step 3. A4 Quit If at any time the Trading Customer decides to quit. The use case ends. A5 Unknown Trading Symbol In Step 3, Customer Gets Quote, in the Basic Flow, if the system cannot recognize the trading symbol, the system notifies the Trading Customer that the trading symbol is not recognizable. The use case continues at the beginning of Step 3. Fluxos alternativos A3 Requisitar cotações adicionais No passo 3, Cliente obtêm cotação, no Fluxo básico, se o cliente desejar cotações adicionais. O caso de uso continua no passo 3. A4 Sair A qualquer tempo o Cliente de Negociações pode sair do sistema. O caso de uso termina. A5 Símbolo de negociação desconhecido No passo 3, Cliente obtêm negociação, no Fluxo Básico, se o sistema não reconhecer o símbolo de negociação, o sistema notifica o ator que o símbolo não existe. O caso de uso continua do início do passo 3. Detalhe fluxos alternativos Descreva o que Acontece Condição Ações Resuma a Localização Localização

100 Evite Comportamento Condicional em série Torna os cenários difíceis de entender. Mais difícil de implementar e testar. Prefira fluxos alternativos.

101 Evite comportamento repetitivo em série Torna os cenários mais difíceis de identificar. Mais difícil de testar e implementar. Prefira fluxos alternativos.

102 Fluxos alternativos X Comportamento Condicional em série Fluxos alternativos –Prós Pode ser usado em qualquer lugar onde haja comportamento condicional. –REPITA-ATÈ, SE-ENTÃO-SENÃO-FIM-SE Torna os cenários fáceis de identificar. –Isto ajuda a implementação e ao teste –Contras Aumenta a complexidade de manter referências. Comportamento condicional em série –Prós Mais de fácil de lidar nos fluxos com pequenas variações. –Contras Difícil de identificar cenários, testar e implementar.

103 Visualizar comportamento alternativo Cliente Sistema Sis. Cotação

104 Sub-fluxos Melhora a clareza. Permite reuso intermo dos requisitos. Diferente dos fluxos alternativos, são chamados explicitamente. Sempre retorna para a linha de onde foi chamado. Fluxos Alternativos Subfluxos

105 Exemplo de Subfluxo

106 Mantenha a interface do usuário fora do caso de uso Texto não é bom para descrever tela. Casos de uso desconhecem tela. Descreva tela durante Análise com protótipos: –Modele a iteração com tela via protótipo Clique Arrastar Form Abrir Fechar Combo Botão Campo Drop-down Pop-up Rolar Navegar Registro Janela Pergunta Escolhe Inicia Especifica Submete Seleciona Começa Apresenta Informa Palavra a EVITARPalavras para usar

107 Use o glossário efetivamente Glossário Detalhes Cadastrais: informações que identificam unicamente e fornecem informações de contato para um cliente localizado nos EUA. A informação consiste de: Nome, 2 linhas de endereço, cidade, estado, cep, e telefone para contato. Caso de uso Entrar com informações do cliente O sistema requisita ao cliente que informe seus detalhes cadastrais. O cliente informa seus detalhes cadastrais. O cliente cria uma conta. Implementação

108 Pré-condições Descreve em qual estado o sistema deve se encontrar para o início do caso de uso. – Não é o evento que inicia o caso de uso. Reduz a quantidade de validação necessária. Opcional: Use somente se necessário para melhorar o entendimento. Obter Cotação Pré-condição O sistema RU e-st deve se estar conectado com o Sistema de Cotação antes do início do caso de uso.

109 Pós-Condições Descreve em qual estado deve estar o sistema ao fim da execução do caso de uso. –Estado garantido de quando terminar o caso de uso. –Pode conter variações. Opcional: descreva somente se necessário para melhorar o entendimento. Executar Previsão Pós-condição Ao fim do caso de uso todas as contas devem estar atualizadas para refletir as transações que ocorreram.

110 Seqüência do caso de uso com pré e pós Condições Casos de uso não interagem.

111 Outras propriedades dos casos de uso Requisitos especiais –Relacionado a este casos de uso, não coberto pelos fluxos. –Geralmente não funcionais, dados, regras de negócio. Pontos de Extensão –Nomeia com conjunto de locais nos fluxos onde há comportamento de extensão a ser executado. Relacionamentos (Use-Case-Model) –Associações com atores e casos de uso. Diagramas de Casos de Uso –Modelo visual de todos os relacionamentos envolvendo o caso de uso. Outros diagramas e encapsulamentos –Interação, atividade, ou outros diagramas.

112 Dicas para casos de uso Descreva apenas eventos visíveis ao ator: –O que o ator faz. –O que o sistema responde ao ator. O que o caso de uso fornece de valor ao ator. Casos de uso podem ter diferentes níveis de detalhe. –Detalhe até que cada stakeholder tenha um entendimento comum dos requisitos de sua perspectiva, e então pare. Use termos e vocabulário comum a todos. Use linguagem precisa.

113 Checkpoints para casos de uso As iterações e trocas com os atores estão claramente descritas? A seqüência de comunicação entre atores e casos de uso estão em conformidade com as expectativas do cliente? Está claro como e onde os fluxos de caso de uso começam e terminam? Subfluxos estão modelados com precisão?

114 E sobre os requisitos não funcionais? O URPS do FURPS –Usabilidade –Robustez (Confiança) –Performance –Suportabilidade Conformidade com as Leis e Regulamentos –IMMETRO –ANVISA –BC –ISO Restrições de Projeto – Sistema Operacional – Ambientes – Compatibilidade – Padrões de Aplicação F unctionality Feature set Capabilities Generality Security Usability Human factors Aesthetics Consistency Documentation Reliability Frequency/Severity of failure Recoverability Predictability Accuracy MTBF P erformance Speed Efficiency Resource usage Throughput Response time Supportability Testability Extensibility Adaptability Maintainability Compatibility Configurability Serviceability Installability Localizability Robustness

115 Exemplo: Requisitos não funcionais O sistema RU e-st –O sistema deve fornecer cotações de preço com um atraso máximo de 15 minutos. E quanto aos outros? Onde cada um deles devem ser especificados?

116 Especifique Requisitos de Usuabilidade Usabilidade é a facilidade com que o software pode ser aprendido e operado por um usuário. Requisitos de Usabilidade incluem: –Requisitos de tempo de treinamento, tempos de tarefas mensuráveis. –Habilidades do usuário (iniciante/avançado). –Comparação com outros sistemas conhecidos pelo usuário. –Help on-line, dicas, necessidades de documentação. –Conformidade com padrões. Exemplos: Windows, guias de estilo, Padrões de Tela Toda a documentação do usuário deve estar em conformidade com o Manual de Estilo para Documentos Técnicos da Microsoft ®.

117 Especifique requisitos de Confiabilidade Confiabilidade é a capacidade que um software tem de se comportar consistentemente da maneira aceitável pelo usuário. Requisitos de Confiabilidade incluem: –Disponibilidade (xx.xx%) –Acurácia –MTBF (xx hrs) –Max. bugs per/KLOC (0-x) O relatório de velocidade da cápsula não tripulada de Marte deve ser em unidade de metros por segundo e estar entre 1 até 1e6.

118 Especifique Requisitos de Performance Performance é a medida de velocidade ou eficiência de um sistema em execução. Requisitos de performance incluem: –Capacidade –Throughput –Tempo de resposta - Memória - Modo de degradação - Use de recursos limitados - Processador, memória, disco, banda de rede Não há mais do que 4 protocolos de troca, tamanhos não menores do que 512k bytes cada, entre cliente e servidor para a troca de dados.

119 Especifique requisitos de Suportabilidade Suportabilidade é a capacidade do software em ser facilmente modificável para acomodar melhorias e reparos. Requisitos de suportabilidade incluem: –Linguagens, SGDB, ferramentas, e etc. –Padrões de programação. –Manipulação de erros e padrões de relatório. Difícil de especificar –Se não mensurável ou observável, assim não é requisito. –É uma restrição de projeto? –É uma intenção ou um objetivo?

120 Como descrever protocolos de comunicação Especifique um protocolo de comunicação se o ator é um sistema externo ou um outro hardware. –A descrição do caso de uso pode estabelecer se um determinado protocolo é usado. –Se o protocolo é novo, ele será totalmente descrito no desenvolvimento orientado a objetos.

121 Estruturar Modelos de Casos de Uso Como estruturar modelos? –Transformar partes de casos de uso em novos casos de uso. Por que estruturar o modelo de casos de uso? –Simplificar os casos de uso originais. Tornar mais fácil de entender. Tornar mais fácil de manter. –Reuso de Requisitos. Compartilhar pelos diversos casos de uso.

122 Relacionamentos entre CSUs Include Extend Generalização «include» «extend»

123 O que é um relacionamento de Include? O relacionamento entre um caso de uso origem com um caso de uso incluído. O comportamento do caso de uso incluído é explicitamente incluído dentro do caso de uso de origem. «include» Origem Inclusão

124 Relacionamento de Inclusão Caso de Uso de Identificar Cliente 1. Autenticar 2. Validar autenticação 3. Entrar com senha 4. Validar senha A1: Autenticação inválida A2: Senha errada A3:... Caso de Uso de Obter Cotação 1. Inclui Identificar Cliente para verificar a identidade do cliente 2. Mostrar Opções. O Cliente seleciona Obter Cotação Executar Negociação Obter Cotação Identificar Cliente Outro caso de uso «include» Trading Customer

125 Execu ç ão de um relacionamento de inclusão Totalmente executado quando o ponto de inclusão é alcançado. Instância de Caso de Uso Base Caso de Uso Incluído

126 Por que utilizar um relacionamento de inclusão? –Cortar comportamento comum entre 2 ou mais casos de uso. Evitar descrever o mesmo comportamento duas vezes. Assegurar comportamento igual em vários outros pontos. –Cortar e encapsular comportamento comum. Simplificar fluxos de eventos complexos. Cortar partes não primárias do comportamento. «include» Base inclusão Por que?

127 O que é um relacionamento de Extend? Conecta um ponto de extensão de um caso de uso a um ponto do caso de uso base. –Insere um ponto de comportamento extensível para um caso de uso base. –Insere apenas se uma condição for verdadeira. –Insere no caso de uso base um ponto de extensão nomeado. «extend» Extension Base

128 Relacionamento de Extensão: Exemplo RU e-st Obter Previsões Obter Notícias Obter Cotação «extend» Cliente de Negociações Sistema especialista em cotações Sistema novo

129 Relacionamento de Extensão Caso de Uso Obter Cotação Fluxo Básico: 1. Incluir Identificar Cliente para verificar identidade do cliente. 2. Apresentar Opções. 3. Cliente seleciona Obter Cotação. 4. Cliente obtêm cotação. 5. Cliente obtêm outras cotações. 6. Cliente faz logs off. A1. Sistema de cotação fora … Pontos de Extensão: O ponto de extensão Serviços Opcionais ocorre no passo 3 do Fluxo Básico e passo A1.7 no fluxo alternativo Sistema de cotação fora. Caso de Uso Obtêm Notícias Este caso de uso extende o caso de Obter cotações, no ponto de extensão Serviços Opcionais. Fluxo Básico: 1. Se o cliente selecionar Obter notícias, o sistema pergunta ao cliente o intervalo de tempo e a quantidade de itens de notícia. 2. O cliente informa os dados. O sistema envia o símbolo de cotação de ações ao sistema de Notícias, recebe a resposta, e apresenta as notícias ao cliente. 3. O caso de uso Obter cotações continua. A1: Sistema indisponível A2: Sem notícias para a cotação da ação …

130 Execução de um Extend Executado quando o ponto de extensão é alcançado e a condição de extensão válida. Instância de Caso de Uso Caso de Uso Base Caso de Uso Extendido Ponto de Extensão

131 Por que usar um relacionamento de Extend? Recortar comportamento excepcional ou alternativo. –Executado somente sob certas circunstâncias. –Recortar simplifica o fluxo de eventos no caso de uso base. –Exemplo: Disparar Alarmes. Adicionar Comportamento de Extensão. –Comportamento desenvolvido separadamente, possivelmente em versão posterior. « extend » Extensão Base

132 Caso de Uso Concreto versus Abstrato Caosos de Uso Abstratos (A & D): Não tem de ser completos. Existem somente em conjunto com outros casos de uso. Não possuem sua própria instância. Um caso de uso pode ser concreto ou abstrato. «extend» «include» Concrete use cases (B & C): Tem que ser completos e claros. Possuem suas próprias instâncias. A D C B Dica: Mesmo retirando todos os casos de uso abstratos você ainda é capaz de entender o sistema

133 Por que não estruturar o Modelo de Casos de Uso? - A solução é mais difícil de ver quando o casos de uso é fragmentado. - Decomposição de Caso de Uso. - Diminui entendimento. - Aumenta complexidade. - Aumenta esforço de revisores, testadores e desenvolvedores. - Nem todos os stakeholders estão confortáveis com o formato. - O Modelo de caso de uso se parece com o design. «include» Base Inclusão Por que não? «extend» Extensão Filho

134 Atores podem ter características comuns. Múltiplos atores podem ter papéis ou propósitos comuns ao interagir com os casos de uso. O que é Generalização de Ator? Filho 1 Filho 2 Pai

135 Pai: Medical Worker –Servidor Hospitalar pode ler prontuário Filhos: Doutor, Enfermeira, Auxiliar –Doutor, Enfermeira, e Auxiliar podem ler prontuário Generalização de Atores Ler Prontuário Enfermeira Auxiliar Servidor Hospitalar Doutor Agendar Operação

136 Por que generalizar atores? Simplifica o relacionamento entre vários atores e casos de uso. Mostra que o comportamento do pai é herdado pelos filhos. Representa diferentes níveis de segurança. Filho 1 Filho 2 Pai

137 Atores concretos versus abstratos Um ator abstrato contém a parte comum dos papéis. –Não podem ser instanciados. –Exemplo: Ninguém terá o cargo: servidor médico. Um ator concreto pode ser instanciado. –Exemplo: Lauren é Doutora. Daniel é enfermeiro. DoutorEnfermeira Funcionário de Medicina

138 Guias para a modelagem de casos de uso Notações para usar e não usar. –Por exemplo, quando usar relacionamento de generalização. Papéis, recomendações, estilos, e como descrever um caso de uso. Recomendações de quando começar a estruturar os casos de uso(não tão cedo).


Carregar ppt "Curso de Requisitos Módulo 03: Requisitos de Software Requisitos de Software, Técnicas de Levantamento, Identificação dos Problemas, Necessidades e Principais."

Apresentações semelhantes


Anúncios Google