PIMVI - ANÁLISE E DESENVOLVIMENTO DE SISTEMAS (NOTA 9.0) 2021

Prévia do material em texto

6
UNIVERSIDADE PAULISTA
ANÁLISE E DESENVOLVIMENTO DE SISTEMA
JEFFERSON DOS SANTOS VEIGA
PROJETO INTEGRADO MULTIDISCIPLINAR VI
Projeto de levantamento e a análise de requisitos 
SÃO PAULO – SP
2021
UNIVERSIDADE PAULISTA
ANÁLISE E DESENVOLVIMENTO DE SISTEMA
PROJETO INTEGRADO MULTIDISCIPLINAR VI
Projeto de levantamento e a análise de requisitos 
Nome: JEFFERSON DOS SANTOS VEIGA
RA: 2018813
Curso: Análise e Desenvolvimento de Sistema
Semestre: 03/2021
SÃO PAULO – SP
2021
RESUMO
O presente Projeto Integrado Multidisciplinar, proposto pela universidade UNIP Interativa, visa aplicar o conhecimento adquirido no bimestre pelas aulas de Análise de Sistemas Orientada a Objetos, Banco de Dados, Gestão Estratégica de RH. Este trabalho propõe a realizar o levantamento e a análise de requisitos do sistema proposto para a empresa destinada à venda de jogos eletrônicos, acessórios e produtos geek. Para este projeto estaremos identificando os requisitos envolvidos e descrevendo os comportamentos pertinentes a eles atrelados. Informar os relacionamentos para a construção do banco de dados e o ambiente pertinente a ele com a construção do modelo de dados, identificação das chaves das entidades e descrevendo a cardinalidade de itens que relacionam nas entidades. Identificação, elaboração e especificação do modelo de casos de uso e elaboração do diagrama de classes.
Palavras-chave: Casos de uso, Requisitos, Modelo de dados.
ABSTRACT
The present Integrated Multidisciplinary Project, proposed by the UNIP Interactive university, aims to apply the knowledge acquired in the two months by the classes of Object-Oriented Systems Analysis, Database, Strategic HR Management. This work proposes to carry out the survey and analysis of requirements of the proposed system for the company destined to the sale of electronic games, accessories and geek products. For this project, we will be identifying the requirements involved and describing the relevant behaviors linked to them. Inform the relationships for the construction of the database and the environment relevant to it with the construction of the data model, identification of the keys of the entities and describing the cardinality of items that relate in the entities. Identification and elaboration and specification of the use-case model, elaboration of the class diagram.
Key words: Use case, Requirements, Data model.
LISTA DE ILUSTRAÇÕES
Figura 1 - Diagrama de Casos de Uso	11
Figura 2 - Menu Estoquista	12
Figura 3 - Menu Atendente	13
Figura 4 - Menu Supervisor	14
Figura 5 - Tela Login	15
Figura 6 - Cadastrar Produto	17
Figura 7 - Alterar Produto	19
Figura 8 - Excluir Produto	21
Figura 9 - Consultar Produto	23
Figura 10 - Cadastrar Cliente	25
Figura 11 - Realizar Venda	27
Figura 12 - Diagrama de Classes	30
Figura 13 - Diagrama Entidade-Relacionamento (DER)	32
Figura 14 - Diagrama Entidade-Relacionamento (MER)	33
LISTA DE TABELAS
Tabela 1 - Fazer Login	15
Tabela 2 - Cadastrar Produto	17
Tabela 3 - Alterar Produto	19
Tabela 4 - Excluir Produto	21
Tabela 5 - Consultar Produto	23
Tabela 6 - Cadastrar Cliente	25
Tabela 7 - Realizar Venda	27
Sumário
1.	INTRODUÇÃO	6
2.	LEVANTAMENTO DE ANÁLISE DE REQUISITOS	7
3.	REGRAS DE NEGÓCIO	8
3.1.	Especificação das Regras de Negócio	8
4.	IDENTIFICAÇÃO DE CASOS DE USO	9
5.	DIAGRAMA DE CASOS DE USO	10
5.1.	Especificação de Casos de Uso	11
5.1.1.	Protótipo de Tela – Menu	12
5.1.2.	Caso de Uso – Fazer Login	14
5.1.3.	Caso de Uso – Cadastrar Produto	16
5.1.4.	Caso de Uso – Alterar Produto	18
5.1.5.	Caso de Uso – Excluir Produto	20
5.1.6.	Caso de Uso – Consultar Produto	22
5.1.7.	Caso de Uso – Cadastrar Cliente	24
5.1.8.	Caso de Uso – Realizar Venda	26
6.	DIAGRAMA DE CLASSES	29
7.	MODELO ENTIDADE-RELACIONAMENTO	30
7.1.	Diagrama Entidade-Relacionamento (DER)	31
7.2.	Modelo Entidade-Relacionamento (MER)	32
8.	CONCLUSÃO	34
9.	REFERÊNCIAS	35
INTRODUÇÃO
O projeto tem como objetivo a criação da documentação de um programa para uma empresa de venda de jogos eletrônicos, acessórios e produtos geek, para efetuar o controle de estoque e de vendas realizadas o sistema será utilizado pelos funcionários da empresa. Para dar seguimento no projeto estaremos efetuando o levantamento e análise dos requisitos utilizando as ferramentas que aprendemos na disciplina Análise de Sistemas Orientada a Objetos, sendo identificado os casos de uso e realizando a modelagem, identificando relacionamento de include, extend e generalização.
Usando a descrição de caso de uso, verificaremos o procedimento e comportamento do fluxo principal, fluxos alternativos e de exceções, descrevendo um dos requisitos não funcionais de usabilidade do projeto, descrevendo a regra de negócio pertinente ao sistema, elaborando o Diagrama de Classes.
Com as técnicas da disciplina Banco de Dados, estará sendo construído o modelo de dados: MER (Modelo Entidade Relacionamento), que estaremos definindo os conjuntos de objetos básicos e sua relação entre si, identificando as chaves da entidade referida e seus atributos. 
O cenário proposto do projeto, resumidamente é que o funcionário entrará com login e senha o atendente fará a passagem dos produtos bem como a consulta e exclusão dos produtos, estoquista estará fazendo o cadastro do produto e também consulta, alteração e exclusão no sistema a supervisão estará concluindo por meio de login e senha a permissão para cancelamento de produtos dentro de uma venda e cancelamento da venda caso o cliente desistir da compra ou de um determinado produto dentro de uma venda.
LEVANTAMENTO DE ANÁLISE DE REQUISITOS
Para termos uma entrega de um projeto com excelência, faremos uso do levantamento de requisitos, que por definição são solicitações, desejos e necessidades que o cliente precisa. Um requisito é uma propriedade que o software exibe para assim solucionar problemas reais. Um dos principais objetivos responsáveis pelo sucesso dos softwares, os requisitos, são a base para projeto, modelagem, estimativas, testes, execução e até para manutenção dos mesmos. Assim, os requisitos estão presentes ao longo do ciclo de vida de um software. Ao começo de um projeto, os requisitos já devem ser levantados, entendidos e documentados. Visando o futuro de um software e a evolução propriamente dita do mesmo, gerenciar a evolução dos requisitos é importante, pelo projeto está sendo em uma loja de vendas, fazendo uma pequena pesquisa de mercado sempre vemos que estão em constantes mudanças e a loja que fica estacionada no tempo, cai o rendimento. Estando ciente da dinâmica em meio aos negócios não garantem estabilidade e podem vir a sofrer alterações, por este motivo é necessário manter a rastreabilidade entre os requisitos e as outras peças do projeto. 
De maneira geral, os requisitos são necessários para cumprir os objetivos, portanto, um requisito é um aspecto que o sistema proposto deve fazer ou uma restrição no desenvolvimento do mesmo. Em modo geral os requisitos podem ser divididos em duas categorias: 
•	Os requisitos funcionais definem o que o sistema fará, descrevem o comportamento do sistema, seus requisitos para o funcionamento de cada item, descrevem o trabalho que o sistema deverá realizar.
•	Os requisitos não funcionais definem como o sistema fará, não estão relacionados diretamente com a funcionalidades de um sistema. São praticamente todas as necessidades que não podem ser atendidas através de funcionalidades. 
Neste projeto daremos ênfase em um dos requisitos não funcionais, sendo ele usabilidade do sistema proposto, mostrar um desenvolvimento para todos os tipos de funcionários e ter a facilidade de uso simples aos mesmos e objetivo, propondo um treinamento e criação do manual. Desenvolvendo para ter facilidade na conclusão das tarefas dentro do sistema e mostrar uma interface atrativa ao operador do sistema.
REGRAS DE NEGÓCIO
No processo de desenvolvimento de qualquer determinado sistema, a regra de negócio tem como objetivo detalhar as funcionalidadesparticulares daquele sistema. Através disso facilita por partes dos programadores o desenvolvimento de métodos de tratamentos de exceções, aquelas particularidades que o sistema possa executar e o mais importante, a limitação de ações fora do processo normal e funcionamento de um sistema específico.
De forma geral regras de negócio são descritivos sobre a forma da empresa fazer negócio. São refletidas nas políticas do negócio. As organizações com isso possuem políticas para satisfazer os objetivos daquele determinado negócio, satisfazer clientes, determinar um bom uso de recursos, obedecendo às leis ou convenções gerais do negócio. A seção 3.1 fornece as informações das regras de negócio do projeto proposto, nomeando e especificando as mesmas.
Especificação das Regras de Negócio
Para descrever as regras do projeto de venda proposto estaremos usando as siglas “[RNXX]”, assim nomeando e definindo individualmente a proposta de cada regra de negócio, abaixo veremos cada uma delas: 
[RN01] – Autenticação do usuário: O usuário deverá digitar o seu nome de usuário usando somente letras e uma senha válida de no mínimo 8 dígitos incluindo número e letras.
[RN02] – Cadastro do produto: O estoquista deverá efetuar o cadastro do produto preenchendo todos os campos necessários do sistema, sendo: categoria, código de barras, nome do produto, fabricante, quantidade, valor do produto. Para os jogos e acessórios deverá ser informado em qual plataforma serão utilizados e qual o prazo de garantia do produto.
[RN03] – Permissão do usuário: Cada usuário do sistema terá sua permissão para cada determinada função e objetivo do sistema, não tendo acesso as outras funções.
· Estoquista terá acesso ao cadastro do produto, alteração do produto, exclusão do produto e consulta do produto.
· Atendente terá acesso a consulta do produto, realização da venda e fechamento da venda, exclusão do produto na venda através da validação do supervisor da loja conforme [RN06], cancelamento da venda através da validação do supervisor da loja conforme [RN06] e cadastramento do cliente.
· Supervisor da loja validará por meio de seu login e senha a exclusão do produto na venda solicitado pelo atendente e validará por meio de seu login e senha o cancelamento da venda solicitado pelo atendente, terá acesso ao cadastro do produto, alteração do produto, exclusão do produto, consulta do produto, cadastro do cliente e acesso a realização da venda.
[RN04] – Cadastro do cliente: O atendente deverá fazer o cadastramento do cliente antes de efetuar a venda ou informará o código do cliente já cadastrado para realização da venda, cadastramento do cliente deverá ser preenchido todos os campos obrigatórios sendo eles: RG, CPF, nome, endereço. Os campos opcionais são telefone, e-mail do cliente, o sistema estará gerando o código do cliente disponível (auto sequencial) e informará a data do cadastro.
[RN05] – Opção de pagamento: O usuário no fechamento da venda informa ao sistema a opção de pagamento sendo ela (dinheiro/cartão débito ou crédito), pela opção de cartão será validado pela operadora de cartões do cliente.
[RN06] – Validação supervisor da loja: O supervisor deverá validar a exclusão do item registrado na venda pelo atendente através do login e senha e deverá validar o cancelamento da venda pelo atendente através de login e senha.
[RN07] – Informativo da venda: O sistema deverá gerar no fechamento da venda, o informativo da venda contendo os dados do cliente e todos os produtos adquiridos, que deverá conter o código único da venda, com data da venda, valor da venda, opções de pagamento, status de pagamento e o status da venda.
IDENTIFICAÇÃO DE CASOS DE USO
Para definir o levantamento de requisitos e conceituar os serviços que o sistema deve realizar e sua interface com os outros elementos e sob quais restrições o sistema deve operar. Identificaremos com os casos de uso.	
Os casos de uso são utilizados para capturar os requisitos do sistema, ou seja, referem-se aos serviços, tarefas ou funcionalidades identificadas como necessários ao software e que podem ser utilizados de alguma maneira pelos atores que interagem com o sistema. Eles são utilizados para expressar e documentar os comportamentos pretendidos para as funções dessas interações. (Guedes, 2009).
Sistemas não existem isoladamente, sistemas relevantes interage com atores humanos ou autônomos que utilizam este sistema para algum intuito e esses atores desejam que o comportamento do sistema esteja de acordo o previsto.
Um caso de uso caracteriza o comportamento de um sistema ou de uma parte do sistema e é uma descrição de um conjunto sequencial de ações, que irá produzir um resultado reconhecível do valor de um ator.
DIAGRAMA DE CASOS DE USO
O Diagrama de casos de uso é o diagrama que traz uma ideia mais geral e informal da UML, utilizado geralmente nas fases de levantamento e análise de requisitos do sistema, embora venha seja feita a consulta durante todo o processo de modelagem e possa servir de auxílio para outros diagramas.
O diagrama é representado por atores, relacionamentos entre elipse contendo o nome do caso em estudo, um ator é representado por uma figura de um boneco palito e seus relacionamentos são representados por traços	.
Os diagramas de casos de uso são importantes para especificar, visualizar e documentar o comportamento de um elemento. Esses diagramas tornam sistemas, subsistemas e classes acessíveis fácil de ser entendidas, por apresentarem uma visão externa sobre como esses elementos podem ser utilizados no contexto do projeto. O diagrama de casos de uso procura, por meio de uma linguagem simples, possibilitar a percepção do comportamento externo do sistema (em termos de funcionalidades oferecidas por ele) por qualquer pessoa, tentando representar o sistema por intermédio de um ponto de vista do usuário. É, entre todos os diagramas da UML, mais abstrato e, portanto, o mais flexível e informal.
A elaboração da Figura 1 – Diagrama de Casos de Uso abaixo se refere ao projeto proposto de venda de jogos, acessórios e produtos geek, que estaremos expondo as principais funcionalidades do sistema e os relacionamentos entre eles.
Figura 1 - Diagrama de Casos de Uso
Fonte: O autor, 2021.
Especificação de Casos de Uso
Abaixo estará sendo apresentado conforme o projeto proposto um esboço das telas do programa juntamente com os casos de uso respectivos, especificando as funcionalidades do programa, atores envolvidos, objetivos do caso de uso referente ao sistema, pré-condição, pós-condição, fluxo principal, fluxo alternativo e a regra de negócio referente a cada casa do uso. Conforme será mostrado nas próximas seções.
Protótipo de Tela – Menu
Para seguir a próxima seção estarei informando os protótipos das telas de menu das funções dos funcionários e exibindo o que cada função pode navegar dentro do sistema e seu acesso. Logo após será especificado as telas e os casos de uso respectivos e suas funcionalidades, conforme a Figura 2 – Menu Estoquista, Figura 3 – Menu Atendente e Figura 4 – Menu Supervisor. 
Figura 2 - Menu Estoquista
Fonte: O autor, 2021.
Figura 3 - Menu Atendente
Fonte: O autor, 2021.
Figura 4 - Menu Supervisor
Fonte: O autor, 2021.
Caso de Uso – Fazer Login
Figura 5 - Tela Login
Fonte: O autor, 2021.
Tabela 1 - Fazer Login
	Identificação:
	Fazer Login
	Descrição:
	Esse caso de uso permite ao usuário do sistema efetuar o login em sua conta.
	Ator Relacionado:
	Funcionário
	Interessados:
	Funcionário e Loja
	Pré-condições:
	O usuário deve possuir um login e senha.
	Pós-condições:
	O usuário efetua o login e é redirecionado para a página inicial do sistema.
	Fluxo normal:
	1.    O usuário acessa a URL do sistema.
	2.    O sistema exibe a tela de login do sistema, contendo o campo de login e senha.
	3.    O usuário informa os dados de acesso.
	4.    O sistema redireciona o usuário para a "tela menu do sistema".
	Fluxo Alternativo:
	2.1 Caso o usuário seja um funcionário novo que não possua cadastroo supervisor solicita o cadastramento (Que será solicitado pelo RH para o departamento TI).
	3.1 Caso o usuário digite login ou senha inválido o sistema irá exibir uma mensagem de erro de login.
	Regras de Négocio Relacionado:
	[RN01] – Autenticação de usuário
