PIM_6_Levantamento e análise de requisitos para loja online de produtos_ENVIADO

Prévia do material em texto

UNIP 
Projeto Integrado Multidisciplinar 
Cursos Superiores de Tecnologia 
 
 
 
 
 
 
 
 
 
PROJETO: LEVANTAMENTO E ANÁLISE DE REQUISITOS DE UM SISTEMA DE 
CONTROLE PARA VENDAS ONLINE DE PRODUTOS E ACESSÓRIOS 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Unip – Guanambi/BA 
2020 
 
 
 
 
UNIP 
Projeto Integrado Multidisciplinar 
Cursos Superiores de Tecnologia 
 
 
 
 
 
 
PROJETO: LEVANTAMENTO E ANÁLISE DE REQUISITOS DE UM SISTEMA DE 
CONTROLE PARA VENDAS ONLINE DE PRODUTOS E ACESSÓRIOS 
 
 
 
 
 Alunos: Ramon Reis Vasconcelos 
Willian Souza Lima 
RA: 1925914 
 Curso: Análise e Desenvolvimento de Sistemas 
 Semestre: 3º Semestre 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Unip – Guanambi/BA 
2020 
 
 
 
 
Resumo 
O presente trabalho tem como propósito elaborar um levantamento e análise 
de requisitos de um sistema de vendas de materiais e produtos online. Manipulando 
as táticas de identificação e elaboração de casos de uso, levantamento de requisitos 
e suas regras de negócio, elaborará o seu modelo, identificando os relacionamentos 
de include, extend e generalização, com uma apresentação precisa de todas as 
suas ações, dos fluxos e conjunturas, bem como, especificaremos os requisitos de 
usabilidade do sistema, seu enquadramento de uso e por fim construiremos o 
modelo de dados do sistema, de igual maneira exibiremos as regras de negócio do 
cliente. Com base nos conhecimentos obtidos nos conteúdos das disciplinas de 
Análise de sistemas orientada a objetos, banco de dados e gestão estratégica de 
recursos humanos. 
 
Palavras-chave: Requisitos, Levantamento, Casos de Uso, Produtos, Vendas. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Abstract 
The purpose of this work is to elaborate a survey and analysis of requirements 
for a system of sales of materials and products online. Manipulating the tactics of 
identification and elaboration of use cases, requirements gathering and its business 
rules, it will elaborate its model, identifying the relationships of include, extend and 
generalization, with an accurate presentation of all its actions, flows and 
circumstances, as well as, we will specify the usability requirements of the system, its 
usage framework and finally we will build the data model of the system, as well as 
display the client's business rules. Based on the knowledge obtained in the contents 
of the disciplines of object-oriented systems analysis, database and strategic 
management of human resources. 
 
Keywords: Requirements, Survey, Use Cases, Products, Sales. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
LISTA DE FIGURAS 
 
Figura 01. Processo de levantamento e análise de requisitos...................................12 
Figura 02. Método VORD...........................................................................................12 
Figura 03. Validação e cadastramento - Ferramenta Astah (evaluation)...................15 
Figura 04. Selecionar produto....................................................................................18 
Figura 05. Confirmação do pedido.............................................................................22 
Figura 06. Diagrama no Astah Community................................................................29 
Figura 07. Exemplo de classe contendo atributos e métodos de um usuário............32 
Figura 08: Diagrama de classe...................................................................................33 
Figura 09: Modelo de Dados (MER)...........................................................................34 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
LISTA DE TABELAS 
 
Tabela 01: Grupos de técnicas para levantamento de requisitos..............................13 
Tabela 02: Conceitos envolvidos na descrição de um caso de uso...........................15 
Tabela 03: Navegar no sistema..................................................................................16 
Tabela 04: Logar........................................................................................................16 
Tabela 05: Registrar-se..............................................................................................17 
Tabela 06: Relação de produtos................................................................................19 
Tabela 07: Consultar produtos...................................................................................20 
Tabela 08: Adicionar produto ao carrinho..................................................................20 
Tabela 09: Excluir produto do carrinho.......................................................................21 
Tabela 10: Fechar pedido...........................................................................................23 
Tabela 11: Consultar item disponível.........................................................................24 
Tabela 12: Reservar produtos....................................................................................24 
Tabela 13: Endereçar dados de cartão......................................................................25 
Tabela 14: Requisitos não funcionais.........................................................................30 
Tabela 15: Regras de negócio...................................................................................31 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Sumário 
1. INTRODUÇÃO .................................................................................................. 8 
2. OBJETIVOS ...................................................................................................... 9 
2.1. Geral ............................................................................................................ 9 
2.2. Específico .................................................................................................... 9 
3. PANORAMA INDICADO PARA O PROJETO .................................................. 9 
4. TÉCNICAS E ANÁLISE PARA LEVANTAMENTO DE REQUISITOS ........... 10 
4.1 REQUISITOS FUNCIONAIS ............................................................................. 11 
4.1.1 Requisitos Não Funcionais ....................................................................... 11 
4.1.2 Regras de Negócio ................................................................................... 11 
5. IDENTIFICAÇÃO E MODELOS ...................................................................... 13 
5.1 CASOS DE USO ....................................................................................................... 13 
6. VALIDAÇÃO E CADASTRAMENTO. ............................................................. 15 
6.1 SELECIONAR PRODUTO (S) ........................................................................... 18 
6.1.1 Confirmação do pedido ............................................................................. 22 
7. MODELO ENTIDADE E RELACIONAMENTO ............................................... 26 
7.1 ENTIDADES ................................................................................................. 26 
7.1.1 Relacionamentos ...................................................................................... 26 
7.1.2 ATRIBUTOS ................................................................................................. 27 
7.1.3 Ferramentas Case .................................................................................... 28 
7.1.4 Requisitos não funcionais ......................................................................... 29 
7.1.5 Diagrama de Classe de Análise ................................................................ 32 
7.1.6 Modelo de Dados (MER)...........................................................................34 
8. CONCLUSÃO ................................................................................................. 35 
8.1 ADENDO ......................................................................................................................................... 35 
9. REFERÊNCIAS ............................................................................................... 36 
 
 
 
 
8 
 
 
 
