O Fluxo de Requisitos
© Alexandre Vasconcelos
[email protected]
[email protected]
Centro de Informática da UFPE/
Qualiti Software Processes
1/51
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
2/51
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.
3/51
Principais Artefatos do fluxo de requisitos






Glossário
Documento de requisitos (funcionais e nãofuncionais)
Modelo de casos de uso (Diagrama de Casos
de Uso + Especificação dos Casos de Uso)
Matriz de rastreabilidade
Termo de Homologação de Requisitos
Protótipo da interface com o usuário (opcional)
4/51
Glossário


Define termos importantes usados no projeto
É importante para garantir que os conceitos
envolvidos são interpretados da mesma forma
por todos os membros da equipe
5/51
Glossário: estrutura

Introdução
 Objetivos
do documento
 Público ao qual se destina

Definições


Termos, definições e sinônimos
Referências
6/51
Documento de requisitos

Mostra a descrição geral do problema a ser
resolvido com o sistema. Apresenta os
requisitos funcionais e não-funcionais.
7/51
Documento de requisitos: estrutura

Introdução




Problema Identificado
Visão geral do sistema





Abrangência e sistemas relacionados
Descrição dos usuários
Referências
Requisitos Funcionais
 Atores


Objetivos do documento
Público ao qual se destina
Diagramas de caso de uso + especificação
Requisitos Não-Funcionais
Descrição do Protótipo de Interface com o Usuário
8/51
Modelo de casos de uso
Diagrama de
casos de uso
Atores
Casos de Uso
Especificações de Casos de Uso
9/51
Modelo de casos de uso
Use Cases
direcionam o
trabalho desde os
requisitos até os
testes
Realizado por
Verificado por
Implementado por
10/51
Exemplo de Diagrama de casos de uso
Solicitar extrato
Consultar saldo
Cliente
Sacar dinheiro
Realizar depósito
Transferir
entre contas
Alterar senha
11/51
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
12/51
Requisitos não-funcionais

Descrevem requisitos de:
 Confiabilidade
 Desempenho
(performance)
 Segurança
 Distribuição
 Adequação
a Padrões
 Restrições de Hardware e
 Software
 etc.
13/51
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?
14/51
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
15/51
Matriz de rastreabilidade

Apresenta o relacionamento entre requisitos. É
usada para a análise de impacto das
mudanças nos requisitos.
16/51
Uma Matriz de rastreabilidade
Requisito
R1
R2
R3
R4
R5
R6
R1
0
0
x
0
x
x
R2
0
0
0
0
0
0
R3
x
0
0
x
0
x
R4
0
0
x
0
x
x
R5
x
0
0
x
0
0
R6
x
0
x
x
0
0
17/51
Termo de Homologação de requisitos:
estrutura

Introdução
 Objetivos
do documento
 Organização do documento

Casos de uso homologados
 Para
cada caso de uso
 Identificador
 Resultado
da homologação
• Homologado, não homologado, homologado com
restrições
 Comentários
18/51
Responsáveis e artefatos
Analista de
sistemas
Usuário
Projetista de
interface
Matriz de
Diagrama de
Documento
rastreabilidade casos de uso
de requisitos Glossário
Termo de
homologação
de requisitos
Protótipo da GUI
Revisor
19/51
O Fluxo de Atividades
Prototipar
Interface
Projetista da
Interface
Analista de
Sistema
Levantar
Requisitos
do Sistema
Detalhar
Especificação
De Caso de Uso
Estruturar
Modelo
de Casos de Uso
Revisor de
Requisitos
Revisar
Requisitos
Usuário
Homologar
Requisitos
Gerenciar
Dependências
20/51
Atividade: Levantar Requisitos do Sistema
Prototipar
Interface
Projetista da
Interface
Analista de
Sistema
Revisor de
Requisitos
Levantar
Requisitos
do Sistema
Levantar
Atores
Levantar
Casos de Uso
Detalhar
Especificação
De Caso de Uso
Estruturar
Modelo
de Casos de Uso
Revisar
Requisitos
Usuário
Homologar
Requisitos
Gerenciar
Dependências
21/51
Atividade: Levantar Requisitos do Sistema

Nesta atividade, o Analista de Sistemas deve
entender o que os stakeholders esperam do
sistema, através da coleta de informações e
necessidades que o sistema deve cumprir. A
execução da atividade tem como artefatos
resultantes o documento de requisitos, o
glossário de termos e o modelo de casos de
uso (diagrama e especificação), brevemente
esboçados.
22/51
Agrupamento de casos de uso

Dividir os casos de uso em pacotes
 Ator
 Funcionalidades
correlatas
 Processos
23/51
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
24/51
Atividade: Detalhar Especificação de Casos
de Uso
Prototipar
Interface
Projetista da
Interface
Analista de
Sistema
Revisor de
Requisitos
Levantar
Requisitos
do Sistema
Levantar
Atores
Levantar
Casos de Uso
Detalhar
Especificação
De Caso de Uso
Desc:
Pré:
Pós:
Fluxo:
1.
2.
Fl. Sec:
Estruturar
Modelo
de Casos de Uso
Revisar
Requisitos
Usuário
Homologar
Requisitos
RNF
Usab.
Conf.
Perfor.
Seg.
Gerenciar
Dependências
25/51
Atividade: Detalhar Especificação de Casos
de Uso

