Requisitos: Fluxo de Trabalho

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

1 Requisitos: Fluxo de Trabalho

2 Requisitos: Fluxo de Trabalho
Cada detalhamento do fluxo de trabalho representa uma habilidade-chave que precisa ser aplicada para executar o gerenciamento eficiente de requisitos. Os detalhamentos do fluxo de trabalho são mostrados em uma ordem lógica e seqüencial. Eles são aplicados em ordem diferente, conforme a necessidade no decorrer do projeto.

3 Detalhamento do Fluxo de Trabalho: Analisar o Problema

4 Detalhamento do Fluxo de Trabalho: Analisar o Problema
A finalidade desse detalhamento do fluxo de trabalho é: Estabelecer acordo sobre o problema a ser resolvido, Identificar os envolvidos, Definir as fronteiras do sistema e Identificar restrições impostas ao sistema

5 Detalhamento do Fluxo de Trabalho: Definir o Sistema

6 A finalidade desse detalhamento do fluxo de trabalho é:
Criar uma compreensão comum do sistema dentro da equipe do projeto. Realizar uma análise de alto nível sobre os resultados da coleta de solicitações dos principais envolvidos. Refinar a visão para que contenha as características a serem incluídas no sistema, juntamente com os atributos adequados. Refinar o modelo de casos de uso para incluir os casos de uso descritos. Documentar com mais formalidade os resultados em modelos e documentos.

7 Requisitos: Visão Geral das Diretrizes
Associação de Comunicação Ator Caso de Uso Classe de Fronteira Diagrama de Atividades no Modelo de Casos de Uso Diagrama de Casos de Uso Documento de Arquitetura de Software Encenação de Caso de Uso Especificação de Requisitos de Software Generalização de Ator Generalização de Casos de Uso Interface do Usuário (Geral) Modelo de Casos de Uso Pacote de Casos de Uso Plano de Gerenciamento de Requisitos Relacionamento de Extensão Relacionamento de Inclusão

8 Visão Geral das Diretrizes
Uma associação de comunicação é uma associação entre uma classe de ator e uma classe de caso de uso, que indica haver interação entre suas instâncias. Ator Uma instância de ator é alguém ou algo externo ao sistema que interage com ele. Uma classe de ator define um conjunto de instâncias de ator, no qual cada uma desempenha o mesmo papel em relação ao sistema. Caso de Uso Uma instância de casos de uso é uma seqüência de ações realizadas por um sistema, que gera um resultado observável de valor para um determinado ator. Um caso de uso define um conjunto de instâncias de casos de uso.

9 Visão Geral das Diretrizes
Uma classe de fronteira modela a interação entre um ou mais atores e o sistema. O diagrama de atividades no modelo de casos de uso ilustra o fluxo de eventos de um caso de uso. Um diagrama de casos de uso mostra os atores, os casos de uso, os pacotes de casos de uso e seus relacionamentos.

10 Visão Geral das Diretrizes
Documento de Arquitetura de Software Visão de Implantação Visão de Implementação Visão de Dados Tamanho e Desempenho Qualidade Referências Metas e Restrições da Arquitetura Visão de Casos de Uso Visão Lógica Visão de Processos Uma encenação de caso de uso é uma descrição lógica e conceitual de como um caso de uso é fornecido pela interface do usuário, incluindo a interação necessária entre os atores e o sistema.

11 Visão Geral das Diretrizes
A Especificação de Requisitos de Software (SRS) abrange todos os requisitos do software para o sistema ou uma parte do sistema. A generalização de ator de um tipo de ator (descendente) para outro tipo de ator (ascendente) indica que o descendente herda o papel que o ascendente pode desempenhar em um caso de uso. Esta é uma descrição das diretrizes gerais aplicáveis à  criação de uma interface do usuário, na qual "A interface do usuário é o que permite que as informações sejam transmitidas entre um usuário humano e os componentes de hardware ou software de um sistema de computador." [IEEE, Std ]