1. INTRODUÇÃO 
 
 Em meio a um gradual panorama, o comércio de produtos e acessórios no 
Brasil mostra-se uma posição privilegiada e deixa claro que vem conquistando, isso 
se já não conquistou um lugar ao sol. 
 Este trabalho tem como umas das finalidades demostrar qual a importância 
da venda online, Com a compra e venda também sendo realizados pela internet 
muitos consumidores passou a se conectar mais e a pesquisarem produtos que lojas 
virtuais disponibilizam e assim chegando a um melhor preço e uma variedade maior 
de produtos no conforto de sua casa. As lojas virtuais vieram para fazer uma 
mudança no modo de compra e venda, pois hoje, a maioria das coisas pode ser feita 
através da internet, como pagamento de contas, visualização de conta corrente, 
transações, envio de documentos, entre outros. 
 Desta forma, por meio deste trabalho será produzido um levantamento e 
análise de requisitos para criação de uma loja online de jogos, acessórios e produtos 
geek. Consequentemente, a análise de requisitos apontada para o funcionamento da 
loja online de produtos, será usada na elaboração de documentos para ser 
implementado. 
 Assim sendo, elaborações dos documentos neste projeto contemplam modelo 
de caso de uso, requisitos funcionais e não funcionais regras de negócio, diagramas 
de classes e modelo de dados (MER) desde modo pondo em prática todo o 
conhecimento abstraído durante o semestre. 
 
 
 
 
 
 
 
 
 
 
 
 
9 
 
 
 
2. OBJETIVOS 
2.1. Geral 
 Requisitos de um sistema para empresa destinada à venda de jogos 
eletrônicos, acessórios e produtos geek, de forma que possa facilitar a vida do 
cliente (usuário) realizando compras, estando no conforto da sua casa. 
 
 2.2. Específico 
 a) permitir e controlar os cadastros gerais das vendas de jogos eletrônicos, 
acessórios e produtos geek.. 
 b) Deverá realizar todos os cadastros, alterações, consultas e exclusões. 
 c) Permitirá realizar o levantamento e análise de requisitos de um sistema 
para empresa destinada as vendas. 
 d) Permitirá alterações, consultas e exclusões relacionadas aos produtos que 
serão vendidos na loja. 
 e) O sistema será utilizado por atendentes, estoquistas e o supervisor da loja. 
 f) Permitirá o cadastro dos clientes e controlar o acesso com níveis de login e 
senha. 
 
3. PANORAMA INDICADO PARA O PROJETO. 
 Têm apresentado neste tópico o panorama oferecido, onde será usado com 
base para toda a produção do projeto. O cenário segue de forma exata como pede 
no manual deste projeto. 
 Uma instituição do ramo de vendas de jogos eletrônico e produtos geek 
resolveu contratar uma empresa para construir um sistema para controlar o estoque 
dos produtos e as vendas realizadas. Desta forma, o usuário deverá acessar o site, 
escolher o (os) produto desejado (s) logo em seguida efetuar a compra. 
 Algumas questões devem ser levadas em conta, o acesso ao sistema deverá 
ser efetuado através de login e senha. O usuário deverá fazer um cadastro, e caso 
seja o seu primeiro acesso. As informações para cadastro são: 
 - Nome completo 
 - Endereço 
 - Telefone 
10 
 
 
 
 - Data de nascimento 
 - CPF 
 - RG 
 - Login 
 - Senha 
 Caso o usuário já possua o cadastro, apenas deve digitar sei login e senha. 
Após a validação do login e senha, o cliente poderá escolher o produto (s) do seu 
interesse, verificando as informações no sistema de controle de estoque (já 
existente). A partir disso irá informa-lo se haverá produtos disponíveis ou não para 
efetuar a compra. Após a escolha do (s) produto (s) desejado, o usuário deverá 
efetuar a compra com pagamento somente com cartão de crédito que deve ser 
validado pelo sistema externo na operadora do próprio cartão. Caso o produto 
escolhido pelo cliente esteja em falta para a compra no momento, o cliente poderá 
realizar a reserva. 
 
4. TÉCNICAS E ANÁLISE PARA LEVANTAMENTO DE REQUISITOS 
Dentro da engenharia de sistemas e engenharia de software, análise de 
requisitos incorpora todas as tarefas que lidam com investigação, definição e escopo 
de novos sistemas ou alterações. Análise de requisitos é uma parte importante do 
processo de projeto de sistemas, na qual o engenheiro de requisitos e o analista de 
negócio, juntamente com engenheiro de sistema ou desenvolvedor de software, 
identificam as necessidades ou requisitos de um cliente. Uma vez que os requisitos 
do sistema tenham sido identificados, os projetistas de sistemas estarão preparados 
para projetar a solução. 
As descrições das funções que um sistema deve incorporar e das restrições que 
devem ser satisfeitas são os requisitos para o sistema. Isto é, os requisitos de um 
sistema definem o que o sistema deve fazer e as circunstâncias sob as quais deve 
operar. Em outras palavras, os requisitos definem os serviços que o sistema deve 
fornecer e dispõem sobre as restrições à operação do mesmo. 
 
