PROJETO INTEGRADO MULTIDISCIPLINAR_PIM_VI_FINAL

Prévia do material em texto

UNIVERSIDADE PAULISTA – UNIP EAD 
Projeto Integrado Multidisciplinar 
Curso Superior de Tecnologia em Análise e Desenvolvimento de Sistemas 
 
 
 
ADRIANA GOMES VERDI – 0579299 
 
 
 
 
 
LEVANTAMENTO E ANÁLISE DE REQUISITOS DE UM SISTEMA PARA A 
EMPRESA NOVA ERA GAMES E INFORMÁTICA DESTINADA À VENDA DE 
JOGOS ELETRÔNICOS, ACESSÓRIOS E PRODUTOS GEEK - PROJETO 
INTEGRADO MULTIDISCIPLINAR VI (PIM VI) 
 
 
 
 
 
 
São Bernardo do Campo 
2021 
ADRIANA GOMES VERDI – 0579299 
 
 
 
 
LEVANTAMENTO E ANÁLISE DE REQUISITOS DE UM SISTEMA PARA A 
EMPRESA NOVA ERA GAMES E INFORMÁTICA DESTINADA À VENDA DE 
JOGOS ELETRÔNICOS, ACESSÓRIOS E PRODUTOS GEEK - PROJETO 
INTEGRADO MULTIDISCIPLINAR VI (PIM VI) 
 
 
 
 
Projeto Integrado Multidisciplinar VI 
para obtenção do título de 
Tecnólogo em Análise e 
Desenvolvimento de Sistemas 
apresentado à Universidade 
Paulista – UNIP EAD. Orientador: 
Professor Luiz Antonio de Lima. 
 
 
 
 
São Bernardo do Campo 
2021 
RESUMO 
 
Atualmente à tecnologia de hardware evoluiu e esta evolução se renova a cada 
dia, e por isso devemos desenvolver sistemas de software que se adaptem a esta 
tecnologia com foco em fornecer uma experiência rica ao usuário, com segurança e 
conforto no uso e, realizando suas atividades de maneira produtiva. O software deve 
ser desenvolvido em tempo e custo a torná-lo efetivamente competitivo em uma 
empresa, apresentando um projeto que ofereça manutenção rápida e eficiente. Pois, 
se o ramo da tecnologia competitiva muda com muita rapidez, um sistema de software 
também deve se adaptar a essa realidade. O objetivo do trabalho sobre a disciplina 
Projeto Integrado Multidisciplinar VI (PIM VI) foi o de realizar o levantamento e a 
análise de requisitos de um sistema para empresa destinada à venda de jogos 
eletrônicos, acessórios e produtos geek, utilizando as técnicas aprendidas através das 
disciplinas Análise de Sistemas Orientada a Objetos, Banco de Dados e Gestão 
Estratégica de Recursos Humanos (RH). A empresa é a Nova Era Games e 
Informática, localizada na rua dos Timbiras, 239 – Loja 4 – Santa Ifigênia, São Paulo 
– SP e atua na área de vídeo games e informática. A metodologia consistiu em 
identificar os casos de uso, elaborar o modelo de casos de uso, identificar 
relacionamentos de include, extend e generalização, demonstrar que cada caso de 
uso deve ter uma descrição sucinta do seu comportamento, do fluxo principal, fluxos 
alternativos e de exceção, pré e pós-condições, descrever os requisitos não funcionais 
(requisitos de usabilidade), identificar e descrever o contexto de uso (usuários, tarefas 
e ambiente), descrever as regras de negócio, elaborar o diagrama de classes de 
análise (Boundary, Control, Entity), construir o modelo de dados chamado Modelo 
Entidade de Relacionamento (MER), onde para todas as disciplinas contempladas 
para a realização do PIM VI utilizamos na metodologia a pesquisa bibliográfica e 
pesquisa de campo. Pudemos observar que a parte mais importante do PIM VI foi a 
de descrever as regras de negócio, onde controlamos o estoque e gerenciamos as 
vendas da empresa para qual desenvolvemos um sistema de software competitivo, 
atingindo um alto nível de qualidade e custo-benefício, e assim fazendo com que a 
empresa esteja na frente de seus concorrentes de mercado. 
 
Palavras-chave: PIM VI, desenvolvimento de software, software competitivo. 
ABSTRACT 
 
