UNIVERSIDADE PAULISTA - UNIP EaD

Projeto Integrado Multidisciplinar VI

Cursos Superiores de Tecnologia a Distância da UNIP EaD

PIM VI – LEVANTAMENTO E A ANÁLISE DE REQUISITOS DE UM SISTEMA

PARA EMPRESA DESTINADA À VENDA DE PRODUTOS E ACESSÓRIOS

São Paulo

2021
 UNIVERSIDADE PAULISTA - UNIP EaD

Projeto Integrado Multidisciplinar VI

Cursos Superiores de Tecnologia a Distância da UNIP EaD

PIM VI – LEVANTAMENTO E A ANÁLISE DE REQUISITOS DE UM SISTEMA

PARA EMPRESA DESTINADA À VENDA DE PRODUTOS E ACESSÓRIOS

Aluno: Lucas Presente Virosta

RA: 2063538
Curso: Análise e Desenvolvimento de Sistemas

São Paulo

2021
 RESUMO

A revolução tecnológica das últimas décadas tem aumentado a demanda cada vez
mais de pessoas e empresas por produtos de software de qualidade e de baixo custo. Isto
tem como objetivo principal a automação de seus processos, o qual resulta em ganho de
produtividade e competitividade no mercado. Tendo em vista essa necessidade de
automação, foram desenvolvidos softwares para vendas, onde é possível gerenciar o estoque
e o caixa. Saber quais itens são mais vendidos, qual o faturamento de cada semana, mês e
ano. Porém, nada disso adianta se os dados não forem armazenados corretamente e que terá
acesso a tais dados. Pensando nisso, o levantamento e a análise de requisitos se fazem
necessária, pois assim, são identificados os atores que utilizaram o sistema e que terão
acesso a certo tipo de dados.

Para armazenar os dados foi será utilizado um banco de dados relacional, definindo
os níveis de acesso para cada ator, assim, restringindo acesso de dados sigilosos por usuários
não autorizados.

Palavras-chaves: Banco de Dados, Software, Análise de Requisitos.

 ABSTRACT

The technological revolution of the last decades has increased the demand of people
and companies for quality and low-cost software products. This has as main objective the
automation of its processes, which results in gains in productivity and competitiveness in the
market. In view of this need for automation, sales software was developed, where it is possible
to manage inventory and cash. Know which items are the most sold, what the sales of each
week, month and year are. However, none of this is useful if the data is not stored correctly
and you will have access to such data. Thinking about it, the requirements survey and analysis
is necessary, because thus, the actors who used the system and who will have access to a
certain type of data are identified.

A relational database will be used to store the data, defining the access levels for
each actor, thus restricting access to sensitive data by unauthorized users.

Keywords: Database, Software, Requirements Analysis.

 SUMÁRIO

Sumário
1 - INTRODUÇÃO.................................................................................................... 7

2 - CASOS DE USO ................................................................................................ 8

2.1 - Requisitos....................................................................................................... 8

2.2 - Casos de uso: ................................................................................................ 8

3 - Modelagem de Casos de Uso ........................................................................... 9

3.1 - Cadastro cliente ............................................................................................. 9

3.2 - Fluxo de Trabalho .......................................................................................... 9

3.3 - Requisitos Relacionados ............................................................................... 9

3.4 - Cadastro de produto .................................................................................... 11

3.5 - Fluxo de Trabalho: ....................................................................................... 11

3.6 - Requisitos Relacionados: ........................................................................... 12

3.7 - Efetuar vendas ............................................................................................. 13

3.8 - Fluxo de trabalho: ........................................................................................ 13

3.9 - Requisitos Relacionados: ........................................................................... 14

4 - Regras de Uso ................................................................................................. 15

4.1 - Login: ............................................................................................................ 16

4.2 - Cadastro de usuário: ................................................................................... 16

4.3 - Cadastro de produto: ................................................................................... 16

4.4 - Cancelamento de vendas: ........................................................................... 16

5 - Contexto de Uso ............................................................................................. 16

5.1 - Usuários e tarefas: ....................................................................................... 16