Requisitos são, normalmente, classificados em requisitos funcionais e não 
funcionais. 
 
11 
 
 
 
4.1 Requisitos Funcionais 
Os requisitos funcionais são aqueles que fazem parte do sistema, como um 
relatório específico, um campo a mais em um cadastro, etc. Eles normalmente têm a 
finalidade de agregar valor ao usuário ou facilitar o trabalho que ele desenvolve. 
Requisitos funcionais serão implementados no próprio sistema e da junção desses 
requisitos o corpo do sistema será montado. Ou seja, como o próprio nome indica, 
apontam as funções que o sistema deve fornecer e como o sistema deve se 
comportar em determinadas situações. 
 
4.1.1 Requisitos Não Funcionais 
Requisitos não funcionais são aqueles relacionados ao ambiente onde o 
sistema está inserido. Um servidor mais robusto, um firewall, ou um usuário 
especializado em determinado procedimento pode ser visto como requisitos não-
funcionais. Eles não devem ser ignorados por não fazerem parte diretamente do 
sistemas, mas devem ser considerados por compor o ambiente onde o software irá 
rodar. Ou seja, descrevem restrições sobre as funções oferecidas, tais como 
restrições de tempo, de uso de recursos etc. Alguns requisitos não funcionais dizem 
respeito ao sistema como um todo e não a funcionalidade específica. 
 
4.1.2 Regras de Negócio 
 Para tê-lo acesso ao sistema (site) deverá ser por meio de login e senha. O 
usuário deverá fazer um cadastro, por ventura seja o seu primeiro acesso. 
 Por motivo de esquecimento, a senha por parte do usuário, o mesmo em 
questão deverá solicitar outra, através de um link e recebera uma senha nova 
temporária em seu e-mail cadastrado no sistema para efetuar login e alterar a senha 
novamente. 
 
O levantamento e análise de requisitos é um processo iterativo, com uma contínua 
validação de uma atividade para outra, conforme mostra a Figura 1. 
 
 
12 
 
 
 
 
Figura 01. Processo de levantamento e análise de requisitos. 
 
Modelo técnico de levantamento orientado a ponto de vista. 
 
 
 
Figura 02. Método VORD. 
 
Amostragem dos grupos de técnicas para o levantamento de requisitos. 
Técnicas 
tradicionais 
São aplicadas em várias áreas do conhecimento. 
Exemplo: questionários, entrevistas, observação, e 
análise de documentos. 
Técnicas de 
elicitação de 
grupo 
Tem por objetivo compreender melhor o pensamento e 
comportamento dos grupos e as necessidadesdos 
usuários. Exemplo: brainstorming e as sessões JAD (Joint 
13 
 
 
 
Application Design). 
Prototipação 
O uso de protótipo auxilia na elicitação e validação dos 
requisitos de sistema. 
A prototipação pode ser utilizada para elicitar requisitos 
quando há um alto grau de incerteza ou quando é 
necessário um rápido feedback dos usuários. 
Técnicas 
contextuais 
Surgiram como uma alternativa para as técnicas 
tradicionais e cognitivas e inclui técnicas de etnografia e 
análise social. 
Tabela 01. Grupos de técnicas para levantamento de requisitos. 
 
5. IDENTIFICAÇÃO E MODELOS 
 
 5.1 Casos de Uso 
● Um modelo de caso de uso é um modelo que descreve como diferentes 
tipos de usuários interagem com o sistema para resolver um problema. Como tal, ele 
descreve as metas dos usuários, as interações entre os usuários e o sistema, bem 
como o comportamento necessário do sistema para satisfazer estas metas. Os 
elementos de modelo mais importantes são: casos de uso, atores e as relações 
entre eles. 
● O Diagrama de Caso de Uso serve para representar como os casos de uso 
interagem entre si no sistema e com os usuários (atores), ou seja, como as 
funcionalidades se relacionarão umas com as outras e como serão utilizadas pelo 
usuário, durante o uso do sistema. 
 
 
14 
 
 
 
Descrição de um caso de uso. 
Objetivo: Contém uma breve descrição do objetivo do caso de uso. 
Requisitos: Neste campo indicamos a qual requisito funcional o caso de uso 
em questão está associado. 
Atores: Neste campo definimos a lista de atores associados ao caso de 
uso. Ator é qualquer entidade externa que interage com o 
sistema (neste caso, com o caso de uso em questão). 
Prioridade: Informação identificada junto ao usuário que auxilia na definição 
dos casos de uso que serão contemplados em cada iteração do 
desenvolvimento do software. 
Pré-condições: Neste campo devemos informar as condições que devem ser 
atendidas para que o caso de uso possa ser executado. 
Frequência de 
uso: 
Informação identificada junto ao usuário que auxilia na definição 
dos casos de uso que serão contemplados em cada iteração do 
desenvolvimento do software. 
Criticalidade: Informação identificada junto ao usuário que auxilia na definição 
dos casos de uso que serão contemplados em cada iteração do 
desenvolvimento do software. 
Condição de 
Entrada: 
Neste campo definimos qual ação do ator dará início à interação 
com o caso de uso em questão. 
Fluxo Principal: Esta é uma das seções principais do caso de uso. É onde 
descrevemos os passos entre o ator e o sistema. O fluxo 
principal é o cenário que mais acontece no caso de uso e/ou o 
mais importante. 
Fluxo 
Alternativo: 
Fluxo alternativo é o caminho alternativo tomado pelo caso de 
uso a partir do fluxo principal, ou seja, dada uma condição de 
negócio o caso de uso seguirá por outro cenário que não o 
principal caso essa condição seja verdadeira. 
Pós-condições: Neste campo devemos informar o estado em que o sistema (ou 
entidade manipulada no caso de uso) estará depois que o caso 
15 
 
 
 