Currently the hardware technology has evolved and, this evolution is renewed every 
day, so we must develop software systems that adapt to this technology with a focus 
on providing a rich user experience, with safety and comfort in use and, carrying out 
their activities productively. The software must be developed in time and cost to make 
it effectively competitive in a company, presenting a project that offers fast and efficient 
maintenance. For, if the field of competitive technology changes very quickly, a 
software system must also adapt to this reality. The objective of the work on the 
discipline Multidisciplinary Integrated Project VI (PIM VI) was to carry out the survey 
and analysis of requirements of a system for a company destined to the sale of 
electronic games, accessories and geek products, using the techniques learned 
through the disciplines Object Oriented Systems Analysis, Database and Strategic 
Human Resources (HR) Management. The company is Nova Era Games e 
Informática, located at Rua dos Timbiras, 239 - Loja 4 - Santa Ifigênia, São Paulo - SP 
and operates in the area of video games and information technology. The methodology 
consisted of identifying the use cases, elaborating the use case model, identifying 
include, extend and generalization relationships, demonstrating that each use case 
must have a succinct description of its behavior, the main flow, alternative flows and 
exception, pre and post conditions, describe the non-functional requirements (usability 
requirements), identify and describe the context of use (users, tasks and environment), 
describe the business rules, elaborate the analysis class diagram (Boundary, Control, 
Entity), to build the data model called Model of Relationship Entity (MER), where for all 
the disciplines contemplated for the realization of PIM VI we use in the methodology 
the bibliographic research and field research. We were able to observe that the most 
important part of PIM VI was to describe the business rules, where we control the 
inventory and manage the sales of the company for which we developed a competitive 
software system, reaching a high level of quality and cost-effectiveness, and thus 
making the company ahead of its market competitors. 
 
 
 
 
keywords: PIM VI, software development, competitive software. 
SUMÁRIO 
 
1 INTRODUÇÃO ....................................................................................................... 07 
2 ANÁLISE DE SISTEMAS ORIENTADA A OBJETOS .......................................... 08 
2.1 Introdução à análise de sistemas orientada a objetos .................................. 08 
2.2 Casos de uso .................................................................................................... 11 
2.3 Modelo de casos de uso .................................................................................. 12 
2.3.1 Cadastrar produto ......................................................................................... 14 
2.3.2 Cadastro de Cliente ........................................................................................ 17 
2.3.3 Efetuar venda .................................................................................................. 19 
2.4 Normas de uso .................................................................................................. 21 
2.4.1 Login ................................................................................................................ 22 
2.4.2 Cadastrar usuário ........................................................................................... 22 
2.4.3 Cadastrar produto .......................................................................................... 22 
2.4.4 Cadastrar vendas ........................................................................................... 22 
2.5 Contexto de uso ................................................................................................ 23 
2.5.1 Usuários e tarefas .......................................................................................... 23 
2.5.2 Ambiente ......................................................................................................... 23 
2.6 Requisitos funcionais ....................................................................................... 24 
2.7 Requisitos não funcionais ................................................................................ 24 
2.8 Requisitos não funcionais de usabilidade...................................................... 26 
3 BANCO DE DADOS ............................................................................................. 27 
3.1 Diagrama de classes de análise ............................................................................. 27 
3.1.1 Diagrama de classes ............................................................................................. 28 
3.1.2 Diagrama de objetos ............................................................................................. 28 
3.1.3 Classes de análises .............................................................................................. 28 
3.1.4 Elaboração do diagrama de classes de análise .............................................. 29 
3.1.5 Modelo Entidade-Relacionamento (MER) ......................................................... 30 
3.1.6 Entidades, atributos e relacionamentos ........................................................... 26 
3.1.6 Entidades, atributos e relacionamentos ........................................................... 26 
3.1.6 Entidades, atributos e relacionamentos ........................................................... 31 
4 GESTÃO ESTRATÉGICA DE RECURSOS HUMANOS ...................................... 32 
5 CONCLUSÃO ........................................................................................................ 33 
REFERÊNCIAS ........................................................................................................ 34 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
7 
 
1 INTRODUÇÃO 
 
 
O objetivo do PIM VI é o de realizar um estudo fazendo um levantamento de 
um sistema de informação, de como podemos desenvolver um sistema de software 
competitivo para a empresa Nova Era Games e Informática, localizada na rua dos 
Timbiras, 239 – Loja 4 – Santa Ifigênia, São Paulo – SP e atuante na área de 
vídeo games e informática. Portanto, o tema do estudo do PIM VI será sobre: uma 
instituição (empresa Nova Era Games e Informática) do ramo de vendas de jogos 
eletrônicos e produtos geek que resolveu contratar uma empresa (PIM VI) para 
construir um sistema para controlar o estoque dos produtos e as vendas realizadas e 
entre os principais objetivos o sistema deverá realizar todos os cadastros, alterações, 
consultas e exclusões relacionados aos produtos que serão vendidos na loja, bem 
como os cadastros dos clientes e ainda deverá ser realizado o controle de acesso ao 
sistema com níveis de Login, onde o sistema será utilizado por atendentes, 
estoquistas e o supervisor da loja. Levando em consideração que todo acesso ao 
sistema é feito na loja por meio de login e senha e que o estoquista cadastra os 
produtos que serão vendidos na loja, os quais deverão ser divididos por categorias: 
jogos, acessórios e produtos geek. Os cadastros dos clientes devem possuir: código, 
RG, CPF, nome, data do cadastro, endereço, telefone, e-mail do cliente. Todos os 
produtos devem possuir: código de barras, nome do produto, categoria, fabricante, 
quantidade, valor do produto. 
Para os jogos e acessórios deve ser informado em qual plataforma serão 
utilizados e também qual o prazo de garantia do produto. A venda deverá possuir os 
dados do cliente e todos os produtos adquiridos. Deverá ser gerado um código único 
da venda, com a data da venda, o valor da venda, opções para pagamento 
(dinheiro/cartão), o status de pagamento e o status da venda. O atendente poderá 
excluir produtos da venda caso o cliente não queira mais adquiri-los. Apenas o 
supervisor da loja poderá excluir o produto da venda, devendo informar um usuário e 
senha válidos. O atendente poderá consultar os preços dos produtos caso o cliente 
solicite. A venda pode ser cancelada apenas pelo supervisor da loja, que deve 
informar usuário e senha válidos. No momento do cancelamento, o código da venda 
deve ser enviado para o sistema financeiro. 
8 
 