Fonte: O autor, 2021.
Caso de Uso – Cadastrar Produto
Figura 6 - Cadastrar Produto
Fonte: O autor, 2021.
Tabela 2 - Cadastrar Produto
	Identificação:
	Cadastrar Produto
	Descrição:
	Esse caso de uso permite ao usuário do sistema efetuar o cadastro dos produtos da loja.
	Ator Relacionado:
	Funcionário (estoquista)
	Interessados:
	Funcionário e Loja (estoque)
	Pré-condições:
	O usuário deve possuir um produto a ser cadastrado.
	Pós-condições:
	O usuário efetua o cadastro do produto referido.
	Fluxo normal:
	1.    O usuário acessa a URL do sistema.
	2.    O usuário na tela de inicial entra com login e senha.
	3.    O sistema exibe a tela de menu e o usuário clica na opção de "Cadastrar Produto".
	4.    O usuário informa os dados do produto a ser cadastrado.
	5.    O usuário clica na opção de "salvar" o produto.
	Fluxo Alternativo:
	4.1 Caso o usuário não queira cadastrar o produto, poderá clicar em voltar e retornará ao menu principal.
	5.1 O usuário deve preencher todos campos de cadastro do produto, caso o usuário deixe algum campo em branco, uma mensagem de "erro de cadastro do produto", aparecerá.
	Regras de Négocio Relacionado:
	[RN01] – Autenticação de usuário; [RN02] - Cadastro do produto; [RN03] - Permissão do usuário.
