Documento de Especificação de Sistema IngreSys

Transcrição

1 Documento de Especificação de Sistema IngreSys Projeto Autor(es) Projeto Integrador II Roberto Socanti Santos Tariana de Jesus Gomes Leite Versão / Data 0.6 / 8 de setembro de 2016

2 Histórico de Versões Data Versão Descrição das Revisões Autor 28/07/ Criação do documento; Roberto / Tariana 28/07/ Definição do escopo; Roberto / Tariana 03/08/ Definição do estudo de viabilidade; Roberto / Tariana 04/08/ Definição do estudo de viabilidade; Roberto / Tariana 10/08/ Definição dos Requisitos; Roberto / Tariana 24/08/ Especificação dos Requisitos; Roberto / Tariana 08/10/ Diagramas de Casos de Uso e Classes Roberto / Tariana página 2 de 20

3 Sumário 1 - INTRODUÇÃO Objetivos do Documento Início Escopo do Produto Materiais de Referência Definições e Siglas Estudo de Viabilidade Identificação dos Requisitos Prioridades dos Requisitos Requisitos REQUISITOS FUNCIONAIS Requisitos Funcionais de Administrador RF01 Gerenciar Bilheteria RF02 Gerenciar Agenciador RF03 Gerenciar Administrador Requisitos Funcionais de Agenciador RF04 Gerenciar Eventos Requisitos Funcionais de Espectador RF05 Gerenciar Espectador RF06 Comprar Ingressos por Boleto RF07 Comprar Ingressos à Vista Requisitos Funcionais de Bilheteria RF08 Abrir Caixa da Bilheteria RF09 Fechar Caixa da Bilheteria RF10 Comprar Ingressos à Vista REQUISITOS NÃO-FUNCIONAIS Requisitos Não Funcionais de Operação NF01 Usabilidade NF02 Desempenho Requisitos Não Funcionais de Segurança NF03 Autenticação Requisitos Não Funcionais de Relatório NF04 Relatório Mensal de Vendas NF05 Relatório de Agenciadores Cadastrados NF06 Relatório Mensal de Vendas por Agenciador NF07 Relatório de Pagamentos Realizados NF08 Relatório de Venda de Ingressos por Evento ESPECIFICAÇÃO Casos de Uso Gerenciar Bilheteria Gerenciar Agenciador...12 página 3 de 20

4 4.1.3 Gerenciar Eventos Gerenciar Espectador Gerenciar Administrador Abrir Caixa da Bilheteria Fechar Caixa da Bilheteria Venda de Ingressos à Vista Venda de Ingressos por Boleto Mapas Conceituais Diagrama de Classes Diagramas de Sequência Mapeamento Objeto-Relacional...17 APÊNDICE I PROPOSTAS RECUSADAS...19 ANEXO I LEGISLAÇÃO...19 página 4 de 20

