o fluxo de requisitos - facombacala/mds2011/mds5.pdf · 2 finalidade do fluxo de requisitos a...

1

O Fluxo de Requisitos

2

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

Principais Artefatos do fluxo de requisitos

Glossário

Documento de requisitos (funcionais e não-

funcionais)

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

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

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

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

Documento de requisitos: estrutura

Introdução

Objetivos do documento

Público ao qual se destina

Problema Identificado

Visão geral do sistema

Abrangência e sistemas relacionados

Descrição dos usuários

Referências

Requisitos Funcionais

Atores

Diagramas de caso de uso + especificação

Requisitos Não-Funcionais

Descrição do Protótipo de Interface com o Usuário

8

Modelo de casos de uso

Diagrama de

casos de uso

Atores Casos de Uso

Especificações de Casos de Uso

9

Modelo de casos de uso

Use Cases

direcionam o

trabalho desde os

requisitos até os

testes

Verificado por

Implementado por Realizado por

10

Exemplo de Diagrama de casos de uso

Transferir

entre contas

Cliente

Realizar depósito

Sacar dinheiro

Consultar saldo

Solicitar extrato

Alterar senha

11

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

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

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

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

Matriz de rastreabilidade

Apresenta o relacionamento entre requisitos. É

usada para a análise de impacto das

mudanças nos requisitos.

16

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

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

Responsáveis e artefatos

Documento de requisitos

Revisor

Protótipo da GUI

Analista de sistemas

Diagrama de casos de uso

Projetista de interface

Glossário

Termo de homologação de requisitos

Usuário

Matriz de rastreabilidade

19

O Fluxo de Atividades

Levantar Requisitos do Sistema

Prototipar Interface

Revisar Requisitos

Detalhar Especificação De Caso de Uso

Projetista da Interface

Analista de Sistema

Revisor de Requisitos

Estruturar Modelo de Casos de Uso

Homologar Requisitos

Usuário

Gerenciar Dependências

20

Atividade: Levantar Requisitos do Sistema

Levantar Requisitos do Sistema

Prototipar Interface

Revisar Requisitos

Detalhar Especificação De Caso de Uso

Projetista da Interface

Analista de Sistema

Revisor de Requisitos

Estruturar Modelo de Casos de Uso

Homologar Requisitos

Usuário

Levantar Atores

Levantar Casos de Uso

Gerenciar Dependências

21

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

Agrupamento de casos de uso

Dividir os casos de uso em pacotes

Ator

Funcionalidades correlatas

Processos

23

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

Atividade: Detalhar Especificação de Casos de Uso

Levantar Requisitos do Sistema

Prototipar Interface

Revisar Requisitos

Detalhar Especificação De Caso de Uso

Projetista da Interface

Analista de Sistema

Revisor de Requisitos

Estruturar Modelo de Casos de Uso

Homologar Requisitos

Usuário

Levantar Atores

Levantar Casos de Uso

Desc: Pré: Pós: Fluxo: 1. 2. Fl. Sec:

RNF Usab. Conf. Perfor. Seg.

Gerenciar Dependências

25

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

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

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

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

Atividade: Estruturar o Modelo de Casos de Uso

Levantar Requisitos do Sistema

Prototipar Interface

Revisar Requisitos

Detalhar Especificação De Caso de Uso

Projetista da Interface

Analista de Sistema

Revisor de Requisitos

Estruturar Modelo de Casos de Uso

Homologar Requisitos

Usuário

Levantar Atores

Levantar Casos de Uso

Desc: Pré: Pós: Fluxo: 1. 2. Fl. Sec:

RNF Usab. Conf. Perfor. Seg.

Gerenciar Dependências

30

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

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

Relacionamentos entre casos de uso

Inclusão

Extensão

Generalização

33

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 Realizar venda

Estabelecer crédito Supervisor

34

Atividade: Gerenciar Dependências

Levantar Requisitos do Sistema

Prototipar Interface

Revisar Requisitos

Detalhar Especificação De Caso de Uso

Projetista da Interface

Analista de Sistema

Revisor de Requisitos

Estruturar Modelo de Casos de Uso

Homologar Requisitos

Usuário

Levantar Atores

Levantar Casos de Uso

Desc: Pré: Pós: Fluxo: 1. 2. Fl. Sec:

RNF Usab. Conf. Perfor. Seg.

Gerenciar Dependências

35

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

Atividade: Prototipar Interface

Levantar Requisitos do Sistema

Prototipar Interface

Revisar Requisitos

Detalhar Especificação De Caso de Uso

Projetista da Interface

Analista de Sistema

Revisor de Requisitos

Estruturar Modelo de Casos de Uso

Homologar Requisitos

Usuário

Levantar Atores

Levantar Casos de Uso

Desc: Pré: Pós: Fluxo: 1. 2. Fl. Sec:

RNF Usab. Conf. Perfor. Seg.

Gerenciar Dependências

37

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

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

Atividade: Revisar os Requisitos

Levantar Requisitos do Sistema

Prototipar Interface

Revisar Requisitos

Detalhar Especificação De Caso de Uso

Projetista da Interface

Analista de Sistema

Revisor de Requisitos

Estruturar Modelo de Casos de Uso

Homologar Requisitos

Usuário

Levantar Atores

Levantar Casos de Uso

Desc: Pré: Pós: Fluxo: 1. 2. Fl. Sec:

RNF Usab. Conf. Perfor. Seg.

Gerenciar Dependências

40

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

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

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

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

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?

45

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

Atividade: Homologar Requisitos

Levantar Requisitos do Sistema

Prototipar Interface

Revisar Requisitos

Detalhar Especificação De Caso de Uso

Projetista da Interface

Analista de Sistema

Revisor de Requisitos

Estruturar Modelo de Casos de Uso

Homologar Requisitos

Usuário

Levantar Atores

Levantar Casos de Uso

Desc: Pré: Pós: Fluxo: 1. 2. Fl. Sec:

RNF Usab. Conf. Perfor. Seg.

Gerenciar Dependências

47

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

Projeto em Equipe

Elaborar os seguintes artefatos :

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

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.