• Nenhum resultado encontrado

Documento de Especificação de Sistema Easy Ticket

N/A
N/A
Protected

Academic year: 2021

Share "Documento de Especificação de Sistema Easy Ticket"

Copied!
14
0
0

Texto

(1)

Documento de Especificação de Sistema

Easy Ticket

Projeto

Projeto Integrador II

Autor(es)

Marcos Augusto Dassie Noronha

Nathison Gomes Chaves Lopes

Versão / Data

0.1

/

03 de Agosto de 2016

0.2 / 04 de Agosto de 2016

0.3 / 17 de Agosto de 2016

(2)

Histórico de Versões

Data Versão Descrição das Revisões Autor

03/08/2016 0.1 Elaboração do Escopo; Marcos/Nathison

04/08/2016 0.2 Elaboração do Estudo de Viabilidade Marcos/Nathison

(3)

Sumário

1 - INTRODUÇÃO...5

1.1 Objetivos do Documento...5 1.2 Escopo do Produto...5 1.3 Materiais de Referência...5 1.3.1 Boleto Bancário... 6 1.4 Definições e Siglas...6 1.5 Estudo de Viabilidade...6

JUSTIFICATIVA DA ALTERNATIVA ESCOLHIDA...6

1.6 Identificação dos Requisitos...7

1.7 Prioridades dos Requisitos...7

1.7.1 Requisitos... 7

2 - REQUISITOS FUNCIONAIS...7

2.1 Requisitos Funcionais de Usuários...7

2.1.1 RF01 – Gerenciar Usuário do Sistema...8

2.1.2 RF02 – Gerenciar Usuário do Serviço...8

2.2 Requisitos Funcionais Gerais...8

2.2.1 RF03 – Gerenciar Promotoria do Evento...8

2.2.2 RF04 – Gerenciar Evento...8

2.2.3 RF05 – Gerenciar Ingressos...8

2.2.4 RF06 – Gerenciar Agência Bancária...8

2.2.5 RF07 – Venda de Ingresso em Caixa Físico...8

2.2.6 RF08 – Venda de Ingresso Online...9

2.2.7 RF09 – Reservar Ingressos...9

2.2.8 RF10 – Cancelar Venda...9

2.2.9 RF11 – Aprovar Pagamento...9

2.3 Requisitos Funcionais de Saída...9

2.3.1 RFS01 – Gerar Boleto...9

2.3.2 RFS02 – Gerar Ingresso...9

3 - REQUISITOS NÃO-FUNCIONAIS...9

3.1 Requisitos Não Funcionais de Operação...9

3.1.1 NF01 – Usabilidade... 10

3.1.2 NF02 – Desempenho...10

3.2 Requisitos Não Funcionais de Segurança...10

3.2.1 NF03 – Autenticação...10

4 - ESPECIFICAÇÃO...10

4.1 Casos de Uso...10 4.1.1 Autenticar Usuário...10 4.2 Mapas Conceituais...11 4.3 Diagrama de Classes...11 4.4 Diagramas de Sequência...11 4.5 Mapeamento Objeto-Relacional...11

(4)

APÊNDICE I – PROPOSTAS RECUSADAS...13

TABELA DE CUSTOS...13

ANEXO I – LEGISLAÇÃO...13

(5)

1 - Introdução

Este documento especifica os requisitos do sistema Easy Ticket, fornecendo aos desenvolvedores as informações necessárias para o projeto e implementação, assim como para a realização dos testes e homologação do sistema.

1.1 Objetivos do Documento

O objetivo deste documento é fornecer um roteiro para o desenvolvimento de sistemas de software utilizando os princípios da engenharia de software orientada a objetos com notação UML(Unified Modeling Language). É destinado a matéria de Projeto Integrado II servindo como instrumento de avaliação semestral da disciplina do sexto módulo do curso de Análise e Desenvolvimento de Sistemas do Instituto Federal de Ciência e Tecnologia do Estado de São Paulo campus de Presidente Epitácio.

1.2 Escopo do Produto