12 Visão Geral das Diretrizes
O modelo de casos de uso é um modelo que descreve os requisitos de um sistema em termos de casos de uso. Um pacote de casos de uso é um conjunto de casos de uso, atores, relacionamentos, diagramas e outros pacotes; ele é usado para estruturar o modelo de casos de uso dividindo-o em partes menores. Plano de Gerenciamento de Requisitos Relacionamento com Outros Planos Identificação de Itens de Rastreabilidade Especificação de Rastreabilidade Organização, Responsabilidade e Interfaces Atributos de Exemplo Seleção de Atributos Relatórios e Medidas Gerenciamento de Mudanças de Requisitos

13 Visão Geral das Diretrizes
Relacionamento de Extensão Um relacionamento de extensão é aquele que se estabelece entre um caso de uso de extensão e um caso de uso base, especificando como o comportamento definido para o caso de uso de extensão pode ser inserido no comportamento definido para o caso de uso de base. Ele é inserido implicitamente no sentido de que a extensão não é exibida no caso de uso base. Relacionamento de Inclusão Um relacionamento de inclusão é aquele que se estabelece entre um caso de uso base e um caso de uso de inclusão, especificando como o comportamento definido para o caso de uso de inclusão é inserido de forma explícita no comportamento definido para o caso de uso base.

14 Introdução aos Requisitos

15 Finalidade A finalidade da disciplina Requisitos é:
Estabelecer e manter concordância com os clientes e outros envolvidos sobre o que o sistema deve fazer. Oferecer aos desenvolvedores do sistema uma compreensão melhor dos requisitos do sistema. Definir as fronteiras do sistema (ou delimitar o sistema). Fornecer uma base para planejar o conteúdo técnico das iterações. Fornecer uma base para estimar o custo e o tempo de desenvolvimento do sistema. Definir uma interface de usuário para o sistema, focando nas necessidades e metas dos usuários.

16 Para atingir essas metas, é importante, antes de tudo, compreender a definição e o escopo do problema que tentamos resolver com este sistema.  As Regras de Negócios, o Modelo de Casos de Uso de Negócios e o Modelo de Objetos de Negócios desenvolvidos durante a Modelagem do Negócio servirão como informações importantes nesse trabalho.  Os envolvidos são identificados e as Solicitações dos Principais Envolvidos são recolhidas, reunidas e analisadas.

17 Relação com Outras Disciplinas
A disciplina Requisitos está relacionada a outras disciplinas do processo: A disciplina Modelagem de Negócios fornece as Regras de Negócios, um Modelo de Casos de Uso de Negócios e um Modelo de Objeto de Negócio, incluindo um Modelo de Domínio e um contexto organizacional para o sistema. A disciplina Análise e Design obtém suas informações primárias (o modelo de casos de uso e o Glossário) dos Requisitos. Falhas no modelo de casos de uso podem ser descobertas durante a atividade de análise e de design; solicitações de mudança são, então, geradas e aplicadas ao modelo de casos de uso.

18 A disciplina Teste valida o sistema com base (entre outras coisas) no Modelo de Casos de Uso. Os Casos de Uso e as Especificações Suplementares fornecem informações sobre os requisitos usados na definição da missão de avaliação e nas atividades subseqüentes de teste e avaliação. A disciplina Gerenciamento de Configuração e Mudança fornece o mecanismo para controle de mudanças dos requisitos.  O mecanismo para proposta de uma mudança consiste em enviar uma Solicitação de Mudança, que será analisada pelo Comitê de Controle de Mudança.

19 A disciplina Gerenciamento de Projeto planeja o projeto e cada iteração (descritas em um Plano de Iteração). O modelo de casos de uso e o Plano de Gerenciamento de Requisitos são informações importantes fornecidas às atividades de planejamento de iterações. A disciplina Ambiente desenvolve e mantém os artefatos de suporte usados no gerenciamento de requisitos e na modelagem de caso de uso, como o Guia de Modelagem de Caso de Uso e o Guia de Interface do Usuário.

20 Conceitos Design Centrado no Usuário Gerenciamento de Requisitos
Rastreabilidade Requisitos Tipos de Requisitos Visão de Casos de Uso

21 Design centrado no usuário
Não há um consenso claro sobre o que é o design centrado no usuário. No entanto, John Gould e seus colegas na IBM desenvolveram um método na década de 1980 chamado Design Pensando em Usabilidade que compreende as definições mais comumente aceitas. Ele foi desenvolvido a partir de experiências práticas com uma série de sistemas interativos, especialmente o Olympic Messaging System (Sistema de Mensagens Eletrônicas Olímpicas) da IBM em O método tem quatro componentes principais, conforme é descrito abaixo. Foco nos usuários Integração com o design Teste com o usuário no início Design iterativo

