PROJETO DE SISTEMA DE CONTROLE DE VENDA DE INGRESSOS

Prévia do material em texto

CURSO SUPERIOR DE ANÁLISE E DESENVOLVIMENTO DE SISTEMAS
4º Semestre
PROJETO DE SISTEMA DE CONTROLE DE VENDA DE INGRESSOS
Prof. Edeilson Ferreira da Silva
Lu................................................ – RGM 19........
São Paulo - SP Dezembro/2019
Índice
Lista de Figuras	4
Lista de tabelas.	4
Lista de abreviações.	4
Introdução	5
Objetivo	6
Capítulo 1 - Conceitos e definições	7
Capitulo 2 - Requisitos funcionais	7
2.1 - Qualidades dos requisitos funcionais	8
Capitulo 3 - Requisitos Não funcionais	8
3.1 - Classificações dos requisitos não funcionais	9
Capitulo 4 - Regaras de negócios	10
- Importância das regras de negócios	10
- Exemplos de regras de negócios	10
Capitulo 5 - O projeto	11
- Falando do projeto	11
- Elicitação de requisitos	11
- Requisitos funcionais e não funcionais por função	12
- Cadastro de usuários	12
- Login do usuário	12
- Cadastro do funcionário	12
- Login de funcionário	13
- Cadastro dos fornecedores	13
- Cadastro dos produtos	13
- Tela confirmar compra	14
- Tela SCVI	14
- Requisitos não funcionais	15
- Regras de negócios	16
- Requisitos funcionais compilado	16
- Requisitos não funcionais compilado	18
- Regras de negócios compilado	20
- Layout do SCVI	21
- Tela do SCVI	21
- Tela confirmar compra	22
- Tela login usuário	22
- Tela cadastro de usuário	23
- Tela cadastro de funcionário	23
- Tela login de funcionário	23
- Tela cadastro de fornecedor	24
- Tela cadastro de produto	25
Capitulo 6 – Macro Fluxo (BPM) do Sistema	26
Capitulo 7–Conclusão	27
Lista de Figuras
Figura 1 – Esquema Modelo em Espiral	12
Figura 2 – Tela do SCVI	21
Figura 3 – Tela Confirmar Compra	22
Figura 4 – Tela Login Usuário	22
Figura 5 – Tela Cadastro Usuário	23
Figura 6 – Tela Cadastro de Funcionários	23
Figura 7 – Tela Login de Funcionário	24
Figura 8 – Tela Cadastro de Fornecedores	25
Figura 9 – Tela Cadastro de Produtos	25
Lista de Tabelas
Tabela 1 – Requisitos funcionais do projeto SCVI	16
Tabela 2 – Requisitos Não funcionais do projeto SCVI	18
Tabela 3 – Regras de negócios do projeto SCVI	20
Lista de Abreviações
SCVI - Sistema de Controle de Venda de Ingressos	6
Introdução
Com a evolução tecnológica cada vez mais sistemas estão sendo desenvolvidos. E, nesse contexto é muito importante saber o que são requisitos funcionais, requisitos não funcionais e regras de negócio, para que possa ser desenvolvido um sistema com o mínimo ou nenhum erro ou falhas.
Diante disso nesse projeto optou-se por começar, capitulo 1, conceituando o que é levantamento de requisitos. E, nesse ponto também é demonstrado como ocorre processo de elicitação de requisitos de uma forma geral. No capítulo 2, nos aprofundamos um pouco mais no levantamento de requisito sobre a ótica dos requisitos funcionais, que define uma função de um sistema ou seu componente. Abordando também as suas qualidades. No capítulo 3, aborda-se o tema requisitos não funcionais, que se relacionam diretamente com o produto, com suas funções e/ou com o ambiente onde será implantado. Esse requisito é classificado e seus diferentes tipos são esclarecidos através de exemplos, tornando mais fácil o seu entendimento. No capítulo 4, define-se o que são regras de negócios. Mostra-se também a sua importância dentro do desenvolvimento de sistemas e finaliza-se esse tópico com alguns exemplos de uso dessas regras. No capítulo 5 desenvolve-se um sistema de controle de vendas de ingresso - SCVI. Esse capítulo é subdividido em vários tópicos onde será mostrado o desenvolvimento do sistema supracitado, abordando o objetivo do trabalho <tópico 5.1>, o procedimento e modelo adotado para o elicitação dos requisitos <tópico 5.2>, seus requisitos funcionais e não funcionais por função <tópico 5.3>, requisitos não funcionais <tópico 5.4>, regras de negócios <tópico 5.5>, layouts <tópico 5.9> e o Macro Fluxo (BPM) do Sistema
<capitulo 6> colocando em pratica o que foi falado nos capítulos anteriores. E por fim, tem se a conclusão <capitulo 7>, que foi alcançada com o desenvolvimento desse trabalho.
 (
10
)
Objetivo
O propósito desse trabalho é desenvolver um Sistema de Controle de Venda de Ingresso. O sistema desenvolvido terá como premissa a simplicidade e intuitividade no uso do sistema, permitindo que qualquer pessoa, de diferentes faixas etária consiga manuseá-lo sem dificuldades. Dessa forma, será elaborado o SCVI – Sistema de Controle de Vendas de Ingresso, que é um sistema que permite a venda de ingressos via internet e presencialmente. Tendo como objetivo atender a qualquer tipo de evento, seja ele uma peça de teatro ou até mesmo um show de rock em um estádio de futebol.
Ilustrando seu uso, como uma situação hipotética, porém plausível dentro das possibilidades de ocorrer, temos:
“Uma organizadora de evento “A”, que nesse trabalho foi chamada de fornecedor, irá produzir um evento. Então ela contrata uma prestadora de serviço “B”, que é detentora do SIV. A empresa B tem sou local de venda físico e virtual e receberá uma quantidade de ingresso da empresa B, para ser vendido ao público. A empresa B deverá preencher o formulário “cadastro de fornecedor”. A empresa A, preencherá o formulário “cadastro de produtos” e “cadastro de funcionários”. A empresa B só poderá cadastrar os produtos se o fornecedor já estiver cadastrado no sistema. Dessa forma o ingresso estará pronto para ser comercializado. Os clientes que entrarão no sistema, terão todas as informações sobre o produto, porém para que a compra seja executada (finalizada), o usuário precisará fazer o login, e para isso, ele terá que está cadastrado no SVI. O cliente fará esse cadastrado utilizando o formulário de “cadastro de usuário”.
Para alcançar o objetivo supracitado transformando a situação hipotética mencionada acima em um sistema “real”, abordou-se elementos do desenvolvimento de sistema, como por exemplo, levantamentos de requisitos.
Capítulo 1 - Conceitos e definições
A análise de requisitos engloba todas as tarefas que lidam com investigação, definição e escopo de novos sistemas ou alterações. Ela é uma parte importante do processo de desenvolvimento de sistemas, na qual a equipe envolvida identifica as necessidades ou requisitos de um cliente. Uma vez que os requisitos do sistema tenham sido identificados, os projetistas de sistemas estarão preparados para projetar a solução.
A análise de requisitos é uma das primeiras atividades de desenvolvimento de sistemas. O produto do seu trabalho é a especificação de requisitos, que define o escopo do sistema em duas dimensões: Requisito funcional e Requisito não- funcional. É nesta fase que o analista faz as primeiras reuniões com os clientes e/ou usuários do sistema para conhecer as funcionalidades que serão desenvolvidas. É nesta fase também que ocorre a maior parte dos erros, pois a falta de experiência dos clientes ou usuários faz com que eles nem sempre tenham claro em sua mente quais funcionalidades o sistema terá.
As entrevistas estruturadas são um método utilizado para esta fase e que poderão ter um papel importante na ajuda à compreensão de todas as funcionalidades pretendidas pelo cliente.
O processo para levantamento de requisitos pode ser difícil, pois o ambiente é afetado por novos sistemas desenvolvidos e eles afetam também as relações humanas, por isso é importante identificar todos os envolvidos, considerando suas necessidades e garantindo que compreenderam as implicações dos novos sistemas. Nesse processo os analistas podem empregar várias técnicas para elicitar os requisitos, tais como: entrevistas em grupos ou individuais, análise de documentações existentes, análise de sistemas semelhantes já desenvolvidos, entre outras.
Capítulo 2 - Requisitos funcionais
Requisito funcional define uma função de um sistema ou seu componente. Ele representa o que o sistema faz, em termos de tarefas e serviços. Uma função é descrita como um conjunto de entradas, seu comportamento e as saídas. Os requisitos funcionais podem ser cálculos, detalhes técnicos, manipulação de dados e de processamento e outrasfuncionalidades específicas que definem o que um sistema, idealmente, será capaz de realizar. Os requisitos funcionais também são
suportados por requisitos não-funcionais (conhecidos como requisitos de qualidade), que impõem restrições sobre o projeto ou execução (tais como requisitos de desempenho, segurança ou confiabilidade). O plano para a implementação dos requisitos funcionais é detalhado no projeto do sistema. Já o plano para a implementação de requisitos não funcionais é detalhado na arquitetura do sistema.
2.1 - São qualidades dos requisitos funcionais:
Prioridade: é importante saber a prioridade do requisito, devido ela ser usada no plano de iterações. Em cada iteração, os requisitos abertos com maior prioridade são detalhados e desenvolvidos. Nesse sentido, garante-se que o cliente receba o que ele mais precisa em um dado momento.
INVEST: devem ser Independentes, Negociáveis, Valoráveis, Estimáveis, Pequenos e Testáveis.
Compreensibilidade: requisitos devem ser escritos na linguagem do cliente.
Rastreável para frente: Esse requisito garante a rastreabilidade entre código fonte e casos de testes. Assim, se alteramos um caso de teste, saberemos em qual código será refletido - e vice-versa.
Capítulo 3 - Requisitos não funcionais
São os requisitos relacionados ao uso da aplicação em termos de desempenho, usabilidade, confiabilidade, segurança, disponibilidade, manutenção e tecnologias envolvidas. Estes requisitos dizem respeito a como as funcionalidades serão entregues ao usuário do sistema. Eles são tratados geralmente como premissas e restrições técnicas de um projeto e são praticamente todas as necessidades que não podem ser atendidas através de funcionalidades. Esses requisitos impõem limites aos sistemas, por exemplo, método de desenvolvimento, tempo, espaço, sistema operacional
Requisitos Não Funcionais demonstram qualidade acerca dos serviços ou funções disponibilizadas pelo sistema. Ex.: tempo, o processo de desenvolvimento, padrões, etc. Eles surgem conforme a necessidade dos usuários, em razão de orçamento e outros fatores.Podem estar relacionados a tempo de resposta e espaço nas mídias de armazenamento disponíveis. Numa eventual falha do sistema no não atendimento a um requisito não funcional, poderá tornar todo o sistema ineficaz. Ex.: requisito confiabilidade em um sistema de controle de voos.
3.1 - Classificações dos Requisitos Não Funcionais
Requisitos de produtos: Requisitos que especificam o comportamento do produto.Ex. portabilidade; tempo na execução; confiabilidade, mobilidade, etc.
Requisitos de usabilidade: facilidade de uso.Ex.: usuários deverão operar o sistema após um determinado tempo de treinamento.
Requisitos de eficiência. Ex.: o sistema deverá processar “n” requisições por um determinado tempo.
Requisitos de confiabilidade. Ex.: o sistema deverá ter alta disponibilidade (ex: 99% do tempo).
Requisitos de portabilidade. Ex.: o sistema deverá executar em qualquer plataforma.
Requisitos organizacionais: Requisitos decorrentes de políticas e procedimentos corporativos. Ex. padrões, infraestrutura, etc.
Requisitos de entrega. Ex.: um relatório de acompanhamento deverá ser fornecido toda segunda-feira.
Requisitos de implementação. Ex.: o sistema deverá ser desenvolvido na linguagem Java.
Requisitos de padrões. Ex.: uso de programação orientada a objeto sob a plataforma A.
Requisitos externos: Requisitos decorrentes de fatores externos ao sistema e ao processo de desenvolvimento. Ex. requisitos de interoperabilidade, legislação,localização geográfica etc.
Requisitos de interoperabilidade. Ex.: o sistema deverá se comunicar com o banco SQL Server.
Requisitos éticos. Ex.: o sistema não apresentará aos usuários quaisquer dados de cunho privativo.
Requisitos legais. Ex.: o sistema deverá atender às normas legais, tais como padrões, leis, etc.
Capítulo 4 - Regras de negócios
O conceito de “regras de negócio” começou a ser desenvolvido nos anos 1990, com a criação do GUIDE Business Rule Project, que posteriormente evoluiu para a criação do Business Rule Group. Sua declaração de princípios (Manifesto) diz que “regras de negócio definem a estrutura e controlam a operação das empresas”. Representam uma mudança na maneira de descrever uma organização, deixando de lado o foco nos dados que a empresa usa e a organização dos processos que executa, para se concentrar nas restrições sob as quais as empresas operam.Uma regra de negócio é a uma declaração que, explicitamente, define ou restringe um aspecto do funcionamento da empresa.
No processo de desenvolvimento de qualquer sistema, a regra de negócio visa detalhar as funcionalidades particulares do software. Com isso facilita por parte dos programadores o desenvolvimento de métodos de tratamento de exceções, particularidades que o sistema possa executar e o mais importante, limitar ações fora do processo normal de funcionamento de um sistema específico.
4.1 - Importância de identificar Regras de Negócio
Podemos identificar alguns tópicos, nos quais se verificam a importância das regras de negócio.
· As melhores práticas de Engenharia de Software advogam código reusável e modular.
· Separar regras de negócio de projetos específicos é uma forma de adaptar esta regra para a gerência de requisitos.
· A regra de negócio pode ser empregada em vários projetos (Sistemas de gestão empresarial, sistemas de gestão financeira, sistemas de compras on- line), cada sistema com suas particularidades que requerem regras de negócio distintas voltadas para as funcionalidades específicas de sua rotina.
4.2 - Exemplos de Regras de Negócio
As regras de negócios são aplicadas em diferentes contextos, como mostrado nos exemplos abaixo.
· O valor total de um pedido é igual à soma dos totais dos itens do pedido acrescido de 10% de taxa de entrega.
· Um professor só pode lecionar disciplinas para as quais esteja habilitado.
Capítulo 5 - O PROJETO
5.1 - Desenvolvimento de um Sistema de Controle de Vendas de Ingressos.
Nesse projeto foi desenvolvido um sistema de controle de ingresso, que atenderá diferentes eventos, tais como: shows em lugares abertos, shows em lugares fechados, cinema, jogos entre outros.
No desenvolvimento do Layout foi usado o Microsoft Visual Studio que é um ambiente de desenvolvimento integrado (IDE) da Microsoft para desenvolvimento de software especialmente dedicado ao .NET Framework e às linguagens Visual Basic (VB), C, C++, C# (C Sharp) e F# (F Sharp). Também é um produto de desenvolvimento na área web, usando a plataforma do ASP.NET, como websites, aplicativos web, serviços web e aplicativos móveis.
5.2 - Para a elicitação de requisitos
O processo de reunião de informação para os requisitos foi baseado em: reuniões com os clientes, reuniões com os usuários, entrevistas e análise de sistemas já existentes. Para isso foi usado o modelo em espiral, que usa uma abordagem ”evolucionária” no desenvolvimento de sistemas, capacitando o desenvolvedor e o cliente a entender e reagir aos riscos em cada fase evolutiva. Esse modelo usa a prototipação como um mecanismo de redução de riscos, mas, o que é mais importante, possibilita que o desenvolvedor aplique a prototipação em qualquer etapa da evolução do produto. Ele mantém a abordagem de passos sistemáticos sugerida pelo ciclo de vida clássico, mas incorpora-a numa estrutura iterativa que reflete mais realisticamente o mundo real.
Nesse projeto foram adotadas três regiões em nossa espiral: elicitação de requisitos, especificação de requisito e validação de requisito. Objetivando dentro de cada giro da espiral levantar, especificar e validar os requisitos. A cada giro era feito o levantamento dos requisitos através de reuniões, entrevistas pesquisa de campo. Gerando um documento especificando esses requisitos, que depois eram validados junto ao cliente. E no final do processo gerou-se um documento determinando os requisitos funcionais e não funcionais do sistema assim como a regra de negócio, listados nos tópicos seguintes.
Fig1 – modelo em espiral
5.3 - Requisitos funcionaise Não funcionais por Função
5.3.1 – Cadastro do Usuário
[RF01]–O sistema solicitará os seguintes dados para cadastrar usuário: nome completo, CPF, e-mail, senha, país, estado e cidade;
[RNF01]– O sistema considerará o cadastro de imagem/foto como opcional para o usuário.
5.3.2 - Login do usuário
[RNF02]–O sistema solicitará CPF e a senha do usuário, para poder fazer login. [RF02]– O sistema cadastrará somente senhas de 6 caracteres.
5.3.3 – Cadastro de funcionário
[RF03] –O sistema solicitará os seguintes dados para cadastrar funcionário: nome completo, CPF, identidade, foto, e-mail, senha, setor de trabalho e a data que foi admitida na empresa.
[RF04]- O sistema gerará um código_funcionário automaticamente e enviará para o e-mail cadastrado.
[RF05] - O código_funcionário é composto de 8 dígitos.
[RNF03] - Os quatros primeiros dígitos do código_funcionário corresponderão ao Mês e Ano (_ _ / _ _) de admissão do funcionário na empresa.
[RNF04]- O cadastro da foto/imagem é obrigatório para completar o cadastro.
5.3.4 - Login do Funcionário
[RF06]–O sistema solicitará o código_funcionário e a senha para o funcionário efetuar o login.
[RNF05]- A senha cadastrada pelo funcionário deverá conter 8 caracteres.
5.3.5 – Cadastro dos Fornecedores
[RF07]–O sistema solicitará o preenchimento dos seguintes campos para cadastrar os fornecedores de ingressos: data que foi realizado o cadastro, nome do fornecedor, código do fornecedor, descrição resumida sobre fornecedor, número do contrato assinado e o responsável pelo SVI – SISTEMA DE VENDAS DE INGRESSOS, código do produto, CNPJ, logomarca da empresa.
[RF08] - O sistema gerará um código_fornecedor automaticamente e mostrará no respectivo campo, quando for preenchido todos os campos do cadastro e clicar em REGISTRAR.
[RF09] - O código_fornecedor é composto de 8 dígitos.
[RNF06] - Os quatros primeiros dígitos do código_forncedor corresponderão ao Mês e Ano (_ _ / _ _) de cadastro do fornecedor na empresa.
[RNF07]- O cadastro da logomarca é opcional para o fornecedor.
5.3.6 – Cadastro dos Produtos
[RF10] –O sistema solicitará os seguintes dados para a cadastrar produtos: data do cadastro do produto, data em que o sistema deixará de vender o ingresso, código do produto, descrição do produto de forma resumida, tipo de evento, acomodação do público, o tipo de público, cadastrar imgem/foto do produto, código_fornecedor, a quantidade de ingressos disponibilizados para o SVI, o valor de um ingresso, o valor total no caso de todos os ingressos serem vendidos.
[RNF08] - O sistema gerará um código_produto automaticamente e mostrará no respectivo campo, quando for preenchido todos os campos do cadastro e clicar em REGISTRAR.
[RF11] - O código_produto é composto de 8 dígitos.
[RNF09] - Os quatros primeiros dígitos do código_forncedor serão iguais aos quatro primeiros dígitos do seu código_forncedor.
[RNF10] - No campo descrição do produto, o título da descrição do produto deverá conter o nome do produto, seguido de uma descrição de no máximo 30 caracteres.
[RNF11] - O cadastro da logomarca é opcional para o fornecedor.
[RF12] - O sistema calculará o valor total, com base no valor unitário do ingresso e a quantidade de ingressos disponibilizados para o SVI, considerando que todos os ingressos serão vendidos.
5.3.7 – Tela Confirmar Compra.
[RF13] - O sistema mostrará os seguintes campos preenchidos, conforme o usuário tenha selecionado na tela SVI antes de fazer o login: imagem do produto, data da compra, encerramento da venda, código_produto, código_fornecedor, tipo de evento, tipo do local do evento, classificação do público do evento e descrição do produto.
[RZ14] - O usuário precisará preencher os campos: quantidade de ingressos desejado,
[RF15] - O sistema preencherá o valor unitário, com base no código_produto.
[RF16] - O sistema calculará e mostrar no respectivo campo, o valor total da compra, com base no valor unitário do ingresso e na quantidade de ingresso informada pelo usuário.
5.3.8 – Sistema de Venda de Ingressos – SVI
[RF17] - O sistema permitirá que o usuário faça buscas por ingressos preenchendo de um a todos os campos em tela. Os campos dessa tela são: dia que começou a ser vendido o ingresso, dia prevista para o término da venda do ingresso, código_produto, tipo de evento, o tipo de local onde o evento ocorrerá, a acomodação do público, tipo de público, nome do fornecedor, valor unitário do ingresso.
[RF18] - A descrição do produto e a imagem, caso seja encontrado algum produto cadastrado, serão preenchidos pelo sistema.
[RF19] - O sistema permitirá que o usuário faça buscas por ingresso filtrando: pelo valor do ingresso, pelo tipo de evento, pela acomodação do público, pela classificação do público, pela data de início de venda de ingresso, pela data de
encerramento das vendas de ingresso, pelo código do produto, pelo nome do fornecedor, pelo nome do evento.
[RNF12] - O usuário terá que está cadastrado para finalizar a comprardo ingresso. [RNF13] - Cada funcionário será identificado pelo seu código de 8 dígitos.
[RNF14] - Quando um usuário confirmar uma compra, ele terá a possibilidade de gera um relatório de consulta de ingresso comprado. Esse relatório será composto pelos seguintes campos: tipo de evento / nome do evento / valor do ingresso / quantidade de ingressos comprados / quando executou a compra / onde foi efetuada a compra.
5.4 - Requisitos Não funcionais
[RNF15] –O layout do site será desenvolvido com o framework Bootstrap4. [RNF16] - Será utilizado o MySQL 7 para gerenciamento de banco de dados [RNF17] – O layout do site será desenvolvido com o HTML5.
[RNF18] – O layout do site será desenvolvido com o CSS3 na configuração da aparência do site.
[RNF19] - No layout será usado o usado o JavaScript criar eventos na página.
[RNF20] - Será usada a linguagem PHP juntamente com o HTML para poder ter acesso ao Banco de Dados.
[RNF21] - A senha do usuárioe do funcionário deverá ser gravada/trafegada utilizando-se o algoritmo SHA-3 para criptografia.
[RNF22] - O sistema fará backup a cada hora cheia
[RNF23] - O sistema gera relatório de vendas as 20 horas do último dia do mês vigente. Esse relatório será composto pelas seguintes colunas: tipo de evento / nome do evento / valor unitário do ingresso / quantidades de ingressos vendidos / Valor total gerado para cada evento / valor total do mês
5.5 - Regra de Negocio
[RN01] - Nos ingressos que custarem mais de R$100 reais, ser á dado desconto de 5% no valor total na compra de 3 ingressos.
[RN02] - Usuários possuidores de carteira de estudantes pagaram a metade do valor de qualquer ingresso.
[RN03] - Usuários possuidores de carteira de estudantes só poderão comprar um ingresso com desconto. Na compra de mais de um ingresso os demais ficarão sujeitos ao preço total vigente para o evento
[RN04] - Pessoas com mais de 60 anos pagará 30 por cento de qualquer ingresso.
[RN05] - Pessoas com mais de 60 só poderão comprar um ingresso com desconto. Compras de mais de um ingresso os demais ficarão sujeito ao preço total vigente para o evento.
[RN06] - Os produtos cujo valor fique abaixo de R$100,só poderão ser vendidos à vista.
[RN07] - As compras que ficarem acima de R$300 reais poderão ser parceladas em duas vezes
[RN08] - Na compra de pacote fechados com 5 ingressos será dado 30% de desconto no valor total.
[RN09] - A venda de ingresso será interrompida, quando o local do evento estiver com a capacidade máxima. Nesse caso, se o evento for em lugares que seja disponível assentos (cinema, teatro), será quando todos os lugares estiverem ocupados. Nos outros casos o sistema permitirá a venda até esgotar o número de ingresso informado pela organizadora do evento.
5.6 – Requisito Funcional – Compilado
	Requito Funcional
	[RF01]– O sistema solicitará os seguintes dados para cadastrar usuário: nome completo, CPF, e-mail, senha, país, estado e cidade;
	
