1

Universidade Paulista - Unip EAD

Projeto Integrado Multidisciplinar
Curso Superior de Tecnologia em Análise e Desenvolvimento de Sistemas

SISTEMA DE GERENCIAMENTO DE VENDAS E ESTOQUE:

LEVANTAMENTO E ANÁLISE DE REQUISITOS

2021
 2

Universidade Paulista - Unip EAD

Projeto Integrado Multidisciplinar
Curso Superior de Tecnologia em Análise e Desenvolvimento de Sistemas

SISTEMA DE GERENCIAMENTO DE VENDAS E ESTOQUE:

LEVANTAMENTO E ANÁLISE DE REQUISITOS

Análise e Desenvolvimento de Sistemas

2º Semestre

2021
 3

Resumo
O mercado tecnológico de games tem atraído muitos jovens adultos em busca de
distração, e acompanhando esse processo, tem surgido cada vez mais lojas
especializadas no assunto, principalmente no âmbito online. Porém, atendendo às
necessidades dos clientes de Brasília em conseguir de forma rápida jogos em mídia
física ou acessórios para consoles, a ThinkGeek abre sua primeira loja física no
país. Enfrentando alguns obstáculos no novo espaço, a loja contratou a Starship
Software para desenvolver um sistema de gerenciamento de vendas e controle de
estoque da loja. Aqui nesse projeto, documentamos todos os procedimentos de
análise do sistema, partindo da elicitação de requisitos, passando pelas regras de
negócios, identificação, descrição e diagramação de casos de uso e, por fim,
modelagem do banco de dados relacional.
Palavras-chaves: Análise de sistema, Banco de dados, Requisitos.
 4

Abstract:
The game technology market has attracted many young adults looking for distraction,
and following this process, there have been more and more stores specializing in the
subject, especially online. However, meeting the needs of customers in Brasília to
quickly get games on physical media or accessories for consoles, ThinkGeek opens
its first physical store in the country. Facing some obstacles in the new space, the
store hired the Starship Software to develop a sales management system and
inventory control store. Here in this project, we document all system testing
procedures, starting from the requirements elicitation, through the business rules,
identification, description and diagramming use cases, and finally, relational database
modeling.
Keywords: System analysis, Database, Requirements.
 5

Sumário

Introdução 6
1 Panorama do projeto 7
2 Levantamento de requisitos 7
2.1 Requisitos não funcionais 8
2.2 Requisitos Funcionais 9
3 Modelagem de processos de negócio 10
3.1 Regra de negócio 10
4 Casos de uso 11
4.1 Principais objetivos do sistema 12
4.2 Descrição de casos de uso 13
4.3 Diagrama de casos de uso 20
5 Diagrama de classes 21
6. Modelo Entidade-Relacionamento (MER) 22
Conclusão 23
Referências bibliográficas 24
 6

Introdução
A loja ThinkGeek atualmente é uma gigante no comércio online que está
abrindo sua primeira loja física em Brasília. Visando um público jovem, a empresa
foca na revenda de produtos com temática nerd, sendo sua principal atuação no
setor de games. Na ThinkGeek, é possível encontrar acessórios para consoles
(controles, cabos, gadgets, etc), jogos em mídia física e itens colecionáveis como
bonecos Funko Pop com temática de jogos nostálgicos.
Por ser a primeira experiência com uma loja física, a ThinkGeek procurou a
Starship Software para que possamos implementar um sistema informatizado a fim
de controlar o estoque de produtos da loja, as vendas realizadas e o cadastro dos
clientes. O sistema será utilizado pelos funcionários da loja, com diferentes
funcionalidades para cada modalidade de empregado e o acesso será através de
login (código do funcionário) e senha.
A empresa está acostumada com o ambiente virtual, onde os clientes
realizam as compras pelo site e os organizadores mantém o controle dos produtos e
receitas através de planilhas, o que já se tornou obsoleto e seria mais difícil de
aplicar no ambiente físico da nova loja. E justamente por estar lidando pela primeira
vez com um ambiente físico e com mais funcionários, a organização da ThinkGeek
procura, com o nosso sistema, ter uma maior segurança sobre o controle de estoque
(entrada e saída de produtos), podendo verificar a quantidade de vendas realizadas
por cada atendente e incluir ações de metas e comissões aos funcionários.
 7