5 1 - Introdução Este documento apresenta os requisitos do sistema de gerenciamento de eventos. O sistema possui ferramentas para auxiliar nas vendas de ingressos via Internet ou presencial, pela bilheteria. O sistema permite o controle de eventos, criação de datas e horários, lugares e definição de ingressos. 1.1 Objetivos do Documento Início Este documento tem por objetivo descrever quais os requisitos do sistema servindo de acordo entre as partes envolvidas cliente e analista / desenvolvedor de sistemas. 1.2 Escopo do Produto A empresa deseja expandir suas vendas de ingressos para eventos e decide entrar para o mercado online. Os eventos podem ser artísticos, esportivos ou culturais e ocorrem em determinada data e local que são previamente definidos pelo agenciador. Para que ocorra um evento o agenciador deve criá-lo utilizando o sistema. Mesmo que os espetáculos sejam recorrentes cada um possui seu próprio registro e identificação, não sendo utilizado o conceito de sessões que se repetem. O sistema permitirá que o agenciador copie todos os dados de um evento para facilitar a criação de uma nova apresentação em um outro local e data. O espectador poderá comprar seus ingressos online após cadastro e a venda é efetivada quando o pagamento via cartão de crédito ou boleto é confirmada. A compra cuja a forma de pagamento selecionada seja boleto bancário manterá a reserva do ingresso por um dia útil desde que a compra não ocorra na véspera do evento, pois não será permitida a venda de ingressos via boleto em vésperas de eventos. O sistema permitirá a venda de ingressos para eventos com locais numerados. As apresentações com locais não numerados possuem apenas o número de série do bilhete. A numeração é dada pelo agenciador do espetáculo no momento de sua criação. A reserva imediata de um ingresso ocorre por vinte minutos ou até que o comprador finalize a compra ou desista do ingresso. Compras efetuadas via cartão de crédito tem sua aprovação ou rejeição imediata e compras efetuadas via boleto bancário mantém uma reserva até o próximo dia útil. O Espectador que preferir efetuar sua compra em um ponto de venda fixo, haverá bilheterias disponíveis em determinados pontos da cidade. O Espectador ao comprar em um ponto de venda fixo tem as opções de pagamento à vista no dinheiro ou cartão de crédito, nas bilheterias não serão permitidas as vendas por boleto bancário. 1.3 Materiais de Referência 1.4 Definições e Siglas GB RAM Gigabyte Memória de acesso rápido (Random Access Memory) página 5 de 20

6 1.5 Estudo de Viabilidade Solução: Sistema WEB O sistema objetiva desempenho, agilidade e comodidade na venda de ingressos. O desenvolvimento desta alternativa permitirá que o Espectador compre ingressos via internet ou pessoalmente em uma bilheteria em determinado ponto da cidade. O software será implementado utilizando a linguagem de programação PHP com o sistema gerenciador de banco de dados PostgreSQL. A tabela que representa os requisitos mínimos para a implantação do sistema é apresentada a seguir: Quantidade Descrição Valor Unitário 1 Sistema R$ 7.000,00 1 Hospedagem do site R$ 539,64 Total: R$ 7.539,64 O sistema depende minimamente de um computador com 2GB de RAM e um processador Dual Core de qualquer fabricante. O servidor tem a função de executar o sistema, além de manter e disponibilizar o banco de dados dos eventos. Benefícios: PHP é uma linguagem gratuita. Depende de instalação básica de seus componentes para utilização. É, também, uma linguagem multiplataforma, o que facilita a integração e portabilidade. PostgreSQL é um sistema de gerenciamento de banco de dados multiplataforma, livre e de fácil integração com a linguagem de programação PHP. 1.6 Identificação dos Requisitos Os requisitos são identificados através de códigos RF (Requisitos Funcionais) e numerados em sequencia de acordo com cada requisito. Os requisitos não funcionais são identificados através de códigos NF (Requisitos não Funcionais) e numerados em sequencia de acordo com cada requisito. 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 Requisitos Gerenciar Bilheteria; Gerenciar Agenciador; Gerenciar Administrador; Gerenciar Eventos; Gerenciar Espectador; página 6 de 20

