1/51 O Fluxo de Requisitos © Alexandre Vasconcelos [email protected] [email protected] Centro de Informática da UFPE/ Qualiti Software Processes.

1/51

O Fluxo de O Fluxo de RequisitosRequisitos

© Alexandre [email protected]@qualiti.com.br

Centro de Informática da UFPE/Qualiti Software Processes

2/51

ObjetivosObjetivos::

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

3/51

Finalidade do fluxo de requisitosFinalidade 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.

4/51

Principais Artefatos do fluxo de requisitosPrincipais 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)

5/51

GlossárioGlossá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

6/51

Glossário: estruturaGlossário: estrutura

Introdução Objetivos do documento Público ao qual se destina

Definições Termos, definições e sinônimos

Referências

7/51

Documento de requisitosDocumento de requisitos

Mostra a descrição geral do problema a ser resolvido com o sistema. Apresenta os requisitos funcionais e não-funcionais.

8/51

Documento de requisitos: estruturaDocumento 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

9/51

Modelo de casos de usoModelo de casos de uso

Diagrama de casos de uso

AtoresCasos de Uso

Especificações de Casos de Uso

10/51

Modelo de casos de usoModelo de casos de uso

Use Cases direcionam o trabalho desde os requisitos até os testes

Verificado porImplementado por

Realizado por

11/51

Exemplo de Diagrama de casos de usoExemplo de Diagrama de casos de uso

Transferir entre contas

Cliente

Realizar depósito

Sacar dinheiro

Consultar saldo

Solicitar extrato

Alterar senha

12/51

Especificação de caso de usoEspecificação de caso de uso

•Breve descriçãoBreve descrição•AtorAtor•PrioridadePrioridade•Interfaces Gráficas Interfaces Gráficas Associadas (opcional)Associadas (opcional)•Entradas e Pré-condiçõesEntradas e Pré-condições•Saídas e Pós-condiçõesSaídas e Pós-condições•Fluxo de eventos principalFluxo de eventos principal•Fluxos secundários: Fluxos secundários: alternativos e de exceção alternativos e de exceção (opcional)(opcional)

Modelo de caso de uso

Atores

Casos de Uso

Especificações de Use Case

...

13/51

Requisitos não-funcionaisRequisitos 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.

14/51

Requisitos não-funcionaisRequisitos 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?

15/51

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 novos

casos de uso

16/51

Matriz de rastreabilidadeMatriz de rastreabilidade

Apresenta o relacionamento entre requisitos. É usada para a análise de impacto das mudanças nos requisitos.

17/51

Uma Matriz de rastreabilidadeUma 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

18/51

Termo de Homologação de requisitos: Termo de Homologação de requisitos: estruturaestrutura

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

19/51

Responsáveis e artefatosResponsá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

20/51

O Fluxo de AtividadesO Fluxo de Atividades

Levantar Requisitos do Sistema

Prototipar Interface

Revisar Requisitos

DetalharEspecificação De Caso de Uso

Projetista daInterface

Analista deSistema

Revisor de Requisitos

EstruturarModelode Casos de Uso

Homologar Requisitos

Usuário

Gerenciar Dependências

21/51

Atividade: Levantar Requisitos do SistemaAtividade: Levantar Requisitos do Sistema



Revisar Requisitos



Analista deSistema




Usuário

Levantar Atores

Levantar Casos de Uso


22/51

Atividade: Levantar Requisitos do SistemaAtividade: 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.

23/51

Agrupamento de casos de usoAgrupamento de casos de uso

Dividir os casos de uso em pacotes Ator Funcionalidades correlatas Processos

24/51

Prioridades de Casos de UsoPrioridades 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

25/51

Atividade: Detalhar Especificação de Casos Atividade: Detalhar Especificação de Casos de Usode Uso



Revisar Requisitos



Analista deSistema




Usuário

Levantar Atores


Desc:Pré:Pós:Fluxo:1.2.Fl. Sec:

RNFUsab.Conf.Perfor.Seg.


26/51

Atividade: Detalhar Especificação de Casos Atividade: Detalhar Especificação de Casos de Usode 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.

27/51

Quando e por que detalhar os casos de Quando e por que detalhar os casos de uso? 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

28/51

Fluxo de eventos básicoFluxo 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!

29/51

Fluxos secundáriosFluxos 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

30/51

Atividade: Estruturar o Modelo de Casos de Atividade: Estruturar o Modelo de Casos de UsoUso



Revisar Requisitos



Analista deSistema




Usuário

Levantar Atores





31/51

Atividade: Estruturar o Modelo de Casos de Atividade: Estruturar o Modelo de Casos de UsoUso

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.

32/51

Por que estruturar o modelo?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

33/51

Relacionamentos entre casos de usoRelacionamentos entre casos de uso

Inclusão

Extensão

Generalização

34/51

Relacionamento entre atores: generalizaçãoRelacionamento entre atores: generalização

Quando um ator A realiza todos os casos de uso que o ator B, dizemos que A estende B.

VendedorRealizar venda

Estabelecer créditoSupervisor

35/51

Atividade: Gerenciar DependênciasAtividade: Gerenciar Dependências



Revisar Requisitos



Analista deSistema




Usuário

Levantar Atores





36/51

Atividade: Gerenciar DependênciasAtividade: 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

37/51

Atividade: Prototipar InterfaceAtividade: Prototipar Interface



Revisar Requisitos



Analista deSistema




Usuário

Levantar Atores





38/51

Atividade: Prototipar InterfaceAtividade: 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.

39/51

Protótipo de interface com o usuárioProtó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

40/51

Atividade: Revisar os RequisitosAtividade: Revisar os Requisitos



Revisar Requisitos



Analista deSistema




Usuário

Levantar Atores





41/51

Atividade: Revisar os RequisitosAtividade: 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.

42/51

Checklists: Modelo de Casos de UsoChecklists: 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?

43/51

Checklists: AtoresChecklists: 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?

44/51

Checklists: Casos de UsoChecklists: 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?

45/51

Checklists: Especificação de Caso de UsoChecklists: 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?

46/51

Checklists: GlossárioChecklists: 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?

47/51

Atividade: Homologar RequisitosAtividade: Homologar Requisitos



Revisar Requisitos



Analista deSistema




Usuário

Levantar Atores





48/51

Atividade: Homologar RequisitosAtividade: 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.

49/51

Projeto em EquipeProjeto 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

50/51

ReferênciasReferê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.

51/51

O Fluxo de O Fluxo de RequisitosRequisitos

© Alexandre [email protected]@qualiti.com.br

Centro de Informática da UFPE/Qualiti Software Processes

1/51 O Fluxo de Requisitos © Alexandre Vasconcelos [email protected] [email protected] Centro de Informática da UFPE/ Qualiti Software Processes.

Documents