N Devem ser testáveis, para isso devem ser mensuráveis! n Precisam estar definidos em números e...

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.