O Sistema EASY TICKET (ET) tem por objetivo auxiliar de forma segura e dinâmica o gerenciamento de atividades de venda de ingressos online, relacionadas a diversos eventos, disponibilizando formas de pagamentos, controle de eventos, reserva e controle de ingressos, cancelamento de compra de ingresso e cadastro de usuários.

O Sistema deverá realizar a organização de dados atribuídos pelo usuário, disponibilizando a criação de cadastro para usuários do serviço e do sistema, limitando seus níveis de acesso de acordo com os requisitos do processo a ser realizado. O usuário do serviço deverá ser capaz de realizar seu próprio cadastro através do site da empresa, tendo acesso aos eventos cadastrados e a compra de ingresso relacionada a um determinado evento.

Os usuários do sistema devem ser divididos em dois níveis de acessos diferentes, um acesso para o gerente do sistema, e outro para o usuário operador do caixa físico do sistema. O sistema deverá permitir ao gerente a manipulação de informações relacionadas ao cadastro de eventos, ingressos, bancos e operadores de caixa. Já o usuário operador de caixa deverá ter acesso apenas a venda de ingressos através de cartões ou dinheiro.

A venda de ingressos online deverá permitir ao usuário do serviço duas formas de pagamentos, através de cartões ou boletos bancários, validando o pagamento para a liberação do ingresso, que deverá ser disponibilizado de forma online para impressão. A venda de ingresso também deverá permitir a escolha do lugar desejado pelo cliente, fornecendo informações a respeito dos possíveis ambientes existentes no evento e os lugares disponíveis para o mesmo.

O sistema deverá reservar uma determinada quantidade de ingressos caso a compra dos mesmos tenha sido feita através de boleto bancário, mantendo os ingressos reservados no tempo estipulado para o vencimento do boleto ou até a confirmação de seu pagamento. A reserva de ingressos também deverá ser realizada assim que o usuário do serviço iniciar seu cadastro de compra, reservando a quantidade de ingressos informada pelo usuário no início da operação, caso a compra não seja finalizada em quinze minutos após a reserva de ingressos os mesmos deverão ser liberados para venda novamente, compras através de boleto não deverão ser permitidas na data anterior do evento.

Todas as informações relacionadas as movimentações do negócio deverão ser mantidas em um sistema de banco de dados, garantindo a segurança e integridade dos dados, disponibilizando um fácil acesso para a verificação das mesmas.

O Sistema EASY TICKET proporcionará a empresa um alto nível de controle e qualidade no serviço prestado, possibilitando a inserção e acompanhamento de informações de forma clara e segura e em tempo real, já que o mesmo será desenvolvido em aplicação web, possibilitando acesso online ao sistema.

1.3 Materiais de Referência

Esta sessão aborda as informações necessárias para a manipulação de serviços já existentes no mercado, alinhando as informações do desenvolvimento de acordo com as normas já expostas pelos sistemas disponíveis.

(6)

1.3.1 Boleto Bancário

Para gerar boletos bancários são necessários alguns dados que devem ser solicitados no banco a ser vinculado aos serviços da empresa. Quem disponibiliza estas informações é o gerente do banco onde a empresa possua sua conta-corrente. O cliente deverá fornecer a carteira de informações de cobrança bancária, disponibilizada pelo próprio gerente do banco.

1.4 Definições e Siglas

Nome Sigla

Easy Ticket ET

Hardware HD

Serviço de Atendimento ao Consumidor SAC

1.5 Estudo de Viabilidade

Esta sessão apresenta a alternativa selecionada pelo cliente (Solução A). A alternativa rejeitada está presente no apêndice 2.

Justificativa da Alternativa Escolhida

Visando na economia do projeto a solução escolhida é a que apresenta o menor custo, garantindo equipamentos de qualidade a um preço acessível, resguardando também a utilização de um SGBD de ponta, para um armazenamento de dados mais robusto e seguro.

Solução A:

O Fluxo de informações cotidianas da empresa poderão ser mantidas através de serviços de banco de dados Oracle, que garantirá o armazenamento de informações. O computador Positivo contará com um Sistema Operacional que auxiliará a execução do sistema.