Fonte: O autor, 2021.
Caso de Uso – Alterar Produto
Figura 7 - Alterar Produto
Fonte: O autor, 2021.
Tabela 3 - Alterar Produto
	Identificação:
	Alterar Produto
	Descrição:
	Esse caso de uso permite ao usuário do sistema efetuar a alteração dos dados dos produtos cadastrado no sistema.
	Ator Relacionado:
	Funcionário (estoquista)
	Interessados:
	Funcionário e Loja (estoque)
	Pré-condições:
	O sistema deve ter o produto cadastrado.
	Pós-condições:
	O usuário efetua a alteração do produto referido.
	Fluxo normal:
	1.    O usuário acessa a URL do sistema.
	2.    O usuário na tela de inicial entra com login e senha.
	3.    O sistema exibe a tela de menu e o usuário clica na opção de "Alterar Produto".
	4.    O usuário informa os dados do produto a ser alterado.
	5.    O usuário altera os dados do produto.
	6.    O usuário clica na opção de "salvar" o produto.
	Fluxo Alternativo:
	4.1 Caso o usuário não queira alterar o produto, poderá clicar em voltar e retornará ao menu principal.
	5.1 O usuário deve preencher todos campos de cadastro do produto.
	6.1 Caso o usuário deixe algum campo em branco, uma mensagem de "erro de cadastro do produto", aparecerá.
	Regras de Négocio Relacionado:
	[RN01] – Autenticação de usuário; [RN02] - Cadastro do produto; [RN03] - Permissão do usuário.
