PIM 6 UNIP

Prévia do material em texto

1 
UNIVERSIDADE PAULISTA – UNIP EaD 
SUP.TEC.ANALISE E DESENVOLVIMENTO DE SISTEMAS 
Projeto integrado multidisciplinar 
 
BRUNO ALVES DA SILVA - RA 2104059 
CLEBER FERREIRA DE FREITAS - RA 2134730 
JAMES BRYAN SAMPAIO DA SILVA - RA 2142437 
JOHNNY NUNES DOS SANTOS - RA 2131524 
SERGIO ROBERTO XAVIER JUNIOR - RA 2255281 
MARCIO ANTONIO MARTINS JUNIOR - RA 2139521 
 
 
PROJETO INTEGRADO MULTIDISCIPLINAR VI 
Levantamento e análise de requisitos de um sistema de controle de vendas de 
uma loja de jogos, acessórios e produtos geek. 
 
 
CAMPINAS – SP 
2022 
 
 2 
BRUNO ALVES DA SILVA - RA 2104059 
CLEBER FERREIRA DE FREITAS - RA 2134730 
JAMES BRYAN SAMPAIO DA SILVA - RA 2142437 
JOHNNY NUNES DOS SANTOS - RA 2131524 
SERGIO ROBERTO XAVIER JUNIOR - RA 2255281 
MARCIO ANTONIO MARTINS JUNIOR - RA 2139521 
 
 
Projeto Integrado Multidisciplinar VI 
Levantamento e análise de requisitos de um sistema de controle de vendas de 
uma loja de jogos, acessórios e produtos geek. 
 
 
 
Projeto Integrado Multidisciplinar para a 
obtenção do título de graduação em 
Analise e desenvolvimento de sistemas, 
apresentado à Universidade Paulista 
UNIP EAD. Orientadora: Profa. Sandra 
Bozolan 
 
CAMPINAS - CENTRO 
2022 
 
 3 
RESUMO 
 
O projeto integrado multidisciplinar VI tem como objetivo de por em prática os 
conteúdos adquiridos nas aulas acadêmicas do curso de Analista e desenvolvimento 
de Sistemas, que abrange e as interligam, sendo elas; Analise de sistemas 
Orientada a Objetos, Banco de Dados e Gestão Estratégica de RH. Com a finalidade 
de apresentar um levantamento e a análise de requisitos de um sistema de controle 
de vendas para uma loja de jogos, acessórios e produtos geek. 
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. É o que será tratado de forma simples 
neste projeto. 
Palavras – Chaves: Agilidade, Organização, Software 
 
 
 
 
 
 
 
 
 
 4 
ABSTRACT 
The integrated multidisciplinary project VI aims to put into practice the content 
acquired in academic classes of the course of Analyst and Systems Development, 
which covers and interconnects them, being they; Object Oriented Systems Analysis, 
Database and HR Strategic Management. The objective is to present a survey and 
requirements analysis of a sales control system for a store that sells games, 
accessories, and geek products. 
The technological revolution of the last decades has increased the demand more and 
more from people and companies for quality and low cost software products. This 
has as a main goal the automation of their processes, which results in productivity 
gain and market competitiveness. In view of this need for automation, software was 
developed for sales, where it is possible to manage stock and cash. This is what will 
be treated in a simple way in this project. 
Keywords: Agility, Organization, Software 
 
 
 
 
 
 
 
 
 
 
 5 