5.2 - Ambiente: ..................................................................................................... 17

6 - REQUISITOS NÃO FUNCIONAIS .................................................................... 17

6.1 - Requisitos Funcionais ................................................................................. 18

6.2 - Requisitos Não Funcionais ......................................................................... 18

6.3 - Requisitos Não Funcionais de Usabilidade ............................................... 20

7 - DIAGRAMA DE CLASSES DE ANÁLISE ........................................................ 21

7.1 - Diagrama de Classes ................................................................................... 21

7.2 - Diagrama de Objetos ................................................................................... 22

7.3 - Classes de Análises ..................................................................................... 22

7.4 - Elaboração do diagrama de classes de análise ......................................... 23

7.5 - Modelo de Entidade-Relacionamento (MER) .............................................. 23

7.6 - Entidades, atributos e relacionamentos ..................................................... 24

8 - CONCLUSÃO ................................................................................................... 27

9 - REFERÊNCIAS ................................................................................................ 28
 1 - INTRODUÇÃO

Cada vez mais as soluções tecnológicas estão sendo procuradas para

automatização, produtividade, segurança e muitos outros fatores trazendo muitas melhorias
para empresas, profissionais e pessoas que se beneficiam com essas soluções.

Uma empresa no ramo de vendas de jogos, acessórios e produtos geek vendo a

necessidade de obter um sistema que controle seu estoque e suas vendas nos procurou para
desenvolver um projeto para esse sistema. Foi feito o levantamento de requisitos junto ao
cliente, a identificação dos casos de uso onde temos como principais casos de uso cadastros
de clientes e cadastros de produtos, ambos com extensões para alteração, exclusão e
consulta e produtos separados em categorias. Para efetuar venda teremos dados do cliente,
dados do produto, exclusão de produto, cancelamento de venda, consulta de preço e os atores
do sistema serão o estoquista, o atendente e o supervisor, todos com login e senha com nível
de acesso para suas responsabilidades. E por traz o sistema terá um banco de dados
elaborado e planejado para suprir todas permissões e necessidades do sistema, trazendo
segurança e informação de qualidade conforme os requisitos do cliente.
 2 - CASOS DE USO

2.1 - Requisitos

Em reunião com nosso cliente para a produção de um sistema para uma

empresa no ramo de vendas de jogos eletrônicos, acessórios e produtos geek, o sistema em
um âmbito geral irá controlar o estoque dos produtos e as vendas. O acesso ao sistema será
através de login e senha com 3 níveis de acesso, Estoquista, Atendente e Supervisor. O
Estoquista terá acesso ao cadastro de produtos onde será possível salvar, alterar, excluir e
consultar os dados dos produtos que terão as categorias de jogos, acessórios e produtos
geek. O Atendente por sua vez terá acesso ao cadastro de clientes podendo também salvar,
alterar, excluir e consultar os dados dos clientes e é o atendente que realiza as vendas da loja
onde constarão os dados da venda como código da venda, data, valores, formas de
pagamento e status de pagamento e venda, constará os dados do cliente e os dados dos
produtos. E o Supervisor tem acesso em todo o sistema, sendo responsável pela exclusão de
um produto na venda ou o cancelamento de toda a venda utilizando usuário e senha válidos,
no cancelamento da venda o código da venda é enviado para o sistema financeiro. Analisando
os requisitos e em vista dos modelos de mercado chegamos aos seguintes casos de uso:

2.2 - Casos de uso:

● RF 01 - Cadastrar cliente;
● RF 02 - Alterar cliente;
● RF 03 - Excluir cliente;
● RF 04 - Consultar cliente;
● RF 05 - Cadastrar produto;
● RF 06 - Alterar produto;
● RF 07 - Excluir produto;
● RF 08 - Consultar produto;
● RF 09 - Efetuar venda;
● RF 10 - Excluir produto;
● RF 11 - Cancelar venda;
● RF 12 - Buscar cliente;
● RF 13 - Consultar preço;
● RF 14 - Efetuar login com nível de acesso.
 3 - Modelagem de Casos de Uso

3.1 - Cadastro cliente

● Identificação: Cadastrar cliente;