Fonte: O autor, 2021.
Caso de Uso – Excluir Produto
Figura 8 - Excluir Produto
Fonte: O autor, 2021.
Tabela 4 - Excluir Produto
	Identificação:
	Excluir Produto
	Descrição:
	Esse caso de uso permite ao usuário do sistema efetuar a exclusão do produto cadastrado no sistema.
	Ator Relacionado:
	Funcionário (estoquista)
	Interessados:
	Funcionário e Loja (estoque)
	Pré-condições:
	O sistema deve ter o produto cadastrado.
	Pós-condições:
	O usuário efetua a exclusão do produto referido.
	Fluxo normal:
	1.    O usuário acessa a URL do sistema.
	2.    O usuário na tela de inicial entra com login e senha.
	3.    O sistema exibe a tela de menu e o usuário clica na opção de "Excluir Produto".
	4.    O usuário informa o código ou nome do produto a ser excluído.
	5.    O usuário clica na opção de "excluir" o produto.
	Fluxo Alternativo:
	4.1 Caso o usuário não queira excluir o produto, poderá clicar em voltar e retornará ao menu principal.
	Regras de Négocio Relacionado:
	[RN01] – Autenticação de usuário; [RN03] - Permissão do usuário.
Fonte: O autor, 2021.
Caso de Uso – Consultar Produto
Figura 9 - Consultar Produto
Fonte: O autor, 2021.
Tabela 5 - Consultar Produto
	Identificação:
	Consultar Produto
	Descrição:
	Esse caso de uso permite ao usuário do sistema efetuar a consulta do produto cadastrado no sistema.
	Ator Relacionado:
	Funcionário (estoquista e atendente)
	Interessados:
	Funcionário e Loja 
	Pré-condições:
	O sistema deve ter o produto cadastrado.
	Pós-condições:
	O usuário efetua a consulta do produto referido.
	Fluxo normal:
	1.    O usuário acessa a URL do sistema.
	2.    O usuário na tela de inicial entra com login e senha.
	3.    O sistema exibe a tela de menu e o usuário clica na opção de "Consultar Produto".
	4.    O usuário informa o código ou nome do produto a ser consultado.
	5.    O usuário clica na opção de "voltar".
	Fluxo Alternativo:
	4.1 Caso o usuário não queira consultar o produto, poderá clicar em voltar e retornará ao menu principal.
	Regras de Négocio Relacionado:
	[RN01] – Autenticação de usuário; [RN03] - Permissão do usuário.