de uso for executado. 
Regras de 
negócio: 
Nesta seção descrevemos todas as regras funcionais que o caso 
de uso deve cumprir durante sua execução. 
Tabela 02. Conceitos envolvidos na descrição de um caso de uso. 
 
6. VALIDAÇÃO E CADASTRAMENTO. 
 Conforme mencionados anteriormente vão ser abordados a seguir modelos 
de tabelas com descrições de cada caso de uso evidenciado no diagrama de caso 
de uso. 
 
 
Figura 03 - Validação e cadastramento - Ferramenta Astah (evaluation). 
Fonte: Willian Souza Lima – Estudante, UNIP 2020. 
Ramon Reis Vasconcelos – Estudante, UNIP 2020. 
 
 
Validação Navegar-se no sistema 
Escopo Validação e cadastro 
Definição 
 
Nesse caso, permite que o cliente possa ter acesso ao sistema 
operando com um navegador Web. 
Ator Usuário 
Interessados Usuário e loja 
16 
 
 
 
Pré-Condição O sistema deverá estar online para navegação 
Pós-Condição O sistema facilitará para que o usuário faça sua validação 
Fluxo-Normal 1- O cliente acessa o sistema utilizando um Browser 
2- O sistema mostra a tela inicial do sistema e solicita a 
validação do usuário. 
Requisitos 
relacionados 
RNF 01 – Disponibilidade de sistema. 
 
Tabela 03 - Navegar no sistema 
 
Validação Logar. 
Escopo Validação e cadastro 
Definição Nesse caso de uso o usuário se identifica para acessar a loja. 
Ator Usuário 
Interessados Usuário e loja 
Pré-Condição O sistema deverá estar online para navegação 
Pós-Condição O usuário é direcionado para a página de produtos 
Fluxo-Normal 1 - O usuário disponibiliza o login e senha no campo pertencente. 
2 - O usuário pressiona realizar login. 
3 - O sistema valida os dados do usuário. 
4 - O sistema direciona o usuário para a página com lista completa 
de produtos e acessórios. 
Fluxo 
alternativo 
1 - Porventura o usuário pressionar realizar login sem preencher 
um dos campos, exibirá uma notificação de campo não preenchido 
obrigatório. 
2 – Caso os dados do usuário não estiverem corretos, exibirá uma 
notificação para que o mesmo forneça as informações corretas 
para continuar o registro. 
Requisitos 
relacionados 
RNF 01 - Navegar-se no sistema 
 
 
Tabela 04 – Logar. 
 
17 
 
 
 
 
 
Validação Registra-se 
Escopo Validação e cadastro 
Definição Nesse caso de uso permite que o usuário registre seus dados 
junto à loja para posteriormente ter as informações validadas. 
Ator Usuário 
Interessados Usuário e loja 
Pré-Condição O usuário não tem cadastro na loja 
Pós-Condição O usuário é informado do registro bem sucedido e 
direcionado a página principal do sistema para ter acesso 
com seu login e senha. 
Fluxo-Normal 1- O cliente preenche os campos com os dados, nome, 
endereço, data de nascimento, telefone, RG, CPF, e-
mail, data do cadastro, login e senha. 
2- O usuário pressiona o botão registrar 
3- O sistema informa registro com sucesso e direciona-o 
para a página inicial. 
Fluxo alternativo 1- Por motivo, o usuário pressionar registro em algum 
campo vazio como: nome, endereço, telefone, data de 
nascimento, login e senha, exibirá uma notificação 
para preencher os campos obrigatórios. 
2- Por acaso o login disponibilizado pelo usuário já exista, 
exibirá uma mensagem “já existe esse nome, escolha 
outra para prosseguir”. 
 
Requisitos 
Relacionados: 
RNF 01 – Navegar-se no sistema 
 
Tabela 05 - Registrar-se 
 
 
 
18 
 
 
 
6.1 Selecionar Produto (S) 
 A seguir serão mencionados modelos de tabelas com descrições de cada 
caso de uso evidenciado no diagrama de caso de uso. 
 
 
Figura 04 - Selecionar produto 
Fonte: Willian Souza Lima - Estudante, UNIP 2020. 
Ramon Reis Vasconcelos – Estudante, UNIP 2020. 
 
 
 
 
 
 
 
 
 
 
 
 
 
19 
 
 
 
Validação Relacionar produtos 
Escopo Selecionar produtos 
Definição Nesse caso de uso permite que o usuário acesse a página 
com a relação de produtos mais procurados. 
Ator Usuário 
Interessados Usuário e loja 
Pré-Condição O usuário foi validado no sistema. 
Pós-Condição O usuário escolhe o produto (o/s) desejado (s) 
Fluxo-Normal 1- O sistema realiza a consulta dos produtos mais 
procurados no sistema de controle de estoque da loja. 
2- Em seguida são mostrados na tela do sistema os 
produtos. 
Requisitos 
Relacionados: 
RNF 02 – Controle de estoque disponível pelo sistema 
Tabela 06 - Relação de produtos 
 