Para a realização do PIM VI iremos abordar as técnicas aprendidas através das 
disciplinas Análise de Sistemas Orientada a Objetos, Banco de Dados e Gestão 
Estratégica de Recursos Humanos (RH) utilizando a metodologia da pesquisa 
bibliográfica e pesquisa de campo. E em relação as disciplinas será analisado 
identificação dos casos de uso, elaboração do modelo de casos de uso, identificação 
dos relacionamentos de include, extend e generalização, demonstração de cada caso 
de uso com descrição de comportamento, do fluxo principal, fluxos alternativos e de 
exceção, pré e pós-condições, descrição dos requisitos não funcionais (requisitos de 
usabilidade), identificação e descrição do contexto de uso (usuários, tarefas e 
ambiente), descrição das regras de negócio, elaboração do diagrama de classes de 
análise (Boundary, Control, Entity), construção do Modelo Entidade de 
Relacionamento (MER). 
O avanço dos computadores é comprovado, ao longo dos anos, pelo aumento 
da capacidade dos processadores, da memória e da velocidade do mecanismo 
entrada/saída e esse avanço deve-se ao fato de que os componentes, também 
chamados de transistores, que compõem um processador foram diminuindo em 
tamanho com o passar do tempo (STALLINGS, 2003). Portanto, a realização do PIM 
VI é de extrema importância para o aprendizado e entendimento do aluno de que a 
área de hardware está em constante atualização e com isso a área de software 
também, devendo sempre estar reinventando-se e superando-se para acompanhar o 
mercado e desenvolver softwares competitivos com alto nível de qualidade e custo-
benefício para as empresas, como por exemplo a empresa Nova Era Games e 
Informática para qual vamos elaborar o estudo do PIM VI, para estarem se destacando 
e sempre saindo na frente em relação aos seus concorrentes de mercado. 
 
2 ANÁLISE DE SISTEMAS ORIENTADA A OBJETOS 
 
2.1 Introdução à análise de sistemas orientada a objetos 
 
A tecnologia de sistemas de informação é toda plataforma tecnológica que dá 
suporte ao processo de negócio, como infraestrutura de rede, servidores, 
computadores, sistemas operacionais, sistemas de software e todo sistema que gera 
e armazena informação pode ser considerado um sistema de informação, 
independentemente se utiliza tecnologia ou não (REZENDE, 2005). Sendo assim 
9 
 
podemos imaginar um sistema de informação que tem como objetivo controlar o 
processo de uma empresa que vende jogos eletrônicos e produtos e serviços de 
informática. 
Para apresentar um valor estratégico e competitivo à empresa esse sistema de 
informação deve considerar os itens para gerenciamento do sistema, o qual deverá 
realizar todos os cadastros, as alterações, as consultas e as exclusões relacionadas 
aos produtos que serão vendidos na loja, bem como os cadastros dos clientes e ainda 
deverá realizar o controle de acesso ao sistema com níveis de login. Alguns aspectos 
como os próximos itens devem ser considerados: todo acesso ao sistema é feito na 
loja por meio de login e senha; o estoquista cadastra os produtos que serão vendidos 
na loja, os quais deverão ser divididos por categorias: jogos, acessórios e produtos 
geek; os cadastros dos clientes devem possuir: código, RG, CPF, nome, data do 
cadastro, endereço, telefone e e-mail do cliente; todos os produtos devem possuir: 
código de barras, nome do produto, categoria, fabricante, quantidade e valor do 
produto. 
Para os jogos e os acessórios, devem ser informados em qual plataforma serão 
utilizados e qual o prazo de garantia que o produto possui; a venda deverá possuir os 
dados do cliente e todos os produtos adquiridos. Deverá ser gerado um código único 
da venda, com a data da venda, o valor da venda, opções para pagamento 
(dinheiro/cartão), o status de pagamento e o status da venda; o atendente poderá 
excluir produtos da venda caso o cliente não queira mais adquiri-los. Apenas o 
supervisor da loja poderá excluir o produto da venda,devendo informar um usuário e 
senha válidos; o atendente poderá consultar os preços dos produtos caso o cliente 
solicite e a venda pode ser cancelada apenas pelo supervisor da loja, que deve 
informar usuário e senha válidos. 
No momento do cancelamento, o código da venda deve ser enviado para o 
sistema financeiro. Deverão ser seguidos os itens e o relacionamento com as 
disciplinas, conforme a seguir: criar um cenário (com a situação problema); identificar 
as funções de negócio do sistema de controle de estoque e vendas de jogos 
eletrônicos, acessórios e produtos geek; pesquisar as soluções disponíveis no 
mercado e comparar as soluções disponíveis com a solução proposta; para cada 
função de negócio, definir os processos de negócio; para cada processo, identificar 
10 
 