SUMARIO 
1. INTRODUÇÃO...............................................................................6 
2. REQUISITOS.................................................................................7 
3. O QUE SÃO CASOS DE USOS....................................................7 
3.1 Identificando Casos de Usos.....................................................7 
3.2 Modelagem de casos de usos...................................................8 
3.3 Cadastro Cliente........................................................................8 
4. TELA INICIAL (Figura 1- Login).....................................................9 
5. TELA CADASTRO CLIENTE (Figura - 2).....................................10 
5.1 Cadastro Produto.....................................................................10 
5.2 Fluxo Operacional....................................................................10 
5.3 Exemplo de Modelagem I.........................................................11 
5.4 Tela Cadastro de Produtos.......................................................12 
6. EFETUAR VENDAR......................................................................12 
6.1 Fluxo Operacional.....................................................................12 
6.2 Exemplo de Modelagem...........................................................14 
7. TELA DE VENDAS........................................................................14 
7.1 Regras de Uso..........................................................................15 
7.2 Cadastro de Usuários...............................................................15 
7.3 Cadastro Produtos....................................................................15 
7.4 Cancelamento de Vendas.........................................................16 
8. USUARIO E TAREFA....................................................................16 
9. AMBIENTE.....................................................................................17 
10. OS REQUISITOS NÃO FUNCIONAIS DE USABILIDADE............17 
11. DIAGRAMA DE CLASSE DE ANÁLISE.........................................18 
12. CLASSE DE ANALISE...................................................................18 
13. O DIAGRAMA DE CLASSE..........................................................19 
14. MODELO DE ENTIDADE – RELACIONAMENTO (MER)..............20 
14.1 Figura Modelo Entidade (MER)..............................................22 
15. CONCLUSÃO.................................................................................23 
16. REFERENCIAS..............................................................................24 
 
 6 
1. INTRODUÇÃO 
 
A revolução tecnológica é um fenômeno atual, que vem transformando a maneira 
das pessoas encararem o mundo. Ela é resultado de um desenvolvimento onde há a 
transição de um ambiente materialista para algo digital e intangível. 
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 de um modo geral a todos os usuário, também para empresas que se 
beneficiam com essas soluções. Empresa essa que precisa de uma melhor 
organização de seus produtos voltada a um estilo Geek, pra facilitar na rotina de 
vendas. 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. 
 
 
 
 
 
 
 
 
 
 7 
2. REQUISITOS 
Após uma entrevista pra melhor entendermos da rotina da loja, e para um melhor 
entendimento dos requisitos necessário para que seja desenvolvido o software que 
auxilie ainda mais no desenvolvimento da empresa. o escopo desse projeto exibirá 
as seguintes informações. 
 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ívelsalvar, 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. Analisandos os requisitos, e em vista dos 
modelos de mercado os casos de uso ficaram assim; 
 
3. O QUE SÃO CASOS DE USO? 
Um caso de uso especifica o Comportamento de uma sistema (ou parte), e é uma 
descrição de um conjunto de sequencia de ações para produzir um resultado 
observável do valor de um ator. No geral podemos dizer que Casos de uso eles 
representam aspecto dos comportamentos de classe e modelam os requisitos do 
sistema. 
 
 3.1 INDENTIFICANDO CASOS DE USO; 
 
a. RF 01 - Cadastrar cliente; 
b. RF 02 - Alterar cliente; 
 8 
c. RF 03 - Excluir cliente; 
d. RF 04 - Consultar cliente; 
e. RF 05 - Cadastrar produto; 
f. RF 06 - Alterar produto; 
g. RF 07 - Excluir produto; 
h. RF 08 - Consultar produto; 
i. RF 09 - Efetuar venda; 
j. RF 11 - Excluir produto; 
k. RF 12 - Cancelar venda; 
l. RF 13 - Buscar cliente; 
m. RF 14 - Consultar preço; 
n. RF 15 - Efetuar login nível de acesso. 
 
3.2 . Modelagem de caso de uso cliente 
3.3 Cadastro Cliente 
• Identificação: Cadastrar cliente 
• Escopo: Vendas, controle de estoque 
• Propósito: Caso de uso Permite Supervisor e atendentes a cadastrar 
• Ator primário: Atendente e supervisor 
• Interessados: Loja / cliente; 
• Pré-condições: Organização de computadores deve esta operando 
• Pós-condições: Dados informados ao sistemas serão armazenados 
 
3.4 Fluxo Operacional 
 
1. Atendente ou supervisor cadastram o cliente; 
2. Inclusão para validar 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 são validados 
 9 
4. O sistema exibe o formulário de cadastro de cliente. 
5. Opção salvar, os dados são armazenados no sistema, uma mensagem é exibida. 
5.1 Caso existam campos em branco, uma mensagem é exibida. 
5.2 Extensão para alterar produto 
5.4 Extensão para exclusão produto 
5.4 Extensão consulta produto 
5.5 Nível de acesso, efetuar login 
 
 
4. TELA INICIAL 
FIGURA 1 - Login 
Fonte: Autoria Própria (2022) 
 
 
5. TELA CADASTRO CLIENTE 
 10 