Validação Consultar produtos 
Escopo Selecionar produto 
Definição Nesse caso de uso concorda que o usuário utilize a interface 
do sistema para realizar buscas especificas de produtos, a 
consulta contempla todas as informações do produto, como: 
nome do produto, código de barra, categoria, fabricante, para 
os jogos e os acessórios, devem ser informados em qual 
plataforma além de quantidade e valor. 
Ator Usuário 
Interessados Usuário e loja 
Pré-Condição O usuário foivalidado no sistema 
Pós-Condição O usuário tem o resultado da busca 
Fluxo-Normal 1- O usuário informa o dado de pelo menos um dos 
campos, categoria, nome do produto e pressiona 
pesquisar. 
2- O sistema utiliza do dado informado para buscar no 
sistema de controle de estoque da loja os produtos 
20 
 
 
 
3- Em seguida é mostrado na tela do sistema o resultado 
da pesquisa. 
Fluxo alternativo 1- Porventura o usuário pressione o botão e não forneça 
nenhum dos campos nome do produto, código de barra, 
categoria, fabricante, para os jogos e os acessórios, em 
qual plataforma além de quantidade e valor. Exibirá uma 
mensagem para preencher o campo obrigatório. 
2- Caso o sistema de controle de estoque não encontre 
nenhum dos produtos para a consulta procurada, o 
sistema mostrará uma mensagem informando, produto 
não encontrado. 
Requisitos 
Relacionados: 
RNF 02 – Controle de estoque disponível pelo sistema 
 
Tabela 07 – Consultar produtos 
 
Validação Adicionar produto ao carrinho 
Escopo Selecione produto 
Definição Nesse caso de uso permite que o usuário adicione os produtos 
de sua escolha no carinho de compras para depois finalizar a 
compra. 
Ator Usuário 
Interessados Usuário e loja 
Pré-Condição O usuário foi validado no sistema 
Pós-Condição Valorizar um carrinho de compras para o usuário 
Fluxo-Normal 1- O usuário pressiona o botão de informações do produto 
de sua escolha. 
2- O sistema direciona o usuário para a página de 
produtos escolhidos. 
Requisitos 
Relacionados: 
RNF 02 – Controle de estoque disponível pelo sistema 
 
Tabela 08 - Adicionar produto ao carrinho 
21 
 
 
 
 
 
 
Validação Excluir produto do carrinho 
Escopo Seleciona produto 
Definição Nesse caso de uso permite que o usuário exclua produtos do 
carrinho de compras, para que naquele instante compre 
somente o produto desejado. 
Ator Usuário 
Interessados Usuário e loja 
Pré-Condição O usuário foi validado no sistema 
Pós-Condição Valorizar um carrinho de compras para o usuário 
Fluxo-Normal 1- O usuário acessa o seu carrinho de compras 
2- O usuário clica no botão excluir para retirar o produto do 
carrinho. 
Requisitos 
Relacionados: 
RNF 02 – Controle de estoque disponível pelo sistema 
 
Tabela 09 - Excluir produto do carrinho 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
22 
 
 
 
6.1.1 Confirmação do Pedido 
 
A seguir serão mostrados modelos de tabelas com descrições de cada caso de uso 
evidenciado no diagrama de caso de uso. 
 
 
Figura 05 - Confirmação do pedido 
Fonte: Willian Souza Lima - Estudante, UNIP 2020 
Ramon Reis Vasconcelos – Estudante, UNIP 2020. 
 
 
Validação Fechar pedido 
Escopo Confirmação da compra 
Definição Nesse caso de uso permite que o usuário conclua seu pedido de 
produto (s) por ele adquirido e reserve um produto não 
disponível. 
Ator Usuário 
Interessados Usuário, loja e Sistema Operador de Cartões de Crédito. 
23 
 
 
 
Pré-Condição O usuário ter produtos no carrinho de compras 
Pós-Condição O usuário concluir sua compra ou reserva de um novo produto. 
Fluxo-Normal 1- O usuário escolhe a melhor maneira “frete” de receber 
sua mercadoria. 
2- O usuário informa a quantidade de cada produto que 
deseja adquirir. 
3- O usuário clica para concluir a compra. 
4- É mostrada no sistema a lista de produtos contendo suas 
quantidades para consultar disponibilidade. 
Fluxo alternativo 1- Porventura o usuário clicar no botão concluir compra sem 
informar a melhor forma de frete e as quantias de cada 
produto, exibira uma notificação para que o usuário 
informe melhor maneira a ser entregue a mercadoria. 
2- Porventura o usuário clicar no botão concluir compra sem 
ao menos informar as quantias de cada produto, exibirá 
uma mensagem para que o usuário ilustre a quantia de 
cada produto. 
Requisitos 
Relacionados: 
RF 03 – Sistema Operadora de Cartões de Crédito estar 
disponível. 
RF 02 – Sistema de controle de estoque disponível. 
 
Tabela 10 – Fechar pedido 
 
 
 
 
Validação Consultar item disponível 
Escopo Confirmação de compra 
Definição Nesse caso de uso, permite que o sistema consulte se a item 
disponível no estoque e a quantia de produtos. 
Ator Usuário 
Interessados Usuário, loja e Sistema Operador de Cartões de Crédito. 
Pré-Condição O usuário ter produtos no carrinho de compras. 
24 
 
 
 
Pós-Condição O usuário finaliza o processo de compra ou reserva de algum 
produto. 
Fluxo-Normal 1- O sistema consulta lista de produtos disponíveis no 
sistema de estoque. 
2- O sistema verifica o feedback de produtos disponíveis. 
Fluxo alternativo Porventura, algum dos produtos não estiver disponível no 
estoque, exibirá uma notificação informando se há 
disponibilidade de produtos e sugerir uma reserva do mesmo 
em questão. 
Requisitos 
Relacionados: 
RNF 03 – Sistema Operadora de Cartões de Crédito estar 
disponível. 
RNF 02 – Sistema de controle de estoque disponível 
 