as operações que poderão ser automatizadas; para essas operações automatizadas, 
identificar os casos de uso; elaborar o modelo de casos de uso; cada caso de uso 
deve ter uma descrição sucinta do seu comportamento, dos fluxos principais, 
alternativos, de exceção e pré e pós-condições; identificar relacionamentos de 
include, extend e generalização; descrever os requisitos não funcionais (e os 
requisitos de usabilidade); identificar e descrever o contexto de uso (usuários, tarefas 
e ambiente); descrever as regras de negócio; descrever o glossário do sistema; 
elaborar o diagrama de classes de análise (Boundary, Control, Entity); construir o 
modelo de dados (MER). 
Para fazer uma tomada de decisão sobre qual processo de desenvolvimento 
utilizar devemos pensar no problema a ser resolvido, porém qualquer que seja o 
problema, segundo Sommerville (2010), é essencial a existência de quatro 
macroatividades: 
1- Especificação de software: Fase na qual são definidas e especificadas as 
funcionalidades do software, seus requisitos e suas regras de execução. 
2- Projeto e implementação de software: Fase na qual os requisitos são 
transformados em sistema de software. Quando são projetados e 
construídos os componentes de software e suas integrações. 
3- Validação de software: Fase na qual o software é validado frente aos 
requisitos especificados. 
4- Evolução de software: Fase na qual são traçadas estratégias para que o 
sistema de software possa ser mantido e evoluído na medida. 
 
Para o processo de desenvolvimento de software cada atividade possui: 
1- Pré e pós-condições: qual é o cenário pré e pós-execução de uma atividade. 
2- Papéis: quem é o responsável pela execução da tarefa. 
3- Produtos: também chamados de artefatos, é o que é produzido como saída 
de uma determinada atividade. 
 
Muitos são os modelos de processos aplicados a um projeto de 
desenvolvimento, como o modelo cascata e o modelo iterativo, cada um com as suas 
particularidades. Porém, todos possuem atividades fundamentais como: especificação 
de software, projeto e implementação de software, validação de software e evolução 
11 
 
de software e o indivíduo tem parte indispensável em qualquer que seja o modelo 
adotado. Os indivíduos que fazem parte de uma equipe de projeto trabalham em 
diversas funções e são responsáveis por atividades e produção de resultados. 
Algumas das funções em um projeto são: gerente de projetos, analista de sistemas, 
projetista, arquiteto, desenvolvedor, analista de qualidade e, principalmente, cliente. 
 
2.2 Casos de uso 
 
A modelagem de caso de uso combina método e ferramenta e deve cumprir 
com os objetivos a serem atingidos na fase de análise de requisitos, onde ressalta as 
exigências solicitadas, pontuando as características operacionais do software, 
especificando suas limitações e suas relações com outros sistemas para combinar 
com um padrão teórico do problema (PFLEEGER, 2004). 
Para a produção de um sistema de software competitivo para a empresa Nova 
Era Games e Informática no ramo de vendas de jogos eletrônicos, acessórios e 
produtos geek, visualizamos as necessidades do cliente que são principalmente as de 
controle do estoque e gerenciamento das vendas para atingir um alto nível de 
qualidade e custo-benefício. O controle de acesso ao sistema será com níveis de 
Login e senha, onde o sistema será utilizado por atendentes, estoquistas e o 
supervisor da loja para controlar o estoque dos produtos e as vendas realizadas e 
entre os principais objetivos o sistema deverá realizar todos os cadastros, alterações, 
consultas e exclusões relacionados aos produtos que serão vendidos na loja, bem 
como os cadastros dos clientes. 
O atendente realiza os cadastros dos clientes que devem possuir: código, RG, 
CPF, nome, data do cadastro, endereço, telefone e e-mail do cliente; e também realiza 
as vendas onde deverá ser gerado um código único da venda, com a data da venda, 
o valor da venda, opções para pagamento (dinheiro/cartão), o status de pagamento e 
o status da venda e poderá excluir produtos da venda caso o cliente não queira mais 
adquiri-los e também terá acesso ao cadastro de clientes salvando, alterando, 
excluindo e consultando os dados dos clientes. Para os jogos e os acessórios, devem 
ser informados em qual plataforma serão utilizados e qual o prazo de garantia que o 
produto possui; a venda deverá possuir os dados do cliente e todos os produtos 
12 
 
