PIM VI Gustavo Maia

Prévia do material em texto

UNIP - UNIVERSIDADE PAULISTA 
 
Gustavo Oliveira Maia - R.A. 0561126 
Levantamento e análise de requisitos para sistema de loja Geek 
Projeto integrado multidisciplinar VI(PIM VI) 
 
São Paulo 
2021 
 
 
Gustavo Oliveira Maia - R.A. 0561126 
 
Levantamento e análise de requisitos para sistema de loja Geek 
Projeto integrado multidisciplinar VI(PIM VI) 
Trabalho apresentado no curso de tecnologia 
em análise e desenvolvimento de sistemas da 
Universidade Paulista – UNIP, polo Tucuruvi, 
para fins de avaliação. 
 
 
 
 
São Paulo 
2021
2 
 
 
Resumo 
 
O presente projeto integrado multidisciplinar que está inserido no programa 
pedagógico dos cursos superiores de tecnologia da Universidade Paulista, 
consiste na elaboração de levantamento e a análise de requisitos de um sistema 
para empresa destinada à venda de jogos eletrônicos, acessórios e produtos geek, 
utilizando técnicas aprendidas. A elaboração será baseada conforme conhecimentos 
adquiridos nas disciplinas de: Análise de Sistemas Orientadas a Objetos; Banco 
de Dados e Gestão Estratégica de RH. Com avanço da tecnologia as pequenas 
tarefas gerenciadas para controle de vendas são manipuladas pelas planilhas 
do Excel, tendo vista a aderência a um processo mais rigoroso para melhoria do 
atendimento ao cliente, a empresa optou pelo desenvolvimento de um software de 
controle e gerenciamento de vendas, solicitando o Levantamento e a Análise de 
requisitos, para que seja organizados os cadastros, alterações, consultas e 
exclusões, o sistema será utilizado por atendentes, estoquistas e o supervisor da 
loja. 
Palavras-chave: Sistema, loja geek, requisitos 
 
 
 
Abstract 
 
The present integrated multidisciplinary project that is not included in the 
pedagogical program of higher technology courses at the Universidade Paulista, 
consists of the preparation of a Survey an d the Analysis of system requirements for 
a company destined to the sale of electronic games, accessories and geek 
products, used Of learned techniques. The elaboration will be based on the knowledge 
acquired in the disciplines of: Analysis of Object Oriented Systems; Database; 
Strategic HR Management. With the advancement of technology today, how small 
tasks managed to control sales are handled by Excel spreadsheets, having a 
little more stringent to improve customer service, a company choosed for the 
development of software for control and management of sales, requesting the 
Survey and Requirements Analysis of a system, so that it is organized in the 
3 
 
 
records, changes, consultations and exclusions, or the system will be used by 
solicitors, stockists and store supervisor. 
Keywords: System, geek, requirements 
4 
 
 
Sumário 
1. Introdução ....................................................................................................... 5 
2. O LEVANTAMENTO E A ANÁLISE DE REQUISITOS DE UM SISTEMA ..... 6 
3. conclusão ..................................................................................................... 19 
REFERÊNCIAS ......................................................................................................... 20 
 
 
5 
 
 
1. INTRODUÇÃO 
O Projeto Integrado Multidisciplinar VI, é um trabalho que consiste em 
apresentar todas as disciplinas estudadas no bimestre. A princípio o presente 
trabalho visa em descrever toda prática que envolva a Análise e Desenvolvimento 
de Sistemas dentro do levantamento e análise de requisição de um sistema, na 
visão prática conforme o aprendizado dos livros, sites e em tele aulas no 
decurso do atual período. Mediante dessas fontes de informações obtidas acima, 
será apresentado um levantamento e análise de requisição de um sistema e 
abordadas pelas disciplinas de: Análise de Sistemas Orientadas a Objetos; 
Banco de Dados; Gestão Estratégica de RH . E para que tenha a melhor 
compreensão foi elaborado um Levantamento e a Análise de requisitos de um 
sistema para empresa destinada à venda de jogos eletrônicos, acessórios e 
produtos geek. Onde o módulo de acesso facilitará aos clientes, usuários portadores 
de deficiências, e o gerenciamento do sistema nos cadastros, alterações, 
consultas e exclusões, realizará por níveis de login d os atendentes, estoquistas 
e o supervisor da loja. Apesar a empresa possuir o grau de raridade e disponibilidade 
da plataforma de desenvolvimento dos jogos, não impede o trabalho de qualidade 
de software, pois o foco é gerenciar as vendas efetuadas ao cliente. Será 
abordado os casos de uso e seus relacionamentos de funcionamentos em detalhes e 
a justificativa da escolha do sistema , o protótipo de telas com alta fidelidade 
para os requisitos funcionais, definido como funcionamento de cada tipo de 
entrada de dados, processamento ou saída de informação. Os dados construídos 
serão revisados conforme modelo (MER) para verificação das chaves primarias da 
tabela. 
 