[RF02]– O sistema cadastrará somente senhas de 6 caracteres.
	[RF03] – O sistema solicitará os seguintes dados para cadastrar funcionário: nome completo,CPF, identidade, foto, e-mail, senha, setor de trabalho e a data que foi admitida na empresa.
	[RF04]- O sistema gerará um código_funcionário automaticamente e enviará para o e- mail cadastrado.
	
[RF05] - O código_funcionário é composto de 8 dígitos.
	[RF06]– O sistema solicitará o código_funcionário e a senha para o funcionário efetuar o login.
	[RF07]– O sistema solicitará o preenchimento dos seguintes campos para cadastrar os fornecedores de ingressos: data que foi realizado o cadastro, nome do fornecedor, código do fornecedor, descrição resumida sobre fornecedor, número do contrato assinado e o responsável pelo SVI – SISTEMA DE VENDAS DE INGRESSOS, código do produto, CNPJ, logomarca da empresa.
	[RF08] - O sistema gerará um código_fornecedor automaticamente e mostrará no respectivo campo, quando for preenchido todos os campos do cadastro e clicar em REGISTRAR.
	
[RF09] - O código_fornecedor é composto de 8 dígitos.
	[RF10] – O sistema solicitará os seguintes dados para a cadastrar produtos: data do cadastro do produto, data em que o sistema deixará de vender o ingresso, código do produto, descrição do produto de forma resumida, tipo de evento, acomodação do público, o tipo de público, cadastrar imgem/foto do produto, código_fornecedor, a quantidade de ingressos disponibilizados para o SVI, o valor de um ingresso, o valor total no caso de todos os ingressos serem vendidos.
	