adquiridos. O atendente poderá consultar os preços dos produtos caso o cliente 
solicite. 
O estoquista cadastra os produtos que serão vendidos na loja podendo salvar, 
alterar, excluir e consultar os dados dos produtos os quais deverão ser divididos por 
categorias: jogos, acessórios e produtos geek; todos os produtos devem possuir: 
código de barras, nome do produto, categoria, fabricante, quantidade e valor do 
produto. 
O supervisor da loja, e apenas ele, poderá excluir o produto da venda, devendo 
informar um usuário e senha válidos e no momento do cancelamento, o código da 
venda deve ser enviado para o sistema financeiro. 
Ressaltando que essa teoria pode ser entendida como uma “estrutura real da 
atualidade” para solucionar o problema. Sendo que, esses modelos são utilizados na 
comunicação entre clientes, arquiteto, gerentes de projeto e desenvolvedores. Modelo 
de casos de uso é uma apresentação das funções dos componentes da parte de fora 
do sistema que harmonizam com ele” (BEZERRA, 2006). 
Portanto, identificamos os seguintes casos de uso: 
● COD 01 - Cadastrar produto; 
● COD 02 - Alterar produto; 
● COD 03 - Excluir produto; 
● COD 04 - Consultar produto; 
● COD 05 - Cadastrar cliente; 
● COD 06- Alterar cliente; 
● COD 07 - Excluir cliente; 
● COD 08- Efetuar login com nível de acesso; 
● COD 09 - Consultar cliente; 
● COD 10- Consultar preço; 
● COD 11 - Efetuar venda; 
● COD 12 - Cancelar venda. 
 
2.3 Modelo de casos de uso 
 
13 
 
Para elaborar e demonstrar a aplicabilidade dos casos de uso, criamos um 
diagrama conforme demonstrado na Figura 1, com os usuários envolvidos e a 
possível existência de integração com sistemas externos. O diagrama demonstra as 
interações entre o atendente, estoquista, supervisor e cliente e a interação destes com 
o sistema de cadastro. 
Diagrama de casos de uso é um diagrama da UML que tem por objetivo 
mostrar, a partir de um ponto de vista estático, o conjunto de casos de uso, 
atores e seus relacionamentos. Podendo acrescentar e fazer uso da inclusão 
que significa que o comportamento definido no caso de uso de inclusão é 
incorporado ao comportamento do caso de uso base, ou seja, para que este 
seja executado, obrigatoriamente o caso de uso de inclusão também deverá 
ser executado, da extensão que significa que o comportamento definido no 
caso de uso de extensão pode ou não ser incorporado ao comportamento do 
caso de uso base, ou seja, para que este seja executado, o caso de uso de 
extensão pode ou não ser executado e da herança que significa que o caso 
de uso filho herda o comportamento e o significado do caso de uso pai, 
acrescentando ou mudando seu comportamento,onde diferentemente dos 
casos de uso, atores possuem apenas um tipo de relacionamento: herança. 
Entretanto, no relacionamento entre atores, o ator filho herda o 
comportamento e o significado do ator pai, acrescentando ou mudando seu 
comportamento, ou seja, o ator filho pode executar todos os casos de uso do 
ator pai e mais aqueles que apenas ele executa (BOOCH; JACOBSON; 
RUMBAUGH, 2006). 
 
Figura 1. Ilustração do Sistema de Cadastro 
 
 
14 
 
 
Fonte: elaborado pela autora. 
 
2.3.1 Cadastrar produto 
 
 
A Tabela 1 descreve o caso de uso COD 01 - Cadastrar produto 
informando às normas que o ator (estoquista) deve seguir para cadastrar os novos 
produtos no sistema e identificar os já cadastrados. 
Tabela 1- Descrição do caso de uso COD 01 - Cadastrar produto 
Descrição de caso de uso COD 01 
Identificação: Cadastrar produto. 
Escopo: Efetuar o cadastro de novos produtos. 
Descrição do 
proposito: 
Caso de uso que descreve os passos para o cadastro de 
novos produtos. 
Ator primário: Estoquista. 
Interessados: Atendente e Supervisor. 
15 
 
Pré-condições: Estar logado no sistema como estoquista ou supervisor. 
Pós-condições: O produto é cadastrado. 
Fluxo normal 
16 
 
 
 
 
1. O sistema exibe a tela principal. 
2. O usuário seleciona a opção “Cadastro de Produto”. 
3. O sistema exibe a tela para o cadastro de novo produto, também para 
“localizar produto” e “excluir produto”. 
4. O usuário informa os dados e confirma o cadastro do produto. 
5. O sistema atualiza o estoque, exibe a mensagem “produto cadastrado com 
sucesso” e retorna a tela principal. 
 
 
 
Itens relacionados 
 
● COD 02 - Alterar produto; 
● COD 03 - Excluir produto; 
● COD 04 - Consultar produto; 
● COD 08 - Efetuar login com nível de acesso. 
 
 
Fonte: Elaborada pela autora 
 
Figura 2 – Ilustração da tela cadastro do produto 
17 
 
 
Fonte: Elaborada pela autora 
 
 
 
2.3.2 Cadastro de Cliente 
 
A Tabela 2 descreve o caso de uso COD 05 - Cadastrar cliente 
informando às normas que o ator (atendente) deve seguir para cadastrar os novos 
clientes no sistema e identificar os já cadastrados. 
Tabela 2- Descrição do caso de uso COD 05 - Cadastrar cliente 
Descrição de caso de uso COD-02 
Identificação: Cadastrar cliente 
Escopo: Efetuar o cadastro de clientes. 
Descrição do 
proposito: 
Caso de uso que descreve os passos para o usuário cadastrar 
novo cliente. 
Ator primário: Atendente 
Interessados: Atendente e supervisor. 
Pré-condições: Estar logado no Sistema como atentente. 
18 
 