Tabela de Custos

Produto Licenças Unidades Valor Total

Hostgator Mensal 1 R$ 39,99

Oracle Database Standard Edition 2 Processor, Software

1 R$ 12.114,42 Computador/PC Positivo Stilo DS3001

com Intel - Dual Core Windows 8.1 2GB 320GB Tela 15.6

Windows 1 R$ 1.160,00

Microsoft Sistema Operacional Windows 8.1 32/64 Bits

Software 1 R$ 420,90

Sistema Easy Ticket Mensal 1 R$ 800,00

Instalação Easy Ticket 1 R$ 3.000,00

(7)

1.6 Identificação dos Requisitos

Os requisitos são identificados através de códigos numerados RF01 (Requisitos Funcionais), variando de acordo com o objetivo do requisito sendo eles RFS01 (Requisitos Funcionais de Saída) e NF01 (Não Funcionais).

1.7 Prioridades dos Requisitos

A prioridade dos requisitos é definida como sendo:

Essencial: é considerado essencial todo requisito imprescindível ao funcionamento do sistema e cuja implementação seja obrigatória;

Importante: é todo requisito não essencial cuja ausência, porém, torna a utilização do sistema possível mesmo que não satisfatória;

Desejável: é o requisito cuja ausência ainda possibilita uma utilização satisfatória do sistema. Requisitos categorizados como desejáveis podem ser adiados para versões posteriores do sistema.

1.7.1 Requisitos

RF01 Gerenciar Usuário do Sistema. RF02 Gerenciar Usuário do Serviço. RF03 Gerenciar Promotoria do Evento RF04 Gerenciar Evento.

RF05 Gerenciar Ingressos

RF06 Gerenciar Agência Bancárias RF07 Venda de Ingresso em Caixa Físico RF08 Venda de Ingresso Online

RF09 Reservar Ingresso RF10 Cancelar Venda RF11 Aprovar Pagamento RFS01 Gerar Boleto RFS02 Gerar Ingresso NF01 Usabilidade NF02 Desempenho NF03 Autenticação

2 - Requisitos Funcionais

Essa sessão abordará os requisitos necessários para o funcionamento correto do sistema de acordo com o que foi solicitado pela empresa contratante.

(8)

2.1.1 RF01 – Gerenciar Usuário do Sistema

desejável importante X essencial

Trata-se de uma operação de gerenciamento de usuários do sistema, itens de informação: código do usuário do sistema, nome, sobrenome, login, senha.

2.1.2 RF02 – Gerenciar Usuário do Serviço

desejável importante X essencial

Trata-se de uma operação de gerenciamento de usuários do serviço, itens de informação: código do usuário do serviço, nome, sobrenome, cpf, rg, login, senha, rua, nº residência, bairro, cep, cidade, estado, telefone residencial, telefone celular, e-mail.

2.2 Requisitos Funcionais Gerais

2.2.1 RF03 – Gerenciar Promotoria do Evento

desejável importante

x essencial

Trata-se de uma operação de gerenciamento de promotores de eventos, itens de informação: código do promotor, cnpj, razão social, rua, número, bairro, cidade, estado, cep, e-mail, telefone 1, telefone 2, celular 1, celular 2.

2.2.2 RF04 – Gerenciar Evento

desejável importante

x essencial

Trata-se de uma operação de gerenciamento de eventos, itens de informação: código do promotor, código do evento, descrição, atração, data, hora, capacidade, ambientes, preços, idade mínima, casa de evento, rua, número, bairro, cidade, estado, cep, e-mail do evento, nº SAC do evento.

2.2.3 RF05 – Gerenciar Ingressos

desejável importante X essencial

Trata-se de uma operação de gerenciamento de ingressos, itens de informação: código do ingresso, código do evento, descrição, quantidade, ambiente, lugar, desconto, valor.

2.2.4 RF06 – Gerenciar Agência Bancária

desejável importante X essencial

Trata-se de uma operação de gerenciamento de agências bancárias, itens de informação: nome do banco, agência, número da conta, código do convênio, código do cedente, carteira, modalidade.