[RF11] - O código_produto é composto de 8 dígitos.
	[RF12] - O sistema calculará o valor total, com base no valor unitário do ingresso e a quantidade de ingressos disponibilizados para o SVI, considerando que todos os ingressos serão vendidos.
	[RF13] - O sistema mostrará os seguintes campos preenchidos, conforme o usuário tenha selecionado na tela SVI antes de fazer o login: imagem do produto, data da compra, encerramento da venda, código_produto, código_fornecedor, tipo de evento, tipo do local do evento, classificação do público do evento e descrição do produto.
	
[RF14] - O usuário precisará preencher os campos: quantidade de ingressos desejado.
	
[RF15] - O sistema preencherá o valor unitário, com base no código_produto.
	[RF16] - O sistema calculará e mostrar no respectivo campo, o valor total da compra, com base no valor unitário do ingresso e na quantidade de ingresso informada pelo usuário.
	[RF17] - O sistema permitirá que o usuário faça buscas por ingressos preenchendo de um a todos os campos em tela. Os campos dessa tela são: dia que começou a ser vendido o ingresso, dia prevista para o término da venda do ingresso, código_produto, tipo de evento, o tipo de local onde o evento ocorrerá, a acomodação do público, tipo de público, nome do fornecedor, valor unitário do ingresso.
	[RF18] - A descrição do produto e a imagem, caso seja encontrado algum produto cadastrado, serão preenchidos pelo sistema.
	[RF19] - O sistema permitirá que o usuário faça buscas por ingresso filtrando: pelo valor do ingresso, pelo tipo de evento, pela acomodação do público, pela classificação do público, pela data de início de venda de ingresso, pela data de encerramento das vendas de ingresso, pelo código do produto, pelo nome do fornecedor, pelo nome do evento.
	[RF20] - O sistema preenchera automaticamente o código do produto, no formulário do fornecedor. Sempre que o fornecedor disponibilizar um novo produto, será acrescentado um novo código nesse campo, gerando uma lista de código, dos produtos daquele