1. Panorama do projeto
O objetivo principal do sistema que está sendo desenvolvido para a
ThinkGeek é o controle de estoque e o gerenciamento de vendas, sendo o acesso
ao sistema restrito aos funcionários (estoquistas, atendentes e supervisor) em
desktops da loja através de rede interna, sendo que, para realizar o acesso, o
usuário deve estar devidamente cadastrado com login e senha válidos. O sistema
trabalha com 3 níveis de acesso, e, ao identificar o usuário, se comporta de acordo
com a atividade daquele colaborador na loja.
Os responsáveis pelo estoque poderão adicionar e excluir produtos, que
serão categorizados como jogos, acessórios e produtos geek. Cada item possui
código de barras, quantidade em estoque e, se necessário, informações sobre
garantia e fabricante. O estoquista pode realizar atualizações no estoque a qualquer
momento.
Os atendentes ficarão encarregados de consultar preços e outras
especificações dos produtos, realizar vendas e cadastrar clientes. Durante o
procedimento de venda, o atendente irá realizar o cadastro do cliente (nome
completo, CPF, telefone e endereço), os produtos por ele adquiridos e a forma de
pagamento. Ao final, será gerado um código único da venda contendo informações
de data, valor e opção de pagamento. Para realizar a exclusão de algum item da
venda ou o cancelamento da mesma, o atendente deve solicitar ao supervisor que
insira seu código de acesso para validar o procedimento. O atendente poderá
realizar atualizações nos cadastros de clientes.
O supervisor terá acesso a todas as informações inseridas pelos estoquistas e
atendentes, fará a revisão das informações, precificação dos itens e também poderá
atualizar os dados. Caso seja solicitado, o supervisor pode realizar o cancelamento
e exclusão de itens da compra. Nesse sistema, o supervisor tem acesso a todas as
vendas realizadas pelos atendentes durante o dia, com o objetivo de facilitar o
manejo de metas e comissões.

2. Levantamento de requisitos
Quando falamos de requisito, estamos falando de necessidade, condição,
premissa ou solicitação. Trazendo o conceito da palavra para a elicitação de
requisitos de software, trata-se das necessidades do nosso contratante sendo
realizadas por um sistema. Os requisitos caracterizam as funções que um sistema
 8

deve incorporar e as restrições que devem ser impostas. A engenharia de requisitos

de software está relacionada com a definição do que o sistema deve fazer, suas
propriedades emergentes desejáveis e essenciais e as restrições quanto à operação
do sistema e quanto aos processos de desenvolvimento de software
(SOMMERVILLE, 2007, p 77).

2.1 Requisitos não-funcionais

Estando claro o panorama do projeto, iniciaremos o planejamento listando os
requisitos de usabilidade, começando pelos requisitos não funcionais: aquele que
descreve não o que o sistema fará, mas como ele fará.

Identificação Nome Descrição

O sistema deve solicitar

autenticação de usuário e
senha devidamente
RNF01 Login do sistema cadastrados para acesso
conectado à rede interna dos funcionários, sendo
necessária conexão à
internet para integração
dos diferentes níveis de
acesso.

Ao consultar o preço de
um item, o sistema deve
RNF02 Consulta de preço exibir a descrição e preço
em, no máximo, 2
segundos

O sistema deve permitir

que o atendente encerre
um processo de venda
 9

RNF03 Tempo de processamento com sucesso e logo em

da venda de um item seguida inicie um novo,
sem atrasos e lentidão de
processamento.

O sistema deve garantir

privilégios e impor
Interação de acordo com restrições com base nas
RNF04 o nível de acesso do atividades
usuário desempenhadas pelo
colaborador na loja.

O sistema será
desenvolvido para
RNF05 Hardware e software alvo ambientes Windows e
para máquinas com pelo
menos 128 MB de
memória

O sistema deverá
suportar a carga máxima
quando os 6 usuários
estiverem utilizando o
Volume de utilização sistema de forma
RNF06 simultânea com
degradação de
desempenho de, no
máximo, 10% em
qualquer operação
Fonte: Criação própria

2.2 Requisitos Funcionais:

A seguir, a lista dos requisitos funcionais: funções que um software deverá
atender/realizar
RF01- Incluir novo item RF03 - Consultar preços de
ao estoque produtos RF06 - Alterar registros

RF02 - Excluir item do

estoque RF04 - Realizar venda RF07 - Precificar itens

RF05 - Cadastrar clientes RF08 - Cancelar compras

Fonte: Criação própria
 10

3. Modelagem de processos de negócio