Tabela 11 - Consultar item disponível 
 
 
Validação Reservar produtos 
Escopo Confirmação de compra 
Definição Nesse caso de uso, permite que o usuário reserve produtos se 
porventura estiverem em disponibilidade. 
Ator Usuário 
Interessados Usuário, loja, Sistema Operador de Cartões de Crédito. 
Pré-Condição O usuário ter produtos no carrinho de compras disponíveis. 
Pós-Condição O usuário assegura a reserva do produto. 
Fluxo-Normal 1- O usuário clica em assegurar produto. 
2- O sistema assegura a reserva do produto na base de 
dados. 
Requisitos 
Relacionados: 
RF 03 - Sistema Operadora de Cartões de Crédito estar 
disponível. 
RF 02 - Sistema de controle de estoque disponível. 
 
Tabela 12 – Reservar produtos 
 
25 
 
 
 
 
 
Validação Endereçar dados de cartão 
Escopo Confirmação de compra 
Definição Nesse caso de uso, permite que os dados de cartão de crédito 
do usuário sejam enviados ao sistema operador de cartões de 
crédito, para serem aprovados. 
Ator Usuário 
Interessados Usuário, loja, sistema operador de cartões de crédito 
Pré-Condição O usuário ter produtos no carrinho de compras disponíveis 
Pós-Condição O usuário registrar a compra do produto mediante aprovação do 
sistema operador de cartões de crédito. 
Fluxo-Normal 1- O sistema solicita os dados do cartão de crédito. 
2- O usuário informa os dados do cartão. 
3- O usuário clica em confirmar compra. 
4- O sistema envia os dados ao sistema operador de cartão 
de crédito. 
5- O sistema exibe mensagem informando que a compra foi 
solicitada e aguarda autorização de credito. 
Fluxo alternativo 1- Porventura o usuário clicar em autorizar compra sem 
informar os dados do cartão, exibirá uma notificação 
informando a necessidade de preencher os campos 
“abertos” dos dados do cartão. 
Requisitos 
Relacionados: 
RNF 03 - Sistema operador de cartão de crédito estar 
disponível. 
RNF 02 - Sistema de controle de estoque disponível. 
 
Tabela 13 - Endereçar dados de cartão 
 
 
 
 
 
26 
 
 
 
7. MODELO ENTIDADE E RELACIONAMENTO. 
 
O Modelo Entidade Relacionamento (também chamado Modelo ER, ou 
simplesmente MER), como o nome sugere, é um modelo conceitual utilizado 
na Engenharia de Software para descrever os objetos (entidades) envolvidos em um 
domínio de negócios, com suas características (atributos) e como elas se relacionam 
entre si (relacionamentos). 
Em geral, este modelo representa de forma abstrata a estrutura que possuirá 
o banco de dados da aplicação. Obviamente, o banco de dados poderá conter várias 
outras entidades, tais como chaves e tabelas intermediárias, que podem só fazer 
sentido no contexto de bases de dados relacionais. 
 
7.1 Entidades 
Os objetos ou partes envolvidas um domínio, também chamados de 
entidades, podem ser classificados como físicos ou lógicos, de acordo sua 
existência no mundo real. Entidades físicas: são aquelas realmente tangíveis, 
existentes e visíveis no mundo real, comoum cliente (uma pessoa, uma empresa) 
ou um produto (um carro, um computador, uma roupa). Já as entidades lógicas são 
aquelas que existem geralmente em decorrência da interação entre ou com 
entidades físicas, que fazem sentido dentro de certo domínio de negócios, mas que 
no mundo externo/real não são objetos físicos (que ocupam lugar no espaço). São 
exemplos disso uma venda ou uma classificação de um objeto (modelo, espécie, 
função de um usuário do sistema). 
 
7.1.1 Relacionamentos 
Uma vez que as entidades são identificadas, deve-se então definir como se dá o 
relacionamento entre elas. De acordo com a quantidade de objetos envolvidos em 
cada lado do relacionamento, podemos classifica-los de três formas: 
 
- Relacionamento 1..1 (um para um): cada uma das duas entidades envolvidas 
referenciam obrigatoriamente apenas uma unidade da outra. Por exemplo, em um 
banco de dados de currículos, cada usuário cadastrado pode possuir apenas um 
https://www.devmedia.com.br/principios-da-engenharia-de-software/29630
https://www.devmedia.com.br/cursos/banco-de-dados
https://www.devmedia.com.br/curso/curso-modelagem-de-bancos-de-dados-relacionais/409
27 
 
 
 
currículo na base, ao mesmo tempo em que cada currículo só pertence a um único 
usuário cadastrado. 
 
- Relacionamento 1..n ou 1..* (um para muitos): uma das entidades envolvidas 
pode referenciar várias unidades da outra, porém, do outro lado cada uma das 
várias unidades referenciadas só pode estar ligada uma unidade da outra 
entidade. Por exemplo, em um sistema de plano de saúde, um usuário pode ter 
vários dependentes, mas cada dependente só pode estar ligado a um usuário 
principal. Note que temos apenas duas entidades envolvidas: usuário e 
dependente. O que muda é a quantidade de unidades/exemplares envolvidas de 
cada lado. 
 
