TRABALHO ROSA E ALESSANDRO 2º PARTE, Trabalhos de Análise de Sistemas de Engenharia

Baixe TRABALHO ROSA E ALESSANDRO 2º PARTE e outras Trabalhos em PDF para Análise de Sistemas de Engenharia, somente na Docsity!

CURSO DE TECNOLOGIA EM ANÁLISE E

DESENVOLVIMENTO DE SISTEMA

A.S.O OBJETO

MANAUS - AM

Rosa Bethânia Serique

Alessandro Andrade

TURMA: DSN03S

A.S.O OBJETO

Trabalho apresentado à disciplina

A.S.O Objeto para obtenção de nota

parcial do 1º Bimestre.

Professora: Dalvanira

MANAUS - AM

Escolher forma de pagamento

Breve Descrição

Este use case descreve como é realizado o processo da escolha da forma de pagamento da compra de uma passagem. A forma de pagamento pode ser dividida em pagamento Web ou pagamento guichê.

Atores:

Usuário

Fluxo de Eventos

Fluxo Básico

Este use case começa quando uma operação de venda de passagem está sendo realizada.

1. O sistema recebe os dados da operação de compra;
2. O usuário escolhe a forma de pagamento;
3. O sistema mostra uma mensagem confirmando a operação.

Fluxos Alternativos

Nenhum

Requisitos Especiais

Requisitos de performance (velocidade)

Pré-Condições

Uma operação de venda de passagem necessita estar sendo realizada.

Pós-Condições

A forma de pagamento da venda é registrada no sistema.

Pontos de Extensão

Nenhum.

Pagamento Guichê

Breve Descrição

Este use case descreve como é realizada a escolha da forma de pagamento no guichê da empresa.

Atores:

Usuário vendedor

Fluxo de Eventos

Fluxo Básico

Segue o fluxo de eventos básico de escolher forma de pagamento, exceto no passo 2 em que deve ser seguido os passos abaixo:

1. O vendedor informa a escolha do cliente entre pagar com cartão de crédito ou a vista;
2. Se escolher pagar com cartão, deverá informar o número do cartão e o CPF;
3. Ainda se tiver escolhido pagamento com cartão, o sistema se comunica com um sistema externo de gerenciamento de cartão de crédito que verifica a validade dos dados;

Fluxos Alternativos

Dados inválidos Se após o passo 3, os dados não forem validados, uma mensagem de erro é apresentada e retorna ao passo 2.

Pagamento Web

Breve Descrição

Este use case descreve como é realizado a escolha da forma de pagamento pela Web.

Atores:

Usuário cliente

Fluxo de Eventos

Fluxo Básico

Segue o fluxo de eventos básico de escolher forma de pagamento, exceto no passo 2 em que é deve ser seguido os passos abaixo:

1. sistema recebe os dados da operação de compra;
2. usuário deve informar o número do cartão e CPF;
3. sistema se comunica com um sistema externo de gerenciamento de cartão de crédito que verifica a validade dos dados.

Fluxos Alternativos

Dados inválidos Se após o passo 3, os dados não forem validados, uma mensagem de erro é apresentada e retorna ao passo 2.

Atores:

Usuário (cliente ou vendedor)

Fluxo de Eventos

Fluxo Básico

Este use case começa quando o ator quer cancelar uma compra ou reserva de passagem.

1. O sistema recebe os dados do cliente;
2. O sistema verifica se o cliente realmente está cadastrado;
3. O usuário informa a compra/reserva a ser cancelada.
4. O sistema verifica se é possível cancelar a compra/reserva da passagem.
5. O sistema é atualizado

Fluxos Alternativos

Usuário não cadastrado Se no passo 2 o usuário não estiver cadastrado: Inclui Cadastrar Cliente; Continua o fluxo de eventos básico no passo 3.

Compra/Reserva inexistente O Se no passo 4 for detectado que a compra/reserva da passagem não existe , o sistema informa o erro ao usuário e volta ao passo 3 do fluxo básico.