Na engenharia de software, a modelagem de processo de negócio visa a
criação de um modelo com os processos de negócios existentes na organização
(NEVES, 2011). Quando é bem arquitetado, um modelo de processos de negócio
evita as ambiguidades e falhas, que podem aparecer durante as narrativas com
linguagem natural de levantamento de requisitos.
Para garantir o bom desenvolvimento da modelagem, podemos contar com
métodos e ferramentas úteis e fundamentais para o entendimento. Uma dessas
ferramentas é o 5H1W, do inglês cinco W´s (What, Who, When, Where, Why) e um
H (How), que consiste em um checklist das atividades estabelecidas e que precisam
ser desenvolvidas com o máximo de clareza possível.
Aplicando o checklist 5W1H em nosso desenvolvimento do sistema para a
ThinkGeek, teremos:
● What? Controlar o estoque de produtos e gerenciar as vendas da loja;
● Why? Promover eficiência no sistema de logística e atendimento;
● Where? Na nova loja física da ThinkGeek em Brasília
● When? Prazo de 2 meses para implementação do sistema e treinamento dos
usuários;
● Who? Funcionários da empresa irão utilizar o sistema;
● How? A partir da análise dos requisitos e escopo do projeto, conseguiremos
desenvolver e implementar um sistema seguro, de fácil usabilidade e de alta
confiabilidade que atinja de forma precisa as expectativas do nosso cliente.
Dessa forma, podemos estabelecer com precisão o planejamento de nosso
objetivo, determinando o que será feito, quem fará o quê, em qual período de tempo,
em qual área da empresa e todos os motivos pelos quais esta atividade deve ser
feita.

3.1 Regra de negócio

Elas são um conjunto de restrições que definem como um processo de
negócio de uma organização deve ser executado, representam determinados
conhecimentos a respeito de um processo e também importantes aspectos
restritivos na execução deste processo
 11

Identificação Restrição de plataforma

Descrição O funcionário não pode acessar o sistema de qualquer outra

plataforma ou OS que não sejam os pré definidos: Windows 10
Desktop.

Identificação Restrição de horário

Descrição O funcionário não pode acessar o sistema fora do horário previsto,

que é das 6:00 às 22:00h.

Identificação Segurança externa

Descrição Nenhuma pessoa não autorizada poderá realizar login no sistema.

Após três tentativas de inserir uma senha sem sucesso, o sistema
fica inoperante por 30 minutos.

Identificação Segurança interna

Descrição Cada funcionário será apresentado a uma interface de sistema de

acordo com seu nível de atuação na empresa. Sendo restrito ao
supervisor de vendas o privilégio de consultar e alterar registros e
cadastros.

Identificação Controle de logística e gerência de vendas

Descrição O funcionário deve cadastrar no sistema todos os clientes

atendidos e vendas efetuadas na loja.
Fonte: Criação própria

Dessa forma, esclarecemos que as regras de negócio representam um

conjunto de instruções que os funcionários da loja seguirão e que devem ser
abrangidos pelo sistema.

4. Casos de uso
Identificando os casos de uso
Com os requisitos e modelos de negócio bem delimitados, nosso próximo
passo é identificar os casos de uso, com a finalidade de descrever como será o uso
das funcionalidades do sistema pelos atores, identificando cada elemento
imprescindível, como o escopo da operação, os interessados na funcionalidade, as
pós e pré condições, o fluxo normal que o sistema deve tomar e os alternativos. Os
 12

atores inseridos no caso de uso designa quem ou o que irá interagir com o
nosso sistema, seja em forma de pessoas, sistemas ou hardware.

Atores Rotina com o sistema

2 (dois) estoquistas Total controle do estoque: cadastramento de todos os

produtos do estoque e atualizações de saída/entrada de
novos itens.

3 (três) atendentes Total controle ao processo de trativa ao cliente: consulta de

produtos, venda e cadastro de clientes.

1 (um) supervisor Total controle ao sistema: atualizar cadastros (produtos e

de venda clientes), precificar itens e gerenciar vendas.

Banco de dados Registro de todos os dados inseridos e armazenados no

SGBD

Leitor de código de Lê o código de barras do item e garante a agilidade na

barras localização pelo sistema, dispensando a inserção do código
de forma manual por parte do atendente.
Fonte: Criação própria

Dentro do ambiente, contamos com um sistema de banco de dados em um

servidor separado dos computadores de atendimento, utilizando um maior
processamento e acesso ao disco rígido. Apenas a alta gerência possui acesso aos
servidores, que estão diretamente conectados ao sistema base (na loja física), onde
são agrupados e alocados todos os dados do sistema, como dados de usuários,
senhas, produtos, etc.

