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.3 / 10 de agosto 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 página 2 de 9

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 Funcionários RF01 Gerenciar Funcionário Requisitos Funcionais Gerais RF02 Gerenciar Peça RF03 Relatório Mensal 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 ESPECIFICAÇÃO Casos de Uso Autenticar Usuário Mapas Conceituais Diagrama de Classes Diagramas de Sequência Mapeamento Objeto-Relacional...8 APÊNDICE I PROPOSTAS RECUSADAS...9 ANEXO I LEGISLAÇÃO...9 página 3 de 9

4 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 clientes e analista / desenvolvedor de sistemas. 1.2 Escopo do Produto Uma empresa deseja entrar no mercado de vendas online de ingressos para eventos. Os eventos são artísticos, esportivos ou culturais e ocorrem em uma data, local e horário prédefinidos pelo responsável por agenciar o evento. Mesmo que o espetáculo seja recorrente, cada exibição possui seu próprio registro e identificação, não sendo utilizado o conceito de sessões que se repetem. O sistema deve, porém, permitir copiar todos os dados de uma apresentação para facilitar o cadastro de uma nova apresentação em um outro dia/horário/local. O espectador deve poder comprar seu ingresso online após cadastro e a venda é efetivada quando o pagamento via cartão ou boleto é confirmada. A proposta de compra do espectador mantém a reserva do ingresso por um dia, que é o próximo dia útil em caso de pagamento via boleto, desde que não ocorra na véspera do evento pois não é feita a venda por boleto em vésperas. O sistema deve permitir a venda de ingressos para os eventos com locais numerados. 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. A reserva imediata de um ingresso ocorre por vinte minutos ou até que o comprador expressamente desista do ingresso, o compre via cartão ou emita o boleto, quando a reserva passa a ser de um dia. Existe a figura da bilheteria: clientes que vendem em locais físicos, para compra de ingressos em dinheiro ou cartão. 1.3 Materiais de Referência 1.4 Definições e Siglas GB RAM Gigabyte Memória de acesso rápido (Random Access Memory) 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 cliente 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. página 4 de 9

5 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$ 15,00/mês Total: R$ 7.015,00 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 Cliente; Gerenciar Eventos; Efetuar Compra; 2 - Requisitos Funcionais Os requisitos funcionais estabelecerão como o sistema vai agir, e o que deve fazer, com as funcionalidades e serviços. página 5 de 9

6 2.1 Requisitos Funcionais de Funcionários Esta seção traz os requisitos relacionados a funcionários. Estes requisitos RF01 Gerenciar Funcionário O funcionário... desejável importante X essencial 2.2 Requisitos Funcionais Gerais RF02 Gerenciar Peça As peças são administradas... desejável X importante essencial RF03 Relatório Mensal O Relatório mensal compreende a relação dos... X desejável importante essencial 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 São considerados Requisitos Não Funcionais de Operação todos requisitos identificados que NF01 Usabilidade Cada tela de entrada de dados do sistema deve prover meios de... X desejável importante essencial 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. Situações extremas são toleradas uma vez em cada mil para... página 6 de 9

7 3.2 Requisitos Não Funcionais de Segurança Compreende-se como Requisito Não Funcional de Segurança todo requisito que envolva NF03 Autenticação desejável importante X essencial É exigida a identificação do usuário através de um processo de autenticação para Especificação Este capítulo fornece as especificações que descrevem tecnicamente os requisitos 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... Figura 1: Diagrama de Caso de Uso do Sistema Autenticar Usuário [Diagrama do caso de uso] Caso de uso: Pré-requisito: não estar cadast Nome: Requisitos relacionados: Ator(es) primário(s): Ator(es) Autenticar Usuário RF01, RNF03. Usuário Banco de Dados página 7 de 9

8 secundário(s): Pré-condição: Objetivo: Pós-condição: Fluxo Básico: Fluxo Alternativo: Usuário não estar autenticado no sistema. Usuário estar identificado e possuir acesso a funcionalidades protegidas do sistema. Não há. 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; 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 4.5 Mapeamento Objeto-Relacional página 8 de 9

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