Figura 2 – Tela de Cadastro Cliente 
Fonte: Autoria Própria (2022) 
 
5.1 Cadastro 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 
• 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; 
 
5.2 Fluxo Operacional 
 
 11 
1. O estoquista ou supervisor clica em cadastrar produto. 
2. Inclusão para validar nível de acesso. 
3. Caso nível de acesso seja incompatível, uma mensagem é exibida. 
4. Caso login e senha estejam incorretos, uma mensagem é exibida. 
5. Login e senha válidos são informados. 
6. O sistema exibe o formulário de cadastro de produto com todas as opções. 
7. Os dados do produto são preenchidos. 
8. Opção salvar, os dados são armazenados no sistema, uma mensagem é 
exibida. 
9. Caso existam campos em branco, uma mensagem é exibida. 
10. Extensão para alterar dados produto. 
11. Extensão para excluir um produto. 
12. Extensão para consultar um produto. 
13. RF 06 - Alterar produto; 
14. RF 07 - Excluir produto; 
15. RF 08 - Consultar produto; 
16. RF 14 - Efetuar login com nível de acesso. 
5.3 Exemplo de modelagem I ; 
 Fonte; Autoria Própria (2022 
 12 
5.4 Tela Cadastro de Produtos 
Figura 3 – Tela Cadastro de Produtos 
 Fonte; Autoria Própria (2022) 
6. EFETUAR VENDAS 
 
• Identificação: Efetuar vendas 
• 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 
• Ator Primário: Atendente e supervisor; 
• Interessados: Loja 
• Pré-Condições: O sistema da loja deve estar operacional; 
• Pós-Condições: Venda é efetuada o pagamento realizado e a venda 
concluída. 
 
6.1 Fluxo Operacional 
1. O atendente ou supervisor seleciona efetuar venda; 
2. Inclusão para validar nível de acesso; 
 13 
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. Forma de Pagamento; 
7. Opção efetuar venda, pagamento é realizado; 
8. Inclusão para atualizar o estoque; 
9. Inclusão para finalizar a venda. 
10. RF 10 - Excluir produto; 
11. RF 11 - Cancelar venda; 
12. RF 12 - Buscar cliente; 
13. RF 13 - Consultar preço; 
14. RF 14 - Efetuar login com nível de acesso. 
 14 
 6.2 Exemplo de Modelagem II; 
Fonte; Autoria Própria (2022) 
 
7. TELA DE VENDAS 
 15 
 
Fonte: Autoria Própria (2022) 
 
 7.1 REGRAS DE USO 
Foram definidas as regras de uso, sendo elas; 
Login; 
• Somente usuários cadastrados no sistema terão acesso; 
• O sistema é privado e apenas funcionários terão acesso; 
• Somente Administradores com suas funções da loja poderão excluir e 
cadastrar usuários. 
• Para usufruir desse sistema o usuário deve informar; usuário e senha 
válidos. 
• todo acesso ao sistema é feito na loja por meio de login e senha; 
 7.2 Cadastro de Usuários; 
• Deve ser feito o cadastro de clientes pra efetuar a compra. 
• Administradores poderão alterar, incluir e excluir cadastro de cliente. 
 7.3 Cadastro Produtos; 
 16 
• 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 solicitados pelo sistema, devem ser preenchidos para efetuar 
o cadastro do produto. 
• O atendente poderá consultar os preços dos produtos caso o cliente solicite. 
 7.4 Cancelamento de Vendas; 
• A venda pode ser cancelada apenas pelo supervisor da loja. 
• Após cancelamento o código da venda deve ser enviado para o sistema 
financeiro. 
 
8. USUARIOS E TAREFAS 
Os usuários que utilizam o sistema são separadas por setores/funções; 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çatem acesso a todo o 
sistema, garantindo uma segurança e total gerenciamento sobre o sistema. 
 
9. AMBIENTE 
 17 
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. 
 
10. OS REQUISITOS NÃO FUNCIONAIS DE USABILIDADE 
 
Neste projeto, apresentamos os requisitos não funcionais de usabilidade do sistema 
que abordam aspectos que serão entregues ao o usuário que terá acesso a esse 
software bem desenvolvido. Tal sistema possui fácil utilização sem muitos recursos 
gráficos, com adição de descrições das funções 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: 
 
• 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. 
 18 
• Eficiência: Um usuário deve poder terminar uma determinada tarefa 
em um prazo especificado (ou em uma quantidade de cliques do 
mouse). 
• Facilidade de Percepção: Um usuário deve recordar facilmente de 
como executar as funções percebendo a simplicidade do sistema, 
como se realizam determinadas tarefas, após um prazo especificado 
de não utilização do sistema. 
• Entendimento: Um usuário deve entender as mensagens e os alertas 
do sistema e o que o sistema faz. 
• Satisfação: Uma porcentagem especificada da comunidade de 
usuários deve expressar a satisfação de usar o sistema. 
 
11. DIAGRAMAS DE CLASSE 
 
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). 
12. CLASSES DE ANALISE 
 
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. 
 19 
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. 
13. O DIAGRAMA DE CLASSES DE ANALISE 
 