fornecedor.
Tabela 1– requisitos funcionais do projeto SCVI
5.7 – Requisito Não Funcional - Compilado
	Requisito Não funcional
	[RNF01]– O sistema considerará o cadastro de imagem/foto como opcional para o usuário.
	
[RNF02]– O sistema solicitará CPF e a senha do usuário, para poder fazer login.
	[RNF03] - Os quatros primeiros dígitos do código_funcionário corresponderão ao Mês e Ano (_ _ / _ _) de admissão do funcionário na empresa.
	
[RNF04]- O cadastro da foto/imagem é obrigatório para completar o cadastro.
	
[RNF05]- A senha cadastrada pelo funcionário deverá conter 8 caracteres.
	[RNF06] - Os quatros primeiros dígitos do código_forncedor corresponderão ao Mês e Ano (_ _ / _ _) de cadastro do fornecedor na empresa.
	
[RNF07]- O cadastro da logomarca é opcional para o fornecedor.
	[RNF08] - O sistema gerará um código_produto automaticamente e mostrará no
respectivo campo, quando for preenchido todos os campos do cadastro e clicar em REGISTRAR.
	[RNF09] - Os quatros primeiros dígitos do código_forncedor serão iguais aos quatro primeiros dígitos do seu código_forncedor.
	[RNF10] - No campo descrição do produto, o título da descrição do produto deverá conter o nome do produto, seguido de uma descrição de no máximo 30 caracteres.
	