6 
 
 
2. O LEVANTAMENTO E A ANÁLISE DE REQUISITOS DE UM SISTEMA 
 
Para iniciar o levantamento e a análise de requisitos de um sistema, foi 
necessário adquirir as práticas para captar e mapear necessidades das 
organizações em um mercado mais competitivos, de forma eficiente no futuro 
do projeto de software, e utilizado o paradigma da orientação a objetos, por ser 
mais difundido no mercado, no padrão da evolução voltadas para segurança e 
reaproveitamento de código, no desenvolvimento de aplicação moderna. 
Considerada a engenharia de requisitos como fase fundamental dentro do projeto 
de desenvolvimento, por especificar, implementar, validar, e implantar o software 
, a importância no relacionamento de atividade com os clientes e usuários finais 
para descobrir o problema a ser resolvido , os serviços do sistema, o 
desempenho, restrições de hardware e outras informações. Com esse novo mercado 
a competição visa para empresa obter foco mais completa , na abordagem nas 
atividades, interação profissional, relação com outra organização, utilização e 
funcionamento dos recursos físicos e sistemas computacional. Para entendermos 
melhor essas abordagens técnicas são expostas através da modelagem de 
processos de negócio ou diagramas de processos, utilizada diagramas da UML 
(Unifield Modeling Language) como ferramenta de apoio, para representar, model ar 
o sistema de software, compondo atividades das áreas de negócios ou da 
empresa, proporcionando a otimização no processo atual. Neste caso conforme a 
evolução do sistema e paradigma da orientação mais difundido no mercado, cabe 
à nossa Fábrica de software PIMVI para nosso cliente , a loja de venda de 
jogos eletrônicos, acessórios e produtos geek, e vem representado pela nossa 
instituição para a elaboração do levantamento de requisitos do sistema desktop. 
Apesar da empresa possuir produtos no grau de raridade e disponibilidade da 
plataforma de desenvolvimento dos jogos, o foco é gerenciar as vendas efetuadas ao 
cliente. 
2.1 REQUISITOS DE UM SOFTWARE 
Os requisitos de um software são as condições minúsculas que o mesmo 
deve atender a fim de solucionar os problemas e, dessa forma, satisfazerem 
as necessidades do cliente contratante. No caso de um software por de manda, 
produto deste projeto, o atendimento destes requisitos e os de qualidade é 
7 
 
 
o principal foco desta empresa no desenvolvimento dosoftware. Para tanto, 
é necessário definir e documentar os requisitos funcionais, não funcionais e os 
de negócios que o software deve atender. 
 
2.2 REQUISITOS FUNCIONAIS 
Os requisitos funcionais são as aplicações que o software deve possuir 
no intuito de atender a demanda do cliente. É a razão de ser de um software. No 
nosso projeto, o software deve atender, a título de requisitos funcionais as 
seguintes demandas: 
• Possuir um Banco de Dados no qual serão elencados todos cadastros, 
alterações, consultas e as exclusões dos produtos vendidos na loja, e os 
cadastros dos clientes, controle de acesso ao sistema com níveis de login; 
• Gerar um código único para cada item, de forma que um produto não 
possa ser emprestado para mais de um usuário ao mesmo tempo; 
• Funcionalidade para tornar indisponível qualquer produto que apresentar 
defeito ou estiver em manutenção; 
• Possuir outro Banco de Dados ao qual serão vinculado s todos os 
usuários do sistema, atendentes, estoquistas e o supervisor da loja e etc 
 
2.3 REQUISITOS NÃO FUNCIONAIS 
Os requisitos não funcionais são aqueles intrínsecos ao funcionamento do 
software em sua relação com o sistema e o hardware. Dessa forma, os requisitos 
não funcionais a serem verificados são: 
• O espaço que este ocupará na memória quando não executado (kbytes) 
e quando executado (RAM); 
• Sua velocidade está atrelada ao tempo de utilização da tela , ou a 
transações processadas por segundo (CODIFICAR, 2017); 
• A facilidade de utilização poder ser medida pelo número de janelas ou 
tempo de treino (CODIFICAR, 2017); 
• A confiabilidade é inerente ao tempo médio de utilização antes do sistema 
falhar, à disponibilidade ou à taxa de ocorrências de falhas (CODIFICAR, 
2017). 
 
 
 
 
 
 
 