7 Comprar Ingressos à Vista; Comprar Ingressos por Boleto; Abrir Caixa da Bilheteria; Fechar Caixa da Bilheteria. 2 - Requisitos Funcionais Os requisitos funcionais estabelecerão como o sistema vai agir, e o que deve fazer, com as funcionalidades e serviços. 2.1 Requisitos Funcionais de Administrador Esta seção traz os requisitos relacionados ao Administrador do Sistema. Estes requisitos descrevem as atividades dos casos de uso gerenciar bilheteria, gerenciar agenciador e gerenciar administrador RF01 Gerenciar Bilheteria O administrador é responsável por gerenciar as atividades da bilheteria. As bilheteria podem vender ingressos em um ponto de venda fixo, venda esta que pode ser feita no dinheiro ou no cartão de crédito. O cliente que deseja ser bilheteria deve enviar uma solicitação ao administrador. O administrador analisa as solicitações de bilheteria enviadas e as aprova ou não. Solicitações aprovadas dão à bilheteria a permissão de vender ingressos na hora. Não há reserva de ingressos. Cabe ao administrador também remover a permissão da bilheteria, tornando a inativa RF02 Gerenciar Agenciador O administrador é responsável por manter os dados do agenciador no sistema. O agenciador deve enviar uma solicitação de cadastro no sistema ao administrador. O administrador analisa a solicitação enviada pelo agenciador e as aprova ou não. Solicitações aprovadas dão ao agenciador a permissão de gerenciar eventos Cabe ao administrador também remover a permissão do agenciador, tornando o inativo RF03 Gerenciar Administrador O administrador é responsável pelo gerenciamento de suas informações. 2.2 Requisitos Funcionais de Agenciador X essencial Esta seção traz os requisitos relacionados ao Agenciador. Estes requisitos descrevem as atividades do caso de uso gerenciar eventos RF04 Gerenciar Eventos O agenciador cria eventos e os gerencia. Ao criar um evento o agenciador deve definir o tipo do evento, data, seu local de realização e quantidade de ingressos. página 7 de 20

8 O agenciador também pode efetuar o cancelamento do evento, no ato do cancelamento ele deverá informar quais foram os motivos. O agenciador pode realizar buscas para verificar a quantidade de ingressos já vendidos e os disponíveis. 2.3 Requisitos Funcionais de Espectador Esta seção traz os requisitos relacionados ao Espectador. Estes requisitos descrevem as atividades do caso de uso gerenciar espectador, comprar ingressos por boleto e comprar ingressos a vista RF05 Gerenciar Espectador O Espectador que deseja comprar ingressos deve estar cadastrado no sistema. X essencial O Espectador já cadastrado pode verificar seus históricos de compra, alterar seus dados ou excluir sua conta, tornando a inativa RF06 Comprar Ingressos por Boleto O espectador acessa o sistema, escolhe o evento desejado e o sistema o direciona para selecionar os lugares disponíveis. Após escolhido o lugar, o cliente finaliza a compra e escolhe a forma de pagamento boleto. O pagamento por boleto implica na reserva do ingresso por um dia útil, até que o boleto seja pago, após este prazo a compra e dada como finalizada se o boleto for pago ou cancelada se não houver o pagamento RF07 Comprar Ingressos à Vista O espectador acessa o sistema, escolhe o evento desejado e o sistema o direciona para selecionar os lugares disponíveis. Após escolhido o lugar, o espectador finaliza a compra e escolhe a forma de pagamento por cartão de crédito. O pagamento por cartão de crédito é uma compra a vista, portanto não a reserva do ingresso. Se o pagamento for aprovado o espectador pode retirar o seu voucher na hora ou se não for aprovado a compra é cancelada. 2.4 Requisitos Funcionais de Bilheteria Esta seção traz os requisitos relacionados à Bilheteria. Estes requisitos descrevem as atividades do caso de uso abrir caixa da bilheteria, fechar caixa da bilheteria e comprar ingressos à vista RF08 Abrir Caixa da Bilheteria Ao acessar o sistema o responsável pela bilheteria deve informar qual o valor inicial RF09 Fechar Caixa da Bilheteria Ao finalizar o dia o responsável pela bilheteria deve informar o valor de fechamento da bilheteria RF10 Comprar Ingressos à Vista O espectador vai até a bilheteria para comprar seus ingressos. O responsável pela bilheteria acessa o sistema, seleciona o evento desejado pelo expectador, o sistema o direciona para selecionar os lugares disponíveis. Após escolhido o lugar, página 8 de 20