[RNF11] - O cadastro da logomarca é opcional para o fornecedor.
	
[RNF12] - O usuário terá que está cadastrado para finalizar a comprar do ingresso.
	
[RNF13] - Cada funcionário será identificado pelo seu código de 8 dígitos.
	[RNF14] - Quando um usuário confirmar uma compra, ele terá a possibilidade de gera um relatório de consulta de ingresso comprado. Esse relatório será composto pelos seguintes campos: tipo de evento / nome do evento / valor do ingresso / quantidade de ingressos comprados / quando executou a compra / onde foi efetuada a compra.
	
[RNF15] – O layout do site será desenvolvido com o framework Bootstrap4.
	
[RNF16] - Será utilizado o MySQL 7 para gerenciamento de banco de dados
	
[RNF17] – O layout do site será desenvolvido com o HTML5.
	[RNF18] – O layout do site será desenvolvido com o CSS3 na configuração da aparência do site.
	
[RNF19] - No layout será usado o usado o JavaScript criar eventos na página.
	[RNF20] - Será usada a linguagem PHP juntamente com o HTML para poder ter acesso ao Banco de Dados.
	[RNF21] - A senha do usuário e do funcionário deverá ser gravada/trafegada utilizando- se o algoritmo SHA-3 para criptografia.
	