Fonte: O autor, 2021.
Caso de Uso – Cadastrar Cliente
Figura 10 - Cadastrar Cliente
Fonte: O autor, 2021.
Tabela 6 - Cadastrar Cliente
	Identificação:
	Cadastrar Cliente
	Descrição:
	Esse caso de uso permite ao usuário do sistema efetuar o cadastro do cliente.
	Ator Relacionado:
	Funcionário (atendente)
	Interessados:
	Funcionário e Loja 
	Pré-condições:
	O sistema deve ter os dados do cliente para cadastro.
	Pós-condições:
	O usuário realiza o cadastro do cliente no sistema.
	Fluxo normal:
	1.    O usuário acessa a URL do sistema.
	2.    O usuário na tela de inicial entra com login e senha.
	3.    O sistema exibe a tela de menu e o usuário clica na opção de "Cadastrar Cliente".
	4.    O usuário informa os dados do cliente para cadastro.
	5.    O usuário clica na opção de "salvar".
	Fluxo Alternativo:
	4.1 Caso o usuário não queira cadastrar o cliente, poderá clicar em voltar e retornará ao menu principal.
	5.1 Caso o usuário deixe de preencher algum campo obrigatório (RG, CPF, Nome, Data do cadastro, Endereço) o sistema apresentará "Erro de cadastro do cliente".
	Regras de Négocio Relacionado:
	[RN01] – Autenticação de usuário; [RN03] - Permissão do usuário; [RN04] - Cadastro do cliente.
