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

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

Curso de Requisitos Módulo 02: 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 02: 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 02: 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 Propriedade medida Velocidade trans. Devem proc. 5 seg Tamanho K bytes Usabilidade tempo de treinamento/ quadros de ajuda Confiabilidade tempo médio de falhas/ tx de ocorrencia de falhas Portabilidade sistemas operacionais utilizados

8 Tipos de não funcionais Produto : confiabilidade,segurança, desempenho, capacidade e portabilidade Organização : métodos, linguagens e ferramenta ex.: linguagem livre Externo : legado de dados q não pertence a organização, legislação

9 Requisitos de Domínio Características das regras de negócio do sistema ex.: no Rup tem um repositório para descrever as regras o cliente pode sacar no máximo 5 mil reais por dia - o cliente pode retirar no máximo 3 vídeos por dia - prazo entrega de no máximo de 3 dias para qualquer qtde pega - para usar o TED só com valores acima de 5 mil - o cadastro tem que ser renovado a cada ano - ter cuidado de não colocar validação

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

12 Gerenciamento Requer Estratégia RUCS10: RM Plan

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

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

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

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

17 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

18 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

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

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

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

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

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

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

26 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

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

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

29 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

30 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

31 RUP: Um Framework para Gerência de Requisitos

32 Disciplina de Requisitos: Detalhes do Workflow

33 Papéis e Artefatos

34 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

35 Onde estamos na disciplina de Requisitos?

36 Análise do Problema: Atividades e Artefatos

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

38 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

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

40 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

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

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

43 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

44 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

45 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

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

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

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

49 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

50 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

51 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

52 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

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

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

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

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

57 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

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

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


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

Apresentações semelhantes


Anúncios Google