[RNF22] - O sistema fará backup a cada hora cheia
	[RNF23] - O sistema gera relatório de vendas as 20 horas do último dia do mês vigente. Esse relatório será composto pelas seguintes colunas: tipo de evento / nome do evento
/ valor unitário do ingresso / quantidades de ingressos vendidos / Valor total gerado para cada evento / valor total do mês
	[RNF24] -Somente funcionários cadastrados como setor de trabalho “Administração”, poderão cadastrar fornecedores e produtos
	[RNF25] -Somente funcionários cadastrados como setor de trabalho “Administração”, poderão acrescentar, deletar ou alterar cadastros de produtos
	[RNF26] -Somente funcionários cadastrados como setor de trabalho “Administração”, poderão acrescentar, deletar ou alterar cadastros de fornecedores
	[RNF24] -Um produto só poderá ser cadastrado no sistema, se o seu respectivo fornecedor já tiver cadastrado.
Tabela 2 – Requisitos Não funcionais do projeto SCVI
5.8 – Regras de Negócios - Compilado
	Regra de Negócios
	[RN01] - Nos ingressos que custarem mais de R$100 reais, ser á dado desconto de 5% no valor total na compra de 3 ingressos.
	[RN02] - Usuários possuidores de carteira de estudantes pagaram a metade do valor de qualquer ingresso.
	[RN03] - Usuários possuidores de carteira de estudantes só poderão comprar um ingresso com desconto. Na compra de mais de um ingresso os demais ficarão sujeitos ao preço total vigente para o evento
	