4.1 Principais objetivos do sistema:

● Controle do estoque de produtos (entrada, saída, catalogação, e valores);
● Gerenciamento das vendas;
● Cadastro de clientes;
 13

4.2 Descrição de casos de uso:

Identificação Login no sistema

Escopo Acesso

Descrição do Esse caso de uso permite ao usuário acessar o sistema

propósito através de seu login e senha

Ator primário Funcionário

Interessados Funcionário

Pré-condições O sistema deve estar conectado à rede interna

Pós-condições O funcionário deve obter acesso às funcionalidades do

sistema conforme seu nível operacional

Fluxo normal O usuário abre a aplicação

Insere seu login válido (código de funcionário)
Insere a senha de 6 dígitos numéricos (criado por ele
mesmo)
Com os dados devidamente validados, o login é bem
sucedido.

Fluxo alternativo Caso o usuário insira algum dado inexistente no registro,

o sistema apresenta a mensagem “Usuário não
localizado”
Caso o usuário insira o usuário correto e a senha errada,
o sistema apresenta a mensagem “Senha incorreta”.
Após três tentativas de inserir a senha errada, o sistema
fica inoperante por 30 minutos até uma nova tentativa.

Requisitos RNF01
relacionados

Identificação Adicionar novo item

Escopo Estoque

Descrição do Esse caso de uso permite que o estoquista insira um

propósito novo produto ao sistema.

Ator primário Estoquista

Interessados Todos os funcionários da loja

Pré-condições O usuário deve estar logado ao sistema.

 14

Pós-condições Ao registrar o novo produto, o mesmo pode ser

consultado pelo atendente da loja.

Fluxo normal O funcionário abre a aplicação do sistema e seleciona a

opção “Novo item”
O sistema direciona o usuário à página de especificações
do item
O usuário insere os dados requisitados referentes ao
produto;
O sistema imprime uma prévia das informações e o botão
“Confirmar novo item”
O usuário valida a operação no sistema

Fluxo alternativo Caso seja confirmado o registro com algum campo em

falta, exibir a mensagem “Preencha todos os campos
obrigatórios”.

Requisitos RNF04
relacionados

Identificação Excluir item

Escopo Estoque

Esse caso de uso permite que o estoquista faça a

Descrição do propósito exclusão de um item do estoque.

Ator primário Estoquista

Interessados Funcionários

O funcionário precisa estar devidamente logado e o item

Pré-condições registrado no estoque.

O produto não estará mais disponível no estoque e não

poderá ser consultado. Um protocolo é enviado ao
Pós-condições sistema financeiro.

O funcionário seleciona o produto que deseja registrar a

saída do estoque
O sistema exibe uma mensagem se é realmente
desejável retirar o item do estoque
O funcionário confirma, digita sua senha de acesso e
valida o procedimento
O sistema gera um protocolo e envia ao sistema
Fluxo normal financeiro

Fluxo alternativo Caso o funcionário insira a senha incorreta, o sistema

 15

imprime a mensagem de erro, e, após três tentativas sem

sucesso, o sistema fica inoperante por 30 minutos.
Caso o funcionário tente validar o procedimento sem
inserir sua senha de acesso, o sistema imprime a
mensagem de erro “Senha obrigatória”
Requisitos
relacionados

Identificação Consultar preço (manual)

Escopo Atendimento

Esse caso de uso permite que o atendente consulte o

preço do item de forma manual, ou seja, buscando o
Descrição do propósito produto por uma especificação.

Ator primário Funcionário

Interessados Loja e cliente

Pré-condições O funcionário precisa estar devidamente logado

O funcionário terá acesso ao valor do item e às suas

Pós-condições especificações gerais

O funcionário digita na barra de busca o nome do

produto, o fabricante ou a categoria que deseja localizar
Ao localizar o produto, o sistema imprime o valor do
produto e as especificações e disponibiliza a opção de
“adicionar ao carrinho” caso o cliente queira proceder a
Fluxo normal compra

Caso o produto não seja localizado por nome, o sistema

Fluxo alternativo imprime a mensagem “Item não disponível em estoque”
Requisitos
relacionados

Identificação Consultar preço (cód. de barras)

Escopo Atendimento

Esse caso de uso permite que o atendente consulte o

Descrição do propósito preço de um item através do leitor de código de barras

Ator primário Leitor de código de barras

