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?
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.
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
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.
Exercício

Levantar requisitos suplementares do
sistema.
Workflow de Requisitos - Visão da Atividade
Analista de
Sistema
Desenvolver
Elicitar
Documento de Visão necessidades
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
Interface com o Usuário
Projetista da
Interface com o Usuário
Arquiteto
Revisor de
Requisitos
Priorizar UC
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.
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.
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.
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.
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.
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.
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.
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
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.
Prototipar 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 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 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 Casos
de Uso
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
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

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 uso

Reuniões
 conversas

com usuários
Storyboarding
 simulação
através de desenhos das interfaces
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?


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 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 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 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í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
casos de uso
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 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 Uso



Deve ser única!
Não deve mudar nunca
Pois casos de uso podem ser referenciados por
seu identificador
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!
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
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!
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
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!
Exercícios

Descrever o fluxo básico dos casos de uso
levantados anteriormente.