Pós-condições: Após a confirmação do cadastro, o sistema atualiza o banco de 
dados e retorna a tela principal. 
Fluxo normal 
1. O sistema exibe a tela principal. 
2. Usuário seleciona a opção “Cadastrar Cliente”. 
3. O Sistema apresenta a tela de cadastro dos dados pessoais do cliente 
(Código, RG, CPF, nome, data do cadastro, endereço, telefone e e-
mail). 
4. O Usuário preenche todos os campos, obrigatórios e clica em “Gravar”. 
5. O sistema valida o cadastro e envia para o banco de dados. 
6. O sistema retorna a tela principal. 
 
Itens relacionados 
 
● COD 06- Alterar cliente; 
● COD 07 - Excluir cliente; 
● COD 09 - Consultar cliente; 
● COD 08- Efetuar login com nível de acesso. 
 
Fonte: Elaborada pela autora. 
 
 
 
 
19 
 
 
Fonte: Elaborada pela autora. 
 
Figura 4. Tela Cadastro do Cliente 
 
Fonte: Elaborada pela autora. 
 
2.3.3 Efetuar venda 
Na Tabela 3 estão descritas as funções para o ator (atendente) COD 11 - 
Efetuar venda, onde se faz a introdução ou verificação dos dados no sistema. 
Tabela 3- Descrição do caso de uso COD 11 - Efetuar venda 
20 
 
Descrição de caso de uso COD-11 
Identificação: Realizar venda. 
Escopo: Efetuar a venda. 
Descrição do 
proposito: 
Caso de uso que descreve os passos para o usuário registrar 
vendas. 
Ator primário: Atendente 
Interessados: Atendente e supervisor. 
Pré-condições: Estar logado no Sistema como atendente e supervisor. 
Pós-condições: Após a confirmação do pagamento o sistema emite a nota e 
volta ao estado inicial. 
Fluxo normal 
 
1. No menu principal do sistema, o usuário escolhe a opção “Vendas”. 
 
2. O sistema apresenta a tela de vendas. 
 
3. O usuário busca o produto por tipo e nome. 
 
4. O sistema exibe a quantidade do produto em estoque. 
 
5. O usuário seleciona o produto, a quantidade e os dados do cliente. 
 
6. O sistema apresenta a tela de vendas com o valor dos produtos. 
 
7. O usuário clica no botão “confirmar venda”. 
 
8. O sistema exibe a tela para a confirmação da forma de pagamento. 
9. O sistema finaliza a venda e retorna a tela principal. 
 
 
21 
 
 
Requisitos relacionados 
 
● COD 03 - Excluir produto; 
● COD 12 - Cancelar venda; 
● COD 09 - Consultar cliente; 
● COD 10 - Consultar preço; 
● COD 08 - Efetuar login com nível de acesso. 
 
Fonte: Elaborada pela autora. 
 
Figura 5. Tela de Venda 
 
 
Fonte: Elaborada pela autora. 
 
2.4 Normas de uso 
 
22 
 
Para a utilização do sistema de software estipulamos as seguintes normativas 
de uso: 
 
2.4.1 Login 
 
● Somente usuários pré-cadastrados (atendente, estoquista ou supervisor) 
poderão ter acesso ao sistema; 
● Somente funcionários (atendente, estoquista ou supervisor) terão acesso direto 
ao sistema; 
● Somente usuários com função de Supervisor poderão cadastrar e excluir 
usuários. 
 
2.4.2 Cadastrar usuário 
 
● Deve ser feito o cadastro de todos os clientes para efetuar a compra; 
● Somente usuários com função de Atendente/Supervisor poderão cadastrar 
clientes; 
● Somente usuários com função de Supervisor poderão alterar e excluir cadastro 
de clientes. 
 
2.4.3 Cadastrar produtos 
 
● Somente usuários com função de Estoquista/Supervisor 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. 
 
2.4.4 Cancelar vendas 
 
23 
 
● Somente usuários com função de Supervisor poderão cancelar uma venda. 
 
2.5 Contexto de uso 
 
2.5.1 Usuários e tarefas 
 
 Os funcionários (usuários) que manuseiam o software ficam localizados em 
setores diferentes e exercem diferentes funções, agrupando e decretando para cada 
um, um formato destacado e arranjado de relação diante do sistema de software. Cada 
funcionário precisa de um modelo particular de ambiente e aplicação, articulando com 
a facilidade e ação enquanto se faz a manipulação do software. 
Temos como usuários, os funcionários atendentes, que precisam ter uma 
rápida resposta durante o uso contendo todas as informações sobre os produtos para 
que informe com agilidade ao cliente para facilitar e fazer com que o cliente realize a 
compra. Já os estoquistas precisam de uma pesquisa rápida para visualização e 
cadastramento dos produtos que a loja oferece. E os supervisores precisam de 
confiança em todo o sistema para atender os clientes da melhor forma possível. 
 
2.5.2 Ambiente 
 
 Dentro do ambiente, existe um serviço de banco de dados, localizados em um 
servidor isolado dos computadores de atendimento, empregando um maior 
processamento e aproximação ao disco rígido. 
Sendo instalado de forma completamente apropriada em um ambiente com 
sistema de refrigeração e segurança. 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. 
24 
 