Fonte: Autoria Própria (2022) 
 
 20 
14. 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. 
Entidades, atributos e relacionamentos; 
O objeto principal da Entidade-Relacionamento é a entidade, pois é por meio dela 
que são representadas as categorias de fatos do mundo real. Segundo Pinto (2020, 
p.33), representam categorias de fatos do mundo real, sejam eles concretos ou 
abstratos, como empregados, departamentos, despesas, etc., ou seja, podem ser 
classificadas em entidade física e entidade lógica. 
Conforme o sítio Devmedia, as Entidades Físicas são existentes e visíveis no mundo 
real, por exemplo, um atendente de um cliente (ex.: uma pessoa) ou até mesmo um 
produto (ex.: um computador). Entidades Lógicas existem em decorrência da 
interação entre ou com entidades físicas que fazem sentido dentro de um certo 
domínio de negócios, mas no mundo externo/real não são objetos físicos (ex.: uma 
função de um usuário do sistema). 
Partindo dessa conjectura podemos classificar as entidades como: fortes, fracas e 
associativa. 
Entidades fortes: são aquelas que existem independentemente de outras 
entidades. Ela possui total sentido para existir. Em nosso sistema de vendas 
por exemplo, a entidade produto existe sem que outra entidade exista. 
Entidades fracas: diferente das entidades fortes, as fracas dependem que 
outras entidades existam, pois ela só não faz sentido. A exemplo, a entidade 
 21 
do nosso sistema de vendas depende da entidade 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 referenciam 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 
 22 
persistidas com suas respectivas tabelas. Assim como, foram criadas as chaves 
primárias de cada tabela. 
As relaçõesdo 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 - Modelo de Entidade-Relacionamento (MER) 
 
Fonte : Bruno Alves (2022) 
 23 
 
15. CONCLUSÃO 
Este projeto tem como conclusão informar que analistas devem se atentar desde a 
entrevista, com requisitos, normas e tudo que é necessário para o desenvolvimento de um 
software. Que busque a realização de um escopo que fique bem claro, de maneira simples e 
organizada para os outros profissionais da área que possam identificar o proposito desse 
software de maneira simples e objetiva, para que se alcance os objetivos do cliente, que ele 
possa usufruir de um sistema capacitado em atender todas as suas expectativas para um 
bom desempenho de qualquer serviço que se vá prestar e se comprometer de que vai 
entregar uma boa qualidade para a satisfação geral. De acordo com esse PIM, o cliente 
possui uma loja geek com diversos funcionários e funções diferentes, com produtos para 
todas as pessoas sem faixa etária. Onde o software que organiza, que agiliza e que vende; 
que seja ele o menor dos problemas para a loja. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 24 
16. REFERÊNCIAS 
 
