Requisitos Não funcionais

Apresentação em tema: "Requisitos Não funcionais"— Transcrição da apresentação:

1 Requisitos Não funcionais
Devem ser testáveis, para isso devem ser mensuráveis! Precisam estar definidos em números e nomes O sistema precisa ser rápido. Quão rápido? O sistema deve ser implementado numa plataforma madura. Que plataforma?

2 Requisitos Não funcionais
Redefinindo os requisitos… O sistema deve responder em menos de 10 segundos. O núcleo do sistema deve ser implementado no sistema operacional Unix/Solaris.

3 Requisitos não funcionais x casos de uso
Associados a um caso de uso específico Associados a todo o sistema Para serem atendidos podem gerar casos de uso

4 Requisitos não funcionais x casos de uso
Requisito não funcional genérico: O sistema deve ser implementado na plataforma Windows. Requisito não funcional associado a um caso de uso: No caso de uso “Sacar dinheiro”, o tempo de resposta para o cliente não pode ser maior que 1 minuto.

5 Exercício Levantar requisitos suplementares do sistema.

6 Workflow de Requisitos - Visão da Atividade
Analista de Sistema Desenvolver Documento de Visão Elicitar necessidades dos Stakeholders Encontrar Atores e Casos de Uso (Use Cases) Revisor de Requisitos Especificador de UC Gerenciar Dependências Capturar um vocabulário comum Detalhar um UC Modelar a Interface com o Usuário Revisar os Prototipar a Arquiteto Estruturar o Modelo de UC Priorizar UC Projetista da Interface com o Usuário

7 Desenvolver Documento de Visão
Nesta atividade, o Analista de Sistemas deve identificar os stakeholders, definir os limites do sistema e descrever as características primárias do sistema. A execução da atividade deve produzir o documento de Visão que é uma visão geral dos requisitos do projeto.

8 Gerenciar de Dependências
Nesta atividade, o Analista de Sistemas deve obter um entendimento dos atributos dos requisitos, o que auxilia no gerenciamento do escopo do projeto e da aplicação. A execução da atividade deve produzir os artefatos Atributos dos Requisitos, Diretrizes de Atributos de Requisitos e a Visão dos Requisitos.

9 Elicitar Necessidades dos Stakeholders
Nesta atividade, o Analista de Sistemas deve entender o que os stakeholders esperam do sistema, coletar informações e necessidades que o sistema deveria cumprir e priorizar as necessidades dos stakeholders. A execução da atividade tem como artefatos resultantes o documento de Necessidades dos Usuários e o Modelo de caso de uso, brevemente esboçado.

10 Capturar um Vocabulário Comum
Nesta atividade, o Analista de Sistemas deve definir um vocabulário comum que pode ser usado em descrições dos sistema. A execução da atividade deve produzir um Glossário.

11 Encontrar Atores e Casos de Uso
Nesta atividade, o Analista de Sistemas esboça a funcionalidade do sistema, define o que será feito pelo sistema e o que será feito fora do sistema, define quem e o que interagirá com o sistema, divide o modelo em pacotes com atores e casos de uso e cria os diagramas do modelo de casos de uso. A execução desta atividade produz o Modelo de Casos de Uso, os casos de uso e Especificações Suplementares.

12 Priorizar Casos de Uso Nesta atividade, o Arquiteto deve definir a entrada para a seleção do conjunto de cenários e casos de uso que serão analisados na iteração atual, o conjunto de cenários e casos de uso que representam alguma funcionalidade significativa e o conjunto de casos de uso que têm uma cobertura arquitetural substancial ou que ilustram um ponto específico e delicado da arquitetura. A execução da atividade deve produzir o documento de Arquitetura de Software e um refinamento do Glossário e do Plano de Iteração.

13 Estruturar o Modelo de Casos de Uao
Nesta Atividade, o Analista de Sistemas extrai o comportamento dos casos de uso que necessitam ser considerados como abstratos e encontra novos atores abstratos que definem papéis que são compartilhados por vários atores. A execução desta atividade tem como objetivo o refinamento do Modelo de Casos de Uso.

14 Detalhar os Casos de Uso
Nesta atividade, o Especificador de Casos de Uso descreve o fluxo de eventos dos casos de uso em detalhes e, também, de forma que o cliente e os usuários possam entender. A execução da atividade tem como resultado a descrição Casos de Uso Complementares, as Especificações Suplementares e os Atributos dos Requisitos

15 Modelar a Interface com o Usuário
Nesta atividade, o Designer de Interface com o Usuário constrói um modelo de interface com o usuário que suporta o melhoramento da usabilidade. A execução desta atividade produz os StoryBoards dos casos de uso, os Atores caracterizados pela perspectiva da usabilidade e as Classes de Fronteira, representando janelas da interface com o usuário.

16 Prototipar a Interface com o Usuário
Nesta atividade, o Designer de Interface com o Usuário deve criar um protótipo de interface.

17 Revisar os Requisitos Nesta atividade, o Revisor de Requisitos formalmente verifica os resultados do Workflow de Requisitos conforme a visão do cliente do sistema. A execução da atividade deve apresentar como resultado uma versão aprovada ou rejeitada com as respectivas alterações da Visão dos Requisitos, do Modelo de Casos de Uso, das Especificações Suplementares e do Glossário.

