Engenharia de Software
Fluxo de Requisitos
Alexandre Monteiro
Objetivos:


Entender os conceitos básicos do fluxo de Requisitos e
como eles afetam a Análise e Projeto
Entender como ler e interpretar os artefatos gerados
por este fluxo
Finalidade do fluxo de requisitos
A finalidade deste fluxo é:
• Chegar a um acordo com o cliente e o usuário sobre o que
o sistema deve fazer.
• Oferecer ao desenvolvedor um melhor entendimento dos
requisitos do sistema.
• Delimitar o escopo sistema.
• Prover uma base para o planejamento do conteúdo
das iterações.
• Definir uma interface do sistema com o usuário.
Artefatos mais relevantes do fluxo de
requisitos
Modelo de caso de uso
Descrição do Atributos
Problema
dos Requisitos
Atores
Casos de Uso
Glossário
Matriz de
rastreabilidade
...
Especificações
Suplementares
Especificações de Caso de Uso
Descrição do problema (documento de
visão)

Mostra a descrição geral do problema a ser resolvido
com o sistema, bem como as funcionalidades básicas
do sistema.
Descrição do
problema
Glossário
• Introdução
• Termos
Glossário
Modelo de casos de uso
• Introdução
• Pacotes de casos de uso
•Diagramas de
casos de uso
•Especificações de
casos de usos
Modelo de
casos de uso
Atores
Casos de Uso
Especificações de Casos de Uso
Modelo de casos de uso
Use Cases
direcionam o
trabalho desde os
requisitos até os
testes
Realizado por
Verificado por
Implementado por
Exemplo de Diagrama de casos de uso
Solicitar extrato
Consultar saldo
Cliente
Sacar dinheiro
Realizar depósito
Transferir
entre contas
Alterar senha
Especificação de caso de uso
• Breve descrição
• Ator
• Prioridade
• Interfaces Gráficas
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)
Modelo de caso de uso
Atores
Casos de Uso
...
Especificações de Use Case
Fluxos de eventos x diagramas de
atividades

Diagramas de atividades:
 Podem
ser usados para representar
graficamente o fluxo de eventos (fluxo básico +
fluxos alternativos)
 São
compostos de:
 atividades
 transições
 decisões
Diagrama de atividades


São um caso especial dos Diagramas de
Estados, com a maioria das transições
resultantes do término das atividades.
São muito usados para modelar atividades
concorrentes.
Diagrama de atividades: exemplo
Especificações suplementares
• Descrevem requisitos não-funcionais:
•Confiabilidade
•Desempenho (performance)
•Segurança
•Distribuição
•Adequação a Padrões
•Restrições de Hardware e Especificações Suplementares
Software
•etc.
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 robusta. Que plataforma?
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 novos
casos de uso
Fluxo de Requisitos - Visão da Atividade
Analista de
Sistema
Desenvolver
Elicitar
Documento de
necessidades
Visão
dos Stakeholders
Gerenciar
Dependências
Encontrar Atores e
Capturar um Casos de Uso
vocabulário comum
Detalhar UC
Especificador
de UC
Revisor de
Requisitos
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
Estruturar o
Modelo de UC
Priorizar UC
Atividade: 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
apresenta uma visão geral dos requisitos do
projeto.
Atividade: Gerenciar 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 o artefato Atributos
dos Requisitos e Matriz de Rastreabilidade.
Atividade: 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 deve cumprir e priorizar as
necessidades dos stakeholders. A execução da
atividade tem como artefatos resultantes o
documento de Necessidades dos Stakeholders
e o Modelo de casos de uso, brevemente
esboçado.
Atividade: 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 o Glossário.
Atividade: 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 e
as Especificações Suplementares.
Agrupamento de casos de uso

Dividir os casos de uso em pacotes
 Ator
 Funcionalidades
 Processos
correlatas
Atividade: Priorizar Casos de Uso

Nesta atividade, o Arquiteto deve definir o
conjunto de cenários de 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 uma
versão inicial do documento de Arquitetura de
Software e um refinamento do Glossário e do
Plano de Iteração.
Prioridades de Casos de Uso


Essencial para gerenciar os requisitos e para
montar as iterações
Deve-se definir as prioridades de todos os
casos de uso, as quais podem ser:
 Essencial
 Importante
 Desejável
Atividade: Estruturar o Modelo de Casos de
Uso

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
outros atores. A execução desta atividade
produz um refinamento do Modelo de Casos de
Uso.
Por que estruturar o modelo?



Extrair descrições de funcionalidades genéricas
e compartilhadas que podem ser usadas por
mais de um caso de uso.
Extrair descrições de funcionalidades
adicionais que possam estender descrições
específicas
Facilitar o entendimento do modelo
Relacionamentos entre casos de uso