Fonte: O autor, 2021.
Caso de Uso – Realizar Venda
Figura 11 - Realizar Venda
Fonte: O autor, 2021.
Tabela 7 - Realizar Venda
	Identificação:
	Realizar Venda
	Descrição:
	Esse caso de uso permite ao usuário do sistema efetuar a venda para o cliente.
	Ator Relacionado:
	Funcionário (atendente e supervisor da loja)
	Interessados:
	Funcionário e Loja 
	Pré-condições:
	Cliente informa os produtos que irá comprar.
	Pós-condições:
	O usuário irá concluir a venda do cliente.
	Fluxo normal:
	1.    O usuário acessa a URL do sistema.
	2.    O usuário na tela de inicial entra com login e senha.
	3.    O sistema exibe a tela de menu e o usuário clica na opção de "Realizar Venda".
	4.    O usuário digita o código do cliente ou CPF no sistema.
	5. O usuário registra os produtos que o cliente está comprando.
	6.    O usuário clica na opção de "Fechar venda".
	7. O usuário informa a opção de pagamento no sistema.
	8. O sistema gera o código único da venda, com data , valor, opção de pagamento, status pagamento e status da venda.
	Fluxo Alternativo:
	4.1 Caso o cliente não tiver cadastro terá que efetuar o caso de uso "cadastrar cliente".
	5.1 Caso o usuário não queira efetuar a venda, poderá clicar em voltar e retornará ao menu principal.
	5.2 Caso o usuário tenha que excluir algum item da venda, selecionará o item a ser excluído e escolhe a opção excluir item, o sistema mostrará a tela de login e senha para ser validado pelo supervisor da loja, que informará os dados de login e senha, que será concluído a exclusão do item.
	5.3 Caso o usuário tenha registrado algum produto e precise cancelar a venda, selecionará a opção "Cancelar Venda" o sistema mostrará a tela de login e senha para ser validado pelo supervisor da loja, que informará os dados de login e senha, para ser concluído o cancelamento da venda.Regras de Négocio Relacionado:
	[RN01] – Autenticação de usuário; [RN03] - Permissão do usuário; [RN04] - Cadastro do cliente; [RN05] - Opção de pagamento; [RN06] - Validação Supervisor da loja; [RN07] - Informativo da venda.