- Relacionamento n..n ou *..* (muitos para muitos): neste tipo de 
relacionamento cada entidade, de ambos os lados, podem referenciar múltiplas 
unidades da outra. Por exemplo, em um sistema de biblioteca, um título pode ser 
escrito por vários autores, ao mesmo tempo em que um autor pode escrever 
vários títulos. Assim, um objeto do tipo autor pode referenciar múltiplos objetos 
do tipo título, e vice versa. 
 
 
7.1.2 Atributos 
Atributos são as características que descrevem cada entidade dentro do 
domínio. Por exemplo, um cliente possui nome, endereço e telefone. Durante a 
análise de requisitos, são identificados os atributos relevantes de cada entidade 
naquele contexto, de forma a manter o modelo o mais simples possível e 
consequentemente armazenar apenas as informações que serão úteis futuramente. 
Uma pessoa possui atributos pessoais como cor dos olhos, altura e peso, mas para 
um sistema que funcionará em um supermercado, por exemplo, estas informações 
dificilmente serão relevantes. 
 
 
 
 
28 
 
 
 
Os atributos podem ser classificados quanto à sua função da seguinte forma: 
- Descritivos: representam característica intrínsecas de uma entidade, tais como 
nome ou cor. 
- Nominativos: além de serem também descritivos, estes têm a função de definir 
e identificar um objeto. Nome, código, número são exemplos de atributos 
nominativos. 
- Referenciais: representam a ligação de uma entidade com outra em um 
relacionamento. Por exemplo, uma venda possui o CPF do cliente, que a 
relaciona com a entidade cliente. 
Quanto à sua estrutura, podemos ainda classificá-los como: 
- Simples: um único atributo define uma característica da entidade. Exemplos: 
nome, peso. 
- Compostos: para definir uma informação da entidade, são usados vários 
atributos. Por exemplo, o endereço pode ser composto por rua, número, bairro, 
etc. 
Alguns atributos representam valores únicos que identificam a entidade dentro 
do domínio e não podem se repetir. Em um cadastro de clientes, por exemplo, esse 
atributo poderia ser o CPF. A estes chamamos de Chave Primária. 
 
7.1.3 Ferramentas Case 
Do inglês Computer-Aided Software Engineering, as chamadas ferramentas 
CASE são aquelas baseadas em computadores (softwares) utilizadas na Engenharia 
de Software para auxílio nas atividades desde análise de requisitos até, modelagem 
de dados. 
As ferramentas CASE permitem a criação de diagramas de forma simples em 
um ambiente de fácil utilização e com recursos para incluir as principais regras de 
composição dos diagramas. 
 
 
 
https://www.devmedia.com.br/ferramentas-case-e-qualidade-dos-dados-o-paradigma-da-boa-modelagem/6905
https://www.devmedia.com.br/ferramentas-case-e-qualidade-dos-dados-o-paradigma-da-boa-modelagem/6905
29 
 
 
 
 
Modelo de diagrama sendo construído no Astah 
 
Figura 06. Diagrama no Astah Community 
Fonte: Willian Souza Lima - Estudante, UNIP 2020 / Ramon Reis Vasconcelos – Estudante, UNIP 
2020. 
 
7.1.4 Requisitos não funcionais 
Quadro 01: Requisitos não funcionais 
 
REQUISITOS NÃO FUNCIONAIS 
Identificação Nome Definição 
RNF O1 Ociosidade do sistema É de suma importância o site estar 
disponível na rede operando no 
sistema. 
RNF O2 Disponibilidade do controle 
de estoque 
O sistema de estoque é um requisito 
essencial, pois nele estar toda a 
informação dos produtos estão nesse 
sistema 
30 
 
 
 
RNF O3 Disponibilidade do Operador 
de cartão de crédito 
A operadora de créditos é o meio de 
pagamento único do sistema e 
indispensável no processo de 
conclusão da compra. 
RNF O4 Seguridade de acesso Proteger de ataques externos é 
necessário, o uso de boas práticas de 
segurança de acesso ao site. 
RNF O5 Desempenho de rede Há uma necessidade de usar dois 
sistemas externos para prover o 
funcionamento do sistema, por isso, a 
comunicação entre eles deve ser de 
alto desempenho. 
RNF O6 Praticidade e entendimento O usuário ao acessar o sistema não 
proverá de um auxilio imediato, por 
isso o sistema deve ser de fácil uso, 
intuitivo, responsivo, para que o 
usuário fique satisfeito. 
RNF O7 Responsividade do sistema Com o avanço dos smartphones é 
providencial que o layout de todo o 
site possa ser acessado sem nenhum 
contratempo nos mobile. 
 
Tabela 14 - Requisitos não funcionais 
 
 
 
 
 
 
 
 
 
 
31 
 
 
 
 
Quadro 02: Regras de negócio 
 
REGRAS DE NEGÓCIO 
Identificação O usuário é validado no sistema – regra de negócio 01 (RN 01) 
Definição O usuário deverá ser aprovado via login e senha para acesso 
Fonte Panorama descrito em Manual do PIM VI 
 
Identificação Preencher os campos no cadastro - regra de negócio 02 (RN 02) 
Definição O usuário disponibilizara todos as suas informações solicitados no 
cadastro, para assim serem enviados os produtos e o contado do 
usuário, caso necessite. 
Fonte Panorama descrito em Manual do PIM VI 
 
Identificação Preenchimento de campos na validação do cartão de crédito – regra 
de negócio 03 (RN 03) 
Definição O usuário deverá informar todos os dados solicitados para 
aprovação do cartão de crédito, pois somente assim o item será 
processado como venda. 
Fonte Panorama descrito em Manual do PIM VI 
 
Tabela 15 - Regras de negócio 
 
 
 
 
 
 
 
 
 
 
 
 
32 
 
 
 
7.1.5 Diagrama de Classe de Análise 
 