18 Requisitos - Visão dos Artefatos
Analista de Sistema Especificador de UC Responsável por Responsável por Atributos dos Requisitos Casos de Uso Visão Necessidades dos Stakeholders Modelo de Use Case Especificação Suplementar Glossário Pacote de Use Case Arquiteto Projetista da Interface com o Usuário Revisor de Requisitos Responsável por Responsável por Documento de Arquitetura de Software Classes de Fronteira UC Storyboard Protótipo da Interface com o usuário

19 Relacionamento entre os artefatos de requisitos x artefatos de outros workflows
Necessidades dos Stakeholders Modelo de Casos de Uso Documento de Visão Especificação Suplementar Material de Documentação do Usuário Final e Material de Treinamento Teste Projeto

20 Como encontrar atores e casos de uso?

21 Técnicas para levantar casos de uso
Workshop de casos de uso não pode ter muita gente pessoas com diferentes perfis presença de um facilitador aceite todo tipo de sugestão e filtre depois! evite pensar em detalhes os casos de uso levantados devem estar claros para todos! principalmente o valor que estes agregam ao usuário consulte todos! dê sugestões

22 Técnicas para levantar casos de uso
Reuniões conversas com usuários Storyboarding simulação através de desenhos das interfaces

23 Como encontrar atores? Quem usa o sistema?
Quem instala/mantém o sistema? Quem inicia/desliga o sistema? Que outros sistemas usam o sistema? Quem recebe informação do sistema? Quem provê informação ao sistema?

24 Como encontrar casos de uso?
Atores são fundamentais para a descoberta dos casos de uso Pergunte Que funções o ator vai querer do sistema? O sistema armazena informações? Que informações atores irão criar, ler, atualizar ou apagar? O sistema precisa notificar o ator sobre mudanças no seu estado interno? Existe algum evento externo que o sistema precisa saber? Que ator informa o sistema destes eventos?

25 Encontrando casos de uso
Casos de uso não precisam ser descritos todos de uma vez: o processo é iterativo Casos de uso devem ser priorizados por iteração (técnica e por prioridade do usuário)

26 Casos de Uso devem ser Unidades testáveis e auto-contidas!
Isso facilita: distribuição de tarefas entre os desenvolvedores gerenciamento do cronograma planejamento e realização de testes unitários integração do sistema Sem isso, não é viável um desenvolvimento iterativo e incremental! O escopo de um caso de uso deve ser limitado. The Scope of a Use Case It is often hard to decide if a set of user-system interactions, or dialog, is one or several use cases. Consider the use of a recycling machine. The customer inserts deposit items, such as cans, bottles, and crates, into the recycling machine. When she has inserted all her deposit items, she presses a button, and a receipt is printed. She can then exchange this receipt for money. Is it one use case to insert a deposit item, and another use case to require the receipt? Or is it all one use case? There are two actions, but one without the other is of little value to the customer. Rather, it is the complete dialog with all the insertions, and getting the receipt, that is of value for the customer (and makes sense to her). Thus, the complete dialog, from inserting the first deposit item, to pressing the button and getting the receipt, is a complete case of use, a use case. Additionally, you want to keep the two actions together, to be able to review them at the same time, modify them together, test them together, write manuals for them and in general manage them as a unit. This becomes very obvious in larger systems.

27 Os requisitos SEMPRE mudam
Atualizar a documentação é fundamental! Lembre-se que os casos de uso serão utilizados para testes e documentação do usuário!!!

28 Exercícios Escrever a descrição geral sistema (descrição do problema)
(em meia página) Levantar atores: listar e descrevê-los (em 1 linha!) Levantar casos de uso: listar e descrevê-los (em 2 ou 3 linhas!)

29 Especificação detalhada de casos de uso

30 Quando e por que realizá-las?
após fazer levantamento dos principais casos de uso do sistema Por que? descrever detalhes do caso de uso descrever fluxo de eventos e outras propriedades uniformizar entendimento entre clientes, usuários e equipe de desenvolvimento

31 Descrevendo um caso de uso
Breve descrição Ator Prioridade Interfaces Associadas (opcional) Entradas e Pré-condições Saídas e Pós-condições Fluxo de eventos principal Fluxos secundários: alternativos e de exceção (opcional)

32 Identificação do Caso de Uso
Deve ser única! Não deve mudar nunca Pois casos de uso podem ser referenciados por seu identificador

33 Pré- e Pós-condições Entradas e Pré-condições Saídas e Pós-condições
O que deve ser verdade antes e depois da realização do caso de uso!

34 Pré- e Pós-condições: exemplos
Caso de uso “Entregar pedido” Pre-condição: os itens do pedido devem ter em estoque Pós-condição: os itens enviados devem ser abatidos do estoque Caso de uso “Recadastramento de CPF” Pre-condição: o usuário deve possuir um CPF Pós-condição: a situação do contribuinte é atualizada

35 Fluxo de eventos básico
Série de passos que compõem um caso de uso Concentre-se inicialmente na funcionalidade básica/central do caso de uso Pense nos fluxos secundários depois!

36 Exemplo de um fluxo básico
Caso de uso “Sacar dinheiro” 1. O cliente passa o seu cartão 2. Digita sua senha 3. Digita o valor do saque 4. O sistema verifica se há saldo suficiente 5. O saldo é debitado da conta do cliente 6. O dinheiro é entregue ao cliente

37 Exemplo de um fluxo básico
Caso de uso “Sacar dinheiro” MAS... E se a senha não conferir? E se não houver saldo? E se não houver dinheiro suficiente na máquina? Calma, vamos deixar estes detalhes para depois!

38 Exercícios Descrever o fluxo básico dos casos de uso levantados anteriormente.