● Escopo: Sistema de vendas e cadastros com controle de estoque;
● Descrição do propósito: Esse caso de uso permite ao atendente ou supervisor realizar
o cadastro de clientes no sistema da loja;
● Ator primário: Atendente e supervisor;
● Interessados: Loja e cliente;
● Pré-condições: O sistema da loja deve estar operacional;
● Pós-condições: O atendente ou supervisor pegam os dados do cliente e salvam no
sistema.

3.2 - Fluxo de Trabalho

1. O atendente ou supervisor clica em cadastrar cliente;

2. Inclusão para validar nível de acesso;
2.1. Caso nível de acesso seja incompatível, uma mensagem é exibida.
2.2. Caso login e senha estejam incorretos, uma mensagem é exibida.
3. Login e senha válidos são informados;
4. O sistema exibe o formulário de cadastro de cliente com todas as opções;
5. Os dados do cliente são preenchidos;
6. Opção salvar, os dados são armazenados no sistema, uma mensagem é exibida.
6.1. Caso existam campos em branco, uma mensagem é exibida.
6.2. Extensão para alterar dados do cliente.
6.3. Extensão para excluir um cliente.
6.4. Extensão para consultar um cliente.

3.3 - Requisitos Relacionados

● RF 02 - Alterar cliente;
● RF 03 - Excluir cliente;
● RF 04 - Consultar cliente;
● RF 14 - Efetuar login com nível de acesso.

Figura 1 - Tela Login

Fonte: Autoria Própria

 Figura 2 - Tela Cadastro Cliente

Fonte: Autoria Própria

3.4 - Cadastro de produto

● Identificação: Cadastrar Produto;

● Escopo: Sistema de vendas e cadastros com controle de estoque;
● Descrição do propósito: Esse caso de uso permite ao estoquista ou supervisor realizar
o cadastro de produtos no sistema da loja;
● Ator primário: Estoquista e supervisor;
● Interessados: Loja e cliente;
● Pré-condições: O sistema da loja deve estar operacional;
● Pós-condições: O estoquista ou supervisor pegam os dados do Produto e salvam no
sistema;

3.5 - Fluxo de Trabalho:

1. O estoquista ou supervisor clica em cadastrar produto.

2. Inclusão para validar nível de acesso.
 2.1. Caso nível de acesso seja incompatível, uma mensagem é exibida.
2.2. Caso login e senha estejam incorretos, uma mensagem é exibida.
3. Login e senha válidos são informados.
4. O sistema exibe o formulário de cadastro de produto com todas as opções.
5. Os dados do produto são preenchidos.
6. Opção salvar, os dados são armazenados no sistema, uma mensagem é exibida.
6.1. Caso existam campos em branco, uma mensagem é exibida.
6.2. Extensão para alterar dados produto.
6.3. Extensão para excluir um produto.
6.4. Extensão para consultar um produto.

3.6 - Requisitos Relacionados:

● RF 06 - Alterar produto;
● RF 07 - Excluir produto;
● RF 08 - Consultar produto;
● RF 14 - Efetuar login com nível de acesso.

Figura 3 - Tela Cadastro Produto

 Fonte: Autoria Própria

3.7 - Efetuar vendas

● Identificação: Efetuar venda;

● Escopo: Sistema de vendas e cadastros com controle de estoque;
● Descrição do propósito: Esse caso de uso permite ao atendente ou supervisor efetuar
a venda de produtos no sistema da loja;
● Ator primário: Atendente e supervisor;
● Interessados: Loja e cliente;
● Pré-condições: O sistema da loja deve estar operacional;
● Pós-condições: os produtos são adicionados a venda é efetuada o pagamento
realizado e a venda concluída.

3.8 - Fluxo de trabalho:

