capturando requisitos com use cases
DESCRIPTION
Capturando Requisitos com Use Cases. Disciplina: Estudo do RUP Autor: Tiago Lima Massoni Orientacao: Augusto Sampaio Paulo Borba. Introdução. Captura de Requisitos : principal esforço modelo do sistema a ser construído. Use Cases Req. Funcionais: naturalmente estruturados - PowerPoint PPT PresentationTRANSCRIPT
Capturando Requisitos com Use Cases
Disciplina: Estudo do RUPAutor: Tiago Lima MassoniOrientacao: Augusto Sampaio
Paulo Borba
1999RUP - DI / UFPE
Introdução
•Captura de Requisitos : principal esforço modelo do sistema a ser construído.
• Use Cases
Req. Funcionais: naturalmente estruturados
Req. Não-funcionais: maioria específicos aos use cases
1999RUP - DI / UFPE
Introdução
• O que favorece use cases
Foco sistemático nos requisitos funcionais com retorno para usuários
Analistas forçados a pensar em termos dos usuários
Papel de direção de todo o restante do desenvolvimento
• Workflow de Requisitos: elicitação, organização e documentação das funcionalidades e restrições requisitadas
1999RUP - DI / UFPE
Atividades Requisitos
Desenvolver Visão
• Worker: Analista de Sistemas
• Visão: Documento com requisitos de alto nível e restrições de projeto - base contratual
• Passos:
1.Adquirir concordância no problema ser resolvido / 2.Identificar cliente / 3.Delimitar o sistema / 4.Definir restrições / 5.Definir features
• Saída: Visão do sistema
1999RUP - DI / UFPE
Atividades Requisitos
Gerenciar Dependências
• Worker: Analista de Sistemas
• Dependências: Entender atributos dos requisitos - matrizes
• Passos:
1.Escolher atributos / 2. Usar atributos
• Saída: Matrizes de dependências (atributos de requisitos)
1999RUP - DI / UFPE
Atividades Requisitos
Capturar Vocabulário Comum
• Worker: Analista de Sistemas
• Ajuda nas descrições textuais do sistema
• Passos:
1.Achar termos comuns ao negócio
• Saída: Glossário
1999RUP - DI / UFPE
Atividades Requisitos
Elicitar Necessidades do Cliente (Stakeholder)
• Worker: Analista de Sistemas
• Necessidades Cliente: Documento com todos os pedidos dos clientes e usuários, e mostra como serão lidados.
• Passos:
1.Determinar fontes dos requisitos / 2.Coletar informação / 3.Conduzir workshops de requisitos / 4. Organizar resultados
• Saída: Necessidades do cliente
1999RUP - DI / UFPE
Atividades Requisitos
Achar Use Cases e Atores
• Worker: Analista de Sistemas
• Delimitar o sistema e esboçar quem irá interagir e qual a funcionalidade esperada
• Passos:
1.Achar os atores / 2.Achar os use cases / 3.Descrever brevemente cada use case / 4. Descrever o modelo use cases como um todo
• Saída: Modelo Use Cases (esboço), Requisitos suplementares
1999RUP - DI / UFPE
Atividades Requisitos
Achar Use Cases e Atores
• Exemplo:•Ator Funcionário do Banco: Representa alguém que utiliza o sistema para manipular diretamente contas bancárias com operações como crédito, débito e transferência.
• Use Case (Escopo) Creditar em Conta: O sistema oferece o use case creditar em conta, para creditar um valor que foi depositado em uma dada conta.
• Descrição resumida1. O funcionário do banco identifica o número da conta2. O funcionário do banco entra com o valor a ser creditado3. O sistema soma o valor à conta e mostra sucesso da operação
1999RUP - DI / UFPE
Atividades Requisitos
Priorizar Use Cases
• Worker: Arquiteto
• Entrada para a arquitetura - Visão de use cases
• Passos:
1.Destacar use cases significantes para a arquitetura
• Saída: Descrição da arquitetura com a visão de use cases
1999RUP - DI / UFPE
Atividades Requisitos
Detalhar Use Cases
• Worker: Especificador de use cases
• Detalhar fluxo de eventos, com início, fim e interação com atores.
• Passos:
1.Estruturando a descrição / 2. Formalizando a descrição (casos mais complexos)
• Saída: Use cases detalhados
1999RUP - DI / UFPE
Atividades Requisitos
Detalhar Use Cases
Exemplo: Use Case Creditar em Conta
Pré-condição O banco já recebeu o dinheiro e a conta já deve estar cadastrada.
Fluxo Básico 1. O funcionário do banco entra com o número da conta. O sistema checa se o número da conta é consistente e existente no banco, e indica para o funcionário de algum modo.
2. O funcionário entra com o valor a ser creditado. O sistema credita o valor na conta.
3. O funcionário é notificado do resultado da operação
Fluxos Alternativos No passo 1, se a conta desejada não existe ou está inconsistente, o sistema cancela o crédito e avisa o funcionário. No passo 2, ator pode cancelar operação.
Pós-condição A instância do use case termina com a conta creditada, ou com cancelamento do crédito.
1999RUP - DI / UFPE
Atividades Requisitos
Protótipos e Modelagem da interface com o usuário
• Worker: Projetista de interface com o usuário
• Desenvolvimento de interfaces para que os atores possam utilizar os use cases de forma efetiva
• Passos:
1.Fazer projeto lógico da interface com o usuário / 2.Fazer projeto físico e protótipos
• Saída: Protótipos de interface com o usuário
1999RUP - DI / UFPE
Atividades Requisitos
Estruturar Modelo Use Cases
• Worker: Analista de sistemas
• Reestruturação do modelo com um todo para facilitar compreensão e modificação
• Passos:
1.Identificar descrições compartilhadas de funcionalidade 2.Identificar descrições adicionais e opcionais de funcionalidade 3.Outros relacionamentos
• Saída: Modelo de use cases estruturado
1999RUP - DI / UFPE
Atividades Requisitos
Estruturar Modelo Use Cases
• Exemplo:
1. Generalização:
Realizar transação Creditar em conta / Debitar de conta
2. Extensão:
Debitar de conta Debitar de conta com CPMF
3. Inclusão:
Transferência entre contas Creditar em conta / Debitar de conta
1999RUP - DI / UFPE
Atividades Requisitos
Fazer transação
Cadastrar conta
Remover conta
Funcionário Banco
Debitar de conta com CPMFCreditar em conta
Fazer transferência entre contas
Debitar de conta
<<extende>>
<<inclui>>
<<inclui>>