Requisitos No funcionais n n Devem ser testveis

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

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

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

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

Exercício n Levantar requisitos suplementares do sistema.

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

Desenvolver Documento de Visão n 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.

Gerenciar de Dependências n 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.

Elicitar Necessidades dos Stakeholders n 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.

Capturar um Vocabulário Comum n 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.

Encontrar Atores e Casos de Uso n 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.

Priorizar Casos de Uso n 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.

Estruturar o Modelo de Casos de Uao n 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.

Detalhar os Casos de Uso n 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

Modelar a Interface com o Usuário n 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 Story. Boards dos casos de uso, os Atores caracterizados pela perspectiva da usabilidade e as Classes de Fronteira, representando janelas da interface com o usuário.

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

Revisar os Requisitos n 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.

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

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

Como encontrar atores e casos de uso?

Técnicas para levantar casos de uso n Workshop de casos de uso u u u u u 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

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

Como encontrar atores? n n n 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?

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

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

Casos de Uso devem ser n Unidades testáveis e auto-contidas! n Isso facilita: n n u distribuição de tarefas entre os desenvolvedores u gerenciamento do cronograma u planejamento e realização de testes unitários u 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.

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

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

Especificação detalhada de casos de uso

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

Descrevendo um caso de uso n n n n 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)

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

Pré- e Pós-condições n n n 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!

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

Fluxo de eventos básico n n n 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!

Exemplo de um fluxo básico n 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

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

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