1. O atendente ou supervisor seleciona efetuar venda;
2. Inclusão para validar nível de acesso;
2.1. Caso nível de acesso seja incompatível, uma mensagem é exibida;
2.2. Caso login e senha estejam incorretos, uma mensagem é exibida.
3. Login e senha válidos são informados;
4. O sistema exibe a tela de vendas com todas as opções;
5. Os produtos são adicionados através do código de barras, valor total é atualizado;
5.1. Caso produto não esteja cadastrado, uma mensagem é exibida;
5.2. Caso produto não esteja cadastrado, digitar código manualmente;
5.3. Extensão para buscar dados do cliente;
5.4. Extensão para excluir produto da venda;
5.5. Extensão para cancelar a venda;
5.6. Extensão para consultar preço.
6. A forma de pagamento é selecionada;
7. Opção efetuar venda, pagamento é realizado;
8. Inclusão para atualizar o estoque;
9. Inclusão para finalizar a venda.

3.9 - Requisitos Relacionados:

● RF 10 - Excluir produto;
● RF 11 - Cancelar venda;
● RF 12 - Buscar cliente;
● RF 13 - Consultar preço;
● RF 14 - Efetuar login com nível de acesso.
 Figura 4 - Tela Venda

Fonte: Autoria Própria

4 - Regras de Uso
Foram determinadas as seguintes regras de uso para o sistema. Dentre elas estão:
 4.1 - Login:

● Só usuários pré-cadastrados poderão ter acesso ao sistema;

● Somente funcionários terão acesso direto ao sistema;
● Somente usuários com função de Administrador poderão cadastrar e excluir usuários.

4.2 - Cadastro de usuário:

● Deve ser feito o cadastro de todos os clientes para efetuar a compra;

● Somente usuários com função de Atendente/Administrador poderão cadastrar
clientes;
● Somente usuários com função de Administrador poderão alterar e excluir cadastro de
clientes.

4.3 - Cadastro de produto:

● Somente usuários com função de Estoquista/Administrador poderão cadastrar os

produtos;
● Todos os produtos devem ser cadastrados para possibilitar a venda e o controle de
movimento;
● Todos os dados devem ser preenchidos para efetuar o cadastro do produto.

4.4 - Cancelamento de vendas:

● Somente usuários com função de administrador poderão cancelar uma venda.

5 - Contexto de Uso

5.1 - Usuários e tarefas:

 Os usuários que utilizam o sistema são separados por setores/funções,
classificando e estabelecendo para cada um, uma forma separada e organizada de interação
perante o software. Cada usuário necessita de um tipo específico de ambiente e
funcionalidades, mas contando com a praticidade e desempenho durante o manuseio do
software.

Dentre os usuários, temos os atendentes, que necessitam ter um fácil acesso e ao

mesmo tempo detalhado sobre todos os produtos para que possa ser repassado ao cliente e
ao final a geração da compra.

Os Estoquistas, que necessitam fazer a verificação, validação e cadastramento de

todos os produtos do estoque. Tudo de forma clara e ágil.

Os Supervisores/Administradores, que por segurança tem acesso a todo o sistema,

garantindo uma segurança e total gerenciamento sobre o sistema.

5.2 - Ambiente:

Dentro do ambiente, temos um sistema de banco de dados, que ficam em um

servidor separado dos computadores de atendimento, utilizando um maior processamento e
acesso ao disco rígido.

Propriamente instalado em uma sala com ar condicionado e acesso restrito. Os

servidores estão diretamente conectados ao sistema base, onde é agrupado e alocado todos
os dados do sistema, como (Dados de usuários, senhas, produtos, etc.).

Os softwares de cadastro serão instalados em computadores desktops, que servirão

de base para a comunicação e registro com o banco de dados.

Com acesso aberto a usuários que tem registro sobre o sistema, é possível acessar
de diferentes máquinas sem interferir nas configurações pré estabelecidas em cada usuário.

6 - REQUISITOS NÃO FUNCIONAIS

 Segundo Sommerville (2010), requisitos são serviços que um sistema deve
prestar e suas restrições de funcionamento. Eles devem necessariamente refletir as
necessidades do cliente e são classificados em dois níveis: requisitos de usuário e requisitos
de sistema.

Os requisitos de usuário são declarações em linguagem natural com diagramas

