Requisitos Não funcionais

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. Desenvolver Documento de Visão Elicitar necessidades dos Stakeholders Analista de Sistema Revisor de Requisitos Encontrar Atores e Casos de Uso (Use Cases) Gerenciar Dependências Capturar um vocabulário comum Estruturar o Modelo de UC Detalhar um UC Revisar os Requisitos Especificador de UC Prototipar a Interface com o Usuário Modelar a Interface com o Usuário Priorizar UC Arquiteto Workflow de Requisitos - Visão da Atividade 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 Casos de Uso Atributos dos Requisitos Necessidades dos Stakeholders Visão 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. Documento de Visão Especificação Suplementar Modelo de Casos de Uso Necessidades dos Stakeholders Material de Documentação do Usuário Final e Material de Treinamento Modelo de Projeto Modelo de Teste Relacionamento entre os artefatos de requisitos x artefatos de outros workflows

20. Como encontrar atores ecasos 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.

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? • Quando? • 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.