Nesta atividade, o Analista de Sistemas
descreve os fluxos de eventos dos casos de
uso em detalhes de forma que o cliente e os
usuários possam entender.
26/51
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
27/51
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!
28/51
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
29/51
Atividade: Estruturar o Modelo de Casos de
Uso
Prototipar
Interface
Projetista da
Interface
Analista de
Sistema
Revisor de
Requisitos
Levantar
Requisitos
do Sistema
Levantar
Atores
Levantar
Casos de Uso
Detalhar
Especificação
De Caso de Uso
Desc:
Pré:
Pós:
Fluxo:
1.
2.
Fl. Sec:
Estruturar
Modelo
de Casos de Uso
Revisar
Requisitos
Usuário
Homologar
Requisitos
RNF
Usab.
Conf.
Perfor.
Seg.
Gerenciar
Dependências
30/51
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.
31/51
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
32/51
Relacionamentos entre casos de uso

Inclusão

Extensão

Generalização
33/51
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
34/51
Atividade: Gerenciar Dependências
Prototipar
Interface
Projetista da
Interface
Analista de
Sistema
Revisor de
Requisitos
Levantar
Requisitos
do Sistema
Levantar
Atores
Levantar
Casos de Uso
Detalhar
Especificação
De Caso de Uso
Desc:
Pré:
Pós:
Fluxo:
1.
2.
Fl. Sec:
Estruturar
Modelo
de Casos de Uso
Revisar
Requisitos
Usuário
Homologar
Requisitos
RNF
Usab.
Conf.
Perfor.
Seg.
Gerenciar
Dependências
35/51
Atividade: Gerenciar Dependências

Nesta atividade, o Analista de Sistemas
executa as seguintes tarefas:
 Gerencia
mudanças nos requisitos que foram
concordados
 Gerencia o relacionamento entre requisitos
 Gerencia as dependências entre os documentos
de requisitos e outros documentos produzidos no
processo de engenharia de sistemas
 Analisa impactos e custos relacionados aos
requisitos que mudaram
36/51
Atividade: Prototipar Interface
Prototipar
Interface
Projetista da
Interface
Analista de
Sistema
Revisor de
Requisitos
Levantar
Requisitos
do Sistema
Levantar
Atores
Levantar
Casos de Uso
Detalhar
Especificação
De Caso de Uso
Desc:
Pré:
Pós:
Fluxo:
1.
2.
Fl. Sec:
Estruturar
Modelo
de Casos de Uso
Revisar
Requisitos
Usuário
Homologar
Requisitos
RNF
Usab.
Conf.
Perfor.
Seg.
Gerenciar
Dependências
37/51
Atividade: Prototipar Interface

Nesta atividade, o Projetista da Interface
projeta e constrói um modelo de interface com
o usuário que suporta o melhoramento da
usabilidade.
38/51
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
39/51
Atividade: Revisar os Requisitos
Prototipar
Interface
Projetista da
Interface
Analista de
Sistema
Revisor de
Requisitos
Levantar
Requisitos
do Sistema
Levantar
Atores
Levantar
Casos de Uso
Detalhar
Especificação
De Caso de Uso
Desc:
Pré:
Pós:
Fluxo:
1.
2.
Fl. Sec:
Estruturar
Modelo
de Casos de Uso
Revisar
Requisitos
Usuário
Homologar
Requisitos
RNF
Usab.
Conf.
Perfor.
Seg.
Gerenciar
Dependências
40/51
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.
41/51
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?
42/51
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?
43/51
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?
44/51
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 45/51
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?
46/51
Atividade: Homologar Requisitos
Prototipar
Interface
Projetista da
Interface
Analista de
Sistema
Revisor de
Requisitos
Levantar
Requisitos
do Sistema
Levantar
Atores
Levantar
Casos de Uso
Detalhar
Especificação
De Caso de Uso
Desc:
Pré:
Pós:
Fluxo:
1.
2.
Fl. Sec:
Estruturar
Modelo
de Casos de Uso
Revisar
Requisitos
Usuário
Homologar
Requisitos
RNF
Usab.
Conf.
Perfor.
Seg.
Gerenciar
Dependências
47/51
Atividade: Homologar Requisitos

Nesta atividade, o usuário faz a homologação
dos requisitos a serem tratados na iteração. O
termo de homologação é preenchido nesta
atividade.
48/51
Projeto em Equipe

Dados os seguintes artefatos do QIB:
 Descrição
Geral
 Glossário



Levantar os atores e casos de uso
Construir o diagrama de casos de uso
Levantar os requisitos não-funcionais
49/51
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, AddisonWesley, 1998.
The Unified Modeling Language: The User Guide, Ivar
Jacobson, Grady Booch e James Rumbaugh, AddisonWesley, 1999.
50/51
O Fluxo de Requisitos
© Alexandre Vasconcelos
[email protected]
[email protected]
Centro de Informática da UFPE/
Qualiti Software Processes
51/51
Descargar

Requirements Overview