9 a compra é finalizada e o espectador pode escolher entre as formas de pagamento por cartão de crédito ou em dinheiro. O pagamento efetuado na bilheteria é sempre a vista, portanto não a reserva do ingresso. O pagamento por cartão de crédito for aprovado o espectador pode retirar o seu voucher na hora ou se não for aprovado a compra é cancelada. 3 - Requisitos Não-Funcionais Os requisitos não funcionais definem as propriedades do sistema e suas restrições. 3.1 Requisitos Não Funcionais de Operação abaixo. São considerados Requisitos Não Funcionais de Operação todos requisitos identificados NF01 Usabilidade X essencial Cada tela de entrada de dados do sistema deve prover meios de um novo usuário ser capaz de fazer um pedido de compra de um ingresso dez minutos de orientação NF02 Desempenho X 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. Situações extremas são toleradas uma vez em cada mil para cinco segundos. 3.2 Requisitos Não Funcionais de Segurança Compreende-se como Requisito Não Funcional de Segurança todo requisito que envolva a segurança dos dados, bem como as permissões de acesso às suas funcionalidades, como por exemplo, usar criptografia em senhas e liberar acesso aos menus do sistema de acordo com a hierarquia do usuário NF03 Autenticação É exigida a identificação do usuário através de um processo de autenticação para acessas as funcionalidades do sistema. Este acesso precisa ser seguro, com autenticação em nível do. 3.3 Requisitos Não Funcionais de Relatório O sistema disponibiliza ao seu usuário relatórios das transações realizadas NF04 Relatório Mensal de Vendas A bilheteria pode solicitar relatórios de vendas por mês no sistema. Para tanto deve estar autenticado no sistema e selecionar qual o mês de referencia para a busca. O agenciador pode solicitar relatórios de vendas por mês no sistema. Para tanto deve estar autenticado no sistema e selecionar qual o mês de referencia para a busca NF05 Relatório de Agenciadores Cadastrados O administrador pode solicitar relatórios de agenciadores cadastrados no sistema. Para tanto deve estar autenticado no sistema e selecionar o agenciador. página 9 de 20

10 3.3.3 NF06 Relatório Mensal de Vendas por Agenciador O administrador pode solicitar o relatório de vendas mensal de cada agenciador cadastrado no sistema. Para solicitar o relatório o administrador deve estar autenticado no sistema NF07 Relatório de Pagamentos Realizados O administrador pode solicitar o relatório de pagamentos realizados. O administrador deve estar autenticado no sistema NF08 Relatório de Venda de Ingressos por Evento O agenciador pode solicitar o relatório de venda de ingressos por evento. O agenciador deve estar autenticado no sistema. 4 - Especificação Este capítulo fornece as especificações que descrevem tecnicamente os requisitos funcionais do sistema. 4.1 Casos de Uso Os casos de uso do sistema especificam as funcionalidades propostas para o sistema IngreSys. A Figura 1 apresenta um Caso de Uso geral do sistema. página 10 de 20

11 Figura 1: Diagrama de Caso de Uso do Sistema Gerenciar Bilheteria [Diagrama do caso de uso] Caso de uso: Gerenciar Bilheteria Pré-requisito: Administrador cadastrado. Nome: Requisitos relacionados: primário(s): secundário(s): Gerenciar Bilheteria RF01, NF02 Administrador; Bilheteria. Banco de Dados página 11 de 20