Considerado por muitos profissionais da área como o mais importante e o 
mais utilizado diagrama da UML. Seu principal aspecto está em permitir a 
visualização das classes que irão compor o sistema com seus respectivos atributos 
e métodos, bem como em demonstrar como as classes do sistema se relacionam, 
complementam e transmitem informações entre si. Este diagrama apresenta uma 
visão estática de como as classes estão organizadas, preocupando-se em definir a 
estrutura lógica das mesmas. O diagrama de classes serve como base para a 
construção da maior parte dos demais diagramas da UML. 
Fundamentalmente, o diagrama de classes é composto por suas classes e 
pelas associações existentes entre elas, ou seja, os relacionamentos entre as 
classes. Segundo Guedesem seu livro “UML – Uma Abordagem Prática”, o objetivo 
do diagrama de classes é mostrar os relacionamentos existentes entre as classes 
que são abstraídas no projeto, e como esses relacionamentos colaboram para a 
execução de um processo específico. 
 
 
Uma classe, na linguagem UML, é representada por um retângulo com até 
três divisões, descritas a seguir: 
 
Usuário 
- cpf: long 
- nome: String 
- telefone: long 
- status: boolean 
+ consulta (cpf : long) : Usuário 
 
Figura 07 - Exemplo de classe contendo atributos e métodos de um usuário. 
Fonte: Willian Souza Lima - Estudante, UNIP 2020. 
Ramon Reis Vasconcelos – Estudante, UNIP 2020. 
 
 
33 
 
 
 
 
Métodos podem receber valores como parâmetros e retornar valores, que 
podem tanto ser o resultado produzido pela execução do método como 
simplesmente um valor representado se o método foi realizado com sucesso ou não. 
Não é obrigatório que uma classe apresente as três divisões, a única realmente 
necessária é a descrição (nome) da classe. 
 
 Modelo de Diagrama de Classe a partir do panorama apontado 
 
Figura 08 – Diagrama de classe 
Fonte: Willian Souza Lima - Estudante, UNIP 2020. 
Ramon Reis Vasconcelos – Estudante, UNIP 2020. 
 
34 
 
 
 
7.1.6 Modelo de Dados (MER) 
 
Desenvolvido para facilitar o projeto de banco de dados relacionais permitindo 
a representação de todas as estruturas dos mesmos e um melhor dialogo entre os 
profissionais envolvidos no projeto, estabeleceu-se como o primeiro modelo de 
dados para aplicações comerciais. Umas das suas maiores vantagens são: 
flexibilidade, adaptabilidade, simplicidade e objetividade. 
 O fundamental proposito que o MER caracteriza é a entidade, representa 
qualquer coisa do mundo real que abrange uma existência independente objetos, 
pessoas, conceitos, “coisas” etc. Além do mais, toda entidade tem especialidades 
que são chamados de atributos e algumas se relacionam uma com as outras. 
 
Modelo de Dados (MER) a partir do panorama apontado 
 
Figura 09 – Modelo de Dados (MER) 
Fonte: Willian Souza Lima - Estudante, UNIP 2020. Ferramenta auxiliar (Coreldraw). 
Ramon Reis Vasconcelos – Estudante, UNIP 2020. 
 
https://www.devmedia.com.br/bancos-de-dados-relacionais/20401
35 
 
 
 
8. CONCLUSÃO 
 
 Nota-se que a partir do desenvolvimento de uma análise para cenário de uma 
loja online de jogos, acessórios e produtos geek, apresentou-se desafiadora no 
começo, um dos fatores é por se tratar de diferentes procedimentos e bases 
analíticas. Entretanto com muita pesquisa em cima do panorama real e a 
comunicação entre o que foi abordado na temática e os profissionais pela análise do 
sistema, conseguiram-se conhecimentos necessários para a conclusão desse 
trabalho. 
Ainda assim, o que não se pode ignorar é o fato de que com vendas online as 
lojas tem uma grande crescente, expandindo para o ambiente físico, onde os 
consumidores podem ter maior contato e testar os produtos. 
 
 8.1 ADENDO 
Na página 19 foi escolhido um caso de uso para produto “selecionar produto” 
nesse caso pode ser para item, jogos, acessórios ou produtos geek. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
36 
 
 
 
9. REFERÊNCIAS 
 
Alberto Debatiani, Carlos. Definindo Escopo em Projetos de Software. São Paulo: 
Novatec. 2015. 
 
https://astah.net 
 
ASTAH. Tutorial. Disponível em: http://astah.net/tutorials.Acesso em: 25 de maio 
2020. 
 
Diagramas de classes UML: referência: Disponível em https://msdn.microsoft.com/pt-
br/library/dd409437 .aspx Acesso em 11 de junho de 2017. 
 
Diferenças entre Lojas Físicas e Lojas Virtuais. 16 abril 2013. Disponível em: . 
Acessado em: 04 jul. 2013 
 
GUEDES, Gilleanes T. A. UML: Uma abordagem prática. São Paulo: Novatec, 2006. 
 
Loja Virtual x Loja Física. Disponível em: Acessado em 20 jul. 2013. 
 
PRESSMAN, Roger S. Engenharia de Software. São Paulo. Ed. Markon Books, 
1995. 
Martins, José Carlos Cordeiro. Gerenciando Projetos de Desenvolvimento de 
Software – 2ª e 4ª edições, 2007. 
 
Somerville, I. Engenharia de software. 6° ed. Tradução Maurício de Andrade. São 
Paulo: Ed Addison-Wesley, 2003 
 
UNIP INTERATIVA, MANUAL PIM VI. Disponível em https://ava.ead.unip.br. Acesso 
em 25/05/2020.