de quais serviços o sistema deverá fornecer a seus usuários e as restrições com as quais ele
deve operar. Eles devem ser direcionados aos clientes, usuários, gerentes de projeto e
arquitetos de sistema, pois definem em alto nível as necessidades, o que define, entre outras
coisas, o escopo do projeto.

Os requisitos de sistema são descrições mais detalhadas das funções, serviços e

restrições operacionais do sistema de software. Eles devem ser direcionados a usuários,
arquitetos de sistema e desenvolvedores, pois podem definir uma sequência de
implementação, o que influencia diretamente na solução dada.

Além da classificação em níveis, os requisitos também são categorizados em:

requisitos funcionais e requisitos não funcionais.

6.1 - Requisitos Funcionais

Os requisitos funcionais (RF) descrevem o comportamento esperado de um

sistema de software, explicita o que o sistema deve fazer e idealmente o que o sistema não
deve fazer (SOMMERVILLE, 2010).

6.2 - Requisitos Não Funcionais

Os requisitos não funcionais (RNF) descrevem restrições sobre os serviços

oferecidos pelo sistema de software (SOMMERVILLE, 2010). Os requisitos funcionais
são insuficientes para descrever o sistema de software, pois é necessário descrever outros
aspectos: atributos do sistema e atributos do ambiente do sistema, normalmente classificados
como requisitos não funcionais. Há várias propostas para classificação de requisitos não
funcionais, Sommerville (2010), por exemplo, classifica‑os de acordo com o representado na
figura a seguir.

Figura 5 - Diagrama de requisitos não funcionais

Fonte: Versolatto, 2015

Além da proposta de Sommerville (2010), a norma ISO/IEC 25010:2011 também trata

da classificação e da definição de requisitos não funcionais. A norma descreve seis
características que definem a qualidade de software: funcionalidade, confiabilidade,
usabilidade, eficiência, manutenibilidade e portabilidade. Essas características, também
denominadas atributos de qualidade, são comumente usadas quando trabalhamos com
requisitos não funcionais. A figura a seguir mostra a estrutura hierárquica dos atributos de
qualidade, quanto a sua classificação, proposta pela norma ISO 25010.

Figura 6 - Diagrama de atributos de qualidade

 Fonte: Versolatto, 2015

6.3 - Requisitos Não Funcionais de Usabilidade

Neste projeto, apresentamos os requisitos não funcionais de usabilidade do

sistema de software desenvolvido. Tal sistema possui fácil utilização sem muitos recursos
gráficos, com adição de descrições das funções (hints) aos botões e configurações de teclas
de atalho para as funções mais utilizadas.

De acordo com uma definição tradicional, a usabilidade consiste de cinco fatores:

● RNF 01 - Facilidade de Aprendizagem: Um usuário com um nível especificado de

experiência deve aprender como usar o sistema em um determinado prazo
especificado.

● RNF 02 - Eficiência da Tarefa: Um usuário deve poder terminar uma determinada

tarefa em um prazo especificado (ou em uma quantidade de cliques do mouse).
 ● RNF 03 - Facilidade de Recordação: Um usuário deve poder recordar como se
realizam determinadas tarefas, após um prazo especificado de não utilização do
sistema.

● RNF 04 - Entendimento: Um usuário deve entender as mensagens e os alertas do

sistema e o que o sistema faz.

● RNF 05 - Satisfação Subjetiva: Uma porcentagem especificada da comunidade de

usuários deve expressar a satisfação de usar o sistema.

Para identificação e especificação dos requisitos não funcionais de usabilidade, utiliza-

se o seguinte método:

1. Identificar as principais questões de usabilidade observando as tarefas críticas, perfis

de usuário, metas do sistema e problemas prévios de usabilidade.

2. Escolher um estilo apropriado para expressar os requisitos:

a. Estilo de Desempenho: Especifica a velocidade que os usuários podem

aprender várias tarefas e a velocidade que eles podem executar as tarefas
após treinamento.

b. Estilo de Defeito: Melhor do que medir os tempos da tarefa, identifica os

defeitos de usabilidade e especifica a frequência com que eles ocorrem.

c. Estilo de Diretriz: Específica a aparência geral e o tempo de resposta da

