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

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

Análise e Gerenciamento de Requisitos com Casos de Uso Módulo 2 Introdução ao Gerenciamento de Requisitos com Caso de Uso.

Apresentações semelhantes


Apresentação em tema: "Análise e Gerenciamento de Requisitos com Casos de Uso Módulo 2 Introdução ao Gerenciamento de Requisitos com Caso de Uso."— Transcrição da apresentação:

1 Análise e Gerenciamento de Requisitos com Casos de Uso Módulo 2 Introdução ao Gerenciamento de Requisitos com Caso de Uso

2 Objetivos Definir os conceitos-chave da gerência de requisitos. Identificar os fatores que contribuem para o sucesso ou falha do projeto. Descrever como o Gerenciamento de Requisitos aumenta as chances de sucesso do projeto. Definir as qualidades de um conjunto de requisitos. –verificável, rastreável, não ambíguo. Conhecer o Workflow de gerência de requisitos com UP, papéis, e artefatos.

3 Algumas situações familiares… Nós construímos tudo o que vc pediu! Certo, mas não é o que eu quero Por que vc não nos disse que queria aquela funcionalidade? Você não perguntou! Hummm... Eu acho que ele faz desse jeito! Eu tive uma idéia para uma função nova, você deixa a gente colocá-la no sistema? Sem problema!

4 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

5 Definições Requisitos –Uma necessidade do processo de negócio que o sistema deverá sanar. 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. Controlar e registrar a evolução do atendimento aos requisitos.

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

7 Definições Requisições do Stakeholder Expressam as características e restrições do produto de software do ponto de vista de satisfação das necessidades do steakholder. Requisitos de Software Requisito Funcional Descrição das funções que os steakholders precisam que o software faça. Definem a funcionalidade desejada do software. Requisito não funcional Qualidades técnicas globais de um software, como manutenibilidade, usabilidade, desempenho e várias outras. Normalmente são descritos de maneira informal, controversa, e são difíceis de validar. 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.

8 Exemplo: Sistema de Matrícula 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 a opção de menu Matricular. 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 para visualizar a grade de aulas, por semestre e por turma.

9 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

10 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

11 Gerência de Requisitos Não é Fácil Requisitos: –Nem sempre são óbvios. –Vêm de várias fontes. –Nem sempre é fácil de expressar claramente em palavras. –São inter-relacionados e relacionados a outras entregas do processo de desenvolvimento de software. –Tem propriedades únicas. –Mudam. –São difíceis de controlar quando em grande número.

12 Gerenciamento Requer Estratégia RM Plan

13 Gerenciamento Efetivo de Requisitos 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 às reais necessidades do usuário.

14 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 Resultados Paradigma baseado em atividades

15 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 (Confiabilidade) Frequência / severidade da falha, recuperabilidade, previsibilidade, MTBF (Mean Time Between Failures ) P erformance Velocidade, uso de recursos, processamento, tempo de resposta Supportability Testabilidade Extensível Adaptabilidade Manutenível Compatibilidade Configurável DisponibilidadeInstalável LocalizávelRobustez

16 No Prazo e No Custo Tempo Quanto de trabalho nós podemos fazer? Recursos Orçamento Scope Escopo

17 Atendendo às 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 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

18 Possibilitar acordo entre os envolvidos Objetivos de sistema Verificação Requisitos Cliente Grupo de Usuários Sistema a ser construído Requisitos O Objetivo

19 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 28% dos projetos completados no prazo e custos. 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 Standish Group, 99 (www.standishgroup.com)

20 Tamanho é importante Taxa de Sucesso (%) Standish Group, 99 (www.standishgroup.com) Sucesso pelo Tamanho do Projeto Tamanho do Projeto ($) Menos de $750K $750K a $1.5M $1.5M a $3M $3M a $6M $6M a $10M Mais de $10M

21 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 Os resultados mostram como corrigir erros encontrados nos requisitos custa até 200 vezes menos do que em estágios mais avançados do ciclo de vida Boehm 1988 A regra do

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

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. Leffingwell & Widrig (1999). IEEE , § 4.3.2, 1994

24 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 Qualidades do Conjunto de requisitos de software

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 leiaute... 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 especifica componentes de um sistema ou suas interfaces com outros sub-componentes. Como saber se os requisitos estão sendo atendidos. Um caso de teste especifica uma forma de testar um cenário de caso de uso. 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 Adapted from Alan Davis O que NÃO é um Requisito? Verificação Dados de Projeto

29 Artefatos Usados para Gerenciar Requisitos 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

30 Revisão: Introdução ao RMUC 1.O que é um Requisito? 2.O que é Gerenciamento de Requisitos? 3.Que fatores contribuem para o sucesso do projeto? 4.Quais membros da equipe são envolvidos na Gerência de Requisitos e como? 5.Saberia explicar a regra de ? 6.Quais são algumas das qualidades dos requisitos? 7.Quais são alguns dos tipos de requisitos não- funcionais? 8.Por que usar UML? 9.Por que usar um processo de desenvolvimento?


Carregar ppt "Análise e Gerenciamento de Requisitos com Casos de Uso Módulo 2 Introdução ao Gerenciamento de Requisitos com Caso de Uso."

Apresentações semelhantes


Anúncios Google