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
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
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...6JUSTIFICATIVA 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...11APÊNDICE I – PROPOSTAS RECUSADAS...13
TABELA DE CUSTOS...13
ANEXO I – LEGISLAÇÃO...13
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.
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
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.
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.
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.
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]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
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])
SANTANDER BANESPA(Banco
033 – Antigo 353) (Carteira 102 – Sem Registro) SANTANDER BANESPA(Banco
033) (Carteira COB – Sem Registro)
BANCOOB (Carteira 01[SICOOB] – Sem Registro)