22 Design centrado no usuário no RUP
Contexto Atributos Tarefas Metas do uso do sistema, freqüência e duração do desempenho, considerações sobre saúde e segurança, alocação das atividades, passos operacionais entre os recursos humanos e tecnológicos. As tarefas não devem ser descritas em termos de funções e características fornecidas por um produto ou sistema. Usuário (para cada tipo ou papel diferente) Conhecimento, habilidade, experiência, instrução, treinamento, atributos físicos, hábitos, preferências, recursos. Ambientes Hardware, software, materiais, ambientes físico e social, padrões relevantes, ambiente técnico, ambiente circundante, ambiente jurídico, ambiente social e cultural.

23 Gerenciamento de requisitos
O gerenciamento de requisitos é um modelo sistemático para encontrar, documentar, organizar e rastrear os requisitos variáveis de um sistema. Um requisito é definido como: Uma condição ou uma capacidade com a qual o sistema deve estar de acordo. Nossa definição formal de gerenciamento de requisitos trata-se de um modelo sistemático para: identificar, organizar e documentar os requisitos do sistema, e estabelecer e manter acordo entre o cliente e a equipe do projeto nos requisitos variáveis do sistema. Os principais itens para o gerenciamento eficiente de requisitos incluem manter uma declaração clara dos requisitos, juntamente com atributos aplicáveis para cada tipo de requisito e rastreabilidade para outros requisitos e outros artefatos do projeto.

24 Rastreabilidade A rastreabilidade é a capacidade de rastrear um elemento do projeto a outros elementos correlatos, especialmente aqueles relacionados a requisitos.  Os elementos do projeto envolvidos em rastreabilidade são chamados de itens de rastreabilidade.  Os itens típicos de rastreabilidade incluem diferentes tipos de requisitos, elementos de modelo de design e de análise, artefatos de testes (conjuntos de testes, casos de teste, etc.) e material de treinamento e documentação de suporte a usuário final A finalidade de estabelecer rastreabilidade é ajudar a: Compreender a origem dos requisitos Gerenciar o escopo do projeto Gerenciar mudanças nos requisitos Avaliar o impacto no projeto da mudança em um requisito Avaliar o impacto da falha de um teste nos requisitos (isto é, se o teste falhar, talvez o requisito não seja atendido) Verificar se todos os requisitos do sistema são desempenhados pela implementação Verificar se o aplicativo faz apenas o que era esperado que ele fizesse.

25 Requisitos Um requisito é definido como "uma condição ou uma capacidade com a qual o sistema deve estar de acordo". As principais categorias de requisitos são: Funcionalidade - Algo passível de execução; Usabilidade - Facilidade de uso; Confiabilidade - É a qualidade do sistema que nos permite confiar, justificadamente, no serviço oferecido; Desempenho - Pode ser definido como o conjunto de características ou capacidades de comportamento e rendimento de um sistema; Suportabilidade - É um dos aspectos da qualidade de software que se refere à habilidade dum suporte técnico de instalar, configurar e monitorar produtos computacionais

26 Tipos de requisitos

27 Visão de caso de uso

28 Visão de caso de uso Visão Lógica - Ilustra as principais realizações de caso de uso, subsistemas, pacotes e classes que abrangem o comportamento significativo em termos de arquitetura. Visão de Processos - Ilustra a decomposição do processo do sistema, incluindo o mapeamento das classes e dos subsistemas para processos e threads. Visão de Implantação - Ilustra a distribuição do processamento em um conjunto de nós do sistema, incluindo a distribuição física dos processos e threads. Visão de Implementação - Capta as decisões de arquitetura tomadas para a implementação

29 Perguntas Qual a importância do fluxo de trabalho?
Como um requisito se relaciona com um caso de uso? Quais são os principais artefatos gerados na modelagem de requisitos?

30 John Weverson Rodrigues Teodoro
Edicarlos Tobias Honório Silva Ericson Luiz Araújo de Oliveira Armando Alves da Rocha Junior Jonatas Cândido Barbosa Lilian Gomes Ana Julia Fonseca Silva