Com acesso aberto a usuários que tem r sobre o sistema, é possível acessar 
de diferentes máquinas sem interferir nas configurações pré estabelecidas em cada 
usuário. 
 
2.6 Requisitos funcionais 
 
O desempenho desejado de um sistema de softwareé descrito pelos 
Requisitos funcionais (RF), demonstrando que o sistema faz e não faz 
(SOMMERVILLE, 2010). 
A descrição da interação entre o sistema de software e o seu ambiente define 
requisitos funcionais Pfleeger (2004). E assim, como indispensável componente do 
ambiente do software é citado o usuário. 
 
2.7 Requisitos não funcionais 
 
Requisitos não funcionais (RNF) demonstram limitação sobre as funções 
cedidas pelo sistema de software e os requisitos funcionais são falhos para pontuar o 
sistema de software. É preciso pontuar outros dados: qualidades do sistema e do 
ambiente do sistema, geralmente especificado como requisitos não funcionais e para 
determinação de requisitos não funcionais existem muitas propostas, como por 
exemplo, a representada na Figura 6 a seguir (SOMMERVILLE, 2010). 
Figura 6. Ilustração do diagrama de requisitos não funcionais 
 
25 
 
 
 
Fonte: (Versolatto, 2015). 
 
A norma ISO/IEC 25010:2011, fora a proposta de Sommerville (2010), também 
fala 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. E quando 
utilizamos requisitos não funcionais essas características sempre são denominadas 
como atributos de qualidade. A Figura 7 mostra a estrutura hierárquica dos atributos 
de qualidade, quanto a sua classificação, proposta pela norma ISO 25010. 
 
Figura 7. Ilustração do diagrama de atributos de qualidade 
 
26 
 
 
 
Fonte: (Versolatto, 2015). 
 
 
2.8 Requisitos não funcionais de usabilidade 
 
 Neste trabalho, apresentamos os requisitos não funcionais de usabilidade do 
sistema de software desenvolvido que possui clara aplicação, com inclusão 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: 
 
● 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. 
27 
 
● 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). 
● 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. 
● Entendimento: Um usuário deve entender as mensagens e os alertas do 
sistema e o que o sistema faz. 
● 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. 
 
3 BANCO DE DADOS 
 
3.1 Diagrama de classes de análise 
28 
 
 
3.1.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, 2006). Pode ser 
definido também como a representação das classes, seus atributos, métodos e o 
relacionamento entre essas classes (VERSOLATTO, 2015). 
 
3.1.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. 
 
3.1.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. 
29 
 
 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. 
 
3.1.4 Elaboração do diagrama de classes de análise 
 
 A Figura 8 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 8 – Ilustração do diagrama de classes de análise 
30 
 
 
Fonte: Elaborado pela autora. 
 
3.1.5 Modelo Entidade-Relacionamento (MER) 
 
 O Modelo Entidade-Relacionamento (MER) é um tipo de processo que 
descreve os objetos (entidades), suas características (atributos) e como se relacionam 
(relacionamento) e é considerado um modelo de top, que tem como objetivo 
representar um arranjo de dados mais perto do mundo real, e é um modelo 
desenvolvido por Peter P. Chen com o intuito de demonstrar as estruturas de dados 
de forma mais próxima do mundo real dos negócios. Sendo assim, podemos entender 
que o modelo reproduz aspectos abstratos que a estrutura possuirá no banco de 
dados da aplicação (PINTO, 2020). 
31 
 
3.1.6 Entidades, atributos e relacionamentos 
 
 A entidade é a principal meta da Entidade-Relacionamento, pois é por meio 
dela que são representados os tópicos de fatos do mundo real e sejam eles concretos 
ou abstratos, como empregados, departamentos, despesas podem ser classificados 
em entidade física e entidade lógica. As entidades físicas são existentes e visíveis no 
mundo real e as entidades lógicas existem em decorrência da ação com entidades 
físicas que fazem sentido dentro de um certo domínio de negócios, mas no mundo 
real não são objetos físicos (PINTO, 2020). E podemos classificar as entidades como: 
fortes, fracas e associativa. A entidades fortes: são aquelas que existem 
independentemente de outras entidades. Em nosso sistema de vendas por exemplo, 
a entidadeproduto existe sem que outra entidade exista. As entidades fracas: 
diferente das entidades fortes, as fracas dependem que outras entidades existam, pois 
ela só não faz sentido. A exemplo, a entidade do nosso sistema de vendas depende 
da entidade produto, sendo assim uma venda sem itens não faz sentido. As 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. 
Os 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). O 
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. Nos relacionamentos um para um (1:1), cada uma das entidades se 
refere obrigatoriamente apenas uma unidade da outra. Nos relacionamentos um para 
muitos (1:n ou 1:n) uma das entidades pode referenciar várias unidades da outra. E 
nos relacionamentos muitos para muitos (n:n) cada entidade, de ambos os lados, pode 
32 
 
referenciar múltiplas unidades da outra. A Figura 9 ilustra a representação gráfica do 
Modelo Entidade-Relacionamento (MER). 
 