Prazo de cancelamento esgotado Se no passo 4 for detectado que o prazo de cancelamento já esgotou, o sistema informa o erro.

Requisitos Especiais

Requisitos de performance (velocidade) e usabilidade.

Pré-Condições

O usuário estar cadastrado no sistema.

Pós-Condições

A passagem passa para o estado disponível ou o sistema informa um erro ocorrido.

Pontos de Extensão

Nenhum.

Remarcar Passagem

Breve Descrição

Este use case descreve como um usuário remarca uma passagem, isto é, o usuário tem a possibilidade de trocar uma passagem previamente comprada por outra.

Atores:

Usuário (cliente ou vendedor)

Fluxo de Eventos

Fluxo Básico

É iniciado quando o usuário solicita a remarcação de uma passagem previamente comprada.

**1. O sistema recebe os dados do cliente

2. O sistema verifica se o cliente está cadastrado.
3. O usuário informa a passagem a ser remarcada.
4. O sistema verifica se é possível remarcar a passagem.
5. O usuário escolhe a nova viagem. 6.** Inclui verificar vagas disponíveis. 7. Inclui emitir confirmação de venda/reserva/remarcação

Fluxos Alternativos . Usuário não cadastrado Se no passo 2, for verificado que o usuário não está cadastrado: Inclui Cadastrar Cliente Continua a partir do passo 3 do fluxo básico.

A passagem a ser remarcada não existe.

Se no passo 4 a passagem não existir, o sistema solicita que o usuário informe a passagem a ser remarcada correta retornando ao passo 3.

A passagem a ser remarcada não foi comprada.

Se no passo 4 a passagem não foi comprada, o sistema solicita que o usuário informe a passagem a ser remarcada correta retornado ao passo 3.

Prazo de reserva esgotado Caso a solicitação de reserva seja feita fora do prazo mínimo estipulado o sistema deve cancelar a operação e informar ao usuário.

Requisitos Especiais

Requisitos de performance (velocidade) e usabilidade.

Pré-Condições:

O ator deve estar cadastrado e deve ter passagens disponível para reserva.

Pós-condições:

O estado da passagem muda de disponível para reservada.

Pontos de extensão:

Nenhum

Verificar as vagas disponíveis numa viagem

Breve Descrição

Este use case descreve como o sistema gera a listagem das vagas disponíveis numa viagem.

Atores:

Usuário (cliente ou vendedor)

Fluxo de Eventos

Fluxo Básico

Este use case começa quando um cliente quer saber que vagas estão disponíveis numa viagem ou quando uma operação necessita verificar as vagas disponíveis para continuar sua execução.

1. ator informa a viagem.
2. O sistema informa as vagas disponíveis.

Fluxos Alternativos

Não há vagas disponíveis Se o ator informar uma viagem que não tem nenhuma vaga disponível será mostrada uma mensagem informando que não há vagas disponível.

Requisitos Especiais

Nenhum.

Pré-Condições

Nenhuma.

Pós-Condições

Se o use case for realizado com sucesso o usuário recebe a informação das vagas disponíveis na viagem

Pontos de Extensão

Nenhum.

Emitir confirmação de compra, reserva ou remarcação

Breve Descrição:

Este use case descreve como o sistema deve confirmar compra, reserva ou remarcação da passagem. A confirmação pode ser confirmação web ou confirmação guichê.

Atores:

Usuário (cliente ou vendedor)

Fluxo de eventos:

Fluxo Principal:

É iniciado por uma operação do sistema;

1. O sistema recebe os dados da operação;
2. O sistema prepara a confirmação;
3. O sistema emite confirmação;

Fluxo Alternativo:

Não há.

Requisitos Especiais

Nenhum.

Pré-Condições

Venda, reserva ou remarcação de passagem deve estar sendo realizada.

Pós-Condições

O usuário receberá uma notificação por e-mail confirmando a realização da venda, reserva ou remarcação da passagem