2.2.5 RF07 – Venda de Ingresso em Caixa Físico

desejável importante X essencial

Esta operação se inicia quando um usuário operador do caixa finaliza a operação da venda, informações necessárias: código de venda, código de ingresso, data, hora, tipo do pagamento, taxas, desconto, valor, código do usuário do sistema, nº guichê, cidade, estado.

(9)

2.2.6 RF08 – Venda de Ingresso Online

desejável importante X essencial

Esta operação se inicia quando um usuário do sistema finaliza a operação de compra, informações necessárias: código da venda, código de ingresso, código do usuário do serviço, data, hora, tipo do pagamento, taxas, desconto, valor.

2.2.7 RF09 – Reservar Ingressos

desejável importante X essencial

Esta operação se inicia quando um usuário de serviço inicia ou finaliza a compra de ingresso no sistema, informações necessárias: código da venda, código do ingresso, tempo de reserva, status do pagamento.

2.2.8 RF10 – Cancelar Venda

desejável importante X essencial

Esta operação se inicia quando um usuário do serviço deseja cancelar o pagamento de uma compra de ingresso, informações necessárias: Código de usuário, código de venda.

2.2.9 RF11 – Aprovar Pagamento

desejável importante X essencial

Esta operação permite ao usuário do sistema aprovar pagamentos de vendas em aberto, informações necessárias: Código de venda, código do usuário do sistema.

2.3 Requisitos Funcionais de Saída

2.3.1 RFS01 – Gerar Boleto

desejável importante X essencial

Esta operação se inicia quando a opção de pagamento via boleto é selecionada no fim da venda de ingresso, informações necessárias: Código da venda, código do ingresso, código do usuário, código do evento, data de vencimento, taxas de boleto, valor.

2.3.2 RFS02 – Gerar Ingresso

desejável importante X essencial

Esta operação se inicia quando o pagamento de um ingresso é confirmado pelo sistema, informações necessárias: Código da venda.

3 - Requisitos Não-Funcionais

Os requisitos não funcionais expõem os requisitos não solicitados pelo stakeholder, mas que devem estar implícitos no desenvolvimento para agregar qualidade ao manuseio do software.

(10)

3.1.1 NF01 – Usabilidade

desejável X importante

essencial

Cada tela de entrada de dados do sistema deve confirmar a inclusão ou cancelamento da operação para o encerramento da janela.

3.1.2 NF02 – Desempenho

desejável X importante

essencial

É necessário que cada operação – entrada, consulta, alteração, exclusão – que envolva interação com o usuário não exceda o tempo espera de dois segundos.

3.2 Requisitos Não Funcionais de Segurança

3.2.1 NF03 – Autenticação

desejável importante X essencial

É exigida a identificação do usuário através de um processo de autenticação para navegação no sistema, informações necessárias: Login, senha.

4 - Especificação

Este capítulo fornece as especificações que descrevem tecnicamente os requisitos...

4.1 Casos de Uso

Os casos de uso do sistema... A Figura 1 apresenta um Caso de Uso geral do sistema no qual pode-se observar...

4.1.1 Autenticar Usuário

[Diagrama do caso de uso]

(11)

Caso de uso:

Pré-requisito: não estar cadast

Nome: Autenticar Usuário

Requisitos

relacionados: RF01, RNF03.

Ator(es)

primário(s): Usuário

Ator(es)

secundário(s): Banco de Dados

Pré-condição: Usuário não estar autenticado no sistema.

Objetivo: Usuário estar identificado e possuir acesso a funcionalidades protegidas do

sistema.

Pós-condição: Não há.

Fluxo Básico: 1 – Usuário requisita autenticação;

2 – Sistema requisita dados para autenticação (nome, senha); 3 – Usuário fornece dados requisitados;

4 – Sistema autentica informações; Fluxo

Alternativo: 4a – Sistema verifica que dados requisitados não são válidos. 4a1 – Sistema registra a tentativa e avisa que não foi possível autenticação; 4a2 – Usuário sai do caso de uso ou retorna ao passo 2.

