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?
Requisitos Não funcionaisRequisitos Não funcionais
Requisitos Não funcionaisRequisitos 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.
Requisitos não funcionais xRequisitos não funcionais x casos de uso casos de uso
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 xRequisitos não funcionais x casos de uso 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.
ExercícioExercício
Levantar requisitos suplementares do sistema.
Workflow de Requisitos - Visão da AtividadeWorkflow de Requisitos - Visão da Atividade
Projetista daInterface com o Usuário
Analista de Sistema
DesenvolverDocumento de Visão
Elicitar necessidades
dos Stakeholders
Encontrar Atores eCasos de Uso (Use Cases)
Revisor deRequisitos
Especificadorde UC
GerenciarDependências
Capturar umvocabulário comum
Detalhar um UC
Modelar aInterface com o Usuário
Revisar os Requisitos
Prototipar aInterface com o Usuário
Arquiteto
Estruturar oModelo de UC
Priorizar UC
Desenvolver Documento de VisãoDesenvolver 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.
Gerenciar de DependênciasGerenciar 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.
Elicitar Necessidades dos StakeholdersElicitar 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.
Capturar um Vocabulário ComumCapturar 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.
Encontrar Atores e Casos de UsoEncontrar 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.
Priorizar Casos de UsoPriorizar 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.
Estruturar o Modelo de Casos de UaoEstruturar 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.
Detalhar os Casos de UsoDetalhar 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
Modelar a Interface com o UsuárioModelar 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.
Prototipar a Interface com o UsuárioPrototipar a Interface com o Usuário
Nesta atividade, o Designer de Interface com o Usuário deve criar um protótipo de interface.
Revisar os RequisitosRevisar 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.
Requisitos - Visão dos ArtefatosRequisitos - Visão dos Artefatos
Analista de Sistema
Visão Necessidades dos Stakeholders
Modelo deUse Case
EspecificaçãoSuplementar
Glossário Atributos dosRequisitos
Casosde Uso Pacote de
Use Case
Especificadorde UC
Responsável por Responsável por
Arquiteto
Documentode Arquiteturade Software
Responsável porProjetista
da Interface com o Usuário
UCStoryboard
Protótipo daInterface com o usuário
Classes de Fronteira
Responsável por
Revisor deRequisitos
Relacionamento entre os artefatos de Relacionamento entre os artefatos de requisitos x artefatos de outros workflowsrequisitos x artefatos de outros workflows
Necessidadesdos Stakeholders
Modelo de Casos de Uso
Documento de Visão
EspecificaçãoSuplementar
Material de Documentaçãodo Usuário Final e
Material de TreinamentoModelo de
Teste
Modelo de Projeto
Como encontrar atores eComo encontrar atores ecasos de uso?casos de uso?
Técnicas para levantar casos de usoTé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
Técnicas para levantar casos de usoTécnicas para levantar casos de uso
Reuniões conversas com usuários
Storyboarding simulação através de desenhos das interfaces
Como encontrar atores?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?
Como encontrar casos de uso?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?
Encontrando casos de usoEncontrando 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)
Casos de Uso devem serCasos 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.
Os requisitos SEMPRE mudamOs 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!!!
ExercíciosExercí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!)
Especificação detalhada de Especificação detalhada de casos de usocasos de uso
Quando e por que realizá-las? 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
Descrevendo um caso de usoDescrevendo 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)
Identificação do Caso de UsoIdentificação do Caso de Uso
Deve ser única! Não deve mudar nunca
Pois casos de uso podem ser referenciados por seu identificador
Pré- e Pós-condiçõesPré- 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!
Pré- e Pós-condições: exemplosPré- 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
Fluxo de eventos básicoFluxo 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!
Exemplo de um fluxo básicoExemplo de um fluxo básico
Caso de uso “Sacar dinheiro”
1. O cliente passa o seu cartão2. Digita sua senha3. Digita o valor do saque4. O sistema verifica se há saldo suficiente5. O saldo é debitado da conta do cliente6. O dinheiro é entregue ao cliente
Exemplo de um fluxo básicoExemplo 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!
ExercíciosExercícios
Descrever o fluxo básico dos casos de uso levantados anteriormente.