8 
 
 
2.4 REQUISITOS DE NEGÓCIO 
Os requisitos de negócio são aqueles que definem a forma como loja de venda 
de jogos eletrônicos, pre tende atingir os objetivos estratég icos do negócio. Dessa 
forma, os requisitos a serem verificados são: 
• Registros; 
• Relatórios; 
• Controle de fluxo; 
• Consultas; 
• Cadastros; 
 
2.4.1 REGRAS DE NEGÓCIO 
 
Segundo Dextra, 2013, as Regras de Negócio definem a forma de 
como a instituição deve fazer negócio, refletindo a política interna, 
regras básicas de conduta, etc. ou seja, o estipula o comportamento 
ao qual os usuários são submetidos dentro do negócio. Restrições, 
validações, condições e exceções do processo são exemplos clássicos 
de regras de negócio. 
 
2.4.2 INTERFACE DAS REGRAS DE NEGÓCIO 
 
A interface das regras de negócio é o ambiente no qual os usuários 
estão submetidos a tais regras. Neste caso , as atividades nas quais serão 
empregados os produtos poderão ser classificadas conforme o grau de 
importância ou visibilidade e assistência prevista para esta. Desta forma, evita o 
emprego do erro de busca de informações. 
Assim sendo, na tabela abaixo, será especificada a regra de negócio para cota 
o grau de importância de cada atividade: 
 
3 Qualidade 
Os modelos de qual idade são ferramentas poderosas que auxiliam na criação 
dos fundamentos de uma empresa se software, a fim de torna-la apta a 
evoluir à medida que atinge os mais elevados graus de maturidade e, dessa 
9 
 
 
forma, se consolidarem no mercado como empresas que gozem de pleno 
reconhecimento, confiabilidade e renome. 
 
3.1 METODOLOGIA DE QUALIDADE 
Por se tratar de uma norma nacional, a qual torna o processo de 
melhoria de qualidade adaptada à realidade local, e por se tratar de um projeto 
feito por demanda para uma instituição nacional, o modelo de qualidade a ser 
empregado para estipular o grau de maturidade da empresa e os testes a 
serem realizados no software será o de Melhoria de Processo de Software 
Brasileiro (MPS.BR). Segundo RIBEIRO, 2015, o modelo MPS.BR está 
estruturado em 4 componentes (modelos de referência), 7 níveis de maturidade 
e 19 processos, distribuídos em seus respectivos níveis. Os componentes são 
modelos de referência para desenvolvimento, aquisição e avaliação do 
processo de software e são divididos em Modelo de referência para 
software, Modelo de referência para serviços, Método de avaliação e Modelo 
de negócios. Os níveis de maturidade compõem um indicador de evolução 
da qualidade e permite definir o grau de maturidade o qual se encontra o 
modelo de qualidade da empresa. Os processos são os requisitos que o 
modelo precisa cumprir para atingir os níveis de maturidade imediatamente 
superior. Dessa forma, os processos estão divididos por níveis de maturidade 
conforme o quadro abaixo: 
10 
 
 
 
4 ORIENTAÇÃO AO OBJETO 
4.1 OBJETO 
Um objeto é um elemento computacional que representa, no domínio da 
solução, alguma entidade (abstrata ou concreta) do domínio de interesse do 
problema sob análise. Objetos similares são agrupados em classes. No paradigma 
de orientação a objetos, tudo pode ser potencialmente representado como um 
objeto. Sob o ponto de vista da programação, um objeto não é muito diferente 
de uma variável no paradigma de programação convencional. Por exemplo, quando 
se define uma variável do tipo int em C ou em Java, essa variável tem: 
• Um espaço em memória para registrar o seu estado atual (um valor); 
• Um conjunto de operações associadas que podem ser aplicadas a ela, através 
dos operadores definidos na linguagem que podem ser aplicados a valores 
inteiros (soma, subtração, inversão de sinal, multiplicação, divisão inteira, resto 
da divisão inteira, incremento, decremento). 
 