12 Pré-condição: Objetivo: Pós-condição: Fluxo Básico: Fluxo Alternativo: Administrador cadastrado e autenticado no sistema. Bilheteria ser identificada e possuir acesso a funcionalidades de compra de ingressos. 1 Administrador busca bilheterias já cadastradas; 2 Administrador cria, edita ou exclui uma bilheteria; 3 Bilheteria efetua a autenticação no sistema; 4 Bilheteria efetua compra de ingressos; 5 Sistema salva as alterações efetuas pelo usuário; 2a Sistema verifica se todos os dados foram inseridos corretamente. 2a1 Sistema registra a tentativa de alteração e informa que os dados não foram preenchidos corretamente; Gerenciar Agenciador [Diagrama do caso de uso] Caso de uso: Gerenciar Agenciador Pré-requisito: Administrador cadastrado. Nome: Requisitos relacionados: primário(s): secundário(s): Pré-condição: Objetivo: Pós-condição: Fluxo Básico: Fluxo Alternativo: Gerenciar Agenciador RF02, NF02 Administrador; Agenciador. Banco de Dados Administrador cadastrado e autenticado no sistema. Agenciador ser autenticado para utilizar as funcionalidades do sistema. 1 Agenciador envia solicitação de cadastro para o administrador; 2 Administrador busca os agenciadores cadastrados; 3 Sistema lista todos os agenciadores; 4 Administrador cria, edita ou exclui um agenciador; 5 Sistema salva as alterações efetuas pelo usuário; 1a Informações inválidas; 1a1 O administrador ao constatar irregularidade nos dados cadastrais do agenciador nega a solicitação de cadastro; 1a2 Retorna para o fluxo 1; 4a Sistema verifica se todos os dados foram inseridos corretamente Gerenciar Eventos [Diagrama do caso de uso] Caso de uso: Gerenciar Eventos Pré-requisito: Agenciador cadastrado. página 12 de 20

13 Nome: Requisitos relacionados: primário(s): secundário(s): Pré-condição: Objetivo: Pós-condição: Fluxo Básico: Fluxo Alternativo: Gerenciar Eventos RF05, NF02 Agenciador Banco de Dados Agenciador cadastrado. Agenciador estar identificado e possuir acesso a funcionalidades protegidas do sistema. 1 Agenciador efetua a autenticação no sistema; 2 Sistema verifica os dados de autenticação do usuário; 3 Agenciador busca, cria, edita ou cancela um evento; 4 Sistema salva as alterações efetuas pelo usuário; 2a Sistema verifica se os dados de autenticação são válidos; 2a1 Sistema registra a tentativa de autenticação e permite ou não o acesso ao sistema; 2a2 Tentativa de autenticação negada retorna para o fluxo 1; 3a Sistema verifica se todos os dados foram inseridos corretamente. 3b Ao cancelar o evento deve ser efetuado o reembolso; Gerenciar Espectador [Diagrama do caso de uso] Caso de uso: Gerenciar Espectador. Pré-requisito: Espectador não cadastrado. Nome: Requisitos relacionados: primário(s): secundário(s): Pré-condição: Objetivo: Pós-condição: Fluxo Básico: Gerenciar Espectador. RF04, NF02 Espectador. Banco de Dados Espectador não cadastrado no sistema. Espectador efetuar cadastro para se autenticar e utilizar as funcionalidades do sistema. 1 O espectador acessa o sistema utilizando a internet; 2 O espectador efetua seu cadastro no sistemas; 3 O espectador pode fazer alteração em seus dados, excluir seu cadastro, efetuar compras de ingressos e verificar seu histórico de compras; 4 O sistema salva as alterações feitas pelo espectador. página 13 de 20

14 Fluxo Alternativo: 2a Dados inválidas; 2a1 Sistema solicita o preenchimento correto dos dados; Gerenciar Administrador [Diagrama do caso de uso] Caso de uso: Gerenciar Administrador. Pré-requisito: Administrador não cadastrado. Nome: Requisitos relacionados: primário(s): secundário(s): Pré-condição: Objetivo: Pós-condição: Fluxo Básico: Fluxo Alternativo: Gerenciar Administrador. RF03, NF02 Administrador. Banco de Dados Administrador não cadastrado no sistema. Administrador efetua seu cadastro para e utilizar e gerenciar as atividades relacionadas ao sistema. 1 O administrador acessa o sistema utilizando a internet; 2 O administrador efetua seu cadastro no sistemas; 3 O administrador pode criar, alterar, excluir ou buscar os usuários que precisam de sua aprovação para efetuar o cadastro; 4 O sistema salva as alterações feitas pelo espectador. 2a Dados inválidas; 2a1 Sistema solicita o preenchimento correto dos dados; Abrir Caixa da Bilheteria [Diagrama do caso de uso] Caso de uso: Abrir caixa bilheteria. Pré-requisito: Bilheteria cadastrada. Nome: Requisitos relacionados: primário(s): secundário(s): Pré-condição: Objetivo: Abrir caixa da bilheteria. RF08, NF02 Bilheteria. Banco de Dados Bilheteria cadastrada. Abrir o caixa da bilheteria informar o saldo inicial das vendas. página 14 de 20