Pontos de Extensão

Nenhum.

Cadastrar Novas Empresas Aéreas

Breve Descrição:

Este use case descreve como um gerente cadastra uma nova empresa aérea que a disponibilizará aos seus clientes.

Atores:

Gerente

Fluxo de eventos:

Fluxo Básico:

É iniciado quando o gerente pretende cadastrar uma nova linha no sistema.

**1. O gerente se identifica.

2. O sistema verifica se o gerente está cadastrado.
3. O gerente informa a nova empresa a ser cadastrada.
4. O sistema verifica se é possível cadastrar empresa.
5. O sistema atualiza o cadastro.**

Fluxo Alternativo:

O gerente não está cadastrado no sistema.

Se após o Passo 2 o gerente não estiver cadastrado então este não terá a permissão de cadastrar uma nova empresa e a operação é finalizada.

A empresa já está cadastrada.

Se após o Passo 4 a linha já existir no cadastro, o sistema informa ao gerente e

retorna ao Passo 3.

Requisitos Especiais

Requisitos de performance (velocidade) e usabilidade.

Pré-Condições

Nenhuma.

Pós-Condições

Se o use case for realizado com sucesso, uma nova linha constará no cadastro do sistema e novas viagens poderão ser vinculadas a essa linha.

Pontos de Extensão

Nenhum

Cadastrar novos pacotes

Breve Descrição

Este use case descreve o processo de cadastramento de novos pacotes feito pela administração.

Atores:

Gerente

Fluxo de Eventos

Fluxo Básico

Este use case começa quando um gerente quer cadastrar novas viagens no sistema.

**1. gerente se identifica.

2. sistema verifica se o gerente está cadastrado.
3. O gerente informa os dados dos novos pacotes.
4. O sistema verifica se esse novo pacote de viagem já existe.
5. O sistema atualiza o cadastro.**

Fluxos Alternativos

O gerente não está cadastrado no sistema.

Se após o Passo 2 o gerente não estiver cadastrado então este não terá a permissão de cadastrar um novo pacote e a operação é finalizada.

Viagem já existente Se no passo 3 o sistema detectar que o pacote de viagem sendo cadastrado já existe, o sistema deve informar o erro e voltar ao passo 3 do fluxo básico.

Linha não cadastrada Se no passo 3 a linha aérea à qual o novo pacote pertence não existir; Inclui cadastrar linha aérea. Volta para o passo 3 do fluxo básico.

Requisitos Especiais

Requisitos de performance (velocidade) e usabilidade.

Pré-Condições

Nenhuma

Pós-Condições

Se o use case for realizado com sucesso novas viagens estarão inseridas no cadastro.

Pontos de Extensão

Nenhum.

Gerar relatórios vendas

Breve Descrição

Este use case descreve como o sistema gera os relatórios para o gerente. Os relatórios podem ser das vendas de passagens aéreas e pacotes de viagens realizadas e das reservas efetuadas.

Atores:

Gerente

Fluxo de eventos:

Fluxo Principal:

É iniciado pelo gerente.

**1. gerente se identifica.

2. sistema verifica se o gerente está cadastrado.
3. gerente informa o tipo do relatório;
4. sistema retorna o relatório com opções de imprimir e salvar arquivo.**

Fluxo Alternativo:

O gerente não está cadastrado no sistema.

Se após o Passo 2 o gerente não estiver cadastrado então este não terá a permissão para solicitar relatórios e a operação é finalizada.

Requisitos Especiais

Nenhum.

Pré-Condições

Nenhuma.

Pós-Condições

Nenhuma

Pontos de Extensão

Nenhum

Apêndices

Nesta seção descrevemos os diagramas de casos de uso do sistema. Os

diagramas foram classificados pelos atores relacionados com cada caso de uso

presente nos diagramas

1. Diagramas de casos de uso relacionados ao usuário

3. Diagrama de casos de uso relacionados ao sistema de

gerenciamento de cartões de crédito