11 
 
 
Da mesma forma, quando se cria um objeto, esse objeto adquire um 
espaço em memória para armazenar seu estado (o s valores de seu conjunto 
de atributos, definidos pela classe) e um conjunto de operações que podem ser 
aplicadas ao objeto (o conjunto de métodos definidos pela classe). Um programa 
orientado a objetos é composto por um conjunto de objetos que interagem 
através de "trocas de mensagens". Na prática, essa troca de mensagem traduz-
se na invocação de métodos entre objetos. 
 
 
4.2 CLASSES 
O desenvolvimento de classes é o resultado da abstração. Uma vez definidos 
os devidos escopos, teremos condições de pensar em termos de classes. É fácil 
notar que muitos objetos possuem características estruturais semelhantes, 
embora todo objeto seja único. Um bom exemplo disso são os objetos que 
recebem a denominação genérica de “carro”. Todos os carros possuem uma 
mesma estrutura, ou seja, todos os objetos carro implementam os mesmos 
métodos e mantém informações sobre os mesmos atributos. O fato de que 
cada objeto mantém seus próprios atributos de forma encapsulada confere 
uma identidade única a cada objeto e também permite que dois objetos 
possam, eventualmente, possuir valores iguais para seus atributos. Esses 
grupos de objetos com estruturas semelhantes são definidos em termos de 
classes. Classes consistem na unidade básica da construção de um programa 
OO e definem o conjunto de atributos mantidos por um conjunto de objetos 
e o comportamento que esses objetos devem respeitar. Segue exemplo de uma 
classe: 
12 
 
 
 
 
4.3 HERANÇA 
Herança é um conceito muito parecido com a delegação. No entanto, seu 
objetivo é a derivação de classes, ou seja, a criação de uma classe (classe 
filha) onde sua base é uma classe já existente (classepai), sendo adicionados 
a essa nova classe apenas atributos e métodos que não existam na classe 
original ou a execução de um método que seja diferente do método da classe 
original. Em outras palavras, a herança é um mecanismo de 
reaproveitamento em que as classes originais ficam contidas na nova classe. 
A reutilização de classes via mecanismo de delegação é útil quando 
consideramos que a classe que reutiliza instâncias de outras classes é 
composta destas. Um bom exemplo é a classe Data Hora, que é composta 
das classes Data e Hora. A solução é a reutilização de classes por meio do 
mecanismo de herança, no qual podemos criar uma classe usando outra como 
base e descrevendo ou implementando as diferenças e adições da classe 
usada como base, isso com a reutilização dos campos e métodos não 
privados da classe base. O mecanismo de herança é o mais apropriado para 
criar relações entre classes. Segue ex. de herança, onde cliente e fornecedor 
herdam atributos de pessoa. 
13 
 
 
 
 
4.4 POLIMORFISMO 
O polimorfismo está relacionado com o conceito de herança, 
especificamente em relação a métodos. O mecanismo de herança permite a 
criação de classes a partir de outras já existentes com relações “é-um-tipo -de”, de 
forma que, a partir de uma classe genérica, classes mais especializadas possam 
ser criadas. Quando uma nova classe necessita de todos os atributos e 
métodos de uma já existente, porém a nova classe possui a execução de 
um ou mais métodos diferenciados, é possível herdarmos todo s os métodos e 
atributos da classe original e realizar a alteração do comportamento do método 
somente na nova. O termo polimorfismo tem origem na composição de duas 
palavras grega s: Poli = muitas. Morphos = formas. Em termos de programação, 
muitas formas significam que um único nome pode representar um código 
diferente, selecionado por algum mecanismo automático. Assim, o polimorfismo 
permite que um único nome expresse muitos comportamentos diferentes 
(SINTES, 2002, p. 122). 
 
4.5 ENCAPSULAMENTO 
O encapsulamento é uma das principais técnicas que define a 
programação orientada a objetos. Se trata de u m do s elementos que 
adicionam segurança à aplicação em uma programação orientada a objetos 
pelo fato de esconder as propriedades, criando uma espécie de caixa preta. A 
maior parte das linguagens orientadas a objetos implementam o 
encapsulamento baseado em propriedades privadas, ligada s a métodos especiais 
chamados getters e setters, que irão retornar e inserir o valor da propriedade, 
14 
 
 
respectivamente. Essa atitude evita o acesso direto a propriedade do objeto, 
adicionando uma outra camada de segurança à aplicação. Para fazermos um 
paralelo com o que vemos no mundo real, temos o encapsulamento em outros 
elementos. Por exemplo, quando clicamos no botão ligar da televisão, não 
sabemos o que está acontecendo internamente. Podemos então dizer que os 
métodos que ligam a televisão estão encapsulados. 
 
