Projeto Interdisciplinar VI Análise e Desenvolvimento de Sistemas SISTEMA DE GERENCIAMENTO DE VENDAS E ESTOQUE: LEVANTAMENTO E ANÁLISE DE REQUISITOS

Prévia do material em texto

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
RNF01 Login do sistema
conectado à rede interna
O sistema deve solicitar
autenticação de usuário e
senha devidamente
cadastrados para acesso
dos funcionários, sendo
necessária conexão à
internet para integração
dos diferentes níveis de
acesso.
RNF02 Consulta de preço
Ao consultar o preço de
um item, o sistema deve
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
da venda de um item
com sucesso e logo em
seguida inicie um novo,
sem atrasos e lentidão de
processamento.
RNF04
Interação de acordo com
o nível de acesso do
usuário
O sistema deve garantir
privilégios e impor
restrições com base nas
atividades
desempenhadas pelo
colaborador na loja.
RNF05 Hardware e software alvo
O sistema será
desenvolvido paraambientes Windows e
para máquinas com pelo
menos 128 MB de
memória
RNF06
Volume de utilização
O sistema deverá
suportar a carga máxima
quando os 6 usuários
estiverem utilizando o
sistema de forma
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
ao estoque
RF03 - Consultar preços de
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
de venda
Total controle ao sistema: atualizar cadastros (produtos e
clientes), precificar itens e gerenciar vendas.
Banco de dados Registro de todos os dados inseridos e armazenados no
SGBD
Leitor de código de
barras
Lê o código de barras do item e garante a agilidade na
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
propósito
Esse caso de uso permite ao usuário acessar o sistema
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
relacionados
RNF01
Identificação Adicionar novo item
Escopo Estoque
Descrição do
propósito
Esse caso de uso permite que o estoquista insira um
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
relacionados
RNF04
Identificação Excluir item
Escopo Estoque
Descrição do propósito
Esse caso de uso permite que o estoquista faça a
exclusão de um item do estoque.
Ator primário Estoquista
Interessados Funcionários
Pré-condições
O funcionário precisa estar devidamente logado e o item
registrado no estoque.
Pós-condições
O produto não estará mais disponível no estoque e não
poderá ser consultado. Um protocolo é enviado ao
sistema financeiro.
Fluxo normal
O funcionário seleciona o produto que deseja registrar a
saída do estoque
Osistema 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
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
Descrição do propósito
Esse caso de uso permite que o atendente consulte o
preço do item de forma manual, ou seja, buscando o
produto por uma especificação.
Ator primário Funcionário
Interessados Loja e cliente
Pré-condições O funcionário precisa estar devidamente logado
Pós-condições
O funcionário terá acesso ao valor do item e às suas
especificações gerais
Fluxo normal
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
compra
Fluxo alternativo
Caso o produto não seja localizado por nome, o sistema
imprime a mensagem “Item não disponível em estoque”
Requisitos
relacionados
Identificação Consultar preço (cód. de barras)
Escopo Atendimento
Descrição do propósito
Esse caso de uso permite que o atendente consulte o
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
Pós-condições
O atendente é capaz de visualizar o valor e as
especificações do item na tela
Fluxo normal
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
venda
Fluxo alternativo
Caso o produto não tenha sido devidamente cadastrado
no sistema, não será possível localizá-lo, o sistema então
imprime a mensagem de erro “Produto não localizado”
Requisitos
relacionados
Identificação Cadastrar cliente
Escopo Registro
Descrição do
propósito
Durante o atendimento, o funcionário irá cadastrar um
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
relacionados
RNF04
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
relacionados
RNF03
Identificação Alterar registros
Escopo Atualizações
Descrição do propósito
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, é
gerado um protocolo.
18
Ator primário Supervisor
Interessados Loja
Pré-condições
O supervisor precisa estar devidamente logado e os
produtos e clientes cadastrados no sistema
Pós-condições Atualizações serão inseridas nos cadastros alterados
Fluxo normal
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
confirmar a validação das alterações
Fluxo alternativo
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
obrigatória”
Requisitos relacionados
Identificação Cancelamento de compra
Escopo Gerência de venda
Descrição do
propósito
Supervisor de venda precisa inserir sua senha de acesso
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
relacionados
RNF04
Identificação Precificação de item
Escopo Gerência de venda e estoque
Descrição do
propósito
Inserir o valor de venda de um produto
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
relacionados
RNF02
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 nodesenvolvimento 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.