Inclusão

Extensão

Generalização
Relacionamento entre atores: generalização

Quando um ator A realiza todos os casos
de uso que o ator B, dizemos que A
estende B.
Vendedor
Supervisor
Realizar venda
Estabelecer crédito
Atividade: Detalhar Casos de Uso

Nesta atividade, o Especificador de Casos de
Uso descreve o fluxo de eventos dos casos de
uso em detalhes de forma que o cliente e os
usuários possam entender. A execução da
atividade tem como resultado a descrição de
Casos de Uso, as Especificações
Suplementares e os Atributos dos Requisitos e
Matriz de Rastreabilidade atualizados
Quando e por que detalhar os casos de
uso?

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
Fluxo de eventos básico


Série de passos que compõem um caso de
uso
Sugestões:
 Concentre-se
inicialmente na funcionalidade
básica/central do caso de uso
 Pense nos fluxos secundários depois!
Fluxos secundários


Só devem ser analisados e descritos após a
descrição dos fluxos básicos.
Fluxos alternativos
 situações
especiais (saque além do limite para
um cliente especial)

Fluxos de erro
 situações
de erro
Atividade: 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 e a definição
das Classes de Fronteira, representando
janelas da interface com o usuário.
Atividade: Prototipar a Interface com o
Usuário

Nesta atividade, o Designer de Interface com o
Usuário deve criar um protótipo de interface
gráfica.
Protótipo de interface com o usuário

Ferramenta para compreensão do caso de
uso
o
nível de detalhes deve ser adequado ao
usuário

Facilidade para a descrição de críticas
básicas
 tamanho
e tipo dos campos
 máscaras
de edição
Atividade: Revisar os Requisitos

Nesta atividade, o Revisor de Requisitos
formalmente verifica os resultados do fluxo 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 dos artefatos de requisitos.
Checklists: Modelo de Casos de Uso





O modelo de caso de usos está fácil de se entender?
Estudando o modelo de caso de usos, você pode ter
uma idéia clara das funções do sistema e como elas
estão relacionadas?
Todos os requisitos foram levantados?
O modelo de caso de usos contém algum
comportamento supérfluo?
A divisão em pacotes do modelo de caso de usos
está apropriada?
Checklists: Atores





Todos os atores foram identificados?
Cada ator está envolvido com pelo menos um caso
de uso?
Cada ator desempenha um papél? Algum deveria ser
fundido com outro ou ser dividido em dois?
Existem dois ou mais atores desempenhando o
mesmo papél em relação a um caso de uso?
Os atores têm nomes intuitivos e descritivos? Tanto
os usuários como os patrocinadores do software têm
um entendimento comum?
Checklists: Casos de Uso





Cada caso de uso está envolvido com pelo menos
um ator?
Os caso de usos são independentes uns dos outros?
Algum dos caso de usos tem comportamento ou
fluxo de eventos muito similares?
Os caso de usos têm nomes únicos, intuitivos e
explicativos de modo que não podem ser
confundidos em um estágio posterior?
Os patrocinadores e usuários entendem os nomes e
descrições dos caso de uso?
Checklists: Especificação de Caso de Uso








Está claro quem deseja executar um caso de uso?
A finalidade de cada caso de uso está clara?
A descrição breve dá uma idéia clara do significado do caso de
uso?
Está claro como e quando os fluxos de eventos de cada caso
de uso começam e terminam?
A seqüência de comunicação entre um ator e um caso de uso
está de acordo com as expectativas do usuário?
As interações e trocas de informação entre os atores e o
sistema estão claras?
Existe algum caso de uso demasiadamente complexo?
Os fluxos de eventos (básicos e alternativos) estão modelados
de forma clara?
Checklists: Glossário



Os termos têm uma definição clara e concisa?
Cada termo do glossário foi incluído em algum lugar
nas descrições dos caso de usos?
Os termos são usados consistentemente nas
descrições dos atores e dos caso de usos?
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
e
Matriz de
Rastreabilidade
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
O documento de requisitos simplificado:
estrutura





Introdução
Descrição Geral do Sistema
Requisitos Funcionais (casos de uso)
Requisitos Não Funcionais
Descrição da Interface com o usuário
Referências




Applying Use Cases: A Practical Guide
Geri Schneider e Jason P. Winters
Addison-Wesley, 1998.
UML Distilled
Martin Fowler
Addison-Wesley, 1997.
The Unified Software Development Process
Ivar Jacobson, Grady Booch e James Rumbaugh
Addison-Wesley, 1998.
The Unified Modeling Language: The User Guide
Ivar Jacobson, Grady Booch e James Rumbaugh
Addison-Wesley, 1999.