Fonte: O autor, 2021.
DIAGRAMA DE CLASSES
Para especificar a estrutura das informações do projeto proposto, estará sendo usado o diagrama de classes que usa uma metodologia de análise e projeto de sistemas computacionais orientada a objetos. Nos diagramas de classes podemos especificar as perspectivas conceitual ou também chamado de entidade, de especificação e de implementação. 
A classe é o elemento-chave em diagrama de classes, de maneira conceitual uma classe representa um conceito de negócio, a classe é identificada no topo da entidade, no próximo campo identificamos os atributos das classes que são as informações a respeito da entidade que desejamos armazenar sobre uma categoria de coisas de um negócio, o terceiro campo dentro de uma classe é preenchido pelos métodos, que são as operações que serão realizadas, as classes identificadas em seu devido contexto se ligam de alguma forma. Relacionamentos em diagramas de classes exibem essas ligações que por também fazem parte do conhecimento a respeito do negócio, precisam ser identificadas e especificadas no modelo de classes, para representar relacionamentos um tipo comum que são as associações entre classes em um diagrama de classes são instâncias (ocorrências) representadas nos modelos de classes. 
As pontas de uma associação entre classes também devem especificar as multiplicidades, que indicam quantas instâncias das classes podem participar da associação, pelo projeto proposto de vendas. Estará sendo informado também por uso de estereótipos para termos uma orientação mais específica para o processo de identificação de classes que se dividem em classe de fronteira (ou boundary), classe de controle (ou control) e classe de entidade (ou entity). Na Figura 12 – Diagrama de classes abaixo, está evidenciado por meio do diagrama de classes de nível conceitual a organização das classes, atributos e métodos do sistema proposto.
Figura 12 - Diagrama de Classes
Fonte: O autor, 2021.
MODELO ENTIDADE-RELACIONAMENTO
O modelo entidade-relacionamento é definido baseado na percepção do mundo real, que consiste em um conjunto de objetos básicos, sendo chamados entidades e nos relacionamentos entre esses objetos. O objetivo do modelo para o projeto proposto de vendas é facilitar o projeto do banco de dados, assim sendo possível especificar a estrutura lógica geral do banco de dados de uma empresa, especificando o esquema da empresa, quais as entidades e como elas relacionam entre si. No modelo a seguir estará sendo informado os atributos que em conjunto se formam uma entidade, um atributo é um dado que está associado a cada ocorrência de uma entidade ou de um relacionamento. Atributos e valores juntos, descrevam as ocorrências/instâncias de uma entidade.
A entidade que é um conjunto de objetos, da realidade modelada sobre o qual é desejável manter informações no banco de dados. Uma entidade tem um conjunto de características, e os valores para alguns conjuntos dessas características devem ser únicos. A entidade pode ser completa como uma pessoa ou abstrata como uma viagem a lazer ou um conceito.
O relacionamento que é uma associação/conexão entre uma ou múltiplas entidades. Para ser determinado os relacionamentos deve-se considerar as entidades dentro do contexto do sistema a ser construído e do domínio de aplicação a que se destina. 
Estará sendo representado também a cardinalidade que expressa o número de entidades as quais outra entidade pode estar associada através de um conjunto de relacionamentos. E o identificador da entidade, que seria o atributo ou conjunto de relacionamentos e atributos cujo valores diferenciam uma ocorrência da entidade das demais, que podemos chama-lo de chave. 
Diagrama Entidade-Relacionamento (DER)
Iniciaremos com a identificação pelo projeto conceitual criado por (Peter Chen), que pela definição das figuras de retângulos representam conjuntos-entidade, as elipses representam os atributos, os losangos representam conjuntos-relacionamento e as linhas ligam atributos a conjuntos-entidades e conjunto-entidade a conjuntos-relacionamento. A Figura 13 – Diagrama Entidade-Relacionamento (DER) abaixo, representa o que foi especificado nessa seção.
Figura 13 - Diagrama Entidade-Relacionamento (DER)
Fonte: O autor, 2021.
Modelo Entidade-Relacionamento (MER)
A partir da seção anterior, seguindo o diagrama conceitual (DER), logo na Figura 14 - Diagrama Entidade-Relacionamento (MER) abaixo, foi criado o modelo entidade-relacionamento (MER), que foi explicado a definição anteriormente, que seria o modelo lógico que se aproxima com o banco de dados de forma geral.
Figura 14 - Diagrama Entidade-Relacionamento (MER)
Fonte: O autor, 2021.
CONCLUSÃO
Neste projeto foram abordados o levantamento de requisitos, que seria uma das atividades mais importante para criação de um software. Com ela temos uma representação, entendimento, levantamento de informações e abordagem da solicitação e necessidade do cliente, conseguimos dividir o sistema a ser criado em partes com os casos de uso, elaborando o modelo de casos de uso e especificando para um melhor aproveitamento das informações adquiridas, entregando ao cliente através dos requisitos de usabilidade um sistema fluido e de fácil entendimento e operação, com auxilio das regras de negócio foi possível identificar e documentar o que o sistema deve ou não fazer, usando o diagrama de classes abordando as suas respectivas entidades, atributos e relacionamentos do sistema.
E pra finalizar usando o Modelo Entidade-Relacionamento (MER) onde seu objetivo é a representação lógica da estrutura de dados de uma forma próxima a realidade e simples compreendimento das funcionalidades do sistema, assim conseguimos uma ótima comunicação e documentação entre as partes para chegar no objetivo final que é a conclusão do projeto e a satisfação do cliente. 
Complemento o uso de ferramentas que foi utilizado para elaboração do projeto como (brModelo, AxureRP10, Lucidchart), que tornaram possível a apresentação e aplicação de todos requisitos apresentados	 de forma proveitosa.
REFERÊNCIAS
WAZLAWICK, R. S. Análise e Projeto de Sistemas de Informação Orientados a Objetos. 2. ed. Revisada e Atualizada. Rio de Janeiro: Elsevier, 2011.
UNIP INTERATIVA. Manual PIM VI. Disponível em: https://ava.ead.unip.br. Acesso em 05/05/2021.
GUEDES, Gilleanes. UML Uma Abordagem Prática. 1. ed. São Paulo: Novatec, 2004.
GUEDES, Gilleanes. UML 2 Uma Abordagem Prática. 3. ed. São Paulo: Novatec, 2018.
BOOCH, Grady.; RUMNAUGH, James; JACOBSON, Ivar. The Unifield Modeling Language User Guide. Tradução de Fábio Freitas da Silva e Cristina de Amorim Machado. 2. Ed. Rio de Janeiro: Elsevier, 2005.
COUGO, Paulo. Modelagem Conceitual e Projeto de Bancos de Dados. 1. ed. Rio de Janeiro: Campus, 1997.
ELMASRI, R. E.; NAVATHE, S. B. Sistemas de Banco de Dados. 4. ed. Rio de
Janeiro: Addison-Wesley, 2005.