Interessados Atendente e cliente

 16

Pré-condições O leitor de código de barras precisa estar operacional

O atendente é capaz de visualizar o valor e as

Pós-condições especificações do item na tela

O atendente escaneia o código de barras com o leitor

O sistema localiza o item, imprime na tela o valor e as
especificações e permite que o atendente prossiga com a
Fluxo normal venda

Caso o produto não tenha sido devidamente cadastrado

no sistema, não será possível localizá-lo, o sistema então
Fluxo alternativo imprime a mensagem de erro “Produto não localizado”
Requisitos
relacionados

Identificação Cadastrar cliente

Escopo Registro

Descrição do Durante o atendimento, o funcionário irá cadastrar um

propósito novo cliente

Ator primário Atendente

Interessados Loja e cliente

Pré-condições O atendente deve estar em procedimento de venda e

devidamente logado no sistema

Pós-condições O cliente será cadastrado com sucesso e seus dados

enviados ao sistema financeiro após formalizada a venda

Fluxo normal Atendente, antes de concluir o procedimento de venda,

solicita os dados pessoais do cliente
O sistema apresenta a tela para cadastro de novo cliente
O atendente preenche os campos de cadastro com o RG,
CPF, nome completo, data do cadastro, endereço,
telefone e e-mail do cliente.
O sistema identifica se os dados inseridos estão em
conformidade com o requisitado e é validado o novo
cadastramento.

Fluxo alternativo Caso seja confirmado o cadastro com algum campo em

falta, exibir a mensagem “Preencha todos os campos
obrigatórios”

Requisitos RNF04
relacionados
 17

Identificação Realizar venda

Escopo Gerência de venda

Descrição do propósito O atendente está em procedimento de venda de um

produto

Ator primário Atendente

Interessados Cliente e loja

Pré-condições O produto de interesse do cliente deve estar

devidamente cadastrado no estoque com todas as
especificações

Pós-condições O sistema deve processar tudo rapidamente liberando o

caixa para uma próxima venda em tempo hábil

Fluxo normal O atendente realiza a busca pelo produto através da

leitora de código de barras
Ao localizar, o sistema informa ao atendente as
especificações do item
O atendente adiciona o item ao carrinho virtual, insere os
dados do cliente e os dados da compra
Após o pagamento, o atendente confirma a venda no
sistema
O sistema gera um código único de venda que será
enviado ao sistema financeiro, informando a data da
venda, o valor, a opção de pagamento (dinheiro/cartão),
o status de pagamento e o status da venda.

Fluxo alternativo Caso o produto não esteja cadastrado, o sistema exibe a

mensagem “Item não localizado”
Caso a venda não seja confirmada em até 10 minutos, o
sistema reinicia o procedimento.

Requisitos RNF03
relacionados

Identificação Alterar registros

Escopo Atualizações

Esse caso de uso demonstra que o supervisor pode

realizar alterações de produtos em estoque e de clientes,
para fim de atualização dos dados. Ao final da ação, é
Descrição do propósito gerado um protocolo.
 18

Ator primário Supervisor

Interessados Loja

O supervisor precisa estar devidamente logado e os

Pré-condições produtos e clientes cadastrados no sistema

Pós-condições Atualizações serão inseridas nos cadastros alterados

O supervisor realiza o login no sistema e seleciona o tipo

de alteração que deseja fazer
Após as alterações, o sistema imprime uma prévia e
questiona se o funcionário deseja continuar
Ao confirmar, o funcionário precisa inserir sua senha e
Fluxo normal confirmar a validação das alterações

Caso o funcionário insira a senha incorreta, o sistema

imprime a mensagem de erro, e, após três tentativas
sem sucesso, o sistema fica inoperante por 30 minutos.
Caso o funcionário confirme o procedimento sem inserir
a senha, o sistema imprime a mensagem “Senha
Fluxo alternativo obrigatória”

Requisitos relacionados

Identificação Cancelamento de compra

Escopo Gerência de venda

Descrição do Supervisor de venda precisa inserir sua senha de acesso

propósito ao sistema do atendente para validar o cancelamento

Ator primário Supervisor de venda

Interessados Cliente e atendente

Pré-condições O supervisor precisa estar disponível e com sua senha de

acesso para inserir no sistema do atendente, que precisa
estar devidamente logado.

Pós-condições O cancelamento é validado e registrado no sistema

financeiro

Fluxo normal O atendente identifica a solicitação de cancelamento da