15 Pós-condição: Fluxo Básico: Fluxo Alternativo: 1 A bilheteria informa a quantidade de dinheiro inicial em caixa; 2 A bilheteria registra as vendas em caixa; 3 Sistema salva as informação e alterações efetuadas pela bilheteria; Fechar Caixa da Bilheteria [Diagrama do caso de uso] Caso de uso: Fechar caixa bilheteria. Pré-requisito: Bilheteria cadastrada. Nome: Requisitos relacionados: primário(s): secundário(s): Pré-condição: Objetivo: Pós-condição: Fluxo Básico: Fluxo Alternativo: Fechar caixa da bilheteria. RF09, NF02 Bilheteria. Banco de Dados Bilheteria cadastrada. Fechar o caixa da bilheteria informar o saldo final após as vendas. 1 A bilheteria informa a quantidade de dinheiro final em caixa; 2 Sistema salva as informação e alterações efetuadas pela bilheteria; Compra de Ingressos à Vista [Diagrama do caso de uso] Caso de uso: Venda de ingresso à vista. Pré-requisito: Usuário autenticado. Nome: Requisitos relacionados: primário(s): secundário(s): Pré-condição: Venda de ingresso à vista. RF07, RF10, NF02 Bilheteria; Espectador. Banco de Dados Usuário autenticado. página 15 de 20

16 Objetivo: Pós-condição: Fluxo Básico: Fluxo Alternativo: Efetuar compra de ingresso à vista. 1 Usuário seleciona forma de pagamento no cartão de crédito/débito ou dinheiro; 2 Ingresso ou voucher é liberado para o espectador; 1a Forma de pagamento no cartão de credito depende da aprovação da operadora e podem ser efetuadas online ou em uma bilheteria; 1a Pagamento online aprovado o voucher é liberado para a impressão; 1a Pagamento recusado deve retornar ao fluxo 1; 1b Pagamento em dinheiro ou cartão de débito deve ser efetuado somente nas bilheterias; Compra de Ingressos por Boleto [Diagrama do caso de uso] Caso de uso: Venda de ingresso por boleto.. Pré-requisito: Espectador autenticado. Nome: Requisitos relacionados: primário(s): secundário(s): Pré-condição: Objetivo: Pós-condição: Fluxo Básico: Fluxo Alternativo: Venda de ingresso por boleto. RF06, NF02 Espectador. Banco de Dados Espectador autenticado. Efetuar compra de ingresso por boleto 1 Usuário seleciona forma de pagamento no boleto bancário; 2 Sistema reserva o ingresso até o próximo dia útil; 3 Pagamento aprovado o voucher é liberado; 1a Pagamento não efetuado o ingresso sai da reserva e volta a ficar disponível no site para a compra; página 16 de 20

17 4.2 Mapas Conceituais Os mapas conceituais / modelos conceituais ilustram os conceitos mais significativos do sistema, como mostra a Figura 2 abaixo. Figura 2: Mapa conceitual do sistema página 17 de 20

18 4.3 Diagrama de Classes Um diagrama de classe descreve o objeto e informações de estruturas usadas pelo seu aplicativo, internamente e comunicação com seus usuários. Ele descreve as informações sem referência a qualquer implementação específica, como pode ser visto na Figura 3. Figura 3: Diagrama de Classes do Sistema 4.4 Diagramas de Sequência 4.5 Mapeamento Objeto-Relacional página 18 de 20

19 página 19 de 20

20 Apêndice I Propostas Recusadas Anexo I Legislação página 20 de 20