5 ELEMENTOS TÉCNICOS DO SISTEMA 
5.1 DIAGRAMA DE CLASSES 
Este diagrama de classe representa o usuário entrando no sistema e 
realizando o pedido, demonstrando os campos que devem ser preenchidos 
para concluir o cadastro de pedidos, apresenta os campos de cadastro das 
tabelas pertencentes a tela de cadastro de pedidos. Onde é possível ver 
todos os campos necessários para completar o pedido. 
 
 
15 
 
 
5.2 DIAGRAMA DE OBJETOS 
O diagrama de objetos representa um detalhamento do que é a real 
construção da marcação do pedido, é apresentado a descrição do real pedido 
que o sistema trabalha. Demonstrando os nomes que são gravados nas 
variáveis para consolidar a reserva no banco de dados. 
 
6 TELAS DA APLICAÇÃO 
Nesta tela apresenta os Perfis do Usuários, e suas Atividades. 
 
Selecione seu perfil para acesso nas informações, ou clique no Ho me 
para retornar na tela inicial da loja. 
16 
 
 
 
Aqui nesta tela digite a sua ID e a senha, e clique no botão entrar para 
continuar no acesso ou sair para retornar na tela dos usuários. 
 
Apresenta esta tela de opções de Cliente, Produto, após se identificar na tela 
de login. Escolha a opção Cliente para verificar cadastros. Caso contrário clique em 
Home para retornar na tela de usuários. 
 
17 
 
 
Na tela Cliente, apresenta o botão Cadastro, Consulta, Alterar e Excluir. 
Para incluir cliente, clique no cadastro; verificar se já existe cliente, clique em 
consultar; corrigir erros ou atualizar dados do cliente, clique em alterar, ou caso 
queira eliminar cliente, clique em excluir. Se não houver nenhuma necessidade clique 
no botão Home para voltar na tela anterior. 
 
Na tela Produto, há também o botão Cadastro, Consulta, Alterar e Excluir. 
Se há necessidade de incluir produto, clique no cadastro; verificar se já existe 
cliente, clique em consultar; corrigir erros ou atua lizar dados do pro duto, clique em 
alterar, ou caso queira eliminar produto, clique em excluir. Se não houver 
nenhuma necessidade clique no botão Home para voltar na tela anterior. 
18 
 
 
 
Na Venda, apresenta também o botão Cadastro, Consulta, Alterar e Excluir. 
Onde pode incluir venda, verificar se já existe cliente, corrigir erros ou atualizar 
dados do produto, se queira eliminar venda. Observação: A exclusão de venda 
concretizada só poderá executado através do perfil supervisor da loja, pois 
atendente somente eliminar da venda não concretizada. Caso se não houver 
nenhuma necessidade clique no botão Home para voltar na tela anterior. 
 
 
 
 
19 
 
 
 
3. CONCLUSÃO 
Esse projeto ponderou a importância da evolução no mercado das 
empresas e softwares, trazendo a melhoria no atendimento aos clientes com geração 
de desktop, facilitando em agilizar os cadastramentos de usuários e produtos , 
tendo em vista se fez necessário fazer um Levantamento de análise de requisitos 
de sistemas , para obter um software atualizado, em cadastro de pro dutos 
Geek e acessórios, atender necessidades ao s usuários, portadores de deficiências, 
clientes, pro dutos no sistema, feitas o controle de acessos por meio login 
personalizado. Apesar da empresa possuir controle de estoque no grau raridade, 
o principal foco foi desenvolver o gerenciador em Desktop, e que tornou o 
processo mais rápido organizado no controle de vendas, cadastros de clientes para 
loja de jogos. 
20 
 
 
REFERÊNCIAS 
https://www.devmedia.com.br/os-4-pilares-da-programacao-orientada-a-
objetos/9264; 
https://www.devmedia.com.br/artigo-engenharia-de-software-4-modelagem-de-
processos-de-negocio/9880. 
https://codificar.com.br/requisitos-funcionais-nao-funcionais/#. 
https://dextra.com.br/pt/requisito-ou-regra-de-negocio/. 
 
https://www.devmedia.com.br/os-4-pilares-da-programacao-orientada-a-objetos/9264
https://www.devmedia.com.br/os-4-pilares-da-programacao-orientada-a-objetos/9264
https://codificar.com.br/requisitos-funcionais-nao-funcionais/