[RN04] - Pessoas com mais de 60 anos pagará 30 por cento de qualquer ingresso.
	[RN05] - Pessoas com mais de 60 só poderão comprar um ingresso com desconto.Na
compra de mais de um ingresso os demais ficarão sujeito ao preço total vigente para o evento.
	
[RN06] - Os produtos cujo valor fique abaixo de R$100, só poderão ser vendidos à vista.
	[RN07] - As compras que ficarem acima de R$300 reais poderão ser parceladas em duas vezes
	[RN08] - Na compra de pacote fechados com 5 ingressos será dado 30% de desconto no valor total.
	[RN09] - A venda de ingresso será interrompida, quando o local do evento estiver com a capacidade máxima. Nesse caso, se o evento for em lugares que seja disponível assentos(cinema, teatro), será quando todos os lugares estiverem ocupados. Nos outros casos o sistema permitirá a venda até esgotar o número de ingresso informado pela organizadora do evento.
Tabela 3 – Regras de negócios do projeto SCVI
5.9 – Layout do Sistema de Controle de Vendas de Ingressos
5.9.1- Tela - Sistema de Vendas de Ingresso
Essa é a tela que o usuário terá acesso para fazer buscar por ingressos. Será permitido ao usuário selecionar vários critérios de busca simultaneamente.Quanto mais campos for selecionado ou preenchido, mas refinado será a buscar, tendo resultados mais específicos.
Fig2 – Tela do Sistema de Controle de Venda de Ingressos
O campoonde será mostrado a imagem do produto e o campo descrição do produto serão preenchidos automaticamente pelo sistema quando o campo código do produto for preenchido pelo usuário. E, linkado ao campo produto está o campo descrição do produto, local no qual apresentará um pequeno texto, que possuirá como título o nome do produto e no corpo, uma breve descrição do produto.
Nessa tela o usuário somente poderá selecionar o ingresso desejado, para executar a compra ele terá que está registrado no sistema. Quando ele clicar no botão registrar será chamada a tela de cadastro de usuário, caso o usuário ainda não seja cadastrado no sistema. E, clicando no botão entrar, chamará a tela de login de usuário, no caso de ele já ser cadastrado.
5.9.2 – Tela – Confirmar Compra
Essa tela apresentará ao usuário vários campos já preenchidos automaticamente pelo sistema. São informações vindas da tela SCVI. Aqui o único campo que usuário precisará preencher é quantidade de ingressos, que ele deseja comprar.
Fig3 – Tela Confirmar Compra
E, pelo código do produto, o sistema saberá qual o valor unitário desse ingresso e informará o valor total da compra ao cliente.
5.9.3 – Tela – Login de Usuário
Fig4 – Tela Login Usuário
Essa tela será chamada quando o usuário já for cadastrado no sistema e desejar executar uma compra, clicando no botão ”entrar” na tela do SVI – Sistema de Controle de Vendas de Ingressos. Para ele entrar no sistema, será necessário digitar o CPF e a senha cadastrados na tela de cadastro de usuário.
5.9.4 – Tela – Cadastro de Usuário
Essa tela será onde o usuário realizará o seu cadastro no sistema. O CPF e a senha cadastradas aqui serão necessários para realizar o login.
Fig5 – Tela Cadastro Usuário
5.9.5 – Tela – Cadastro de Funcionário
Nessa tela será realizado o cadastro dos funcionários. Somente funcionários, que preencham o campo “setor de trabalho” como “administração” poderá manipular os cadastros de fornecedores, produtos e usuários.Da informação colocada no campo “data de admissão na empresa” será montado o código de identificação do funcionário.
Fig6 – Tela Cadastro de Funcionários
O sistema pegará o ano de admissão informado e através de programa gerador de números aleatórios montará o código de 8 dígitos, sendo os quatro primeiros, o ano
de admissão na empresa. O código será enviado para o e-mail cadastrado pelo funcionário.
5.9.6 – Tela – Login de Funcionário
Essa é tela é solicitado o código de identificação do funcionário, que foi enviado para o e-mail dele no ato do cadastro. Através desse código o sistema identificará, a qual setor de trabalho o usuário pertence e, assim liberará ou restringirá acessos.
Fig7 – Tela Login de Funcionário
5.9.7 – Tela – Cadastro de Fornecedores
O funcionário autorizado usará essa tela para realizar o cadastro do fornecedor.
A logomarca do fornecedor, quando cadastrada, será mostrada após o reflash da página. No campo “código do produto” será mostrado o(s) código do produto cadastrado para esse fornecedor. Quando o fornecedor tiver mais de um produto cadastrado e esse campo for clicado, abrirá a lista com os códigos de produtos relacionados a esse fornecedor.O sistema gerará um código_fornecedor automaticamente e mostrará no respectivo campo, quando for preenchido todos os campos do cadastro e clicar em REGISTRAR.
Fig8 – Tela Cadastro de Fornecedores
5.9.8 – Tela – Cadastro de Produto
Fig9 – Tela Cadastro de Produtos
O funcionário autorizado usará essa tela para realizar o cadastro do produto, que será disponibilizado pelo Sistema de Controle de Venda de Ingressos. O código do produto gerado nessa tela será linkado ao seu respectivo fornecedor. O sistema gerará automaticamente um código de 8 dígitos, após ser preenchido todos os campos e clicar no botão registrar.
Capitulo 6 – Macro Fluxo (BPM) do Processo.
Capitulo 7 - Conclusão
Com o desenvolvimento desse projeto mostramos como é possível criar um sistema de controle de vendas de ingresso visando atender a diferentes tipos de eventos e públicos. Nesse processo foi possível perceber como os requisitos funcionais descrevem explicitamente as funcionalidades de um sistema. Enquanto que, requisito não funcionais se relacionam diretamente com o produto, com suas funções e/ou com o ambiente onde será implantado, desempenhando um papel critico durante o desenvolvimento de sistemas, pois erros devido a não elicitação ou a elicitação incorreta estão entre os mais caros e difíceis de corrigir, uma vez que um sistema tenha sido implementado. No decorrer desse percurso foi possível perceber a grande importância que é a identificação dos requisitos funcionais e não funcionais para o desenvolvimento de sistemas, pois a análise incorreta pode gerar muitos retrabalhos e também gerar implementações com erros e falhas, como por exemplo de segurança, deixando o sistema vulnerável para ações maliciosas, que poderão gerar transtornos para os usuários. Dessa forma, ficou claro o quão importante é tentar enquadrar os requisitos dentro das suas propriedades, por exemplo: A coesão, que diz que os requisitos devem apoiar o seu propósito e escopo geral. A Consistência em que os requisitos individuais não conflitem entre si e a Correção que deve descrever corretamente a funcionalidade. Pois, defeitos nos requisitos levam a defeitos na solução, na implementação.