Figura 9 – Ilustração do Modelo de Entidade-Relacionamento (MER) 
 
 
Fonte: Elaborada pela autora. 
 
Figura 9 – Ilustração do Diagrama Entidade-Relacionamento (DER) 
 
4 GESTÃO ESTRATÉGICA DE RECURSOS HUMANOS 
 
A missão do RH dentro da empresa PIM VI é a de selecionar os técnicos para 
desenvolvimento do software especifico que a empresa Nova Era Games e 
Informática contratou, fazer o recrutamento, a seleção a entrevista, os testes de 
seleção e capacitação dos futuros colaboradores. Pelo quadro de funcionários que 
33 
 
tem na empresa PIM VI, deve fazer uma avaliação bem detalhada sobre o potencial 
de conhecimento, e qual os salários, idades. Entrevistando os funcionários do PIM VI 
ficou constatado que os funcionários estão dispostos a enfrentarem o desafio de fazer 
parte da do projeto nesta nova adaptação e as novas tecnologias que serão implantas 
na empresa Nova Era Games e Informática, por isto foi oferecido capacitação para 
eles. Estes contratados teriam 6 meses para aprender como funciona o novo sistema. 
Aos demais funcionários que não se adaptarem ao novo sistema seria dado à 
oportunidade de demissão voluntaria onde eles seriam demitidos com alguns 
benefícios, e no período de três meses estes estabelecidos pela empresa teriam a 
responsabilidade de garantir o funcionamento do sistema. Ao todo a empresa 
necessita de 5 funcionários técnicos em desenvolvimento de sistemas. Foi-nos 
envidando muitos currículos e tivemos de escolher os que mais se adaptam as 
necessidades da empresa. A face mais difícil era fazer uma proposta salarial, como 
esse processo e um pouco mais demorado, pois teríamos de oferecer os salários que 
estão em nosso escopo e tentar superar propostas altas e com benefícios. As 
entrevistas com os candidatos foram essenciais, pois assim pode-se verificar as 
necessidades pessoais e desejos de cada um. Definido o grupo com os novos 
funcionários temos agora três meses de preparação para o trabalho. Nesta nova parte 
do projeto será definido que tipo de organização teria para tratar. Inicialmente esses 
novos colaboradores ganharam cursos nas áreas que atuariam, mesmo que eles já 
tivessem esses conhecimentos, e com isso iria igualar os conhecimentos a um nível 
mínimo e promover uma interação entre os colaboradores. A próxima missão era 
documentar todos os passos desde a criação do projeto até a implantação, para o 
caso de haver a necessidade de fazer alguma revisão e saber como proceder. 
 
5 CONCLUSÃO 
 
O objetivo do PIM VI foi o de um estudo fazendo um levantamento de um 
sistema de informação, de como podemos desenvolver um sistema de software 
competitivo para a empresa Nova Era Games e Informática, atuante na área de 
vídeo games e informática com o objetivo de poder realizar cadastro de novos 
usuários e clientes, salvado seus dados em um banco de dados. Para isso foi 
34 
 
realizado o levantamento e análise de requisitos junto ao cliente, para saber quais 
suas necessidades para a realização do projeto. Um dos principais obstáculos foi o 
fato de se ter níveis de acesso diferentes para cada tipo de usuário, assim restringindo 
o acesso não autorizado de determinados dados. 
Para definir a estrutura do banco de dados foi utilizado o Modelo Entidade-
Relacional (MER) e apresentado o diagrama de classes de análise, com este 
diagrama foi possível modelar de forma mais precisa o software do cliente e os dados 
a serem armazenados. Portanto, pudemos observar que a parte mais importante do 
PIM VI foi a de descrever as regras de negócio, onde controlamos o estoque e 
gerenciamos as vendas da empresa para qual desenvolvemos um sistema de 
software competitivo, atingindo o alto nível de qualidade e custo-benefício esperados, 
e assim fazendo com que a empresa esteja na frente de seus concorrentes de 
mercado. 
 
REFERÊNCIAS 
 
BEZERRA, E. Princípios de análise e projeto de sistemas com UML: um guia prático 
para modelagem de sistemas orientados a objetos através da linguagem de 
modelagem unificada. Rio de Janeiro: Campus, 2006. 
 
BOOCH, G.; JACOBSON, I.; RUMBAUGH, J. UML: guia do usuário. 2. ed. Rio de 
Janeiro: Campus, 2006. 
 
PFLEEGER, S. L. Engenharia de Software: teoria e prática. 2. ed. São Paulo: Prentice 
Hall, 2004. 
 
PINTO, Gisele Lopes Batista. Administração de banco de dados. São Paulo: Editora 
Sol, 2020. 
 
REZENDE, A. D. Engenharia de Software e sistemas de informação. 3. ed. Rio de 
Janeiro: Brasport, 2005. 
35 
 
 
SOMMERVILLE, I. Engenharia de Software. São Paulo: Pearson, 2010. 
 
STALLINGS, W. Arquitetura e Organização de Computadores. São Paulo: Prentice 
Hall, 2003. 
 
 
 
 
 
 
 
 
 
 
 
	Fonte: elaborado pela autora.