https://www.youtube.com/c/bosontreinamentos 
http://www.univasf.edu.br/~jorge.cavalcanti/Ihm5_Engenharia%20de%20Usabilidade
.pdf 
http://www.inf.puc-rio.br/~inf1403/docs/alberto2011_1/18_Design_Requisitos.pdf 
http://www.corais.org/node/86 
https://www.digitalhouse.com/br/blog/revolucao-tecnologica/ 
https://www.trt9.jus.br/pds/pdstrt9/guidances/guidelines/supporting_requirements_8E
D0BB6B.html 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. 
https://www.google.com/search?q=diagrama+modelo+(der)&tbm=isch&ved=2ahUKE
wid-ODC_I34AhX1MrkGHXV1DzEQ2-
cCegQIABAA&oq=diagrama+modelo+(der)&gs_lcp=CgNpbWcQA1C0B1jAC2C-
D2gAcAB4AIABaogBnwOSAQMwLjSYAQCgAQGqAQtnd3Mtd2l6LWltZ8ABAQ&scli
ent=img&ei=NkKYYp2FL_Xl5OUP9eq9iAM&bih=547&biw=1242&rlz=1CAPPDO_en
BR942 
DEVMEDIA. Modelo Entidade Relacionamento (MER) e Diagrama Entidade-
Relacionamento (DER). Disponível em: <https://www.devmedia.com.br/modelo-
entidade-relacionamento-mer-e-diagrama-entidade-relacionamento-der/14332>. 
Acesso em: 18 de maio de 2020. 
http://wiki.foz.ifpr.edu.br/wiki/index.php/Arquivo:UCManterRota.png 
https://www.digitalhouse.com/br/blog/revolucao-tecnologica/ 
file:///home/chronos/u-
9220b97d74be8af2650bb92ce625e9af37c72acf/MyFiles/Downloads/Unip/%20An%C
http://www.univasf.edu.br/~jorge.cavalcanti/Ihm5_Engenharia%20de%20Usabilidade.pdf
http://www.univasf.edu.br/~jorge.cavalcanti/Ihm5_Engenharia%20de%20Usabilidade.pdf
http://www.inf.puc-rio.br/~inf1403/docs/alberto2011_1/18_Design_Requisitos.pdf
http://www.corais.org/node/86
https://www.trt9.jus.br/pds/pdstrt9/guidances/guidelines/supporting_requirements_8ED0BB6B.html
https://www.trt9.jus.br/pds/pdstrt9/guidances/guidelines/supporting_requirements_8ED0BB6B.html
http://wiki.foz.ifpr.edu.br/wiki/index.php/Arquivo:UCManterRota.png
/home/chronos/u-9220b97d74be8af2650bb92ce625e9af37c72acf/MyFiles/Downloads/Unip/%20Análise%20de%20Sistemas%20Orientada%20a%20Objetos%20Livro-Texto%20–%20Unidade%20II.pdf
/home/chronos/u-9220b97d74be8af2650bb92ce625e9af37c72acf/MyFiles/Downloads/Unip/%20Análise%20de%20Sistemas%20Orientada%20a%20Objetos%20Livro-Texto%20–%20Unidade%20II.pdf
 25 
3%A1lise%20de%20Sistemas%20Orientada%20a%20Objetos%20Livro-
Texto%20%E2%80%93%20Unidade%20II.pdf 
http://www.univasf.edu.br/~ricardo.aramos/disciplinas/ES_II_2011_1/aulas/Exemplo
ModelagemCasosDeUso.pdf 
 
 
/home/chronos/u-9220b97d74be8af2650bb92ce625e9af37c72acf/MyFiles/Downloads/Unip/%20Análise%20de%20Sistemas%20Orientada%20a%20Objetos%20Livro-Texto%20–%20Unidade%20II.pdf
/home/chronos/u-9220b97d74be8af2650bb92ce625e9af37c72acf/MyFiles/Downloads/Unip/%20Análise%20de%20Sistemas%20Orientada%20a%20Objetos%20Livro-Texto%20–%20Unidade%20II.pdf
http://www.univasf.edu.br/~ricardo.aramos/disciplinas/ES_II_2011_1/aulas/ExemploModelagemCasosDeUso.pdf
http://www.univasf.edu.br/~ricardo.aramos/disciplinas/ES_II_2011_1/aulas/ExemploModelagemCasosDeUso.pdf