4b – Sistema verifica que número máximo de tentativas inválidas foi atingido. 4b1 – Sistema avisa que acesso não pode ser dado a esse usuário por excesso de tentativas inválidas;

4b2 – Sistema termina caso de uso.

4.2 Mapas Conceituais

4.3 Diagrama de Classes

4.4 Diagramas de Sequência

(12)
(13)

Apêndice I – Propostas Recusadas

Solução B:

O fluxo constante de informações em atividades de cadastros de contratos, necessitam de um alto nível de controle e segurança de informações, visando na performance e eficiência de um bom desenvolvimento das tarefas diárias implantaremos um sistema integrado a um SGBD (Sistema de Gerenciamento de Banco de Dados) que auxiliará o controle dos contratos disponíveis no sistema. Informará com exatidão os valores e cálculos utilizados pelo sistema.

Tabela de Custos

Produto Licenças Un. Valor un.

Hostgator Mensalidade 1 R$ 39,99

Oracle Database Enterprise Edition

Processor, Software

1 R$ 32.850,00

Oracle Security backup Software 1 R$ 770,00

Inspiron Small Desktop I5 Win 8.1/ RAM 4GB/ 1TB

Windows 1 R$ 1.992,00

Microsoft Sistema Operacional Windows 8.1 32/64 Bits

Software 1 R$ 420,90

Sistema Easy Ticket Mensalidade 1 R$ 800,00

Instalação 1 R$ 3.000,00

TOTAL R$ 39.872.89

Anexo I – Legislação

Tabela de Bancos e carteiras:

BANCO DO BRASIL (Carteira 18 – Convênio de 6, 7 ou 8 dígitos) UNIBANCO (Carteira Especial – Sem Registro

CAIXA (Carteira SR[SICOB, SINCO e SIGCN])

ITAU BANKLINE (Carteira 175/174/178/104/109 – Sem Registro)

HSBC (Carteira CNR – Sem Registro)

BRADESCO (Carteira 06/03 – Sem Registro)

BANESTES (Carteira 00 - Sem Carteira)

BANCO REAL ABN AMRO (Carteira 57 – Sem Registro)

NOSSA CAIXA/BB (Carteira 5[Cobrança Direta] ou Carteira 1[Cobrança Simples])

SUDAMERIS (Carteira 57[Cobrança sem registro] ou Carteira 20[Cobrança com registro])

(14)

SANTANDER BANESPA(Banco

033 – Antigo 353) (Carteira 102 – Sem Registro) SANTANDER BANESPA(Banco

033) (Carteira COB – Sem Registro)

BANCOOB (Carteira 01[SICOOB] – Sem Registro)

Referências

Documentos relacionados

Não tem informações sobre a sua modificação química e, pelo exposto acima, no presente trabalho tem-se estudado a modificação química deste amido variando a concentração

7.7.1- Indicação de um representante discente do CEPE para compor comissão que escolherá o professor a ser agraciado com a Medalha de Ouro Peter H... 7.10- Licença para

Forte compromisso Corporativo de RSE Forte compromisso Corporativo de RSE Forte compromisso Corporativo de RSE Forte compromisso Corporativo de RSE Expo Perspectivas 50 años Escuela

c.4) Não ocorrerá o cancelamento do contrato de seguro cujo prêmio tenha sido pago a vista, mediante financiamento obtido junto a instituições financeiras, no

Os autores relatam a primeira ocorrência de Lymnaea columella (Say, 1817) no Estado de Goiás, ressaltando a importância da espécie como hospedeiro intermediário de vários parasitos

A Arktus se responsabiliza pelas características técnicas e de segurança do equipamento somente em casos que o equipamento tenha sido utilizado de acordo com as instruções de uso

O CFOP (Código Fiscal de Operações e Prestações) será o 6.401 (venda de produção do estabelecimento em operação com produto sujeito ao regime de substituição

Para que o estudo seja possível, houve um levantamento bibliográfico sobre o cenário do sistema produtivo da saúde no Brasil, tendo em vista a proteção