interface de usuário pela referência a um padrão aceito e bem definido.

3. Escrever requisitos reais, incluindo critérios de desempenho.

7 - DIAGRAMA DE CLASSES DE ANÁLISE

7.1 - Diagrama de Classes

Diagrama de classes é um diagrama UML que tem como objetivo representar

a estrutura estática das classes de um sistema de software (BOOCH, et al., 2006). Pode ser
definido também como a representação das classes, seus atributos, métodos e o
relacionamento entre essas classes (VERSOLATTO, 2015).

7.2 - Diagrama de Objetos

Diagrama de objetos é um diagrama que tem como objetivo representar

instâncias de classes, ou seja, objetos e suas respectivas ligações ou associações. Logo,
podemos dizer que a base do diagrama de objetos é o diagrama de classes. Por meio do
diagrama de objetos tem-se uma visão dos objetos, suas informações e seus relacionamentos
em um determinado cenário em determinado momento de execução desse cenário.

Os diagramas de classes e de objetos são os principais diagramas que

representam a visão estrutural estática de um sistema, todavia, em um sistema existem
aspectos dinâmicos, reações e respostas que o sistema produz e que não são captadas
nessas representações.

7.3 - Classes de Análises

A partir da visão estrutural estática, representada pelos modelos de classes e

de objetos, originou-se o modelo estrutural dinâmico, por meio do qual ocorre a realização
dos casos de uso, ou seja, como efetivamente os objetos se relacionam entre si de forma
dinâmica. Para isso, antes da definição de como uma tarefa será realizada, determinam-se
as responsabilidades de cada objeto.

Os objetos são divididos e categorizados em três grupos de acordo com seu

tipo de responsabilidade: classe entidade, classe de fronteira e classe de controle, também
chamadas de classes de análise.

A classe entidade é o objeto mais próximo do mundo real que o sistema

representa e tem como objetivo principal manter informações referentes ao domínio de
problema que queremos resolver.

A classe de fronteira tem como responsabilidade dividir o ambiente interno do

sistema e suas interações externas.
 A classe de controle tem como objetivo realizar o sequenciamento da execução
de um caso de uso na estrutura de objetos do sistema, fazer a coordenação entre camadas
internas do sistema, representadas pelas classes de entidade, com as camadas externas do
sistema, representadas pelas camadas de fronteira.

7.4 - Elaboração do diagrama de classes de análise

A figura XX apresenta o diagrama de classes de análise do projeto do sistema

de software, elaborado com base na identificação dos substantivos do texto e dos casos de
uso; o relacionamento entre eles com seus respectivos nomes e a multiplicidades entre
classes identificadas. O diagrama mostra também os atributos e métodos de cada classe e a
existência de agregações e heranças.

Figura 7 - Diagrama de classes de análise

Fonte: Autoria Própria.

7.5 - Modelo de Entidade-Relacionamento (MER)

 O Modelo Entidade-Relacionamento (MER) é um tipo de modelo conceitual que
descreve os objetos (entidades), suas características (atributos) e como se relacionam
(relacionamento). Considerado um modelo de alto-nível, tem como objetivo representar um
arranjo de dados mais perto do mundo real, como salienta Pinto (2020, p.36), é um modelo
abstrato desenvolvido pelo Prof. Peter Chen, a fim de representar as estruturas de dados de
forma mais natural e mais próxima do mundo real dos negócios. Partindo desta afirmativa,
podemos entender que o modelo reproduz aspectos abstratos que a estrutura possuirá no
banco de dados da aplicação. Sendo assim, utilizamos os recursos do MER para desenvolver
o Diagrama Entidade-Relacionamento (DER) o qual é a sua representação gráfica.

7.6 - Entidades, atributos e relacionamentos