compra e comunica ao supervisor
O sistema solicita que um funcionário autorizado insira a
senha de acesso para validar o cancelamento
O supervisor de vendas insere os dados no sistema
O cancelamento é justificado e registrado
 19

Fluxo alternativo O atendente tenta realizar o cancelamento por si próprio

e o sistema imprime a mensagem de erro “Acesso não
autorizado”

Requisitos RNF04
relacionados

Identificação Precificação de item

Escopo Gerência de venda e estoque

Descrição do Inserir o valor de venda de um produto

propósito

Ator primário Supervisor de venda

Interessados Funcionários da loja

Pré-condições O usuário precisa estar logado ao sistema e os produtos

devidamente cadastrados

Pós-condições O valor do produto poderá ser consultado no sistema

Fluxo normal O supervisor acessa o sistema utilizando login e senha

válidos
O sistema apresenta todos os produtos em estoque
O supervisor insere nos campos destinados o valor de
venda do item e as formas de pagamento aceitáveis (se
permite parcelamento)
O sistema valida todas as informações

Fluxo alternativo Caso seja confirmado o procedimento com algum campo

em falta, exibir a mensagem “Preencha todos os campos
obrigatórios”

Requisitos RNF02
relacionados
Fonte: Criação própria
 20

4.3 Diagrama de casos de uso

Tendo as descrições de nossos casos de uso planificadas, vamos representar
o esquema de atividades desempenhadas por cada funcionário no diagrama abaixo:
Um diagrama de caso de uso é excelente para mostrar a fronteira do sistema
e o que está dentro ou fora dele, além de dar uma visão geral do comportamento do
sistema e como ele é usado e por quem.

Fonte: Criação própria. Programa de modelagem: Astah UML.

 21

5. Diagrama de classes
Usamos o diagrama de classes para descrever a estrutura de um sistema,
representando classes, atributos, operações e as relações entre os objetos que
manipulam o sistema. Essa representação é útil no desenvolvimento de sistemas
pois define todas as classes que o sistema precisa ter e embasa a construção de
outros diagramas, definindo o tipo de comunicação, sequência e estados dos
sistemas.

Fonte: Criação própria. Programa de modelagem: Astah UML.

 22

Modelo Entidade-Relacionamento (MER)

O MER é um diagrama que representa o modelo de dados do nosso sistema,
possibilitando a identificação dos objetos envolvidos no domínio do nosso sistema,
seus atributos e relacionamentos e a representação abstrata da estrutura que irá
constituir o banco de dados.
Com base no diagrama de classes criado anteriormente, vamos identificar as
classes que precisam ser preservadas em nosso DER:

Fonte: Criação própria. Programa de modelagem: Lucidchart.

 23

Conclusão
Esse projeto nos dá uma noção de como é trabalhada a análise e
documentação para o desenvolvimento de um sistema de software, dando ênfase
nos passos principais.
Iniciando pela visão geral do projeto, podemos ter uma noção das
funcionalidades que o sistema precisa ter para resolver o problema proposto pelo
contratante, dessa forma, é possível iniciar a documentação pela elicitação dos
requisitos funcionais e não funcionais. Com os requisitos devidamente listados,
passamos para o planejamento de casos que uso, uma ferramenta que nos
possibilita uma boa visualização das funcionalidades do sistema, identificando todas
as interações de todos os atores (usuários) do sistema e o ambiente em que o
sistema está inserido. Após isso, iniciamos a abstração dos componentes, atributos
dos objetos e métodos que o sistema irá desempenhar, transformando tudo isso em
diagramas. Aplicamos essa forma de prototipação aos casos de uso e às classes
(que predizem a parte de codificação do sistema). Por fim, tratamos do banco de
dados do sistema, modelando suas funcionalidades de acordo com os passos
levantados anteriormente.
 24

Referências Bibliográficas

Versolatto, Fábio Rossi. Análise Orientada a Objetos. – São Paulo: Editora Sol,
2015. 172 p. il.
PINTO, Gisele Lopes Batista. Administração de banco de dados. São Paulo: Editora
Sol, 2020.
SOMMERVILLE, Ian. Engenharia de Software, 8ª edição - São Paulo: Pearson
Addison-Wesley, 2007
NEVES, Denise Lemes Fernandes. Modelagem de Processos de Negócio –
Engenharia de Software. São Paulo - Denan, 2011.
Análise de Sistemas Orientada a Objetos. / Fábio Rossi Versolatto. – São Paulo:
Editora Sol, 2015.