Engenharia de Software Fluxo de Requisitos

Apresentação em tema: "Engenharia de Software Fluxo de Requisitos"— Transcrição da apresentação:

1 Engenharia de Software Fluxo de Requisitos
Alexandre Monteiro

2 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

3 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.

4 Artefatos mais relevantes do fluxo de requisitos
Descrição do Problema Especificações Suplementares Glossário Atributos dos Requisitos Matriz de rastreabilidade ... Especificações de Caso de Uso Modelo de caso de uso Casos de Uso Atores

5 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

6 Glossário Introdução Termos Glossário

7 Modelo de casos de uso Introdução Pacotes de casos de uso Diagramas de
Especificações de casos de usos Modelo de casos de uso Atores Casos de Uso Especificações de Casos de Uso

8 Modelo de casos de uso Use Cases direcionam o trabalho desde os requisitos até os testes Verificado por Realizado por Implementado por

9 Exemplo de Diagrama de casos de uso
Transferir entre contas Cliente Realizar depósito Sacar dinheiro Consultar saldo Solicitar extrato Alterar senha

10 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

11 Fluxos de eventos x 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

12 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.

13 Diagrama de atividades: exemplo

14 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 Software etc. Especificações Suplementares

15 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?

16 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

17 Fluxo de Requisitos - Visão da Atividade
Projetista da Interface com o Usuário Especificador de UC Arquiteto Priorizar UC Analista de Sistema Desenvolver Documento de Visão Elicitar necessidades dos Stakeholders Encontrar Atores e Casos de Uso Revisor de Requisitos Gerenciar Dependências Capturar um vocabulário comum Detalhar UC Modelar a Revisar os Prototipar a Estruturar o Modelo de UC

18 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.

19 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.

20 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.

21 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.

22 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.

23 Agrupamento de casos de uso
Dividir os casos de uso em pacotes Ator Funcionalidades correlatas Processos

24 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.

25 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

26 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.

27 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

28 Relacionamentos entre casos de uso
Inclusão Extensão Generalização

29 Relacionamento entre atores: generalização
Quando um ator A realiza todos os casos de uso que o ator B, dizemos que A estende B. Realizar venda Vendedor Estabelecer crédito Supervisor

30 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

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

32 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!

33 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

34 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.

35 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.

36 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 Na RF queremos “desobrigar” o definidor de ter que encarregar-se do projeto detalhado da GUI. Assim, a seção de Interface, no doc. De requisitos, não necessariamente conterá a descrição detalhada de todas as interfaces - fazer uma descrição detalhada ou não fica a critério do definidor. Se ele quiser, pode usar a seção de Interface apenas para dar uma ideia de como deve ser a interface e dizer que campos ela deve conter, deixando para os desenvolvedores o projeto propriamente dito. Claro que se ele (o definidor) quiser fazer uma descrição detalhada da interface, ele pode fazê-lo. Em sistemas já existentes ele pode, inclusive, capturar telas do sistema e incluí-las na seção de interface, para ilustrar algum ponto do fluxo dos casos de uso. Assim, a descrição de interfaces funciona como uma ferramenta para a compreesão dos casos de uso - este é o seu objetivo. O nível de detalhes depende do estilo de cada definidor. Porém, via de regra, a descrição não deveria ser um projeto completo da interface, até porque é provável que características técnicas, levantadas nas atividades de análise e projeto, influenciem o design da interface. Os definidores costumam descrever também as críticas que são feitas aos campos da interface (ex.: este campo é numérico da forma xx.xxx.xx, etc.). Essas críticas podem ser feitas na própria descrição das interfaces, evitando assim a descrição de uma série de fluxos de erro que iriam especificar essas entradas erradas. Mas, cuidado! As críticas descritas em conjunto com a descrição das interfaces devem ser críticas bem básicas,destas que Java e Delphi permitem que você trate apenas setando uma propriedade dos campos. Críticas que traduzem regras de negócio mais complexas DEVEM ser descritas nos fluxos de erro, para não induzir que sejam tratadas diretamente na interface do sistema e não em camadas mais “internas” da aplicação (como a camada de regras de negócio). Senão você acaba favorecendo uma dependência de interface nos sistemas.

37 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.

38 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?

39 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?

40 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?

41 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?

42 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?

43 Requisitos - Visão dos artefatos
Analista de Sistema Especificador de UC Responsável por Responsável por Atributos dos Requisitos e Matriz de Rastreabilidade Casos de Uso Visão Necessidades dos Stakeholders Modelo de Use Case Especificação Suplementar Glossário Pacote de Use Case Arquiteto Projetista da Interface com o Usuário Revisor de Requisitos Responsável por Responsável por Documento de Arquitetura de Software Classes de Fronteira UC Storyboard Protótipo da Interface com o usuário

44 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

45 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 The Unified Modeling Language: The User Guide Addison-Wesley, 1999.