●
● produto, sendo assim uma venda sem itens não faz sentido.
● Entidades associativas: surgem quando há a necessidade de associar uma entidade
a um relacionamento existente. Na modelagem Entidade-Relacionamento não é
possível que um relacionamento seja associado a uma entidade. Então tornamos esse
relacionamento uma entidade associativa, que a partir daí poderá se relacionar com
outras entidades, conforme descrito no sítio Devmedia.
● Atributos são a representação de uma propriedade de uma entidade ou de um
relacionamento, ou seja, são as características usadas para descrever cada entidade
dentro do domínio, podendo ser descritivo os quais representam características
particular (ex.: nome, cor), nominativos além de descritos tem a função de identificar e
definir o objeto (ex.: número, código) e referenciais que é a ligação de uma entidade a
outra em um relacionamento (ex.: CPF relaciona com a entidade vendas).
● Relacionamento é a representação das associações entre entidades indicadas através
das cardinalidades que é o número de ocorrências de uma entidade que se relaciona
com uma outra.
● Relacionamentos um para um (1-1) - nesse tipo de relacionamento cada uma das
entidades se referência obrigatoriamente apenas uma unidade da outra.
● Relacionamentos um para muitos (1-n ou 1..*) - nesse tipo de relacionamento uma das
entidades pode referenciar várias unidades da outra.
● Relacionamentos muitos para muitos (n-n ou *..*) - neste tipo de relacionamento cada
entidade, de ambos os lados, podem referenciar múltiplas unidades da outra.
 A figura XX, ilustra a representação gráfica do Modelo Entidade-Relacionamento
(MER) e o Diagrama de Entidade-Relacionamento (DER). A partir do diagrama de classes
foram identificadas as classes que precisaram ser persistidas com suas respectivas tabelas.
Assim como, foram criadas as chaves primárias de cada tabela.

As relações do tipo 1..n também foram especificadas e propagadas a chave

estrangeira para o lado n. Da mesmas forma, as relações do tipo n..n foram confeccionadas
juntamente com suas tabelas de relacionamento, contendo as chaves primárias das tabelas
envolvidas nessa relação.

Figura 8 - Modelo de Entidade-Relacionamento (MER)

Fonte: Autoria Própria.

Figura 9 - Diagrama Entidade-Relacionamento (DER)

Fonte: Autoria Própria.

 8 - CONCLUSÃO

Neste Projeto Integrado Multidisciplinar (PIM), apresentou-se um projeto para

desenvolvimento de um sistema para uma loja. Seu objetivo era poder realizar cadastro de
novos usuários e clientes, salvado seus dados em um banco de dados relacional, para
recuperação posterior.

Para isso foi realizado o levantamento e análise de requisitos junto ao cliente, para
saber quais suas necessidades para o projeto.

Um dos pontos a se analisar era o fato de se ter níveis de acesso diferentes para
cada tipo de usuário, assim restringindo o acesso não autorizado de dados sensíveis.

Para definir a estrutura do banco de dados foi utilizado o Modelo Entidade-Relacional

(MER) e Diagrama Entidade-Relacional (DER). Também foi apresentado o diagrama de
classes de análise, com este diagrama podemos modelar de forma mais precisa o software
do cliente e os dados a serem armazenados.
 9 - REFERÊNCIAS

Árvore do Conhecimento http://www.corais.org/node/86 Acessado dia 09/04/2021.

Diretriz: Requisitos Não-Funcionais

https://www.trt9.jus.br/pds/pdstrt9/guidances/guidelines/supporting_requirements_8ED0BB6
B.html Acessado dia 10/04/2021.

Engenharia de Usabilidade
http://www.univasf.edu.br/~jorge.cavalcanti/Ihm5_Engenharia%20de%20Usabilidade.pdf

Acessado dia 13/04/2021.

O Processo de Design Necessidades dos Usuários Requisitos http://www.inf.puc-

rio.br/~inf1403/docs/alberto2011_1/18_Design_Requisitos.pdf Acessado dia 13/04/2021.

Versolatto, Fábio Rossi. Análise Orientada a Objetos. – São Paulo: Editora Sol, 2015. 172 p. il.

PINTO, Gisele Lopes Batista. Administração de banco de dados. São Paulo: Editora Sol, 2020.

Site para modelagem de tela: https://ninjamock.com/Designer/Workplace

Acesso em 13/04/2021.

Site usado para criação dos diagramas https://lucid.app/documents#/dashboard Acessado dia

14/04/2021.